我做到了！！DeepSeek-V4-Flash-Vision EXL3 MixedK 现在单台 DGX Spark 上同时运行视觉与DSpark推测解码。🚀🚀 使用DSpark3时文本解码速率达19.7 tok/s，相比纯视觉路径提升约2.2倍，同时图像提示在同一vLLM进程中仍能正常工作。🔥

这正是我想要验证的核心成果。

不是：

“305B权重能装下。”

也不是：

“视觉模型能加载。”

而是：

→ 约95GB的MixedK打包文件 → 全部256个路由专家 → 视觉塔+对齐器 → 3个原生DSpark MTP层 → 单台GB10设备 → 单个vLLM服务器 → 同时支持图像处理与推测解码

视觉与推测解码协同运作成功！

打包文件将视觉权重与三个DSpark草稿层作为一等权重承载。

vLLM每夜构建版本自动选择 DeepseekV4ForConditionalGeneration，而DSpark草稿层复用了目标解码器实现。

因此草稿配置只需：

{"method":"dspark","num_speculative_tokens":3}

无需独立的草稿检查点。 无需草稿端模型加载器黑客手段。

在短响应中，我观察到平均接受草稿长度在2.3到3.2个标记之间。

在单台GB10设备上测量：

文本 + DSpark3：19.7 tok/s 图像问题：16至20 tok/s 256标记技术回答：14.8 tok/s 纯视觉路径：8.5至10.8 tok/s 带草稿的KV池：84,554个标记

图像测试确实是真正的多模态提示。

我的合成测试卡包含一个大红色方块和左上角一个较小的蓝色方块。

无论是否启用推测解码，模型都正确描述了对象、颜色和位置。

三处必须修复的问题

1. SM120/121宽视觉预填充行

视觉模型将滑动窗口预填充行从128扩展至512标记，使图像区段能进行双向注意力计算。

FlashInfer在GB10上的稀疏MLA路径期望128宽的行。

结果如何？

引擎在预热时死亡。

我的补丁将每个宽行切分为128标记的片段，运行相同内核，然后使用log-sum-exp合并部分softmax结果。

数学原理相同。生成了内核兼容的较小片段。

这解锁了GB10上的视觉功能。

2. 在约122GiB统一内存机器上加载约95GB数据

模型能装下。

朴素加载路径却不行。

95GB检查点不能随意在Spark上进行双缓冲加载，同时指望统一内存能宽容处理。

我添加了流式加载器，增量消耗分片并在加载前清除页面缓存。

完整的视觉+草稿启动现在保持主机内存平稳，不会在中途卡住。

3. 混合精度在运行时必须保持混合状态

这个问题更棘手，因为出错不一定导致崩溃。

我的vllm-exl3插件现在理解：

non_routed_dtype_policy: "bf16_as_stored"

EXL3路由专家保持压缩状态。

BF16非路由张量保持BF16格式。

DSpark源格式专家保持其声明格式。

如果没有此策略，BF16张量可能通过FP8参数加载，模型可能返回流畅的垃圾内容、均匀的logits或空输出，而无明显加载器错误。

这正是我讨厌的那类bug。😅

自行尝试视觉路径

我包含了 scripts/vision_probe.py。

它生成自己的测试图像，通过OpenAI兼容的视觉端点发送，并检查模型是否真正理解所见内容。

下一步

当前瓶颈在于密集路径，而非EXL3专家库。

我正在研究：

→ EXL3 lm_head → CUDA图用于启动开销胶水层 → 原生GB10 EXL3内核 → P1位精确反量化验证

让305B视觉MoE装进单台Spark很有趣。

让视觉和推测解码在同一台Spark上协同工作是更有用的里程碑。

配方： https://github.com/vcruz305/DeepSeek-V4-Flash-Vision-EXL3-MixedK-DGX-Spark-recipe…

模型： https://huggingface.co/vcruz305/DSV4-Flash-Vision-ablit-EXL3-MixedK…

vLLM EXL3插件： https://github.com/vcruz305/vllm-exl3…

vcruz305/DeepSeek-V4-Flash-Vision-EXL3-MixedK-DGX-Spark-recipe

来源：https://github.com/vcruz305/DeepSeek-V4-Flash-Vision-EXL3-MixedK-DGX-Spark-recipe

在单台NVIDIA DGX Spark上的DeepSeek-V4-Flash-Vision EXL3 MixedK

在X上关注 (https://x.com/ViC305) 在Hugging Face上关注 (https://huggingface.co/vcruz305)

针对 vcruz305/DSV4-Flash-Vision-ablit-EXL3-MixedK (https://huggingface.co/vcruz305/DSV4-Flash-Vision-ablit-EXL3-MixedK) 在 单台NVIDIA DGX Spark / GB10 (SM121) 上的可复现 vLLM 配方。

此打包文件在混合每层2/3位的EXL3格码（六层3位，其余2位）下保持全部256个路由专家（无专家修剪），非路由权重保持其官方源格式，并搭载视觉塔、对齐器和三个DSpark MTP草稿层。

推荐路径是vLLM每夜构建版 + vllm-exl3插件，启用打包文件的DSpark草稿：它在单台GB10上的一个进程中以约20 tok/s（2026-09-02验证）的速度服务文本和图像。原版vLLM 0.28.0是纯文本替代方案（22-24 tok/s，无视觉类）。此处提供的每个补丁都小巧、锚定精确且幂等。旧的分叉运行时路径保留在docs/ROUTE_B_FORK.md中。

独立社区工程。与DeepSeek、NVIDIA或vLLM无关或未获其背书。

核心验证结果

文本 + 视觉 + DSpark草稿：vLLM每夜构建版（推荐）

于2026-09-02在单台GB10（约122GiB可见统一内存）上测量，enforce-eager，贪心模式，--kv-cache-dtype fp8。启动：仅视觉类（利用率0.85，16k），同一类带打包文件的DSpark草稿（利用率0.88，{"method":"dspark","num_speculative_tokens":3}，16k），然后在MAX_MODEL_LEN=65536和启用工具调用时再次启动草稿。

三个服务端补丁使其工作（见下表）：原版0.28.0补丁、视觉类流式权重加载器，以及视觉类在SM120/121上产生的宽滑动窗口行的切片预填充。

仅文本：原版vLLM 0.28.0 + DSpark推测解码

于2026-09-02在单台GB10（约122GiB可见统一内存）上测量，enforce-eager，贪心模式256/512标记补全，--kv-cache-dtype fp8。

相同打包文件，相同分片，无分叉：pip install vllm==0.28.0，插件，scripts/patch_dsv4_stock028.py，以及以下配置策略。分叉运行时（非路由权重在加载时量化为块-FP8，无草稿时15.9 tok/s，仅文本）归档在docs/ROUTE_B_FORK.md中。

速度：时间去向与未来规划

在GB10上的单序列解码是内存带宽问题。每个标记读取六个活动专家（EXL3，2-3位）加上每个非路由张量（BF16格式，注意力、密集早期层、共享专家、DSA索引器、lm_head），每层运行十几个小型BF16 cuBLAS矩阵乘法，永远填不满GPU。在同系列GLM-5.3-Flash配方中，分析器将47.5%的GPU时间花在这些密集BF16线性层上，使用插件的覆盖工具将其重量化到EXL3后获得1.80倍无草稿解码提升。这里的数字一致：BF16密集路径11.5 tok/s（文本路径）和8.5-10.8 tok/s（视觉类），加载时fp8密集路径15.9 tok/s（分叉），DSpark草稿大致将密集路径的任何输出翻倍（纯文本22-24 tok/s，视觉类约20 tok/s）。

按收益排序，推荐路径接下来正在连接的内容：

1. 密集EXL3覆盖用于非路由线性层（vllm-exl3 tools/dense_overlay.py，在GLM上1.80倍），与草稿叠加。
2. CUDA图。 以上所有数字都是--enforce-eager。
3. 更高利用率一旦机器有干净首次启动：上面的64k草稿运行在利用率0.88时留下8-9GiB空闲主机内存，64k时的KV池容纳的请求远多于一个，因此131072是下一个上下文步骤。

要求

• 一台DGX Spark（GB10 / SM121），NVMe需有约100GB空闲空间用于打包文件。
• 文本 + 视觉：包含vllm#54566 (https://github.com/vllm-project/vllm/pull/54566) 的vLLM 每夜构建版 aarch64轮子（使用 0.28.1rc1.dev324 验证），exllamav3>=1.4.5 及其编译的 exllamav3_ext 模块（仅纯Python JIT轮子不够：插件导入编译模块，因此需从源代码构建exllamav3或从已有安装复制.so），flashinfer-python==0.6.18，以及 vllm-exl3 (https://github.com/vcruz305/vllm-exl3) 插件 >= 0.2.3。
• 仅文本带DSpark草稿：来自PyPI的 vllm==0.28.0，exllamav3>=1.4.5，flashinfer-python==0.6.18（旧版FlashInfer拒绝此模型的 index_topk=192），以及插件 >= 0.2.3（bf16_as_stored 策略）。
• 分叉运行时：见 docs/ROUTE_B_FORK.md。
• nvcc 和 ninja 需在服务时的PATH中。 FlashInfer在此机器上JIT编译其内核；没有nvcc时，唯一可用的注意力后端会在引擎初始化时被拒绝，vLLM将因“No valid attention backend found“而死亡。export PATH=/usr/local/cuda-13.0/bin:$PATH 并使用虚拟环境的ninja。

快速启动

# 0) 下载打包文件（可恢复，多流）
hf download vcruz305/DSV4-Flash-Vision-ablit-EXL3-MixedK \
  --local-dir ~/models/DSV4-Flash-Vision-ablit-EXL3-MixedK

# 1) 写入服务配置（幂等；扫描分片获取layer_bits）
python scripts/fix_pack_config.py ~/models/DSV4-Flash-Vision-ablit-EXL3-MixedK

# 2) 修补运行时的DeepSeek-V4文件（幂等，精确锚点，每个文件旁有备份；
#    每个脚本可选接受site-packages/vllm路径）
python scripts/patch_dsv4_stock028.py            # 原版0.28.0和每夜构建版
python scripts/patch_dsv4_vl_stream_load.py      # 仅每夜构建版：流式加载视觉类
python scripts/patch_dsv4_vl_sm120_wide_swa.py   # 仅每夜构建版：SM120/121上的宽窗口行

# 3a) 使用DSpark草稿服务文本 + 视觉（每夜构建版）。已验证设置
#     （64k上下文；保守首次启动使用MAX_MODEL_LEN=16384）。
#     无草稿类移除SPEC_CONFIG（更多KV，速度减半）。
#     工具调用和推理分离默认开启
#     （TOOL_CALL_PARSER="" 或 REASONING_PARSER="" 关闭它们）。
MODEL_DIR=~/models/DSV4-Flash-Vision-ablit-EXL3-MixedK \
  GPU_MEM_UTIL=0.88 MAX_MODEL_LEN=65536 \
  SPEC_CONFIG='{"method":"dspark","num_speculative_tokens":3}' \
  bash scripts/serve_one_spark_dsv4.sh

# 3b) 使用DSpark草稿仅服务文本（原版0.28.0）
MODEL_DIR=~/models/DSV4-Flash-Vision-ablit-EXL3-MixedK \
  SPEC_CONFIG='{"method":"dspark","num_speculative_tokens":3}' \
  bash scripts/serve_one_spark_dsv4.sh

# 4) 冒烟测试：文本，然后通过聊天端点发送图像
curl -s http://127.0.0.1:8899/v1/completions -H 'content-type: application/json' \
  -d '{"model":"DSV4-Flash","prompt":"The capital of France is","max_tokens":32,"temperature":0}'

IMG=$(base64 -w0 test.png)
curl -s http://127.0.0.1:8899/v1/chat/completions -H 'content-type: application/json' \
  -d "{\"model\":\"DSV4-Flash\",\"max_tokens\":64,\"temperature\":0,\"messages\":[{\"role\":\"user\",\"content\":[{\"type\":\"image_url\",\"image_url\":{\"url\":\"data:image/png;base64,$IMG\"}},{\"type\":\"text\",\"text\":\"Describe this image in one sentence.\"}]}]}"

# 5) 或单文件探测：无图像时绘制测试卡，打印答案加标记计数和tok/s
#    （任何有Python和Pillow的机器）
python scripts/vision_probe.py                      # 测试卡
python scripts/vision_probe.py photo.jpg "What is this?" http://127.0.0.1:8899

模型默认思考。启用推理解析器（默认开启）时，思考内容位于reasoning_content，content仅包含答案；使用REASONING_PARSER=""时，答案遵循content内的</think>标记。从另一台机器测试（端口转发、工具设置、Hermes Agent和Open WebUI、健康服务器数字、故障排除）记录在docs/TEST_VISION.md中。

打包文件配置契约

vLLM在查看您的CLI标志之前就从打包文件的config.json解析量化方法，残留的基础模型声明会静默覆盖--quantization exl3。打包文件的quantization_