先说一个最近常被问到的问题为什么模型选型、Prompt 编排、Agent 流程都做完了线上用户还是觉得“卡”这个问题的答案基本都落在AI系统性能工程上。模型能力再强如果系统扛不住真实并发延迟和吞吐压不住最终产品体验都会被拖垮。这篇是AI系统性能工程系列的第二篇我会把重心放在大模型推理优化、Agent 工作流编排、以及线上压测和问题排查上。第一篇聊过的基础方法这篇会直接带过重点讲可落地的优化手段和现场经验。适合做模型部署、写AI Agent 应用、或者正在被AI服务性能问题折磨的工程同学阅读。就算你刚入门也能照着里面的步骤给自己服务做一次性能体检。1. AI 系统性能工程为什么不能照搬传统思路1.1 传统性能优化工具在这里经常失灵做传统Web服务性能优化时思路很清晰加缓存、加连接池、调线程池、做负载均衡、优化慢SQL。因为请求相对独立CPU 和内存是主要瓶颈监控体系也很成熟拿到CPU、内存、磁盘、网络指标就能定位大多数问题。但AI系统的性能模型完全不一样。一个推理请求进来不只是消耗CPU还会占用GPU显存和算力多个请求可以拼在一个batch里跑请求之间互相影响模型权重、KV Cache、临时激活值都在抢显存。于是你会遇到传统监控完全解释不了的现象显存看着还剩不少新请求却被拒绝GPU利用率很高但吞吐上不去CPU一点都不忙用户延迟却高得离谱。这些问题的根因往往藏在推理框架的调度策略和显存分配逻辑里靠老一套工具确实看不到。1.2 从模型层到应用层性能问题分布在四个层面我习惯把AI系统的性能工程拆成四层看模型层参数量、量化精度、上下文窗口、采样参数。这里决定单次推理的理论代价。推理运行时层显存管理、批处理策略、调度器、并行方式。这里是AI性能优化的主战场。服务层API框架、网关、队列、限流、鉴权。这里负责把推理能力对外开放并保护后端。应用层/Agent层Prompt长度、工具调用次数、上下文管理、多智能体协作方式。这一层经常是性能瓶颈最容易被忽略的地方。性能问题往往是跨层的。比如模型层超长上下文导致prefill变慢表象却是服务层的请求超时再比如 Agent 应用层不断重复调用大模型成本飙升但监控图上模型延迟却很正常。只有先把问题映射到正确的层才能找到合适的解法。1.3 性能工程本质是目标取舍延迟、吞吐、成本、稳定性这四个目标在AI系统里天然互相拉扯。小并发场景下你希望TTFT足够低用户体验好高负载场景下你希望吞吐最大化摊薄单次成本但高吞吐往往意味着把更多请求塞进同一个batch又会推高单请求延迟。所以AI系统性能工程的本质不是“越快越好”而是“在可接受的延迟范围内尽量压出吞吐、控住成本、稳住尾延迟”。这也意味着性能工程必须建立在量化指标之上。没有基线就没有优化拍脑袋调参数只会把问题调得更乱。下一节就先解决指标问题。2. 先把指标定明白没有基线就没有优化2.1 大模型服务绕不开的六组关键指标做AI系统性能工程第一件事是统一语言。我常用的指标是这六组指标含义建议观测方式常见参考范围TTFT首Token延迟从请求发出到返回第一个Token的时间服务端打点观测p50/p95交互式场景最好1秒以内TPOT每个输出Token的平均生成时间用总生成时间除以Token数低于50ms/token才有流畅体感生成吞吐每秒生成的Token数tokens/sGPU或服务进程统计与模型规模和硬件相关请求吞吐每秒处理的完成请求数req/s压测工具统计与业务SLA绑定尾延迟p95/p99的端到端延迟压测日志分位统计过高会显著感知为“卡顿”错误率与重试率超时、拒绝服务的比例网关和客户端双向统计线上建议低于0.1%不要只盯“平均延迟”平均延迟会掩盖大量问题。一个服务平均200msp99却到了5秒说明长时间存在长尾请求拖后腿。性能调优的目标往往是先压p99而不是让平均值更好看。2.2 端到端延迟和模型延迟不是一回事最常见的误判是把模型推理耗时当成端到端延迟。实际一个AI请求在系统里走过的路径可能很长客户端到网关鉴权、路由转发、服务进程接包、预处理、构建Prompt、检索召回、排序、模型prefill、模型decode、流式返回、客户端首包解析。比如一个RAG问答系统用户体感延迟 网络RTT 网关耗时 向量检索耗时 Prompt构造耗时 模型推理耗时 流式传输耗时。如果模型推理只占40%那你优化模型半天体感提升也不明显。所以排查性能问题前先做链路分段打点。代码层可以很简单地打点不用引什么重型框架import time def handle_query(query): t0 time.time() retrieved retriever.retrieve(query) t1 time.time() prompt build_prompt(query, retrieved) t2 time.time() result model.generate(prompt) t3 time.time() print(fretrieve{t1-t0:.3f}s prompt{t2-t1:.3f}s generate{t3-t2:.3f}s)这样跑一次就能看出时间到底烧在哪个环节。实测中我见过不少“优化模型”的项目最后发现检索库没加索引一次检索占了总耗时一半以上。2.3 指标采样的三个坑第一压测并发线程数没设对。用JMeter或Locust压测时如果线程池配置过高客户端自己先成为瓶颈测出来的延迟曲线完全失真。先确认压测工具所在机器负载正常再谈服务端指标。第二只看均值不看分位。AI推理的延迟分布通常不均匀受批处理、抢占、显存换页影响长尾非常明显。必须把p50、p95、p99三档日志都打出来对比观察。第三忽略冷启动和预热。模型加载、内核缓存填充、显存预分配都需要时间。刚启动的服务前几十个请求性能会明显偏差压测时先热一杯水跑5到10分钟预热请求再正式开始记录。3. 大模型推理优化的显存、批处理与多卡选型3.1 先算一笔显存账再决定并发策略大模型推理的显存占用不是固定的。模型权重只是一部分随着请求生成KV Cache会不断膨胀。这一点如果不理解后面做并发策略全是盲打。KV Cache的估算公式不复杂每个Token需要保存Key和Value两组向量大小为 2 × 层数 × 隐藏层维度再乘以精度字节数最后乘上序列长度。以7B级模型为例假设32层、隐藏层维度4096、FP16精度每个Token的KV Cache约占用2×32×4096×2字节算下来差不多0.5MB。如果序列长度2048单请求的KV Cache就要吃掉约1GB显存。所以显存账要这样算可用显存 模型权重 激活值 KV Cache预留 推理框架开销。模型权重是固定的KV Cache却随请求并发和序列长度线性增长。你只调大并发数忘了给KV Cache留够空间系统就会在某个瞬间触顶显存接下来要么OOM要么疯狂抢占和换页延迟爆炸。3.2 连续批处理才是吞吐的发动机传统动态批处理是等一批请求凑齐再统一推理谁的请求短就先结束先返回但批次必须整体结束才能释放资源中间空转浪费很大。现在的推理框架普遍采用连续批处理GPU空闲时立即插入新的请求每个请求生成到自己的结束符就立刻退出不用等整批结束。这个机制对吞吐的提升非常直观。我曾经在同一个7B模型、同样硬件条件下做过对比关闭连续批处理稳定吞吐约400 tokens/s开启后同样的并发规模能跑到900 tokens/s以上。代价是单请求的延迟波动会大一些所以要通过调度策略控制同一时刻的活跃序列数比如max_num_seqs参数避免一个批次塞进太多长上下文请求把批处理周期拖得太长。配合连续批处理很多框架还在KV Cache分配上用到了类似虚拟内存的分页机制给每个请求按页分配缓存而不是预先分配最大可能长度的连续显存。好处是显存碎片大幅减少长请求短请求可以混跑缓存利用率高不少。这也是为什么我建议优先用成熟推理框架而不是自己写批处理逻辑调度算法远比想象中复杂。3.3 多卡并行方式怎么选模型太大单卡放不下或者算力不够想多卡一起跑常见的并行方式有三种数据并行每张卡放完整模型副本各处理不同请求吞吐能线性扩展但显存需求不变。适合模型能塞进单卡、主要缺吞吐的场景。张量并行把一层网络切到多卡每张卡算一部分适合单卡放不下的大模型但通信开销大跨机时延迟会明显增加。流水线并行按层切分不同卡负责不同层适合超大模型但容易出现流水线气泡利用率不容易打满。选型逻辑并不复杂7B、13B这种能单卡或双卡放下的小模型优先数据并行加连续批处理把吞吐压出来70B以上大模型节点内用张量并行节点之间再用数据并行只有模型在单节点都放不下时才需要认真考虑流水线并行。3.4 一套我实测过的推理服务参考配置拿一个13B模型部署在两卡环境的场景举例我会用类似的启动参数python -m vllm.entrypoints.openai.api_server \ --model /models/llama-13b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 64 \ --enable-prefix-caching几个参数的意思要说透tensor-parallel-size 设为2是因为模型在单张80G卡上虽然能放下但单卡算力有限两卡张量并行能显著降低单Token延迟。gpu-memory-utilization 设为0.9给CUDA、驱动、推理框架留出10%的显存余量避免显存颠簸。别贪心设成0.99实测很容易OOM。max-model-len 是支持的最大上下文长度。这个值越大KV Cache上限占用越高。如果业务不需要8192设成4096能省出大量显存给并发。max-num-seqs 控制同一时刻活跃的序列数。设得太大一个批次里挤满长请求端到端延迟会飙升设得太小GPU算力吃不饱。64是我在这个硬件组合下的折中值业务不同需要自己压测调整。开启prefix-caching多个请求共享相同Prompt前缀时可以复用KV Cache尤其适合Agent场景里反复使用系统提示词的调用模式。4. AI Agent 工作流的性能工程慢往往不是模型一个人的问题4.1 先拆一次 Agent 调用的时间账单AI Agent系统性能问题的特征和纯模型服务很不一样。用户的一次请求往往对应多次大模型调用中间还可能穿插工具调用、代码执行、文档检索。模型单次响应不慢但被编排逻辑一叠端到端就慢得离谱。我拆过一个典型的多智能体协作任务运行时间分布大概是环节调用次数单次耗时合计任务规划LLM调用13秒3秒子任务工具API52-6秒不等约20秒代码生成LLM调用28秒16秒审查LLM调用16秒6秒聚合总结LLM调用15秒5秒这些环节如果全部串行执行整体耗时接近50秒。但里面工具API调用是相互独立的代码生成和审查之间也有冗余等待。经过优化总耗时压到了18秒左右体感差距非常大。4.2 缓存一切能复用的结果Agent工作流的耗时大头往往不是模型能力而是重复劳动。同一个工具执行结果被反复取用同一段上下文被反复塞进Prompt这些都在浪费时间和Token。做三件简单的缓存收益往往立竿见影工具结果缓存比如检索API、数据库查询、HTTP请求加个内存或Redis缓存相同输入直接返回。不要求长期有效几分钟内复用就够了。LLM结果缓存相同或高度相似的Prompt直接命中历史结果。可以用语义哈希或嵌入相似度做近似匹配但要注意业务对结果时效性的要求。Prompt片段缓存现在主流推理框架支持前缀缓存或上下文缓存如果业务里所有请求都带一大段一样的系统提示词开启这个功能每次请求的prefill耗时能省一大截。4.3 并行化与流式输出要双管齐下很多Agent框架默认把工具调用写成了串行先调A工具拿到结果再调B工具。但实际业务里几个独立的工具往往可以一次并发发起。在代码层面用异步并发来控制几个工具同时跑时间成本从“加和”变成“取最大值”。具体实现时注意控制并发度不要无限发请求。可以用信号量把同阶段工具并发数限制在5个左右避免把下游API打挂。工具返回后优先把结果流式输出给用户而不是等全部链路跑完再一次性返回。至少能提升“首包体验”的感知用户以为系统在思考其实结果已经在路上了。4.4 上下文管理是Agent性能的隐形杀手Agent一多轮历史上下文会越来越长。Prompt长度直接影响prefill时间还同步扩大KV Cache占用。很多Agent变慢不是模型推理变慢了而是上下文太长了。优化思路是压缩和选择性保留历史消息做摘要把对话历史压缩成一段结构化摘要而不是把原始对话全部灌进模型。控制工具返回值长度检索结果动辄几万字符实际用到可能只有一小段。先做裁剪再进Prompt。阶段性“清空”一轮子任务结束后把中间细节写进摘要文件让主模型的上下文保持精简。这类优化对Agent性能的影响比调整模型采样参数明显得多。我在一个长会话机器人上试过上下文从1万Token压缩到3千Token后每次请求的prefill时间从2秒降到0.6秒。4.5 多AI协作场景里容易被忽略的系统级开销多智能体协作、多个模型并行处理任务听起来强大但系统开销很容易失控。每个Agent背后都可能是一个推理服务实例每个推理服务都有调度队列和连接池。如果Agent编排层没有全局限流和连接池共享流量峰值一到各个模型服务互相争抢资源整体雪崩。这里要特别提醒不要让每个Agent都维护独立的后端连接。公共模型网关连接池要复用给不同Agent设置优先级和配额对耗时长的任务设置超时和优雅降级。AI系统性能工程不只是调GPU参数还包括编排层的流量治理。4.6 一个可落地的Agent调优案例我对一个代码生成类Agent做了三轮改造第一轮去掉重复的上下文拼接逻辑所有工具返回先裁减再入Prompt单次调用的Prompt长度减少60%。第二轮把独立工具调用改成并发执行规划完成后一次发出5个检索请求而不是循环等待。第三轮给“审查”环节增加条件判断只有测试失败或者代码规范检查不过时才触发二次生成避免每次都白跑一轮。三轮改完端到端p50从42秒降到19秒p95从68秒降到31秒Token消耗也明显下降。这说明Agent性能工程的核心不是某一个高大上的参数而是把调用链路里的每一段浪费找出来处理掉。5. 线上表现怎么压测和排查5.1 压测方案先定好别上来就打性能优化最忌讳没有基准的乱调。一个可信的压测方案至少要包含四件事。第一请求集要有代表性。不要只压单一短Prompt要覆盖长短文本、工具调用、多轮对话、长回复生成。我习惯从线上日志里抽取真实请求做脱敏后组成测试样本这样的结果才贴近真实。第二压力要阶梯式增加。从低并发开始比如1、2、4、8、16逐步加每档维持3到5分钟观察系统在哪个阶段指标开始劣化。一上来就压高并发只会得到一张什么都看不出来的曲线。第三压测时长要够。很多推理服务前5分钟表现正常10分钟后显存碎片累积、队列积压性能开始恶化。每次正式压测我至少跑15分钟记录全过程的p50/p95/p99和错误率。第四软硬件状态要记录。模型版本、推理框架版本、量化方式、并发参数、GPU型号和显存全部存进压测报告。没有这些上下文以后你根本没法对比优化前后到底差了多少。5.2 典型性能问题的快速排查手册我把这几年最常见的线上问题整理成了一张速查表遇到问题直接对着查现象可能原因优先排查项常见解法TTFT很高prefill阶段慢、输入过长Prompt长度、检索耗时压缩上下文、开启前缀缓存生成阶段卡顿TPOT偏高decode带宽不足GPU利用率、显存频率减并发、降上下文长度、调量化吞吐上不去batch被长请求拖死平均生成长度、max-num-seqs调整批大小、限制最大长度显存OOMKV Cache预留不足、并发过高nvidia-smi观测显存曲线调低gpu-memory-utilization和max-num-seqs部分请求超时长尾调度问题、抢占频繁p99延迟、队列深度加超时重试、做优先级调度GPU很忙但CPU也满前处理、序列化、网关占资源CPU火焰图优化预处理逻辑、数据走二进制协议其中有一个我反复踩过的坑GPU利用率明明很高但吞吐就是上不去。最后定位到是API网关里的一次JSON序列化把CPU打满了请求在进模型服务之前就已经排队。这类问题靠GPU监控看不出来必须把全链路分段耗时打出来。5.3 给AI测试开发的一点心得性能工程和测试开发可以非常紧密地配合。我的习惯是把线上流量录制下来脱敏后保存成性能回归样本集每次模型迭代、框架升级、Prompt调整后都用同一套样本跑基线。没有回归样本的性能优化很容易出现一个问题这次延迟降了10%但另一个场景的长尾反而变差了你却完全没有发觉。测试用例也不能只覆盖标准输入。一定要包含极端场景超长文本、超高并发、工具调用失败后重试、连续多轮对话。AI系统性能是数据敏感的不同输入分布下性能差异极大测试覆盖不全会给你一种“性能很好”的错觉。6. 几个实践后才知道的性能细节分享三个很土但很有效的经验。第一个把耗时日志埋到所有关键环节。别一上来就上链路追踪系统先用最简单的时间戳打印采样率百分之几就够了。我排查过很多“又卡又慢”的AI服务最终都是靠这些原始日志定位到瓶颈。工具不怕土好用就行。第二个线上优化永远先解决“跨层浪费”。不少团队的模型推理耗时只有200毫秒但一次请求端到端要2秒差距基本都被Agent编排、重复调用、无效上下文吃掉了。先做链路分析再做参数调优顺序不能颠倒。第三个每次只改一个变量。今天调并发数明天换量化后天改上下文长度然后看整体指标这是性能工程的大忌。改完之后你根本说不清哪个改动起了作用。我用成本最低的方式保证可信度每次改动后只对比改动前后的全量指标其他条件原封不动。AI系统性能工程这项工作技术和业务耦合很深。模型在变、数据在变、Prompt在变性能基线需要持续维护。能跑通一个稳定、可控、有预算约束的AI性能体系本身就是竞争力。