★ FEATURED ARTICLE 把大模型从单机Demo推到生产环境难度完全不是同一个量级。我见过不少团队在跑通一个7B模型的时候信心满满结果一上服务就翻车显存爆了、并发一高就超时、多卡通信直接卡死。这篇文章就围绕“大规模部署LLM”这件事把我实际踩过的坑、测过的参数、最后沉淀下来的对策完整梳理一遍。内容聚焦在推理服务层的部署与调优适合正在做模型落地、或者准备把本地实验环境升级成正式服务的同学参考。1. 部署需求拆解先算清楚账再动手1.1 你的业务到底需要什么样的LLM服务很多人在部署LLM之前只想着“把模型跑起来”却忽略了“服务”和“跑起来”完全是两码事。生产环境需要明确的性能指标否则后面做的所有调优都没有目标。我建议在部署前先问自己三个问题业务方预期的并发量是多少峰值QPS大概多少单次请求允许的最长响应时间是多少模型上下文窗口要设多大是8K、32K还是更长这些问题直接决定了你选什么推理引擎、配置多少显存、用不用量化。举个例子一个客服场景可能要求首token延迟在2秒以内生成速度每秒不低于10个token并发50路。而一个离线批量处理的场景对延迟完全不敏感但要求吞吐量越高越好。两者的部署策略截然不同前者要调低并发、预留更多算力保证响应速度后者可以尽量把batch推到极限。我建议把SLA量化成几个核心指标再拆解TTFTTime to First Token从请求发出到返回第一个token的耗时反映服务响应的即时性。TPOTTime Per Output Token每个输出token的生成耗时决定用户感受到的生成速度。吞吐量Tokens/s单位时间内整体系统能生成的token数决定服务能支撑多少并发。这三个指标没办法同时全部拉满互相对抗。TTFT需要推理引擎尽快拿到第一批输出就要预填充阶段算得快减少排队但高吞吐量需要尽量把批量请求合在一起做连续批处理这又会让先来的请求等后续请求凑批拉高TTFT。记住这个矛盾后面调参就有方向了。1.2 量化方案与推理引擎选型引擎选型是整个部署的基石。当前主流推理框架无外乎vLLM、TensorRT-LLM、SGLang这些我最终用的是vLLM原因是它的PagedAttention机制能大幅减少显存碎片连续批处理continuous batching带来的吞吐提升非常明显而且它做到了OpenAI接口兼容接入业务代码几乎零成本社区活跃度也最高遇到问题容易找到解决方案。vLLM生态好部署快吞吐高支持模型广最适合第一版上线快速落地。TensorRT-LLMNVIDIA全家桶推理性能极致但模型编译和构建流程复杂适合追求极限性能的团队。SGLang新秀RadixAttention做前缀缓存很强适合长上下文或大量同前缀请求场景。Transformers原生出一个Demo可以生产环境不要碰速度慢且缺乏并发管理。谈到硬件成本量化是一个绕不开的话题。我只推荐两种方案AWQ和GPTQ4bit。他们在推理质量上损失很小普遍在小语种、逻辑推理等场景下会有一点掉点但显存占用能下降接近一半到三分之二。曾经有一个服务原来跑13B模型需要接近24GB显存换成4bit量化后卡在16GB显卡上也能稳定支撑业务。量化格式对比格式精度权重显存以7B为例推理速度推荐场景FP16/BF1616bit约14GB最快有充足A100/H100不差钱INT88bit约7GB较快显存紧张但不愿降质量AWQ/GPTQ 4bit4bit约4GB中等服务型场景追求低成本部署注意量化只是把权重压下来了KV Cache和中间激活值仍然是全精度计算所以显存估算别只按量化后的权重大小来算要留出至少30%的冗余。1.3 显存规划估算公式与服务器选型显存规划是大规模部署中最先要算清楚的一笔账我见过太多人模型还没加载就因为显存估算失误导致OOM崩溃。别只盯着模型权重显存消耗大头其实有三块模型权重、KV Cache、激活值。权重大小较好估算一个7B模型FP16权重就是7B × 2字节 14GB4bit量化则约3.5GB。KV Cache按上下文长度和并发数动态增长公式大致为单位字节2 × 层数 × KV头数 × 头维度 × 序列长度 × batch数 × 精度字节数。以常见7B规模的32层模型为例上下文4K单并发时KV Cache约0.5GB左右但这个数会随并发线性增长。激活值则取决于batch大小和序列长度通常建议预留总显存的10%到20%。我的选型建议很直接单张24GB显卡可以支撑7B模型的量化部署但并发只能控制在20到50路之间如果要把13B模型跑FP16并获得较高并发至少需要两张24GB卡做张量并行。服务器选型时优先考虑A800、H800这类大显存卡不要只图便宜选16GB的卡然后被显存问题折磨。2. 环境准备与基础依赖部署2.1 CUDA/PyTorch/vLLM版本匹配编程环境版本匹配是部署LLM中第一个劝退点很多人在这上面浪费了一整天时间。从我的实战经验看版本不匹配造成的“诡异问题”远比代码逻辑错误多得多比如CUDA driver版本过低导致无法加载算子或者PyTorch与vLLM版本相差过大导致引擎初始化失败。我当时部署时采用的稳定组合是CUDA 12.1 driver、PyTorch 2.1.x、vLLM 0.4.x。这个组合经历了生产环境多次验证稳定性很好。如果要用更新的vLLM版本建议同步升级PyTorch并检查驱动是否满足要求。部署前检查环境的命令nvidia-smi # 查看驱动版本和显存 python -c import torch; print(torch.__version__, torch.version.cuda) python -c import vllm; print(vllm.__version__)版本匹配决定了很多隐性问题是否存在。torch和CUDA toolkit版本不匹配时某些自定义算子会静默失败或直接抛错。目前社区有个常见的经验法则vLLM对CUDA版本的要求比较严格低版本CUDA驱动下很多算子无法编译而高版本驱动反而容易导致显存分配行为变了。因此装完环境后第一件事不是直接跑模型而是先跑一下官方预置的示例确认GPU算子和通信库都工作正常再往下走。2.2 模型文件下载与格式处理模型下载是大规模部署中极容易忽略的环节特别是国内服务器直接访问HuggingFace经常断流导致模型文件下载到一半就中断之后加载时随机报错特别难排查。建议下载时使用huggingface-cli并开启断点续传或者先用wget配合代理下载再通过huggingface-cli导入到指定缓存目录。另一个更稳妥的办法是将模型文件通过SCP到服务器本地目录然后直接用本地路径加载完全不依赖HuggingFace服务。模型文件格式也要注意。官方现在普遍默认用safetensors格式它比旧式的bin格式更安全更快加载时不需要反序列化Python pickle对象安全性高很多。如果下载的模型同时包含两种格式优先加载safetensorsvLLM会自动识别。还要记住不同格式的分片逻辑可能不一样比如某些模型会把权重拆成多个文件文件名中的数字序号跟文件大小必须完整缺少任何一片模型都无法加载。下载完成后检查文件数量、大小是否与仓库描述一致最好计算一下SHA256校验值。2.3 容器部署与基础配置生产环境我用容器部署。这里有一个新手容易踩的硬坑/dev/shm 空间默认只有64MB而vLLM在加载模型时会在共享内存中写入大量中间数据空间不足会直接报错退出。启动容器时务必加上--shm-size10g之类的参数。容器启动参数示例docker run --gpus all \ --shm-size10g \ -p 8000:8000 \ -v /data/models:/models \ -e HF_HOME/models/cache \ your-registry/vllm-image:latest \ --model /models/llama-7b \ --served-model-name my-llm多卡场景下还要额外配置NCCL环境变量比如NCCL_DEBUGINFO用于排查通信问题NCCL_IB_DISABLE1可以在没有InfiniBand的时候强制走TCP避免启动时卡在通信初始化。这些坑在文档里基本不会写但实际部署时几乎每次都会遇到。3. 核心服务启动与关键参数配置3.1 启动vLLM服务聚焦几个生死攸关的参数vLLM虽然看起来是启动一个服务那么简单但内部参数很多。实际生产环境中影响服务生死的就是几个关键参数--gpu-memory-utilization、--max-model-len、--max-num-seqs、--tensor-parallel-size。一个典型的启动命令vLLM较新版本python -m vllm.entrypoints.openai.api_server \ --model /data/models/llama-7b-chat \ --served-model-name chat-7b \ --gpu-memory-utilization 0.90 \ --max-model-len 8192 \ --max-num-seqs 64 \ --tensor-parallel-size 1 \ --dtype auto这几个参数之间不是独立的而是相互制约的关系。--max-model-len设置得越大KV Cache预留就越多--max-num-seqs越大batch上限越高吞吐量越好但显存压力也越大--gpu-memory-utilization则是所有这些参数的“总预算”。如果把这些参数都设到极大值服务会直接启动失败因为显存装不下。3.2 显存利用率、最大序列长度、并发数与KV Cache的关系先解释--gpu-memory-utilization。它指的是模型权重和KV Cache占显存的上限比例剩余部分留给激活值和临时计算。设为0.9已经是个比较激进的数值如果你同时还有别的GPU任务跑在同一张卡上建议降到0.8甚至更低。这个参数设置过高时某些模型会在长上下文的极端情况下触发显存溢出。--max-model-len指的是模型允许的最大上下文长度。很多人有个误解认为模型本身能支持32K就一定要设成32K。实际不是这样你设置的是显存预算的一部分每拉大一倍都会显著增加KV Cache开销。如果业务正常对话平均只有2K到3K上下文但你把上限设到32K意味着你为一个几乎不会发生的场景预留大量显存白白浪费资源就会导致并发下降。--max-num-seqs是引擎所允许的最大同时推理序列数。它跟外部并发密切相关假设你设64那么即便客户端发了200个并发请求服务端也只会同时处理64个其余请求排队。这个值调大吞吐量会上升但每个请求的延迟也会相应增加。一般7B模型单卡设为32到64是平衡区间超过之后收益变得很小排队延迟反而让人难以接受。3.3 多卡部署与tensor parallelism单卡扛不住大模型时就需要多卡并行。vLLM中最常用的方式是--tensor-parallel-size数值代表用几张GPU分担同一个模型的计算。例如13B模型在两张24GB卡上做张量并行权重被切分到两张卡上每张卡只需要负责一半的矩阵运算。张量并行能解决单卡显存放不下大模型的问题但它并非没有代价。每轮计算的过程中多张卡之间要通过NCCL同步中间结果通信耗时随着卡数量增多会变得明显。对于7B以内的模型我实际上不推荐做2卡并行单卡的性能往往更好因为通信开销有时反而让推理变慢。只有当模型单卡完全放不下时或者你需要同时服务的上下文特别长才考虑张量并行。另外部署时还要区分张量并行TP和流水线并行PP。TP是切分单层计算PP是按层切分vLLM对PP支持不如TP成熟。生产环境的稳妥做法是优先TP别碰PP。多卡部署还有一个容易被忽视的问题TP规模必须在启动时固定运行中不能动态调整如果业务需要弹性扩缩容就要在部署层重新拉起新进程而负载均衡则交给服务网关处理。4. 性能评估与调优让模型跑得更快更稳4.1 性能基线怎么测不要凭感觉判断快慢部署完成后第一件事不是让业务接入而是先打出一个性能基线。我在调试过程中每次都先用一个小脚本模拟请求记录TTFT、TPOT和总吞吐量。没有基线的调优都是盲人摸象。一个简单的压测思路是先单线程发一个请求连续发10次取平均值确定单请求的延迟天花板。然后逐渐增加并发线程数观察吞吐量和延迟的变化曲线。一般规律是并发从1增加到16时总吞吐量显著上升延迟上升不大继续增加并发到64以上时吞吐量增长变缓延迟开始快速攀升这说明已经接近系统瓶颈。模型实测中的一组典型数据量化与未量化的对比配置TTFT首token延迟TPOT每token耗时吞吐量显存占用7B FP16约680ms约35ms约28 tokens/s约16GB7B AWQ 4bit约760ms约43ms约23 tokens/s约6GB13B FP16 双卡约920ms约52ms约19 tokens/s约30GB13B AWQ 4bit约1050ms约47ms约21 tokens/s约8GB从数据能看出一个容易被误解的点FP16单看TPOT更快但实际吞吐量不一定比量化高多少。4bit量化虽然权重精度低了但显存占用大幅下降同样的显存下可以开更大的批处理把连续批处理的效果发挥出来从而在总吞吐上扳回一城。如果你的业务场景对单请求延迟极其敏感用FP16划算如果你追求单位时间处理最多请求量化后调大并发往往收益更高。4.2 continuous batching与并发调优连续批处理是vLLM对比传统批处理的核心优势。传统方案是把一批请求对齐到同一波次整批结束时统一交换结果一旦某个请求生成长文本其他已完成请求的GPU算力就空等了。连续批处理则不同任何序列生成结束后立刻从待处理队列拉新请求填充GPU始终处于忙碌状态。这种机制对吞吐量的提升非常明显尤其是当请求的生成长度差异很大时传统批处理的算力浪费比例会达到40%以上连续批处理能让利用率保持在80%以上。为了让吞吐跑起来还要调整客户端和服务端的配合方式。客户端不能发一个请求等一个结果再发下一个那样无论服务端多强都撑不起并发。应该用线程池或异步IO同时发送多个请求。一个简单的Python压测脚本示意import concurrent.futures import requests url http://127.0.0.1:8000/v1/chat/completions def send_one(prompt): payload { model: chat-7b, messages: [{role: user, content: prompt}], max_tokens: 512, temperature: 0.7 } resp requests.post(url, jsonpayload, timeout120) return len(resp.json()[choices][0][message][content]) prompts [介绍一下人工智能] * 100 with concurrent.futures.ThreadPoolExecutor(max_workers32) as pool: results list(pool.map(send_one, prompts)) print(len(results), sum(results))实测下来当并发从1提升到32时总吞吐通常能翻5到10倍。但并发继续加到128延迟会急剧升高TTFT可能从不到1秒飙升到5秒以上。这就回到了第一节说的矛盾高吞吐和低延迟需要动态平衡。4.3 长上下文的性能陷阱与PagedAttention长上下文是大规模部署中最隐形的性能杀手。很多人最初只看模型参数支持多少K没有意识到长上下文会对显存造成巨大压力。当多个请求同时持有很长上下文时KV Cache占用会指数级增长触发OOM没有任何先兆。vLLM的PagedAttention把KV Cache按固定大小的块来分配解决了碎片化问题。每个“页”可以被多个序列引用这就使得前缀相同的请求能共享KV Cache节省大量显存。这一特性对系统提示词很长、用户问题有明显共同前缀的场景特别有价值显存占用可能减少50%以上。但要注意PagedAttention并不会减少长上下文的绝对消耗。假设每个请求固定10K上下文100个并发请求的KV Cache预留会达到非常可观的数值。这时候就需要动态权衡设置--max-model-len为业务实际所需值不要盲目追求长文本另外主动控制请求的最大输出长度否则模型生成到一半显存耗尽服务直接崩溃没有任何缓冲余地。我在一些项目中甚至会在API网关层限制业务侧请求的max_tokens避免业务方把输出长度调得过大导致后端不稳定。5. 高频故障排查与稳定性保障5.1 显存相关问题的排查与解决显存溢出是部署中最常见的问题但表现形式五花八门。一种情况是启动时直接显存不足日志会报CUDA out of memory。另一种情况更隐蔽启动时明明显存足够跑着跑着突然OOM这通常是长上下文请求导致的。第三种情况是显存溢出没有报错只是推理速度突然变得极慢这是显存碎片化导致额外内存拷贝增多。排查显存问题的实用命令nvidia-smi # 查看进程占用 nvidia-smi --query-gpumemory.total,memory.used,memory.free --formatcsv遇到启动OOM优先降低--gpu-memory-utilization或降低--max-model-len。遇到运行期OOM先检查是否有异常长上下文的请求进来再检查并发峰值是否超过--max-num-seqs设定。还有一个小技巧vLLM支持--enforce-eager模式它关闭了CUDA Graph的预编译优化虽然性能会有损失但能显著降低启动时显存占用排查问题时可以先用它验证模型的正确性。5.2 并发下的性能劣化与超时处理一旦并发压上去最容易出现的问题是客户端超时。表现出来就是服务端日志显示请求正在排队而客户端已经报Connect timed out或者Read timed out。这种情况下很多人第一反应是加机器但有时候不需要先看服务端是否还有余量。vLLM的请求队列有个特点并发请求数超过--max-num-seqs时新的请求会进入内部队列等待。如果队列过长先进入的请求TTFT会不断推迟。此时需要做限流合理设置--max-num-seqs的值控制每次实际处理的数量同时让真正进入服务端的请求都能在可接受时间内返回。生产环境我建议在业务侧做两层超时保护第一层业务后端调用LLM时设置连接超时和读超时第二层网关层设置请求总超时超时直接返回降级文案不要傻等。不然一个慢请求把线程占住后面所有请求全部遭殃。另外vLLM的队列本身是内存态的一旦进程崩溃所有排队的请求都会消失所以网关层的超时和降级策略一定要有。5.3 服务稳定性保障与监控稳定性保障有一个核心原则一切可能挂的东西都会挂要提前做预案。LLM服务是长驻服务不像普通Web服务那样进程退出了重启就完事它重启一次光模型加载就要几十秒到几分钟。因此一定要有健康检查和自动拉起机制。健康检查不要只检查进程是否存活最好是发一个真实的最小LLM请求比如“你好”看它能否在30秒内返回结果。只检查端口能连通是不可靠的我之前遇到过进程活着但CUDA上下文已经损坏模型推理全部卡死TCP端口却正常响应的情况。监控指标至少要覆盖这几个维度请求数、平均TTFT、平均TPOT、生成总token数活跃序列数、排队序列数GPU利用率、显存占用率、温度进程异常退出次数和原因我习惯把这些指标通过Prometheus格式暴露出来配一个定时拉取的监控平台再对关键指标设置阈值告警。显存占用率超过设定值就提前报警不要在OOM之后才收到通知。还有一点服务进程要注意用--served-model-name显式命名模型这样在OpenAI接口调用时产品名与模型真实名称解耦后续模型迭代升级直接改映射即可不需要开发改代码。5.4 故障排查速查表现象可能原因解决方案启动时CUDA OOMGPU显存不足或--gpu-memory-utilization过高调低该值降低--max-model-len运行一段时间后OOM长上下文请求或并发峰值超预算限制输入长度降低--max-num-seqs多卡推理卡死NCCL通信初始化异常设NCCL_IB_DISABLE1查看NCCL_DEBUG日志服务端口通但推理超时内部排队过长或GPU算力打满客户端做限流服务端开新的副本模型加载报格式错误模型文件不完整或格式不支持校验文件完整性优先使用safetensors输出效果和本地测试不一致量化精度损失或temperature设置不同对比配置文件必要时切换到BF16精度这个部署链路走完一遍你会发现真正难的不是把模型加载起来而是让它在真实负载下保持稳定、可控、可观测。我在部署几个项目之后最大的体会是一定要先把性能基线和SLA指标定好再往里调参否则每天都在救火。如果在做生产部署时能把显存规划、引擎选型、参数匹配、监控告警这四件事提前想清楚大概可以避开七八成以上的故障希望你部署时也顺利。
阅读完成 · 觉得有帮助？
