[Bug]: DeepSeek-V4 NIXL failure returns corrupted reasoning with empty content

快速结论：该报错在 vLLM 使用 NIXL/HMA 做分离式 Prefill/Decode 时触发，根本原因是 NIXL 兼容性握手失败后，请求并未被终止，而是继续解码，导致返回 HTTP 200 并伴随 corrupted tokens。优先排查方向是检查 Prefill 与 Decode 两端的 `kv-transfer-config` 是否完全匹配，尤其是手动添加 `enforce_handshake_compat` 配置项绕过握手兼容性检查。

适用环境：vLLM（`vllm/vllm-openai:v0.27.0-cu129-ubuntu2404` Base image，Runtime vLLM 0.26.1rc1.dev657+g793ca6998，Source commit 793ca6998）、DeepSeek-V4 模型、分离式 Prefill/Decode 拓扑、TP=8、NixlConnector with HMA（KV connector）、Prefill 使用 V1 model runner 且禁用 speculative decoding、Decode 使用 V2 model runner 且启用 DSpark（num_speculative_tokens=7）、reasoning parser 为 deepseek_v4、KV load failure policy 为 fail。

最快修复方案：在 Prefill 端的 `–kv-transfer-config` 中添加 `”kv_connector_extra_config”:{“enforce_handshake_compat”:false}` 参数。Issue 评论中用户确认应用此配置后 corrupted-output 问题不再复现，并已解决了该部署问题。

注意事项：该方案在 Issue 中仅经过单一用户部署验证，是否适用于所有 NIXL/HMA 场景尚未完全确认；它通过绕过 NIXL 握手兼容性检查来避免失败，但根本的 KV 数据丢失问题仍需依赖 PR #52232 的模型无关请求级失败传播来彻底修复，该 PR 虽预期覆盖此场景，但尚未在 DeepSeek-V4/DSpark 组合上进行专项回归验证。

问题场景

用户使用 vLLM 以分离式 Prefill/Decode 拓扑部署 DeepSeek-V4，Prefill 端禁用 DSpark，Decode 端启用 DSpark。在 NIXL/HMA 接收失败后，API 返回 HTTP 200，但响应中出现 corrupted tokens：启用 thinking 时 corrupted 内容出现在 reasoning 字段而 content 为空；禁用 thinking 或禁用 reasoning parser 时，corrupted 内容会暴露在 content 字段中。所有 32 个请求都生成了 128 个 tokens，前两种模式下的空输出只是响应字段路由问题。

报错原文

[Bug]: DeepSeek-V4 NIXL failure returns corrupted reasoning with empty content
After a failed NIXL/HMA receive, DeepSeek-V4 can return HTTP 200 with corrupted
tokens in `reasoning` and an empty `content` field. Clients that read only
`choices[].message.content` see an apparently empty response.
The failed HMA receive is reported as receive completion without a
request-level failure reaching the scheduler, so Decode resumes with missing KV
data and generates corrupted tokens.

原因分析

可能原因：在 NIXL 兼容性握手失败后，HMA receive 失败被错误地报告为接收完成，没有请求级失败传递到调度器，导致 Decode 端在缺失 KV 数据的情况下继续解码，生成 corrupted tokens。Issue 中提到，在 commit 793ca6998 上，非对称的 Prefill/Decode 配置（Prefill 禁用 DSpark，Decode 启用 DSpark）会使 NIXL 兼容性握手失败，但请求仍会恢复解码。当 thinking 启用时，corrupted 输出会出现在 reasoning 字段而 content 为空，这与响应解析将生成文本视为 reasoning 的处理方式一致，但确切的解析器机制尚未隔离；字段拆分只是改变了 KV corruption 的暴露方式，并不能说明解析器导致了 KV 失败。

环境排查

确认 vLLM 版本是否为 Issue 中的 0.26.1rc1.dev657+g793ca6998，或更新版本是否已包含 PR #52232 的修复。
确认 Base image 是否基于 vllm/vllm-openai:v0.27.0-cu129-ubuntu2404（CUDA 12.9 + Ubuntu 24.04）。
确认 Prefill 与 Decode 的 --kv-transfer-config 中 kv_connector、kv_role、kv_load_failure_policy 配置是否正确，尤其是 Prefill 为 kv_producer、Decode 为 kv_consumer。
确认 NIXL/HMA 环境配置（HMA 设备、NIXL 库版本）是否正确。
确认 TP=8 的 GPU 环境是否满足 NIXL 通信要求。

解决步骤

首选方案（已验证）：在 Prefill 端的 --kv-transfer-config 中添加 enforce_handshake_compat 参数，绕过 NIXL 握手兼容性检查：
```
--kv-transfer-config \
'{"kv_connector":"NixlConnector","kv_role":"kv_producer","kv_load_failure_policy":"fail","kv_connector_extra_config":{"enforce_handshake_compat":false}}'
```
应用此配置后，corrupted-output 问题不再复现，可优先尝试。
如果上述方案无法解决，检查并升级到包含 PR #52232（模型无关的请求级失败传播修复）的 vLLM 版本。该 PR 通过在任何输出解析之前终止请求来防止此类失败，预期覆盖此 DeepSeek-V4/DSpark 场景，但需注意其在 DeepSeek-V4/DSpark 上尚未进行专项回归验证。
检查 Prefill 与 Decode 两端的 speculative 配置是否对称。Issue 中明确 Prefill 禁用 DSpark、Decode 启用 DSpark 会导致 NIXL 握手失败，可尝试将 Prefill 端也启用 DSpark（或两端保持对称配置）作为排查手段，但未在 Issue 中验证。
若问题仍存在，检查后端日志中是否有 NIXL/HMA receive 失败或握手失败的具体错误信息，并反馈给 vLLM 社区。

验证方法

应用上述修复后，重复 Issue 中的四模式测试矩阵（default、thinking enabled、thinking disabled、reasoning parsing disabled），每种模式发送 8 个请求（共 32 个请求），确认 8/8 请求均返回 HTTP 200 且 content 字段中不再出现 empty 或 corrupted 内容，reasoning 字段不再出现 corrupted tokens，生成内容与预期一致。也可在 NIXL 握手失败场景下确认请求被正确终止而非返回 200。