7 月 31 日，DeepSeek 发布了 V4 Flash 的正式版本 0731——284B 总参数、13B 激活参数的 MoE 模型，MIT 许可，1M 上下文窗口。架构与前序预览版完全相同，变化全部来自重新执行的完整后训练管线：在 Terminal Bench 2.1 上从 61.8 跃升至 82.7，在 DeepSWE 上从 7.3 跳至 54.4。一个 13B 激活参数的模型在几乎所有 agentic 指标上超越了 49B 激活参数的 V4 Pro 预览版。
0731 发布前后，Reddit 的 r/LocalLLaMA 社区和开源贡献者持续测试本地推理，从消费设备到价值 5 万美元以上的双 GH200 工作站都有相关进展。其中也穿插了约 150 美元 AMD BC-250 矿卡运行 Qwen 的案例；它展示了低成本设备的潜力，但与 V4 Flash 的部署结果属于不同模型。
多种硬件已出现适配案例，但模型、内存和测试条件各不相同
在硬件梯度的底端，QuarkStar——一个 Vulkan/Metal 推理引擎——将 Qwen3.6-35B-A3B 带到了 16GB 设备上，包括约 150 美元的 AMD BC-250。该卡基于 PS5 APU，24 个可用 CU，通过 Vulkan 计算管线运行量化模型。这个 Qwen 案例表明，量化和 CPU/GPU 混合卸载可以帮助有限内存的设备运行较大模型；对 284B 的 V4 Flash，仍需单独核算权重与缓存需求。
在大内存 Mac 端，antirez（Redis 作者）用约两周时间写出了 ds4——一个单文件 C 推理引擎，专门为 DeepSeek V4 Flash 在 Apple Metal 上优化。ds4 使用的 2-bit 量化不是标准 Q2_K：它仅对 routed MoE experts 做激进量化（输入/门控用 IQ2_XXS，输出用 Q2_K），而路由、投影和共享专家保持 Q8_0。在 128GB M3 Max MacBook 上，这套配置在 32K 上下文中达到约每秒 58.5 个 token 的输入预处理速度（prefill），以及每秒 26.7 个 token 的生成速度。
社区贡献者还在单张 RTX 5090（32GB VRAM）+ DDR5 系统内存的配置上，通过 vLLM + CPU/RAM offload 跑通了完整的 1M 上下文窗口，prefill 约 800 tok/s、decode 约 15+ tok/s。
在高端工作站端，David Noel Ng 在其双 GH200 系统上对 V4 Flash 0731 进行了系统性基准测试。vLLM + DSpark k=6 在代码审查场景达到约 276 tok/s decode，1M 上下文完全常驻 HBM。SGLang 的一版补丁配置曾达到 317 tok/s decode，作者后续以原生 FP8 共享专家运行的最终配置约为 309 tok/s。自适应 prefill chunk 策略将 1M 上下文的首 token 等待时间（TTFT）从固定 chunk 方案的 895 秒压缩到约 358 秒。
在服务器 GPU 端，Fergus Finn 和 Doubleword 团队在单张 AMD MI300X（192GB HBM3）上完成了完整适配，解决了 MI300X 的 fnuz FP8 方言问题、AITER 内核覆盖缺失和 HIP graphs 兼容性。该适配报告给出的输出吞吐约为 2,699 tok/s；由于并发等测试条件尚不明确，不能与前面的交互式单流速度直接比较。报告还将租金估为同代 NVIDIA 方案的约一半，其商业价值仍需结合并发、任务和租用条件判断。
在 Mac 端，M3 Ultra（256GB 统一内存，819 GB/s 带宽）的相关 MXFP4-MLX 测试给出了约 40-54 tok/s prefill、约 4.5 tok/s decode，以及其他交互测试中 34-43 tok/s 的结果。这些数字缺少统一配置说明，不能视为同一条件下的生成速度。
DSpark 结合草稿生成与按置信度分配验证预算
DSpark 是这轮推理优化中的重要组成部分。DSpark 不是新模型——DeepSeek 的 HuggingFace 模型卡第一句话就说得很清楚：它是同一个 checkpoint，附加了一个推测解码模块。
DSpark 的设计针对传统推测解码中的两个问题。第一个是「后缀衰减」：传统 speculative decoding 使用小模型顺序生成 draft token，越靠后的 token 准确率越低，导致大量被验证步骤拒绝。DSpark 采用半自回归草稿生成：主干网络一次为整块 token 计算候选概率，再由轻量的顺序 Markov 模块根据已接受的 token 逐位修正，目标是在保持高接受率的同时降低草稿生成开销。
第二个问题是高并发退化。大多数推测解码实现在低并发时表现亮眼，但 batch size 上升时验证步骤的成本迅速超过收益。DSpark 的 confidence-scheduled verification 在每个 request 上分配不同的验证窗口：高置信度请求验证更长的 draft block，低置信度则提前截断。LMSYS 团队的 SGLang 集成在 H200 上的测试显示，在低接受率场景（如诗歌生成）中，动态预算相比全 block 验证持续领先。
SGLang 的 DSpark 集成还支持在 CUDA graphs 下验证不同长度的请求（ragged verify）。传统方法需要将各请求填充到统一验证长度；SGLang 则将不同长度的请求紧凑打包，按总 token 数选择计算图。验证预算减少时，实际执行的计算量也能随之减少。
在 Ng 的 GH200 测试中，DSpark k=6 实现约 2.97 倍的 decode 加速。但 Ng 也发现 DSpark block size 为 5，任何 num_speculative_tokens < 5 的配置会被直接拒绝——用户无法在低资源情况下通过减少 draft 深度来降低内存开销。
非对称量化保留共享部分精度，低比特质量仍需更多任务检验
2-bit 量化版本在 llm-sql-benchmark 上取得 25/25 满分——此前仅 Claude Opus 4.7 和 GPT-5.5 做到过。但这个结果需要放在正确上下文中。
antirez 的方案有一个关键设计选择：非对称量化。仅对 routed MoE experts 做 2-bit，路由网络、注意力投影、共享专家和共享部分的相关组件保持 Q8_0。在 MoE 架构中，routed experts 占参数量的绝大多数，但每个 expert 只处理一小部分 token。这套方案希望在压缩大量专家权重的同时，尽量保留共享组件的精度；实际质量损失仍需测试。antirez 在 X 上总结道：「输入/门控 IQ2_XXS，输出 Q2_K。其他所有保持 Q8，以保护共享专家、投影和路由。」
但这套方案有一个实际约束：ds4 的 GGUF 文件不是标准格式，需要专用推理引擎，不兼容通用 llama.cpp 或 Ollama。
Escha Labs 的 Escha-W2 方案将 Qwen3.6 35B 压缩到 12.3GB，使用 2-3 bit 混合量化 experts、INT8 密集层。在 RTX 4090 上单流约 225 tok/s，32 并发约 1,321 tok/s。但在 LiveCodeBench v6 上得分 62.6，低于 FP8 基线的 67.0，显示这个 Qwen 量化方案在该代码测试中仍有质量损失。
更广泛的约束：Unsloth 的分析显示，即使 3-bit 量化（UD-IQ3_XXS）也需要约 103GB 内存，至少 110GB 总内存才能运行。这对大多数消费级硬件仍是门槛。
首次响应、长上下文和专用引擎维护仍影响实用性
几个具体的技术瓶颈：
TileLang 运行时编译：Ng 在 vLLM 测试中发现 p99 TTFT 飙升至 11.5 秒，原因是 mHC kernel 在服务期间即时编译。换成 PyTorch/Triton fallback 可消除延迟尖峰，但 decode 吞吐下降约 65%。
长上下文 prefill 仍然昂贵：1M 上下文的 prefill 约需 358 秒——这是该配置下测得的等待时间，后续仍可能通过实现优化改善。
专用引擎碎片化：ds4、Krasis、Escha-W2 都依赖定制运行时。ds4 甚至不支持标准 GGUF。当模型更新时，维护成本集中在少数贡献者身上。
2-bit 质量边界不明确：SQL benchmark 满分表明这套配置能完成该测试，但 IQ2_XXS 量化在更长上下文、更复杂的 agentic 任务或推理链场景下的退化尚未被系统性评估。SQL 问题空间相对受限，满分未必能推广到开放域 agent 任务。
社区测试不可比：不同测试者使用不同的 prompt、量化级别和上下文长度。横向对比这些数字的意义有限——它们更适合说明某种配置能否运行模型。
明确许可和工具支持吸引适配，稳定部署仍需统一评测
2023 年 Llama 2 发布后，社区围绕它建立了量化、微调和部署的完整生态——不是因为 Llama 2 是所有模型中最好的，而是因为它是当时开源可用的最佳起点。
DS V4 Flash 0731 的社区响应速度表明它正在获得类似地位。三个关键驱动因素：MIT 许可提供了较清晰的模型使用条件；284B/13B 的总参数与激活参数配置减少了每个 token 需要参与计算的专家权重，但保存和调度全部权重仍有很高的内存要求；DSpark 的内置支持意味着社区不需要自己实现推测解码。
与同期竞争者对比：Qwen3.7 Flash 目前仅通过 API 提供，MiniMax H3 的开放发布有延迟期，GLM-5.2 在 GH200 上需要 IQ2 量化且 decode 仅为个位数 tok/s。这些条件共同推动了围绕 DS V4 Flash 的社区适配，但不能单凭不同配置的测试断定其全面领先。
更多社区参与仍未消除部署困难。2-bit 量化的交互式推理速度对日常使用仍然偏慢，1M 上下文在消费级硬件上更多是能力验证，各专用引擎的长期维护存在不确定性。这些尝试扩展了本地部署的选择。下一步需要减少专用引擎之间的兼容差异，并在一致任务条件下复现 3-bit 以下量化的质量与速度。
