企业客户调用 MaaS 时，买到的是一项能用于生产的服务能力。接口能返回 Token 只是起点，输出要达到约定的质量，服务还要在延迟目标内承载约定流量。
这项能力包含两种承诺。质量承诺回答模型生成的内容能否用于目标任务，性能承诺回答系统在给定 SLO 下能同时处理多少请求。少了任何一项，客户拿到的服务都不完整。
平台内部可以持续更新 runtime、调整 cache、并行策略和算子实现。但每次优化都要重新证明质量和性能仍然满足承诺。合同允许的范围内，优化节省的资源成本才可能成为利润。
MaaS 交付的是质量和性能
质量承诺需要一个可复现的基线：模型在给定任务、评测集和评分口径下达到什么水平。性能承诺也需要明确条件：在约定的请求特征和 SLO 下，一个副本或一组资源能够提供多少吞吐。
两项承诺解决不同问题。模型答得好，但并发增加后延迟超出 SLO，业务无法稳定运行；吞吐足够高，但输出质量低于基线，更多 Token 也没有交付价值。
GPU 数量、runtime、部署模板和调度参数都属于平台的实现手段。合同可能约束模型版本、精度基线、部署形态或性能边界，平台可以在这些边界内优化实现。若优化改变了合同约定的对象，就需要重新定价或取得客户确认。
精度评测则是一个复杂话题。笼统地来说，大家在“行业认可度”、需求场景之间试探自己的底线，并非严谨或完备的度量衡。毕竟也是行业初期，甲乙双方的认知也会不断迭代。不过在执行细节上，测试集、超参数、thinking/non-thinking 和对照基线都需要逐项对齐。否则，不通过可能来自评测配置错误，通过也可能是测了错误的模型或输出格式。
性能压测同样依赖测试条件。输入输出长度及分布、请求到达方式及顺序、cache 状态、部署拓扑和 SLO 都会改变容量结论。脱离这些条件的一条 TPS 曲线，无法直接报价。例如，反复重放同一批请求时，Prefix Cache 命中率可能接近 100%。cache-aware 路由会把请求集中到已有缓存的实例，压测结果反映的是这批数据、请求顺序和路由状态的组合。换成随机输入或保留业务会话的真实增长顺序后，命中率和吞吐都会变化。
快照事实必须与评测/压测绑定版本
评测开始前，平台需要冻结候选版本，记录模型、runtime、模板、拓扑和关键参数。测试数据也要有稳定标识，至少能够区分数据版本、内容变化和请求顺序。这样，结果才能回答测了哪个对象、使用了什么输入。
这里除了人工审核，机器流程已经可以解决大部分的事情，包括部署检查、数据完整性校验和红线阻断，可以采用 CI/CD 那套思路。人工只负责处理合同或例外 case。
注意每当模型、runtime、模板、工况/数据集或关键参数变化后，必须重走流程。这是鉴于推理系统的复杂性和黑盒型，任何变更都得视为历史数据失效。端到端地判断质量或性能是否退化。也许未来随着范式地迭代，能够不必兴师动众。
质量和性能不退化，优化才会形成利润
MaaS 平台赚得是技术优化的利润。量化、cache、并行策略、调度和高性能算子，都可能让平台用更少资源交付相同服务。实现变化后，平台仍需通过精度回归和性能压测，证明输出质量达到原有基线，并且在约定 SLO 下维持原有容量。
对于已有合同，如果服务承诺和计价规则保持不变，资源成本下降会增加平台利润。但若平台准备调整价格、容量步长、模型版本或合同约束，就得重新报价或获得客户确认。对于新客户，则不必这么麻烦，通常会应用新报价。
另一方面，利润还取决于实际部署情况。订单、期望资源和实际部署发生偏差时，闲置或错误分配的资源也会吞掉优化收益。