LLM 推理基础设施规划：GPU 选型、容量设计与成本优化

欢迎使用Markdown编辑器

你好！ 这是你第一次使用# LLM 推理基础设施规划：GPU 选型、容量设计与成本优化

一、为什么推理基础设施规划如此困难

当一个 AI 应用从原型走向生产，团队迟早要面对一个棘手的问题：该买多少 GPU？买什么型号？部署在哪里？这个问题之所以困难，是因为它交织着延迟目标、模型选择、流量模式和预算约束等相互矛盾的变量。更麻烦的是，几乎没有团队敢拍胸脯说"我的容量规划是准的"——流量预测本身就充满不确定性，而 GPU 采购周期长、成本高昂，错了很难回头。

许多团队的第一反应是"买最贵的卡、买最多的卡"，结果发现利用率长期徘徊在低位，成本失控。另一些团队则走向反面，一切用云端按需实例，结果流量高峰时延迟飙升、账单爆炸。真相是：推理基础设施规划远不止"每秒 Token 数"这么简单，它是一套从业务场景出发、逐层推导的系统工程。本文提供一套可执行的规划框架，帮助团队把使用场景映射到合适的 GPU 配置。

二、第一步：明确你的工作负载类型

一切规划的起点是回答一个看似简单却至关重要的问题：你在解决什么问题？不同使用场景对应截然不同的基础设施配置。业界通常把推理工作负载归为四类：

对话与 Copilot 场景。用户与 AI 助手交互，特点是交互式、对延迟敏感、请求较短。这类负载的核心指标是 TTFT（首 Token 延迟），用户等待超过一两秒就会流失。

Agent 与深度推理场景。智能体执行多步骤任务，特点是长上下文、多次工具调用、输入输出序列都很长。这类负载的 KV Cache 需求极大，对内存带宽和容量提出双重挑战。

内容生成场景。文章、代码、营销文案的批量生成，特点是请求量大、对延迟容忍度高、输出长。这类负载适合最大化吞吐的配置，延迟优化不是重点。

翻译与格式化场景。结构化转换任务，特点是输入输出比例固定、对格式要求严格。这类负载相对轻量，可以用较小模型 + 较大的并发配置。

工作负载类型决定了后续所有决策的方向：延迟敏感的选低延迟优先配置，吞吐优先的选大 batch 配置，长上下文的选大显存配置。跳过这一步直接选 GPU，等于蒙着眼睛开车。

三、第二步：用六个维度量化需求

确定了工作负载类型后，用以下六个维度把模糊的需求量化为具体的数字。

并发与 QPS。并发数（同时处理的请求数）比日活用户数更能反映基础设施压力。需要评估：DAU 是多少、高峰时段的并发峰值是多少、每个用户每小时的请求频率。公式很简单：并发需求 ≈ 峰值 QPS × 单请求平均处理时间。

输入/输出序列长度。这是最容易被低估的维度。输入越长，预填充阶段的算力消耗越大；输出越长，解码阶段的 KV Cache 占用越大。Agent 工作流的序列长度往往是普通对话的数倍甚至数十倍，规划时必须按最坏情况估算。

KV Cache 命中率。如果系统做了前缀缓存或语义缓存，部分请求可以跳过重复计算。命中率越高，实际需要的 GPU 算力越少。对话和 Agent 场景天然有较高的前缀复用率，善用缓存能显著降低容量需求。

延迟指标。需要明确的延迟目标：TTFT 的 P50/P99 是多少？每秒输出多少 Token 可接受？不同场景的延迟敏感度差异巨大，规划时必须把"业务可接受的延迟"翻译成"需要多少算力"。

Token 吞吐与成本预算。单卡能提供多少 Token 吞吐、单位 Token 的成本是多少，这是把需求翻译成 GPU 数量的桥梁。不同型号显卡的吞吐能力差异可达数倍，成本差异更是巨大。

模型选择。模型大小直接决定显存需求。7B 模型单卡可跑，70B 模型需要多卡并行，百B 以上模型进入集群范畴。选型原则是"满足质量要求的最小模型"——微调一个小模型往往比部署一个大模型更划算。

四、第三步：GPU 选型与容量计算

量化了需求，就可以进入 GPU 选型环节。这里提供一套经验性的决策框架：

先算显存，再算算力。模型推理的显存需求 = 模型权重 + KV Cache + 运行时开销。以 7B 模型 FP16 为例，权重约 14GB，加上 KV Cache 和运行开销，单卡 24GB 起步。70B 模型 FP16 需要约 140GB 权重，通常用 2 到 4 张 80GB 卡张量并行。显存决定了"能不能跑"，算力决定了"跑多快"。

用量化扩大单卡容量。INT8 量化把显存需求减半，INT4 减到四分之一。量化的价值不仅是省显存，更是在相同显存下容纳更多并发请求，直接改善单卡的经济性。代价是精度损失，需要在业务数据上验证。

吞吐与延迟的平衡。追求吞吐选大 batch 配置和更大的算力卡；追求低延迟选小 batch 和更高主频的卡。没有全能卡，只有适合特定工作负载的卡。

容量计算用"峰值 + 缓冲"。用高峰时段的并发需求计算基准容量，在此基础上加 20% 到 30% 的缓冲应对流量波动，再考虑故障冗余。容量规划宁可略有余量，也不要捉襟见肘——推理服务的降级体验是用户无法接受的。

五、第四步：本地与云端的容量组合

GPU 采购决策还涉及一个关键问题：自建还是上云？成熟的方案几乎都是"核心 + 弹性"的组合。

核心容量本地化。对于流量稳定、可预测的基线负载，用本地部署或长期合约锁定价格，单位成本更低。这类负载的特征是：日间波动有规律、预测性强、利用率可以保持较高水平。

弹性容量云端化。对于流量波动大、不可预测的峰值负载，用云端按需实例或 Spot 实例弹性扩容。高峰拉起、低谷释放，避免了为一年只用几次的峰值流量支付全年成本。

探索期用云。项目早期需求不明确、模型迭代频繁，用云端按需实例灵活试错。当需求稳定、模型定型后，再把核心负载迁移到成本更优的方案。很多团队的错误是在探索期就大举采购硬件，结果模型一换，硬件全废。

六、第五步：持续优化 TCO 的六个手段

基础设施上线只是开始，持续的成本优化才是长期命题。以下是六个被验证有效的优化手段：

模型优化先行。量化、剪枝、知识蒸馏是降本的源头手段。知识蒸馏用大模型训练小模型，让小模型在特定任务上逼近大模型的效果，是"降本不降质"的典范。

缓存最大化。前缀缓存 + 语义缓存双管齐下。对话场景启用前缀缓存，FAQ 类场景启用语义缓存，能把实际算力需求降低可观的比例。

批处理调优。通过 vLLM 等框架的连续批处理把 GPU 利用率拉满。很多时候不是 GPU 不够，而是利用率太低——同样的卡，利用率从 40% 提到 80%，等于成本减半。

负载整形。对非实时任务（批量生成、离线分析）做错峰调度，避开高峰时段的算力竞争，让基础设施全天候平稳运行。

实例规格审计。定期检查每个实例的利用率，把长期低利用率的实例降配或合并，把超负荷的实例升级。实例规格与负载的匹配度是 TCO 优化的高频抓手。

监控驱动决策。建立 GPU 利用率、TTFT、P99 延迟、Token 成本四类核心指标的监控看板。容量决策、选型决策、优化决策，都以数据为依据，而不是靠感觉。

六、案例复盘：一次完整的容量规划过程

用一个简化的案例演示整套框架如何运转。假设要上线一个面向企业用户的文档问答助手，模型选择 7B 级开源模型（FP16 权重约 14GB），预期 DAU 一万，高峰时段约 5% 的日活用户同时在线使用，每个用户高峰期的请求频率约每分钟 1 次，单次请求平均处理时间（含检索与生成）约 5 秒。

先算并发：峰值并发 ≈ 10000 × 5% × 1 / 60 × 60 秒 ≈ 每小时峰值请求 5000 次，换算成同时处理中的请求约为 5000 / 3600 × 5 ≈ 7 个并发。这个数字看起来不大，但每个请求的上下文约 2K Token、输出约 1K Token，单卡在给定延迟目标下大约能同时处理 4 到 8 个此类请求。于是得到初步结论：单卡（INT8 量化后）即可满足常规负载，加上 30% 的流量缓冲，初期部署 2 张卡（一主一备或负载分担）是稳妥选择，同时保留云端按需实例作为流量突增时的弹性补充。

再用成本视角复核：如果乐观预测 DAU 半年后翻三倍，并发需求约 21，单卡不够，需要提前评估多卡张量并行或升级模型量化方案。此时"核心本地 + 弹性云端"的组合就体现出价值——本地两卡覆盖基线，云端实例承接增量，避免了为半年后的规模提前买断硬件。整个决策链路从业务数字出发，经过量化计算落到具体配置，每一步都有据可查，这就是规划方法论的意义。

这个案例提醒我们：容量规划的精度不取决于公式多复杂，而取决于你对业务数字的把握有多准。与其纠结参数的精细度，不如把 DAU、请求频率、序列长度这几个关键假设调查清楚——它们对结论的影响，远超计算公式本身的差异。

七、规划不是一次性的，而是一个循环

最后要强调的是：推理基础设施规划不是一次性的项目，而是一个持续的循环。需求在变、模型在变、技术在变——今天的最优解，三个月后可能就不再最优。正确的姿态是：建立一套可重复的规划方法论，让每次调整都有数据支撑；保持架构的弹性，让容量可以平滑伸缩；把成本优化当作常态化工作，而不是上线前的突击任务。

回顾整套框架：从工作负载分类出发，用量化维度锁定需求，经 GPU 选型与容量计算落到配置，通过本地与云端组合控制成本，再以持续优化形成闭环——这五个步骤构成了一条从业务到硬件的完整链路。AI 应用的竞争，不只是模型能力的竞争，也是工程成本的竞争。把推理基础设施规划做扎实，就是为你的 AI 业务装上了一个既跑得快、又花得省的引擎。

Markdown编辑器所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章，了解一下Markdown的基本语法知识。

新的改变

我们对Markdown编辑器进行了一些功能拓展与语法支持，除了标准的Markdown编辑器功能，我们增加了如下几点新功能，帮助你用它写博客：

1. 全新的界面设计，将会带来全新的写作体验；
2. 在创作中心设置你喜爱的代码高亮样式，Markdown将代码片显示选择的高亮样式进行展示；
3. 增加了图片拖拽功能，你可以将本地的图片直接拖拽到编辑区域直接展示；
4. 全新的KaTeX数学公式语法；
5. 增加了支持甘特图的mermaid语法¹功能；
6. 增加了多屏幕编辑Markdown文章功能；
7. 增加了焦点写作模式、预览模式、简洁写作模式、左右区域同步滚轮设置等功能，功能按钮位于编辑区域与预览区域中间；
8. 增加了检查列表功能。

功能快捷键

撤销：Ctrl/Command+Z
重做：Ctrl/Command+Y
加粗：Ctrl/Command+B
斜体：Ctrl/Command+I
标题：Ctrl/Command+Shift+H
无序列表：Ctrl/Command+Shift+U
有序列表：Ctrl/Command+Shift+O
检查列表：Ctrl/Command+Shift+C
插入代码：Ctrl/Command+Shift+K
插入链接：Ctrl/Command+Shift+L
插入图片：Ctrl/Command+Shift+G
查找：Ctrl/Command+F
替换：Ctrl/Command+G

合理的创建标题，有助于目录的生成

直接输入1次#，并按下space后，将生成1级标题。
输入2次#，并按下space后，将生成2级标题。
以此类推，我们支持6级标题。有助于使用TOC语法后生成一个完美的目录。

如何改变文本的样式

强调文本强调文本

加粗文本加粗文本

标记文本

删除文本

引用文本

H₂O is是液体。

2¹⁰运算结果是 1024.

插入链接与图片

链接: link.

图片:

带尺寸的图片:

居中的图片:

居中并且带尺寸的图片:

当然，我们为了让用户更加便捷，我们增加了图片拖拽功能。

如何插入一段漂亮的代码片

去博客设置页面，选择一款你喜欢的代码片高亮样式，下面展示同样高亮的代码片.

// An highlighted blockvarfoo='bar';

生成一个适合你的列表

• 项目
  • 项目
    • 项目

1. 项目1
2. 项目2
3. 项目3

• 计划任务
• 完成任务

创建一个表格

一个简单的表格是这么创建的：

设定内容居中、居左、居右

使用:---------:居中
使用:----------居左
使用----------:居右

SmartyPants

SmartyPants 是一个文本转换工具，主要功能是将普通的 ASCII 标点符号自动转换为更美观的印刷体标点符号。例如：

创建一个自定义列表

Markdown

Text-to-HTMLconversion tool

Authors

John

Luke

如何创建一个注脚

一个具有注脚的文本。²

注释也是必不可少的

Markdown将文本转换为HTML。

KaTeX数学公式

您可以使用渲染LaTeX数学表达式 KaTeX:

Gamma公式展示Γ ( n ) = ( n − 1 ) ! ∀ n ∈ N \Gamma(n) = (n-1)!\quad\forall n\in\mathbb NΓ(n)=(n−1)!∀n∈N是通过欧拉积分

Γ ( z ) = ∫ 0 ∞ t z − 1 e − t d t . \Gamma(z) = \int_0^\infty t^{z-1}e^{-t}dt\,.Γ(z)=∫0∞​tz−1e−tdt.

你可以找到更多关于的信息LaTeX数学表达式here.

新的甘特图功能，丰富你的文章

• 关于甘特图语法，参考 这儿,

UML图表

可以使用UML图表进行渲染，例如下面产生的一个序列图：

• 关于UML图表语法，参考 这儿,

流程图

• 关于Mermaid语法，参考 这儿,

FLowchart流程图

我们依旧会支持flowchart.js的流程图语法：

• 关于Flowchart流程图语法，参考 这儿.

导出与导入

导出

如果你想尝试使用此编辑器, 你可以在此篇文章任意编辑。当你完成了一篇文章的写作, 在上方工具栏找到文章导出，生成一个.md文件或者.html文件进行本地保存。

导入

如果你想加载一篇你写过的.md文件，在上方工具栏可以选择导入功能进行对应扩展名的文件导入，
继续你的创作。