2026年再回头看，大模型服务器部署这件事已经从“能不能跑起来”彻底变成了“能不能稳定跑下去”。开源模型的能力一年比一年强，生态和文档也比两年前成熟得多，但真到自己给团队搭生产环境、选框架、对比云服务的时候，框架选型、云服务对比、生产级流程这三个词还是会卡住不少人。尤其当你面对的是72B级模型、多卡并行、内网私有化这些现实需求时，光靠照抄启动命令是远远不够的。

这篇内容是我过去一年实际部署多套大模型服务之后的落地记录，覆盖了推理框架怎么选、云GPU机器怎么买才不亏、从一台裸机到稳定对外服务要走的完整流程，以及微调产物怎么安全接到生产环境。适合刚拿到GPU预算的算法工程师、要自己动手搭私有化部署的运维同学，还有正在做技术选型的技术负责人参考。

1. 动手之前，先把部署目标想清楚

1.1 2026年的部署难题：模型好选，工程难做

我接触过不少团队，上来第一句话就是“我要部署一个大模型”，然后开始纠结用哪个框架。但实际聊下去就会发现，真正的问题往往不是模型，而是环境。

2026年这个时间点，开源模型的选择已经非常丰富：轻量级的7B、14B，到能力接近闭源一线的72B甚至更大规模；通用对话、代码、多模态各有各的好手。API调用也很便宜，很多场景完全没必要自己部署。那为什么还有这么多人坚持自建服务器？我总结下来无非三个原因：数据不能出域、长期成本想可控、需要深度定制。

数据不能出域是大多数企业私有化部署的硬理由。金融、医疗、政务、企业内部知识库，这些场景的数据级别决定了你根本不能把文本丢给外部API，只能在自己的机房或云主机上跑。长期成本方面，如果业务量稳定在每天几十万token，自建GPU服务器的边际成本会明显低于按量调用外部API。深度定制则更直接：微调、LoRA、领域知识注入，这些都需要你有模型权重和推理环境的完整掌控权。

但问题也随之而来——部署这件事不再是“git clone + pip install + 跑起来”就完事。你需要面对多卡并行怎么切、量化精度损失多少、并发上来以后KV Cache会不会爆、模型文件怎么在内网分发、服务挂了怎么恢复。这一整套问题，就是标题里说的“生产级流程”的分量所在。

1.2 场景决定一切：在线推理、离线批处理、微调训练是三条不同的路

我在帮团队做架构方案时，第一件事永远是逼他们把场景说清楚。因为不同场景对算力、框架、服务器的要求，差异大到可以让你前面的所有选型全部作废。

在线推理服务是大家最熟悉的场景：客服机器人、知识库问答、写代码助手、内容生成。这类服务7×24小时跑着，核心指标是首Token延迟、单Token生成速度、并发吞吐和稳定性。此时你需要的是高性能推理引擎，比如vLLM、SGLang，配合合理的并发控制。它关注的是怎么让显存被高效利用、怎么让多个请求交错不排队。

离线批量处理则完全不同：批量文档解析、知识抽取、数据标注、报表生成。这类任务可以排队、可以跑几个小时，但对单位时间的吞吐量有要求。此时你不一定需要最顶尖的推理引擎，Ollama、LMDeploy甚至直接用批量脚本都能胜任，关键是做好任务队列和失败重试。比如之前热词里提到的知识抽取框架OneKE，本质上就是这类离线任务，对吞吐的要求远高于对单请求延迟的要求。

微调训练又是一条独立的路。它吃显存、吃算力、吃多卡通信带宽，用的是LLaMA-Factory、MS Swift这类训练框架，和推理框架完全是两套体系。很多人混淆了“部署一个微调环境”和“部署一个推理服务”，结果买了一堆推理卡去跑训练，效率惨不忍睹。

另外还有一类就是多模态部署，涉及图像、语音、视频编码器，对特定的算子库和依赖版本有要求，不再是单单一个transformers就能搞定的。讯飞实时语音转写这类场景，前端适配、流式处理、推理引擎的流式接口都要单独设计。所以，第一步一定是定义场景，而不是问用什么框架。

1.3 预算、团队能力和合规约束，比框架更先定调

很多技术选型最后死掉，不是死在框架不够强，而是死在预算和运维能力上。

先说预算。GPU服务器的成本大头在显卡。一张A100/H100级别的卡，按量计费每小时就是几十元甚至上百元的量级，一个月跑下来轻松超过一台中配燃油车的月供。包年会有明显折扣，但需要你一次性投入；竞价实例便宜，但实例随时可能被回收，只适合离线任务。这些计费模式直接决定你的架构：是按量临时跑，还是包年撑长期服务，还是竞价实例扛批处理。

再说团队能力。如果团队里只有一位同时懂算法和Linux的工程师，我强烈建议不要一上来就上Kubernetes——那是给自己找罪受。单机Docker加systemd，再加一个简单的监控，就能覆盖大多数中小团队的90%需求。反过来说，如果有专职运维，多节点高可用、自动扩缩容才有意义。

还有合规约束。有些业务明确要求数据必须留在内网，这时候你连公有云的GPU机器都不能直连外网拉模型，必须走完整的内网分发流程：模型文件先下载到安全区，再拷贝到机房或VPC内。这个流程本身也是一大块工作。Dify接入本地大模型这类需求之所以火，正是因为企业既要本地模型的能力，又要通过Dify这种平台去管知识库和Agent，链条一下子就长了。

2. 推理框架选型：2026年该用什么

2.1 主流框架横向对比：vLLM、SGLang、Ollama、TensorRT-LLM

框架选型是所有部署工作的第一道分水岭。我2026年的结论是：生产环境基本被vLLM和SGLang统治，Ollama留在开发和个人场景，TensorRT-LLM偏极致优化，LMDeploy是国产方案里的稳妥选择。

vLLM是当前生态最广、社区最活跃的推理框架。它的核心优势是PagedAttention（显存分页管理）和Continuous Batching（连续批处理），前者大幅提升了显存利用率，后者让多个请求可以动态拼批，而不是傻等一个batch跑完。它对OpenAI接口的兼容做得最全，几乎所有上层应用都能直接对接。生产环境如果不知道选什么，选vLLM是大概率不会错的决定。

SGLang用RadixAttention做前缀缓存，对RAG这类长前缀重复场景收益非常明显；调度器做得更细，对长上下文和复杂推理任务的控制更强。前两年DeepSeek推理服务的走红也让SGLang的关注度上了一个台阶。如果你的场景是大量文档问答、Agent多轮调用、上下文动不动几万token，SGLang的吞吐优势会让你觉得换得值。

Ollama的强项是“零门槛”三个字。下载安装，拉模型，一条命令起服务，底层甚至也能切到vLLM这类高性能后端。但默认情况下它的并发和吞吐能力远不如vLLM，而且精细参数控制能力弱。适合个人电脑、十几人小团队内部试用，或者作为模型管理工具存在。一旦业务开始有稳定并发，就要考虑迁到vLLM。

TensorRT-LLM是NVIDIA自家的优化方案，能做到最低延迟、最高吞吐，代价是模型需要编译优化，装环境、排依赖的工程量大得多，而且基本绑死在N卡生态。除非你的延迟要求极其苛刻、且有人力长期维护，否则不建议作为第一选择。

LMDeploy是国产框架里做得比较扎实的，上手简单，推理性能也不错，对很多国产芯片和中文文档环境的适配更好。如果团队有国产化要求，或者想要一个中文资料更友好的框架，它可以和vLLM并列放进候选名单。

2.2 我的选型组合与决策逻辑

我不太喜欢把架构搞得很复杂，所以给团队做方案时用的是这样一套决策逻辑。

第一档，个人开发、内部demo、并发个位数：直接用Ollama跑，省心。模型用Qwen系列或者Llama系列的量化版本，一张消费级显卡就能带起来。这一档不追求吞吐，追求的是快速验证。

第二档，正式的在线服务、预计并发几十到几百：用vLLM，模型选择量化后单卡或双卡能扛住的规模，比如Qwen2.5-14B或72B的AWQ量化版。vLLM的OpenAI接口可以直接对接业务代码，也可以接Dify这类应用平台。这是我最推荐的“默认组合”。

第三档，大量RAG、Agent、长上下文场景：换SGLang。它在前缀缓存上省出来的算力，可能直接让你的响应速度快一倍，尤其多轮对话里每轮都在反复处理相同知识库上下文的时候，差距明显。

第四档，极致性能、纯N卡、团队有工程人力：TensorRT-LLM。我自己只在第三方评测环境里用过，做产品我不太愿意碰它，因为每次换模型都等于重新走一遍编译和调优，ROI不高。

还有一个原则：不要双线并行。看到一个新框架火了就马上切换，会让团队把大量时间花在迁移上。vLLM打底、SGLang作为长上下文特型方案、Ollama做开发调试，这个组合我自己用了一年多，基本覆盖了所有业务场景。

2.3 容易被忽略但决定成败的部署参数

很多人部署vLLM只知道填个模型路径，但真正影响服务稳定性的是一些不起眼的小参数。

量化精度是一切的起点。FP16的70B模型需要约140GB显存，两张80G卡刚好放下，但KV Cache就没多少空间了；换成AWQ 4bit量化，权重降到约35GB，单张80G卡就富余很多。代价是量化后模型会有一定的质量损失，通常不明显，但如果你做的是代码生成、数学推理这类任务，最好拿评测集实测对比一下。

max-model-len是显存规划的关键。它决定模型最大支持的上下文长度，而这个长度直接决定了KV Cache能占多大。上下文长度设得越大，能同时服务的并发数就越少。很多OOM问题不是模型太大，而是这个值设得太狠。

gpu-memory-utilization建议不要设满。我一般设0.85到0.93之间，留出一点显存给CUDA上下文、临时张量和偶发峰值，否则稍有波动就可能OOM。

max-num-seqs控制的是并发batch上限。设小了吞吐上不去，设大了显存扛不住。要根据压测结果慢慢调，而不是拍脑袋。

prefix caching在vLLM和SGLang里都建议开启。RAG场景下，用户问题不同但知识上下文相同，缓存能省掉大量重复计算。实测某些问答场景开启后吞吐能提升30%以上。

speculative decoding（投机解码）也是一项有价值的优化：用一个小模型先草拟多个token，大模型一次验证，从而加速生成。前提是你有额外显存来放草稿模型，且场景以批量或高并发为主。

3. 云服务器怎么选：从GPU型号到成本测算

3.1 选云GPU主机的五个关键指标

云GPU主机的选型，不少人只看“多少G显存”，但实际部署后你会发现，还有四个指标同样决定体验。

第一是GPU型号与显存。模型能跑起来靠的是显存容量，跑得快不快靠的是算力。以2026年常见的几款为例：A100/A800 80G适合大模型推理和中等规模微调；H20是不少云厂商主推的合规选择，算力不弱、显存大；L40S 48G是视频生成和推理的常见选择；A10 24G适合轻量模型和开发调试；消费级的4090 24G在小团队和个人项目里也很常见，但大规模生产要谨慎。还有昇腾系列这些国产芯片，生态越来越成熟，vLLM等主流框架已有官方适配。

第二是卡间互联带宽。当你需要多卡跑一个70B以上模型，Tensor Parallel并行策略会让显卡之间高频通信。A100/A800之间的NVLink带宽接近600GB/s，而PCIe只能到几十GB/s，差了一个数量级。我见过有人用四张PCIe互联的卡跑72B模型，推理速度比两张NVLink互联的卡还慢。所以预算里卡间互联的优先级，仅次于显存本身。

第三是内网带宽。模型文件动辄几十GB，从对象存储拉到GPU机器，如果内网带宽小，光下载模型就要一小时。分布式推理时不同机器之间还要同步中间结果，网络一慢就是灾难。

第四是云盘IOPS。很多人忽略这一点。模型加载、KV Cache写入刷盘、日志落盘，全都依赖云盘性能。模型放高IOPS的SSD上，加载时间能从10分钟降到2分钟；放普通HDD上，光启动就能让人崩溃。

第五才是计费模式：按量、包年、竞价实例的取舍，直接关系你每个月的成本，我下面详细算一笔账。

3.2 主流云服务对比与真实成本测算

云厂商的选择维度，不只是价格。我评估过阿里云、腾讯云、华为云、AWS、Azure这几家主流平台，给团队的参考维度是这么几条：

• GPU型号覆盖度：A100/H100/L40S/昇腾这些算力卡是否齐全，能不能支撑后续扩容；
• 国产芯片选项：有国产化合规需求时，昇腾这类方案是否成熟，主流框架适配度如何；
• 计费灵活性：按量、包年、竞价实例的搭配是否方便，能不能自动释放；
• 运维生态：监控、安全组、容器服务、对象存储这些周边是否好用；
• 出海场景：如果你的业务部署在海外，AWS和Azure的全球覆盖优势明显。

具体到成本测算，我用一个真实的70B模型部署来算。模型选用Qwen2.5-72B的AWQ量化版，权重约35GB，推理时KV Cache预留20GB到30GB，总计约65GB，所以一张80G显卡就够。按当前公开市场的量级估算：

这个表格只是量级参考，具体价格各平台会有差异。核心结论是：在线服务长期跑，一定要转包年或预留实例；离线任务能接受中断，就上竞价实例；不确定业务量的时候，按量先测一个月再决定。

另外再推荐一个算账思路：用“单token成本”来评估你的部署值不值。拿月总成本除以月输出token数，得到每个token的部署成本，再去和外部API价格对比。如果明显更低，自建的意义就成立了。

3.3 网络、存储、安全组与远程运维细节

选好机器之后，网络和安全组配置是很多人踩坑的地方。

安全组原则是最小开放。GPU机器上只开放必需的端口，比如推理服务的8000端口只允许反向代理IP访问，SSH端口只允许公司IP访问，数据库端口一律不对外。API服务不要直接暴露公网。前端业务通过Nginx或其他网关转发到内网的vLLM服务，这样既安全又方便做限流和审计。

模型文件一定要放在高性能云盘或SSD数据盘。大模型加载时要把几百GB权重读进显存，磁盘IOPS低的话，加载耗时能让人怀疑服务器是不是坏了。有条件的话，把模型放在NVMe SSD上，加载时间会明显缩短。

远程运维方面，我个人的习惯是不依赖公网IP暴露。比如你在家里想连回办公室或IDC机房的GPU机器查看训练日志，可以用frp这类内网穿透工具，把SSH端口或可视化面板端口透传出来。这种做法不是把服务暴露到公网，而是给自己留一条管理通道，配好访问认证之后，远程维护会方便很多——尤其是半夜接到告警又没法立刻到机房的时候，这条通道能救急。国内也有不少云厂商提供成熟的运维堡垒机方案，团队有条件可以优先用堡垒机。

容器镜像和模型仓库也建议实现内网化。生产环境里，镜像从内网registry拉取，模型文件从内网对象存储或NAS加载，依赖包从内网pip源安装。这样既避免公网流量费用，也符合数据合规的硬性要求。我看到很多团队部署失败，最后查明原因居然是下载模型超时——换成内网分发之后，这个问题直接消失。

4. 生产级部署流程：从裸机到可用服务

4.1 环境初始化：驱动、容器运行时与模型分发

拿到一台全新的GPU云主机，我是按这个顺序初始化的：

第一步，检查GPU驱动。跑一句nvidia-smi，看能不能正常输出显卡信息，确认驱动版本和CUDA版本。如果是全新系统，大概率需要先安装NVIDIA驱动和CUDA toolkit。这里有个经验：GPU机器上尽量用Docker跑大模型，而不是直接在宿主机的Python环境里装。因为推理框架对CUDA、PyTorch、Transformer的版本组合非常敏感，直接装在宿主机上，升级一次驱动可能就把环境搞坏。Docker镜像把整个依赖链固化下来，部署和迁移都干净很多。

第二步，装NVIDIA Container Toolkit，让Docker能访问GPU：

# Ubuntu/Debian系安装nvidia-container-toolkit distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker

第三步，配置Docker默认使用NVIDIA运行时：

sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker # 验证 docker run --rm --gpus all nvidia/cuda:12.3.1-base-ubuntu22.04 nvidia-smi

第四步，准备模型文件。生产环境下载模型，我推荐优先用ModelScope（魔搭）而不是直接从Hugging Face拉。一是国内网络稳定，二是支持命令行工具，方便做脚本化和内网分发：

pip install modelscope modelscope download --model Qwen/Qwen2.5-72B-Instruct-AWQ --local_dir /data/models/Qwen2.5-72B-Instruct-AWQ

下载完成后，模型目录结构就是标准的Hugging Face格式，包含config.json、权重文件、tokenizer等。如果公司有内网对象存储，把这整个目录传到内网，其他机器直接内网拉取，速度比公网快得多。

4.2 用vLLM拉起推理服务：Docker命令逐参数解读

环境就绪后，我用vLLM的官方Docker镜像启动推理服务。下面这条命令是我在2×A100 80G机器上跑Qwen2.5-72B-Instruct-AWQ时的完整写法：

docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-72B-Instruct-AWQ \ --served-model-name qwen72b \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 64 \ --enable-prefix-caching \ --api-key sk-token-xxx

逐参数解释一下关键点：

• --tensor-parallel-size 2：2张卡做张量并行，单卡放不下模型权重和KV Cache时必须用。粗粒度并行度不是越高越好，通信开销会吃掉收益。
• --max-model-len 32768：最大上下文长度。显存紧张就调低到16384，空间立刻释放出来。
• --gpu-memory-utilization 0.9：给显存留10%余量，别设1.0。
• --enable-prefix-caching：开启前缀缓存。RAG和Agent场景强烈建议开。
• --api-key：vLLM自带接口鉴权，生产环境必须加。

启动后先用curl验证服务是否正常：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-token-xxx" \ -d '{ "model": "qwen72b", "messages": [{"role": "user", "content": "你好，介绍一下你自己"}], "max_tokens": 256 }'

返回正常的OpenAI格式结果就说明服务通了。为了生产级稳定性，我还会把容器纳入 systemd 管理，设置开机自启和异常自动拉起，或者用 docker compose 管理环境变量和启动参数，方便以后升级时只改一行镜像版本。

4.3 压测与容量规划：用数据决定并发上限

服务跑起来只是开始，我得知道它到底能扛多少并发、输出速度多少，才能决定线上给业务分配多少流量。压测是这步的关键。

我用的是oha这个开压测工具，简单、输出清晰：

oha -z 60s -c 32 -m POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-token-xxx" \ -d '{"model":"qwen72b","messages":[{"role":"user","content":"写一段产品介绍"}],"max_tokens":128}' \ http://localhost:8000/v1/chat/completions

-z 60s表示持续压测60秒，-c 32表示32个并发连接。压测后重点看几个指标：

• 吞吐：每秒生成多少token；
• TPOT（单Token生成时间）：每个token平均生成耗时；
• 错误率：请求失败比例；
• P99延迟：最慢的那批请求耗时。

我记录了一份典型数据（2×A80G跑72B AWQ，max-model-len=32768）：

从这个结果看，32并发以内是比较舒适的工作区间，64并发开始错误率上升，说明已经接近上限。容量规划的经验公式是：预估线上峰值QPS乘以单请求平均生成token数，得到需要的吞吐能力，再除以0.7，留30%余量。比如线上预测峰值5 QPS、平均每个请求生成200 token，需要1000 tokens/s的吞吐，那么这个服务至少得按能跑1400 tokens/s来规划，也就是并发控制在16以内比较安全。

4.4 监控告警与服务高可用

生产服务不能“跑起来就不管”。vLLM内置了Prometheus指标接口，默认通过/metrics暴露。我配合Prometheus加Grafana搭了一套基础监控。

监控里我重点盯这几个指标：

• gpu_utilization和显存占用：确认GPU没有被闲置或打满；
• kv_cache_usage_perc：KV Cache使用率，超过80%意味着快OOM了；
• request_success：成功率，掉到99%以下要警觉；
• request_queue：排队请求数，持续增高说明后端处理不过来了。

告警规则我用表格整理一下，方便直接抄：

高可用层面，如果预算允许，我会用两台GPU机器，前面放一个负载均衡器：Nginx做轮询或最少连接，后端分别指到两台机器的vLLM服务。这样单台故障时流量自动切到另一台，业务无感。两台机器之间用健康检查接口持续探测，比如每10秒请求一次/health。

至于Kubernetes，我的判断是：不到多模型、多团队、需要按流量自动扩缩容的程度，不要主动上。单机加负载均衡就足够支撑绝大多数中小团队。K8s带来的运维复杂度，不是所有人都能消化得起的。

5. 微调之后的模型，怎么安全接到生产

5.1 主流微调工具选型与产物格式说明

部署不只是把开源原版模型跑起来，很多业务最终要走到微调这一步。工具选型直接影响后面部署的顺畅程度。

当前主流微调工具里，LLaMA-Factory是我最常用也最推荐的一款。它把LoRA、QLoRA、全参微调、DPO这些常见方案都封装好了，命令行和WebUI都有，中文资料丰富，新手也能快速上手。MS Swift是魔搭生态里的微调工具，和ModelScope的数据集、模型库结合很紧密，国产化环境下用起来很顺手。Axolotl更偏研究型配置，灵活度高但上手门槛也高。Unsloth的优势是速度和显存优化都做得很好，适合在意训练耗时的场景。

微调完的产物格式需要提前想清楚。常用的几种：

• HF格式全量权重：微调后直接导出整个模型目录，可以加载到vLLM里跑；
• LoRA Adapter：只保存增量权重，部署时合并到基座；
• GGUF格式：给llama.cpp和Ollama用的量化格式，适合单机CPU/混合推理；
• AWQ/GPTQ量化格式：推理性能好，适合vLLM、SGLang生产部署。

如果训练时只保存了LoRA adapter，部署前必须先合并成完整权重，否则没法直接喂给vLLM。

5.2 LoRA合并、量化转换与权重验证

用LLaMA-Factory导出合并后的模型，命令大致是：

CUDA_VISIBLE_DEVICES=0 python -m llamafactory.cli export \ --model_name_or_path /data/models/Qwen2.5-7B \ --adapter_name_or_path /data/train/output_lora \ --template qwen \ --finetuning_type lora \ --export_dir /data/models/Qwen2.5-7B-finetuned \ --export_size 4 \ --export_legacy_format false

这条命令的作用是把基座模型和LoRA adapter合并成一个完整的HF格式模型目录。合并之后，再用vLLM加载验证一遍：跑几个训练集里的问题，看输出是否符合预期，同时确认--max-model-len、量化配置等参数正常。

如果生产环境显存紧张，合并后的模型再做AWQ量化。我用的是autoawq：

pip install autoawq python -m awq.entry \ --model_path /data/models/Qwen2.5-7B-finetuned \ --quant_path /data/models/Qwen2.5-7B-finetuned-AWQ \ --quant_method awq \ --bits 4

量化完成后，用vLLM加载AWQ模型再跑一轮评测，确认质量损失在可接受范围。GGUF转换则用llama.cpp仓库里的convert.py脚本，转换完喂给Ollama即可。这里有一个核心经验：每次转换都重新做一次质量评测，不要假设转换是无损的。

5.3 上线前评测、灰度与回滚策略

微调模型上线前，我坚持要做一套标准化的评测流程。评测集从业务真实问题里抽100到200条，覆盖主要场景和边界情况，比如长文本、多轮追问、模糊提问、敏感话题等。打分方式可以是人工评分，也可以用LLM judge，但评判标准必须固定，否则没法在不同模型版本之间对比。

上线策略上，我沿用这套流程：

1. 新旧模型对比评测：微调版和原版在评测集上跑一遍，记录准确率、拒答率、字数控制等指标；
2. 灰度发布：在负载均衡层把5%到10%的流量切到新模型，跑一两天，观察业务反馈和错误率；
3. 全量发布：灰度没问题，再逐步放大流量；
4. 回滚预案：模型目录带版本号，比如/data/models/qwen7b-finetuned-v3，容器镜像tag也对应版本。一旦发现异常，改一行配置把流量切回旧模型目录，重启容器即可。

版本化是这一节里最容易被忽略的细节。没有版本号的模型目录，上线一个月后你根本分不清线上跑的是哪个权重，回滚也无从谈起。

6. 生产环境常见问题排查实录

6.1 显存OOM与KV Cache溢出

OOM（Out of Memory）是GPU部署里最常见的故障，没有之一。症状是vLLM日志直接报CUDA out of memory，或者容器被操作系统杀掉，服务静默挂掉。

我排查OOM的顺序是固定的：

1. 看nvidia-smi，确认当前显存占用情况；
2. 看vLLM启动日志，确认KV Cache预留了多少显存；
3. 看最近一次请求的上下文长度，是不是有个别超长请求把显存吃爆了；
4. 看max-num-seqs，是不是并发batch过大。

根据原因对症下药：

6.2 首Token延迟高与吞吐上不去

另一个高频问题是：服务响应慢，或者并发一上来吞吐就卡死。

首Token延迟高，我先看几个点：

• 是不是CUDA graph没有预热？vLLM第一次请求会触发kernel编译，之后才快。解决办法是启动后发一条短请求预热；
• 模型文件是不是放在HDD上？权重加载慢会拖慢冷启动，且服务启动后首次推理要等权重全进显存。模型挪到SSD上能明显改善；
• 是不是没开prefix caching？RAG场景下前缀重复计算会拖慢每个请求。开启后立竿见影；
• 最大上下文长度过大导致KV Cache碎片化？调小max-model-len能减少碎片。

吞吐上不去，则优先检查并发和调度设置。max-num-seqs太小会导致GPU利用率不足，调度不了足够多请求；TP设置不合理则通信开销吃掉算力；另外确认一下是不是没有开启Continuous Batching——vLLM默认开启，但如果用了旧版本或某些参数配置，可能退化成静态批处理。

6.3 接口安全、限流与稳定性加固

最后说安全。很多人部署完大模型，第一件事是把接口地址发给前端开发，这其实特别危险。没有鉴权的OpenAI兼容接口等于把服务裸奔在公网上，谁都能来白嫖你的算力，甚至可能被恶意灌垃圾请求打爆。

我的加固方案是这样：

1. vLLM启动时加--api-key，所有请求带Authorization: Bearer头；
2. 外侧再加一层Nginx反向代理，做IP白名单和请求体大小限制；
3. Nginx层限流，比如每个IP每分钟最多60次请求，防止突发流量打挂后端；
4. 健康检查走独立路径：/health放行，/v1/chat/completions必须带鉴权；
5. 日志里做脱敏处理，不要把完整prompt打到日志里，尤其注意用户上传的文档内容可能包含敏感信息。

稳定性方面，我建议业务侧配置合理的接口超时和重试机制。大模型生成本来就慢，超时设太短容易误判失败；设太长又会让请求堆积。我一般把超时设为生成时间上限+10秒，重试次数限制在1到2次，避免雪崩。

另外，如果vLLM容器在运行中无故退出，先看Docker日志，再看系统日志journalctl -u docker，多数情况下是OOM kill或者显卡驱动异常。这类问题排查时要有耐心，别一看到报错就重启——很多故障重启后不复现，反而更难定位。

我个人这一年多带项目最大的体会是，不要一开始就把架构搞得很复杂。GPU机器先单机、vLLM容器、挂上监控，跑通一两个真实业务再谈扩容和微调上线。另一个小技巧是，把所有的启动参数和环境变量收进一个.env文件，用docker compose管理服务，升级换版本只改一行镜像tag或一个环境变量，省心很多。部署这件事，稳定压倒一切，先把这套工序跑熟，再往深了做也不迟。