做高并发AI系统的时候最容易踩的第一个坑就是——默认把“高并发”当成纯运维问题。大家忙着加机器、上调度、扩副本折腾几天发现QPS还是上不去机器倒是吃满了。有一次我们大促前压测一个模型服务的P99直接冲上800毫秒我翻监控一看模型推理本身占了整个接口时延的八成还多。问题根本不在网关也不在负载均衡就在模型自己身上。当时我们的目标很典型既要顶住高并发流量又要把模型塞进边缘设备里还不能牺牲太多准确率。这个目标光靠堆显卡满足不了因为边缘设备跑不动大模型单次推理的时间决定了整个链路的极限。于是我们把重心从“买机器”转到了“让模型更轻”做的核心工作就是量化、剪枝再加上边缘部署架构的重构。这篇文章算是把这一整套完整实践过程、选型逻辑和踩过的坑一起写出来。适合正在做AI推理服务、边缘计算、部署优化的团队参考不管你是刚摸到门路还是已经上过线里面都有能直接落地的东西。先说结论模型压缩不是单纯“减小体积”的手段它直接影响的是并发能力、时延水位和部署成本三件事。接下来我按实践顺序讲从定位瓶颈开始再到量化剪枝的具体操作然后是边缘部署最后是压测和复盘。1. 先定位瓶颈高并发AI系统里真正的延迟包袱在哪1.1 一个典型的高并发推理链路长什么样我们当时做的是一套面向多路内容请求的智能分析服务流程大致是请求进来 → 网关鉴权 → 参数解析/预处理 → 模型推理 → 结果后处理 → 写回缓存。这个链路在高并发下最容易先出问题的不是模型而是上游的线程池和下游的连接池。但等我们把线程数调优、连接复用都做完之后瓶颈依然压得很死——因为无论上游多顺模型推理这一步是串行的它算多久这个请求就得等多久。那段时间我们做了很多次压测观察到的现象很典型并发升到某个值之后平均时延开始线性上涨再往后就变成指数上涨服务直接雪崩。表面看像是流量太大扛不住了实际上是因为模型单次推理时延太长线程资源被长时间占住新请求排队越来越久。所以第一件事不是再扩容而是把模型单次推理的时间砍下来。1.2 快速定位瓶颈的方法看三张曲线定位瓶颈不需要上太复杂的工具把三张曲线拉出来就够了。第一看GPU利用率。如果GPU利用率持续很低但接口时延还在涨说明推理没被打满瓶颈在数据预处理、传输或者服务框架本身。第二看接口时延拆解。把“CPU预处理耗时”“模型推理耗时”“网络耗时”分开埋点打点直接看哪一段占比最高。我们当时埋点之后发现模型推理占时延的80%以上方向就明确了。第三看显存和内存占用。显存如果长期逼近上限说明模型太大了并发多副本都塞不进这时候光调代码没用必须让模型本身瘦下来。在第三代硬件环境或者边缘设备上还要额外看算力利用率。边缘设备算力有限很多时候模型算力需求远超设备供给反而带宽和光靠并发调度也没用必须做端侧模型轻量化。1.3 为什么不优先选择堆机器有人会问既然模型这么大多加几台带大显存的机器不就完了吗这个思路在并发量小的时候成立但到了高并发场景问题就变成了“单次推理成本”。举个例子一个模型单次推理要200毫秒、占显存3GB一台机器最多同时跑两个副本QPS天花板就摆在那。你加十台机器成本和运维复杂度全上去了但单副本能力没变。而如果把模型体积降一半、推理时延降到80毫秒同样一台机器可能同时跑四个副本成本可能省下六成以上。对于边缘部署更是如此设备是固定的型号是固定的能跑什么模型完全由硬件上限决定不在模型层面压缩部署方案都不会成立。所以我们的路线很明确先做量化再做剪枝让模型在单次推理的算力开销和内存占用上都降下来然后再去做边缘部署的高并发编排。2. 量化落地先选位宽再定校准方案别一上来就签INT82.1 位宽选型FP16、INT8、混合精度怎么取舍量化本质上是用更少的比特去表示模型里的权重和激活值从而减少内存带宽占用、提升计算吞吐。很多人一聊量化就直接上INT8但“尽量低位宽”不一定是最高效的选择。我整理了三种常用方案的适用场景方案精度损失加速收益适用场景FP16基本无损约10%-20%大模型跑在支持半精度算力较强的设备上INT8动态量化中小模型可接受约1-2倍白天在线服务、边缘设备内存紧张INT8静态量化混合精度需要调校约2-3倍高并发服务、延迟敏感场景4bit/混合低比特精度风险高约3-5倍实验性质或配套强蒸馏重建当时我们走的是“FP16先落地INT8再优化”的两阶段方案。第一步先确认FP16能让模型在现有硬件上完整跑起来把显存占用压下去。第二步再针对推理热点算子做INT8量化同时对少数特别敏感的层保持FP16。这种做法比直接全量INT8稳妥得多尤其在没有大规模调参经验的时候能少踩很多坑。2.2 PTQ量化落地的几个关键动作后训练量化PTQ看起来简单——把模型权重替换成低比特表示就行但实际部署时误差很容易爆炸。我们踩出来的经验是校准集的选择比量化算法本身更重要。校准集必须和线上真实输入的分布一致而且要覆盖数据的“边界情况”。比如内容推荐模型线上会出现深夜的异常流量模式如果校准集里全是白天的正常样本量化模型在深夜流量下就可能输出奇怪结果。我当时用的是大概1200条样本做校准覆盖了正常样本、长尾样本和几个极端输入。校准时的统计工作大致如下面这个示意流程# 伪代码PTQ校准的完整思路 model.eval() calib_loader build_calib_loader(valid_data, count1200) # 记录每一层的激活值min/max以及权重分布 observer collect_activation_and_weight_ranges(model, calib_loader) # 选择per-channel或per-tensor粒度的量化方式 quant_spec make_quant_spec( activation_bits8, weight_bits8, per_channelTrue, per_tensorFalse ) # 对非sensitive层做INT8对敏感层保留FP16 quantized_model apply_ptq_quantization( model, quant_specquant_spec, sensitive_layersget_sensitive_layer_names(model) )还有一个非常容易被忽略的点量化不是把所有权重一视同仁。某些层对数值扰动特别敏感比如最后的分类层、embedding层直接压到INT8可能让指标掉得很明显。那时候我们采用的方式是“混合精度量化”把敏感层标记出来维护在一个名单里用FP16跑其余层INT8。名单不是猜的是用敏感度分析跑出来的。2.3 QAT感知训练什么时候值得花这个成本PTQ便宜但不是万能的。如果模型量化后准确率掉得超过3%又实在没办法替换结构那就得走量化感知训练QAT。QAT的思路是让模型在训练阶段就适应低比特带来的扰动把量化误差通过反向传播“消化”掉。它的成本主要在训练时间上通常要多训练几个epoch还要改训练脚本里插入伪量化节点。我们判断要不要用QAT一般看三点一是PTQ后指标跌幅是否不可接受二是模型是否需要长期迭代如果后面还要反复优化QAT的一次性成本可以被摊薄三是团队有没有足够的调参时间。如果决定做QAT有个经验是初始学习率要降到原来的十分之一左右否则伪量化节点的梯度噪声很容易让模型震荡。我们实际跑下来QAT之后模型的准确率能回到PTQ之前的95%-99%高并发场景下的推理速度还保持量化后的水平。2.4 量化之后必须做的评测和回滚机制很多人量化完只看一个指标——模型跑通了没。这远远不够。我们会在量化前后各跑一遍同一套评测集对比准确率、F1或者线上核心指标。这个评测集不能太小至少几百条否则统计噪声会掩盖真实的精度变化。另外就是做好版本化。我们当时把“原始模型”“FP16模型”“INT8混合精度模型”三个版本都打上了标签存在模型仓库里线上出问题时可以一键回退。高并发系统最忌讳的是上线后发现模型坏了又找不到原始版本那只能干瞪眼。在评测过程中我们遇到过一个反直觉的现象量化后单看准确率只掉了0.2%但线上用户反馈变差了。后来排查发现掉的那0.2%集中在长尾用户上而长尾用户更敏感。所以评测不能只看平均数要把按用户群拆分的指标也跑一遍。3. 结构化剪枝通道和注意力头的取舍逻辑与精度回补3.1 非结构化剪枝为什么不适合高并发场景剪枝的目标是去掉模型中的冗余连接。但剪枝还分两种非结构化和结构化。非结构化剪枝是把权重矩阵里不重要的单个数值清零模型参数量确实是少了但它变成一堆稀疏参数。通用推理引擎对稀疏参数的支持很有限稀疏度上去了推理速度却不一定提升甚至因为访问不规则还可能变慢。高并发和边缘部署要的是“实打实的计算量下降”而不是“理论参数量下降”。所以我们做的都是结构化剪枝——按通道、按层、按注意力头为单位整块移除让模型结构和算子在底层天然变少推理引擎不需要特殊优化也能直接提速。打个比方说明两者的差别非结构化剪枝像在墙上每隔几块砖抽掉一两块墙表面看没什么不同但你要重新粉刷时根本没法施工结构化剪枝则像直接拆掉一整段非承重墙施工效率高改动也干净。3.2 剪什么通道剪枝和注意力头剪枝的判定方法在CNN结构里最常用的判定维度是BN层的缩放系数。BN层里的γ参数直观反映了对应通道对输出结果的影响程度γ越小说明这个通道的信息量弱剪掉后影响也相对小。流程我们就用四步训练一个完整模型 → 统计各通道γ的绝对值 → 按阈值剪掉低贡献通道 → 微调恢复精度。以我们项目中的一个视觉模型为例剪枝后直接砍掉约25%的通道单次推理时延降了32%准确率只掉了0.4%微调后基本拉回原水平。对Transformer结构注意力头是更值得下手的目标。多头注意力机制本身有冗余有些头学到的模式和别的高度重合。判断方法是用一组代表性样本跑一遍模型统计每个注意力头的激活值与输出相关性把长期低激活、低相关的头整组移除。这里有个关键点不要只剪“看起来不重要”的头要看你剪完后剩下头的组合是否还能覆盖足够多的特征。我们曾经一口气剪了30%的头结果模型精度掉得比预想严重很多后来改成逐层少量剪、每剪一步就跑一次评测才稳住。3.3 剪枝微调的正确顺序剪枝之后必须微调这个没有讨论余地。但顺序问题容易被搞错。我们的正确做法是用完整训练集训练原始模型到收敛记录其效果。基于统计指标选出要剪的通道/头。一次性剪枝尽量避免剪一次调一次因为每次都改变优化目标很混乱。接着用原始训练数据进行若干轮微调。这里还要补充一个经验微调时不能用太小的学习率否则模型很难适应结构变化。我一般设置成原始训练学习率的10%-20%然后观察验证集指标如果前两轮不降反升说明学习率合适如果降了就停下来把学习率再降。3.4 用蒸馏补回剪枝损伤的实战方法剪枝后精度回不来很多人第一反应是更长时间训练。其实更好的办法是知识蒸馏让完整模型当“老师”剪枝后的模型当“学生”学生不仅学真实标签还学老师的输出分布通常几轮就能明显提升。有一个我们坑过的地方蒸馏的时候老师模型必须用“剪枝前的原始模型”而不是“剪枝后再训练复原的模型”。听起来理所应当但我们的同学在实现时误把老师设成了当前剪枝后的模型蒸馏了等于没蒸馏浪费了一整天的训练时间。老师模型的输出要在每轮前固定下来做成离线张量缓存能省很多重复前向计算。量化与剪枝合起来用的时候顺序也很重要。我们推荐先剪枝再量化。因为剪枝会改变模型中各通道的数值分布先量化再剪枝会导致量化统计的分布被后续变化破坏。先剪后量校准分布是最终结构的分布效果更稳。4. 边缘部署架构多设备编排与缓存设计把并发撑起来4.1 模型压缩之后部署层面才能谈高并发模型体积从几百MB降到几十MB单次推理时延从几百毫秒降到几十毫秒这才有了做高并发边缘部署的底气。但实际部署时还会遇到另一堆问题设备多、型号杂、算力分布不均怎么分配流量、怎么做缓存、怎么处理模型版本更新这些都是模块级的事情。我们当时的边缘部署环境是“一台中心调度节点 多台边缘推理节点”的结构。中心节点负责任务分发和汇总边缘节点只做推理。每个边缘节点部署同一个量化剪枝后的模型副本靠业务侧的负载均衡把请求打到不同节点上。这套架构下并发能力的上限就是“单副本QPS × 副本数 × 可用率系数”模型的单次推理越快同等硬件下的并发天花板就越高。4.2 批处理与异步推理把设备利用率拉满边缘设备的算力不大但并不意味着必须一次推理一个请求。我们用动态批处理把多个请求合并成一次推理设备利用率能提升一大截。核心是在“等待攒批”和“及时响应”之间做权衡。延迟太敏感就不能攒太久我们把攒批窗口控制在5-10毫秒最多攒16个请求一次推理效果非常明显。伪代码如下思路很容易迁移# 示意动态批处理核心逻辑 async def handle_request(req): batch await batch_queue.collect( max_wait_ms8, max_batch_size16 ) results await model_infer(batch) return results[req.index]异步推理也对并发帮助很大。请求进来后先入队推理线程不会阻塞等待每个请求完成而是批量消费队列完成一批再统一返写。高并发下用异步消息队列缓冲瞬时洪峰比每个请求同步占用一个线程要稳得多。4.3 缓存策略重复请求的隐性成本高并发系统里重复计算是最浪费的一件事。我们在边缘节点上加了缓存层缓存的是“输入特征 → 模型输出”的一一映射或者更节省点只缓存高频top结果。对于内容推荐类的场景热门内容被反复请求的概率很高命中率能达到20%-30%等于凭空省下了这部分推理。缓存还要注意失效策略。不能因为缓存让用户一直看到旧结果。我们用“时间窗口分数微调”的做法给每条缓存设一个有效期过期后该条请求重新走完整推理新结果再写回缓存。这样一个渐变刷新的机制既能扛突发流量又能保证结果不太旧。4.4 边缘设备适配算力、内存、带宽的三重约束部署阶段还有一个容易低估的环节模型压缩了但关键运算算子未必在每个设备上都高效。比如INT8量化在一些芯片上有专门的加速指令在另一些芯片上反而比FP16还慢。所以模型放到边缘设备前必须先在目标设备上做基准测试确认INT8算子的实测速度。内存上也要盯住。边缘设备的运行内存一般不大模型文件、运行时、中间结果三者会互相抢内存。我们直接把模型文件通过“轻量化容器”的只读层挂载避免重复加载和复制。带宽方面模型更新包不能太大量化剪枝后我们的更新包从几百MB缩到了二三十MB边缘设备在做模型热更新时基本感觉不到影响。还有一个我们觉得很有用的细节把模型拆成“主模型辅助分支”两部分主模型部署在边缘端需要大量算力的辅助逻辑比如复杂形态的排序和筛选尽量放到中心侧。边缘端只做最核心的判断和决策这样单设备压力小整个集群吞吐也更容易平衡。5. 压测与调优用P99和显存曲线决定能否上线5.1 压测指标不能只看平均时延高并发系统压测时最阴险的是平均值掩盖了大量慢请求。业务上我们最关心两个指标QPS每秒能处理的请求数和P9999%请求的耗时都低于某个值。P99反映的是极端条件下的体验如果P99飙到800毫秒平均时延再好看用户流失也挽回不了。除了时延还要观察显存曲线在长时间压测下是否缓慢增长。如果显存在不断攀升多半是推理框架内部有张量或队列没有释放。边缘设备上还会看温度设备过热降频QPS会突然掉一截这类问题在纯云环境压测里根本发现不了。5.2 一次量化剪枝后压测的完整过程和结果拿我们当时一个召回模型来举例。压测前先做设备校准把量化剪枝后的模型部署到边缘节点跑30分钟小流量观察日志里有没有异常输入确认无误后再逐档加压。压测分成三档低并发模拟日常流量、中并发模拟活动流量、高并发模拟峰值流量。每档跑10分钟记录QPS、P99、平均时延和显存峰值然后休息5分钟观察显存是否回落。最终数据大致如下模型版本单副本QPSP99时延显存占用原始FP32模型28620ms2.8GBFP1639430ms1.6GBINT8混合精度86190ms0.9GB剪枝INT8121108ms0.7GB这个结果验证了我们的方向模型单次推理快P99显著下跌相同显存下能跑更多副本。高并发能力不是靠堆机器堆出来的而是靠单次推理成本降下来的。5.3 上线之后常见的性能回退排查链路压测过了不代表上线后永远稳定。我们维护了一份排查手册遇到性能回退按顺序查先看时延有没有伴随显存曲线异常如果有查推理框架的缓存和连接池。再看是某一台设备变慢还是所有设备变慢如果是单台查设备是否过热降频或已被其他任务抢占资源。如果P99上涨但平均时延变化不大重点查批处理是否失效——请求模式突变导致攒批超时率上升每次推理都在“等batch”拖累了尾部时延。最后排查模型输入分布是否和校准集偏差过大尤其是量化模型输入分布漂移会引起激活值范围估计不准结果就是推理结果质量下降。这个链路我们反复用过很多次基本上能覆盖九成以上的线上性能问题。6. 复盘清单量化与剪枝失败的常见原因和正确顺序6.1 “量化一定掉点”是最大的误区好几次分享时有人问我你们量化后精度不降吗我的回答是不一定。量化掉不掉点主要看你有没有做对三件事。校准集和真实分布是否一致敏感层是否得到保留处理以及评测时有没有区分长尾。很多团队量化后掉点不是量化本身有问题而是校准集太随意或者一刀切全INT8。我们做过一次粗颗粒度的分析实验同一份校准集只调整覆盖范围量化后的精度差距就有1.8个百分点。可见“掉点”未必是量化的本质而是操作细节的代价。6.2 剪枝前先看算子热点分布剪枝别按“直观感觉”来。得先知道哪些算子或层真的占了大量计算时间剪掉它们才能带来可感知的速度提升。我们第一次剪枝时把精力放在参数量最多的层上结果参数量掉了很多时延没怎么降。后来一分析慢的其实是一些计算密度高的算子不是因为层参数多而是因为反复被调用。调整思路后先做profiling按算子耗时排序再针对耗时占比最高的层做剪枝和结构改造效果立刻不一样。6.3 高并发边缘部署的容量规划清单最后给大家一份我们内部在用的容量规划清单直接按项目套就行预估峰值QPS按日常10倍流量以上估算别太乐观。单副本能力取压测P99稳定下的最大QPS别用理论值。副本数峰值QPS ÷ 单副本QPS再乘以1.3-1.5的冗余系数。设备型号异构如果边缘设备有高算力和低算力两档分别测不同档位的单副本能力。模型更新节奏预留热更新窗口更新时对新版本做灰度验证。显存冗余至少保留20%余量防止推理中间张量临时上涨导致内存溢出。这一套下来从模型压缩到边缘部署再到并发支撑和压测验证整条链路就算闭环了。我个人在带这几次项目后最大的体会是模型压缩和高并发架构不是两件事而是一件事。量化让模型更快剪枝让模型更轻部署架构让流量更均衡压测让上限更清楚。先搞清楚瓶颈在哪再决定动哪里比拿着一堆热门技术名词往上硬套要靠谱得多。如果看完想跑通一遍建议你先拿一个小模型把量化、剪枝、部署、压测整个流程走一遍踩一遍坑以后对这个体系的体会会完全不一样。