大模型算力基础：GPU 云、推理部署与 API 取舍完全指南
跑大模型不等于买 GPU——推理和训练对算力的要求截然不同，自建集群和调用 API 的综合成本差距可达数倍。本文从推理与训练的本质区别出发，把显存、GPU 选型、主流部署框架和成本权衡一次讲透，帮你在资源投入前做出正确决策。
推理 vs 训练：两种截然不同的算力需求
很多人一听”跑大模型”就想到要买大量 GPU，但这个判断混淆了训练和推理两个场景：
训练是从零开始（或基于预训练权重继续）调整模型参数的过程，需要存储梯度、激活值和优化器状态，显存需求是推理的 3–8 倍，且对 GPU 互联带宽（NVLink、InfiniBand）极为敏感。
推理则是用已有权重生成输出，只需加载权重和 KV 缓存，单卡或少数几卡即可运行主流 7B–70B 模型。绝大多数企业应用场景属于推理，而非训练。
| 维度 | 训练 | 推理 |
|---|---|---|
| 显存占用 | 权重 + 梯度 + 优化器状态 | 权重 + KV Cache |
| 典型 GPU 用量 | 多机多卡（8–数百张） | 单卡到少量多卡 |
| 单位成本压力 | 极高，GPU 小时费用持续计算 | 可按请求量弹性扩缩 |
| 对互联带宽要求 | 极高（张量并行、流水线并行） | 中低（仅批处理调度） |
| 适合自建的场景 | 少数有定制需求的大厂/研究机构 | 有合规/延迟/私有化要求时可考虑 |
结论：如果你的需求是推理，不要用训练的标准衡量算力成本。
自托管 vs 调用 API：两种路径的本质差异
这是目前企业最常面临的决策分岔点。
调用 API 的优势
- 零运维：无需管理 GPU 节点、驱动版本、CUDA 环境、服务宕机处理
- 即用即付：流量低时近乎零成本，不存在”空跑的 GPU 时”
- 模型快速迭代：切换到更好的模型只需改一个参数，无需重新部署
- 全球低延迟：主流 API 提供商已在多地建立推理节点
自托管的优势
- 数据不出本地：金融、医疗、政务等合规场景的刚性要求
- 极高并发下可能更划算：当日均调用量极大且稳定时，专属算力的边际成本更低
- 定制化：可调整系统提示缓存、KV 缓存策略、批处理窗口等底层参数
什么情况下才值得自托管？
一个简化的决策判断：如果你的月均 GPU 计算成本预算超过自托管硬件/租赁的月摊销成本，且你有专职 MLOps 工程师，自托管才具备经济可行性。否则 API 通常是更理性的起点。
详细的账单对比逻辑见 自托管 vs 用 API 怎么算账。
显存：推理的真正瓶颈
推理场景的算力瓶颈几乎永远是显存，而不是计算核心数。
显存需求的近似估算公式
总显存 ≈ 模型权重占用 + KV Cache + 框架开销
模型权重占用（近似）：
权重显存(GB) ≈ 参数量(B) × 每参数字节数
| 精度格式 | 每参数字节数 | 7B 模型权重占用 | 70B 模型权重占用 |
|---|---|---|---|
| FP32（全精度） | 4 字节 | ~28 GB | ~280 GB |
| BF16 / FP16 | 2 字节 | ~14 GB | ~140 GB |
| INT8（量化） | 1 字节 | ~7 GB | ~70 GB |
| INT4 / Q4（量化） | 0.5 字节 | ~3.5 GB | ~35 GB |
KV Cache：随并发请求数和上下文长度线性增长。在 FP16 下，每个 token 的 KV Cache 占用约为 2 × 层数 × 头维度 × 2 字节，高并发场景下可与权重相当。
框架开销：通常 1–4 GB，可视为固定项。
拿一次真实场景算一遍，别只背公式
光记公式没用，你得代进真实数字里跑一遍，才知道自己那张卡到底够不够用。假设你要跑一个 7B 模型，BF16 精度，权重占用按 14GB 算。你的业务场景是客服问答，平均单次会话上下文在 4K token 左右，同时要撑住 8 路并发（也就是同时有 8 个用户在等回复）。
KV Cache 这块最容易被低估。它不是一个固定数字，而是跟着「并发数 × 上下文长度」线性往上涨的。你可以把它想象成每个正在处理的请求都要单独占一块”草稿纸”，请求越多、每个请求要记的东西越多，草稿纸就摊得越大。如果按照前面给的近似公式估算，8 路并发、4K 上下文，7B 模型的 KV Cache 大概会额外吃掉 4–6GB 显存——这还只是”正在处理”的部分，一旦你把最大上下文长度设到 32K，同样 8 路并发，KV Cache 能直接顶到 20GB 以上，比权重本身还重。
这就是为什么很多人拿着 24GB 的消费卡，本地跑单轮对话感觉丝滑，一上生产环境开高并发就直接爆显存——不是模型选错了，是没把 KV Cache 这块账算进去。实操建议：先按你业务的”最大可能并发数 × 最大可能上下文长度”去估 KV Cache，而不是按平均值估，因为显存溢出是硬性错误（OOM），不会优雅降级，一旦触发就是直接崩服务。
实际选型经验
- 跑 7B 模型（INT4）：消费级 8–12 GB 显存卡基本够用
- 跑 13B–14B 模型（INT4）：需要 16 GB 以上
- 跑 70B 模型（INT4）：需要 40 GB 以上，通常要多卡
- 跑 70B 模型（BF16）：单卡 A100 80GB 刚好，或两张 40GB 卡张量并行
显存详细估算见 跑大模型要多少显存。
主流推理部署框架概览
选框架影响吞吐量、延迟和运维复杂度。
| 框架 | 核心优势 | 典型适用场景 |
|---|---|---|
| vLLM | PagedAttention 技术，极高吞吐，支持主流开源模型 | 生产级高并发推理，首选 |
| Ollama | 开箱即用，一行命令拉起模型 | 本地开发测试，不适合生产 |
| llama.cpp | 纯 CPU/轻量 GPU 运行，量化支持完善 | 边缘设备或无 GPU 环境 |
| TGI（Hugging Face） | 与 HF Hub 生态无缝集成，支持多种量化 | 已有 HF 工作流的团队 |
| SGLang | 激进的前缀缓存与批处理优化，延迟更低 | 延迟敏感的 Agent 场景 |
| TensorRT-LLM | NVIDIA 官方，极致 GPU 利用率 | 大规模 NVIDIA 集群 |
vLLM 是目前生产环境使用最广泛的框架，对 Llama、Qwen、Mistral、Gemma 等主流架构均有良好支持，API 兼容 OpenAI 协议，可无缝切换。
vLLM 部署几个绕不开的坑
真正上手部署时，光知道”vLLM 吞吐高”没用，下面这几个参数不摸清楚，十有八九第一次启动就翻车。
gpu_memory_utilization 这个参数一定要手动调。 vLLM 默认会尝试占满显卡显存的 90% 用来做 KV Cache 预分配，这在共享 GPU 或者卡上还跑着别的进程时会直接把别的服务挤爆。如果你看到报错里出现类似 CUDA out of memory. Tried to allocate ... 的字样，第一反应不是去换更大的卡，而是先检查这个参数有没有设置得过于激进——把它从默认值调低到 0.7–0.8，往往就能腾出足够的余量。
max_model_len 设置过大会在启动阶段直接报错拒绝加载，报错信息通常类似”The model’s max seq len is larger than the maximum number of tokens that can be stored in KV cache”。根因很简单：你告诉框架”我要支持 32K 上下文”，但按当前显存和并发设置根本分配不出这么多 KV Cache 空间。修法有两条路：要么调低 max_model_len 匹配实际业务需求（多数客服/问答场景 8K 完全够用，别为了”以防万一”设成 32K），要么增加显卡或降低并发上限。
批处理调度不是并发数越高越好。 vLLM 的连续批处理（continuous batching）机制会自动把多个请求打包处理以提升吞吐，但如果你把并发上限设得远超显存承载能力，表现出来不是报错，而是每个请求的延迟显著变长——因为请求在排队等显存腾空间。如果你发现线上 P99 延迟突然从 2 秒涨到 10 秒以上，且 GPU 利用率长期顶在 95%+，这通常就是并发设置超出了硬件承载上限的信号，该做的是降并发上限或者加卡，而不是去优化代码逻辑。
成本权衡：如何在三个维度做取舍
算力决策本质上是在以下三个维度之间权衡：
成本 ←——→ 延迟 ←——→ 灵活性
| 场景 | 推荐路径 | 理由 |
|---|---|---|
| 初创/原型验证 | API 优先 | 无需预付，快速迭代，运维零负担 |
| 稳定高并发（日均百万请求+） | 评估自托管 | 边际成本可能低于 API，但需 MLOps 团队 |
| 合规/私有化要求 | 私有化部署 | 数据不出域，无讨论空间 |
| 混合场景（大部分轻量+少量重量） | API 路由 + 模型分级 | 轻任务用小模型便宜 API，重任务用旗舰 |
容易被忽视的隐性成本
- 人力成本：自托管需要专职 MLOps，按实际工资折算往往高于 API 费用差
- 空跑成本：流量波动时，自建 GPU 节点的闲置时间都是真实支出
- 升级成本：模型版本更新时自托管需要重新下载权重、测试、重新部署
常见问题
推理需要哪种 GPU？
消费卡（RTX 系列）显存较小，适合 7B 以下小模型个人实验；专业卡（A100、H100、H20 等）ECC 内存更稳定、显存更大，适合生产级多并发推理。价格差距通常在 5–20 倍以上。
量化会影响模型效果吗？
INT8 基本无感知损失，INT4 在部分推理任务上有轻微下降，但对对话、摘要等常见场景影响有限。GPTQ、AWQ、GGUF 等主流量化方案均有大量社区验证。
vLLM 和 Ollama 哪个适合我？
如果你在本地测试或个人使用，Ollama 简单够用；如果你要部署面向用户的服务，需要处理并发请求，vLLM 是正确选择。
多大并发量才值得自托管？
没有通用答案，核心是对比”自托管月总成本（硬件摊销+带宽+人力）“与”同等调用量的 API 费用”，前者低于后者且业务稳定才有意义。
延伸阅读：
- 详细账单对比：自托管 vs 用 API 怎么算账
- 显存估算详解：跑大模型要多少显存
- 算力专题 Hub：算力专题
- 想省去部署烦恼直接调用？加入候补，体验接入即用服务