Jev 接入 MiniMax H3 提速 41.7%：但作者实测表里，固定 5% 比它更快

1 hours ago AI笔记

结论先行：社区正在转的那句「Jev 让 MiniMax H3 生成提速 41.7%」，数据源是作者的仓库没错，但它测的不是 Jev 的功劳。同一份仓库里还有一张对照表，同样是 RTX 4070、同样 1024×1792、124 帧、4 步：固定 5% 稀疏率跑 212.20 秒，Jev 自适应跑 219.15 秒——Jev 版本反而慢了约 7 秒。作者在两张表上都写明了：「这是 SLA＋Jev 方式整体的效果，不是 Jev 相对固定 SLA 的单独优势」「质量同等性未认定」。这两句限定语在转发链里几乎全部消失了。

我把仓库的 README、009JEV.md、JEV_ADAPTIVE.md 和实测记录都翻了一遍，下面是完整的数字和机制。

这件事到底是什么

主角是一个日本开发者（X 账号 @sep_is_heim，社区也称作 Kamimoto）维护的 ComfyUI 自定义节点仓库 ComfyUI-MiniMax-H3-W4A4-VSA。9 月 9 日首次发布，9 月 20 日在实验分支 exp/jev-adaptive-vsa 上加了名为 009jev 的新方法，节点显示名是「009jev: Jev-guided Native SLA」。

这里的 Jev 就是站里此前写过的那个 TypeSafe AI 决策模型——不是聊天模型，不生成文本，只返回带置信度的结构化判断。证据是硬的：仓库要求配置 TYPESAFE_API_KEY 环境变量，示例用 TypeSafe SDK，模型版本号 jev-1.13.0，走的正是 Choice 原语那套「给候选打分挑一个」的调用方式。

009jev 做的是一件事：让 Jev 替标准 SLA 决定每一层保留多少注意力。Jev 只从 1%、3%、5%、10% 四个档位里给每层挑一个 keep 率，至于具体哪些 attention 连接被跳过，由 SLA（native sparse linear attention）自己去算。换句话说，Jev 在这里扮演的是「算力预算分配器」，不是加速器本身。

和仓库早期那条路线相比，009jev 有个对使用者很友好的变化：不再需要 W4A4 权重量化转换。旧路径要求跑 convert.py 把 FC1 转成 W4A4、预生成 gate 缓存、占用约 5.8 GB 额外磁盘；009jev 直接用原始 INT8 模型，只保留标准的模型加载、线性计算和 FastVAE。

那 41.7% 是怎么测出来的

作者在 009JEV.md 里给出的实测表只有两行，条件是 RTX 4070 12GB、1024×1792、124 帧 / 24fps（约 5.2 秒视频）、seed 2026、4 步采样：

方案 全程耗时 显示时间
matlow fused 4step（基线） 366.720 秒 06:07
009jev 213.890 秒 03:34

缩短 41.675%，社区转的 6:07 → 3:34 就是这两个数。时间含模型加载、等待 Jev 返回、VAE 解码和写盘。

但作者在这张表正下方加了一句加粗说明，原文是：「SLA＋Jev方式全体の効果であり、固定SLAに対するJev単独の優位を測った値ではありません。品質同等性は未認定。」——这是 SLA＋Jev 整体方案相对原始基线的效果，不是 Jev 单独相对固定 SLA 的优势；质量是否等效，没有认定。

这句话不是客气。仓库里另一组实验直接把对照做出来了。

真正的对照实验：固定 5% 赢了

9 月 20 日那份逐层验证记录（docs/experiments/README.md）是同一台机器、同一套参考图、同一个 prompt，条件统一为 1024×1792、124f、24fps、4step、seed 43：

条件 平均 keep 率 全程生成 后 3 步均值（秒）
Fixed1 1% 200.71 32.68
Fixed5 5% 212.20 35.43
run16 / layer_v4 4.85% 219.32 35.59
run17 / 低置信度回退 5% 222.64 36.32
run18 / layer_v5（最终版） 3.8675% 219.15 35.22

把这张表读清楚，有三件事需要同时看到：

第一，Jev 的最终版没有跑赢固定 5%。219.15 秒对 212.20 秒，慢了 6.95 秒。而它把平均 keep 率压到了 3.8675%，比固定 5% 更稀疏——算得更少，却更慢。

第二，最省的那档不是 Jev 选出来的。固定 1% 只要 200.71 秒，是全场最快，比 Jev 快 18 秒。作者没有把固定 1% 作为推荐配置，因为画质风险未评估，但这说明这条曲线的形状是「keep 率越低越快」，Jev 的动态调度并没有在这条曲线上找到更好的点。

第三，作者自己把结论写死了。原文：「最终版把要求的非 sink 注意力预算削减了 22.65%，但总生成时间没有改善」「180 秒以内未达成」。

还有两处诚实的限定，值得原样搬过来：一是「单次运行、历史对照，不是统计上确立的速度差异」——每个条件只跑了一次，没有重复测量；二是后 3 步的时间是从进度时间戳推算的，包含观测开销，不是 GPU kernel profiling。

跨表再看一眼也能互相印证：009jev 的 213.890 秒（seed 2026）和这里的 Fixed5 212.20 秒（seed 43）差 1.7 秒，落在同一区间。两个方向的证据都指向同一件事——提速到 3 分半是 SLA 稀疏注意力的功劳，Jev 的动态调度在这个尺度上没有额外贡献，甚至略有倒退。

Jev 到底在决定什么

机制值得单独拆一下，因为这是整件事里真正有意思的部分。

模型是 MiniMax H3，共 50 个 block。每一步采样全部 50 层都要执行，Jev 不跳过任何一层，它只调每层的稀疏率。流程分两段：

  • 第一步：把 prompt 正文和可选的「历史统计」一次性交给 Jev，让它对 50 层做批量判断。第 0 层的候选只有 5% 和 10%。这里不做任何额外的 probe forward，也不预读当前画面。
  • 第 2 至 4 步：把上一步音、视频各 64 token × 16 channel 的相对残差、层内排名、残差的 step 间变化喂给 Jev，判断第 1 至 49 层，第 0 层固定 5%。

这里有个口径要纠正：社区转述里到处是「Jev 判断 49 层」。作者在文档里专门解释了——「模型は全50層を毎step実行します。図が49層なのは表示範囲です」。全 50 层每步都跑，图里显示 49 层只是绘图范围，因为第 0 层是固定值不参与决策。「49 层」是显示范围，不是跳过了一层。

最终版策略 layer_v5 的档位表是这样的：

层位置 低 / 基准 / 高 keep 率
浅层 2% / 5% / 7.5%
中间层 1% / 5% / 7.5%
最后 5 层 3% / 5% / 10%

另外还有一条规则：第一步无论 Jev 怎么选，全层锁 5%，并且 block0、block1 受保护。Jev 同时会选一个 2.5% / 3% / 3.5% 的总预算，主机侧再按置信度优先级在预算内分配。

失败处理做得比较保守，这点值得肯定：置信度低于 0.4（预算）或 0.3（首次）就退回保守档；API 失败或回答不合法，就关闭该次生成的后续 API 调用，后续步骤全部锁回 5%。超时 20 秒，重试 0 次，单次生成最多 4 次请求。

为什么提速撞墙了

把三处数字放在一起，原因就清楚了。

一是稀疏率不等于总计算量。作者反复强调「keep 1% 不等于全计算量的 1%」——sink token、并列时的追加选择、QKV、FFN、projection、routing、数据搬运都还在。那张 allocation 图上也写着：图中是 keep 设定值，不是实际被选中的全部连接掩码，也不是总计算削减率。所以把平均 keep 率从 5% 压到 3.87%，省下来的只是一部分注意力，摊到全程就稀释掉了。

二是 API 调用本身要花时间。这次验证里 Jev 的决策耗时约 4.56 秒。相对 212 秒的总时长只有 2%，不算多，但它正好抵消掉了省下的那部分——预算削减 22.65% 换来的是 0 秒改善，账单对不上。

三是真正的大头来自别处。基线 366.72 秒到 213 秒这一大截，主要来自 SLA 稀疏注意力本身，以及早期那条路线上的 W4A4 量化。这两项都不是 Jev 的贡献。

成本：一次生成约 1 美分

这次逐层验证全程，Jev 侧消耗是：9 次 HTTP 请求、447 个问题、输入 237,982 tokens、输出 16,586 tokens。按 TypeSafe 公布的输入价（每 10 亿 token 42 美元，即 0.042 美元/百万）、输出免费估算，约 0.01 美元。

作者标注这是估算价不是实际账单，且价格与服务规格可能变动。但量级说明了一件事：用决策模型做推理调度，成本几乎可以忽略，一次五秒视频一分钱。真正的问题是它有没有换来东西——目前的答案是肉眼可见的部分没换来。

上手前必须知道的八件事

仓库是实验分支，作者明说「不保证稳定版的提速」。如果你打算真的跑一遍，这些限制最好先看：

  • 硬件实测只覆盖 RTX 4070 12GB。comfy-kitchen 的 native ConvRot INT4 走的是 SM8x（Ampere/Ada）路径，Hopper / Blackwell 架构直接被排除。其他显卡必须自己跑 --check 加实际生成验证。
  • 必须是 4 步 + res_multistep。步数不是 4 会报错；用其他 sampler 会落到旧 wrapper 的固定 10% 且不调 API——跑完也不代表 Jev 生效了。
  • 环境版本卡得很死：ComfyUI 0.36.0、Python 3.13.x、PyTorch 2.14.0+cu130、comfy-kitchen 0.2.34。作者甚至记了 ComfyUI 的 commit 号，因为「版本号相同并不保证 GPU 二进制兼容」。
  • API key 只从环境变量读，别写进工作流 JSON——那些文件是要分享和进版本库的。仓库给了 PowerShell 的 SecureString 写法，避免密钥落在命令历史里。
  • SDK 要独立 venv（示例用 Python 3.10），因为它和 ComfyUI 的 Python 依赖不同。忘了在工作流里指定 sdk_python 绝对路径，会静默地用错环境。
  • 日志会留 prompt。[009jev] 前缀的日志包含判断 state、Jev 的回答和 usage，也就是说你的提示词会写进日志。原始图像、音频、模型权重不上送，但 prompt 会。
  • 画质没有评估。仓库多处写明：主观画质、角色一致性、音频质量均未评价。音频只比了 1–4kHz 频段能量占比（固定 5% 为 9.344%，run18 为 9.495%），作者直接说了「这不是音质一致的证明」。
  • 早期策略有翻车记录。block_v3 那版因为跳 block 导致人物再现性崩坏，被明确标为「本次入口之外」；run17 的低置信度回退也只是中间产物。当前代码对应 run18 的行为，不是 run17。

我的三点判断

一、把决策模型用在推理调度上，这个方向是对的

Jev 这类 System One 模型的特性——毫秒级、返回结构化选择、带置信度——天生适合做「运行时参数选择」这种高频小决策，而不是生成内容。本站此前整理的几类用法里，客服路由、意图分发、执行守卫都是同一逻辑。把每层的稀疏率当成一个 50 选项的 Choice 问题，思路是干净的。而且这条路线已经有了本地化选项——APUS 开源的 OpenJev-v1 和 Laya 都能把这类决策搬到本机，不必依赖云端 API 和那 4.56 秒。

二、但目前的实测结果不支持「Jev 提速」这个说法

这是我认为最该被说出来的部分。一份严谨的仓库里写着固定 5% 跑 212.20 秒、Jev 跑 219.15 秒，转述出去却变成「Jev 提速 41.7%」——偏差不在数据，在于把「整体方案 vs 原始基线」读成了「Jev vs 固定稀疏」。作者在两张表下都写了限定语，还是没拦住。

三、视频生成的提速主战场仍在架构侧

这次 366 秒到 213 秒的大头来自 SLA 和量化，不是调度。回看 H3 本身，效率的来源也是架构：H3-VAE 的 4 倍有效序列长度、理解与生成负载分离调度带来的近 30% 训练吞吐。这类收益是结构性的，而运行时调度的收益是边际的。同期其他视频模型走的路子也类似——通义 Wan2.2 的 MoE 架构、Gemini Omni 1.1 Flash 的 60% 提速，都不是靠动态调度。

小结

009jev 是一次值得尊重的开源实验：代码、实测数据、失败记录、限制说明全部公开，连「目标未达成」都写在文档首页。它证明了一件有价值的事——决策模型可以被接进扩散模型的推理循环里做逐层预算分配，成本约一分钱。

但它目前没有证明自己更快。同条件下固定 5% 是 212.20 秒，Jev 自适应是 219.15 秒；全场最快的固定 1% 是 200.71 秒。社区热传的 41.7%，属于 SLA 稀疏注意力加 W4A4 量化的整体收益。

对想在本地跑 H3 的人来说，眼下更实际的顺序是：先把 SLA 和量化这套确定性收益拿到手，再考虑要不要加一层动态调度。而这个调度层如果真要落地，本地开源决策模型可能比云 API 更合适——毕竟那 4.56 秒的往返，省下来的注意力还没它多。

常见问题

这个 Jev 和 TypeSafe AI 的 Jev 是同一个吗

是。仓库要求配置 TYPESAFE_API_KEY、使用 TypeSafe SDK、模型版本 jev-1.13.0，调用的正是 Choice 原语。它在此处的作用是给每层从 1/3/5/10% 四个稀疏率里挑一个，属于典型的决策模型用法。

那 41.7% 到底能不能信

数字本身没问题（366.72 秒 → 213.89 秒），但它衡量的是「SLA＋Jev 整体方案」相对原始基线的效果。同条件下的对照显示 Jev 自适应 219.15 秒、固定 5% 212.20 秒，Jev 并未胜出。另外每个条件只跑了一次，作者明确说这不是统计上确立的差异。

画质有保证吗

没有。仓库多处声明主观画质、角色一致性、音频质量均未评价，质量同等性未认定。音频侧只对比了 1–4kHz 频段能量占比，作者说明那不是音质一致的证明。早期 block_v3 策略还出现过人物再现性崩坏的记录。

消息来源

  • sepiablue-ai/ComfyUI-MiniMax-H3-W4A4-VSA 仓库（实验分支 exp/jev-adaptive-vsa）的 README、009JEV.md、JEV_ADAPTIVE.md 与 docs/experiments/README.md
  • 作者 X 账号 @sep_is_heim；Reddit r/StableDiffusion 讨论帖（u/Repulsive_Gap_1678）
  • AGI Hunt 事件聚合页；X @TheMoonMidas 转述
  • MiniMax H3 模型背景参考 MiniMax 技术博客与公开报道

相关阅读

延伸阅读

AI 自学笔记 每天更新 AI 前沿动态，订阅 RSS，或按 Ctrl/⌘+D 收藏本站，明天见。

Related News