ComfyUIの新アテンション実装「Comfy Kitchen」int8量子化で計算する専用カーネル群が起動オプション1つで切り替わる

【更新 2026年9月25日】 本記事は2026年8月29日時点の確認で公開しました。2026年9月25日にPyPIとComfyUI公式GitHubを開き直し、3点を確認しています。(1) comfy-kitchenは0.2.31→0.2.35に更新されており（PyPIへの登録は2026年9月17日、ComfyUI本体は同年9月21日公開のv0.37.0でこのバージョンを指定）、int8_attentionのバックエンド対応表（CUDA・HIPのみ対応、eager・Tritonは非対応）自体は変わっていません。(2) 本文で引用した--disable-triton-backendのヘルプ文にあった「the automatic ROCm/AMD default」（ROCm/AMDでの自動的な既定設定）という一節は、2026年9月15日公開のv0.36.0で削除されました。あわせて、本記事が対象としたv0.32.0のコードでも、ROCm環境でTritonを自動で有効にする条件はすでにコメントアウトされていたことを確認したため、本文の「AMD GPU環境ではTritonバックエンドが既定で使われる」という読みを訂正しました（詳細と一次ソースは本文の該当箇所に追記）。(3) v0.37.0には「Comfy Kitchen attention使用時に動画生成モデルWanのピークVRAM使用量を下げる」という変更も入っており、Comfy Kitchen attentionの経路が個別のモデル向けに調整され始めています（PR本文は空欄で、削減量の数値は示されていません）。本文にある「品質劣化の定量評価は確認できなかった」という限界は、9月25日に見直したPR本文とPyPIのREADME（0.2.35）の範囲でも変わっていません。

画像・動画生成のノードベースツール「ComfyUI」は、v0.32.0（2026年8月11日公開）で、モデル内部の計算方式（アテンション実装）を選べる新しい仕組みを追加した。GitHubのリリースノートには「Implement comfy kitchen attention.」という1行しかないが、実装したPRと、関連パッケージの公式説明を追うと、その正体は独立した量子化カーネルライブラリだと分かる。

3行まとめ

• ComfyUI v0.32.0の--use-ck-attentionは、comfy-kitchenという別パッケージのint8量子化アテンションカーネルを既定バックエンドに切り替える起動オプション
• PyPIのJSON API経由でREADME全文（約14,000字）を取得すると、開発元はgithub.com/Comfy-Org/comfy-kitchen──ComfyUI本体と同じ「Comfy-Org」組織──で、Apache-2.0ライセンス、バージョンは0.2.31（2026年8月29日確認）だった
• int8_attentionはCUDAとHIP（AMD）バックエンドのみに対応し、eager（通常のPyTorch実行）・Tritonには対応していない。バックエンド選択の優先順位はhip → cuda → triton → eagerの順

リリースノート1行の裏にある実装

この変更を実装したPR #15479（2026年8月11日マージ）の本文は、次の通り簡潔だ。

"Add a ModelAttentionBackend node to manually select the attention for models in the workflows. Currently supports pytorch attention or comfy kitchen attention." "Add --use-ck-attention to enable comfy kitchen attention as the default attention backend for all models (might break some)."

（ワークフロー内のモデルに対して、アテンション実装を手動で選択できるModelAttentionBackendノードを追加した。現時点ではPyTorchアテンションかComfy Kitchenアテンションのどちらかに対応している。すべてのモデルの既定アテンションバックエンドとしてComfy Kitchenアテンションを有効化する--use-ck-attentionも追加した（一部のモデルでは動作が壊れる可能性がある）)

つまり今回の変更は2段構えだ。ワークフロー単位でノードから選択できる方法と、起動時のコマンドラインオプションで全体の既定値を切り替える方法の両方が用意されている。「一部のモデルでは動作が壊れる可能性がある」という但し書きが、開発者自身によって明記されている点は正直な記載だ。

「Comfy Kitchen」の正体は別パッケージのint8量子化カーネル

実際にComfyUI本体のソースコード（comfy/ldm/modules/attention.py）を確認すると、この機能はcomfy_kitchenという別パッケージをインポートして使っていることが分かる。ソースコード中にはattention_comfy_kitchen_int8という関数名があり、int8（8ビット整数）量子化を使ったアテンション計算であることが読み取れる。

このパッケージ自体は、PyPI（Pythonパッケージのレジストリ）に「comfy-kitchen」として公開されている。公式の説明文はこうだ。

"Fast Kernel Library for ComfyUI with multiple compute backends" "# Comfy Kitchen Fast kernel library for Diffusion inference with multiple compute backends."

（ComfyUI向けの、複数の計算バックエンドに対応した高速カーネルライブラリ。Comfy Kitchen：複数の計算バックエンドに対応した、拡散モデル推論向けの高速カーネルライブラリ）

PyPIページに掲載されている「Backend Capabilities Matrix（バックエンド対応表）」を見ると、int8_attentionという関数は、eager（PyTorchの通常実行モード）とTritonには対応しておらず、CUDAとHIP（AMD GPU向け）のバックエンドでのみ実装されていることが確認できる。一方、quantize_per_tensor_fp8やadaln、na3d（Neighborhood Attention 3D）といった他のカーネルは、eager・CUDA・Triton・HIPのすべてに対応している。

開発元はComfyUI本体と同じ「Comfy-Org」組織

PyPIのJSON API（pypi.org/pypi/comfy-kitchen/json）からパッケージのメタデータとREADME全文を取得すると、project_urlsのHomepageはgithub.com/Comfy-Org/comfy-kitchenだった。PR #15479が送られた先もComfy-Org/ComfyUIであり、両者は同じGitHub Organization配下にある。ライセンスはApache-2.0、確認時点（2026年8月29日）のパッケージバージョンは0.2.31。バージョン番号の低さからも、比較的新しく開発が進んでいるパッケージであることがうかがえる。

README全文（約14,000字）には、以下のようなカーネル関数の対応表（Backend Capabilities Matrix）も含まれていた。抜粋すると次の通りだ。

出典: PyPI JSON API経由で取得したcomfy-kitchenのREADME「Backend Capabilities Matrix」（2026年8月29日確認、全34関数中6件を抜粋）

READMEにはハードウェア要件も明記されており、fp8量子化テンソル（TensorCoreFP8Layout）はSM 8.9以上（NVIDIA Ada世代以降）、NVFP4・MXFP8はSM 10.0以上（Blackwell世代以降）のGPUを要求する。バックエンドの自動選択はhip → cuda → triton → eagerという優先順で行われ、入力が満たせないバックエンドはNoCapableBackendErrorという例外で明示的に弾かれる（try/exceptによる暗黙のフォールバックはしない、とREADMEに明記されている）設計だという。

--enable-triton-backendという関連オプションも存在する

ComfyUI本体のコマンドライン引数を確認すると、Comfy Kitchenに関連する別のオプションも見つかった。

"--enable-triton-backend: ComfyUI will enable the use of Triton backend in comfy-kitchen. Is disabled at launch by default." "--disable-triton-backend: Force-disable the comfy-kitchen Triton backend, overriding the automatic ROCm/AMD default and --enable-triton-backend."

（--enable-triton-backend：comfy-kitchen内でのTritonバックエンドの使用を有効化する。起動時は既定で無効。--disable-triton-backend：comfy-kitchenのTritonバックエンドを強制的に無効化し、自動的なROCm/AMDの既定設定と--enable-triton-backendの両方を上書きする)

「ROCm/AMDでは自動的にTritonバックエンドが選ばれる」という記述から、AMD GPU環境ではTritonバックエンドが既定で使われる設計になっていることがうかがえる。int8_attention自体はTritonに対応していないため、この--enable-triton-backendオプションはComfy Kitchen内の他のカーネル（adalnやna3dなど）に影響するオプションだと考えられる。

（2026年9月25日追記） 上で引用した--disable-triton-backendのヘルプ文は2026年8月29日時点のものだった。2026年9月25日にComfyUI公式GitHub（v0.37.0時点のcomfy/cli_args.py）を確認すると、文言は「Force-disable the comfy-kitchen Triton backend, overriding --enable-triton-backend.」に変わっており、「the automatic ROCm/AMD default and」の部分が削除されている。変更元のPR「quant_ops: drop the dead ROCm triton arch gate」（2026年9月9日マージ、v0.36.0に収録）は、GitHubユーザーの0xDELUXA氏が送り、ComfyUIのメンテナー（comfyanonymous）がマージしたものだ。PR本文はこう説明している。

"comfy-kitchen now ships a self-registering HIP backend for ROCm." "This makes the ROCm logic in quant_ops.py outdated: Triton is no longer the only accelerated ROCm backend, and _rocm_kitchen_arch_supported() is dead code. The helper and misleading comments/help text can be removed, while simplifying the gating to the actual flag states."

（comfy-kitchenは、ROCm向けに自分で登録されるHIPバックエンドを同梱するようになった。これによりquant_ops.py内のROCm向けロジックは古くなった。TritonはもはやROCmで唯一の高速バックエンドではなく、_rocm_kitchen_arch_supported()は使われていないコード（dead code）だ。この補助関数と、誤解を招くコメント・ヘルプ文は削除でき、有効化の判定も実際のフラグの状態だけに単純化できる）

さらに、本記事が対象としたv0.32.0のcomfy/quant_ops.pyを今回あらためて読むと、ROCm環境でTritonを自動で有効にする条件（torch.version.hip is not None and _rocm_kitchen_arch_supported()）はその時点ですでにコメントアウトされており、--enable-triton-backendを付けない限りTritonバックエンドは無効化される実装だった。つまり上の段落の「AMD GPU環境ではTritonバックエンドが既定で使われる設計になっていることがうかがえる」という読みは、ヘルプ文の文言とは合っていたが、当時の実際のコードの動作とは合っていなかった（frontmatterの訂正欄にも記録した）。なお、同PR本文には「Tested all four flag combinations on a ROCm build with comfy-kitchen 0.2.33: dispatch priority stays ['hip', 'cuda', 'triton', 'eager'], with Triton disabled unless explicitly enabled.」（comfy-kitchen 0.2.33を使ったROCmビルドでフラグの4通りの組み合わせをすべて試したところ、ディスパッチの優先順位は['hip', 'cuda', 'triton', 'eager']のままで、Tritonは明示的に有効化しない限り無効だった）とあり、この変更でバックエンド選択の挙動は変わっていないと説明されている。

なぜ量子化アテンションが必要なのか

拡散モデル（画像・動画生成モデル）の推論では、attention計算がGPUメモリと計算時間の両方で大きな比重を占める。int8のような低ビット精度で計算することで、メモリ使用量を減らし、計算速度を上げられる可能性がある一方、精度の低下によって生成結果の品質に影響が出るリスクもある。今回のリリースでは、同じv0.32.0にMiniMax-H3（動画生成モデル）のVAE最適化（PR「Optimize MiniMax-H3 VAE」）も含まれており、動画生成のような計算負荷の重いワークロードへの対応強化が、このリリース全体のテーマの1つだったとみられる。同じ2026年8月11日には、Lightricksが動画生成モデルLTX-2.5をオープンウェイトで公開しており、ローカルで動かす動画生成モデルの選択肢もこの時期に増えている。

（2026年9月25日追記） その後、Comfy Kitchen attentionの経路を個別のモデル向けに調整する変更も入った。2026年9月20日にマージされたPR「Lower wan peak vram when using comfy kitchen attention.」（v0.37.0に収録）は、タイトルどおりComfy Kitchen attention使用時の動画生成モデルWanのピークVRAM使用量を下げる変更だ。PR本文は空欄で、どれだけ減ったかの数値は示されていない。コード差分（comfy/ldm/wan/model.py）を読む限り、Wanのアテンション呼び出しでq・k・vをAttentionTensorContainerという入れ物に包んで渡すようにしたもので、Comfy Kitchen側の処理（comfy/ldm/modules/attention.py）はこれを受け取るとint8に量子化した時点で元のテンソルを手放す作りになっている。比べているのは「変更前と変更後のComfy Kitchen attention」であり、PyTorchアテンションと比べてVRAMが減ることを示したものではない。また、下の「品質劣化の定量評価」とも別の話だ。拡散モデルの計算コストを削る取り組みはComfyUI本体の外でも進んでおり、拡散モデルの強化学習「DiffusionOPSD」という論文は、比較対象のDiffusionNFTに対して学習のGPU時間をSD 3.5-Mで40%、Z-Image-Turboで63%削ったと報告している（推論ではなく学習の話で、論文の表ではピークVRAMは比較対象より増えている）。

GPUの種類で最適解が変わる複雑さ

筆者は自宅の環境でComfyUIを使って画像生成を試したことがあるが、アテンション実装の違いを意識して切り替えたことはなかった。今回、comfy_kitchenというパッケージが独立したPyPIパッケージとして存在し、CUDA・Triton・HIPという複数のバックエンドを想定して設計されていることを確認して、ComfyUI本体とは別に、推論カーネルの最適化だけを専門に扱うレイヤーが育ちつつあることを認識した。ローカルで画像・動画生成AIを動かす際、GPUの種類（NVIDIA/AMD）によって最適な設定が変わってくる、という複雑さが、この手のオプションの多さからも見て取れる。ComfyUIはノードベースの自由度の高さが売りだが、その分バックエンド選択のような設定項目も増える。自分のGPUを使わずにInference ProvidersとSpacesへ推論を投げる「Workflow1111」のような、GPU管理そのものを手放す別アプローチも同時期に出てきている。

限られたVRAMに合わせてモデル側を細かく最適化する動きは、LLM側でも進んでいる。量子化ツール「shoehorn」は、プリセットの量子化刻みを使わず、今使える実メモリ量から逆算してテンソルごとに精度を割り当てる設計で、公式サイトの実行例ではメモリ使用率99.998%まで詰め込んだ数字が示されている。Comfy Kitchenのバックエンドごとの対応表（CUDA・HIP・Triton・eagerの組み合わせ）と、shoehornのテンソル単位の精度割り当ては層が違うが、「ハードウェアの制約から逆算して計算方式を変える」という方向性は共通している。

品質劣化の定量評価は確認できなかった

comfy-kitchenの開発元がComfyUI本体と同じ「Comfy-Org」組織であることはPyPIのメタデータから確認できたが、int8量子化によって生成画像・動画の品質にどの程度の劣化が生じるか（あるいは生じないか）についての定量評価は、今回参照したPR本文にもPyPIのREADMEにも記載がなかった。「一部のモデルでは動作が壊れる可能性がある」という記載についても、具体的にどのモデル・どのような壊れ方をするのかという詳細は確認できていない。README内の「Constraint System」の説明によれば、対応できない入力はNoCapableBackendErrorという例外を出す設計だとあるが、--use-ck-attention使用時にComfyUI側がこの例外をどう扱う（起動が止まるのか、警告を出して別バックエンドに回るのか）かは、ComfyUI本体側のコードまでは今回読み込んでおらず確認できていない。

関連記事

• Stable Diffusion ローカル導入ガイド【2026年版】
• ComfyUIで生成が止まる・エラーが出る時の切り分け手順──公式トラブルシューティングを読む
• ローカルLLMとは何か──自分のPCでAIを動かす仕組み・利点・始め方を解説