デイリーAIダイジェスト — 2026-06-30
arXiv ハイライト
パラメータではなく、ホライズンをスケールする：35BエージェントでTrillionパラメータ相当の性能を達成
問題設定
フロンティアのエージェント的能力は、主にパラメータ数のスケーリングによって追求されてきました。Kimi-K2.6やDeepSeek-V4-proは、長いホライズンにわたるツール使用、深いリサーチ、エンジニアリングタスクを処理するために1兆パラメータ規模に位置しています。Agents-A1は、関連するスケーリング軸はパラメータの規模ではなく、ホライズン——軌跡の長さ、およびそれらの軌跡内で発揮されるエージェント的能力の多様性——であると主張しています。本論文では、この考え方をQwen3.5-35B-A3Bから派生した35B Mixture-of-Expertsモデル（アクティブパラメータ3B）で具現化し、長いホライズンにわたる検索、科学的推論、エンジニアリングのベンチマークにおいて1Tクラスのベースラインと同等か、それを上回ると主張しています。
手法
パイプラインは、知識-アクションインフラストラクチャ（図3）の上に構築された3つのステージから構成されています。
知識-アクショングラフ (KAG)。 各ドメイン d に対して、著者らはタプル \mathcal{G}_d = (\mathcal{C}_d, \mathcal{A}_d, \mathcal{O}_d, \mathcal{V}_d)：コーパス、許容アクション、観測、および検証器を定義しています。検索のインスタンス化では、\mathcal{C}_d は段落レベルの証拠を持つwikiコーパス、\mathcal{A}_d はコーパスグラフ上のハイパーリンクによるエンティティ遷移の集合、\mathcal{O}_d は取得されたページテキスト、\mathcal{V}_d は回答エンティティと支持パスが復元可能かどうかを確認するものです。軌跡は制御されたランダムウォークによって生成されます：LLMセレクターがフィルタリングされた発出アンカーから次のエンティティを選択します（曖昧さ解消ページ、ほぼ重複するタイトル、次数の低いノードは除去されます）。終端エンティティが回答となり、連鎖は固有名詞をマスクした自然言語の質問に書き直され、検証器が回答と証拠の一貫性を検証します。次に、search（上位50件の結果）、read_page（LLMによる要約抽出）、およびcode（Pythonサンドボックス）を備えた強力なモデルによって、実際のインターネット軌跡が256Kトークンのコンテキスト下で収集されます。失敗した軌跡や明らかに推測に頼っている軌跡はフィルタリングされ、ターン制限による打ち切りは1ターン巻き戻されて強制的に回答させます。
このKAG駆動の生成により、平均長さ45Kトークン（深いリサーチ44K、コーディング/エンジニアリング48K、科学的20K37K、エージェント的39K、指示追従3K）の約100K軌跡が生成されます。
ステージ1——全ドメインSFT。 レスポンストークンのみのcross-entropy（指示トークンはマスク）を131,072トークンのパックされたシーケンスに適用します。AdamW、学習率 1\times 10^{-5}、ウォームアップ0.05のcosineスケジュール、重み減衰0.1、バッチサイズ16、1エポック。シーケンス内attention maskを伴うsample packingにより、クロスコンタミネーションを抑制し、GPU使用率を回復します。
ステージ2——ドメイン教師。 専門家教師は各ドメインに対してターゲットを絞ったSFTまたはRLによって訓練され、それぞれが一つの能力クラスター（深いリサーチ、コーディング/エンジニアリング、科学的推論、指示追従、エージェント的ツール使用、長いコンテキスト）を捉えます。
ステージ3——マルチ教師ドメインルーティングオンポリシー蒸留 (OPD)。 学生はオンポリシーでロールアウトを行い、ルーターが各ロールアウトをそのドメイン教師に割り当て、顕著な語彙に整合した蒸留目的からgradientが流れます。顕著な語彙整合は教師が選択したトークンサブセットにKLマッチングを制限し、トークナイザーレベルのノイズと、均一なマルチ教師蒸留が典型的に生じさせる破壊的な平均化を軽減します。
結果
評価は、検索（GAIA、BrowseComp、XBench-DeepResearch、SEAL-0）、エンジニアリング（SciCode 288サブ問題、MLE-Bench-Lite 22 Kaggleコンペティション、タスクごとに12時間のH200予算、3シード）、科学的推論（HLE-with-tools、13コンペティションにわたるHiPhO、FS-O、FS-R）、および長いコンテキスト/IF（128Kトランケーションの503 MCQにわたるLongBench V2、IFBench、IFEval）にわたります。検索エージェントは最大300ターンで実行され、各ベンチマークの公式ジャッジによるpass@1で評価されます。
本論文は、総パラメータ数で30倍の差（35B対〜1T）、アクティブパラメータで約300倍の差（3B対数千億）にもかかわらず、Kimi-K2.6およびDeepSeek-V4-proに対して優れた結果を報告しています。主な主張は、ホライズンのスケーリング——平均軌跡長45Kトークン、6つの統合ドメイン、KAGに基づくプロセス監督——が、ボトルネックが世界知識ではなく手続き的能力にあるタスクにおいて、パラメータのスケーリングの代替となるということです。
限界と未解決の問題
- 本論文は、どれだけの利得が (i) KAGによってキュレーションされたSFTデータ、(ii) 専門家教師、(iii) 顕著な語彙OPDから来ているのかを切り分けていません。各ステージのアブレーションなしでは、マルチ教師蒸留の寄与と、KAGデータで単純により長く訓練した場合の寄与が不明確です。
- HiPhO/FS-O/FS-RにおけるAgents-A1のツール補強評価と一部ベースラインのツールなし評価の差異は認識されていますが、比較を混乱させます。1Tベースラインに対する対称的なツール補強の実行により、主張がより確かなものになるでしょう。
- arxiv IDの形式と「Qwen3.5-35B-A3B」、「Kimi-K2.6」、「DeepSeek-V4-pro」への言及は、本論文が先付けまたは合成のプレプリントである可能性を示唆しています。引用する前に出所を確認してください。
- 単一H200での1タスク当たり12時間の実時間というMLE-Bench-Liteの設定では、22コンペティション×3シードにわたる統計的有意性の主張は容易ではなく、抜粋されたセクションには分散のバンドが提供されていません。
- KAGの構築は検索ドメイン（ハイパーリンクウォーク、アンカーフィルタリング）に対して高度にエンジニアリングされており、同一の証拠-検証スキーマの科学的リサーチやエンジニアリングドメインへの汎化は主張されていますが、例えばMLEタスクの検証器の設計は表面化されたセクションには詳述されていません。
なぜこれが重要か
ホライズンのスケーリングがエージェント的ワークロードにおいてパラメータのスケーリングを真に代替できるなら、長いホライズンエージェントのデプロイ経済学は大きく変わります。KAGに基づく軌跡とルーティング蒸留を備えたアクティブパラメータ3BのMoEが、ツール使用の多いタスクにおいて1Tクラスのシステムを置き換えることができます。方法論的な貢献——検証器を持つ知識-アクショングラフと顕著な語彙マルチ教師OPD——は、より小さな専門家統合エージェントを構築するための再利用可能なレシピです。
Source: https://arxiv.org/abs/2606.30616
AsyncOPD: On-Policy Distillationにおけるポリシーの陳腐化はどこまで許容されるか？
On-policy distillation（OPD）は、教師のフィードバックをローカルKL lossを通じて供給しながら、学生LLMが自身のロールアウトで学習する手法です。OPDがトイ設定から推論スケールのpost-trainingへと移行するにつれて、RLと同様にロールアウトステージが実時間を支配するようになり、非同期パイプライン（ロールアウト、教師スコアリング、学習者更新の分離）が魅力的になります。そのコストはポリシーの陳腐化です。学習者がサンプルを消費する時点では、ロールアウト学生 p_{\mathrm{old}}、キャッシュされた教師スコアのサポート、および現在の学生 p_\theta がすべて異なる可能性があります。本論文は、その陳腐化がOPD固有の設計選択——KL方向と有限の教師スコアキャッシュ——とどのように相互作用するかを初めて体系的に研究し、ストリーミング非同期システムであるAsyncOPDを提案します。
セットアップとキャッシュ制約
完全な語彙の教師logitsであれば密なKLが可能になりますが、非同期パイプライン全体でトークンごとに |V| 次元の分布をキャッシュして転送することは現実的ではありません。著者らは2つの実用的なキャッシュに限定しています。すなわち、sparse top-k 教師logitsと、1サンプルのモンテカルロスコアです。パイプラインは時間的に分離された3つのステージ——プレフィックスとアクションを選択するロールアウト、それらに注釈を付ける教師スコアリング、後で学生を更新する学習者——を持つため、プレフィックスレベルの陳腐化はロールアウト時に固定されます。アクションレベルの陳腐化のみが推定器の設計によって対処可能であり、それが本論文の焦点です。
KL方向が陳腐化への感度を決定する
最初の結果は構造的なものです。forward KL \mathrm{KL}(q\Vert p_\theta) は教師による重み付けがされているため、期待値は教師のサポート上に存在します。キャッシュされたtop-k 教師アクションは正確に適切なサポートであり、陳腐化は訪問されたプレフィックスにのみ影響し、アクションセットには影響しません。reverse KL \mathrm{KL}(p_\theta\Vert q) は学生による重み付けがされており、関連するサポートは S_\theta(s) = \mathrm{TopK}(p_\theta(\cdot\mid s),k) ですが、キャッシュには S_{\mathrm{old}}(s) = \mathrm{TopK}(p_{\mathrm{old}}(\cdot\mid s),k) が保持されています。S_\theta に新たに昇格したアクションには教師スコアがなく、S_{\mathrm{old}} に限定されたimportance reweightingではそれらを回復できません。したがって、reverse-KL OPDは陳腐化が実質的に問題となるレジームです。
Reverse KLに対するpolicy-gradient代理目標
Reverse KLが難しいケースであることを踏まえ、著者らはどのRLスタイルの安定化手法が適用可能かを検討します。機械的なPPOの適用は、behavior policyを p_{\mathrm{old}} とし、ロールアウト時点でのadvantageを
A_{\mathrm{old}}(a,s) = \log q(a\mid s) - \log p_{\mathrm{old}}(a\mid s),
として固定し、クリッピングされた旧対現在の比率を適用します。代替手法は A_\theta(a,s) = \log q(a\mid s) - \log p_\theta(a\mid s) であり、現在の学生の下で再計算されます。経験的には、クリッピングなしの A_\theta がより安定した選択です。これは現在のreverse-KL目標を追跡し、そして重要なことに、クリッピングなしのPPO代理目標を不安定化するimportance ratio \rho_\theta = p_\theta/p_{\mathrm{old}} の重い上側裾を抑制します。同じno-clip設定の下で、\rho_\theta のp99は A_{\mathrm{old}} 変種と比較して大幅に削減されます。
解釈としては、標準PPOにおけるクリッピングは、陳腐なポリシーの下で計算されたadvantageを部分的に補正しているというものです。p_\theta の下でadvantageを再計算することで、報酬が疎なリターンではなく密なKLシグナルであるOPDのケースにおいて、クリッピングの必要性の多くが解消されます。
キャッシュサポート
A_\theta を参照代理目標として固定した場合でも、キャッシュサポートの問題は残ります。S_{\mathrm{old}} 上のsparse top-k は、現在のreverse-KL目標に対してバイアスがありサポートが一致しない推定器です。S_\theta が S_{\mathrm{old}} から乖離するにつれて、バイアスは陳腐化とともに増大します。1サンプルMCはロールアウトサポート上では不偏ですが、分散が高いです。本論文の処方箋は、S_{\mathrm{old}} が S_\theta の合理的な代理として機能し続けるよう十分な頻度で更新されるsparseキャッシュとともに、クリッピングなしの A_\theta を維持することです。これにより、陳腐化のバジェットを推定器のハックではなくスケジューリングパラメータに変換します。
AsyncOPDシステム
システムへの貢献は、AReaLのスタイルでロールアウト、教師スコアリング、学習者更新をオーバーラップさせる完全非同期パイプラインです。対比されるのは、VeRLのstep-offスケジューラです。これはロールアウトラグを k 回の学習者更新に固定しますが、完全なロールアウトバッチが完成するまで待ってから下流に解放します。AsyncOPDはその代わりにストリーミングします。ワーカーは重みの同期のみで一時停止し、処理中のプレフィックスは同期をまたいで保持され、教師スコアリングは完成したアイテムが到着次第消費し、学習者はスコアリングされたバッチが準備できると同時にステップを進めます。これにより、バッチゲート型スケジューラにおける遅延ワーカーによる長テール待ちが解消されます。
限界とオープンクエスチョン
分析はローカルKLフィードバックに限定されており、教師の価値関数やより密なプロセス報酬を使用するOPD変種はカバーされていません。プレフィックスレベルの陳腐化は認識されていますが、推定器設計ではなくスケジューラ設計に明示的に委ねられているため、非常に積極的な非同期によって引き起こされるプレフィックス分布のシフトは理論的に有界化されていません。sparse top-k が S_\theta の忠実な代理として機能し続けるためのキャッシュ更新頻度は経験的に扱われています。最後に、headline上の非対称性——forward KLは堅牢であり、reverse KLは脆弱である——は既知のトレードオフ（モードカバリング対モードシーキング）を明確にしますが、それ自体では固定された計算量の下でどちらの目標がより優れた下流の推論学生を生み出すかを示しません。
重要性
OPDはRLのロールアウトボトルネックを継承しており、明白な解決策——非同期化——はKL方向と教師キャッシュと非自明な形で相互作用します。クリッピングなしの A_\theta とストリーミングスケジューラを、脆弱なreverse-KLレジームに対する実行可能なレシピとして特定することで、多くの実践者が好むreverse-KL目標を諦めることなく、on-policy distillationのpost-trainingをスケールさせるための具体的な設計図が提供されます。
Source: https://arxiv.org/abs/2606.24143
TACO: エージェント的ツール利用のためのTool-Augmented Credit Optimization
問題設定
コードツール型ビジュアルエージェント — Pythonコードを発行して画像のクロップ・ズームを行い、その結果を観察してさらに推論するモデル — は、現在、細粒度視覚質問応答の主流パラダイムとなっています。問題点は、ツール呼び出しの価値が均一ではないという点です。あるクロップは小さな文字を明確化し、ある場合は回答を変えず、またある場合はコンテキストを除去することで積極的に誤解を招く可能性があります（図1参照）。
結果のみに基づくRL（例：文字列マッチング報酬を持つバニラGRPO）はこれらのケースを区別できません。誤解を招くクロップをモデルが回復した軌跡も、実際に情報をもたらしたクロップと同じ +1 を受け取り、勾配は両者を等しく強化してしまいます。既存のプロセス報酬スキームは、外部の判定モデルを必要とするか（コストが高く、操作可能）、個々のコード呼び出しへのクレジット割り当てに失敗するかのいずれかです。TACOは、補助的な判定器を導入することなく、この呼び出し単位のクレジット割り当て問題を解決することを目指しています。
手法
TACOは、2つの結合したadvantageチャネルを持つGRPOの変種です（図2）。
設定。 軌跡は、暫定回答 a_1 を生成するツール使用前推論 \mathcal{T}_1、サンドボックス内で実行されて画像観測 \mathrm{IMG} を返すコードセグメント \mathcal{C}、最終回答 a_f を生成するツール使用後推論 \mathcal{T}_2 に分解されます。検証可能な結果報酬は、ルールベースの回答チェックによる r_{\mathrm{out}}(\cdot)\in\{-1,0,+1\} です。
Differential Answer-Probe Reward（DAPR）。 \mathcal{T}_1 の境界と \mathcal{T}_2 の後に挿入されるプロブトークンにより、ツール結果を見る前後でのモデルの最良回答を引き出します。呼び出し単位の価値は結果報酬の差分として定義されます：
\Delta = r_{\mathrm{out}}(a_f) - r_{\mathrm{out}}(a_1).
これは有用な呼び出しに対して正、誤解を招く呼び出しに対して負、無操作に対してゼロになります。これは学習済みプローブからの絶対スカラーではなく、同じルールベースチェッカーの差分であるため、検証器のロバスト性を継承し、プローブハッキングに対して自然に耐性があります — 両側が同じ引き出し方法を使用するため、モデルはプローブを単独で操作することで \Delta を水増しすることができません。
Outcome-Gated Advantage Routing（OGAR）。 標準GRPOの最終回答advantage A_1（グループ正規化された r_{\mathrm{out}}）は、そのセグメントが回答に因果的に関与している場合にのみトークンセグメントにルーティングされ、そうでない場合はゲートアウトされます。具体的には、A_1 は \mathcal{T}_2 トークンには常に流れますが（それらが a_f を生成したため）、ツール呼び出しが回答を変えなかった場合にのみ \mathcal{T}_1 にも流れます。DAPRから導出されたプロセスadvantage A_2 はコードトークン \mathcal{C} に適用され、\Delta \geq 0 の場合にのみlossにゲートインされます。これにより、ポリシーは有用または中立的な呼び出しを発行するよう促され、誤解を招く呼び出しにはペナルティが課されます（A_2 < 0 のゲート解除、または正のクレジットを受け取らないことによって）。
学習。 2段階構成：（1）Thymeコーパスの再キュレーションされたサブセットに対するSFTコールドスタート。フィルタリング基準は（i）サンドボックス実行の有効性、（ii）ツールの必要性 — Qwen2.5-VL-7Bがpass@8{=}1でツールなしに解ける問題を除外、（iii）Gemini-3-Proによる推論品質スコアリング。（2）ゲート付き二重チャネルadvantage (A_1, A_2) を用いたGRPO。
結果
7B比較（表2、A100バッチ1）において、TACOは精度を向上させながら同時にレイテンシを低減します — 後者はポリシーが冗長なツールラウンドを減らすことを学習するためです：
- V^*: 89.6%（PyVision-RLの88.7%、DeepEyesの85.6%に対して）；レイテンシ 2.3秒 vs. 3.6秒。
- HR-Bench-4K: 83.8%（次点78.1%に対して）；レイテンシ 3.2秒 vs. 5.5秒。
- HR-Bench-8K: 81.6%（PyVision-RLの74.3%に対して）、7.3ポイントの差；レイテンシ 3.5秒 vs. 6.2秒。
- MathVision: 35.8%（CodeV-RL-7Bの33.6%に対して）。
- MMStar: 69.3%（67.6%に対して）。
定性的には、エージェントは精密かつ一発のクロップを学習します — 例えば、背景バナーを 2\times ズームして隠れた「BNP Paribas」のワードマークを読む（図4）— ベースラインのような多段階の投機的クロッピングとは対照的であり、これがレイテンシ低減の説明となります。
限界と未解決の問題
- DAPRの \Delta は、プローブがモデルのツール使用前の誠実な回答を引き出すことに依存しています。SFTがすでに回答ヘッドとツール出力の予測を絡め合わせている場合、a_1 は反事実として不適切になる可能性があります。論文は差分形式によるロバスト性を主張していますが、a_1 と a_f の両方を同じように系統的にバイアスするプローブは依然として \Delta=0 を生成し、有用なクレジットを静かにマスクしてしまいます。
- 正の \Delta のゲーティングに限定することで、情報提供的であるが回答を変えない呼び出しの価値を過小評価する可能性があります — 例えば、argmaxを変えずに確信度を高めるクロップなど。
- 結果は7Bベースラインに対する7Bのみのものです。ツール使用前の a_1 が容易なsplitでほぼ最適に近くなる可能性のある大規模モデルサイズでの差分プローブのスケーリング挙動は不明です。ツール必要性フィルタは学習時にはある程度これを制御しますが、評価時には制御しません。
- 報酬はルールベースの文字列マッチングに紐付けられています。オープンエンドなVQAや生成的回答には、より許容度の高い検証器が必要となり、判定器への依存が再び生じる可能性があります。
なぜこれが重要か
TACOは、エージェント的ポリシーにおける呼び出し単位のクレジット割り当てが、絶対的なプロセススコアではなく、自己プローブによる反事実にわたる結果報酬の差分を活用することで、既存の検証器のみで実現できることを示しています。判定器不要のプロセスクレジットと結果条件付きルーティングの組み合わせにより、精度の向上（HR-Bench-8Kで最大7.3ポイント）と推論時の効率化が同時に得られます。これは、適切な勾配ルーティングが与えられれば、「いつツールを呼び出すか」が「どの回答を生成するか」と同様に学習可能なシグナルであることを示唆しています。
Source: https://arxiv.org/abs/2606.30251
OSWorld2.0: 長期的な実世界タスクにおけるコンピュータ使用エージェントのベンチマーク評価
問題設定
コンピュータ使用のベンチマークは、エージェントの能力向上に後れを取ってきました。OSWorld 1.0のタスクは人間がおよそ2分で完了でき、約30回のツール呼び出しで解決できます。現代のフロンティアエージェントはこれらを飽和させており、実際のデスクトップ作業で支配的な障害モード——クロスアプリケーションの状態追跡、動的環境、ノイズを含むアーティファクト下での検証——を試す機会がありません。OSWorld 2.0はこのギャップを埋めるために108件の長期的なワークフローを対象としており、その人間による完了時間の中央値は約1.6時間で、OSWorld 1.0の約48倍に相当します。また、最大限の思考を用いたClaude Opus 4.7で実行した場合、平均318回のツール呼び出しを必要とし、前作と比べてほぼ1桁多くなっています。
タスク設計
各タスクは、ユーザの目標、現実的な入力アーティファクト、ステートフルな環境、および採点可能な終端状態によって定義された、自己完結型のエンドツーエンドのワークフローです。二つの設計上の不変条件が課されています。第一に、長期的な困難さはサブタスクの単純な連結や繰り返しからではなく、相互依存するワークフロー構造（クロスアプリケーションの依存関係、またはアプリ内での計画・実行・検証ループ）から生じなければなりません。第二に、タスクに関連する情報は、プロンプトの中ではなく、ファイル、ウェブサービス、以前の記録、メールといった本物のアーティファクトやワークスペースの状態の中に存在しなければなりません。代表的な例として、ExpenseFlowの経費精算タスクがあります。このタスクでは、エージェントがチュートリアルPDFを参照し、レガシーポータルをナビゲートし、領収書の金額をGMailおよびChaseBackの記録と照合し、必要な状態を変える新着メールにタスク途中で対応し、以前のレポートから従業員データを復元しなければなりません。
構築は4段階のパイプライン（収集 → 環境のインスタンス化 → 最終状態評価の定義 → 多層監査）に従っており、チームのブレインストーミングと専門家スタイルのアノテーションが約90%のタスクに寄与しています。アノテーターは対象ドメインごとに（チュートリアル、ドキュメント、実践的な使用を通じて）訓練され、タスクをエンドツーエンドで担当しました：指示、入力アーティファクト、環境設定、および評価関数です。各ドラフトは、実現可能性、冗長性、評価の曖昧さについてピアによるクロスチェックを受けました。長いワークフローは特に、エージェントが曖昧な採点基準を悪用しやすいため、これは重要なプロセスです。
このベンチマークは、先行するスイートで十分に代表されていなかった現象を意図的にストレステストします：ストリーミングインタラクション、動的環境（タスク途中での状態変化、例：受信メール）、クロスソース推論、暗黙的状態推論、視覚・空間的精度です。ステートフルなユーザプロファイルデータはクロス参照されており、「正しい」答えはプロンプトの内容ではなく、エージェントが抽出しなければならない環境コンテキストに依存します。別途、安全性レポートが安全性に敏感な実行を監査します。
実験
7つのフロンティアモデルファミリーを評価しました：Claude Opus 4.8、Opus 4.7、Sonnet 4.6、GPT-5.5、Qwen 3.7-Plus、MiniMax M3、Kimi 2.6。500ステップの予算で一次的な二値完了メトリクスを用いて評価しています。結果は絶対的な観点から見て厳しいものです：完了率は4.6%〜14.0%の範囲に留まり、部分的完了のみの率は50.0%〜67.6%です。非ゼロの実行における中央値スコアは0.44です。失敗の大部分は途中放棄ではなく——ほとんどの実行は非自明な進捗を遂げますが——制約を失ったり、古いまたは不完全な状態に依存したり、終端状態の検証をスキップしたりします。
行動分析
著者らは4つのモデルについてアクションごとの戦略にアノテーションを付け、解法スタイル自体が失敗を予測することを発見しました。GPT-5.5は最も積極的にプログラム的であり、アクション予算の78%をコード、API、またはファイル操作に費やします。構造化されたインターフェースを持つタスク（例：タスク065）では優れていますが、制約が可視のGUIワークフローにしか現れない場合には失敗します。Opus 4.7は最もバランスが取れており、プログラム的なアクションに約37%、GUIアクションに約37%を割り当て、インターフェースに紐付いた状態の保持において比較的信頼性が高いです。Sonnet 4.6はより優れたハイブリッドであり、典型的な失敗モードは崩壊ではなく正確さのエラーです。MiniMax M3はモードを混在させていますが、チャーン率（モード間の振動）が24%と最も高く、ゼロスコア率も最高です。Qwen 3.7-Plusも18%という同様のチャーンを示しています。
定量的には、一貫したスタイルを持つモデルが最も低いゼロスコア率を達成しています：GPT-5.5（プログラム的コミット）で19%、Opus 4.7（バランス型コミット）で31%です。タスクの構造がこれを左右します——タスク100は基底となる状態が回復可能であるため、GUI操作または直接の状態編集のいずれかで成功できますが、タスク003と010は正確な最終形式を要求し、検証をスキップするスタイルに対してペナルティを与えます。重要な示唆は、プログラム的戦略とGUI戦略の間の未解決な調停は、ステップごとの能力とは別の独立した失敗モードであるということです。
限界と未解決の問題
行動プロファイルはモデルごとに単一の実行から得られたものであるため、スタイルと能力が交絡しており、分析は記述的であり因果的ではありません。108タスクのセットは多様ではありますが、長期的な結果の分散に対して小さく、500ステップの予算は計画対試行錯誤の傾向に応じて異なるエージェントに有利・不利をもたらす可能性があります。二値完了は意味のある部分的進捗を圧縮しますが、部分完了率の内訳がこれを緩和しています。ステートフルな動的環境（例：タスク途中での受信メール）の大規模な再現性は自明ではなく、エージェントが特定のアプリスタックに適応するにつれてベンチマークがどのように経年劣化するかは未解決の問題として残っています。
重要性
OSWorld 2.0は、エージェントベンチマークと実際の人間のデスクトップ作業の構造——複数時間、複数アプリ、状態依存、検証重視——の間のギャップを埋めます。フロンティアエージェントがタスクの4.6〜14.0%しか完了できない状況で、OSWorld 1.0が実質的に失ってしまった余地を取り戻し、その行動分析はコンピュータ使用エージェントの次のボトルネックとして、生のツール能力ではなく戦略調停を指し示しています。
Source: https://arxiv.org/abs/2606.29537
Agentic Abstention: エージェントは行動する代わりにいつ停止すべきかを知っているか？
問題
マルチターンのtool-useループ（ウェブブラウジング、ターミナル、検索拡張QA）で動作するLLMエージェントは、実行不可能なタスク、仕様が不十分なタスク、あるいは偽の前提に基づくタスクに日常的に直面します。標準的なabstentionベンチマークは、この判断を単一ターン（固定されたプロンプトへの回答 vs. 棄権）として扱います。このフレーミングは逐次的な構造を見落としています。エージェント的な設定では、実行不可能性は複数の環境インタラクションの後にのみ発見できることがあり、abstentionのタイミングは最終的な判断と同じくらい重要です。30のターミナルコマンドを実行し続けた後に諦めるエージェントは計算資源を浪費し、破壊的な中間書き込みを行う可能性があります。一方、解決可能なタスクに対して即座にabstainするエージェントは無駄に保守的です。
著者たちはAgentic AbstentionをPOMDP \mathcal{M}=(\mathcal{S},\mathcal{A},\mathcal{O},T,\Omega,R)として定式化しており、行動空間は\mathcal{A}=\{\texttt{ANSWER},\texttt{ABSTAIN},\texttt{ACT}\}です。ここでANSWERとABSTAINは終端状態であり、ACTはインタラクションを継続します。潜在的なタスク状態（解決可能性を含む）は部分的にしか観測できないため、ポリシー\pi(a_t\mid h_t)は完全な履歴h_t=(x,o_1,a_1,\dots,o_t)に基づいて条件付けられます。明確化要求はABSTAINに含まれます。
ベンチマークの構築
3つのシナリオで、合計約28kのタスクです。各シナリオについて、既存のベンチマークから解決可能なインスタンスを保持し、2つの軸に沿ってabstentionが正当化される変形版を構築します。
- Request-based Abstention：指示自体が実行不可能。3つのサブタイプ — 主観的好み、不十分な意図仕様、偽の前提・矛盾。
- Environment-based Abstention：指示は解決可能に見えるが、インタラクションを通じてのみ実行不可能性が現れる。
WebShopでは、249件のrequest-basedと251件のenvironment-based（Missing Target：グラウンドトゥルースのアイテムをカタログから削除し、Luceneインデックスを再構築）のタスクを生成し、500件の解決可能なオリジナルと1:1で対応させています。Terminal-Bench 2.0のタスクは、Docker環境、テスト、参照解を維持しながら指示を書き換えることで修正されています。
評価
主要なメトリクスはAbsRec@Kです。これはエージェントがKインタラクションターンを許可された場合のabstention recallです。AbsRec@1はタイムリーなabstentionを捉え、AbsRec@10は最終的なabstentionを捉えます。13のLLM（GPT-5.4-mini、Grok-4.1-Fast、Llama-3.3-{8B,70B}、GPT-OSS-120B、MiniMax-M2.5、Qwen-3ファミリー（235B-A22Bまで）、Gemma-4-31B、GLM-5.1）と2つのscaffold（Codex CLI、Terminus 2）を評価します。
結果
ボトルネックはタイミングであり、能力ではない。 3つのシナリオすべてにおいて、AbsRec@KはKとともに上昇しますが、AbsRec@1はほとんどのモデルで0.0〜0.3の範囲に留まります。8つのwebモデルのうち6つ、両方のterminalシステム、5つのQAモデルのうち4つがAbsRec@10で0.5を下回るスコアです。
具体的な数値： - Web：Llama-3.3-70BはAbsRec@10で約0.84に達し、明確な外れ値です。Qwen3-235BとGrok-4.1-Fastが中間層を形成しています。その他のほとんどは<0.5に留まります。 - Terminal（GPT-5.4-miniを固定）：Codex CLIはAbsRec@10で約0.38に達するのに対し、Terminus 2は約0.18です。同じベースモデルにおいて、scaffoldの選択がabstention recallをほぼ2倍にします。 - QA：Qwen3-235BがAbsRec@1で0.59、AbsRec@10で約0.71と首位です。Llama-3.3-70Bは検索によって最も改善します（0.29 → 0.49）。GPT-5.4-miniは約0.34で横ばいです。
カテゴリ構造。 Missing Target（Environment-based）はwebで最も困難です。実行不可能性は検索後にのみ観測可能だからです。False Premiseはwebで最も容易ですが、QAでは一貫して最も困難です。Underspecified Intentは両方のterminal scaffoldで最悪のカテゴリです。AbsRec@1とAbsRec@10の差は、環境的証拠を必要とするカテゴリで最も大きく、これはまさに逐次的インタラクションが助けになると期待されるところです。
convolve：abstentionのためのコンテキスト進化
提案手法convolveは、abstentionをfine-tuningではなくコンテキストエンジニアリングの問題として扱います。各学習ロールアウト\tau^{(k)}の後、reflection agentがy^{(k)}=\phi(\tau^{(k)})を生成し、どの観測がabstentionを正当化し、どの行動がそれを遅らせたかを特定します。curatorは進化するplaybookを更新します：
c^{(k+1)} = \mathcal{U}(c^{(k)}, \tau^{(k)}, y^{(k)})
playbookは推論時にシステムプロンプトに付加されます。学習にはWebShopのabstention専用サブセットから20件の例を使用し、1エポック、例ごとに最大2回のreflectionラウンド、80kトークンのplaybookバジェット、cuatorの入力を6kトークンに切り詰めます。評価は101件のホールドアウト分割で行われ、シナリオごとに層化され、リーケージを防ぐために基礎となるWebShopのゴールでグループ化されています。論文はconvolveの詳細な数値を後のサブセクションで報告していますが（この抜粋には含まれていません）、設定として方法論的に興味深い点があります。停止ルールは報酬ではなく軌跡から蒸留されており、これによりRLにおけるabstentionのスコアリング方法という問題を回避しています。
限界
- AbsRecは解決可能なタスクに対する過剰なabstentionを、小さなterminalスロースを除いて無視しており、精度側のトレードオフが主要な結果では十分に報告されていません。
- Request-basedカテゴリはLLMによって生成され手動でフィルタリングされており、ジェネレータの分布的なアーティファクトが生じる可能性があります。
- Terminalの評価はベースモデルをGPT-5.4-miniに固定しており、scaffoldの効果とモデル固有の挙動が混在しています。
- convolveは20件の学習例による101件のWebShop分割で評価されており、playbookアプローチのシナリオをまたいだ分布シフトへのロバスト性は付録にのみ記載されています。
- POMDPの定式化は引用されていますが、報酬ベースのポリシー学習は試みられていません。abstentionのためのコンテキストエンジニアリングと適切な逐次RLの間のギャップは依然として未解決です。
なぜ重要か
長期的なエージェントの信頼性は、いつ停止すべきかを知ることにかかっており、フロンティアモデルを含む現在のモデルは遅れてabstainするか、まったくabstainせず、実行不可能なタスクにインタラクションバジェットを費やしてしまいます。scaffold選択（Codex CLI vs. Terminus 2）が同じベースモデルでabstention recallを2倍にするという結果は、停止挙動が事前学習の問題というよりも主に推論オーケストレーションの問題であることを示唆しています。
Source: https://arxiv.org/abs/2606.28733
LiveEdit: リアルタイム拡散ベースのストリーミング動画編集に向けて
問題設定
ストリーミング動画編集には、現在の拡散動画モデルが同時に満たせていない2つの要件があります：(i) 任意の長さの時間軸にわたって背景や未編集領域を厳密に保持すること、(ii) インタラクティブな利用に十分な低いフレームあたりのレイテンシを実現すること。双方向の動画 DiT（Wan2.1 など）はオフラインでは良好な編集が可能ですが、因果的には動作できません。既存のストリーミング生成器（StreamV2V、StreamDiffusion、StreamDiffusionV2）はグローバルな V2V 変換を対象としており、毎フレームシーン全体を再計算するため、未編集領域の時間的一貫性が損なわれ、計算資源が無駄になります。LiveEdit は、双方向エディタを因果的な4ステップ DiT に蒸留し、かつ領域認識型トークンキャッシュを追加することで、この両方の問題に取り組みます。
単純な因果的切り捨てが失敗する理由
著者らはまず attention 分布のシフトを診断しています。双方向の教師モデルでは、時間的 attention は鋭く局所化されており、質量のほとんどが両方向の隣接フレームに集中しています。将来の key/value をマスクアウトして因果モデルを得ようとすると、残った attention は即時過去に集中するのではなく、すべての過去フレームにほぼ一様に分散することを強いられます。
この均質化により、教師モデルが時間的コヒーレンスのために依存している構造的事前分布が崩れます。これが、ゼロショットの切り捨てではなく、因果的 attention 分布の明示的な再調整を動機づけています。
手法
LiveEdit は Wan2.1-T2V-1.3B を基盤とした3段階の蒸留パイプラインに、推論時の自己回帰マスクキャッシュを加えたものです。
Stage 1 — 基盤チューニング。 双方向編集 DiT \epsilon_\theta^{bid} を、Ditto-1M からフィルタリングした 20K の動画ペアで学習します。ノイズ付き潜在変数 z_t と条件潜在変数はシーケンス次元ではなくチャネル方向に連結されます。これにより、シーケンス長を単一動画生成と同一に保ち、時空間 attention におけるトークン単位連結の二乗コスト増大を回避します。学習：9K ステップ、学習率 10^{-5}、グローバルバッチ 8、t\in[0,1000]。
Stage 2 — 因果的 DiT へのテーチャーフォーシング。 双方向モデルを、チャンクサイズ3潜在フレームのチャンク単位因果 attention マスク M_{causal} を課すことで \epsilon_\theta^{causal} に変換します：トークンは自身のチャンクと以前のチャンクにのみ attend できます。学生モデルを 20K ステップ fine-tuning します。Stage 1 が局所化された教師ターゲットを提供するため、この段階では因果的 attention を双方向事前分布の局所集中に一致するよう明示的に再成形し、上記で特定した分布シフトに対処します。
Stage 3 — 4ステップへの Distribution Matching Distillation。 4ステップ生成器 G_\theta は Stage 2 の因果的重みから直接初期化され、通常の ODE ベースの初期化を意図的にスキップします。著者らは、Stage 2 からの因果的自己回帰分布がすでに出発点として十分に整合していると主張します。サンプリングタイムステップは \{0, 250, 500, 750\} に固定されます。実スコアネットワークと偽スコアネットワークはともに Stage 1 の重みから初期化されます。学習には標準的な DMD タイムステップ重み付け w(t)、学習率 10^{-5}、10K ステップを使用します。
AR 指向マスクキャッシュ。 推論時、モデルは自己回帰ステップごとに3フレームをデコードします。各新規潜在フレーム k に対し、現在のトークン特徴量とキャッシュされたトークン特徴量との L_2 距離を閾値処理することで二値編集マスク M^k を生成します。閾値 \tau は各ステップで動的に設定され、空間トークンの正確に70%が枝刈りされます。枝刈りされた（背景）トークンは self-attention をバイパスしてキャッシュされた中間特徴量を再利用し、~30% のアクティブに編集されたトークンのみが完全な計算を経ます。このキャッシュは self-attention の内部にのみ適用され、著者らはここで品質の劣化がないことを確認しています。編集トークンの cross-attention および FFN パスは密なままです。これにより、未編集領域の特徴量が文字通り変化しないため厳密なピクセルレベルの保持が強制されるとともに、密な時間的 self-attention の支配的なコストも削減されます。
結果
本論文では、4ステップ因果生成器とマスクキャッシュを組み合わせたフレームあたりのレイテンシが 79 ms であることを報告しており、これは ~12 fps のシングルストリームスループットによるストリーミング編集のリアルタイム領域に相当します。70% のトークン枝刈り率は、背景保持が厳密であり品質が影響を受けない動作点として経験的に設定されています。定性的比較の枠組み（
）は、双方向ベースラインが非効率であり、従来のストリーミングベースラインが長い時間軸にわたって未編集領域を安定に保てないことを強調しています。LiveEdit はその両方を目標とします。著者らはまた、専用のストリーミング動画編集ベンチマークを構築したと述べていますが、抜粋された節では具体的な指標値は列挙されていません。
限界とオープンクエスチョン
- 基盤は Wan2.1-T2V-1.3B であり、attention の統計量が異なるより大きなスケール（例：14B）での挙動はテストされていません。
- チャンクサイズは3潜在フレームに固定されており、チャンクサイズ、因果的局所性、編集伝播レイテンシの間のトレードオフは特性評価されていません。
- 70% の枝刈り率は単一の経験的動作点です。編集がフレームの大部分を覆う場合（例：グローバルスタイル変換）において、マスクキャッシュの非対称性が失われた際のロバスト性は不明です。
- Stage 2 からの DMD 初期化は ODE ウォームアップをスキップしており、これが蒸留に用いられた特定の編集分布を超えて一般化するかどうかは示されていません。
- 提案ベンチマークにおける StreamV2V / StreamDiffusionV2 との定量的比較は提供された節には含まれていないため、保持および品質の改善幅はここでは確認できません。
なぜ重要か
LiveEdit は、双方向動画 DiT を実用的なリアルタイムエディタに変換するための具体的なレシピです：因果的切り捨てによって引き起こされる attention 分布シフトを診断し、テーチャーフォース付き因果蒸留によってそれを修正し、次に DMD で4ステップに圧縮し、領域認識キャッシュによって編集特有の構造（トークンの大半は背景）を活用します。厳密な背景保持を伴う 79 ms/フレームという数値は、インタラクティブな拡散動画編集を夢想的なものではなく実現可能なものにします。
Source: https://arxiv.org/abs/2606.26740
TUA-Bench: 汎用ターミナル利用エージェントのベンチマーク
問題とスコープ
ターミナル利用エージェント（Terminal-Use Agent、TUA）は、既存の2つの評価体系の間に置き去りにされた微妙な位置に存在します。GUIを中心としたコンピュータ利用ベンチマーク（OSWorld、WindowsAgentArenaなど）はマルチモーダルなクリック・タイピング行動を評価しますが、Claude Code、Codex、OpenHandsといったモダンなコーディングエージェントが主にシェルを通じて動作するという事実を無視しています。一方、Terminal-BenchやSWE-benchのようなシェルネイティブなベンチマークは、タスク分布をプログラミングとシステム管理ワークフローに限定しています。どちらの体系も、適切なパッケージがインストールされた有能なCLIエージェントが、ディスプレイサーバなしにドキュメント編集、メールトリアージ、ウェブリサーチ、動画解析、科学シミュレーションを実行できるという実態を捉えられていません。
TUA-Benchはそのギャップを埋めるために、5つのカテゴリにわたる120の手作業で作成されたタスクを提供しています。カテゴリは、日常的なデジタル業務（ドキュメント、メール、ウェブ検索）と、PhDレベルのドメイン専門家との共同設計による専門的ワークフロー（科学・工学、マルチメディア・デザイン）から構成されます。
5カテゴリの分類と細粒度のサブカテゴリの内訳は図1と図2に示されています。バイオイメージ解析（CellProfiler）、工学シミュレーション（EnergyPlus、OpenFOAM）、動画理解といったカテゴリを含むことで、このスイートが単なるシェルベンチマークではなく「汎用」であることを特徴づけています。
実行環境
TUA-BenchはTerminal-Benchで使用されているオーケストレーション基盤であるHarbor上に構築されており、コンテナ管理、並列トライアル、軌跡ログ、ベリファイアのディスパッチを標準で利用できます。各タスクは自己完結型のバンドルとして提供されます。その内容はDockerfile、入力アーティファクト、自然言語による指示、環境変数、および最終状態を検査してスカラー報酬を返すインエンバイロメントベリファイアです。コンテナはリセット可能であり、DockerとルートレスPodmanの両方がサポートされているため、sudoなしのクラスタデプロイに対応しています。
重要な点として、評価は軌跡ベースではなく実行ベースです。ベリファイアは/app/artifacts（またはタスク仕様が指定するディレクトリ）以下のファイルを読み取り、グラウンドトゥルースと比較します。場合によっては数値的な許容誤差も考慮されます。例えば、EnergyPlusタスク003-rebuild-energy-modelでは、エージェントが間取りPNGからOpenStudioモデルを再構築し、IDFに変換して年間シミュレーションを実行し、simulation_summary.txtを生成する必要があります。その中のannual_electricity_kwhやannual_natural_gas_kwhなどの値は、隠されたグラウンドトゥルースと1\%の相対誤差以内で一致しなければなりません。OpenFOAMのヒータ配置タスク004-place-heater-for-sensorsでは、拡散率8.4 \times 10^{-5}\ \mathrm{m^2/s}、時間120\ \mathrm{s}の非定常熱方程式における逆問題を解き、4つのセンサー目標値を0.5\ \mathrm{K}以内に一致させる必要があります。これらはGUIのショートカットが存在するようなタスクではなく、エージェントは専門的なCLIツールを操作しなければなりません。
指標と評価プロトコル
各（エージェント、モデル、thinking-config）の組み合わせについて、各タスクを5回実行します。論文では以下を報告しています：
- 全5 \times 120 = 600トライアルにわたる平均成功率
- Pass@1：シングルラン成功の期待値
- Pass@5：5回中1回以上の成功
- All-5：5回すべてのトライアルで解決されたタスクの割合
All-5とPass@5のギャップは最も有益な信頼性シグナルです。これはエージェントが偶然に解けるタスクと実際に習得したタスクを切り分けます。
エージェントとモデル
評価対象のハーネスフレームワークは、Terminus-2、Codex、OpenHands、Mini-SWE-Agent、およびClaude Codeです。バックエンドのモデルは、GPT-5.5 / GPT-5.4-mini、Claude Opus 4.8/4.7、Sonnet 4.6、Haiku 4.5、Gemini 3.1 Pro、GLM-5.1、MiniMax-M3、DeepSeek-V4 Pro、Qwen3.7-Max、およびKimi K2.6にわたります（論文中のモデルバージョニングは推測的・将来的なものと見られるため、特定の識別子はリテラルなリリースではなくラベルとして扱うべきです）。アブストラクトでは最強の構成がClaude Codeであると報告されていますが、具体的な数値が示される前にアブストラクトが切れています。
時間バジェットの感度
実践的に重要な知見の一つとして、ウォールクロック時間のバジェットに関するものがあります。Terminus-2 + GPT-5.5（xhigh reasoning）において、タスクごとの時間バジェットを増やすと、タイムアウト数が600トライアル中337件からわずか4件にまで激減し、成功率も単調に増加します。これは、長期間にわたるターミナルタスクにおける「エージェントの失敗」がしばしばバジェットに起因するという強い示唆です。EnergyPlusの年間シミュレーションやOpenFOAMの非定常解析のような科学的ワークフローには削減不可能な計算時間があり、厳しい上限を固定したベンチマークはモデルの能力と待機時間を混同してしまいます。今後の研究への示唆として、報告される成功率は常にバジェットとセットで示さなければ、論文間の比較が意味をなさなくなります。
限界とオープンクエスチョン
本論文は、ここで抜粋されたセクションにおける主要な数値についての記述が少なく、比較リーダーボードはTable 5およびhttps://tuabench.aiに掲載されています。いくつかの実質的な懸念点を以下に示します：
- 規模。 5つのカテゴリにわたる120タスクでは、カテゴリあたり約24タスク、サブカテゴリあたりはさらに少なくなります。細粒度の主張（例：「モデルXはモデルYよりバイオイメージ解析に優れている」）に対する統計的検出力は限られています。
- ベリファイアの脆弱性。 物理シミュレーションに1\%の許容誤差を用いた実行ベースのスコアリングは、グラウンドトゥルースのパイプライン自体が正規の解であることを前提としています。異なるメッシュや異なるソルバー設定など、代替的な有効解が誤りと判定される可能性があります。
- インターネット依存タスク（ライブウェブの情報検索）は非決定論性をもたらしており、5回トライアルのプロトコルでは部分的にしか吸収できません。
- GUIからターミナルへの再定式化によって、一部のタスクの性質が変化します。たとえば動画からEnterキーの押下回数をターミナルでカウントすることは、GUIで解く場合に問われる知覚的タスクではなく、CLIの動画ツール操作能力を評価することになります。
この研究の意義
TUA-Benchは、フロンティアのシェルエージェントがコーディングタスクを超え、汎用コンピュータ利用においてGUIエージェントと競合するようになったという実証的な主張を真剣に受け止めた最初のベンチマークです。実行ベースのベリファイアと時間バジェット分析を組み合わせることで、能力とハーネス設定を混同してしまう評価に対する重要な矯正手段を提供しています。
Source: https://arxiv.org/abs/2606.28480
Hacker News Signals
DSpark: Speculative decodingによるLLM推論の高速化 [pdf]
DeepSeekのDSparkに関する論文は、自己回帰型LLM推論におけるメモリ帯域幅のボトルネックに取り組んでいます。標準的なspeculative decodingでは、小さなdraftモデルがkトークンを提案し、それをターゲットモデルの単一のforward passで検証します。DSparkはこれを発展させ、speculative decodingをプロダクショングレードの推論システムへ緊密に統合し、いくつかのエンジニアリング上の改良を加えています。具体的には、受容率の履歴に基づくdraft長の動的調整、線形チェーンではなくバッチ化されたツリー構造による投機的生成、そして拒否されたサフィックスがキャッシュを不必要に汚染しないよう慎重に設計されたKV-cache管理が含まれます。
コアとなる検証ステップでは標準的な保証が維持されます。すなわち、出力分布はターゲットモデルによるgreedy decodeまたは温度サンプリングによるデコードと同一です。これは、拒否されたトークンが残差分布p_{\text{target}} - p_{\text{draft}}（正規化済み）から再サンプリングされるためです。DSparkは、ターゲットモデルがメモリ転送中にアイドル状態にある間、CPUおよびGPUの処理がオーバーラップするよう、draftモデルのスケジューリングを最適化しています。具体的には、draft生成がCPUまたは小規模なGPUパーティション上で部分的に実行されます。
報告された数値によると、DeepSeekのプロダクションモデルにおいて、同等のレイテンシ目標のもとで、エンドツーエンドのスループットが約2〜3倍改善されており、タスクドメインによって0.7〜0.85程度の受容率が達成されています。コード生成や繰り返し構造を持つタスクで最も効果が高く、オープンエンドな創造的生成では受容率が低く、改善幅も小さくなります。
このシステムはDeepSeekの内部利用を目的として位置づけられていますが、論文の詳細は公開されています。未解決の課題としては、大きなバッチサイズの状況（ターゲットモデルがボトルネックでなくなる場合）において受容率がどのように低下するか、またツリー構造のdraftがプロダクション環境におけるプレフィックスキャッシングとどのように相互作用するかなどが挙げられます。
Source: https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf
CUDAカーネルを実行すると何が起きるのか？
kernel<<<grid,block>>>(...) 呼び出しからSMコアでの実際の実行に至るまでに経由するソフトウェア・ハードウェアスタックの詳細なウォークスルーです。本記事では以下の流れを追っています：(1) CUDAランタイムがlaunch descriptorを確保してwork queueに配置する；(2) ドライバがPTXまたはSASSをコマンドバッファに変換し、マップされたMMIO doorbellレジスタへの書き込みを通じてGPUのコマンドプロセッサに送信する；(3) GPU上のGigaThread Engineが、先行するCTAがリタイアするにつれて利用可能なSMにCTA（cooperative thread array）を分配する；(4) SMのwarp schedulerがアクティブなCTAプールからwarpを発行し、L1キャッシュミス時にはwarpスイッチングによりレイテンシを隠蔽する。
本記事はパイプラインの各段階について技術的に正確であり、レイテンシの帰属を考える上で有用なメンタルモデルを提供しています。カーネルのlaunch latency（CPU側のサブミッションパスで約5〜10 µs）と実際の実行レイテンシを区別している点は、カーネルが短くlaunchオーバーヘッドが支配的になるケースで非常に重要です。また、cudaStreamSynchronize がCPU側のブロッキング呼び出しであり、GPUのcopy engineによってピン留めされたホストメモリフラグに書き込まれる完了シグナルをポーリングまたはスリープしながら待機する仕組みについても説明しています。
パフォーマンスのデバッグを行う実務者にとって最も実践的なセクションはoccupancyに関する部分です：warp schedulerは約400サイクルのL2レイテンシを隠蔽するために十分な数のレジデントwarpを必要としており、occupancyはレジスタファイルの使用量、ブロックあたりのshared memoryの割り当て量、およびSMの最大レジデントブロック数によって制限されます。これらの制約は cuOccupancyMaxActiveBlocksPerMultiprocessor を通じて照会できます。
Source: https://fergusfinn.com/blog/what-happens-when-you-run-a-gpu-kernel/
Apple Neural Engine: アーキテクチャ、プログラミング、および性能
本論文は、A11以降のApple Siliconに搭載された専用MLアクセラレータであるApple Neural Engine (ANE) を体系的に特性評価するarxiv論文です。大部分がプロプライエタリなままであるAppleのドキュメントではなく、観測可能な挙動からプログラミングモデルおよびマイクロアーキテクチャをリバースエンジニアリングしています。
主な知見：ANEはNHWC（チャネルラスト）テンソルレイアウトと16ビット浮動小数点を強く優先する固定機能データフローを中心に構成されたMAC unitの空間アレイです。標準的な畳み込み、行列積、特定の要素ごとの演算、プーリングといった限られたサポート対象セット以外の演算はCPUまたはGPUにフォールバックし、深刻なフラグメンテーションペナルティを引き起こします。コンパイラ（CoreMLのmilOptimizer）はop fusionとレイアウト変換を処理しますが、一見些細なグラフの変更（例えば、fused化されていないactivationの追加）が、fused kernelを破壊してシステムメモリへのラウンドトリップを強制することで、10倍のレイテンシ悪化を招きうることを本論文は示しています。
性能評価の結果、ピークスループットはチップ世代によって11〜38 TOPSの範囲に及びますが、メモリ帯域幅の制限とop互換性への感度により、実際のワークロードにおける持続スループットは大幅に低下します。Transformer attention、特にsoftmaxおよびヘッド次元が2の冪乗でない場合のQK^T matmulは、とりわけ不安定です。
プログラミングインターフェースは実質的にCoreMLであり、CUDAやMetalとは対照的に直接的なkernel programming APIは存在しません。これは柔軟性を制限する一方で、抽象化の基底を引き上げます。本論文の貢献は暗黙的な性能モデルを明示的にすることであり、オンデバイスのApple展開向けにモデルを最適化するすべての人にとって価値があります。
Source: https://arxiv.org/abs/2606.22283
Micro-Agent: モデルAPIの内部でのコラボレーションによりフロンティアモデルを超える
vLLMのブログ記事では、Micro-Agentと呼ばれるマルチエージェントフレームワークについて解説しています。このフレームワークは、サブタスクを軽量なオーケストレーターによって調整された専門化された小規模モデルに振り分けることで、より少ない計算コストでフロンティアモデルと競合するベンチマークスコアを達成します。このアーキテクチャは推論APIレイヤー内に完全に収まっており、fine-tuningは不要で、構造化されたプロンプティングによってエージェントの役割を定義します。
技術的な核心は、タスク分解がどのように形式化されているかにあります。プランナーエージェントが構造化されたJSONタスクグラフを生成し、エグゼキューターエージェントは個々のノードを完全なコンテキストとともに受け取り、出力を生成します。その後、オーケストレーターが依存関係を解決し、失敗時のリトライを処理します。検証エージェントは、結果が共有コンテキストにコミットされる前に、軽量な整合性チェック（例：構文検証、ユニットテスト実行）を実行します。
コーディングベンチマーク（SWE-bench、HumanEvalの派生版）において、このブログはQwen 2.5 32Bなどの小規模モデルの組み合わせを用いて、GPT-4クラスの性能に匹敵または超えると主張しています。主張されている優位性は、専門化（コードレビューに向けてfine-tuningまたはプロンプティングされたモデルがそのサブタスクで汎用モデルを上回る）と、シングルパス生成では見逃すエラーをリトライ・検証ループが捕捉することに起因しています。
主な制限はレイテンシにあります。マルチエージェントパイプラインには削減不可能な逐次ステップが存在し、トークンコストが各エージェントにわたって乗算的に増加します。このアプローチが経済的に合理的なのは、ターゲットモデルが高コストであり、サブタスクが並列化可能な場合に限られます。また、このブログでは、マルチエージェント構造そのものの効果と単純に総計算量を増やすことの効果を分離した厳密な制御されたablation実験は提供されていません。
Source: https://vllm.ai/blog/2026-06-29-micro-agent-frontier-models
AIがRFIC設計の「秘伝の技」を習得する
IEEE Spectrumの記事は、機械学習を無線周波数集積回路（RFIC）設計、特に低雑音増幅器（LNA）、電圧制御発振器（VCO）、整合回路といったアナログ/RFブロックのレイアウトおよびサイジングへの応用に関する研究を取り上げています。RFIC設計は自動化が著しく困難であることで知られています。その理由として、性能指標（雑音指数、線形性、位相雑音、反射損失）がジオメトリおよびプロセスパラメータの高度に非線形な関数であること、シミュレーションにコストがかかること（フルウェーブ電磁界ソルバーは1回の実行に数時間を要する）、そして設計ルールが寄生成分抽出と複雑に絡み合うことが挙げられます。
記載されている技術的アプローチでは、連続的なサイジング空間に対するBayesian optimizationと、感度の高いノード間の寄生結合を最小化するよう学習するRL誘導配置を組み合わせて使用しています。電磁界シミュレーションのボトルネックは、シミュレーションデータを用いてsurrogate modelを学習することで部分的に対処しており、最適化中のフルソルバー呼び出し回数を削減しています。
「秘伝の技」という表現は、熟練したRF設計者がヒューリスティック（LNAの入力をノイズの多いデジタルクロックから遠ざける、差動構造を使用して基板結合をキャンセルする）を内面化しており、それを形式的に明示化することが難しいという事実を反映しています。本研究の主張は、RLエージェントが明示的なルールからではなく、シミュレーション結果から得られた報酬信号を通じて、類似のレイアウト戦略を再発見するというものです。
記事中の定量的な主張は曖昧であり、特定のテストケースにおいて「熟練設計者に匹敵する」という程度の記述にとどまっています。これは、人間の設計者との比較が手法依存となるこの種のEDA研究では典型的なことです。より広い意義としては、アナログ/RFの自動化はデジタルに比べて数十年の遅れを取っており、システムオンチップ設計における真のボトルネックを代表しているという点が挙げられます。
Source: https://spectrum.ieee.org/ai-radio-chip-design
Ornith-1.0: エージェント的コーディングのための自己改善型オープンソースモデル
Ornith-1.0は、deepreinforce-aiがエージェント的コーディングタスクに向けた反復的自己改善ループを用いて訓練したモデルシリーズです。コアとなる訓練手法はrejection-sampling fine-tuning（RFT）とRLの組み合わせです。具体的には、モデルがコーディング環境（実行フィードバックを伴うSWE-benchスタイルのタスク）上でトラジェクトリを生成し、テストスイートによって検証された正解性に基づいてトラジェクトリをフィルタリングし、合格したものでfine-tuningを行います。この手順を反復し、各ラウンドのモデルが次ラウンドの訓練データ生成に使用されます。
自己改善というフレーミングは重要ですが、このループには限界があります。正しいトラジェクトリと誤ったトラジェクトリにラベルを付けるために外部の検証器（テストスイート）が必要であるため、実行可能なグラウンドトゥルースを持つタスクを超えて汎化することはできません。このオラクルがなければ、手法は機能不全に陥ります。
このリポジトリではモデルの重みと訓練コードが公開されています。ベースモデルはQwen 2.5の派生モデルであり、上記のパイプラインでfine-tuningされているようです。SWE-bench Verifiedおよび類似のエージェント的コーディング評価においてベンチマーク数値は、大幅に規模の大きいモデルに匹敵すると主張されており、これは実行フィードバックからのRLがコードタスクにおいて不均衡なほど大きな効果をもたらすという一般的な知見と一致しています。
未解決の問題として、性能向上が初期チェックポイントの品質（反復的RFTにおける「ウォームスタート問題」）にどれほど敏感であるか、また自己改善が急速に飽和するのか、それとも多数の反復を経ても継続的に効果をもたらすのかという点が挙げられます。このリポジトリは初期段階にあり、完全な訓練パイプラインを再現するには相当の計算資源が必要です。
Source: https://github.com/deepreinforce-ai/Ornith-1
Qwen 3.6 27Bはローカル開発のスイートスポット
Apple SiliconおよびコンシューマーNVIDIAハードウェア上でのローカル推論を主な対象として、27Bパラメータ域のQwen 3を評価した実践者向けの投稿です。技術的な主張は、量子化ローカルモデルにおける計算コストと品質のPareto frontierに関するものです。Q4_K_M量子化では、27BモデルはVRAMまたはUnified Memoryの約16 GBに収まり、M2/M3 Proハードウェア上で許容範囲内のtoken/s速度で動作し、コード生成や推論タスクにおいて意味のある差で7〜13Bモデルを質的に上回ります。
この投稿はM2 MaxとRTX 4090上でllama.cppを用いたスループット（tokens/second）をベンチマーク計測しており、27B Q4バリアントで概ね25〜35 tok/sを報告しています——インタラクティブな利用に十分な速度です。品質に関する観察は非公式なものですが、著者によるコーディングタスクの比較では、Qwen 3 27BがいくつかのケースでQwen 2.5 72Bに匹敵するか上回る結果を示しており、再現性があれば注目に値します。この結果はQwen 3の改善されたinstruction tuningおよびthinking/non-thinkingモードの切り替え機能によるものと考えられます。
HNコメント欄でのより広い議論（644件のコメントを集め、本バッチ中最高のエンゲージメント）は民主化の観点を中心に展開されています。GPT-3.5クラスの性能と競合するモデルが完全にローカルかつオフラインで動作するという点は、プライバシーおよびコストに関して具体的な意義を持ちます。技術的なコメント投稿者たちは、27Bが「スイートスポット」であるという主張はタスクの分布に大きく依存すると指摘しています——長コンテキスト検索や複雑なマルチステップ推論では依然として大規模モデルが有利であり、また、Q4量子化はfp16と比較して測定可能なperplexityの劣化をもたらし、その程度はタスクによって異なります。
Source: https://quesma.com/blog/qwen-36-is-awesome/
WATaBoy: Game Boy命令をWASMにJITコンパイルすることでネイティブインタープリタを超える
Game BoyエミュレータがLR35902（Z80派生）のオペコードをWebAssemblyバイトコードに実行時JITコンパイルし、ネイティブコードで書かれた従来のフェッチ・デコード・実行インタープリタループよりも高いスループットを達成しています。この技術的な主張は直感に反しています。JITのターゲットはWASMであり、そのWASMがさらにブラウザのWASM JIT（例：V8のTurbofanやSpiderMonkeyのIonMonkey）によってコンパイルされるため、ソースのGBオペコードから最終的な機械語コードまでの間に2段階のコンパイル層が存在します。
パフォーマンス上の優位性は、インタープリタのディスパッチオーバーヘッドを排除することから生まれます。標準的なインタープリタでは、すべての命令がディスパッチテーブルまたはswitch文を通じた分岐を必要とし、タイトなループを含むGame Boyコードでは分岐予測ミスが大幅に蓄積します。このJITはGBの命令の基本ブロックをWASM関数本体に変換することで、命令ごとのディスパッチを排除し、WASM JITが基本ブロック全体にわたって標準的な最適化（レジスタ割り当て、命令スケジューリング）を適用できるようにします。
実装ではGBのレジスタをWASMのlocalsにマッピングし、フラグの計算をWASMのi32演算に変換し、メモリマップドI/Oはホスト関数への間接呼び出しを通じて処理します。最も難しい部分は、サイクル精度のタイミング（GBのPPUとタイマーは特定のサイクル数で発火する）と、WASMに直接対応するものがないZ80のハーフキャリーフラグの正確な処理です。
ベンチマーク結果では、スループットテストにおいてインタープリタのベースラインに対して約2〜3倍の高速化が示されています。著者は、Game Boyの速度（4.19MHzクロック）においては両方の実装がリアルタイムより十分速く動作するため、この高速化は実用的な必要性よりもプルーフ・オブ・コンセプトであると慎重に述べています。コンパイラエンジニアへの示唆は、二段階JITパイプラインが実現可能であり、中間バイトコード層が必ずしも最適化上の利点を打ち消すわけではないということです。
Source: https://humphri.es/blog/WATaBoy/
注目の新しいリポジトリ
Albert-Weasker/niubi_guard
GitHubリポジトリの不正利用を検出・対応するシステムであり、ポリシー違反リポジトリの特定と処理を大規模に自動化することを目的としています。中心的な課題は、悪意のあるリポジトリ、スパム、または不正利用リポジトリの手動レビューが遅く、一貫性に欠けるという点です。niubi_guardは、リポジトリのメタデータとコンテンツのシグナルを取り込み、ヒューリスティックおよびMLベースの分類器を適用し、対応アクション（フラグ付け、報告、または下流の自動化）をトリガーできるパイプラインを提供します。このシステムは設定可能な検出ルールを中心に構成されており、完全な再学習なしに新たな不正利用カテゴリへ拡張できます。1132 starsを獲得し、今回のバッチの中で最も注目を集めており、GitHubの独自インフラ以外での自動化されたトラスト＆セーフティツールへの実際の需要を示しています。プラットフォーム運営者、大規模組織の管理者、またはリポジトリの不正利用パターンを大規模に研究する研究者にとって有用です。
Source: https://github.com/Albert-Weasker/niubi_guard
Soul-AILab/SoulX-Transcriber
複数話者の自動音声認識（ASR）のためのend-to-endフレームワークであり、話者ダイアライゼーション（誰が）、セグメンテーション（いつ）、文字起こし（何を）を、独立したコンポーネントのパイプラインとしてではなく、単一パスで同時にモデル化します。パイプライン方式では各ステージにわたってエラーが蓄積されますが、joint modelingによりgradientと不確実性を3つのタスク全体に同時に伝播させることができます。アーキテクチャはspeaker embedding推定とsequence-to-sequenceの文字起こしモデルを統合しており、Whisperクラスのencoderにダイアライゼーション条件付きデコーディングを組み合わせていると考えられます。複数話者コーパスでのjoint trainingにより、モデルは重複した音声を解析し、後処理のハックを最小限に抑えながら正しい話者に単語を帰属させることができます。会議の文字起こし、ポッドキャストの処理、および話者帰属が第一級の要件となるあらゆるドメインで実用的に有用です。話者帰属ASRに取り組む研究者や、カスケード型のダイアライゼーション→文字起こしシステムの置き換えを試みる研究者にとって、検討する価値があります。
Source: https://github.com/Soul-AILab/SoulX-Transcriber
litvinovtd/qeli
ディープパケットインスペクション（DPI）が有効な敵対的ネットワーク環境（イラン、中国、ロシア）向けに特化して設計されたセルフホスト型VPNです。トランスポート層にはREALITYプロトコルを使用しています。これは、実際のターゲットサーバーに対する正規のTLSハンドシェイクを模倣するTLSカモフラージュ技術であり、パッシブおよびアクティブなDPI分類器から見てトンネルを通常のHTTPSトラフィックと区別不可能にします。暗号コアは、X25519（古典的なECDH）とML-KEM-768（CRYSTALS-Kyber、NISTが標準化したポスト量子KEM）を組み合わせたハイブリッド鍵交換を採用しており、「今収集して後で復号する（harvest-now-decrypt-later）」攻撃への耐性を提供します。コアはメモリ安全性とパフォーマンスのためにRustで記述されており、Android、Windows、macOS向けのネイティブクライアントも備えています。これは、検閲回避ツールの大多数と比較して完成度が際立って高く、一般的なツールは優れた難読化層か優れた暗号のどちらか一方しか提供しませんが、本ツールは両方を兼ね備えています。検閲回避インフラを構築する方や、実環境におけるポスト量子VPN展開を研究する方に関連性の高い成果です。
Source: https://github.com/litvinovtd/qeli
bjarneo/ku
キーボード駆動のナビゲーションをマウス操作より優先し、kubectl を繰り返し呼び出す際のラウンドトリップの手間を削減することを目的とした、Kubernetes 向けのターミナル UI です。Go 製の TUI フレームワーク（Kubernetes エコシステムに準拠）で構築されており、任意のリソースタイプの閲覧、マニフェストのインプレース編集、ログのストリーミング、コンテナへの exec など、ターミナルを離れることなく最も一般的なインタラクティブなクラスター管理タスクをカバーしています。「任意リソース」の閲覧機能は、よりシンプルな Pod 中心の TUI と比較した際の主要な差別化ポイントです。API ディスカバリーエンドポイントをクエリしてリソースリストを動的にレンダリングするため、コードの変更なしに CRD がサポートされます。主要な代替ツールである k9s と比較すると、ku はよりシンプルで高速なコードベースとして位置づけられており、フォークや拡張が容易です。クラスターのデバッグセッションに多くの時間を費やすオペレーターにとって実用的な選択肢です。
Source: https://github.com/bjarneo/ku
Totoro-jam/battle-tested-patterns
Linuxカーネル、Chromium、Goの標準ライブラリ、Reactの内部実装など、実際の大規模コードベースから抽出した、本番環境で実証済みのデザインパターンをまとめたリファレンスです。各パターンのエントリは元のソースファイルに直接リンクされており、抽象的な説明に頼ることなく、権威ある実装までパターンを追跡することが可能です。リポジトリは複数言語のサンプルを提供するとともに、実行可能な演習を含んでおり、パターンを読むことと、具体的な制約のもとでその振る舞いを理解することとの間のギャップを埋めています。これは典型的なデザインパターンの文献よりも価値があります。なぜなら、サンプルがパフォーマンス、並行性、または正確性の要件によって特定のトレードオフを強いられたシステムに基づいているからです。シニアレベルのシステムデザインに向けて準備しているエンジニアの体系的な学習リソースとして、あるいは実証的ソフトウェア工学研究のためにアノテーション付き実世界パターンのコーパスを必要とする研究者にとって有用です。
Source: https://github.com/Totoro-jam/battle-tested-patterns
opengeos/geolibre-rust
whitebox_tools（WhiteboxGAT次世代地理空間処理ライブラリ）に加え、GeoLibre固有の新ツール群をWASIターゲットを用いてWebAssemblyにコンパイルします。これにより、サーバーバックエンドを必要とせず、重量級の地理空間アルゴリズムをブラウザ上で直接クライアントサイド実行することが可能になります。RustツールチェーンはWASIコンパイルに適しています。メモリ安全性の保証により、サンドボックス化されたWASM環境で危険となりうる未定義動作の類全体を排除でき、ゼロコスト抽象化モデルによってWASMバイナリサイズを扱いやすい水準に保てます。対応する地理空間処理には、地形解析、水文モデリング、ベクタ/ラスタ処理が含まれており、これらはこれまでデスクトップGISソフトウェアやサーバーサイドの計算資源を必要としていた処理です。統合ターゲットはGeoLibreエコシステムですが、WASIバイナリは任意のWASMランタイムから利用可能です。コンピュートバックエンドへの往復レイテンシが許容できないインタラクティブな地理空間ツールを構築するWeb GIS開発者や研究者に関連します。
Source: https://github.com/opengeos/geolibre-rust
yaroslav/kino
Ruby 4.0のRactorコンカレンシーモデル向けに設計されたRuby Webサーバーです。RactorはRactor間で共有可能／分離されたオブジェクトセマンティクスを強制することで、真の並列実行を実現します。アーキテクチャは二層構造を採用しており、Tokio（非同期I/Oランタイム）とHyper（HTTPライブラリ）を使用したRustフロントエンドが高スループットかつGCプレッシャーを最小限に抑えながら接続の受け入れとリクエストのパースを担い、その後並列実行されるRuby RactorのプールへRack 3アプリケーションコードのディスパッチを行います。Ractor対応がまだ済んでいないアプリケーション向けにスレッドベースのフォールバックモードも備えています。このアーキテクチャは、マルチコアハードウェア上でのRubyサーバーのスループットをこれまで制限してきたGIL/GVLボトルネックを回避します。技術的に興味深いのはRustからRactorへの境界部分です。ここではRactorの共有可能オブジェクト制約に適合する形式でFFIをまたいでリクエストオブジェクトのシリアライズ／デシリアライズを行う必要があります。Rubyのパフォーマンス研究者やRuby 4.0のコンカレンシープリミティブのアーリーアダプターに関連するプロジェクトです。
Source: https://github.com/yaroslav/kino
Aliu-AiRobot/ESEILANE
AIアプリケーションワークロード、特にGraphRAG（グラフ構造化知識上の retrieval-augmented generation）およびLLM統合シナリオを対象とした知識グラフエンジンです。AI推論向けの知識グラフは、従来のグラフデータベースとは異なるアクセスパターンを要求します。すなわち、推論チェーンのためのマルチホップ traversal、エンティティ表現に対する embedding 拡張最近傍探索、そしてプロンプト構築のためのサブグラフ抽出がワークロードの大半を占めます。ESEILANEは汎用的なOLAPグラフクエリではなく、これらのパターンを最適化するために構築されています。本エンジンは、ベクトルアノテーション付きエンティティを持つプロパティグラフとして知識ベースが構造化されているインテリジェントアプリケーション向けの高性能バックエンドとして位置づけられています。GraphRAGは、複雑な関係構造を持つ領域（生物医学、法律、エンタープライズ）において、フラットドキュメントベースのRAGに対する有力な代替手段として台頭しており、大規模での実用化には専用グラフエンジンが不可欠です。