Qwen3.8-27B 部署现状与容量说明
一句话
单卡 48GB Blackwell 跑 FP8 权重的 Qwen3.8-27B，KV 池只有约 10～14 GiB，单并发硬上限约 32 万 tokens。当前配置的 131,072 只用掉池子的 1/3——建议直接提到 262,144（模型原生上限，不需要 YaRN），这是零代价翻倍。
估算方法与公式见 Qwen3.8-27B 显存与 KV Cache 预算。
一、当前部署配置
| 项目 | 配置 |
|---|---|
| 显卡 | NVIDIA RTX PRO 5000 Blackwell，单卡 |
| 显存 | 48GB（采样总量 48,935 MiB ≈ 47.79 GiB） |
| 推理引擎 | vLLM 0.29.0 |
| 模型服务名 | qwen3.8-27b |
| 模型目录 | /data/models/Qwen3.8-27B-FP8 |
| 服务地址 | http://<内网地址>:8000/v1 |
| 最大上下文 | 131,072 tokens（128K） |
| KV Cache 精度 | FP8 |
| 前缀缓存 | 已启用 |
| 显存利用率 | 0.9 |
| 目标并发 | 单用户为主，最多 2 用户 |
关于脱敏
本库的
大模型/目录会随公开站点导出，因此内网 IP 用占位符代替。完整的服务入口清单属于内网信息，按惯例放在内部库记录。
二、显存预算拆解
| 项 | 大小 | 依据 |
|---|---|---|
| 卡总显存 | 47.79 GiB | 采样 48,935 MiB |
| vLLM 预算（util 0.9） | 43.01 GiB | 48,935 × 0.9 |
| FP8 权重（含视觉塔 + MTP 头） | −28.56 GiB | 实测 14.28 GiB/GPU @ TP2 |
| 激活 / workspace | −2～4 GiB | 估算，取决于 max_num_batched_tokens |
| CUDA graph 捕获 | −0～2 GiB | 开了图捕获就有 |
| 线性注意力状态池（2 序列） | −0.28 GiB | 144 MiB/序列 |
| 剩给 KV 池 | ≈ 9.5～14 GiB |
最大不确定项
权重到底占 27 还是 29 GiB，直接决定池子是 9.5 还是 14 GiB——这是整条推算里误差最大的地方。启动日志里模型加载后打印的显存占用拿到，就能把误差从 ±5 万 tokens 收敛到 ±1 万。
权重吃掉了预算的 66%，这是这台机器最大的单项。FP8 已经是官方检查点，除换 NVFP4 外没什么可压的。
三、单并发容量上限
FP8 KV = 32 KiB/token，池子 9.5～14 GiB → 可装 31 万～46 万 tokens，取保守值 约 32 万。
| max-model-len | KV 需求（fp8） | 可行性 |
|---|---|---|
| 131,072（128K） | 4.0 GiB | ✅ 当前配置，池子只用 1/3 |
| 196,608（192K） | 6.0 GiB | ✅ 直接改参数 |
| 262,144（256K） | 8.0 GiB | ✅ 推荐，模型原生支持，无需 YaRN |
| 327,680（320K） | 10.0 GiB | ⚠️ 取决于实际池子，需开 YaRN |
| 393,216（384K） | 12.0 GiB | ⚠️ 池子得 ≥12 GiB，且需 YaRN |
| 524,288（512K） | 16.0 GiB | ❌ FP8 权重下做不到 |
| 1,048,576（1M） | 32.0 GiB | ❌ 单卡物理上不可能 |
1M 不是调参问题
1M × 32 KiB = 32 GiB，比整个 vLLM 预算减去权重后剩下的还多。任何 vLLM 参数都绕不过去，只能换权重精度、加卡，或把 KV 卸载到 CPU/SSD。
四、1～2 用户的实际情况
| 场景 | KV 占用 | 占池子 | 判断 |
|---|---|---|---|
| 1 用户 × 128K | 4 GiB | ~35% | ✅ 绰绰有余 |
| 2 用户 × 128K | 8 GiB | ~70% | ✅ 可行，余量不多 |
| 1 用户 × 256K | 8 GiB | ~70% | ✅ 推荐目标 |
| 2 用户 × 256K | 16 GiB | >100% | ❌ 超出 |
前缀缓存对多轮长会话价值很大：第二轮起复用前缀，实际容量远好于”几条并发”这个静态数字。
五、还能榨出来的三项
① --max-num-seqs 2（最可能的大头）
线性注意力状态池按 max_num_seqs 预留。2 序列 = 288 MiB 可忽略；若默认值开得很大（常见默认 256），这块可能悄悄占掉好几 GiB。先看启动日志有没有单列的 state cache 行，占了就压。
② --language-model-only
纯文本服务时丢掉 27 层视觉塔。实测在 1×5090 上 KV 池从 91,022 → 135,926 tokens（+49%）。
③ 想要 256K 以上：换 NVFP4 检查点
| 权重方案 | 权重 | KV 池估算 | 单条 512K（16 GiB） |
|---|---|---|---|
| FP8（当前） | 28.56 GiB | ~10～12 GiB | ❌ |
| NVFP4（unsloth） | ~21.3 GiB | ~15～17 GiB | ✅ 勉强 |
代价是量化精度略降；recipe 实测 NVFP4 的 MTP 接受率（0.897）反而比 FP8（0.771）高。
六、待核实清单
- 启动日志
GPU KV cache size: N tokens—— 预期 33 万～38 万 - 启动日志
Maximum concurrency for 131,072 tokens per request—— 预期 ≥ 2.0 - 是否存在单列的 linear / mamba state cache 行，占多少
- 模型加载后的实际权重显存占用（收敛预算误差）
- 重新采样实际可用显存、驱动版本、卡上是否有其他进程
- vLLM 0.29.0 是否对
qwen3_5走原生混合注意力路径（无 fallback 警告）
信息来源边界
vLLM 版本与服务配置来自本次实时查询；显卡型号、数量、显存来自 9 月 29 日硬件采样报告。本次 SSH 认证未通过，因此尚未重新核验当前硬件、驱动和 GPU 负载——第二节所有”剩余显存”都是按 48,935 MiB 推算的，这三个数任何一个不对，推算就会偏。
七、风险提示
版本差异
vLLM Recipes 在消费级 Blackwell（sm120，即 RTX PRO 5000 架构）上验证的是 vLLM 0.26.1rc1，不是当前部署的 0.29.0。建议确认日志里没有 fallback 到慢路径的警告，并跑一次长上下文实测。
sm120 上的 FP8
recipe 明确：block-scaled FP8 检查点在 Blackwell 上会被 vLLM 自动禁用 DeepGemm 并回退 CUTLASS，无需
VLLM_USE_DEEP_GEMM=0之类的 workaround。当前用的正是 FP8 检查点，这条适用。