DeepSeek 最近开源的 V4-Flash-0731，Jetson Thor 能跑吗？284B MoE 的边缘部署边界
继 Qwen3.8-Max 之后，我又查了 DeepSeek 最近开放权重的模型。当前最值得看的不是老的 DeepSeek-V3 / R1，而是 DeepSeek-V4-Flash-0731。
结论先说：
| 问题 | 结论 |
|---|---|
| 最近 DeepSeek 开源/开放权重模型看哪个？ | DeepSeek-V4-Flash-0731 |
| 许可 | MIT License |
| 模型规模 | V4-Flash 系列官方表格写 284B total / 13B activated |
| 上下文 | 1M tokens |
| Thor 单机能不能直接本地跑？ | 不建议，也基本不现实 |
| 正确测试方式 | 多卡服务器跑 V4-Flash；Thor 跑更小的 DeepSeek distilled / Qwen / coder 模型做边缘对照 |
一句话：DeepSeek-V4-Flash-0731 很开源、很强，但不是 Jetson Thor 的单机模型。
最近发布的到底是什么
DeepSeek Hugging Face 组织页显示，deepseek-ai/DeepSeek-V4-Flash-0731 是近期发布/更新的 DeepSeek-V4 系列模型。模型卡重点信息：
| 项目 | DeepSeek-V4-Flash-0731 |
|---|---|
| 架构 | MoE |
| 参数量 | V4-Flash 系列：284B total / 13B activated |
| Hugging Face 模型页显示 size | 304B params |
| 上下文长度 | 1M tokens |
| 精度 | FP4 + FP8 mixed |
| 许可证 | MIT |
| 重点能力 | code agent、tool use、长上下文、reasoning effort 控制 |
DeepSeek-V4 系列还有更大的 DeepSeek-V4-Pro：官方表格写 1.6T total / 49B activated，同样支持 1M 上下文。Pro 是能力上限，Flash 是更偏效率和部署成本的版本。
这次的 0731 版本最醒目的地方是 agent benchmark 提升很猛。模型卡给出的公开测试里，V4-Flash-0731 相比 preview 版大幅上涨：
| Benchmark | V4-Flash-0731 | V4-Flash Preview |
|---|---|---|
| Terminal Bench 2.1 | 82.7 | 61.8 |
| NL2Repo | 54.2 | 39.4 |
| Cybergym | 76.7 | 38.7 |
| DeepSWE | 54.4 | 7.3 |
| Toolathlon-Verified | 70.3 | 49.7 |
| Agents' Last Exam | 25.2 | 15.8 |
这说明它不是单纯聊天模型，而是明显朝“代码 agent + 工具调用 + 长上下文任务”优化。
Thor 真机检查
我连到两台 Thor 检查了本地模型目录：
| 设备 | 状态 |
|---|---|
thor | NVIDIA Thor，CUDA 13.0，Linux 6.8.12-tegra，122 GiB 内存 |
thor-jd | NVIDIA Thor，CUDA 13.0，Linux 6.8.12-tegra，122 GiB 内存 |
两台机器上都没有找到 DeepSeek 或 DSpark 相关权重：
find /home/nvidia/models -maxdepth 2 -iname "*deepseek*" -o -iname "*dspark*"
返回为空。
所以目前不能写“DeepSeek-V4-Flash-0731 已在 Thor 上跑出多少 token/s”。没有权重、没有可用本地服务，而且从模型规模看，Thor 单机也不是它的目标硬件。
为什么 V4-Flash 也不适合 Thor 单机
很多人看到 “Flash” 和 “13B activated” 会以为它可以像 13B dense 模型一样在边缘设备上跑。这是 MoE 模型最容易误判的地方。
13B activated 只表示每个 token 前向激活的专家规模，不表示只需要加载 13B 权重。
V4-Flash 的总参数仍然是 284B 级别。即便专家权重采用 FP4、其他部分 FP8，模型权重和运行时开销仍远超 Thor 舒适区。
粗略估算：
| 项目 | 估算 |
|---|---|
| 284B 全 FP8 权重 | 约 284 GB |
| 284B 全 INT4 权重 | 约 142 GB |
| FP4 + FP8 mixed | 取决于非专家占比，通常仍接近或超过 Thor 123 GB 上限 |
| 1M 上下文 KV cache | 会进一步吃掉大量内存 |
这还没有算：
- CUDA / runtime workspace
- MoE routing buffer
- prefill 临时张量
- speculative decoding 额外状态
- SGLang / vLLM 调度开销
官方模型卡给的运行示例也很说明问题。vLLM 示例写的是单个 4×GB300 节点，并开启：
--data-parallel-size 4
--enable-expert-parallel
--moe-backend deep_gemm_mega_moe
--kv-cache-dtype fp8
--speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'
SGLang 示例同样是 --tp 4，并使用 MoE 专用 runner：
sglang serve \
--model-path deepseek-ai/DeepSeek-V4-Flash-0731 \
--tp 4 \
--moe-runner-backend flashinfer_mxfp4 \
--speculative-algorithm DSPARK
这不是 Jetson Thor 单机的部署形态。Thor 可以做边缘推理，但不是 284B MoE + 1M context + TP4 的多卡服务器。
和 Qwen3.8-Max 的区别
这两个“最近旗舰”有一个共同点：都不是 Thor 单机本地模型。
| 模型 | 参数规模 | 开放状态 | Thor 单机本地推理 |
|---|---|---|---|
| Qwen3.8-Max | 2.4T | 官方发布/可用性需按渠道确认 | 不现实 |
| DeepSeek-V4-Pro | 1.6T / 49B active | Hugging Face 权重，MIT | 不现实 |
| DeepSeek-V4-Flash-0731 | 284B / 13B active | Hugging Face 权重，MIT | 不建议，基本不现实 |
| Qwen3.6-35B-A3B-FP8 | 35B MoE | 已在 Thor 本地目录 | 可跑 |
| Qwen3-Coder-30B-A3B-FP8 | 30B MoE | 已在 thor-jd 本地目录 | 可跑 |
DeepSeek-V4-Flash 的优势是：它真的有 MIT 权重，而且比 Pro 小很多。问题是“小很多”仍然是 284B，不是 30B。
Thor 上应该怎么测 DeepSeek 相关能力
如果目标是“比较 DeepSeek 最新开源路线和 Thor 本地部署”，我建议不要强行下载 V4-Flash 到 Thor，而是做两个层次：
1. 云端或多卡服务器测 V4-Flash-0731
测试它真正擅长的任务：
- 代码仓库修改
- terminal agent
- 多工具调用
- 长上下文文档定位
- SWE 类修复任务
记录：
| 指标 | 含义 |
|---|---|
| Pass@1 | 第一次能不能做对 |
| 总耗时 | agent 完成任务需要多久 |
| 输出 token | reasoning effort 的成本 |
| 工具调用轮数 | 是否过度调用工具 |
| 失败类型 | 命令错误、幻觉、格式失败、没验证 |
2. Thor 本地测 30B / 35B 级模型做边缘对照
在 Thor 上测这些更实际：
| 模型 | 适合用途 |
|---|---|
| Qwen3-Coder-30B-A3B-FP8 | 本地 coding agent |
| Qwen3.6-35B-A3B-FP8 | 本地通用 agent / 长上下文 |
| Qwable-v1 | Claude 风格 agent 行为蒸馏 |
| DeepSeek-R1-Distill-Qwen-14B / 32B | 如果后续下载，可测 reasoning 小模型 |
这样能回答一个真正有用的问题：
DeepSeek-V4-Flash 代表的 frontier open-weight agent 能力，和 Thor 本地 30B/35B 模型之间，差距到底体现在任务成功率、速度还是工程稳定性？
如果硬要在 Thor 上尝试，需要什么条件
理论上可以尝试极端路线，但我不建议把它当生产方案：
- 找到可靠的 V4-Flash 低比特量化版本。
- 确认 llama.cpp / SGLang / vLLM 在 ARM64 + Thor + CUDA 13.0 上支持该架构。
- 关闭 1M 上下文，先用 4K / 8K context smoke test。
- 接受大量 CPU/NVMe offload，速度可能低到不可交互。
- 准备处理 tokenizer、chat encoding、reasoning effort、MoE kernel 不兼容问题。
如果最终只能跑出几 token/s，工程意义不大。Thor 的价值不是“硬塞最大模型”，而是以 60W 级功耗稳定跑可交互模型。
我的判断
DeepSeek-V4-Flash-0731 是最近开源模型里很值得关注的一个：MIT License、284B MoE、13B activated、1M context、agent benchmark 大幅增强。它比 Qwen3.8-Max 更“可下载”，也比 V4-Pro 更现实。
但对 Jetson Thor 来说，它仍然太大。官方示例已经指向 4 卡高端服务器和 TP4 / expert parallel，而不是单块边缘 SoC。
我的选择会是：
- 要测 DeepSeek-V4-Flash-0731：去多卡服务器或云端测 agent 质量。
- 要测 Thor 本地部署：跑 Qwen3-Coder-30B-A3B-FP8、Qwen3.6-35B-A3B-FP8，或者 DeepSeek-R1 distill 级别模型。
- 要写工程文章：不要写假跑分，写“开放权重 frontier 模型为什么仍然离边缘本地部署很远”。
一句话总结：DeepSeek-V4-Flash-0731 是最近 DeepSeek 最值得看的开放权重模型，但 Jetson Thor 的正确角色是本地 30B/35B agent 对照平台，不是 284B MoE 单机服务器。
资料来源
- DeepSeek Hugging Face 组织页：
https://huggingface.co/deepseek-ai - DeepSeek-V4-Flash-0731 模型卡：
https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731 - DeepSeek-V4-Pro 模型卡：
https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro - DeepSeek-V3 GitHub：
https://github.com/deepseek-ai/DeepSeek-V3
Thor 环境检查时间：2026 年 8 月 13 日。本文没有声称完成 DeepSeek-V4-Flash-0731 本地跑分，因为当前 Thor 设备上没有该模型权重，且官方推荐运行形态明显指向多卡服务器。