OpenAI Jalapeño が Blackwell 比でワットあたり 1.5〜1.9倍・低レイテンシ 1.7〜3.6倍を InferenceX で実測、Qwen 3.8-Flash-Next 125B a6B が明日リリース、MXFP4 60B が 120B bf16 を 7/9 ベンチマークで上回るほか6件

今日の3行

• OpenAI が Broadcom と開発した汎用推論チップ Jalapeño が InferenceX で Nvidia Blackwell/AMD/Google を上回る電力効率とレイテンシを実測しました。ワットあたりスループットは 1.5〜1.9倍、低レイテンシは 1.7〜3.6倍で、HBM4 を搭載し空白から 16 か月でテープアウトした汎用設計です。
• Alibaba の Qwen 3.8-Flash-Next（125B パラメータ中 6B 活性の MoE）が明日リリースされます。ModelScope で公開され、オープンウェイトの最前線が翌日に更新されます。
• Multiverse Computing の Quantization-Aware Healing で、GPT-OSS 120B を 60B に圧縮して MXFP4 に量子化した 4-bit モデルが元の 120B bf16 を 9 ベンチマーク中 7 件で上回りました。圧縮して小さくしても精度が上がる逆転はデプロイコストを根本から変えます。

1. OpenAIの汎用推論チップJalapeñoがNvidia Blackwell / AMD / Googleを上回る性能をInferenceXで実測

要点 OpenAIがBroadcomと共同開発した汎用推論チップ「Jalapeño」がHot Chipsで発表されました。空白の状態からLLM inference専用に設計され、2024年半ばに設計を開始して約16か月でtape-outした、極めて高速なASIC開発サイクルです。SemiAnalysisがOpenAIのラボに招かれてInferenceXでベンチマークを検証しています。初代チップは通常競争力を持たないとされる中で、Jalapeñoは複数のトップオープンソースモデルでNvidia、AMD、Googleの全チップを上回り、extremeなhardware software codesignによる汎用チップとして特定ワークロードへの過度な特化ではなく全シナリオで高い性能を発揮します。AIによるチップ設計加速が現実であることも示しています。HBM4を採用し、スペック上はNvidiaやAMDのフラッグシップGPUに匹敵します。メディアではOpenAIモデル専用に最適化されたという報道もありますが、Jalapeñoは汎用推論チップで全モデル・全ワークロードを動作させ、ベンチマークでも汎用性を検証しています。参考としてDoomがCodexのプロンプトだけで移植され動作することも披露されました。性能面ではSingle Token Prediction（STP）のみで、他社がMulti Token Prediction（MTP）ありの最良構成で計測した結果との比較でも、トークン throughput per MW（All-in utility MWあたり）で全チップを上回ります。低レイテンシから高スループットまで曲線上のほぼ全点でBlackwellを上回り、STP同士の比較ではさらに差が開きます。低concurrencyではDeepSeek R1でconcurrency 1あたり700 tokens/sec/user超を記録し、Kimi-K2.5とGPT-OSSでは約1,400 tok/sec/userで動作しました。いずれのモデルでもGSM8kの評価はNvidiaチップと同等です。これらはprefill-decode disaggregationやspeculative decodingなしでの結果です。ただし留意点があります。数値はOpenAI提供で、SemiAnalysisはラボでInferenceXの実行を立ち会い検証したものの全スイートの実行やAgentXの結果は未確認です。AgentXは長コンテキスト・多ターンという本番のキャッシュ挙動を反映するため、8k1kの単発ベンチマークで優れても本番負荷では異なる結果になる可能性があります。またBlackwellとの比較は時期的に不公平で、HBM4を採用する点で競合はVera Rubinがより適切です。Vera Rubin NVL72はGB200 NVL72比で5.4倍のperf/MW（NvidiaとCoreWeaveが7月に公表したMTP結果）とされていますが、JalapeñoはSTPの出力トークン throughput per MWでそのVera Rubinの7月公表MTP結果を上回り、GB200の2025年MTP結果も大きく上回ります。両者とも初期bring-up段階で今後性能はさらに上がる見込みです。perf/TCOではVera RubinとJalapeñoはほぼ互角で同等のoutput tokens per $ですが、Jalapeñoはspeculative decodingなし、Vera Rubinはspeculative decodingありでの比較です。

なぜ重要か ワットあたりスループットと低レイテンシの改善は推論コストと体感速度を直接変えます。自前ホスティングとAPI利用のどちらに寄せるか、将来の値下げ余地をどう読むかという判断材料になります。

原典 OpenAI Jalapeño: Better than Nvidia Blackwell

2. Alibaba Qwenが125B中6B活性のMoEモデルQwen3.8-Flash-Nextを明日リリース

要点 AlibabaのQwenがMoEモデルQwen3.8-Flash-Nextを明日リリースすると告知しています。125Bパラメータ中6Bだけを活性化する構成（125B a6B）で、ModelScopeで公開される予定です。

なぜ重要か オープンウェイトの最前線が翌日に更新されます。コストとコンテキスト性能の新しい基準になるため、評価用の推論環境を用意しておくと明日から比較検証できます。

原典 Qwen 3.8-Flash-Next releasing tomorrow (125B a6B)

3. Quantization-Aware Healingで60B MXFP4モデルがbfloat16版を7/9ベンチマークで上回る

要点 論文「Quantization-Aware Healing: A Practical Recipe for Recovering Compressed, 4-Bit LLMs」は、構造圧縮を経たモデルで回復がどの程度機能し、どうするのが正しいかを問うています。定番の効率化パイプラインは、アーキテクチャを圧縮してlayersやheads、neuronsを削除してパラメータ数を削減し、残った重みを4-bitに量子化してからhealingで回復させる流れです。両者を併用するとreasoningや数学的問題解決、コード生成が体系的に劣化するため、本番投入前にhealingが加えられます。gpt-ossやNVIDIAのNemotronファミリー、Hypernova 60Bなどの近年のopen-weightリリースもcompress-then-healを採用しています。従来のhealingはquantization-aware training（QAT）が主流で、forward passにfake-quantization演算子を挿入してtask lossでfine-tuningし、重みに低精度を耐えさせる方法です。実際にはsupervised fine-tuningやRLHF、agentic tuningといった多段階のpost-trainingをノイジーな低精度forwardで再実行するためコストが高く、最適点を超えて学習を続けると不安定になります。もう一つの手法であるquantization-aware distillation（QAD）は、凍結したfull-precision teacherから出力logitsのKL divergenceで直接distillするため履歴の再実行を避けられますが、量子化だけなら同一モデルのfull-precision版がteacherとして存在するため有効でも、構造圧縮後は成り立ちません。layersやheads、neuronsが減った小さいアーキテクチャの独立したfull-precision版は存在せず、候補となるのは回復済みのbfloat16チェックポイントだけであり、それ自体が元モデルのdistilled approximationのため、そこからdistillすると劣化したターゲットに固定され精度の上限が抑えられます。Quantization-Aware Healing（QAH）はこの上限を一つの変更で外します。回復済みチェックポイントではなく、圧縮前の元モデルをfrozen teacherとして直接distillします。teacherはfull-sizeかつfull-precision、studentは半分のサイズでMXFP4で動作し、architectureを共有しません。teacherの出力分布はarchitectureに依存しないためサイズや形状の不一致は転移を妨げず、studentはhard labelを一切見ず、logitsの出力分布をKL divergenceで合わせるだけです。これにより量子化はheal後の損失的後処理ではなく、元teacherに対する二度目のdistillationとして再定義され、bfloat16チェックポイントが時間やデータ不足で転移しきれなかった情報を拾います。KL distillationは固定されたteacher分布にstudentを紐づけるため、一度追いつけばdriftする圧力がなく安定します。cross-entropyのtask lossはhard labelに向けて押し続けるのに対し、KLではそうなりません。長文脈対応ではhealingコーパスに最大32kトークンの文書が含まれるため、系列をスライスごとにKLを計算し語彙×系列全体のグリッドをmaterializeしない、memory-efficientなchunked KL-divergence lossを再利用し、固定GPUメモリで32kトークンのhealingを可能にしています。QAHの概要は、構造圧縮と量子化で能力が急落した後、回復済みチェックポイントではなく元モデルからlogitsをオフラインで事前計算したfrozen teacherでdistillする構成です。結果として、GPT-OSS 120Bを60Bに圧縮してbfloat16で回復させたうえでMXFP4にQAHで再量子化したモデルは、同じ60Bのbfloat16チェックポイント（このアーキテクチャで存在する最良のfull-precision版）との比較で9ベンチマーク中7件で上回りました。小さく、実行コストも低く、かつ量子化元より正確という、通常の4-bitモデルと16-bitモデルの関係を逆転させています。内訳はAA-LCR（long-context reasoning）が35.3から42.7（+7.4）、AIME 2025（math）が70.7から76.3（+5.6）、Aider（agentic coding）が38.2から40.9（+2.7）、τ²-bench（tool use）が59.4から61.7（+2.3）、GPQA Diamond（science）が65.7から67.4（+1.7）、IFBench（instruction following）が58.4から59.9（+1.5）、LiveCodeBench（coding）が65.5から66.5（+1.0）で上回り、MMLU-Pro（knowledge）は74.0から73.8（−0.2）、SciCode（science coding）は35.6から34.2（−1.4）と1.5ポイント未満の差で下回りました。最も大きな改善は圧縮で最も損なわれやすいlong-context reasoningとmathに現れています。元の120B teacherとの比較でも、パラメータ数は半分、weightメモリは約4分の1ながら、LiveCodeBenchでは66.0に対し66.5で上回り、GPQA Diamondでは69.0に対し67.4と1.6ポイント差まで接近しました。teacherとの差が最も残るのはAA-LCRで、圧縮で失われた容量の回復が本質的に最も難しい極端な長文脈ベンチマークです。QATとの直接比較では、GPT-OSS 9BをMXFP4に量子化しMMLU-Pro、LiveCodeBench、GPQA Diamondの平均で学習推移を追跡すると、ピークはQAH 54.9、QAT 54.6でほぼ同等ですが、QAHは約100ステップでピークに到達しQATの700ステップより約7倍速く、その後もピークから約2ポイント以内で安定するのに対し、QATは崩れるとしています。

なぜ重要か 圧縮して小さくしても精度が上がるという逆転はデプロイコストを根本から変えます。GPT-OSS 120B→60Bの事例は自分のモデルでも「圧縮→QAH」のパイプラインを試す根拠になります。

原典 Quantization-Aware Healing: a compressed, 4-bit model that outperforms its full-precision original

4. IBM Granite 4.2が3B/8B/30Bの推論特化ファミリをApache 2.0で公開、15Tトークン事前学習と512Kコンテキスト対応

要点 IBM Granite TeamがGranite 4.2ファミリを公開しました。初のdense, decoder-onlyな推論特化モデルで、3B/8B/30Bの3サイズを展開し、すべてApache 2.0ライセンスで提供されます。事前学習はスクラッチから約15Tトークンで、5段階の戦略で進められ、第5フェーズでコンテキストウィンドウを512Kトークンまで拡張します。事前学習後はchain-of-thoughtやreasoning、agentic-trajectoryデータでsupervised fine-tuningを行い、その後multi-stageの強化学習パイプラインでpost-trainingします。8Bと30Bはreal sandboxed environments内でtoolを使って行動することを学ぶagentic RLブロックを追加で経ます。すべてのモデルはthinking / non-thinkingの切り替えを持ち、easyな質問に少ないreasoning budgetを使うlow-effort thinkingモードとnative tool callingを備えています。従来のGraniteがstrong instruction-followingなアシスタントだったのに対し、Granite 4.2はexplicitなreasoningを追加したリリースです。3サイズは同じarchitectural designと同じtraining pipeline（pre-training from scratch、SFT、multi-stage RL）を各スケールで共有しますが、post-trainingで能力差が最も明確に現れます。8Bと30Bのagentic RLではtool呼び出し、コードの編集と実行、terminal操作、web検索をreal environments内で学習します。native tool callingはOpenAI-compatibleなエンドポイント（vLLMなど）でOpenAI function-calling形式で出力され、agentic harnessにそのまま接続できます。

なぜ重要か 商用利用可能なオープンモデルで、思考モード切替とネイティブtool calling、8B/30BのAgentic RLまで揃っています。ローカルや自前環境で推論・エージェントを試す選択肢が増えます。

原典 Granite 4.2 LLMs: How They’re Built

5. ChatGPT WorkとCodex向けAdmin pluginが登場、利用状況分析からメンバー管理や権限・上限調整までを会話で完結

要点 OpenAIがChatGPT WorkとCodex向けのAdmin pluginを公開しました。ワークスペースの情報を分析し、設定を更新し、リクエストに対応する作業を、複雑なプロンプトやツール切替なしに一つの会話で完結できます。会話の中で質問し、詳細を掘り下げ、権限があれば変更を実行し、結果を確認する流れで、analyticsやsettings、reportsを行き来する定常的な管理を一体化し、成長するワークスペースをsecureでproductive、予算内に収まる状態に保つことを支援します。会話から実行できる具体的なタスクは、adoptionとusageの把握（ChatGPT WorkとCodex横断のactivityやcredit usageの確認、enablementが必要な箇所やcredit上限に近づくメンバー・グループの特定）、membersとgroupsの管理（メンバーの追加・削除、グループ更新、onboarding/offboardingやチーム変更）、accessとpermissionsの管理（effective permissionsの確認、access issueの診断、roleやgroup単位でのfeatureやmodelアクセス制御）、usage limitsとspending requestsの管理（メンバー／グループ／ワークスペース単位の上限調整、現行usageとの突合でのリクエスト確認、context付きでの承認・拒否）が挙げられています。定型ワークフローはカスタム開発なしで自動化でき、手動モニタリングを減らしてポリシーを一貫して適用できます。例として、保留中のusage requestをSlackやMicrosoft Teamsへルーティングして承認・拒否を既存ツール内で完結させることや、feature access requestを事前定義の基準で自動付与し例外のみをレビューへ回すことが紹介されています。Admin pluginはユーザーの既存roleとpermissionsの範囲内で動作し、より広いアクセスを付与しません。指示を適切なread/write actionにマッピングして構造化された結果を返し、Admin Consoleの機能をpermission-awareなツールとして提供し、ワークスペースのポリシーや承認要件を尊重します。変更ごとに何をリクエストし完了したか何が変わったかを確認でき、影響の大きい操作は適用前にレビューできます。導入はChatGPTのworkspace settingsでpluginを有効化し、ChatGPT Work（webまたはdesktop app）のPlugins directoryからインストールする手順です。OpenAIのITチームの活用例では、Slack上のChatGPT Workエージェントが従業員からのITリクエストやサポートチケットのトリアージと対応、context取得、ポリシー照合、対応可能なタスクの実行、例外のエスカレーションを担い、報告時点でデプロイ済みワークフローがチケット量の約45%を解決し、サポートチケットのデータと履歴を運用健全性のダッシュボード化して可視化し、バックログ解消や需要予測に基づく優先度付けに活かし、サポート量が約2倍になる中でも先回りした運用に切り替えたことが紹介されています。

なぜ重要か ワークスペースの権限やクレジット上限の申請・承認をSlackやMicrosoft Teams連携で自動化できます。分散したanalyticsとsettingsの行き来を会話に集約することで、成長するワークスペースでも管理の一貫性と予算統制を保てます。チームでCodexを使う個人開発や小規模組織の運用工数を直接削れる点で、明日の運用判断に直結します。

実践で使える点 チームでCodexやChatGPT Workを使う個人開発や小規模組織は、まずworkspace settingsでAdmin pluginを有効化し、ChatGPT WorkのPlugins directoryからインストールして、activityやcredit usageの把握とメンバー・グループ管理を会話で試せます。定常的なusage requestやfeature access requestはSlackやMicrosoft Teamsへのルーティングと自動付与ルールを設定し、例外のみをレビューする運用に切り替えると、手動モニタリングを減らしながら権限とポリシーに沿った運用を続けられます。

原典 Introducing the Admin plugin for ChatGPT Work and Codex

6. OpenAIがChatGPT PlusのCodexとChatGPT Workで5時間制限を復活、8月25日から週次上限と併用

要点 OpenAIは数週間にわたり週次上限のみとしてきた運用から、ChatGPT Plus向けのCodexとChatGPT Workで5時間制限を復活すると発表しました。発表はCodexとChatGPT Workのengineering leadであるThibault “Tibo” Sottiaux氏が行い、8月25日から適用されます。5時間または週次のいずれかの上限に達した後は、次のサイクルのリセットを待つか追加クレジットを購入できます。OpenAIは時折無料でリセットすることもあります。banked resetsは特定のプロモーションや紹介オファーで獲得できます。過去数週間は5時間制限が一時的に解除され週次上限のみとなっており、その間は2つのプラットフォーム（現在は統合済み）で100万人のアクティブユーザー増を含むマイルストーンを祝して、週次使用量が前倒しでリセットされることもありました。復活の理由について、Tibo氏はXで (a) 5時間制限によりcomputeの負荷を平準化し週次上限を寛大に保てること、(b) Plusプランのユーザーは比較的カジュアルで新規ユーザーが多く、誤って1週間分の使用量を使い切って混乱する体験を避けるため、と説明しています。今後数か月はPro $100およびPro $200サブスクリプションでは5時間制限は有効化されません。EnterpriseやEduアカウントについては変更は言及されておらず、現在は別のcredit-basedな利用システムを利用しています。

なぜ重要か Plusプランは再び5時間で区切られるため、長時間のエージェント実行やバッチ処理の計画が変わります。Proは当面対象外なのでプラン選択とクレジット購入の判断に直結します。

原典 OpenAI restores 5-hour Codex and Work limits for ChatGPT Plus users

7. Prime Agentが長期エージェント実行向けオープンソースハーネスを公開、永続IPython REPLと再帰サブエージェントでRLM抽象化を実装

要点 Prime Agentはlong-horizonな評価とコーディングエージェントワークフローのためのオープンソースハーネスです。言語モデルはsequential processorsである一方、long-horizon agencyではモデル重みとactive contextを超える外部情報と計算が必要であるという前提に立っています。永続的なIPython REPLがRecursive Language Model（RLM）抽象化に従い、プログラム的なコンテキスト処理とtest-time computeを担います。Continual Harnessがhistories、memories、skills、prompts、subagent specificationsをtrajectories間で保持します。再帰的なサブエージェントは直接的なagent-to-agent communicationで連携します。

なぜ重要か コンテキストをプログラム的に処理し、記憶やスキルを軌跡間で保持できるハーネスは、コーディングエージェントを長時間走らせる際の実装の出発点になります。

原典 Prime Agent: A Self-Improving RLM Harness

8. Andrew NgがDeepLearning.aiをAI Engineering中心に再始動、1万件超の求人分析から導いた4つの必須スキルを提示

要点 Andrew Ng氏（Google BrainとCourseraの共同創業者）がDeepLearning.aiをAI Engineering中心に再始動しました。判断の根拠は10,000件超の求人情報の分析、数十件のAI専門家・採用マネージャー・リクルーターへの構造化インタビュー、サーベイ、その他オンラインデータの合成です。原典で示された最も重要な4つのAI Engineeringスキルは次のとおりです。(1) Building and deploying AI applications — LLMs、context engineering、RAG、agentic workflows、machine learningとdeep learningといった構成要素を理解し、統計的手法で計測・制御・ガバナンスしてAIシステムをより予測可能に振る舞わせること、中でもdisciplined evalsとerror analysis loopsを駆動できることが中核です。(2) Software engineering fundamentals — ソフトウェアの基礎を理解してトレードオフの存在自体を認識し、スタック選定、アーキテクチャ設計、データストア設計、テストなどでより良い意思決定をすること。vibe codingでcoding agentのトレードオフを理解せずにコンテキストを与える場合と比べ、成果に大きく差が出るとしています。(3) Using coding agents — agentic codingを効果的に使うスキルとして、エージェントの仕組みと限界を理解し、介入と放置のバランスを取りつつ素早く誘導して過度な時間やトークン浪費なく堅牢なソフトウェアを構築すること、明確なspecの使いどころ、複数エージェントのオーケストレーション、production databaseを破損させるような落とし穴の回避、急速に進化する最新プラクティスの習得とワークフローの継続的な更新を含むことです。(4) Shaping the build — product senseとビジネス文脈・顧客目標を理解して構築を牽引・推進すること、ユーザー検証のために素早くMVPを作るべき時と、慎重に時間をかけて作るべき時を見極めてプロジェクトを前に進めることを含みます。Latent Spaceの解説では、これらのAI Engineeringスキルは職種名がAI Engineerであるかに限らず広く適用可能で示唆に富む焦点だとしています。

なぜ重要か AIアプリの構築・デプロイと厳密なevalループ、ソフトウェア基礎の重要性は、個人開発の学習優先度を決める直接の指標になります。

原典 [AINews] Andrew Ng gets into AI Engineering

9. Interaction Tax — マルチエージェントの対話が多様性を消し独立サンプリングと同等に留まることを検証

要点 論文「The Interaction Tax: When Communication Erases Diversity in Multi-Agent Teams」は、マルチエージェントLLMのinteractionが有益か有害かを問います。Debate（Du et al., 2024）やcritique loops（Chen et al., 2025）、mixture-of-agents synthesis（Wang et al., 2025）で改善したという報告がある一方、等予算下ではinteractionがコストを上乗せするだけで品質を改善しない（Tran & Kiela, 2026; Xu et al., 2026; Jarrett et al., 2025）、あるいはindependent samplingがすでにマルチエージェントの利得を捉えている（Li et al., 2024）という報告もあります。著者らはこの矛盾はmulti-agent communicationがすべて同等ではないという区別の欠如を一部反映していると主張しています。

なぜ重要か 討論や批判ループを重ねても等予算では上乗せがないケースがあり、エージェントを増やす前に「単独で複数回サンプルする」方が安く速い選択になり得ます。

原典 The Interaction Tax: When Communication Erases Diversity in Multi-Agent Teams