成本、质量与延迟

"规模"是个代理指标，且会漏水。

粗略说，更大的模型（更多参数、更多训练算力）往往更有能力、每 token 更慢、每 token 更贵。但参数量是不可靠的标题：架构、训练数据质量与训练算力同样重要，而且许多模型根本不公布参数量。提供方转而暴露档位——通常一个小/快档、一个均衡中档、一个前沿档——这些档位标签是比任何数字都更实用的把手。

持久的直觉：按档位思考，而非按参数。当前的中档模型往往以前沿模型一个零头的成本与延迟，就能匹敌上一代的前沿模型。正是这种代际漂移，使得"用最大的模型"很少是正确默认——去年的旗舰能力就是今年的便宜档。

这个三角。

经典错误是孤立地优化某一个角：选了质量最高的模型，却发现延迟对交互式产品不可用；或选了最便宜的，却上线了用户能察觉的质量退步。正确的框架是一个约束满足问题：在我的延迟预算与成本上限下，我能拿到的最高质量是多少？——在有代表性的评测集上度量，而非在公开基准上。

每个轴，具体说。

成本

按 token 计价，通常输入比输出便宜，且推理/"思考" token 也计费。成本随模型档位以及你携带多少上下文而扩张——一个每轮被灌入巨大提示的小模型，可能比被灌入精简提示的大模型还贵。成本优化往往既是模型选择问题，也是上下文工程问题。

延迟

两个数字要紧：首 token 时间（响应性）与总生成时间（吞吐）。更大的模型与推理模式会同时拉高两者。对交互式体验，首 token 时间加流式通常比原始总时间更重要；对批处理作业，总吞吐主导，延迟几乎无所谓。

质量

不是一个数字。小模型在常规抽取或分类上可与前沿模型持平，却在多步推理上崩溃。"足够好"是任务特定的，正因如此，公开排行榜无法替你和你的任务回答它，而你自己的评测集可以。

围绕三角做工程。

你不必接受单一的全局点。最强的生产模式是路由/级联：每个请求先送到便宜、快的模型；只在便宜模型不确定或检测到任务困难时才升级到更大或推理模型。多数真实流量是简单的，所以多数请求在便宜路径上解决，只有需要的少数才付前沿的成本与延迟。

• 按步骤分档。在智能体内部，每步用能用的最便宜模型：小模型做分类或路由，推理模型只用于真正难的规划步，中档模型写最终答案。
• 积极缓存。提示缓存压平稳定上下文的成本，往往会改变哪一档更经济。
• 先适配规模，再升级。从通过你评测的最小档起步，仅在它可度量地失败处往上走——与"从前沿起步、之后再砍成本"相反。