ChimeraForge

Chimeraforge

ローカルファーストで、モデルに依存しないLLMデプロイ計画ツールです。「どのモデル、量子化、GPU、バックエンドを何台使えばよいか。メモリに収まるか、SLOを達成できるか、コストはいくらか」という疑問に、明確な根拠と前提を添えて、シェル、Python、AIアシスタントからすばやく回答します。

uvx chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB"

信頼性の原則

すべての数値には measured、extrapolated、derived、estimated、unknown のいずれかが付けられ、このツールは根拠を示せない数値を捏造しません。 VRAM と KV キャッシュは derived です。測定値ではなく、モデルの実際のアーキテクチャに基づく正確な計算値です。スループットは、コーパスの測定に使用したリグ上でのみ、測定値の検索結果として返されます。それ以外の GPU では、その行をメモリー帯域幅に基づいてスケーリングし、参照元の行、測定に使ったリグ、適用した比率を添えて extrapolated として報告します。たとえば、帯域幅を 17.8 倍にしても（RTX 4080 Laptop 432 GB/s -> B200 7700 GB/s）、お使いのカードの測定値にはなりません。それができない場合は、明示的なルーフライン estimate を示します。実際のデータではないものを、データであるかのように提示することはありません。付属コーパスに品質データがない場合は、架空のスコアではなく unknown と報告します。候補が 0 件の場合は、一般的な「見つかりませんでした」ではなく、すべての候補を除外した具体的な条件を示します。テレメトリーも、外部への情報送信もありません。エアギャップ環境でも動作します。

モデルを指定すると（サイズクラス、Hugging Face リポジトリ、Ollama タグ、または未リリースモデル向けの手動オーバーライド）、VRAM、品質、レイテンシー、コスト、エネルギー、およびオプトインの安全性ゲートに照らして、（モデル x 量子化 x バックエンド x GPU 数 x テンソル／パイプライン並列処理）の組み合わせを検索し、SLO を満たす最も安価な構成を返します。

25 個のコマンドを 1 つのツールで: plan - check - bundle - study - deploy - suggest - measure - workload - monitor - validate - doctor - contribute - catalog - safety - bench - trace - trace-campaign - score - gate - eval - compare - refit - report - mcp - serve。

経験的コーパスのデータは Technical Reports TR108-TR137 にさかのぼり、コンシューマー向け GPU での実測値が約 204,000 件含まれています。機能の全履歴については、CHANGELOG をご覧ください。

プランナーが実際に参照するデータ。 約 204,000 件という測定数は、研究プログラム全体のレポートにおける合計です。plan が数値を検索するテーブルは、はるかに小規模です。

テーブル	件数	構成
デコードスループット	23 行	FP16 のみ。7 モデル（最大は llama3.2-3b の 3.21B）。サービングエンジンでの測定が 9 行（ollama 3、tgi 3、vllm 3）、transformers の研究用ハーネスでの測定が 14 行。各行は 1 基の GPU で測定。GPU は RTX 4080 Laptop 12GB（192-bit GDDR6、432 GB/s）
量子化による高速化率	7 個の倍率	FP16 の行に適用。量子化後のスループットは、その量子化設定での測定値ではありません
品質	モデル x 量子化の組み合わせが 35 件	各 n=20 項目（TR125）
安全性	モデル x 量子化の組み合わせが 40 件	拒否率（TR134/TR142）
レイテンシーサービス時間	9 件	モデル x バックエンド
サードパーティー監査	17 基の GPU でスコア付けした 42 件	公開ベンチマーク（スコアカード）。公開済みの追加 26 件は、スコア付けするには詳細が不十分

これらの行に含まれないものはすべて、extrapolated（基準 GPU からメモリー帯域幅に基づいてスケーリング）、derived（正確な計算値）、または estimated（ルーフライン推定値）となり、プラン内のすべての数値にその区分が示されます。データには、次の制限も記録されています。

• スループットのすべての行は FP16 です。量子化後のスループットは、FP16 の行に量子化倍率を掛けたものであり、その量子化設定での測定値ではありません。
• すべての行は 1 基の GPU で測定されています。それ以外のハードウェアについては、帯域幅に基づく外挿を行い、「測定値」ではなく 'extrapolated' と表示します。
• 測定された最大のモデルは 3.21B です。それを超える予測にはべき法則の外挿を適用します。
• SGLang の行はありません。このバックエンドでは、fp16／べき法則の経路にフォールバックします。

---

インストール

インストールせずに試すには：

uvx chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB"
pipx run chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB"

実際にインストールするには：

pip install chimeraforge            # planner + model resolution (HF/Ollama) + suggest/measure/safety/bench
pip install "chimeraforge[bench]"     # + GPU environment metadata for benchmarks (pynvml)
pip install "chimeraforge[mcp]"       # + MCP server so Claude/GPT/Cursor can call the planner
pip install "chimeraforge[eval]"      # + quality evaluation (ROUGE-L; BERTScore additionally needs `bert-score` + torch)
pip install "chimeraforge[refit]"     # + coefficient refitting (numpy, scipy)
pip install "chimeraforge[all]"       # everything

Python 3.10 以降が必要です。コアのインストールには、プランナーとネットワークに接続するコマンドが含まれます（httpx はコア依存関係です）。レジストリのプランニングとローカルカタログはオフラインで動作します。HF/Ollama の解決または検出には、明示的なネットワークアクセスが必要です。bench／measure／safety には、実行中のバックエンドが必要です（Ollama、vLLM、TGI、SGLang。safety が対応するのは Ollama のみです）。Windows／macOS／Linux に対応しています。

リリース範囲（2026-10-17）。 Chimeraforge 0.66.0 では、固定済み予測スコアカードが追加されました。以下のワークフローは、このバージョンで利用できます。ネイティブプロトコルの観測とホスト型 CPU の受け入れ検証は、GPU 実行や物理的なサービング性能の証明にはなりません。

pip install "chimeraforge[mcp]==0.66.0"

クイックスタート

# Plan a registry size class on your GPU
chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --request-rate 2.0

# Plan ANY model -- a Hugging Face repo or an Ollama tag
chimeraforge plan --model Qwen/Qwen2.5-7B-Instruct --hardware "RTX 4090 24GB"
chimeraforge plan --model ollama:qwen3:14b --ollama-url http://localhost:11434

# Split a model too big for one GPU across several (tensor parallelism)
chimeraforge plan --model Qwen/Qwen2.5-72B-Instruct --hardware "H100 80GB" --tp 4

# Shrink the KV-cache, print the cost/latency/quality trade-off menu
chimeraforge plan --model-size 8b --hardware "RTX 4080 12GB" --kv-quant q8 --pareto

# Benchmark a live model and plan on the MEASURED numbers
chimeraforge plan --model qwen3:14b --measure

# Discover + rank what fits your GPU and budget
chimeraforge suggest --source ollama --hardware "RTX 4090 24GB" --budget 500

# Save and recheck an offline plan
chimeraforge plan --model-size 3b --hardware "RTX 4090 24GB" --no-network --save offline-plan.json
chimeraforge check offline-plan.json --json

プランニングからエクスポートまで、同じ Hub チェックポイントを維持する

# Metadata/config only: no model weights are downloaded by the planner
chimeraforge plan --model HuggingFaceTB/SmolLM2-135M-Instruct \
  --revision 12fd25f77366fa6b3b4b768ec3050bf629380bac \
  --hardware "RTX 4080 12GB" --platform linux --request-rate 0.01 \
  --quality-target 0 --budget 100000 --save checkpoint-plan.json --json
chimeraforge check checkpoint-plan.json --json           # offline
chimeraforge check checkpoint-plan.json --network --json # explicit Hub inspection

ブランチとタグも指定できます。解決時には、まず不変のコミットを確定し、そのコミットの設定と宣言されたファイルメタデータを読み込みます。複数の HF モデルをプランニングする場合は、--revision MODEL=REF を繰り返し指定してください。キャッシュされた移動参照は、日付付きの生成時点での観測であり、現在の状態を証明するものではありません。

デプロイメントエクスポートの前に、対応する保存済み候補を選択してください。vLLM、TGI、SGLang のコマンドには、解決済みコミットを指定する --revision が含まれます。Ollama への変換ではこの固定指定を維持できないため、拒否されます。レシートは実際に読み込まれた設定のバイト列をハッシュ化し、宣言された重みのメタデータを記録します。ダウンロードした重みやトークナイザーのバイト列を検証したり、実行中のサーバーを特定したりするものではありません。従来のプランも、元の識別情報の不足を残したまま読み込まれます。Python のチェックポイントループを参照してください。

---

推測ではなく、実際のトラフィックに基づいてプランニングする

chimeraforge workload --from-log requests.jsonl --out workload.json
chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --workload-profile workload.json

リクエストログ、または稼働中の vLLM／SGLang の /metrics エンドポイントから、リクエストレート、プロンプトと出力の長さ、トラフィックの変動、プレフィックスキャッシュのヒット率を算出します。特に重要なのは変動の値です。これがない場合、plan では 4 つのプリセットから選ぶことになり、キューイング時のテール全体に影響します。

メトリクス名はエンジンごとに異なり、明示的に指定されています。vLLM では、これらのうち 2 つがバージョン間で改名されています。古い名前にひそかにフォールバックするスクレーパーは、実際にはない計測値を報告します。未知のエンジンはエラーとなり、ソースが公開していないフィールドはデフォルト値が補われず、欠落したままになります。

意思決定の概要

chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --request-rate 2 --report brief.md

意思決定を記録した Markdown 文書を生成します。そこには、推奨事項、判明事項ではなく入力値として示されるすべての前提、選択肢の表、プランナーの警告（原文のまま）、そして文書を再生成するための正確なコマンドが記載されます。各数値は、記号だけでなく文章中で measured／extrapolated／derived／estimated／unknown のいずれかに分類されます。

古い価格スナップショットでは文書の生成を拒否して、ゼロ以外の終了コードを返します。古い価格を見栄えのよいフォントで表示することはありません。整形された文書は、ターミナルの一行よりも長く信頼できるように見え、読む人が計算をやり直すこともないためです。

MCP サーバー -- Claude / GPT / Cursor に同じ数値を提供

GPU のサイジングは、アシスタントが特に失敗しやすい領域です。学習データのカットオフ時点のハードウェア価格や仕様に加え、記憶を頼りに行う KV キャッシュやバッチ処理の計算は間違いやすいためです。chimeraforge mcp は stdio MCP サーバーを起動し、アシスタントが推測するのではなく、実測データに基づいて実際のプランナーを呼び出せるようにします。

pip install "chimeraforge[mcp]"

Claude Code：

claude mcp add --transport stdio chimeraforge -- uvx --from "chimeraforge[mcp]" chimeraforge mcp

Claude Desktop / Cursor（MCP 設定ファイルに追加）：

{
  "mcpServers": {
    "chimeraforge": {
      "command": "uvx",
      "args": ["--from", "chimeraforge[mcp]", "chimeraforge", "mcp"]
    }
  }
}

--from "chimeraforge[mcp]" は MCP SDK を取り込みます。uvx は自己完結型の環境でサーバーを実行します。クライアントが起動する環境にすでに pip install "chimeraforge[mcp]" を実行済みの場合は、代わりに "command": "chimeraforge", "args": ["mcp"] を使用できます。

HTTP 対応の MCP クライアントでは、ネイティブの Streamable HTTP トランスポートを起動します。

chimeraforge mcp --transport streamable-http --port 8766
# Connect the client to http://127.0.0.1:8766/mcp

HTTP はループバックにバインドされ、デフォルトではオフラインでモデルを解決します。Hugging Face の検索や検出を有効にできるのはサーバーの運用者だけで、その場合は --allow-network を指定します。HTTP ツールの呼び出し元は、ローカルのファイルパス、エンドポイント URL、ネットワーク設定の上書きを指定できません。Ollama のエンドポイント解決と検出は、引き続き stdio の機能です。SDK はブラウザーの Origin、許可されていない Host、64 KiB を超える本文（チャンク形式のアップロードを含む）を拒否します。ネイティブセッションの上限は 32 で、300 秒間アイドル状態が続くと期限切れになります。これらの設定と固定の 2 ワーカー容量は、mcp --help から変更できます。 HTTP の Hugging Face 検出では、ネットワーク処理を受け付ける前に、1 回の呼び出しにつき最大 16 モデルに制限されます。stdio では、既存の検出オプションが引き続き利用できます。

HTTP ツールはプロトコルのイベントループ外で実行されます。応答は 30 秒でタイムアウトします。タイムアウトまたはキャンセルされた同期処理は、実際に終了するまでワーカースロットを占有し続けます。容量がいっぱいの場合、それ以降の呼び出しにはビジーエラーが返されますが、プロトコルの ping や検出は応答し続けます。Python のスレッドは強制停止されません。サーバーのシャットダウン時には、管理下の処理が完了するまで待機するため、基盤のリゾルバーの処理が遅い場合は待ち時間が発生することがあります。このトランスポートは、ネイティブの Streamable HTTP セッションとリクエストガードを備えた、サポート対象の MCP 1.x SDK（>=1.30,<2）を使用します。

5 つのツールを公開します。chimeraforge_plan（完全なゲート検索）、chimeraforge_suggest（逆引きで、指定された GPU に実際に収まるものを順位付け）、chimeraforge_compare_api（セルフホストとホスト型 API のコスト、および損益分岐となる利用量の比較）、chimeraforge_resolve_model（モデル ID を実際のパラメーター数やアーキテクチャに照らして検証）、chimeraforge_list_hardware です。すべての結果には CLI と同じ measured / extrapolated / estimated / unknown の出所情報が含まれ、ツールの説明では、モデル自身の知識よりもこれらを優先するよう指示します。chimeraforge_plan は launch フィールドも返します。これは推奨構成のサーブコマンドなので、アシスタントはフラグをでっち上げずに「では、どう実行すればよいですか」に答えられます。chimeraforge_compare_api は日付付きスナップショットに基づいて価格を比較し、その経過時間も報告するため、アシスタントは古い数値を現在の価格として提示するのではなく、取得日を添えて価格を伝えられます。

---

コマンド

plan -- 予測型キャパシティプランナー

chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --request-rate 2.0
chimeraforge plan --model Qwen/Qwen2.5-7B-Instruct --hardware "RTX 4090 24GB"   # any HF repo
chimeraforge plan --model ollama:qwen3:14b --ollama-url http://localhost:11434  # any Ollama tag
chimeraforge plan --model Qwen/Qwen2.5-72B-Instruct --hardware "H100 80GB" --tp 4   # multi-GPU
chimeraforge plan --model-size 3b --kv-quant q4 --pareto                       # smaller KV cache, trade-off menu
chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --launch          # + the serve command to actually run it
chimeraforge plan --model-size 3b --workload agent --safety-target 0.85 --json

• レジストリのサイズクラス、HF リポジトリ（org/name）、Ollama タグ、または手動のオーバーライド（--params-b/--n-layers/...）を使って、あらゆるモデルのプランを作成します。
• 5 段階のパイプライン（VRAM -> 品質 -> 安全性（オプトイン） -> レイテンシ -> 予算）を通じて、モデル x 量子化 x バックエンド x N 個のレプリカ x バッチ/GPU を検索します。
• 実際のサービングの物理特性をモデル化します。連続バッチ処理（vLLM/TGI）、プリフィルとデコードの分離（TTFT + TPOT）、KV キャッシュに制約される同時実行数、分散を考慮したキューイング（--workload）に対応します。
• 1 台の GPU では大きすぎるモデルにも対応します： --tensor-parallel/--tp {N|auto} は、重みと KV を N 台の GPU に分割します（Megatron 方式、通信をモデル化）。--pipeline-parallel/--pp {N|auto} は、代わりにレイヤーを N 個のステージに分割します（低速なインターコネクトではこちらの方が低コストですが、パイプラインを埋めるにはバッチ処理が必要です）。現時点では併用できません。
• バックエンドが実際にサポートするものを提供します： GGUF 量子化モデルは Ollama で提供され、vLLM/TGI では FP16 と FP8 が提供されます（FP8 テンソルコアを備えた GPU（Ada/Hopper/Blackwell/CDNA3）のみ）。プランナーは、llama.cpp の高速化を前提とした価格で、GGUF チェックポイントを vLLM 用に提案しなくなりました。
• エンジンが動作する環境で実行します（--platform linux|windows|wsl2|macos。デフォルトは linux、または --hardware auto の場合はこのマシンの OS）： 各エンジンは、各 OS と GPU で動作すると公式ドキュメントに記載されている場合にのみ提供されます。拒否されるのは、ドキュメントに明記されている場合のみで、それぞれに該当するドキュメントが示されます：
  • ネイティブ Windows 上の vLLM。
  • ROCm のドキュメントで Instinct のみが対象となっている場合の、コンシューマー向け Radeon カード上の SGLang または TGI。
  • AMD 上の vLLM AWQ/GPTQ、または Intel 上の FP8。
  • ROCm 上の TGI AWQ。 エンジンのドキュメントに記載がない場合、プランでは設定を拒否するのではなく、未検証であると警告します。また、TGI がメンテナンスモードであることは常に明記します。
• KV キャッシュの量子化（--kv-quant {fp16,q8,q4}）：キャッシュを縮小して最大同時実行数を増やします。コンテキストが長い場合に最大の効果があります。
• 異種 GPU フリート（--fleet "H100 80GB,A100 80GB,L4 24GB"）：同一 GPU を N 台並べる代わりに、異なる GPU タイプを組み合わせて構成します。SLO に余裕がありリクエストが小さい場合は安価な GPU が有利で、SLO が厳しくリクエストが長い場合は高価な GPU が有利になるためです。250 req/s の 8B では、H100 3 台 + L4 1 台が $5,760/月で、A100 6 台の $6,912に対して16.7%安くなります。これは、最後の数 req/s を処理する場合、大型 GPU をもう1台追加するより小型 GPU のほうが安価だからです（plan --model-size 8b --request-rate 250 --fleet "H100 80GB,A100 80GB,L4 24GB" --budget 100000）。混在構成では、どのサービングエンジンにも同梱されていない、能力を考慮したルーターが前提となるため、混在プランにはその旨が必ず記載されます。また、報告されるデータの出所の確かさは、使用する GPU タイプのうち最も低いものに合わせられ、最も高いものには合わせられません。
• コストの現実性（--duty-cycle、--gpu-price-multiplier）：見出しに表示される $/1M-tok は、飽和状態のフリートを基準としています。確保した余力とアイドル時間にも料金がかかるため、2 req/s の 8B を H100 で実行する場合、実効コストは稼働率100%で $2.71/1M、30%で $9.04/1Mとなり、容量いっぱいの場合の $0.71 と比べて高くなります（plan --model-size 8b --request-rate 2 --hardware "H100 80GB" --budget 100000 --duty-cycle 0.3）。スポット料金や予約料金は入力値として指定し、推測値をあらかじめ組み込むことはありません。
• ハイパースケーラーのオンデマンド料金（--cloud aws|azure）：同梱されているデータセンター料金はマーケットプレイス価格で、AWS や Azure のオンデマンド料金よりおよそ4～5倍安く設定されています。--cloud を指定すると、各クラウドの公開価格リストを日付付きスナップショットで参照してフリートの料金を算出します。AWS は us-east-1 の EC2 料金リスト、Azure は eastus の Azure Retail Prices API を参照します。料金は Linux、オンデマンド、共有テナンシーの場合です。
  • インスタンス全体： TP/PP グループは1つのインスタンスに収まる必要があり、一部しか使用しないインスタンスでも、搭載されているすべての GPU の料金が発生します。
  • 例： 同じ8Bを H100 1台で実行する場合、マーケットプレイス料金では $1,800/月、AWS では $4,954（1 GPU の p5.4xlarge 1台）、Azure では $70,790 です。Azure では H100 は8 GPU の VM でのみ提供されるため、プランには8 GPU のうち7 GPU がアイドル状態になると記載されます（plan --model-size 8b --request-rate 2 --hardware "H100 80GB" --budget 100000 --cloud azure）。
  • データの取得元： 各オファーの GPU モデルは、そのクラウド独自のインスタンスまたは VM シリーズのページから取得し、GPU 数とメモリをハードウェアデータベースと照合します。名前が似ている別のカードは、理由を添えて除外されます。たとえば、Azure の H100 NVL と A100 PCIe VM が該当します。スナップショットは scripts/build_cloud_prices.py で再生成され、90日を過ぎると古いデータとして警告されます。
• バッチモード（--mode batch）：誰も待っていないオフラインのバックログ（夜間の要約ジョブ、埋め込みのバックフィル、評価の一括実行など）が対象です。レイテンシの条件と70%の使用率余力は適用されません。各 GPU はスループットを最大化するバッチを実行し、フリートは --request-rate を使用率100%で処理しきれる最小構成となります。結果は月額料金ではなく、$/1M tokens で順位付けされます。
  • 例：2 req/s の 8B を H100 で実行する場合、$1,800/月の同じ GPU 1台を使いながら、コストは $0.66/1M（オンラインで最も安価な Ollama Q2_K）から $0.065/1M（バッチ267の vLLM AWQ）になります（plan --model-size 8b --request-rate 2 --hardware "H100 80GB" --budget 100000 --mode batch）。このスループットはルーフライン推定であり、出力にもその旨が記載されます。
  • バッチモードとレイテンシ目標（--latency-slo、--ttft-slo、--tpot-slo）を同時に指定すると、無視されるのではなくエラーになります。報告されるリクエスト時間はサービス時間のみで、キュー待ち時間は含まれません。バックログの待ち時間はその規模によって異なるためです。--pareto では、$/1M tokens と品質のトレードオフを調整できます。
• セルフホストと API の損益分岐点の比較（--compare-api）：ワークロードをホスト型 API と比較し、セルフホストが有利になり始める月間のリクエスト量を報告します。価格はプロバイダーごとの出典 URL を含む日付付きスナップショットで、90日を過ぎると古いデータとして警告されます。最新の見積もりとして表示することはありません。また、最先端の API は同等品質であるかのように扱わず、異なる品質レベルとして表示します。
• 分離処理に関するアドバイザリー： Prefill/decode の分離処理はモデル化されていません。Prefill と decode の比率を閉じた形式で算出する方法はなく、vLLM 自身のドキュメントでも「スループットは改善しません」と記されています。代わりにプランナーは、公開資料で検討に値するとされる条件に当てはまる候補に印を付け、その資料を引用しますが、予測値は示しません。
  • 表示条件： プランが --ttft-slo と --tpot-slo の両方を条件として指定し、オンラインでサービングを行い、複数の GPU を使用し、かつエンジン（vLLM または SGLang）のドキュメントでこの機能が説明されていることが条件です。各条件は、DistServe（OSDI 2024）またはプランナーが固定しているタグのエンジンのドキュメント内の記述に対応しています。
  • 報告内容： モデル化されたリクエストのサービス時間に占める prefill の割合を報告します。常駐化が有効な場合は、セッションによって制限された TTFT を使用します。また、KV の受け渡しには高速なリンクが必要なため、GPU のインターコネクトも報告します。
• プレフィックスキャッシュ（--prefix-cache-hit-rate）：チャットボットやエージェントのトラフィックでは、長いシステムプロンプトが再利用されるため、prefill の大部分がすでにキャッシュされています。プロンプトが4kでヒット率が90%の場合、H100 上の8Bでは TTFT が166msから17msになります（plan --model-size 8b --prompt-tokens 4096 --hardware "H100 80GB" --budget 100000 --prefix-cache-hit-rate 0.9）。参照用 RTX 4080 で同じクエリを実行した場合は、2051msから205msになります。デフォルトは0で、値を推測することはありません。また、共有プレフィックスによって節約される KV は意図的に差し引きません。KV の見積もり不足が、「収まる」はずの構成を OOM にする原因だからです。
• マルチターンセッションの常駐化（--think-time SECONDS --session-turns T）：会話の次のターンでプレフィックスキャッシュが使われるのは、ユーザーが考えている間、KV が保持されている場合に限られます。ターン間、会話はアイドル状態です（decode は行われず、同時実行数の上限にも数えられません）が、そのプレフィックスは KV プールに保持しておく必要があります。
  • 計算方法： リトルの法則により、フリートは一度に rate x (T-1)/T x think time 件のアイドル状態の会話を保持します。プランナーは、各（レプリカ数 x バッチ）構成の空き KV に、それらのプレフィックスをいくつ保持できるかを計算し、提示するヒット率をその割合に制限します。TTFT は検索中に制限後のヒット率を使って算出されるため、レプリカ数を増やすと実際に効果があります。
  • 例： プロンプトが4kでターン間隔が60秒の 8B を 2 req/s で処理する場合、アイドル状態の会話は108件になります。RTX 4090 1台の空き KV にはそのうち19件分しか保持できないため、指定した90%のヒット率は16%になり、TTFT は100msから837msになります（plan --model-size 8b --hardware "RTX 4090 24GB" --request-rate 2 --prompt-tokens 4096 --context-length 8192 --prefix-cache-hit-rate 0.9 --think-time 60 --session-turns 10）。
  • 出力に明記される前提： セッションアフィニティルーティングにより、戻ってきたターンはそのプレフィックスを保持しているレプリカに届くものとします。また、会話が戻ってくるタイミングに対してランダムにアイドル状態の会話を退避するものとします。Ollama では、レプリカスロットごとに会話を1件保持します。両方のフラグが指定された場合にのみ有効です。
• 推論モデル（--reasoning-tokens N）：呼び出し元には見えなくても、隠れた思考トークンは GPU で decode され、KV に保持されます。可視出力だけを数えると、decode 処理を推論比率分だけ過小評価します。隠れたトークンが1000個ある場合、H100 上の8Bプランの p95 は193msから3664msになります（plan --model-size 8b --hardware "H100 80GB" --budget 100000 --reasoning-tokens 1000）。デフォルトは0で、値を推測することはありません。比率は重みではなく、ワークロードの特性です。
• アテンション形状を考慮した KV： MLA（DeepSeek-V2/V3）では、ヘッドごとの K/V ではなく圧縮された潜在表現をキャッシュするため、GQA として見積もると DeepSeek-V3 のキャッシュを57倍過大評価します。また、スライディングウィンドウモデルでは、ウィンドウサイズを超えてキャッシュが増えることはありません。レイヤー構成が宣言されていないウィンドウは適用されません。KV の見積もり不足が、「収まる」はずの構成を OOM にする原因だからです。
• Mixture-of-Experts を考慮： VRAM サイズは総パラメーター数（すべてのエキスパートが常駐）に基づき、スループットと TTFT は有効パラメーター数（トークンはルーティング先のエキスパートのみを参照）に基づきます。MoE モデルを dense モデルとして扱うと、Mixtral-8x7B ではスループットを3.6倍、DeepSeek-V3 では約18倍過小評価します。有効パラメーター数は、モデルの実際のエキスパート構成から算出され、公開されている数値と一致します。
• エネルギー（--electricity-rate）：月間の kWh コスト、$/1M-tok (+energy)、および tok/s-per-watt を、予算条件に含めず併記します。
• 運用時のカーボン排出量（--grid-region USA|DEU|France|... または --carbon-intensity G）：100万トークンあたりの gCO2e と月間の kg を報告します。エネルギー量にグリッドの炭素強度を掛けて算出します。2 req/s の 8B を H100 で実行する場合、米国のグリッドでは100万トークンあたり60 gCO2e、フランスでは6.5 gCO2eになります（plan --model-size 8b --request-rate 2 --hardware "H100 80GB" --budget 100000 --grid-region USA）。
  • 炭素強度は Our World in Data を通じて取得した Ember の国別年間平均ライフサイクル値を使用し、OWID のコミットに固定されます。scripts/build_carbon_data.py で再生成されます。各数値には年が表示され、2年を超えて古い数値は警告されます。
  • SCI の運用時の項（O = E x I）のみを対象とします。内包排出量はモデル化されていないため、完全な SCI スコアではありません。
  • E はホストやデータセンターの PUE を含まないボード電力であり、数値は下限値です。TDP が不明な場合、カーボン排出量も不明となり、ゼロにはなりません。
• 起動コマンドのエクスポート（--launch）：採用された構成に対応する vllm serve／ollama run／TGI の docker run コマンドを生成します。プランで使用したコンテキスト長、TP/PP 度数、バッチサイズ、KV データ型を埋め込みます。これらのフラグは手計算すると間違いやすいためです。導出できない情報を捏造することはありません。たとえば、GGUF の量子化レベルは、架空の --quantization フラグではなく、ネイティブ相当のチェックポイントをサービングするようにという注記になります。
• 各予測のデータの出所の確かさ（measured／extrapolated／derived／estimated／unknown）を示し、条件に合う構成がない場合は、制約となっている条件を説明します。
• レジストリデータで検証済み：VRAM R^2=0.968、スループット R^2=0.859、品質 RMSE=0.062、レイテンシ MAPE=1.05%（解析的な M/D/1 より20.4倍良好、TR133）。ML は使用せず、第一原理に基づく補間を用いた経験的ルックアップテーブルを使用します（レジストリにないモデルにはルーフラインを使用）。

check -- 保存済みプランをオフラインで再チェックする

chimeraforge plan --model-size 3b --no-network --save plan.json
chimeraforge check plan.json --json

使用した入力、ローカルの価格、実現可能性、候補の順序、モデル化された差分を比較します。保存済みファイルは変更されません。新しいスナップショットでは、モデルの完全なジオメトリ、GPU／プラットフォーム、入力の受領情報がひも付けられます。従来のスナップショットでは、ひも付けが欠けている項目は未検証として報告されます。チェックによって、保存済みの権限設定からネットワークアクセスが有効になることも、auto プランで新しいホストのプローブが行われることもありません。終了コード 0 は必須のモデル化コンポーネントに変更がないこと、1 は必須の証拠に変更・期限切れ・未検証があること、2 は入力形式が不正であることを示します。モデル化された推奨が安定していても、実運用時の性能が証明されるわけではなく、不変のモデルウェイトが特定されるわけでもありません。API コントラクトを参照してください。

bundle -- 保存済みプランを移送可能な形式で引き渡す

公開済みの 0.61.0 CLI で利用できます。

ハーネスファイルには、非公開のプロンプトやその他のデータが含まれている場合があります。バンドルを共有する前に、正確な入力内容を確認してください。 作成時にコピーされるのは、元のプランと、そこにひも付けられた係数／品質ファイルのみです。元のバイト列、パス、フィンガープリントはそのまま保持されます。

chimeraforge bundle create plan.json --out handoff
# Move the whole handoff directory to the receiving machine.
chimeraforge bundle verify handoff --json
chimeraforge bundle check handoff --json

再チェックでは、生成元のファイルが削除された後も、オフラインで検証済みの入力バイト列を使用します。JSON では、生成元とローカルのソース場所が別々に表示されます。現在のツール、ポリシー、ハードウェア、適用対象の価格／クラウドの変更は、引き続き対応が必要な項目として扱われます。検証済みであることだけでは、プランのチェックに合格したことにはなりません。verify は内容が検証済みの場合に終了コード 0 を返し、check は必須の事実に変更がない場合に 0、変更・期限切れ・必須項目の未検証がある場合に 1 を返します。不正なバンドルまたはサポート対象外のバンドルは 2 を返します。バイト列のひも付けがない従来のプラン、および空でない寄与依存関係があるプランは、書き込み前に拒否されます。整合性が確認されても、ソースの真正性や、配信されたウェイトまたは性能が証明されるわけではありません。移送可能なワークフローを参照してください。

study -- コンテキストを固定したワークロードとコストの感度分析

公開済みの 0.61.0 CLI で利用できます。 1 つの保存済みプランまたは移送可能なバンドルを基に、明示的な前提条件をオフラインで比較します。

[
  {"name": "twice-the-load", "changes": {"request_rate": 2}},
  {"name": "half-duty", "changes": {"duty_cycle": 0.5}},
  {"name": "no-budget", "changes": {"budget": 0}}
]

リストを cases.json として保存し、次を実行します。

chimeraforge study plan.json --cases cases.json --out study.json --json
# A portable bundle works even with the producer's input files absent.
chimeraforge study handoff --cases cases.json --json

通常の検索では、各ケースに対して同じ、ひも付け済みのモデル／GPU ジオメトリと、検証済みの係数／品質バイト列を使用します。現在のエンジン対応状況、適用対象のクラウド価格、グリッドの炭素強度、隔離記録とその時刻情報は、1 回だけ取得されます。レポートでは、これらの現在の事実と生成元の受領情報を区別し、ゲートの理由を添えて実現不可能なケースも保持します。また、構成と推定値をネイティブ単位で比較します。ポリシーの識別情報に変更があると、分析は中止されます。

一意のケースを 1～16 件指定すると、ひも付け済みのモデルターゲットを最大 16 個まで扱えます。ワークロード、コンテキスト、SLO、品質／安全性のターゲット、予算、稼働率、コストの前提条件は変更できます。モデル、物理ハードウェア、プラットフォームは固定されます。gpu_cost_per_hour は運用者が設定する価格の前提条件です。クラウドインスタンスの価格には使用できず、ゼロを指定するとネイティブの価格不明時の動作が維持されます。出力によって既知の入力が上書きされることはありません。終了コード 0 は、実現不可能なケースを含め、モデル化された分析が完了したことを示します。入力が無効または利用できない場合は 2 で終了します。ウェイトはダウンロードされず、サービングトラフィックも生成されません。整合性やモデル化された差分は、入力の真正性を証明するものでも、性能を認定するものでもありません。Python およびケースのコントラクトを参照してください。

deploy -- サービング設定をエクスポートする

保存済みの候補を1つ選び、Compose、systemdユーザーサービス、Ollama macOS LaunchAgent、またはModelfileとしてエクスポートします。エンジンのインストール、起動、デプロイは行いません。

mkdir deployment
chimeraforge plan --model Qwen/Qwen2.5-1.5B-Instruct --hardware "RTX 4090 24GB" --ttft-slo 500 --tpot-slo 50 --save plan.json
# Bash: select a single-replica, resident vLLM FP16 candidate from this artifact.
CANDIDATE_INDEX=$(python -c "import json; p=json.load(open('plan.json')); print(next(i for i,c in enumerate(p['result']['candidates']) if c['backend']=='vllm' and c['quant']=='FP16' and c['n_agents']==1 and c['offload_fraction']==0))")
chimeraforge deploy --plan plan.json --candidate-index "$CANDIDATE_INDEX" --format compose --image vllm/vllm-openai:v0.30.0 --out deployment/compose.yaml

PowerShellでは、同じPythonの選択処理を $CANDIDATE_INDEX = python -c "..." として割り当てます。 エクスポートする前に保存済みの候補を確認してください。一致する候補がない場合、選択は失敗します。 最初の候補が必ずしもvLLMやチェックポイント本来の精度とは限りません。 イメージタグは明示的な例であり、実行済みであることを示すものではありません。イメージのバイト列を固定するには、検証済みのエンジンイメージまたはダイジェストを使用してください。出力ファイルは新規作成する必要があります。 明示したイメージのバックエンドに一致する候補を選択してください。未対応のフリート、オフロード、解決できないアダプターパス、チェックポイントとKVの不一致は、明確なエラーになります。 Ollamaはデーモン設定と、必要なプロビジョニング手順を記載した付属のModelfileを生成します。 ネイティブユニットでは、インストール済みの実行ファイルのパスを明示する必要があります。対応テンプレートと設定の検証をご覧ください。設定が受け入れられたからといって、GPUで実行されることや予測精度が保証されるわけではありません。

suggest -- モデルを見つけてランク付けする

chimeraforge suggest --source ollama --hardware "RTX 4090 24GB" --budget 500
chimeraforge suggest --source hf --hf-limit 8 --hardware "RTX 4080 12GB"
chimeraforge suggest --source catalog --hardware "RTX 4080 12GB"   # offline, after `catalog --build`

稼働中のOllama（/api/tags）、HF Hub（上位のテキスト生成モデル）、ローカルカタログから候補を取得します。各候補を実際のパラメーター数とアーキテクチャに解決して、同じゲート検索を実行し、モデルごとに最適な設定を表示します。

measure -- 実測値でベンチマークし、計画する

chimeraforge measure --model qwen3:14b --ollama-url http://localhost:11434
chimeraforge plan --model qwen3:14b --measure   # measure then plan in one step

稼働中のモデルをベンチマークし（実測のN=1スループット、サービス時間、同時実行数のスケーリング）、ローカルコーパスに取り込みます。その後、plan／suggestは測定値を自動的に優先するようになり、プロベナンスは measured に切り替わります。

SGLangには測定済みのデータが含まれていないため、プランナーはvLLMのデータを流用せず、その旨を示します。次のコマンドで独自に測定してください。chimeraforge measure --backend sglang --model <served-model-name> --base-url http://localhost:30000。vLLM、TGI、SGLangのアダプターはストリームを処理し、最初と最後のトークンを計測します。そのため、プリフィルを含む壁時計時間あたりのトークン数ではなく、プランナーが予測するデコードレートを記録します。TTFTは別途報告されます。トークン数はサーバーから取得します（usageブロック、またはTGIの最終的なgenerated_tokens）。どちらも含まれない応答は推定せず、破棄されます。

workload -- 実際のトラフィックからプランの入力値を算出する

chimeraforge workload --from-log requests.jsonl --out workload.json
chimeraforge workload --from-metrics http://localhost:8000/metrics --engine vllm --out workload.json
chimeraforge workload --from-metrics http://localhost:8000/metrics --interval 60 --engine vllm --hardware "H100 80GB"
chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --workload-profile workload.json

JSONL リクエストログまたは稼働中の vLLM/SGLang /metrics エンドポイントから、リクエストレート、プロンプト／出力の長さ、トラフィックの変動、プレフィックスキャッシュのヒット率を読み取るため、plan でこれらの値を手入力の推測値に頼らずに済みます。特に重要なのは変動です。キューイングのテール全体を左右するためです。また、実測した CV^2 は4つのプリセットのどれかに当てはまるものではありません。

• ウィンドウ（--interval 60）では、2回スクレイプして実際の間隔を計測します。--interval を指定して保存済みの2つのスクレイプを使うこともできます。この場合、出力ではその間隔を実測値ではなく、指定値としてラベル付けします。ウィンドウを使うとカウンターから実測リクエストレートを算出でき、平均、分散、キャッシュヒット率はエンジンの稼働開始からの累積値ではなく、そのウィンドウを対象とした値になります。スクレイプ間にカウンターがリセットされた場合（エンジンが再起動した場合）はエラーになります。
• KV キャッシュの圧迫度は、vLLM の kv_cache_usage_perc と SGLang の token_usage に加え、ゼロ以外の場合は SGLang の SWA および Mamba プールから読み取ります。いずれも 0～1 の割合で、瞬時値としてラベル付けされます。
• MFU と MBUは、ウィンドウ内の各エンジンの FLOP およびバイトのカウンターを、--hardware で指定したカードの密な FP16 のピーク性能とメモリ帯域幅と比較して算出します。カウント値はハードウェアカウンターではなく、エンジン独自の分析モデルに基づくため、estimated とラベル付けされます。これらのカウンターはサーバーを --enable-mfu-metrics 付きで実行した場合にのみ存在します。存在しない場合はプロファイルにその旨が示されます。
• メトリクス名は vLLM v0.30.0 と SGLang v0.5.20 のソースから確認しました。テストフィクスチャには、それらの宣言から生成した実際の prometheus_client 出力を使用しています（scripts/make_engine_metrics_fixtures.py）。手入力のフィクスチャでは、vLLM のプレフィックスキャッシュカウンターが _total サフィックス付きで公開されることが見落とされていたため、これまで実際のエンドポイントからヒット率を読み取れていませんでした。

メトリクス名はエンジンごとに明示されます。未知の --engine はエラーとなり、エンドポイントに誤ったエンジンを指定した場合も、エラーがはっきり表示されます。名前が変更されたメトリクスにスクレイパーが黙ってフォールバックすると、実在しない測定値が報告されるためです。ログでは平均と分散が measured として得られます。Prometheus ヒストグラムでは平均は正確ですが、分散はバケットから近似されるため、estimated とラベル付けされます。1回のスクレイプではレートを算出できないため、未計測の稼働時間で割ることはせず、request_rate は未設定のままになります。また、データソースが公開していないフィールドは既定値ではなく、引き続き plan に必須の入力値です。明示的に指定したフラグは、常にプロファイルより優先されます。

validate -- 測定値に照らして予測を監査する

chimeraforge validate --matrix matrix.json --measurements captured.json

プランナー自身の予測を出所クラスごとに採点するため、「推定」に感覚ではなく数値を付けられます。設定マトリックスは監査にフィンガープリント化して記録されます（SHA-256、順序に依存しません）。そのハッシュを --expect-fingerprint <hash> で渡すと、マトリックスのハッシュが一致しない場合にコマンドは失敗します。これにより、結果を見た後に編集したマトリックスを、登録済みのものとして提示できなくなります。つまり、事後選択ではなく事前登録です。このフラグを指定しない場合は、読み込まれたマトリックスからフィンガープリントが再計算されて出力されますが、それだけでは何の証明にもなりません。すべてのセルが公開され、集計では最悪のケースが平均化されずに残り、セル数が少なすぎるクラスには、率として引用するのではなく「検証不足」とラベルが付きます。

測定値は、単なる数値ではなく出所の記録とともに提供されます。各セルには以下が記載されます。

• 誰が測定したか：own-rig-measured または third-party-measured。これらは別々のスコアカード行として扱われ、決して平均化されません。
• どこから得たか：source_url、または own-rig の実行では記録されたベンチ環境。
• captured_at の日付。
• 出典でサービング設定が省略されていたかどうか（underspecified）。該当セルは主要行から除外されますが、引き続き公開されます。
• 各数値が示す指標：decode_tps_single_stream、e2e_tps_single_stream、prefill_tps（セルのプロンプト長を使って TTFT に換算）、ttft_ms、e2e_latency_ms（1リクエスト、バッチサイズ1で、プランナーのサービス時間と比較して採点）、e2e_latency_p95_ms、または aggregate_tps_at_concurrency。

エンドツーエンドのレートや集約レートは生の出力には保持されますが、プランナーのデコード予測との比較には決して使われません。また、ambiguous は読み込まれません。プランナーのフィッティングに使われた TR コーパスを出典としているサードパーティのセルは拒否されます。出所情報のない v1 形式 {cell: {metric: value}} は拒否されます。

{"schema_version": 2, "hardware": "RTX 4090 24GB", "cells": {
  "<model|quant|backend|c..|p..|o..|b1>": {
    "evidence": "third-party-measured", "source_url": "https://...", "captured_at": "2026-09-25",
    "underspecified": false, "config_quote": "llama-bench -ngl 99 -fa 1",
    "metrics": [{"definition": "decode_tps_single_stream", "value": "<tok/s>", "quote": "tg128 | ..."}]}}}

スコアカードでは、インバンド合格率（マトリックスで事前登録された bands の許容範囲に対する合格率。登録されていない場合は n/a）、絶対誤差の中央値、GMFE（幾何平均倍率誤差。2倍の過大評価と2倍の過小評価は同じスコアになります）、符号付きバイアス、最悪のセルが報告されます。許容範囲、参照した出典の一覧、およびセルごとの spec（オフライン予測で固定するアーキテクチャ）は、フィンガープリントの一部です。--models-path を指定しない限り、予測には常に同梱のコーパスが使われるため、公開済みの監査は measure がキャッシュに残した内容に依存しません。バッチ処理のセルは、単一ストリームの予測と比較する代わりにスキップされます。

公開済みの監査。 corpora/SCORECARD.md では、17種類の GPU に関する8件の公開サードパーティベンチマーク出典からの42セルを使って、プランナーを評価しています。生の JSON、ルールとともに記録されたすべての除外項目、事前登録された出典一覧はすべてコミット済みで、評価レポートは TR147 です。監査対象の予測はすべてルーフライン推定値です。

設定が完全に指定されたセルでは、デコードが+-25%以内に収まるのはわずか**13%で、絶対誤差の中央値は35.9%**です（n=15）。メモリの種類によって、誤差の方向は反対になります。

• HBM 搭載のデータセンター向け GPU： デコードは中央値で**+58%**過大予測され、B200 では最大+206%に達します。llama.cpp は A100/H100/H200/B200/MI300X で200-308 tok/sを測定する一方、ルーフラインは帯域幅に比例してスケールします。
• GDDR 搭載のコンシューマー向けカード： デコードは中央値で**-36%**過小予測されます。

HBM 搭載 GPU のルーフラインによるデコード値は、上限として捉えてください。python scripts/build_validation_corpus.py --write --audit で監査を再生成できます。公開済み監査が古くなった場合や、誤差範囲が拡大した場合、テストは失敗します。

monitor -- 明示的なレイテンシ SLO を監視する

chimeraforge monitor --backend vllm --url http://localhost:8000 --model YOUR_SERVED_MODEL \
  --ttft-slo 500 --tpot-slo 50 --interval 30 --windows 1 --json
# After starting the selected candidate and generating traffic, bind its saved targets.
chimeraforge monitor --from-plan plan.json --candidate-index "$CANDIDATE_INDEX" \
  --backend vllm --url http://localhost:8000 --model Qwen/Qwen2.5-1.5B-Instruct --windows 1 --json

2 回のスクレイプによるヒストグラムウィンドウを通じて、既存のトラフィックを監視します。P95 バケット境界を明示的なミリ秒単位の目標値と照合し、pass（終了コード 0）、breach（3）、または unknown（4）を報告します。運用上のエラーの場合は終了コード 1 になります。データがない場合、トラフィックがない場合、リセットが発生した場合、およびバケットが目標値をまたぐ場合は、合格になりません。SGLang の TTFT はサポートされていますが、その ITL ヒストグラムではリクエストごとの TPOT を判定できません。--from-plan plan.json --candidate-index 0 を指定すると、保存済みの候補と目標値のソースをパッシブなサービングメタデータに紐付けます。既知の ID／構成の不一致はネイティブ SLO の結果とは別に終了コード 5 で報告されます。必須のエンドポイント ID を取得できない場合は終了コード 4 になります。GPU の構成、フリートのトポロジ、ワークロード、不変の重みは、利用できない場合、明示的に未検証として扱われます。独立したプラン紐付け用およびネイティブ SLO 用の Prometheus ゲージについては、監視ガイドに記載されています。これは、校正済みの予測ドリフトを主張したり、トラフィックを生成したりするものではありません。

doctor -- このマシンを確認する（読み取り専用）

chimeraforge doctor            # detected GPUs, what the planner can do with each, local engines
chimeraforge doctor --json     # the same report as JSON

このコマンドは各ベンダー独自のツールを使ってローカルプラットフォームを検出し、何も変更しません。各プローブは使用したツールを明示し、ツールが見つからない場合はエラーではなく検出事項として報告します。

• NVIDIA： デバイスには nvidia-smi、CUDA バージョンには pynvml を使用します。
• Linux 上の AMD： amd-smi、または非推奨の rocm-smi を使用します。カードが一覧にない場合は、カード自身が報告する帯域幅を --gpu-bandwidth-gbps に設定します。
• Apple Silicon： system_profiler を使用し、ユニファイドメモリとして報告します。
• Intel： xpu-smi を使用します。PCI ID に基づくデバイス名を製品名として推測することはありません。
• Windows、ベンダーを問わず： CIM とディスプレイクラスのレジストリを使用します。Win32_VideoController.AdapterRAM は uint32 で 4 GB が上限のため、代わりにドライバーの qwMemorySize を読み取ります。統合 GPU の値は VRAM ではなく、共有メモリアパーチャとして表示されます。
• WSL： カーネルリリース内の WSL を検出します。Microsoft によると、「microsoft」だけでは WSL 以外のカーネルにも含まれます。

終了コードは信用しません。rocm-smi は報告対象が何もなくても終了コード 0 を返すためです。パーサーは実際のキャプチャを使ったゴールデンテストで検証されており、各ソースとライセンスは tests/fixtures/doctor/SOURCES.md に記載されています。

各デバイスにはプランナーのステータスが付与されます。

• matched：データベースのエントリと、それを使ってプランを作成するためのフラグが示されます。
• supply-figures：データベースにないため、必要な --gpu-* フラグが一覧表示されます。数値が設定されるのは、ツールが専用 VRAM を報告した場合のみです。

ローカルのサービングエンジンは、bench が使用するものと同じデフォルト URL でプローブされます。エンジンは、バージョンエンドポイントを通じて自身を識別した場合にのみ、実行中として扱われます。:8000 の /health に応答する汎用 Web アプリは、vLLM としてではなく、「応答したが vllm として識別されなかった」と報告されます（プランのドリフト検出には check を使用します）。

doctor は、検出したプラットフォームに対応するエンジンサポートマトリックスの行も表示します。行は linux-cuda、linux-rocm、linux-xpu、windows-native、windows-wsl2、macos-apple-silicon、cpu です。

各セルは、固定されたリリースのエンジン独自のドキュメントに基づいています。対象は vLLM v0.30.0、SGLang v0.5.20、TGI v3.3.7、Ollama v0.34.4 です。すべての記述には、原文からの引用と /blob/<tag>/ URL が付いています。記載がない場合は推測せず、not documented と記録します。

マトリックスの内容は次のとおりです。

• vLLM は Windows 上ではネイティブに実行されず、WSL2 上で実行されます。
• ROCm では、vLLM はコンシューマー向け Radeon カード（RDNA3/4）を掲載していますが、SGLang と TGI は Instinct のみを対象としています。
• ネイティブな Windows AMD サポートを文書化しているエンジンは Ollama のみです。
• TGI のリポジトリはアーカイブされ、メンテナンスモードになっています。

scripts/build_engine_support.py はマトリックスを再構築して検証します。90 日を超えて古くなると、doctor が警告します。

contribute -- ベンチマーク結果を共有し、他の結果を隔離する

# Serve the FP16 checkpoint first; --quant records its precision.
chimeraforge bench --model llama3.2-3b --backend vllm --quant FP16 --runs 5 --output-dir results/
chimeraforge contribute export results/bench_*.json --out contributions/   # one file per result
chimeraforge contribute verify contributions/*.json              # schema + content hash
chimeraforge contribute import theirs.contribution.json          # into the local quarantine
chimeraforge contribute list
chimeraforge contribute review theirs.contribution.json --decision retain --reason "Replay needed" --json
chimeraforge contribute replay theirs.contribution.json --prompt "Explain KV caching briefly." --output-tokens 128 --runs 3 --base-url http://localhost:8000 --out replay.json --json
chimeraforge plan --model-size 3b --hardware "RTX 4090 24GB" --contributions

署名なしの v1 ワークフローは、測定結果を共有するコーパスに向けた最初の一歩です。

• 貢献データに含まれるもの： 完全な環境フィンガープリント（GPU、メモリ、ドライバー、CUDA、OS、エンジンとバージョン、chimeraforge のバージョン）、実行ごとのデコード値と TTFT 値、SHA-256 コンテンツ ID を含む 1 件の bench 結果です。
• エクスポートが拒否するもの： GPU 名がない結果、実行回数が 3 回未満の結果、バックエンドのデフォルト精度が不明な結果、または適用されていない量子化スイープのラベルが付いた結果です。--quant は提供されるチェックポイントの精度を宣言するものであり、サーバーに読み込まれたモデルを変更するものではありません。無効なフィンガープリント、タイムスタンプ、サンプル、一貫性のない派生統計も拒否されます。デコード CV が 5% を超える結果は不安定としてフラグが付けられますが、保持されます。
• ID が証明するもの： これらの v1 ファイルは署名されていません。ID が示すのは、エクスポート後にファイルが変更されていないことだけであり、誰が実行したか、数値が実際のものかどうかは証明しません。そのため、インポートはローカルの隔離領域に格納され、そこにあるデータが同梱コーパスや measure コーパスに入ることはありません。
• plan --contributions での利用方法： モデル、エンジン、量子化、GPU が完全に一致する場合に限り、一致した貢献データの中央値を使用します。この数値には contributed（*）というラベルが付き、extrapolated より低いクラスとして、貢献 ID と、そのデータの取得元となったエンジン／ドライバーのクラスターも併記されます。このプロジェクト独自のリファレンスリグでの測定値がある場合は、そちらが引き続き優先されます。

review は、元の完全なコンテンツ ID とエンベロープダイジェストに紐付けて、署名なしの pending／retain／reject の判定と理由を記録します。ファイルまたは隔離領域にある完全な ID を読み取り、元データ、隔離領域、コーパスを保持します。判定レシートがデータ作成者を認証したり、プランナーでの適格性を変更したりすることはありません。

replay は、明示的に接続したエンドポイントに対して既存のベンチマークランナーを実行し、プロンプトと出力トークンの上限を必須とします。適用されたワークロード、実際のトークン数、要求／成功／失敗の全件数、ネイティブサンプル、提供前後のメタデータを記録します。CPU、エンジン、量子化、モデル、設定に関する既知の不一致は、証拠が得られない場合とは区別されます。GPU 名は観測されたメモリを使って正規化されます。クライアント側の NVML GPU 情報は、リモートで実行されたことを証明しません。

現在の contribution v1 では、元のプロンプト／オプション／並行数、変更不能なモデル設定、リモート設定との紐付けが省かれています。そのため、ネイティブのデコード／TTFT の差分は、再生の同等性が未検証のまま算術的に比較されます。終了コード 0 は、既知の不一致がない状態でレビューまたは再生操作が完了したことを意味し、再現に成功したことを意味するものではありません。既知の不一致、実行失敗／部分実行では再生は終了コード 1 を返し、不正な入力／オプション、またはレシート出力エラーでは 2 を返します。新しいレシートで貢献データの入力を上書きしたり、隔離領域に書き込んだりすることはできません。また、エンドポイント URL から認証情報とクエリが除外されます。

署名付き v2 貢献データとプライベート再生（0.65.0 以降）

オプションの署名機能をインストールします：pip install "chimeraforge[sign]==0.66.0"。 現在保存されている PlanBenchmark レシートと Ed25519 キーファイルを使用します：

chimeraforge contribute sign plan-benchmark.json --private-key producer.key --out signed.json --json
chimeraforge contribute verify signed.json --format v2 --trusted-key producer.pub --out verified.json --json
chimeraforge contribute replay signed.json --format v2 --trusted-key producer.pub --private-workload private-workload.json --base-url http://localhost:11434 --out replay-v2.json --json

プライベートファイルには、元のプロンプトと記録されたアダプターオプションがそのまま含まれます。エンドポイントへの接続前に、これらのハッシュが一致している必要があります。公開署名済みアーティファクトには、ネイティブ母集団、宣言された制御項目、コミットメントが含まれますが、プロンプト、完了内容、生のオプションは含まれません。署名の有効性と受信者の信頼性は別個に扱われます。再生では、現在記録されているプロファイルとの比較、既知の不一致、確認できない事実が報告されます。元のワイヤー上のデフォルト値と、実際に生成されたポアソンのスケジュールは未検証のままです。v2 ファイルは v1 の隔離領域とプランナーの集計対象から除外されます。鍵の設定、API、プロトコル、終了コードの仕様を参照してください。

catalog -- ローカルモデルカタログ

chimeraforge catalog --build         # resolve a curated seed (+ --with-ollama) and cache specs
chimeraforge catalog                 # list the cached catalog

解決済みの仕様を保存し、完全にオフラインで既知の良好なセットを suggest --source catalog で順位付けします。

safety -- ライブ拒否判定

chimeraforge safety --model llama3.2-3b --prompts harmful.txt --quant Q4_K_M --safety-target 0.85

plan --safety-target は同梱の TR134/TR142 データから判定するのに対し、safety は測定します。プローブ用プロンプトをライブモデルに対して実行し、拒否を分類し（ルールベース -- TR134 の正規表現ベースライン）、測定した拒否率を同梱のゲートデータと比較して報告し（期待値、ドリフト、RTSI リスクティア）、--safety-target を下回ると終了コード 1 で終了します。プロンプトはユーザーが用意します（--prompts、1 行につき 1 つ）。パッケージに攻撃コーパスは同梱されていないため、HarmBench / AdvBench / 独自のセットを指定してください。Ollama の実行が必要です。

bench -- ライブ推論のベンチマーク

chimeraforge bench --model llama3.2-3b --runs 5
chimeraforge bench --model llama3.2-3b --all-quants --context 512,1024,2048,4096 --json
chimeraforge bench --model llama3.2-3b --backend vllm --base-url http://localhost:8000
# Requires the selected vLLM candidate from the deploy example to be running.
chimeraforge bench --plan plan.json --candidate-index "$CANDIDATE_INDEX" --model Qwen/Qwen2.5-1.5B-Instruct --base-url http://localhost:8000 --prompt "Explain KV caching briefly." --runs 5 --json

bench --plan は、保存済みの不変な候補を、実際のサービング観測値と適用されたワークロードに紐付けます。モデル化された値と測定値、算術的な差分、設定の不一致、利用できない証拠を記録します。指定された量子化／TP ラベルでは、エンドポイントを検証できません。一部のリクエストや異なる計測基準では、モデル化された SLO を達成できません。レシート、アダプターの制限、終了コードについては、計画 API ガイドをご覧ください。ホスト型 CPU チェックでは、この経路を検証しますが、GPU 予測精度を保証するものではありません。

3 種類のワークロードプロファイル（単一／バッチ／サーバー Poisson）を用意しています。スループット、TTFT、レイテンシを p50/p90/p95/p99 で測定し、CV に基づく安定性警告を表示し、JSON を出力します。

最初のリクエストの前に、bench（および measure）は URL のサーバーが指定されたエンジンであることを確認します。vLLM は /version、TGI は /info、SGLang は /server_info、Ollama はルートバナーで確認します。/health に応答しても自身を識別しないポートは拒否されるため、別のウェブアプリの数値が vLLM のものとして記録されることはありません。

gate -- 明示的な測定済み回帰ポリシー

空でないネイティブメトリックルール、正確な順序付き反復回数、観測済みのコントロールと処置を含むポリシーを保存します。各ルールはすべてのペアで合格する必要があり、宣言されたすべてのレシートと生サンプルの集計値が検証されます。

{"rules":{"completed_token_rate_tps":0.05,"ttft_ms":0.10},"expected_replicates":2,"fixed_controls":{"device":"cpu","backend":"ollama"},"require_cache_evidence":true}

chimeraforge gate --baseline baseline-1.json --baseline baseline-2.json --candidate candidate-1.json --candidate candidate-2.json --policy policy.json --out gate.json --json

実際の bench --plan レシートファイルを使用してください。終了コード 0 は条件付きのエンジニアリング上の合格、1 は回帰、2 は入力／出力の形式不正、3 は判定不能を示します。ネイティブな Ollama サーバーのプリフィル／デコード／合計時間は、SSE クライアントの計測時間とは異なります。完全なトークン数／クライアント側の経過時間のルールでは、明示的に変更されたバックエンドを比較できます。必須のコントロールが不明な場合、リクエストが失敗した場合、観測された長さが異なる場合、実行ペイロードがコピーされている場合は合格できません。キャッシュの証拠は、観測されたネイティブなカウントと設定に基づきます。必須の事実が欠けている場合や既知の変更がある場合は、3 になります。require_cache_evidence:false を明示的に事前宣言すると、証拠の不在のみが免除されますが、キャッシュが制御されていない範囲は維持され、既知のドリフトによる拒否も引き続き適用されます。いずれの判定も、重みの真正性、独立したコールド実行、信頼度、GPU 精度、キュー時間を含む SLO の達成を証明するものではありません。完全なポリシー／API 契約をご覧ください。ベンチマークゲートは 0.61.0 で利用できます。

trace -- 実際のスケジュール済みリクエストと複合ターゲットのグッドプット

明示的なスケジュールと出力上限を指定したプライベートな workload.json を作成します。

[
  {"request_id": "first", "prompt": "Explain KV caching briefly.", "max_output_tokens": 32, "arrival_offset_s": 0},
  {"request_id": "second", "prompt": "List three primary colors.", "max_output_tokens": 16, "arrival_offset_s": 0.1}
]

# Requires this model to be running on the named endpoint. Prompts are sent there.
chimeraforge trace workload.json --model llama3.2-3b --backend ollama --concurrency 1 --latency-slo 2000 --first-output-slo 500 --tpot-slo 50 --out trace.json --json

trace は、失敗、一部完了、キャンセル、未開始のリクエストを含め、計画されたすべてのリクエストを記録します。実際のクライアント到着時刻、キュー待ち時間、初回出力時刻、終了時刻を使って、スケジューラーの遅延とサービングレイテンシを区別します。複合ターゲットのグッドプットには、計画および観測された期間全体が使われます。必要なタイミングが不明な場合、そのリクエストは条件を満たしません。Ollama のストリーミングでは初回出力を直接観測しますが、ネイティブのプリフィル時間は別に扱われます。平均デコード時間にはその算出基準が明記され、すべてのトークンがターゲットを満たすことの証明にはなりません。初回出力を取得する機能のない他のアダプターでは、その値は不明として報告されます。出力上限はリクエストとして指定し、実際のトークン数は別に記録します。

0.62.0 以降： --backend vllm、sglang、または tgi では、ネイティブのストリーミングを通じて、ユーザーに表示される初回出力を観測します。ネイティブのトークン ID には EOS／制御ステップが含まれ、最終的なサーバー側カウントとの整合が必要です。リクエストされた上限を超えると、完了として扱われません。クライアント側の平均デコード時間を算出するには、完全な ID、最初の到着時のトークンが 1 つであること、初回と最終の到着時刻が異なることが必要です。有効な 1 トークンの完了またはバッファリングされた完了では、デコード時間は取得できなくても、カウントと初回出力は保持されます。ID／キャッシュ数が欠落している場合は、不明のままです。これらのクライアント側タイミングは、サーバー側のプリフィル時間および Ollama のサーバー側デコード基準とは別のものです。

レシートには、プロンプトや完了テキストではなく、プロンプトのハッシュが含まれます。終了コード 0 は、SLO 違反を含め、実行が完了したことを意味します。1 は実行が未完了または失敗したことを、2 は入力形式が不正であることを意味します。ターゲットが指定されていない場合、SLO 条件の判定は行われません。この測定の対象は、接続先のエンドポイントとクライアントのワークロードです。GPU の構成、独立したコールド実行、サービング対象ファイルの認証は検証されません。Python API、制限、キャンセル、タイミングの算出基準については、トレースの仕様を参照してください。

gate --kind trace -- キュー待ち時間を含めたリグレッション判定（0.63.0 以降）

Chimeraforge 0.63.0 以降では、事前に宣言したトレースポリシーを trace-policy.json として保存します。

{
  "rules": {"goodput_rps": 0.05, "latency_p95_ms": 0.10},
  "expected_replicates": 1,
  "fixed_controls": {"device": "cpu"},
  "require_cache_evidence": true
}

chimeraforge gate --kind trace --baseline baseline-trace.json --candidate candidate-trace.json --policy trace-policy.json --out trace-gate.json --json

順序付きの各反復について、各群につき 1～16 件の --baseline と --candidate を指定します。このゲートは、保持されたレシートを検証し、リクエストのタイミング、SLO の状態、ネイティブの算術値、グッドプットを再構築します。母集団全体の p95 にはキュー遅延が含まれます。tpot_p95_ms はリクエストごとの 平均 TPOT を集計したものであり、個々のトークンの値ではありません。必要な行が不明、実行が失敗、制御条件または長さが不一致、キャッシュのドリフトが既知、あるいは実行が複製されている場合、判定は結論不能になります。ペアになっていないレシートを含め、宣言された入力はすべて保持されます。終了コード 0 は条件付きのポリシー合格、1 はリグレッション、2 は入力または出力の形式不正、3 は結論不能を表します。ベンチマークのゲート判定では、引き続きデフォルトの --kind benchmark を使用します。ゼロのベースライン、エビデンスの制限、出力の保護については、トレースポリシー／API の仕様を参照してください。物理的なソース認証、独立したコールド実行、GPU の適合性は検証されません。

trace-campaign -- 凍結されたシリアル再生対象群（0.64.0 以降）

Chimeraforge 0.64.0 以降と、既存のサービング済みモデルを使用します。

chimeraforge trace-campaign workload.json --model llama3.2-3b --backend ollama --replicates 3 --campaign-timeout 1800 --concurrency 1 --request-timeout 300 --trace-timeout 600 --latency-slo 2000 --first-output-slo 500 --tpot-slo 50 --out campaign.json --json

ワークロードは一度だけ保持され、エンドポイントに接続する前に、ハッシュ、順序付けされた記述子、制御情報、対象群のマニフェストが凍結されます。レプリカはリトライやウォームアップなしでシリアルに実行されます。最初の実行が未完了になった後、後続のレプリカは宣言されたまま not_started になります。失敗したネイティブレシートには、計画されたリクエストがすべて保持されます。子の生ハッシュは、凍結された型付きリクエストを使用するため、正確に null のままです。マニフェストは元の入力バイト列も個別にバインドします。SLO 違反と不明なターゲットはネイティブレシートに保持され、実行全体が未完了になることはありません。

--campaign-timeout は、受付、事前確認、メタデータ、スケジュール済み再生を対象とします。ネイティブ停止を通知し、後続の受付を防ぎます。ドレインは協調的に行われ、無期限に続く場合があります。SIGINT を受けると停止レシートが生成されます。外部による非同期タスクのキャンセルは、所有タスクのクリーンアップ後に伝播します。終了コード 0 は宣言されたすべてのレプリカが完了したこと、1 は対象群の実行が未完了または停止したこと、2 は入力の形式不正または出力エラーを示します。シリアル実行では、独立性やコールドキャッシュの動作は証明できません。キャンペーン API とライフサイクルの契約を参照してください。

score -- 凍結された予測スコアカード（0.66.0 以降）

Chimeraforge 0.66.0 以降を使用します。score-policy.json で計画にバインドされた対象群と相対誤差範囲を宣言し、保存済みのエビデンスをオフラインでスコアリングします。

chimeraforge score --plan plan.json --policy score-policy.json --benchmark plan-benchmark.json --out scorecard.json --json

スコアラーは、再計画や係数の置き換えを行わず、保存済みの候補予測を読み込みます。ネイティブ対象群、レート、サービングバインディングを再計算し、生成側の監査上の主張は信頼しません。スコアリング対象となるのは、Ollama サーバーの単一ストリームのデコードレートのうち適格なものだけです。誤差は (prediction - measured) / measured で計算します。欠落、余分、不一致、利用不可、重複のエビデンスは、すべて確認できる形で残ります。対象群が完了し、誤差が包含境界内に収まる場合は終了コード 0、他に未完了の行があっても比較可能な違反がある場合は終了コード 1、入力形式不正は終了コード 2、エビデンス未完了は終了コード 3 になります。実 CPU または部分的なハードウェアメタデータでは、モデル化された GPU 予測の適格条件を満たせません。これは条件付きの算術処理であり、物理的な認証やキャリブレーション GO を伴いません。ポリシーの設定、API、適格性の制限を参照してください。

eval -- 品質評価

chimeraforge eval --task general_knowledge --json
chimeraforge eval --predictions preds.txt --references refs.txt --model llama3.2-3b

メトリクス：完全一致、ROUGE-L（LCS フォールバック）、BERTScore、コヒーレンス → 複合スコア（0.2*EM + 0.3*ROUGE + 0.3*BERT + 0.2*coherence）。品質ティアは TR125 に基づきます。組み込みタスクは 3 種類（general_knowledge、summarization、code）です。低下ティアを分類するには --fp16-baseline を渡します。

compare -- ベンチマーク実行の差分比較

chimeraforge compare --baseline run1.json --candidate run2.json,run3.json --json

（model、backend、quant、workload、context_length）で構成を照合し、スループット／TTFT／所要時間の差分を計算して、改善または後退の集計サマリーを生成します。

refit -- プランナー係数の更新

chimeraforge refit --bench-dir ./results/ --output fitted_models.json --validate

ベイズブレンディング（キーごとの信頼度重み付け）、ハードウェアオフセット、べき乗則の再フィッティング、および書き込みをゲートする 10 項目の検証スイート（--validate）を実行します。

report -- レポートの生成

chimeraforge report --results-dir ./results/ --format markdown --output report.md

Markdown（GitHub 互換）と、単体で動作し XSS 対策済みの HTML を生成します。構成ごとのパーセンタイル表を含む統計分析（RMSE、MAE、MAPE、R^2）を行います。

serve -- ローカルプランニング HTTP API

chimeraforge serve --port 8765 を実行すると、検証済みプランナーがループバック HTTP 経由で公開されます。デフォルトではオフラインです。POST /v1/plan は保存済みプランのアーティファクトを返し、形式不正な入力には構造化エラーを返します。ローカル API の契約を参照してください。

mcp -- AI アシスタント向けにプランナーを提供

chimeraforge mcp
chimeraforge mcp --transport streamable-http --port 8766

上記の MCP サーバーを実行します。デフォルトは stdio で、Streamable HTTP は明示的に指定するループバックオプションです。pip install "chimeraforge[mcp]" が必要です。

---

モデル化の対象

項目	算出方法	データの由来
VRAM／KV キャッシュ	実際のモデルアーキテクチャに基づく第一原理計算。KV 量子化と TP／PP を考慮したシャーディング、MLA／SWA のキャッシュ形状に対応。ハイブリッドモデルではアテンション層のみキャッシュし、系列ごとに再帰状態を保持	導出（厳密な算術）
最大同時実行数	GPU あたりの KV キャッシュで上限が決まる系列数	厳密
スループット（デコード）	参照環境での実測値を参照し、それ以外では帯域幅に応じてスケーリング。それ以外はルーフラインモデルを使用。extrapolated の値には、その基準となる行、環境、比率を付記	実測／外挿／推定
TTFT（プリフィル）	計算律速（GPU の FP16 TFLOPS × MFU）で算出し、メモリ律速の重み読み込み時間を下限とします。チャンク化プリフィルには --max-num-batched-tokens を使用	推定
品質	実測複合指標の参照値、ファミリーに基づく事前推定、または不明。すべてのセルにサンプル数と、そのサンプル数で判別可能な最小差を付記します。--quality-from で実際の lm-evaluation-harness の実行結果を取り込みます	実測／推定／不明
コスト	GPU の時間単価（$／時間）×台数（$／100 万トークンはレプリカ数によらず一定）	導出（厳密な算術）
エネルギー	TDP に基づく月間 kWh、$／100 万トークン（エネルギーコスト込み）、W あたりのトークン数／秒	推定
炭素排出量（オプトイン）	エネルギー量 × 電力網の排出原単位（OWID 経由の Ember ライフサイクル gCO2e／kWh、国・年別）。SCI の運用項目のみ	推定
安全性	TR134／TR142 の拒否率参照値（オプトインのゲート）	実測／不明

ハードウェア： GPU 50 種：

• コンシューマー向け： Ampere／Ada／Blackwell（RTX 30／40／50 シリーズ）および AMD RDNA4（RX 9070／9070 XT／9060 XT）。
• ワークステーション向け： RTX PRO 6000 Blackwell（Workstation、Max-Q、Server）、Radeon AI PRO R9700、Intel Arc Pro B60／B65。
• データセンター向け： A100 40／80GB、H100、H200、B200、L4、T4、AMD MI300X／MI325X／MI350X／MI355X／MI455X。
• ユニファイドメモリ： 現在販売中のすべての Mac に搭載された Apple Silicon チップ（GPU コア構成別の A18 Pro、M4、M5、M5 Pro／Max／Ultra、M6）に加え、AMD Ryzen AI Max+ 395 と NVIDIA DGX Spark。

各 GPU について、VRAM、帯域幅、FP16 TFLOPS、TDP、インターコネクト（NVLink／Infinity Fabric／PCIe）を記載しています。また、出典 URL、取得日、TFLOPS 値の元となったデータシートの列、$/hr がレンタル料金か購入費の償却額かも記載しています。

ユニファイドメモリデバイスでは、CPU と GPU がメモリプールを共有するため、プール全体を VRAM として扱うことはありません。

• --unified-memory-fraction で GPU が使用できる割合を指定します。OS や他のアプリにもメモリが必要なため、デフォルト値はなく、指定が必須です。
• 各エントリーには、販売されているすべてのメモリ構成を記載しています（M5 Max の 40 コア GPU には 48、64、128 GB の構成があります）。名前付きプランでは最大容量を想定し、その旨を明記します。--gpu-vram-gb で修正できます。--hardware auto は搭載メモリを使用します。
• プランでは、CPU と GPU が帯域幅を共有するため、デコード速度は上限値であることを警告します。
• Apple Silicon のプランには、vLLM が CPU 専用となる macOS の行を使用し、Strix Halo には ROCm の行を使用します。

ベンダーが公開していない値は不明のままとし、不明をゼロとして扱いません。

• 価格なし（RTX PRO 6000、Instinct、Arc Pro、R9700）：予算ゲートは価格を $0 とみなすのではなく、該当カードを拒否します。--gpu-price-per-hour を指定してください。
• 密な FP16 値なし（Arc Pro、および「1 PFLOP」のラベルが付いていない RTX PRO 6000 Server Edition）：TTFT はメモリ律速の下限値として報告され、その下限値を根拠とする --ttft-slo は拒否されます。scripts/build_hardware_data.py で再生成・検証してください。リストにない GPU も、もはや障壁にはなりません。--gpu-vram-gb と --gpu-bandwidth-gbps（および任意の --gpu-fp16-tflops／--gpu-tdp-w／--gpu-interconnect-gbps／--gpu-price-per-hour）を指定すれば、任意のカードをプランに使用でき、--hardware auto は搭載カードを読み取ります。 既知の制限事項（正直な説明）： 投機的デコーディングはまだモデル化されていません。プリフィルの下限は MBU_DEFAULT から導かれる上限値で、単一のデータポイントを基に調整されています。「予測値」ではなく、「これより速くはならない」と解釈してください。チャンク化プリフィルのオーバーヘッドは、この仕組みが伴う KV の再読み込みから導き、公開されている唯一の上限値（512 トークンの予算で 25％、Sarathi-Serve arXiv:2403.02310）でクランプしています。タイル量子化の急激な性能低下（257 トークンの予算では 256 トークンの場合より約 32％遅いことが測定されています）は実際に起きるもので、顕著ですが、意図的にモデル化していません。代わりにプランナーが警告します。プレフィックスキャッシュではプリフィルの削減分をモデル化しますが、KV の削減分はモデル化しません（意図的に保守的な見積もりです）。推論トークンはモデル化されますが、その比率は入力値（--reasoning-tokens）であり、推定されることはありません。MoE では有効パラメーター数と総パラメーター数の違いをモデル化していますが、エキスパート並列処理とルーティング負荷の偏りはモデル化していません。ハイブリッドモデルでは、アテンション層の内訳と Mamba-2／Mamba-1／gated-DeltaNet の再帰状態をモデル自身の設定から読み取り、transformers のソースにある形状情報から導出します。Kimi の KDA 状態は DeltaNet の慣例から推定しており、その旨を明記しています。また、レイヤーパターンを特定できないモデルファミリー（並列ハイブリッドである Falcon-H1 など）では、推測せず、すべてのレイヤーに完全な KV を保持します。Multi-LoRA ではアダプターの VRAM 使用量を正確に算出しますが、デコードコストは公開された単一の測定結果から得たランク別の推定値であり、アダプターごとの KV の断片化はモデル化していません。異種構成の GPU 群では割り当てを正確に求めますが、現在どのエンジンも提供していないリクエストルーターを想定しており、構成に含まれるすべての GPU 種類のスループット推定誤差を引き継ぎます。vLLM／TGI／SGLang の量子化対応範囲は FP16 と FP8、AWQ／GPTQ です。FP8 と W4A16 の品質は測定値ではなく推定値です。TR 品質コーパスが対象とするのは GGUF の k 量子化のみです。同梱の品質コーパスは 20 件で、約 21 パーセントポイント未満の差は判別できません（Miller、arXiv:2411.00640 式 9）。そのため、コーパス内で測定された量子化による差分はすべて、差があるのではなく FP16 のベースラインと区別できないものとして報告されます。実際のハーネスを実行し、--quality-from で渡せば、差を判別できるセルを得られます。品質はコンテキスト長 2K で測定され、損失が 59％に達する公開結果がある 64K 以上では、低ビット量子化の品質は UNKNOWN として報告されます（arXiv:2505.20276）。TP と PP のスループットは通信モデルに基づく推定値であり、測定値ではありません。また、1 つのプランに組み合わせることはできません。キューイングは分散を考慮した解析的手法であり、離散イベントシミュレーターではありません。同梱のコーパスは主に 1 台の構成（RTX 4080 12GB）で調整されています。他の GPU については、ユーザーが自分の環境で measure するまで、帯域幅と演算性能に基づいてスケーリングします。このスケーリングの誤差は、推測ではなく公開されています。サードパーティーのベンチマークと比較すると、ルーフラインモデルは HBM 搭載製品では楽観的（デコードの中央値で +58％）、GDDR カードでは悲観的（中央値で -36％）であり、TTFT の誤差は逆方向です（TR147）。ユニファイドメモリー搭載デバイスでは、ユーザーが指定したプールの割合で計画します（--unified-memory-fraction。デフォルト値はありません）。OS の予約分はユーザーが指定します。CPU と GPU は同じ帯域幅を共有するため、デコード性能は上限値です。また、ベンダーは GPU の FP16 性能もデバイスごとの価格も公開していません。プラットフォームごとのエンジン対応状況は各エンジンのドキュメントに基づいて判定しますが、デプロイ先の OS は入力値（--platform。デフォルトは linux）であり、プランナーが自動的に検出するものではありません。エンジンのドキュメントに特定のプラットフォームについての記載がない場合、プランは拒否されず、警告されます。ユーザー指定のカードではベンダーが不明なため、エンジンの対応状況は確認されず、すべての候補にその旨が記載されます。--hardware auto はベンダーごとの doctor プローブを通じてローカル GPU を読み取り、--platform で別途指定されていない限り、このマシンの OS 向けにプランを作成します。Mac では、auto はチップと搭載メモリーを照合し、その構成で販売されているモデルに合わせます。MCP は stdio と、オプトイン方式のループバック Streamable HTTP トランスポートに対応しています。HTTP はデフォルトでオフラインであり、セッション数とワーカー数に上限があります。また、一般公開されているサービスではありません。タイムアウトした同期処理は、完了するまでワーカーを占有します。

---

調査で明らかになったこと

フェーズ 2（TR123-TR133、約 106,000 件の測定）から、成果物に基づくデプロイフレームワークを導き出しました。これはプランナーが適用するルールと同じです。

判断	推奨事項	根拠
単一エージェントのバックエンド	Ollama Q4_K_M	1 ドルあたりのスループットが最高。品質の低下は -4.1pp 以内（TR123-TR125）
マルチエージェントのバックエンド（N>=4）	vLLM FP16	継続的バッチ処理により 2.25 倍の優位性（TR130-TR132）
コンパイル方針	プリフィルのみ、Linux、Inductor+Triton	24～60% 高速化。デコードは 100% クラッシュ（TR126）
量子化	デフォルトは Q4_K_M。品質重視の場合は Q8_0。Q2_K は使用しない	5 つのモデルすべてで最適なバランス（TR125）
コンテキスト予算	12 GB で 4K トークンを超える場合は Ollama	VRAM のあふれにより性能が 25～105 倍低下（TR127）
キャパシティプランニング	chimeraforge plan	R^2>=0.859 を検証済み。M/D/1 を 20.4 倍上回る（TR133）
安全性スクリーニング	plan --safety-target（オプトイン）	設定ごとの拒否率と RTSI リスクを評価。安全性が崩れる構成を除外（TR134/TR142）

主な調査結果（全データは TR を参照）：単一エージェントでは Rust が Python を上回る（スループットが +15.2%、TTFT が -58%、メモリが -67% ― TR112）。Ollama を 2 インスタンスで実行すると、マルチエージェントの並列性はほぼ完全な水準（約 99%）に達するのに対し、1 インスタンスでは 82.2%（TR110/TR113/TR114）。vLLM の継続的バッチ処理は N=8 で 2.25 倍の優位性を発揮します。ボトルネックはスタックではなく GPU メモリ帯域幅です（TR130-TR132）。

調査の全容： docs/archive/technical_reports.md に全 32 件のレポートがまとめられています。方法論と生データへの参照を含むアーカイブ全体は outputs/publish_ready/reports/ にあります。

---

数値の算出方法

• 約 204,000 件の主要測定値は、RTX 4080 Laptop（12 GB、192-bit GDDR6、432 GB/s）を使用した 32 件のテクニカルレポート（TR108-TR137、および安全性の来歴に関する TR142/TR146）全体のものです。このマシンを基準機として、GPU 間のすべての推定値を換算しています。重複は除外済みです。TR137/TR142 は、すでに集計済みのデータを統合したものです。プランナー独自の参照テーブルはその一部（スループットの 23 行）にすぎません。その正確な規模は、導入部の表に記載されています。
• 厳密性： 実行ごとに新しいプロセスで分離（ウォームキャッシュによる偏りを排除）、コールドスタートを強制、統計的な信頼性を確保するため設定ごとに 3～5 回実行し、完全な来歴を含む構造化 JSON/CSV ログを記録しています。すべての主張は、再実行可能な生データまでたどれます。
• プログラムの背景： ChimeraForge は、親プログラム Banterhearts（54 件の TR にわたる主要測定と判定測定を合わせて約 1,337,000 件）の知見を実用的な CLI に統合したものです。安全性の攻撃対象領域とサービングスタックに関する調査は、関連する別のリポジトリで行われています。
• 自動テストは 3,828 件（pytest --collect-only tests/ で収集）あり、プランナーモデル、ゲート検索、リゾルバー、検出、安全性、ベンチマークバックエンド、MCP サーバーを対象としています。GPU に依存せず、コアテストスイートの実行に稼働中のバックエンドは不要です。日付付きの収集結果とコンシューマーチェック では、テストの収集と実行を区別しています。前回のローカル全件実行 では、3,798 件が成功し、3 件がスキップされました。

数値を再現するには、outputs/publish_ready/reports/ 内のレポートで主張を探し、参照先のデータフォルダーを確認して CSV/JSON を調べ、提供されているスクリプトまたはノートブックを再実行してください。docs/archive/methodology.md を参照してください。

リポジトリの構成

パス	内容
src/chimeraforge/	chimeraforge CLI とキャパシティプランナー（pip パッケージ）
src/python/banterhearts/	Python エージェントのベンチマーク、モニタリング、プロファイリング
src/rust/	Rust によるシングルエージェントおよびマルチエージェントの実装（Tokio と 4 つの代替ランタイム）
outputs/publish_ready/reports/	正式な TR アーカイブ（TR108～TR137）と統合レポート――調査結果はこちらから
docs/	ガイド、API リファレンス、技術レポートのインデックス――使い方はこちらから
experiments/、data/、benchmarks/	再現用の足場、ベースライン、生のベンチマーク成果物

ドキュメント

• docs/README.md -- ドキュメントのインデックスとナビゲーション
• docs/quick_start.md -- 最初のベンチマーク実行（Python + Rust）
• docs/API.md -- パッケージの Python API リファレンス
• docs/archive/technical_reports.md -- 全 32 件の技術レポートのインデックス
• docs/archive/dual_ollama_setup.md -- マルチエージェントの結果を再現するために必要です
• docs/archive/methodology.md / docs/archive/rust_vs_python.md -- 方法論と、言語間の比較全体

コントリビューション

コントリビューションを歓迎します。詳細は CONTRIBUTING.md をご覧ください。取り組みやすい領域：追加のベンチマーク設定、新しい最適化戦略、より多くのモデルやハードウェア、ドキュメント、分析ツール。

ライセンス

MIT -- 詳細は LICENSE をご覧ください。

謝辞

電力の炭素強度データ：Ember の Yearly Electricity Data（2026）を Our World in Data（energy-data、Ritchie、Rosado、Roser）が処理したもの。いずれも CC BY 4.0 です。バンドルされたスナップショットには、データを取得した時点の正確な OWID コミットが記録されています。

Banterhearts LLM Performance Research Program の一環として実施しました。フェーズ 1（TR108-TR122）では測定方法と言語間の比較を確立し、フェーズ 2（TR123-TR133）ではデプロイメントフレームワークとキャパシティプランナーを作成し、フェーズ 3（TR134-TR137）では推論最適化による安全性コストを測定しました。これは現在、プランナーのオプトイン式安全性ゲートとなっています。

---

リポジトリ： https://github.com/Sahil170595/Chimeraforge - PyPI： https://pypi.org/project/chimeraforge/ - ステータス： ベータ版、活発に開発中

保存済みプランと Python 統合

chimeraforge plan --model-size 3b --no-network --save plan.json は、有効な入力、解決済みの事実、候補の来歴を、バージョン管理された成果物として保存します。検証済みの Python API は PlanRequest を受け取り、同じプランニングコアの結果を返します。API と成果物の仕様をご覧ください。