MaaS平台价格不能只看报价单上的软件或接口费用。模型调用、GPU算力、存储网络、实施交付、人力、监控和闲置资源可能分散在不同科目中，只有先统一服务范围、流量假设和责任边界，企业才有可能比较自建、托管和私有化方案的真实投入。

成本口径：本文只给予变量、科目和核算方法，不写市场价格、折扣、ROI或节省比例。

为什么报价不能直接横比

不同方案的“价格”可能对应完全不同的对象：有的按请求或Token计量，有的按实例或资源时间计量，有的把实施、升级和运维放在服务包中，还有的只报价平台软件，基础设施和内部人力由企业承担。把这些数字直接放在一起，会得到一个看似精确却没有可比性的结论。

比较前要先回答四个问题：买的是什么服务，使用什么资源，谁负责交付和运维，成本按什么时间与业务范围计量。若其中任何一项不清，应先建立假设表，而不是先向供应商追问最终总价。

软件和服务成本怎样拆

可以先按成本对象建立地图，再由采购、财务和技术共同确认具体计量方法：

*图：统一服务范围、流量假设、阶段和责任边界后，再拆解六类成本科目，避免不同报价口径直接横比。*

表格不是报价模板，而是避免重复或遗漏的检查框架。比如平台软件已经包含某类监控能力，不代表企业的值班、告警分派和故障演练就不需要投入；云上算力按使用量计费，也不代表模型、存储和网络依赖没有成本。

算力与调用成本怎样计量

MaaS成本通常同时受请求量、输入输出规模、模型类型、并发、服务副本、资源规格和使用时段影响。预算阶段不一定需要精确预测每个请求，但要把变量列出来，并说明哪些变量最可能改变方案选择。

建议准备三组假设：

• 业务假设：日请求量、峰值窗口、输入输出、用户与应用数量
• 平台假设：模型数量、服务数量、版本变化、资源配额和保留容量
• 运营假设：监控范围、日志留存、升级频率、故障窗口和支持角色

对于共享GPU、弹性服务或多模型路由，还要说明闲置、抢占、冷启动和故障备用资源如何计入。没有统一的业务样本和资源条件时，不应用某个厂商的示例单价推导企业总成本。

试点与生产为什么要分开

试点通常模型少、流量低、范围受控，生产则可能需要更长的运行窗口、备份、日志、告警、权限、容量和故障响应。如果用生产规模估算试点，容易过度采购；如果把试点成本直接外推到生产，又会漏掉持续运营对象。

可以把预算分成三个阶段：

1. 场景试点：关注样本、模型服务、必要资源和测试证据。
2. 受控共享：增加项目、权限、入口、计量、监控和交付动作。
3. 生产扩展：增加容量、备份、升级、值守、回退和多业务接入。

每个阶段都要写进入条件和退出条件。阶段扩展不是自动发生，而是由真实流量、模型数量、业务价值、团队能力和风险要求触发。

如何做敏感性分析

预算不确定时，最有价值的不是给出一个虚假的单点数字，而是找出会改变决策的变量。例如请求量增长、模型服务数量变化、资源利用率、日志留存、支持窗口、故障备用和内部人员投入，都可能让自建与采购的边界发生变化。

可以为每个变量记录基准、上行、下行和验证方式，并标记由谁给予数据。财务需要知道哪些科目是固定投入，技术需要知道哪些依赖工作负载，采购需要知道哪些项目包含在供应商报价，业务需要知道增长假设是否可信。

采购证据如何支撑成本判断

每个成本数字都应能回到可复核证据。模型调用费用关联计量字段和账单样例，算力费用关联资源申请、实际使用和保留容量，存储网络关联容量与流量记录，实施和运维关联人员、阶段输出、服务窗口与问题单。供应商报价中的“包含”也要写清版本、数量、期限和排除项。

建议在POC中采集一段代表性工作负载，记录请求、输入输出、并发、资源、日志量和人工动作，再由技术、财务与采购共同确认如何外推。POC只给予估算依据，不直接承诺生产成本；业务增长、模型变化、资源冗余和支持范围仍需用敏感性分析表达。

成本失控时如何缩小或退出

成本治理需要预先设定触发条件，例如单位调用成本持续偏离假设、保留资源长期低效、共享治理带来的人工工作超出计划，或供应商计量无法与企业记录核对。触发后先定位变量，区分业务增长、模型变化、资源配置和合同口径，再决定优化、缩小范围或更换方案。

退出预算不能遗漏模型与配置导出、接口改造、双轨资源、旧环境保留、数据清理和供应商支持。即使本期不计划迁移，也应在采购时确认这些对象和责任。没有退出估算的低价方案，可能把成本推迟到合同结束或业务切换阶段。

预算责任人如何持续校准假设

成本模型需要定期由业务、平台、财务和采购共同更新。业务确认请求与增长，平台确认资源、日志和容量，财务确认科目与分摊，采购核对合同包含项和变更价。每次更新保留数据期间和来源，避免不同月份使用同名但不同口径的数字。

预算复核与下一步

在正式比较方案前，建议建立一张“科目—变量—责任人—证据”表，要求每个数字都能回到业务样本、资源记录、合同范围或内部人力假设。没有来源的数字应标记为待确认，不用精确的小数掩盖不确定性。

下一步可以选一个真实模型服务，记录请求、资源、存储、日志、交付和运维假设，再分别填入自建、托管和私有化方案。若需要进一步判断资源与服务边界，可结合AI基础设施和模型服务文章继续核对，但不应把通用成本模型直接解释成某个平台报价。

常见问题

Token成本如何进入MaaS预算？

先确认Token字段来自哪里、统计的是输入、输出还是合计、是否包含重试和失败请求，以及不同模型或路由是否使用同一口径。Token只是调用计量的一种输入，最终预算还要结合请求量、模型类型、上下文长度、并发、服务方式和其他平台成本。

预算阶段可以用业务样本得到请求量和输入输出范围，再做变量敏感性分析。不要直接拿公开示例或供应商展示的单次调用数字推导生产总成本；未确认的计量字段应由技术、采购和财务共同核对。

还要把计量异常和供应商账单与企业日志进行抽样核对，确认字段、时区和统计窗口一致。若存在多模型路由，应分别记录模型选择和重试，避免同一业务请求被重复或错误计费。

GPU闲置要不要计入成本？

如果企业为模型服务预留了资源，闲置、峰值备用、冷启动和故障冗余都可能影响真实投入。是否计入以及如何分摊，取决于资源池、租户、业务窗口和财务核算口径，但不能因为某段时间没有请求就把保留资源当成零成本。

建议同时记录资源申请、实际使用、峰值、回收和共享情况，并区分试点、受控共享和生产阶段。平台利用率可以帮助发现治理问题，但不能在没有统一工作负载和资源条件时承诺某个提升比例。

对于共享资源，还要确定成本如何按项目或服务分摊，以及冗余资源由谁承担。闲置不必简单等同浪费，但其业务目的、保留窗口和回收门槛应能被解释和复核。

实施服务和持续运维如何区分？

实施服务通常围绕安装、配置、集成、迁移、培训和初始验收，持续运维则涉及监控、升级、故障、容量、备份、值守和长期变更。不同项目会有不同边界，采购时应把每项动作、角色、时间窗口和输出写清，而不是用“技术支持”一项概括。

预算表可分别记录一次性项目投入和持续运行投入，并标注企业承担的内部人力。若供应商只给出实施报价，却没有说明升级、故障和退出支持，企业仍需把这些未覆盖工作纳入风险与资源计划。

持续运维还可能包含版本维护、安全修复、监控规则、容量评审和退出支持。报价中没有覆盖的动作要指定企业责任和预算，不能在验收后再默认由交付团队免费承担。

报价缺少假设时应该怎么办？

先不要把多个供应商的总价直接排序。要求每家供应商按同一模板说明计量对象、服务范围、模型和资源前提、流量窗口、支持内容、排除项和变更条件，再把报价拆成可比较的科目。

如果仍有变量无法确认，就在预算中保留区间和待验证项，并安排小范围POC或商务澄清。采购结论应同时说明价格数字的适用条件，避免合同签订后才发现网络、存储、日志、实施或运维没有被计入。

澄清后的报价应保存版本，并规定业务量、模型、资源或服务范围变化时如何重新计价。没有同口径条件的候选可以继续补充材料，但不宜用总价参与直接排名。