[AI ニュース] 新たな AI インフラのユニコーン企業：Fireworks、Baseten（OpenRouter も進行中）

2026 年 AI エンジニアリング調査に参加し、2,000 ドル以上のクレジットと AIE WF のチケットを獲得しよう！

読者の方々は「ニュースなし」という報告を好まれる傾向がありますが、私たちが次に好きなことは、あなたが知っておくべきトレンドを単に強化できることです。4 月に私たちは推論の転換点（Inference Inflection）を取り上げましたが、今日のヘッドラインが先週のそれと似ていると感じるなら、まさにそれが私たちが伝えたいポイントです。

$2k のクレジットと AIE WF チケット！

[AINews] 新たな AI インフラのユニコーン：Exa, Modal, TurboPuffer

著者：Latent.Space

バイオグラフィー：ライター、キュレーター、潜在空間探検家。メインブログ：https://swyx.io / Devrel/Dev コミュニティ：https://dx.tips / Twitter: https://twitter.com/swyx

公開日：2026 年 5 月 22 日

カバー画像：[AINews] New AI Infra unicorns: Exa, Modal, TurboPuffer

セクション名：AINews: Weekday Roundups（平日まとめ）

投稿 ID: 198804002

タイプ：ニュースレター

反応数：43

コメント数：0

出版物名：Latent.Space

最近の AI 資金調達のペースを踏まえると、当社の一般的な方針は、スタートアップを取り上げる際はデカコーン（100 億ドル超）の地位に達した時だけとするものです。ただし、これは確認された場合に限られます。本日の Fireworks の 150 億ドルラウンド（"交渉中"、7 ヶ月で 3.75 倍増、当社のポッドキャストはこちら）や Baseten の 110 億ドルラウンド（"募集中"、3 ヶ月で 2.2 倍増）というニュースは少し時期尚早かもしれませんが、推論（Inference）領域における加速とユニコーンからデカコーンへの進展のペースがあまりにも魅力的であるため、本日のヘッドラインストーリーとして取り上げるには十分です。さらに、マルチモデル推論を行うならルーターが必要となるでしょうという点で、1 億 1300 万ドルの OpenRouter シリーズ C ラウンド（6 ヶ月で利用量が 5 倍）がまさにその上乗せの甘味となります。

2026 年 5 月 23 日〜26 日の AI ニュース。12 のサブレッド、544 のツイートを確認し、Discord は追加情報なしでした。AINews のウェブサイトでは過去のすべての号を検索できます。念のため、AINews は現在 Latent Space の一部となっています。メールの頻度を選択して受け取ることができます。

AI Twitter リキャップ

エージェント・ハーネス、コーディングベンチマーク、そして「モデルだけ」を超えた転換点

コーディングエージェントにおけるエンジニアリングの構築が主要な差別化要因となりつつある：複数の投稿が同じ主張に収束している。すなわち、勝つためのスタックは単なる強力なベースモデルではなく、「モデル＋ハルネス（harness）＋評価ループ」である。Zhihu 上の長文要約では、DeepSeek が明示的にハルネスチームを構築し、モデル出力とランタイムフィードバック、検証、修正の間のループを閉じようとしていることが指摘された。これには、より緊密な相互作用・検証ループを支えるキャッシュ入力コストの優位性が伴うとされる。一方、Google の Gemini Managed Agents ガイドでは、エージェントインフラをサンドボックス化、永続性、マウント機能を備えた管理型ハルネスへの単一 API 呼び出しとして位置づけている。また、LangChain の更新された create_agent ドキュメントや dair.ai の「harness」論文要約も、同じスタックを形式化したものであり、コンテキストガバナンス、信頼性の高いメモリ、動的スキルルーティングを特徴としている。

ベンチマークは実際の開発者体験に近づいています：エージェント型コーディングのための新しいベンチマークとして導入された DeepSWE は、実務家から強い支持を得ました。@theo 氏はこれを「これらのモデルでコードを書く際の感覚と実際に整合する最初のコードベンチ」と呼びました。また、これは公開されている SWE リーダーボードが示すものよりも上位層での明確な差を生み出しました。関連するベンチマークの兆候として、Qwen3.7 Max は Code Arena: Frontend で #4 にデビューし、エージェント型 Web 開発タスクにおいて Claude Opus 4.6 とほぼ同等のパフォーマンスを示し、アリババはこの結果を強調しました。ツールリングスタック全体では、Anthropic が Claude Code のためのセキュリティガイダンスプラグインをリリースし、社内利用においてセキュリティ関連の PR コメントが 30〜40% 減少したと報告しました。一方、OpenAI は Databricks で Codex における GPT-5.5 を紹介し、より信頼性の高いドキュメント解析が可能になったことを強調しました。

研究エージェント、長期推論、およびコンテキスト圧縮のための「スリープ」

数学・科学エージェントは、適切なハネス（枠組み）が与えられれば、能力の過剰（オーバーハング）を示すより多くの証拠を呈しました。最も強いツイート群は、古い未解決問題に取り組むモデルを中心に展開されました。ある数学者は、Claude Mythos がエルデシュ問題#90を解決したと報告し、その続報として、このモデルが OpenAI の以前の経路とは異なる、よりクリーンな証明経路に収束することが多いという詳細を付け加えました。これは @_sholtodouglas 氏や @kimmonismus 氏によって支持され、さらに Sébastien Bubeck 氏によって鋭く補足されました：適切なハネスがあれば、Mythos と GPT-5.5 の両方が、内部モデルがワンショットで実行したことを再現できるという点です。これは、バニラなチャット UX（ユーザーエクスペリエンス）では露呈していない膨大な潜在能力の存在を暗示しています。

長期にわたる記憶は、中核的なボトルネックとして再び浮上しています。「言語モデルには睡眠が必要」という論文が注目を集めました。そのメカニズムは、直近のコンテキスト（文脈）を永続的な高速重み（ファストウェイト）に変換し、KV キャッシュ（キー・バリューキャッシュ）をクリアする前に実行される、睡眠のような統合フェーズです。これにより計算がオフラインパスに移行しつつも、起動時のレイテンシは維持されます。dair.ai の要約はシステム側の視点を強調しました：これは、長期の軌道を持つエージェントにおける KV キャッシュの無限拡大に対する代替案です。このテーマは、Omar が Anthropic の記憶に関する講演や Dream 機能に言及したように、エージェントにおける記憶システムをめぐる継続的な議論と見事に結びついています。

オープンな深層調査エージェントと科学予測も進展しました。長期的な事実探索、引用根拠の付与、レポート合成を目的としたオープンな 2B〜35B モデル群 QUEST は、汎用的な深層調査エージェントとしてリリースされました。科学評価の側面では、Sakana/Stanford/Oxford/AI2 が共同開発した CUSP ベンチマークにおいて、現在のモデルは有望な研究方向を特定できることが多い一方で、ブレークスルーがいつ実現するかについては依然として大きな課題を抱えていることが示されました。

モデル、オプティマイザ、アーキテクチャの更新

オプティマイザに関する取り組みは活発で、特に Muon 派生型やスケジューリングフリー学習（schedule-free training）を中心に展開されています。AMUSE は「Anytime MUon with Stable gradient Evaluation」を提案し、Muon にスケジューリングフリー型の勾配評価を組み合わせて、学習率減衰（LR decay）なしで安定した任意時点でのトレーニングを実現しました。124M / 720M / 1B の規模および ViT/ImageNet のファインチューニングにおいて性能向上が報告されています。関連する実装の議論としては、ClashLuke による SFMuon スニペットや、kellerjordan による Newton-Muon を採用した Modded-NanoGPT の結果があります。

スパースアテンション（sparse attention）の設計空間はさらに多様化しています。MiniMax は M3 をオープンソースとして公開する予告を行い、続報となる技術解説では新しいブロックスパースな 2 段階アテンションパスが示唆されました。@kimmonismus が報告された速度向上を要約すると、1M トークンにおいて M2 と比較してプレフィリング（prefilling）で 9.7 倍、デコーディング（decoding）で 15.6 倍の高速化です。@eliebakouch は、M3 が DeepSeek の圧縮アテンション派生型とは異なり、実 KV（Key-Value）上でブロック選択を行う GQA ベースのスパースアテンションへと回帰しているように見えると付け加えました。

ビジョン/オープンモデルのリリースとランキング更新：PrismML は Bonsai Image 4B をリリースし、1 ビットおよび 3 値（ternary）バリアントを含み、これらはラップトップやスマートフォンでローカル実行を意図しています。続報では、ブラウザでのローカル実行が約 3GB のフットプリントで可能であることが示されました。クローズドモデル側では、Microsoft の MAI-Image-2.5 が Image Arena で #3 にデビューし、これまで OpenAI と Google が支配していたトップ 5 クラブを破り、Arena によるスコアは 1,254 点となりました。一方、Artificial Analysis によると、Gemini 3.5 Flash は最大で約 280 トークン/秒の出力速度と、著しく優れたエージェント性能を示しましたが、そのコストは Gemini 3 Flash の約 5 倍でした。

インフラ、システム、および半導体スタック

Huawei の「τ スケーリング」論文は、新しい物理法則ではなく、主にエンジニアリングのロードマップとして読まれました。ある非常に詳細なスレッドでは、Huawei の「多層電子システムのための時間定数スケーリング理論」は戦略的白書またはマニフェストとして解釈されるべきだと論じました。その中核的な提案は、プロセスノードではなく、時間定数τをデバイス、チップ、データセンターの各スケールにわたる統合指標として扱うことです。

最も具体的な主張は、将来のキリン（Kirin）設計における「ロジックフォールディング」に関するもので、固定されたノード条件下で密度が+55%向上し、エネルギー効率が+41%改善され、周波数が+13%上昇するとされています。また、ユニファイドバスや Hi-ONE 光学 I/O といったパッケージングやネットワークに関するアイデアも含まれています。

同じスレッドでは、検証に必要な資料（ダイの写真、走査型電子顕微鏡画像、ワークロードの詳細、歩留まり曲線など）が欠落している点に注意を促し、最も目を引く数値は有望であるものの未検証であると解釈するよう慎重に記述していました。

続報の反応でも、Huawei のアプローチはリソグラフィ技術での追従よりも、パッケージングやアーキテクチャへの依存度が高い可能性が強調されました。例えば、@josiah_leee はジェンセン・フアン氏の指摘を引用し、Hopper から Blackwell への性能向上の大部分はノード以外の最適化によるものだったと述べています。

データセンターの電力供給と推論処理能力の制約が、最優先課題となりつつあります。SemiAnalysis は 800VDC への移行について発表し、ジョン・カーマックもこれを推奨しました。これは電気自動車（EV）のパワーエレクトロニクスからデータセンター設計への技術的転用を示しており、高電圧 SiC パーツの採用などが含まれます。一方、Epoch AI は推論計算資源の逼迫の可能性を試算しています。需要がサービス提供能力よりも急速に成長しているように見え、特に長文コンテキストを扱うワークロードで顕著です。彼らの簡易モデルによると、現在のグローバルな Blackwell 供給量は有利な仮定の下では今日の需要に応えられる可能性がありますが、スループットは長いコンテキストにおいて急激に低下し、需要の増加がすでに供給を上回っている可能性があります。

生産ツールと開発者インフラ

サービス提供・推論スタックにおいて、有意義なパフォーマンス向上と観測性（observability）の更新が行われました。vLLM は Rust 製のフロントエンドをマージし、Python API サーバーに代わるドロップイン代替手段として提供しています。初期の数値では、前処理が重いワークロードにおいて単一プロセスで約 837 req/s の性能を示し、従来の約 162 req/s を上回りました。W&B は MCP サーバーをリリースし、コーディングエージェントが実験やトレーニング実行を検査できるようにしました。これは文脈ウィンドウの爆発（context-window blowups）を防ぐことを目的とした、スキーマファーストな再設計です。Unsloth では、ローカル UI 内で GPT や Claude、その他の API を実行するサポートを追加し、プロンプトキャッシュやコード実行機能も利用可能になりました。

Cloudflare、OpenRouter、およびベクトル/検索ベンダーが「実装化」層を推進しました。OpenRouter は 1.13 ドルのシリーズ B ラウンドでの資金調達を発表し、6 ヶ月間で週間の処理量が 5 トリリオントークンから 25 トリリオントークンに増加したと述べています。Cloudflare は最大 350,000 ドル相当のクレジットを提供するスタートアッププログラムを再始動しました。一方、Think やエージェントの使いやすさに関する別々の投稿では、持続可能なターン（対話）、再接続、 stale-state（状態が古くなったもの）の処理、回復が、実用的な差別化要因として強調されました。検索インフラについては、Booking.com が 1 億以上の埋め込みベクトルへのスケーリングについて議論し、フィルタ付きベクトル検索、書き込み中の読み取り、並行処理、パートナー向けメッセージングエージェントのための人間を介した評価（human-in-the-loop evals）が含まれています。

エンゲージメント数上位のツイート

Codex / エージェント型コーディングの実践：最も示唆に富んだプロダクト利用のツイートは、@bunkaich が Codex を活用して安価な MP3 プレイヤーのファームウェアをリバースエンジニアリングしパッチを当てる様子を示したものでした。このワークフローにはチップの検査、OS の抽出、バイナリ解析、修正されたイメージへのフラッシュが含まれます。

DeepSWE ベンチマークの発表：@serenaa_ge による DeepSWE の発表は、「これが実際のコーディング体験と一致するか？」という議論における主要な参照点となりました。

Claude Code セキュリティプラグイン：@ClaudeDevs のリリースが際立ったのは、具体的なプロダクトの発売と内部指標（セキュリティ関連の PR コメントが 30〜40% 減少）を組み合わせた点です。

OpenRouter の資金調達と生産トークンの成長：@OpenRouter の 1.13 ドルのシリーズ B は、ルーティングやマルチモデルインフラがもはや持続可能なプラットフォーム層として認識されていることを示す明確な市場シグナルの一つです。

vLLM Rust フロントエンド：@vllm_project のマージ発表は、高スループット推論における CPU や API サーバーのボトルネックに直面している人々にとって重要な意味を持ちました。

AI Reddit リキャップ

/r/LocalLlama + /r/localLLM リキャップ

1. Qwen 3.7 のローンチと Qwen 3.6 のローカルパフォーマンス

Qwen 3.7 のオープンウェイト版を待っている… 新しい王様が到着した…（アクティビティ：1217）：この画像は、Qwen3.7-Max をエージェント型コーディング、ソフトウェアエンジニアリング、MCP/ツール使用、推論、知識評価の各分野において Qwen3.6-Plus、DS-V4-Pro Max、GLM-5.1、Kimi K2.6、Claude Opus-4.6 Max に対して先端的なモデルとして位置づける Qwen3.7 ブログからのベンチマーク/マーケティング比較です。技術的な意義は、このスライドが Qwen3.7-Max を多くのベンチマークにおいて Claude クラスのモデルと互角以上であると枠組み化している点ですが、ClawEval や CoWorkBench などの一部のタスクでは Claude Opus-4.6 Max が依然としてリードしているように見えます。コメント投稿者らは、これは Max モデルであり、必ずしも小型版やオープンウェイト版を代表するものではないと指摘し、Strix Halo などのローカルハードウェア向けに 512k コンテキストを持つ 3.7-122B-A17B MXFP4 モデルの存在を推測しています。主な議論はオープンウェイトに対する懐疑論です：投稿者らは Qwen が歴史的に Max シリーズをオープンウェイト化していないため、タイトルにある「オープンウェイト版を待っている」という枠組みは非現実的であると指摘します。また、仮説上の 27B モデルが示された Max タイアのベンチマーク結果に匹敵するものになると期待すべきではないという警告もあります。

複数のコメント投稿者が、Qwen Max をおそらく公開重み付け（open-weight）されるリリースと区別しており、「Qwen は Max シリーズを一度も公開重み付けしたことはない」と指摘し、27B 規模の小型バリアントが Max レベルのベンチマーク性能に匹敵するのを期待しないよう警告しています。暗黙的な技術的教訓は、公開または公開重み付けされた Qwen 3.7 のリリースでは、ベンチマーク対象となったフラッグシップモデルとは異なるアーキテクチャやスケールが採用される可能性があるということです。

一つの技術的な要望リストには、512k コンテキストを持つ仮説上の Qwen 3.7 122B-A17B MTP MXFP4 モデルが含まれており、コメント投稿者たちはこれが Strix Halo クラスのローカルハードウェアに非常に適していると主張しています。別のユーザーは Qwen 3.5 397B-A17B NVFP4 に言及し、これは 4 枚の RTX 6000 Pro GPU で動作可能であり、約 10 の並行する 200k トークンセッションに十分なメモリ余裕があるため、Qwen 3.7 が報告されたベンチマークに合致すれば「自宅用 Opus」として位置づけられると述べています。

あるコメント投稿者は、高度な能力を持つローカルモデルがプロバイダーの収益化を損なう可能性があるため、公開重み付けされたフロンティアリリースはより起こりにくい可能性があると主張しています。彼らは Qwen の戦略が破壊から収益化されたフロンティア競争へと移行したと指摘し、これが 397B-A17B のような大規模 MoE モデルが公開されるかどうかに影響を与える可能性があるとしています。

Qwen3.6 35Ba3 は私のワークフロー、さらにはコンピュータの使い方も変えてしまいました（アクティビティ：567）：この投稿は、pi を介して Qwen3.6 35B a3 を使用したローカル・エージェント・ワークフローについて述べています。ユーザーは反復可能な手順を Codex によって生成/文書化された「スキル」に変換し、VPS DevOps、docling PDF→EPUB 変換、Playwright テスト、コードチケット、OS レベルのシェルタスクなどで再利用しています。具体的な例としては、WhatsApp の音声 → AnythingLLM での文字起こし → content.md → ローカル生成されたランディングページ、そして「マネージャー」pi プロセスが pi -p @plan.md "Check the first Ticket with Status UNDONE and do it" を実行して新鮮なコンテキストを持つサブエージェントを起動し、チケットを DONE にマークし、git でコミットし、最後に VPS スキルを通じてデプロイするという一連の流れがあります。コメント欄では、このセットアップを実行できるハードウェア、OS アクセスにおいてエージェントがサンドボックス化されているか信頼性があるか、そして Hermes などの他のエージェントツールと比較して pi の導入がどれほど難しいかといった運用上の懸念に焦点が当てられています。

あるユーザーは、MS-02 で Unsloth Studio を経由して unsloth/Qwen3.6-35B-A3B-MTP-GGUF を実行しており、24GB の RTX Pro 4000 Blackwell SFF GPU を搭載した環境で、一貫して 100 トークン/秒を超えるパフォーマンスを達成していると報告しています。彼はこのパフォーマンスを、Mac Studio M2 で動作する「最適化されていない GGUF」と比較し、MS-02 を Mac ワークステーション用の小型リモート GPU サーバーとして利用している点を指摘しています。また、Unsloth における将来の MLX サポートが Mac 側のパフォーマンス向上につながる可能性にも言及しています。スクリーンショット：preview.redd.it

Qwen3.6 35B A3B および ik_llama.cpp における 12GB VRAM で 110 tok/s（アクティビティ：565）: この投稿は、RTX 4070 Super 12GB と Ryzen 7 9700X を用いた環境で、byteshape の IQ4_XS 4.19 bpw GGUF 形式を採用した Qwen3.6-35B-A3B MTP（Multi-Token Prediction）のベンチマーク結果を報告しています。比較対象は、--ctx-size 131072、q8_0 KV キャッシュ、MTP ドラフト最大値 3、p_min=0.75 の設定で動作する標準 llama.cpp と ik_llama.cpp です。同じ mtp-bench.py ワークロードを使用した場合、標準 llama.cpp は平均 89.76 tok/s で集計 MTP 受容率が 0.9393 でしたが、ik_llama.cpp は 16.64 秒間で平均 110.24 tok/s を達成し、更新された結果では集計受容率が 0.8749 とやや低下したものの、スループットで約 23% の向上が報告されています。投稿者は、ik_llama.cpp における --fit/--fit-margin 1664 の設定が実用的な適合性をもたらすと説明し、--fit-margin を 1792 または 2048 に引き上げることで OOM（Out Of Memory）対策が可能であると指摘しています。また、ディスプレイを iGPU で実行することで、推論にほぼ全 12GB の VRAM を割り当てられることも注記されています。コメント欄では再現性に関する議論が中心で、標準 llama.cpp の完全なコマンドライン引数の開示や、最近 MTP 関連の PR がマージされたためベンチマークのタイミングはビルド日付に強く依存する可能性があることが指摘されました。単一 GPU を使用する CachyOS/KDE ユーザー向けの技術的回避策として、LIBGL_ALWAYS_SOFTWARE=1 および GALLIUM_DRIVER=llvmpipe を設定したソフトウェアレンダリングによる Plasma Wayland セッションが提案されており、これによりアイドル時の VRAM 使用量が約 1024MB から 126MB に削減されますが、その代償としてコンポジターエフェクトが遅延または無効化されることになります。

CachyOS/KDE Wayland ユーザーは、シングル GPU システム向けの VRAM 節約ワークアラウンドを説明しました。具体的には、LIBGL_ALWAYS_SOFTWARE=1、GALLIUM_DRIVER=llvmpipe、KWIN_COMPOSE=Q を設定してカスタム SDDM セッションを作成し、KDE Plasma が CPU 経由でレンダリングするように強制するものです。この方法により、KDE Wayland のアイドル時の VRAM 使用量が 1024 MB から約 126 MB に低下し、35B モデルの実行のためにほぼ 1 GB の VRAM を確保できる一方、コンポジットアニメーションが無効化されるか非常に低速になるという代償があります。

複数のコメント投稿者は、報告された 110 tok/s という速度が、ik_llama.cpp がアップストリームの llama.cpp よりも優れた MTP（Multi-Token Prediction）や推測デコーディングの挙動を示していることによるものかどうかについて焦点を当てていました。ある投稿者は、ik_llama.cpp の採用率が報告上 0.790 を下回ることは決してなく、一方 llama.cpp は最低 0.477 まで低下したと指摘し、正確な llama.cpp コマンドや設定を求めるとともに、直近の 24 時間以内に llama.cpp に複数の MTP 関連の PR（Pull Request）がマージされたことを注記しました。

ある投稿者は、Qwen3.6 35B A3B で使用されている IQ4_XS 量子化について質問し、これが最もメモリ効率の良い Q4 量子化のように見えると指摘するとともに、モデルの品質・知能への影響と、最終的な VRAM/RAM の分割比率の詳細を求めていました。これは、12 GB VRAM 環境における重要なトレードオフを浮き彫りにしています。すなわち、積極的な量子化によってモデルを収容することと、推論の質を維持し、過度な CPU/RAM オフロードによるボトルネックを回避することとの間の選択です。

さらに詳しく読む