★ FEATURED ARTICLE 去年有段时间我手上同时压着三个业务方的对话模型 demo全塞在一台单卡机器上。最开始的做法很朴素每个模型起一个进程用原生 PyTorch 加载 fp16 权重前面套一层 FastAPI。结果就是显存被三份权重切成碎片并发一上来就 OOM单条请求的吐字速度也就十几 token 每秒演示的时候肉眼可见地卡。后来把模型换成 int4 量化权重、推理侧统一交给LMDeploy托管同一张卡上三个服务稳稳跑起来并发吞吐翻了好几倍这套组合从那时候一直用到现在。所以当我看到实战营第二期把LMDeploy单独拎出来讲我一点都不意外——大模型推理部署这件事模型本身只是入场券真正决定你能不能上线的是引擎这一层。这篇东西我想聊的不是怎么敲那几行命令而是这条链路上每一个选择的理由为什么部署侧要单独引入一个推理引擎、TurboMind 和 PyTorch 两条后端什么时候该用哪条、量化到底是省了显存还是省了带宽、KV Cache 那笔账怎么提前算清楚、参数调优时哪些旋钮一动就出事。适合刚跑通pipeline()就想把服务推上线的同学也适合已经在用但一直被 OOM 和吞吐卡住的人。全文基于我在单卡和多卡环境里的实操涉及具体数值的地方都写了测算过程你可以直接照着套到自己的硬件上。1. 大模型部署为什么必须多一层推理引擎1.1 从能跑起来到跑得起之间隔着什么很多人第一次跑通模型推理是在 notebook 里写model.generate()看着文字一个个蹦出来觉得事情成了。但这一步和能对外提供服务之间隔着的不是工程包装而是三个硬指标显存占用、首 token 延迟、整体吞吐。原生 PyTorch 的generate()是逐请求执行的一个 batch 里所有序列必须等最长的那条生成完才能返回短请求被长请求拖着空转同时它不会为 KV Cache 做预分配显存是动态涨的涨到什么程度、什么时候爆你事先根本不知道。我印象最深的一次是给某业务方做内测五个人的小流量前四分钟一切正常第五分钟开始陆续报显存不足。查下来就是动态 KV Cache 在高并发长 prompt 下把预留的余量吃干净了。换成推理引擎之后这类问题的性质就变了从随机爆变成启动时就告诉你上限在哪。推理引擎干的核心事情说穿了就是把显存当成一块固定预算来规划而不是让框架在运行时随缘分配。1.2 LMDeploy 在整条链路里的位置把大模型上线拆成流水线大概是这么几段权重准备预训练/SFT→ 量化压缩 → 格式转换与引擎适配 → 推理服务 → 客户端接入 → 监控与压测。LMDeploy 覆盖的是后四段它同时提供了量化工具离线权重量化、推理引擎TurboMind 与 PyTorch 双后端、服务接口兼容 OpenAI 协议的服务端、以及客户端 SDK 和命令行工具。这种一个包打通量化到服务的设计好处是你不用在三个项目之间倒腾中间格式坏处是它的版本迭代很快网上搜到的教程命令经常和你装上的版本对不上——这个坑后面会专门讲。它支持的模型结构覆盖面比较广主流的对话模型基本都在列表里视觉语言模型和部分 MoE 结构也有适配。选它而不是自己写一套调度最实际的理由有两个一是 TurboMind 引擎在消费级和服务器级卡上都有不错的实测表现二是它的量化工具链和引擎是配套的W4A16 权重训出来能直接被引擎吃进去省掉了自己写加载逻辑的功夫。2. 双引擎架构TurboMind 和 PyTorch 该选谁2.1 两条后端的定位差异LMDeploy 里同时存在两套推理后端这是新手最容易懵的地方。TurboMind 是用 C/CUDA 重写的推理内核特点是权重布局和计算图都针对推理做了专门优化支持 Tensor Parallel 多卡切分、Persistent Batch 连续批处理、KV Cache 分块管理PyTorch 后端则是直接基于 PyTorch 和部分融合算子实现胜在兼容性好、支持新模型快、支持更激进的量化格式比如权重和激活都量化的方案。我的选型经验很直接TurboMind 能加载的模型一律用 TurboMind加载报错或者模型太新还没适配才退回 PyTorch 后端。同一张卡上同一个模型的实测TurboMind 的吞吐通常是 PyTorch 后端的两到三倍量级首 token 延迟也明显更低差异主要来自 Persistent Batch 和更紧凑的 KV Cache 布局。但要注意TurboMind 的适配是跟着版本走的某些结构上做过魔改的权重比如自定义 attention 或者特殊的 RoPE 实现会加载失败这时候别硬刚换后端跑通再说。2.2 连续批处理为什么是吞吐的命门讲清楚 Persistent Batch 这件事可以用餐厅类比。传统批处理像凑满一桌才开席来十个客人必须等第十个到了才一起上菜前面九个干坐着。连续批处理像流水席谁来了谁坐下谁吃完了立刻腾位置给下一个人。落到推理上就是每个请求单独维护自己的 KV Cache 槽位请求结束立即释放新请求填进空位GPU 的计算单元几乎不会因为等最慢的那条序列而空转。这件事对吞吐的提升是非线性的。短请求多的场景比如意图分类、短问答提升尤其夸张因为传统批处理里短请求被长请求拖累的时间占比极高。但连续批处理也带来一个副作用单条请求的延迟会随并发数上升而变差因为计算资源被摊薄了。所以调max_batch_size的时候不是越大越好得看你的业务更在意吞吐还是单请求响应。2.3 显存预算怎么提前算清楚这是我觉得实战营里最该反复练的一块。显存占用大致分三块模型权重 KV Cache 激活值与框架开销。权重那块好算参数量乘以每参数字节数。fp16 是 2 字节int8 是 1 字节W4A16 的权重量化是 0.5 字节再加上一些不可量化的层如 embedding、norm按原精度存储实际会略高一点经验上按 0.6 到 0.7 字节估比较稳。KV Cache 这块的公式值得背下来单 token 单层 KV 占用 2 × num_kv_heads × head_dim × dtype_bytes 全模型单 token 占用 上式 × num_layers 单条序列占用 全模型单 token 占用 × 序列长度拿一个典型的 7B 量级模型举例32 层、32 个注意力头、每头维度 128、KV Cache 用 fp16单 token 单层是2 × 32 × 128 × 2 16384字节也就是 16KB乘 32 层是 512KB约 0.5MB/token。一条 4096 长度的会话就要吃掉 2GB 左右。如果模型用了分组查询注意力GQAKV 头数会远小于注意力头数比如 8 个 KV 头那这块能直接降到四分之一这也是为什么现在新模型普遍上 GQA——它省的不只是训练显存更是推理时能不能把 batch 开大的关键。把三块加起来你就能反推cache_max_entry_count这类参数该给多少。LMDeploy 里这个参数控制 KV Cache 占空闲显存的比例默认值是 0.8意思是剩下 80% 的空闲显存全拿来开 cache 槽位。显存紧张的时候往下调到 0.5 甚至 0.4服务能起来但并发上限会降显存富裕的时候可以往上顶到 0.9但要留出至少 1 到 2GB 给激活值和 CUDA 上下文不然跑着跑着就爆。3. 量化这条路省的是显存赚的是带宽3.1 权重量化的原理与直观理解大模型推理是典型的内存带宽受限任务不是算力受限。解码阶段每生成一个 token都要把全部权重从显存读一遍做一次矩阵向量乘。所以瓶颈不在算得快不快而在搬得快不快。把权重从 fp16 压到 4 bit等于把要搬的数据量砍到四分之一理论上解码速度能接近四倍提升——当然实际会被反量化开销和各种 overhead 吃掉一部分但方向是对的。LMDeploy 主推的是 W4A16 方案也就是权重量化到 4 bit激活值保持 16 bit。选择这个组合而不是权重激活都量化理由很实在激活值量化对精度的损伤更难控制需要更复杂的校准和算子支持而 W4A16 在绝大多数对话任务上的效果损失已经小到业务方感知不出来。分组大小一般设 128也就是每 128 个权重共享一组缩放因子组越小精度越好但额外存储越多128 是个被验证过的甜点值。3.2 离线量化的完整流程量化的命令在不同版本里长得不一样新版把校准和量化合并成一步。核心参数就几个校准数据集、校准样本数、序列长度、位宽、分组大小。lmdeploy lite auto_awq \ ./hf_model_dir \ --work-dir ./awq_model \ --calib-dataset ptb \ --calib-samples 128 \ --calib-seqlen 2048 \ --w-bits 4 \ --w-group-size 128 \ --batch-size 1几个参数的选择逻辑值得说清楚。--calib-samples给 128 是我反复试出来的平衡点给 32 效果会明显掉给 512 提升很有限但时间翻几倍--calib-seqlen用 2048 是因为校准数据的长度最好贴近你真实业务里的 prompt 长度分布如果你的场景全是长文档问答可以往上提到 4096代价是显存和时间。--batch-size保持 1 最稳调大了容易在校准阶段 OOM收益也不明显。注意校准数据集的选择会实打实影响量化后的效果。通用文本校准出来的权重在代码、数学、多语言场景上可能有可见退化。如果你的业务偏某个垂直领域最好自己准备一份该领域的文本做校准这一步的收益比调任何推理参数都大。3.3 量化精度到底掉多少怎么验证不能只听几乎无损这种说法得有自己的一套验证方法。我的做法是准备一份 50 到 100 条的评测集覆盖业务里最常见的几类问题事实问答、指令跟随、格式输出、多轮上下文分别用原始 fp16 权重和量化权重跑一遍人工比对或者用一个更强的模型做裁判打分。从我的多次实测看W4A16 在通用对话上的表现和 fp16 的差距基本落在看不出来到偶尔措辞不同这个区间但在两类任务上要格外小心长链推理数学题、多步逻辑和严格格式输出JSON、代码。前者会因为细微的概率偏移导致错误累积后者会出现偶发的格式破损需要在后处理里加容错。还有个容易被忽略的点是量化后的重复退化就是模型偶尔陷入复读循环这个在温度设得很低的时候更明显把top_k和repetition_penalty稍微调一下能缓解不少。4. 从零跑起一条可用的推理服务4.1 环境准备版本对齐是第一道坎这块踩过的坑最多值得单独说。LMDeploy 对 CUDA、PyTorch、Triton 的版本组合比较敏感装错版本的表现往往是编译期报一堆看不懂的 C 错误或者运行时报找不到某个符号。我的建议是先看官方文档里那张版本对照表按表装别自己发挥。# 建议在干净的环境里操作避免和已有依赖打架 conda create -n lmdeploy_env python3.10 -y conda activate lmdeploy_env # 先装匹配的 PyTorch再装 lmdeploy pip install torch2.1.2 torchvision0.16.2 --index-url https://download.pytorch.org/whl/cu118 pip install lmdeployPython 版本我一般锁 3.103.11 和 3.12 在部分依赖上还会出问题。装完之后先跑一句lmdeploy --version确认命令可用再跑一个极简的加载测试别等业务代码写完才发现环境是坏的。提示如果机器上有多个 CUDA 版本务必确认nvcc -V和torch.version.cuda一致并且CUDA_HOME指向正确的路径。这三者对不上是最常见的玄学编译失败来源。4.2 离线推理先用最小代码验证链路不要一上来就起服务先用离线推理确认模型能正常加载和生成。新版的接口已经很简洁不再需要手动 convert 出 workspace 目录from lmdeploy import pipeline, TurbomindEngineConfig, GenerationConfig engine_cfg TurbomindEngineConfig( model_formatawq, # 量化权重格式fp16 模型留空 tp1, # 张量并行卡数 session_len8192, # 单会话最大长度 max_batch_size64, # 最大并发批 cache_max_entry_count0.8, # KV Cache 占空闲显存比例 ) pipe pipeline(./awq_model, backend_configengine_cfg) gen_cfg GenerationConfig( temperature0.7, top_p0.8, max_new_tokens512, ) resp pipe([介绍一下你自己, 用三句话解释什么是注意力机制], gen_configgen_cfg) for r in resp: print(r.text)这段代码跑通说明权重、引擎、显存配置三件事都对上了。如果卡在加载阶段先看是不是model_format和实际权重格式不匹配如果卡在生成阶段八成是session_len设得太大把 KV Cache 撑爆了往下调一半再试。4.3 起服务、接客户端、压测闭环离线通了之后起服务就是一行命令的事。LMDeploy 的服务端兼容 OpenAI 协议这意味着你现有的客户端代码基本不用改lmdeploy serve api_server ./awq_model \ --model-format awq \ --server-name 0.0.0.0 \ --server-port 23333 \ --tp 1 \ --session-len 8192 \ --cache-max-entry-count 0.8起来之后用 curl 验证一下curl http://127.0.0.1:23333/v1/chat/completions \ -H Content-Type: application/json \ -d { model: awq_model, messages: [{role: user, content: 你好}], temperature: 0.7, max_tokens: 256, stream: true }流式返回正常说明整条链路通了。接下来必须做压测不然你不知道这台机器到底能扛多少并发。关注四个指标首 token 延迟TTFT、每 token 输出延迟TPOT、单请求总耗时、系统整体吞吐tokens/s。我的经验是先固定并发数扫一遍找到吞吐曲线的拐点——并发从 1 加到 32 的时候吞吐一路涨加到 64 可能就平了再加就是延迟飙升而吞吐不涨那个拐点就是你该设的max_batch_size上限。至于tp多卡切分不是卡越多越好。7B 量级的模型在单卡显存够的情况下tp1往往是最优的因为多卡通信开销会吃掉切分带来的收益真正需要多卡的场景是模型大到单卡放不下或者你要用多卡去撑更高的并发。我见过有人给 7B 模型设tp4结果吞吐还不如单卡就是通信开销的锅。5. 常见问题与排查速查5.1 启动阶段的高频报错现象大概率原因处理方式加载时报unsupported model或结构不匹配模型结构未适配当前引擎版本升级 lmdeploy或改用 PyTorch 后端启动即 OOMcache_max_entry_count或session_len给太大先把 session_len 降到 4096、比例降到 0.5 试量化权重加载失败model_format与实际格式不符确认是 awq 还是 fp16参数必须对应编译期报 C 符号错误CUDA / PyTorch / Triton 版本不匹配按官方版本对照表重装环境服务起来了但请求 404端口或路径写错或模型名不匹配请求体里的model字段要和启动时一致这几条是我在帮别人排查时命中率最高的。特别是第一条很多人拿着最新开源的模型直接往旧版本引擎上怼报错信息又非常晦涩第一反应是怀疑环境坏了其实是结构没适配。5.2 运行期的性能异常吞吐上不去先看三件事max_batch_size是不是设得太保守默认值在小显存机器上可能只有个位数、KV Cache 预留是不是不够导致请求排队、以及是不是用了 PyTorch 后端。我遇到过一次吞吐只有预期三分之一的案例最后发现是启动时没指定model_format引擎按 fp16 加载了量化权重目录里的配置文件走了兜底路径速度自然起不来。延迟忽高忽低通常是长请求把批处理槽位占住了。可以在服务端加一个请求长度分流的逻辑超过某个长度的 prompt 走单独的低并发通道短请求走主通道。这个做法在混合业务场景里效果很明显代价是多占一点显存。显存缓慢上涨不回落如果排除了业务侧真的在累积上下文那多半是某些异常请求没有被正确释放槽位。加一层请求超时和主动断开能让这类泄漏收敛。5.3 效果类问题的排查思路量化之后效果变差别急着否定量化方案按这个顺序查先确认校准数据是不是和业务分布差太远这是最常见的原因再看是不是采样参数被量化放大了副作用把 temperature 从 0.1 调到 0.7 试试复读是否消失最后才怀疑分组大小设得太粗从 128 降到 64 重训一版对比。还有一种情况是看起来效果差其实是 prompt 变了。从原生框架切到推理引擎tokenizer 的处理、chat template 的拼接方式、特殊 token 的保留策略都可能有细微差异。我踩过一次坑切换之后模型总是把系统提示词复述出来查了半天发现是模板拼接时少了一个分隔符。这类问题的排查方式很土但有效——把送进模型的完整 prompt 打印出来逐 token 对比两边的输入是不是一模一样。6. 几个参数旋钮的调优心得session_len和cache_max_entry_count是一对强耦合参数调一个必须回头看另一个。我的做法是先按业务最长的上下文需求定session_len再反推能开多少个槽位最后用cache_max_entry_count去兜。举个例子业务里最长会到 8K那session_len就得给 8192假设 KV Cache 单 token 占用 0.5MB一条满长序列要 4GB显存只剩 20GB 可用的话理论上最多开 5 条满长并发——这个数字明显撑不起业务那就要么用 GQA 结构的模型要么把长上下文请求单独隔离出去要么干脆接受长请求数量受限这个事实并在网关层做限流。先算账再调参比在线上瞎试高效得多。max_batch_size我一般从 32 起调往上扫到吞吐拐点为止同时盯着 TPOT 别超过业务能忍的阈值。temperature和top_p在量化模型上可以比 fp16 稍微保守一点repetition_penalty从 1.05 起试能明显压住复读。最后分享一个我觉得最值钱的习惯每次改配置都记一笔写清楚改了什么、前后吞吐和延迟数字、业务侧有没有感知。这套记录攒上两三个月你对这台机器、这个模型的体质就有直觉了后面再来新模型估参数基本能一次到位。我在实际操作中的体会是推理部署这件事的天花板不在工具本身而在于你对显存这笔账算得够不够细、对瓶颈到底在哪看得够不够准——工具只是把这些判断落地的手段。
阅读完成 · 觉得有帮助？
