在企业落地大模型时，最常见的误区是：只看参数规模，不看算力匹配。结果往往是——模型能跑，但跑不动；或者算力很强，但性能发挥不出来。很多时候可能靠“猜”去验证，和预想的结果相差甚远，在验证模型适配性和性能压测时，经常会遇到如下两个问题：

• 模型能不能跑起来（显存）
• 模型能跑多快（tokens/s）

本文以 NVIDIA GB10 、vLLM、 Qwen3.5-35B-A3B-FP8 这组黄金拍档为例，从理论和实测数据展开。

1、评估模型能不能跑起来

判断模型能不能在设备上跑起来，会不会 OOM，本质是显存测算。

测算模型的显存占用需要先了解模型的具体数据，例 Qwen3.5-35B-A3B-FP8 模型的数据可以在 HuggingFace 中查询到，关键信息如下：

Number of Layers: 40
KV heads：2
Head Dimension: 256
dtype：FP8（1 Byte）

1.1 显存占用的本质

总显存 = 模型权重 + KV Cache + 运行时开销

实际可以简化成

总显存 ≈ 模型权重 + KV Cache

说明：KV Cache 是大模型推理时的核心优化手段，和 Transformer 原理紧密相关，典型的以空间换时间的设计

1.2 模型权重计算

Qwen3.5-35B-A3B-FP8 的总参数是 350 亿，精度是 FP8（1 Byte）

模型权重显存 = 35 B x 1 Byte ≈ 35 GB

说明：上述结果为 Qwen3.5-35B-A3B-FP8 的固定值，若使用 FP4 精度，则显存占用减半 35 B x 0.5 Byte；该模型是 MoE 模型，MOE 省算力，但不省显存

1.3 KV Cache 计算

和模型权重占用显存不一样，KV Cache 占用显存受诸多因素制约，主要包含以下几点

• 上下文长度（input + output）
• 并发数

KV Cache 计算公式：

KV Cache ≈ 并发 × token × Layers × KV heads × head_dim × 2 × dtype
 
释义：
token： 包含input 和 output
Layers： 模型总的注意力层数，可在 HuggingFace 中查询
KV heads： 注意力头数量，可在 HuggingFace 中查询
head_dim： 注意力头维度，可在 HuggingFace 中查询
2： 注意力机制需要同时缓存 Key 和 Value 两个向量，固定乘以 2
dtype： 模型精度，此为 FP8 精度，此为 1 Byte

示例1：中等上下文（1024 / 512，5并发）

总 token = 1024 + 512 = 1536

单请求占用 KV ≈ 1536 × 40 × (2 × 256 × 2 × 1B) ≈ 60 MB

5并发： 5 x 60M ≈ 300 MB

示例2：长上下文（256K / 10K，5并发）

总 token = 256K + 10K = 266K

单请求占用 KV ≈ 266K × 40 × (2 × 256 × 2 × 1B) ≈ 10 GB

5并发： 5 x 10GB ≈ 50GB

⚡特别说明：上下文长度显著影响 KV Cache 显存占用，请合理规划上下文限制

1.4 显存评估

示例1：中等上下文（1024 / 512，5并发）
总显存 = 模型权重 + KV Cache + 运行时开销 = 35GB + 0.3GB + 冗余 ≈ 40GB

示例2：长上下文（256K / 10K，5并发）
总显存 = 模型权重 + KV Cache + 运行时开销 = 35GB + 50GB + 冗余 ≈ 90GB

2、评估模型能跑多快

模型能跑多快（Tokens/s）同时受算力和显存带宽限制，属于典型的木桶效应：

TPS ≈ min(算力上限, 显存带宽上限)

2.1 计算算力上限

GB10算力：
GB10 在NVFP4 精度下的算力是 1000 TFLOPS，未公布 FP8 精度下的算力，折算成 FP8：≈ 500 TFLOPS

单 token FLOPs 估算：
Qwen3.5-35B-A3B-FP8 是 MoE 模型，激活参数是 3B
FLOPs/token ≈ 2 × 激活参数量 = 6 GFLOPs
理论TPS：

TPS_compute = 算力 / 每token FLOPs
                       ≈ 500 / 0.006
                       ≈ 83,000 tokens/s

看起来很高，但这是理论值。

2.2 计算带宽上限

GB10带宽：
通过官方手册可查询到显存带宽为 273 GB/s

每 token 需要读取的数据：
权重访问 ≈ 激活参数 × dtype ≈ 3B × 1 Byte ≈ 3 GB
KV Cache（以长上下文为例）≈ 266K × 1KB ≈ 0.26 GB
总数据量 ≈ 3 + 0.26 ≈ 3.26 GB / token

3.3 TPS 计算

TPS_memory = 带宽 / 每 token 数据
           ≈ 273 / 3.26
           ≈ 83 tokens/s

理论约 83 tokens/s

3.4 实际吞吐量

选取算力、带宽计算结果的最小值。

TPS ≈ min(83000, 83)
    ≈ 80 tokens/s

说明：因效率问题，实际结果还需要乘以 0.8 左右的效率系数，最后实际约为 60~70 tokens/s

3.5 一个简化的工程直觉公式

TPS ≈ 带宽 / 激活参数大小 ≈ 273 / 3 ≈ 90 tokens/s（非常接近真实值）

⚡示例：若基于该环境部署 Qwen3.5-27B，则理论输出仅有 10 tokens/s，两者相差近 10 倍，所以在选择模型时显存带宽往往限制 tokens 快慢。
⚡说明：上述计算均为裸模型理论上限，实际部署时可选择 vLLM 提升性能

4、vLLM推理加速

vLLM 不会突破显存带宽限制，但是因为其KV 分页、动态调度等能力，可以显著提高 GPU 利用率 和 并发能力。在单用户和多用户压测时，均体现其价值，工程上能使 GPU 利用率达到 80~90% 左右，并发能力提升 2 ~ 4 倍。

看显存：Dense更省
看吞吐：MoE更强
看并发：优先MoE