这两年我帮团队和外部客户落地了十多个大模型推理服务从最初几个人围着一台 4090 折腾到后来用多卡 GPU 机器扛线上流量框架选型、云服务配额、部署流程这些事基本都踩过一遍。到了 2026 年大模型服务器部署其实已经有一套成熟的做法但网上大量教程仍停留在单机体验阶段真正能照着落地的生产级内容并不多。这篇就把我常用的完整链路写出来先帮你把显存、并发、成本三笔账算清楚再对比主流推理框架和云服务 GPU 实例最后给一套从环境初始化到监控压测的生产部署流程。适合准备把开源模型接进业务或者正在云上规划正式服务的团队参考。1. 部署前先算清楚的三笔账显存、并发与成本很多人一上来就问该买几张卡我通常先反问三个问题模型多大、线上什么负载、每月愿意烧多少钱。这三件事不定下来选型就是碰运气。1.1 模型权重、KV Cache 与运行时开销的显存估算模型显存占用主要分三块权重、KV Cache、激活值与运行时开销。权重部分最简单参数量乘以每个参数的字节数。FP16/BF16 每个参数占 2 字节FP8 占 1 字节INT4 量化后大概 0.5 到 0.6 字节AWQ/GPTQ 还要额外存 scale 等系数。所以 7B 模型 FP16 权重约 14GB70B 模型 FP16 权重约 140GBAWQ 4bit 量化后大约落到 45 到 55GB。这一档账谁都会算真正容易翻车的是 KV Cache。KV Cache 和并发数、上下文长度强相关粗略估算可以按权重显存乘以 1.4 左右去粗估总需求KV Cache 建议至少留出 20% 到 40% 的余量。比如 70B FP16 权重约 140GB加上 KV Cache 和激活值2 张 80GB 卡合计 160GB是及格线想跑较长上下文老老实实上 4 卡或者直接做量化。我自己部署 Llama-3-70B 时用的是 2×A100 80GB量化后模型 50GB 左右KV Cache 留了大约 25GB跑 8K 上下文、中等并发是稳的。如果你在单张 24GB 的卡上跑 7B FP16权重占 14GB剩下的 10GB 全给 KV Cache并发一高照样 OOM这时候把max-model-len调小或者换量化版本更实际。1.2 并发画像决定你要的是吞吐还是低延迟部署前一定要分清业务类型。实时对话助手看重首 token 延迟用户发出请求后超过 1.5 秒还没开始输出体感就很差离线批量任务则只看整体吞吐比如每天要处理几十万条摘要慢一点没关系。再就是内部实验环境这种通常并发很低一张 A10 都能跑。估算负载时别只盯平均并发要看 p99。很多线上服务的请求分布是长尾的平均 5 并发不代表安全晚高峰可能瞬间冲到 30。我的做法是统计一周内每小时的请求量和单请求平均输入输出 token 数然后用一个简单公式估算吞吐需求平均并发 × 平均输出 token 数 ÷ 目标完成时间。举个例子假设高峰期 10 个并发用户每个请求平均输出 512 token你希望 15 秒内完成那至少需要约 340 tokens/s 的综合生成吞吐。单张 A10 或 L20 级别的卡能摸到这个量级但要留冗余和波动余量稳妥起见按 2 张卡规划。1.3 成本红线先定预算再反推架构GPU 成本是大多数团队的第一道坎。我的判断标准是如果单台 GPU 服务器月利用率长期低于 20%按量付费买云资源更划算如果利用率能稳定在 70% 以上并且至少跑半年以上再考虑包月甚至自购托管。很多团队一开始被云厂商的按量价格吓到转头买了物理机结果发现运维成本更高这是另一种踩坑。从成本反推架构还有一个好处逼着你认真考虑量化。70B FP16 需要 2 张 80GB 卡AWQ INT4 后单张 80GB 或两张 48GB 都能跑单卡成本直接减半。代价是精度略有损失这点要提前和业务方对齐别等服务上线了再说效果不对。2. 推理框架选型vLLM、SGLang、TGI、Ollama 各守一段2026 年主流推理框架的格局其实已经很清楚了每个框架都有明确的主场。选型不需要追逐最新而是要找到和你业务最匹配的那一个。2.1 vLLM 能成为默认选择靠的是生态和稳定vLLM 是我绝大多数场景的默认选项。它的核心是 PagedAttention把 KV Cache 按页管理显存碎片大幅减少配合 continuous batching请求之间不再互相等待吞吐提升非常可观。更关键的是 vLLM 的生态兼容性OpenAI 兼容 API 让你换了框架业务端几乎不用改代码Tensor Parallel 多卡支持成熟量化模型加载、embedding 模型、多模态支持都跟得很紧还有/metrics可以直接对接监控系统。要说缺点也有某些模型首次启动需要编译算子冷启动比较慢版本升级时参数变动较大旧配置可能失效。我的做法是部署脚本里固定镜像版本不追新只在需要新模型支持时才升级。2.2 SGLangAgent 和多轮对话场景的隐藏冠军如果你的业务以 Agent、多轮工具调用、超长思维链为主我建议认真看 SGLang。它用 RadixAttention 做前缀复用多轮对话中重复出现的系统提示词、上下文片段可以直接命中 KV Cache不用重新算。实测下来在固定系统提示词 工具定义 多轮历史这种场景里SGLang 的缓存命中能显著降低首 token 延迟和算力消耗。SGLang 的 API 也兼容 OpenAI 格式迁移成本不高。但它迭代节奏快版本间行为变化大社区自定义能力相对 vLLM 要弱一些。我的选型原则是Agent 链路占比高就选 SGLang常规文本生成一律 vLLM。2.3 TGI、Ollama 以及特殊场景框架TGI 是 HuggingFace 家的框架和 HF 生态集成度最高部署最简单对中小规模内部服务足够用。但它在大并发、复杂调度上的灵活性和性能上限比 vLLM 弱适合快速起一个标准的 HF 模型服务这种诉求。Ollama 则更适合本地开发和自测一条命令跑起模型Modelfile 在离线环境分发时也很好用但生产上用它扛流量的场景确实不多。还有一个方向是 TensorRT-LLM 和 LMDeploy。这类框架想做极致调优比如低延迟、低显存需要团队有比较强的 CUDA 工程能力。常规业务不需要一上来就上它维护成本会吃掉你省下的那点 GPU 钱。2.4 一张表直接给选型结论维度vLLMSGLangTGIOllama典型场景通用在线推理、大规模并发Agent、多轮对话、前缀复用场景HF 生态中小型服务本地体验、开发自测并发吞吐高高缓存命中时提升明显中低多卡支持Tensor Parallel / Pipeline Parallel 成熟支持但节点数不宜过大有基础支持有限API 兼容OpenAI 兼容生态最好OpenAI 兼容HF 风格兼容度高OpenAI 风格 API易用性中启动参数多中高极高维护成本低中版本迭代快低低我个人的结论是单模型对外提供服务默认 vLLMAgent 链路长、多轮上下文重选 SGLang内部小范围用 TGI开发阶段随便用 Ollama。这套组合在 2026 年依然不过时。3. 云服务 GPU 实例的真实成本账别只看单价云服务商的 GPU 型号和实例规格几乎每季度都在变但核心判断维度没变显存大小、卡间互联带宽、CPU 与内存配比以及付费模式的真实成本。3.1 主流 GPU 实例的大致格局国内平台目前能看到的主力卡包括 A10 24GB、L20 48GB、L40S 48GB、A100 40/80GB以及 H 系列 80GB 档位。以阿里云为例gn7i 系列常见 A10gn7e 常见 A100 40GB高配裸金属实例能拿到 A100 80GB 或 H 系列腾讯云、火山引擎、百度智能云也有类似档位。海外平台 AWS 的 p4d/p5 实例、Azure 的 ND 系列也都成熟但采购流程、网络延迟和数据合规这些因素必须在选型清单里。挑实例时我建议盯住三个参数单卡显存、卡间互联NVLink 还是 PCIe、CPU 型号和内存。显存决定你能跑多大模型卡间带宽决定多卡扩展效率CPU 和内存往往决定了 prefill 阶段的速度。很多团队只看 GPU 型号结果买的实例 CPU 配比太低首 token 延迟直接拉胯。3.2 按量、包月和竞价实例怎么选按量付费适合短期测试和波动明显的业务跑一两个小时验证模型直接释放不白花冤枉钱。长跑服务一定要看包年包月或预留实例折扣力度通常很大但前提是你的用量足够稳定。竞价实例/Spot 则只建议用于离线批处理、微调和压测这类可中断任务不要用在在线推理上平台的回收机制可能让你瞬间丢服务。还有个容易忽略的点新用户优惠。很多平台首月折扣很猛续费价格却翻几倍。签前务必算清续费价最好把预留实例和按量的账单对比完整一年周期别只看首月。3.3 隐性成本带宽、存储、日志都是钱大模型服务最容易被低估的其实是公网带宽。一次 512 token 的输出响应大概在 1KB 到 2KB高峰期每秒几十个请求流量并不小。很多平台公网带宽按量计费一个月下来甚至比 GPU 费用还高。我的做法是推理节点不配公网 IP服务放在内网由网关统一承担出口流量安全性和成本都能兼顾。模型权重存储也是隐性支出。70B INT4 大概 50GB云盘、对象存储、多副本镜像加起来每月的存储费用不容忽视。建议把模型放在共享存储或对象存储里按需挂载不要在每台机器上各存一份。日志、监控指标、镜像仓库这些也要纳入成本模型否则月底账单出来会非常意外。4. 生产级部署流程从裸机到对外服务的完整链路框架和云资源定了之后剩下的就是按部就班地把服务跑起来。这部分我给的是经过反复验证的操作链路每一步都能直接照做。4.1 GPU 驱动与容器运行时的基础环境生产服务器我强烈建议不要手动折腾 CUDA 环境直接用容器。宿主机只需要装两样东西NVIDIA 驱动和 nvidia-container-toolkit。驱动装完先验证nvidia-smi看到 GPU 列表和驱动版本再继续。然后安装容器运行时之后跑一次最简单的 CUDA 验证docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi这一步能确认容器内可以正常访问 GPU。驱动版本和 CUDA 版本不需要强行对应nvidia-container-toolkit 会自动帮容器绑好驱动这点比手动装 CUDA 省心太多也是我在生产环境选容器方案的根本原因。4.2 模型获取、文件校验与共享存储模型文件建议提前下好放到独立存储不要在服务启动时现场下载。下载工具可以用 huggingface-cli国内环境用 ModelScope 的 SDK 也很快。下载完成后记得检查文件完整性同时确认配置里的tokenizer_config和generation_config是否齐全缺 tokenizer 文件的服务启动到一半必然会挂。生产环境多实例部署时模型放共享存储只读挂载能省大量重复存储成本。如果模型要打进容器镜像注意镜像体积膨胀和构建时间更推荐运行时挂载。4.3 推理服务启动参数每个参数都要知道为什么以 vLLM 为例我常用的启动命令长这样python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-72B-Instruct-AWQ \ --served-model-name qwen2.5-72b \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 128 \ --host 0.0.0.0 \ --port 8000逐项说下参数的意义--model指向模型目录--served-model-name是对外暴露的模型名改名字不影响内部加载--tensor-parallel-size设为 2 表示权重切分到 2 张卡--max-model-len直接决定 KV Cache 上限盲目设大等于把显存全喂给长文本--gpu-memory-utilization控制显存使用率上限我一般设 0.85 到 0.92不拉到 0.95 以上否则容易 OOM--max-num-seqs控制并发序列上限设太大会造成排队堆积设太小又浪费 GPU。服务起来后先用小并发验证curl 一下/v1/models确认模型加载成功再发一个测试请求确认生成的流式响应正常。这一步跑通后才进入网关和服务管理环节。4.4 反代与网关流式响应必须关缓冲推理服务本身不能直接暴露公网必须在前面加一层网关做鉴权、限流和流控。Nginx 是最常见的反代但大模型接口和普通 Web 接口有个关键区别响应是流式的 SSE。Nginx 默认会缓冲响应导致客户端迟迟收不到首 token。我常用的配置片段如下location /v1/ { proxy_pass http://vllm-backend; proxy_buffering off; proxy_cache off; proxy_read_timeout 600s; proxy_set_header Connection ; chunked_transfer_encoding off; }proxy_buffering off是 SSE 流式响应的关键proxy_read_timeout要拉长否则生成时间长一点的请求会被 Nginx 中断。生产环境更推荐在网关层做统一的 API Key 鉴权、按用户限流和用量计费这些功能用开源网关或者云上的 API 网关都能实现。4.5 健康检查、systemd 服务与滚动发布vLLM 自带/health端点负载均衡的探活直接指到这个路径就行。服务托管我常用 systemd 单元文件崩溃自动重启如果已经在 Kubernetes 体系内用 Deployment 管理实例数更省事。生产发布流程建议走金丝雀先起一个新版本副本加进负载均衡观察 10 到 20 分钟的 p50 延迟和错误率没有异常再逐步切流量。镜像 tag 固定用带版本号的不要用 latest否则回滚时会很痛苦。5. 指标监控、压测与故障复盘服务上线只是开始真正考验部署水平的是你面对故障时能不能快速定位。这里把监控和压测讲透。5.1 监控指标GPU 层和业务层分开看vLLM 的/metrics暴露了大量指标配合 Prometheus Grafana 就能搭一套完整面板。GPU 层重点看利用率、显存占用、温度业务层重点看吞吐、首 token 延迟、队列深度和错误率。我的告警规则一般是这样显存使用率超过 95% 持续 2 分钟、GPU 利用率长期低于 10%说明负载没打上去、队列深度超过阈值、5xx 错误率超过 1%这些都触发通知。监控数据平时可能没人看但故障发生时它就是救命稻草。建议在压测阶段就把监控面板调好带着监控去看压测结果很多问题当场就能定位。5.2 压测方法流式接口不能用普通压测工具大模型 API 是 SSE 流式响应用 wrk、vegeta 这类工具去压会得到完全错误的结果。我的压测方案是用 Python 异步脚本模拟真实请求统计首 token 延迟、完整响应时间和生成吞吐。下面是个简化版模板import asyncio import httpx import time async def test_one(client, model, prompt): start time.perf_counter() first_token_time None tokens 0 async with client.stream(POST, /v1/chat/completions, json{...}) as r: async for line in r.aiter_lines(): if line and data: in line: if first_token_time is None: first_token_time time.perf_counter() - start tokens 1 return time.perf_counter() - start, first_token_time, tokens async def main(): async with httpx.AsyncClient(base_urlhttp://your-endpoint) as client: tasks [test_one(client, model, prompt) for _ in range(20)] results await asyncio.gather(*tasks) # 这里汇总结果压测时要观察吞吐曲线的拐点并发从 10 加到 20 时吞吐上去了从 20 加到 30 吞吐不再涨甚至下降说明已经到了瓶颈继续加压只会增加排队延迟。下表是我在某次 7B 模型、单张 L20 实例上的压测数据仅供参考不同硬件差异很大并发数首 token 延迟 p95生成吞吐GPU 利用率40.4s210 tokens/s65%80.6s360 tokens/s88%161.1s410 tokens/s95%322.3s380 tokens/s97%这个表说明并发到 16 已是甜点区再往上延迟快速恶化、吞吐反而下降。生产环境的容量规划就按甜点区留 30% 余量。5.3 线上常见故障复盘OOM、超时与慢请求最典型的故障是显存 OOM。常见触发原因包括gpu-memory-utilization设太高、max-model-len过大、以及突发的超长单请求。处理手段按优先级是限制max-model-len、调低显存使用率、给网关加单请求大小限制。第二个高发问题是请求超时。max-num-seqs打满后请求会排队如果排队时间超过反代超时时间客户端直接报错。遇到这种场景先看是不是流量超预期是就加副本再看模型服务端指标若有长尾大请求占坑就该在网关层限制 max tokens而不是压底层。第三个容易被忽视的问题是慢请求。个别请求输出两千 token把整个批次拖慢其他短请求跟着遭殃。vLLM 这类框架有调度策略可以缓解但我们通常在业务层做限制对输出长度分级处理、长短请求分流到不同副本。6. 框架细节调优与避坑经验最后聊几个容易出问题但文档里很少写透的细节。这些经验都是真金白银堆出来的。6.1 KV Cache 与显存利用率的平衡很多人有个误区以为gpu-memory-utilization越高越好。实际上设到 0.95 以上一旦遇到长上下文请求KV Cache 扩容没有余量进程直接 OOM。我常用的经验值是 0.88 到 0.92给系统预留缓冲。另外max-model-len不要为了显得厉害就设 32K它直接决定了 KV Cache 的显存预分配实际业务场景如果 80% 请求都不到 8K就该设为 8K 或者对着上限设剩余显存留给并发。6.2 量化方案与推理速度的真实关系量化不只是省显存还把吞吐上了一个台阶。70B FP16 在 2 张 80GB 卡上勉强跑改成 AWQ INT4 后单张 80GB 就够而且因为权重读取量变小理论上每 token 的生成速度还能更快。代价是精度损失不同任务表现差异很大。我的建议是先拿业务里最难的样本做量化前后对比评测指标不掉就上线掉了就退回 FP8 或 FP16。FP8 是个不错的折中方案显存减半、精度损失小但对显卡型号有要求选卡时先查支持矩阵。6.3 多卡并行选 TP 还是多副本多卡并行有两个方向Tensor Parallel 把单模型切到多卡显存扩容、吞吐上升Data Parallel多副本则是在每张卡上放一个完整模型前面负载均衡分摊流量。我的经验是单机内多卡且卡间有高带宽互联优先 TP尤其 70B 以上模型跨机器不要轻易用 TP就算走 RDMA通信损耗也很可观。如果模型单卡能放下直接用多副本最省心扩缩容也简单。混合方案的话通常是单副本内 TP 2 卡多副本横向扩展。最后分享一点实操中的体会部署大模型这事真正让我翻车的从来不是框架本身而是对需求估算太乐观、对显存用量太含蓄以及上线前没压测就把端口暴露出去。我现在养成一个习惯任何模型先以最小可用实例跑通接口和监控再逐步加并发和上下文长度每改一个参数都记录当时的显存和延迟数据积累两三轮数据后再做真正的调优和容量规划。如果你正打算部署一个大模型服务建议先把显存、并发、成本三笔账算清楚再用小实例跑通全链路最后上量。这一步走稳了后面基本就顺了。