★ FEATURED ARTICLE 这段时间一直在折腾开源大模型的落地部署试了不少推理框架最后在业务环境里稳定跑下来的是 LMDeploy。如果你也在做类似的事情——想把 Qwen、Llama 这类开源模型接到自己的系统里或者想在项目里做一个带 API 的聊天服务那么这篇文章应该能省下你不少折腾的时间。 LMDeploy 不是一个简单的模型加载脚本它把量化、推理、服务三个环节串成了一条线。也就是说你不需要先拿一个框架做量化、再换一个框架做推理、最后再单独写一个 HTTP 包装层。它自己就把这些事都干了。我这次用它在内网环境里部署了一个 7B 级别的中文模型从下载权重到对外提供 OpenAI 风格的接口整个流程走下来很顺。文章会按照我实际操作的过程来写适合有一定 Python 基础、打算把开源模型真正跑起来的同学参考。1. 为什么选 LMDeploy 做模型落地1.1 部署开源模型绕不开的三个痛点先说我自己遇到的情况。之前用一枚 7B 模型做验证FP16 权重大概 15GB单张卡勉强能加载但一旦开并发显存直接见底系统动不动就 OOM。这是第一个痛点显存不够放、放得下也跑不动。第二个痛点是吞吐。模型加载起来只是开始生产环境要面对的是多个用户同时请求。如果没有做动态批处理每一次请求都独占显卡算一遍资源利用率低得吓人。手动拼 batch 又很麻烦因为不同请求到达时间不一样强行等一批再算延迟又上去了。第三个痛点是全链路工具碎。量化是一套工具推理是另一套工具暴露 API 还要自己写中间层。中间只要有一个环节版本对不上整个流程就卡住了。我需要的是一个集成度足够高的工具包而不是一堆需要自己拼装的零件。1.2 和其他推理框架的对比我在选型阶段简单做过一轮对比下面的表是我当时整理的思路。对比维度LMDeployvLLMTGIllama.cpp量化能力内置 AWQ/GPTQ偏弱需外部配合偏弱支持较好OpenAI 兼容 API开箱即用开箱即用开箱即用需额外封装动态批处理TurboMind 原生支持PagedAttention 支持支持较弱GPU 吞吐表现高高中低偏 CPU上手门槛中低中中低vLLM 的吞吐确实强但量化不是它的强项我需要 AWQ 量化用 vLLM 的话还得额外搞一套量化工具链。TGI 部署很标准但对非主流显卡的支持一般。llama.cpp 在 CPU 场景很强可我要的是 GPU 高吞吐它不太合适。LMDeploy 把量化、推理、服务三者合在一起这一点对我来说是决定性的。1.3 它到底解决了什么问题LMDeploy 的核心是 TurboMind 引擎。你可以把它理解成一个专门为大模型推理调优过的执行引擎它会在内部做连续批处理和显存管理不需要你干预。其次量化工具是内置的。用lmdeploy lite子命令就能做 AWQ 4bit、GPTQ 8bit 量化量化完的模型直接给推理引擎用。我实测一个 7B 模型从 FP16 压到 4bit显存占用能降到原来的三分之一左右这对单卡部署来说是质变。再一个是服务化能力。lmdeploy serve api_server一条命令就能起一个 OpenAI 兼容的服务接口路径和参数格式都对齐 OpenAI业务端不用改 SDK 就能切过来。这一点在接现有系统时特别省事。2. 环境准备与安装2.1 硬件需求与显存评估部署之前先搞清楚自己的显卡能跑什么规模的模型。我按自己的经验给一个参考表模型规模精度权重显存约推理时总显存建议7BFP1614~15GB24GB7BW4A164~5GB12GB13BFP1626~28GB40GB13BW4A167~8GB16~24GB70BW4A1635GB多卡 80GB注意权重显存不等于实际占用。推理过程中还有 KV Cache、激活值这些额外开销所以表里给的“总显存建议”会宽松一些。我用的是一张 24GB 的显卡7B 模型做 4bit 量化后跑得非常宽裕。确认环境用两个命令就行nvidia-smi python -c import torch; print(torch.version.cuda)确保显卡驱动、CUDA 版本和后面安装的 PyTorch 是匹配的。强烈建议先用nvidia-smi看一下驱动支持的 CUDA 版本再决定 PyTorch 版本不然装完 CUDA 不可用排查起来很折磨人。2.2 创建环境并安装 LMDeploy我习惯先用 Conda 开一个干净环境避免和项目里的其他依赖冲突。conda create -n lmdeploy python3.10 -y conda activate lmdeployPython 版本建议选 3.10 或 3.11太新的版本有些依赖轮子还没跟上。然后直接安装pip install lmdeploy安装过程中会带上推理需要的相关依赖。如果你只需要在 CPU 上跑跑看可以装 CPU 版本但实际做服务部署肯定还是要 GPU 版本。装完之后验证一下lmdeploy --help如果能正常打印出子命令列表说明基本环境没问题。2.3 安装时的几个坑我第一次装的时候遇到了 FlashAttention 相关的编译报错。后来发现是 CUDA 版本和 PyTorch 版本不匹配导致的。解决方法是先把 PyTorch 装对再装 LMDeploy顺序反了容易踩雷。另外要注意lmdeploy升级很频繁不同版本之间某些参数名会变。我建议装完之后锁定版本pip freeze | grep lmdeploy记录下当前版本号后续如果升级一定要先看官方文档的变更说明否则之前能跑通的脚本可能突然报参数解析错误。还有一个很容易踩的坑环境里如果已经有旧版的transformers可能会和 LMDeploy 要求的版本冲突。建议在新环境里装的时候先不装乱七八糟的东西直接装 LMDeploy缺什么再补什么。3. 模型准备与量化3.1 拉取开源模型模型下载这一步国内环境我优先推荐用 ModelScope速度比直接连 HuggingFace 快很多。安装好客户端后执行pip install modelscope modelscope download --model Qwen/Qwen2-7B-Instruct --local_dir ./models/qwen2-7b-instructHuggingFace 用户也可以继续用huggingface-cli download拉权重命令类似。下载前确认模型协议允许商用这点在业务环境里很重要。这里有一个小经验下载时认准-Instruct或-Chat后缀的版本这些是对齐了对话格式的权重。如果你拿基座模型直接做对话没有经过对话模板处理回答会非常奇怪。3.2 格式转换与 TurboMind 的关系模型从 HuggingFace 或 ModelScope 拉下来之后原生是 safetensors 格式。LMDeploy 在加载模型时会把它转换成自己的 TurboMind 格式来跑转换过程会自动完成。你也可以提前手动转换lmdeploy convert ./models/qwen2-7b-instruct --dst-path ./models/qwen2-7b-turbomind提前转换的价值在于把格式转换的时间消耗从启动过程里挪走服务上线时启动速度更快。批量部署多台机器时也可以只转换一次然后把 TurborMind 格式目录分发到其他机器。3.3 AWQ 4bit 量化实操量化的价值再说直白一点把模型权重从 16bit 降到 4bit显存占用和计算量都大幅下降而精度损失控制在可接受范围内。LMDeploy 里做 AWQ 量化用这一条命令lmdeploy lite auto_awq ./models/qwen2-7b-instruct --work-dir ./models/qwen2-7b-awq --batch-size 32这里有几个参数值得解释--work-dir是量化后模型的输出目录。--batch-size是校准数据的批次大小显存足够时尽量调大校准效果更好。AWQ 量化本身需要一个校准数据集工具会默认拉取一批公开的校准数据如果你有自己业务领域的样本数据替换掉默认校准集会更好。我实际测下来7B 模型 AWQ 量化后显存占用从 15GB 左右降到 5GB 出头生成速度反而比 FP16 快了一截。所以在 GPU 资源有限的场景里量化不是“将就”而是一个更优的策略。量化完不用再做额外处理LMDeploy 的推理引擎和 API 服务都能直接加载这个 4bit 模型目录。4. 本地推理与服务部署4.1 命令行对话模式模型准备好之后先跑一个快速验证确认权重没问题lmdeploy chat turbomind ./models/qwen2-7b-awq --session-len 8192--session-len是上下文长度。7B 模型 8K 上下文比较稳妥如果你要处理超长文档可以调大但同时要留意显存变化。看到提示符之后直接输入中文问几个问题比如让它写一段代码、总结一段文字。这一步能快速发现两个问题量化出的模型到底能不能用、对话模板是否正常。如果连命令行对话都不对劲就没必要往下部署了。4.2 用 Python 接入模型命令行验证通过后下一步是把模型接进 Python 应用。LMDeploy 提供了 pipeline 接口from lmdeploy import pipeline, TurbomindEngineConfig engine_config TurbomindEngineConfig( session_len8192, cache_max_entry_count0.8, ) pipe pipeline(./models/qwen2-7b-awq, backend_configengine_config) response pipe(用一句话解释什么是动态批处理) print(response.text)cache_max_entry_count控制显存中 KV Cache 的占用比例。我建议不要设满留一点余量给显存波动。0.8 是一个比较稳的起点。pipeline 接口还支持批量传参responses pipe([ 介绍一下LMDeploy, 写一首关于秋天的诗, ]) for item in responses: print(item.text)这里要注意传列表进去框架内部会自动做动态批处理而不是简单的循环逐条执行。并发请求多的时候这个能力直接决定吞吐上限。4.3 一键启动 OpenAI 兼容服务最让我省心的是这一步。命令行里执行lmdeploy serve api_server ./models/qwen2-7b-awq \ --server-port 8080 \ --session-len 8192 \ --cache-max-entry-count 0.8服务起来后用curl验证一下curl http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2-7b, messages: [{role: user, content: 你好}] }返回的 JSON 结构和 OpenAI 的完全一致。这意味着你现有的业务代码只要配一个 base_url 就能把模型服务从云端切到内网不需要改请求格式。Python 端也可以用 OpenAI SDK 直接连from openai import OpenAI client OpenAI( base_urlhttp://localhost:8080/v1, api_keynot-needed, ) completion client.chat.completions.create( modelqwen2-7b, messages[{role: user, content: 你好}], ) print(completion.choices[0].message.content)这一步做完整个服务就相当于上线了。我实际部署时前后跑了不到半小时就把一个 7B 模型从权重变成了可对外服务的 API。5. 多卡部署与性能调优5.1 张量并行部署如果你手头是多卡机器或者模型的体量已经超出单卡显存LMDeploy 支持张量并行部署lmdeploy serve api_server ./models/qwen2-70b-awq \ --tp 2 \ --server-port 8080--tp 2表示把模型切到两张卡上并行推理默认是 0 卡开始。70B 模型做 4bit 量化后单卡 80G 能勉强装下但数据和并发一上来就吃力。用--tp 2切到两张卡单卡压力小很多并发也更稳。张量并行的原理是把 Transformer 层的计算分布到多张卡上每张卡只存一部分权重计算过程中卡之间要通信交换中间结果。所以多卡之间如果是 NVLink 或者高速互联性能会很好如果是普通 PCIe 连接性能会有折损但比单卡 OOM 强。5.2 核心性能参数怎么调我调试时最常用的几个参数逐个说明session_len控制上下文窗口长度。如果业务是短问答为主不需要开太大开大了 KV Cache 会吃掉大量显存。cache_max_entry_count控制 KV Cache 占显存的比例。这个值设得越高能同时服务的请求数越多但留给权重和激活值的空间就越少。我建议从 0.8 开始观察显存占用再微调。max_batch_size控制单次推理的最大 batch。TurboMind 本身有动态批处理不开这个参数也能工作但如果你明确知道业务峰值可以设置一个上限避免显存被冲爆。参数推荐值说明session_len4096~8192短对话用低值cache_max_entry_count0.8可从 0.9 开始往下调max_batch_size32~64按显存余量调整性能调优是一个试出来的过程没有万能参数。但套路是固定的先跑少量请求观察显存和延迟再逐步加并发找到性能拐点。6. 常见问题与排查实录6.1 显存不够用爆 OOM 怎么办这是最普遍的一个问题。排查步骤我按经验排序先看nvidia-smi确认显存是被谁占的是不是有其他进程残留。检查session_len上下文越长 KV Cache 越大。调低cache_max_entry_count从 0.8 调到 0.6 或者更低。如果还不行模型本身就需要量化或者换更小的模型。另外有些环境里会出现显存碎片化的问题服务跑一阵子后显存碎片变多新的分配请求失败。这种情况重启服务是最快的解决办法生产环境可以考虑定时在低峰期重启。6.2 量化后效果明显变差AWQ 量化之后模型效果变差首先怀疑校准数据质量。默认的校准数据是通用文本如果你的业务是代码生成或者数学推理建议提供一批真实业务样本来做校准。我做量化的经验是校准数据集要和实际使用场景尽量接近样本数量在 128 条以上效果比较稳。--batch-size不要开太小校准的时候显存允许就尽量用大 batch。如果真的压不住精度损失可以考虑 W4A16 的机制也就是权重用 4bit、激活值保留 16bit——LMDeploy 的 AWQ 量化默认就是这么工作的比连激活值一起压的“纯 4bit”要稳得多。如果还是不满意退回 8bit GPTQlmdeploy lite auto_gptq ./models/qwen2-7b-instruct --work-dir ./models/qwen2-7b-gptq6.3 API 服务起不来或者请求报错最常见的原因端口被占用了换一个--server-port。模型路径不对启动时一定要指向模型目录本身而不是它的上一级目录。模型名称不匹配虽然 OpenAI 兼容接口里的model字段不一定严格校验但有些客户端会校验保持和模型目录名一致最省事。并发请求过大时出现 502 之类的错误多半是显存被占满了按 6.1 的步骤调参。6.4 版本兼容性问题lmdeploy版本更新快命令和参数都有变动。我吃过一次亏旧版本里--cache-max-entry-count能直接用升级之后这个参数仍然可用但某些引擎参数名称变了。遇到这种问题先看版本lmdeploy --version然后去官方文档或者 GitHub 的 release 说明里比对参数变化。不要盲目相信网上旧的教程命令版本之间的命令差异是导致部署失败的高频原因。还有一个容易被忽视的点transformers版本不要随意升降级。LMDeploy 内部依赖它做 Tokenizer 和模型加载版本不匹配会在启动时给出难懂的报错。如果遇到tokenizer相关报错先查这一层的版本。7. 结尾我在实际部署中的体会是LMDeploy 最舒服的一点就是它把“量化—推理—服务化”串成了闭环你不需要在多个工具之间来回切换。第一次跑通的时候我从下载权重到启动 OpenAI 兼容服务大概用了不到一小时这个效率在以前的工具链里很难想象。最后再分享一个小技巧如果你的显卡是 24G 显存部署 7B 模型做量化后cache_max_entry_count调到 0.85 左右在保证稳定性的前提下并发性能会比默认设置好不少。我跑过一轮压力测试并发从 8 加到 32延迟增长依然可控。这个参数值得反复试找到你自己硬件的最佳值。下次遇到部署相关的问题欢迎回来交流这篇里的每一条经验都是实测过的。
阅读完成 · 觉得有帮助？
