デイリーAIダイジェスト — 2026-07-23
arXiv ハイライト
Self Gradient Forcing: ネイティブ長尺動画外挿
問題設定
自己回帰型動画 diffusion モデルは、latent ブロックを逐次的に生成します。各新規ブロック j は z_j^t をノイズ除去しながら、既に生成されたクリーンな latent から構築された履歴 key/value キャッシュに attention します。Self Forcing（SF）は、教師強制的なグランドトゥルース履歴ではなく、自身のロールアウト上で学生モデルを訓練することで、訓練・推論間の不一致を低減しました。しかし、SF は履歴 K/V エントリをデタッチされたロールアウト状態として扱います。その結果、著者らが歴史的コンテキスト・勾配ギャップと呼ぶ問題が生じます。すなわち、将来のノイズ除去 loss が、以前に生成された latent をメモリに書き込んだクリーンコンテキスト計算を通じて伝播されることはありません。
形式的には、ブロック i<j が生成済みであり、そのクリーン latent 推定 \tilde x_i がクリーンコンテキストのタイムステップ t_{\mathrm{ctx}}=0 でエンコードされる場合、
\mathsf{KV}_i^{0}(\theta) = \mathcal{C}_\theta\!\left(\tilde x_i, t_{\mathrm{ctx}}; \mathsf{KV}_{<i}^{0}\right).
SF の DMD loss は共有された DiT パラメータ \theta を更新するため、一般に \mathsf{KV}_i^{0}(\theta_{r+1})\not\equiv\mathsf{KV}_i^{0}(\theta_r) となります。しかし、後続ブロックのノイズ除去が改善されるよう \tilde x_i を K/V へどのように書き込むかについて、\mathcal{C}_\theta に勾配シグナルが伝わることはありません。長い時間軸ではこれが視点の急変、シーンの断絶、アイデンティティのドリフトとして顕在化します。
手法
Self Gradient Forcing（SGF）は、逐次ロールアウトを通じた誤差逆伝播（長尺動画では非現実的なほど深くなる）を行わずに、欠落していたメモリ書き込み勾配を回復する、2パスの訓練戦略です。
パス 1 — 勾配なしロールアウト。 推論時と全く同様に自己回帰的な因果生成器を実行します。ランダムにサンプリングされたブロックインデックスとノイズ除去終了ステップにおいて、K/V キャッシュを構築するために使用した自己生成クリーン latent コンテキスト \{\tilde x_i\}_{i<j} と、モデルが次に処理しようとしていたノイズ付き latent z_j^t の 2 つを記録します。このロールアウトを通じて勾配は保持されません。
パス 2 — 並列コンテキスト勾配再構築。 記録された終了ステップの入力を用いて、そのステップのみを並列で再実行します。記録されたコンテキスト latent は stop-gradient クリーン入力（sg[·]）として扱いますが、クリーンコンテキスト K/V 表現 \mathsf{KV}_{<j}^{0}(\theta) = \mathcal{C}_\theta(\text{sg}[\tilde x_{<j}], 0) と、現在のノイズ付きブロックからそれら再計算されたエントリへの因果 attention を、勾配を有効にした状態で再計算します。z_j^t における DMD loss は、ターゲット側のノイズ除去計算と、ソース側のキャッシュ書き込み計算 \mathcal{C}_\theta の両方を通じて伝播されます。
パス 2 はアンロールされた再帰ではなく、1 つの終了ステップに対する単一の並列 forward/backward であるため、メモリコストはロールアウト長ではなくスライディングウィンドウのサイズによって制限されます。\tilde x_{<j} をデタッチすることで勾配がそれ以前のノイズ除去軌跡に漏れ込むことを防ぎます。すなわち、既に生成されたコンテンツのメモリへのエンコーディングのみが教師あり学習の対象となります。
実験
すべてのモデルは固定された 5 秒の訓練ウィンドウを共有しており、60 秒および 240 秒はネイティブ外挿を検証します。SGF と SF のすべての比較は、初期化、プロンプト、シード、sink/FIFO ポリシー、スライディングウィンドウ、チャンキング、サンプラーを揃えており、唯一の変数は終了ステップの loss が凍結キャッシュ（SF）を読むか、勾配再構築キャッシュ（SGF）を読むかです。2 種類の推論構成をテストします。
- フレーム単位：sink 4、合計ウィンドウ 21、FIFO 16、現在チャンク 1。
- チャンク単位：sink 3、合計ウィンドウ 12、FIFO 6、現在チャンク 3、チャンクサイズ 3。
5 秒（VBench 標準プロトコル）では、SGF と SF は両構成において概ね同等であり（付録 B）、SGF が短時間軸の品質を低下させないことが確認されています。本論文の主要部では、メモリ書き込み誤差が蓄積する 60 秒（VBench-Long プロンプト）と 240 秒（128 件の MovieGen プロンプト）に焦点を当てています。報告される VBench-Long メトリクスは、aesthetic quality、background consistency、dynamic degree、imaging quality、motion smoothness、subject consistency、flickering であり、ペアでの GSB 人間評価も含まれます。
定性的には、240 秒フレーム単位比較において SF がシーンカットやアイデンティティのドリフトを生じさせるのに対し、SGF は時間軸全体を通じて同一の被写体と背景レイアウトを維持しており、\mathcal{C}_\theta を教師あり学習することで K/V キャッシュに実際に格納される内容のドリフトが防がれるという仮説と一致しています。
制限と未解決の問題
論文の抄録は VBench-Long の絶対的な改善量を開示していないため、ここで提供されている抜粋からはメトリクスごとの改善幅を検証することができません。訓練サンプルごとに勾配が届くのは 1 つの終了ステップのみであるため、\mathcal{C}_\theta に対する有効な教師シグナルはブロック間で確率的となり、多ステップ再構築と比較したサンプル効率が不明です。\tilde x_{<j} に対する stop-gradient は、SGF がコンテンツのメモリへの書き込み方は修正しますが、それ以前のロールアウトが何を生成したかは修正しないことを意味します。したがって、ロールアウト自体に起因する失敗モード（例：初期ブロックでの幻覚）は直接対処されません。sink/FIFO ポリシーとの相互作用、および本修正が大きく異なるチャンクサイズや、クリーンコンテキストタイムステップを持たないモデルにも汎化するかどうかは未解決のままです。
この研究の意義
長時間軸の自己回帰動画生成は、フレームごとのノイズ除去よりも、以前の生成フレームが後の attention のために K/V キャッシュに残す内容によってボトルネックとなります。SGF は、Self Forcing が自己生成した履歴で訓練しているにもかかわらず、このメモリ書き込みステップを一切教師あり学習していないことを指摘し、完全なロールアウトの誤差逆伝播を避けつつ、コストが制限された 2 パス方式でそのギャップを埋めます。定性的な改善が定量的にも確認されれば、これは他の因果型動画 diffusion スタックが直接採用できる、安価なアーキテクチャ・訓練上の修正となります。
Source: https://arxiv.org/abs/2607.20368
能動的観察者のための試験
人間の視覚は、単一の網膜スナップショットに対するフィードフォワード型の分類器ではありません。心理物理学はかねてより、前注意的・並列的なチャンネルと、曲線トレーシング、サビタイジング限界を超えた逐次的な列挙、細粒度のクロスリージョン比較といった注意を要する直列的なルーティンとを区別してきました。これらのルーティンは、繰り返しの視線移動とワーキングメモリの更新によって実行されます。静的なVQAが主流を占める現在のMLLMベンチマークは、画像を一度だけ記述するモデルと実際にピクセルを再訪するモデルとを区別しません。ActiveVisionは後者を強制するよう設計されたベンチマークであり、フロンティアモデルと人間との間の顕著な差を明らかにします。
タスクの構成
このベンチマークは、各々が能動視覚の基本操作の一つを対象とした3つのファミリーに分類された、手続き的に生成された17のタスクから構成されます。
- Distributed Scanning（5タスク）：空間的に分散した局所信号（ドット、ストローク、領域、グラフの面、絡まったループ）を数える。失敗モードはpartial coverage（途中で止まったスキャン）とfaulty individuation（信号の結合または分割）です。
- Sequential Traversal（5タスク）：位置、方向、集計を維持しながら、連結構造（矢印チェーン、色付き領域を通る絡まった曲線、迷路の経路、直線交差シーケンス）を追う。失敗モードはgestalt interpolation、すなわち出発点から終点を推測することです。
- Visual Attribute Transfer（7タスク）：参照領域から細粒度の特性（長さ、曲率、太さ、ドットパターン、向き）を抽出し、候補と照合する。失敗モードはprior substitution、すなわち測定せずに言語的事前分布を適用することです。
重要な設計原理は、各インスタンスが単一の言語記述では可逆的にエンコードできない情報量を持つ弁別的な視覚状態を持つことです。これは4段階のパイプラインによって実施されます：決定論的なPythonジェネレータが、グランドトゥルース（カウント、順序付きパス、マッチした属性）を持つ幾何学的なスキャフォールドを生成し、タスク固有のGPT-image-2プロンプトが、位置、カウント、トポロジーを変更することなく、スキャフォールドを写実的な画像に再レンダリングします。
この分離は重要です：グランドトゥルースはスキャフォールドによって固定されますが、表面的な外観は合成画像のアーティファクトを利用した解法を排除するのに十分なほど自然です。
評価と結果
各ジェネレータはN=5のインスタンスを提供し、85アイテムを生成します。スコアリングは<answer>タグで囲まれた回答に対して完全一致で行われ、大文字小文字とホワイトスペースについて正規化されます。デフォルトのプロトコルは純粋なCoTです：質問と画像を含む1つのユーザーメッセージで、システムプロンプトもツールもありません。3名の人間の参加者が同じ基準のもと、自己ペースのWebUIで全85アイテムの評価を完了しました。
最大の結果として：各モデルの最高推論努力ティアにおいて、最良モデルであるGPT-5.5は9/85（10.6%）を解き、17タスクのうち11タスクで0/5を記録しました。推論・コーディングのリーダーボードでトップに立つClaude Fable 5は3/85（3.5%）を解きました。Gemini 3.5 Flashは7/85（8.2%）、Gemini 3.1 Proは5/85（5.9%）、Claude Opus 4.7は4/85（4.7%）、Claude Opus 4.8は2/85（2.4%）に達しました。人間の平均は81.7/85（96.1%）で、個人スコアは97.6%、96.5%、94.1%であり、最良モデルのおよそ9\timesです。
2つの構造的な観察がこれが単一モデルの特異現象ではないことを裏付けます。第一に、全6モデルが解いたアイテムは存在しないため、成功集合の重なりは弱いものにとどまります。第二に、GPT-5.5に対する画像省略コントロールは2/85（2.4%）を記録し、これは画像を含めたnoneの努力ランと本質的に一致します――したがって約10%の上限は、タスク構造を漏洩させるプロンプト事前分布ではなく、真の（しかし著しく制限された）視覚処理を反映しています。アイテムあたりの平均推論バジェットは相当なものです：GPT-5.5は22.5kトークン、Claude Fable 5は15.4kトークン、Gemini 3.1 Proは16.8kトークンであるのに対し、人間はアイテムあたり33.6秒の実時間です。
タスクごとの粒度は示唆的です。Sequential Traversalでは、全モデルがTraversal Point Ordering、Color Zone Sequencing、Line Intersection Sequencingで0/5を記録し、Maze Path TracingとArrow Chain Followingのみが一部ヒットを得ており、どのモデルもいかなるトラバーサルタスクでも2/5を超えません。Visual Attribute Transferでは、人間が\geq 4.3/5を記録しているにもかかわらず、4つの差異発見タスク全てがモデル全体でほぼゼロです。Distributed Scanningは唯一の孤立した明るい点を示します：GPT-5.5はRegion Countingで2/5、Constellation Match Countingで3/5を獲得しますが、Tangled Loop Countingは全モデルで0/5です。
限界と未解決の問題
評価スプリットは小さく（タスクあたりN=5、合計85）、タスクごとのセルの分散が増加しますが、集計パターンは明確です。著者らは、エージェント的なツール使用――モデルが自身の視覚コードを記述して実行する――がギャップを縮めないと報告しています。なぜならそのようなコードは現実的な画像に対して信頼性が低く、その失敗を自ら捉えること自体が能動的知覚を必要とするからです。これはボトルネックが外部ツールの欠如ではなく、モデル内の閉じた知覚-行動ループの欠如であることを示唆しています。これが根本的にアーキテクチャの問題（再固視や視覚スクラッチパッドを維持するメカニズムの欠如）なのか、学習分布の問題（直列的な視覚ルーティンを促進する教師信号の欠如）なのかは不明です。写実的なレンダリングステップはGPT-image-2の失敗モードとのある程度の結合をもたらしますが、グランドトゥルースは構造上保持されます。
なぜこれが重要か
ActiveVisionは、現在のMLLMが本質的に欠如している能力――直列的で注意に導かれたピクセルの再検査――を分離し、それを子供でも実行できるタスクで実現しています。プロンプト事前分布をすでに考慮したベンチマークにおける96%の人間ベースラインに対する約10%の上限は、静的な image embedding に対する推論トークンバジェットのスケーリングではこのギャップを埋められないことを示しており、反復的な視覚アクセスのためのメカニズムが必要です。
Source: https://arxiv.org/abs/2607.16165
ユークリッドClippingを超えて：リーマン等距離Policy最適化によるLLM RLにおける探索崩壊の克服
問題
PPO-ClipおよびそのLLM時代の後継手法（GRPO、DAPO、GSPO、GMPO、DCPO）は、importance ratio r_{s,a}(\theta) = \pi_\theta(a|s)/\pi_{\theta_{\text{old}}}(a|s) を (1-\epsilon, 1+\epsilon) の範囲に制約します。著者らはこれが幾何学的に誤りであると主張しています。このratioはユークリッド量ですが、policyはFisher情報量を局所計量とするリーマン多様体上に存在します（これはKLの二次展開と等価です）。一様なユークリッドclipのもとでは、更新によって消費されるKL「予算」は \pi_{\theta_{\text{old}}}(a|s) に強く依存します。
具体的に、\epsilon=0.2 の場合：\pi_{\text{old}}=0.8 の高確率トークンは 0.96 まで移動できる（変化量 +0.16）のに対し、\pi_{\text{old}}=0.01 の低確率トークンは 0.012 にしか到達できません（変化量 +0.002）。この2つの更新は幾何学的距離として大きく異なります（論文の単位で 0.016 対 0.0002）。結果として、すでに活用済みのトークンは自由に増幅される一方、稀少だが価値あるトークンは事実上凍結されます——これが探索崩壊です。DAPoのClip-Higher（\epsilon_{\text{high}}=0.28）は低確率トークンの上限を 0.0128（+0.0008 の増分）に引き上げるにとどまり、同時に高確率トークンを 1.0 まで飽和させてしまい、不均衡をさらに悪化させます。
手法：リーマン等距離Clip
RIPOは定数のユークリッド \epsilon を、局所Fisher計量のもとで等しい幾何学的距離を要求することから導出されたトークンごとのclip半径に置き換えます。二次KL展開を用いて、著者らは以下を定義します。
d_{\text{geom}}(\pi_{\theta_{\text{old}}}, \pi_\theta) \triangleq \tfrac{1}{2}\pi_{\theta_{\text{old}}}(a|s)\,(r_{s,a}(\theta)-1)^2 \le \delta.
ratioについて解くと、分布依存のclipが得られます：
|r_{s,a}(\theta) - 1| \le \epsilon_{s,a}(\pi_{\theta_{\text{old}}}), \qquad \epsilon_{s,a}(\pi_{\theta_{\text{old}}}) = \sqrt{\frac{\delta}{\pi_{\theta_{\text{old}}}(a|s)}}.
すべてのトークンが同じtrust-region予算 \delta を消費します。\delta=0.02 として先の例を再検討すると：\pi_{\text{old}}=0.8 のトークンは 0.92 で上限が設けられ（PPOの 0.96 より厳しい）、\pi_{\text{old}}=0.01 のトークンは 0.024 まで到達できます——PPO-Clipと比較して許容される更新量が 2\times 増加します。両者は同じ幾何学的距離 0.01 を消費します。
実用上、これは標準的なGRPO形式のsurrogateへのドロップイン置換です：detachされたold-policyの確率からトークンごとに \epsilon_{s,a} を計算し、通常の \min(r\hat A, \text{clip}(r, 1-\epsilon_{s,a}, 1+\epsilon_{s,a})\hat A) を適用します。著者らはまた、非対称な \{\delta_{\text{low}}, \delta_{\text{high}}\}（Clip-Higherのアナログですが幾何学的単位）も許容しています。一般的な慣行に従い、極端なratioを抑えるための [0.5, 10] のdual clipを維持し、KLペナルティを削除し、group-relative advantageを使用します。デフォルトは \delta = 0.05 です。
論文ではさらに、RIPOがより良いバイアス・分散のプロファイルを持つと主張しています：clip半径が 1/\sqrt{\pi_{\text{old}}} でスケールするため、低確率トークン（高分散のimportance-sampling項に寄与する）は比例的に大きいが幾何学的に有界な更新を受け、高確率トークンは抑制されます。
結果
7つの競技レベルの数学ベンチマークと4つのベースモデル（Llama3.2-3B-Instruct、Qwen3-1.7B/4B/8B-Base）を通じて、RIPOはGRPO、DAPO、GSPO、GMPO、DCPOを上回ります。最大の数字はAIME24においてGRPOと比較して最大 60\% の改善です。
Qwen3-8BのAIME accuracyカーブは、ユークリッドclipのベースラインが早期にプラトーに達することを示しており——これが探索崩壊の特徴です——一方でRIPOは改善を続けます。小さいモデルではメカニズムがさらに明確です：GSM8kで訓練されたQwen2.5-1.5B-Instructにおいて、RIPOの非対称幾何学的clipはPPO系手法が停滞または振動する中、単調に上昇するaccuracyの軌跡をもたらします。
\{\delta_{\text{low}}, \delta_{\text{high}}\} のablationは探索・活用のレバーを確認しています：大きな \delta_{\text{high}}（稀少トークンへの上方予算の増加）は学習を加速させ、\delta_{\text{low}} はすでに選好されているトークンをどれだけ積極的に押し下げられるかを制御します。
限界と未解決の問題
- 幾何学的距離 d_{\text{geom}} はKLの二次テイラー近似です。これは r=1 付近では正確ですが、低確率トークンが合法的に到達できる非常に大きなratioに対しては精度が低下します（例：\delta=0.05 において \epsilon_{s,a}=\sqrt{\delta/0.001}\approx 7）。これがまさに [0.5, 10] のdual clipが維持される理由です。等距離境界とdual clipの相互作用は分析されていません。
- すべての実験は数学ベンチマークにおけるgroup-relative advantageを使用しており、一般的なRLHF preference タスク、ツール使用、または長期的なエージェントRLにおける挙動は未検証です。
- \pi_{\theta_{\text{old}}}(a|s) はsampling policyから取得されており、マルチステップのオフポリシーやreplayにおける扱いは議論されていません。
- 同じ幾何学的問題をclip側ではなくoptimizer側から対処するnatural-gradientやK-FAC系手法との比較がありません。
- AIME24の「60\% 改善」は相対値であり、ベンチマークごとの絶対値は提供されているセクションから抽出できません。
この研究の重要性
LLM RLにおけるclippingには、Clip-Higher、sequence-level、geometric-mean、dynamic-adaptiveといったヒューリスティックが積み重なっており、いずれも同じ根本的な幾何学的不整合にパッチを当てています。RIPOは原因——Fisher-リーマン多様体上のユークリッド閾値——を特定し、任意のGRPO/DAPOコードベースに追加するのが容易なワンライン・トークンごとのclip半径 \sqrt{\delta/\pi_{\text{old}}} でそれを修正します。
Source: https://arxiv.org/abs/2607.10169
SLPO: サロゲートポリシーによる潜在推論のスケーリング
問題
検証可能な報酬を用いた強化学習（RLVR）は、明示的なchain-of-thought（CoT）推論器におけるテスト時スケーリングを引き出すための標準的な手法となっていますが、計算コストはすべての中間ステップを言語トークンとしてデコードすることに支配されています。潜在推論器（COCONUT、CODI、CoLaR）は、推論を連続的な隠れ状態として伝播させ、はるかに短いホライズンで同等の精度を達成します。しかし、これらはいまだ教師CoTの模倣によって学習されています。すなわち、（i）連続的な潜在遷移にはPPOスタイルの目的関数で使用可能なステップごとの扱いやすい尤度が存在せず、（ii）固定された思考バジェットでは適応的な停止が不可能であるため、結果報酬による軌跡長の選択ができません。その結果、潜在推論器は明示的なCoTが行うようなテスト時スケーリングをいまだ活用できていません。
SLPOはこの両方の課題に対処します。すなわち、ポリシーgradientのクレジット割り当てのために潜在遷移に対する経験的なサロゲート密度を定義し、さらに正しさに対してコールドスタートされた後に結果報酬RLによって共同で洗練される学習済み停止ヘッドを追加します。
手法
Stage 1 — 停止ゲートのコールドスタート。 停止ヘッド g_\theta が潜在状態 h の上に取り付けられ、そのステップで潜在計算を終了する確率 s_\theta(h)=\sigma(g_\theta(h)) を出力します。各入力 x_i に対して、凍結された潜在バックボーンが T_{\max} まで N 個の確率的潜在軌跡をサンプリングします。すべての軌跡 n と候補停止長 t\in[T_{\min},T_{\max}] に対して、モデルはプレフィックス h_{i,1:t}^{(n)} を条件として明示的な回答をデコードします：
a_{i,n,t}\sim \pi_\theta(\cdot\mid x_i, h_{i,1:t}^{(n)}).
検証可能な報酬のもとでの正しさが有効停止集合 \mathcal{V}_i^{(n)} = \{t : R(a_{i,n,t}, a_i^\star)=1\} を定義します。\rho_{i,n,t}=s_\theta(h_{i,t}^{(n)}) と書くと、誘導される停止時刻の分布は
P_\theta(\tau_i^{(n)}=t) = \rho_{i,n,t}\prod_{k<t}(1-\rho_{i,n,k}),
となり、ヘッドは有効停止時刻への全確率質量を最大化することで学習されます：
\mathcal{L}_{\text{stop}}^{(i)} = -\frac{1}{N}\sum_{n=1}^N \log \sum_{t\in \mathcal{V}_i^{(n)}} P_\theta(\tau_i^{(n)}=t).
これにより、任意のRL fine-tuningの前に、明確に定義された尤度を持つ継続対停止のインターフェースが導入されます。
Stage 2 — サロゲートポリシー最適化。 核心的な困難は、決定論的な漸化式のもとでは連続遷移 h_{t-1}\to h_t に閉形式の密度が存在しないことです。そのため、（確率的な、例えばMC-dropoutによる）バックボーンから K 個の潜在後継状態を再サンプリングし、結果報酬目的関数に代入できる遷移尤度サロゲートを経験的に推定します。検証可能な報酬は次の要素の結合対数尤度を重み付けします：（a）サロゲートの潜在遷移、（b）デコードされた回答トークン、（c）ゲートの停止時刻分布：
ゲートが目的関数に参加するため、正しさの信号は潜在遷移を形成するだけでなく、ステップ間の計算を再配分し、固定バジェットのバックボーンから可変ホライズンのポリシーを生成します。RLOOとGRPOはいずれも互換性のあるadvantage推定量です。
推論。 テスト時には、ゲートが停止か継続かをサンプリングしながら潜在的思考が前進します。停止したら、終端の潜在プレフィックスを条件として回答がデコードされます。並列サンプリングによりPass@k曲線が得られます。
結果
評価はGSM8K-Augによる学習とホールドアウトされたGSM8K-Test、GSM-Hard、MultiArithで行われ、COCONUTとCODIに対してGPT-2（124M）とLlama-3.2-1Bバックボーンの両方を使用しています。決定論的精度にはdropoutを使用せず、Pass@kにはMC-dropout p=0.1 を使用します。
GPT-2では、COCONUT+SLPOにより平均Accが40.88から42.13に、Pass@16が50.86から52.22に向上します。CODI+SLPOの改善は平均Acc（47.59 → 47.66）では同程度ですが、Pass@16（54.81 → 55.84）ではより大きくなっています。Llama-3.2-1Bでは、より弱いCOCONUTバックボーンで改善がより顕著です：平均Acc 22.29 → 25.01、Pass@16 37.06 → 41.38、GSM-Hard Pass@16が9.94 → 10.93、MultiArith Pass@16が63.10 → 71.38に向上します。LlamaにおけるCODI+SLPOはPass@16を60.63から62.18に移動させ、GSM8K Pass@16は67.48 → 70.28に上昇します。Pass@kの改善はAccの改善を一貫して上回っており、結果報酬RLが決定論的なモードではなく確率的な潜在ポリシーを鋭化するという解釈と一致しています。
RLOOとGRPOの変種はCODIでは近似していますが、RLOOは高い k においてCOCONUTで優位になる傾向があります。これは、基礎となる潜在ポリシーが弱い場合に低分散のleave-one-outベースラインが有効であることを示唆しています。
ハイパーパラメータ感度。 グループサイズ G（問題ごとの軌跡数）は K（遷移ごとのサロゲート推定サンプル数）を支配します。もう一方を4に固定した状態で各々を \{2,4,8\} でスイープすると、より大きな G はGSM-HardとMultiArithにおけるPass@2を一貫して改善する一方、K はサロゲート密度を安定化させるのに十分な大きさになると飽和します。これは予想されるパターンです：K はニュアンス量の推定量分散を制御し、G は真のポリシーgradientのadvantage推定分散を制御します。
適応的な長さ。 Llama-3.2-1BにおけるソフトトークンTransferの設定では、結果報酬最適化が学習中に平均生成シーケンス長を変化させており、ゲートが単一のホライズンに収束するのではなく非自明な計算配分を行っていることを示しています：
制限と未解決の問題
評価は初等算術と、MATH500/AIME25/AMC23への限定的なソフト潜在Transferに限定されており、より長いホライズン・高い分岐を持つ推論（定理証明、コード）においてサロゲートが適切な振る舞いを維持するかどうかは未解決です。サロゲート密度は再サンプリングのためにMC-dropoutの確率性に依存しており、決定論的な潜在バックボーンには代替のノイズソースが必要となります。強い決定論的精度における改善は小さく（多くの場合1ポイント未満）、利益のほとんどはPass@kにあります。これはRLが新しい推論を教えているのか、既存の潜在モードの分布を再重み付けしているのかという問いを提起します。最後に、二段階の分離（コールドスタート後のRL）により、ゲートとサロゲートをスクラッチから完全に共同で学習できるかどうかが未解決のままです。
なぜ重要か
SLPOは、ステップごとのトークン尤度なしに自己回帰的潜在推論器に対して結果報酬RL——明示的なCoTのテスト時スケーリングの背後にあるメカニズム——を適用できることを初めて実証したものです。これは、経験的遷移サロゲートと学習済み停止分布を組み合わせることで実現されています。サロゲートアプローチが算術を超えて汎化するならば、潜在推論を現在明示的なCoTを支配しているRLVR駆動のスケーリング曲線から切り離している主要な技術的障壁が取り除かれることになります。
Source: https://arxiv.org/abs/2607.19691
SLAI T-Rex: DeepSeek-V4ファミリーのAscend SuperPOD上での全パラメータPost-training
問題設定
兆規模MoEモデルの全パラメータpost-trainingは、3つのシステムレベルの病理によってボトルネックが生じています。(1) オプティマイザの状態、活性化、エキスパート重みによるメモリ圧迫（高並列度でもデバイスあたりのHBMを超過する）、(2) 露出した通信（MoEルーティングのためのall-to-allのdispatch/combineおよびテンソル並列のall-reduceは、計算と自然に重複しない）、(3) attention、MoEゲーティング、エキスパートGEMMにおけるフラグメント化された演算に起因するカーネルの非効率性。公開されているレシピのほとんどはNCCL/NVLinkを搭載したNVIDIA GPUを対象としています。本レポートは代わりに、DeepSeek-V4ファミリーのためにHuawei Ascend NPU SuperPOD上でエンドツーエンドのスタックを構築し、未開拓の問いに取り組んでいます。すなわち、非GPUアクセラレータ上での兆規模MoEのpost-trainingにおいて現実的に達成可能なMFUはどの程度か、そしてボトルネックはどこにシフトするか、という問いです。
手法
本システムは、並列化、オーケストレーション、カーネルにまたがる3層階層最適化として構成されています。
並列化。 著者らは、エキスパート並列（EP）、パイプライン並列（PP）、テンソル並列（TP）、ZeRO方式のオプティマイザシャーディングを組み合わせています。これはDeepSeek-V4のMoEトポロジー（共有エキスパートを持つ細粒度エキスパート）をAscend SuperPODのインターコネクト上に収めるために選択されています。この選択は、HCCLファブリック帯域幅に対する露出all-to-allボリュームを最小化すること、すなわちEPグループを高帯域域内に収め、PPを低帯域リンク越しに配置することを指針としています。E個のエキスパート、top-kルーティング、隠れ次元h、トークンあたりのエキスパート数kを持つMoEレイヤーについて、トークンあたりステップあたりのdispatchボリュームはO(k h)でスケールするため、EPグループサイズ|EP|は次が成立するよう選択されます。
T_{\text{a2a}} \approx \frac{k h B}{|EP| \cdot BW_{\text{intra}}}
この値が対応するエキスパートGEMMの時間より小さくなるようにします。
計算-通信オーケストレーション。 All-to-allのdispatch/combineはマイクロチャンクに分割され、隣接するマイクロバッチの共有エキスパートMLPおよびattention計算とインターリーブされます。これにより、実効ステップ時間はT_{\text{comp}}とT_{\text{comm}}の和ではなく\max(T_{\text{comp}}, T_{\text{comm}})に近づきます。パイプラインスケジュールは1F1B類似の変形を使用し、ウォームアップ整形をMoE dispatchレイテンシにわたってPPバブル時間が償却されるよう調整します。さらに、attentionに選択的に適用される再計算ポリシー（MoEエキスパートには適用しない。ルーティングのスパース性によりエキスパートの活性化は再計算よりも保存のほうが安価なため）と組み合わせることで、ピーク活性化メモリをNPUあたりのHBM上限以下に抑えます。
カーネル。 低レベルでは、チームはattention（オンライン正規化を伴うFlashAttention方式のタイル化softmax）、MoEゲーティング+permutation+unpermutation、エキスパートのforward/backwardのためのgrouped GEMMを融合しています。Grouped GEMMが重要なのは、エキスパートあたりのトークン数n_eが著しく不均衡だからです。パディングされたbatched GEMMは\max_e n_e / \bar{n}_eに比例するFLOPを無駄にしますが、grouped変形はジャギー（不揃い）なバッチに対して1回のカーネル起動で実行します。bf16での数値安定性は、マスター重みとオプティマイザのモーメントをfp32で保持し、loss-scaledリダクションを用いることで維持されます。
結果
注目すべき数値は、Ascend SuperPOD上のDeepSeek-V4-FlashワークロードにおけるMFU 34.22%であり、同一ハードウェア上のオープンソースベースラインレシピに対して2.93倍の改善です。これはH100/H800クラスター上での兆規模MoEトレーニングで報告されているMFU（シーケンス長とルーティングに依存し、通常30〜40%）と同等の水準にあり、これこそがより意味のある比較です。すなわち、十分なco-designによってアクセラレータの選択が制約要因にはならないことを示しています。トレーニングの安定性は実行全体にわたって維持されており、つまりロールバックを要するダイバージェンスやlossスパイクが発生しませんでした。これはロータ崩壊とエキスパート不均衡が既知の失敗モードである兆規模MoEの全パラメータ（LoRAではない）post-trainingとして自明ではありません。
最適化されたインフラの上に、著者らはオペレーションズリサーチ（OR）タスクのためのCPT + SFTワークフローを構築しています。データパイプラインは収集されたORドメインコーパスと、ソルバー検証済み合成最適化ドキュメントを混合しています。これは古典的ソルバー（LP/MILP/CP）が真の最適解を生成する問題であり、その最適解は合成問題文のフィルタリングとchain-of-thought導出のラベリングの両方に使用されます。abstractは結果として得られたデータセットが約10Kの高品質サンプル（提供テキスト内では打ち切られている）であることを報告しています。これは堅実な合成データレシピです。ソルバー検証により、LLM生成の数学トレーニングデータの主要なリスク、すなわちもっともらしいが誤った中間ステップが除去されます。
限界と未解決の問題
本レポートは第一にシステム論文です。ORの下流評価は提供されたabstractに詳述されていないため、CPT+SFTステージがベースのDeepSeek-V4-Flashと比較して標準的なORベンチマーク（NL4Opt、ComplexOR、MAMO）の求解率をどの程度改善するかは不明です。MFU 34.22%は印象的ですが、理論FLOPの約3分の2がいまだ未活用です。残留通信露出、カーネル非効率性、パイプラインバブル間の内訳はここでは定量化されていません。他のMoEトポロジー（より密なルーティング、より大きなk、または共有エキスパートを持たない設計）への並列化レシピの汎用性は確立されていません。最後に、HCCLおよびベンダーカーネルへの依存により、Ascend SuperPOD外での再現性は限られています。技術的にはGPUクラスターへの概念的な移植は可能ですが、具体的なオーバーラップスケジュールは再調整が必要です。
重要性
これは兆規模MoEの全パラメータpost-trainingを非NVIDIAハードウェア上で競争力のあるMFUに到達させた数少ない公開された詳細な報告の一つであり、フロンティアトレーニングにおけるアクセラレータの多様性という実践的問いと、Ascend以外にも適用可能なMoEの計算-通信オーバーラップの具体的なレシピの両方において重要性を持ちます。ソルバー検証済みORデータパイプラインもまた、合成トレーニングデータの正確性が機械的に検証できるドメインに対して再利用可能なテンプレートです。
Source: https://arxiv.org/abs/2607.20145
関連性中心の検索を超えて：ルーブリック指向のドキュメントセット選択とランキング
問題
検索評価はドキュメント単位のパラダイムに縛られています。nDCGおよびその派生指標は、関連性判断に対して各ドキュメントを独立にスコアリングし、線形に集約します。しかし、RAGやエージェント的推論を行うLLMが下流の利用者である場合、重要なのは返されたセットの統合的な有用性です。すなわち、ドキュメント同士が矛盾しているか、内容が重複しているか、あるいはクエリに回答するために必要な推論チェーンを集合的にカバーしているかどうかです。著者らは、nDCG@5 = 100%でありながら、セットにはDoc [11]と[12]の間に事実の矛盾、ペア間の冗長性、そして重要な事実の欠落が存在するという具体的な例を示しています。
本論文が対象とするのはこのギャップです。すなわち、相互作用に敏感な次元に沿ってドキュメントセットをスコアリングする評価器を構築し、現在のrerankerがどこで失敗しているかを診断し、同一のルーブリックを学習不要の選択シグナルとして活用します。
手法
SetwiseEvalKitは、評価をドキュメントレベル・セットレベル・グローバルレベルという3階層9次元のタクソノミーに整理し、短形式および長形式のシナリオにわたる約28Kのルーブリックを備えています。セットレベルの次元はドキュメント間の相互作用（冗長性・矛盾・相補性）を明示的に捉え、グローバルレベルはセットが回答の再構築に十分かどうか（到達可能性・カバレッジ）を捉えます。
形式的には、クエリqと参照回答aが与えられたとき、(q, a)を条件として\mathcal{R}=\{r_1,\ldots,r_K\}を合成します。reranker mは|S_m|\le kを満たすS_m\subseteq\mathcal{C}を返します。judgeは以下を出力します。
\text{Score}(S_m) = \mathcal{E}(q, S_m, \mathcal{R}) \in \mathbb{R}^9,
すなわち、LLMはセット全体を一度読み込み、各次元を0〜4で採点します。ルーブリックは参照回答を条件とするため、セットレベルの病理を明らかにする粒度で情報ニーズをエンコードします。例えば、ケーススタディのクエリでは、複数のドキュメントが「戴冠」に関する矛盾した主張をしているため冗長性2/4・矛盾2/4となり、表面的な関連性は高いにもかかわらず推論チェーンを再構築できないため到達可能性1/4となります。
人間による検証（図3）では、博士レベルの評価者が生成されたルーブリックを高品質と判断しており、ルーブリックバンクをノイズの多いLLMの産物ではなくベンチマークとして使用することを支持しています。
Rubric4Setwiseは、同一のルーブリックを推論時の選択シグナルとして活用します。ドキュメントを個別にスコアリングするのではなく、候補となるサブセットを\mathcal{R}に対してスコアリングし、ルーブリックのカバレッジを最大化するサブセットを選択します。これは学習不要です。ルーブリック生成器とセットスコアラーはどちらもプロンプトによるLLMであり、選択は候補プール上のgreedy/beamな手続きです。核心的な帰納バイアスは、評価における「良いセット」を定義するルーブリック分布が選択の正しい目的でもあるということです。評価器と選択器を一致させることで、nDCG学習済みrerankerを悩ませる仕様のギャップが解消されます。
結果
著者らは3つのファミリーにわたる12のrerankerをベンチマークしています。アドホックなcross-encoderおよびリスト型LLM ranker（BGE-Reranker-Large、MonoT5、RankT5、RankLlama、RankVicuna、RankZephyr、Setwise）、推論強化型reranker（Rank1、Rearank、ReasonRank）、セット型reranker（SetR、Rank4Gen）、さらにBM25とGoogle Searchの下限値です。
セクション4の主要な知見：
- 上限が低い。 最良のrerankerでもルーブリックカバレッジは45%以下です。ルーブリック評価器の下では、現在のシステムはセットレベルの品質の大部分を達成できていません。
- ドキュメント間の協調が一様に弱い。 冗長性・矛盾・相補性の次元は、12のrerankerすべてで最低スコアです。セット単位で学習したメソッド（SetR、Rank4Gen）でさえ、このギャップを有意に埋めることができません。
- 体制をまたいだ勝者が存在しない。 短形式のコンテキストで先行するrankerは長形式で低下し、その逆も然りです。これは関連性に最適化された目的がセット構成の体制をまたいで汎化しないことを示しています。
- Rubric4Setwiseは下流生成で勝利する。 より少ないドキュメントとより少ない検索ラウンドで優れており、一貫してそうする唯一の手法として報告されています。共有されたルーブリックによって評価器と選択器を一致させることが、実証的に正しい結合であることを示しています。
セクション5のケーススタディは失敗モードを具体的に示しています。従来の指標はセットを完璧に評価する一方で、冗長性2/4・矛盾2/4・到達可能性1/4は、下流の生成器がつまずく欠陥を正確に示しています。
制限事項と未解決の問い
- 評価器\mathcal{E}自体がLLMであり、judgeの系統的なバイアスがベンチマークランキングとRubric4Setwiseの選択シグナルの両方に伝播します。人間による検証はルーブリックの品質をカバーしていますが、対抗的なセットに対するjudgeのスコアリングキャリブレーションはカバーしていません。
- ルーブリック生成には参照回答aが必要です。デプロイメントでは参照が存在しないため、選択時の手続きはqのみから、または予備的なドラフトからルーブリックを合成する必要があります。本論文のRubric4Setwiseの評価では、これらの体制と参照条件付きベンチマークが混在しています。
- 計算コストは焦点ではありませんが、LLMによるサブセットスコアリングは組み合わせ論的です。|\mathcal{C}|とkに対するスケーリング挙動は十分に特徴付けられていません。
- 9つの次元は動機付けられていますが、最小またはorthogonalであることは示されていません。次元の崩壊や重み付けの変更によって、手法のランキングが変わる可能性があります。
なぜ重要か
LLMが検索の主要な利用者である場合、評価の目標はポイントワイズな関連性ではなく統合的なセット有用性であるべきです。本論文は、そのギャップが大きい（12のrerankerの最良でも45%以下のカバレッジ）こと、そしてルーブリックを評価器と選択器の両方として使用することが学習なしにギャップを埋めることを示しています。ルーブリック条件付きセット選択が、デフォルトのRAGフロントエンドとしてポイントワイズrerankerに取って代わることが期待されます。
Source: https://arxiv.org/abs/2607.19747
大規模言語モデルにおけるハイパーネットワークベースの知識注入のスケーリング則
問題設定
凍結されたLLMへの信頼性の高い大規模知識注入は未解決の問題です。fine-tuningはコストが高く破壊的であり、RAGは負担を検索側に転嫁し、in-context learningはファクト数に対してスケールが悪くなります。本論文では、大規模なファクトコーパスで一度訓練されたハイパーネットワークが、そのコーパスから任意に取り出されたファクトに関する質問に答えるために、凍結された対象LMに挿入可能なLoRA adapterを生成できるかどうかを検討します。新しい切り口は実証的なものです。ハイパーネットワークはこれまでスケーリング則の観点から特性評価されておらず、先行研究ではハイパーネットワークの容量と対象モデルの容量が混在していました。本研究では対象LMを凍結するため、ハイパーネットワーク単独のスケーリング挙動を分離して観察できます。
手法
この設定では、知識注入を償却適応（amortized adaptation）として扱います。各訓練サンプルはクエリ q と、N 個の言語化されたファクトの集合 \mathcal{F} = \{f_1, \dots, f_N\} \subset \Omega から構成され、そのうち厳密に1つが関連するファクトであり、残り N-1 個はファクトコーパス \Omega からの一様なネガティブサンプルです。ハイパーネットワーク H_\phi(\mathcal{F}) は固定のLoRA adapter \Delta\theta を出力し、それが凍結された対象モデル \mathcal{M}_\theta に挿入されます。訓練lossは \mathcal{M}_{\theta + \Delta\theta} の下での回答 a の標準的な自己回帰NLLです。更新されるのは \phi のみであり、\theta は一切変更されません。デフォルトでは N=4 です。
訓練コーパスは MegaWikiQA であり、Wikidata5M（460万エンティティ、822の関係、2200万トリプル）から構築されています。k \in \{1,2,3,4\} に対するマルチホップQAサンプルは、知識グラフ上の一様ランダムウォークによって生成されます。再帰的な文法 f が k ホップのウォーク (s_1, r_1, o_1, \dots, r_k, o_k) を入れ子の名詞句（例：「マリー・キュリーの配偶者の国籍」）に変換し、それが質問テンプレートに変換されます。ウォークは知識グラフ上で決定論的であるため、正解は一意であり、データセットは39の知識ドメインにわたっており、OOD評価のためにドメイン全体を除外するのに十分な規模です。
4つの評価指標が異なる汎化軸を検証します。IDバリデーションloss、OOD非言い換えloss（除外ドメイン、同一テンプレート）、OOD言い換えloss（除外ドメインの言い換え質問）、およびOOD MCQ（除外ドメインへの選択式再構成）です。すべてのスケーリングfitは、最終エポックのlossを対数空間での最小二乗法により \mathcal{L} = a x^b と推定します。対象モデルはwidth/depth/ファクト数スイープにおいてQwen2.5-1.5B-Instructを使用しています。これはQwen2.5ファミリーが幅広いサイズにわたって一貫したアーキテクチャを提供するために選択されました。
結果
widthスケーリング。 固定depthにおいて d_{\text{model}} \in \{64, 128, 256, 512, 1024\} を変化させると、4つのすべての指標で明確なべき乗則が得られます。
- IDバリデーション：\mathcal{L}_{\text{val}} = 1.02 \cdot d^{-0.096}
- OOD非言い換え：指数 -0.100
- OOD言い換え：指数 -0.036
- OOD MCQ：指数 -0.075
IDの指数（-0.096）とOOD非言い換えの指数（-0.100）がほぼ等しいことは、widthが分布内と同一テンプレートのOOD再現率を実質的に同じ速度で向上させることを示しています。しかし言い換えの指数（-0.036）は約2.7倍フラットであり、widthだけでは表層形式の変動に対するロバスト性が得られないことを示しています。これは多様な言い換え訓練データや単純なパラメータ数を超えたメカニズムを必要とする能力と考えられます。MCQはその中間（-0.075）に位置し、open-endedな生成からの中程度の分布シフトと整合しています。
depthスケーリング。 固定widthでハイパーネットワークのtransformerレイヤー数 L_{\text{HN}} を変化させると：
- IDバリデーション：\mathcal{L}_{\text{val}} = 0.677 \cdot L^{-0.088}
- OOD非言い換え：指数 -0.096
- OOD言い換え：指数 -0.042
depthの指数はwidthの指数と近い値を示しています（ID: -0.088 対 -0.096；OOD非言い換え: -0.096 対 -0.100；OOD言い換え: -0.042 対 -0.036）。したがって、depthとwidthは注入品質に関してほぼ互換的であると考えられます。そして重要なことに、言い換えのギャップは持続します。どの軸をスケールしても、言語的な再定式化に対するロバスト性の改善はわずかにとどまります。これはアーキテクチャ上の問題ではなく、構造的なボトルネックです。
限界とオープンクエスチョン
すべての指数は浅く（絶対値 \le 0.1）、lossを半減させるにはハイパーネットワークのパラメータを約2桁増やす必要があり、検索などの代替手法と比較してコストがかかります。言い換えOODフロアは、ハイパーネットワークが真のファクトコンテンツルーティングではなく、テンプレート条件付きのパターンマッチングを学習している可能性を示唆しています。本論文では、これがデータ多様性の問題かアーキテクチャの問題かを切り分けていません。デフォルトの対象はQwen2.5-1.5Bのみであり、対象モデルとハイパーネットワークの同時スケーリングは今後の課題として残されています。ランダムウォークによるQA生成もまた、短いチェーン状の推論パターンを過剰に表現し、横断的な組み合わせを過少に表現している可能性があります。最後に、N=4 ファクトは現実的な検索バッファと比較して少なく、報告されているファクト数スイープは本稿では示されていません。
重要性
これは凍結されたLLMへの知識注入基盤としてのハイパーネットワークに関する初の制御されたスケーリング研究であり、widthとdepthの両方が（浅いながらも）明確なべき乗則に従うことを確立しています。一方で、言い換えに対するロバストな汎化ギャップがいずれの軸によっても意味のある形で解消されないことも明らかにしています。そのギャップこそが、ハイパーネットワークがRAGを置き換えるまたは補完できることを期待する研究者にとっての主要な研究対象です。
Source: https://arxiv.org/abs/2607.19604
Hacker News Signals
Gemini 3.6 Flash、3.5 Flash-Lite、3.5 Flash Cyber
Googleは、コストと性能のトレードオフが異なる3つのモデルバリアントをリリースしました。Gemini 3.6 Flashは主要なアップグレード版として位置づけられており、Flash クラスのレイテンシとコストで動作しながら、いくつかのベンチマークにおいて2.5 Proと同等の性能を発揮すると主張しています。アーキテクチャの詳細は非公開ですが、発表済みの1Mトークンコンテキストウィンドウは維持されており、テキスト・画像・音声・動画・コードに対応したマルチモーダルモデルです。ベンチマークの主張にはMMMLU、GPQA、コーディング評価が含まれていますが、Googleが自ら公表した数値である以上、自己申告型ベンチマーク特有の注意点を念頭に置いて読む必要があります。
Gemini 3.5 Flash-Liteは積極的なコスト削減を狙ったモデルです。3.5 Flash よりも低い価格設定で、トークンあたりのコストが支配的な高スループット・低レイテンシ重視のパイプラインにおいて3.5 Flashの置き換えを意図しています。ファミリーの中で最も小型でありながら、全マルチモーダル入力セットをサポートする唯一のモデルです。
Gemini 3.5 Flash Cyberは、セキュリティユースケース——CTFチャレンジ、脆弱性解析、exploit の推論——に特化して fine-tuning されたバリアントです。GoogleはCyberSecEval スタイルのベンチマークと並べて位置づけています。セキュリティ特化の fine-tune は増加傾向にあり（MistralのCodestral ファミリーも参照）、本モデルも汎用ベースモデルにセキュリティコーパスでドメイン固有のRLHFまたはSFTを施すというパターンに倣っています。
このリリース戦略は、単一のフラッグシップリリースからモデルファミリーへという業界全体のシフトを反映しています。開発者はコスト・レイテンシ・性能のPareto frontier上で自分たちに適した点を選択します。Flash ラインはAnthropicのHaikuおよびOpenAIの4o-miniティアと直接競合します。
注目すべき点として、リリースに公開技術レポートが添付されていないことが挙げられます。アーキテクチャの詳細（深さ、幅、MoE vs. dense、学習計算量）は不透明なままです。実務家にとって重要な問いは、3.6 Flashが主張するコストあたりの品質向上がドメイン固有のタスクでも成立するかどうかであり、本番ワークロードを移行する前に内部評価が不可欠です。
SIMDはすべての人が知るべき
Mitchell Hashimotoの投稿は、SIMDのリテラシーはシステムプログラマーにとって専門的なニッチではなく、基礎的なスキルであるべきと主張しています。この投稿ではx86 SSE/AVXとARM NEONを命令レベルで取り上げ、機械的なモデルを順を追って説明しています。すなわち、レジスタは固定幅のレーン（128ビット、256ビット、512ビット）であり、それぞれ幅Wの要素をN個保持し、N×Wがレジスタ幅と等しくなるというものです。演算はレーンごとに同時に適用され、明示的なshuffle/permute命令を使わない限りレーン間の通信は発生しません。
投稿では配列の総和という具体的な例を取り上げています。スカラーのループはアキュムレータへのシリアルなデータ依存があるためO(N)です。256ビットのAVX2と32ビット浮動小数点数を使えば、8要素の並列処理が得られます。すなわち、8つのfloatを__m256にロードし、ベクトルアキュムレータに積算し、最後に水平方向のリダクションを行います。この水平リダクション（ベクトルからスカラーの総和を取り出す操作）は複数のshuffleを要するコストがかかる処理であり、初心者が一貫して軽く見てしまう点です。
投稿が挙げる実践的なポイントとして、コンパイラが自動ベクトル化を確実に行えるのはエイリアシングがなくストライド1の単純なアクセスパターンに限られます。条件分岐や非単位ストライド、gather/scatterのアクセスパターンを導入した途端に、明示的なintrinsicが必要になります。投稿ではIntelのIntrinsics Guideを主要な参考資料として推奨し、まずスカラーのフォールバックを書いて正しさを検証してから、内側のループをintrinsicで置き換えるというアプローチを提唱しています。
また、アライメント要件（歴史的には非常に重要でしたが、AVX以降はアライメント非依存のロード命令により以前ほどではなくなったものの、レイテンシの観点では依然として考慮すべき点）についても触れています。さらに、x86-64の関数呼び出しにおいてワイドなレジスタを使用する場合のABIへの影響（YMM/ZMMに関してはcallee-savedかcaller-savedかのレジスタ規約が異なる点）についても説明しています。
SIMDのリテラシーを広めるべきという主張は実用的なものです。データ並列なワークロードにおけるボトルネックは一貫してメモリ帯域幅であり、SIMDはアルゴリズムを変えることなく演算強度を高める最も安価な方法です。
Source: https://mitchellh.com/writing/everyone-should-know-simd
Python 3.15の超低オーバーヘッドなインタープリタプロファイリングモード
CPython 3.15では、インタープリタループに軽量な計装パスを直接挿入することで実装された統計的プロファイリングモードが追加されます。解決しようとしている核心的な問題は次の通りです：既存のプロファイリングツール（cProfile、py-spy）は大きなオーバーヘッドを課します。cProfileのトレースフックはすべての関数呼び出しと返却時に発火し、10〜100倍の速度低下を引き起こします。py-spyはOSレベルのサンプリングを使用するため低オーバーヘッドですが、ptraceまたは同等の機能が必要で、Pythonフレームメタデータへのアクセスが制限されます。
新しいメカニズムはCレベルでバイトコード評価ループを計装します。グローバルカウンタが設定可能なインターバルでデクリメントされ、ゼロに達すると軽量なコールバックが発火します。設計上の重要な制約は、これがホットパスを乱してはならないということです：カウンタのチェックはほぼ常に分岐が取られない単一の分岐でなければならず、カウンタ自体はキャッシュミスなしにアクセス可能でなければなりません。
実装の詳細：CPythonにはすでに「eval breaker」メカニズム（シグナル処理とGILの解放に使用される）があり、後方ジャンプと関数エントリ時にスレッドステートのフラグをチェックします。プロファイリングフックは新たな無条件チェックを追加するのではなく、この既存のメカニズムに便乗します。これにより、通常（非プロファイリング）パスにおける追加オーバーヘッドはほぼゼロになります。eval breakerのビットチェックはすでに存在していたためです。
この記事には、以前のアプローチの10%超と比較して、CPUバウンドなワークロードで約1〜3%のオーバーヘッドを示すベンチマーク数値が含まれています。I/Oバウンドなワークロードでは、インタープリタのほとんどの時間が待機に費やされるため、オーバーヘッドは無視できます。
未解決の問題：統計的プロファイリングは、サンプルと一致しない短命な関数を見逃します。インターバルの選択（設定可能で、デフォルトは数百マイクロ秒程度）は、解像度とオーバーヘッドのトレードオフとなります。
Source: https://fidget-spinner.github.io/posts/ultra-fast-tracing.html
フランスのANSSIは2027年からPQC非対応製品の認証を拒否へ
フランスの国家サイバーセキュリティ機関（ANSSI）は、2027年以降にCSPN（第一レベルセキュリティ認証）またはCC（コモンクライテリア）認証を申請する製品に対し、耐量子計算機暗号アルゴリズムのサポートを義務付けると発表しました。古典的な非対称プリミティブ（RSA、ECDH、ECDSA）のみを実装した製品は、その他のセキュリティ評価に合格していても認証を取得できなくなります。
ANSSIが義務付ける具体的なアルゴリズムは、NISTが最終化したPQC標準に準拠しています。鍵カプセル化にはML-KEM（CRYSTALS-Kyber、FIPS 203）、署名にはML-DSA（CRYSTALS-Dilithium、FIPS 204）が指定されており、代替署名方式としてSLH-DSA（SPHINCS+、FIPS 205）も認められています。ANSSIは暗号移行に関して歴史的に保守的な立場をとってきたことで知られており、今回の2027年という期限は推奨ではなく、厳格な締め切りです。
技術的な負担は軽視できません。ML-KEMはモジュール格子を使用しており、鍵生成では q = 3329 として \mathbb{Z}_q^{k \times k} 上の中心二項分布からのサンプリングが行われ、そのセキュリティはModule-LWE問題の困難性に依拠しています。また、暗号文のサイズはRSAやECDHと比べて大幅に増大します。ML-KEM-768では1088バイトの暗号文が生成されるのに対し、X25519ではわずか32バイトです。この差異は、TLSハンドシェイクのサイズ、証明書チェーン、そしてバッファに制約のある組み込みシステムにとって大きな問題となります。
すでに開発中の製品にとって、2027年という期限は非常に厳しいものです。認証プロセスには通常12〜18ヶ月を要するため、設計の確定を早急に行う必要があります。この認証要件は、NISTの任意ガイダンスが果たせなかった強制力を持っています。すなわち、EU政府調達市場への参入を望むベンダーは必ず準拠しなければなりません。
ハイブリッドモード（古典暗号とPQCの同時使用）は移行手段として許容される可能性が高いと考えられますが、今回の発表ではハイブリッドが「PQC非対応」に該当するかどうかについては明確にされていません。
Source: https://postquantum.com/security-pqc/anssi-pqc-certification-2027/
あらゆる Text-to-SQL ベンチマークは実世界のデータストアが持つ困難に向き合うべきである
Databricks およびその他の研究者によるこの CACM ブログ投稿は、標準的な text-to-SQL ベンチマーク（Spider、BIRD、WikiSQL）と本番データベース環境との間にある体系的なギャップを指摘しています。主張の核心は、ベンチマーク用データベースが実際のエンタープライズデータウェアハウスとは異なり、クリーンで小規模かつスキーマが正規化されているという点です。
列挙された具体的な失敗パターン：
スキーマの複雑性: 実世界のデータウェアハウスは、命名規則が統一されていない数百から数千のテーブルを持ち、レガシーなセマンティクスを持つ冗長なカラムが存在し、外部キー制約も強制されていません。一方、ベンチマークのスキーマは自己説明的な名前を持つ5〜20テーブル程度で構成されています。
データ品質: 本番テーブルには、意味的に重要なカラムにNULLが含まれ、重複行、型の不一致、構造化データ（例：JSONブロブ、パイプ区切り値）をエンコードした文字列カラムが存在します。正しいSQLはこれらを防御的に処理する必要があります。ベンチマークはクリーンかつ完全に正規化された行を提供します。
曖昧な自然言語: 実ユーザーのクエリは仕様が不完全です。「先月の売上を見せて」という要求は、財務月と暦月のどちらか、どの売上定義（総売上/純売上/認識済み売上）か、複数の候補テーブルのうちどれかを知る必要があります。ベンチマークでは一対一の曖昧さのないマッピングが与えられます。
実行環境: ベンチマークの評価は小規模なテーブルに対してexact-matchまたはexecution-matchを使用します。本番クエリは数十億行に対して実行されるため、正解ではあるが非効率なクエリ（パーティションフィルターの欠落、cross joinの使用）は、サンプルデータ上では正しい結果を出せても、運用上は誤りとみなされます。
この投稿は、NULL処理に対するロバスト性、乱雑なデータ分布を持つテーブルでの正確性、そして精度と並んだ効率性の指標を含む評価基準を提案しています。新しいベンチマークのリリースには至っておらず、そこには明らかなギャップがあります。批判の問題設定は適切ですが、建設的な貢献は不完全なままです。
Source: https://cacm.acm.org/blogcacm/if-you-think-you-can-do-real-world-text-to-sql/
AIラボはPelicanmaxxingをしているのか？
Dylan Castilloの投稿では、「pelicanmaxxing」という言葉を用いています。これは動物の行動戦略に由来する用語で、単一の指標を異常なまでに追求することを意味します。この概念を通じて、フロンティアAIラボがbenchmark性能への過学習（overfitting）を実際の能力と引き換えに行っているのではないかという問いを提起しています。この主張自体は目新しいものではありませんが、その切り口は明快です。
技術的な核心的観察として、benchmarkの飽和は組織レベルでGoodhart’s Lawのダイナミクスを生み出すということが挙げられます。MMLU、HumanEval、あるいはMATHがモデル品質の代理指標となった途端、トレーニングパイプライン、データのキュレーション、そしてRLHFの報酬信号がその代理指標に合わせて調整されるようになります。その結果、benchmarkの分布上では高スコアを記録するものの、意味的には等価でありながらも分布外（out-of-distribution）のバリアントでは失敗するモデルが生まれます。本投稿では、GSM8K上の性能と、表面的な言い換えを施したGSM8K形式の問題における性能との間に広く知られたギャップがあることを引用しています。
提案されている具体的なメカニズムは次の通りです。RLHFの報酬モデルは、評価者によって収集された人間の選好データを用いて訓練されますが、その評価者自身が品質の表面的なマーカー（自信に満ちたトーン、構造化されたフォーマット、回答の長さなど）に影響を受けています。これにより、ベースモデルが報酬モデルで高スコアを得るような出力を生成するよう学習するフィードバックループが生まれます。報酬モデルは人間の評価を近似したものであり、その人間の評価自体がbenchmarkで飽和した出力に影響を受けています。つまり、報酬モデルは真の能力に対してalignされているのではなく、能力の見かけに対してalignされているのです。
本投稿は、これが外部から完全に証明できるものではないという点について正直に認めています。ラボはevalの数値を公開しますが、報酬モデルのアーキテクチャやデータキュレーションのパイプラインは公開しません。状況証拠（benchmarkの急速な飽和、些細なバリアントで失敗するモデル）はこの仮説と整合しますが、決定的なものではありません。
建設的な示唆として、評価インフラはトレーニングインフラと同等に重要であるということです。Benchmarkには、クリーンな分布上の正確さだけでなく、adversarialなロバスト性が求められます。
Source: https://dylancastillo.co/posts/pelicanmaxxing.html
スタートアップのための Postgres 生存ガイド
Hatchet のエンジニアリングブログ記事は、専任 DBA を持たないチームが負荷のかかった状態で Postgres を運用するための、実践的な運用ガイドです。技術的な内容は「生存ガイド」というフレーミングが示唆するよりも密度が高くなっています。
主要なセクション：
接続管理: Postgres は接続ごとに1プロセスを使用します（スレッドではありません）。そのため、接続数はメモリプレッシャーおよびコンテキストスイッチのオーバーヘッドに直接比例します。本記事では、ほとんどのワークロードに対して transaction-mode pooling の PgBouncer を推奨していますが、transaction-mode は prepared statement およびセッションレベルの状態（SET LOCAL、advisory lock）を破壊するという注意点があります。代替手段として Supavisor や pgpool-II があり、それぞれ異なるトレードオフのプロファイルを持ちます。
Vacuum とブロート: MVCC により、デッドタプルの蓄積は避けられません。本記事では autovacuum のチューニングを取り上げており、autovacuum_vacuum_scale_factor（デフォルト 0.2 はテーブルの 20% がデッドタプルになった後に vacuum がトリガーされることを意味し、大規模テーブルには高すぎます）は大規模テーブルに対して下げるべきであり、autovacuum_vacuum_cost_delay は I/O スロットリングを制御します。書き込み頻度の高いテーブルでは、バルク操作後に手動で VACUUM ANALYZE を実行することが必要になるケースが多いです。
Index 戦略: 固定述語を持つクエリ（例：WHERE status = 'pending'）に対する partial index、ヒープフェッチを回避するための covering index、追記専用の時系列テーブルに対する BRIN index。本記事は index の過剰追加に対して明示的に警告しており、各 index は書き込み増幅を引き起こし、autovacuum のコストを増加させます。
ロック競合: 大規模テーブルに対する ALTER TABLE は ACCESS EXCLUSIVE ロックを取得します。ゼロダウンタイムのスキーマ変更に推奨されるパターンは、pg_repack 拡張機能または CREATE INDEX CONCURRENTLY とconstraint のスワップによるアプローチです。本記事では、一般的な DDL 操作における具体的なロックレベルも文書化しています。
モニタリング: pg_stat_activity、pg_stat_user_tables、pg_locks、および pg_stat_bgwriter の4つのビューが、本番環境のほとんどの問題を診断するために必要です。本記事では具体的なクエリも提供しています。
Source: https://hatchet.run/blog/postgres-survival-guide
Gemini最新モデル：temperature、top_p、top_kが非推奨となり無視されるように
Googleの「gemini-latest」モデルエイリアスに関するAPIドキュメントに、temperature、top_p、top_kのサンプリングパラメータが非推奨となり、サイレントに無視されると明記されました。これは技術的に重要な変更であり、本番システムに実際的な影響をもたらします。
この変更が意味するのは、これらのモデルが呼び出し元によってオーバーライドできない、内部でチューニングされた固定のサンプリング設定を使用しているということです。最も妥当な説明としては、モデルがspeculative decoding、distillationベースの推論、またはカスタムサンプリング手順（classifier-free guidanceの変形型やlearned temperature scalingの可能性あり）を採用しており、標準的な多項サンプリングのパラメータ化と非互換であるというものです。あるいは、サンプリングのハイパーパラメータがRLHF/RLAIFのトレーニングプロセス自体に吸収されており、事後的な調整が冗長あるいは有害になっているとも考えられます。
APIのユーザー視点からは、これによりいくつかの一般的なパターンが機能しなくなります。評価パイプラインで決定論的な出力を得るためのtemperature=0の設定、出力の多様性を制御するためのtop_p nucleus sampling の使用、クリエイティブなタスクに向けたtemperatureのスイープなどが該当します。再現性のあるコード生成や構造化データ抽出のために低いtemperatureの出力に依存しているアプリケーションは、新しい固定動作が要件を満たすか検証する必要があります。
HNのディスカッションでは、これがAPIサーフェスからサンプリングパラメータを完全に削除するための布石なのではないか、という疑問が提起されました。これはGoogleが推論を統計的なプリミティブとして公開するのではなく、ブラックボックスとして扱う方向性と一致しています。しかしその立場は、制御された実験にこれらのパラメータを活用している研究者や実務家の利用スタイルと相容れません。
固定サンプリング設定の内容を説明するドキュメントは一切提供されておらず、出力分布の特性を推論することが不可能な状態です。サイレントな非推奨化（パラメータは受け付けるが無視される）は、デバッグの観点からは明示的なエラーを返す場合よりも問題が大きいと言えます。
注目の新しいリポジトリ
can1357/pon
Rustで書かれたネイティブのPython 3.14コンパイラおよびランタイムで、CPythonバイトコードではなく実際のマシンコードをターゲットにしています。コンパイラパイプラインはAST構築にRuffパーサーを使用し、コード生成にはCranelift（Wasmtimeおよびrustcのデバッグビルドで使用されているのと同じバックエンド）を採用しており、Green Teaと呼ばれるカスタムGCを搭載しています。JITとAoTの両コンパイルモードに対応しており、デプロイ前に事前コンパイルすることも、動的なワークロードに対してランタイムでネイティブコードを生成することも可能です。
技術的に最も興味深い点は、差分テストハーネスです。コンパイルされた出力がCPythonインタープリタに対してバイト単位で正確にテストされ、高レベルのテストスイートに頼るのではなく、値レベルでのセマンティクスの乖離を検出します。これは、Pythonのように暗黙的な型変換や例外伝播の挙動が多数存在する言語に対して正しいアプローチです。
CraneliftはここではRich選択肢と言えます — クリーンなIRを持ち、コンパイル時のパフォーマンスも妥当で、LLVMのような複雑さなしに優れたレジスタ割り当てを実現しています。Rustによる実装により、ランタイム自体がGIL相当の問題を設計上回避できます。これは初期段階の成果物ですが、アーキテクチャ（Ruff + Cranelift + カスタムGC + 差分テスト）は健全であり、セマンティクスの定義が不十分になりがちなPythonコンパイラプロジェクトにありがちな落とし穴を回避しています。
Pythonのパフォーマンスを研究している方、ネイティブPython実行まわりのツールを構築している方、あるいは実用的なモダンスタックを用いたコンパイラ構成を学んでいる方に適しています。
Source: https://github.com/can1357/pon
deer-flow/llm-space
LLMエージェントの反復開発のためのローカルファースト型デスクトップアプリケーションです。コアとなる価値提案は完全な可観測性にあります。エージェントの実行ハーネスにおけるすべてのステップがキャプチャされ、検査可能で、再実行可能です。失敗の replay はファーストクラスの機能として提供されており、失敗したトレースを再実行する際に、エージェントループ全体を再実行したり、本番インフラに触れたりすることなく実行できます。
アーキテクチャはローカルファーストを基本とし、マネージドエージェントデプロイメント向けにオプションのクラウドパスも用意されています。これは開発においては適切なトレードオフです。プロトタイピング中は決定論的でオフライン対応の反復作業が求められ、本番環境への移行時にはマネージドインフラへのハンドオフが必要になります。このツールはトレースインスペクタと並行して評価ツールを統合しており、パフォーマンスメトリクスを定義してライブ実行時だけでなくキャプチャされたトレースに対しても実行できます。
エージェント開発者にとって、replay と評価のループは最も一般的なペインポイントの一つに対処しています。非決定論的な多段階エージェントの挙動をデバッグするには再現性が必要ですが、現在のほとんどのツールはそれを提供していません。プロトタイプ、検査、replay、ベンチマークを単一のアプリケーションで処理できることで、個別のトレース・評価・デプロイメントツール間のコンテキストスイッチを削減できます。
ステップレベルの詳細検査と構造化された評価パイプラインの組み合わせにより、反復ループを厳密に制御したい開発者にとっては、汎用の可観測性プラットフォーム（LangSmith 等）よりも有用なツールとなっています。
Source: https://github.com/deer-flow/llm-space
michaelshimeles/boring-computers
Firecracker microVMを基盤とするオンデマンドのLinux環境で、AIコーディングエージェントへの提供を専目的として設計されています。各VMにはブラウザ、ターミナル、コーディングエージェント統合が含まれており、AIがプログラム的に環境を操作できる薄いレイヤーを備えています。Firecrackerはこの用途に適した基盤です：100ミリ秒未満の起動時間、VM間の強固なハードウェア仮想化による分離、そしてフルQEMUやコンテナベースのアプローチと比較して最小限の攻撃対象範囲を実現しています。
この設計は、「computer use」エージェントという新興パターンを対象としています。これは、サンドボックス化されたサブプロセスではなく、本物の隔離された実行環境を必要とするモデルのことです。コンテナやシミュレーション環境ではなく、本物のVMに各セッションを根ざすことで、忠実なファイルシステム状態、実際のネットワークスタック、そして真のプロセス分離が得られます。エージェントが任意のコードを実行する場合、これらは重要な要素となります。
ブラウザが含まれている点は注目に値します：多くのエージェントタスクではJavaScriptが多用されるページのレンダリングが必要であり、ヘッドレスのスクレイピングレイヤーではなく、VM内に本物のブラウザを持つことで、エージェントは完全なDOMとインタラクション対象への完全なアクセスが可能になります。これはアーキテクチャ的にE2BやModalのsandbox製品と類似していますが、オープンでセルフホスト可能な代替として位置づけられています。
コーディングエージェント、セキュリティサンドボックス、あるいは真のOSレベルの分離を必要とする自動評価環境を構築している方に関連します。
Source: https://github.com/michaelshimeles/boring-computers
eli-labz/Cognitive-Core-Skills
LLM、SLM、エージェント、およびワールドモデルを対象とした認知能力の構造化タクソノミーであり、知覚・記憶・推論・計画・行動・検証・学習・ガバナンスという8つのトップレベルカテゴリに整理されています。本プロジェクトは159枚の個別スキルカード、機械可読スキーマ、benchmark マッピング、およびスキーマの整合性を検証するCIパイプラインを提供します。
このタクソノミーは明示的に業界中立として設計されており、特定のアプリケーションドメインやモデルアーキテクチャには対応していないため、製品固有のオントロジーではなく横断的なリファレンスとして利用されることを意図しています。各スキルカードにはスキルの定義、関連する benchmark、および他スキルとの関係が記述されており、フラットなリストではなくグラフ構造の能力マップを構成しています。
想定される実用的なユースケースとしては、評価設計（benchmark スイートをタクソノミーにマッピングしてカバレッジのギャップを特定する）、能力の伝達（モデルが何をできて何ができないかを構造化された形式で報告する）、およびエージェントアーキテクチャの計画（どの認知機能をどのコンポーネントが担うべきかを特定する）が挙げられます。スキーマの妥当性に対するCI強制により、このタクソノミーは静的なドキュメントではなく継続的に維持されるアーティファクトとして管理されています。
このタクソノミーの価値は benchmark マッピングの品質に大きく依存しており、それが浅いものであれば、スキルカードは操作可能な仕様ではなくドキュメントにとどまってしまいます。評価フレームワークとして採用する前に、benchmark のカバレッジを詳細に検討する価値があります。
Source: https://github.com/eli-labz/Cognitive-Core-Skills
QuintinShaw/openasr
クラウド依存なし・テレメトリなしで、OpenAI互換のエンドポイントを公開するローカル音声テキスト変換CLIおよびAPIサーバーです。統一されたCLIインターフェースを通じて7つのモデルファミリー（Whisperのバリアントなどが含まれると思われます）を選択でき、モデルの重みのサプライチェーン置換を防ぐための署名付きモデルカタログを同梱しています。
フェイルクローズド設計がこのアーキテクチャの重要な判断です。ローカルランタイムがリクエストを処理できない場合、リモートAPIへフォールバックするのではなく、エラーを返します。これは、クラウドへのサイレントフォールバックがセキュリティおよびコンプライアンス上の問題となる、プライバシーに敏感なデプロイメント（医療・法律・オンプレミスエンタープライズ）に対して正しいデフォルト動作です。
OpenAI互換のAPIサーフェスにより、openai.Audio.transcribe を使用する既存のコードベースへのドロップイン置換が可能です。署名付きカタログは実際の攻撃ベクターに対処しています。署名なしのモデルダウンロードは転送中または保存中に改ざんされる可能性があり、ハッシュ検証付きの署名済みマニフェストにより、使用している重みのカストディチェーンをオペレーターに提供します。
7つのモデルファミリーを単一のCLIインターフェースで扱えることは、モデルごとに個別のツールを管理することなく、アーキテクチャをまたいだ文字起こし品質とレイテンシのトレードオフをベンチマークしたいオペレーターにとって、使い勝手の良い設計です。
Source: https://github.com/QuintinShaw/openasr
William-Lu-stack/Flawless
Kubernetesおよびクラウドインフラ向けのエージェント型SREプラットフォームであり、「AgenticOps」カテゴリに位置づけられています。これは、人間によるレビューのための推奨事項を提示するだけでなく、運用タスクを自律的に実行するエージェントを指します。本システムは、インシデント検知、根本原因分析、修復、およびインシデント後のレポート作成という標準的なSREの問題領域を対象としており、エージェントループがオンコールエンジニアの判断を代替または補完します。
Kubernetesへの注力は、k8sの運用上の複雑さ（連鎖的なPod障害、HPAの設定ミス、リソース枯渇、ネットワークポリシーの競合など）が、大規模環境において手動でのトリアージが困難なアラートストームを引き起こすという観点から、適切な選択です。Kubernetes API、メトリクス、およびログへのアクセスを持つエージェントは、複数のダッシュボードを横断して作業する人間よりも原理的に高速にシグナルを相関させることができます。
あらゆるAgenticOpsシステムにおける重要なエンジニアリング上の問題は、エージェントが自律的に実行できるアクションと人間の承認を必要とするアクションの区別、アクション境界の強制方法、そしてエージェントが誤った修復判断を下した場合のロールバック手順です。リポジトリの説明ではこれらの境界が明示されておらず、本番環境での採用前に評価すべき主要な点となっています。
技術的にはk8sgptやRobustaのようなプロジェクトに隣接していますが、アドバイザリー的なフレーミングではなく、より自律的なエージェントとしてのフレーミングが特徴です。
Source: https://github.com/William-Lu-stack/Flawless
pocket-stack/pocketjs
ブラウザ以外の環境——組み込みディスプレイ、キオスクハードウェア、TVプラットフォーム、およびそれに類する制約されたレンダリングターゲット——を対象としたJSX UIフレームワークです。Vue VaporおよびSolidスタイルのリアクティブプリミティブを実装しており、仮想DOMのdiffingを必要としないfine-grainedなリアクティビティを実現するとともに、ユーティリティクラスレイアウト向けのTailwind互換スタイルエンジンを備えています。
8 MBのメモリ予算と60 FPSのアニメーションターゲットが設計上の制約を定義しています。8 MBでは、フルブラウザエンジンやNode.jsランタイムを搭載する余裕はないため、フレームワークはコンパクトなネイティブレンダリングパスにコンパイルされなければなりません。フレームレートターゲットを達成するために、ソフトウェアラスタライゼーションに頼らず、ハードウェアレンダリング（おそらくOpenGL ES、Metal、あるいはそれに類するプリミティブによるGPUアクセラレーションされた2D API）を使用します。
Vue VaporおよびSolidのコンポーネントモデルをサポートするという判断は、移植性の観点から賢明です。これらのリアクティビティシステムに精通した開発者は、新しいコンポーネントAPIを学ぶことなく、組み込みハードウェア上で動作するコンポーネントを記述できます。Tailwindスタイルエンジンにより、CSSの抽象化とプラットフォームが公開するネイティブレイアウトモデルとの間の変換が不要になります。
このようなプロジェクトにおける主要なエンジニアリング上の課題は、フォントレンダリング、テキストシェーピング、そしてアクセシビリティです——これらはブラウザエンジンが長年にわたって積み重ねてきた膨大な複雑さを抱える領域です。pocketjsがこれらをどのように扱うかによって、プロダクションUIとして実用に耐えるものになるか、あるいは主にテキストが少ないグラフィカルなダッシュボードやキオスク向けに有用なものにとどまるかが決まるでしょう。
Source: https://github.com/pocket-stack/pocketjs
KlaatAI/klaatcode
マルチモデルルーティング層を備えたターミナルベースのAIコーディングエージェントであり、タスクの種類とコストプロファイルに応じてサブタスクを異なるモデルに振り分けます。シングルモデルアプローチ（例：常にClaude OpusやGPT-4oを使用する場合）と比較して10倍のコスト削減が可能と謳われていますが、これはフロンティアモデルの性能が不要なタスク——ファイルナビゲーション、ボイラープレート生成、検索——には安価または小規模なモデルを振り向け、複雑な推論ステップにのみ高コストなモデルを割り当てることで実現しています。
対応バックエンドにはClaude、GPT、Gemini、DeepSeekが含まれており、ルーターは幅広い性能・コストの選択肢を持っています。ターミナルファーストのインターフェースは、エージェントとのやり取りにIDEプラグインよりもCLIツールを好む開発者のワークフローと親和性が高いです。
技術的に核心となる問いは、ルーターがどのモデルにどのサブタスクを担当させるかをどのように決定するかという点です。適切に設計されたルーターには、それ自体が安価に動作するタスク分類器、各バックエンドの性能モデル、そしてルーティング判断が節約するコストを上回るオーバーヘッドを生じさせないためのレイテンシバジェットが必要です。ルーティングロジックの設計が不十分な場合、シングルモデルアプローチを下回る精度に容易に劣化し得るため、ルーティングヒューリスティックスはとりわけ精査に値するコンポーネントです。
「Claude Code相当の精度」という主張はベンチマークに関するアサーションであり、額面通りに受け取るのではなく、SWE-benchや類似の標準化されたコーディングエージェント評価で検証する価値があります。