DeepSeek-V4-Flash × 昇腾 PD 分离 × Mooncake 外部 KV 池：external 命中乱码排障全记录

骄阳如火

56人浏览 · 2026-08-30 10:37:17

骄阳如火 · 2026-08-30 10:37:17 发布

一句话结论：在 DeepSeek-V4-Flash（hybrid 架构）+ 昇腾 PD 分离场景下，AscendStoreConnector(backend=mooncake) 外部共享 KV 池的 “external 命中” 路径未经过端到端验证，实测表现为命中即乱码（静默输出损坏）；而 PD 分离本身的 P→D KV 传输路径是可用且相对稳定的。

重要声明：文中标注 [推断] 的部分，是基于现象与公开资料（issue / release note / 社区报告）的合理推测，尚未被官方 issue 直接确认，需要你用本文第 6 节的闸门自行验证。请勿将推断直接当结论上生产。

1. 环境与背景

1.1 部署架构

项目	配置
硬件	昇腾 910B3，单卡 64GB HBM，单机 8 卡
模型	DeepSeek-V4-Flash-0731（hybrid：Compress-4/128 + HCA / Mamba 混合）
框架	vLLM 0.26.0 + vLLM-Ascend（实际 commit 未锁定，强烈建议核查）
架构	PD 分离（Prefill / Decode）
P 节点并行	DP2 × TP4（两机各 4 卡，共 2 个 DP 组）
投机解码	DSpark（num_speculative_tokens=7）
量化	W8A8（`--quantization ascend`）
KV 量化	曾开 `int8`，已确认移除（现走默认 fp16/bf16）

1.2 业务痛点

长上下文（16K~200K tokens）业务为主
并发上来后，本地 KV Cache 淘汰极快，前缀命中率崩塌
缓存丢失后需重新 prefill 长上下文，耗时数秒到数十秒
核心诉求：启用跨节点共享 KV 池（Mooncake 外部池），复用别人的前缀 KV，避免重算

2. 问题现象

2.1 核心现象：external 命中即乱码

启用 AscendStoreConnector(backend=mooncake) 后：

只要 external_prefix_cache_hit_rate > prefix_cache_hit_rata，长上下文输出必乱码，此时使用了外部缓存，导致乱码，但是好像一旦缓存命中后会放入gpu的显存中，我重新对话prefix_cache_hit_rata高了，又正常了
关掉外部池（纯本地 prefix cache），完全正常、不乱码

2.2 现象特征（决定了排查方向）

现象	说明
短上下文正常，长上下文乱	短的没跨 chunk / group 边界
本地命中正常，external 命中乱	问题在"从池 load 回来"这条路径
external=2% 也乱	不是"命中比例"问题，是"只要命中过"问题
跑一会才乱	池子先被填满、命中才开始发生
纯 DRAM 与 SSD 均复现	与存储介质无关

2.3 关键认知：为什么 2% 命中也会全乱？

KV Cache 是累加复用的——前缀里错一个 block，后面所有 token 的 attention 都基于错误的 KV 计算。乱码不需要"全部命中外部"。

类比：一本 100 页的书，只有第 3 页（2%）是错的，但后续剧情都依赖第 3 页，整本书就废了。

这个认知直接**排除了"把 external 命中率压低就能规避"**的想法——只要 >0，就可能中招。

3. 排障过程：逐一排除嫌疑

3.1 嫌疑一：int8 KV 量化 → 已排除

假设：kv_cache_dtype=int8 的 KV 序列化进 Mooncake 池，跨节点 load 回来后反量化出错（scale / zero_point 错位、block 边界不对齐），产生微小数值误差，注意力累乘累加上万 token 后完全乱码。
验证：确认已移除 int8 配置（走默认 fp16/bf16），长上下文 + external 命中依然乱码。
结论：int8 不是唯一根因（但仍是"高危组合"，外部池场景建议先不用 int8）。

3.2 嫌疑二：MTP / DSpark 投机解码 → 已排除（逻辑上）

假设：DSpark 的 draft 状态与 pool load 的 KV 不同步，导致乱码。
排除理由：MTP/DSPark 作用在 decode 阶段（投机采样生成 output token），而乱码发生在 prefill / context 侧（external 命中的是输入前缀 KV）。这两者是独立的两条链路。
重要推论：不要为了"救乱码"而关掉 MTP/DSpark——既救不了，又白丢一份加速，没有测试。

3.3 嫌疑三：`use_layerwise` → 确认不支持

官方约束：use_layerwise 仅 backend=memcache 支持，backend=mooncake 明确不支持
hybrid 模型 + TP 不匹配时，源码会直接 raise NotImplementedError
hybrid 场景必须保持 use_layerwise: false

3.4 嫌疑四：`kv_load_failure_policy=recompute` → 确认不支持

官方文档明确：hybrid attention 模型（DeepSeekV4、Qwen3.5）不支持 recompute
源码层面 hybrid 会直接断言失败
必须用默认 fail 策略

3.5 嫌疑五：存储介质 / 容量 / 参数 → 已排除

纯 DRAM vs SSD：均复现 → 与介质无关
global_segment_size 调大调小：均复现 → 与容量无关
各种超时参数：均复现 → 与超时无关

这组排除实验价值极高——它把问题从"配置/容量/介质层"锁死到了"语义层（KV 状态恢复）"。

3.6 嫌疑六：DSA-CP 开关 → 引发崩溃，非乱码根因

尝试开 enable_dsa_cp=true + enable_flashcomm1=true 后，服务直接崩溃：

SDMA EI00100 / SDMA memory copy task exception
error code: 507035 / The vector core execution is abnormal
MTE error info / aivec error exception
DDR address of the MTE instruction is out of range

崩溃原因：DSpark(num=7) + DSA-CP + FlashComm1 三者冲突，底层环通信（ring-ring-ring）内存越界
结论：DSA-CP 是"非零前缀命中的前提"（社区报告佐证），但与 DSpark 不兼容。二者只能二选一，或把 DSpark 降级为 MTP 1-token

4. 根因收敛

4.1 hybrid 模型 KV 的特殊性（为什么这么难）

DeepSeek-V4-Flash 不是标准 GQA/MLA，它的 KV 包含三类难以统一处理的状态：

压缩注意力状态（Compress-4 / Compress-128）：多 token 压缩成一个 state，前缀长度在压缩维度上不再简单对齐
Mamba / SSM 递归状态：必须严格按顺序累积，不能像普通 KV 那样随便截取一段复用
多个 KV Cache Group：不同 group 的 block size、对齐方式不同

这意味着"外部池 KV 复用"在 hybrid 上变成了：

普通模型：存 KV → 命中 → 原样拷回 → 直接复用
V4(hybrid)：存 KV + 压缩state + SSM state + 专家路由
           命中时要验证：压缩边界对齐？SSM状态连续？hash一致？
           跨节点还要：block对齐？TP切分一致？

4.2 静默损坏的机理 [推断]

最可能的机制："content hash 命中"与"物理 KV 实际可安全复用的长度"不一致。

跨 Compress-4/128 的长 prompt 在写入池 / 读出池时，压缩边界与 SSM 递归状态的连续性无法保证，导致 load 回来的 KV 与"现场重算"的 KV 不一致——不报错，只产生微小数值误差，注意力累乘后完全乱码。

4.3 官方已知关联修复（佐证此路径确有静默损坏风险）

vLLM-Ascend v0.23.0rc1 release notes 明确修复：

“Fixed silent prefix-cache output corruption and block-table overflow for Qwen3-Next, Qwen3.5, and other hybrid Mamba models using MTP/EAGLE”（#11353）

这说明 hybrid KV 的前缀命中在这条代码线上确实曾出现"静默输出损坏"——你看到的"命中即乱码"是一个真实存在的风险类别。

4.4 确定性支持矩阵（本文最有价值的部分之一）

能力	对 DeepSeek-V4-Flash(hybrid)	依据
PD 分离：P→D KV 传输（`MooncakeHybridConnector`）	✅ 支持（实验性）	官方教程 + 落地案例
外部共享 KV 池：`AscendStoreConnector` + mooncake	⚠️ 未验证，实测乱码	本文实测
`use_layerwise`	❌ mooncake 不支持（仅 memcache）	官方文档
`kv_load_failure_policy=recompute`	❌ hybrid 不支持	官方文档 + 源码断言
DSA-CP + DSpark(7) 同时开	❌ 冲突崩溃（SDMA 越界）	本文实测
DSA-CP + MTP(1)	⚠️ 待验证（社区报告可行）	社区报告
KV Cache CPU Offload	⚠️ 架构支持，V4-Flash 端到端待验证	官方文档未点名 V4

5. 可行方案

5.1 方案 A：稳定优先（推荐，今天就能用）

保留 PD 分离，只放弃外部共享池，靠本地 prefix cache + 路由亲和性提吞吐。

P 节点（standalone，不带 Store）：

--kv-transfer-config '{
  "kv_connector": "MooncakeHybridConnector",
  "kv_role": "kv_producer",
  "kv_ip": "<P节点IP>",
  "kv_port": "30000",
  "engine_id": "0",
  "kv_connector_extra_config": {
    "prefill": {"dp_size": 2, "tp_size": 4},
    "decode":  {"dp_size": 2, "tp_size": 4}
  }
}'

D 节点（standalone consumer）：

--kv-transfer-config '{
  "kv_connector": "MooncakeHybridConnector",
  "kv_role": "kv_consumer",
  "kv_port": "30100",
  "engine_id": "1",
  "kv_connector_extra_config": {
    "prefill": {"dp_size": 2, "tp_size": 4},
    "decode":  {"dp_size": 2, "tp_size": 4}
  }
}'

配套（已验证不乱码的组合）：

export PYTHONHASHSEED=0
export HCCL_INTRA_ROCE_ENABLE=1
export VLLM_PREFIX_CACHE_RETENTION_INTERVAL=16384   # block-size=128 下
# P 开启 prefix caching（不加 --no-enable-prefix-caching）
# D 保持 --no-enable-prefix-caching --no-disable-hybrid-kv-cache-manager --async-scheduling
# 不用 AscendStoreConnector、不用 memcache、不用 use_layerwise、不用 recompute

关键：把"跨节点共享 KV"的收益，换成"把本地 prefix cache 命中率做高"——请求按前缀亲和性路由到固定 P 实例 + 调大 HBM 给本地 pool + 必要时加大批处理。

5.2 方案 B：外部池 + 正确性闸门（给非要用共享缓存的人）

如果你一定要试外部池，在方案 A 基础上只改 P 节点，用 MultiConnector 把传输层和池化层包起来（D 节点保持 standalone，不要加 AscendStoreConnector）：

--kv-transfer-config '{
  "kv_connector": "MultiConnector",
  "kv_role": "kv_producer",
  "engine_id": "0",
  "kv_connector_extra_config": {
    "connectors": [
      {
        "kv_connector": "MooncakeHybridConnector",
        "kv_role": "kv_producer",
        "kv_port": "30000",
        "kv_connector_extra_config": {
          "prefill": {"dp_size": 2, "tp_size": 4},
          "decode":  {"dp_size": 2, "tp_size": 4}
        }
      },
      {
        "kv_connector": "AscendStoreConnector",
        "kv_role": "kv_producer",
        "kv_connector_extra_config": {
          "lookup_rpc_port": "0",
          "backend": "mooncake",
          "use_layerwise": false,
          "load_async": false,
          "consumer_is_to_put": false
        }
      }
    ]
  }
}'

必读风险：这个组合（PD 分离 + 外部池）没有公开成功案例。必须先过下面第 6 节的 token 级闸门。

参数要点：

use_layerwise: false（mooncake 后端不支持）
load_async: false（规避异步加载竞态）
不要 kv_load_failure_policy=recompute（hybrid 不支持）
想提高成功率可把 P/D 并行度改成 DP2 × TP8 + EP16（对齐社区验证的 KV 切分）

5.3 方案 C：CPU Offload 兜底

外部池不靠谱时，用 CPU 内存做 HBM 之外的第二层（详见姊妹篇《调优篇》）：

P 节点：OffloadingConnector —— 被淘汰的前缀 KV 换页到 CPU，下次直接从 CPU 载回，避免重算
D 节点：RecomputeCPUOffloadConnector + recompute_scheduler_enable:true —— 被抢占请求的 KV 暂存 CPU，避免回流 P 重算

6. token 级正确性闸门（方法论，可复现）

6.1 为什么不能"看起来像人话"

乱码是静默错误：输出语法通顺、格式正确，但内容完全错误。肉眼无法判断。必须做 token 级（不是文本级）比对。

6.2 闸门设计

temperature=0 + 固定 seed
构造 ≥ 16K tokens 的长 prompt（要跨过 16384 的 retention checkpoint）
发两次相同请求（第二次应命中外部池）
对比两次的 output token ID 序列（不是文本！）
扫描 4K / 8K / 16K / 32K / 65K 多档长度
构造跨 Compress-4/128 checkpoint 的长 prompt vs 纯 Full Attention 短前缀

6.3 判定标准

# 伪代码
response_1 = query(prompt, temperature=0, seed=42)   # 第一次，应 miss
response_2 = query(prompt, temperature=0, seed=42)   # 第二次，应 external hit

assert response_1.token_ids == response_2.token_ids  # 逐 token 比对

完全一致 → 通过（✅ 该配置可用）
任何一档出现 diff → 判为不可用，回退方案 A

6.4 分档加回 DSpark

闸门通过后，再逐步把投机解码加回来（每档重跑闸门）：

先 --speculative-config '{"method":"mtp","num_speculative_tokens":1,"enforce_eager":true}'
通过后试 3
再试 7
哪档开始乱码，就停在上一档——这是"保外部池"与"保 DSpark 加速"的权衡点

7. 待验证清单与后续

7.1 版本基线核查（最重要，先做这个）

pip show vllm vllm-ascend
git rev-parse HEAD

官方 vLLM-Ascend 最新 tag 只到 v0.23.0（对齐 vLLM v0.23.0），没有对应 vLLM 0.26.0 的官方 tag
你现在这套"vLLM 0.26.0 + vLLM-Ascend"很可能是内部分支/开发分支/版本显示被覆盖
不锁定真实 commit，升级就是盲赌
公开成功案例（含 0 error / 0 mismatch）多在 vLLM-Ascend nightly-main（vLLM 0.23.0）

7.2 别被启动时的"11GB"吓到：那是理论预留，不是真实占用

排查过程中你可能见过 vLLM 的提示：

“一个完整请求需要 11GB 显存，显存不够，请调低 max-model-len”

这大概率只是 vLLM 按 max-model-len 算出来的理论预留最大值，而非运行时真实占用，别拿它当故障证据：

vLLM 启动时做一次 profile_run，再按 max-model-len × 每 token KV 大小 预留"单请求最坏情况"的 KV 空间
该估算偏保守：可能未充分计入 V4-Flash 的 MLA 压缩 / 混合注意力带来的 KV 缩减，且默认按"请求一定跑满 max-model-len"留预算
V4-Flash 采用压缩注意力，每 token KV 远小于传统 GQA 模型（社区实测约 6~8 bytes/token 量级）

真实数字只能靠启动日志反算（不挂任何 KV 连接器裸跑 baseline）：

# 启动日志里找这两行
# GPU KV cache size: YYYYY tokens
# Available KV cache memory: Z GiB

bytes_per_token = (Z * 1024^3) / Y

与社区参考值（V4-Flash 压缩后约 6~8 bytes/token 量级）量级一致 → hybrid 压缩 KV 工作正常，"显存不够"只是 max-model-len 设太大导致的预留误报
显著偏大（数倍甚至一个数量级） → 排查是否误加了 --disable-hybrid-kv-cache-manager（禁掉它会让压缩失效、KV 变大），或版本 / 连接器存在异常