📚 双 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 亿参数。

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

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

于是：

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

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 到底有什么区别？ →