DeepSeek V4 Flash 在 Strix Halo 上跑出 26.76 t/s

一位 Reddit 用户在 Flow Z13（搭载 Ryzen AI MAX+ 395 与 Radeon 8060S / gfx1151，128GB LPDDR5X）上对 DeepSeek V4 Flash 0731 进行了为期一周的实测，借助 llama.cpp 的 Vulkan 后端与 DSpark 投机解码，在统一内存 APU 上跑出了 26.76 t/s 的持续解码速度。该结果为本地运行百亿参数级 MoE 大模型提供了一个可复现的参考配置。

核心性能数据

测试使用 Unsloth UD-IQ3_XXS 量化（≈98GB，4 文件分片）与 bf16 草稿模型（≈11GB），q8_0 KV 缓存，上下文 131,072 token。主要结果如下：

• 持续解码（4096 token）：26.76 t/s
• 峰值解码（3 秒窗口）：35.27 t/s
• Prefill（2209 token 提示）：236 t/s
• DSpark 接受率：0.586，平均接受长度 3.93
• GPU 利用率：约 92%；CPU 利用率：约 1%

测试环境为 CachyOS，内核 7.1.6，Mesa 26.1.6，使用 Nathan 打包的 llama.cpp v0.6.1（自带 RADV，未启用 ROCm）。

与 DGX Spark 的横向对比

Strix Halo 与 NVIDIA DGX Spark（GB10）同为统一内存 APU，LPDDR5X 带宽接近（约 256 GB/s vs 273 GB/s），但预填阶段 DGX Spark 优势明显：

• Strix Halo（Vulkan v0.6.1 + DSpark）：解码 26.76 t/s，Prefill ≈236 t/s（@2K）
• DGX Spark（Entrpi/ds4 fork v0.5.6 + DSpark）：解码 27.3 t/s，Prefill ≈960 t/s（@2K）

未启用投机解码时，两平台裸解码几乎一致（15.7 vs 14.2 t/s），均受内存带宽制约；启用 DSpark 后差距也仅在误差范围内（26.76 vs 27.3 t/s）。DSpark 在 Strix Halo 上的加速比更高（1.70× vs 约 1.34×），原因是 DGX Spark 的裸解码 CUDA-graph 实现本身已更快，投机解码的提升空间更小。Prefill 方面，DGX Spark 凭借 D2R tensor-core GEMM 几乎是 Strix Halo 的 4 倍。需注意的是，两平台所用量化精度（IQ3_XXS ≈98GB vs Q2 ≈81GB）、引擎与草稿精度（bf16 vs Q2K）并不完全等同，仅作参考。

推荐配置

测试者给出的可复现启动命令核心参数：

• 目标模型：DeepSeek-V4-Flash-0731-UD-IQ3_XXS
• 草稿模型：DSV4-Flash-DSpark-draft-bf16
• 后端：ngl all + ngld all，启用 Flash Attention，KV 量化 q8_0
• 上下文长度：131072，批大小 -b 2048 -ub 2048
• 投机解码：--spec-type draft-dspark --spec-draft-n-max 64
• 内核启动参数：amd_iommu=off amdgpu.gttsize=126976 ttm.pages_limit=32505856
• BIOS 显存划分：4GB，剩余由 GTT 覆盖，合计提交约 109GB
• 电源策略：z13ctl+ 配置文件，关闭 CPU 加速、固定最低频率，因解码为带宽受限，降频不影响吞吐

实战踩坑经验

作者总结了在 gfx1151 上踩过的六个关键问题：

• q8_0 KV 在长生成下优于 f16：4096 token 测试中 22.7 vs 19.3 t/s，且上下文可翻倍至 131k；f16 仅在短生成（<1024 token）占优。
• 草稿模型必须使用 bf16：Q2_K-Q8 量化草稿（6.5GB）会立即触发「invalid token = -1」崩溃，无更小的可用草稿，11GB 是下限。
• Vulkan 在 Strix Halo 上明显优于 ROCm：antirez/ds4 ROCm 版本仅 122 t/s prefill、12.5 t/s decode，相比 Vulkan 的 232 t/s 与 22+ t/s 仍有差距，ROCm 在 gfx1151 上尚不成熟。
• Ubatch 2048 是显存上限：总提交约 109GB，KV 与缓冲仅剩 7GB，ubatch 4096 会触发 OOM；如放弃草稿改用 ngram，ubatch 8192 可达约 254 t/s prefill，但解码性能下降。
• 必须升级到 v0.6.1：v0.6 存在 TENSOR_ALLOW_RESHAPE 的 stride bug，会静默回退 43 层注意力到 CPU，表面 GPU 75%、CPU 50% 看似繁忙，实际仅半速运行。
• GPU 利用率下降 ≠ 性能下降：v0.6.1 利用率约 92%（vs 0.4 时代的 99%），但新 MoE shader（ROWLISTS、SMALLN、BM64、M128、F16B、FA_WAVE32）让单 kernel 更快，吞吐反而从 20.88 提升至 26.76 t/s。

模型信息：deepseek4 架构，43 层，256 专家（激活 6 + 共享 1），embedding 维度 4096，原生上下文 1M，MIT 许可证。GGUF 文件托管于 Hugging Face（unsloth/DeepSeek-V4-Flash-0731-GGUF），llama.cpp 定制构建见 Nathan 的 GitHub 仓库（v0.6.1）。