11 模型选择和工程建议

讲到这里，模型选型就不能只看标价了。

长上下文和 Agent 场景里，真实成本大概由三件事决定：模型基础价格、缓存命中率、链路有没有把缓存优惠传给你。

举个粗算例子。

假设普通输入价格记作 1，缓存读取按 0.1 算。

一个中转站打 3 折，但实际缓存命中率只有 50%。这一轮输入的有效成本大概是：

0.5 × 1 + 0.5 × 0.1 = 0.55

再乘 3 折，就是 0.165。

另一个中转站打 6 折，但缓存命中率能到 95%。有效成本大概是：

0.05 × 1 + 0.95 × 0.1 = 0.145

再乘 6 折，就是 0.087。

看起来 6 折更贵，算完反而便宜得多。它大概只有前者的一半成本。

这就是为什么“几折中转”这个指标很容易误导人。折扣只作用在明面单价上，缓存命中率会直接改变计费基数。长上下文任务里，命中率差一点，价格排序就可能反过来。

所以模型和供应链选择，应该按场景看。

如果是重度 Agent、长会话、代码任务，Claude 仍然很适合。它的优势是可控：breakpoint、TTL、usage 字段都比较明确。代价是工程要求高。上下文放错位置，动态内容太靠前，TTL 选错，账单就会很难看。

如果是产品化调用，OpenAI 的自动缓存更省心。稳定前缀够长，系统会自动尝试复用。它适合结构稳定、调用规模大、工程团队不想手动管理缓存点的场景。

如果是价格敏感的长输入复用，DeepSeek 很值得看。它的缓存命中和未命中价差大，长文档、多轮问答、重复上下文任务会很受益。但前提是调用链路能看到缓存账本。字段不透传，优势就容易被中转站抹平。

Agent 框架的选型，也不要只看“支持多少工具”。

更应该看它怎么组织上下文：稳定规则会不会每轮重写，tool schema 能不能按需加载，MCP 工具会不会一次性全塞进去，compaction 有没有策略，subagent 有没有成本边界。

工具越多，能力越强，但请求也越容易变。缓存命中率最后看的是前缀能不能稳定，工具数量本身不能说明问题。

中转站也是一样。

便宜折扣只是入口。更重要的是三件事：usage 字段有没有透传，缓存输入怎么计费，同一会话有没有路由粘性。

如果一个平台给你 3 折，但每轮都打散缓存，或者把缓存输入按普通输入算，那它未必便宜。如果另一个平台折扣没那么狠，但路由稳定、缓存字段透明、账单能对上，长任务跑下来可能更省。

企业和团队还要多看一层治理能力。

至少要能按项目、用户、key、模型看到输入、输出和缓存相关统计。否则账单涨起来之后，只能看到“某个模型花了很多钱”，看不到钱花在普通输入、重复上下文、工具结果，还是路由打散上。

最后可以用一个简单判断框架。

短输入、低频调用，看模型单价就够了。

长上下文、多轮会话，要看缓存命中率。

Agent 和中转站场景，要看上下文组织和账单透明度。

到了团队规模，缓存就不能再当成模型附带功能了。它应该进入成本治理指标。否则你以为自己买的是便宜模型，实际可能是在为重复上下文、动态工具和不透明链路付钱。