Qwen3.8 on Jiangwan's Blog

200K Context 到底需要多少显存？从 KV Cache 算到 Qwen3.8 的真实部署

Fri, 28 Aug 2026 12:00:00 +0800

📚 双 RTX 5060 Ti 部署 Qwen3.8 系列 · 5/6

💡 导读：

长上下文显存最容易算错的地方，是把 Hybrid Attention 模型直接当成传统 64 层 Full Attention。Qwen3.8-27B 实际只有 16 层传统 Full Attention，这会把 200K 的 FP8 KV 理论值从约 12.2 GiB/GPU 改写为约 3.05 GiB/GPU，但真实生产边界仍然要看完整 Runtime。

前面已经把模型权重和 GPU 执行链基本处理清楚了。

接下来真正开始和长上下文抢显存的，就是 Cache。

但这里有一个非常容易算错的问题。

如果把 Qwen3.8-27B 当成一个传统的 64 层 Full Attention 模型，那么在 TP2 + FP8 KV 下，200K Context 会算出大约：

12.2 GiB / GPU

对于一张 16GB 的 RTX 5060 Ti，这几乎意味着根本没有正常部署空间。

但 Qwen3.8-27B 实际不是这种结构。

它采用混合 Attention：

48 × Gated DeltaNet + 16 × Full Attention

真正随着 Context 长度线性增长的传统 KV Cache，主要来自其中 16 个 Full Attention Layer。

重新计算以后：

100K ≈ 1.53 GiB / GPU
200K ≈ 3.05 GiB / GPU

差了整整四倍。

不过这仍然不意味着我的双 5060 Ti 最终能稳定跑 200K。

实际最终采用的是：

2 × RTX 5060 Ti 16GB
Qwen3.8-27B NVFP4
TP2
FP8 KV
CUDA Graph ON
gpu_memory_utilization = 0.97
max-model-len = 100K

vLLM Profile 最终显示：

Maximum Concurrency ≈ 1.07x

这篇真正想回答的就是两个看起来有点矛盾的问题：

为什么 200K 的传统 KV Payload 理论上只有约 3.05GiB / GPU，但最终生产配置却停在了 100K？

以及：

为什么我最后选择 FP8 KV，而没有继续把 KV 压到 INT4？

1. 先把 Qwen3.8 的 KV Cache 算对

自回归生成时，前面 Token 已经算出来的 Key 和 Value 不需要在每一步重新生成，因此会被缓存下来。

概念上可以理解成：

Token 1 → K1 / V1
Token 2 → K2 / V2
Token 3 → K3 / V3
...

对于一层传统 Full Attention，每个 Token 的 KV Cache 可以近似写成：

KV Heads
× Head Dim
× 2（K + V）
× dtype bytes

整个模型则是：

Tokens
× Full Attention Layers
× KV Heads
× Head Dim
× 2
× dtype bytes

因此对纯 Full Attention 模型来说，Context 翻倍，KV Cache 基本也会跟着翻倍。

但这个公式有两个很重要的前提：

模型到底有多少层真正使用 Full Attention；
每层到底需要缓存多少个 KV Head。

Qwen3.8-27B 在这两个地方都不能按“传统 64 层 Transformer”直接套公式。

GQA 先把 KV Head 数降了下来

Qwen3.8-27B 的 Full Attention 部分大致是：

Query Heads = 24
KV Heads = 4
Head Dim = 256

虽然 Query 有 24 个 Head，但真正需要长期缓存的 K/V 只有 4 组。

传统 MHA 更接近：

24 Q / 24 K / 24 V

GQA 则是：

24 Q
 ↓ 共享
4 K
4 V

所以算 KV Cache 时，真正需要代入的是：

KV Heads = 4

而不是 24。

这也是 GQA 对长 Context 显存非常直接的价值。

如果错误地把 64 层全部当成 Full Attention

先故意按传统模型算一次。

条件：

64 Layers
KV Heads = 4
Head Dim = 256
FP8 KV
TP2

TP2 下，4 个 KV Head 分到两张 GPU，每张大致保存 2 个。

每层、每 Token、每 GPU：

2 KV Heads
× 256
× 2（K + V）
× 1 Byte

= 1024 Bytes

64 层：

1024 × 64 = 64 KiB / Token / GPU

200K Context：

64 KiB × 200,000 ≈ 12.2 GiB / GPU

如果 Qwen3.8-27B 真的是 64 层全部 Full Attention，单是 200K 的 FP8 KV 就接近吃掉一张 16GB 卡的大部分显存。

这时候再讨论 23GB 权重、CUDA Graph、Runtime，基本就没有意义了。

问题在于：

Qwen3.8-27B 不是这种结构。

Qwen3.8-27B 只有 16 层传统 Full Attention

Qwen3.8-27B 的 64 层按照下面的模式循环：

3 × Gated DeltaNet + 1 × Full Attention

一共循环 16 次。

最终就是：

48 × Gated DeltaNet
16 × Full Attention

于是传统 KV 重新计算：

2 KV Heads / GPU
× 256
× 2（K + V）
× 1 Byte
× 16 Layers

=
16 KiB / Token / GPU

对应不同 Context：

Context	FP8 Full-Attention KV / GPU
32K	≈0.49 GiB
64K	≈0.98 GiB
100K	≈1.53 GiB
128K	≈1.95 GiB
200K	≈3.05 GiB
256K	≈4.00 GiB

所以同样是 200K：

错误按 64 层 Full Attention：
≈ 12.2 GiB / GPU

按实际 16 层 Full Attention：
≈ 3.05 GiB / GPU

正好差了接近四倍。

这也是为什么面对 Hybrid Attention 模型时，不能只知道“它有 64 层”，就直接套传统 KV 公式。

另外 48 层并不是完全没有状态

Gated DeltaNet 不需要像 Full Attention 一样，为每个历史 Token 保存完整 K/V。

它更接近维护 recurrent state：

历史信息
↓
不断更新 State
↓
当前 State

Full Attention 的传统 KV 是：

Context 越长 → KV 越大

而 Gated DeltaNet 的 recurrent state 本身不是这种“每多一颗历史 Token 就追加一份完整 K/V”的线性增长方式。

因此 Qwen3.8-27B 的 Cache 更准确地理解为：

16 × Full Attention
→ 随 Context 增长的传统 KV Cache

48 × Gated DeltaNet
→ per-sequence recurrent state

这解释了为什么它在超长 Context 下，比“64 层全部 Full Attention”的模型省很多传统 KV。

但同时也提醒我们：

3.05GiB 只是 Full Attention KV Payload，不是整个 Engine 最终的显存成本。

2. 1.53GiB 理论 KV，不等于只多占 1.53GiB 显存

100K FP8 Full-Attention KV 的理论值只有：

≈ 1.53 GiB / GPU

但 GPU 上同时还需要存在：

NVFP4 Weights
Gated DeltaNet State
CUDA Runtime
CUDA Graph
Peak Activation
Workspace
Allocator
KV Block / Metadata
通信 Buffer
框架其他 Buffer

所以实际绝对不能直接做：

16GB
-
权重
-
1.53GB
=
剩余显存

理论公式真正回答的是：

Context 每增加一段，传统 Full Attention KV Payload 大概增长多少？

而真实部署要回答的是：

模型加载、Graph、Activation、State 和所有 Buffer 都存在以后，到底还能留多少 Cache Capacity？

前者靠公式。

后者靠实际 Profile。

3. 从理论 Payload 到真实 Runtime 边界

最终跑通并采用的配置是：

GPU：
2 × RTX 5060 Ti 16GB

Model：
Qwen3.8-27B NVFP4

Parallel：
TP2

KV Cache：
FP8

CUDA Graph：
ON

gpu_memory_utilization：
0.97

max-model-len：
100K

vLLM Profile 给出的：

Maximum Concurrency ≈ 1.07x

更准确的理解不是简单说：

100K × 1.07 = 107K

然后把 107K 当成一个精确的“总 Cache Token 数”。

它更适合被理解为：

在当前 max-model-len = 100K 和当前 Cache 配置下，Profile 估算只能同时容纳大约 1.07 条达到最大长度的 Sequence。

也就是说，这套配置对：

1 × 100K 长上下文

已经比较接近当前 Profile 给出的容量边界，余量并不算大。

这里还要再加一层保险：Qwen3.8-27B 属于 Full Attention + Gated DeltaNet 的 Hybrid Model，vLLM 的 Maximum Concurrency 是当前版本 Cache Manager 根据实际 Cache 配置给出的 Profile 指标，不应该被当成一个脱离版本、Backend 和 Hybrid Cache 实现后仍然精确成立的物理常数。

所以我把：

Maximum Concurrency ≈ 1.07x

理解成：

当前这套 Runtime 配置已经非常接近 1 条最大长度 Sequence 的容量边界。

而不是拿它反推出一个精确的“总 Cache Token 数”。

所以：

200K 传统 KV Payload ≈ 3.05 GiB / GPU

并不能直接推出：

200K 一定能稳定启动并保留 CUDA Graph 等运行配置

决定最终 Context 上限的是整套 Runtime 显存，而不是传统 KV 这一项。

max-model-len 不是“每个请求固定预留这么多 Cache”

设置：

--max-model-len 100000

表示的是：

单条 Sequence 最大允许达到 100K。

它不等于“每来一个请求，就静态给它预留完整 100K KV”。

vLLM 实际维护的是共享 Cache Pool。

概念上，如果当前几个请求分别占用：

请求 A：40K
请求 B：30K
请求 C：20K
请求 D：10K

它们会共同消耗 Engine 的 Cache Capacity。

而不是：

4 × 100K = 400K

全部提前保留。

所以生产 Serving 不能只问：

“我设置 100K，可以并发几条？”

还要看实际请求长度分布、Block 使用情况以及 Hybrid State 的 per-sequence 成本。

Hybrid Model 下，总 Token 相同也不代表显存完全相同

只考虑 Full Attention KV：

1 × 100K

和：

5 × 20K

总 Token 数一样，传统 KV Payload 也接近。

但 Qwen3.8-27B 还有 per-sequence recurrent state。

一条 100K Sequence 只需要一套 Sequence State。

五条 20K Sequence 则需要五套。

除此之外还有：

Scheduler State
Output Buffer
Block Fragmentation
其他 per-request allocation

所以在 Hybrid Model 下：

总 Token 数相同，不代表最终显存占用完全相同。

这也是为什么 Maximum Concurrency 和实际并发能力，最终还得通过真实 workload 测。

4. KV 精度怎么选：BF16、FP8 与 INT4

对于这 16 个 Full Attention Layer，TP2 下：

100K

BF16 KV
≈ 3.05 GiB / GPU

FP8 KV
≈ 1.53 GiB / GPU

200K

BF16 KV
≈ 6.10 GiB / GPU

FP8 KV
≈ 3.05 GiB / GPU

对一张只有 16GB 的 5060 Ti 来说，每卡节省 1.5GB 或 3GB 已经足以直接改变最终可用 Context。

所以我的实际组合是：

Weights：NVFP4
KV：FP8

权重和 KV 根本没有必要追求同一种 bit 数。

它们走的是不同的数据路径，也有不同的性能瓶颈。

INT4 KV 确实更省，但不能只看 bit 数

只从数据量来看：

FP8 = 1 Byte / element
INT4 ≈ 0.5 Byte / element

所以理论上传统 KV Payload 还能再减半。

例如 100K：

FP8 ≈ 1.53 GiB / GPU
INT4 ≈ 0.76 GiB / GPU

200K：

FP8 ≈ 3.05 GiB / GPU
INT4 ≈ 1.53 GiB / GPU

容量收益确实很诱人。

但 KV Cache 和“硬盘压缩”不一样。

Attention 每一轮都要频繁读取这些数据。

INT4 KV 往往还会涉及：

packed INT4 read
↓
unpack
↓
scale / dequant
↓
格式转换
↓
Attention

所以：

Memory Traffic ↓

并不自动等于：

Latency ↓

额外 unpack、scale 和反量化本身也要花算力与 Kernel 开销。

为什么这套 5060 Ti 最后还是选 FP8 KV？

RTX 5060 Ti 属于 Blackwell。

在这套硬件上，我更关心的是：

当前框架的 FP8 Attention / Cache 路径能不能稳定、高效地运行。

而不是单纯追求最低的 KV bit 数。

INT4 KV 的优势很明确：

更省显存
更大的理论 Context

但代价也同样明确：

packed read / unpack
dequant / scale
Kernel 路径更复杂
可能增加 Decode 计算开销
精度风险也更激进

FP8 KV 虽然占用比 INT4 大一倍，但在当前硬件和推理框架里，是一个更自然的平衡点：

容量已经明显低于 BF16
Kernel 路径更成熟
不需要为了进一步压缩增加过多低 bit 解码工作
精度选择也更保守

更重要的是，这套机器使用 FP8 KV 已经可以做到：

100K Context + Maximum Concurrency ≈ 1.07x

对我的真实代码任务来说，这已经够用了。

所以没有必要为了“Context 数字更大”而继续把 KV 压到 INT4，最后反而让 Decode 更慢。

为什么是 NVFP4 权重 + FP8 KV？

表面上看：

Weights：4bit
KV：8bit

好像精度“不统一”。

但实际非常合理。

NVFP4 权重

主要目标是：

让 27B 权重完整 GPU Resident
减少 Weight Traffic
利用 Blackwell 对 NVFP4 的低精度 GEMM 路径

FP8 KV

主要目标是：

降低长 Context 显存
保持更直接的 Attention 执行路径
避免更低 bit 带来的额外 unpack / dequant 成本
保持长上下文稳定性

所以实际部署并不是：

“整个模型统一选一个 bit 数。”

更合理的思路是：

权重、KV、Activation 分别选择当前 GPU 和当前 Kernel 最合适的数据格式。

这也是低精度推理真正进入工程阶段以后，和“模型量化成几 bit”这种单一描述最大的区别之一。

5. 最终配置

最后我实际采用的是：

2 × RTX 5060 Ti 16GB

Qwen3.8-27B NVFP4

TP2

FP8 KV

CUDA Graph ON

gpu_memory_utilization = 0.97

max-model-len = 100K

结果：

Maximum Concurrency ≈ 1.07x

对这套硬件来说，它形成了一个比较合理的平衡：

27B 模型质量
+
权重完整 GPU Resident
+
TP2 Decode 性能
+
100K Context
+
FP8 KV
+
CUDA Graph

而不是为了追求一个单独的：

200K

把 KV 精度、Decode 性能和显存稳定性同时推到极限。

6. 结论

Qwen3.8-27B 的长 Context 显存不能按照：

64 Layers × 传统 KV Cache

直接计算。

它实际是：

48 × Gated DeltaNet + 16 × Full Attention

再加上：

24 Query Heads / 4 KV Heads

的 GQA。

因此 TP2 + FP8 KV 下，仅计算传统 Full-Attention KV Payload：

100K
≈ 1.53 GiB / GPU

200K
≈ 3.05 GiB / GPU

但真实运行还必须容纳：

Weights
Gated DeltaNet State
Runtime
Activation
CUDA Graph
Workspace
Allocator
其他 Buffer

所以最终实际采用的是：

100K Context
FP8 KV
gpu_memory_utilization = 0.97
Maximum Concurrency ≈ 1.07x

这给出了一个我现在很喜欢的判断方式：

公式负责解释显存模型，vLLM Profile 负责找边界，真实长上下文压测负责定生产配置。

而 NVFP4 Weights + FP8 KV 也不是精度选择混乱。

它只是分别给不同数据路径选择更合适的格式。

到这里，“100K 能不能装下”的问题基本结束了。

接下来的问题变成：

100K Context 真正跑起来以后，怎么避免每一轮 Agent 都重复计算几十 K、甚至接近 100K 的相同 Prompt？

下一篇进入整个系列最后一层：

《长上下文推理优化：Prefix Cache、调度与 MTP》

系列导航： ← 上一篇：为什么生产推理我默认 vLLM：从 NVFP4、Kernel 到 CUDA Graph · 下一篇：长上下文推理优化：Prefix Cache、调度与 MTP →

双卡部署大模型：TP、PP、DP 和 Layer Split 到底有什么区别？

Mon, 24 Aug 2026 10:00:00 +0800

📚 双 RTX 5060 Ti 部署 Qwen3.8 系列 · 2/6

💡 导读：

模型单卡放不下以后，“再加一张 GPU”并不是完整答案。Layer Split、Pipeline Parallel、Tensor Parallel 和 Data Parallel 看起来都是多卡推理，实际解决的却是容量、单实例加速和并发吞吐三个不同问题。

上一篇先把显存问题算清楚了：双 16GB 能不能跑 27B，首先取决于权重能不能装下，以及装完以后还剩多少运行空间。

但模型单卡放不下以后，“加一张 GPU”并不是一个完整答案。

多卡部署至少有几种完全不同的思路：

Layer Split
Pipeline Parallel（PP）
Tensor Parallel（TP）
Data Parallel（DP）

它们表面上都是“多张 GPU 跑一个模型服务”，实际解决的问题却不一样。

先记住一个最简单的结论：

Layer Split / PP
主要解决：模型装不下

TP
主要解决：模型装不下 + 单个模型实例的计算并行

DP
主要解决：并发吞吐

下面继续以这套硬件为例：

2 × RTX 5060 Ti 16GB + Qwen3.8-27B

1. Layer Split：最直观的多卡切法

假设模型有 64 层。

最简单的办法就是按层拆：

GPU0
Layer 0 ~ 31
      ↓
GPU1
Layer 32 ~ 63

原本一张 16GB GPU 放不下整个模型，现在变成：

GPU0 放一部分权重。
GPU1 放另一部分权重。

两张卡的容量都被利用起来了。

llama.cpp 的多 GPU layer split，可以先把它理解成这一类思路。

它最大的优势是灵活。

如果两张卡容量甚至不一样，例如：

GPU0：16GB
GPU1：12GB

就可以让 GPU0 多放一些层，GPU1 少放一些。

对于消费级硬件、GGUF、混合显存容量，这种模型放置方式非常实用。

Layer Split 的问题

一颗 token 在 Decode 时仍然要依次经过整套模型：

Token
 ↓
GPU0 上的前半模型
 ↓
GPU1 上的后半模型
 ↓
输出

GPU0 没完成前面的层，GPU1 后面的层就拿不到对应的 Activation。

所以它首先解决的是：

Capacity Scaling——容量扩展。

而不是自动获得：

2× Single-stream Decode Performance。

这也是整个系列里一个很重要的区分：

模型成功分到两张卡，不等于两张卡会同时为同一层工作。

2. Pipeline Parallel：也是按层切，但它是一套执行策略

Pipeline Parallel，简称 PP。

双卡 PP2 可以画成：

Stage 0              Stage 1

GPU0                 GPU1
Layer 0~31   ─────→  Layer 32~63

从模型切分上看，它和 Layer Split 很像：

不同层位于不同 GPU。

但 PP 不只是“把哪些层放哪张卡”的问题。

推理框架还会显式管理：

Pipeline Stage
Stage 间通信
Micro Batch
Pipeline Scheduling
分布式 Runtime

所以我更倾向于这样区分：

Layer Split 更像模型放置方式；PP 是完整的并行执行策略。

PP 能不能让单请求快一倍？

对于单条请求、单 token Decode，通常不能这么理解。

因为它仍然有：

GPU0 Stage
↓
GPU1 Stage

这样的前后依赖。

但当 Batch 或并发增加后，可以让不同请求处于不同 Stage：

时间 T1
GPU0：请求 A
GPU1：空闲

时间 T2
GPU0：请求 B
GPU1：请求 A

时间 T3
GPU0：请求 C
GPU1：请求 B

这时候 Pipeline 才真正“流动”起来。

因此 PP 对吞吐和多请求调度的价值，通常比对单流 Decode 延迟更明显。

3. TP：不是切 Layer，而是切 Layer 里面的矩阵

Tensor Parallel，简称 TP。

它和前面两种方式最大的区别是：

两张 GPU 会同时参与同一层的计算。

例如：

              Layer N

        ┌───────────────┐
        │               │
        ↓               ↓
      GPU0            GPU1
   Matrix Part 0   Matrix Part 1
        │               │
        └──────┬────────┘
               ↓
          通信 / 聚合
               ↓
            Layer N+1

假设一个 Linear 是：

Y = XW

可以把 W 切开：

W0 → GPU0
W1 → GPU1

两张卡同时计算：

GPU0：X × W0
GPU1：X × W1

然后再通过 Collective 把结果组合成下一步需要的形式。

在 TP2 下，从第一层到最后一层，两张 GPU 都会持续参与。

为什么 TP 更可能让双卡的单流 Decode 变快？

RTX 5060 Ti 16GB 单卡显存带宽约：

448 GB/s

Layer Split 时，一颗 token 更接近：

GPU0 读前半权重并计算
↓
GPU1 读后半权重并计算

而 TP2 更接近：

GPU0 读取这一层的一部分权重
+
GPU1 读取这一层的另一部分权重

同时进行

于是两张卡的：

显存带宽
计算单元
Tensor Core

都有机会同时参与同一个 Layer。

这也是为什么 TP 是这几种方案里，最值得拿来讨论单个模型实例加速的一种。

但 TP 不是免费的。

每层的局部结果需要通过：

AllReduce
AllGather
ReduceScatter
NCCL
PCIe / P2P

等方式交换或聚合。

所以 TP 的收益实际上是一笔账：

并行计算节省的时间
-
跨卡通信时间
-
同步与调度开销
=
最终 Scaling

到这里先不展开通信量。

因为第三篇就专门回答一个最容易凭直觉判断错的问题：

没有 NVLink、甚至没有 CUDA P2P 的消费级双卡，TP 到底还值不值得？

4. TP 和 PP 最本质的区别

可以直接看图。

PP2

GPU0
Layer 0
Layer 1
...
Layer 31
   ↓
GPU1
Layer 32
Layer 33
...
Layer 63

每个 Layer 基本只属于一个 Stage。

TP2

Layer 0  → GPU0 + GPU1
Layer 1  → GPU0 + GPU1
Layer 2  → GPU0 + GPU1
...
Layer 63 → GPU0 + GPU1

每一层，两张卡都参与。

所以最简单的一句话就是：

PP 是切 Layer，TP 是切 Layer 里面的矩阵。

这也是理解二者单流性能差异的关键。

Layer Split 和 PP 为什么看起来那么像？

因为从外面看，它们都可能是：

前半模型 → GPU0
后半模型 → GPU1

区别更像是关注点不同。

Layer Split

重点是：

权重怎么放。

典型问题是：

这张卡放多少层？
那张卡放多少层？

Pipeline Parallel

重点是：

模型如何被划成 Stage，并按 Pipeline 方式运行。

它会进一步涉及 Stage、Micro Batch 和调度。

所以二者虽然都按层切，但不能完全当成同一个概念。

5. DP：根本不是用来解决单模型显存的

Data Parallel，简称 DP。

最简单的 DP2：

GPU0
完整模型
→ 请求 A

GPU1
完整模型
→ 请求 B

两张 GPU 各放一份完整模型。

所以如果一个模型本身需要：

23GB VRAM

而单张 5060 Ti 只有：

16GB

单纯开 DP2 没有帮助。

它不会把：

16 + 16

变成一个 32GB 的模型实例。

因为每个 DP Replica 都需要自己完整的一份权重。

DP 解决的是并发吞吐

假设单个 Replica 能稳定处理一批请求。

DP2 相当于：

GPU0：Replica A
GPU1：Replica B

两张卡可以独立服务不同请求。

因此 DP 的核心目标是：

Throughput Scaling。

而不是：

Single Request Speed。

请求 A 不会因为 DP2 就自动从 30 token/s 变成 60 token/s。

但服务可以同时让另一个 Replica 去处理请求 B。

这和 TP 的目标明显不同。

6. TP、PP、DP 可以组合

真实的大规模部署往往不会只使用一种并行方式。

例如 8 张 GPU 可以做：

TP4 × DP2

也就是：

GPU0~3
→ TP4
→ Replica 1

GPU4~7
→ TP4
→ Replica 2

这里：

TP4
负责一个模型实例内部的并行

DP2
负责复制两个服务实例扩展并发

也可以做：

TP2 + PP2

四张 GPU：

Stage 0
GPU0 + GPU1
TP2

↓

Stage 1
GPU2 + GPU3
TP2

也就是层之间用 PP，层内部用 TP。

所以 TP、PP、DP 并不是互斥选项，它们是在不同维度切模型和请求。

7. 一个表看懂四种方式

方式	怎么切	扩展单实例显存	单请求加速潜力	并发扩展
Layer Split	按层放到不同 GPU	✅	较弱	一般
PP	按 Stage 分模型	✅	有限	✅
TP	每层内部切矩阵	✅	✅	间接
DP	复制完整模型	❌	❌	✅✅

如果换成实际问题：

模型单卡放不下怎么办？

优先看：

Layer Split / PP / TP

想提高单请求 Decode 速度？

优先研究：

TP

模型单卡已经能放下，只想扩大并发？

优先考虑：

DP

模型特别大，单一 TP 或 PP 都不够？

就会进入：

TP + PP

这样的组合。

8. 为什么消费级双卡特别值得测试 TP？

数据中心 GPU 的多卡环境往往拥有：

NVLink
NVSwitch
高带宽 GPU 互联

消费级 GPU 的现实则经常是：

PCIe
没有 NVLink
P2P 甚至可能不可用

这就出现了一个很自然的担心：

TP 每层都要同步，PCIe 这么慢，是不是直接把双卡并行收益吃光？

但这里不能只拿：

GPU 本地显存带宽：几百 GB/s，而 GPU 间通信：个位数或十几 GB/s。

直接下结论。

因为 TP 的收益来自两张卡同时处理自己的权重分片，而跨卡同步的也不是“把几十 GB 模型权重来回传”。

到底通信量有多大、为什么没有 P2P 也还能跑出不错的 Scaling，必须结合实际模型 hidden size、Collective 次数和实测带宽一起算。

这就是下一篇的主题。

9. 双 5060 Ti，我会怎么选？

如果模型单卡能放下：

单用户 / 单请求
→ 单卡就可能够用

大量并发
→ DP 才开始有意义

如果模型单卡放不下，又是 llama.cpp / GGUF、希望兼容不同显存容量和 CPU + GPU：

Layer Split

通常很自然。

如果使用 vLLM，希望一个模型实例同时利用两张 GPU 的计算与显存带宽：

TP2

更值得优先测试。

如果 TP 不适合当前模型、并行维度受限，或者通信条件实在太差：

PP

则可以回到容量优先的方向。

10. 结论

多 GPU 推理不能简单理解成：

多一张卡
=
多一倍性能

不同并行方式解决的是不同问题：

Layer Split：按层分权重，重点解决容量。

PP：按 Stage 分模型，重点解决超大模型和 Pipeline 吞吐。

TP：切分每一层内部的矩阵，重点解决单实例模型并行和计算性能。

DP：复制完整模型，重点解决多 Replica 并发吞吐。

其中最值得先记住的一句话还是：

PP 是切 Layer，TP 是切 Layer 里面的计算，DP 是复制整个模型。

对于双 RTX 5060 Ti，真正有意思的问题也从这里开始：

TP2 确实能让两张 GPU 同时工作，但消费级显卡又没有 NVLink。PCIe 通信到底会损失多少性能？

下一篇直接用实测回答：

《两张 RTX 5060 Ti 为什么没有两倍推理速度？显存带宽、PCIe 与 P2P》

系列导航： ← 上一篇：2× RTX 5060 Ti 16GB 能跑 27B 大模型吗？先把显存算清楚 · 下一篇：两张 RTX 5060 Ti 为什么没有两倍推理速度？显存带宽、PCIe 与 P2P →

2× RTX 5060 Ti 16GB 能跑 27B 大模型吗？先把显存算清楚

Sun, 23 Aug 2026 10:00:00 +0800

📚 双 RTX 5060 Ti 部署 Qwen3.8 系列 · 1/6

💡 导读：

从两张 RTX 5060 Ti 16GB 能不能跑好 27B 模型这个问题开始，先把 BF16、FP8、NVFP4 的权重和运行显存拆开算清楚。真正决定能不能长期使用的，不只是模型文件能否塞进 32GB，而是权重之外还能给 Cache、Runtime 和长上下文留下多少空间。

Qwen3.8-27B 在 2026 年 8 月 14 日开放权重。写这篇的时候，它出来已经一个多星期。

这一周我基本把空闲的 GPU 时间都花在了它身上。

最开始的问题其实很简单：

两张 RTX 5060 Ti 16GB，到底能不能把一个 27B 模型跑好？

一开始我以为这只是一个显存问题：32GB 总显存，算一下权重，挑一个合适的量化，然后把服务启动起来，大概就结束了。

真正开始部署以后，问题却一层一层冒了出来：

27B 到底应该选 BF16、FP8、NVFP4，还是普通 4bit？
2×16GB 为什么不能简单当成一张 32GB？
模型分到两张卡以后，TP、PP、Layer Split 到底谁真的会让 Decode 变快？
没有 NVLink，甚至实际机器没有 CUDA P2P，TP 为什么还能有不错的 Scaling？
同样写着 NVFP4，“能加载”和“真正跑到适合 Blackwell 的低精度 Kernel”是不是一回事？
100K、200K Context 到底需要多少显存？
模型终于跑起来以后，Prefix Cache、Continuous Batching、CUDA Graph、MTP 又分别在优化什么？

于是原本一个“能不能跑”的问题，最后变成了这组六篇文章。

整个系列基本按照我实际部署时遇到问题的顺序展开：

显存与量化 → 多卡并行 → PCIe 与通信 → vLLM 执行栈 → 长上下文显存 → 长上下文 Serving 优化。

硬件则一直尽量保持在个人开发者真正可能接触到的范围：消费级 RTX 5060 Ti、PCIe 多卡、没有 NVLink。

所以这组文章并不是讨论“如果我有 8 张 H100 应该怎么部署”，而是想回答另一个更现实的问题：

在有限的消费级 GPU 上，怎么让一个足够强的模型不只是成功启动，而是真正达到可以长期使用的状态？

第一步还是最朴素的：先把显存算清楚。

双 RTX 5060 Ti 16GB，一共 32GB 显存。27B 模型到底能不能跑？

结论先说：

可以，但基本要进入高质量 4bit / NVFP4 这一档。BF16 明显不够，FP8 对双 16GB 来说通常也太挤。

真正需要计算的不是“模型文件有没有小于 32GB”，而是：

显存预算
=
模型权重
+ Cache
+ CUDA / Runtime
+ Workspace
+ Activation
+ 框架额外开销

而且还有一个贯穿整个系列的前提：

2×16GB 也不等于一张 32GB GPU。

1. 27B 模型到底需要多少显存？

27B 表示大约 270 亿参数。

最简单的权重估算公式是：

权重大小 ≈ 参数量 × 每参数字节数

于是：

权重精度	27B 理论权重大小
BF16 / FP16	≈54GB
FP8 / INT8	≈27GB
FP4 / INT4	≈13.5GB

从理论值已经能看到大致边界：

2 × RTX 5060 Ti 16GB = 32GB 总显存

BF16 基本不用考虑。

FP8 看起来接近能放下。

4bit 则开始进入比较合理的范围。

但这里的 13.5GB 只是“27B × 4bit”的理想数学值，不等于实际模型文件大小。

实际量化模型还可能包含：

Scale
部分高精度 Tensor
Embedding
Norm
Output Head
量化元数据
其他未按同一 bit 数保存的权重

所以“4bit”不能直接理解成“模型一定只有 13.5GB”。

2. 用实际 Qwen3.8-27B 看更直观

以这次部署的 Qwen3.8-27B 为例，不同版本大致是：

BF16 ≈ 55GB
FP8 ≈ 31GB
NVFP4 ≈ 23GB

放到双 5060 Ti 16GB 上就很直观了。

BF16

权重 ≈ 55GB
总显存 = 32GB

明显放不下。

当然，可以通过 CPU / RAM Offload 把一部分权重留在系统内存，但那已经是另一种性能模型，不能再算正常的“双 GPU 全显存部署”。

FP8

权重 ≈ 31GB
总显存 = 32GB

数字上看似乎只差一点。

但对于推理服务，这种“刚好塞进去”基本没有意义。

因为权重之外还要给下面这些东西留显存：

Cache
CUDA Context
Runtime
Workspace
Activation
CUDA Graph

也就是说：

“权重能塞进去”和“模型能正常提供服务”是两回事。

如果还希望跑几十 K、100K 甚至更长 Context，FP8 在双 16GB 上就更难留出足够的运行空间。

NVFP4

NVFP4 权重进入约 23GB 以后，情况明显不同：

总显存 ≈ 32GB
权重 ≈ 23GB
名义剩余 ≈ 9GB

当然，这 9GB 也不能全部给 Cache。

Runtime、Workspace、CUDA Graph 等仍然会吃掉一部分。

但至少从这里开始，才真正有空间继续规划 Context 和 Serving。

所以对于：

2 × RTX 5060 Ti 16GB + 27B 模型

如果只谈这套硬件上的部署适配度，我的顺序会很明确：

高质量 NVFP4 / 4bit
>
FP8
>
BF16

这不是在说 FP4 的模型质量天然高于 FP8，而是双 16GB 的容量约束决定了 FP8 很难给实际推理留下足够空间。

3. 模型权重不是唯一的显存开销

部署 LLM 时，一个非常常见的误区是：

模型文件约 23GB、总显存 32GB，表面上看似乎“还剩 9GB”。

实际不能这么算。

更合理的模型是：

VRAM
=
Weights
+ Cache
+ Runtime
+ Workspace
+ Activation
+ CUDA Graph
+ Framework Buffer

其中很多项还会随着配置变化。

例如：

Context Length
Batch Size
并发数量
CUDA Graph
Attention Backend
KV / Cache dtype
推理框架

都会改变最终显存占用。

所以部署之前，我现在更习惯把问题拆成两步。

第一步：

模型权重能不能装下？

第二步：

装完权重以后，还剩多少显存能够真正用于推理？

第二步往往比第一步更重要。

4. 为什么 2×16GB 不等于 1×32GB？

假设模型权重是 24GB。

如果是一张 32GB GPU：

GPU0
├── 24GB 权重
├── Cache
├── Runtime
└── Workspace

总上限：32GB

所有显存都在同一个 GPU 的地址空间和资源预算里。

双 16GB 则不同：

GPU0                  GPU1
├── 一部分权重         ├── 一部分权重
├── Runtime            ├── Runtime
├── Cache              ├── Cache
└── Workspace          └── Workspace

上限 16GB              上限 16GB

如果出现：

GPU0：16.1GB
GPU1：13GB

即使 GPU1 还剩 3GB，也不能简单理解成 GPU0 可以把这 3GB 当成本地显存继续使用。

所以多卡部署不仅要看：

总显存够不够

还要看：

每张卡分别放了什么？
每张卡分别占多少？

这也是为什么“模型怎么切”会直接影响能不能启动以及最终能开多大 Context。

5. 模型分到两张卡，只是下一层问题的开始

模型单卡放不下以后，常见思路大致可以先分成两类。

一种是按层拆：

GPU0
Layer 0 ~ 31
      ↓
GPU1
Layer 32 ~ 63

另一种是让两张 GPU 同时参与同一层：

          Layer N

     GPU0       GPU1
      1/2        1/2
        \        /
         聚合结果

前者首先解决容量问题；后者除了容量，还可能真正聚合多张卡的计算和显存带宽。

所以：

模型能不能分到两张卡，和两张卡能不能让单请求跑得更快，不是同一个问题。

具体的 Layer Split、PP、TP、DP，下一篇单独拆开讲。

6. 双卡 448GB/s 能不能直接变成 896GB/s？

RTX 5060 Ti 16GB 单卡显存带宽约为：

448 GB/s

两张卡的物理显存带宽总和当然是：

448 × 2 = 896 GB/s

但推理时能不能真正把它变成接近 2× 的单 token 性能，取决于并行方式。

按层串行执行时，两张卡并不会一直同时为同一颗 token 读取权重。

Tensor Parallel 则更有机会让两张卡在同一层同时工作，但又会引入跨卡通信和同步。

所以这里不能简单写成：

2 张 GPU = 2× token/s

第三篇会直接用 TP2 的实测数据、PCIe、P2P 和 AllReduce 把这笔账算清楚。

7. 长上下文会继续吃掉剩余显存

如果只是跑 4K、8K 对话，权重通常是最大的显存项目之一。

但我的实际目标还包括长代码 Context，所以还会继续关注：

32K
64K
100K
128K
200K

这时剩余显存会继续被 Cache 消耗。

经典 Transformer 经常用 KV Cache 公式估算：

KV Cache
≈
Token 数
× Layer 数
× KV Head
× Head Dimension
× K/V
× dtype

但现代模型不能一律直接套这个公式。

Qwen3.8-27B 是混合 Attention 架构，并不是 64 层全部使用传统 Full Attention。

因此：

200K Context 到底需要多少显存，必须结合模型结构计算。

这部分放到第五篇专门算。

8. 双 5060 Ti 跑 27B，我目前会怎么选？

如果硬件固定为：

2 × RTX 5060 Ti 16GB

目标是：

27B
+
长 Context
+
代码 / Agent

我的选择会是：

BF16

不考虑。容量明显不足。

FP8

权重本身已经接近吃满 32GB，总体精度很好，但在双 16GB 上很难留下足够的 Runtime 和 Cache 空间。

高质量 NVFP4 / 4bit

优先考虑。

权重压到 20 多 GB 后，双 16GB 才真正有空间继续规划：

Cache
Context
并发
Runtime
CUDA Graph

所以对消费级双 16GB GPU 来说：

量化的意义不只是让模型“装得下”，更重要的是给实际推理留下显存。

9. 结论

双 RTX 5060 Ti 16GB 可以部署 27B 级模型，但不能只用：

16GB × 2 = 32GB

来判断。

真正需要看的，是：

模型权重
+
Cache
+
Runtime
+
Workspace
+
其他运行开销

对于 Qwen3.8-27B 这类 27B 模型，在双 16GB 上大致可以形成这样的判断：

BF16：容量明显不足

FP8：权重已经接近吃满总显存

NVFP4 / 高质量 4bit：
开始进入比较合理的部署区间

同时记住两个结论：

2×16GB 不等于 1×32GB。

容量扩展不等于性能扩展。

模型能分到两张卡，只解决了“装不装得下”。

至于两张卡到底怎么分、谁负责容量、谁负责单请求加速、谁负责并发吞吐，就进入下一篇：

《双卡部署大模型：TP、PP、DP 和 Layer Split 到底有什么区别？》

系列导航： 下一篇：双卡部署大模型：TP、PP、DP 和 Layer Split 到底有什么区别？ →