AI全栈知识13模型加速 - 量化、KV Cache与推理优化写在前面你部署了一个大模型用户问一个问题模型想了5秒才回答。用户又问了一个又等5秒。5秒看起来不长但如果100个人同时问呢排队等到天荒地老。模型加速要解决的就是这个问题同一个模型、同样的回答质量怎么让它更快、更省资源这不是换一个更大的GPU就能解决的那是加钱不是加速。真正的加速是用更聪明的方法让模型跑得更快。为什么大模型推理慢先搞清楚慢在哪里。大模型推理的瓶颈不是计算GPU算得飞快而是瓶颈一模型太大显存装不下模型参数量FP16显存需求一张T4能装下吗Qwen2-1.5B15亿约3GB能Qwen2-7B70亿约14GB勉强T4是16GBLlama3-70B700亿约140GB不能需要多卡模型参数占显存。参数越多需要的显存越大。一张卡装不下就得多卡多卡就贵。瓶颈二生成是串行的大模型生成文字是一个Token一个Token往外蹦的不能并行生成。用户问K8s的Pod有哪些状态 模型内部 第1步生成 Pod 第2步生成 的 第3步生成 状态 第4步生成 有 ... 第50步生成最后一个Token 每步都要把整个模型跑一遍50个Token 跑50次模型。每次跑一遍需要读取所有参数。模型越大每次读取越慢。瓶颈三重复计算浪费生成第50个Token时模型需要回顾前面49个Token的信息。如果不做优化每次都要重新算一遍前面所有Token的注意力大量重复计算。四大加速技术技术解决什么问题类比量化模型太大装不下搬家时把大箱子换成小箱子KV Cache重复计算浪费做过的笔记不用重写直接翻Flash Attention注意力计算慢优化读写顺序减少来回搬运Continuous Batching多用户排队慢银行从叫号变成多窗口并行技术一量化 - 用更小的数字表示参数原理模型参数本来是高精度浮点数FP16每个数占2字节。量化就是把它们转成低精度的整数INT8占1字节INT4占0.5字节。生活类比原来你记账精确到分127.53元。量化后你记到元128元。虽然不那么精确了但记得更快计算量小账本更小占空间少对日常使用影响不大谁在乎那几毛钱量化级别对比量化级别每参数大小7B模型显存速度提升精度损失FP16不量化2字节14GB基准无INT81字节7GB约1.5-2x几乎无INT40.5字节3.5GB约2-3x轻微INT30.375字节2.6GB约3-4x明显量化方法方法原理特点GPTQ逐层量化用少量数据校准离线量化速度快社区模型多AWQ保护重要参数不量化精度损失更小GGUFllama.cpp生态CPU也能跑适合本地部署bitsandbytes动态量化加载时转换最简单一行代码搞定实际效果以Qwen2-7B为例测试环境T4 16GB GPU FP16 - 显存占用14.2GB - 速度12 tokens/s - 能装下但几乎满了 INT8GPTQ - 显存占用7.1GB - 速度20 tokens/s - 还剩一半显存 INT4GPTQ - 显存占用3.8GB - 速度28 tokens/s - 显存很富裕什么时候用量化场景建议GPU显存够追求最佳效果不量化FP16显存刚好不够装下模型INT8精度几乎无损想在小GPU上跑大模型INT4精度轻微损失本地笔记本跑模型GGUF INT4CPU也行批量推理追求吞吐量INT8速度和精度兼顾量化的代价量化不是免费的午餐代价说明精度下降INT4对复杂推理、数学题影响较大量化本身需要时间GPTQ量化一个7B模型约10-30分钟不是所有模型都适合小模型3B量化后掉点明显需要对应推理框架支持vLLM支持GPTQ/AWQ不是所有格式都支持技术二KV Cache - 记笔记避免重复计算原理模型生成每个Token时都要看前面所有Token。Transformer的注意力机制需要对每个历史Token算出Key和Value两个向量。没有KV Cache时生成第1个Token计算第0个Token的KV 生成第2个Token重新计算第0、1个Token的KV 生成第3个Token重新计算第0、1、2个Token的KV ... 生成第50个Token重新计算第0到49个Token的KV50次重复有KV Cache时生成第1个Token计算第0个的KV → 存起来 生成第2个Token读缓存拿到第0的KV 只新算第1个的KV → 存起来 生成第3个Token读缓存拿到第0、1的KV 只新算第2个的KV ... 生成第50个Token读缓存拿到0-48的KV 只新算第49个 → 快很多生活类比写一篇长文章。没有KV Cache就像每写一段新话之前都要从头到尾重读一遍前面写的所有内容。有KV Cache就像你在旁边贴了便签纸记着前面讲了啥写新段落时瞄一眼便签就行不用重读全文。KV Cache的代价占显存模型序列长度KV Cache显存7B模型2048 tokens约2GB7B模型8192 tokens约8GB7B模型32K tokens约32GB序列越长缓存越大。这就是为什么长上下文模型需要更多显存。PagedAttentionvLLM的杀手锏传统KV Cache有个问题为每个请求预分配最大长度的显存。如果最大支持8192 tokens就算用户只问了10个字也分配8192的缓存空间。浪费vLLM的PagedAttention解决了这个问题像操作系统管理内存的分页机制一样把KV Cache切成小块页按需分配。用多少分多少不浪费。传统方式 请求A预分配8192 tokens的显存 → 实际只用了200 → 浪费7992 请求B显存不够了 → 排队等 PagedAttention 请求A先分配1页256 tokens用完再加1页 → 实际用了200只占1页 请求B显存充裕 → 同时处理效果同样的GPU能同时服务的请求数提升2-4倍。技术三Flash Attention - 优化读写顺序原理注意力计算涉及大量矩阵运算。瓶颈不在算GPU计算很快而在搬数据在GPU的高速缓存和主显存之间来回搬。生活类比你在厨房做菜。冰箱主显存很大但离灶台计算单元远台面高速缓存很小但在手边。普通方式每用一个食材就跑一趟冰箱。来回跑浪费大量时间。Flash Attention先规划好菜谱一次性把需要的食材都拿到台面上集中处理。减少来回跑冰箱的次数。效果指标标准AttentionFlash Attention速度基准快2-4倍显存O(N^2)O(N)省很多精度标准完全一致无损Flash Attention是免费午餐不损失精度纯粹通过优化内存读写顺序来加速。使用方式# vLLM默认开启Flash Attention不需要手动配置# 如果用Hugging Face TransformersmodelAutoModelForCausalLM.from_pretrained(Qwen/Qwen2-7B,attn_implementationflash_attention_2# 一行搞定)技术四Continuous Batching - 动态批处理原理传统批处理Static Batching收集一批请求等最长的那个生成完了整批才算结束。短请求已经生成完了也得等长请求。类比旅行团坐大巴到景点后所有人必须集合了才能走。快的人等慢的人。Continuous Batching谁先生成完谁先走空出来的位置立刻让排队的新请求进来。类比改成出租车模式。到目的地的人直接下车新乘客立刻上车。车不空跑。效果场景10个用户同时提问回答长度不同有的20字有的200字 Static Batching - 所有人等最长的那个200字生成完 - 短的用户明明1秒就能拿到结果却等了10秒 - GPU利用率先高后低短请求完了GPU空转等长请求 Continuous Batching - 短请求1秒就返回不等别人 - 空出来的GPU资源立刻给排队的新请求 - GPU利用率始终保持高位指标Static BatchingContinuous Batching用户体验短请求被拖慢每个请求尽快返回GPU利用率波动大持续高位吞吐量中高提升2-3倍vLLM为什么快四合一vLLM之所以成为最流行的推理框架是因为它把上面四种优化都集成了技术vLLM中的实现量化支持GPTQ、AWQ格式自动识别KV CachePagedAttention独创Flash Attention默认开启Continuous Batching默认开启# 一行命令启动所有优化自动生效vllm serve Qwen/Qwen2-7B-Instruct-GPTQ-Int4 \--max-model-len4096\--gpu-memory-utilization0.9不需要你手动配置每项优化。vLLM帮你做完了。实际性能对比同一张T4 GPU同一个Qwen2-7B模型 原始HuggingFace推理 - 单请求12 tokens/s - 并发102 tokens/s/请求排队 - 显存14.2GB vLLMINT4 PagedAttention Flash Attention Continuous Batching - 单请求28 tokens/s - 并发1010 tokens/s/请求批处理 - 显存4.5GB 提升 - 单请求速度2.3倍 - 并发吞吐5倍 - 显存节省68%其他加速手段了解即可技术原理适用场景TensorRT-LLMNVIDIA专用编译优化NVIDIA GPU上追求极致性能Speculative Decoding小模型猜、大模型验证长文本生成场景Prefix Caching相同前缀的请求共享KV Cache系统提示词相同的批量请求Tensor Parallelism模型切分到多张GPU单卡装不下的大模型动态量化推理时实时量化不想提前转换模型格式选择加速方案的决策树你的模型能装进一张GPU吗 ├── 能 → 直接用vLLM默认优化全开 │ └── 想再快→ 用INT8量化版 └── 不能 → 两条路 ├── 用INT4量化缩小到一张卡装得下→ 用vLLM └── 用多卡Tensor Parallelism→ 用vLLM --tensor-parallel-size 2运维视角怎么选模型大小和量化级别上面讲的是技术原理但作为运维你实际面对的问题是业务要上一个AI功能给你一张卡你怎么选模型第一步从需求反推问题影响什么模型要干什么简单问答还是复杂推理决定模型大小要扛多少并发决定要留多少显存给KV Cache有几张什么卡决定显存上限延迟要求用户能等几秒决定是否需要量化加速第二步选模型大小任务复杂度推荐参数量典型场景简单分类、提取关键词1.5B-3B工单分类、意图识别中等问答、总结、翻译7B客服助手、内部知识库复杂代码生成、多步推理14B-72B编程助手、复杂Agent原则能用小模型搞定的就不用大模型。大模型不一定更好但一定更贵更慢。第三步选量化级别GPU显存够装FP16吗 ├── 够且并发低5 → FP16效果最好 ├── 够但并发高10→ INT8省显存给KV Cache和并发 └── 不够 → 两条路 ├── INT4量化后能装下 → INT4 └── INT4也装不下 → 换更小的模型或加卡实际选型表单张T4 16GB模型FP16INT8INT4推荐方案Qwen2-1.5B3GB富裕没必要没必要直接FP16Qwen2-7B14GB满了7GB有余量3.5GB很宽裕INT8或INT4Qwen2-14B28GB装不下14GB刚好7GB宽裕INT4推荐Qwen2-72B144GB不可能72GB不可能36GB不行单卡T4放弃显存估算公式模型显存 ≈ 参数量(B) × 每参数字节数 FP167B × 2字节 14GB INT87B × 1字节 7GB INT47B × 0.5字节 3.5GB 实际还要加KV Cache和框架开销约多20-30% 7B INT4实际占用 ≈ 3.5 × 1.3 ≈ 4.5GB简单记GPU显存的70%给模型30%留给运行时KV Cache 并发。第四步量化后验证效果量化不能盲目上线要测试1. 准备20-50条业务场景的测试问题 2. 分别跑FP16版和量化版 3. 对比 - 答案正确率是否下降 - 格式是否正常JSON输出会不会乱 - 复杂推理是否明显变差 4. INT4效果不行 → 退到INT8 5. INT8也不行 → 不量化换大卡运维选型checklist检查项说明模型显存 GPU 70%留30%给KV Cache和并发量化后跑测试集对比不能盲目量化就上线压测吞吐量vLLM自带benchmark工具P99延迟达标最慢请求也在可接受范围算总成本大模型多卡 vs 小模型单卡哪个划算面试怎么说如果被问你了解模型加速吗了解。大模型推理的瓶颈主要是模型太大显存不够和生成是串行的Token一个一个出。常用的加速技术有四种量化把FP16参数压成INT8或INT4显存减半或减到1/4速度翻倍KV Cache缓存历史Token的计算结果避免重复计算Flash Attention优化显存读写顺序速度提升2-4倍且无精度损失Continuous Batching动态批处理短请求先返回GPU不空转实际部署中我用vLLM它把这四种优化都集成了。在T4上跑Qwen2-7B的INT4量化版单请求28 tokens/s并发10时总吞吐量能到100 tokens/s。选型方面我的经验是先看任务复杂度选模型大小再看显存选量化级别。70%显存给模型30%留给运行时。量化后必须跑测试集验证效果再上线。延伸思考问题答案量化后模型变笨了怎么办INT8几乎无损。如果必须用INT4且效果不行换更大的模型量化到INT4可能比小模型FP16好KV Cache占满显存了怎么办限制最大序列长度或用PagedAttentionvLLM自动处理Flash Attention要自己装吗vLLM自带。用Transformers需要单独安装flash-attn包vLLM和TensorRT-LLM哪个好vLLM更易用一行命令TensorRT-LLM更极致但配置复杂加速是运维干的事还是算法干的事都有关。量化方案可能算法定部署配置和资源分配是运维的活小结本篇核心收获推理瓶颈不是GPU算不快是模型太大显存 生成串行带宽 重复计算浪费量化用低精度INT8/INT4表示参数显存减半以上速度翻倍精度轻微损失KV Cache缓存历史计算结果避免重复计算。vLLM的PagedAttention按需分配不浪费Flash Attention优化显存读写顺序快2-4倍且无损。是免费午餐Continuous Batching动态批处理短请求先走GPU利用率持续高位实战选择直接用vLLM四种优化全部内置一行命令搞定下一篇预告AI全栈知识14GPU资源弹缩实战 - 从HPA到Cluster Autoscaler下一篇进入资源管理领域基于推理队列长度的HPA配置GPU节点自动扩缩容竞价实例混合策略弹缩延迟和冷启动优化参考链接vLLM官方文档PagedAttention论文Flash Attention论文GPTQ量化AWQ量化 
长河君 · 2026/8/21 21:17:15 · 阅读 1.2k AI全栈知识13：模型加速 - 量化、KV Cache与推理优化
AI全栈知识13模型加速 - 量化、KV Cache与推理优化写在前面你部署了一个大模型用户问一个问题模型想了5秒才回答。用户又问了一个又等5秒。5秒看起来不长但如果100个人同时问呢排队等到天荒地老。模型加速要解决的就是这个问题同一个模型、同样的回答质量怎么让它更快、更省资源这不是换一个更大的GPU就能解决的那是加钱不是加速。真正的加速是用更聪明的方法让模型跑得更快。为什么大模型推理慢先搞清楚慢在哪里。大模型推理的瓶颈不是计算GPU算得飞快而是瓶颈一模型太大显存装不下模型参数量FP16显存需求一张T4能装下吗Qwen2-1.5B15亿约3GB能Qwen2-7B70亿约14GB勉强T4是16GBLlama3-70B700亿约140GB不能需要多卡模型参数占显存。参数越多需要的显存越大。一张卡装不下就得多卡多卡就贵。瓶颈二生成是串行的大模型生成文字是一个Token一个Token往外蹦的不能并行生成。用户问K8s的Pod有哪些状态 模型内部 第1步生成 Pod 第2步生成 的 第3步生成 状态 第4步生成 有 ... 第50步生成最后一个Token 每步都要把整个模型跑一遍50个Token 跑50次模型。每次跑一遍需要读取所有参数。模型越大每次读取越慢。瓶颈三重复计算浪费生成第50个Token时模型需要回顾前面49个Token的信息。如果不做优化每次都要重新算一遍前面所有Token的注意力大量重复计算。四大加速技术技术解决什么问题类比量化模型太大装不下搬家时把大箱子换成小箱子KV Cache重复计算浪费做过的笔记不用重写直接翻Flash Attention注意力计算慢优化读写顺序减少来回搬运Continuous Batching多用户排队慢银行从叫号变成多窗口并行技术一量化 - 用更小的数字表示参数原理模型参数本来是高精度浮点数FP16每个数占2字节。量化就是把它们转成低精度的整数INT8占1字节INT4占0.5字节。生活类比原来你记账精确到分127.53元。量化后你记到元128元。虽然不那么精确了但记得更快计算量小账本更小占空间少对日常使用影响不大谁在乎那几毛钱量化级别对比量化级别每参数大小7B模型显存速度提升精度损失FP16不量化2字节14GB基准无INT81字节7GB约1.5-2x几乎无INT40.5字节3.5GB约2-3x轻微INT30.375字节2.6GB约3-4x明显量化方法方法原理特点GPTQ逐层量化用少量数据校准离线量化速度快社区模型多AWQ保护重要参数不量化精度损失更小GGUFllama.cpp生态CPU也能跑适合本地部署bitsandbytes动态量化加载时转换最简单一行代码搞定实际效果以Qwen2-7B为例测试环境T4 16GB GPU FP16 - 显存占用14.2GB - 速度12 tokens/s - 能装下但几乎满了 INT8GPTQ - 显存占用7.1GB - 速度20 tokens/s - 还剩一半显存 INT4GPTQ - 显存占用3.8GB - 速度28 tokens/s - 显存很富裕什么时候用量化场景建议GPU显存够追求最佳效果不量化FP16显存刚好不够装下模型INT8精度几乎无损想在小GPU上跑大模型INT4精度轻微损失本地笔记本跑模型GGUF INT4CPU也行批量推理追求吞吐量INT8速度和精度兼顾量化的代价量化不是免费的午餐代价说明精度下降INT4对复杂推理、数学题影响较大量化本身需要时间GPTQ量化一个7B模型约10-30分钟不是所有模型都适合小模型3B量化后掉点明显需要对应推理框架支持vLLM支持GPTQ/AWQ不是所有格式都支持技术二KV Cache - 记笔记避免重复计算原理模型生成每个Token时都要看前面所有Token。Transformer的注意力机制需要对每个历史Token算出Key和Value两个向量。没有KV Cache时生成第1个Token计算第0个Token的KV 生成第2个Token重新计算第0、1个Token的KV 生成第3个Token重新计算第0、1、2个Token的KV ... 生成第50个Token重新计算第0到49个Token的KV50次重复有KV Cache时生成第1个Token计算第0个的KV → 存起来 生成第2个Token读缓存拿到第0的KV 只新算第1个的KV → 存起来 生成第3个Token读缓存拿到第0、1的KV 只新算第2个的KV ... 生成第50个Token读缓存拿到0-48的KV 只新算第49个 → 快很多生活类比写一篇长文章。没有KV Cache就像每写一段新话之前都要从头到尾重读一遍前面写的所有内容。有KV Cache就像你在旁边贴了便签纸记着前面讲了啥写新段落时瞄一眼便签就行不用重读全文。KV Cache的代价占显存模型序列长度KV Cache显存7B模型2048 tokens约2GB7B模型8192 tokens约8GB7B模型32K tokens约32GB序列越长缓存越大。这就是为什么长上下文模型需要更多显存。PagedAttentionvLLM的杀手锏传统KV Cache有个问题为每个请求预分配最大长度的显存。如果最大支持8192 tokens就算用户只问了10个字也分配8192的缓存空间。浪费vLLM的PagedAttention解决了这个问题像操作系统管理内存的分页机制一样把KV Cache切成小块页按需分配。用多少分多少不浪费。传统方式 请求A预分配8192 tokens的显存 → 实际只用了200 → 浪费7992 请求B显存不够了 → 排队等 PagedAttention 请求A先分配1页256 tokens用完再加1页 → 实际用了200只占1页 请求B显存充裕 → 同时处理效果同样的GPU能同时服务的请求数提升2-4倍。技术三Flash Attention - 优化读写顺序原理注意力计算涉及大量矩阵运算。瓶颈不在算GPU计算很快而在搬数据在GPU的高速缓存和主显存之间来回搬。生活类比你在厨房做菜。冰箱主显存很大但离灶台计算单元远台面高速缓存很小但在手边。普通方式每用一个食材就跑一趟冰箱。来回跑浪费大量时间。Flash Attention先规划好菜谱一次性把需要的食材都拿到台面上集中处理。减少来回跑冰箱的次数。效果指标标准AttentionFlash Attention速度基准快2-4倍显存O(N^2)O(N)省很多精度标准完全一致无损Flash Attention是免费午餐不损失精度纯粹通过优化内存读写顺序来加速。使用方式# vLLM默认开启Flash Attention不需要手动配置# 如果用Hugging Face TransformersmodelAutoModelForCausalLM.from_pretrained(Qwen/Qwen2-7B,attn_implementationflash_attention_2# 一行搞定)技术四Continuous Batching - 动态批处理原理传统批处理Static Batching收集一批请求等最长的那个生成完了整批才算结束。短请求已经生成完了也得等长请求。类比旅行团坐大巴到景点后所有人必须集合了才能走。快的人等慢的人。Continuous Batching谁先生成完谁先走空出来的位置立刻让排队的新请求进来。类比改成出租车模式。到目的地的人直接下车新乘客立刻上车。车不空跑。效果场景10个用户同时提问回答长度不同有的20字有的200字 Static Batching - 所有人等最长的那个200字生成完 - 短的用户明明1秒就能拿到结果却等了10秒 - GPU利用率先高后低短请求完了GPU空转等长请求 Continuous Batching - 短请求1秒就返回不等别人 - 空出来的GPU资源立刻给排队的新请求 - GPU利用率始终保持高位指标Static BatchingContinuous Batching用户体验短请求被拖慢每个请求尽快返回GPU利用率波动大持续高位吞吐量中高提升2-3倍vLLM为什么快四合一vLLM之所以成为最流行的推理框架是因为它把上面四种优化都集成了技术vLLM中的实现量化支持GPTQ、AWQ格式自动识别KV CachePagedAttention独创Flash Attention默认开启Continuous Batching默认开启# 一行命令启动所有优化自动生效vllm serve Qwen/Qwen2-7B-Instruct-GPTQ-Int4 \--max-model-len4096\--gpu-memory-utilization0.9不需要你手动配置每项优化。vLLM帮你做完了。实际性能对比同一张T4 GPU同一个Qwen2-7B模型 原始HuggingFace推理 - 单请求12 tokens/s - 并发102 tokens/s/请求排队 - 显存14.2GB vLLMINT4 PagedAttention Flash Attention Continuous Batching - 单请求28 tokens/s - 并发1010 tokens/s/请求批处理 - 显存4.5GB 提升 - 单请求速度2.3倍 - 并发吞吐5倍 - 显存节省68%其他加速手段了解即可技术原理适用场景TensorRT-LLMNVIDIA专用编译优化NVIDIA GPU上追求极致性能Speculative Decoding小模型猜、大模型验证长文本生成场景Prefix Caching相同前缀的请求共享KV Cache系统提示词相同的批量请求Tensor Parallelism模型切分到多张GPU单卡装不下的大模型动态量化推理时实时量化不想提前转换模型格式选择加速方案的决策树你的模型能装进一张GPU吗 ├── 能 → 直接用vLLM默认优化全开 │ └── 想再快→ 用INT8量化版 └── 不能 → 两条路 ├── 用INT4量化缩小到一张卡装得下→ 用vLLM └── 用多卡Tensor Parallelism→ 用vLLM --tensor-parallel-size 2运维视角怎么选模型大小和量化级别上面讲的是技术原理但作为运维你实际面对的问题是业务要上一个AI功能给你一张卡你怎么选模型第一步从需求反推问题影响什么模型要干什么简单问答还是复杂推理决定模型大小要扛多少并发决定要留多少显存给KV Cache有几张什么卡决定显存上限延迟要求用户能等几秒决定是否需要量化加速第二步选模型大小任务复杂度推荐参数量典型场景简单分类、提取关键词1.5B-3B工单分类、意图识别中等问答、总结、翻译7B客服助手、内部知识库复杂代码生成、多步推理14B-72B编程助手、复杂Agent原则能用小模型搞定的就不用大模型。大模型不一定更好但一定更贵更慢。第三步选量化级别GPU显存够装FP16吗 ├── 够且并发低5 → FP16效果最好 ├── 够但并发高10→ INT8省显存给KV Cache和并发 └── 不够 → 两条路 ├── INT4量化后能装下 → INT4 └── INT4也装不下 → 换更小的模型或加卡实际选型表单张T4 16GB模型FP16INT8INT4推荐方案Qwen2-1.5B3GB富裕没必要没必要直接FP16Qwen2-7B14GB满了7GB有余量3.5GB很宽裕INT8或INT4Qwen2-14B28GB装不下14GB刚好7GB宽裕INT4推荐Qwen2-72B144GB不可能72GB不可能36GB不行单卡T4放弃显存估算公式模型显存 ≈ 参数量(B) × 每参数字节数 FP167B × 2字节 14GB INT87B × 1字节 7GB INT47B × 0.5字节 3.5GB 实际还要加KV Cache和框架开销约多20-30% 7B INT4实际占用 ≈ 3.5 × 1.3 ≈ 4.5GB简单记GPU显存的70%给模型30%留给运行时KV Cache 并发。第四步量化后验证效果量化不能盲目上线要测试1. 准备20-50条业务场景的测试问题 2. 分别跑FP16版和量化版 3. 对比 - 答案正确率是否下降 - 格式是否正常JSON输出会不会乱 - 复杂推理是否明显变差 4. INT4效果不行 → 退到INT8 5. INT8也不行 → 不量化换大卡运维选型checklist检查项说明模型显存 GPU 70%留30%给KV Cache和并发量化后跑测试集对比不能盲目量化就上线压测吞吐量vLLM自带benchmark工具P99延迟达标最慢请求也在可接受范围算总成本大模型多卡 vs 小模型单卡哪个划算面试怎么说如果被问你了解模型加速吗了解。大模型推理的瓶颈主要是模型太大显存不够和生成是串行的Token一个一个出。常用的加速技术有四种量化把FP16参数压成INT8或INT4显存减半或减到1/4速度翻倍KV Cache缓存历史Token的计算结果避免重复计算Flash Attention优化显存读写顺序速度提升2-4倍且无精度损失Continuous Batching动态批处理短请求先返回GPU不空转实际部署中我用vLLM它把这四种优化都集成了。在T4上跑Qwen2-7B的INT4量化版单请求28 tokens/s并发10时总吞吐量能到100 tokens/s。选型方面我的经验是先看任务复杂度选模型大小再看显存选量化级别。70%显存给模型30%留给运行时。量化后必须跑测试集验证效果再上线。延伸思考问题答案量化后模型变笨了怎么办INT8几乎无损。如果必须用INT4且效果不行换更大的模型量化到INT4可能比小模型FP16好KV Cache占满显存了怎么办限制最大序列长度或用PagedAttentionvLLM自动处理Flash Attention要自己装吗vLLM自带。用Transformers需要单独安装flash-attn包vLLM和TensorRT-LLM哪个好vLLM更易用一行命令TensorRT-LLM更极致但配置复杂加速是运维干的事还是算法干的事都有关。量化方案可能算法定部署配置和资源分配是运维的活小结本篇核心收获推理瓶颈不是GPU算不快是模型太大显存 生成串行带宽 重复计算浪费量化用低精度INT8/INT4表示参数显存减半以上速度翻倍精度轻微损失KV Cache缓存历史计算结果避免重复计算。vLLM的PagedAttention按需分配不浪费Flash Attention优化显存读写顺序快2-4倍且无损。是免费午餐Continuous Batching动态批处理短请求先走GPU利用率持续高位实战选择直接用vLLM四种优化全部内置一行命令搞定下一篇预告AI全栈知识14GPU资源弹缩实战 - 从HPA到Cluster Autoscaler下一篇进入资源管理领域基于推理队列长度的HPA配置GPU节点自动扩缩容竞价实例混合策略弹缩延迟和冷启动优化参考链接vLLM官方文档PagedAttention论文Flash Attention论文GPTQ量化AWQ量化