1. 先说结论：大模型加速不是单点优化，而是系统工程
1.1 为什么大模型会慢？
很多人一听“大模型加速”，第一反应就是换更强的 GPU，或者把模型量化成 4bit。这样想没有错，但只看到了冰山一角。大模型真正慢，通常不是单个原因造成的，而是模型大、上下文长、显存吃紧、KV Cache 膨胀、请求长短不一、GPU 调度不充分、业务链路太重共同作用的结果。
所以，加速大模型不能只问“怎么让模型跑得快”，而要问：首 token 慢不慢？后续 token 生成慢不慢？吞吐够不够？显存能不能撑住并发？P95 和 P99 延迟是不是稳定？每千 token 成本能不能接受？这些问题拆开后，才知道该优化哪里。
1.2 面试里最稳的回答框架
可以先把加速拆成五层：模型层、结构层、算子层、服务层、业务层。模型层包括量化、蒸馏、剪枝和小模型路由；结构层包括 KV Cache、MQA/GQA、Speculative Decoding；算子层包括 FlashAttention、算子融合、 CUDA Graph；服务层包括连续批处理、PagedAttention、Prefix Cache、Chunked Prefill；业务层包括缓存、降级、RAG 上下文裁剪和模型路由。
2. 大模型 推理 的两个阶段：Prefill 和 Decode
2.1 Prefill：模型先把题读完
当用户发来问题、历史对话和 RAG 检索证据后，模型要先把这整段输入读进去，这个阶段叫 Prefill。它通常影响首 token 延迟，也就是用户从点击发送到看到第一个字之间的等待时间。
Prefill 的特点是一次处理很多输入 token，矩阵计算比较集中。如果上下文很长，比如塞了几十页文档、很多历史对话，首 token 就会明显变慢。因此，Prefill 的优化方向通常是缩短上下文、做好检索重排、使用 FlashAttention、Prefix Cache 和 Chunked Prefill。
2.2 Decode：模型逐字写答案
Decode 阶段则是模型一个 token 一个 token 地生成答案。因为自回归模型必须先生成前一个 token，才能继续生成下一个，所以它天然很难完全并行。这个阶段常常受 KV Cache 读取、显存带宽、调度效率影响。
Decode 优化的核心是让每一轮生成尽量少浪费：管好 KV Cache，避免显存碎片，做连续批处理，提高 GPU 利用率，必要时用量化和投机解码降低成本。
3. 量化：最常见、最直接的模型压缩与推理加速手段
3.1 量化到底在做什么？
量化可以简单理解为：原来模型权重用很精细的小数表示，现在用更粗但更省空间的数字表示。比如从 FP16 降到 INT8、INT4，显存占用会明显下降，模型加载更轻，显存带宽压力也会降低。
但量化不是白捡性能。位数越低，模型精度风险越大。一个在聊天上看起来没问题的量化模型，可能在代码、数学、 长上下文 、工具调用等场景突然下降。所以生产环境不能只看几个 demo，要做任务集回归测试。
3.2 常见量化方法怎么理解？
GPTQ 更像是一种离线后训练量化方案，会利用校准数据估计权重量化误差；AWQ 关注激活分布，试图保护少量更重要的通道，因此常见于 4bit 权重量化；SmoothQuant 更偏向权重和激活一起量化，解决激活值难量化的问题；KV Cache 量化则是专门针对长上下文推理中不断增长的缓存显存。
3.3 量化怎么选？
如果是严肃生产场景，通常先从 FP16/BF16 或 INT8 开始；如果部署成本压力很大，再考虑 INT4；如果是长上下文、高并发、KV Cache 爆显存，则要重点看 KV Cache 量化。面试里不要只说“量化能加速”，还要补一句：量化一定要结合业务评测、回归测试和质量监控。
4. KV Cache：大模型推理里最关键的显存战场
4.1 KV Cache 为什么能加速？
模型在生成每个 token 时，都要关注前面所有历史 token。如果每一轮都把历史重新算一遍，那会非常慢。KV Cache 的作用就是：把历史 token 的 Key 和 Value 缓存起来，后面生成新 token 时直接读取，而不是重复计算。
从用户体验上看，KV Cache 能显著降低后续 token 的生成成本；从系统角度看，它又会吃掉大量显存，尤其是长上下文和高并发场景。
4.2 PagedAttention 为什么重要？
传统 KV Cache 管理容易遇到碎片化问题：每个请求长度不同，生成长度也不确定，显存中会出现大量空洞。PagedAttention 的思想很像操作系统的虚拟内存分页：逻辑上连续的 KV Cache，可以被拆成固定大小的块，物理上分散存放。这样能减少碎片浪费，也更适合动态请求调度。
这也是 vLLM 能在服务端吞吐上表现突出的核心原因之一。你可以把它理解成：不是模型本身变聪明了，而是显存管理变得更聪明了。
5. Continuous Batching：让 GPU 不再“等人”
5.1 传统静态批处理的问题
传统批处理像是等一车人坐满再发车。问题是，大模型请求长度差异很大，有的用户只问一句，有的用户塞了很长上下文；有的答案 20 个 token 就结束，有的答案要 1000 个 token。短请求提前结束后，如果整个 batch 还被长请求拖着，GPU 利用率就会下降。
5.2 连续批处理的直觉
Continuous Batching 像地铁到站上下客：每一轮 decode 后，完成的请求退出，新来的请求加入，让 GPU 尽量一直保持满载。这种方式非常适合 LLM 在线服务，因为请求是持续流入的，生成长度又不确定。
面试时可以这样说：连续批处理主要解决的是吞吐和 GPU 利用率问题，通常要和 KV Cache 管理、PagedAttention、调度器一起看。
6. FlashAttention：为什么它能让 Attention 更快？
6.1 不是少算了，而是少搬了
普通 Attention 在计算时会产生很大的中间矩阵，尤其是长序列时，内存读写非常重。GPU 里显存 HBM 容量大但读写成本高，片上 SRAM 很快但容量小。FlashAttention 的核心思想，就是把计算切成块，在更快的 SRAM 中分块完成，减少来回读写。
这也是为什么 FlashAttention 常被称为 IO-aware，也就是“懂 GPU 内存层级”的 Attention。它不是通过近似牺牲准确率，而是在保持精确 Attention 的前提下，优化数据搬运方式。
6.2 适合什么场景？
长上下文、训练大模型、Prefill 阶段、Attention 占比较高的场景都更容易受益。你可以把它放在“算子级加速”这一层来讲，和量化、批处理、缓存属于不同维度的优化。
7. Speculative Decoding：小模型先猜，大模型批量验证
7.1 为什么需要投机解码？
Decode 阶段最大的问题，是模型一次只能生成一个 token。Speculative Decoding 的想法是：用一个更快的小模型先草拟多个 token，再让大模型一次性验证。如果小模型猜得准，大模型就能接受多个 token，相当于一次向前走了好几步。
7.2 它不是所有场景都适合
投机解码的收益取决于小模型的速度和接受率。小模型太弱，猜错多，大模型验证后大量拒绝，收益就小；小模型太大，猜得准但自己也慢，得不偿失。因此它适合目标模型慢、小模型足够快且两者输出分布比较接近的场景。
8. 多 GPU 并行：模型太大、请求太多时怎么拆？
8.1 张量并行、流水线并行、数据并行分别解决什么问题？
张量并行是把同一层的大矩阵拆给多张 GPU，适合单层太大或单卡放不下；流水线并行是把不同层放到不同 GPU，适合模型层数多、整体显存压力大；数据并行是多份模型处理不同请求，适合吞吐扩容；专家并行则常见于 MoE 模型，把不同专家分到不同设备。
8.2 选择并行方式前，先判断瓶颈
如果模型单卡放不下，优先考虑量化、张量并行、流水线并行或 Offload；如果模型能放下但吞吐不够，优先看连续批处理、数据并行和缓存；如果单请求延迟太高，再考虑张量并行、算子优化和投机解码。
9. 推理框架怎么选？vLLM、TensorRT-LLM、TGI、SGLang 都是什么定位？
9.1 vLLM：高吞吐服务化的常见选择
vLLM 的核心卖点是 PagedAttention、Continuous Batching、Prefix Cache、 OpenAI 兼容服务接口和较活跃的生态。它适合快速把开源大模型变成高吞吐在线服务。
9.2 TensorRT-LLM：压榨 NVIDIA GPU 性能
TensorRT-LLM 更偏向在 NVIDIA GPU 上做深度优化，包括 in-flight batching、KV Cache、量化、并行、插件算子等。它适合对性能、成本和 GPU 利用率要求很高的生产场景，但工程复杂度通常也更高。
9.3 TGI 与其他框架
Hugging Face TGI 更贴近 Hugging Face 生态，支持连续批处理、Flash/Paged Attention、监控与分布式追踪等生产能力。SGLang、LMDeploy 等框架则常用于更复杂的结构化生成、 Agent 、国产模型或特定部署环境。
10. 业务层加速：别让大模型干所有活
10.1 模型路由：简单问题走小模型，复杂问题走大模型
很多系统成本高，并不是因为模型选错，而是所有请求都走同一个大模型。实际上，简单分类、FAQ 命中、格式转换、摘要清洗等任务，可以交给小模型；复杂推理、长上下文分析、关键业务决策再交给大模型。
10.2 缓存：最便宜的加速手段之一
在客服、知识库、代码问答、报告生成等场景里，大量问题是重复或相似的。常见缓存包括：Prompt 前缀缓存、检索结果缓存、FAQ 答案缓存、完整响应缓存。缓存命中时，速度和成本都会明显下降。
10.3 RAG 上下文裁剪：别把垃圾证据塞给模型
RAG 系统里经常出现“检索越多，答案越差”的情况。原因是上下文太长、噪声太多，Prefill 变慢，生成也更容易被无关内容干扰。因此，检索重排、证据裁剪、父子切片、引用控制，本质上也是大模型加速的一部分。
11. 上线前怎么评估大模型加速是否真的有效？
11.1 不要只看平均延迟
平均延迟很好看，不代表系统稳定。生产系统一定要看 P50、P95、P99，尤其是高并发、长上下文、低显存余量时的尾延迟。很多系统不是平时慢，而是高峰期突然排队、OOM 或超时。
11.2 同时看质量和速度
比如量化后速度提高了，但答案质量下降；上下文裁剪后首 token 变快，但关键信息被裁掉；小模型路由降低成本，但复杂问题误判给了小模型。这些都说明，加速评估不能只看速度，还要看任务成功率、准确率、用户满意度和失败率。
12. 总结：大模型加速的核心，是“先定位瓶颈，再组合方案”
大模型加速不是单一技术，而是一套从模型到业务的系统工程。Prefill 慢，就优化上下文、Prefix Cache、Chunked Prefill 和 FlashAttention；Decode 慢，就优化 KV Cache、PagedAttention、连续批处理、量化和投机解码；显存不够，就做量化、KV Cache 压缩、Offload 或并行；吞吐不够，就看调度、批处理、数据并行和缓存；成本太高，就做模型路由、蒸馏和业务降级。
面试里最好的回答，不是把所有名词背一遍，而是先说明瓶颈在哪里，再解释为什么选这个方案，以及这个方案会带来什么副作用。真正的工程能力，体现在能把速度、成本、质量和稳定性一起权衡。
附：30 秒面试快答模板
“大模型加速我会先拆瓶颈。Prefill 慢主要影响首 token 延迟，可以通过减少上下文、Prefix Cache、Chunked Prefill、FlashAttention 优化；Decode 慢主要影响后续生成速度，可以通过 KV Cache 管理、PagedAttention、连续批处理、量化和 Speculative Decoding 优化；如果显存不够，可以做 INT8/INT4 量化、KV Cache 量化、Offload 或多 GPU 并行；如果吞吐不够，可以用 Continuous Batching、数据并行和缓存；如果成本太高，可以做小模型路由、蒸馏和业务降级。生产里要同时看 TTFT、TPOT、吞吐、P95/P99、显存、失败率和每千 token 成本。”
