每次接手一个新的AI模型部署项目团队最先问我的往往不是“模型怎么调优”而是“要不要买卡、买什么卡”。这个问题本身没有标准答案但它有一个比较靠谱的思考路径先算清模型的显存和算力账单再倒推业务需要的时延与吞吐最后才轮到硬件选型和性能优化。这篇文章就把这条路径完整走一遍重点拆解硬件选型里的常见坑以及部署后怎么把性能一点一点压出来。内容偏工程实践适合正在做模型服务化落地的开发者也适合准备从训练转向推理部署的同学。1. 部署前的需求拆解决定买什么卡的从来不是模型精度1.1 先算模型的“饭量”显存占用里藏着哪些大头很多人做硬件选型时只盯着参数量觉得一个7B模型FP16权重占14GB买一张24GB的卡就绰绰有余。实际上这只是一个开始。在线推理服务除了权重还要把KV cache、激活值、中间缓冲区、框架运行开销全部算进去才是一张卡真实要装的“饭量”。我一般用这个粗估公式显存占用 ≈ 权重 激活或KV cache 输出缓冲 冗余余量以当前主流的7B大语言模型为例FP16权重约14GB。如果在线服务batch size为8平均序列长度2048模型有32层、KV头数32、每个头维度128那KV cache的占用大约是batch×seq×layers×kv_heads×head_dim×2K和V×2字节 8×2048×32×32×128×2×2 ≈ 8GB权重加KV cache已经22GB再算上输入输出缓冲24GB卡很容易触发OOM。很多项目上线后频繁重启问题就出在只算了权重没算KV cache。所以我的习惯是部署前先写一个显存估算脚本把模型结构、目标并发、最长序列都做成参数跑一遍再决定卡。脚本逻辑其实很简单核心就是把上面公式落到代码上。我自己常用的版本长这样def estimate_memory(params_b, bits, batch, seq, layers, kv_heads, head_dim): weight_gb params_b * 1e9 * bits / 8 / 1e9 kv_gb batch * seq * layers * kv_heads * head_dim * 2 * (bits / 8) / 1e9 # 再加一点激活值和框架余量 total_gb weight_gb kv_gb 1.5 return weight_gb, kv_gb, total_gb weight, kv, total estimate_memory(7, 16, 8, 2048, 32, 32, 128) print(fweight: {weight:.1f}GB, kv cache: {kv:.1f}GB, total: {total:.1f}GB)当然实际部署时还要看你用的推理引擎会不会额外复制显存。比如有些框架默认开显存复用占用低一些有些则干脆利落地重新分配。这些差异在选型阶段不容易发现所以宁可把余量放大一点也别卡着临界点买卡。1.2 业务目标不只是精度时延、吞吐与成本怎么取舍硬件选型另一个误区是“我只需要跑得快”。可“快”本身分成两种单个请求要快那是时延敏感型单位时间处理请求要多那是吞吐优先型。两种诉求对应的硬件方案可能完全不同。在线客服机器人和AI对话助手是典型的时延敏感场景用户输入一个请求你必须在几百毫秒内返回。这种场景拼的是GPU算力、显存带宽以及动态批处理的效率。而离线批量内容审核、数据清洗、报表生成则更吃吞吐只要能在一晚上把几百万条数据跑完单个请求慢个三五倍都可以接受。这类任务用CPU或低功耗加速卡反而更划算因为不怕等待只要整体成本低、能效高。我在选型前通常会把业务指标写成一张小表目标p99时延是多少、峰值QPS是多少、单请求最大输入长度是多少、每天需要处理多少请求。有了这些数字才能判断硬件配置够不够。否则等到上线后压测不达标再回头换卡、改并行策略成本远高于一上来把需求想清楚。2. 硬件选型的核心指标算力、显存、带宽缺一不可2.1 CPU、GPU、NPU和专用加速卡怎么分先给一个粗略分类。CPU是通用计算负责数据搬运、预处理、控制逻辑低并发小模型跑起来完全够用但遇到大矩阵并行就力不从心。GPU是高并行计算适合深度学习里的矩阵乘法和卷积是当前大模型和视觉模型部署的主流。NPU和各类专用加速卡主打能效比功耗低、体积小适合边缘设备但算子兼容性和精度支持往往要仔细验证。我见过不少团队做边缘部署时直接用GPU开发板功耗压不住散热改造又是一笔成本。后来换成NPU方案算力够用功耗降了一半只是需要把部分特殊算子重写。选型的核心是看模型算子形态和目标设备的功耗预算而不是哪个听起来高大上就用哪个。这里给一个通用对比类型优势劣势典型场景CPU通用、易维护、生态成熟算力密度低大模型效率差传统机器学习、小模型、离线批量任务GPU并行度高、算子丰富、生态完善功耗高、采购成本高大语言模型、视觉模型、在线推理NPU/专用加速卡能效比高、单位功耗算力强算子受限、工具链成熟度参差边缘设备、嵌入式、功耗敏感场景2.2 算力和显存怎么算成具体数字算力需求看起来复杂其实可以按模型一次前向传播的FLOPs和目标时延反推。以自回归生成模型为例每生成一个token大约需要2倍模型参数量的FLOPs。一个7B模型就是大约14 GFLOPs/token。如果你想达到100 token/s的输出速度理论算力需求是14×100 1.4 TFLOPs。但这里有个反直觉的地方大语言模型在线推理的瓶颈往往不在算力而在显存带宽。因为生成token时要反复读权重7B模型FP16权重14GB每生成一个token就等于把14GB数据从显存里读一遍。假设显存带宽2TB/s理论最大输出速度是2000GB/s ÷ 14GB ≈ 142 token/s。带宽减半速度上限也跟着减半。所以选型时不能只看多少TFLOPs还要关注显存类型和带宽。视觉类模型则是另一套逻辑它们通常是单次前向完成更吃算力峰值和卷积算子效率。目标检测、语义分割这类模型显存占用主要看输入分辨率和batch size分辨率越高中间特征图占的显存越大。这时候要优先保证显存容量够用再追求算力。2.3 存储与网络的隐性约束还有一个容易被忽略的环节是模型文件加载。现在一个模型动辄几十GB如果放在普通机械硬盘上服务冷启动可能要花几分钟。放在NVMe SSD上能把加载时间压缩到几十秒。尤其是容器和Serverless架构下频繁弹缩实例冷启动慢会直接影响整体可用性。多卡并行部署时卡间通信也很关键。数据并行、张量并行都会产生大量通信如果卡间走的是普通PCIe通信带宽不够多卡还不如单卡跑得快。这也是为什么专业服务器里会有更高带宽的卡间互联方案。选多卡方案前一定要先弄清楚自己的并行策略到底有多少通信量再决定用普通服务器还是高互联带宽的平台。3. 推理引擎与模型优化让硬件真正跑满3.1 用专用推理引擎替代裸跑框架买了好硬件只是第一步真正影响上线体验的是推理优化做没做到位。很多团队直接把训练完的模型用训练框架加载起来当服务用这其实是性能杀手。训练框架要兼顾反向传播、自动求导、算子调试内部结构比推理复杂得多运行时开销自然大。比较成熟的做法是先把模型导出成开放的中间表示再通过专门为推理优化过的引擎做编译和部署。这类引擎会做常量折叠、算子融合、内存复用、自动选择最优kernel甚至针对不同硬件生成不同版本。优化效果通常很惊人都同样是单个请求的时延转换前后差两三倍不奇怪。但转换不是无脑点一下导出就行。有些算子在中间表示上支持不好会把一个算子拆成好几个低效算子反而更慢。所以每次转换后都要做两件事一是做精度回归对比转换前后模型输出差异二是在目标硬件上重新压测别用训练机器的数据当参考。3.2 量化、剪枝、算子融合三板斧模型部署优化里最常用也最见效的三个手段是量化、剪枝和算子融合。量化是把模型参数从高精度降到低精度。主流做法是FP16转INT8显存占用直接减半推理速度通常也能提升30%到50%。像我部署过一个OCR模型FP16转INT8之后时延降了47%准确率只掉了0.3%完全在业务可接受范围内。但量化不是简单地把每个权重除以一个缩放系数它需要在校准集上统计每个张量的动态范围选合适的缩放因子。量化后再跑一遍精度测试尤其是对数值敏感的模型逐层混合精度往往比全量INT8更稳。剪枝适合稀疏化程度高的模型。传统机器学习或轻量视觉模型剪掉一部分不重要的通道或连接精度影响有限计算量却明显下降。大语言模型的结构化剪枝更激进因为它改变整体权重矩阵需要重新微调部署阶段一般不轻易碰。算子融合则是把多个相邻算子合并成一个减少中间结果的显存读写。传统框架里一个卷积后面跟着BatchNorm再跟ReLU可能需要三次读写显存融合后一次读写就完成。这个优化大部分由推理引擎自动完成不需要你手动改模型但前提是你选用了带图优化能力的部署方案。3.3 动态批处理与并发设计在线推理服务如果想提高吞吐批处理是最直接的手段。但静态批处理有一个笨拙的地方一批请求必须全部处理完最早到达的请求要等最晚到达的。想象一下去餐厅吃饭必须等人齐了才上菜人均等待时间会长得离谱。动态批处理能解决这个问题。它允许先完成的请求立刻离开批次新到的请求马上补位进来类似流水线交替出餐。对生成式模型来说这个机制收益尤其明显不同请求的生成长度差异大动态拼装能让GPU在绝大多数时间都处于满负荷状态。我在实测中给一个文本生成服务加上动态批处理后吞吐量差不多翻了一倍而平均时延几乎没变。视觉模型也类似可以把尺寸接近的图片分到同一个batch里减少padding浪费。或者在后端做动态shape支持让引擎根据输入尺寸自适应选kernel。但动态shape会限制一些算子的预优化所以最好在吞吐收益和算子效率之间做一个平衡。4. 部署后的性能监控与问题排查4.1 盯住哪些指标才不算白监控我见过不少人上线后只盯“平均时延”这个指标非常不靠谱。一次慢请求会把平均值拉高但完全看不出抖动模式。正确做法是同时看p50、p99、p999还有吞吐量和硬件利用率。如果p99比p50高一大截说明存在明显的尾延迟根因可能是排队不均、GC抖动、网络重传也可能是CPU预处理卡顿。如果GPU利用率不到50%但显存占用很高说明请求可能堵在某个环节没到GPU瓶颈不在算力而在数据流。如果GPU利用率高但p99仍然高那基本是排队模型或批处理策略出了问题。压测也不应该跑几十个请求就下结论。我习惯至少压测30分钟最好1小时观察指标是否平稳。很多问题在短时间压测里根本暴露不出来比如显存泄漏、自动扩容震荡、缓存失效等都是跑一段时间后才现出原形。4.2 典型瓶颈定位与解决路径整理几个我踩过的高频问题现象可能原因排查思路解决手段GPU利用率低CPU占用高图片或文本预处理太慢看CPU各线程耗时数据加载丢到异步线程预处理多进程并行GPU利用率高p99高动态batch排队过长检查队列深度和等待时间缩小batch触发阈值限制最大排队数量偶发OOM长序列请求过多看显存曲线峰值降并发、限流、做量化或开启显存复用时延周期性抖动自动扩容或容器迁移叠加监控看扩容事件提前预热关闭无关的后台任务最典型的案例就是我之前部署过的一个图像识别服务。单看GPU算力两张卡怎么都够但压测时GPU利用率只有20%。排查后发现瓶颈不在推理而在图像解码和预处理它们走了同一个Python进程把GPU饿着了。我改成生产者-消费者流水线图片加载一个线程预处理一个进程池推理单独跑后处理再异步回传。改动之后GPU利用率升到了80%整个服务的吞吐直接翻倍。这类问题不做剖析很难发现因为任务管理器里CPU和内存看起来都不高。4.3 一个真实压测复盘再分享一个文本生成服务的调优过程。第一次压测时它用的单卡24GB给模型量化到INT8后权重约7GB加上KV cache和buffer压测到并发20时显存就报警了。我把问题拆成两段先用内存profiler看模型实际峰值发现模型本身没问题问题是框架为每个请求预分配了大量临时buffer相当于每个人都开了一个独立工作台。我做的改动有三个开启显存复用、限制最大序列长度、把动态batch的阈值调低。改完后同样的并发下显存峰值从22GB降到15GBp99时延从1200ms降到650ms吞吐还提升了一半。回头看没做什么惊天动地的操作但每一步都建立在监控数据上而不是凭感觉调参。5. 上线前避坑清单与我的实操习惯5.1 经常被忽略的细节清单很多部署事故不是模型问题而是工程细节。以下几条是我每次上线前必查的驱动和推理引擎版本要锁死。版本不一致算子和优化策略都可能变压测有效的数据上线后就不复现了。服务启动后一定要预热。让模型先跑几轮输入把权重加载到显存各算子完成初始化再开放真实流量。否则第一批请求会承担所有冷启动开销。输入输出要做尺寸和类型校验。动态shape虽然灵活但有些引擎遇到特殊尺寸会走fallback内核速度慢很多。最好在业务层做限制。显存使用率要设监控告警。接近阈值时提前扩容或限流别等到OOM才处理。压测环境必须和生产环境一致。这个一致包括CPU型号、内存通道数量、PCIe链路、操作系统内核甚至电源管理模式。我见过换了台CPU型号性能差30%的情况。5.2 我的优化节奏与一个小习惯最后说说我的工作习惯。做性能优化时我坚持一次只改一个变量。先加动态batch压测记录数据再上量化重新压测再调整预处理流水线继续记录数据。每个变量独立评估这样出了问题能立刻回滚也清楚知道收益来自哪里。另外一个小习惯帮了我很多次在压测脚本里打印模型输出的hash值和原始输出逐条对比。性能优化最容易踩的坑是精度悄悄变了但人工看几组结果根本看不出来。有了hash对比任何优化带来的输出变化都无处可藏。这个习惯也让我在团队评审时拿得出证据而不是“感觉效果不错”。踩过几次坑之后我现在接手任何部署任务都会先算清两笔账一笔是模型的显存和带宽需求一笔是业务可接受的时延与成本。算清楚再选硬件、做优化后续的坑会少很多。希望这套从选型到调优的思路对正在搞AI模型部署的你有用。 
长河君 · 2026/10/19 7:51:41 · 阅读 1.2k AI模型部署实战：从显存估算到推理性能优化
每次接手一个新的AI模型部署项目团队最先问我的往往不是“模型怎么调优”而是“要不要买卡、买什么卡”。这个问题本身没有标准答案但它有一个比较靠谱的思考路径先算清模型的显存和算力账单再倒推业务需要的时延与吞吐最后才轮到硬件选型和性能优化。这篇文章就把这条路径完整走一遍重点拆解硬件选型里的常见坑以及部署后怎么把性能一点一点压出来。内容偏工程实践适合正在做模型服务化落地的开发者也适合准备从训练转向推理部署的同学。1. 部署前的需求拆解决定买什么卡的从来不是模型精度1.1 先算模型的“饭量”显存占用里藏着哪些大头很多人做硬件选型时只盯着参数量觉得一个7B模型FP16权重占14GB买一张24GB的卡就绰绰有余。实际上这只是一个开始。在线推理服务除了权重还要把KV cache、激活值、中间缓冲区、框架运行开销全部算进去才是一张卡真实要装的“饭量”。我一般用这个粗估公式显存占用 ≈ 权重 激活或KV cache 输出缓冲 冗余余量以当前主流的7B大语言模型为例FP16权重约14GB。如果在线服务batch size为8平均序列长度2048模型有32层、KV头数32、每个头维度128那KV cache的占用大约是batch×seq×layers×kv_heads×head_dim×2K和V×2字节 8×2048×32×32×128×2×2 ≈ 8GB权重加KV cache已经22GB再算上输入输出缓冲24GB卡很容易触发OOM。很多项目上线后频繁重启问题就出在只算了权重没算KV cache。所以我的习惯是部署前先写一个显存估算脚本把模型结构、目标并发、最长序列都做成参数跑一遍再决定卡。脚本逻辑其实很简单核心就是把上面公式落到代码上。我自己常用的版本长这样def estimate_memory(params_b, bits, batch, seq, layers, kv_heads, head_dim): weight_gb params_b * 1e9 * bits / 8 / 1e9 kv_gb batch * seq * layers * kv_heads * head_dim * 2 * (bits / 8) / 1e9 # 再加一点激活值和框架余量 total_gb weight_gb kv_gb 1.5 return weight_gb, kv_gb, total_gb weight, kv, total estimate_memory(7, 16, 8, 2048, 32, 32, 128) print(fweight: {weight:.1f}GB, kv cache: {kv:.1f}GB, total: {total:.1f}GB)当然实际部署时还要看你用的推理引擎会不会额外复制显存。比如有些框架默认开显存复用占用低一些有些则干脆利落地重新分配。这些差异在选型阶段不容易发现所以宁可把余量放大一点也别卡着临界点买卡。1.2 业务目标不只是精度时延、吞吐与成本怎么取舍硬件选型另一个误区是“我只需要跑得快”。可“快”本身分成两种单个请求要快那是时延敏感型单位时间处理请求要多那是吞吐优先型。两种诉求对应的硬件方案可能完全不同。在线客服机器人和AI对话助手是典型的时延敏感场景用户输入一个请求你必须在几百毫秒内返回。这种场景拼的是GPU算力、显存带宽以及动态批处理的效率。而离线批量内容审核、数据清洗、报表生成则更吃吞吐只要能在一晚上把几百万条数据跑完单个请求慢个三五倍都可以接受。这类任务用CPU或低功耗加速卡反而更划算因为不怕等待只要整体成本低、能效高。我在选型前通常会把业务指标写成一张小表目标p99时延是多少、峰值QPS是多少、单请求最大输入长度是多少、每天需要处理多少请求。有了这些数字才能判断硬件配置够不够。否则等到上线后压测不达标再回头换卡、改并行策略成本远高于一上来把需求想清楚。2. 硬件选型的核心指标算力、显存、带宽缺一不可2.1 CPU、GPU、NPU和专用加速卡怎么分先给一个粗略分类。CPU是通用计算负责数据搬运、预处理、控制逻辑低并发小模型跑起来完全够用但遇到大矩阵并行就力不从心。GPU是高并行计算适合深度学习里的矩阵乘法和卷积是当前大模型和视觉模型部署的主流。NPU和各类专用加速卡主打能效比功耗低、体积小适合边缘设备但算子兼容性和精度支持往往要仔细验证。我见过不少团队做边缘部署时直接用GPU开发板功耗压不住散热改造又是一笔成本。后来换成NPU方案算力够用功耗降了一半只是需要把部分特殊算子重写。选型的核心是看模型算子形态和目标设备的功耗预算而不是哪个听起来高大上就用哪个。这里给一个通用对比类型优势劣势典型场景CPU通用、易维护、生态成熟算力密度低大模型效率差传统机器学习、小模型、离线批量任务GPU并行度高、算子丰富、生态完善功耗高、采购成本高大语言模型、视觉模型、在线推理NPU/专用加速卡能效比高、单位功耗算力强算子受限、工具链成熟度参差边缘设备、嵌入式、功耗敏感场景2.2 算力和显存怎么算成具体数字算力需求看起来复杂其实可以按模型一次前向传播的FLOPs和目标时延反推。以自回归生成模型为例每生成一个token大约需要2倍模型参数量的FLOPs。一个7B模型就是大约14 GFLOPs/token。如果你想达到100 token/s的输出速度理论算力需求是14×100 1.4 TFLOPs。但这里有个反直觉的地方大语言模型在线推理的瓶颈往往不在算力而在显存带宽。因为生成token时要反复读权重7B模型FP16权重14GB每生成一个token就等于把14GB数据从显存里读一遍。假设显存带宽2TB/s理论最大输出速度是2000GB/s ÷ 14GB ≈ 142 token/s。带宽减半速度上限也跟着减半。所以选型时不能只看多少TFLOPs还要关注显存类型和带宽。视觉类模型则是另一套逻辑它们通常是单次前向完成更吃算力峰值和卷积算子效率。目标检测、语义分割这类模型显存占用主要看输入分辨率和batch size分辨率越高中间特征图占的显存越大。这时候要优先保证显存容量够用再追求算力。2.3 存储与网络的隐性约束还有一个容易被忽略的环节是模型文件加载。现在一个模型动辄几十GB如果放在普通机械硬盘上服务冷启动可能要花几分钟。放在NVMe SSD上能把加载时间压缩到几十秒。尤其是容器和Serverless架构下频繁弹缩实例冷启动慢会直接影响整体可用性。多卡并行部署时卡间通信也很关键。数据并行、张量并行都会产生大量通信如果卡间走的是普通PCIe通信带宽不够多卡还不如单卡跑得快。这也是为什么专业服务器里会有更高带宽的卡间互联方案。选多卡方案前一定要先弄清楚自己的并行策略到底有多少通信量再决定用普通服务器还是高互联带宽的平台。3. 推理引擎与模型优化让硬件真正跑满3.1 用专用推理引擎替代裸跑框架买了好硬件只是第一步真正影响上线体验的是推理优化做没做到位。很多团队直接把训练完的模型用训练框架加载起来当服务用这其实是性能杀手。训练框架要兼顾反向传播、自动求导、算子调试内部结构比推理复杂得多运行时开销自然大。比较成熟的做法是先把模型导出成开放的中间表示再通过专门为推理优化过的引擎做编译和部署。这类引擎会做常量折叠、算子融合、内存复用、自动选择最优kernel甚至针对不同硬件生成不同版本。优化效果通常很惊人都同样是单个请求的时延转换前后差两三倍不奇怪。但转换不是无脑点一下导出就行。有些算子在中间表示上支持不好会把一个算子拆成好几个低效算子反而更慢。所以每次转换后都要做两件事一是做精度回归对比转换前后模型输出差异二是在目标硬件上重新压测别用训练机器的数据当参考。3.2 量化、剪枝、算子融合三板斧模型部署优化里最常用也最见效的三个手段是量化、剪枝和算子融合。量化是把模型参数从高精度降到低精度。主流做法是FP16转INT8显存占用直接减半推理速度通常也能提升30%到50%。像我部署过一个OCR模型FP16转INT8之后时延降了47%准确率只掉了0.3%完全在业务可接受范围内。但量化不是简单地把每个权重除以一个缩放系数它需要在校准集上统计每个张量的动态范围选合适的缩放因子。量化后再跑一遍精度测试尤其是对数值敏感的模型逐层混合精度往往比全量INT8更稳。剪枝适合稀疏化程度高的模型。传统机器学习或轻量视觉模型剪掉一部分不重要的通道或连接精度影响有限计算量却明显下降。大语言模型的结构化剪枝更激进因为它改变整体权重矩阵需要重新微调部署阶段一般不轻易碰。算子融合则是把多个相邻算子合并成一个减少中间结果的显存读写。传统框架里一个卷积后面跟着BatchNorm再跟ReLU可能需要三次读写显存融合后一次读写就完成。这个优化大部分由推理引擎自动完成不需要你手动改模型但前提是你选用了带图优化能力的部署方案。3.3 动态批处理与并发设计在线推理服务如果想提高吞吐批处理是最直接的手段。但静态批处理有一个笨拙的地方一批请求必须全部处理完最早到达的请求要等最晚到达的。想象一下去餐厅吃饭必须等人齐了才上菜人均等待时间会长得离谱。动态批处理能解决这个问题。它允许先完成的请求立刻离开批次新到的请求马上补位进来类似流水线交替出餐。对生成式模型来说这个机制收益尤其明显不同请求的生成长度差异大动态拼装能让GPU在绝大多数时间都处于满负荷状态。我在实测中给一个文本生成服务加上动态批处理后吞吐量差不多翻了一倍而平均时延几乎没变。视觉模型也类似可以把尺寸接近的图片分到同一个batch里减少padding浪费。或者在后端做动态shape支持让引擎根据输入尺寸自适应选kernel。但动态shape会限制一些算子的预优化所以最好在吞吐收益和算子效率之间做一个平衡。4. 部署后的性能监控与问题排查4.1 盯住哪些指标才不算白监控我见过不少人上线后只盯“平均时延”这个指标非常不靠谱。一次慢请求会把平均值拉高但完全看不出抖动模式。正确做法是同时看p50、p99、p999还有吞吐量和硬件利用率。如果p99比p50高一大截说明存在明显的尾延迟根因可能是排队不均、GC抖动、网络重传也可能是CPU预处理卡顿。如果GPU利用率不到50%但显存占用很高说明请求可能堵在某个环节没到GPU瓶颈不在算力而在数据流。如果GPU利用率高但p99仍然高那基本是排队模型或批处理策略出了问题。压测也不应该跑几十个请求就下结论。我习惯至少压测30分钟最好1小时观察指标是否平稳。很多问题在短时间压测里根本暴露不出来比如显存泄漏、自动扩容震荡、缓存失效等都是跑一段时间后才现出原形。4.2 典型瓶颈定位与解决路径整理几个我踩过的高频问题现象可能原因排查思路解决手段GPU利用率低CPU占用高图片或文本预处理太慢看CPU各线程耗时数据加载丢到异步线程预处理多进程并行GPU利用率高p99高动态batch排队过长检查队列深度和等待时间缩小batch触发阈值限制最大排队数量偶发OOM长序列请求过多看显存曲线峰值降并发、限流、做量化或开启显存复用时延周期性抖动自动扩容或容器迁移叠加监控看扩容事件提前预热关闭无关的后台任务最典型的案例就是我之前部署过的一个图像识别服务。单看GPU算力两张卡怎么都够但压测时GPU利用率只有20%。排查后发现瓶颈不在推理而在图像解码和预处理它们走了同一个Python进程把GPU饿着了。我改成生产者-消费者流水线图片加载一个线程预处理一个进程池推理单独跑后处理再异步回传。改动之后GPU利用率升到了80%整个服务的吞吐直接翻倍。这类问题不做剖析很难发现因为任务管理器里CPU和内存看起来都不高。4.3 一个真实压测复盘再分享一个文本生成服务的调优过程。第一次压测时它用的单卡24GB给模型量化到INT8后权重约7GB加上KV cache和buffer压测到并发20时显存就报警了。我把问题拆成两段先用内存profiler看模型实际峰值发现模型本身没问题问题是框架为每个请求预分配了大量临时buffer相当于每个人都开了一个独立工作台。我做的改动有三个开启显存复用、限制最大序列长度、把动态batch的阈值调低。改完后同样的并发下显存峰值从22GB降到15GBp99时延从1200ms降到650ms吞吐还提升了一半。回头看没做什么惊天动地的操作但每一步都建立在监控数据上而不是凭感觉调参。5. 上线前避坑清单与我的实操习惯5.1 经常被忽略的细节清单很多部署事故不是模型问题而是工程细节。以下几条是我每次上线前必查的驱动和推理引擎版本要锁死。版本不一致算子和优化策略都可能变压测有效的数据上线后就不复现了。服务启动后一定要预热。让模型先跑几轮输入把权重加载到显存各算子完成初始化再开放真实流量。否则第一批请求会承担所有冷启动开销。输入输出要做尺寸和类型校验。动态shape虽然灵活但有些引擎遇到特殊尺寸会走fallback内核速度慢很多。最好在业务层做限制。显存使用率要设监控告警。接近阈值时提前扩容或限流别等到OOM才处理。压测环境必须和生产环境一致。这个一致包括CPU型号、内存通道数量、PCIe链路、操作系统内核甚至电源管理模式。我见过换了台CPU型号性能差30%的情况。5.2 我的优化节奏与一个小习惯最后说说我的工作习惯。做性能优化时我坚持一次只改一个变量。先加动态batch压测记录数据再上量化重新压测再调整预处理流水线继续记录数据。每个变量独立评估这样出了问题能立刻回滚也清楚知道收益来自哪里。另外一个小习惯帮了我很多次在压测脚本里打印模型输出的hash值和原始输出逐条对比。性能优化最容易踩的坑是精度悄悄变了但人工看几组结果根本看不出来。有了hash对比任何优化带来的输出变化都无处可藏。这个习惯也让我在团队评审时拿得出证据而不是“感觉效果不错”。踩过几次坑之后我现在接手任何部署任务都会先算清两笔账一笔是模型的显存和带宽需求一笔是业务可接受的时延与成本。算清楚再选硬件、做优化后续的坑会少很多。希望这套从选型到调优的思路对正在搞AI模型部署的你有用。