一个用户在产品页里敲下一句提问，按下回车。屏幕上的光标闪了一下，又闪了一下，答案才一个字一个字地浮出来。这短短几秒里发生的事，常被一个词打包概括——推理优化。听起来像给模型装了个更快的马达，但真拆开看，它更像一场关于时间、显存和耐心的分配。
等待其实是两段不同的时间
把一次回答切成两段：前半段叫预填充，模型要读完你给的整段上下文，算出后续要用的中间结果；后半段叫解码，一个一个往外吐词。这两段的脾气完全不同：前者是一次性的、可以并行的大计算，后者是串行的，每多一个字就要再跑一遍。用户感知到的卡，有时是首字迟迟不来，有时是首字来了但后面吐得慢。两者需要不同的调整，混在一起谈，很容易把力气用在错的地方。
缓存省下的是重复计算
解码阶段能一个词一个词往前走，靠的是把已经算过的中间结果存下来，也就是常说的键值缓存。逻辑很朴素：同一段上下文，不必反复重算。代价是显存。上下文越长、并发越多，缓存占用的空间就越可观，最后往往不是算力不够，而是显存先满。于是你会看到一些看似矛盾的做法：一边想办法压缩缓存，一边又舍不得丢掉历史信息。这里没有通用答案，取决于你的对话有多长、同时有多少人在用。
批处理的两难
GPU 喜欢一次干很多活，把多个请求拼成一批送进去，单位时间能处理的请求数就上去了。但同一批里的请求要互相等待，先来的可能被后来的拖慢。连续批处理试图缓解这一点，让完成的请求随时退出、新的随时加入。可只要目标是吞吐，就一定有人在为排队买单。做产品的人常要在这里做一个不情愿的决定：是让多数人稍微慢一点，还是让少数人快、多数人等。
压缩、近似，以及它们的账单
量化把权重和计算压到更低的精度，投机解码先用小模型草拟、再让大模型核对，这些手段都在做同一件事：把每一步的成本降下来。它们确实有效，但省下的算力往往要在别处找补——精度掉一点、实现复杂度涨一截、某些输入下退化得更明显。工程上有条不太好听但真实的规律：任何一次压榨，都会在某个地方留下一个需要长期盯着的角落。
优化有天花板，衡量标准才是准绳
所以推理优化很少是一个纯技术问题。同样一套手段，放在实时对话里和放在离线批处理里，评价标准几乎是反的。更要紧的往往在于先弄清业务真正在意的那几个指标，而不是把延迟压到多低：首字要多久、每秒要吐出多少字、单次对话的成本能承受多少。这几个数常常互相拉扯，定下来之后，技术选择反而变得清晰。
我更愿意把它看成一笔预算：延迟、吞吐、成本、质量各占一格，你从哪一格多拿一点，就要在另一格还回去。真正难的是承认这种此消彼长，并按场景做出取舍。