演示环境里，模型回一句话只要眨眼的工夫。上线第一周，监控面板上两条曲线一起抬头：一条是 P99 延迟，一条是每天结算的算力开销。产品经理问“为什么用户说卡”，运维问“为什么这个月翻了一倍”。这两个问题最后都落到同一件事上——推理优化。
先把目标说清楚：压延迟，还是压成本
一次请求在服务端通常被拆成两段。前一段把输入读进去，算出上下文表示，计算密集、并行度高，GPU 大多时候在忙；后一段逐字往外吐，每生成一个词都要把权重和缓存重新读一遍，瓶颈往往落在显存带宽而不是算力上。两段的脾气完全不同，优化手段也就不同。
于是第一个该做的不是选框架，而是定指标。首 token 时间决定用户觉得“快不快”，输出速度决定“顺不顺”，单位请求成本决定这门生意能不能持续。三者经常互相拉扯：把请求攒成更大的批次能提高吞吐、摊薄成本，但排在后面的那个请求会等更久。想同时把两头都按住，通常得在调度上做取舍，而不是靠一个开关。
能省的部分，常常藏在重复里
多轮对话、固定的系统提示词、同一份长文档被反复提问——这些场景里，前缀部分的计算结果其实可以留着复用。缓存命中之后，省下的是实打实的算力，不是纸面上的百分比。代价是显存：缓存占的地方越多，能同时服务的请求越少；淘汰策略写得不谨慎，反而会把命中率做低，变成“看起来很忙，实际上没省”。这块的调优更像内存管理，手感比公式管用。
少算一点，但要清楚少算的是什么
- 量化：把权重和激活压到更低位宽，显存带宽压力随之下降，吞吐往往能上来。但不同任务对数值误差的敏感度差别很大，长文生成、代码、结构化输出这几类，压得太狠会以你看不见的方式掉质量，需要自己的评测集盯着。
- 投机解码：用一个小模型先起草几个词，再由大模型一次性校验。输出越可预测，接受率越高，收益越明显；开放式的创意写作就很难指望它。
- 蒸馏与剪枝：更偏训练侧的动作，但对线上形态影响直接。代价是改动了模型本身，回滚成本比改配置高得多。
这些手段有个共同点：它们都在拿“通用性”换“此刻的效率”。换得值不值，取决于你的业务有多窄。
优化的边界在哪里
有一类需求天生昂贵：超长上下文、复杂多步推理、实时多模态。推理优化能让这类需求的成本从“无法接受”降到“勉强可谈”，但它不会改变量级。把优化当成万能药，去承接本来就不该用大模型解决的问题，最后往往是账单降了一点，体验也降了一点，两头不讨好。
还有一个容易忽略的边界：优化的收益会被版本迭代吃掉。模型换了、上下文变长了、产品加了新功能，原来调好的批次大小和缓存策略可能不再合适。也就是说，这是一件需要持续维护的事，而不是一次性交付的项目。
我更愿意先做的那件事
如果只能给一个建议：先把延迟拆开。把排队、预处理、首 token、逐字生成这几段分别打点，连续观察一周。多数团队真正的问题不是算法不够新，而是没有稳定的测量——不知道钱花在哪一段，也就无从判断某个改动到底有没有用。测量做扎实了，该不该上缓存、该不该量化、批次开多大，答案往往自己就浮出来了。
推理优化不是一个可以一次性勾掉的清单项，它更像一种持续的账目管理：知道每一分算力花在哪，知道哪些开销是必要的，哪些只是没想清楚。