尧图网页设计 
1. 大模型部署这件事到底难在哪2026 年做大模型部署跟两年前完全不是一个玩法了。2024 年那会儿大家还在折腾怎么把 LLaMA 跑起来、怎么装 CUDA 驱动不报错到了现在推理框架已经卷出天际云服务商的 GPU 实例价格每个月都在变企业侧的需求从“能跑就行”变成了“生产级稳定、成本可控、弹性伸缩”。我过去一年帮三个团队从零搭建了大模型推理服务踩过的坑从显卡驱动冲突到显存碎片化导致 OOM从云服务账单失控到推理延迟抖动超过 SLA基本上能遇到的都遇到了。这篇文章想做的事情很具体把大模型服务器部署这件事从框架选型、云服务对比、到生产级流程完整地拆一遍。不是那种“Hello World 跑通就算完”的教程而是真正上线跑业务时会遇到的那些决策点和坑。适合谁看如果你是大模型开发工程师、AI 基础设施负责人、或者正在把大模型能力集成到产品里的技术负责人这篇内容应该能帮你省掉至少两到三周的试错时间。如果你只是想在个人电脑上跑个模型玩玩那 Ollama 加一条命令就够了不需要往下看。核心关键词先摆出来大模型服务器部署、推理框架选型、云服务对比、生产级流程。这四个词基本覆盖了从决策到落地的全链路。下面我会按实际项目的推进顺序来展开——先想清楚要什么再选框架再选云服务最后把生产级的那套流程跑通。2. 部署前的核心决策你到底需要什么2.1 先搞清楚推理场景别上来就选框架我见过太多人一上来就问“vLLM 和 TGI 哪个好”但连自己的请求模式都没搞清楚。这个顺序是反的。推理场景的差异直接决定了框架选型和硬件配置所以第一步应该是把场景拆清楚。大模型推理场景大致可以分成四类交互式对话用户发一条消息等模型回复。特点是请求频率不稳定、对首 token 延迟敏感、输出长度中等几十到几百 token。典型产品是客服机器人、AI 助手。批量离线推理一次性提交几千条数据跑完拿结果。特点是吞吐量优先、延迟不敏感、可以接受排队。典型场景是数据标注、内容审核、批量摘要。流式生成需要 token 逐个吐出来用户体验要求高。特点是首 token 延迟和 token 间延迟都要控制。典型场景是在线写作助手、代码补全。多模态推理输入包含图像、音频甚至视频。特点是显存占用大、预处理链路复杂、对 GPU 型号有要求。典型场景是工业质检、文档理解。这四类场景对框架的要求完全不同。交互式对话需要框架支持 continuous batching 和 PagedAttention 来提升 GPU 利用率批量离线推理更看重吞吐量可以用更大的 batch size 换延迟流式生成对调度器的公平性要求高多模态推理则需要框架支持视觉编码器的并行加载。我的经验是先把场景写下来标注清楚 QPS 预期、P99 延迟要求、平均输入输出长度、是否需要流式返回。这四个数字定了框架选型基本就锁定了一半。2.2 模型规模与硬件匹配的粗略计算选硬件之前先算一笔账。模型推理的显存占用大致可以按这个公式估算显存占用 ≈ 模型参数量 × 精度字节数 × 1.2额外开销 KV Cache举个例子一个 70B 参数的模型用 FP16 精度推理光模型权重就需要 70 × 2 × 1.2 168GB 显存。这意味着单张 80GB 的 A100 或 H100 根本放不下至少需要三张做张量并行。如果用 INT8 量化权重占用降到 84GB 左右两张 80GB 卡就够了。如果用 INT4 量化一张 80GB 卡勉强能跑但 KV Cache 空间会很紧张。KV Cache 的计算稍微复杂一点公式是KV Cache 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × batch_size × 精度字节数以 LLaMA 3 70B 为例80 层、64 个注意力头、头维度 128序列长度 4096batch_size 为 1 时FP16 精度下 KV Cache 大约是 2 × 80 × 64 × 128 × 4096 × 1 × 2 10.7GB。如果 batch_size 开到 16KV Cache 就超过 170GB 了比模型权重还大。这就是为什么 PagedAttention 这类技术这么重要——它能把 KV Cache 的显存利用率从 20%-40% 提升到 90% 以上。实际选卡的时候我一般会留 20% 的显存余量给框架本身和临时缓冲区。所以一张 80GB 的卡实际可用显存按 64GB 算比较稳妥。2.3 成本预算的三种模式部署大模型的成本结构差异很大取决于你选哪种模式模式前期投入月度成本适合场景风险自建 GPU 服务器高5-30万低电费运维长期稳定负载硬件贬值快、扩容难云 GPU 按量付费无高按小时计短期项目、波动负载账单失控云 GPU 包年包月中预付中可预测的稳定负载资源闲置浪费我个人的建议是如果你能预测未来 12 个月的 GPU 利用率超过 60%自建或包年包月更划算如果利用率低于 30%按量付费更灵活。介于两者之间的可以考虑预留实例加按量补充的混合模式。3. 推理框架选型2026 年的主流选项与取舍3.1 vLLM目前最主流的生产级选择vLLM 在 2026 年依然是大模型推理框架里最主流的选择核心优势是 PagedAttention 和 continuous batching 带来的高吞吐量。我实测下来在同样的 A100 上跑 LLaMA 3 70BvLLM 的吞吐量比朴素 HuggingFace Transformers 高出 10-20 倍比 TGI 也高出 20%-30%。vLLM 的部署方式很直接pip install vllm python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3-70b-chat-hf \ --tensor-parallel-size 4 \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000几个关键参数值得展开说--tensor-parallel-size张量并行数等于你用的 GPU 数量。70B 模型 FP16 精度下4 张 A100 80GB 是比较稳的配置。--gpu-memory-utilizationGPU 显存利用率上限默认 0.9。这个值设太高容易 OOM设太低浪费显存。我一般设 0.85-0.9。--max-model-len最大序列长度。这个值直接影响 KV Cache 的显存占用设得越大能同时处理的请求越少。--enable-prefix-caching如果多个请求共享相同的 system prompt开启这个能大幅减少重复计算。vLLM 的坑主要在两个地方一是显存碎片化长时间运行后可能出现“明明显存够但就是分配不出来”的情况解决办法是定期重启或者用--swap-space参数留出交换空间二是多卡通信开销张量并行数超过 4 之后卡间通信的延迟会明显上升吞吐量提升不再线性。3.2 TGIHuggingFace 生态的集成优势TGIText Generation Inference是 HuggingFace 推出的推理框架最大的优势是和 HuggingFace 生态的无缝集成。如果你的模型是从 HuggingFace Hub 直接拉取的TGI 的部署体验会比 vLLM 更顺滑。TGI 的 Docker 部署方式docker run --gpus all \ -p 8080:80 \ -v /data/models:/data \ ghcr.io/huggingface/text-generation-inference:latest \ --model-id meta-llama/Llama-3-70b-chat-hf \ --num-shard 4 \ --max-input-length 4096 \ --max-total-tokens 8192TGI 在 2025 年之后引入了 continuous batching 和 Flash Attention 的优化性能已经和 vLLM 很接近了。它的优势在于对量化模型的支持更成熟特别是 GPTQ 和 AWQ 量化模型TGI 的加载速度和推理稳定性都更好。不过 TGI 的定制化能力不如 vLLM。如果你想改调度策略或者加自定义的预处理逻辑vLLM 的代码结构更清晰改起来更方便。3.3 Ollama个人和小团队的低门槛选择Ollama 严格来说不算生产级推理框架它的定位是“让个人电脑也能跑大模型”。但 2026 年的 Ollama 已经支持了多并发的请求处理在小规模场景下比如团队内部工具、原型验证完全够用。Ollama 的安装和运行极其简单curl -fsSL https://ollama.com/install.sh | sh ollama pull llama3:70b ollama serveOllama 底层其实也是基于 llama.cpp 的推理引擎支持 CPU 和 GPU 混合推理。如果你的机器只有一张消费级显卡比如 RTX 4090 24GBOllama 可以通过量化把 70B 模型压到 24GB 以内跑起来虽然速度慢一些但能用。Ollama 的局限也很明显并发能力弱、没有 continuous batching、不支持张量并行。所以它适合个人开发和小团队内部使用不适合面向用户的生产服务。3.4 框架选型的决策树把上面的信息整理成一个决策逻辑条件推荐框架理由生产环境、高并发、追求吞吐量vLLMPagedAttention continuous batching吞吐量最优生产环境、HuggingFace 生态重度用户TGI集成度高量化模型支持好个人开发、原型验证、单卡环境Ollama安装简单资源占用低需要深度定制调度策略vLLM代码结构清晰易于修改多模态推理vLLM 或 TGI两者都支持视觉编码器vLLM 的多模态支持更活跃一个常见的误区是“选一个框架就一直用”。实际上我建议在项目初期用 Ollama 快速验证确认模型效果后再迁移到 vLLM 或 TGI 做生产部署。迁移成本主要是重新写部署脚本模型本身不用动。4. 云服务对比2026 年的 GPU 实例怎么选4.1 主流云服务商的 GPU 实例对比2026 年国内可选的 GPU 云服务商主要有阿里云、腾讯云、华为云海外有 AWS、GCP、Azure。我整理了一个对比表聚焦在大模型推理最常用的几款实例上服务商实例类型GPU 型号显存按量价格元/小时包月价格元/月网络带宽阿里云ecs.gn7i-c16g1.4xlargeA1024GB约 12约 5800按带宽计费阿里云ecs.gn7e-c16g1.4xlargeA10080GB约 35约 16800按带宽计费腾讯云GN10Xp.4XLARGE80A10080GB约 33约 15800按带宽计费华为云p2s.4xlarge.8V10032GB约 18约 8600按带宽计费AWSp4d.24xlargeA10080GB×8约 220约 105000按流量计费GCPa2-highgpu-1gA10040GB约 28约 13400按流量计费价格是 2026 年上半年的参考值实际会有浮动。几个观察阿里云和腾讯云的 A100 实例价格接近但阿里云的生态工具更完善比如 PAI 平台、NAS 存储集成。华为云的 V100 实例性价比不错但 V100 对 FP8 和 Flash Attention 3 的支持不如 A100/H100新模型部署时可能遇到兼容性问题。海外云服务商的优势在于 H100 实例可选但价格明显更高而且网络延迟对国内用户不友好。4.2 云服务选型的五个关键考量第一GPU 型号与框架兼容性。vLLM 和 TGI 对 A100/H100 的支持最好V100 在 FP16 推理上没问题但如果你要用 FP8 量化或者 Flash Attention 3就必须上 H100。选实例之前先确认框架的硬件要求。第二存储与模型加载速度。大模型动辄几十上百 GB从对象存储拉取模型文件的时间可能比推理本身还长。阿里云的 NAS 和腾讯云的 CFS 都支持多实例共享模型文件避免每个实例重复下载。我实测过用 NAS 共享模型新实例启动时间从 15 分钟降到 3 分钟。第三网络带宽与延迟。如果推理服务需要对外提供 API带宽成本不能忽略。阿里云按带宽计费10Mbps 带宽每月大约 500 元如果按流量计费每 GB 大约 0.8 元。对于高 QPS 的服务带宽成本可能占到总成本的 20% 以上。第四弹性伸缩能力。生产级部署需要根据负载自动扩缩容。阿里云的 ESS弹性伸缩服务和腾讯云的 AS弹性伸缩都支持基于 GPU 利用率的自动扩缩。但 GPU 实例的启动时间通常在 3-5 分钟所以扩容策略要提前触发不能等负载满了再扩。第五数据安全与合规。如果模型或数据涉及敏感信息需要确认云服务商是否支持私有网络隔离、加密存储、访问审计。这部分不是技术问题但选型时必须考虑。4.3 成本优化的几个实操技巧云 GPU 的成本优化空间很大我总结了几条实际有效的做法用抢占式实例跑离线任务。阿里云和腾讯云都有抢占式 GPU 实例价格是按量实例的 30%-50%但可能被随时回收。适合批量离线推理任务配合 checkpoint 机制被回收了也能续跑。混合使用包年包月和按量实例。基线负载用包年包月峰值负载用按量实例补充。我帮一个团队做过这个方案月度成本降低了 35%。模型量化降低显存需求。把 FP16 量化到 INT8显存占用减半可以用更便宜的实例。精度损失通常在 1%-3% 以内对大多数业务场景可以接受。合理设置自动缩容策略。很多团队的自动缩容太保守导致夜间闲置实例浪费。我一般建议 GPU 利用率低于 20% 持续 10 分钟就缩容高于 70% 持续 5 分钟就扩容。5. 生产级部署流程从零到上线的完整路径5.1 环境准备与基础镜像制作生产级部署的第一步不是装框架而是做一个可复现的基础镜像。我见过太多团队因为环境不一致导致“本地能跑、线上报错”的问题。基础镜像应该包含CUDA 驱动、Python 环境、推理框架、监控 agent。一个典型的 Dockerfile 结构FROM nvidia/cuda:12.4.1-runtime-ubuntu22.04 RUN apt-get update apt-get install -y \ python3.11 python3-pip curl git \ rm -rf /var/lib/apt/lists/* RUN pip install --no-cache-dir \ vllm0.6.3 \ prometheus-client \ opentelemetry-api COPY entrypoint.sh /entrypoint.sh RUN chmod x /entrypoint.sh ENTRYPOINT [/entrypoint.sh]几个细节值得注意基础镜像用runtime而不是devel体积小很多生产环境不需要编译工具。Python 版本锁定在 3.11vLLM 对 3.12 的支持在 2026 年初还有问题。推理框架版本必须锁定不能写latest否则某天自动更新可能引入不兼容的变更。监控 agent 提前装好不要等上线了再补。5.2 模型加载与预热策略模型加载是部署过程中最耗时的环节。一个 70B 的模型从磁盘加载到 GPU 显存通常需要 3-8 分钟取决于存储速度和模型格式。优化模型加载速度的几个方法使用 safetensors 格式。比 PyTorch 的 pickle 格式加载快 30%-50%而且更安全。模型文件放在本地 NVMe SSD 上。如果用的是云实例把模型文件从对象存储拉到本地 SSD 再加载比直接从 NAS 加载快 2-3 倍。预热请求。服务启动后先发几个预热请求把 KV Cache 和 CUDA kernel 都初始化好再接入正式流量。预热请求可以用固定长度的输入比如 512 token 的填充文本。import requests def warmup(base_url, num_requests5): for i in range(num_requests): payload { model: llama-3-70b, prompt: 预热请求 * 100, max_tokens: 32, temperature: 0.0 } requests.post(f{base_url}/v1/completions, jsonpayload)预热请求的数量不用太多5-10 个就够了。关键是让 CUDA kernel 完成 JIT 编译后续请求的延迟会稳定很多。5.3 负载均衡与请求路由单实例的推理服务总有容量上限生产环境需要多实例负载均衡。大模型推理的负载均衡和普通 Web 服务不太一样有几个特殊考量请求长度差异大。一个 100 token 的请求和一个 8000 token 的请求处理时间可能差 50 倍。简单的轮询负载均衡会导致某些实例排队严重。KV Cache 状态。如果开启了 prefix caching相同 system prompt 的请求路由到同一实例能命中缓存减少计算。实例健康检查。GPU 实例可能出现显存泄漏、CUDA 错误等问题健康检查不能只检查 HTTP 端口还要检查 GPU 状态。我一般用 Nginx 做第一层负载均衡配合自定义的 upstream 健康检查脚本upstream vllm_backend { least_conn; server 10.0.1.10:8000 max_fails3 fail_timeout30s; server 10.0.1.11:8000 max_fails3 fail_timeout30s; server 10.0.1.12:8000 max_fails3 fail_timeout30s; }least_conn策略比轮询更适合推理服务因为它会把新请求发给当前连接数最少的实例。但更好的做法是基于请求队列长度做路由这需要自己写一个简单的路由层。5.4 监控体系与告警配置生产级部署没有监控就是裸奔。大模型推理服务的监控指标比普通服务多一层 GPU 相关的指标。我通常监控以下几类指标类别具体指标告警阈值说明GPU 硬件GPU 利用率持续90% 或 10%过高可能排队过低可能浪费GPU 硬件GPU 显存使用率95%接近 OOM 风险GPU 硬件GPU 温度85°C散热问题推理性能首 token 延迟 P992s用户体验下降推理性能token 间延迟 P99100ms流式体验变差推理性能请求队列长度10需要扩容服务健康请求错误率1%可能模型或框架异常资源实例数量低于最小值缩容过度Prometheus Grafana 是标配vLLM 和 TGI 都内置了 Prometheus metrics 端点。GPU 指标需要额外部署 DCGM Exporterdocker run --gpus all -d \ -p 9400:9400 \ nvcr.io/nvidia/k8s/dcgm-exporter:3.3.0-3.2.0-ubuntu22.04告警配置有几个经验首 token 延迟的告警阈值不要设太紧因为大模型推理本身就有波动GPU 利用率的告警要区分“持续高”和“瞬时高”瞬时高是正常的请求队列长度的告警最灵敏通常是最早发现容量不足的指标。5.5 灰度发布与回滚机制模型更新或框架升级时不能直接全量替换。灰度发布的流程新版本实例部署到独立的实例组不接入正式流量。用内部测试流量验证新版本的功能和性能。将 5% 的正式流量切到新版本观察 30 分钟。逐步增加流量比例5% → 20% → 50% → 100%。每一步都检查错误率、延迟、GPU 指标。回滚机制要提前准备好。最直接的方式是保留旧版本的镜像和模型文件回滚时把负载均衡的流量切回去。回滚时间应该控制在 5 分钟以内。我踩过的一个坑有一次模型更新后新版本在短请求上表现正常但长请求超过 4000 token的延迟暴涨。灰度阶段只测了短请求全量后才发现问题。所以灰度验证的请求分布要覆盖真实流量的分布不能只测简单 case。6. 常见问题与排查技巧实录6.1 显存相关问题的排查问题一启动时报 CUDA out of memory。这是最常见的问题。排查顺序确认模型权重的显存占用是否超过 GPU 容量。用nvidia-smi查看 GPU 总显存对比模型参数量 × 精度字节数。检查是否有其他进程占用显存。nvidia-smi会列出所有 GPU 进程。降低--gpu-memory-utilization参数从 0.9 降到 0.8 试试。减小--max-model-len降低 KV Cache 的预留空间。问题二运行一段时间后 OOM。这种通常是显存碎片化或 KV Cache 泄漏导致的。vLLM 的 PagedAttention 已经很大程度上解决了碎片化问题但长时间运行后仍可能出现。解决办法设置--swap-space参数留出 CPU 内存作为交换空间。配置定期重启策略比如每 24 小时滚动重启一次。监控显存使用率的增长趋势如果持续上升说明有泄漏。问题三多卡推理时显存不均衡。张量并行下每张卡负责模型的一部分显存占用应该大致均衡。如果差异超过 10%可能是模型切分不均匀或者某张卡上有其他进程。检查--tensor-parallel-size是否和实际 GPU 数量一致。6.2 性能不达预期的排查首 token 延迟高。可能的原因请求排队检查队列长度、KV Cache 未命中检查 prefix caching 配置、CUDA kernel 未预热发预热请求。吞吐量低。检查 batch size 是否太小、continuous batching 是否开启、GPU 利用率是否偏低。如果 GPU 利用率低于 50%说明请求调度有问题可能是 batch 组装策略不够激进。token 间延迟抖动大。通常是 GPU 被其他进程抢占或者温度过高降频。检查nvidia-smi的 GPU 利用率和温度曲线。6.3 网络与 API 相关问题请求超时。大模型推理的延迟本身较高客户端超时时间要设置合理。我一般建议首 token 超时设 30 秒总超时设 120 秒。如果经常超时检查是不是请求队列太长。流式返回中断。检查负载均衡的超时配置Nginx 默认的proxy_read_timeout是 60 秒对于长文本生成可能不够。改成 300 秒。并发请求被拒绝。vLLM 默认的并发上限是 256如果超过会返回 503。可以通过--max-num-seqs参数调整但调太高会导致显存不足。6.4 常见问题速查表现象可能原因排查方法解决措施启动 OOM模型太大/显存被占nvidia-smi 查看降精度/减 max-model-len运行中 OOM显存碎片/泄漏监控显存趋势定期重启/加 swap首 token 慢排队/未预热查队列长度扩容/预热吞吐量低batch 太小查 GPU 利用率调大 batch/开 continuous batching流式中断超时配置短查 Nginx 日志调大 proxy_read_timeout多卡不均衡切分不均nvidia-smi 对比检查 tensor-parallel-size请求被拒并发超限查 503 错误调大 max-num-seqs7. 一些实际项目中的经验体会部署大模型这件事技术选型只占 30% 的工作量剩下 70% 是运维和调优。我见过太多团队在框架选型上纠结了两周结果上线后发现真正的瓶颈在存储 IO 和网络带宽上。一个很实际的建议如果你的团队第一次做大模型部署先用 Ollama 在一台开发机上把流程跑通确认模型效果和业务需求匹配再考虑生产级部署。生产级部署的复杂度主要来自高可用、监控、弹性伸缩这些工程问题而不是模型本身。另外模型量化是降低成本最直接的手段。INT8 量化通常能把显存占用减半精度损失在大多数业务场景下可以忽略。如果业务对精度极其敏感可以考虑 AWQ 或 GPTQ 这类更精细的量化方法但需要做充分的评测。最后说一个容易被忽略的点模型版本管理。生产环境跑的模型版本必须和训练、评测时完全一致包括 tokenizer 配置、模型权重、推理参数。我建议用类似 Git LFS 或者专门的模型仓库来管理模型版本每次部署都记录清楚用的是哪个版本。这个习惯在出问题时能帮你快速定位和回滚。 大模型服务器部署实战：推理框架选型、云服务对比与生产级流程
1. 大模型部署这件事到底难在哪2026 年做大模型部署跟两年前完全不是一个玩法了。2024 年那会儿大家还在折腾怎么把 LLaMA 跑起来、怎么装 CUDA 驱动不报错到了现在推理框架已经卷出天际云服务商的 GPU 实例价格每个月都在变企业侧的需求从“能跑就行”变成了“生产级稳定、成本可控、弹性伸缩”。我过去一年帮三个团队从零搭建了大模型推理服务踩过的坑从显卡驱动冲突到显存碎片化导致 OOM从云服务账单失控到推理延迟抖动超过 SLA基本上能遇到的都遇到了。这篇文章想做的事情很具体把大模型服务器部署这件事从框架选型、云服务对比、到生产级流程完整地拆一遍。不是那种“Hello World 跑通就算完”的教程而是真正上线跑业务时会遇到的那些决策点和坑。适合谁看如果你是大模型开发工程师、AI 基础设施负责人、或者正在把大模型能力集成到产品里的技术负责人这篇内容应该能帮你省掉至少两到三周的试错时间。如果你只是想在个人电脑上跑个模型玩玩那 Ollama 加一条命令就够了不需要往下看。核心关键词先摆出来大模型服务器部署、推理框架选型、云服务对比、生产级流程。这四个词基本覆盖了从决策到落地的全链路。下面我会按实际项目的推进顺序来展开——先想清楚要什么再选框架再选云服务最后把生产级的那套流程跑通。2. 部署前的核心决策你到底需要什么2.1 先搞清楚推理场景别上来就选框架我见过太多人一上来就问“vLLM 和 TGI 哪个好”但连自己的请求模式都没搞清楚。这个顺序是反的。推理场景的差异直接决定了框架选型和硬件配置所以第一步应该是把场景拆清楚。大模型推理场景大致可以分成四类交互式对话用户发一条消息等模型回复。特点是请求频率不稳定、对首 token 延迟敏感、输出长度中等几十到几百 token。典型产品是客服机器人、AI 助手。批量离线推理一次性提交几千条数据跑完拿结果。特点是吞吐量优先、延迟不敏感、可以接受排队。典型场景是数据标注、内容审核、批量摘要。流式生成需要 token 逐个吐出来用户体验要求高。特点是首 token 延迟和 token 间延迟都要控制。典型场景是在线写作助手、代码补全。多模态推理输入包含图像、音频甚至视频。特点是显存占用大、预处理链路复杂、对 GPU 型号有要求。典型场景是工业质检、文档理解。这四类场景对框架的要求完全不同。交互式对话需要框架支持 continuous batching 和 PagedAttention 来提升 GPU 利用率批量离线推理更看重吞吐量可以用更大的 batch size 换延迟流式生成对调度器的公平性要求高多模态推理则需要框架支持视觉编码器的并行加载。我的经验是先把场景写下来标注清楚 QPS 预期、P99 延迟要求、平均输入输出长度、是否需要流式返回。这四个数字定了框架选型基本就锁定了一半。2.2 模型规模与硬件匹配的粗略计算选硬件之前先算一笔账。模型推理的显存占用大致可以按这个公式估算显存占用 ≈ 模型参数量 × 精度字节数 × 1.2额外开销 KV Cache举个例子一个 70B 参数的模型用 FP16 精度推理光模型权重就需要 70 × 2 × 1.2 168GB 显存。这意味着单张 80GB 的 A100 或 H100 根本放不下至少需要三张做张量并行。如果用 INT8 量化权重占用降到 84GB 左右两张 80GB 卡就够了。如果用 INT4 量化一张 80GB 卡勉强能跑但 KV Cache 空间会很紧张。KV Cache 的计算稍微复杂一点公式是KV Cache 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × batch_size × 精度字节数以 LLaMA 3 70B 为例80 层、64 个注意力头、头维度 128序列长度 4096batch_size 为 1 时FP16 精度下 KV Cache 大约是 2 × 80 × 64 × 128 × 4096 × 1 × 2 10.7GB。如果 batch_size 开到 16KV Cache 就超过 170GB 了比模型权重还大。这就是为什么 PagedAttention 这类技术这么重要——它能把 KV Cache 的显存利用率从 20%-40% 提升到 90% 以上。实际选卡的时候我一般会留 20% 的显存余量给框架本身和临时缓冲区。所以一张 80GB 的卡实际可用显存按 64GB 算比较稳妥。2.3 成本预算的三种模式部署大模型的成本结构差异很大取决于你选哪种模式模式前期投入月度成本适合场景风险自建 GPU 服务器高5-30万低电费运维长期稳定负载硬件贬值快、扩容难云 GPU 按量付费无高按小时计短期项目、波动负载账单失控云 GPU 包年包月中预付中可预测的稳定负载资源闲置浪费我个人的建议是如果你能预测未来 12 个月的 GPU 利用率超过 60%自建或包年包月更划算如果利用率低于 30%按量付费更灵活。介于两者之间的可以考虑预留实例加按量补充的混合模式。3. 推理框架选型2026 年的主流选项与取舍3.1 vLLM目前最主流的生产级选择vLLM 在 2026 年依然是大模型推理框架里最主流的选择核心优势是 PagedAttention 和 continuous batching 带来的高吞吐量。我实测下来在同样的 A100 上跑 LLaMA 3 70BvLLM 的吞吐量比朴素 HuggingFace Transformers 高出 10-20 倍比 TGI 也高出 20%-30%。vLLM 的部署方式很直接pip install vllm python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3-70b-chat-hf \ --tensor-parallel-size 4 \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000几个关键参数值得展开说--tensor-parallel-size张量并行数等于你用的 GPU 数量。70B 模型 FP16 精度下4 张 A100 80GB 是比较稳的配置。--gpu-memory-utilizationGPU 显存利用率上限默认 0.9。这个值设太高容易 OOM设太低浪费显存。我一般设 0.85-0.9。--max-model-len最大序列长度。这个值直接影响 KV Cache 的显存占用设得越大能同时处理的请求越少。--enable-prefix-caching如果多个请求共享相同的 system prompt开启这个能大幅减少重复计算。vLLM 的坑主要在两个地方一是显存碎片化长时间运行后可能出现“明明显存够但就是分配不出来”的情况解决办法是定期重启或者用--swap-space参数留出交换空间二是多卡通信开销张量并行数超过 4 之后卡间通信的延迟会明显上升吞吐量提升不再线性。3.2 TGIHuggingFace 生态的集成优势TGIText Generation Inference是 HuggingFace 推出的推理框架最大的优势是和 HuggingFace 生态的无缝集成。如果你的模型是从 HuggingFace Hub 直接拉取的TGI 的部署体验会比 vLLM 更顺滑。TGI 的 Docker 部署方式docker run --gpus all \ -p 8080:80 \ -v /data/models:/data \ ghcr.io/huggingface/text-generation-inference:latest \ --model-id meta-llama/Llama-3-70b-chat-hf \ --num-shard 4 \ --max-input-length 4096 \ --max-total-tokens 8192TGI 在 2025 年之后引入了 continuous batching 和 Flash Attention 的优化性能已经和 vLLM 很接近了。它的优势在于对量化模型的支持更成熟特别是 GPTQ 和 AWQ 量化模型TGI 的加载速度和推理稳定性都更好。不过 TGI 的定制化能力不如 vLLM。如果你想改调度策略或者加自定义的预处理逻辑vLLM 的代码结构更清晰改起来更方便。3.3 Ollama个人和小团队的低门槛选择Ollama 严格来说不算生产级推理框架它的定位是“让个人电脑也能跑大模型”。但 2026 年的 Ollama 已经支持了多并发的请求处理在小规模场景下比如团队内部工具、原型验证完全够用。Ollama 的安装和运行极其简单curl -fsSL https://ollama.com/install.sh | sh ollama pull llama3:70b ollama serveOllama 底层其实也是基于 llama.cpp 的推理引擎支持 CPU 和 GPU 混合推理。如果你的机器只有一张消费级显卡比如 RTX 4090 24GBOllama 可以通过量化把 70B 模型压到 24GB 以内跑起来虽然速度慢一些但能用。Ollama 的局限也很明显并发能力弱、没有 continuous batching、不支持张量并行。所以它适合个人开发和小团队内部使用不适合面向用户的生产服务。3.4 框架选型的决策树把上面的信息整理成一个决策逻辑条件推荐框架理由生产环境、高并发、追求吞吐量vLLMPagedAttention continuous batching吞吐量最优生产环境、HuggingFace 生态重度用户TGI集成度高量化模型支持好个人开发、原型验证、单卡环境Ollama安装简单资源占用低需要深度定制调度策略vLLM代码结构清晰易于修改多模态推理vLLM 或 TGI两者都支持视觉编码器vLLM 的多模态支持更活跃一个常见的误区是“选一个框架就一直用”。实际上我建议在项目初期用 Ollama 快速验证确认模型效果后再迁移到 vLLM 或 TGI 做生产部署。迁移成本主要是重新写部署脚本模型本身不用动。4. 云服务对比2026 年的 GPU 实例怎么选4.1 主流云服务商的 GPU 实例对比2026 年国内可选的 GPU 云服务商主要有阿里云、腾讯云、华为云海外有 AWS、GCP、Azure。我整理了一个对比表聚焦在大模型推理最常用的几款实例上服务商实例类型GPU 型号显存按量价格元/小时包月价格元/月网络带宽阿里云ecs.gn7i-c16g1.4xlargeA1024GB约 12约 5800按带宽计费阿里云ecs.gn7e-c16g1.4xlargeA10080GB约 35约 16800按带宽计费腾讯云GN10Xp.4XLARGE80A10080GB约 33约 15800按带宽计费华为云p2s.4xlarge.8V10032GB约 18约 8600按带宽计费AWSp4d.24xlargeA10080GB×8约 220约 105000按流量计费GCPa2-highgpu-1gA10040GB约 28约 13400按流量计费价格是 2026 年上半年的参考值实际会有浮动。几个观察阿里云和腾讯云的 A100 实例价格接近但阿里云的生态工具更完善比如 PAI 平台、NAS 存储集成。华为云的 V100 实例性价比不错但 V100 对 FP8 和 Flash Attention 3 的支持不如 A100/H100新模型部署时可能遇到兼容性问题。海外云服务商的优势在于 H100 实例可选但价格明显更高而且网络延迟对国内用户不友好。4.2 云服务选型的五个关键考量第一GPU 型号与框架兼容性。vLLM 和 TGI 对 A100/H100 的支持最好V100 在 FP16 推理上没问题但如果你要用 FP8 量化或者 Flash Attention 3就必须上 H100。选实例之前先确认框架的硬件要求。第二存储与模型加载速度。大模型动辄几十上百 GB从对象存储拉取模型文件的时间可能比推理本身还长。阿里云的 NAS 和腾讯云的 CFS 都支持多实例共享模型文件避免每个实例重复下载。我实测过用 NAS 共享模型新实例启动时间从 15 分钟降到 3 分钟。第三网络带宽与延迟。如果推理服务需要对外提供 API带宽成本不能忽略。阿里云按带宽计费10Mbps 带宽每月大约 500 元如果按流量计费每 GB 大约 0.8 元。对于高 QPS 的服务带宽成本可能占到总成本的 20% 以上。第四弹性伸缩能力。生产级部署需要根据负载自动扩缩容。阿里云的 ESS弹性伸缩服务和腾讯云的 AS弹性伸缩都支持基于 GPU 利用率的自动扩缩。但 GPU 实例的启动时间通常在 3-5 分钟所以扩容策略要提前触发不能等负载满了再扩。第五数据安全与合规。如果模型或数据涉及敏感信息需要确认云服务商是否支持私有网络隔离、加密存储、访问审计。这部分不是技术问题但选型时必须考虑。4.3 成本优化的几个实操技巧云 GPU 的成本优化空间很大我总结了几条实际有效的做法用抢占式实例跑离线任务。阿里云和腾讯云都有抢占式 GPU 实例价格是按量实例的 30%-50%但可能被随时回收。适合批量离线推理任务配合 checkpoint 机制被回收了也能续跑。混合使用包年包月和按量实例。基线负载用包年包月峰值负载用按量实例补充。我帮一个团队做过这个方案月度成本降低了 35%。模型量化降低显存需求。把 FP16 量化到 INT8显存占用减半可以用更便宜的实例。精度损失通常在 1%-3% 以内对大多数业务场景可以接受。合理设置自动缩容策略。很多团队的自动缩容太保守导致夜间闲置实例浪费。我一般建议 GPU 利用率低于 20% 持续 10 分钟就缩容高于 70% 持续 5 分钟就扩容。5. 生产级部署流程从零到上线的完整路径5.1 环境准备与基础镜像制作生产级部署的第一步不是装框架而是做一个可复现的基础镜像。我见过太多团队因为环境不一致导致“本地能跑、线上报错”的问题。基础镜像应该包含CUDA 驱动、Python 环境、推理框架、监控 agent。一个典型的 Dockerfile 结构FROM nvidia/cuda:12.4.1-runtime-ubuntu22.04 RUN apt-get update apt-get install -y \ python3.11 python3-pip curl git \ rm -rf /var/lib/apt/lists/* RUN pip install --no-cache-dir \ vllm0.6.3 \ prometheus-client \ opentelemetry-api COPY entrypoint.sh /entrypoint.sh RUN chmod x /entrypoint.sh ENTRYPOINT [/entrypoint.sh]几个细节值得注意基础镜像用runtime而不是devel体积小很多生产环境不需要编译工具。Python 版本锁定在 3.11vLLM 对 3.12 的支持在 2026 年初还有问题。推理框架版本必须锁定不能写latest否则某天自动更新可能引入不兼容的变更。监控 agent 提前装好不要等上线了再补。5.2 模型加载与预热策略模型加载是部署过程中最耗时的环节。一个 70B 的模型从磁盘加载到 GPU 显存通常需要 3-8 分钟取决于存储速度和模型格式。优化模型加载速度的几个方法使用 safetensors 格式。比 PyTorch 的 pickle 格式加载快 30%-50%而且更安全。模型文件放在本地 NVMe SSD 上。如果用的是云实例把模型文件从对象存储拉到本地 SSD 再加载比直接从 NAS 加载快 2-3 倍。预热请求。服务启动后先发几个预热请求把 KV Cache 和 CUDA kernel 都初始化好再接入正式流量。预热请求可以用固定长度的输入比如 512 token 的填充文本。import requests def warmup(base_url, num_requests5): for i in range(num_requests): payload { model: llama-3-70b, prompt: 预热请求 * 100, max_tokens: 32, temperature: 0.0 } requests.post(f{base_url}/v1/completions, jsonpayload)预热请求的数量不用太多5-10 个就够了。关键是让 CUDA kernel 完成 JIT 编译后续请求的延迟会稳定很多。5.3 负载均衡与请求路由单实例的推理服务总有容量上限生产环境需要多实例负载均衡。大模型推理的负载均衡和普通 Web 服务不太一样有几个特殊考量请求长度差异大。一个 100 token 的请求和一个 8000 token 的请求处理时间可能差 50 倍。简单的轮询负载均衡会导致某些实例排队严重。KV Cache 状态。如果开启了 prefix caching相同 system prompt 的请求路由到同一实例能命中缓存减少计算。实例健康检查。GPU 实例可能出现显存泄漏、CUDA 错误等问题健康检查不能只检查 HTTP 端口还要检查 GPU 状态。我一般用 Nginx 做第一层负载均衡配合自定义的 upstream 健康检查脚本upstream vllm_backend { least_conn; server 10.0.1.10:8000 max_fails3 fail_timeout30s; server 10.0.1.11:8000 max_fails3 fail_timeout30s; server 10.0.1.12:8000 max_fails3 fail_timeout30s; }least_conn策略比轮询更适合推理服务因为它会把新请求发给当前连接数最少的实例。但更好的做法是基于请求队列长度做路由这需要自己写一个简单的路由层。5.4 监控体系与告警配置生产级部署没有监控就是裸奔。大模型推理服务的监控指标比普通服务多一层 GPU 相关的指标。我通常监控以下几类指标类别具体指标告警阈值说明GPU 硬件GPU 利用率持续90% 或 10%过高可能排队过低可能浪费GPU 硬件GPU 显存使用率95%接近 OOM 风险GPU 硬件GPU 温度85°C散热问题推理性能首 token 延迟 P992s用户体验下降推理性能token 间延迟 P99100ms流式体验变差推理性能请求队列长度10需要扩容服务健康请求错误率1%可能模型或框架异常资源实例数量低于最小值缩容过度Prometheus Grafana 是标配vLLM 和 TGI 都内置了 Prometheus metrics 端点。GPU 指标需要额外部署 DCGM Exporterdocker run --gpus all -d \ -p 9400:9400 \ nvcr.io/nvidia/k8s/dcgm-exporter:3.3.0-3.2.0-ubuntu22.04告警配置有几个经验首 token 延迟的告警阈值不要设太紧因为大模型推理本身就有波动GPU 利用率的告警要区分“持续高”和“瞬时高”瞬时高是正常的请求队列长度的告警最灵敏通常是最早发现容量不足的指标。5.5 灰度发布与回滚机制模型更新或框架升级时不能直接全量替换。灰度发布的流程新版本实例部署到独立的实例组不接入正式流量。用内部测试流量验证新版本的功能和性能。将 5% 的正式流量切到新版本观察 30 分钟。逐步增加流量比例5% → 20% → 50% → 100%。每一步都检查错误率、延迟、GPU 指标。回滚机制要提前准备好。最直接的方式是保留旧版本的镜像和模型文件回滚时把负载均衡的流量切回去。回滚时间应该控制在 5 分钟以内。我踩过的一个坑有一次模型更新后新版本在短请求上表现正常但长请求超过 4000 token的延迟暴涨。灰度阶段只测了短请求全量后才发现问题。所以灰度验证的请求分布要覆盖真实流量的分布不能只测简单 case。6. 常见问题与排查技巧实录6.1 显存相关问题的排查问题一启动时报 CUDA out of memory。这是最常见的问题。排查顺序确认模型权重的显存占用是否超过 GPU 容量。用nvidia-smi查看 GPU 总显存对比模型参数量 × 精度字节数。检查是否有其他进程占用显存。nvidia-smi会列出所有 GPU 进程。降低--gpu-memory-utilization参数从 0.9 降到 0.8 试试。减小--max-model-len降低 KV Cache 的预留空间。问题二运行一段时间后 OOM。这种通常是显存碎片化或 KV Cache 泄漏导致的。vLLM 的 PagedAttention 已经很大程度上解决了碎片化问题但长时间运行后仍可能出现。解决办法设置--swap-space参数留出 CPU 内存作为交换空间。配置定期重启策略比如每 24 小时滚动重启一次。监控显存使用率的增长趋势如果持续上升说明有泄漏。问题三多卡推理时显存不均衡。张量并行下每张卡负责模型的一部分显存占用应该大致均衡。如果差异超过 10%可能是模型切分不均匀或者某张卡上有其他进程。检查--tensor-parallel-size是否和实际 GPU 数量一致。6.2 性能不达预期的排查首 token 延迟高。可能的原因请求排队检查队列长度、KV Cache 未命中检查 prefix caching 配置、CUDA kernel 未预热发预热请求。吞吐量低。检查 batch size 是否太小、continuous batching 是否开启、GPU 利用率是否偏低。如果 GPU 利用率低于 50%说明请求调度有问题可能是 batch 组装策略不够激进。token 间延迟抖动大。通常是 GPU 被其他进程抢占或者温度过高降频。检查nvidia-smi的 GPU 利用率和温度曲线。6.3 网络与 API 相关问题请求超时。大模型推理的延迟本身较高客户端超时时间要设置合理。我一般建议首 token 超时设 30 秒总超时设 120 秒。如果经常超时检查是不是请求队列太长。流式返回中断。检查负载均衡的超时配置Nginx 默认的proxy_read_timeout是 60 秒对于长文本生成可能不够。改成 300 秒。并发请求被拒绝。vLLM 默认的并发上限是 256如果超过会返回 503。可以通过--max-num-seqs参数调整但调太高会导致显存不足。6.4 常见问题速查表现象可能原因排查方法解决措施启动 OOM模型太大/显存被占nvidia-smi 查看降精度/减 max-model-len运行中 OOM显存碎片/泄漏监控显存趋势定期重启/加 swap首 token 慢排队/未预热查队列长度扩容/预热吞吐量低batch 太小查 GPU 利用率调大 batch/开 continuous batching流式中断超时配置短查 Nginx 日志调大 proxy_read_timeout多卡不均衡切分不均nvidia-smi 对比检查 tensor-parallel-size请求被拒并发超限查 503 错误调大 max-num-seqs7. 一些实际项目中的经验体会部署大模型这件事技术选型只占 30% 的工作量剩下 70% 是运维和调优。我见过太多团队在框架选型上纠结了两周结果上线后发现真正的瓶颈在存储 IO 和网络带宽上。一个很实际的建议如果你的团队第一次做大模型部署先用 Ollama 在一台开发机上把流程跑通确认模型效果和业务需求匹配再考虑生产级部署。生产级部署的复杂度主要来自高可用、监控、弹性伸缩这些工程问题而不是模型本身。另外模型量化是降低成本最直接的手段。INT8 量化通常能把显存占用减半精度损失在大多数业务场景下可以忽略。如果业务对精度极其敏感可以考虑 AWQ 或 GPTQ 这类更精细的量化方法但需要做充分的评测。最后说一个容易被忽略的点模型版本管理。生产环境跑的模型版本必须和训练、评测时完全一致包括 tokenizer 配置、模型权重、推理参数。我建议用类似 Git LFS 或者专门的模型仓库来管理模型版本每次部署都记录清楚用的是哪个版本。这个习惯在出问题时能帮你快速定位和回滚。