★ FEATURED ARTICLE 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多轮调用、上下文动不动几万tokenSGLang的吞吐优势会让你觉得换得值。Ollama的强项是“零门槛”三个字。下载安装拉模型一条命令起服务底层甚至也能切到vLLM这类高性能后端。但默认情况下它的并发和吞吐能力远不如vLLM而且精细参数控制能力弱。适合个人电脑、十几人小团队内部试用或者作为模型管理工具存在。一旦业务开始有稳定并发就要考虑迁到vLLM。TensorRT-LLM是NVIDIA自家的优化方案能做到最低延迟、最高吞吐代价是模型需要编译优化装环境、排依赖的工程量大得多而且基本绑死在N卡生态。除非你的延迟要求极其苛刻、且有人力长期维护否则不建议作为第一选择。LMDeploy是国产框架里做得比较扎实的上手简单推理性能也不错对很多国产芯片和中文文档环境的适配更好。如果团队有国产化要求或者想要一个中文资料更友好的框架它可以和vLLM并列放进候选名单。框架核心优势典型场景上手难度生产推荐度vLLM生态最广、PagedAttention、OpenAI兼容绝大多数在线推理中等首选SGLang前缀缓存、长上下文调度强RAG、Agent、长文档问答中等强力候选Ollama一键部署、模型管理简单个人开发、小团队试用很低仅限轻量场景TensorRT-LLMNVIDIA极致优化、低延迟苛刻延迟要求的N卡环境高评估后选用LMDeploy国产化、易用、文档友好国产芯片/内部环境低合规备选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显卡就够。按当前公开市场的量级估算方案规格计费模式月成本量级适用场景方案A1×A100/A800 80G按量数万元量级短期测试、弹性突发方案B1×A100/A800 80G包年/预留数千到上万元量级长期在线服务方案C4×A10 24G包年与方案B接近多模型共存、开发环境方案D竞价实例按量约为按量两三成离线批处理、评测这个表格只是量级参考具体价格各平台会有差异。核心结论是在线服务长期跑一定要转包年或预留实例离线任务能接受中断就上竞价实例不确定业务量的时候按量先测一个月再决定。另外再推荐一个算账思路用“单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 --runtimedocker 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 22张卡做张量并行单卡放不下模型权重和KV Cache时必须用。粗粒度并行度不是越高越好通信开销会吃掉收益。--max-model-len 32768最大上下文长度。显存紧张就调低到16384空间立刻释放出来。--gpu-memory-utilization 0.9给显存留10%余量别设1.0。--enable-prefix-caching开启前缀缓存。RAG和Agent场景强烈建议开。--api-keyvLLM自带接口鉴权生产环境必须加。启动后先用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个并发连接。压测后重点看几个指标吞吐每秒生成多少tokenTPOT单Token生成时间每个token平均生成耗时错误率请求失败比例P99延迟最慢的那批请求耗时。我记录了一份典型数据2×A80G跑72B AWQmax-model-len32768并发数吞吐(tokens/s)P99 TPOT(ms)错误率8约1200900%16约18001300%32约24001800.2%64约29002601.8%从这个结果看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_percKV Cache使用率超过80%意味着快OOM了request_success成功率掉到99%以下要警觉request_queue排队请求数持续增高说明后端处理不过来了。告警规则我用表格整理一下方便直接抄告警项触发条件处理动作KV Cache使用率连续1分钟80%降低并发、缩短max-model-len、扩容请求错误率连续5分钟1%查看后端日志、检查GPU状态、重启容器GPU显存不足出现OOM事件降低max-num-seqs、换量化模型、加卡机器温度过高连续10分钟85°C检查风扇/散热、降低负载高可用层面如果预算允许我会用两台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_DEVICES0 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量化。我用的是autoawqpip 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但评判标准必须固定否则没法在不同模型版本之间对比。上线策略上我沿用这套流程新旧模型对比评测微调版和原版在评测集上跑一遍记录准确率、拒答率、字数控制等指标灰度发布在负载均衡层把5%到10%的流量切到新模型跑一两天观察业务反馈和错误率全量发布灰度没问题再逐步放大流量回滚预案模型目录带版本号比如/data/models/qwen7b-finetuned-v3容器镜像tag也对应版本。一旦发现异常改一行配置把流量切回旧模型目录重启容器即可。版本化是这一节里最容易被忽略的细节。没有版本号的模型目录上线一个月后你根本分不清线上跑的是哪个权重回滚也无从谈起。6. 生产环境常见问题排查实录6.1 显存OOM与KV Cache溢出OOMOut of Memory是GPU部署里最常见的故障没有之一。症状是vLLM日志直接报CUDA out of memory或者容器被操作系统杀掉服务静默挂掉。我排查OOM的顺序是固定的看nvidia-smi确认当前显存占用情况看vLLM启动日志确认KV Cache预留了多少显存看最近一次请求的上下文长度是不是有个别超长请求把显存吃爆了看max-num-seqs是不是并发batch过大。根据原因对症下药常见原因解决办法max-model-len设得过大调小到实际业务需要比如16384或8192并发请求数过高降低max-num-seqs限制同时处理的请求数gpu-memory-utilization设满降到0.85到0.9留出峰值余量模型太大换AWQ/GPTQ量化版或多卡tensor-parallel并行KV Cache使用率持续高位开启prefix caching、限制单请求长度6.2 首Token延迟高与吞吐上不去另一个高频问题是服务响应慢或者并发一上来吞吐就卡死。首Token延迟高我先看几个点是不是CUDA graph没有预热vLLM第一次请求会触发kernel编译之后才快。解决办法是启动后发一条短请求预热模型文件是不是放在HDD上权重加载慢会拖慢冷启动且服务启动后首次推理要等权重全进显存。模型挪到SSD上能明显改善是不是没开prefix cachingRAG场景下前缀重复计算会拖慢每个请求。开启后立竿见影最大上下文长度过大导致KV Cache碎片化调小max-model-len能减少碎片。吞吐上不去则优先检查并发和调度设置。max-num-seqs太小会导致GPU利用率不足调度不了足够多请求TP设置不合理则通信开销吃掉算力另外确认一下是不是没有开启Continuous Batching——vLLM默认开启但如果用了旧版本或某些参数配置可能退化成静态批处理。6.3 接口安全、限流与稳定性加固最后说安全。很多人部署完大模型第一件事是把接口地址发给前端开发这其实特别危险。没有鉴权的OpenAI兼容接口等于把服务裸奔在公网上谁都能来白嫖你的算力甚至可能被恶意灌垃圾请求打爆。我的加固方案是这样vLLM启动时加--api-key所有请求带Authorization: Bearer头外侧再加一层Nginx反向代理做IP白名单和请求体大小限制Nginx层限流比如每个IP每分钟最多60次请求防止突发流量打挂后端健康检查走独立路径/health放行/v1/chat/completions必须带鉴权日志里做脱敏处理不要把完整prompt打到日志里尤其注意用户上传的文档内容可能包含敏感信息。稳定性方面我建议业务侧配置合理的接口超时和重试机制。大模型生成本来就慢超时设太短容易误判失败设太长又会让请求堆积。我一般把超时设为生成时间上限10秒重试次数限制在1到2次避免雪崩。另外如果vLLM容器在运行中无故退出先看Docker日志再看系统日志journalctl -u docker多数情况下是OOM kill或者显卡驱动异常。这类问题排查时要有耐心别一看到报错就重启——很多故障重启后不复现反而更难定位。我个人这一年多带项目最大的体会是不要一开始就把架构搞得很复杂。GPU机器先单机、vLLM容器、挂上监控跑通一两个真实业务再谈扩容和微调上线。另一个小技巧是把所有的启动参数和环境变量收进一个.env文件用docker compose管理服务升级换版本只改一行镜像tag或一个环境变量省心很多。部署这件事稳定压倒一切先把这套工序跑熟再往深了做也不迟。
阅读完成 · 觉得有帮助？
