Basaltエンジン：Blackwell専用のQwen3.8-Flash-Next、設定に依存するスループット

Blackwell sm_120とCUDA 13に縛られた導入範囲

READMEによると、BasaltはStrataをフォークしてQwen3.8-Flash-Nextに絞ったローカル推論エンジンだ。要件はAVX2付きのLinux x86-64、compute capability 12.0のNVIDIA Blackwell GPU、CUDA 13である。

VRAMに収まらないエキスパート（MoEのサブネットワーク）はシステムRAMに置き、任意で2枚目のGPUをピアのエキスパート層として使う。

対象が狭いぶん実装を集中できる。ただし他のGPU世代やOSは、別のCUDA推論ソフトが動くというだけでは対象に含まれない。

モデルファイルに含まれないエンジン設定

READMEはエンジンの組み込み既定値を未調整だとしている。4096コンテキスト、fp16 KV、投機的デコードなし、エキスパートキャッシュなしで、モデルファイルはエンジンフラグを持たない。

設定は一つのbasalt_config.jsonにまとめて--configで渡し、優先順位はコマンドライン、設定ファイル、組み込み既定値の順だ。

モデルパックを取得して既定値で起動するだけでは、調整済みの結果を支える条件は再現されない。

--parallelスロットとKVキャッシュの割り当て

--parallel Nはエンジンのバッチスロットで1〜8件のリクエストを同時に処理し、--max-contextはスロット間で分け合う。--parallel 4 --max-context 262144なら、各スロットは65536トークンになる。

--slot-full-contextを指定すると全スロットが--max-context全体を受け取るが、KVキャッシュはN倍になる。スロットのKVキャッシュはエキスパートキャッシュから差し引かれる。

同時実行を増やすことは、リクエスト当たりのコンテキストかエキスパート用のメモリを手放すトレードオフになる。

精度ドキュメントが扱う試験範囲

精度ドキュメントの試験構成は、400W電力制限のRTX 5090 1枚と、ピアのエキスパート層用のRTX 5060 Tiだ。400Wは2枚のGPUの合計消費電力ではない。

エキスパート層を固定した状態で、275件のgreedyプロンプトすべてがMTPの有無にかかわらず同じトークンを出した。プロンプトは19〜395トークン、新規256トークンで、ドキュメント自身が長いコンテキストではなくデコード経路の試験だと述べている。

エキスパートがCPUとGPUの間を移動すると丸めが変わり得るとも記している。品質はllama.cppのQ8_0を基準に比較し、20チャンクではなく100チャンクの結果を比較の拠り所とする。

いずれもプロジェクト自身の試験であり、あらゆるコーディングや推論タスクで同じ結果を保証するものではない。

品質の受け入れとメモリ配置は別の試験

これらの条件は二つの受け入れ基準に分かれる。選んだ設定が想定する作業とプロンプト長で許容できる回答を出すか、そのメモリ配置が想定ユーザー数で必要な遅延を満たすかだ。

短い決定的な一致試験は実装変更の追跡に役立つが、ワークロード単位の確認の代わりにはならない。複数リクエストの合計スループットが上がっても、単一リクエストが早く終わるとは限らない。

実際の設定とスロットメモリを確かめる実行例

Blackwellワークステーションで試すなら、モデルパックのリビジョン、エンジンのビルド、設定ファイルを一組で残し、文章、構造化出力、同時サービスを別々に測る。READMEが記載する起動とメトリクス確認は次の形だ。

bin/basalt serve --config basalt_config.json --parallel 4 --max-context 262144
curl http://127.0.0.1:8080/metrics

READMEによると、サーバーは起動時にデバイスごとに[server] kv cache:の行を出力し、スロットがエキスパートキャッシュを過度に削ると警告を出す。/metricsはlive.slotsのtotal、active、queue_depthを報告する。

長い会話履歴に依存する作業なら、短いプロンプトの一致結果から外挿するより、その履歴自体で評価するほうが現実的だ。本記事のためにBasaltは実行していない。

Basaltのスループット値は、エンジン単体の速度ではなく、モデルパック、設定ファイル、スロットのメモリ配置を合わせた結果と読むのが正確だ。