年初团队接了个任务把开源的 GPT 系大模型做私有化部署跑成内部服务给几个业务系统调用。模型本身两天就起来了HTTP 接口也能正常出结果但性能惨到没法看——单条请求要等二十多秒十个并发一起来就开始排队压力再大一点直接 OOM。就是在那段时间我们把“让 GPT OSS 私有部署的推理性能拉满”当成硬目标前后折腾了大半个月最终把系统吞吐从每秒 0.4 个请求干到了每秒 42 个请求一百多倍。这篇先讲上篇为什么你的推理服务那么慢、怎么量化自己的瓶颈、怎么通过权重精度、KV Cache 和推理引擎三板斧把性能拉起来。这里的“GPT”是生成式预训练 Transformer 架构的通用说法OSS 就是 Open Source Software开源软件的缩写。市面上已经有很多开源 GPT 架构大模型我下面统一叫“某开源GPT模型”避免具体名称干扰正文。这个教程适合已经把模型跑起来、但觉得响应速度不可接受的人不适合完全没部署过模型的新手。硬件方面我建议至少有一块显存 24GB 以上的企业级 GPU普通开发机上做性能对比会很容易被 IO 或散热干扰。1. 为什么私有部署的推理性能会差到“想砸键盘”1.1 先搞懂推理的计时到底花在哪大模型推理不是“算一次就完事”它分成两个阶段。第一个阶段叫预填充用户输入的一整段 prompt 会一次性喂给模型模型逐层计算产出一个带注意力缓存的中间状态这个阶段是典型的计算密集。第二个阶段叫解码模型一个 token 一个 token 地往外蹦每一步都依赖前面所有 token并且每生成一个 token 都要把全部权重从显存搬运到计算单元。这就是关键解码阶段是访存密集不是计算密集。拿 7B 参数量、FP16 精度的模型来说权重就有约 14GB。每次生成一个 token都要把这 14GB 数据读一遍。主流显卡的显存带宽大概在 1~2TB/s所以单个 token 的下限延迟基本就是十几毫秒。换句话说模型越大、精度越高单 token 延迟的物理地板就越低你再怎么改算法也突破不了这条带宽天花板。可以这么理解计算单元是大厨显存是山脚下的仓库权重是食材。大厨炒一个菜可能只要一秒但每炒一个菜都要把食材从山脚运上来运货速度才是真正的瓶颈。我们想做性能优化核心思路就是减少“搬运量”。1.2 并发一多就崩问题出在调度和显存如果你只是用模型加载工具写个简单的 HTTP 服务通常没有批处理也没有并发调度。一个请求来了独占 GPU 跑解码它跑完下一个请求才接着上。这就像只有一条流水线一个工件加工完才轮到下一个GPU 的算力在大部分时间里其实是空转的因为计算单元一直在等显存搬运。就算你加了静态批处理把几个请求攒成一批一起跑也会遇到另一个坑只要这批里有一个请求特别长整批都要等它结束才能腾出资源。GPU 吞吐上去了但单个请求的延迟会被拖得很高用户体验反而变差。显存碎片则是第三个隐患。每个请求在解码时会动态申请 KV Cache 空间申请释放、释放申请时间一长显存里到处都是小碎片明明总剩余容量够新请求却找不到连续大块空间于是 OOM。很多团队把“并发 6 个请求就崩”归结为显存太小实际上多半是调度和分配策略的问题。1.3 100 倍不是数学幻觉把优化项拆开算账先给结论我们最终实现的“100 倍”指的是系统吞吐也就是单位时间内能完成的请求数量。单请求延迟没那么夸张只有 4 到 5 倍左右的提升。面向服务的场景单请求体验和系统吞吐要分开看下面这张表是我优化前做的大致拆解优化手段理论提升量级说明权重精度从 FP16 降到 INT42~4 倍权重复制量减少解码带宽瓶颈松绑引入连续批处理5~20 倍从串行排队变成 GPU 流水线满载KV Cache 页式管理2~3 倍主要是提高显存利用率和并发上限推理引擎算子融合与图优化1.5~2 倍减少 Python 层调度和中间数据写回多实例/多卡并行2~4 倍下篇会讲是进一步扩展的手段这些优化不是简单的加法而是乘法关系。但也要注意瓶颈会在不同阶段之间转移先解决 CPU 调度再解决显存带宽再解决显存容量。每一步做到位后下一步的瓶颈才会暴露出来。所以不要指望单一手段能带来 100 倍它是组合拳的结果。2. 优化前必须做好的三件套基线、压测和对照实验2.1 先把三个指标念明白动手优化之前必须把“慢”量化成数字。我建议你至少盯住三个指标。首 token 延迟TTFT指的是用户发出请求到模型吐出第一个 token 的时间。它影响“首字响应”的体感主要由预填充阶段决定。单 token 延迟TPOT指的是生成阶段每个 token 的平均耗时它乘以生成长度就是你等待完整回复的时间。吞吐量则是一个时间段内完成的请求数或 token 数用来衡量系统扛并发的能力。这三个指标常常是矛盾的提高了吞吐单个请求的延迟可能会上升降低了精度延迟下去了但质量可能变差。优化前先确定你的业务到底看重哪个指标。如果做内部聊天助手TTFT 和 TPOT 更重要如果做离线批量分析吞吐量更重要。2.2 写一个简单的压测脚本把基线数据打出来不要用浏览器手动点接口也不要只看一条请求的时间那样得不出有效结论。我建议压测脚本固定 prompt 长度和生成长度。固定 prompt 长度是因为输入越长预填充阶段越耗时固定生成长度则避免模型自行决定结束位置导致指标不可比。下面这个脚本用 Python 标准库实现并发压测逻辑很简单开 N 个线程每个线程反复请求接口记录首 token 延迟和总持续时间最后汇总平均、最大、最小值和吞吐。你可以根据自己的请求格式改一发。import json import time import urllib.request from concurrent.futures import ThreadPoolExecutor API_URL http://127.0.0.1:8000/v1/completions PROMPT 请用200字以内的篇幅介绍一下大语言模型推理优化的基本思路。 MAX_TOKENS 256 TOTAL_REQUESTS 40 CONCURRENCY 8 def single_request(idx): payload json.dumps({ prompt: PROMPT, max_tokens: MAX_TOKENS, temperature: 0.1 }).encode(utf-8) req urllib.request.Request(API_URL, datapayload, headers{Content-Type: application/json}) start time.time() with urllib.request.urlopen(req, timeout120) as resp: body json.loads(resp.read().decode(utf-8)) total time.time() - start # 如果有返回 token 数或首 token 时间戳这里可以详细统计 text body.get(choices, [{}])[0].get(text, ) return total, len(text) def run(): t0 time.time() with ThreadPoolExecutor(max_workersCONCURRENCY) as pool: results list(pool.map(single_request, range(TOTAL_REQUESTS))) wall time.time() - t0 completed len(results) print(f完成请求数: {completed}) print(f总耗时: {wall:.2f}s) print(f平均单请求耗时: {sum(r[0] for r in results)/completed:.2f}s) print(f总吞吐QPS: {completed/wall:.3f}) if __name__ __main__: run()如果你用的接口是流式输出最好在客户端按事件解析首 token 时间否则你测到的 TTFT 会和网络缓冲混在一起。压测的时候记得把模型侧日志关掉日志输出是写磁盘一条两条不明显并发一高就会严重拖慢整体速度。2.3 对照实验的三条铁律少一条结果都不可信第一条铁律一次只改一个变量。很多同学喜欢同时升级引擎、改量化、调并发最后性能确实涨了但说不清是谁的功劳。后续某个参数回滚时也会非常痛苦。第二条铁律测试集必须固定且跑足时间。并发测试至少要跑 60 秒以上短时间压测很容易遇到缓存热效应数字虚高。每轮测试最好重复三到五次取中位数别用平均值平均值会被个别极慢请求带偏。第三条铁律记录环境和模型的状态。GPU 温度直接影响频率热的卡和冷的卡性能差很多。每次跑压测前先让一张空卡“预热”几分钟等温度稳定了再测。我们最初没注意这点前后两天同样的配置 QPS 差了 20%排查好久才发现是机房温度变了。3. 第一个提速开关把权重精度降到“刚刚好”3.1 精度到底影响了什么不是你想象中那么简单先看一张表明确不同精度下 7B 模型的权重占多大空间精度每个权重占字节数7B 模型权重显存解码时每步理论搬运量FP324约 28GB高BF16/FP162约 14GB中INT81约 7GB低INT40.5约 3.5GB更低解码阶段每生成一个 token 都要把所有权重读一遍所以权重体积直接决定了解码速度的物理上限。把 FP16 换成 INT4理论上搬运量减到约四分之一单 token 延迟会显著下降。同时权重腾出来的显存可以给 KV Cache 和批处理用并发能力也跟着上来。但它不是免费的。低精度带来的误差会在层与层之间传播尤其在长文本生成时误差会累积可能出现内容空洞、重复啰嗦甚至乱码。另外低精度推理对 GPU 有要求部分消费级显卡对 INT4 算子的加速效果一般降精度后可能只快了一点点甚至因为反量化开销不降反升。这也是我强调“刚刚好”的原因不是越低越好得拿你的业务数据来验证。3.2 量化方案怎么选校准比工具本身更关键业界的量化方案大体分两类训练后量化和量化感知训练。后者要在训练阶段就把量化误差考虑进去成本太高不适合大多数私有部署场景。前者就不动权重本身的训练只做后处理是私有部署的主流做法。训练后量化里又要区分只量化权重、还是权重和激活一起量化。只量化权重计算时再反量化回较高精度做乘加实现简单、质量损失小是第一次做性能优化时的首选。权重和激活都量化速度上限更高但容易遇到数值溢出需要大量调参和校准。校准环节最容易翻车。量化的本质是给每个权重段找合适的缩放因子缩放因子怎么定用真实业务数据来定。实际操作时我收集了业务系统里真实出现的几百条 prompt覆盖各种提问风格和长度喂给量化工具做校准。千万不要用随机文本也别用新闻语料随机文本的分布和真实业务相差太大校准出来的缩放因子在真实数据上效果很差。整个流程大概是导出原始 FP16 权重 → 加载到量化工具 → 用校准数据集计算缩放因子 → 导出低精度权重 → 做质量回归测试。质量回归这一步不能省我会拿同一组问题分别让 FP16 和量化后的模型回答对比内容完整性、明显错误、答案长度分布。3.3 四种精度的实测对照我在一块 40GB 显存的企业级 GPU 上跑同一个 7B 模型固定同一份压测脚本得到的数据大概是这样的精度方案权重显存单token延迟首token延迟质量表现FP1614GB80ms2.8s基准INT87GB48ms1.9s几乎无损INT43.7GB25ms1.1s可感知但可接受注意这个数据是“只改精度、其他条件不变”的情况下得到的。实际部署时还要配合后面讲的引擎INT4 的收益会更明显。我们最后选了 INT4 权重方案原因很简单内部场景允许一定程度的灵活表达但对速度敏感。如果你的业务是法律文书摘要、财务报告审核这类对严谨度要求极高的场景我会建议保守一点停在 INT8。3.4 量化翻车的三个常见现场现场一模型输出一堆乱码或者根本无法自洽。这通常是量化配置里的分组大小、反量化精度参数和原始模型结构对不上。排查方法是先量化一个单层对比输出差值逐步缩小范围。现场二短问题回答正常长文本越写越弱。这是量化误差在长序列自回归过程中的累积效应。可以考虑提高量化分组粒度或者对关键层通常是前几层和最后几层保留 FP16。现场三精度降了速度没有任何变化。遇到这种情况第一反应不是量化工具坏了而是你的模型还在用 Python 逐层调度的老路子执行根本没有走到低精度内核。这个问题我们换推理引擎后彻底解决了这就进入下一节。4. 第二个提速开关把 KV Cache 管起来4.1 KV Cache 到底吃了多少显存Transformer 模型做注意力计算时每个 token 都要生成对应的 Key 和 Value 矩阵后续 token 做注意力时又需要复用前面所有 token 的 Key 和 Value。为了不重复计算模型会把它们缓存下来这就是 KV Cache。它随序列长度线性增长是解码阶段显存开销的大头。可以这样估算单个请求占用的 KV Cache 空间层数 × 注意力头数 × 头维度 × 序列长度 × 2Key 和 Value 共两套× 数据类型字节数。拿 32 层、32 头、每头 128 维、FP16 的 7B 模型为例2048 个 token 的上下文算下来约 1GB。8 个并发请求就是 8GB再加上权重和计算中间激活24GB 的卡很容易被压垮。很多我觉得“显存不够用”的部署问题真实原因其实是 KV Cache 没有被好好管理。有的框架会为每个请求预留整块连续显存按最大序列长度算哪怕这个请求实际只生成了 100 个 token也按 2048 的长度预分配。这是巨大的浪费。4.2 两个突破口页式 KV Cache 和连续批处理第一个突破口是页式 KV Cache思路和操作系统虚拟内存很像。显存被切成固定大小的块哪个请求需要就分配给它不需要就回收。序列更新时不再要求一整段连续空间而是像翻书一样一页页往后加。这样碎片化问题大幅缓解显存利用率显著提高。这也是高性能引擎与我原来用的朴素加载工具最大的区别之一。第二个突破口是连续批处理。传统静态批处理的问题是等最慢的一个请求连续批处理则不同GPU 在运行时只要有一个请求生成了最后一个 token就立刻释放它的资源把排队的下一个请求补进去。GPU 流水线上永远有活干吞吐自然就上来了。说穿了这是一个调度策略的变革但带来的收益是数量级的。还有一个容易忽略的小优化叫前缀缓存。如果业务系统提示词是固定的比如每次请求都带一大段系统指令这部分前缀算出来的 KV Cache 完全可以跨请求复用。长系统提示词的场景下TTFT 能从中受益很多。4.3 显存怎么分配参数怎么调推理引擎一般会提供显存利用率参数让你控制“总显存里有多少可以用来分配”。我的经验是把权重占用、激活中间量、显存碎片余量先预留出来剩下的全给 KV Cache。比如 40GB 显存INT4 权重只占约 4GB我给 KV Cache 预留 32GB 左右剩下的留给激活和备用。块大小是一个需要调的重要参数。块太大一个请求哪怕只用了一小块空间也可能占据整块浪费块太小索引和管理的开销迅速增大。理论上大多数模型从 16 到 64 token 之间选择比较合适。我实践下来32 token 是多数场景的稳妥起点。优化前后并发表现对比如下配置可稳定承载并发数现象优化前固定大块预分配46 并发开始频繁 OOM页式 KV Cache1616 并发稳定显存无碎片崩溃再加连续批处理24GPU 利用率显著提升吞吐上涨明显4.4 这一段的避坑经验如果你看到有资料说“显存不够就把 KV Cache 关掉”请你直接划走。关闭 KV Cache 意味着每个 token 生成时都要重算一遍之前所有 token 的 Key 和 Value速度可能慢一个数量级这不是优化是灾难。另一个常见问题是把 max_model_len 设得非常大以为上下文越长越好。模型支持的上下文长度是能力上限不代表部署时要把显存按上限预分配。设成 32768KV Cache 的预分配压力会翻好几倍实际多数请求可能只用了几千 token纯属浪费。我建议按业务真实需求来设比如内部客服场景4096 或 8192 就够用了没必要追高。5. 第三个提速开关换掉“裸”的推理执行方式5.1 原生脚本为什么慢引擎到底做了什么事如果你目前是用模型加载工具加 Flask 之类的框架写了个 HTTP 接口每次请求进来都走 Python 层逐层执行计算图那性能天花板非常低。原因在于动态 shape 让算子无法充分融合Python 调度开销巨大GPU 内核频繁启停。简单说每一步都要在 CPU 和 GPU 之间往返时间全耗在路上。专业的推理引擎做的事情可以拆成三块。第一计算图静态化把模型结构固定下来减少动态分支开销。第二算子融合把多个连续操作合并成一个内核中间结果不再写回显存省下大量搬运。第三实现连续批处理和页式 KV Cache把调度和显存管理做到极致。这三块叠加起来比单纯换精度带来的提升还要明显。我习惯把这个东西叫“引擎X”因为市面这类框架的原则是相通的。你不需要自己造轮子选一个主流的、支持你所需量化格式的引擎即可。5.2 替换过程怎么做关键参数怎么定下面是一个简化的配置示意不同引擎的参数名略有差异但核心项是相通的。记得把每次修改后的配置存档方便回滚和对照。# 示意配置具体参数以所用引擎文档为准 model_path /data/models/your-gpt-oss-model-int4 dtype auto # 读取量化权重时自动选择计算类型 max_model_len 8192 # 模型最大上下文长度按业务实际设 gpu_memory_utilization 0.9 # 显存利用率预留10%给激活和系统 kv_cache_block_size 32 # KV Cache块大小32 token为稳妥起点 max_num_seqs 24 # 最大并发序列数根据压测逐步调大替换流程一般就是把量化后的权重目录指给引擎设置上面的参数启动服务把原来的接口地址切过来。最难的不是启动而是参数到底取多少。max_num_seqs 不是越大越好。它过大时并发序列抢占 KV Cache每个序列分到的空间变少可能出现上下文被迫截断或反复抢占反而吞吐下降日志里全是排队等待。第一次启动时建议把 max_num_seqs 从 8 开始压测一轮观察显存水位再逐步往上加。每加一档跑一轮压测直到 QPS 不再明显增长或出现 OOM 为止。这个“试探式调参”的过程比任何经验公式都靠谱。5.3 换完引擎后的第一眼数据同样的 7B 模型、同样的压测脚本、同样的并发工具只把执行方式从原生加载换到推理引擎数据是这个样子的指标原生加载推理引擎XTTFT2.8s0.6s单token延迟80ms28ms10并发下QPS0.415.0显存分配方式静态预分配动态池化可以看到单请求的 TTFT 和 TPOT 都有提升但更猛的是并发吞吐直接提升了三十多倍。这里面的主力是连续批处理它让 GPU 不再闲着每个 token 的时间都被压到极限。换完引擎后发现一个问题也很有意思日志里显示批大小很大但吞吐反而轻微下降。后来排查下来是 max_num_seqs 设置过大导致 KV Cache 块被抢来抢去每个请求都要频繁等待缓存块。把它从 32 调回 24QPS 立刻恢复。这验证了前面说的调参是个精细活。5.4 对推理引擎说几句实话不是所有场景都适合上推理引擎。小模型比如参数量几个亿的模型引擎的调度开销反而可能比模型计算还大性能提升不明显。7B 及以上的模型引擎的优势才会充分体现。引擎版本和量化格式的匹配也很重要。有些量化格式在原生工具里生成得很好但引擎不支持或者加载时要反量化回 FP16 再计算那前面降精度带来的带宽红利就全白费了。选型前先看引擎支持哪些量化格式再决定量化方案。6. 上篇收尾组合是乘积不是加法6.1 上篇四步做完后的成绩单到这里我们完成了四件事建立了基线、量化了权重、管好了 KV Cache、换上了推理引擎。把它们拼在一起最终的对照数据是指标优化前优化后提升倍数TTFT2.8s0.4s7 倍单token延迟80ms18ms4.4 倍单请求完整回复耗时256 token约 23s约 5s4.6 倍20并发下系统吞吐 QPS0.442105 倍可稳定承载并发数4246 倍所以准确说上篇做完后单请求体验提升了 4 到 7 倍系统总吞吐提升了约 100 倍。如果你只有一个用户在那里慢慢点你感受到的是“快了几倍”如果你有几十个人同时使用你感受到的是“从卡死到流畅”。6.2 还没讲完的事下篇还会讲什么很多朋友可能已经注意到上面所有优化都假设只有一张 GPU、一个模型副本。要再往上走下篇会涉及多卡和多实例部署张量并行如何把一个大模型切到多张卡上、多副本加负载均衡如何把单点服务的瓶颈摊开、投机解码和草稿模型怎么在不牺牲质量的前提下进一步压低单 token 延迟。还有监控和容量规划GPU 利用率、显存水位、KV Cache 命中率这些指标怎么接怎么在业务量上来之前发现问题。6.3 几句话说给正在踩坑的人性能优化做到最后本质是取舍。质量、延迟、吞吐、硬件成本四件事不可能全部做到最优。我的建议是别一上来就想着把它优化到极限先把业务负载摸清楚再针对真正的瓶颈动手。还有每一版配置和压测结果都留档随时准备回滚。最后提醒一句量化后的模型质量一定要让业务方参与验收让真正常用系统的人做盲测不要只盯着延迟曲线。我个人最深的体会是100 倍从来不是某一个大招带来的而是一层一层优化累积出来的结果每一层都在解决上一个瓶颈。
