デイリーAIダイジェスト — 2026-09-04
arXiv ハイライト
LatentPress: テキストとビジョンを超えたContext Compression
問題設定
長文コンテキストLLMに対するcontext compressionは、通常、離散的なチャネルを経由します。すなわち、LLMが生成するテキスト要約か、あるいは近年では視覚言語モデル（例：DeepSeek-OCR）によってデコードされるページレンダリング画像のいずれかです。いずれのアプローチも、圧縮された表現がリーダーによって再embeddingされる前に、人間が読めるトークンとして存在することを強制します。LatentPressはその迂回路を完全に省略します。小規模なwriterが、凍結されたデコーダのinput-embedding空間に存在する連続的な「ソフトトークン」を生成し、推論時に直接注入します。このアプローチは、要約による意味的損失、自己回帰的OCR再構築のレイテンシ、およびリーダーのfine-tuningに必要なパラメータコストを回避できるという主張に基づいています。
手法
ターンまたはチャンクに分割されたコンテキスト x = (x_1, \ldots, x_T) が与えられたとき、writer \textsc{Write}_\phi はソフトトークン m を生成し、それをembeddingされた質問の先頭に付加します。
m = \textsc{Write}_\phi(x;\pi), \qquad y = f_\theta\!\left([m; \mathrm{emb}(q)]\right)
ここで \pi はセグメントごとの圧縮率、f_\theta は凍結されたデコーダです。各トークン位置において、writerはリーダーの文字通りのinput embedding E_i とコンテキストを考慮した抽象表現 c_i を融合します。
h_i = H(E_i, c_i)
H は軽量な融合として実装されています（論文では、Highway/GRU-gatingに倣った学習済みトークン単位の重要度重み付けを将来の課題として挙げています）。h_i はリーダーのembedding空間に存在するより短いシーケンスにpoolingされます。
重要な設計上の選択が3つあります。
- リーダーに対応したwriter。 ソフトトークンは特定のembedding幾何学に結び付いているため、リーダーごとに1つのwriterが必要です。writerはリーダーの下位 L=2 層をエンコーダのバックボーンとして借用しており、これがICAE（全LLMでエンコードする）と比較して書き込み時の高速化の起源となっています。
- Adapterのみの学習。 学習可能なパラメータは4.2M〜26.2Mであり、デコーダの約0.1%に相当します。凍結されたデコーダはgradientの更新を受けません。
- 推論時に再構築のobjective不要。 オートエンコーダ型のsoft promptとは異なり、ソフトトークンはテキストにデコードされることはなく、writerは単一のforward passを実行します。
学習には、会話型メモリ実験に対してUltraChatの会話データ（テストのみ、QAラベルなし）を使用し、長文書のtransfer実験にはLongMemEvalから派生したQAを使用します。
結果
LongMemEval（oracle-evidenceによるメモリQA、500問、Qwen2.5-7B凍結リーダー）。 ロール認識圧縮を用いたLatentPressは、7.70×圧縮において精度0.504を達成し、非圧縮evidenceの0.490を上回ります。ベースライン：テキスト要約は0.184に低下し、DeepSeek-OCRは圧縮率が高くなるにつれて0.426から0.312に低下します。より非力なQwen3-1.7Bでは、ロール認識LatentPressは生のモデルを超え、より強力なQwen3-8Bでは生のモデルを下回ります。テスト済みの圧縮率全体でLatentPressの精度・圧縮フロンティアは顕著に平坦であるのに対し、OCRは単調に低下します。
LongBench-QAクロスドメインtransfer。 非圧縮ベースライン：Qwen2.5-14Bが47.93、Qwen2.5-7Bが43.80、Qwen3-8Bが30.80（non-thinking）。LongMemEval派生のQAで学習した圧縮器をLongBench-QAにzero-shotで適用した場合：
- Qwen2.5-7B：4×で45.13（生の43.80を上回る）、8×で40.69、16×で32.94。
- Qwen3-8B：4×で32.79（生の30.80を上回る）、より高い圧縮率では低下し、これは一部フォーマットの病理的挙動による（Appendix D.3）。
LongBench-QAでのin-domainの適応は、4〜8×において3つのリーダー全てで生のモデルを上回りますが、16×では生のモデルを下回ります。
効率性（H100、bfloat16、batch 8、Qwen3-8B）。 会話あたりの書き込みコスト：
- LatentPress：43 ms
- テキスト要約：407〜645 ms（約9〜15×遅い）
- DeepSeek-OCR：844〜1056 ms（約22×遅い）
- ICAE：350〜700 ms（約8〜15×遅い。全LLMではなく2層を借用してエンコードするため）
注入されるprefixが短いため、読み込みコストは生のコンテキストまたはキャッシュ済みOCRよりも5〜9×高速です。
制限と未解決の課題
- 検索はスコープ外です。 LongMemEvalの数値はすべてoracle-evidence設定を使用しており、より長いhaystack（LongMemEval-S/M）は学習時の履歴長を超え、検索と圧縮が混在します。LatentPressと検索器を組み合わせることは未解決の課題です。
- クロスドメインtransferは4×を超えると不安定です。 ターゲットドメインへの適応なしでは、穏やかな4×の圧縮率のみがリーダー全体で生のモデルと同等か上回る結果を安定して出し、8×および16×では低下します。
- in-domainの16×は全3つのリーダーで生のモデルに劣ります。 したがって、マッチした教師ありデータがある場合でも、積極的な圧縮は依然として精度を犠牲にします。
- リーダーごとに1つのwriter。 ソフトトークンはリーダー固有のembedding多様体に存在するため、デコーダが変わった際にはwriterの再学習が必要です。共有または転送可能なソフトトークン空間は未解決です。
- 融合 H は軽量な実装です。 E_i と c_i の間の学習済みトークン単位のgatingは挙げられていますが、評価されていません。
- 効率性の比較は再構築ベースのルートに限定されています。 他のone-passソフトトークン圧縮器は書き込み時においてベンチマークされていません。
なぜ重要か
連続的なsoft-prompt compressionはすでに存在しています（ICAE、AutoCompressor、Gist）。しかしLatentPressは、writerがフルLLMエンコーダではなく、デコーダパラメータの約0.1%に相当するリーダーに対応した小規模なadapterであり得ること、そしてこのアプローチが、圧縮トークンあたりの精度および書き込み・読み込みレイテンシの両面において、テキスト要約と近年のDeepSeek-OCRの「コンテキストを画像として扱う」ラインの双方を上回ることを示しています。検索とクロスリーダーtransferの問題が解決されれば、direct-readソフトトークンメモリは長期的なエージェントメモリにおけるKV cacheの代替として有望です。
Source: https://arxiv.org/abs/2609.01507
Random Attention: 効率的な推論のためのKV Cache Evictionの再考
問題
長いchain-of-thoughtのデコードはKV cacheを支配的なメモリコストへと変え、32kトークンの生成においては、FLOPsではなくKV cacheが、GPUが同時に処理できるリクエスト数の上限となります。標準的な対応策はスコアベースのevictionです：キャッシュされた各トークンに顕著性スコア（attention質量、value norm、クロスヘッド集約など）を割り当て、上位K件を保持するというものです。SnapKV、R-KV、VaSE、TriAttentionはいずれもこのパラダイムの具体例であり、通常は「ランダム保持」ベースラインと比較してそれを大きく上回るとして評価されています。本論文は、そのような差は選択信号自体ではなくプロンプトの処理方法から生じるほぼ完全なアーティファクトであり、選択信号そのものは推論ワークロードにおいてほとんど何も貢献していないと主張します。
手法
Random Attentionは2つのルールのみによって定義されます。\ell_{\mathrm p}をprefill長（システムプロンプト、チャットテンプレート、質問）とします。すべてのevictionイベントにおける、すべてのKVヘッドにおける、キャッシュされたすべての位置iに対して、スコアを
s_i = \begin{cases} +\infty, & i \le \ell_{\mathrm p}, \\ u_i \sim \mathrm{Uniform}(0,1), & \text{otherwise}, \end{cases}
と計算し、KVヘッドごとに上位K件を保持します。プロンプトは強制的に保持され、トレースはi.i.d.一様抽出によって保持されます。この抽出はヘッド間で独立に行われます。イベントごとのコストは1回のrandと形状(B, H_{\mathrm{kv}}, S)の1回のtopkであり、attention統計量は一切参照されません。
この設計は推論トレースに関する2つの構造的な観察に基づいています：
- プロンプトは一度のみ提示され、evictされた場合に再構築することができません — これはキャッシュの脆弱な部分です。
- 作業状態は2つのレベルで冗長です。テキスト的には、モデルは作業を進めながら中間結果を再述します（「つまり x = 3 であるから…」）。ヘッド間では、各KVヘッドがトレース自身のコピーを保持しています。そのため、ヘッド間で独立に行われるサイズKの一様抽出は、スコアリングなしで、まだ必要とされているものの十分なコピーを保持します。
Random Attentionは実用的に展開可能であると同時に帰無仮説でもあります：同じ予算でそれを上回れないスコアは、利用可能な情報を抽出できていないということです。
結果
中心的な診断実験（論文のTable 2）は、各ベースラインをリリース時の状態と、プロンプトを強制的に保持した状態の両方で実行します。プロンプト保護を追加することによる改善幅は、各手法のスコアがどれだけプロンプトをそれまでdropしていたかによって正確に順位付けられます。Phi-4-reasoningのGPQA-Dにおいて：
- SnapKV: 0.442 \to 0.667 (+22.5)
- VaSE: 0.562 \to 0.664 (+10.2)
- R-KV: 0.636 \to 0.655 (+1.9)
スコアによってすでにプロンプトの大部分を保持していたR-KVは、どの設定においても1.9ポイント以上の改善を得ることはありません。すべての手法においてプロンプトが保護されると、3つの学習済みセレクターはすべての設定で互いに2.2ポイント以内に収まり、Phi-4-reasoningではRandom Attentionとも概ね2ポイント以内となります。Qwen3-4Bでは4〜6ポイントの残差が残りますが、それは学習済みスコアに不利に働きます：それらはシグナルなしの方策に後れを取っています。
シグナルなしの制御実験は対称的な観点を示しています。プロンプト保護なしでは、StreamingLLM型の直近ウィンドウはGPQA-Dで0.09という低スコアを記録し、Random Attentionはタスクによって0.23〜0.76まで低下します。同じプロンプト保護ルールを追加すると、Random Attentionはすべての報告設定でベストな方策となり、単純な直近ウィンドウも最良の学習済みベースラインの2ポイント以内に収まります。つまり、先行研究（例：Yuan et al. 2026、Liu et al. 2025の引用結果）における「ランダムベースライン」の失敗モードは、プロンプトを含むキャッシュ全体から一様抽出していたことにあり、修正すればそのギャップは消えます。
効率性は処理を減らすことから直接もたらされます。1台のH200上のvLLMとPagedAttentionを用いて、K=2048、1kトークンのプロンプト、32kトークンの生成、128の同時リクエスト（Table 4）という条件で：
| モデル | Full | TriAttention | Random Attention | vs TriAttention |
|---|---|---|---|---|
| Qwen3-4B | 1296 | 1494 (1.15\times) | 2046 (1.58\times) | +37\% |
| Phi-4-reasoning | 780 | 1212 (1.55\times) | 1737 (2.23\times) | +43\% |
| Qwen3-14B | 925 | 1303 (1.41\times) | 1819 (1.97\times) | +40\% |
| Qwen3-32B | 346 | 700 (2.02\times) | 923 (2.67\times) | +32\% |
Random Attentionはfull attentionのスループットの1.6〜2.7\timesを達成し、同じカーネルを用いてTriAttentionを32〜43\%上回ります。このマージンは512リクエストの設定においても持続し（容量プラトーの7\%以内で、+41\%と+42\%の差）、維持されます。
限界と未解決の問題
この主張はトレースが長く、自己反復的であり、マルチヘッドの冗長性を持つ推論ワークロードに限定されています。この冗長性を持たないタスク — 長文コンテキスト検索、needle-in-haystack、ある単一の以前のトークンが唯一クリティカルであるエージェント型ツール使用など — は対象外であり、まさにそこで学習済みスコアが重要になるはずです。Qwen3-4BにおけるRandom Attentionに有利な4〜6ポイントの残差は未説明のままです；これは学習済みスコアが単に情報を持たないのではなく、積極的に有害（冗長だが多様なコピーをevictしている）である可能性を示唆しています。最後に、ヘッドごとの独立したランダム抽出はgrouped-query attentionと何らかの相互作用をもつと考えられ、より高いGQA比率での定量化は検討に値します。
なぜこれが重要か
Random Attentionは混雑した研究分野を再構成します：KV evictionリーダーボードはこれまで選択品質ではなくプロンプト保護ヒューリスティックを測定しており、その交絡因子を除去すると、推論タスクにおいて均一サンプリングを上回る公開スコアは存在しないことになります。実用的な帰結として、\mathrm{rand} + \mathrm{topk}の方策が精度を同等に保ちながら、これまでの最強のevictorと比べて32〜43\%高いスループットをもたらします。また、今後の研究では「キャッシュ全体に対するランダム保持」よりも適切な帰無仮説が必要です。
Source: https://arxiv.org/abs/2609.03430
Gated DeltaNetが4ビット量子化を乗り越える理由：ハイブリッド27B LLMの再帰部分におけるNVFP4 W4A4
問題
ハイブリッドLLMはsoftmax attentionと、Gated DeltaNet（GDN）のような線形attentionレイヤーを交互に組み合わせています。GDNは固定サイズの再帰状態 S_t = (I - \beta_t k_t k_t^\top)\, \mathrm{diag}(\alpha_t)\, S_{t-1} + \beta_t k_t v_t^\top を持ち、減衰ゲート \alpha_t と書き込み強度ゲート \beta_t を累積状態に折り込みます。コミュニティで広く共有されている直感——公開されているQwen3.8-27B（48 GDN + 16 attentionレイヤー）の全4ビットビルドにも見られる——は、再帰内の丸め誤差が長いコンテキストにわたって蓄積するため、GDN、特にその a/b ゲート射影はFP8/BF16に留めておく必要があるというものです。UnslothとRadixArkはいずれもMLPのみをNVFP4に量子化し、GDN + attentionはFP8 W8A8に保っています。本論文（Minima）は、496個の全線形レイヤー（GDNゲートを含む）をNVFP4 W4A4に量子化することでこの直感を検証し、再帰が実際に誤差を蓄積するかどうかを問います。
手法
NVFP4は16要素ブロックとブロックごとのE4M3スケール、テンソルごとのFP32グローバルスケールを使用します。ブロックスケーリングにより外れ値は15個の近傍要素に局所化されます。Minimaはllm-compressorのNVFP4 W4A4を全240個のGDN、64個のattention、192個のMLP射影に適用し、128サンプル × 32Kトークンでキャリブレーションしています。lm_head、embedding、conv、normのみが除外されます。結果を解釈可能にするために、2つの機械的な修正が必要でした。
- Fused-GEMMスケールの調和。 vLLMは
in_proj_qkv + zおよびin_proj_b + aを単一のNVFP4 GEMMに融合し、ローカルE4M3ブロックを再スケールせずに構成要素のFP32グローバルスケールの最大値を取ります。全48 GDNレイヤーにおいて、ペアのグローバルスケールはqkv/zで 1.82\times、b/aで 2.75\times の差がありました。そのため、サービングカーネルは誤ったスケールの重みで減衰ゲートと書き込みゲートを暗黙的に計算していました。著者らは各融合グループを共有グローバルスケールに書き直し、その比率をE4M3ブロックごとのスケールに折り込みます（94スケールセット、最悪比率 2.81\times、再丸め誤差 \leq 6.2\%）。GEMMプローブにより、カーネルと参照実装の誤差が 0.35/0.57 \to 0.002 に改善されたことが確認されます。この修正なしでは、AIMEは80.8に崩壊しますが、PPL@32Kは6.86という偽りの良好値を示します——状態を溜め込む壊れたforgetゲートはnext-tokenの予測には有利ですが、推論を破壊します。 - FP8 KVスケール。 GDNはKVキャッシュを持たず、16個のattentionレイヤーのみが持ちます。K/V射影が既にW4A4であるため、スケール1.0のFP8 KVはMinima上でPPL@32Kを +0.41 増加させます（BF16では +0.13）。キャリブレーション済みのテンソルごとのFP8スケール（32テンソル）により、スループットコストゼロでそのペナルティの83%を回復します（10.84 \to 10.50）。
結果
チェックポイントレベルでは（vLLM 0.27.1、TP=1、RTX PRO 6000）、Minimaは5タスク平均でBF16とシードノイズの範囲内で一致しています：85.10 vs. 85.62（\Delta = -0.52）、Unslothの -0.28、RadixArkの -0.82 に対して。いずれのタスクにおいても、どのモデルペアも信頼区間で分離されていません。MinimaはAIME’25でBF16と完全に一致しており（86.7、全4シードで26/30が同一）、GDNは完全に4ビットで動作しており、生成長も変化していません（平均14,531 vs. 14,532トークン）。RULER検索は全4モデルで32K/64Kともに100です。
GDNの量子化（5.5Bパラメータ、デコード重みバイトの約23%）による効率向上こそ、Minimaがコミュニティのレシピと一線を画す点です：重みが17.53 GiB vs. 20.23（Unsloth）/ 18.83（RadixArk）/ 50.13（BF16）、BF16に対して 2.9\times の縮小、32Kプリフィルでの TTFT 6.90\text{s} \to 4.03\text{s}、8Kでのプロンプトスループット+14–19%を達成しています。デコードは重み帯域幅律速であり、3つのNVFP4ビルドはいずれも4%以内に収まります。
PPLはレシピを順序付ける唯一の指標であり（Unsloth < RadixArk < Minima）、コミュニティビルドが保持する追加の1.3–2.7 GiBのBF16/FP8重みを反映しています。重要なのは、BF16に対するMinimaのPPLギャップが4Kで +0.72 であるのに対し32Kでは +0.49 のみであるという点です——ギャップは位置とともに縮小しており、誤差蓄積とは逆の挙動を示しています。
GDNが4ビットを乗り越える理由
メカニズム研究では全48 GDNレイヤーの実際の入力を収集し、NVFP4へのfake量子化を行った結果、以下の知見が得られています。
- GDNの入力分布はattentionのそれより容易ではありません。 GDNのqkv/z/a/bの中央値 \max/\mathrm{RMS} は63.5であるのに対し、attentionのq/k/vは71.5です。尖度は約1,564、16要素ブロックの10.6%は1-hot（単一の値がブロックエネルギーの56%超を占める）です。GDNの
out_projでは \max/\mathrm{RMS} = 298.1、1-hotブロックが32.1%に達します。 - ブロックスケーリングにより、全レイヤーの役割にわたってトークンごとのactivation誤差が7.5–9.2%に均一化されます。 各外れ値は15個の近傍に限定されるためです。重み誤差（10.5–11.9%）はどこでもactivation誤差を上回り、両者とも32K位置にわたって平坦です。
- ゲート射影は再帰の制御信号を担うにもかかわらず、最も感度が低いです。 Softplus/指数関数（\alpha_t = \exp(-\mathrm{softplus}(a))）とsigmoid（\beta_t = \sigma(b)）のパラメータ化により、約11%のGEMM誤差が約2%の出力誤差に圧縮されます——飽和型非線形関数はpre-activationに対して縮小的に作用します。
したがって、ロバスト性はGDNがどのように誤差を処理するか（縮小的ゲート、delta-rule状態正規化）に由来するものであり、入力がより扱いやすいことによるものではありません。
制限事項
単一モデル研究（Qwen3.8-27B）であり、調和化の監査は融合されたGDNグループを量子化するレシピにのみ影響するため、異なる融合パターンを持つハイブリッドへの転用可能性は保証されません。+0.49 PPL@32Kの残差はゼロではありませんが、いずれのタスクにも表れていません。デコードスループットはRadixArkに2–4%遅れており、GDNにおけるNVFP4カーネルのディスパッチに残余オーバーヘッドがあることを示唆しています。分析はNVFP4の16要素ブロックに限定されており、MXFP4（32要素）は1-hotブロックで異なる挙動を示す可能性があります。
なぜこれが重要か
線形attention再帰がハイブリッドのattention部分より高い精度を必要としないという実証的な根拠は、ハイブリッドLLMの均一4ビット展開に対する最後の構造的障壁を取り除きます。また、fused-GEMMスケール調和化のバグは、それらを融合するサービングスタックでペアの射影を量子化するすべての人にとって一般的な落とし穴です。その結果——2.9倍小さく、プリフィルが19%高速で、BF16とタスク同等——こそ、正しい4ビットハイブリッドレシピのあるべき姿です。
Source: https://arxiv.org/abs/2609.04098
RealSWE: 現実的なユーザーリクエストに基づくコーディングエージェントの構成的評価
問題設定
SWE-benchおよびその派生版（Verified、Pro）は、コーディングエージェントの能力を測る事実上の標準となっています。しかし、これらのベンチマークにおける問題文はGitHubのissueをキュレーションしたものであり、開発者が実際にコーディングエージェントに入力する内容と比較して、長く・構造化されており・形式的で・一般的に過剰な情報量を持っています。ベンチマークへの入力が実際の運用時の入力と情報量やレジスターの点で系統的に異なる場合、報告される解決率やモデル間のランキングは実環境に転用できない可能性があります。本論文はこのギャップを定量化したうえで、根底にあるタスクとゴールドパッチを固定したまま、情報の構成と言語スタイルという2つの軸を独立に制御した評価手法を構築しています。
ギャップの特徴づけ
著者らは、SWEリクエストに対する6カテゴリの情報分類体系（問題文P、再現手順D、根本原因R、期待動作E、追加制約A、および機能要求フィールド）と、4つの言語スタイル次元（形式性、命令性、確信度、人称）を定義しています。この体系を、SWE-chatからフィルタリングされた718件のユーザーの最初のターンのプロンプトと、SWE-bench VerifiedおよびProの問題文に適用しています。
2つの主要なミスマッチが浮かび上がります。第1に、情報構成について、問題文のみ、または最大1つの追加フィールドのみを含むリクエストは、実際のプロンプトの88%を占める一方で、ベンチマーク問題では7%にすぎません。ベンチマークのタスクは、複数フィールドを持つ情報量の豊富な尾部に集中しています。第2に、スタイルについて、実際のプロンプトの87%がカジュアルな文体であるのに対し、ベンチマークの問題文の94%は形式的です。これらは直交する軸における大きな分布シフトです。
構築パイプライン
RealSWEは、各ソースベンチマーク問題の問題文をLLMによって分類体系のフィールドに分解し、(a) フィールドをサブセット化し、(b) 残存するテキストを選択した言語スタイル設定に基づいて書き換えたバリアントを生成することで構築されています。ゴールドパッチはソースに固定されているため、タスクファミリー内のすべてのバリアントは同一のグラウンドトゥルースを共有し、変化するのは仕様のみです。
各ソースタスクは（フィールドサブセット、スタイルベクトル）によってインデックスされたバリアントのファミリーを生成します。本論文は2つの成果物を公開しています。RealSWE-benchは、実際のユーザー分布（SWE-chatの支配的なパターン）に合致する単一の固定構成であり、RealSWE-frameworkは制御されたアブレーション研究のための完全なグリッドを公開しています。最終的なベンチマークはVerifiedおよびProから導出された381のタスクファミリーで構成されています。
具体的な例として、5つのフィールド[P,D,R,E,A]がすべて存在するバグ修正タスクにパイプラインを適用した場合、[PDREA]バリアントはすべての情報を保持しつつ、カジュアル・命令的・確信的・非一人称スタイルに書き換えられています。
検証では、LLMによる分解および言い換えを人間のラベルと比較しています。分解における不一致は隣接するスコア境界に留まっており、人間がスコア1と判定したフィールドに対してジャッジがスコア3を与えるケースはありません。言い換えにおける不一致は情報保存スコア2対3に限定されており、パイプラインが暗黙のうちにフィールドを削除したり捏造したりしないことが示されています。
結果
推論機能を持つ7つのエージェントが評価されています：DeepSeek V4 Pro / Flash、MiMo V2.5 Pro / V2.5、Claude Haiku 4.5、Qwen3.7 Plus、MiniMax M3です。RealSWE-benchにおける解決率は、オリジナルの問題文と比較してすべてのモデルで低下しており、平均6.4ポイントの低下となっています。
n=381の全タスクセットにおけるモデルごとの差分：
- DeepSeek V4 Pro: 53.9 → 45.9 (-8.0)
- DeepSeek V4 Flash: 49.7 → 41.6 (-8.0)
- MiMo V2.5 Pro: 49.1 → 44.0 (-5.1)
- MiMo V2.5: 48.4 → 40.7 (-7.7)
- Claude Haiku 4.5: 42.1 → 36.7 (-5.4)
- Qwen3.7 Plus: 50.1 → 43.5 (-6.6)
- MiniMax M3: 34.1 → 30.1 (-4.0)
バグ修正タスクは機能要求タスクより劣化が大きく、例えばDeepSeek V4 Flashはバグで11.8ポイント低下するのに対し機能要求ではわずか4.2ポイントの低下であり、Claude Haiku 4.5はバグで10.2ポイント低下する一方で機能要求ではほぼ変化なし（0.5ポイント）です。これは、バグ報告が（再現手順や期待動作などの）診断フィールドをより多く含んでおり、それらの省略がコストとなることと一致しています。
ランキングも変化します。オリジナルではDeepSeek V4 Pro（53.9）が首位で、Qwen3.7 Plus（50.1）とDeepSeek V4 Flash（49.7）がそれに続きますが、RealSWE-benchではDeepSeek V4 Pro（45.9）が依然として首位である一方、MiMo V2.5 Pro（44.0）がDeepSeek V4 Flash（41.6）とMiMo V2.5（40.7）を上回ります。コストとステップ数の変化はわずかであり（例：DeepSeek V4 Pro: 3.02¢/42.6ステップ → 3.16¢/44.2ステップ）、エージェントは仕様の不足を補うためにより多くの探索を行っているわけではなく、単純に失敗が増えているということです。
限界とオープンクエスチョン
言語変換はLLMによって生成され、少数の人間パネルに対して検証されています。「スタイルのみ」と「情報のみ」の分割において分類フィールドが漏洩する可能性が残りますが、混同行列によってその範囲は限定されています。SWE-chatの最初のターンのプロンプトは実際の運用分布を近似するものの完全に一致するわけではなく、実際のセッションにはフォローアップが含まれ、ターン1のみを保持するという選択は保守的に明確化の機会を除去しています。ゴールドパッチはVerified/Proから継承されているため、欠落フィールドによって解決が本質的に左右されるタスクは、適切な明確化要求としてではなく失敗としてスコアされます。適切に構成された明確化要求を評価するベンチマークは自然な発展方向といえます。最後に、RQ2とRQ3（スタイルのみの効果、フィールドごとの限界価値）は予告されていますが、提供されたテキストでは要旨が途中で終わっています。
なぜ重要か
コーディングエージェントにおけるベンチマークと実際の運用環境との分布ギャップは、単に難しいタスクの問題ではありません。仕様そのものが分布外であり、それだけで解決率が6.4ポイント低下し、リーダーボードの順位が入れ替わります。入力分布を無視した評価はエージェントの実用性を過大評価し、アーキテクチャやトレーニングの意思決定を誤った方向に導く可能性があります。
Source: https://arxiv.org/abs/2608.27831
Principia: 動画モデルのための関係的物理テスト
生成された動画がニュートン力学に従っているかどうかを評価することは、カメラの内部パラメータ、フレームレート、および物体のスケールが未知であることによって困難になります。g \approx 9.8~\text{m/s}^2 のような絶対量は、これらのパラメータなしに生成されたクリップから復元することができず、「9.8~\text{m/s}^2 の重力を生成せよ」とモデルに指示することも不適切です。Principia は、同一の物理法則のもとで関係的不変量を満たさなければならない、同一シーン内の物体ペアを評価することでこの問題を回避します。ピクセル空間の軌跡間の比や等式は欠損した較正情報に対して不変であるため、2つの物体間に残る非対称性はすべて測定パイプラインではなくモデルに帰せられます。
ベンチマークの構成
このデータセットは8つの現象を対象としています。すなわち、重力（自由落下の質量独立性）、反発係数、動摩擦、回転慣性（中実シリンダー対中空シリンダーの転がり）、飛距離、運動量の伝達、振り子の周期（T \propto \sqrt{L/g}）、質量-バネ振動（T \propto \sqrt{m/k}）であり、フィルタリング後の約750テイクから取得された529の実際に録画されたシーンを含んでいます。
関係的シグナルは脆弱であるため、構築プロトコルは重要です。2つのランプ間のわずかな傾き非対称性、数ミリ秒の解放タイミングのずれ、または振り子の解放時の横方向の押しは、真の物理則違反と区別がつかないシグネチャを生み出します。著者らは以下を徹底しています。すなわち、一致した形状（例えば、質量・高さ・外半径を5%以内に一致するよう加工されたDelrin製中実シリンダーとアルミニウム製中空シリンダー）、同期した発射のための機械式解放ガイド、検証済みの接触面（転がりにおけるスリップなしの検査、制御された摩擦面）、そして外力の最小化（ほぼゼロの解放速度、関連する時間スケールにおける無視可能な空気抵抗）です。物体は手動でアノテーションされたシードポイントからSAM3によってセグメンテーションおよびトラッキングされ、生の動画とSAM3の軌跡の両方の手動検査を通過したテイクのみが保持されます。
一貫性スコア
現象 \phi に対して、不変量は正しい物理学のもとで等しくなければならない2つのスカラー汎関数 \mathcal{F}_\phi(o_1), \mathcal{F}_\phi(o_2) として記述されます。これらは直接的な測定値（減速から求める動摩擦係数）または測定値から導かれる比のいずれかです。例えば、重力の場合は2つの質量の落下時間の比、振り子の場合は T_1/T_2 と \sqrt{L_1/L_2} との比較、反発の場合はバウンス高さの比です。一貫性スコアは次のように定義されます。
S_\phi \;=\; 1 - \frac{|\mathcal{F}_\phi(o_1) - \mathcal{F}_\phi(o_2)|}{|\mathcal{F}_\phi(o_1)| + |\mathcal{F}_\phi(o_2)|} \in [0,1].
S_\phi = 1 は厳密な不変性を意味し、S_\phi = 0.95 はおよそ10%の関係的非対称性に対応します。分子と分母はいずれも同一の物理次元を持つピクセル空間の量であるため、未知のスケールとフレームレートはキャンセルされます。飛距離と運動量については、不変量が等式ではなく定性的なものであるため、正しい距離の順序を持つシーンの割合をスコアとする順序的な変形を使用します。
この図は、関係的テストが単一物体の尤もらしさでは見逃してしまう失敗を捉えられる理由の論拠です。個別には各軌跡は妥当なスライドですが、合わせて見ると等価原理に違反しています。
評価と結果
6つの動画生成モデルが評価されています。Omni、Veo-3.1、5Bおよび14BのWan2.2、そして2Bおよび14BのCosmos-2.5です。それぞれは、テキストプロンプトと対応する実録画の最初のフレームを条件として与えられます。ただし、実験者・懸垂ひも・解放装置はNano Banana 2を用いてインペインティングされており、モデルが可視のメカニズムではなく物理的な配置を条件とするようになっています。シーンごとに複数のシードを平均化します。物理的な失敗と生成全体の失敗を混同しないよう、動画は定性的に正しい全体的な動き（例えば物体が実際に降下するなど）を示すもののみを保持するよう事前フィルタリングされます。4つのオープンウェイトモデルにわたる総計算量は2,600 A100時間を超えます。
主要な結果は以下の通りです。いかなる生成モデルもPrincipiaで 0.42 を超えない一方で、6つすべてがVBenchでは 0.8 前後のスコアを示します。つまり、標準的な動画品質ベンチマークで高いパフォーマンスに見えるモデルが、関係的テストでは大きく失敗しています。10%の非対称性が S_\phi = 0.95 に対応する中、 0.4 近傍の集計スコアは非正規化の意味で50%をはるかに上回る関係的偏差を示しています。
定性的なパネルは、失敗モードが物体ごとの独立した動きの合成に集中していることを示しています。各物体は個別には妥当な物理的軌跡のように見えますが、共に動くべきペア（等しい落下時間、等しい振り子の周期、中空が中実より遅いという正しい転がり順序）が代わりにずれたり、順番がずれて到着したり、不一致な周波数で振動したりします。視覚言語モデル（Gemini-3.1-Pro、Gemini-3-Flash、Qwen-32B、Qwen-4B）についても、動画入力から関係的違反を検出する能力が追加テストされています。論文の記述はこれらも苦戦していることを示唆していますが、該当の抜粋には正確な数値は記載されていません。
限界と未解決の問題
8つの現象は、ほぼ理想化された条件下での剛体ニュートン力学に限定されており、変形可能な物体、流体、および多接触シナリオは対象外です。定性的に誤った動画を除去する事前フィルタリングはスコアを上方バイアスさせます。フィルタリングなしの生成における真の失敗率はより高くなります。不変量は特定の条件（小角振り子、スリップなしの転がり、無視可能な抵抗）を仮定しており、生成モデルの動画はこれらを技術的に違反した方法で関係的チェックを表面上「通過」する可能性があります。さらに、シーンは装置がインペインティングされた実録画であるため、このベンチマーク上の生成モデルの挙動は物理的な事前分布と画像条件付き生成品質の両方を反映しており、それらを分離することは未解決の課題として残されています。
この研究が重要な理由
Principia は動画モデルにおける物理的推論の較正不要・再現可能なプローブを提供し、VBench（~0.8）とPrincipiaの間の約2倍のギャップ（<0.42）は、現在の視覚品質メトリクスが物理的一貫性をまったく追跡していないことを示しています。動画生成モデルが「世界モデル」であるという主張は今後、ペア物体関係的不変量において0.42を有意に上回るスコアを示すことが期待されるべきです。
Source: https://arxiv.org/abs/2609.04200
Terminal-Universe: エージェントの軌跡をスケーラブルなターミナル環境へ変換する
Terminalエージェントのpost-trainingは供給の非対称性という問題を抱えています。軌跡（trajectory）は豊富に存在しますが、その軌跡が実行された実行可能な環境は希少です。軌跡は模倣にしか使えない固定されたデモンストレーションですが、環境は多数の検証可能なタスクとして再クエリでき、RLやrejection samplingのための実行フィードバックを提供します。Terminal-Universeは、軌跡 \tau のツール実行履歴から環境 E を再構築し、その復元されたワークスペース \widehat{E} を新規タスクの合成基盤として利用することで、このギャップを埋めます。
再構築パイプライン
このフレームワークは、記録されたすべての読み取り・書き込み・編集操作を下層のファイルシステムに関する証拠として扱い、3段階で再構築を行います。
Stage 1 — 決定論的リプレイ。 \tau 内のファイル操作が時系列順に処理されます。アクセスされた各パスに対して、最初に観察されたコンテンツがエージェント実行前の状態として採用されます。エージェントが作成したファイルは初期ワークスペース \widehat{E}_0 から除外されますが、検証用のground-truthのdiffとして別途保持されます。軌跡はアクセスされたパスのみを露出し、途中で切り捨てられたダンプを含む場合があるため、\widehat{E}_0 は本質的に不完全なものとなります。
Stage 2 — エージェントによる補完。 補完エージェントは \widehat{E}_0 と復元されたタスク q を受け取り、不足しているファイルを補完し、不完全なファイルを完成させ、q を解決可能にするために必要な依存関係をインストールします。ただし、タスクそのものを解決することは明示的に禁止されています。出力 \widehat{E} が実際に実行される環境となります。
Stage 3 — 環境フィルタリング。 読み取り専用のジャッジが q を条件として \widehat{E} を検査し、ソース・設定・データ・構造が有能なエージェントに十分なコンテキストを提供しているかどうかに基づいて、十分または不十分とラベリングします。十分なワークスペースのみが下流に流れます。すべての処理はリポジトリごとのイメージではなく、ネットワークアクセス可能な標準の ubuntu:24.04 コンテナ内で実行され、わずかな解決率の低下と引き換えにデプロイコストを大幅に削減します。
再クエリの軸
\widehat{E} が構築されると、4つの方法で活用されます。Intent Recovery（元のタスクを再構築して再解決）、Single-WS synthesis（単一ワークスペース内で新規タスクを提案）、Cross-WS synthesis（プロファイリングされた複数のワークスペースにまたがる関係を掘り起こし、複数のコードベースに触れるタスクを構成）、Multi-Round continuation（タスクを反復的なセッションへと拡張）です。シードは、ターミナルワークスペースに \geq 5 ファイルかつ \geq 100 行を持つ軌跡にフィルタリングされ、Terminal-Bench由来のソースは除外され、学習前に13-gramの汚染チェックが適用されます。
学習および評価の設定
Qwen3.5-27BをTerminal-Universeデータで2エポック、学習率 7\times 10^{-6}、バッチサイズ256、シーケンス長256kでSFTします。評価はTerminal-Bench 2.0/2.1（シングルラウンド、Claude Code 2.1.126およびTerminus2-XML）とEvoCode-Bench v2（マルチラウンド、26タスク / 227ラウンド、累積verifier、MT@4 fail-stopスコアリング）を対象とします。デコーディング：temperature 1.0、top-p=0.95、コンテキスト長256k、65,536トークン/ターン、176kで要約、最大500ターン、壁時計時間4時間（ステートフルタスクは10時間）。スコアは6回（EvoCodeは4回）の実行の平均です。
コアアブレーション：再構築 vs. 模倣
最も重要な問いは、\widehat{E} を再構築して q を再解決することが、元の軌跡を直接SFTするよりも実際に優れているかどうかです。データサイズを揃えた（35.8k）Terminal-Bench 2.1での結果：
- ベースQwen3.5-27B：47.8（Claude Code）/ 46.2（Terminus2-XML）、平均47.0。
- 元の軌跡でSFT：33.0 / 40.3、平均 36.7 — ベースモデルに対して大幅な性能低下。
- Intent Recoveryデータでのみ SFT：51.3 / 52.9、平均 52.1。
解釈は明快です。元エージェントの不均質な混合を模倣することでより強力なベースモデルが積極的に劣化する一方、再構築されたワークスペース上で一貫した強力なteacherを用いて同じ復元タスクを再解決することで、ベースモデルを上回るコヒーレントな教師信号が得られます。ここでのIntent Recoveryは意図的にverifierフィルタリングを行っていないため、15.4ポイントの差は選択ではなく再構築+再解決のループ自体に起因するものです。
この論文はさらに、(i) エージェントによる補完 vs. 決定論的リプレイのみ、(ii) verifierフィルタリングのコスト/ベネフィット、(iii) 幅（Single/Cross-WS）・深さ（Multi-Round）・環境対クエリにわたるバジェット配分、(iv) ターミナルワークスペースを超えた転移性を個別に検証しています。設定からこれらが52.1のベースラインに加算的に効くことが示唆されています。
限界と未解決の問題
再構築は明示的に情報損失を伴います。アクセスされていないファイル、暗黙のシステム状態、外部ネットワークリソースは痕跡を残さないため、補完エージェントはもっともらしいコンテンツを「幻覚」しなければなりません。\widehat{E} が E の意味的な難易度を保持しているか（単に実行可能でverifierが受け入れるものを生成するのではなく）は直接測定できません。verifierはタスクの十分性をチェックするのみで、元プロジェクトへの忠実性はチェックしません。単一の ubuntu:24.04 イメージを選択することで解決率をシンプルさと引き換えにしていますが、その交換の規模は先行研究に委ねられています。SFTのみの学習レジームでは、環境（軌跡ではなく）を持つことが本来可能にするはずの、実行フィードバックを用いたRLの下での利得の継続や複合がどの程度生じるかも未解決のままです。最後に、teacherモデルの汚染——再解決teacherのバイアスがすべての合成デモンストレーションに焼き込まれること——は分析されていません。
この研究の意義
生の軌跡でのSFTが強力なベースモデルを損なう一方で、再構築された環境上で再解決されたタスクでのSFTが改善するという結果は、軌跡コーパスの価値観を再定義します。その価値はデモンストレーションにあるのではなく、暗黙的にエンコードされた環境構造にあるのです。再構築が一般化するならば、エージェントのpost-trainingのボトルネックは環境の設計から、軌跡のマイニングとverifier設計へとシフトします。
Source: https://arxiv.org/abs/2609.04148
大規模言語モデルのOn-Policy Distillationの再考 II：1件の学習例
問題設定
On-policy distillation（OPD）は、教師のper-tokenの分布を密なsupervisionとして用いながら、学生自身のrolloutで学生を学習させる手法です。これはpost-trainingパイプラインにおける標準的な要素となっていますが、既存研究はアルゴリズム的な変種（lossの形式、advantage推定器）に焦点を当てており、学習データが何をもたらすかをほぼ無視してきました。本論文の著者らはこれを極限まで推し進めます：学習セットが1件のクエリのみの場合、full-data OPDの利得はどれほど残るのでしょうか？この問いは、OPDのコストがデータセットのキュレーションと最適化のどちらに起因するか、そして実際のボトルネックは何かということに直接関わります。
設定
学生と教師は4つのドメイン（Table 1）にわたってマッチしたファミリーから選ばれています：数学（R1-Distill-1.5B → JustRL-1.5B；Llama-3.2-3B-Instruct → GT-Llama-3B-Math；OLMo-3-7B-Instruct-DPO → OLMo-3-7B-Instruct）、コード（R1-Distill-1.5B → Nemotron-1.5B）、instruction following（R1-Distill-1.5B → UltraData-IF-1.5B）、エージェント的ツール使用（Qwen2.5-Coder-1.5B-Instruct → Hammer-1.5B）。OPDは1回の更新につき64回のrolloutで300ステップ実行されます；token levelのlossはtop-kまたはsampled-tokenの advantage A_i = \log \pi_T(y_i \mid s_i) - \log \pi_\theta(y_i \mid s_i) を用い、状態は s_i = (x, y_{<i}) です。
1件学習現象
単一のクエリで学習することにより、テストされた4つのドメインおよびすべてのモデルファミリーにわたって、full-dataの教師-学生ギャップのほとんどが回復されます。この利得はクエリの難易度（学生が常に解けるクエリと全く解けないクエリがほぼ同等）、応答の長さ、およびsampling temperatureに対してロバストです。学習の改善は数十ステップで飽和するのではなく、数百ステップにわたって単調に進行するため、「学生が1つの軌跡を記憶しただけ」という単純な解釈は否定されます。
データの観点：状態カバレッジ
この研究の核心的なメカニズムの主張は、OPDが「クエリ」ではなく「状態」を消費するということです。1回の更新につき64回のrolloutを行うことで、単一のクエリからすでに数万の異なるprefix s_i = (x, y_{<i}) が生成され、それぞれが教師の目標値を持ちます。著者らは広さを次のように定量化しています：(i) 各状態を教師の最終層の隠れベクトル h_T(s) で最後のトークンにおいてembeddingし、(ii) DAPO-Math-17Kにおけるfull-data OPDが訪れた状態をプールし、(iii) 参照プールにPCA + K-meansを K=200 で適用し、(iv) 次式を計算します： \mathrm{Cov}(S) = \tfrac{1}{K}\bigl|\{c(s) : s \in S\}\bigr|. ホールドアウトされたfull-dataのrolloutのセットは、設計上300ステップの予算で100%に達します。
主要な数値：単一のクエリは 71.5\% の状態カバレッジに達し、そのカバレッジの大部分は最初の100ステップ以内に到達します。BGE-M3クラスターごとに1件の代表クエリという形で意味的に異なるクエリを追加すると、カバレッジと検証精度がともに向上し、16件のクエリで 98.9\% のカバレッジに達してfull-data OPDと同等になります。追加の例の価値は本質的に状態カバレッジへの限界的な貢献です。
アルゴリズムの観点：緩慢なアライメント
単一のクエリが100ステップで状態空間のほとんどを供給できるとすれば、なぜ学習は収束に数百ステップを要するのでしょうか？著者らは、学生が実際に訪れた状態における2つの量を追跡します： d_t = \tfrac{1}{|\mathcal{T}_t|} \sum_{i \in \mathcal{T}_t} \bigl|\log \pi_T(y_i \mid s_i) - \log \pi_{\theta_t}(y_i \mid s_i)\bigr|, これはper-token log-probギャップの平均絶対値であり、吸収率は v_t = \frac{d_t - d_{t+1}}{d_t} です。残り距離 d_t/d_{30}（gradient clippingレジームの後）を報告すると、v_t は t とともに減衰し、その速度はOPDが1件のクエリで学習されるかfull datasetで学習されるかにほぼ依存しないことが観察されます。つまり、学生が教師-学生の不一致を吸収する速度は最適化のダイナミクスによって決定されており、データ量によって決まるわけではありません。最初から状態セットを固定した制御実験でも収束に数百ステップかかるため、継続的に更新される状態ストリームが学習を長引かせているわけではありません。
図2の要約は本論文の中心的な診断です：OPDはデータが過剰供給されており（rolloutはほぼ即座に広範なsupervisionを提供する）、一方でアルゴリズムが不足しています（学生はそのsupervisionをゆっくりと吸収し、その速度はデータ量にほぼ依存しない）。
複数教師への拡張
複数教師OPD（MOPD）において、単一の学生がドメインごとの教師（JustRL-1.5B、Nemotron-1.5B、UltraData-IF-1.5B）を用いて数学、コード、instruction followingにわたって学習される場合、同じパターンが成立します：ドメインごとに16件の意味的に多様なクエリがfull-data MOPDと一致し、そのfull-data MOPD自体はドメインごとにfull-data OPDを個別に実行した場合と同等です。
限界と未解決の問題
状態カバレッジの議論は教師の最終層の隠れ表現を状態表現として使用しているため、カバレッジは教師の視点から見て異なるように見えるものを測定します；他の表現では結果が異なる可能性があり、Appendix B.1では K、参照セット、sampledされた位置にわたるロバスト性のみを議論しています。吸収率 v_t は幾何学的なウィンドウで推定されており、ステップ300付近のダイナミクスを解像できません。すべての実験は1.5B〜7Bのスケールであり、より大きな学生が依然として〜16件のクエリでカバレッジを飽和させるかどうかは未検証です。最後に、真のボトルネックがアルゴリズム的であるならば、本論文は修正策を提案していません――目標を明確にするものの、どのoptimizer、lossの形状、またはカリキュラムがカバレッジを損なわずに v_t を向上させるかは未解決のままです。
なぜこれが重要か
本論文はOPDのコスト構造を再定義します：データセットの規模が制約要因ではなく、最適化こそが制約要因です。ドメインごとに慎重に選ばれた16件のクエリがfull-data MOPDと一致するならば、キュレーションの努力は量よりも意味的多様性に向けるべきであり、研究の努力は新しいデータレシピではなく、吸収率の上限を標的にすべきです。
Source: https://arxiv.org/abs/2609.04172
Hacker News Signals
ClaudeとCodex、Cursorはどのツールを選ぶか？17,000回の実行を計測して明らかに
Armatureは、Claude（Anthropic API）、Codex（OpenAI）、Cursorを対象に17,000回のエージェント型コーディングセッションを実施し、ベンダーの主張に頼るのではなく、tool-useの挙動を実証的に計測しました。手法としては、タスク完了中に発行されたすべてのサブプロセス呼び出し、ファイルI/O呼び出し、シェルコマンドをログに記録し、エージェントおよびタスクカテゴリ別に頻度を集計しました。
主な知見：Claudeはコードベースのナビゲーションにripgrepとfdを強く好み、POSIXのgrep/findへのフォールバックはほとんどありません。CodexはGitのプリミティブ――diff、log、blame――をより積極的に活用しており、バージョン管理を意識した推論がトレーニングで重視されていたことを示唆しています。Cursor（独自のtool layerでモデルをラップしている）は明らかに異なる分布を示しており、生のシェルツールよりも内部のAST ベースのシンボル検索を好むため、生のサブプロセス数は減少する一方、抽象化レイヤーによって呼び出しあたりのレイテンシが増加します。
システム的な観点から興味深いシグナルは、エラー回復挙動の違いです。ツール呼び出しが失敗した場合（非ゼロ終了、バイナリ欠落、パーミッション拒否）、Claudeは約70%のケースでフォールバックツールを使ってリトライしますが、Codexはエラーを上位に伝搬させてユーザーに問い合わせることが多いです。これは無人パイプラインでの利用において重要な意味を持ちます。
計測手法については精査に値します：セッションはタスクの難易度で正規化されていないため、あるエージェントによるツール使用の多さは、真の行動上の選好ではなく、より難しいタスクが割り当てられたことを反映している可能性があります。著者らもこの点を認めており、タスクタイプを統制することで差は縮まるものの完全には解消されないと述べています。
これらのエージェント上に構築するチームへの実践的な示唆：サンドボックス化された実行環境を設計する場合、ツールのallowlistはエージェントごとに異なるべきです――単一のallowlistは、一部のエージェントに対して過剰に許可的になるか、または別のエージェントをブロックすることになります。
Source: https://armature.tech/blog/which-tools-coding-agents-install
Qwen 3.8 27B が Cerebras 上で毎秒1500トークンで利用可能に
CerebrasはQwen 3.8の27Bパラメータモデルを、自社のウェーハスケールエンジン（WSE-3）上でリクエストあたり毎秒1500トークンで提供しています。参考として、27BモデルをvLLMで一般的なA100クラスター上において合理的なバッチサイズで提供した場合、リクエストあたりおよそ80〜150トークン/秒程度になるため、これは単一リクエストのスループットにおいて約10倍の改善に相当します。
このアーキテクチャ上の理由は、Cerebrasのメモリ帯域幅にあります。WSE-3は44 GBのオンチップSRAMを統合しており、総計約21 PB/sの帯域幅を持っています。自己回帰的デコーディングはコンピューティング律速ではなくメモリ帯域幅律速であり、単一シーケンスの各フォワードパスでは、1トークンを生成するために全パラメータセットを一度読み込む必要があります。GPUクラスターでは、モデルの重みはHBM（H100 SXMの帯域幅は約3.35 TB/s）およびNVLinkファブリックを経由して転送される必要があります。一方WSE-3では、重みはオンダイSRAMの中またはその近傍に収まるため、メモリレイテンシが大幅に削減されます。
トレードオフはバッチスループットにあります。Cerebrasのアーキテクチャは低バッチサイズにおけるレイテンシに最適化されており、従来のGPUクラスターは数百の同時リクエストをバッチ処理する際に、大きなバッチでコンピューティング利用率が向上するため、総合スループットで優れています。インタラクティブな低レイテンシアプリケーション（リアルタイムのコード補完や、各ステップの出力が次のステップの入力となるエージェントループ）においては、リクエストあたり1500トークン/秒は非常に有用です。高い並列性を持つバルク推論ジョブに対しては、継続的バッチ処理を行うGPUクラスターがトークンあたりのコストで優位になる可能性が高いです。
Qwen 3.8の27Bは特に、thinking/non-thinkingハイブリッドモデル（Qwenの「budget forcing」機構）であるため、1500トークン/秒という数値は純粋なベースモデルの場合よりも重要な意味を持ちます。思考チェーンは長くなる可能性があり、レイテンシはチェーンの長さに対して乗法的に累積するためです。
Source: https://inference-docs.cerebras.ai/models/overview
1993年製Amigaゲームをリバースエンジニアリングし、LLMに68000アセンブリを読ませてGodotに移植する
この記事では、具体的なリバースエンジニアリングのワークフローを詳述しています。著者は1993年製Amigaゲームのバイナリから生のMotorola 68000アセンブリを直接LLM（Claude）に入力し、Godot 4向けのゲームロジックをGDScriptで反復的に再構築しました。
68000は直交アドレッシングモードを持つクリーンなCISCアーキテクチャであり、不規則なエンコーディングを持つx86などと比較してLLMによる解析に適しています。著者はバイナリをvasmのモニターモードで逆アセンブルし、全体のリストをまとめてダンプするのではなく、ルーチンを関数単位で入力しました。これによりコンテキストウィンドウを管理しやすい状態に保ちつつ、使用パターンから変数の役割をLLMが推測できるだけの局所性を確保しました。
LLMが具体的に貢献した点としては、blitter操作シーケンス（2D演算用のAmigaカスタムチップのDMAエンジン）の識別、フラグ操作パターンからの衝突検出ロジックの再構築、copper listのタイミング構造をスキャンライン効果を説明するコメントへの変換などが挙げられます。一方で失敗した、あるいは大幅な修正を要した領域としては、割り込みハンドラのセマンティクス（サイクル精度のタイミングが重要であり、LLMは機能的には妥当だがタイミングが不正確な再構築を生成しました）と、自己書き換えコード（速度向上のためにコードが自身のオペランドを書き換えるAmigaで一般的な最適化手法）が挙げられます。
このワークフローは、LLMのニッチなISAに関する知識についての興味深い問いを提起しています。68kアセンブリはレトロコンピューティングコミュニティ、Amiga開発者アーカイブ、コンパイラ出力ドキュメントを通じてトレーニングデータに十分に含まれています。より難解な組み込みISAでは結果が大幅に悪化する可能性が高いでしょう。また著者は、LLMはコードが何をしているかを説明することよりも、慣用的なGDScriptへの等価変換を生成することが苦手だった点も指摘しています。セマンティックな再構築が正確だった場合でも、生成コードの構造については手動でのクリーンアップが必要でした。
Source: https://babyloniantwins.com/blog/porting-a-1993-amiga-game-to-godot/
OpenAI の GPT-6 Astra の ARC-AGI-3 における性能
ARC Prize は、ARC-AGI-2 で高スコアを可能にしていたパターンマッチング戦略に対抗するよう設計された更新版 benchmark である ARC-AGI-3 における GPT-6 Astra の性能を公開しました。ARC-AGI-3 のタスクは、新規グリッド変換に対する多段階の compositional reasoning を必要とし、設計上 training セットからの漏洩が不可能な構造になっています。
報告されたスコアは、執筆時点でリンク先の投稿において相対的な順位以上の具体的な数値は開示されていませんが、Astra は従来のフロンティアモデルを上回る「意味のある改善」を達成している一方で、依然として大きな余地を残しているという位置付けです。ARC-AGI-3 は人間の baseline が 95%以上に設定されており、モデルは当初大きく下回ることが想定されています。
ARC Prize の分析において機構的に興味深い点は次の通りです：ARC-AGI-3 では、正しい変換ルールが単一のサンプルセット内で変化するタスク（すなわち、デモンストレーションペアをまたいでルールが非定常となる）が導入されています。これは、モデルがタスクごとに真のルール帰納を行っているのか、それとも training コーパス全体にわたる統計的集約を行っているのかを具体的に検証するものです。このサブセットで高スコアを得ることは、圧縮された記憶に起因するものとは言い難くなります。
評価方法論について、ARC Prize はグラウンドトゥルースの人手による検証を伴うホールドアウトテストセットを使用しており、提出物は推論中のインターネットアクセスを防止するサンドボックス環境で実行されます。これにより、既知のテストセットに対するプロンプトエンジニアリングを API アクセスで行えるリーダーボードと比較して、benchmark の不正対策が大幅に強化されています。
より広い意義として、ARC-AGI スコアは「AGI の進歩」に関する公開議論を密接に追跡していますが、この benchmark が測定しているのは特定の限られた能力（新規視覚ルール帰納）に過ぎません。非定常ルールのサブセットにおける Astra の性能は、見出しとなる数値よりも情報量が高いと言えます。
Source: https://arcprize.org/blog/astra
GPT-6 Astra
OpenAIはGPT-6 Astraをリリースしました。これはGPT-4oおよびoシリーズの後継として位置付けられたマルチモーダルモデルです。テクニカルレポートはアーキテクチャの詳細に乏しいですが、開示された機能には以下が含まれます：ネイティブなリアルタイム音声・映像理解（事後的な文字起こしではない）、長文書にわたる改善された検索を伴う拡張コンテキスト処理、そしてo1/o3のように「高速」モデルと「思考」モデルを切り替える必要のない統合推論モードです。
このモデルは、OpenAIが「persistent memory」と呼ぶものを推論時に統合しています。これはターンやセッションをまたいで維持される構造化された外部状態であり、コンテキスト長とは区別されます。このメカニズムは、拡張コンテキストウィンドウではなく、モデルが管理するkey-valueストアに対する検索システムと見られますが、具体的なアーキテクチャの詳細は開示されていません。
OpenAIが報告したベンチマーク数値：MMLUにおけるGPT-4oからの改善は漸進的（約2〜3ポイント）ですが、エージェント型タスクのベンチマーク（SWE-bench、GAIA）では大きな向上が見られ、これはモデルが知識検索よりもツール使用や多段階タスク完了に特化して最適化されていることと一致しています。HumanEvalおよびLiveCodeBenchにおけるコード生成は主な訴求点ではなく、長いエージェントループにわたる一貫性の持続が強調されています。
「Cyber」バリアント（他の項目で言及）は、セキュリティ向けにチューニングされたバージョンであり、システムプロンプトの修正と責任ある情報開示およびペネトレーションテストのユースケースを対象とした追加RLHFを備えていますが、アーキテクチャが異なる別モデルではありません。
重要な注意点：HNのディスカッション時点では、このモデルは限定的なロールアウト中です。報告されているベンチマーク数値はOpenAI自身によるものであり、独立した第三者による評価は投稿時点ではまだ利用できません。
Source: https://openai.com/index/gpt-6-astra/
Gemini 3.8 Flash と 3.8 Flash Cyber
GoogleがGemini 3.8 Flashと「Flash Cyber」バリアントをリリースしました。Flashはトークン当たりのレイテンシとコストを最適化したGoogleの効率化ティアに位置しており、3.8は2.0 Flashからのアップデートを表しています。主な主張としては、instruction followingの改善、特にマルチファイル編集における coding performanceの向上、そして実用上より信頼性が高くなった100万トークンのcontext windowが挙げられています（以前の100万トークン対応モデルは、実際には約20万トークンを超えると検索精度が大幅に低下していました）。
Flash Cyberはより技術的に興味深い公開内容です。CTFチャレンジの解決、脆弱性分析、コード監査といったサイバーセキュリティワークフロー向けにfine-tuningされています。GoogleはCyberSecEvalや内部レッドチームタスクスイートを含むサイバーセキュリティベンチマークにおいて、汎用Geminiモデルを上回ると述べています。このfine-tuningには、セキュリティコーパスに対する単純なsupervised fine-tuningだけでなく、セキュリティ固有の報酬シグナルに対する reinforcement learningも含まれているようです。
3.8 Flashのアーキテクチャは、Gemini 2.xシリーズのmixture-of-experts構造を維持しており、トークンごとに選択的なexpert activationを行います。これが、同等のパラメータ数を持つdenseなモデルと比べた場合の速度・コスト効率の主な源泉となっています。Googleは総パラメータ数やexpert数を公開していません。
Cyberバリアントは、GoogleのポストではうまくかわされているデプロイメントS上の問題を提起しています。強化されたセキュリティ推論が攻撃的な目的で使用されることを防ぐセーフガードは何か、そしてfine-tuningが既存のsafety tuningとどのように相互作用するのか、といった問いがあります。投稿には技術的な詳細のない「責任ある利用ポリシー」への言及があるのみです。同じニュースサイクルでリリースされたOpenAIのCyberバリアントと比較すると、セキュリティ特化型LLMをひとつの製品カテゴリとして推進する協調的な動きがうかがえます。
K2 Horizon: 6つのオープンモデルからなる連携フリート
IFM AIは、独立したモデルとしてではなく、協調フリートとして動作するよう設計された6つのオープンウェイトモデルのシステム、K2 Horizonをリリースしました。このアーキテクチャは「connected（連携型）」と表現されており、各モデルが共通のembedding空間を共有し、モデル間の一貫性を目的とした学習を行っている点が特徴です。すなわち、あるモデルの出力が、ドメインシフトのアーティファクトを生じることなく、別のモデルへの入力として解釈可能であることが期待されています。
6つのモデルはタスク軸に沿って専門化されており、推論、コード生成、文書理解、マルチモーダル知覚、構造化データ（表形式/SQL）、そしてクエリを振り分けるコーディネーター/ルーターモデルから構成されています。コーディネーターはパラメータ数が最も小さいモデルであり、システムレベルのmixture-of-expertsルーターとして機能します。つまり、単一のMoEモデル内でトークンをルーティングするのではなく、クエリ全体を専門モデルへルーティングします。
共有embedding空間が主要な技術的主張の核心です。各スペシャリストは共通のベースモデルからfine-tuningされており、モデルの境界を越えた意味的な整合性を保証するcontrastive objectiveが用いられています。これは、chain-of-modelワークフローをサポートすることを目的としており、例えば文書理解モデルが抽出した構造化された事実を、情報損失を招く明示的なシリアライズ/デシリアライズのステップなしに推論モデルへ渡すといった利用が可能です。
ウェイトはオープンライセンス（投稿によればApache 2.0）のもとで公開されています。モデルのパラメータ数は7Bから70Bの範囲です。個別のスペシャリストタスクにおけるbenchmark結果は、同等サイズの単一モデルと競争力がありますが、複数の専門領域にまたがるマルチステップタスクにおけるフリートの総合性能こそが差別化の主張であり、それらは独立して検証することが最も難しいbenchmarkでもあります。
未解決の問題として、共有embedding空間の整合性に関する主張には慎重な検討が必要です。embeddingが幾何学的に整合していることを示すだけでは、下流のスペシャリストが共有表現を同一に解釈することを保証するものではありません。
Source: https://ifm.ai/blog/k2/
OpenAIがGPT-6 Astraの展開を開始
CNBCの記事は技術的な詳細ではなく展開のロールアウトを取り上げていますが、OpenAIの発表には含まれていない運用上の関連データポイントがいくつか含まれています。GPT-6 AstraはまずChatGPT PlusおよびProユーザーに展開され、APIアクセスはウェイトリストで制限されています。「Cyber」バリアントは、セキュリティリサーチのユースケースが確認されたエンタープライズアカウントに明示的に制限されており、コンシューマーアクセスはありません。
OpenAIが段階的なロールアウトを行う理由として公表しているのは、実際の負荷下での永続的メモリシステムの評価です。retrieval-augmented memoryアーキテクチャはChatGPTスケール（2026年初頭時点で週間アクティブユーザー数は5億人超と報告されています）でのストレステストが実施されておらず、ソフトローンチなしに完全展開を行うと、スケール時のretrieval一貫性障害という許容できないリスクが生じます。
CNBCの記事ではさらに、AstraのマルチモーダルビデオCapabilityが当初30秒のクリップに制限されていることも指摘しています。これはモデルが理論上より長いシーケンスをサポートしているにもかかわらずであり、この制限はモデル側ではなくインフラ側（ビデオエンコーディングパイプラインのスループット）に起因しています。これはGPT-4Vのリリース時に、最終的な本番Capabilityに対してロールアウト時のvision capabilityがスロットルされたパターンと一致しています。
インフラの観点からは、永続的メモリシステムはステートフルなサービングを意味します。各ユーザーセッションは、そのユーザーのメモリストアにアクセスできる推論バックエンドにルーティングされなければなりません。これは標準的なステートレスな水平スケーリングを複雑にし、段階的なロールアウトとウェイトリストの両方を説明するものと考えられます。ステートレスなLLM推論を前提とするシステム（現在のほとんどのサービングフレームワークの標準）は、このパターンをスケールでサポートするためにアーキテクチャの変更が必要になります。
Source: https://www.cnbc.com/2026/09/03/open-ai-astra-gpt-6-cyber.html
注目の新規リポジトリ
NiluK/worldmodels101
9つのビジュアルチャプターにわたってワールドモデルを網羅する、無料かつ自己完結型のインタラクティブコースです。カリキュラムは、予測と潜在ダイナミクスから始まり、プランニング、JEPA（Joint Embedding Predictive Architecture）、ビデオ生成モデル、そして失敗モードへと進んでいきます。これはSchmidhuber時代のRNN予測器から現代のcontrastiveおよびmasked-predictionアプローチに至る研究文献の流れを反映した、教育的に一貫したアークを成しています。
本コースはブラウザベースで、静的なスライドではなくインタラクティブな可視化を採用しているため、潜在空間のロールアウトや想像ベースのプランニングといった抽象的な概念を具体的に理解することができます。JEPAの扱いは特筆に値します。LeCunのエネルギーベース・非生成的なワールドモデルの枠組みを、diffusionスタイルおよびautoregressiveスタイルのビデオモデルと並置することで、読者がそれぞれのinductive biasを直接比較できるようになっています。失敗モードの章では、予測誤差の累積、プランニング中の分布シフト、表現崩壊といった問題を扱っており、これらはサーベイ論文では往々にして軽く触れられるにとどまる論点です。
本リポジトリはコードベースというよりも主に教育インフラですが、その内容の深さは博士課程レベルに近いものがあります。embodied AI、model-based RL、またはビデオ予測の分野に参入する研究者向けの体系的なオンボーディングリソースとして、また20本もの関連性の薄い論文を読ませることなく新しいラボメンバーを方向づけるための参考資料として有用です。
Source: https://github.com/NiluK/worldmodels101
pis10/TraceSurface
フロントエンドのJavaScriptに埋め込まれた隠しAPIエンドポイントを発見し、不正アクセスの可能性を探るセキュリティ調査ツールです。コア設計は、2つの相補的な技術を組み合わせています。ひとつはダイナミックブラウザトレーシング（ヘッドレスブラウザを計装し、実行時にXHR/fetchコール、WebSocketハンドシェイク、service-workerリクエストをインターセプト）、もうひとつはJSバンドルの静的解析（ASTレベルのパースにより、文字列リテラル、ルートパターン、通常のセッションでは決して発火しないエンドポイント構築ロジックを抽出）です。
この組み合わせが重要なのは、どちらの技術単独でも盲点があるためです。静的解析はデッドコードのエンドポイントを捕捉し、動的トレーシングは静的パーサーが見逃す動的に組み立てられたURLを捕捉します。エンドポイントの列挙後、TraceSurfaceは認可プローブを実行します。具体的には、認証トークンなし、あるいは低権限の認証情報でリクエストをリプレイし、エンドポイントが単にURLを難読化しているだけでなく、アクセス制御を適切に実施しているかどうかを検証します。
想定ユーザーは、SPAやモバイル寄りのウェブバックエンドを監査するペネトレーションテスターおよびバグバウンティ研究者です。中国語の説明文から、このカテゴリで重要なツールを多数輩出している中国のセキュリティコミュニティ発のツールであることがわかります。短期間で344スターを獲得していることは、実務者への実際の普及を示しています。React、Vue、またはAngularフロントエンドを通じて公開されているAPIサーフェスに対してレッドチーム演習を行うあらゆる組織にとって有用です。
Source: https://github.com/pis10/TraceSurface
grpcer/ownmem
AIコーディングエージェント（Claude Code、Codex、Cursor、Gemini CLI、およびその互換ツール）向けに設計された、Git-nativeな永続メモリレイヤーです。ベクターデータベースによるin-context retrievalに依存するのではなく、ownmemはメモリをプレーンファイルとしてローカルのGitリポジトリにコミットし、決定論的な recall を実現します。つまり、同一コミットに対する同一クエリは常に同じ結果を返し、embedding modelのドリフトや近似最近傍探索の非決定性が生じません。
メモリのフォーマットはプロジェクトリポジトリ内の .ownmem/ にチェックインされた構造化テキストであり、ソースコードと並んでメモリのdiff、バージョン管理、監査が可能です。エージェントはシンプルなAPIを通じてメモリを書き込み、recallはセマンティックなembeddingではなく完全一致または軽量なファジーテキスト検索によって行われます。これは意図的なトレードオフであり、再現性と外部サービス依存ゼロを得る代わりに、セマンティックな汎化能力を犠牲にしています。
実用的な動機として、LLMコーディングエージェントはセッションをまたいでプロジェクト固有の規約、過去のデバッグ上の意思決定、チームの慣習を繰り返し忘れてしまうという問題があります。ownmemはクラウドサービスを必要とせずにこのレイヤーをローカルに永続化するため、プロプライエタリなコードベースにとって重要な選択肢となります。Git-nativeな設計により、メモリはclone時にリポジトリと一緒に持ち運ばれるため、オンボーディングの一貫性が保たれます。主な制限は、embeddingベースのアプローチと比較して、言い換えられたクエリに対するrecallの精度が低下することです。
Source: https://github.com/grpcer/ownmem
azrtydxb/procoder
AIコーディングエージェントに対して、コミット時にシニア開発者レベルの規律を課す品質強制バイナリです。ランタイム依存関係なしの単一Goバイナリとして構築されており、20以上のエージェントと統合し、コーディングループの3つのポイントで動作します。
第一に、コミットゲートは未チェック項目（TODO、未解決マーカー、エージェント自身がフラグを立てた未テストのブランチ）を含む変更セットを拒否します。これらを警告ではなく失敗として扱います。第二に、品質コントローラーがエージェントのタスク完了自己報告をインターセプトします。事前に定められた品質基準が満たされていない状態でエージェントが作業完了とマークした場合、ゲートは完了シグナルを拒否し、反復処理を強制します。第三に、lessonsループがエスケープしたバグに対してポストモーテムのタグ付けを実行し、各バグを欠陥タイプ別に分類して、そのクラスに対するエージェントの将来の動作への制約としてその分類をフィードバックします。
アーキテクチャ上の洞察は、現在のコーディングエージェントは「完了している」状態になるのではなく「完了しているように見える」状態に最適化されているという点です。エージェントは完了シグナルに反応するため、そのシグナルを制御することで動作が変わります。これはprompt engineeringアプローチではなく外部強制レイヤーであるため、モデルのアップデートに対して堅牢です。依存関係なしの単一バイナリにより、CIパイプラインへの統合が極めて容易です。主な未解決の問題は、品質コントローラーの述語を、誤拒否と不十分なカバレッジの両方を避けられるほど正確に仕様化できるかどうかという点です。
Source: https://github.com/azrtydxb/procoder
Flaminis/Dalaran
Rerunのハードフォークであり、ロボティクスファーストのマルチモーダル時系列可視化とデータインフラに特化して方向転換されたプロジェクトです。既存の .rrd 録画ファイル（Rerunのネイティブバイナリフォーマット）との後方互換性を維持しつつ、ROS 2ネイティブ統合とロボティクスドメインのデータ型を優先するアーキテクチャ上の分岐を行っています。
Rerunが汎用の可視化ツールキットであるのに対し、Dalaranの設計上の選択はロボティクス固有の要件を反映しています。具体的には、ロボットシステムで典型的なレイテンシとデータ量における異種センサーストリーム（LiDARポイントクラウド、カメラフレーム、IMU、ジョイント状態、TFトランスフォーム）の同期再生、変換オーバーヘッドなしの密なROS 2メッセージ型サポート、そしてロボット実験のロギングと再生のためのデータインフラプリミティブが挙げられます。Apache-2.0ライセンスとハードフォーク構造により、上流の制約なしにRerunのロードマップから乖離することが可能です。
スター数778というのはニッチなロボティクスツールとしては高く、プラグインエコシステムとしてではなくロボティクスをファーストクラスの関心事として扱う可視化スタックに対するコミュニティの実際の需要を示唆しています。今後の主要な技術的課題は、Rerunのウェブベースストリーミング機能との同等性を維持できるかどうか、また数十のセンサーにわたって100 Hz以上で動作するオートノミースタックが生成する現代的なデータセットの規模にどう対応するかという点です。
Source: https://github.com/Flaminis/Dalaran
Gnosil/semantix
LLMベースのエージェントをより効率的にし、自己進化を可能にすることを目指したセマンティック・エージェント・カーネルです。核心的なアイデアは、セマンティックレベルで動作することにあります。すなわち、エージェントのゴール、記憶、エージェント間の通信を、生のプロンプト文字列ではなく構造化されたセマンティック・オブジェクトとして表現し、それらの表現を計画立案、ツール選択、および能力更新の指針として活用します。
ここでいう自己進化とは、エージェントが蓄積された経験に基づいて自身の行動ポリシーやスキルライブラリを修正することを指します。このメカニズムは、エピソードをまたいで保持される永続的なセマンティック状態表現を必要とします。「カーネル」というフレーミングは、semantix をアプリケーションロジックではなくメモリ管理やスケジューリングを提供するOSカーネルに類比した、特定のエージェントが構築される基盤インフラとして位置づけるものです。
このリポジトリは初期段階にあり、実装よりも説明およびアーキテクチャの方が成熟しています。関連する技術的課題としては、非構造化自然言語に逆戻りすることなくエージェントの意図を捉えられるほど表現力豊かなセマンティック表現を定義すること、および発散せず収束する自己修正ループを設計することが挙げられます。エージェント・アーキテクチャ、ツール使用フレームワーク、またはマルチエージェント協調システムを研究している研究者にとっては、セマンティック状態の抽象化を検討する価値があるかもしれません。実装の成熟度について継続的に注視する価値があります。
Source: https://github.com/Gnosil/semantix
orbien-org/orbien
Rustで書かれた軽量・高性能なイントラネット浸透プロキシで、バイナリサイズは約5 MBです。トランスポート層プロトコルとしてTCP、QUIC、KCP、WebSocketの4種類をサポートし、アプリケーション層プロトコルとしてTCP、UDP、HTTP、HTTPS、SOCKS5の5種類をプロキシします。このプロトコルマトリクスにより、標準的なトランスポートをブロックする制限的なネットワーク環境でもトンネリングを柔軟に行えます。
QUICとKCPのサポートは技術的に重要な意義を持ちます。KCPはUDP上の信頼性のあるARQプロトコルであり、帯域幅を犠牲にして低レイテンシに最適化されており、パケットロスや遅延ジッタの大きいリンクで有効です。QUICはTLS 1.3による多重化ストリームを提供し、マルチコネクションシナリオにおけるハンドシェイクのオーバーヘッドを削減します。この組み合わせにより、orbienはfrpのようなTCP専用ツールと比較して、モバイル環境や国際通信環境においてより高い堅牢性を発揮します。
Rustによる実装は、ガベージコレクションによる停止を伴わないメモリ安全性を実現しており、高スループットで並行トンネルを処理するプロキシにとって重要な特性です。Electronを使用しないネイティブのクロスプラットフォームデスクトップクライアントとサーバー側のWeb UIを同梱しており、デプロイの手間を軽減します。スター数1177はここで紹介するエントリの中でも上位に位置し、軽量なセルフホスト型トンネルインフラに対する活発な需要を反映しています。主なユースケースは、ローカル開発サーバーの公開、リモートデバイスアクセス、およびイントラネットサービスのブリッジングです。
Source: https://github.com/orbien-org/orbien
rome-os/rome
Romeは「agentic OS」——Unix プロセスではなくエージェントプロセスをプリミティブとするオペレーティングシステム——として自らを位置づけています。このプロジェクトはまだ初期段階にあり、説明も簡潔ですが、アーキテクチャ上の主張は次のとおりです。AIエージェントが独自のリソース要件、スケジューリング、プロセス間通信、永続化セマンティクスを持つ長期稼働の自律プロセスへと発展するにつれ、エージェントのライフサイクル管理を中心に設計された基盤は、POSIX スタイルの OS プリミティブでは明確に表現できない抽象化を提供できるというものです。
具体的には、エージェントのスポーン・ターミネート、エージェント間のケイパビリティ委譲、エージェント再起動をまたいだ永続的ゴール状態、ファーストクラスの OS リソースとしてのサンドボックス化されたツールアクセス、そして LLM のインタラクションパターンに適合したメッセージパッシングプリミティブ（IPC としての構造化プロンプト）といったコンセプトを中心に設計されています。比較対象となるプロジェクトとしては AutoGPT のエージェントループや LangGraph のステートフルグラフ実行などが挙げられますが、「OS」というフレーミングはより低レベルなインフラへの野心を示唆しています。
462 スターを獲得しており一定の注目を集めていますが、リポジトリの内容はプロダクションシステムというよりもアーキテクチャ設計とスキャフォールディングが中心と思われます。技術的に興味深い問いとしては、プロセスモデルの形態（シングルスレッドのイベントループか真の並行性か）、エージェントメモリの分離と共有の方法、スケジューリング層が LLM を意識しているか（例えば推論呼び出しのバッチ処理）といった点が挙げられます。マルチエージェントインフラやエージェントランタイム設計に取り組んでいる方には注目に値するプロジェクトです。
Source: https://github.com/rome-os/rome