Astra以降:ループ型トランスフォーマーがAIインフラ経済をどう変えるか

Lablup CEOシン・ジョンギュの考察を出発点に、Huginn・Ouro・MoR研究を読み解き、パラメータ効率・計算・メモリ・サービング費用を切り分ける。

同一のニューラルネットワークを繰り返し通過させることで、小規模モデルはより難しい問題を解けるようになるのか。Lablup CEOシン・ジョンギュはAstra以降のループ型トランスフォーマーに関するFacebook考察でこの問いに再び向き合っている。アーキテクチャの問いの背後には、インフラ上の意思決定が潜んでいる——アクセラレータとメモリをどれだけ調達し、どう運用するかという問題だ。

公開研究は、保存された重みを固定したまま共有の計算ブロックを繰り返し実行することで、モデルが問題解決能力を向上できることを示している。しかし繰り返しは時間とエネルギーを消費する。モデルが小さくなっても、サービング費用が自動的に安くなるわけではない。

本稿はシンの考察を起点とした独立分析であり、原論文とモデルカードで補足している。Astraに関するエッセイの解釈と公的に確立された事実を切り分け、業界への含意は条件付き分析として扱う。情報源は2026年9月8日時点で確認済み。

Astraの成果はアーキテクチャを開示していない

OpenAIの9月3日の発表はGPT-6 Astraのリリースと性能向上を確認している。しかし、ここで参照した発表文システムカードは、ループ型トランスフォーマーのアーキテクチャ、再帰回数、総パラメータ数およびアクティブパラメータ数を開示していない。

そのため、AstraとHuginn型設計との関連を既定事実として扱わない。エッセイに登場する10T/1Tのサイズ主張やAGI引用も、本分析の前提から除外する。性能の向上だけでは内部アーキテクチャを特定できない。

それでも再帰を検討する理由は十分ある。公開モデルはすでに、保存パラメータ容量と推論計算量を独立して変化させる試みを示している。その展開はフロンティアモデルの非公開設計に依存せずに評価できる。

より多く保存することと、より長く計算することは別の選択肢だ

パラメータとは学習時に調整される数値的な重みを指す。モデルを大きくすると、通常は保存量が増える。Mixture of Experts(MoE)は各入力に対して一部のエキスパートモジュールを選択し、総モデル容量に対して実行する計算量を抑えることを目指す。

MoEはSwitch Transformerだけが起源ではない。2017年のスパース・ゲーテッドMoE論文は、スケールでのルーティングと学習を簡略化した2021年のSwitch Transformerに先行する。また、総パラメータ数が多いことは必ずしも層が増えることを意味しない。

Chain-of-thought(CoT)は中間トークンを生成し、後続の計算のためにコンテキストを拡張する。ループ型モデルは内部状態を共有重みのブロックに再び通す。中間計算はすべてのステップで単語に変換される必要はない。これらのアプローチを組み合わせることも可能だ。

各アプローチが何を増やすかを比較すると、トレードオフが明確になる。

アプローチ増えるもの潜在的なコスト
モデルの大規模化重みまたはエキスパート容量ストレージ、アクティブ計算、通信
Chain-of-thought中間推論トークン生成時間、コンテキストとキャッシュ
再帰的な深さ共有ブロックの通過回数繰り返し計算、レイテンシ、状態管理

これは概念的な比較だ。実際の経済性は、同一精度・入力長・ハードウェア条件での実測値が必要になる。

発話前に考える研究は異なるメカニズムを使っている

Pause tokensは回答前に追加の計算を提供する。Quiet-STaRは後続トークンの予測を助ける中間的な根拠を生成することを学習する。その名称は非言語的な連続状態推論の使用を証明するものではない。

Coconutは最終的な隠れ状態を単語に変換せずに入力として返す。言語に確定する前に、内部表現の中で可能性を保持し続けることを探求する。これは人間の意識や継続的に動作する自律的思考の証拠ではない。

再帰的な深さの研究には2018年のUniversal Transformerがあり、変換を繰り返して位置ごとに計算を異なって割り当てられる。難しいのは有用な繰り返しを学習させることだ。共有ブロックは異なる段階の状態を処理しなければならず、次のパスが結果を改善しなければならない。層の役割の衝突は有用な直感ではあるが、すべての失敗に対する普遍的な説明ではない。

層をコピーすることと同一重みを共有することは異なる

UpstageのSOLAR 10.7BはDepth Up-Scaling(DUS)を導入した。既存の層をコピーし、一部を除去して深いモデルに接続し、学習を継続する。同一の初期値から始まったコピーは異なる重みを持つようになる。結果として得られるモデルはより多くのパラメータを保存する。

一方、再帰型モデルは同一の重みを共有し続ける。DUSは事前学習を再利用してより深いモデルを構築し、ループは保存された重みを対応して増やすことなく実行の深さを増す。両者を同じメモリ節約技術として扱うと、コストモデルが誤ったものになる。

HuginnとOuroの数値は比較条件とともに読む必要がある

GeipiingらによるHuginn研究](https://arxiv.org/abs/2502.05171)は入力処理、再帰コア、出力処理を分離する。コアは繰り返し実行によって内部状態を洗練させる。著者らは800BトークンでトレーニングされたパラメータサイズのQ3.5Bモデルを研究し、再帰的な計算量が増えるにつれて推論タスクの性能が向上したことを報告した。

アブストラクトにある50Bという数値は注意が必要だ。これは50Bパラメータと同等の計算負荷までの改善を説明するものであり、すべてのタスクで50Bモデルの品質を保証するわけではなく、同コストでその品質が得られるとも言っていない。少ない重みでより多くの計算を使うことは研究成果であり、サービス経済性は別途実測が必要になる。

OuroはByteDanceと共同研究者によって2025年10月に公開された。論文は1.4Bと2.6Bのモデルファミリーをカバーし、ベンチマークで最大12Bのモデルとの比較を報告している。しかし公式のOuro-1.4Bモデルカードは、その特定のモデルが従来の3〜4Bモデルに匹敵すると説明している。1.4Bが常に12Bを置き換えると言えば、比較を過大評価することになる。

パラメータ数は学習データ量、再帰回数、評価タスクと合わせて読む必要がある。見かけ上の推論効率は、相当な事前学習投資を前提としている場合もある。

保存される重みが少なくなってもメモリのボトルネックはなくならない

例示的な計算を考えてみよう。3.5Bパラメータを1パラメータあたり2バイトで保存すると、重みだけで約7GBを必要とする。その重みを繰り返し使っても、ストレージ要件が再帰回数分だけ増えるわけではない。これは算術であり、HuginnのGPUメモリ使用量の実測値ではない。

推論の総メモリには、過去のコンテキストを再利用するためのKVキャッシュ、中間状態、実行ワークスペースも含まれる。NVIDIAの推論最適化ガイドは重みとKVキャッシュを主要なメモリ構成要素として区別している。コンテキストが長くなり、同時リクエストが増えるほどキャッシュの圧迫は高まる。再帰ステップ間でキャッシュを共有できるかどうかは設計によって異なる。

重みの再利用はデータ移動の削減とも異なる。重みが高速なオンチップメモリに留まれない場合、次のパスでHBMから再び読み込む必要が生じる可能性がある。繰り返しは計算に加えて帯域幅の需要も増やす可能性がある。メモリ階層と実装を検討せずに、ループがHBM不要の根拠だとは言えない。

早期終了による節約はソフトウェアが実現しなければならない

Mixture-of-Recursions(MoR)はトークンごとに再帰の深さを変え、ある深さでまだアクティブなトークンを中心に計算とキャッシュを管理する。目的は、簡単なトークンに計算を費やすのではなく、難しいトークンに集中させることだ。

サービングはこれを難しくする。リクエスト間で再帰要件が異なると、バッチング効率が下がる可能性がある。スケジューラは早期完了によって解放されたリソースを他のワークに使えるようにする必要がある。これは特定の商用製品での実測結果ではなく、予想される運用上の課題だ。

Ouroモデルカードは具体的な例を与えてくれる。このモデルは早期終了をサポートするが、カードにはvLLMがこの機能をサポートしておらず、設定された完全な再帰回数を実行すると記載されている。アーキテクチャ上の機能がサービングエンジンで自動的に実装されるわけではない。

これはLablupのようなAIインフラソフトウェア企業に具体的な問いを与える——プラットフォームは再帰の深さが異なるジョブをバッチ処理し、キャッシュを再利用し、同等品質での完了時間とエネルギーコストを削減できるのか。これはLablupがすでにその機能をサポートしているとか、収益成長を実証しているという主張ではなく、機会を評価するための問いだ。

韓国の半導体にはリソース節約と利用拡大の両方の可能性がある

以下は収益予測ではなく、ループ型モデルが広く普及した場合の条件付きシナリオだ。

条件考えられる業界への影響必要なエビデンス
同等品質でより少ない重みとキャッシュリクエストあたりのメモリ圧迫の低下同一コンテキスト・同時実行数でのメモリ実測
難しい問題への再帰の増加アクセラレータ時間とエネルギー需要の増大タスク成功あたりのGPU時間とエネルギー
コスト低下が利用拡大を促進集約インフラ需要の安定または増加実際の顧客利用状況と購買計画
再帰とキャッシュ管理がバッチング効率を低下させる商用化の遅延同一レイテンシ目標でのスループット

Samsung ElectronicsやSK hynixのようなメモリサプライヤーにとって、集約需要はリクエストあたりのリソースとリクエスト数の両方に依存する。効率化が採用を促進する可能性はあるが、その成長が節約分を上回ると仮定することはできない。この分析だけではHBM需要や企業の収益予測を修正するには不十分だ。

より有用な比較は、1回の成功したタスクを完了するコストだ。繰り返しに時間がかかりすぎる、またはリトライが頻繁であれば、ベンチマークスコアが高くても高コストになり得る。逆に、最初の試みの成功率が十分に向上するなら、追加の計算がトータルコストを下げる可能性もある。

次のテストはパラメータ数ではなくタスクコストだ

産業的なケースを検証するには、同一精度での総メモリ・完了時間・エネルギー・同時スループットの比較が必要だ。簡単な質問に対する平均値と同様に、テールレイテンシも重要になる。再帰を増やしても品質が改善されなくなる場合、またはバッチング損失がリソース節約を上回る場合、商用化の論拠は弱まる。

アーキテクチャのさらなる開示によって、AstraがこのリサーチラインナップのQ中に属するかどうかが確立されるかもしれない。その一方で、検証可能な変化は確かに存在する——インフラ計画は保存モデルのサイズと並んで、各問題にどれだけ長く計算し、いつ止めるかを考慮しなければならない。その柔軟性を実際のコスト削減に転換することは、ハードウェアとソフトウェア双方の共同テストだ。

Hugo で構築されています。
テーマ StackJimmy によって設計されています。