团队内部刚开始评估大模型私有化的时候很多人第一反应是“直接用微信小程序里那种云端API不就行了吗”。等真把业务数据放进去试一圈才发现外部接口慢、贵、还有数据出域的合规顾虑这才开始认真研究自己部署推理服务。折腾了大半年我把vLLM从单卡跑通到多卡集群中间踩过不少坑也有过几次凌晨两点的救火经历。这篇东西就是我自己从零到上线的实战记录不打算写成一个通用教程而是把我认为最关键、最容易翻车的地方逐一拆开讲清楚适合准备做企业内网模型服务、正在对比推理方案、或者已经被显存和并发问题折磨过几轮的开发者。1. 为什么企业私有化部署绕不开vLLM1.1 先搞清楚你是被哪个问题逼到这一步的我接触到的团队选择私有化部署大模型服务理由基本逃不出三类。第一类是数据出域问题。有些业务数据明文里带客户信息、内部财务信息合同或者内部合规要求里写得明明白白数据不能离开自有环境。这时候无论外部API效果多好都用不了只能自己把模型圈在内网里跑。第二类是成本账单失控。外部API按token计费平时测试没感觉一旦接入真实业务流量调用量上来之后月度账单涨得很快。尤其是文档处理、客服问答这类需要长文本和多次调用的场景成本曲线是陡峭的。自建方案把成本从“按次计费”变成“一次性硬件投入电费”长期看账面上更划算。第三类是模型私有化定制。业务方往往会基于开源底座模型做微调把企业知识库、专属话术灌进去。微调后的模型权重不可能传到外部平台只能在内部环境里自己加载和服务。这三种情况都会导向同一个技术选型问题推理服务用什么跑。早期方案有直接用深度学习框架做动态图推理的有基于其他推理框架改的但实践下来大家基本都会绕回vLLM。1.2 vLLM到底动了哪块蛋糕vLLM不是大模型本身它是一个专门做大模型推理加速和服务的开源引擎核心是“PagedAttention”这套显存管理思路。传统推理框架处理请求时会给每个请求的KV缓存模型生成过程中保存的中间状态分配一块连续显存。问题在于每次请求生成的序列长度是动态的预先按最大长度分配会浪费大量空间而如果分配得太保守又放不下。这就类似老式内存分配里“碎片化”问题显存明明剩很多但都是零散的新的请求塞不进去。PagedAttention做的事就是把KV缓存切分成固定大小的块像操作系统管理虚拟内存一样按需分配、可以分散存放。这样做的好处很直接显存利用率大幅提升同样的显存能塞下更多并发请求吞吐量随之成倍上涨。vLLM还实现了continuous batching连续批处理请求结束一个就立刻补一个不用等整个批次跑完避免了GPU空转。另一个被低估的优势是它提供了OpenAI兼容的HTTP接口。这意味着你原来怎么调用外部API现在把base_url换成内网地址请求格式、返回格式几乎不用改。这一点在迁移阶段省了大量研发成本内部系统切过来基本是无痛的。2. 部署前的三件套算力、模型权重与运行环境2.1 算力评估先把账算清楚再下手算力规划是私有化部署里最容易拍脑袋踩坑的环节。很多团队上来就问“7B模型要什么显卡”但这个问题本身就不完整因为显存占用不只是模型权重还要叠加KV缓存和运行时开销。先说权重大账。模型权重显存大约等于参数量乘以每个参数占用的字节数。以主流FP16精度为例每个参数占2字节7B参数量模型权重约14GB13B模型约26GB70B模型约140GB。注意这只是权重还没算KV缓存。KV缓存大小跟模型结构、最大序列长度、并发数强相关。序列越长、并发越高KV缓存占用越大。此外还有CUDA运行上下文、激活值等开销实际占用通常高出权重一大截。基于我的经验一个7B对话模型最大上下文压在8192 token以内、并发10到20路的话单张24GB显存的卡能跑但要留足KV缓存预算显存利用率别拉满。如果是70B级模型单卡基本没戏至少需要两张80GB级别的卡做张量并行或者四张48GB级别的卡。做预算的时候我习惯按“模型权重每路请求约0.5到1GB KV缓存×目标并发数10%冗余”这个口径估算宁可多算一点也好过上线前发现塞不下。2.2 模型权重从哪来、怎么选格式模型获取这块主流渠道是开源模型仓库平台。下载时注意选safetensors格式的权重这种格式把模型参数分片存储安全性和加载速度都比老式格式好vLLM解析起来也更顺畅。下载完的目录结构一般是模型配置JSON、分词器文件和多个分片权重文件直接把整个目录路径传给vLLM即可不需要人工改文件。如果显存实在紧张可以考虑量化模型。vLLM原生支持AWQ、GPTQ以及FP8等量化格式。量化的本质是把权重从16位压到4位或8位用更少的显存换一些精度损失。我的建议是能上FP16或BF16就别量化生产环境优先保质量确实需要量化来塞进现有显卡优先试AWQ或FP8从评测集上肉眼抽查输出质量确认可接受再上线。2.3 环境依赖版本锁定是保命手段vLLM对运行环境要求不低最省心的方式是直接用官方预构建的Docker镜像。自己从源码编译不是不行但需要手动对齐GPU驱动的计算平台版本、Python版本、深度学习框架版本组合错了编译一次能折腾大半天。用官方镜像的好处是依赖已经完全打过架了拉下来启动就能跑。版本选择上我倾向用固定的版本号标签而不是latest因为推理引擎迭代快前两天还能跑的版本升级后启动参数或默认行为可能就变了。生产环境里“能用就别乱动”是我的基本原则。3. 动手部署把服务真正跑起来3.1 启动命令逐参数拆一遍假设权重已经放在内网服务器 /data/models/llm-7b-instruct 目录下启动服务只需要一条命令vllm serve /data/models/llm-7b-instruct \ --served-model-name internal-llm \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --tensor-parallel-size 1 \ --max-num-seqs 32这里每个参数都很关键我逐个解释。--served-model-name是暴露给调用方的模型名。它不一定要跟真实权重名一致我习惯起一个跟业务对得上的名字这样前端配置不暴露底层模型信息后续换底座模型也不需要改业务代码。--host 0.0.0.0表示绑定所有网卡这样内网其他机器才能访问。如果只在本机调试用 127.0.0.1 就好生产环境务必通过内网网关控制访问范围。--gpu-memory-utilization控制显存使用上限0.9表示最多吃90%显存。不要设成1.0显卡驱动、显示输出、推理引擎自身都要占一点显存设满容易启动即崩溃。--max-model-len限制最大序列长度。这里有个容易被忽略的关系这个值同时决定了KV缓存的预留上限设得太高会吃掉大量显存设得太低又会截断长文请求。先想清楚业务最长输入是多长再定这个值。--tensor-parallel-size是张量并行卡数。单卡就是1多卡跑大模型时设为显卡数量引擎会自动把模型切分到多张卡上。--max-num-seqs限制最大并发序列数。它跟显存、延迟直接相关我后面单独讲调优。3.2 用OpenAI兼容接口验证服务服务起来之后先别急着接入业务用命令行快速验证一下。vLLM默认提供OpenAI兼容的 /v1/chat/completions 接口直接拿curl测curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: internal-llm, messages: [{role: user, content: 用一句话介绍什么是大模型}], max_tokens: 256, temperature: 0.7 }返回的JSON结构和外部API几乎一模一样包含角色、内容、token用量等字段。业务侧迁移时只需要把请求的base_url从外部地址改成 http://内网地址:8000/v1 即可请求体基本不用动。我还习惯验证一下流式输出from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY) resp client.chat.completions.create( modelinternal-llm, messages[{role: user, content: 写一段300字的欢迎语}], max_tokens1024, streamTrue ) for chunk in resp: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end)流式返回对用户体验影响很大客服问答、内容生成这类场景基本都要流式长文本场景不流式的话用户得干等十几秒体验很糟糕。3.3 压测用数据说话别靠感觉服务跑通之后我建议立刻做一轮简单压测哪怕只是用脚本模拟并发也能暴露很多问题。我常用的方式是用Python的并发请求脚本同时发50个请求统计响应时间和吞吐量import time from concurrent.futures import ThreadPoolExecutor from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY) def one_request(i): start time.time() resp client.chat.completions.create( modelinternal-llm, messages[{role: user, content: f请简要回答第{i}个问题}], max_tokens512 ) return time.time() - start with ThreadPoolExecutor(max_workers50) as pool: t0 time.time() results list(pool.map(one_request, range(50))) total time.time() - t0 print(f总耗时: {total:.2f}s) print(f平均单请求耗时: {sum(results)/len(results):.2f}s)压测时重点看两类指标端到端平均耗时和吞吐量每秒生成多少token。如果并发稍微一高平均耗时就从2秒跳到10秒以上说明参数还有调整空间别急着上线。4. 调到生产可用吞吐、延迟与稳定性4.1 影响吞吐和延迟的几个旋钮vLLM最核心的调优轨迹其实就是平衡显存、并发和延迟三者关系。首先是--max-num-seqs。它决定了同时有多少个序列挤在GPU上。这个值调大吞吐量会上升但每个请求能分到的算力变少单个请求的响应会变慢。反过来调小响应快了但GPU可能吃不饱整体吞吐下降。我的经验是先按显存预算给一个初值然后压测观察一般7B模型在24GB卡上从16到32之间来回试找一个吞吐和延迟都能接受的平衡点。其次是--max-model-len。前面提过它控制序列长度上限实际上也充当了KV缓存的总量闸门。序列长度上限设得很大比如32768每个请求预留的缓存就多能同时跑的请求数反而变少。有些团队为了“能力上限”把语境设得很长结果并发上不去典型的捡了芝麻丢西瓜。先看业务真实需要多长的上下文再定这个值。最后是--gpu-memory-utilization。它决定了显存分配策略的激进程度。有些显存是留给KV缓存动态增长的设低了并发上不去设高了可能触发显存溢出。我个人习惯设0.85到0.9之间然后配合压测观察显存水位微调。4.2 多卡部署的细节与通信开销大模型单卡装不下时就得用张量并行把模型权重和计算切到多张卡上。启动时把 --tensor-parallel-size 设为卡数即可但有几个细节值得注意。卡间通信是张量并行的命脉。如果服务器支持高速卡间互联通信开销很小如果只靠PCIe总线通信每步推理都要跨卡同步数据性能会明显缩水。买机器或租卡时优先选带高速互联配置的机型多卡效率才起得来。多卡模式下KV缓存也在多卡间均匀分布每张卡负责一部分。这时候 max-num-seqs 的计算要以单卡显存为准不是总显存。比如两张80GB卡跑70B模型权重分两半各占70GB每张卡剩下的空间才是可用缓存加起来的并发上限并不等于单卡80GB容量的两倍。4.3 用守护进程和指标监控守住服务服务跑起来之后第一件要做的事是把它交给守护进程管理不能依赖人工盯着终端窗口。我习惯写一个systemd服务单元设置开机自启和异常重启[Unit] DescriptionvLLM Inference Server Afternetwork.target [Service] ExecStart/usr/bin/docker run --name vllm-server --gpus all \ -v /data/models:/data/models \ -p 8000:8000 \ vllm-image:latest \ --model /data/models/llm-7b-instruct \ --served-model-name internal-llm \ --gpu-memory-utilization 0.9 Restartalways RestartSec10 [Install] WantedBymulti-user.target监控方面vLLM内置了Prometheus指标接口可以采集吞吐量、显存使用、延迟分布等核心指标。我后续还搭了一个简单的看板专门盯三个数字GPU显存利用率、平均首token延迟、每分钟请求数。显存利用率长期贴着上限就要警惕KV缓存挤占首token延迟突然变高很可能是某个长上下文请求把算力吃光了。这些信号越早看到越能避免业务方先发现问题。5. 这些坑我基本都踩过5.1 启动后立刻崩溃报显存溢出最经典的坑。症状是服务启动几秒后直接退出打日志一看是CUDA out of memory。原因通常是 --gpu-memory-utilization 设得过高或者 --max-model-len 设得过大导致模型加载完加上KV缓存预分配直接爆显存。排查顺序我建议这样先把显存利用率降到0.8把 max-model-len 降到4096能启动再逐步往上加参数。如果这样还是溢出说明你的显存真的不够装这个模型要么换更大的卡要么考虑量化版本。5.2 请求都能响应但首token迟迟不出来服务不报错接口也通但用户发一句话要等好几秒才开始吐字。这个现象多半是某个长文本请求把计算队列堵住了。长序列生成的每一步计算量都远大于短序列如果混跑场景里有大量长上下文请求短请求就得排队等GPU空出来。解决办法分两层一是调低 max-num-seqs限制同时运行的请求数避免长序列把算力占满二是在业务层面做分级长文任务走单独的实例别跟实时代聊的请求混在一起。我自己后来就是把“实时问答”和“离线文档处理”拆成了两套服务问题才彻底解决。5.3 量化模型上线后效果明显变差为了省显存上了4位量化结果线上用户反馈“回答变笨了”一查评测指标确实掉了一截。量化本质是有损压缩4位量化对模型质量的影响比多数人预想的大尤其对逻辑推理、数学计算这类任务。如果必须量化我的做法是先跑一轮评测对比量化前后的输出挑影响小的方案同时准备一条后路——保留FP16权重版本只对轻量场景走量化实例重场景走精度更高的实例。生产环境里“效果为王”省下的显存如果换来用户流失得不偿失。5.4 OpenAI兼容也不是百分之百无缝兼容接口大大降低了迁移成本但细节上还是有差异的。比如某些外部API特有的字段vLLM不一定支持流式返回的分块格式不完全一致token计数字段在某些版本里会有细微差别。迁移前一定要把业务代码里用到的所有接口字段过一遍跑通之后再上线。5.5 服务升级后“变慢”了我遇到过换了新版本镜像后同样配置下吞吐反而下降的情况。查了半天发现是默认参数变了旧的启动命令在新版本里某些参数没显式指定采用了新的默认值。从那以后我每改一次镜像版本都会把所有启动参数重新核对一遍不依赖“应该没变”的感觉。升级之前先看变更记录升级之后先压测这两步省不掉。最后说一点个人体会。vLLM这套服务跑顺之后真正的运维压力其实不在引擎本身而在流量模型和组织协作。什么场景该走长上下文、什么场景必须限制并发、谁有权限调参数这些规则如果不在上线前定清楚后面就是无休止的救火。我踩过几次坑之后最大的收获不是学会了更多的启动参数而是把“上线前先做容量评估、上线后紧贴指标调优”这个流程固定成了团队习惯。如果能重来一遍我会在第一套服务上线前就多花两天时间把监控、守护进程和压测基线全部配齐而不是等服务出问题再回来补课。