1. 大模型服务器部署到底在解决什么问题把大模型跑起来这件事2026 年和两年前已经完全不是一个难度级别了。2024 年的时候很多人还在折腾怎么在消费级显卡上把 7B 模型量化到 4bit 勉强跑通到了现在企业侧的需求早就变成了我要在自有服务器上稳定支撑日均百万级 token 的推理请求还要控制单次调用成本。这个跨度非常大涉及的东西从显卡选型、推理框架、云服务计费模型一直到生产环境的灰度发布和监控告警。我自己是从 2023 年开始接触大模型部署的那时候帮一个做法律文书检索的团队搭过一套本地推理服务用的是两张 3090 跑 ChatGLM3-6BQPS 大概只有个位数稍微来点并发就排队排到天荒地老。后来陆续做过电商客服机器人、企业内部知识库问答、代码补全助手这几个项目踩过的坑从 CUDA 版本冲突到显存碎片化导致 OOM基本上能遇到的都遇到了。所以这篇内容我打算把整个部署链路从头到尾捋一遍不讲虚的就讲实际落地时每个环节该怎么选、为什么这么选、选错了会怎样。这篇文章适合几类人看一是刚入行的大模型应用开发工程师需要把模型从 notebook 搬到生产环境二是中小团队的技术负责人要在预算有限的情况下做出合理的架构决策三是有一定运维基础、想了解大模型部署特殊性的后端工程师。不管你是哪种我都会尽量把为什么讲清楚而不是只给一堆命令让你复制粘贴。核心关键词会贯穿全文大模型服务器部署、推理框架、云服务、生产级流程。这四个词基本上就是整条链路的四个支柱缺一个都跑不起来。2. 推理框架选型别只看 benchmark 排名2.1 主流推理框架的真实定位差异2026 年市面上能用的推理框架比两年前多了不少但真正在生产环境经得起考验的其实就那么几个。我把它们分成三个梯队来说。第一梯队是vLLM和SGLang。vLLM 的 PagedAttention 机制到现在依然是显存管理的标杆方案它的核心思路是把 KV Cache 按页来管理就像操作系统管理内存页一样避免了传统方案中因为序列长度不一致导致的显存浪费。实测下来同样的 A100 80GvLLM 能比朴素 HuggingFace 推理多扛 3 到 5 倍的并发。SGLang 则在结构化生成和前缀缓存上做得更激进如果你的场景有大量共享 system prompt 的请求SGLang 的 RadixAttention 能带来非常明显的吞吐提升。第二梯队是TensorRT-LLM和TGI。TensorRT-LLM 的性能上限确实高但它的编译流程太重量级了每次换模型或者换精度都要重新编译 engine调试成本很高。TGI 是 HuggingFace 出的生态整合好但自定义程度不如 vLLM遇到特殊需求容易被框架限制住。第三梯队就是各种轻量级方案比如llama.cpp、Ollama、MLC-LLM。这些更适合本地开发、边缘设备或者个人使用场景生产环境高并发下基本扛不住。框架核心优势适用场景主要限制vLLM显存利用率高社区活跃通用生产部署自定义算子支持有限SGLang前缀缓存强结构化输出好多轮对话、Agent生态相对年轻TensorRT-LLM极致性能固定模型大规模服务编译复杂灵活性差TGI开箱即用快速验证、中小规模深度定制困难llama.cpp资源占用低本地开发、边缘并发能力弱2.2 选型时最容易忽略的三个维度很多人选框架只看吞吐量 benchmark但实际生产中最容易出问题的往往不是吞吐。第一个是首 token 延迟TTFT。流式输出场景下用户感知最明显的就是从发送请求到看到第一个字的时间。vLLM 在开启 chunked prefill 之后TTFT 能控制在几百毫秒级别但如果你的请求普遍很长比如 RAG 场景拼接了大量上下文TTFT 可能会飙到好几秒。这时候就需要考虑 prefix caching 或者把长上下文做预压缩。第二个是显存碎片化。这个问题在长时间运行后特别明显。我遇到过一次服务跑了三天之后开始间歇性 OOM重启就好但过几天又出现。后来排查发现是不同长度的请求交替进来导致 KV Cache 的块分配出现碎片。vLLM 的gpu_memory_utilization参数设得太高比如 0.95就容易触发这个问题调到 0.85 到 0.9 之间会稳很多。第三个是模型格式兼容性。有些框架对量化格式的支持是有坑的比如 AWQ 和 GPTQ 在不同框架上的表现差异很大。我建议在选型阶段就把你实际要用的模型和量化方案跑一遍别等到上线了才发现不支持。2.3 一个实际的选型决策流程我一般会按这个顺序来决策先确认模型是否被框架官方支持优先选支持列表里有的用真实业务数据做压测重点看 P99 延迟而不是平均延迟检查框架的并发调度策略是否匹配你的请求模式评估运维复杂度包括日志、监控、版本升级最后才看极限吞吐提示不要用框架官方给的 benchmark 数据直接做决策那些数据通常是在理想条件下跑出来的。一定要用你自己的数据和请求模式来测。3. 云服务对比算力成本的真实账本3.1 自建 vs 云端的决策边界这个问题我被问过无数次。简单说如果你的推理需求是稳定的、可预测的而且规模足够大自建服务器长期来看更划算。但如果需求波动大或者你还在验证阶段云服务明显更合适。算一笔实际的账。以 A100 80G 为例自建一台 8 卡服务器的硬件成本大概在 80 到 100 万人民币加上机房、电力、运维三年总拥有成本大概在 150 万左右。折算下来每卡每小时大约 7 块钱。而云服务上 A100 的按需价格普遍在每小时 15 到 30 块之间包年包月能降到 8 到 12 块。所以如果你的 GPU 利用率能稳定在 60% 以上自建是有优势的如果利用率低于 40%云端更划算。但这里有个隐藏成本很多人不算运维人力。自建需要有人管驱动、管 CUDA 版本、管硬件故障、管散热。这些事情的隐性成本很高尤其是小团队一个运维工程师的年薪可能就够你租好几年的云服务了。3.2 主流云服务商的差异化定位国内的话阿里云、腾讯云、华为云在 GPU 实例上各有侧重。阿里云的 ECS GN 系列生态最完整文档和工具链都比较成熟腾讯云的 GPU 实例在网络带宽上有优势适合需要大量数据传输的场景华为云的昇腾系列在国产化替代需求下有一定市场。海外的话AWS 的 P4/P5 实例、GCP 的 A3 系列、Azure 的 ND 系列都是常见选择。另外还有一些专门做 GPU 云的服务商价格上更有竞争力但稳定性和生态支持需要自己评估。维度自建云服务前期投入高低长期成本利用率高时更优利用率低时更优弹性扩展差好运维复杂度高低数据可控性完全可控依赖服务商适合阶段稳定大规模验证期、波动期3.3 成本优化的几个实操手段抢占式实例是个好东西价格通常是按需的 30% 到 50%但随时可能被回收。适合跑离线推理、批量任务、模型微调这些可以中断的工作负载。我一般会用它来做模型量化和评测跑之前做好 checkpoint被回收了也能续上。预留实例适合长期稳定的推理服务折扣力度大但灵活性差。如果你的服务已经跑了一段时间流量曲线比较稳定可以考虑把一部分按需实例转成预留。自动伸缩是控制成本的关键。大模型的冷启动时间比较长加载模型到显存可能要几分钟所以伸缩策略不能太激进。我一般会设置一个最小实例数保证基础流量然后根据 GPU 利用率和请求队列长度来触发扩容缩容则要设置足够的冷却时间。注意自动伸缩的触发指标不要只看 CPU 或 GPU 利用率大模型推理的瓶颈往往在显存带宽或者 KV Cache 上。建议用请求队列等待时间作为主要伸缩指标。4. 生产级部署流程从裸机到稳定服务4.1 环境准备与基础依赖拿到一台新的 GPU 服务器第一件事不是急着装框架而是把基础环境理清楚。我见过太多因为驱动版本和 CUDA 版本不匹配导致的问题排查起来非常浪费时间。标准流程是这样的先确认显卡型号和驱动版本用nvidia-smi看。然后根据你要用的框架确定需要的 CUDA 版本。vLLM 目前主流版本需要 CUDA 12.1 以上SGLang 类似。CUDA 版本和驱动版本之间有对应关系驱动版本太低的话需要先升级驱动。# 查看显卡和驱动信息 nvidia-smi # 查看 CUDA 版本 nvcc --version # 查看 Python 版本 python3 --versionPython 环境我强烈建议用 conda 或者 uv 来管理不要用系统自带的 Python。不同项目之间的依赖冲突在大模型领域特别常见隔离环境是必须的。# 用 conda 创建独立环境 conda create -n llm-serving python3.11 -y conda activate llm-serving # 安装 vLLM pip install vllm # 或者安装 SGLang pip install sglang[all]4.2 模型下载与格式转换模型下载看起来简单但有几个坑要注意。第一是下载源的选择国内访问 HuggingFace 有时候不稳定可以用镜像站或者提前把模型下载到本地再传上去。第二是模型格式原始权重、量化权重、编译后的 engine 文件不同框架需要不同格式。# 用 huggingface-cli 下载模型 pip install huggingface_hub huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir ./models/qwen2.5-7b # 如果网络不稳定可以用 hf_transfer 加速 pip install hf_transfer HF_HUB_ENABLE_HF_TRANSFER1 huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir ./models/qwen2.5-7b模型文件通常比较大7B 的模型 fp16 格式大概 14GB70B 的模型大概 140GB。下载之前先确认磁盘空间够不够另外建议把模型放在 SSD 上加载速度会快很多。4.3 推理服务启动与参数调优以 vLLM 为例启动一个生产级的推理服务大概是这样python -m vllm.entrypoints.openai.api_server \ --model ./models/qwen2.5-7b \ --served-model-name qwen2.5-7b \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.88 \ --max-model-len 8192 \ --max-num-seqs 64 \ --enable-prefix-caching \ --disable-log-requests几个关键参数解释一下。tensor-parallel-size是张量并行的卡数单卡就设 1多卡根据实际情况设。gpu-memory-utilization控制显存使用比例前面说过不要设太高0.85 到 0.9 比较稳。max-model-len是最大上下文长度设得越大占用的显存越多要根据实际需求来。max-num-seqs是最大并发序列数这个值直接影响吞吐和延迟的平衡。enable-prefix-caching在多轮对话场景下非常有用能把共享前缀的 KV Cache 复用起来。disable-log-requests在生产环境建议开启否则日志量会非常大。4.4 反向代理与负载均衡推理服务本身通常不直接暴露给外部前面会加一层反向代理。Nginx 是最常见的选择主要做几件事SSL 终止、请求限流、负载均衡、超时控制。upstream llm_backend { server 127.0.0.1:8000; server 127.0.0.1:8001; keepalive 32; } server { listen 443 ssl; server_name llm.example.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location /v1/ { proxy_pass http://llm_backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_read_timeout 300s; proxy_buffering off; } }大模型推理的响应时间比较长尤其是生成长文本的时候proxy_read_timeout要设大一点否则容易断连。proxy_buffering off对流式输出很关键开启缓冲会导致 token 不能实时推送给客户端。4.5 监控与告警体系生产环境没有监控就是在裸奔。大模型服务需要关注的指标和普通 Web 服务不太一样。核心指标包括GPU 利用率、显存使用率、请求队列长度、首 token 延迟、每 token 生成时间、吞吐量tokens/s、错误率。这些指标可以用 Prometheus 采集vLLM 和 SGLang 都内置了 metrics 接口。# prometheus 配置示例 scrape_configs: - job_name: vllm static_configs: - targets: [localhost:8000] metrics_path: /metrics scrape_interval: 15s告警规则我一般会设这几条显存使用率超过 95% 持续 5 分钟、请求队列长度超过阈值持续 2 分钟、P99 首 token 延迟超过 3 秒、错误率超过 1%。这些阈值要根据实际业务来调整不能照搬。5. 常见问题与排查技巧实录5.1 显存相关问题OOM显存溢出是最常见的问题。排查思路是这样的先看是加载模型时就 OOM还是运行一段时间后 OOM。加载时 OOM 通常是模型太大或者gpu_memory_utilization设太高解决办法是降低这个值或者用量化模型。运行时 OOM 多半是并发太高或者请求太长需要调整max-num-seqs和max-model-len。还有一种隐蔽的情况是显存碎片化。表现是nvidia-smi看显存还有剩余但就是分配不出来。这种情况重启服务能暂时解决长期方案是降低gpu_memory_utilization并开启--enforce-eager模式会牺牲一些性能但更稳定。5.2 性能不达预期如果吞吐量比预期低很多按这个顺序排查检查 GPU 利用率如果低于 70%说明瓶颈不在计算检查是否有 CPU 瓶颈特别是 tokenizer 处理大量请求时检查网络带宽模型并行时卡间通信可能是瓶颈检查请求模式长请求和短请求混合会降低整体效率我遇到过一次吞吐量只有理论值的三分之一最后发现是 tokenizer 在多线程下有问题换成了 fast tokenizer 之后直接翻倍。5.3 服务稳定性问题服务跑着跑着挂了或者响应越来越慢这类问题通常和内存泄漏或者资源没释放有关。Python 的 GC 在大模型场景下有时候不太给力可以试试手动触发 GC 或者调整 GC 阈值。另一个常见原因是日志写满了磁盘。大模型服务的日志量很大尤其是开了请求日志之后。建议用 logrotate 做日志轮转或者直接输出到标准输出由容器运行时管理。问题现象可能原因排查方法解决方案加载时 OOM模型太大/显存设置过高看加载日志量化模型/降低利用率运行时 OOM并发过高/请求过长看请求队列调整并发和长度限制吞吐低CPU 瓶颈/tokenizer 慢看 CPU 利用率换 fast tokenizer响应变慢显存碎片/内存泄漏长时间监控重启/调整 GC服务崩溃磁盘满/驱动问题看系统日志日志轮转/升级驱动5.4 几个独家避坑技巧技巧一模型加载的时候用--load-format指定 safetensors 格式比 bin 格式快很多而且更安全。技巧二如果用的是多卡张量并行确保卡之间的 NVLink 或者 PCIe 带宽足够。我见过用 PCIe 4.0 x8 跑 4 卡并行的通信开销直接把性能吃掉了大半。技巧三生产环境一定要做健康检查不只是检查端口通不通还要实际发一个推理请求验证模型能正常响应。有些时候服务进程还在但模型已经挂了端口检查发现不了。技巧四版本升级要灰度。推理框架的版本迭代很快新版本可能引入性能回归或者行为变化。我一般会保留一个稳定版本新版本先在测试环境跑一周再上生产。技巧五把模型的 warmup 做好。服务刚启动时第一次推理会特别慢因为要编译 CUDA kernel、初始化各种缓存。可以在启动后自动发几个预热请求把常用路径都跑一遍。6. 从部署到运维的持续优化部署上线只是开始后面的持续优化才是真正拉开差距的地方。我自己的经验是一个推理服务上线后至少还有 30% 到 50% 的性能优化空间可以挖。最直接的优化手段是量化。从 fp16 降到 int8 或者 int4显存占用能减少一半到四分之三吞吐量通常能提升 1.5 到 2 倍。但量化会带来精度损失需要在自己的业务数据上评估。我一般会用 AWQ 或者 GPTQ 做权重量化对精度影响相对可控。另一个方向是请求调度优化。把长请求和短请求分开处理短请求优先响应能显著改善用户体验。vLLM 的 continuous batching 已经做了很多工作但在应用层还可以做更细粒度的控制。还有就是缓存策略。对于重复性高的查询可以在应用层加一层语义缓存相同或者相似的问题直接返回缓存结果不用每次都走模型推理。这个在客服场景下效果特别明显能减少 40% 以上的推理请求。最后再分享一个小技巧定期做压测但不要用固定的测试集。我一般会从生产日志里采样真实的请求分布来做压测这样测出来的数据才有参考价值。固定测试集跑久了会产生过拟合掩盖真实问题。这个领域变化很快框架在迭代硬件在更新云服务的计费模型也在变。保持关注定期重新评估自己的技术选型比一次性做一个完美的决策更重要。我在实际项目中的体会是没有最好的方案只有最适合当前阶段和约束条件的方案。