- A.T.L.A.S (Adaptive Test-time Learning and Autonomous Specialization) は、コンシューマ向けGPU 1基で大規模モデル級のコード生成性能を実現するセルフホスト型AIシステム
- LiveCodeBench v5で74.6% pass@1-v(k=3) を記録し、Claude 4.5 Sonnet(71.4%) を上回り、前バージョン比でほぼ2倍の性能向上を達成
- 14Bパラメータモデル(Qwen3-14B-Q4_K_M) を凍結したまま、制約ベース生成、自己検証・修正ループ、Geometric Lensによる候補選択で高性能を確保
- クラウドやAPI呼び出しなしにローカル環境で完全自律実行され、コストは電気代のみのため、APIベースモデルと比べてコスト効率が非常に高い
- RTX 5060 Ti 16GB GPU 環境で約2時間以内に599件の課題を処理し、大規模モデルのコード生成能力を個人向けハードウェアで再現可能
ベンチマーク結果
- LiveCodeBench v5: 74.6% pass@1-v(k=3)、599件の課題を実行
- V3パイプライン: PlanSearch + self-verified PR-CoT repair
- GPQA Diamond: 47.0%、198件の課題
- SciCode: 14.7%、341件の課題
- pass@k-v(k=3) は単一試行の結果ではなく、3つの候補生成後にLensで選択し、失敗時には反復修正を含む方式
-
V3段階別の寄与度 (Ablation Study)
- A: 基本形 (V3未適用) → 54.9%
- B: Phase 1 (PlanSearch + BudgetForcing + DivSampling) → 67.3% (+12.4pp)
- C: Phase 1+2 (Lens routing) → 67.3% (+0.0pp)
- D: Phase 1+3 (self-verified refinement) → 74.6% (+7.3pp)
- Phase 3ではモデルが自ら生成したテストケースで内部検証を行い、実際の正解は使用しない
- PR-CoTはPhase 3で42件中36件(85.7%)の問題を復旧
コストと性能の比較
| システム |
LCB pass@1 |
課題あたりのコスト |
備考 |
| DeepSeek V3.2 Reasoning |
86.2% |
~$0.002 |
API、単一試行 |
| GPT-5 (high) |
84.6% |
~$0.043 |
API、単一試行 |
| ATLAS V3 |
74.6% |
~$0.004 |
ローカル電力のみ使用、best-of-3 + repair |
| Claude 4.5 Sonnet |
71.4% |
~$0.066 |
API、単一試行 |
| Claude 4 Sonnet |
65.5% |
~$0.066 |
API、単一試行 |
- ATLASは電気代のみで、APIコストは不要
- 165W GPU 基準で599件の課題実行に約1時間55分を要する
- レイテンシは長いが、コスト効率は非常に高い
動作原理
-
全体パイプライン
- Phase 1: Generate
- PlanSearch: 制約抽出と多様な計画生成
- Budget Forcing: トークン使用量の制御
- Verify段階
- Geometric Lens (C(x)): 5120次元の自己埋め込みベースのエネルギースコアリング
- Sandbox: コード実行と検証
- Phase 3: Repair
- Self-Test Generation: モデルが自ら入出力ペアを生成
- PR-CoT Repair: 多視点チェーン・オブ・ソートに基づくコード修正
- 単一のllama-serverインスタンスがK3s上で動作し、speculative decoding と 自己埋め込み生成を同時に実行
- Geometric Lens は候補の中から最適なコードを選択 (混合結果課題で87.8%の精度)
- 失敗した課題はPhase 3へ移行し、自己テスト生成と反復修正を実行
インストールと実行
- GitHubリポジトリをクローン後、設定ファイルをコピーしてインストールスクリプトを実行
benchmark/v3_runner.py でV3ベンチマークを実行- 詳細なインストール手順はdocs/SETUP.md を参照
ハードウェアと再現
| リソース |
最小 |
テスト環境 |
| GPU VRAM |
16 GB |
RTX 5060 Ti 16 GB |
| システムRAM |
14 GB |
16 GB |
| Python |
3.10+ |
3.11 |
| OS |
RHEL 9 / Ubuntu 24 |
RHEL 9 (Proxmox VM) |
- Proxmox VM + VFIO GPUパススルー環境で再現
- 16GB以上のVRAMを持つ他のNVIDIA GPUでも可能だが、ドライバおよびVRAM設定の調整が必要
- 主な調整変数:
--parallel スロット数 (デフォルト2、VRAM不足時は1に減少)- KVキャッシュ量子化(Q4_0)
- スロットあたりのコンテキスト長(デフォルト20480トークン)
- CUDA 12.8バージョンでテスト完了
- V3.1 で移植性の改善を予定
ロードマップ
-
V3.0 (完了、2026-03-05)
- Qwen3-14B-Q4_K_Mベース、74.6%のLCB性能
- PlanSearch + BudgetForcing + Geometric Lens + PR-CoTパイプラインを完成
-
既知の限界
- LCB専用最適化: GPQA、SciCodeなど他ベンチマークへの最適化は不十分
- Phase 2 (Lens routing): データセット不足で効果が小さい (+0.0pp)
- G(x) metric tensor無効化: C(x)未学習のため有意な幾何構造がない
- 単一スレッド処理: 課題の並列化を未サポート
- SandboxAdapter stdioバグ: 入力区分機能が無効化されている (V3.1で修正予定)
-
V3.1 (進行中)
- モデル置き換え: Qwen3-14B → Qwen3.5-9B (DeltaNet線形アテンション、3〜4倍の高速化)
- Lens再学習: リアルタイムフィードバックに基づくC(x)の再較正
- Phase 2再設計: G(x)の再実装または削除、SandboxAdapterバグ修正
- 並列処理導入: 課題の並列実行で処理速度を向上
- 拡張ベンチマークスイート: コーディング以外の推論・知識評価を含む
-
予定されているV3.1ベンチマーク
- コーディング: LiveCodeBench v5、SciCode、追加の汚染耐性データセット
- 推論/知識: GPQA Diamond、AA-LCR、AA-Omniscience、Humanity’s Last Exam、CritPt など
- Confidence Router が課題難易度に応じて経路を選択:
- 単純な問い合わせ → RAGベースの高速推論 (~30秒)
- 複雑なコーディング問題 → 全体パイプライン (~20分)
- 目標: 80〜90% LCB pass@1-v(k=3) と さらなる高速処理
ライセンス
- A.T.L.A.S Source Available License v1.0 を適用
1件のコメント
Hacker Newsの意見
私はエージェントに大きなコードブロックの生成は期待していない
その代わり、ログを追ったり複数のソースファイルを分析して、テスト失敗の原因を説明させるのにはるかに有用だ
こうした能力を評価するデバッグベンチマークが必要だと思う。ビルドシステムやCLIの習熟度を測るテストがあるとよい
たとえばアプリ全体を hard delete から soft delete にリファクタリングしたが、削除ロジックとクエリの両方を修正する必要があった
手作業だと退屈でミスしやすいが、エージェントが素早く処理してくれて本当に助かった
SWE Bench Pro はまだ過度に最適化されておらず、信頼できる
一方で通常の SWE や LCB は、すでに数値の吊り上げ競争になっていて実効性が低い
参考までに、私は Quesma の創業者だ
もう会社の仕事でもサイドプロジェクトでも、自分でコードをほとんど書かない
主に Rust と TypeScript で開発者ツールを作っている
kubectl / helmでデプロイし、問題が起きたらエージェントが直接デバッグする
何時間もかかっていた作業が一瞬で終わるので、驚くほどだ
開発者にはMiniMaxやKimiのようなモデルを実務で使ってみることを勧めたい
ただし欠点もすぐに見えてくる — 推論トークン使用量の増加、遅い出力、品質低下など
それでもモデルルーティングとreasoning budgetをうまく管理すれば、コストを大きく節約できる
アプリとプロンプトを最適化して出力トークンを減らすことも重要だ
ただ、難しい作業では単純なトークン単価より効率のほうが重要だ
リンク先にあるアプローチは Sonnet と Opus にも有効だ
ただし MiniMax や Qwen はまだそのレベルに達していない
結局のところ、どの作業にどのモデルが費用対効果に優れるかを見分けるハーネス設計が核心だ
Opus 4.6 medium を使ってみてすぐに後悔した。品質差が大きすぎる
aibenchy 比較結果
トークン使用量は気にしていない。月 10 ユーロのプランで 5 時間ごとに 1500 回リクエストできる
実際には Opus や Sonnet より遅くない
ベンチマークでは Anthropic のモデルのほうが良く見えるが、実際の作業では差はほとんどない
MiniMax が行き詰まったら Opus に切り替え、また MiniMax に戻ればいい
Opus は予算をすぐ消費するが、MiniMax は事実上無制限だ
Claude や GPT よりも問題を速く見つける
ただし文脈の一貫性の問題が深刻で、コードを書き換える際に小さな誤差が生じて全体を壊してしまうことがある
今は価格競争の終わりなきレースだ
DeepSeek が単一実行基準で全モデルに勝ち、コストもローカル電力の半分程度だ
複数の解答を生成し、小さなモデルで有望な候補を選んでテストし、フィードバックを繰り返す方式だ
一種の遺伝的アルゴリズムのように段階的に収束していく
小さなモデルはテスト向けに過度にファインチューニングされていて、実環境では性能がひどい
私はいつも懐疑的だ
ベンチマークは通っても、実際には汎用性が低いことが多い
それでもモデルをスリム化しようとする試み自体は興味深い
システムプログラミング（C++, Rust）では、依然として Sonnet 4.5 水準とは大きな隔たりがある
オープンモデルは構文エラーの修正に時間をかけすぎて、論理的一貫性を失うことが多い
ローカル GPU は十分に持っているが、クラウドモデルのライセンス問題も気になっている
複数のソリューションを生成し、それぞれのコードの埋め込みフィンガープリント（fingerprint）を計算して正確性を予測する
小さなニューラルネットワークであるCost Fieldがこれをスコア化し、最も可能性の高いコードを選ぶ
そのおかげでテスト時間を減らしつつ、88% の精度で正しい解答を選べる
むしろ大きなモデルのほうが構造的に単純かもしれない
読んでいる間に GPU の価格が**$1000**になってしまった
この AI が書いたプロジェクトは、LiveCodeBenchとはまったく異なるやり方で独自ベンチマークを回している
README には、ATLAS スコアは 599 件の LCB タスクに基づく**V3 パイプライン（best-of-3 + Lens + iterative repair）**の結果だと明記されている
一方で競合モデルのスコアは単一実行（pass@1）基準なので、比較が不公平だ
Sonnet や GPT5.4 も同じ方式でテストすれば、さらに高いスコアを出せるはずだ
README には実際には使われていない構造が多く、AI 自動生成コードの粗さが露呈している
こうしたベンチマークが問題専用の最適化にしか効かないのではないかと気になる
結局、私たちは汎用性を圧縮できない限界を学ぶことになるだろう
「Geometric Lens routing」という表現は妙に違和感がある
ただ GPT が作った用語みたいに聞こえる
懐疑的ではあるが、こうしたオープンモデルの実験は本当に歓迎したい
中上級クラスの PC でもローカルでモデルを動かせるなら、大きな前進だ