大模型部署硬件资源计算方法
本文主要研究大模型部署过程中硬件资源（如 GPU 显存、服务器内存）的计算方法。文章先介绍大模型计算涉及的必要参数，再给出详细的计算过程和计算示例。
单位与口径约定 ：本文所有容量计算统一按 1 GB = 10910^9109 字节 计算（十进制，非 GiB）。显卡容量沿用厂商标称值（如 A100 80GB 实为 80 GiB ≈ 85.9 GB 字节），因此涉及"剩余显存"的结论按标称值粗算，实际可用字节数会略多约 7%。框架开销统一按 10%~20% 预留，示例取 15%；推理显存按 Decode 稳态激活计算，Prefill 峰值激活另作校验。
小白速览 ：这篇文章帮你回答一个问题------「我想部署一个大模型，需要买什么样的显卡和服务器？」。你不需要看懂所有公式，只需记住四个结论：① 模型越大越吃显存（7B 级一张普通卡就够，70B 级要好几张专业卡）；② 人越多越吃带宽（并发高就要上专业卡）；③ 先定场景、再定速度标准------聊天 30 tokens/s 就流畅，代码生成要 60+，Agent 还要按步数叠加，行内补全则只看总延迟（< 300 ms）；④ 预算有限就选小模型 + 量化（INT8），能省一半显存。下面各章会逐步展开，看不懂公式时直接看每章的「说明」和最后的「一句话评估」即可。
1. 基础概念介绍
- 模型权重： 模型在训练过程中学到的、决定输入转变成输出的全部数值参数（如矩阵、偏置和缩放因子），是模型推理时必须常驻或按需加载的数据，决定了模型能否装下、跑多快，以及量化后精度损失多少
- 参数量（Parameters）： 模型包含的全部可学习参数个数，通常以 B（十亿）为单位，如 7B、70B。它是显存占用和计算量的核心驱动因素，直接决定模型权重所需存储空间。
- 层数（Number of Layers）： Transformer 的堆叠层数。总参数量、计算量和 KV Cache 均与层数近似线性相关。
- 中间层维度（Hidden Size / Intermediate Size）： 每层 Transformer 的隐藏维度和 FFN 中间维度。它们与层数共同决定单层参数量，是计算总参数和激活值的基础。
- 词表大小（Vocabulary Size）： 词表包含的 token 种类数。它决定 embedding 层和输出层的参数量，在 7B 级模型中通常占数亿参数，不可忽略。
- 序列长度（Sequence Length）： 输入文本的 token 数量。KV Cache 显存与序列长度呈线性关系 （见下文 KV Cache 条目）；Prefill 阶段的注意力计算量与序列长度呈平方关系。二者不可混为一谈------常驻显存的是前者且线性增长，后者只影响计算且可用 FlashAttention 规避其显存平方项。它是估算 KV Cache 和计算量的关键参数。
- 上下文窗口（Context Window）： 模型一次能处理的最大 token 数。它决定了 KV Cache 的上限，也影响部署时的显存规划。
- KV Cache： 推理时为避免重复计算而缓存的历史 Key/Value 张量。其显存占用约等于
2 × 层数 × KV头数 × 头维度 × 序列长度 × 每参数字节，是长上下文推理显存估算的主要部分。 - 激活值（Activations）： 前向传播过程中各层产生的中间张量。训练时需保存用于反向传播，显存占用可能超过权重本身；推理时通常逐层计算、无需常驻，但会显著影响计算吞吐。
- 批大小（Batch Size）： 单次前向/反向传播同时处理的样本数。批大小越大，总吞吐越高------权重显存不变，随 batch 线性增长的只有 KV Cache 与激活值。正是「权重读取成本被多请求摊薄」这一点，使批处理成为提升总吞吐的首要手段（见 4.3、4.4 节）。
- 显存带宽： 显卡在单位时间内能传输多少数据，直接决定了模型在计算过程中数据的搬运速度；
- 计算吞吐： 处理器或系统在单位时间内能完成的运算次数，常用 FLOP/s、FLOPS 表示。FLOP/s 是速率单位，1 TFLOPS = 101210^{12}1012 FLOP/s ；FLOPs 是运算总次数；GFLOPs 表示十亿次运算、TFLOPs 表示万亿次运算；GFLOP/s（GFLOPS）表示每秒十亿次运算；TFLOP/s（TFLOPS）表示每秒万亿次运算。
- 推理吞吐与延迟（Throughput / Latency）： 推理吞吐指单位时间处理的 token 数（tokens/s），延迟指单个请求的响应时间。二者是部署规格选型时权衡算力与显存的核心指标。注意与上一条「计算吞吐」（FLOP/s，指运算速率）区分，两者单位与含义均不同。
- 张量并行度 / 流水线并行度（TP / PP）： 分布式部署时把模型切分到多张卡的方式。它们影响单卡显存占用和通信开销，是集群资源规划的重要参数。
- 量化： 把原本用较高精度的数值（如 FP32、BF16），转换成用较少位数表示的格式（如 INT8、INT4），以减小存储开销与带宽压力 、加速计算，代价是引入一定精度损失。严格区分：FP32 / BF16 / FP16 属于数值精度 ，INT8 / INT4 / FP8 / FP4 属于量化 ；TF32 是一种张量核计算格式（仅改变计算过程，权重存储仍为 32 bit，不减小显存），不属于量化。
常见数值精度与量化格式对比如下：
| 量化格式 | 每参数字节 | 符号/指数/位数 | 特点 | 用途 |
|---|---|---|---|---|
| FP32 | 4 字节 | 1/8/23 | 精度最高，通用计算标准，显存占用大 | 训练基准、精度要求高的场景 |
| TF32 | 4 字节（仅计算时，权重存储不变） | 1/8/10 | 截断尾数位，精度略低于 FP32，吞吐更高 | NVIDIA Ampere 及之后架构的加速训练（需显式开启，非默认） |
| BF16 | 2 字节 | 1/8/7 | 与 FP32 同指数范围，尾数少，适合大数值范围 | 大模型训练、混合精度训练 |
| FP16 | 2 字节 | 1/5/10 | 动态范围窄，易溢出，但吞吐高 | 混合精度训练、推理加速 |
| FP8 | 1 字节 | 1/4/3 或 1/5/2 | 吞吐高，精度有限，需配合缩放 | 新一代硬件上的训练与推理加速 |
| FP4 | 0.5 字节 | 1/2/1（E2M1，另有 E1M2 / E3M0 变体） | 极低精度，显存占用极小 | 极限压缩场景、边缘部署 |
| INT8 | 1 字节 | 1/0/7 | 整数表示，推理加速明显，精度损失可控 | 推理量化、部署优化 |
| INT4 | 0.5 字节 | 1/0/3 | 压缩比高，精度损失较大 | 大模型压缩、显存受限场景 |
2. 常见显卡参数
部署大模型时，显卡的显存容量、显存带宽、算力（FLOPS）以及多卡互联方式直接决定了能否装下模型、跑多快、能否横向扩展。下面按消费卡、专业卡（数据中心卡）和国产卡三类介绍常见型号的关键参数。
小白怎么选：不用记参数，记住「显存决定装不装得下，带宽决定跑得快不快」即可。个人用、人少 → 消费卡（RTX 4090 这类）够用；公司用、人多 → 专业卡（A100/H100）更稳；国产卡适合信创/私有化，但要先确认软件生态是否支持你要用的模型。
2.1 消费级显卡（NVIDIA GeForce / RTX）
消费卡性价比高、生态成熟，适合个人开发、小规模推理和微调实验。主要短板是显存带宽相对专业卡偏低，且多卡互联（NVLink）通常被禁用，只能走 PCIe。
| 型号 | 显存容量 | 显存带宽 | FP32 算力（CUDA 核） | 互联方式 | 适用场景 |
|---|---|---|---|---|---|
| RTX 4090 | 24 GB GDDR6X | ≈ 1.0 TB/s | ≈ 82.6 TFLOPS | PCIe 4.0 x16（无 NVLink） | 7B 级模型推理、LoRA 微调 |
| RTX 4080 Super | 16 GB GDDR6X | ≈ 736 GB/s | ≈ 51 TFLOPS | PCIe 4.0 x16 | 7B 级模型轻量推理 |
| RTX 3090 | 24 GB GDDR6X | ≈ 936 GB/s | ≈ 35.6 TFLOPS | PCIe 4.0 x16（无 NVLink） | 二手性价比之选，7B~13B 推理 |
| RTX 4060 Ti 16GB | 16 GB GDDR6 | ≈ 288 GB/s | ≈ 22 TFLOPS | PCIe 4.0 x8 | 入门级 7B 量化推理 |
算力口径说明 ：上表数值为 FP32（CUDA 核，非张量核） 峰值；而 2.2 节专业卡列的 312 / 989 / 362 TFLOPS 是张量核 BF16/FP16 稠密 峰值，两者口径不同，不可直接横向比较。若统一按张量精度衡量，消费卡的 FP16/BF16 算力约为表中 FP32 值的 2 倍（如 RTX 4090 ≈ 165 TFLOPS）。
说明：消费卡显存带宽普遍在 0.3~1.0 TB/s 量级，远低于专业卡。正如第四章 4.3 节的带宽校验所示，带宽往往是推理吞吐的瓶颈，因此消费卡更适合低并发、单用户场景。
2.2 专业级显卡（NVIDIA 数据中心卡）
专业卡面向数据中心，显存更大、带宽更高，支持 NVLink 高速互联，是大模型生产部署的主流选择。
| 型号 | 显存容量 | 显存带宽 | FP16/BF16 张量算力（稠密） | 互联方式 | 适用场景 |
|---|---|---|---|---|---|
| A100 40GB | 40 GB HBM2e | ≈ 1.6 TB/s | 312 TFLOPS | NVLink 3.0（600 GB/s）、PCIe 4.0 | 中小规模训练与推理 |
| A100 80GB | 80 GB HBM2e | ≈ 2.0 TB/s | 312 TFLOPS | NVLink 3.0（600 GB/s）、PCIe 4.0 | 32B 级模型推理、LoRA 微调 |
| H100 80GB | 80 GB HBM3 | ≈ 3.35 TB/s | 989 TFLOPS（BF16） | NVLink 4.0（900 GB/s）、PCIe 5.0 | 大模型训练、高吞吐推理 |
| H200 141GB | 141 GB HBM3e | ≈ 4.8 TB/s | 989 TFLOPS（BF16） | NVLink 4.0（900 GB/s）、PCIe 5.0 | 超大模型、长上下文推理 |
| L40S | 48 GB GDDR6 | ≈ 864 GB/s | 362 TFLOPS（FP16） | PCIe 4.0（无 NVLink） | 推理为主、兼顾轻量训练 |
说明：专业卡的核心优势在于高带宽 + NVLink 多卡互联。多卡张量并行（TP）时，卡间通信走 NVLink 可显著降低同步开销；若只有 PCIe，多卡扩展效率会大打折扣。
2.3 国产显卡
国产卡在信创、私有化部署场景中需求增长迅速，生态（驱动、CUDA 兼容层、推理框架适配）仍在完善中。以下为常见型号的公开参数，实际以厂商最新规格为准。
| 型号 | 显存容量 | 显存带宽 | 算力 | 互联方式 | 生态说明 |
|---|---|---|---|---|---|
| 华为昇腾 910B | 64 GB HBM | ≈ 1.6 TB/s | ≈ 376 TFLOPS（FP16） | HCCS（华为自研高速互联） | 支持 MindSpore、PyTorch（通过 CANN 适配） |
| 华为昇腾 310P | 8~24 GB | ≈ 0.3~0.6 TB/s | 推理卡，算力较低 | PCIe | 偏推理场景，常用于边缘/推理服务器 |
| 寒武纪 思元 590 | 64 GB | ≈ 1.2 TB/s | ≈ 200+ TFLOPS（FP16） | 自研互联（MLU-Link） | 支持 PyTorch 部分算子，生态逐步完善 |
| 海光 DCU Z100 | 32 GB HBM2e | ≈ 1.2 TB/s | ≈ 100+ TFLOPS（FP16） | PCIe 4.0 | 兼容 CUDA 生态（ROCm 路线），迁移成本较低 |
| 摩尔线程 MTT S4000 | 48 GB | ≈ 1.0 TB/s | ≈ 100 TFLOPS（FP16） | PCIe 5.0 | 兼容 CUDA 生态，驱动与框架适配中 |
说明：国产卡选型时除看显存与带宽，还需重点评估软件生态成熟度------算子覆盖率、推理框架（vLLM、TensorRT-LLM 等）是否适配、以及多卡互联的通信库是否完善，这些往往比硬件参数更影响落地效率。
3. 常见开源模型参数与选型
企业私有化部署时，通常优先选择开源权重、可商用（或宽松许可）的模型。下面按参数量级整理几类主流模型的核心参数，便于结合第二章的显卡参数做选型。
小白怎么选 ：模型参数越大，能力越强但也越贵。7B 级（约 15 GB）适合日常对话、单卡就能跑；14B~34B 级（约 29~68 GB）适合质量要求更高的场景，需要专业卡；70B 级（约 141 GB）能力最强，但要多卡部署，成本高。预算有限就从 7B 或 14B 起步，够用就好。
3.1 7B~9B 级模型
| 模型 | 参数量 | 上下文窗口 | 每参数精度（典型） | 权重显存（BF16） | 适用场景 |
|---|---|---|---|---|---|
| Llama 3.1 8B | 8.03B | 128K | BF16（2 字节） | ≈ 16 GB | 通用对话、轻量推理、单卡部署 |
| Qwen2.5 7B | 7.6B | 128K | BF16（2 字节） | ≈ 15 GB | 中文场景、函数调用、Agent |
| Mistral 7B | 7.3B | 32K | BF16（2 字节） | ≈ 15 GB | 英文对话、代码生成 |
说明：7B 级模型权重在 BF16 下约 15~16 GB，单张 24 GB 消费卡（如 RTX 4090）即可运行；INT8 量化后可进一步降到约 8 GB，16 GB 显存也能跑。
3.2 13B~34B 级模型
| 模型 | 参数量 | 上下文窗口 | 每参数精度（典型） | 权重显存（BF16） | 适用场景 |
|---|---|---|---|---|---|
| Qwen2.5 14B | 14.7B | 128K | BF16（2 字节） | ≈ 29 GB | 中文通用、代码、数学 |
| Qwen3-32B | 32.8B | 40K（原生）/ 128K（YaRN 扩展） | BF16（2 字节） | ≈ 66 GB | 高质量中文生成、复杂推理（本文主示例模型） |
| Yi-34B | 34B | 200K | BF16（2 字节） | ≈ 68 GB | 长上下文、中文优化 |
| DeepSeek-V2-Lite（MoE） | 15.7B（激活 2.4B） | 128K | BF16（2 字节） | ≈ 31 GB | 低激活参数、高性价比 |
说明：14B 级模型 BF16 权重约 29 GB，单张 40 GB 专业卡可跑；32B 级约 66 GB，需 80 GB 单卡或双卡切分，与第五章示例一、示例三的估算一致。
架构提醒（易错点） ：Qwen3-32B 官方配置为 64 层 / 隐藏维度 5120 / 查询头 64 / KV 头 8 / 头维度 128 。特别注意
head_dim是显式声明的 128 ，而不是hidden_size ÷ num_attention_heads = 5120 ÷ 64 = 80。若按 80 代入 KV Cache 公式，会低估 1.6 倍，长上下文规划会严重偏乐观------网上不少资料就踩了这个坑。MoE 模型的显存特点 ：DeepSeek-V2-Lite 这类 MoE（混合专家）模型，全部专家权重都需常驻显存 （显存占用按 15.7B 总参数量算，约 31 GB），只有计算量 按激活参数（2.4B）计。也就是说，MoE 省的是算力和单 token 延迟，不省显存，选型时不要用激活参数量去估显存。
唯一的例外是专家并行（EP） ：把不同专家分布到不同卡上，单卡确实只保存部分专家。但这是"用卡数换显存"------集群总显存占用不变，且会引入 All-to-All 通信开销。上一段"不省显存"的结论，在单卡或纯张量并行口径下成立。
3.3 70B 级模型
| 模型 | 参数量 | 上下文窗口 | 每参数精度（典型） | 权重显存（BF16） | 适用场景 |
|---|---|---|---|---|---|
| Llama 3.1 70B | 70.6B | 128K | BF16（2 字节） | ≈ 141 GB | 高质量通用对话、复杂推理 |
| Qwen2.5 72B | 72.7B | 128K | BF16（2 字节） | ≈ 145 GB | 中文高质量生成、Agent |
| DeepSeek-V3（MoE） | 671B（激活 37B） | 128K | BF16（2 字节） | 全量 ≈ 1.3 TB | MoE 架构，激活参数少，推理成本低 |
说明：70B 级模型 BF16 权重约 141 GB，连同 KV Cache 与 15% 框架开销后约 164 GB 。2×A100 80GB 的可用显存约 147 GB（按 92% 利用率），已经装不下 ，需 4×80GB（每卡约 41 GB）；或改用 INT8 量化。若用 INT8，权重降到约 70.6 GB，加 KV Cache 与开销后仍约 82 GB ，单张 80 GB 卡依然装不下 ，需 2×80GB（每卡约 41 GB）或进一步量化到 INT4（约 35 GB，2 卡从容）。另需牢记："装得下"不等于"能承载并发"------70B INT8 在 2×80GB 上扣除权重后仅剩约 73 GB 给 KV Cache，实际并发数见 4.4 节的公式与示例。
3.4 模型选型速查
| 部署目标 | 推荐模型 | 推荐显卡 | 说明 |
|---|---|---|---|
| 轻量对话、单用户 | Qwen2.5 7B / Llama 3.1 8B | RTX 4090（24GB） | 单卡即可，INT8 更从容 |
| 中文通用、中等并发 | Qwen2.5 14B | A100 40GB / L40S | 单卡 BF16 可跑 |
| 高质量生成、5~10 人并发 | Qwen3-32B | 2×A100 80GB（TP=2）/ 32B INT8 + A100 80GB 单卡 | BF16 单卡仅约 5 路并发且余量不足 4%，10 人需双卡或 INT8；对应第五章示例一、示例三与 4.4 节 |
| 复杂推理、高并发 | Llama 3.1 70B / Qwen2.5 72B | 4×A100 80GB / 2×H100（INT8 后） | BF16 约 164 GB，2×80GB 已装不下（见 3.3 节）；需 4 卡 TP 或 INT8 后双卡，务必配 NVLink |
| GIS / 自然资源（坐标密集、长上下文） | Qwen3-32B | 2×A100 80GB（TP=2） | 权重用 BF16 即可，不要为「坐标精度」上 FP32 （见 6.3 节辨析）；量化底线 INT8；必须开 Prefix Caching，坐标尽量不进 prompt |
| 信创/私有化 | 昇腾 910B / 寒武纪 590 | 对应国产卡 | 重点评估软件生态 |
4. 计算过程详解
下面以 A100 80GB 显卡 + Qwen3-32B（BF16） 部署为例，逐一演示每个公式的计算过程。示例参数：参数量 P=32.8×109P = 32.8 \times 10^9P=32.8×109，BF16 每参数 2 字节，A100 80GB 显存带宽 ≈ 2.0 TB/s，BF16 算力 312 TFLOPS。
小白速览 ：这一章是「算账」------教你用几个简单公式估算「模型要占多少显存、跑多快」。你不需要自己算，记住结论：32B 模型用一张 A100 80GB 就能装下，但单请求 Decode 吞吐只有约 30 tokens/s。人多就要多卡或换更高带宽的卡。
4.1 显存占用计算
-
模型权重显存：
参数量 × 每参数字节示例：Qwen3-32B 的 BF16 权重：
32.8×109×2 字节=65.6×109 字节=66 GB32.8 \times 10^9 \times 2 \text{ 字节} = 65.6 \times 10^9 \text{ 字节} = 66 \text{ GB}32.8×109×2 字节=65.6×109 字节=66 GB
即约需 66 GB 显存。
-
KV Cache 显存：
2 × 层数 × KV头数 × 头维度 × 序列长度 × 每参数字节注意：这里的「头数」指 KV 头数（num_key_value_heads） ，而非查询头数。现代模型普遍使用 GQA（分组查询注意力），KV 头数远小于查询头数------Qwen3-32B 为查询头 64、KV 头 8 ------若误用查询头数会高估 8 倍（64 ÷ 8）。
示例 ：取 Qwen3-32B 官方配置：64 层、查询头 64、KV 头 8、头维度 128，序列长度 4096，BF16 每参数 2 字节：
2×64×8×128×4096×2=1.07×109 字节≈1.1 GB2 \times 64 \times 8 \times 128 \times 4096 \times 2 = 1.07 \times 10^9 \text{ 字节} \approx 1.1 \text{ GB}2×64×8×128×4096×2=1.07×109 字节≈1.1 GB
-
激活值显存：与批大小、序列长度、隐藏维度、FFN 中间维度 相关。推理时逐层串行执行、中间张量算完即释放，因此要分两个阶段看：
- Decode 阶段（部署稳态主口径） ：每次只算 1 个 token，激活量约
隐藏维度 × 批大小 × 每参数字节，可忽略； - Prefill 阶段（瞬时峰值） ：一次性并行处理全部输入 token，峰值只等于单层 激活量，主项是 FFN 中间张量
序列长度 × 中间维度 × 每参数字节。
易错点 ：
序列长度 × 隐藏维度 × 层数是训练 口径（需保留各层激活供反向传播），不能用于推理------推理下按此式会把激活值高估几十倍。示例（Qwen3-32B：隐藏维度 5120、FFN 中间维度 25600、64 层、序列长度 4096）：
-
Decode 稳态 ：逐 token 生成，batch = 1 时激活张量形状是
[1, 5120]（不是[4096, 5120]------4096 是上下文长度，已计入 KV Cache），约 5120×1×2≈10 KB5120 \times 1 \times 2 \approx 10 \text{ KB}5120×1×2≈10 KB，可忽略； -
Prefill 峰值 ：主项是 FFN 中间张量
序列长度 × 中间维度：4096×25600×2 字节≈0.21 GB4096 \times 25600 \times 2 \text{ 字节} \approx 0.21 \text{ GB}4096×25600×2 字节≈0.21 GB
再叠加注意力与残差分支约 5~10 个
[序列长度, 隐藏维度]张量（每个 4096×5120×2≈0.04 GB4096 \times 5120 \times 2 \approx 0.04 \text{ GB}4096×5120×2≈0.04 GB），Prefill 峰值量级约 0.5~0.7 GB 。计入总显存校验时按 0.7 GB 保守取值。
- Decode 阶段（部署稳态主口径） ：每次只算 1 个 token，激活量约
-
总显存 = 权重 + KV Cache + 激活值 + 框架开销（本文统一预留 10%~20%，示例取 15%）
示例（Decode 稳态口径，与第五章一致）：
66+1.1+0.01 (激活值，可忽略)≈67.1 GB67.1×1.15≈77.2 GB66 + 1.1 + 0.01\ (\text{激活值，可忽略}) \approx 67.1 \text{ GB} \qquad 67.1 \times 1.15 \approx 77.2 \text{ GB}66+1.1+0.01 (激活值，可忽略)≈67.1 GB67.1×1.15≈77.2 GB
单张 A100 80GB 可容纳，但余量仅约 2.8 GB（不足 4%）。
Prefill 峰值校验 ：66+1.1+0.7=67.8 GB66 + 1.1 + 0.7 = 67.8 \text{ GB}66+1.1+0.7=67.8 GB，加 15% 后约 78.0 GB，仍在 80 GB 内------单卡可完成 Prefill，但已相当接近上限。
那么"长输入 / 高并发会把单卡撑爆"的真正原因是什么？ 不是激活值，而是 KV Cache ：它按「并发路数 × 序列长度」线性 累积。本例仅 1 路、序列 4096 就占 1.1 GB；10 路并发即 11 GB，总显存需求随之涨到约 88.6 GB ------这才是撑爆单卡的原因 。完整的并发数估算见 4.4 节。
4.2 计算量（FLOPs）估算
重要说明：Prefill 与 Decode 是两种截然不同的计算阶段，必须分开估算。 Prefill（预填充）阶段一次性并行处理全部输入 token，是计算密集型 （compute-bound），瓶颈在算力；Decode（解码）阶段逐 token 串行生成，是访存密集型（memory-bound），瓶颈在显存带宽。二者对硬件资源的需求完全不同，部署规划时必须分别计算。
-
Prefill 阶段（处理输入） ：
2 × 参数量 × 输入 token 数示例：输入 1000 token 时：
2×32.8×109×1000=6.56×1013 FLOPs=65.6 TFLOPs2 \times 32.8 \times 10^9 \times 1000 = 6.56 \times 10^{13} \text{ FLOPs} = 65.6 \text{ TFLOPs}2×32.8×109×1000=6.56×1013 FLOPs=65.6 TFLOPs
Prefill 一次处理全部输入 token，计算量大但可高度并行，吃算力。
-
Decode 阶段（逐 token 生成） ：
2 × 参数量（每生成 1 个 token）示例 ：每生成 1 个 token 需 2×32.8×109=65.6 GFLOPs2 \times 32.8 \times 10^9 = 65.6 \text{ GFLOPs}2×32.8×109=65.6 GFLOPs；生成 1000 个 token 共需 65.6×1000=65.6 TFLOPs65.6 \times 1000 = 65.6 \text{ TFLOPs}65.6×1000=65.6 TFLOPs。Decode 逐 token 串行，每次都要重新读取全部权重，吃带宽。
-
Prefill 与 Decode 的计算量对比：
阶段 计算量公式 1000 token 示例 瓶颈 Prefill 2 × 参数量 × 输入 token 数65.6 TFLOPs（一次并行） 算力（compute-bound） Decode 2 × 参数量（每 token）65.6 GFLOPs × 1000 = 65.6 TFLOPs（逐 token） 显存带宽（memory-bound） 两者总计算量相同（都是 65.6 TFLOPs），但时间分布完全不同：Prefill 在极短时间内爆发式完成，Decode 则被带宽拖慢、均匀拉长。这就是为什么「首 token 延迟」由 Prefill 决定，而「后续 token 生成速度」由 Decode 决定。
-
训练总计算量：
6 × 参数量 × 训练 token 数示例 ：若用 1 万亿 token 训练：6×32.8×109×1012=1.97×1023 FLOPs6 \times 32.8 \times 10^9 \times 10^{12} = 1.97 \times 10^{23} \text{ FLOPs}6×32.8×109×1012=1.97×1023 FLOPs，即约 197 ZFLOPs。
4.3 吞吐与延迟估算
吞吐与延迟是部署规格选型时权衡算力与显存的核心指标。必须区分 Prefill 与 Decode 两个阶段分别估算 ：Prefill 决定「首 token 延迟」，Decode 决定「生成速度（tokens/s）」。下面基于 A100 80GB 与 Qwen3-32B（BF16）的示例参数，分别从算力视角 和显存带宽视角估算两个阶段的吞吐上限。
已知条件 ：参数量 P=32.8×109P = 32.8 \times 10^9P=32.8×109，BF16 每参数 2 字节，A100 80GB 显存带宽 ≈ 2.0 TB/s，BF16 算力 312 TFLOPS，单 token 前向计算量 =2×32.8×109=65.6 GFLOPs= 2 \times 32.8 \times 10^9 = 65.6 \text{ GFLOPs}=2×32.8×109=65.6 GFLOPs。
Prefill 阶段（处理输入，计算密集型）
-
理论算力上限：
显卡 FLOPS × 利用率示例 ：A100 80GB BF16 算力 312 TFLOPS，为保守起见取利用率 50%，得可用算力 312×0.5=156 TFLOPS312 \times 0.5 = 156 \text{ TFLOPS}312×0.5=156 TFLOPS。（大 batch 的 Prefill 实际利用率可达 70%~80%，此处取值偏保守。）
-
Prefill 吞吐（算力视角）：
算力 ÷ 每 token 计算量每处理 1 个输入 token 需 2×32.8×109=65.6 GFLOPs2 \times 32.8 \times 10^9 = 65.6 \text{ GFLOPs}2×32.8×109=65.6 GFLOPs：
156×1012÷65.6×109≈2400 tokens/s156 \times 10^{12} \div 65.6 \times 10^9 \approx 2400 \text{ tokens/s}156×1012÷65.6×109≈2400 tokens/s
即每秒可处理约 2400 个输入 token 。若按「每个请求输入 1000 token」折算，则约 2400÷1000≈2.42400 \div 1000 \approx 2.42400÷1000≈2.4 个请求/s（这是「请求吞吐/QPS」，可用于估算排队等待，但不与 Decode 的 tokens/s 直接比大小）。
为什么统一用 tokens/s，而不用「批次/s」？ 因为每 token 的计算量（2P2P2P）与输入长度无关 ，所以 tokens/s 只由「硬件算力 + 模型大小」决定，换任何长度都成立；而「批次/s」的数值会随「一批多少 token」变化（1000 token 一批时是 2.4/s，2000 token 一批时就变成 1.2/s），既不便横向比较，也无法与 Decode 的 30 tokens/s 放在同一尺度上------而 4.3 节末尾判断瓶颈用的
min(算力上限, 带宽上限)，恰恰要求两边同单位。自洽性核对 ：0.42 s 处理 1000 个输入 token（见下条），折算为 1000÷0.42≈24001000 \div 0.42 \approx 24001000÷0.42≈2400 tokens/s，与上式一致。Prefill 是计算密集型 ，瓶颈在算力而非带宽（输入 1000 token 时带宽上限约 30×1000=3000030 \times 1000 = 3000030×1000=30000 tokens/s，远高于算力上限，故由算力决定）。
-
Prefill 首 token 延迟：
输入 token 数 × 每 token 计算量 ÷ 算力示例 ：1000×65.6×109÷(156×1012)≈0.42 s1000 \times 65.6 \times 10^9 \div (156 \times 10^{12}) \approx 0.42 \text{ s}1000×65.6×109÷(156×1012)≈0.42 s。即输入 1000 token 时，约 0.42 秒出第一个 token。Prefill 阶段算力充足，首 token 延迟很低。
Decode 阶段（逐 token 生成，访存密集型）
-
Decode 吞吐（算力视角）：
算力 ÷ 每 token 计算量示例 ：156×1012÷(65.6×109)≈2400 tokens/s156 \times 10^{12} \div (65.6 \times 10^9) \approx 2400 \text{ tokens/s}156×1012÷(65.6×109)≈2400 tokens/s。实际受显存带宽限制，需用带宽校验。
为什么和 Prefill 的算力上限是同一个数？ 因为 Prefill 与 Decode 每 token 的计算量都是 2P2P2P ，除以同一个算力自然得到同一个值。但含义完全不同：在 Prefill，它是可达到的实际吞吐；在 Decode，它只是算力上界（实际被带宽压到 30 tokens/s）。
-
Decode 吞吐（带宽视角）：
显存带宽 ÷ 每 token 权重读取量每生成 1 个 token 需从显存读取全部权重（BF16 下 65.6 GB），因此带宽上限为：
2.0 TB/s÷65.6 GB≈30 tokens/s2.0 \text{ TB/s} \div 65.6 \text{ GB} \approx 30 \text{ tokens/s}2.0 TB/s÷65.6 GB≈30 tokens/s
两个重要修正：
① 长上下文会进一步压低吞吐 。上式的"权重读取量"只是主项，每生成 1 个 token 还需读取全部历史 KV Cache：序列 4096 时约 1.1 GB，可忽略；但序列 128K 时约 34 GB ，此时每 token 总读取量接近 100 GB，吞吐会降到约 20 tokens/s。所以长上下文场景的实际吞吐明显低于 30 tokens/s。
② 批处理能成倍提升总吞吐 。权重读取量不随 batch 变化（一批请求共享同一次权重加载），但每轮还要读取 B 份 KV Cache ，所以每轮总读取量是
权重 + B × 单请求 KV Cache，并非恒定值。因此：总吞吐=B×带宽权重+B×单请求 KV Cache单请求速度=带宽权重+B×单请求 KV Cache总吞吐 = \frac{B \times 带宽}{权重 + B \times 单请求\ KV\ Cache} \qquad 单请求速度 = \frac{带宽}{权重 + B \times 单请求\ KV\ Cache}总吞吐=权重+B×单请求 KV CacheB×带宽单请求速度=权重+B×单请求 KV Cache带宽
以 32B @ A100 为例（带宽 2.0 TB/s、权重 66 GB、单请求 KV 1.1 GB）：B = 1 时约 30 tokens/s；B = 5 时总吞吐约 5×2000÷(66+5×1.1)≈1405 \times 2000 \div (66 + 5 \times 1.1) \approx 1405×2000÷(66+5×1.1)≈140 tokens/s。可见总吞吐随 B 近似线性增长，但单请求速度随 B 缓慢下降 （B 越大，每轮要多读 B 份 KV）。B 足够大后会转入算力受限区，增长趋于平缓，并最终受显存容量 硬约束------完整的并发数估算见 4.4 节。这也是第 6 章把"连续批处理"列为首选优化手段的原因。
-
Decode 吞吐上限的判定：
min(算力上限, 带宽上限)示例 ：按 50% 利用率估算的算力上限约 2400 tokens/s，带宽上限约 30 tokens/s，Decode 实际吞吐被显存带宽牢牢卡住 ，约 30 tokens/s。这也印证了第二章「带宽往往是推理吞吐的瓶颈」的结论------对 32B 级模型，单卡 A100 的算力远未用满，瓶颈在权重搬运。
注：2400 tokens/s 是"取 50% 利用率"下的估计值 ，并非理论硬上限（按 Prefill 实测 70%~80% 的 MFU 可达 3300~3800 tokens/s）。结论不受影响------即便取最大值，仍远高于带宽上限 30 tokens/s。
-
Decode 单 token 延迟（生成阶段）：
1 ÷ Decode 吞吐示例 ：带宽视角下每生成 1 个 token 约 1÷30≈33 ms/token1 \div 30 \approx 33 \text{ ms/token}1÷30≈33 ms/token；算力视角约 1÷2400≈0.42 ms/token1 \div 2400 \approx 0.42 \text{ ms/token}1÷2400≈0.42 ms/token。实际生成阶段受带宽限制，约 33 ms/token，即每秒约生成 30 个 token。
Prefill 与 Decode 部署计算对比
| 维度 | Prefill（处理输入） | Decode（逐 token 生成） |
|---|---|---|
| 计算类型 | 计算密集型（compute-bound） | 访存密集型（memory-bound） |
| 瓶颈 | 算力（FLOPS） | 显存带宽 |
| 计算量 | 2 × 参数量 × 输入 token 数（一次并行） |
2 × 参数量（每 token） |
| 吞吐上限 | 算力 ÷ 每 token 计算量（≈ 2400 tokens/s） | 带宽 ÷ 权重读取量（≈ 30 tokens/s） |
| 延迟指标 | 首 token 延迟（≈ 0.42 s） | 单 token 延迟（≈ 33 ms） |
| 显存需求 | 激活值峰值高（需按序列长度 × 隐藏维度估算） | KV Cache 随序列增长 |
| 优化方向 | 提升算力、增大批大小 | 量化减权重、提高带宽、连续批处理 |
部署启示 ：Prefill 与 Decode 对硬件需求截然不同------Prefill 吃算力、Decode 吃带宽。若业务以「长输入、短输出」为主（如文档分析、代码审查），Prefill 占比高，应优先选高算力卡；若以「短输入、长输出」为主（如对话、写作），Decode 占比高，应优先选高带宽卡。这也是为什么生产环境常把 Prefill 与 Decode 拆分到不同实例（如 vLLM 的 disaggregated serving），让算力卡和带宽卡各司其职。
小结 ：对 Qwen3-32B 这类大模型，Prefill 阶段算力充足（首 token 约 0.42 s），Decode 阶段被显存带宽卡住（单请求约 30 tokens/s） 。单请求 30 tokens/s 对交互式对话基本够用 （主流商业 API 单流普遍在 20~60 tokens/s），真正的挑战在并发------权重已占掉 66 GB，留给 KV Cache 的空间不足 6 GB。下一节给出并发数的估算方法。
4.4 并发数估算（工程口径）
前面各节的公式都是单请求 口径。生产部署真正要回答的是：这张卡能同时服务多少人？ 它由两条互相独立的约束共同决定，必须分别计算再取小。
约束①：显存约束------决定「能同时跑几路」
B显存=单卡容量×gpu_memory_utilization−权重−运行时固定开销单请求 KV CacheB_{显存} = \frac{单卡容量 \times gpu\_memory\_utilization - 权重 - 运行时固定开销}{单请求\ KV\ Cache}B显存=单请求 KV Cache单卡容量×gpu_memory_utilization−权重−运行时固定开销
gpu_memory_utilization：推理框架（vLLM 等）的显存占用上限，常取 0.90~0.95；运行时固定开销：CUDA context、cuBLAS workspace、CUDA Graph 复本、显存碎片等，约 1~3 GB。
为什么不沿用前面"总额 × 15%"的框架开销？ 因为框架开销主要是固定量，不会随 KV Cache 按比例放大。做并发规划时若把 KV Cache 也放大 15%，会虚增约 10 GB 占用，直接导致并发数算错。这里的"工程口径"与第五章的"公式口径"并行使用，各司其职。
约束②：带宽约束------决定「每路能跑多快」（即 4.3 节的批处理公式）
总吞吐=B×带宽权重+B×单请求 KV Cache单请求速度=带宽权重+B×单请求 KV Cache总吞吐 = \frac{B \times 带宽}{权重 + B \times 单请求\ KV\ Cache} \qquad 单请求速度 = \frac{带宽}{权重 + B \times 单请求\ KV\ Cache}总吞吐=权重+B×单请求 KV CacheB×带宽单请求速度=权重+B×单请求 KV Cache带宽
实际并发数 = min（约束①的 B 值，总吞吐 ÷ 每人期望速度）
示例一：Qwen3-32B BF16 @ A100 80GB（序列 4096，按每人 30 tokens/s）
- 约束①：B显存=(80×0.92−66−2)÷1.1=5.6÷1.1≈5 路B_{显存} = (80 \times 0.92 - 66 - 2) \div 1.1 = 5.6 \div 1.1 \approx \mathbf{5\ 路}B显存=(80×0.92−66−2)÷1.1=5.6÷1.1≈5 路
- 约束②：B = 5 时总吞吐 =5×2000÷(66+5×1.1)≈140= 5 \times 2000 \div (66 + 5 \times 1.1) \approx 140=5×2000÷(66+5×1.1)≈140 tokens/s，每人约 140÷5≈28140 \div 5 \approx 28140÷5≈28 tokens/s；按 30 tokens/s 折算约 4.7 路
- 并发数 = min(5, 4.7) ≈ 5 人（两条约束几乎同时到顶）
示例二：Qwen3-32B INT8 @ A100 80GB（同为序列 4096）
- 权重降到 32.8 GB，约束①：B显存=(73.6−32.8−2)÷1.1≈35 路B_{显存} = (73.6 - 32.8 - 2) \div 1.1 \approx \mathbf{35\ 路}B显存=(73.6−32.8−2)÷1.1≈35 路
- 约束②：B = 35 时总吞吐 =35×2000÷(32.8+35×1.1)≈980= 35 \times 2000 \div (32.8 + 35 \times 1.1) \approx 980=35×2000÷(32.8+35×1.1)≈980 tokens/s，每人约 28 tokens/s
- 并发数 ≈ 33 人，保守取约 30 人
| 精度 | 权重显存 | 单请求速度 | 显存允许并发 | 支持并发（30 tokens/s/人） |
|---|---|---|---|---|
| BF16 | 66 GB | ≈ 30 tokens/s | 5 路 | ≈ 5 人 |
| INT8 | 33 GB | ≈ 59 tokens/s | 35 路 | ≈ 30 人 |
关键结论：量化让并发提升约 6 倍，而速度只提升约 2 倍。 因为 INT8 省下的 33 GB 显存，几乎全部转化成了 KV Cache 容量------在这个量级上，并发能力是被显存的"剩余空间"卡住的，不是被速度卡住的。这是全文最容易被低估的一条结论。
由此得到两条选购原则：
① 并发数由显存容量决定，单请求速度由显存带宽决定------买卡时必须分开看。
典型反例：A100 80GB 与 H100 80GB 显存容量相同 ，跑 32B BF16 时并发上限都是约 5 路 ；H100 的收益只是带宽从 2.0 提到 3.35 TB/s，即单请求速度从 30 提到约 50 tokens/s 。想提升并发，要靠：加卡 （TP=2 后每卡只放一半权重，剩余空间大增）、换更大显存的卡 （H200 141GB → 约 56 路，是 A100 的 11 倍 ）、或量化。
② 别拿"总吞吐"直接比对"并发 × 每人速度"。
厂商与博客给出的吞吐数字通常混合了 Prefill token 与 Decode token，而 Prefill 每 token 成本只有 Decode 的约 1/80（2400 vs 30 tokens/s）。引用时必须确认口径，并要求标明输入/输出长度比。
5. 多卡部署与量化显存计算示例
前面第四章以单卡 A100 80GB 部署 Qwen3-32B 为例演示了基础公式。实际生产中，大模型往往需要多卡切分，或通过量化压缩显存 。本章给出三个典型示例，全部基于 Qwen3-32B ：BF16（单卡）、FP32（双卡切分）、BF16（2×A100 40GB 切分）三种组合下的推理显存估算。除显存外，也会一并考虑服务器内存（CPU 侧 RAM）的大小要求。本章框架开销统一取 15%，激活值按 Decode 稳态计（与 4.1 节口径一致）。
5.1 示例一：32B 模型 BF16 推理显存估算
已知条件 ：Qwen3-32B 参数量 P=32.8×109P = 32.8 \times 10^9P=32.8×109，BF16 每参数 2 字节，目标部署在 A100 80GB 上。
第 1 步：计算 BF16 权重显存
32.8×109×2 字节=65.6×109 字节≈66 GB32.8 \times 10^9 \times 2 \text{ 字节} = 65.6 \times 10^9 \text{ 字节} \approx 66 \text{ GB}32.8×109×2 字节=65.6×109 字节≈66 GB
第 2 步：计算 KV Cache 显存
设 Qwen3-32B 为 64 层、KV 头 8、头维度 128，序列长度 4096，BF16 每参数 2 字节：
2×64×8×128×4096×2=1.07×109 字节≈1.1 GB2 \times 64 \times 8 \times 128 \times 4096 \times 2 = 1.07 \times 10^9 \text{ 字节} \approx 1.1 \text{ GB}2×64×8×128×4096×2=1.07×109 字节≈1.1 GB
第 3 步：计算总显存并校验
总显存 = 权重 + KV Cache + 激活值 + 框架开销：
66+1.1+0.01 (激活值，可忽略)≈67.1 GB66 + 1.1 + 0.01\ (\text{激活值，可忽略}) \approx 67.1 \text{ GB}66+1.1+0.01 (激活值，可忽略)≈67.1 GB
再加 15% 框架开销：67.1×1.15≈77.2 GB67.1 \times 1.15 \approx 77.2 \text{ GB}67.1×1.15≈77.2 GB。
第 4 步：服务器内存（RAM）估算
推理时权重需从内存加载到显存，内存至少需容纳权重 + 运行时开销：
66 GB×1.5≈99 GB66 \text{ GB} \times 1.5 \approx 99 \text{ GB}66 GB×1.5≈99 GB
建议服务器配置 ≥ 128 GB 内存，以容纳权重加载、KV Cache 及框架运行开销。
结论 ：显存约需 77.2 GB ，单张 A100 80GB 可容纳，但余量仅约 2.8 GB（不足 4%） ，无法再容纳长上下文或高并发下的 KV Cache 增长；建议限制并发数，或直接用双卡切分。服务器内存建议 ≥ 128 GB。
5.2 示例二：32B 模型 FP32 推理显存估算
已知条件 ：Qwen3-32B 参数量 P=32.8×109P = 32.8 \times 10^9P=32.8×109，FP32 每参数 4 字节，目标部署在 A100 80GB 上。
第 1 步：计算 FP32 权重显存
32.8×109×4 字节=131.2×109 字节≈131 GB32.8 \times 10^9 \times 4 \text{ 字节} = 131.2 \times 10^9 \text{ 字节} \approx 131 \text{ GB}32.8×109×4 字节=131.2×109 字节≈131 GB
第 2 步：计算 KV Cache 显存
设 Qwen3-32B 为 64 层、KV 头 8、头维度 128，序列长度 4096，FP32 每参数 4 字节：
2×64×8×128×4096×4=2.15×109 字节≈2.1 GB2 \times 64 \times 8 \times 128 \times 4096 \times 4 = 2.15 \times 10^9 \text{ 字节} \approx 2.1 \text{ GB}2×64×8×128×4096×4=2.15×109 字节≈2.1 GB
第 3 步：计算总显存并校验
总显存 = 权重 + KV Cache + 激活值 + 框架开销：
131+2.1+0.02 (激活值，可忽略)≈133.1 GB131 + 2.1 + 0.02\ (\text{激活值，可忽略}) \approx 133.1 \text{ GB}131+2.1+0.02 (激活值，可忽略)≈133.1 GB
再加 15% 框架开销：133.1×1.15≈153.1 GB133.1 \times 1.15 \approx 153.1 \text{ GB}133.1×1.15≈153.1 GB。
第 4 步：服务器内存（RAM）估算
131 GB×1.5≈197 GB131 \text{ GB} \times 1.5 \approx 197 \text{ GB}131 GB×1.5≈197 GB
建议服务器配置 ≥ 256 GB 内存。
结论 ：显存约需 153.1 GB ，单张 A100 80GB 无法容纳 ，需 2×A100 80GB 切分。按 5.3 节的分步口径（不能把含开销的总量整体除以 TP）计算每卡占用：
(131+2.1)÷2+0.02 (激活值)+通信/临时缓冲(约 1 GB)≈67.6 GB(131 + 2.1) \div 2 + 0.02\ (\text{激活值}) + 通信/临时缓冲(约\ 1\ GB) \approx 67.6\ \text{GB}(131+2.1)÷2+0.02 (激活值)+通信/临时缓冲(约 1 GB)≈67.6 GB
再加 15% 框架开销约 77.7 GB/卡 （占满度 ≈ 97% ），余量同样紧张。服务器内存建议 ≥ 256 GB。
重要提醒 ：本示例仅用于演示"精度翻倍 → 显存翻倍"的对照关系。生产推理不推荐 FP32 ------BF16 的精度对推理已足够；而 A100/H100 上若走纯 FP32（非张量核路径），CUDA 核算力仅约 19.5 TFLOPS，远低于 BF16 张量核的 312 TFLOPS。若确需更高精度，应显式开启 TF32 ------注意 PyTorch 中
torch.backends.cuda.matmul.allow_tf32在 1.12 之后默认为 False，不会自动启用，且需评估精度影响。实际部署请优先 BF16/FP16。
5.3 示例三：32B 模型 BF16 推理显存估算（多卡切分）
已知条件 ：Qwen3-32B 参数量 P=32.8×109P = 32.8 \times 10^9P=32.8×109，BF16 每参数 2 字节，目标部署在 2×A100 40GB 上。
第 1 步：计算 BF16 权重显存
32.8×109×2 字节=65.6×109 字节≈66 GB32.8 \times 10^9 \times 2 \text{ 字节} = 65.6 \times 10^9 \text{ 字节} \approx 66 \text{ GB}32.8×109×2 字节=65.6×109 字节≈66 GB
第 2 步：计算 KV Cache 显存
设 Qwen3-32B 为 64 层、KV 头 8、头维度 128，序列长度 4096，BF16 每参数 2 字节：
2×64×8×128×4096×2=1.07×109 字节≈1.1 GB2 \times 64 \times 8 \times 128 \times 4096 \times 2 = 1.07 \times 10^9 \text{ 字节} \approx 1.1 \text{ GB}2×64×8×128×4096×2=1.07×109 字节≈1.1 GB
第 3 步：计算总显存并校验
总显存 = 权重 + KV Cache + 激活值 + 框架开销：
66+1.1+0.01 (激活值，可忽略)≈67.1 GB66 + 1.1 + 0.01\ (\text{激活值，可忽略}) \approx 67.1 \text{ GB}66+1.1+0.01 (激活值，可忽略)≈67.1 GB
再加 15% 框架开销：67.1×1.15≈77.2 GB67.1 \times 1.15 \approx 77.2 \text{ GB}67.1×1.15≈77.2 GB。
第 4 步：多卡切分方案
多卡切分（张量并行 TP）时，每卡显存可由下式估算：
每卡显存≈权重+KV CacheTP+激活值+通信/临时缓冲+框架开销每卡显存 \approx \frac{权重 + KV\ Cache}{TP} + 激活值 + 通信/临时缓冲 + 框架开销每卡显存≈TP权重+KV Cache+激活值+通信/临时缓冲+框架开销
单张 A100 40GB 无法容纳 77.2 GB，需 2×A100 40GB 切分。按上式逐步 计算（不能把含开销的总量整体除以 TP------那等于把框架开销也"切分"了，与实际不符）：
66+1.12+0.01 (激活值)+通信/临时缓冲(约 1 GB)≈34.6 GB\frac{66 + 1.1}{2} + 0.01\ (\text{激活值}) + 通信/临时缓冲(约\ 1\ GB) \approx 34.6\ GB266+1.1+0.01 (激活值)+通信/临时缓冲(约 1 GB)≈34.6 GB
再加框架开销：按 15% 系数约 39.8 GB （占满度 ≈ 99%），按 4.4 节的固定开销口径（约 2 GB）约 36.6 GB （占满度 ≈ 92%）。两种口径都指向同一结论：几乎没有余量。
这也是第二章强调"多卡优先选 NVLink"的原因：TP 每层都要做 2 次 All-Reduce 同步，走 PCIe 会成为新的瓶颈。
第 5 步：服务器内存（RAM）估算
66 GB×1.5≈99 GB66 \text{ GB} \times 1.5 \approx 99 \text{ GB}66 GB×1.5≈99 GB
建议服务器配置 ≥ 128 GB 内存。
结论 ：显存约需 77.2 GB 。单张 A100 80GB 可容纳，但余量不足 4%（约 2.8 GB）；2×A100 40GB 切分后每卡约 36~40 GB，占满度 92%~99%，比单卡 80GB 更满，显存上并不更从容。
它真正的优势是单请求 Decode 速度 ：TP = 2 时每卡只需保存并读取约 33 GB 权重（66 ÷ 2），单步耗时从 66÷2.0≈3366 \div 2.0 \approx 3366÷2.0≈33 ms 降到 33÷1.555≈2133 \div 1.555 \approx 2133÷1.555≈21 ms，即约 47 tokens/s（受卡间 All-Reduce 通信影响，实测通常略低）。
机制澄清 ：提速的原因是「每卡只读 1/TP 的权重 」，而不是「两张卡的带宽合并成了一个大池子」。两种说法算出的数字接近，但前者才是真实机制------后者会让人误以为多加卡就能无限提速（实际上通信开销会迅速吃掉收益）。
两种方案都需严格控制并发（按 4.4 节，BF16 下单卡仅约 5 路）。真正宽裕的做法是 INT8 量化 （并发可提升到约 30 路）或换更大显存 的卡（如 H200 141GB，约 56 路）。服务器内存建议 ≥ 128 GB。
5.4 小结
| 部署方案 | 模型 | 精度 | 权重显存 | 总显存估算 | 服务器内存建议 | 结论 |
|---|---|---|---|---|---|---|
| A100 80GB 单卡 | Qwen3-32B | BF16 | ≈ 66 GB | ≈ 77.2 GB | ≥ 128 GB | 单卡可容纳，但余量仅约 2.8 GB，建议限制并发数或改用双卡切分 |
| 2×A100 80GB | Qwen3-32B | FP32 | ≈ 131 GB | ≈ 153.1 GB | ≥ 256 GB | 需双卡切分；FP32 仅作精度对照，生产推理不推荐 |
| 2×A100 40GB | Qwen3-32B | BF16 | ≈ 66 GB | ≈ 77.2 GB | ≥ 128 GB | 切分后每卡约 39 GB，显存不更宽裕；优势是聚合带宽翻倍 |
三个示例分别展示了精度选择 （BF16 vs FP32）与部署方式 （单卡 vs 多卡切分）对显存和内存需求的显著影响：FP32 相比 BF16 显存翻倍，直接把单卡方案推向双卡；多卡切分把单卡显存压力分摊到多张卡上，但单卡占满度并未下降（因为单卡容量也变小了），真正的收益是聚合带宽翻倍带来的吞吐提升。
6. 总结
6.1 关键公式回顾
-
模型权重显存 ：
参数量 × 每参数字节示例 ：Qwen3-32B（32.8B）BF16 下 32.8×109×2=66 GB32.8 \times 10^9 \times 2 = 66 \text{ GB}32.8×109×2=66 GB；FP32 下 32.8×109×4=131 GB32.8 \times 10^9 \times 4 = 131 \text{ GB}32.8×109×4=131 GB。
-
KV Cache 显存 ：
2 × 层数 × KV头数 × 头维度 × 序列长度 × 每参数字节示例 ：64 层、KV 头 8、头维度 128、序列长度 4096、BF16 下约 2×64×8×128×4096×2=1.07×109 字节≈1.1 GB2 \times 64 \times 8 \times 128 \times 4096 \times 2 = 1.07 \times 10^9 \text{ 字节} \approx 1.1 \text{ GB}2×64×8×128×4096×2=1.07×109 字节≈1.1 GB。
-
总显存 ：
权重 + KV Cache + 激活值 + 框架开销（统一按 10%~20%，示例取 15%）示例 ：66+1.1+0.01 (激活值，可忽略)≈67.1 GB66 + 1.1 + 0.01\ (\text{激活值，可忽略}) \approx 67.1 \text{ GB}66+1.1+0.01 (激活值，可忽略)≈67.1 GB，加 15% 开销后约 77.2 GB。
-
单 token 前向计算量 ：
2 × 参数量示例 ：2×32.8×109=65.6 GFLOPs2 \times 32.8 \times 10^9 = 65.6 \text{ GFLOPs}2×32.8×109=65.6 GFLOPs。
-
训练总计算量 ：
6 × 参数量 × 训练 token 数示例 ：6×32.8×109×1012=1.97×1023 FLOPs6 \times 32.8 \times 10^9 \times 10^{12} = 1.97 \times 10^{23} \text{ FLOPs}6×32.8×109×1012=1.97×1023 FLOPs。
-
推理吞吐（算力视角） ：
算力 ÷ 每 token 计算量示例 ：156×1012÷(65.6×109)≈2400 tokens/s156 \times 10^{12} \div (65.6 \times 10^9) \approx 2400 \text{ tokens/s}156×1012÷(65.6×109)≈2400 tokens/s。
-
推理吞吐（带宽视角） ：
显存带宽 ÷ 每 token 权重读取量示例 ：2.0 TB/s÷65.6 GB≈30 tokens/s2.0 \text{ TB/s} \div 65.6 \text{ GB} \approx 30 \text{ tokens/s}2.0 TB/s÷65.6 GB≈30 tokens/s（batch = B 时近似提升为 30 × B）。
-
吞吐上限判定 ：
min(算力上限, 带宽上限)示例 ：Qwen3-32B 单卡 A100 上，带宽上限（30 tokens/s）远低于算力上限（2400 tokens/s），实际吞吐被带宽卡住。
-
首 token 延迟 ：
Prefill 时间 + 首次 Decode 时间；单 token 延迟 ：1 ÷ Decode 吞吐示例 ：输入 1000 token 时，Prefill 约 0.42 s（见 4.3 节），加上首次 Decode 约 33 ms，首 token 延迟约 0.45 s ；生成阶段单 token 延迟 = 1 ÷ Decode 吞吐，约 33 ms。
6.2 常见估算误区
-
只算权重、忽略 KV Cache ：KV Cache 既随序列长度 线性增长，也随并发路数 线性增长------两者相乘才是真实占用 。示例中 Qwen3-32B 序列 4096 时每路 KV Cache 约 1.1 GB（每 token 约 0.26 MB）；序列拉到 32K 约 8.6 GB、128K 超过 34 GB。注意这是单路的量：10 路并发、序列 32K 就是 86 GB，单卡直接撑爆。
-
混淆 FLOPs 与 FLOPS ：FLOPs 是运算总次数 （如 65.6 GFLOPs），FLOPS 是运算速率（如 312 TFLOPS）。前者用于算单次计算量，后者用于算吞吐上限，二者单位不同，混用会导致数量级错误。
-
忽视带宽瓶颈：对 32B 级及以上模型，单卡推理吞吐往往被显存带宽卡住而非算力。示例中算力上限 2400 tokens/s、带宽上限仅 30 tokens/s，若只按算力规划会严重高估并发能力。
-
忽略框架与激活值开销：总显存需在权重 + KV Cache 基础上再加 10%~20% 框架开销。示例中 67.1 GB 加 15% 后到 77.2 GB，对 80 GB 卡只剩不足 4% 余量------"装得下"和"能承载并发"是两件事。
-
只算显存、不算服务器内存：推理时权重需从 CPU 内存加载到显存，内存至少需容纳权重并留出运行时开销。示例中 66 GB 权重建议配 ≥ 128 GB 内存，内存不足会导致加载失败或频繁换页。
-
把理论峰值当实际吞吐 ：必须区分两类指标，不能套用同一个折扣系数：
指标 实际可达峰值的比例 原因 算力（FLOPS） 30%~60% 受 kernel 实现、算子融合、MFU 影响（本文 4.3 节取 50%） 显存带宽 60%~90% Decode 是访存密集型（GEMV），带宽利用率反而较高 因此本文 4.3 节用"满带宽 2.0 TB/s"估算出的 30 tokens/s 是合理的（与 A100 + vLLM 实测的 25~50 tokens/s 吻合），不能再套用 30%~60% 二次打折------那会得到 9~18 tokens/s，反而错得更远。
-
用单请求吞吐线性推算并发能力 ：30 tokens/s 是单请求下的 Decode 吞吐，不能简单地"乘并发数"当成总吞吐。正确做法是：先用「带宽 ÷ 权重读取量 × batch」估算总吞吐上限，再用「权重 + 并发数 × 单请求 KV Cache」复核总显存是否够用（见 6.3 节）。
-
为「保证数值精度」而上 FP32 ：这是代价最高的一类误区。权重量化精度 ≠ 结果的数值精度 ------模型输出数字（坐标、金额）是文本 token 逐个生成 的，并不经过一次浮点运算，因此 BF16 与 FP32 的输出精度没有差别；FP32 只带来显存翻倍（66 → 131 GB）与速度减半。真正需要守住的是：权重量化不低于 INT8 （INT4 在数值推理与多步推理任务上有实测退化）、数值计算交给 FP64 专业库。详见 6.3 节 GIS 专题。
-
按「4096 序列」估算所有业务 ：4.4 节给出的并发数（如 32B 单卡约 5 路）默认序列 4096 。真实业务差异极大：GIS 坐标密集型业务 单个请求就可能达到 24K token（约 1000 个节点），此时单请求 KV Cache 约 6.4 GB，32B BF16 在单张 A100 80GB 上连 1 路都放不下 。估算前务必先测出业务的真实序列长度。
6.3 部署选型建议
结合第 3.4 节速查表，按部署目标分层建议如下：
| 部署目标 | 推荐模型 | 推荐显卡 | 关键考量 |
|---|---|---|---|
| 轻量对话、单用户 | Qwen2.5 7B / Llama 3.1 8B | RTX 4090（24GB） | 单卡 BF16 即可，INT8 更从容；带宽足够，无需多卡 |
| 中文通用、中等并发 | Qwen2.5 14B | A100 40GB / L40S | 单卡 BF16 可跑；注意 KV Cache 随并发增长 |
| 高质量生成、5~10 人并发 | Qwen3-32B | 2×A100 80GB（TP=2）/ 32B INT8 + A100 80GB | BF16 单卡仅约 5 路并发、余量不足 4%；10 人需双卡，或改用 INT8（单卡可到约 30 路） |
| 复杂推理、高并发 | Llama 3.1 70B / Qwen2.5 72B | 4×A100 80GB / 2×H100（INT8 后） | BF16 约 164 GB，2×80GB 已装不下（见 3.3 节）；必须多卡 TP 并优先 NVLink |
| 信创/私有化 | 昇腾 910B / 寒武纪 590 | 对应国产卡 | 重点评估软件生态与框架适配 |
并发是选型的首要变量：并发数直接决定所需吞吐量，而吞吐量又决定显卡档位与卡数。选型时应先明确「并发用户数 × 每用户期望吞吐」得到总吞吐需求，再反推显卡方案，而不是先定模型再碰运气。
先定标准：到底需要多少 tokens/s？
这是选型里最容易拍脑袋的一步。不同场景的正确答案相差 3 倍以上，笼统地定一个数必然出错。先看参照系。
参照系 ：2026 年主流商业 API 的单流输出速度（Artificial Analysis 及各家实测中位数，单位 tokens/s）：
| 档位 | 代表模型 | 单流速度 |
|---|---|---|
| 快档（轻量 / Flash 类） | Gemini 2.5 Flash ≈ 224、DeepSeek V4 Flash ≈ 198、GPT-5.6 Luna ≈ 185、Claude Haiku 4.5 ≈ 183 | 130~230 |
| 中档（通用主力） | Gemini 3.1 Pro ≈ 115、Claude Sonnet 5 ≈ 76、DeepSeek V4 Pro ≈ 63 | 60~130 |
| 慢档（旗舰推理 / 编程专用） | GLM-5.3 ≈ 60、Claude Opus 5 ≈ 54、Kimi K3 ≈ 41、Qwen3.8-Max ≈ 36 | 35~60 |
可见主流区间是 40~220，中位数落在 60120**------早年流传的「2060 tokens/s 就流畅」已经明显过时，不宜再作为目标值。另注意：上表是单流速度**，与厂商宣传的「300+ tokens/s」（服务端聚合吞吐，或混算了 Prefill token）不是一回事，详见 4.4 节原则②。
分场景建议值：
| 场景 | 单次输出规模 | 建议速度 | 关键依据 |
|---|---|---|---|
| 交互式对话 / 问答（本文并发规划口径） | 每轮 50~300 token | ≥ 30 tok/s（40+ 舒适） | 人阅读中文约 5~8 字/s，生成快于阅读即「跟手」；低于 15 tok/s 才会明显卡顿 |
| 代码生成（对话式，一次出函数/文件） | 每次 150~800 token | ≥ 60 tok/s，建议 100+ | 一个 300 token 的函数：30 需 10 s、60 需 5 s、100 需 3 s。代码要「整块读完才能验证」，等待感远强于聊天 |
| Agent / 多步工具调用 | 每步 100~400 token × 5~20 步 | Decode ≥ 60，且单步端到端 ≤ 5~8 s | 延迟按步数线性叠加 ；此时瓶颈常是 Prefill 而非 Decode，见下方专门分析 |
| 行内代码补全（Copilot / Tab 类） | 每次 5~30 token | 端到端 p50 < 300 ms | 必须在你敲下一个键之前出现。此时不看 tokens/s，只看总延迟，通常要小模型 + 专用优化，自部署很难达标 |
| GIS 空间查询 → SQL / 工具调用 | 每次 100~400 token | ≥ 40 tok/s，TTFT ≤ 2 s | 输出短，瓶颈在 Prefill；必须开 Prefix Caching，详见下方 GIS 专题 |
| GIS 坐标串 / GeoJSON 生成 | 每次 500~5000 token | ≥ 60，建议 100+ | 坐标约 24 token/点，比代码还密------要按「点/秒」折算，60 tok/s 仅约 2.5 点/s |
| 长文 / 报告生成 | 每次 1000~5000 token | ≥ 40 tok/s | 输出长、容忍度较高，但过慢会导致中途放弃 |
| 批量离线生成 | 不限 | 越高越好，只看总吞吐 | 不关心单流延迟 |
为什么 coding / agent 必须单独定标准？ 三个原因：
① 输出量比聊天大一个量级 。实测 Claude Code 完成一个任务平均输出约 4,200 token ------30 tok/s 要 140 秒，100 tok/s 只要 42 秒。同样是「等 3 秒还是 10 秒」的差别，在代码场景里被放大成「等 40 秒还是等 140 秒」。
② 代码的 token 密度更高 。缩进、括号、换行、符号都是独立 token，一行代码约 5~15 token，一个 300 行的文件就是 1,500~3,000 token。
③ 代码要「整块可读」才有意义 。聊天可以边流边读；代码却要等函数/文件完整，才能判断是否可用、能否编译运行------等待是整块的，不是流式的，所以感知上比同等速度的聊天慢得多。
特别分析：Agent 场景的延迟是「按步叠加」的，不能只看 tokens/s
Agent 循环每一轮都是一次完整的模型调用，且上下文逐轮变长：
单步耗时=TTFT（Prefill）+输出 token 数Decode 速度+工具执行时间任务总耗时=∑i=1n单步耗时i单步耗时 = TTFT（Prefill） + \frac{输出\ token\ 数}{Decode\ 速度} + 工具执行时间 \qquad 任务总耗时 = \sum_{i=1}^{n} 单步耗时_i单步耗时=TTFT（Prefill）+Decode 速度输出 token 数+工具执行时间任务总耗时=i=1∑n单步耗时i
示例：8 步 Agent 任务，上下文 16K，每步输出 250 token，工具执行约 1.5 s/步：
| 组件 | A100 单卡 Qwen3-32B（30 tok/s） | 商业 API（100 tok/s） |
|---|---|---|
| Prefill / 步（未开缓存，16K 全量重算） | 16K÷2400≈16K \div 2400 \approx16K÷2400≈ 6.7 s | ≈ 0.5 s |
| Decode / 步（250 token） | 250÷30≈250 \div 30 \approx250÷30≈ 8.3 s | 2.5 s |
| 工具执行 / 步 | 1.5 s | 1.5 s |
| 单步合计 | ≈ 16.5 s | ≈ 4.5 s |
| 8 步总计 | ≈ 132 s | ≈ 36 s |
把「提速」和「开缓存」拆开看，收益差别很大（下表基于上例的 8 步任务）：
| 配置 | Prefill/步 | Decode/步 | 单步合计 | 8 步总计 | 相对现状 |
|---|---|---|---|---|---|
| 30 tok/s，无缓存（单卡 32B 现状） | 6.7 s | 8.3 s | 16.5 s | ≈ 132 s | --- |
| 100 tok/s，无缓存（只堆带宽） | 6.7 s | 2.5 s | 10.7 s | ≈ 86 s | 仅 1.5 倍 |
| 30 tok/s + Prefix Caching（命中 70%） | 2.0 s | 8.3 s | 11.8 s | ≈ 94 s | 1.4 倍 |
| 100 tok/s + Prefix Caching（命中 70%） | 2.0 s | 2.5 s | 6.0 s | ≈ 48 s | 2.75 倍 |
（Prefix Caching 命中 70% 时，需重算 16K×30%=4.8K16K \times 30\% = 4.8K16K×30%=4.8K token，4.8K÷2400≈2.04.8K \div 2400 \approx 2.04.8K÷2400≈2.0 s。）
这张表给出两个反直觉的结论：
- 单纯提速的收益被固定成本稀释 。Decode 快了 3.3 倍（30 → 100），总耗时却只降了 1.5 倍------因为 Prefill（6.7 s）与工具执行（1.5 s）是与速度无关的固定成本 。想拿到全部收益，必须同时开 Prefix Caching；两者叠加才有 2.75 倍。
- Agent 场景里 Prefill 甚至比 Decode 更值得先优化 。上例未开缓存时，单卡 Prefill 占 6.7 s，与 Decode 的 8.3 s 几乎相当；而按 4.3 节，单卡 Prefill 吞吐约 2400 tokens/s，16K 上下文全量重算就要约 6.7 s，32K 时约 13 s ------上下文越长越致命。这也解释了为什么生产环境普遍采用 PD 分离（Prefill/Decode 拆到不同实例）。
给「单卡 A100 + 32B、跑 coding/agent」的优化优先级 （按性价比排序，前三项不损失精度）：
① 开 Prefix Caching / Prompt Caching （vLLM、SGLang 默认支持）------省掉每轮重复的上下文重算，对 Agent 是数量级 的收益，零精度损失；
② 上 INT8 / FP8 量化 ------Decode 从 30 提到约 59 tok/s，并发从 5 路提到约 30 路；
③ 开推测解码（Speculative Decoding） ------代码里的 import、函数签名、样板结构高度可预测，草稿接受率显著高于自然语言，通常可再提速 1.5~3 倍 ，且输出分布与原模型严格一致；
④ 模型分层路由 ------Agent 中多数步骤（格式化工具调用、简单判断）用 14B（约 69 tok/s）足够，只把复杂生成留给 32B；
⑤ 最后才是加卡 / 换 H100、H200（只提速 1.7~2.4 倍，不改善并发）。
「每人 100 tokens/s」到底对不对？ 要区分两件事：单流体验目标 与并发规划标准 不是一回事。coding/agent 的单流体验目标确实应该定在 60~100 tok/s；但做并发规划时若按 100 摊销，会推出「RTX 4090 跑 7B（约 62 tok/s）连 1 个人都不够用」这类与事实相反的结论------因为交互式对话 30 tok/s 已流畅，且真实用户不会全程满速占用。结论：并发规划按 30 摊销，coding/agent 的单流目标按 60~100，两者不冲突。
特别分析：GIS / 空间数据场景（坐标密集 + 高精度 + 长上下文）
GIS（地理信息系统）场景与通用对话、coding 都有本质差异，直接套用前面的标准会严重低估资源需求。它有三个特殊性：
| 特殊性 | 后果 |
|---|---|
| ① 坐标文本的 token 膨胀率极高 | 一个坐标点的 token 成本约等于 24 个汉字，输入与输出双双放大 |
| ② 精度要求跨越 4 个数量级 | 从米级（一张图浏览）到厘米级（不动产登记界址点） |
| ③ 几何计算不能交给 LLM | 面积、距离、拓扑关系必须由专业空间库在 FP64 下完成 |
下面逐一展开，其中第（1）条纠正了一个普遍存在且代价高昂的误解。
（1）必须先澄清：权重量化精度 ≠ 坐标精度，不要为此上 FP32
这是 GIS 场景最容易踩、代价也最大的一个坑。很多人的直觉是「我的坐标要 8 位小数，模型得用高精度（FP32）推理」------这个推理链是不成立的。
原因在于：BF16 / FP32 说的是模型「权重」的存储精度，而模型输出坐标是「文本 token 逐个生成」的 。108.12345678 这 12 个字符（11 个数字 + 1 个小数点）是一个个 token 拼出来的，只要模型的记忆与抄写能力足够，BF16 权重同样能一字不差地输出完整 8 位小数------它并不经过一次浮点数运算。
那么这些浮点格式在真实坐标量级下到底有多准？下表按 IEEE 754 计算各格式的 ULP（相邻两个可表示数的间隔，最大舍入误差为其一半）：
| 坐标类型 | 示例值 | FP64 分辨率 | FP32 分辨率（ULP） | BF16 分辨率（ULP） |
|---|---|---|---|---|
| 纬度（度，8 位小数） | 34.12345678 | 纳米级 | 3.8×10−63.8 \times 10^{-6}3.8×10−6 度 ≈ 0.42 m | 0.25 度 ≈ 2.8 万 km |
| 经度（度，8 位小数） | 108.12345678 | 纳米级 | 7.6×10−67.6 \times 10^{-6}7.6×10−6 度 ≈ 0.85 m | 0.5 度 ≈ 5.6 万 km |
| 高斯投影 X（北坐标，7 位整数） | 3456789.1234 m | 纳米级 | 0.25 m | 16 km |
| 高斯投影 Y（东坐标，带带号 8 位整数） | 38456789.1234 m | 纳米级 | 4.0 m | 262 km |
注意最要命的一行：高斯投影 Y 坐标带带号时是 8 位整数 ，FP32 只有 24 位尾数，在 2252^{25}225 量级上分辨率退化到 4 米 ------用它存国家 2000 坐标系的投影坐标，误差可达数米。这也是为什么所有 GIS 数据链路（PostGIS、SuperMap、GeoPandas）都强制用 FP64（double）存坐标。
由此得到三条可执行的结论：
- LLM 权重用 BF16 就够，上 FP32 是无效投入 。FP32 会让显存翻倍（66 → 131 GB）、速度减半，而输出坐标的精度一分不涨。省下的显存用来开并发或换更大模型，收益大得多。
- 权重量化的底线是 INT8，不要用 INT4 。虽然坐标输出是文本，但量化确实会损伤模型的数值推理与长数字串处理 能力------已有研究给出理论证明（低精度下迭代加法、乘法需要超多项式规模的模型才能完成），实测也显示：INT8 / FP8 基本无损，而 INT4 在多步推理任务上会出现两位数百分点的退化。BF16 完全安全，INT8 可接受，INT4 不用。
- 坐标一旦离开 LLM，全程 FP64 。入库、投影转换、空间分析、序列化（GeoJSON 的
COORDINATE_PRECISION至少 7 位）都要卡住，且绝不要让float32出现在任何一环。
（2）速度标准：坐标的「有效生成速度」要按点折算
GIS 场景不能只看 tokens/s------因为坐标的 token 密度比代码还高 。按 Qwen 系列分词器逐位切分数字的规则（与 GPT 系「3 位一组」不同，这是 Qwen 的刻意取舍，便于算术对齐）：
单个经纬度对=11⏟108.12345678 的数字+1+10⏟34.12345678 的数字+1≈24 token\text{单个经纬度对} = \underbrace{11}{108.12345678\ 的数字} + 1 + \underbrace{10}{34.12345678\ 的数字} + 1 \approx \mathbf{24\ token}单个经纬度对=108.12345678 的数字 11+1+34.12345678 的数字 10+1≈24 token
对照中文（1 字 ≈ 1 token），一个坐标点的信息成本约等于 24 个汉字。由此折算「有效生成速度」：
| 配置 | tokens/s | 6 位小数（20 token/点） | 8 位小数（24 token/点） |
|---|---|---|---|
| 32B BF16 单卡 A100 | 30 | 1.5 点/s | 1.25 点/s |
| 32B INT8 单卡 / 14B BF16 | 60 | 3.0 点/s | 2.5 点/s |
| 理想目标 | 100 | 5.0 点/s | 4.2 点/s |
这个换算很反直觉，但非常关键 ：生成一段含 100 个界址点的坐标串，60 tok/s 需要 100×24÷60≈100 \times 24 \div 60 \approx100×24÷60≈ 40 秒 ；而生成一个 300 token 的函数只要 5 秒------同样「60 tok/s」，坐标场景的等待感是代码场景的 8 倍。这也是很多团队「明明测出 60 tok/s 觉得很流畅，一上 GIS 业务就卡」的原因。
GIS 分场景建议值：
| 场景 | 输出规模 | 建议标准 | 说明 |
|---|---|---|---|
| 空间查询意图理解 → SQL / 工具调用 | 100~400 token | Decode ≥ 40，TTFT ≤ 2 s | 输出短，瓶颈在 Prefill；配合 Prefix Caching 收益极大 |
| 空间分析结果解读 → 报告 | 500~2000 token | ≥ 50 tok/s | 与长文生成同档 |
| 坐标串 / GeoJSON 生成 | 500~5000 token | ≥ 60，建议 100+ | 按上表折算成「点/秒」再判断是否可接受 |
| 批量图斑 / 影像解译结果处理 | 不限 | 只看总吞吐 | 离线，不关心单流延迟 |
（3）Token 成本：坐标是第一开销，且会直接击穿并发上限
输入侧的膨胀同样致命。一个含 1000 个节点 的地块边界，8 位小数下约 1000×24=24,0001000 \times 24 = 24,0001000×24=24,000 token------相当于 2.4 万汉字，已经接近一篇长报告。这带来两个连锁后果：
-
Prefill 压力远大于 Decode ：24K token 在 A100 单卡（Prefill 约 2400 tok/s）全量重算就要约 10 秒 。GIS 场景的瓶颈通常在 Prefill 侧，与聊天场景完全相反。
-
并发上限被 KV Cache 直接击穿 ：按 4.4 节公式，24K 序列下单请求 KV Cache 约 24K÷4096×1.1≈6.424K \div 4096 \times 1.1 \approx 6.424K÷4096×1.1≈6.4 GB，则
B=(80×0.92−66−2)÷6.4=5.6÷6.4≈0.9 路B = (80 \times 0.92 - 66 - 2) \div 6.4 = 5.6 \div 6.4 \approx \mathbf{0.9\ 路}B=(80×0.92−66−2)÷6.4=5.6÷6.4≈0.9 路
即 32B BF16 在单张 A100 80GB 上，面对 24K 长上下文连 1 路都放不下 ------这与 4.4 节按 4096 序列算出的「约 5 路」相差 5 倍以上。若改用 INT8（权重 33 GB），B=(73.6−33−2)÷6.4≈B = (73.6 - 33 - 2) \div 6.4 \approxB=(73.6−33−2)÷6.4≈ 约 6 路。
降低 token 消耗的手段（按收益排序）：
| 手段 | token 节省 | 说明 |
|---|---|---|
| ① 坐标不进 prompt------传图层名 + 要素 ID，由 PostGIS / 空间库按需取用 | 接近 −100% | 根本解，配合工具调用使用 |
| ② 只回传统计结果------让空间库先完成查询/统计，只把面积、数量、bbox 等结论给模型 | −90% 以上 | 绝大多数 GIS 问答并不需要原始节点 |
| ③ 降精度到业务够用的位数 | 8 位 → 6 位 −17% | 必须先确认业务精度底线，见下表 |
④ 整数微度编码 （去掉小数点，如 108123456） |
约 −25% | 需在 prompt 中约定格式，可读性下降，谨慎使用 |
降精度前必须核对业务精度底线（纬度方向，1 度 ≈ 111 km）：
| 小数位数 | 地面精度 | 典型业务 |
|---|---|---|
| 5 位 | ≈ 1.1 m | 一张图浏览、宏观展示 |
| 6 位 | ≈ 11 cm | 国土空间规划、一般图斑分析 |
| 7 位 | ≈ 1.1 cm | 不动产登记界址点、地籍调查（普遍要求 5~10 cm 级，以现行规范为准） |
| 8 位 | ≈ 1.1 mm | 精密测绘、工程放样 |
经度的地面精度随纬度升高而降低（中国约 35°N 处 1 度 ≈ 91 km），上表按纬度方向给出，经度方向略优。
（4）GIS 场景推荐配置
| 项目 | 推荐 | 理由 |
|---|---|---|
| 模型 | Qwen3-32B（中文 GIS 术语覆盖好、支持长上下文）；轻量步骤可下沉到 14B | 自然资源领域术语与公文表述密集，中文能力优先 |
| 权精度 | BF16 （不要 FP32 ）；量化底线 INT8 ，不采用 INT4 | 见（1）；FP32 无精度收益却翻倍显存 |
| 显卡 | 2×A100 80GB（TP=2）起步；长上下文/高并发上 H200（141GB） | 长上下文下 KV Cache 是主要压力，单卡 80GB 不足 1 路 |
| 上下文 | 32K 起步，必须开 PagedAttention + Prefix Caching | 见（3），Prefill 是主瓶颈，缓存收益最大 |
| 架构 | LLM 只做意图理解 + 工具编排 ；几何计算（面积/距离/拓扑/投影转换）交给 PostGIS / SuperMap iObjects（FP64） | 从根上消除精度风险 |
| 输出校验 | 坐标做**正则 + 范围（经纬度/投影域）+ 拓扑（面积、自相交）**三重校验 | 大模型输出坐标存在「位数丢失」「首尾不一致」等典型错误 |
| 信创要求 | 昇腾 910B / 寒武纪 590 需重点评估：长上下文算子支持、框架适配、坐标相关精度表现 | 国产卡生态差异大于算力差异 |
一句话总结 GIS 场景 ：BF16 权重 + FP64 空间库 + 坐标不进 prompt。前两项解决精度与成本，第三项解决 token 与并发------这三件事做对，比换更贵的卡有效得多。
并发对选型的影响路径：
-
并发 → 吞吐需求 ：按「并发人数 × 每人 30 tokens/s」估算总生成吞吐。例如 10 人并发需约 300 tokens/s 。对照 4.4 节：单张 A100 80GB 跑 Qwen3-32B BF16 的总吞吐约 140 tokens/s、显存只够 5 路------单卡撑不住 10 人并发，需双卡或 INT8。
-
并发 → KV Cache 显存 ：KV Cache 按「并发路数 × 序列长度」线性累积。10 路并发、序列 4096 时，Qwen3-32B 的 KV Cache 从单路约 1.1 GB 涨到约 11 GB，总显存需求为：
(66+11+0.01)×1.15≈88.6 GB(66 + 11 + 0.01) \times 1.15 \approx \mathbf{88.6\ GB}(66+11+0.01)×1.15≈88.6 GB
已超过 80 GB 上限。（注意不能简单用"77.2 + 11"------77.2 GB 里已含 1 份 KV 且已乘过 15% 系数，会重复计入。）
-
并发 → 批大小与带宽摊薄 ：高并发下增大批大小，让多个请求共享一次权重加载，摊薄每 token 的权重读取开销。但每轮还要多读 B 份 KV Cache ，所以总吞吐应按 4.3 节的 B×带宽÷(权重+B×单请求 KV Cache)B \times 带宽 \div (权重 + B \times 单请求\ KV\ Cache)B×带宽÷(权重+B×单请求 KV Cache) 计算，而非简单的「30 × B」。这也是生产环境常用「连续批处理（continuous batching）」提升吞吐的原因。
按并发档位快速选型：
下表按「每人 30 tokens/s （交互式对话）、序列 4096、BF16」估算。并发数取 4.4 节两条约束的较小值，已计入 KV Cache 随 batch 增长与约 15% 通信/调度开销，并留有安全余量：
| 并发档位 | 总吞吐需求 | 推荐方案 | 单请求速度 | 说明 |
|---|---|---|---|---|
| 个人 / 1~2 人 | 30~60 tokens/s | 7B + RTX 4090（24GB） | ≈ 62 tokens/s | 显存余量大，可开到约 15 路；单人速度已超 40 tokens/s |
| 小团队 / 3~10 人 | 90~300 | 7B + 4090（到顶） / 14B + A100 40GB | 62 / 54 | 4090 的 24GB 是并发瓶颈；14B 在 40GB 卡上显存仅够约 7 路 |
| 部门 / 10~30 人 | 300~900 | 14B + A100 80GB 单卡 （性价比最高）/ 32B INT8 单卡 | 69 / 59 | 14B 单卡显存可开约 50 路；32B 必须量化才能上单卡（BF16 只有 5 路） |
| 企业 / 30~50 人 | 900~1500 | 32B + 2×A100 80GB（TP=2） / 70B INT8 + 2×80GB | ≈ 47 / ≈ 48 | 32B BF16 单卡仅约 5 人，必须双卡；TP=2 后每卡只放一半权重，余量大增 |
| 高并发 / 50~100 人 | 1500~3000 | 32B~70B + 4×A100 80GB / 32B + H200（141GB） | ≈ 47~71 | H200 单卡可到约 56 路，是 A100 80GB 的 11 倍------并发靠显存容量，不是靠算力 |
| 100 人以上 | 3000+ | 70B + 4×H100 / 多机集群 | --- | 需连续批处理 + Prefill/Decode 分离部署（PD 分离） |
读表提醒 ：并发数随实际序列长度线性变化。上表按序列 4096 估算；若实际用到 8K，并发数约减半；若只用到 2K，则可翻倍。
⚠️ GIS / 坐标密集业务不要直接套用上表 ：这类业务的序列长度普遍远超 4096（一个 1000 节点的地块边界就约 24K token）。按 4.4 节公式重算，24K 序列下 32B BF16 在单张 A100 80GB 上连 1 路都放不下 （需 INT8 才能到约 6 路）。估算前务必先测出业务的真实序列长度------这是 GIS 场景选型中最容易低估的一项。
选型三步法：
- 先定场景与标准 ：这一步常被跳过，却是后面所有计算的前提。四类场景的标准完全不同 ：交互式对话按每人 30 tok/s 摊销；coding / agent 单流目标 60~100 tok/s，且要按
单步耗时 × 步数预算总时长；GIS 坐标生成要先按「token/点」折算成「点/秒」再判断是否可接受；行内补全则不看 tokens/s，只看端到端延迟 < 300 ms。定好标准再乘并发人数得到总吞吐需求。（批量离线不受此限，只看总吞吐。） - 再算显存（定并发上限） ：用 4.4 节的工程口径
B = (容量 × 0.92 − 权重 − 约 2 GB) ÷ 单请求 KV Cache，算出显存允许的最大并发路数。若不足，规划多卡切分或量化。 - 最后验带宽（定每路速度） ：用
总吞吐 = B × 带宽 ÷ (权重 + B × 单请求 KV Cache)校验每路速度是否达标。coding / agent 与 GIS 场景必须额外验 Prefill ：用上下文长度 ÷ Prefill 吞吐估算 TTFT，并默认开启 Prefix Caching ------这两类场景的瓶颈常在 Prefill 而非 Decode。GIS 还要额外验序列长度 ：坐标密集业务的实际序列往往远超 4096，必须按真实 token 数重算 KV Cache 与并发（24K 序列下 32B BF16 单卡不足 1 路）。不满足时按性价比排序：① 减少输入 token （GIS 收益最大，坐标不进 prompt 可省近 100%）→ ② Prefix Caching → ③ 量化 （并发约 6 倍、速度约 2 倍）→ ④ 推测解码 （代码场景 1.5~3 倍）→ ⑤ 加卡做 TP（配 NVLink） → ⑥ 换更大显存的卡（如 H200）。
通用原则：
- 精度 ：能 BF16 不 FP32；能 INT8 不 BF16------但要分清目的 ：为提速 ，收益约 2 倍；为提并发 ，收益可达约 6 倍（省下的显存几乎全部变成 KV Cache 容量，见 4.4 节）。 ⚠️ 重要纠正：不要为了「保证计算精度」而上 FP32 。权重量化精度与「模型输出结果的数值精度」是两回事，详见下方 GIS 专题的辨析。简言之：BF16 足以胜任坐标、几何、金融类任务；FP32 会让显存翻倍、速度减半，却不带来任何精度收益 。真正需要守住的两条线是：① 权重量化不低于 INT8 （INT4 在数值推理任务上有实测退化）；② 数值计算交给 FP64 的专业库，不要让 LLM 直接算。
- 卡数 ：在显存与延迟均达标时优先单卡 （省成本、免通信）；若单卡延迟或并发不达标，双卡 TP 反而更快也更装得下------此时不应为了"少用一张卡"牺牲体验。多卡务必配 NVLink。
- 卡型 ：并发看显存容量、速度看显存带宽，两者分开选。同为 80GB 时，H100 相对 A100 的收益是速度（约 1.7 倍）而非并发；要提并发请加卡、量化，或选 H200（141GB）。
- 国产卡：优先评估软件生态与框架适配。
三个会显著改变结论的优化（务必纳入评估）：
| 优化手段 | 作用 | 影响量级 | 精度损失 |
|---|---|---|---|
| PagedAttention | 把显存碎片从 20%~40% 降到 < 4% | 直接增大 4.4 节公式里的"剩余空间"，并发数显著上升 | 无 |
| Prefix Caching（前缀缓存） | 复用系统提示词与历史轮次的 KV Cache，省掉重复 Prefill | Agent 场景收益最大------多轮循环下 TTFT 可下降一个量级 | 无 |
| 推测解码（Speculative Decoding） | 小草稿模型先生成、大模型并行验证 | 代码场景 1.5~3 倍（import、函数签名等可预测性高） | 无（输出分布严格一致） |
| FP8 / INT8 KV Cache 量化 | KV Cache 直接减半 | 128K 长上下文时尤其关键（34 GB → 17 GB） | 极小 |
上表前三项都会放宽 本节估算出的并发上限，第四项放宽长上下文能力，因此本文给出的并发数应视为保守下限；落地时请结合所用推理框架（vLLM / TensorRT-LLM / SGLang）的具体实现复核。
注意区分 ：上表的「Prefix Caching / 推测解码」改善的是延迟 ，「PagedAttention / KV Cache 量化」改善的是容量------两者解决的是不同问题，不可互相替代。
一句话评估（给小白）：
| 你的情况 | 推荐方案 | 大概成本量级 |
|---|---|---|
| 个人学习、1~2 人用 | 7B + RTX 4090（24GB） | 一台工作站（约 62 tokens/s，显存还够开 10 多路） |
| 小团队、3~10 人 | 7B + RTX 4090（到顶）/ 14B + A100 40GB | 一台工作站或入门专业服务器 |
| 公司正式对外、10~50 人 | 14B + A100 80GB 单卡（10~30 人）/ 32B + 2×A100 80GB（30~50 人） | 一台专业服务器（32B 用单卡只能带约 5 人，务必双卡或 INT8） |
| 代码生成 / Agent 自用 | 32B INT8 + A100 80GB；或 14B BF16 跑简单步骤、32B 只跑复杂生成 | 速度优先于并发 ：32B BF16 单卡仅约 30 tok/s，代码场景必然卡。必须开 Prefix Caching + 推测解码，比换卡划算得多 |
| GIS / 自然资源（一张图、不动产、空间规划） | 32B BF16 + 2×A100 80GB（TP=2）；几何计算走 PostGIS / SuperMap iObjects（FP64） | 权重用 BF16 即可，不要用 FP32 （不提升坐标精度却翻倍显存）。坐标不进 prompt、只回传统计结果；长上下文下必须开 Prefix Caching |
| 高并发、50 人以上 | 32B~70B + 4×A100 80GB / H200 / 多机 | 多卡服务器或集群级投入 |
记住五句话：
① 先定「什么场景 + 几个人用」，再定「模型多大」，最后定「买什么卡」 。场景直接决定速度标准------聊天 30 tok/s 够用，代码生成要 60+，Agent 要 60~100 且按步数预算，GIS 坐标生成要按「点/秒」折算，行内补全是另一套（看总延迟 < 300 ms）。笼统套一个数必然选错。
② 装得下 ≠ 跑得动 ------显存容量只决定"能不能把模型加载进去"；能不能带人，要看扣掉权重后还剩多少空间给 KV Cache（4.4 节）。
③ 提速靠带宽、提并发靠显存 ------这是两个互相独立的维度，买卡时必须分开算。同为 80GB 时，H100 相对 A100 只是"更快"（约 1.7 倍），并不"更能带人"（并发上限都是约 5 路）；要提并发，请加卡、量化，或选更大显存的卡（如 H200 141GB，约 56 路）。
④ Agent / coding / GIS 场景，先优化 Prefill 再优化 Decode ------延迟按步数线性叠加 ，未开缓存时 16K 上下文全量重算就要约 6.7 s，已与 Decode 相当。先把 Prefix Caching → 量化 → 推测解码 这三项零精度损失 的手段用满，再考虑加卡换卡。GIS 还要优先做「输入瘦身」（坐标不进 prompt），这比任何硬件升级都有效。
⑤ 精度分两层看：权重精度 ≠ 结果精度 ------BF16 足够胜任坐标、几何、金融类任务，上 FP32 不提升任何精度，却让显存翻倍、速度减半 。需要守住的两条线是：权重量化不低于 INT8 （INT4 在数值推理任务上有实测退化），数值计算交给 FP64 专业库（GIS 即 PostGIS / SuperMap）。别用「换更高推理精度」去解决一个它根本不管的问题。
附：数据来源与口径说明
- 显卡参数 （显存容量、带宽、算力）整理自各厂商公开规格页与官方产品文档。为便于横向比较，专业卡算力统一取张量核 BF16/FP16 稠密 峰值，消费卡统一取 FP32（CUDA 核） 峰值，并在 2.1 节注明两者口径不可直接比较。厂商参数可能随驱动、固件、批次调整，实际以采购时的最新规格为准。
- 国产卡 一栏受公开资料限制，部分算力/带宽为约值或厂商宣传值，选型前建议索取厂商正式规格书并实测。
- 模型参数量与权重显存按公开权重配置计算，未计入进程开销之外的额外缓冲。
- 浮点格式在坐标量级下的分辨率 （6.3 节 GIS 专题表）按 IEEE 754 定义计算：ULP =2e−m= 2^{e-m}=2e−m，其中 eee 为指数位、mmm 为尾数位数（FP32 取 23、BF16 取 7）；最大舍入误差为 ULP 的一半。地面距离换算按纬度 1 度 ≈ 111.32 km，经度随纬度升高而减小（约 35°N 处 1 度 ≈ 91 km）。
- 坐标的 token 数 （约 24 token / 经纬度对）按 Qwen 系列分词器「数字逐位切分」 的规则估算。注意这与 GPT 系「数字每 3 位一组」不同（同一个数在 Qwen 下可能是 GPT 的 2~3 倍 token），换用其他模型时 token 数会有明显差异，请以实际分词器实测为准。
- 量化对精度的影响 （INT8/FP8 基本无损、INT4 在多步推理任务上明显退化）引自公开研究：ACL 2025《How Numerical Precision Affects Arithmetical Reasoning Capabilities of LLMs》（低精度下迭代加法与乘法需超多项式规模）、《Quantization Hurts Reasoning?》（W8A8KV8 近无损、4-bit 显著退化）。落地前建议在自身业务评测集上做 A/B 验证，而非仅依赖公开基准。
- 业务精度底线 （如不动产登记界址点 5~10 cm 级）为行业通行要求概述，具体项目请以现行国家标准与行业规范为准（如《地籍调查规程》等）。
- 成本量级为定性描述，不含具体报价------显卡与整机价格随市场、渠道、批量波动较大，正式方案请以商务询价为准。
- 推理性能估算 （首 token 延迟、tokens/s）属于理论峰值下的量级判断，实际值受推理框架（vLLM / TensorRT-LLM）、kernel 实现、批处理策略、卡间通信影响很大，建议以目标框架的实测 benchmark 为准。
- 商业 API 速度 （6.3 节参照系）取自 Artificial Analysis 及厂商公开实测的单流 中位数，统计时间为 2026 年 10 月 。各源之间存在口径差异（是否含网络往返、输入/输出长度比、是否含推理思考 token、缓存命中率），同一模型在不同来源可相差 2~3 倍，故正文只给量级区间。厂商迭代极快，引用前请复核当日数据。
- 特别提示 ：厂商宣传的「300+ tokens/s」通常是服务端聚合吞吐 或混算 Prefill token，与单流体验无关，不可直接对比（见 4.4 节原则②与 6.3 节）。
- Agent 延迟模型 （6.3 节）为简化线性叠加模型，未计入排队等待、重试、上下文压缩、并行子任务等因素；真实 Agent 的 token 放大系数可达 4~15 倍（多智能体架构下验证步骤可占总 token 的 70%+），实际延迟需按目标框架实测。