做AI系统性能工程这件事跟我以前做传统后端性能优化的手感完全是两回事。传统Web服务你压一压、查一下慢日志、把慢SQL调一调基本就稳了。AI系统完全不一样它的“慢”藏在模型推理、显存排队、Token生成速度这些地方不把整条链路拆开看你甚至不知道瓶颈在GPU还是在你自己的代码里。这篇文章是AI系统性能工程系列的第二篇更适合正在负责AI应用落地的工程师、做本地部署AI服务的同学、被AI测试和性能压测折磨的QA以及想要搞清楚GPU开销到底花在哪儿的架构师。第一篇聊了整体的工程化思路和基本概念这篇我打算直接上硬货为什么传统性能工程的套路在AI系统上失效、怎么逐层拆解AI系统的性能瓶颈、一个真实推理服务的优化复盘、AI压测怎么做才靠谱最后是几个高频踩坑点的排查记录。1. AI系统性能工程到底是什么为什么不能照搬传统套路性能工程这个词在传统后端领域说了很多年无外乎容量规划、链路压测、瓶颈定位、缓存与异步化改造那一套。但AI系统一旦引入大模型推理这些老方法论会出现很明显的失灵现象不是理论错了而是系统的运行特征变了。1.1 传统性能工程的老办法在AI系统上为什么失灵传统Web系统有一个很大的特点请求成本大致可控。一个接口查询用户信息SQL语句是固定的索引是确定的数据库返回的行数也差不多于是单请求的CPU时间、内存消耗、IO次数都能估算。容量规划就是算并发乘以单请求成本再加个安全系数方向很清楚。AI系统不是。一个LLM服务接到同一个Prompt输入长度可能不同模型生成Token的长度可能不同中间还有采样过程带来的随机性时延波动天然就大得离谱。更关键的是大模型推理不是单一计算模式而是分成两个完全不同的阶段Prefill阶段也就是预填充。模型要处理你输入的整段Prompt本质上是大规模的矩阵乘法计算密集吃的是GPU的算力。一个1280 Token的PromptPrefill阶段就是一次大矩阵乘可以高度并行。Decode阶段也就是自回归生成。模型一次只能生成一个Token生成序列长度为N就要串行做N次小规模计算。每次都要把模型权重从头到尾搬一遍而实际的有效计算量很小本质上是访存密集。打个比方Prefill像是把一仓库的货一次性全部搬出来装车干的是体力活累但效率能靠并行拉满Decode像是一条流水线每次只从仓库里取一个零件送过去零件一次只送一个但你来回跑的路程一点没少腿脚倒是跑满了。两个阶段的瓶颈完全不同性能调优的策略当然也就不能一刀切。这个差异直接导致了传统三板斧的失效。加并发显存可能先爆加缓存缓存的是推理结果命中率天然不高而且结果要可缓存得先解决一致性问题加机器单请求时延不降吞吐可能被卡在通信上。所以说AI系统性能工程不是传统性能工程换了个场景而是需要一套从算子到业务层的全局视角。1.2 AI系统性能的三个核心层次我觉得做AI系统性能工程首先要在认知里建一个三层模型不然很容易陷入局部优化里出不来。数据与业务层Prompt长度与结构、RAG检索策略、上下文管理、缓存策略、业务超时设置。这一层最容易被技术型工程师忽略但往往是收益最大的。做过实际项目的人应该有体会Prompt精简20%、检索结果裁剪一半时延下降可能比换一块GPU还明显。模型与推理层模型参数量、量化精度、推理框架配置、批处理策略、KV Cache管理、算子融合。这一层是AI性能优化的主战场也是大多数人理解的“AI性能优化”。系统与基础设施层GPU型号与显存、CPU和内存资源、网络带宽、容器编排、弹性扩缩容。这一层决定了上下两层能跑多稳。三层之间会互相影响。举个真实例子业务层不做上下文压缩Prompt越长Prefill时间越长KV Cache占用越大推理层能支撑的并发就会越低最后基础设施层的显存直接爆掉。性能问题往往不止在一层所以我的习惯是每发现一个问题先问一句这个问题往上层追溯是什么往下层追溯又是什么。一个人很难对这三层全都精通但做性能工程的负责人至少要能看懂每一层的核心指标哪层的指标异常就拉哪层的同事一起看。性能优化做不好的团队最常见的问题不是某个人能力不够而是各层的人只盯自己的指标缺少一个能把链路串起来的人。2. 端到端性能分析框架从数据到显存逐层拆很多人在接到AI服务性能优化任务时第一反应是看GPU利用率发现不高就加并发发现太高就降并发然后就没有然后了。这太可惜了因为AI系统的性能问题很少只停留在GPU利用率这一个数字上。2.1 五层拆解法我在实际项目中习惯把AI系统的请求链路拆成五层每一层都有明确的采集手段和核心指标。数据入口层请求体解析、文本预处理、Token izer分词。Token izer看起来简单但长文本反复调分词就是纯CPU开销并发一高容易被忽视地打满。检索增强层有RAG的话向量库检索、文档召回、重排序、上下文拼接。这里涉及网络IO、向量相似度计算时延范围从几毫秒到几百毫秒都有可能。模型推理层Prefill和Decode两个阶段核心是模型前向计算。这一层的GPU算力、显存带宽是决定因素。服务编排层路由转发、限流熔断、超时重试、流式响应。一个常见的坑是重试策略过于激进线上一个小抖动就会触发重试风暴把系统打垮。基础设施层GPU、CPU、内存、网络、磁盘各自的压力和排队情况。为什么要拆这么细因为AI系统的时延问题是层层叠加的。用户感知到的总时延等于以上各层的时延之和如果不逐层测量你只知道“慢”不知道谁在拖后腿。我个人每到一个项目第一件事就是在每个关键节点埋点把每层的耗时字段都加到链路追踪里。很多团队做了链路追踪但只记录总时延这是浪费了这套基建的价值。2.2 关键指标表与口径统一AI服务性能指标和传统指标有不少重叠但有几个是AI特有的而且踩坑很多。我把常用指标整理成一个表方便团队对齐口径类别指标说明与口径建议时延类TTFT从请求发出到返回第一个Token的时间用户感知的“首响速度”时延类TPOT生成每个Token的平均耗时反映生成速度时延类端到端时延从请求发出到生成完成的总时间注意必须带上下文字段说明吞吐类Token/s单实例或集群每秒生成的Token总数吞吐类请求并发数同时在处理的请求数不只是压测那边发的连接数资源类GPU算力利用率建议看DCGM指标不要只看nvidia-smi的利用率口径会偏乐观资源类显存占用与上限普通额、KV Cache占、推理框架预留各是多少要分开统计资源类显存带宽利用率Decode阶段的隐性瓶颈容易被忽略质量类首包错误率建连失败、超时、非200的占比质量类超时率超过业务约定SLA的请求占比指标口径不统一这件事我在跨团队协同时踩过好几次坑。比如同样的“GPU利用率”NVIDIA的DCGM里细分了计算利用率、显存利用率和带宽利用率但很多同学看的是nvidia-smi里的那个百分比这个数字在某些场景下会虚高。又比如“显存占用”推理框架可能会预分配一部分显存作为缓存池已用显存看起来永远满的但这不代表业务真的把显存放在那儿跑。我跟团队现在强制的约定是任何涉及性能的指标讨论时必须写明取数来源和统计口径否则数据对比没有意义。这套五层拆解法本质上就是把AI服务当成一个有输入有输出的分布式系统来做性能工程而不是把它当成一个黑盒子只看外部指标。有了这个基础才能进入真正动刀优化的环节。3. 实操复盘一次AI推理服务的百毫秒级优化光讲框架有点虚我拿一个真实项目来复盘。注意细节我都做了脱敏处理但数据和优化思路是真实的。当时我们负责的是一个基于开源7B模型加RAG的文档问答服务部署在单张A10 GPU上用vLLM做推理服务业务场景是大量用户对着几份核心文档提问。上线没多久反馈就来了响应慢、经常转圈、一到大促压测就直接超时。3.1 最开始的性能画像接手之后我没有直接调参而是先做了两天的性能画像。第一步是部署标准链路追踪给每一层加了耗时统计第二步是用PyTorch Profiler和vLLM自带的日志看模型推理的细节第三步是用nvidia-smi和DCGM实时记录GPU状态。压测出来的第一版数据是这样的并发4的时候端到端时延已经到1.2秒P99直接到2秒并发8的时候显存OOM服务直接报错。GPU利用率不算低每次异步看都在70%以上问题是并发能力太弱根本没把这张卡喂饱。我逐层看数据之后定位出三个关键问题显存预算被模型权重吃掉太多。7B模型FP16精度下光权重就占14GB左右A10总共24GB显存还要留一部分给CUDA上下文和推理框架剩下的空间给KV Cache自然少得可怜并发能力被死死锁在个位数。RAG检索链路太慢。每次请求都做全量的向量检索和重排序平均耗时在200毫秒以上占总时延的六分之一以上。关键是有大量请求是重复的热点问题缓存完全没有利用起来。长Prompt的Prefill开销没有治理。业务侧图省事把一堆上下文和参考文档全部拼进Prompt单请求Prefill阶段就要处理几千个Token每次都重新计算既耗时又吃显存。3.2 三个关键的优化动作性能画像做完方向就清楚了不是先换GPU而是先把现有资源的浪费堵住。第一件事量化和显存重构。我们把模型从FP16切到INT8动态量化权重占用从14GB降到7GB左右省下来的显存全部留给KV Cache。这一步做完同等显存约束下能支撑的并发数直接翻倍。然后动用了vLLM的PagedAttention机制让KV Cache按需分配、分页管理而不是预留一大块整块空间等着每个请求来占。两个操作配合下来并发从4提到了16左右基本告别OOM。第二件事给检索层加缓存给重复上下文加前缀缓存。RAG链路里向量检索按相似度找文档但如果问题是重复的检索结果完全可以复用。我们加了一层带LRU淘汰的缓存把“查问题、拼上下文、召回的文档”都缓存起来命中率做到60%左右检索时延从平均200毫秒降到了10毫秒以内。还有个容易被忽视的优化是前缀缓存Prefix Caching。业务场景里所有请求都带同一份系统提示词和相同的背景文档这些前缀在每次请求里都被重复计算一遍。vLLM支持前缀缓存后重复前缀的KV Cache直接复用Prefill时间大幅下降。我印象很深一个包含2000多Token公共前缀的请求优化前Prefill要花800多毫秒优化后能跑到几十毫秒。第三件事调动态批处理和调度参数。这里涉及vLLM的几个关键参数。max_num_seqs控制一个批次最多塞多少个请求max_model_len控制模型能处理的最大序列长度gpu_memory_utilization控制有多少显存可以用来加载模型和KV Cache。我把gpu_memory_utilization从默认0.9调到0.95把批量策略切到Continuous Batching长请求和短请求混跑时不会再因为一个长请求卡住整个批次。调度上还加了个小优化流式输出开着但业务侧改成首Token到了就渲染用户的等待感明显下降。这些动作全部做完同一台A10上压测结果变成了这样指标优化前并发4优化后并发16-32端到端平均时延约1200 ms约300-400 msTTFT约800 ms约150 ms并发上限4再高OOM32吞吐每分钟不到10个请求每分钟约50个请求P99时延约2000 ms约700 ms3.3 优化效果与取舍这个项目让我感受最深的一点是AI系统性能优化的收益排序往往是先管好数据流再管显存预算最后才谈算子级别的优化。我们这次没有写一行CUDA代码也没有换模型靠的就是把业务层和推理层的浪费堵住效果甚至比换一块更大的GPU还明显。但也要说清楚代价。INT8量化确实会带来一定精度损失当时我们做了针对性评测结论是在这个问答场景下可接受。实话说如果业务对回答质量极度敏感量化这一步需要更谨慎收益和风险都要量化。另外动态批处理调上去之后单请求时延会更偏向高并发环境下的排队表现如果你是纯低并发的实时交互场景参数策略还得再调头。这个案例想说明的关键点是优化前先画像、先埋点数据会告诉你往哪儿用力。我最怕听到的一句话是“我觉得瓶颈在模型层”问一句“你怎么知道的”对方沉默。性能工程里直觉是起点的火花但能撑得起结论的永远是数据。4. 性能压测的工程化思路别再用压Web那套压AI性能优化做得再好没有一套可靠的压测体系你连自己优化得好不好都不知道。但AI系统的压测跟传统Web压测完全是两种生物。4.1 AI压测和传统压测的本质区别传统压测工具比如JMeter、LoadRunner核心假设是请求可以重复、响应可以断言、时延基本稳定。一个GET接口返回永远是那几百毫秒压测脚本永远可以重放。AI系统把这几个假设全都推翻了。请求幂等性不同。同一个Prompt发给模型两次生成的内容可能不一样没法用一个固定响应去断言。不是说不能断言而是要断言的维度变了比如是否返回了合理长度的输出、是否出现了失败码。时延分布不同。传统接口时延是窄分布AI服务的时延高度依赖输入长度和输出长度。输入越长Prefill越长输出越长Decode越长压测时如果不固定这两个长度出来的时延曲线是完全不可解释的。缓存会污染数据。压测如果反复打同一个热门问题比如500个并发全部问“公司年假政策”一旦命中检索缓存和前缀缓存拿到的性能数据就全偏乐观了根本不能反映真实业务混合场景。客户端可能是瓶颈。AI服务是流式输出的SSE连接会持续占用客户端连接数压测机自己的CPU、内存、网络如果不给够很可能服务端只跑到20%并发客户端机器自己先跨了。这个坑我踩过当时一度以为服务端不行结果一看压测脚本单线程排队数据全废。所以AI压测必须重新设计场景和指标这也是为什么我很少推荐直接拿JMeter上不是不能用而是它没法很好模拟AI的流式输出和动态长度特性。4.2 一套能落地的AI压测方案我目前的实操方案是用Python异步脚本来压AI服务理由有三一是能用httpx或aiohttp以流式方式接收SSE输出匹配AI服务真实的输出模式二是指标统计完全自己控制TTFT、TPOT这些传统压测工具很难拿到三是方便做成参数化脚本一键跑不同场景。压测场景至少要有三档短问短答平均输入300 Token输出100 Token模拟轻量闲聊。标准场景输入800 Token输出512 Token模拟日常文档问答。长程场景输入2000 Token输出1024 Token模拟大上下文使用。每一档都要有冷热两组数据。热数据是重复打同一个问题看缓存命中后的最佳表现冷数据是每次换不同的问题哪怕是随机生成同长度的伪问题看真实业务混合下的表现。两组数据差距越大说明缓存策略对性能兜底的程度越高一旦缓存失效系统能跌到什么程度心里要有数。加压节奏上不要一上来就500并发猛冲。我习惯从并发1开始逐级递增1 → 4 → 8 → 16 → 32每档跑3分钟让显存波动稳定下来再记录数据。记录的核心指标就是第2章那张表里的TTFT、TPOT、端到端时延的P50/P95/P99加上Token吞吐和错误率。除了阶梯加压还要补一个突刺测试在低并发平稳运行一段时间后瞬时把并发拉高到目标值的3到5倍观察服务的恢复时间。AI服务的弹性能力很大程度上取决于推理框架的调度能力能不能快速积压、快速消化、不雪崩突刺一下立刻见分晓。压测报告我一般用一张总表给结论里面放四行场景、冷/热、并发档位、关键指标。其他细节全部放到附录避免报告被淹没在数据里。5. 常见问题与排查技巧实录AI系统性能问题在现象上总是大同小异但根因可以五花八门。我把自己和身边朋友实际踩过的高频问题整理一下按现象到排查方向排列建议收藏备用。现象常见根因排查思路GPU利用率低但CPU高数据预处理、Token izer、RAG检索在CPU上拖后腿先看CPU热点py-spy看原生栈再定位是哪个库吃掉了时间显存OOMBatch Size过大、KV Cache预留不当、max_model_len设置不合理看显存分配明细优先调gpu_memory_utilization和max_num_seqs单请求时延慢但GPU、CPU都不忙网络、共享存储、Python解释器的GIL、向量库连接池耗尽分层埋点看哪层耗时最多重点查跨节点网络往返并发上去后回答质量变差采样参数被覆盖、动态批处理导致超长截断、上下文被裁剪检查推理框架的请求默认参数压测脚本里显式传参并记录采样配置多GPU不线性扩展通信开销大于计算收益、张量并行还是数据并行选错看通信占比小模型试数据并行不一定能加速单请求大模型才适合张量并行首Token很快但整体很慢Decode阶段吞吐上不去显存带宽是瓶颈看TPOT和显存带宽利用率部署层面考虑模型量化或换成更大带宽的GPU压测数据前后对不上压测机成瓶颈、缓存命中率波动、并发模型设置不一致复查压测脚本、固定冷热数据比例、每次记录时把压测机资源占用一并记录挑几个典型的展开说说第一个是GPU利用率低但CPU高。这个现象在RAG类服务里太常见了向量检索、文档拼接、Prompt预处理全在CPU上跑GPU大部分时间在等数据。我当时用py-spy dump看了一下CPU热点发现真正的坑就是一个关键路径上的json.loads加一次正则清洗每毫秒几百次CPU直接被吃满。优化办法也不复杂把数据解析和清洗放到请求进来之前的进程里或者用更高效的序列化格式立竿见影。第二个是显存OOM。很多人下意识觉得把Batch调小就行但AI场景要小心OOM很多时候不是因为模型本身大而是KV Cache分配策略的问题。vLLM的PagedAttention能让KV Cache按需分配但如果你同时把max_model_len设得非常大预分配的缓存池也会很夸张。这类问题必须先看显存分配明细别一上来就降Batch。第三是并发上去后回答质量变差这是个非常隐蔽的坑。最典型的是压测脚本里没有显式传temperature和top_p服务端在不同并发下采用了不同的默认参数导致生成风格漂移还有的是动态批处理为了排队效率把超过max_model_len的请求做了静默截断回答自然就变短变差。排查办法是每次压测前固定采样参数同时记录实际请求的上下文长度分布防止“隐性截断”蒙混过关。再补一个排队论层面的经验。AI推理服务在高并发下很容易出现排队时间指数上升因为每个请求的Decode阶段都要占用大量显存带宽新请求进来了老请求还没生成完排队越滚越长。你有两种解法一种是削峰把峰值请求放到队列里限制速率另一种是让推理框架支持抢占调度把低优先级的长任务暂停给短任务让路。能接受业务上轻微波动的我推荐后者收益明显。写在最后的实操体会做到现在我最大的体会是AI系统性能工程这件事拼的从来不是哪一招多漂亮而是能不能把指标拆干净、把动作做闭环。我见过一个团队花了两周在算子融合上猛抠性能结果一查线上数据RAG检索占了总时延的一半方向完全错了。如果让我给刚入坑的同学一个建议我会说先从“为你的服务建立一套完整的分层指标”开始指标都不完整就不存在真正的性能工程。每次线上抖动或者时延上升都要做到能在一小时内回答出“卡在哪个层、为什么、怎么修”这三个问题。能做到这一点的团队哪怕不做任何花哨的优化系统的稳定性也已经在及格线之上了。另外一个小技巧是多利用推理框架的观测能力。vLLM这类框架自带的日志和Prometheus指标里藏着大量信息很多人只把它当部署工具用却没用它的内置观测能力实在可惜。比如通过每请求的TTFT和TPOT分布能直接看出是排队问题还是单请求生成太慢这个信息量比任何外部压测都要真实。AI系统性能工程的路还长模型在变、硬件在变、框架也在变但“先观测再动手先找瓶颈再谈优化”的思路不会变。希望这篇复盘能帮你在自己的AI系统里少踩几个坑。
