SGLang / vLLM / diffusers / ComfyUI：H3 四种跑法怎么选
截至 2026-08-09 的 MiniMax H3 官方仓库 README，在「Recommended Workflow」里列了四个推荐的推理框架：SGLang、vLLM、diffusers、ComfyUI。第一次看到这张表的人容易产生一个误解——以为这是四个功能等价的入口，随便挑一个装上就行。实际上它们的门槛差得很远，官方给出的信息密度也差得很远：有的给了可以直接抄的启动命令，有的只丢了一个文档链接。
我写这篇的时候没有下载过权重，没有部署过任何一个框架，也没有在 ComfyUI 里发起过一次生成。所以下面不会出现速度、显存、画质这类结论。能比的只有一件事：官方到底给了你多少东西，你要自己补多少。
先把「四种跑法」的真实结构看清楚
README 那张表长这样（入口路径原样引用）：
| 框架 | 官方给的入口 |
|---|---|
| SGLang | docs.sglang.io，cookbook 路径 /cookbook/diffusion/MiniMax/MiniMax-H3 |
| vLLM | github.com/vllm-project/vllm，recipes 路径 recipes.vllm.ai/MiniMaxAI/MiniMax-H3 |
| diffusers | github.com/huggingface/diffusers，文档在 minimax-h3 分支的 docs/source/en/api/pipelines/minimax_h3.md |
| ComfyUI | github.com/Comfy-Org/ComfyUI，教程 docs.comfy.org/tutorials/video/minimax/minimax-h3 |
这张表真正该读出来的信息是：前三个都在 MiniMax 自己的权重生态里，第四个不是。
MiniMax 官方托管在 Hugging Face MiniMaxAI/MiniMax-H3 的是原始 checkpoint，README 标明精度是 BF16，两个 checkpoint 分别对应 FL2VA（t2va / fl2va）与 Ref2VA（ref2va），发布的是 CFG-distilled 的 Omni Transformer 权重。而 ComfyUI 官方教程指向的是 huggingface.co/Comfy-Org/MiniMax-H3，文件名里带着 pruned_int8_convrot（扩散模型）与 nvfp4_awq（文本编码器）——这是量化/裁剪过的一套权重，跟 MiniMax 官方那套不是同一批文件。
这一点必须在选型的第一步就摆出来，因为它决定了一件很实际的事：**你在 ComfyUI 里看到的结果和别人用 SGLang 按 README 跑出来的结果，不要直接混着评估。**至于两者具体差多少、量化损失多大，官方两边都没有给出任何对比数据，本文不做任何猜测，也不给百分比。
四个入口，官方各给了多少
SGLang：唯一有完整启动命令的
README 里直接给了可以照抄的服务启动命令。FL2VA：
sglang serve \
--model-path MiniMaxAI/MiniMax-H3 \
--num-gpus 4 \
--ulysses-degree 4 \
--performance-mode speed \
--host 0.0.0.0 \
--port 30010 \
--model-variant fl2va
Ref2VA 是另一条几乎一样的命令，区别在 --model-variant ref2va 与 --port 30011。
这里有两条要读懂的：第一，两个变体是分别起服务、分别占端口的。想同时对外提供 t2va/fl2va 和 ref2va 能力，就是两个服务实例，不是一个进程加个开关。第二，示例里 --num-gpus 4 与 --ulysses-degree 4 相等，且 README 只是给了一个 4 GPU 配置的示例，并没有说这是最低要求。所以正确的复述是「官方示例使用 4 GPU 配置」，而不是把它读成一条硬性的最低 GPU 数量要求。至于 --ulysses-degree 究竟是什么、改成别的值会怎样，README 没有解释，我也不编——要展开只能去 SGLang 的 MiniMax-H3 部署指南看。
权重下载 README 也给了原样命令：
# Original checkpoint, both task families (SGLang, vLLM):
hf download MiniMaxAI/MiniMax-H3 --include "model_index.json" "FL2VA/*" "Ref2VA/*" --local-dir MiniMax-H3
# Or a single task family:
hf download MiniMaxAI/MiniMax-H3 --include "model_index.json" "FL2VA/*" --local-dir MiniMax-H3
--include 不是可有可无的讲究。仓库把原始 checkpoint（FL2VA/、Ref2VA/）和 diffusers 格式并排托管在同一个 repo 里，不加限定直接全量拉，会把两套格式一起拖下来；tokenizer 那几个文件（tokenizer.json、vocab.json、merges.txt）在两套格式里就是重复出现的。只做首尾帧和文生视频的人，只下 FL2VA/* 就够了。
vLLM：只给了 recipes 链接
README 对 vLLM 给的就是仓库地址加一个 recipes 路径。我没有取过这个 recipe 页面的正文，所以这篇不会展开 vLLM 的启动参数——编一条「差不多的命令」出来是这类文章最容易骗人的地方。这里能说的只有：vLLM 与 SGLang 同属「用原始 checkpoint 起服务」这一类，权重下载走上面那条带 --include "FL2VA/*" "Ref2VA/*" 的命令。要不要选它，取决于你团队现有的推理栈里已经站着谁。
diffusers：门槛在「装哪个 diffusers」
diffusers 路线的特别之处是你不用手动下权重。README 说 ModularPipeline.from_pretrained("MiniMaxAI/MiniMax-H3") 会精确拉取它所需的组件。听起来最省事，但有个坑写在仓库的 requirements.txt 注释里：
约束是 diffusers>=0.32.2，但官方文档引用的是 diffusers 的 minimax-h3 分支，注释里给的安装方式是：
pip install "git+https://github.com/huggingface/diffusers.git@minimax-h3"
并明说等它落到 PyPI 之后再收紧版本上界。换句话说，**直接 pip install diffusers 装 PyPI 上的版本，可能根本没有 H3 的模型类。**这条我可以放心讲，因为依据就是官方 requirements.txt 的注释本身。同一份文件还写明：模型是作为 Hugging Face diffusers pipeline 发布的，通过 trust_remote_code=True 使用；accelerate>=0.34.0 用于 33B Omni-Transformer 与 visual VAE 的 device_map / 多 GPU 加载；soundfile>=0.12.0 是官方推荐的写出方式，因为音频 VAE 返回的是 32 kHz 立体声张量。
所以 diffusers 的真实门槛不是「会不会写 pipeline 代码」，而是你的环境允不允许从 git 分支装依赖。企业内网只有私有 PyPI 镜像、CI 里锁死了 requirements 哈希的团队，这一步就会卡住。
ComfyUI：唯一有图形界面和现成模板的
ComfyUI 是四条路里唯一不用写代码的。官方教程页写明需要 ComfyUI 0.30.0 或更高版本（v0.30.0 发布于 2026-08-03），关联 PR 是 ComfyUI#15224；紧接着的 v0.31.0（2026-08-08）release notes 里有一条 fix(minimax): cast raw parameters to input device in H3 VAEs（PR #15268）——H3 支持刚落地就修了 VAE 的一个设备转换问题，所以要跑建议至少到 v0.31.0。模板说明里还有一条容易忽略的提醒：Desktop 与 Cloud 跟随 stable 发布，某些 nightly 才支持的模型可能还不可用。
模型文件要自己放到位（来自 Comfy-Org/MiniMax-H3）：
| 类别 | 文件名 | 放置目录 |
|---|---|---|
| diffusion_models（t2v/i2v） | minimax_h3_fl2va_pruned_int8_convrot.safetensors | ComfyUI/models/diffusion_models/ |
| diffusion_models（r2v） | minimax_h3_ref2va_pruned_int8_convrot.safetensors | ComfyUI/models/diffusion_models/ |
| text_encoders | qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors | ComfyUI/models/text_encoders/ |
| vae（视频） | minimax_h3_video_vae_fp16.safetensors | ComfyUI/models/vae/ |
| vae（音频） | minimax_h3_audio_vae_fp32.safetensors | ComfyUI/models/vae/ |
注意 fl2va 与 ref2va 在 ComfyUI 侧是两个独立的扩散模型文件，模板说明原文强调 ref2va 用的是与 t2v/i2v 模板不同的一套权重。两类任务都要做，两个文件都得下。官方提供 T2V、I2V、R2V 三个模板，JSON 在 Comfy-Org/workflow_templates 仓库（templates/video_minimax_h3_t2v.json、templates/video_minimax_h3_r2v.json）。
模板里有几个值得先知道的默认值：采样器 res_multistep，BasicScheduler 的 scheduler 是 simple、steps 20；而官方模板说明自己就写了，对参考密集的提示词，beta 或 normal 调度器往往比默认的 simple 表现更好——默认值和官方建议不一致，这种地方不看说明就会一直用着次优配置。ResolutionSelector 默认 megapixels 是 0.4（对应 864×480），而教程页推荐的是 1.0。
有一件事四条路都一样
不管你走哪条，拿到的都只是 H3-Base，也就是产出 768p 的那一层。README 把整个系统拆成三个模块：H3-Context-IR 负责把复杂的多模态输入精炼成 Context Intermediate Representation，H3-Base 负责生成，H3-Regenerate-2K 负责把 768p 结果连同原始上下文送回去重新生成 2K。开源发布的只有中间的 H3-Base：Context-IR 未包含在本次开源发布中，Regenerate-2K 官方原话是「Due to the complexity of the system, this module is not yet open-sourced」，两者都只提供 API。
而 README 对 Context-IR 有一句很重的话：它对最终输出质量至关重要，强烈建议要么把它接进你的生成流水线，要么照「Prompting Guidance」自建一套上下文处理系统。
这意味着两件事。第一，要 2K 就必须联网调官方 API，本地四条路都到不了，ComfyUI 模板里也没有这个模块，别把 ResolutionSelector 表里 2.0 那一档误读成「支持 2K」。第二，如果你打算全程离线，那你要补的不只是部署，还有一套自己的提示词前处理——官方给了 Prompting Guidance，但活是你干。顺带一提，走官方 API 这条路还意味着提交的文本、图像、视频以及增强后的提示词都会过自动审核，README 也坦承行业标准的过滤措施无法消除误判与漏判；纯本地部署没有这一层。这是合规敏感场景需要提前想清楚的差别。
关于速度：这一点官方没给数据，本文不比
四个框架谁快、谁省资源、谁的吞吐高——MiniMax README 没有给任何性能数字，ComfyUI 教程页也没有给模型体积和显存要求，我自己也没有跑过。所以本文不比速度、不比显存、不比画质，任何看起来像结论的数字都不会出现在这里。
唯一沾边的官方表述是 ComfyUI 教程页提到 Patch Sage Attention KJ 为可选优化，官方教程称可加速约两倍，需单独安装依赖，并注明可能看到 “using pytorch attention instead” 之类的消息属于正常现象。这是教程页的说法，不是我们验证过的结论，也不能拿去跨框架比较。
决策路径
与其记四张参数表，不如按自己的处境往下走：
第一问：你需要图形界面吗？ 需要点着调、需要看到节点连线、需要把工作流存成 JSON 给同事复用——直接选 ComfyUI，它是四条里唯一有官方模板和界面的。需要同时记住的是：你用的是 Comfy-Org/MiniMax-H3 那套 pruned_int8_convrot / nvfp4_awq 权重，和 README 口径的 BF16 原始 checkpoint 不是同一批文件，两边的结果别混着评估——至于孰优孰劣，官方双方都没给数据，本文不下判断。
第二问：不需要界面，那你要不要把它接进服务？ 要对外提供 HTTP 接口、要多路并发、要被别的系统调用——往 SGLang / vLLM 这一支走。其中 SGLang 是唯一有官方原样启动命令的，--model-variant 与端口分离的服务形态也写得很明白；vLLM 官方只给了 recipes 链接，正文我没读，选它意味着你要自己啃那份 recipe。
第三问：只想在脚本里调一下、不想起服务？ 那是 diffusers 的场景，而且不用手动下权重。但先回答第四问。
第四问：你的环境能从 git 分支装依赖吗？ 不能，diffusers 这条基本就断了——官方文档指的是 minimax-h3 分支，PyPI 版本未必带 H3 的模型类。这时候要么退回 SGLang/vLLM 走原始 checkpoint，要么退到 ComfyUI。
第五问：要不要 2K？ 要，就必须接受调官方 H3-Regenerate-2K API，也就必须能联网、必须有 token（正文里一律写 <token>，别把真 token 写进任何配置文件或截图）。README 的 Full 2K Workflow 就是把本地 SGLang 服务与官方 Context-IR、Regenerate-2K API 组合起来的。补一句 README 自己的提醒：示例里把本地输出编码成 Base64 Data URL，但生产场景推荐把视频传到公开可访问的 URL 再作为 base_video 传入。
第六问：合规怎么算？ 走官方 API 的那部分会过自动审核；纯本地不会。至于能不能商用、二次分发怎么算，License 全称是「MiniMax H3 Community License Agreement」，我没读过正文，一律以官方 LICENSE 原文为准，这篇不做任何解读。
条件式的结论
- 如果你要的是尽快看到一个能跑的工作流、且清楚自己跑的是 ComfyUI 那套量化权重，ComfyUI 是门槛最低的一条，前提是版本至少到 v0.31.0，五个模型文件按目录放对，并且知道模板默认的
simple调度器与 megapixels0.4都不是官方建议的最优值。 - 如果你要的是对外服务形态、且照官方口径用 BF16 原始 checkpoint，SGLang 是官方给料最全的一条；记得 fl2va 与 ref2va 是两个服务实例，也记得那条 4 GPU 命令只是官方示例。
- 如果你要的是在自己的 Python 代码里调，diffusers 最省心，但先确认你的环境装得上
minimax-h3分支。 - 如果你的团队已经在跑 vLLM，那顺着已有栈走是合理的，只是得自己去读 recipes，这篇给不了更多。
- 无论哪条，只要目标是复现官方那种 2K 效果，就绕不开未开源的 Context-IR 与 Regenerate-2K，也就绕不开联网调 API。想全离线，就要接受 768p，并自建提示词前处理。
这些结论都带前提，因为在没有性能数据、没有本机部署的前提下，任何「就选它」的断言都是编的。
延伸阅读
本文依据 MiniMax H3 官方仓库（github.com/MiniMax-AI/MiniMax-H3）的 README、模型配置文件与仓库 requirements.txt 整理，核对日 2026-08-09。本文内容为官方仓库口径，未在本机部署或调用过 H3。ComfyUI 侧依据 ComfyUI 官方仓库（github.com/Comfy-Org/ComfyUI）的 README 与 release notes 整理，对应版本 v0.31.0；ComfyUI 侧的模型文件与工作流信息来自 docs.comfy.org 的官方教程与 Comfy-Org/workflow_templates 仓库的模板文件。本文非本机实测，参数、默认值与功能随版本变动，请以官方文档与实际输出为准。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。