#五、推理优化、Serving 与部署工程
#代表笔试题
- 什么是 KV cache？
- 为什么大模型推理时显存会越用越多？
- quantization（INT8 / INT4 / FP16 / BF16）的核心作用是什么？
- batching 为什么能提吞吐，但不一定能降延迟？
- speculative decoding 的基本思想是什么？
- continuous batching 和静态 batching 的区别是什么？
#就地速答
- 问：什么是 KV cache？
答：
KV cache的本质，是把历史 token 在每一层算出来的K/V保留下来。这样在自回归生成下一个 token 时，不需要每一步都把整段历史重新做一遍 attention，而是只算新 token 对历史缓存的交互。详见后文“### 49. 什么是 KV cache？”。 - 问：为什么大模型推理时显存会越用越多？
答：大模型推理显存会越用越多，核心原因不是权重在变大，而是生成过程中历史
KV cache在持续累积。每多生成一个 token，每一层都要多存一份新的K/V，所以上下文越长、输出越长，缓存就越涨。详见后文“### 50. 为什么大模型推理时显存会越用越多？”。 - 问：quantization（INT8 / INT4 / FP16 / BF16）的核心作用是什么？
答：量化的核心，不是“为了把数值变丑一点”，而是把权重、激活或者缓存用更低比特表示，从而减少显存占用、降低带宽压力，并在某些硬件上换到更高吞吐。对推理系统来说，这往往直接对应更低成本和更高并发。详见后文“### 51. quantization（INT8 / INT4 / FP16 / BF16）的核心作用是什么？”。
- 问：batching 为什么能提吞吐，但不一定能降延迟？
答：batching 能提吞吐，是因为 GPU 更擅长并行处理一批请求，而不是一个请求一个请求地喂。把多个请求合成 batch 后，硬件利用率会更高，单位时间能处理的 token 数也更大。详见后文“### 52. batching 为什么能提吞吐，但不一定能降延迟？”。
- 问：speculative decoding 的基本思想是什么？
答：speculative decoding 的思路可以概括成一句话：让便宜的小模型先打草稿，让昂贵的大模型负责验收。具体做法是小模型先一次提议多个 token，大模型再并行检查这些 token 是否能接受；如果大部分都通过，就相当于把原本大模型必须逐 token 做的工作，提前批量推进了。详见后文“### 53. speculative decoding 的基本思想是什么？”。
- 问：continuous batching 和静态 batching 的区别是什么？
答：静态 batching 更像“开整点班车”：先凑一车请求，再统一发车，中途不再变化。它实现简单，但在线场景下会浪费很多空闲，因为不同请求长度差异很大，短请求很快结束后，剩余算力不一定能及时被新请求补上。详见后文“### 54. continuous batching 和静态 batching 的区别是什么？”。
#代表面试题
- 你详细讲一下 Prefill 和 Decode 两个阶段，瓶颈为什么不一样？
- KV cache 为什么既能提速又能成为显存灾难？你会怎么优化？
- vLLM、TGI、TensorRT-LLM、SGLang 这类推理引擎你怎么比较？
- 如果线上服务要求首 token 延迟很低，但吞吐也不能差，你会怎么折中？
- 量化为什么有时几乎不掉效果，有时却会明显掉点？
- 如果你要给 7B、32B、70B 三个模型做路由和部署，你会怎样设计推理层？
#就地速答
- 问：你详细讲一下 Prefill 和 Decode 两个阶段，瓶颈为什么不一样？
答：Prefill 和 Decode 的差别，不能只理解成“一个在前一个在后”，而要理解成它们的硬件画像完全不同。Prefill 阶段要把整段输入上下文一次性过模型，所以矩阵计算多、并行度高，更偏 compute-heavy；Decode 阶段则是逐 token 生成，每一步算量没那么大，但高度串行，而且强依赖
KV cache读取，所以更容易受显存带宽和调度影响。详见后文“### 55. 你详细讲一下 Prefill 和 Decode 两个阶段，瓶颈为什么不一样？”。 - 问：KV cache 为什么既能提速又能成为显存灾难？你会怎么优化？
答：
KV cache之所以既能提速又会变成显存灾难，是因为它解决的是“算太多”的问题，却引入了“存太多”的问题。缓存之后，历史 token 不用反复重算，所以 decode 速度显著提升；但代价是每层、每个历史 token 的K/V都要常驻显存，长度一上去就会很夸张。详见后文“### 56. KV cache 为什么既能提速又能成为显存灾难？你会怎么优化？”。 - 问：vLLM、TGI、TensorRT-LLM、SGLang 这类推理引擎你怎么比较？
答：比较
vLLM、TGI、TensorRT-LLM、SGLang这类引擎时，不应该直接说谁最好，而要先讲比较维度：吞吐、首 token 时延、动态 batch 能力、KV cache管理方式、量化支持、硬件绑定程度、部署和运维复杂度、生态成熟度。详见后文“### 57. vLLM、TGI、TensorRT-LLM、SGLang 这类推理引擎你怎么比较？”。 - 问：如果线上服务要求首 token 延迟很低，但吞吐也不能差，你会怎么折中？
答：如果线上既要很低的首 token 延迟，又不能把吞吐做得太差，通常要靠调度层做折中，而不是指望一个单点技巧解决。常见做法包括：把短请求和长请求拆开处理、做分级路由、小模型优先返回、缓存可复用前缀、针对 prefill 和 decode 分别优化，必要时再引入 speculative decoding。详见后文“### 58. 如果线上服务要求首 token 延迟很低，但吞吐也不能差，你会怎么折中？”。
- 问：量化为什么有时几乎不掉效果，有时却会明显掉点？
答：量化有时几乎不掉效果，有时却掉得很明显，核心原因是不同模型、不同层、不同任务对数值误差的容忍度差很多。有些场景只要保持大体语义正确就行，比如常规聊天或简单分类，量化误差不容易被放大。详见后文“### 59. 量化为什么有时几乎不掉效果，有时却会明显掉点？”。
- 问：如果你要给 7B、32B、70B 三个模型做路由和部署，你会怎样设计推理层？
答：给
7B、32B、70B三个模型做路由时，核心目标不是让最大模型包打天下，而是让“请求价值”和“模型成本”匹配。常见设计是多级路由：简单问答、低风险请求先走7B；中等复杂度请求升到32B；真正高价值、长推理、复杂工具调用或疑难样本再交给70B。详见后文“### 60. 如果你要给 7B、32B、70B 三个模型做路由和部署，你会怎样设计推理层？”。
#这一块真正考什么
- 是否理解推理不是“加载模型然后调 API”，而是一个真正的系统问题。
- 是否知道吞吐、延迟、显存、成本、精度之间必然存在权衡。
#作答抓手
回答部署题时，用这个框架最稳：流量画像 -> 模型选型 -> 推理引擎 -> 显存/吞吐优化 -> 监控与回滚。