我们做推理服务，绕不开一个选择。优化推理性能，是把它和底层的资源调度绑在一起做，还是分开做。我们选分开，而且越来越确信这个选择是对的。
推理优化有哪些事
模型量化，用更低精度换速度，比如从浮点十六位压到八位，显存和计算都省。投机解码，先猜几步再验证，减少串行等待，用户看到的是首字更快出来。批处理，把多个请求拼一起跑，单位时间吞吐上去。还有各种 kernel 层面的细活。这些事做好了，同样的卡每秒能多处理不少请求，单位 token 的成本就降下来。我们实测过一类典型负载，优化到位之后，每百万 token 的成本能降三成以上。
绑死的代价
如果优化写死在某一套调度框架里，用户想换弹性策略就动不了优化，想换优化就动不了调度，两头绑死。比如你调好了一套很棒的量化方案，结果换了个调度框架就得重写。我们倾向让它们解耦。优化层只管把模型跑得又快又省，调度层只管什么时候拉起机器、拉几张、缩不缩。两层通过干净的接口说话。
class InferenceOptimizer(Protocol): def optimize(self, model: Model) -> OptimizedModel: ...
registry.register("speculative-v3", SpeculativeDecoder())
scheduler.use(registry.get("speculative-v3"))好处：各自的迭代互不打扰
调度团队想加一个新区域的路由逻辑，不用碰推理优化。推理团队想上新一个投机解码算法，不用管底层怎么扩缩容。我们这边优化团队上半年迭代了四版解码策略，调度那边完全没动，客户无感地就用上了更快的版本。如果绑死，这四版每一次都得拉着调度一起改。
两层互相成全
有个细节值得提。优化层把单次推理变快，调度层才能把缩容做得更狠。因为每次处理更快，同样流量需要的常驻资源更少，闲置也就更少。两层是互相成全的。我们调参数时常遇到，优化上一层，调度那头的常驻就能降一档，省出来的显存又能让给别的小任务，整体利用率又上去了。
结论：做成独立可替换的一层
推理优化是平台该持续投入的硬功夫，但它不该被锁死在某一套调度里。把它做成独立、可替换的一层，平台才能既跑得快，又调得活。我们现在的优化层是插件式的，新算法来了按接口接进去，调度那头一个字不用改。两层之间接口怎么定，优化层出错了调度层怎么兜底，都是实打实要解决的问题，但方向我们没动摇过。
一组我们见过的优化前后
同一个模型，同样流量，优化前他一天烧的卡，优化后省了三分之一还多。他没加预算，吞吐量反而上去了，省下来的算力拿去跑更多实验，模型迭代反而快了。这比单纯压单价实在，因为它不依赖供应商让利，是自己技术挣来的。
新优化算法上线前，我们有一道验证：先在影子流量上跑，对比原算法的延迟、精度、单位成本，三项都达标才切到正式路径；优化层出错了，调度层不跟着傻等，识别后切到备用路径。方向我们没动摇过，解耦之后平台两边都能独立往前走，哪一边的技术进步都不被另一边拖后腿。
优化团队和调度团队各跑各的路线图，客户不用理解背后的切分，他只知道用着越来越便宜、越来越稳。我们要做的，就是把这两层都做到位，且互不打扰，让任何一边的技术进步都不被另一边拖后腿。
我们内部有个说法，优化是省钱，调度是省心，两件事分开做，合起来才是一个平台该给的东西。客户不一定懂这两层怎么切，但他能感觉到，账单在降、服务在稳，那就够了。