はじめに：推論の「枠組み」を変える動きが目立つ一日

7月25日に収集されたAIニュースを振り返ると、目立つのは「LLM推論をどう効率化するか」というテーマです。モデルの巨大化が続く一方で、ハードウェア・アーキテクチャ・実行環境の工夫で「リソースの限られた環境でもっと大きなモデルを動かす」という方向に関連する発表が相次ぎました。

本日はその中から6つのトピックを取り上げます。また前回掲載のOpenAIエージェント暴走事件は今回追加情報が限定的だったため、本稿では取り上げません。

1. 富士通の光ベース新AIアーキテクチャ「PHOTON」が「475倍」を主張

富士通が新たに提唱したAIアーキテクチャ「PHOTON」が話題を呼んでいます。技術解説記事を公開したQiitaのDev_haru氏の記事によれば、PHOTONは光通信技術をAI処理の通信パスに活かすことで、従来と比較して最大475倍の効率改善を主張しているとのこと。

プレスリリースで謳われている数値について、同記事では「技術的に読み解く」という形でアプローチの概要と数値の根拠を詳しく考察しています。光技術を用いたチップ間通信のレイテンシ削減や、メモリ帯域のボトルネック回避が中心となるアプローチとみられますが、原本の論文等は本稿では未確認のため、詳細は同解説記事および富士通の公式発表を参照してください。

2. Slipstream：SSDからMoEエキスパートをストリーミング、36GB Macで35B〜480Bを実行

Redditのr/LocalLLaMAで話題を集めているのが「Slipstream」です。開発者のIllustrious-Cup-5895氏によれば、llama.cppをフォークし、MoE（Mixture of Experts）モデルのエキスパート重みをSSDからオンデマンドでストリーミングする仕組みを実装したとのこと。

MoEはトークンごとに少数のエキスパートだけが発火するため、大半の重みは待機状態になります。Slipstreamは常に必要な重みだけをRAMに常駐させ、ルーティングされるエキスパートを都度ストリーミングして、スワップを起こさないよう制約付きキャッシュで管理します。結果として36GBのMacBookでも35B〜480Bの符号化モデルが動作可能だと説明しています。

興味深いのは「失敗も含めて公開」している点です。投稿では、Qwen3.6-35B-A3B（Q4）で約13 tok/s（キャッシュ10GiB）、Laguna 118B-A8Bでは約2.8 tok/sという実測値の一方、デュアルSSDストライピングや投機的プリフェッチはネガティブな結果に終わったことも率直に報告されています。MITライセンス・完全オフライン動作のネイティブmacOSアプリとして公開されており、Colibriを参考にApple Silicon向けに最適化したとのことです。

3. TensorSharp：C#で実装したLLM推論エンジン、llama.cppに匹敵する性能を主張

同じくr/LocalLLaMAでfuzhongkai氏が公開した「TensorSharp」は、C#でゼロから実装されたLLM推論エンジンです。llama.cppのC#ラッパーではなく、LLM推論エンジン全体をボトムアップで実装したとしています。

Gemma 4 E4B / 12B、Qwen 3.6 35B-A3B / 27Bで、CUDA・Vulkanバックエンドにおけるllama.cppとの比較ベンチマークが公開されています。decode（トークン生成）で1.00〜1.21倍、_prefill_で最大1.28倍、TTFTで最大1.27倍と、シナリオによってはllama.cppを上回る結果を示しました。ただしVulkanのQwen 3.6 27Bでは0.84〜1.02倍と、バックエンド・モデルによってばらつきがあります。

Windows/macOS/LinuxでNvidia・Apple・AMD・Intelなどマルチプラットフォーム対応をうたっており、APIはOpenAI/Ollama互換。vLLM由来のページ化KVキャッシュや連続バッチ処理、oMLX由来のMoE向けSSDベースキャッシュなど、先進的な工夫も取り込んでいるとのことです。

4. LFM 2.5 230M：WebGPUでブラウザ内1440 tok/sを実現

WebGPU経由でLLMをブラウザ実行する取り組みも進んでいます。lordhiggsboson氏が公開したデモでは、LFM 2.5 230MがRTX 3090環境で1400〜1500 tok/s、Apple M4で400〜500 tok/sを記録したと報告されています。Bonsai 1.7BでもRTX 3090で500〜600 tok/sを計測。

注目すべきは最適化のハードウェア特化設計です。Nvidia向けにはマルチパス構造でカーネルを激しく融合させる一方、Apple SiliconではTBDR（Tile Based Deferred Rendering）のオーバーヘッドを最小化するため単一の融合メガカーネルを採用しています。実際のデモは https://warp.sipp.sh で公開されており、このコードは今後Sippライブラリに統合される予定とのことです。

5. Pyshackle：AIエージェントのツール呼び出しに「事前実行ゲート」を設けるOSS

AIエージェントの自律性が高まる中、意図しないツール実行を防ぐセキュリティ層の需要が増えています。PyPIで公開された「Pyshackle」は、エージェントがツールを呼び出す前に「ハードな事前実行ゲート（hard pre-execution gate）」を挟む仕組みを提供します。オープンソースでHacker Newsでも取り上げられました。

詳細な実装内容は本稿収集データでは限定的なため、設定可能なゲートの条件や対応ランタイムについては原本（pypi.org/project/pyshackle/）を参照してください。Slipstreamの「失敗も公開」というスタンスと並べて考えると、AIエージェントの安全性をどう設計するかがエンジニアリングの重要テーマになりつつあることが伺えます。

6. AlayaWorld：15Bのインタラクティブ長時間ビデオワールドモデルがオープンソースで登場

Papers with Codeに掲載された「AlayaWorld」は、インタラクティブかつ長時間生成可能なビデオワールドモデルです。15Bのビデオdiffusion transformerをベースにし、24fps・540p/720pの映像を生成。カメラ軌跡と切り替え可能なテキストプロンプトに従い、短い潜在チャンクを自己回帰的に生成する仕組みです。

特に工夫されているのが「bounded visual context」の設計。永続シンクフレーム・圧縮された時間履歴・幾何整合的な空間メモリ・直近フレームの条件付けを組み合わせることで、長時間生成時のドリフトを低減しています。さらに学習時に破損履歴と自己ロールアウト由来の予測残差を活用するアプローチや、分布マッチング蒸留・self-forcing++・一貫性蒸留を組み合わせた「離散自己回帰蒸留」により、チャンクあたり約30ステップだった推論を4ステップまで削減しています。iWorld-Benchでは長時間生成で最高性能を達成したと主張。フルスタックのオープンソース長期プロジェクトとして公開されています。

編集後記：LLM推論の「地続き」な工夫が加速している

今週後半のニュースを見ると、超大規模モデルの「学習」よりも、既存のモデルを「どう動かすか」というインフラ寄りの工夫が目立ちます。光技術の投入（富士通PHOTON）から始まり、SSDストリーミング（Slipstream）、言語ランタイムでの再実装（TensorSharp）、GPUリソースの直取り（WebGPUブラウザLLM）、エージェント実行の安全弁（Pyshackle）、そしてビデオ生成の長時間化・低ステップ化（AlayaWorld）まで、それぞれレイヤーは違えど「限られたリソースをどう絞り出すか」という共通の関心が読み取れます。

詳細な数値や実装の正しさについては原本を参照してください。本稿では収集データの範囲内で、過度な断定を避けて書いています。