光明日报：大模型竞争进入“能力+成本”阶段，企业选型为何不能只看效果？

2026年9月3日，《光明日报》关注到，大模型竞争正在从单一的能力比拼，转向能力、成本、算力与治理能力的综合博弈。对企业而言，这意味着模型选型的核心问题不再只是“谁更强”，而是“在具体任务中，谁能以更稳定、可控的成本交付更好的结果”。

大模型竞争的衡量单位正在变化

过去，企业评估大模型，往往围绕参数规模、基准测试成绩、回答质量和产品知名度展开。这些指标仍然重要，但它们主要回答的是“模型具备多强的能力”，并不能直接回答“模型是否适合长期用于业务”。

当模型进入客服、知识管理、软件开发、数据分析和流程自动化等场景后，企业购买的并不是一次回答，而是一项持续运行的任务。一次看似简单的业务结果，可能包含多轮推理、长上下文读取、工具调用、结果校验和失败重试。模型的单次能力，最终要通过完整链路转化为可交付的业务结果。

因此，模型竞争的比较单位，正在从“模型本身”转向“单位任务”。更值得关注的问题包括：

• 完成一次任务需要多少输入和输出词元；
• 是否需要多轮调用，调用链有多长；
• 上下文是否过长，是否存在重复传输；
• 工具调用和检索环节是否增加额外开销；
• 任务失败后需要多少次重试；
• 在业务高峰期，响应速度和服务稳定性如何。

这也是“能力+成本”成为大模型竞争新阶段重要特征的原因。低单价并不必然意味着低成本，高能力也不必然意味着高性价比。只有把模型放进真实任务流程，企业才能看到完整账本。

词元成本为什么会改变采购逻辑

词元是模型处理文本信息的基本计量单位。企业通常看到的是输入词元和输出词元的计费方式，但实际成本还受到上下文长度、调用轮次、推理强度和失败重试等因素影响。

例如，一个模型在单轮问答中表现优秀，但如果智能体需要反复调用它来读取资料、规划步骤、执行工具并检查结果，那么最终成本就不由一次调用的价格决定，而由整条任务链路决定。长文档、多轮对话和复杂工作流尤其容易放大这种差异。

这会带来三个采购变化。

从单价比较转向任务成本核算

企业不应只要求供应商提供每百万词元的价格，而应将典型任务纳入测试。例如，客服工单处理可以测算每单平均调用次数和词元消耗；合同审阅可以测算长上下文处理、风险识别和复核所需的总成本；代码生成则应同时评估生成、调试和重试成本。

更合理的指标是：

单位任务成本 = 模型调用成本 + 检索与工具成本 + 重试成本 + 算力与运维成本 + 人工复核成本

这不是精确不变的财务公式，而是帮助采购团队避免遗漏成本的核算框架。

从“最强模型”转向“任务分层”

不同任务不需要同样强度的模型。复杂规划、关键决策辅助和高风险内容审核，可能需要能力更强的模型；分类、摘要、格式转换和简单信息抽取，则可以优先考虑响应更快、成本更低的模型。

企业可以采用分层策略：让不同模型承担不同难度的任务，并通过路由机制把请求分配给合适的模型。这样做的重点不是追求模型数量，而是让模型能力与任务价值相匹配。

从一次采购转向持续运营

模型价格、能力和服务策略都可能变化，企业不能把模型采购理解为一次性软件采购。上线后仍需持续观察词元消耗、调用峰值、错误率、延迟和业务转化情况，并据此调整提示词、上下文管理、调用频率和模型路由。

智能体调用规模会放大成本差异

智能体与传统问答应用的区别，在于它通常需要自主拆解目标、调用外部工具、读取数据、执行动作并根据结果继续判断。任务越复杂，调用链越长，模型推理成本和系统工程成本就越容易叠加。

这意味着，智能体项目不能只做“能不能完成任务”的演示，还要回答“完成任务需要多少次调用”和“在规模化运行时是否可控”。

企业在测试智能体时，至少应记录以下数据：

• 平均调用轮次和最大调用轮次；
• 单次任务的输入、输出词元量；
• 工具调用次数及失败比例；
• 任务成功率和人工接管率；
• 平均响应时间与高峰期延迟；
• 异常重试是否会造成调用失控；
• 每项业务任务的综合成本。

如果一个智能体虽然效果较好，但经常重复读取相同内容、反复调用工具或因判断不稳定而重试，那么它的实际成本可能远高于测试阶段的预估。反过来，一个能力略逊但流程设计更简洁、调用次数更少的模型，可能更适合大规模部署。

因此，智能体建设不只是模型问题，也是架构问题。上下文压缩、缓存、检索范围控制、工具权限管理、步骤上限和人工确认机制，都会影响最终的成本与稳定性。

企业模型选型应建立五维评估框架

围绕“大模型竞争”和企业AI采购，管理者可以把评估分为五个维度，而不是用单一排名作决定。

1. 效果：是否完成真实任务

效果评估应使用企业自己的业务数据和验收标准，而不是只看公开基准。除了答案准确率，还要关注格式遵循、事实可靠性、复杂任务完成率和人工修改比例。

2. 成本：每项任务到底花多少钱

成本测算应覆盖词元、调用轮次、工具使用、检索服务、推理算力、运维和人工复核。对于智能体，还要特别关注长流程和异常重试带来的尾部成本。

3. 稳定性：能否持续交付

企业需要评估服务可用性、延迟波动、并发能力、限流策略和故障恢复机制。一次演示中的优秀结果，不能替代长期运行中的稳定表现。

4. 数据安全：业务数据如何被处理

采购团队应核实数据传输、存储、日志保留、权限控制和数据隔离等安排，并明确敏感信息是否进入模型训练或其他处理流程。不同业务的数据分级，也应对应不同的部署和调用策略。

5. 供应商可控性：是否能够避免过度绑定

供应商可控性不仅包括价格，还包括接口兼容、服务连续性、版本变更通知、迁移能力和故障响应。企业应尽量避免把核心业务流程设计成只能依赖单一模型的封闭系统。

模型、架构与算力需要联动规划

模型选型一旦脱离架构设计，就容易出现“模型买得好、系统用不起”的问题。相同模型在不同提示词、上下文组织和调用策略下，可能产生完全不同的任务成本。

企业可以先从高频、可量化、风险边界清晰的场景开始，建立任务基线，再进行小规模压测。压测不应只比较最终答案，还应同步记录调用次数、词元消耗、延迟、错误率和人工介入情况。只有这样，采购决策才能与算力规划衔接起来。

在部署方式上，云端API、自建推理和混合架构各有适用条件。高峰波动明显、希望快速上线的场景，可能更看重弹性和运维便利；数据敏感、调用量稳定且具备技术团队的场景，则需要进一步评估自建或专属部署的长期经济性。这里不能简单地把某一种模式视为普遍最优。

编辑判断：企业真正要采购的是可控的交付能力

从“谁更强”转向“单位任务谁更划算”，并不意味着企业可以忽略模型能力，而是要把能力放回业务目标和成本约束中衡量。一个模型只有在真实任务中稳定完成工作，并且能以可预测的成本运行，才具备企业采购价值。

对管理者而言，下一阶段的重点不是追逐每一次模型排名变化，而是建立可复用的评估机制：用真实任务测试效果，用完整链路核算成本，用长期运行验证稳定性，再把安全、供应商治理和迁移能力纳入合同与架构设计。

大模型竞争最终会落到业务交付上。企业AI采购也将从“买一个更强的模型”，转向“建设一套能算清成本、控制风险并持续优化的智能任务系统”。