大模型价格战收尾，成本战刚刚开局

过去一段时间，大模型服务的公开报价持续下探：输入价格被压到个位数元/百万词元量级，对话类产品出现免费策略，API价格也不断向更低区间靠拢。百度在对话类产品免费与API价格下探上的动作，是这一阶段的典型信号。对市场而言，价格战完成了用户教育和需求激发；对开发者和企业而言，真正的挑战才刚刚开始：当单价不再是唯一变量，如何用可度量的工程体系控制“完成一次业务任务”的综合成本，才是下一阶段的核心竞争力。

一、价格战为何阶段性收尾

价格战收尾，并不意味着竞争消失，而是竞争维度发生了变化。

第一，公开单价正在逼近可感知的边际成本。大模型推理需要持续消耗算力、显存带宽、网络与存储资源，免费或极低价格可以短期获客，但难以长期覆盖峰值容量、冷启动、失败重试和运维治理成本。第二，报价透明化让“只看单价”的营销空间收窄。不同服务在输入/输出计费、缓存命中、批处理、上下文长度、并发限制和SLO上的口径并不完全一致，单纯比较每百万词元价格容易失真。第三，企业用户开始从“能不能用”转向“值不值得规模化用”。试点阶段的成本可以被预算吸收，生产阶段则必须回答每成功请求成本、每会话成本、每业务动作成本等更贴近经营的问题。

因此，价格战阶段性结束，成本战刚刚开局。成本战不是继续压低报价，而是围绕单位经济性进行系统性优化：用更少的资源完成更多有效任务，用更可观测的链路定位浪费，用更稳定的容量规划抵御峰谷波动。

二、从“每百万词元”转向“每成功任务”

大模型服务的成本不能只看账单上的词元单价。一个请求从进入系统到产生业务价值，通常经历鉴权、路由、上下文组装、模型推理、结果校验、重试、日志记录与后处理等环节。任何一个环节的低效都会放大总成本。

建议建立三层成本指标：

1. 资源层指标：算力利用率、显存占用、缓存命中率、网络出入流量、存储占用、冷启动次数。
2. 服务层指标：每千次请求成本、每万词元成本、P95/P99延迟、超时率、重试率、降级率。
3. 业务层指标：每成功任务成本、每会话成本、每转化成本、每工单处理成本、每文档解析成本。

其中，“每成功任务成本”最值得作为主指标。因为失败请求、无效重试和过度生成都会消耗资源，却不产生业务价值。可以用如下伪代码建立基础核算：

function cost_per_success(requests):
    total_cost = 0
    success_count = 0
    for r in requests:
        total_cost += r.input_tokens * price_input
        total_cost += r.output_tokens * price_output
        total_cost += r.cache_lookup_cost
        total_cost += r.retry_cost
        total_cost += r.network_and_storage_cost
        if r.status == "success" and r.quality_check == "pass":
            success_count += 1
    return total_cost / max(success_count, 1)

这段伪代码的意义不在于精确到某个接口，而在于明确成本归因：输入、输出、缓存、重试、网络存储都应进入同一张成本账。只有把“失败成本”和“质量返工成本”纳入核算，才能避免单价下降但总成本上升的假象。

三、成本构成拆解：钱花在哪里

1. 推理链路成本

推理成本通常由预填充和解码两部分构成。长上下文会显著增加预填充开销，长输出会增加逐词元解码开销。工程上应优先控制上下文长度和输出长度：对历史对话做摘要，对检索结果做重排与截断，对结构化任务限制最大输出，对确定性任务使用模板化返回。

2. 缓存与复用成本

缓存是成本战中的高杠杆手段。结果缓存适合确定性查询；语义缓存适合表达多样但意图稳定的场景；前缀缓存适合共享系统提示词或固定知识框架的请求。缓存设计必须同时考虑命中率、失效策略、数据隔离和审计要求。缓存命中率提升一个百分点，可能比单纯等待报价下降更有价值。

3. 模型路由成本

并非所有请求都需要同等规模的模型。可按任务类型、输入长度、置信度、业务价值和延迟要求进行路由：简单分类、抽取、改写优先使用小模型；复杂推理、长文档分析和高质量生成再升级到大模型；离线任务进入批处理队列；低置信度结果触发回退或人工审核。伪代码示意如下：

function route_request(req):
    if req.task_type in ["分类", "抽取", "短文本改写"] and req.length < SMALL_CONTEXT_LIMIT:
        return small_model
    if cache_hit(req.normalized_prompt):
        return cached_result
    if req.offline or req.deadline > OFFLINE_THRESHOLD:
        return batch_queue
    if req.business_value >= HIGH_VALUE and req.quality_requirement == "strict":
        return large_model_with_budget(req.budget)
    return medium_model

4. 容量与弹性成本

生产环境的成本往往不是平均负载决定的，而是峰值负载决定的。为峰值过度预留容量会浪费资源，为峰值准备不足则会造成超时、重试和体验下降，反而推高总成本。需要结合历史流量、业务日历、并发模型和冷启动时间做容量池规划，并通过弹性伸缩、混部、队列削峰和降级策略降低峰谷差。

5. 可观测性与治理成本

没有成本可观测性，就无法治理。应在日志、指标和追踪中统一打入业务标签、模型标签、租户标签和请求链路标签，形成成本归因。建议至少监控：每成功请求成本、缓存命中率、重试率、超时率、平均输入/输出长度、P95/P99延迟、资源利用率、预算消耗速率。预算告警应与自动降级、限流和路由策略联动，而不是只做事后报表。

四、可落地的成本治理闭环

成本战需要闭环，而不是一次性优化。

第一步，建立预算。 按业务线、租户、任务类型设置预算与阈值，明确哪些请求可以升级大模型，哪些必须走批处理或小模型。

第二步，做成本归因。 每个请求携带追踪标识和业务标签，将资源消耗映射到具体场景。没有归因的优化容易误伤核心业务。

第三步，执行优化。 从上下文压缩、输出限制、缓存、路由、批处理、量化和弹性调度中逐项验证，优先做收益高、风险低的改动。

第四步，质量回归。 成本优化不能以牺牲任务成功率为代价。应使用固定评测集对路由、缓存、压缩和降级策略做回归，确保每成功任务成本下降的同时，质量指标不出现不可接受的退化。

第五步，审计与复盘。 定期检查异常重试、长尾请求、缓存污染、容量闲置和预算漂移，把成本指标纳入发布流程。

在百度智能云环境中，可通过通用监控告警、日志服务、容器平台与对象存储等类目能力承载上述闭环：监控告警用于预算与异常检测，日志服务用于成本归因与审计，容器平台用于推理服务弹性调度，对象存储用于评测集、审计记录与冷数据归档。关键不是堆叠工具，而是让指标、预算、路由和发布流程形成联动。

五、常见误区与工程建议

第一，只看公开报价，不看综合成本。低价可能伴随更长的重试链路、更高的失败率或更保守的限流策略。第二，忽略长上下文和长输出。上下文和输出是成本放大的主要来源，必须在产品设计阶段设定边界。第三，缺少质量校验。低质量结果会带来人工返工，返工成本往往高于推理成本。第四，缓存没有隔离与失效策略。缓存命中率提升的同时，可能引入数据泄漏和过期结果风险。第五，容量规划只看平均值。峰值、冷启动和突发并发才是成本治理的难点。

更稳妥的做法是：先建立“每成功任务成本”主指标，再围绕请求层、模型层、服务层和基础设施层逐层优化；先做可观测，再做自动化；先保证质量回归，再扩大降级与缓存范围。

结语

大模型价格战让行业完成了第一轮市场教育，但成本战才是长期竞争的主战场。单价下探会继续发生，但真正决定企业能否规模化使用大模型的，是单位经济性、工程治理和持续优化能力。把成本从“账单数字”变成“可归因、可预算、可优化、可审计”的工程体系，开发者才能在价格战收尾之后，赢得成本战的主动权。