2024年聊AI应用架构绕不开一个尴尬现状模型参数越堆越大到手能用的算力却还是那几张卡。我见过不少团队在训练阶段跑得风生水起一到生产环境就被显存和延迟卡死。模型压缩和性能优化听起来是两个方向实际是一条链路的两端——压缩负责把模型塞进显存优化负责让塞进去的模型跑出吞吐。这篇文章我就把这两个东西揉在一起讲从原理到实操从量化到推理引擎配置直接给你一套能落地的组合拳。如果你是做AI应用架构、模型部署或者推理服务优化的工程师看完应该能直接对齐思路。哪怕你是刚接触部署的新人也能搞清楚该从哪里下手。1. 先盘一盘全局压缩和优化到底在解决什么问题1.1 为什么2024年模型压缩和性能优化被绑在了一起2024年的应用架构师面对的不再是单纯的CNN分类模型而是动辄几十亿、上百亿参数的大语言模型。这类模型给部署带来的问题非常具体权重文件动辄十几GB甚至几十GB一张加速卡根本放不下推理时的KV Cache又会随并发和上下文长度暴涨生成式任务对首字延迟和吞吐又有极高要求。单独做模型压缩解决的是装不装得下的问题单独做性能优化解决的是跑得够不够快的问题。但2024年这两件事已经没法分开讨论了。原因是减速器硬件生态里低精度计算单元和稀疏计算单元正在成为标配压缩方案必须主动适配硬件特性才有效反过来推理引擎的调度策略又会直接影响压缩后的模型能不能把硬件吃满。换句话说压缩决定性能上限优化决定能不能摸到那个上限。1.2 一条完整部署链路里的三个层次我习惯把部署链路分成三个层次来看这样遇到问题很容易定位。第一层是权重层也就是模型文件本身的大小和精度。这一层的手段包括量化、剪枝、蒸馏目标是减少参数量或者降低每个参数的表示精度。第二层是计算图层对应模型的结构和算子组织方式。这里的手段是算子融合、计算图重写、注意力机制优化目标是减少计算量和访存量。第三层是运行时层涉及推理引擎的调度、显存管理、并发策略。这一层重点是KV Cache管理、连续批处理、动态形状适配目标是提高硬件利用率和并发吞吐。三层之间会互相影响。举个例子你把权重从FP16量化到INT4显存确实省了但如果推理引擎不支持INT4算子运行时就得频繁做反量化性能反而更差。所以架构师思考问题时必须三层一起看这恰恰是AI应用架构师和单纯调模型精度的算法工程师之间的核心区别。2. 量化当前投入产出比最高的压缩手段2.1 量化原理从FP16到INT8/INT4是怎么换算的量化本质上是把连续的浮点数映射到离散的整数。最常见的对称量化公式很简单量化$q round(r / s)$反量化$r q \times s$缩放因子$s max(|r|) / 127$以INT8为例举个实际例子某层权重数值范围是 $[-1.2, 1.2]$那么 $s 1.2 / 127 ≈ 0.00945$。原始值 $1.0$ 对应的INT8整型值就是 $round(1.0 / 0.00945) ≈ 106$。反量化回来就是 $106 \times 0.00945 ≈ 1.0017$误差约千分之二。为什么大模型量化能在精度损失很小的情况下把体积压缩数倍因为权重矩阵里有很多冗余信息神经网络的容错性远比想象中强把连续分布离散化后只要保留整体统计特征输出质量不会明显下降。但这里有个经典坑某些层的个别权重数值特别大也就是所谓的异常值这些异常值会把缩放因子s撑得很大导致大多数正常权重在量化后精度严重损失。这类问题在处理大模型时尤其突出所以后续的AWQ等方案专门针对这个问题做优化把少量敏感通道保留高精度或者用激活值分布来指导权重缩放效果比朴素量化好很多。2.2 PTQ和QAT怎么选量化落地主要分两条路线训练后量化PTQ和量化感知训练QAT。PTQ流程是加载训练好的模型用一小部分校准数据跑一遍前向统计各层激活值和权重的数值范围然后计算缩放因子并完成量化。整个过程不需要重新训练可能几十分钟就搞定。针对大语言模型权重量化还有基于二阶Hessian信息的逐层补偿算法GPTQ一类的方法在校准数据上逐步修正量化误差精度明显好于简单的RTN逐张量量化。QAT则是在训练或者微调阶段就插入伪量化节点让模型在训练过程中适应低精度的数值表示。训练完后直接导出低精度模型精度通常比PTQ更稳但需要训练资源和时间成本。我的建议很简单能PTQ就不上QAT对于7B以上的大模型先试PTQ如果精度回退明显再考虑混合方案。QAT一般用在小模型或者对精度极其敏感的场景比如医疗、金融这类容错率很低的任务。记住一点QAT不是万能药它需要完整训练流程的配合很多项目根本没有微调数据硬做QAT反而会把基线搞乱。2.3 2024年值得落地的量化方案参考我把当前主流的几种量化方案整理成一个对比表方便你在方案选型时直接对标。方案类型精度显存节省相对FP16适用场景备注FP16原始精度0%精度敏感显存充裕所有硬件友好FP8较高50%新一代加速卡需要硬件支持训练推理均可INT8高50%大部分生产场景生态成熟算子支持广INT4GPTQ类中约75%单卡部署大模型需要校准数据精度损失需评估INT4AWQ类中高约75%单卡部署大模型无需反向传播速度更快同时保护敏感通道2024年的新趋势是所有方案都在往感知激活值的方向走AWQ就是一个典型例子——它本质上是用激活值的统计信息来挑选哪些通道对量化更敏感然后做一个不等价缩放在不依赖反向传播的情况下就能有效保护精度。3. 剪枝与蒸馏从结构上把模型变小3.1 剪枝的三种粒度与硬件支持的配合量化减的是每个数的体积剪枝减的是数的数量。剪枝按粒度可以分成三种非结构化剪枝、结构化剪枝、半结构化剪枝。非结构化剪枝就是把权重矩阵中绝对值接近零的元素直接删掉使矩阵变得稀疏。理论上压缩比很高但实际推理时随机稀疏矩阵很难利用硬件加速很多场景下非但不提速还可能因为稀疏索引的额外开销变慢。结构化剪枝是按行、列或者整个通道去删除可以直接减少矩阵乘法的计算维度对硬件友好很多。半结构化剪枝是折中方案最有名的是2:4稀疏模式即每四个元素中保留两个非零值某些主流加速卡对这种模式有专门的硬件支持理论上有接近两倍的加速潜力。我在实际项目里的体感是Transformer结构的大模型结构化剪枝对精度拖累比较明显而且调起来费劲。除非你非常确定某个模块是冗余的否则在LLM时代优先把量化做了剪枝更多用在CNN时代的模型上。3.2 知识蒸馏大模型带小模型知识蒸馏在2024年的玩法跟以前很不一样。以前是拿一个大教师模型的软标签去训练一个小学生模型让它学输出分布。现在则是直接用大模型生成高质量数据来微调一个小模型或者把大模型在特定任务上的推理路径蒸馏到专用小模型里。蒸馏的优势在于它不受硬件精度限制可以把7B模型的知识压到3B甚至1B模型里而且推理时就是普通FP16精度不需要任何特殊算子支持。缺点是训练成本高而且小模型的capacity毕竟有限蒸馏出来的模型在下游任务上能保留多少能力需要仔细验证。蒸馏和量化其实可以叠加使用。先蒸馏出一个体积适中的小模型再对这个模型做低比特量化两轮压缩叠加以后同一个业务场景的推理成本下降非常可观。我一个项目里就是这么干的先蒸馏再INT8量化最终QPS比最初直接用原模型提升了接近4倍。4. 推理性能优化让压缩后的模型真正跑起来4.1 算子融合与计算图重写模型压缩完成之后下一步要解决的是算力利用问题。Transformer模型的计算图里有很多细碎的算子比如LayerNorm、残差连接、激活函数、矩阵乘法。如果不做任何优化每一个算子都会被单独调度到硬件上执行每次调度都有kernel启动开销和显存读写开销。以自注意力里的QKV投影为例原始计算图是三个独立的矩阵乘分别算Q、K、V。融合优化后把三个权重矩阵拼接成一个大矩阵一次矩阵乘同时算出QKV再用split算子切开。这样kernel启动次数从三次变成一次显存访问也减少了一半多。同样GELU激活和残差Add可以融合进前面的矩阵乘算子或者下一个算子LayerNorm则可以与之前的算子合并。市面上大多数推理引擎和编译器都提供了自动或半自动的算子融合能力。实际做项目时我很少手工去融合算子一般直接交给推理框架。但架构师必须能看懂框架的图优化日志知道它到底做了什么、没做什么否则性能出现问题都无从排查。4.2 KV Cache与自注意力的显存博弈KV Cache是自回归生成推理里减速器显存占用的一个大头。想象一下每生成一个token我们需要把之前所有token的K和V都拿去算注意力。如果每次都重新算一遍历史token的K和V计算量是无意义的翻了倍所以推理引擎会把历史token的K、V矩阵缓存在显存里这就是KV Cache。KV Cache有多大来个具体计算假设一个7B规模模型有32层每层有32个注意力头每个头维度128用FP16存。单个token在所有层占用的KV缓存就是 32层×2K和V×32头×128维×2字节 524,288字节约0.5MB。看起来不多但支持4096上下文、并发32路请求时这个数字变成 0.5MB × 4096 × 32 ≈ 64GB轻松吃掉一整张加速卡。所以KV Cache的管理策略直接决定并发上限。2024年主流的做法是借鉴操作系统的分页思想把KV缓存按固定大小的块来管理不要求连续内存有效减少显存碎片同时还能让多个请求共享已经计算好的前缀。这种机制就是PagedAttention的核心思路也是当前各类高性能推理引擎的标配。如果你在做长上下文场景完全绕不开这个概念。4.3 连续批处理吞吐量倍增的关键传统批处理是等一个batch里的所有请求都生成完了再放下一个batch进来。但在自回归生成里不同请求的长度天然不一样快的请求可能要等慢的请求完成GPU在这段时间里大量空转。连续批处理Continuous Batching把调度粒度从整个batch降到了每生成一个token。每一轮迭代结束后只要某个请求生成了结束符就立刻把空闲位置让给新请求。理论上这一步优化能把GPU利用率拉满吞吐量提升两到三倍并不夸张。我建议所有做生成式应用部署的团队框架选型时把是否支持连续批处理作为硬性指标。不支持这个机制的引擎在大并发场景下先天吃亏用再好的压缩方案也很难把吞吐做上去。5. 一个7B模型部署的实操复盘5.1 项目目标与资源约束我拿去年做过的一个模拟项目X来复盘场景是做一个内部知识库问答系统基础模型是7B规模的开源大模型。生产环境约束很明确单张加速卡显存24GB要求支持不低于32路并发首token延迟小于1.5秒模型回答质量不能明显低于FP16基线。资源算一下FP16权重约14GB看起来24GB放得下但加上KV Cache、激活值、推理框架自身的运行时开销32路并发一压上来显存分分钟爆掉。这个场景不是能不能跑而是能不能在指定并发和延迟下稳定跑。5.2 第一轮量化并守住精度底线我的第一轮动作是先做INT8静态量化。校准数据选了内部知识库的真实问题集覆盖不同风格和长度约2000条。权重按per-channel量化激活值按per-tensor量化。量化前后跑了一组评测集得分从91.4掉到90.7降幅不到1个百分点完全能接受。接着我尝试了INT4权重量化用AWQ方案保留约10%的敏感通道不加量化处理。模型显存占用从14GB直接降到4GB左右但评测得分掉到86.9。这个结果业务方不满意所以最终选择INT8权重加FP16激活的混合方案。这里有个经验可以分享权重精度对模型输出的影响远大于激活精度所以激活值保持FP16牺牲不大但换来的是更高的精度保留度。5.3 第二轮推理引擎配置与性能调优量化完成后用推理引擎加载INT8模型。这轮优化的重点是注意力计算和调度策略。我开了算子融合和分页KV Cache同时把连续批处理打开warmup 200次请求不再用默认值。实测数据变化很明显。连续批处理开启后GPU利用率长时间稳定在85%以上没开启时大概只有50%出头。KV Cache用分页后显存碎片少了同样显存下能容纳的并发数量从不到40路提升到接近64路。这轮基本达成目标但首token延迟还有优化空间原因是输入侧有大量padding。5.4 第三轮服务化参数与稳定性验证最后一轮处理的是实际对外服务时的参数调优。我把输入端的最大序列长度收窄到训练时常用的范围同时设置合理的max_tokens上限避免个别请求无限生成长文本占住资源。又把推理引擎的请求队列长度、超时策略、失败重试逻辑都配好。稳定性测试压了8小时模拟生产高峰流量观察显存是否有泄漏、延迟是否有抖动。最后整体指标INT8模型相比FP16基线单卡并发从24路提升到64路吞吐从原来的每秒约200 tokens提升到每秒约750 tokens。最终方案就是INT8权重量化分页KV Cache连续批处理三件套缺一不可。6. 高频问题排查与避坑经验6.1 量化后输出质量明显变差这是最常见的问题。先别急着怀疑量化本身第一步应该对比不同量化参数下的输出差异定位到底哪一层出了问题。我的排查顺序是先检查校准数据集是否和真实数据分布一致校准数据太偏会导致缩放因子计算错误然后看异常值分布尤其注意某些层出现的极端权重值最后是逐层对比量化前后的激活误差把误差大的层挑出来保持高精度其余层低精度这个混合精度方法往往能救回不少效果。6.2 模型正好变小了但速度反而更慢出现这种情况十有八九是硬件或引擎不支持低精度算子。INT8模型被加载后权重是低精度但实际计算时引擎找不到对应精度的算子只能反量化回FP16再算等于多了一轮转换开销。所以架构师选型时要看硬件支持的算子列表而不是只看纸面数据。如果推理引擎对INT8算子支持不好就换成引擎支持度更好的方案比如FP8或者保持FP16同时剪枝。6.3 显存占用仍然超标压缩完还爆显存多半问题出在KV Cache和运行时开销上。看看上下文是不是被设得太长并发是不是被限得太低。用分页KV Cache机制可以大幅减少碎片。还有一个小技巧把显存分配方式改成预分配加复用减少频繁申请释放带来的抖动。如果实在不够可以fallback到INT4权重量化但要配合做充分评测。6.4 精度-性能取舍速查表应用场景推荐方案说明追求最高精度显存充足FP16全精度无需压缩直接上推理引擎显存紧张但精度要求高INT8量化混合精度性价比最高损失可控单卡部署大模型INT4/AWQ分页KV Cache性能优先时做精度评估超长上下文人INT8连续批处理分页KV Cache优先解决KV Cache暴涨我在实际项目中踩过的另外两个坑也提一下。一个是手动指定线程数和CPU绑核这个在CPU推理场景尤其重要乱设会直接导致延迟翻倍。另一个是预热问题量化模型第一次推理时要做校准和算子选择延迟会特别高上线前一定要先预热几轮否则监控系统会被吓到报警。真要说模型压缩和性能优化怎么结合我个人体会最深的一点是所有方案都要围绕部署目标反推而不是追求单个指标的极致。INT4省显存但精度掉了FP16精度好但并发上不去最后拍板的依据永远是业务测出来的那组评测分数和线上压测的真实数据。架构师手里握着的不是某个独家模型的训练技巧而是这条链路里所有环节的取舍判断。你在项目里先做量化还是先做优化不必太纠结只要记住压缩和运行时是一体的压缩方案必须被推理引擎完全接住性能优化必须为压缩后的模型让路这套打法在任何部署项目里都能复用。