Intel 官方 ComfyUI Docker 最新版提升巨大：Arc Pro B70 同卡同工作流实测，附自建版的编译过程与三方对比

八月那篇我在一张 Intel Arc Pro B70 上量了一遍 ComfyUI 的活，结论是「能干，慢两三倍」。这个月 Intel 发了官方的 ComfyUI 镜像，同一张卡、同一份工作流，它比我们自己搭的更新的 ComfyUI 快 1.66 倍。我一开始不信，怀疑它省了采样步；扫完步数发现它每一步反而更慢。真正的差别是一个我们的环境里根本不存在的目录。最后我把那套东西编进了我们的最新版——三方对比，自建版追平并略超。

平时我聊得多的是片子怎么剪、词怎么写。这回还是讲机房里那张不带 CUDA 的显卡：官方出了镜像，比我们自己搭的快得多；差在哪、怎么补上，一步一步量给你看。

八月那篇（《为 Intel Arc Pro B70 正名》）里，我们跑的是自己装的 ComfyUI：上游最新提交，PyTorch 官方的 torch.xpu，没有任何 Intel 的私货。当时的成绩单是：MiniMax H3 Turbo 出一条 5 秒 480p 有声视频 2 分 27 秒，720p 要 5 分 27 秒，720p 的 15 秒长片 71 分钟没跑完。

九月初，Intel 的 llm-scaler 仓库发了一个专门给 ComfyUI 用的镜像：intel/llm-scaler-omni:0.2.0-b1。我把它拉下来，用同一份工作流跑了同一件事。

01同一张卡、同一份图，官方 60 秒，我们 100 秒

先把变量锁死。官方镜像里没有我们生产上用的第三方 Turbo 节点，所以两边都改用纯核心节点的等价图——同样的 INT8 权重、同样的 Turbo LoRA、同样的采样器、同样的 6 步、同样的种子，一份 JSON 发给两个服务。计时取服务端「开始执行到执行完成」，不含排队。每档换种子跑两三次。

灰色是八月那篇的旧栈（上一行是当时的数字，下一行是这次用核心节点图重测的），蓝色是官方镜像，绿色是本文最后做出来的自建版。

快 1.66 倍。 720p 那档也是同一个方向：282 秒对 182 秒，快 1.55 倍。

这个结果让我不舒服的地方在于版本号。官方镜像里的 ComfyUI 是 0.31.0，torch 是 2.11；我们的是 0.34、torch 2.13——我们的更新。更新的反而慢了四成，不合直觉。

我先做了一件排除法：把我们的 ComfyUI 再往上升 40 个提交到当天的 master，什么都不装，重测。99.5 秒。一秒没变。 版本不是变量。

「更新」和「更快」是两件事。上游更新的是功能，Intel 显卡上跑得快不快，取决于另一层东西。

02我怀疑它偷步，扫了一遍步数

投机的解释最省事：官方在采样上动了手脚，少跑几步，或者用缓存跳过一些层。如果是这样，耗时对步数就不会是直线——少跑的步数不随你设的步数涨。

于是两边各跑 2 步、6 步、12 步：

每条线的斜率是「每一步多花多少秒」，截距是「不管几步都要花的固定开销」。灰色旧栈在 6 步之后拐了个弯，蓝色官方是一条直线，绿色自建版把弯拉直了。

官方是一条直线：固定开销 17.2 秒，每步 7.12 秒；拿这两个数回代 6 步，预测 59.9 秒，实测 60.2 秒，误差 0.5%。跳步做不出这么老实的线。

更有意思的是斜率。用 2 到 6 步这一段算：官方每步 7.20 秒，我们每步 6.28 秒——官方每一步反而慢 15%。 它赢的全是截距：固定开销我们 62 秒，官方 17 秒，差了 45 秒。这 45 秒是 32B 文本编码器的前向、两个 VAE 的解码、权重在显存里的搬运——不在采样循环里的那些活。

顺带看见我们自己的一个问题：旧栈的线在 6 步之后拐弯，每步成本从 6.28 秒跳到 13.8 秒，12 步跑两次都复现。生产上我们正好用 6 步，等于一直贴着拐点跑。原因当时没查出来——不过后面它自己消失了。

一个数只要跟另一个数对不上，就别急着发。「官方偷步」这个解释省事，但它过不了步数扫描这一关。

03拆到底：72% 的差距来自一个我们没有的目录

官方镜像的加速分三层：一个原生 XPU 内核库（omni_xpu_kernel），一个给 comfy-kitchen 加的 XPU 后端，一个 ComfyUI 自定义节点（ComfyUI-OmniXPU）负责把注意力、归一化这些调用点接到内核上。最后这层是看得见的，而且有开关，可以逐项关掉再计时：

同一台机器、同一份图，只改环境变量。attention 适配值 6 秒，norm 适配值 5.3 秒，加起来 28%。剩下 72% 不在这个节点里。

关掉整个自定义节点，官方还要 71 秒，依然比我们快 1.40 倍。大头在别处。

后面自建版做出来之后，我又从另一头量了一次：内核和自定义节点都留着，只关掉 comfy-kitchen 的 XPU 后端——从 58.5 秒退到 93.4 秒。这一层单独值 35 秒。

comfy-kitchen 是 ComfyUI 官方的算子库，上游发布，ComfyUI 核心到处在用它。我把两边的安装目录并排一看：

左：我们机器上从 PyPI 装的 0.2.31，版本更新。右：官方镜像里的 0.2.28，是 Intel 维护的分支。多出来的那个 xpu/ 目录就是 72% 的去处。

我们的 comfy-kitchen 版本更新，但它没有 xpu 后端。 在 Intel 显卡上，它把 INT8 线性层、ConvRot、AdaLN、RoPE 这些算子全部落回通用的 eager 实现。官方分支多出来的那个目录里有 39 个 capability，其中 INT8 线性和 ConvRot 正是我们那个 32B 文本编码器走的路——文件名就叫 qwen3vl_32b_minimax_h3_int8_convrot。文本编码在固定开销里，不在采样循环里。这和步数扫描量出来的形状严丝合缝：差距在截距，不在斜率。

还有一件事得说清楚，免得读者以为官方镜像里藏着什么魔法。它确实带了一个「跳块换速度」的节点（CacheDiT 的 H3 优化器，前 8 个 block 永远算、后面按残差阈值决定跳不跳），但那是要手动接进工作流的，我们两边都没用。官方模板里带 api_ 前缀的那几个 H3 工作流，用的是调 MiniMax 云端 API 的节点，跟本地推理无关。

快的原因往往不在你盯着的那层。看得见的自定义节点只值 28%，看不见的库后端值 72%。

04把它编进我们自己的最新版

知道了差在哪，下一步自然是：能不能把这三层东西搬到我们的 ComfyUI 上，既要最新的上游功能，又要 Intel 的算子。

官方轮子不能直接用。它钉死 torch==2.11.0，二进制是 Python 3.12 的；我们是 Python 3.13、torch 2.13。打包层的白名单只认 torch 2.10 到 2.12，构建文档明写「2.13 尚未包含在已验证范围内」。所以得自己编。

编译本身两分多钟，找到怎么编花了几个小时。坑全是同一个性质——版本必须同代：

• 运行库：torch 2.13 自带的 Intel 运行时是 2026.0.0（libsycl.so.9），官方镜像里的编译器是 2025.3（libsycl.so.8）。镜像的环境变量把老的排在前面，import torch 直接报未定义符号。修法是在 source setvars.sh之后再把 venv 的库目录压到最前。
• 编译器：镜像只配了 Intel 的 GPU 仓库，锁在 2025.3.3。加上完整的 oneAPI 仓库才装到 2026.0 的 icpx，和 torch 的运行时同代。
• oneDNN：轮子默认拉 2025.3.0，它的 libdnnl 链的是 libsycl.so.8，装好一跑就找不到库；换 2026.0.0 之后构建脚本又拒绝——setup.py 里把 oneDNN 版本钉死成 3.9.1。改成环境变量驱动。
• 一个老坑：脚本里写了 set -u，Intel 的 setvars.sh 引用了未定义变量，直接自杀。这条我们六月的部署记录里就写着，我照抄旧脚本又踩了一次。

然后是并行。官方的构建脚本把所有源文件塞进一次icpx 调用，机器 32 个核只用 1 个，6 分钟还在编第一个扩展。我在 setup.py 里加了一段：逐文件 -c 并行编译再链接，编译参数一个不改，三个扩展并发：

同一台机器、同一份源码。串行那根条是被我停掉时的时间，不是完成时间。

整包 2 分 21 秒。

内核编好了，comfy-kitchen 又来了一道：Intel 的分支停在 0.2.28，我们的最新 ComfyUI 要 0.2.31 的 API，装上分支直接崩溃循环。把分支相对上游 0.2.28 的改动摘出来——10 个补丁、13 个新增文件——全部干净打到 0.2.31 上，xpu 后端起来，39 个 capability，和官方镜像自检时一个数。

最后一个坑在自定义节点里。装上一跑，日志里有一条回退：H3 VideoVAE 那条专用的 CUTE 路由没走，落回了 PyTorch。内核明明导出了那个算子，问题在适配层：

官方只在 torch 2.11 上验证过这几条 CUTE 路由，于是把版本号硬钉在代码里，五处。我们的内核是对着 2.13 编的，把钉子改成集合判定，路由就通了。

「官方没验证」和「跑不了」是两回事。这次遇到的所有钉子——torch 版本、oneDNN 版本、适配层里的 == (2, 11)——都是验证范围的边界，不是技术的边界。

05三方对比：自建版追平并略超

同一张卡、同一份图、同一批种子，三套栈的成绩：

自建版的优势有三条，都不是「快几秒」这种：

第一，它是最新的 ComfyUI。 官方镜像停在 0.31，我们跑的是 9 月 5 日的 master，多出来的 54 个提交里有新模板、新节点、新的 API——而且以后上游再更新，git pull 就行，不用等 Intel 重新出镜像。

第二，它把旧栈的拐点抹平了。 旧栈在 6 步之后每步成本翻倍的那个毛病，自建版上没有了：2 步到 12 步一条直线，7.08 秒一步，截距 16.4 秒，两个数都比官方还低一点。

第三，一套环境跑所有活。 官方镜像和我们的 ComfyUI 不能同时跑——都要 8188 端口，都要整张卡。用官方镜像意味着出视频切过去、配音超分切回来。自建版不用切。

画面也核对过：同一个种子，三套栈抽同一帧并排看，构图、光线、毛发细节一个档次；自建版和旧栈几乎逐像素一致，因为它们的 torch 数值是同一套。

顺带把另外两个模型也在自建版上重测了一遍，八月那篇里有 Music 3 的数字可以直接对：

出歌这一档的提升比出视频还大——八月那篇里我写过，Music 3 出歌时要一个音符一个音符往外吐，每吐一个都要把结果从显卡搬回内存，而那段循环里的快路径当时只对 CUDA 开放。现在这条路上的算子有了 XPU 实现，六分零七秒变成了一分半。

还有一个官方镜像自带、我们两边此前都没开的加速器——CacheDiT 的 H3 优化器，它按残差差异跳过一部分计算块。在自建版上顺手量了一下（704×1280，跳过率 66.7%）：

片子越长越划算，15 秒这档直接砍掉一半。但它会影响画质——同种子抽帧比对，跳过率拉到 66.7% 时画面出现亮斑、细节发糊。要用得自己在速度和画质之间找那个阈值，我们没有把它接进生产。

官方镜像值得感谢——没有它我不会知道差在哪。但它给的是一个答案，不是一个环境。答案可以搬，环境得自己搭。

06那你到底该装哪个？我们的建议是：官方 Docker

前面把自建版夸了一路，结论却要往回收一步：如果你现在要在 B70 上部署 ComfyUI，我们建议用官方的 intel/llm-scaler-omni 镜像。

理由很简单——自建版还没有经过长时间的稳定性验证。

上面所有数字都是台架数据：同一份工作流、同一批种子、跑几十次、量到秒。台架跑得漂亮，和一台机器连续几周替你出片，是两回事。八月那篇里我写过，B70 那台机器当时已经连续运行三天二十一小时、整片的配音和逐帧人脸追踪都在它身上跑完没崩过——那种数据现在的自建版一条都还没有。它是今天下午才编出来的东西，中间还改过官方的构建脚本、嫁接过一个上游库、解掉了五处版本判断。每一处我都验证了当下的正确性，但没有一处经受过时间。

官方镜像的价值恰恰在这里：它是 Intel 自己 CI 过、自己发出来的一整套东西，版本互相咬合，出了问题有地方问。少的那 2% 速度，换的是这个。

我们会继续用自建版跑生产——因为我们需要最新的 ComfyUI，也因为出了问题我们自己修得动。等它在真实的出片流程里连续跑够时间、拿到和八月那台一样的稳定性记录，我们会把整套东西（补丁、构建脚本、嫁接方案）放到 GitHub 上供大家使用。在那之前，这篇里的编译过程当作原理解释看就好，不建议照着往生产机上搬。

一个能跑出漂亮数字的环境，和一个能托付工期的环境，中间隔着的是时间，不是技术。

07几条带走的认识

先说清这份成绩的天花板。 这张卡是 Intel 自家板卡，功耗上限 230 W，出视频的时候实测就是 230.0 W，一分不剩地贴在墙上。Intel 给板卡伙伴的区间是 160 到 290 W，铭瑄的 B70 32G Turbo 官网规格就是 290 W。本文所有数字代表的是一张 230 W 的 B70，不代表这颗芯片的上限。

看到「官方版本更快」，先拆层，别先猜。 我第一反应是「它偷步了」，第二反应是「我们的版本旧了」，两个都错。步数扫描否掉第一个，升级 40 个提交否掉第二个，逐项关开关才找到 72% 在哪。

版本同代比版本最新重要。 这次编译遇到的每一个坑——运行库、编译器、oneDNN、适配层的钉子——都是「两个组件不同代」。torch 2.13 配 2026.0 的编译器和 2026.0 的 oneDNN，一路绿灯；混一个 2025.3 进来，哪一层都能炸。

八月那篇的一条结论要改。 「要出 720p 以上的长片，别用这块卡」——那是旧栈的结论。官方镜像把 15 秒 720p 从「71 分钟没跑完」做到了 19 分 57 秒出片，自建版 19 分 33 秒。它还是慢，但从「工期变一周」退回到了「等一顿饭」。

下一篇讲那套调度脚本：短活走 B70、长活走 5090，按输入自动分流——现在 B70 这边的账单便宜了四成，分界线要重新画。关注着，可以期待。

我是把大模型搬进机房的桑雅。想我了就常来。

这次用到的东西

• 官方镜像：intel/llm-scaler-omni:0.2.0-b1（ComfyUI 0.31.0 / torch 2.11 / oneAPI 2025.3.3）· intel/llm-scaler
• Kitchen XPU 分支：xiangyuT/comfy-kitchen-xpu @ 575741da
• 自建版：ComfyUI acb2a019（v0.34.0-54）+ torch 2.13.0+xpu + 自编 omni_xpu_kernel 0.2.0b1+torch213.bmg（oneAPI 2026.0 编译器、onednn 2026.0.0）+ comfy-kitchen 0.2.31 嫁接 xpu 后端 + ComfyUI-OmniXPU（解掉五处 == (2, 11)）
• 上游 ComfyUI：comfyanonymous/ComfyUI
• 八月那篇：《为 Intel Arc Pro B70 正名》
• 补测模型：MiniMax Music 3（120 秒 · 30 步）、Breeze-TTS-2（节点与权重自 192.168.115.41 迁入）
• B70 功耗区间：ServeTheHome / StorageReview；铭瑄 Arc Pro B70 32G Turbo 官网页（290 W）