RTX A6000 48GB単体でgpt-oss-120Bを推論するhotsetが公開
25秒でわかる内容解説
開発者KaiDong-coderが単一のRTX A6000と30GB RAMで117Bパラメータのgpt-oss-120Bモデルを動作させる推論エンジンhotsetを公開した。2026年10月22日にGitHubにアップロードされたこのプロジェクトは、VRAM不足をCPUメモリと高速カーネルで補う。ローカルPCで超大規模モデルを動かす新しい枠組みを示す。ホストメモリ帯域が速度上限を決定する点が特徴だ。
MXFP4カーネルとMoE配置で48GB GPUを最大化する
hotsetは117Bパラメータを持つgpt-oss-120Bモデルを、RTX A6000と30GBのRAMで実行する。評価環境ではi9-10900XとPCIe 3.0 x16スロットを用い、8kコンテキストで30.6 tok/sのデコード速度を記録した。プリフィルル処理は97.8 tok/sに達する。従来の推論では演算能力が問題視されがちだが、このモデルではメモリ帯域がボトルネックとなる。
各トークン生成ごとにCPU側メモリから専門家の重みをPCIe経由でGPUへ転送する仕組みだ。測定されたホストメモリ帯域は16.5 GB/sであり、これがデコード速度の理論上限を40.8 tok/sに制限している。エンジンは自動配置プランナーによって、VRAMの空き容量とCPUメモリの利用可能な量を精密に計算する。8つのMoEレイヤーをCPU側に残す構成で、VRAM使用量は47.7 GiBに達する。
メモリ配置の最適化が、単なるカーネルの高速化と同じくらい速度に直結する。32kコンテキストでq8_0量子化のKVキャッシュを用いれば24.9 tok/s、プリフィルルは179 tok/sに達する。f16をデフォルトとし、q8_0は32kコンテキストに収めるための妥協案として提供される。MXFP4形式のmul_mat_id（行列乗算を高速化する関数）カーネルがデコードとプリフィルルの両方で速度向上に貢献する。
| 構成条件 | 速度/使用量 |
|---|---|
| デコード速度 | 30.6 tok/s |
| プリフィルル速度 | 97.8 tok/s |
| VRAM使用量 | 47.7 GiB |
| CPU側レイヤー | 8個 |
ホストメモリ帯域が決定する速度の壁とルーティングの偏り
デコード速度の上限を押し上げる鍵は、データ転送の効率化にある。エンジンが実測で確保している帯域は12.4 GB/sであり、利用可能な16.5 GB/sの92％を消費している。 モデルの構造がこの可能性を許容している。128ある専門家のうち、上位14が各レイヤーで54％から68％のルーティングスロットを占める偏りが確認された。
A 117B model on one RTX A6000 is a memory-bandwidth problem, not a FLOP problem
単一のRTX A6000で動作する117Bモデルは、演算能力ではなくメモリ帯域の問題である。
均等なら10.9％である。この偏りを活用し、頻繁に呼ばれる専門家のセットを高速に読み込む設計が採用された。各トークンあたりの転送バイト数は ncmoe × 50.56 MiB で計算され、少ないバイト数で速度を稼げる構造になっている。CPU側のメモリ使用量はVRAMよりも重要な制約条件となる。
ncmoeパラメータを12に増やしてCPU側の専門家を19.4 GiBにすると、ページングが発生してディスク読み取りが122 GBに達する。その結果、デコード速度は21.8 tok/sまで低下した。30 GBのRAMが第一次制約となり、VRAMの空き容量よりもCPU側のメモリ管理が性能を支配する。
scripts/batch_union.pyが897トークンのルーティングダンプを再生し、50.3 tok/sと67.6 tok/sの投影値を導出している。
実測値と投影値を明確に区別するベンチマーク手法
hotsetは公開当初から、数値の根拠を明確に示す点を重視している。v0.1ではCPU保持型のMoE配置、MXFP4形式の高速カーネル、自動配置プランナー、ルーティングトレースツールが実装された。各数値はrawなベンチマーク出力ファイルと紐付けられており、再現性が担保されている。並列ストリームのテストでは、8kコンテキストで2ストリーム同時実行時の合計スループットが26.6 tok/sとなった。
単一ストリームの24.9 tok/sと比較して約8％の向上であり、連続バッチ処理はまだ実装されていない。開発者は共有GPU環境での利用も想定している。VRAMを他プロセスが占有している場合、hotsetは他のプロセスを強制終了させずに待機する。41.9 GiBを占有する別プロセスがいた環境でも、正常にスケジュールを実行する仕組みが備わる。
自前のプロセスではない他者のpidを殺したり優先度を下げたりせず、VRAMの予算が空くまで待つ。scripts/gpu_queue.pyが41.9 GiBの予算を必要とし、他プロセスの占有を待機する。tests/run_tests.pyがユニットテストとカーネルA/B検証を行う。これにより共有GPU環境での使用耐性が高まる。
v0.2で導入されるexpert cacheとPCIe世代の未計測性能
現在開発中のv0.2では、split-MoE GPU expert cacheの導入が予定されている。CPUとCUDAカーネルにマスクIDスキップ機能を実装し、2つのmul_mat_id演算に置き換える設計だ。これにより、同じ構成で50.3 tok/s、expert cacheを28-expertに拡張すれば67.6 tok/sのデコード速度が投影されている。
投影値は実際のトレースデータからバイトモデルで算出されたものであり、まだ実測されていない。
PCIe 3.0世代以降の環境での動作性能も測定されていない。現在の結果はPCIe 3.0の条件に限定される。moe_fit.pyスクリプトはGen 3より上位のPCIe世代ではop_offloadをautoに切り替えるが、その動作はまだ計測されていない。docs/SPLIT-MOE.mdにexpert cacheの設計図が記載され、masked-idスキップの実装が進められている。
単一GPUで120Bクラスのモデルを動作させたいPC愛好家にとって、メモリ帯域と配置アルゴリズムのバランスが性能を左右する具体的な指標が提示された。2026年10月22日に公開されたv0.1に続き、v0.2でexpert cacheが実装されれば性能上限がさらに明確になる。