作者花了几个月回答一个听起来很简单的问题：把一个编码工作负载从前沿 API 搬到你自己运行的开源权重模型上，究竟需要什么。他们特意选了编码代理，因为它长周期、脏乱，也是企业最想先搬的工作负载，因为 token 账单在那里涨得最快。做法是在一批真实软件工程任务上跑多种开源权重模型，每个模型配能好好服务它的硬件，再更换上层的代理 harness，然后测量解决了多少任务、耗时多久、能并行服务多少用户。三个结果出人意料：能力是按硬件档位计价的，质量在开源模型里缓慢提升，但硬件是跳变的，因为关键是权重能不能装进你现有那台机器的显存，越过那条线你付的不是多几十亿参数，而是下一台机器；并发是没人做预算的变量，自托管时每个用户都带着上下文、每个上下文都要进显存，延迟在硬件还撑得住之前就变得不可接受，最能干的配置并行服务的人反而最少，而弱配置的盈亏平衡利用率远高于企业实际达到的水平；harness 对解决率几乎没影响，却能改变账单，同样的模型、硬件和任务，墙钟时间能差一倍，一次 prefix caching 的小改动就让他们成本涨了五倍。