OpenMythos 入門：Claude Mythos 循環推論アーキテクチャに基づくオープンソース実装

プロジェクト概要

2026 年 4 月、Anthropic は Claude Mythos をリリースしました。これは Claude シリーズの次世代推論モデルであり、ソフトウェアエンジニアリング、ネットワークセキュリティ（特にゼロデイの発見と悪用）といったタスクで、前例のない能力を示しています。ただし Mythos は現状、「Project Glasswing」を通じて一部の防御的セキュリティ研究パートナーに限定公開されているだけで、全面的なリリースには程遠い状況です。

OpenMythos は、そうした閉じたアーキテクチャに対するコミュニティのオープンソースでの応答です。独立開発者の Kye Gomez が、公開論文や研究文献を基に、第一原理から Mythos の中核アーキテクチャを再構築しました。これは公式版でもなく、重みの流出でもありません。理論上の再構築（theoretical reconstruction）——研究者や開発者が、近い発想を実験的に検証できることを目的としています。

その核心のブレイクスルーが Recurrent-Depth Transformer（RDT） です。これは同一の Transformer 重みを、単一のフォワード（前向き計算）で最大 16 回まで（設定可能）繰り返し実行し、従来のように数百層分の独立した重みを積み重ねるのではなく、連続する潜在空間の中で反復的に「思考」を行います。770M パラメータの循環モデルは、約 1.3B の標準 Transformer と同等の品質に到達できます——同じ能力を、パラメータを半分以下に抑えて実現するわけです。

---

難易度 / 所要時間 / 得られること

入門レベルの難易度で、約 30 分。最初の OpenMythos のフォワードを動かし、循環推論の本質、LTI 安定注入の原理、そして MoE FFN が「活性（activation）パラメータを増やさずに」モデルの幅を拡張する仕組みを理解できます。

---

対象読者

LLM アーキテクチャを基礎的に理解しており、「循環推論」メカニズムとその実装を深掘りしたい 1〜5 年の経験のある開発者向けです。以下の問いに興味があるなら、OpenMythos は良い出発点になります：

• 「より多くの循環＝より深い推論」という考え方そのものに理論的な裏付けがあるのはなぜか
• LTI の力学的制約が、循環学習の発散をどう抑えるのか
• MoE + 循環重み共有が、パラメータ量と計算量の間の新しいバランスポイントをどう見いだすのか

---

コア依存関係と環境

• Python 3.10+
• PyTorch 2.0+（CUDA 対応が推論を高速化）
• 任意：flash-attn >= 2.8.3（GQA 注意を高速化、IO を最適化）
• 最低要件：CPU で toy demo は動作可能、GPU なら完全な学習が可能

# CPU only
pip install open-mythos

# with Flash Attention 2 (requires CUDA + build tools)
pip install "open-mythos[flash]"

---

完全なプロジェクト構成

open_mythos/
├── main.py              # コア：OpenMythos クラス、MythosConfig、全アーキテクチャ構成要素
├── moda.py              # MoE / LoRA などのモジュール
├── tokenizer.py         # MythosTokenizer（openai/gpt-oss-20b をラップ）
├── variants.py          # 事前設定スケール：mythos_1b 〜 mythos_1t
├── docs/
│   ├── open_mythos.md   # 完全な API 参照ドキュメント
│   └── datasets.md      # 学習データセット選定の提案
training/
└── 3b_fine_web_edu.py   # 3B モデルの単一カード / 複数カード学習スクリプト
examples/
├── moda_example.py          # MoE FFN + LoRA Adapter のデモ
└── variants_example.py     # 複数スケールのバリアントでのパラメータ比較
tests/
├── test_main.py             # コアモジュールのユニットテスト
├── bench_vs_transformer.py  # 標準 Transformer とのベンチマーク比較
└── small_benchmark.py       # 小規模の性能ベンチマーク

---

ハンズオン手順

手順 1 — インストール

pip install open-mythos

手順 2 — 設定の構築

すべてのハイパーパラメータは MythosConfig に渡します。いくつかの重要フィールドを理解しましょう：

from open_mythos.main import MythosConfig

cfg = MythosConfig(
    vocab_size=1000,        # 語彙サイズ。demo は小さな語彙
    dim=256,                # 隠れ層の次元
    n_heads=8,              # Query ヘッド数
    n_kv_heads=2,          # KV ヘッド数（GQA：Q ヘッドより少なくすると显存を節約）
    max_seq_len=128,        # 最大シーケンス長（RoPE の事前計算上限）
    max_loop_iters=4,       # 循環深度 T（推論時に上げられる）
    prelude_layers=1,       # Prelude 部分の標準 Transformer 層数
    coda_layers=1,          # Coda 部分の標準 Transformer 層数
    attn_type="mla",        # "mla" または "gqa"（手順 5 を参照）
    n_experts=8,            # MoE ルーティングの専門家（エキスパート）総数
    n_shared_experts=1,     # 常駐エキスパート数（各 token で有効化される）
    n_experts_per_tok=2,    # 各 token で有効化される top-K エキスパート数
    expert_dim=64,          # 各エキスパートの隠れ次元
    lora_rank=8,            # 深い LoRA adapter のランク
)

MythosConfig にはデフォルトのコンストラクタがあり、単に MythosConfig() とするだけで、いくつかの中規模なプリセット値が使用されます。

手順 3 — モデルを初期化してフォワード推論を実行

import torch
from open_mythos.main import OpenMythos, MythosConfig

cfg = MythosConfig()
model = OpenMythos(cfg)

# パラメータ数を集計
total = sum(p.numel() for p in model.parameters())
print(f"Parameters: {total:,}")

# フォワード：input_ids の shape (B, T)、logits の shape (B, T, vocab_size)
ids = torch.randint(0, cfg.vocab_size, (2, 16))   # batch=2, seq=16
logits = model(ids, n_loops=4)                    # 4 回の循環推論
print(f"Logits shape: {logits.shape}")            # torch.Size([2, 16, 32000])

n_loops は循環深度を制御します。デフォルト値は cfg.max_loop_iters に由来します。推論時は必要に応じて上げられます——これが RDT の重要な特徴です：深度外挿（depth extrapolation）。つまり、学習時は N 回のループで学習し、推論時には N+k 回使って、より複雑な問題を扱えるということです。

手順 4 — 自己回帰による生成

# 新しいトークンを生成（最大 8 個）、循環深度 8
out = model.generate(ids, max_new_tokens=8, n_loops=8)
print(f"Generated shape: {out.shape}")  # torch.Size([2, 24])

generate メソッドの内部では KV cache を維持します。最初の呼び出しでは完全なプロンプトを処理し、その後の各ステップでは 1 トークンだけデコードします。temperature はサンプリングのランダム性を制御し、top_k はサンプリング対象の範囲を制限します：

out = model.generate(
    ids,
    max_new_tokens=64,
    n_loops=16,
    temperature=0.8,   # 値が低いほど確定的
    top_k=40,          # 0 = 無効化
)

手順 5 — 注意メカニズムを選択：MLA vs GQA

# Multi-Latent Attention（デフォルト、長いコンテキスト向けに推奨）
cfg_mla = MythosConfig(
    attn_type="mla",
    kv_lora_rank=512,      # キャッシュする KV 潜在次元（小さいほど显存を節約）
    q_lora_rank=1536,      # Q の圧縮次元
    qk_rope_head_dim=64,   # RoPE を使う各ヘッドの次元
    qk_nope_head_dim=128,  # RoPE を使わない各ヘッドの次元
    v_head_dim=128,
)

# Grouped Query Attention（显存にやさしい。flash-attn 併用で効率が高い）
cfg_gqa = MythosConfig(
    attn_type="gqa",
    n_kv_heads=4,         # n_heads より少なく（KV キャッシュが n_heads/n_kv_heads 分だけ縮小）
)

それぞれのトレードオフ：MLA は KV を低ランクの潜在ベクトルとしてキャッシュに圧縮し、显存を約 10〜20 倍削減しますが、その代わり毎回 K/V を再構築する必要があります（1 回の線形投影）。GQA は完全な KV ヘッドをそのままキャッシュし、Flash Attention 2 と組み合わせることで IO が最適になります。プロダクション規模では MLA が显存面で有利で、開発段階では GQA の方がデバッグが簡単です。

手順 6 — 循環の安定性を検証：スペクトル半径チェック

RDT の学習で最も起きやすい問題は、循環が発散することです——隠れ状態が各循環で指数関数的に増幅します。OpenMythos は LTI 安定注入 により、構造的に安定性を保証します。検証方法はスペクトル半径 ρ(A) を調べることです：

# 離散化された状態行列 A_discrete を取得
A = model.recurrent.injection.get_A()           # shape (dim,)
rho = torch.linalg.eigvals(A).abs().max().item()

print(f"Spectral radius ρ(A) = {rho:.4f}")
assert rho < 1.0, f"Unstable: ρ(A) = {rho:.4f} >= 1"

手順 7 — プリセットされたスケール・バリアントを使う

MythosConfig を手で組むのが面倒？ variants.py には 1B から 1T までのプリセットが用意されています：

from open_mythos import mythos_1b, mythos_3b, mythos_10b, mythos_50b, mythos_100b

# mythos_7b() は MythosConfig を返す
cfg = mythos_3b()
model = OpenMythos(cfg)
print(f"Variant 3B: {sum(p.numel() for p in model.parameters()):,} params")

手順 8 — 学習スクリプトを実行

このプロジェクトには、FineWeb-Edu データセット上で 3B モデルを学習するスクリプトが組み込まれています：

# 単一 GPU
python training/3b_fine_web_edu.py

# 複数 GPU（GPU 数を自動検出）
torchrun --nproc_per_node=$(python -c "import torch; print(torch.cuda.device_count())") \
    training/3b_fine_web_edu.py

重要な学習設定：

# training/3b_fine_web_edu.py（重要パラメータ）
optimizer = torch.optim.AdamW(model.parameters(), lr=3e-4, weight_decay=0.1)
# 精度：H100/A100 は bfloat16、古い GPU は float16 + GradScaler
# スケジューラ：2000 ステップの warmup → 残りを cosine 減衰
# Tokenizer：MythosTokenizer 経由で openai/gpt-oss-20b

---

よくある問題の切り分け

1. 显存爆発：循環回数 × バッチサイズの組み合わせの罠

RDT の循環フェーズは、標準 Transformer の層間のように独立しません。各循環ステップで、すべての token の KV 状態が cache に蓄積されます。循環 16 回 × シーケンス 4096 × バッチ 8 の場合、显存の負荷は通常のモデルの数倍になります。

解法：まずは小さい n_loops（例：4）で検証し、収束したら徐々に増やします。バッチは固定ではなく、線形にスケールさせてください。

2. Flash Attention がないが高速化したい

flash-attn のコンパイルが失敗する場合（Windows + CUDA 環境でよくあるケース）、OpenMythos は自動的に PyTorch の標準注意実装へフォールバックします。なお、このフォールバックは正しさには影響しません。速度だけが変わります——小さめのバッチ条件では、その差は大きくありません。

3. スペクトル半径チェックが失敗：学習が発散

LTIInjection のパラメータ化を自分で変更した、または微調整で誤った層を freeze してしまい、注入パラメータが壊れていると、ρ(A) >= 1 が発生します。パラメータをそのまま clip しないでください。デフォルトの初期化へ戻して最初からやり直してください。LTI の制約は、パラメータ化された構造により支えられており、事後修正ではありません。

4. ACT の早期停止により、循環が本来より少ない

act_threshold=0.99 は、各位置で確率が 99% に達した時点で早期終了することを意味します。あるタスクで実際の循環回数が n_loops より大幅に少ない場合、データ中のトークンの難易度分布を確認してください。難しすぎないトークンは halting を早く引き起こし、複雑なトークンが十分な深さを得られないことがあります。

5. MoE ルーティングの崩壊：特定の専門家が永遠に起動しない

DeepSeekMoE 風の補助損失なし負荷分散は、router_bias の動的調整に依存しています。もし最初からこの調整ロジックを呼び出していない場合、ルータはすぐに少数の専門家だけを有効化する状態へ収束します（通常は最初の 1〜2 個）。プロジェクト内の MoEFFN.forward にはバイアス調整のプレースホルダは組み込まれていますが、カスタム学習スクリプトでは定期的にバイアス更新ロジックを呼び出す必要があります。

6. 生成品質が悪い：temperature と top_k の合わせ方

---

追加の読み物 / 進め方

中核となる論文

進展方向

1. カスタム LoRA Adapter：現在の lora_rank は全体で一律ですが、層ごとに設定できるようにして、異なる循環深度で異なる適応の強さを使えるようにできます。

2. ACT 閾値のスキャン：デフォルトの 0.99 は経験値です。0.8〜0.999 でグリッドサーチすると、タスクによっては 0.95 の方が 0.99 より良いことが分かります（早期停止が overthinking を回避）。

3. Depth Extrapolation 実験：固定 n_loops で学習し、推論時に n_loops をスイープして、「循環回数 → 下流タスクの精度」の曲線を描きます。理論上、指数減衰の形状が見えるはずです——これが RDT の最重要な検証可能性の一つです。

4. 標準 Transformer との比較：bench_vs_transformer.py スクリプトで、同じパラメータ量のもと、循環モデルと標準モデルの差を compositional / systematic generalization タスクで比較します。これが RDT の最も顕著な優位性が現れる状況です。