深夜改稿，敲完一句提示词，光标闪了三四秒，字才一个个蹦出来。多数人对模型能力的判断，其实就建立在这样的几秒里。可这几秒内发生的事，跟模型聪不聪明关系不大，更多是推理优化要处理的代价。
先弄清楚在等什么
一次生成可以拆成两段：先把上下文读进去，再一个词一个词往外吐。前一段是算力密集，像一次性做大矩阵乘法，加速卡容易被吃满；后一段相反，每吐一个词都要把整个模型的权重过一遍，算力闲着，带宽先撑不住。所以同样一块卡，读长文档可能很快，写长回答却很慢——慢的地方不一样，能动手的地方也不一样。
这两件事常被混着谈。做服务的人在意吞吐，也就是一张卡一秒钟总共能服务多少词；用产品的人在意延迟，也就是等多久看到第一个字。这两个指标经常互相拉扯：把请求攒成更大的批次一起算，吞吐上去了，排在后面的请求就得多等一会儿。取舍的关键在于把等待放在哪一环，而不是找一个两全的答案。
KV 缓存是绕不开的一笔账
生成时为了避免重复计算，会把注意力里已经算过的键值存下来，这就是 KV 缓存。它让第二个词不必重算第一个词，但也吃显存。上下文越长，缓存越大，能并发的路数就被压下来。相当一部分推理优化的工作，是在这块显存上腾挪：分页管理、按需换出、把相似请求的前缀合并共用。做得好，同样的机器能多接几路；做得糙，显存先满，再快的算力也白搭。
量化与推测，两种不同的赌
量化是把权重和激活压到更低的精度，换来更小的显存占用和更高的带宽利用率。代价通常落在长尾能力上，一些需要精细数值的任务会先露怯，所以低精度能不能用，得看具体任务，不能一概而论。
推测解码走另一条路：用一个小模型先草拟几个词，大模型一次并行校验，猜对了就白赚。它的收益高度依赖草稿的命中率，任务类型一变，效果可能就打折扣。这类方法听着巧妙，落地时往往要先摸清楚自己的流量长什么样。
有些场景不值得动手
还有一层常被忽略：如果请求本身很稀疏，加速卡大部分时间在空转，那么折腾算子融合、调度策略带来的收益，可能还不如把批次拼好、把冷启动压下去。反过来，如果业务对首字延迟极敏感，比如交互式输入补全，把预填充和逐词生成拆到不同的机器上、让它们各自跑在合适的位置，常常比在单机上抠细节更管用。
我自己的判断是，推理优化更像一门关于取舍的手艺，而不是堆技巧。先量清楚瓶颈在哪一层——带宽、显存、调度还是网络，再决定动哪里。不少团队一上来就换框架、试新算子，最后发现真正卡住的是排队策略，或者上下文长度没管住。这类问题不需要什么高深方法，只需要有人愿意把链路从头到尾量一遍。
至于那几秒等待，短期内不会消失，但可以变得可预期。用户能接受慢一点，很难接受忽快忽慢。