自托管开源模型跑编码Agent：模型是最简单的一环

越来越多团队想把自己的编码工作负载从前沿API搬到自托管开源模型上。但真正动手之后会发现，模型选择只是整个工程中最简单的一步。我们花了几个月时间，用真实软件工程任务测试了一批开源权重模型，每个模型搭配能正常服务它的硬件，并在上层更换不同的Agent Harness。测量结果指向三个反直觉的结论。

能力定价是阶梯式的，不是线性的

常见直觉是模型越强、运行成本按比例越高。实际情况并非如此。开源模型的质量在整体上逐步提升，但底层硬件成本却是跳变的——关键在于权重能否塞进你现有机器的内存。

一旦跨过这条线，你付出的不是多几个B参数的代价，而是换一整台机器的代价。所以有些模型性价比很差，有些则非常划算，而这跟它们在排行榜上的位置关系不大。

在我们的测试集中，一个中等规模模型的部署成本是某个更小模型的4倍，但应用性能只提升了约2%。另一个大得多的模型，成本仅比低一档的略高，却能解决明显更多的任务。

真正有用的问题不是“哪个模型最好”，而是“哪个模型刚好落在某个硬件层级内”，并且要用每解决任务成本来衡量，而不是每token成本。

什么是“权重塞进内存”：当你用 GPU 服务一个开源模型时，显存里不只是放参数。权重、KV cache（随并发和上下文增长）、激活值、框架开销都要共享同一块内存。跨过“这个模型能装进我现有机器”的门槛，意味着要么换更大显存的卡、要么上多卡，整机成本随之跳变。这也解释了为什么同一档位内加几个 B 参数几乎不花额外钱，而多出来的那一层内存则要换整台机器。

并发是没人做预算的变量

用API时，并发是别人的问题。你得到相对可预期的响应时间，根本不用操心。

自己管栈之后，并发就成了硬约束。每个用户带来一份上下文，每份上下文都要装进内存，而延迟在硬件真正耗尽之前早就不可接受了。

在我们的各种配置里，一台机器能舒服地承载多少开发者差异极大——而且方向和规格表暗示的相反。最大、最强的配置反而同时服务的人数最少。

大多数自托管商业案例就是在这里悄悄崩掉的。我们测的较弱配置，盈亏平衡利用率远高于企业实际能达到的水平。真实部署中报告的利用率本来就低，管理良好的集群也好不到哪里去。如果你的方案需要接近满负荷，那它就行不通。

Harness改变的是账单，对应用性能影响甚微

我们在相同硬件、相同推理设置下比较了三个广泛使用的编码Harness，原本以为编排层会带来巨大差异。结果在解决率上，它几乎没怎么动指标——不同Harness之间的差距也就是几个任务上下。

但成本上，它影响很大。同样的模型、同样的硬件、解决同样的任务，总墙钟时间因搭配不同能差出2倍。当你租GPU时，墙钟时间才真正定义你的成本。

而且选好Harness之后，评测很关键，因为事情很容易坏掉。实验中，某个Harness本来是明显的赢家，直到下一个软件版本发布，性能直接崩掉。原因是prefix caching的处理方式有个小改动，缓存机制突然完全失效，GPU租用成本暴涨5倍。

关键结论是：选你的开发者想用的Harness，然后做好监控，因为一个点版本升级对你成本的影响可能比换模型还大。

prefix caching 为什么决定成本：在编码 Agent 场景里，system prompt、工具定义、仓库上下文往往占据输入的大头，且每轮对话重复出现。prefix caching 让这些固定前缀的 KV 计算结果被复用，直接省掉大量 prefill 计算。一旦它的处理方式被改动或失效，每次请求都要从头 prefill，GPU 计算时间和墙钟时间同步上涨，表现在账单上就是数倍成本差。

这对你意味着什么

问题不是“自托管是否更便宜”。这么问没有答案，因为它取决于你的工作负载、峰值以及对更慢Agent的容忍度。

更好的问题是：你真实的利用率是多少？以及有哪些东西你无论如何都不能放到别人的API上？不允许离开大楼的数据、没人能限流的栈、不会在季度中途变动的价格——这些理由能经得住电子表格的考验。纯粹的成本理由通常不行。