Midnight AI Groove 26-04-28

――――――――――
番組名：Midnight AI Groove
出演：DJレン（男）／DJミオ（女）
――――――――――

DJレン:
こんばんは、Midnight AI Groove。ナビゲーターのDJレンです。

DJミオ:
DJミオです。今夜はAINewsの「not much happened today」回、2026年4月27日から28日分をしっかり読み込んだうえで、静かな日と言いつつ実は論点がかなり多かったAIニュースをまとめていきます。

DJレン:
そう、「今日はあんまり何もなかった」と言いながら、実際には推論基盤、オープンモデル、ローカルLLM、価格問題、ベンチマーク、政策まで一通り動いてる。
しかもAINews側は12個のsubreddit、544のTwitterアカウントをチェックしていて、Discordはその日でアクセス終了。今後は新しいAINewsを出す予定、という締めでした。

DJミオ:
あと運営面では、AINewsはLatent Spaceの一部になったこと、過去号検索ができること、メール頻度の設定もできることが改めて案内されていましたね。

---

1. Twitter総括：vLLM 0.20と推論スタック競争

DJレン:
まずTwitter recapの主役は、やっぱりvLLM 0.20.0。今回かなり明確に、メモリ最適化とMoEサービング効率に寄せた更新でした。

DJミオ:
ポイントを並べると、

• TurboQuant 2-bit KV cacheでKV容量4倍
• FA4がMLA prefill向けにSM90+で再有効化
• 新しいvLLM IR foundation
• fused RMSNormでエンドツーエンド遅延が2.1%改善
• 対応範囲も広くて、DeepSeek V4 MegaMoE on Blackwell
• Jetson Thor
• ROCm
• Intel XPU
• GB200 / Grace-Blackwellのセットアップ簡素化

という感じ。

DJレン:
要するに、単なる「新機能追加」じゃなくて、最新ハードウェア上で巨大MoEをどう回すかという、かなり実運用寄りの進化ですね。

DJミオ:
それと周辺では、SemiAnalysisがDeepSeek V4 Proの初期サービング結果を取り上げていて、B200/B300/H200/GB200の分離構成比較の中で、B300はこのワークロードではH200より最大8倍速い可能性があると紹介していました。

DJレン:
さらに今後のvLLM 0.20ベンチマークでは、DeepGEMM MegaMoEも注目。これは
EP dispatch + EP combine + GEMMs + SwiGLU
を単一の巨大カーネルに融合するという話で、完全にカーネル融合の軍拡競争です。

DJミオ:
この流れ、最近の推論界隈らしいですよね。モデル性能だけでなく、メモリ、ルーティング、KV、カーネル実装、配備の速さまで含めて戦ってる。

---

2. 新モデルへのDay-0対応とサービング論争

DJレン:
vLLMまわりでは、新しいオープンモデルにDay-0対応する速度も話題でした。

DJミオ:
具体的には、

• Poolside Laguna XS.2
• Ling-2.6-flash
• NVIDIA Nemotron 3 Nano Omni

に初日対応。

DJレン:
「いいモデルを出す」だけじゃなくて、出たその日に主要スタックで動くことが、エコシステムの強さになってきてますね。

DJミオ:
一方で、サービングの設計論もいくつか。
Jeremy Howardは、DeepSeek V4がprefillをサポートしている点を評価していて、これは実は多くのプロバイダが捨ててしまった機能だと指摘していました。

DJレン:
そしてMaharshiは、dynamic activation quantizationのオーバーヘッドを問題視。キャリブレーションコストはあっても、推論速度だけ見ればstatic quantizationの方が勝ちやすいと。

DJミオ:
さらにteortaxesTexは、DeepSeekがTileKernelsによってCUDAロックインから構造的に離れつつあると見ていました。
これ、けっこう大きな話で、今後はモデルベンダーがNVIDIA専用ではなく、異種混成や国産アクセラレータ群も想定して最適化していくかもしれない、ということです。

---

3. オープンモデル新作：Poolside、Nemotron、TRELLIS.2

3-1. Poolside Laguna XS.2

DJレン:
次はモデルリリース。まずはPoolside。同社初の公開モデルとしてLaguna XS.2を出しました。

DJミオ:
これがかなり“配備しやすさ”を打ち出していて、

• 33B total / 3B activeのMoEコーディングモデル
• Apache 2.0
• 単一GPUで動作可能
• 自前のデータ、学習インフラ、RL、推論スタックで完全内製で学習

という構成。

DJレン:
加えて、より大きいLaguna M.1やagent harnessも公開。
コミュニティまとめでは、Aymeric Roucherが、実際には

• 225B / 23B active
• 33B / 3B active

の2種類のcoderモデルがあり、hybrid attention、FP8 KV cache、性能はQwen-3.5近辺と説明していました。

DJミオ:
しかもOllamaが即日対応。この“公開→即実行可能”のテンポが今のオープンモデルの強さですね。

3-2. NVIDIA Nemotron 3 Nano Omni

DJレン:
その一方で、インフラ寄りの大型ニュースはNVIDIA Nemotron 3 Nano Omni。

DJミオ:
これは

• open 30B / A3B multimodal MoE
• 256K context
• text / image / video / audio / documents対応
• agentic workload向け

という、かなり“全部入り”な設計です。

DJレン:
配布の広がりがすごくて、OpenRouter、LM Studio、Ollama、Unsloth、fal、Fireworks、DeepInfra、Together、Baseten、Canonicalなどが同日対応。

DJミオ:
詳細では、Piotr Żelaskoが、これをNVIDIA初のomniリリースとして紹介。
音声理解にはParakeet encoderが使われていて、現時点では英語のみ。
さらに**Open ASR leaderboardでWER 5.95%**という数字も出ていました。

DJレン:
ホスティング各社が挙げていた数字としては、類似のオープンomniモデル比で約9倍のスループット。
もしこれが実運用でも安定するなら、かなりインフラ寄りに強いモデルです。

3-3. TRELLIS.2 と World-R1

DJミオ:
その他では、MicrosoftのTRELLIS.2。
これは4Bのimage-to-3Dモデルで、最大1536³のPBR textured assetsを生成できる、オープンソースのモデルです。

DJレン:
ベースはnative 3D VAEで、16倍の空間圧縮。
3D資産生成の効率と品質を両立させようとしている点が強調されていました。

DJミオ:
そして世界モデル系ではWorld-R1。
主張はかなり面白くて、**既存の動画モデルはすでに3D構造を内部表現として持っていて、RLで“目覚めさせればよい”**と。
しかも

• アーキテクチャ変更なし
• 追加の動画学習データなし
• 追加推論コストなし

とされています。

---

4. Agents：デモから実運用へ

DJレン:
次はエージェント。ここはかなり“現場化”が進んでいました。

DJミオ:
まずMistralがWorkflowsをpublic previewで発表。
企業向けAIプロセスを、durableで、観測可能で、fault-tolerantな本番システムに変えるためのオーケストレーション層ですね。

DJレン:
関連発言として、Sydney Runkleは長時間動くエージェントにはdurable executionが必須とコメント。
threepointoneも、subagents / agents-as-tools、さらに永続化、ストリーミング、再開に取り組んでいると話していました。

DJミオ:
つまり話題の中心が、派手なデモから運用の継続性や再実行性に移ってきたわけです。

4-1. ローカル／オフラインエージェント

DJレン:
一方でローカル志向も強い。
Tekniumは「完全オフラインのエージェントは可能」と主張。
Niels RoggeはRaspberry Pi + ローカルモデルでデスクトップ整理をデモしていました。

DJミオ:
Google Gemmaもローカルコーディングエージェントのチュートリアルを公開。
さらにHugging Faceまわりでは、Clement Delangueが、30万人のユーザーがHubにハードウェア情報を登録して、ローカルで何が動くか見つけやすくしていると話していました。

DJレン:
実例としては、AmmaarがGemma 4をMLXで完全オンデバイス実行するvibe-codingアプリをオープンソース化。
Kimmonismusは、オープンモデルを使う**プライベートなブラウザ内ローカルエージェント構想「Sigma」**を紹介していました。

4-2. Hermes と研究エージェント

DJミオ:
Hermes周辺も勢いがありましたね。
複数の投稿で、instruction-followingや実務ワークフローでOpenClawより良いという報告が出ていました。

DJレン:
名前が挙がっていたのはSecretArjun、somewheresyあたり。
Telegramで使ったり、医学文献抽出に使ったりと、かなり現場感のある使われ方です。

DJミオ:
研究エージェント側では、Hugging FaceのML InternがSpaces内でトレンドに。
その後、native metric loggingとTrackio integrationが追加されて、学習ジョブがブラックボックスでなく観測可能になった、というのも重要でした。

---

5. ベンチマーク、評価、研究メモ

5-1. GPT-5.5 Pro、ARC-AGI-3、現実寄り評価

DJレン:
評価系では、まずEpochがGPT-5.5 Proに関する強い数字を出していました。

DJミオ:
具体的には、

• Epoch Capabilities Indexで159
• FrontierMath
  • Tier 1–3で52%
  • Tier 4で40%
• しかもTier 4の問題を2問、これまでどのモデルも解けていなかったのに解いた

という内容です。

DJレン:
さらにGreg Kamradtは、GPT-5.5とOpus 4.7のARC-AGI-3テストが完了し、今は失敗モードを分析中とコメントしていました。

DJミオ:
ベンチマークの種類も変わってきていて、
LysandreはTransformersをagent-friendlyにするためのベンチマークを発表。
VibeBenchは、1000人の有資格ソフトウェアエンジニアによる主観評価で、「実務でどう感じるか」を測ろうとしている。

DJレン:
文書理解ではLlamaIndex ParseBenchが、OCRベンチだけでは足りないと主張。
取り消し線や上付き文字みたいな意味に直結するフォーマットを見ないと、エージェント用途では危ないというわけです。

5-2. 研究メモ

DJミオ:
研究寄りの話もいくつか。

• Rosinalityが、DeepSpeedとOpenRLHFにSFT性能を落とすバグがあると指摘
• Arjun Kocherが、DeepSeek-V4論文のCompressed Sparse Attentionを忠実実装
• che_shr_catが、single-block transformerでExtreme Sudokuを解くにはexplicit scratchpadとinverted routing initが必要、それがないと性能ゼロ
• Keller Jordanが、MuonやAdamWを比較できる軽量Modded-NanoGPT optimizer benchmarkを公開

DJレン:
地味に見えて、どれもエンジニアには刺さるやつですね。
「昔の論文結果はバグ込みかもしれない」「scratchpadがないと解けない」「最適化手法は再現可能なspeedrunタスクで比べよう」みたいな。

---

6. 経済性、API価格、クローズドモデル依存リスク

DJレン:
次はかなり重要なテーマ、お金と依存リスクです。

DJミオ:
まずオープンモデル経済圏について、Aidan Gomezは、private deploymentが重要なのはコストを自分で支配できるからだと主張。
Vtrivedyも、Haiku/Flash相当の用途はオープンモデルで再評価すべきと述べていました。

DJレン:
引き合いに出されていたモデル群は、DeepSeek、Minimax、GLM、Nemotron。
価格差が大きく、品質も上がってきているので、従来の“軽量クローズドモデルで十分”という発想を見直すべきだと。

DJミオ:
そしてDeepSeek自体もこの物語を後押ししていて、V4 Proの大幅値下げとキャッシュ割引を実施し、その期限も5月末まで延長しました。

DJレン:
一方でクローズドモデル依存の問題。
Gergely Oroszは、Anthropicの最近のサイレント変更や顧客影響のある挙動を見て、クローズドモデルは**“巨大なオペレーショナルリスク”**だとまとめていました。

DJミオ:
Zach Muellerも、Claude 4.7が自分のコーディングワークフローで劣化したと報告して、最終的に乗り換えたと。

DJレン:
さらにAran Komatsuzakiは、非英語トークン税を定量化。特にAnthropicで強いとされ、その後さらに多言語・多モデル比較を広げた結果、GeminiとQwenは非英語に比較的やさしいという話になっていました。

---

7. エンゲージメント上位ツイート

DJミオ:
上位ツイートも軽く押さえましょう。

DJレン:
まず、OpenAIがCodexのレート制限を一時的に全有料プランでリセット。
GPT-5.5を使った構築を促進する狙いですね。

DJミオ:
次に、Claude Codeの障害をネタにしたYuchen Jinのジョーク。
「Claude Codeが落ちたらシリコンバレー全体が反応する」という話で、コーディングエージェントの社会インフラ化を象徴していました。

DJレン:
あとは、OpenAIがポッドキャストでGPT-5.4 Proが60年物のErdős問題解決を助けた話を宣伝。
それとSam Altmanが5.5への強い熱狂を述べ、そこにEpochのベンチ数字が裏付けとして乗った、という流れです。

---

8. ガバナンスと防衛：Googleのペンタゴン契約

DJミオ:
この日の政策面で一番荒れたのは、Googleの機密扱いの国防総省AI契約。

DJレン:
Kimmonismusの要約によると、Googleは機密業務や“あらゆる合法的な政府目的”にAIを使える契約を結び、
契約文言上は政府が安全フィルタ変更を要求できる余地があり、
監視や自律兵器についての制限は拘束力の弱い“intendedではない”表現に留まっている、という報道でした。

DJミオ:
これに対して、GoogleやDeepMind内部からもかなり強い反発が出ていて、
BlackHCは**“shameful”とまで言い、しかも社内に事前の周知や議論がなかった**と批判していました。

DJレン:
この件の重要性は、各フロンティア研究所のレッドラインの違いが鮮明になったこと。
S. Ó hÉigeartaighは、Google DeepMindもOpenAIと同じ基準で監視されるべきだとし、
TurnTroutは、Googleの規約はOpenAIの“申し訳程度の制限”よりさらに弱いと指摘。

DJミオ:
逆に、Anthropicは以前から一部のレッドラインを下げなかったために調達面の摩擦があった、という報道もあって、対照的でした。
エンジニア目線では、これは単なる政治ニュースではなくて、安全ポリシー、配備コントロール、契約文言そのものが製品仕様になってきた、という話ですね。

---

9. Reddit総括：LocalLlama / localLLM

9-1. Qwen 3.6 のベンチと量子化

DJレン:
ここからはReddit。まずはローカル界隈の本丸、Qwen 3.6。

DJミオ:
ひとつ目は、Qwen 3.6 27BのBF16、Q4_K_M、Q8_0 GGUF比較。
評価はllama-cpp-pythonとNeo AI Engineerで、
HumanEval、HellaSwag、BFCLを見ていました。

DJレン:
実用面で目立ったのはQ4_K_M。
なんと

• BF16より1.45倍高速
• ピークRAM 48%削減
• モデルサイズ 68.8%縮小
• function calling性能はほぼ同等

という結果で、ローカル/CPU用途ならQ4_K_M推奨、最高品質が必要ならBF16、というまとめでした。

DJミオ:
ただしコメント欄は慎重で、
error barがないこと、
Q4_K_MがQ8_0を上回るのはサンプリング誤差ではという指摘、
あるいはKV cacheまで量子化されていたのではという疑念も出ていました。

DJレン:
HumanEvalのスコア自体も、他モデル比較から見て低すぎるのではという意見がありましたね。
要するに、定量評価への不信感がかなり強い。

9-2. Luce DFlash と単一3090での高速化

DJミオ:
次はLuce DFlash。
これはQwen3.6-27B向けのspeculative decoding実装で、
単一RTX 3090上、ggmlベースの独立C++/CUDAスタックで動きます。

DJレン:
技術的には、

• DDTree tree-verify speculative decoding
• KV cache compression
• sliding-window flash attention

などを使って、HumanEval、GSM8K、Math500で最大1.98倍のスループットを達成。
しかも再学習不要。

DJミオ:
コンテキスト長も256Kまで対応。
ただ、コメントではやはり量子化による精度低下、特にコーディングやツール呼び出し用途での影響を気にする声がありました。

9-3. 古いGPUを追加してVRAMを足す話

DJレン:
そして面白かったのが、16GB VRAM勢は古いGPUを挿せという投稿。

DJミオ:
例としては、5070 Ti + 2060で合計22GB VRAMを作り、
llama-serverでQwen3.6-27Bのようなdense modelを回す構成ですね。
設定は

• dev=Vulkan1,Vulkan2
• no-mmap
• n-gpu-layers=999

など。

DJレン:
数字としては、128k contextで
prompt処理 186 tok/s、
generation 19 tok/s。
単体カード時の4 tok/sに比べると大幅改善。

DJミオ:
ただし副作用もあって、たとえば3090 Ti + 2070だと、遅い方が足を引っ張って30 tok/s→20 tok/sに落ちる、という報告もありました。
つまりVRAM拡張にはなるけど、速度ボトルネックの設計が必要ということ。

DJレン:
また、かなり厳しい構成――たとえばGTX 1650 4GB + 62GB RAMでQwen3.6-35B-A3Bを、
--cpu-moe、--mlock、キャッシュ設定を工夫して20〜21 tok/s程度で回している例もありました。
資源管理次第で意外と戦える。

---

10. Reddit：新モデル・新ツールの予告と話題

10-1. Mistral Vibe teaser

DJミオ:
「Something from Mistral (Vibe) tomorrow」という予告投稿もありました。

DJレン:
コメントでは、新モデルではなくMistral Vibe Xアカウント由来で、
Mistral AI本体とは別の、ローカルモデルと相性のいいcoding agent / coding harnessの発表ではという見方がありました。

DJミオ:
一部では軍事契約でSOTA開発が遅れるのではという憶測も出ていて、Mistralの現状モデルを「meh」と評価する声もありましたね。
あと**Devstral SWE Bench 81.00+**というスコア言及もありました。

10-2. Deepseek Vision Coming

DJレン:
Deepseek Vision Comingという話も。
Xiaokang Chen由来の投稿で、Deepseek Visionは近いと見られています。

DJミオ:
すでに基盤モデルはできていて、multimodalityの統合が残っているという理解ですね。
DeepSeek V4 previewから本番V4までが2〜3週間だったことから、Vision側も比較的早いのではと推測されていました。

DJレン:
ただコミュニティは、別個のVisionモデルよりV4.1みたいなネイティブ統合マルチモーダルを望んでいる感じでした。

10-3. TRELLIS.2 のRedditでの反応

DJミオ:
TRELLIS.2はRedditでも話題で、
「実は4か月前に出ていたけど、多くの人には今さら新鮮だった」という反応。

DJレン:
実運用上の問題としては、AMD 7800XT + ROCmでsegfaultした報告、
主にNVIDIAの24GB VRAM環境で検証されていたこと、
ROCm supportのPRは通ったが依存関係やgated repoで苦戦、という感じでした。
とはいえ画像を処理して資産生成に入りはするので、部分的には動くようです。

---

11. Reddit：ローカルLLM利用の現実と課題

11-1. 「ローカルLLMでコーディングするのをやめる」

DJレン:
かなり伸びたのが、**「ローカルLLMでコーディングするのをやめる」**という投稿。

DJミオ:
投稿者は、Qwen 27BやGemma 4 31Bを試したけれど、職場のClaude Codeと比べると、
特に

• 意思決定
• tool calling
• Dockerizationの手順判断
• 長時間プロセスの扱い
• レスポンス速度
• 壊れたprompt cache

あたりで不満が大きかったと。

DJレン:
なので、重い仕事はOpenRouterなどのクラウドに任せ、
ローカルは簡単な自動化や言語タスク向けにする、という結論でした。

DJミオ:
でもコメントで重要だったのは、モデル単体よりharnessの影響が大きいという指摘。
同じモデルでも、使うエージェントハーネス次第で全然違う結果になる。
たとえばHermesは、長時間プロセスの扱いやログファイル出力の利用に強みがある、みたいな話ですね。

DJレン:
あとUnslothのドキュメントへのリンクも共有されていて、
ローカル環境での低速推論やキャッシュ不全の改善方法が紹介されていました。

DJミオ:
コスト面では、Kimi K2.6がClaude Opusに近い性能を低コストAPIで提供する選択肢として言及されていたのも印象的でした。

11-2. r/LocalLLaMAの“二重性”

DJレン:
関連して、Duality of r/LocalLLaMAという投稿も面白い。
同じコミュニティに「もう無理」と「実務で使える」が同時に存在する。

DJミオ:
コメントでは、
Qwen 3.6 27Bはtrillion-parameter級とは競えないけれど、ワークフロー設計次第で実用に近づける、
AIは創造部分よりgrunt workに使うべき、
といった整理がされていました。

DJレン:
さらに、

• harness設定
• system prompt
• モデルごとの癖に合わせたglue
• 量子化レベル（IQ2なのかQ8なのか）

が体験を大きく左右する、という話も。
ユーザーが量子化条件を書かずに能力を語りがちなのも、議論を混乱させる要因です。

DJミオ:
戦略としては、大きいクローズドモデルで計画し、ローカルモデルでトークン効率よく実行するという使い分けが示唆されていました。

11-3. LM Studioのネットワークセキュリティ警告

DJレン:
そして重要だったのが、ネットワークセキュリティ警告。
なんと373台のLM StudioインスタンスがAPIキーなしで公開されていたという話です。

DJミオ:
地図ではタイが194台で最多。
問題は、インターネットに直接さらされたLM Studioへ外部からプロンプト実行できる点で、かなり危ない。

DJレン:
対策としては、Tailscaleを使う、あるいは認証付きリバースプロキシを使う、など。
コメントでも、これは単に「ネットに繋いだPCでローカルLLMを動かす」のが問題なのではなく、ルーターでポート転送して公開してしまったケースが危険だと説明されていました。

DJミオ:
倫理的ハッキングとして評価する声もありましたが、当然ながら勝手に他人の計算資源を使える状態なので、かなり深刻です。

---

12. Less Technical Subreddit：Claude/Opus価格問題

12-1. Opusの“二重課金”疑惑

DJレン:
Less technical側では、まずClaude / Opusの価格・アクセス問題が大きかった。

DJミオ:
「AnthropicがClaude CodeのProユーザー向けに、Opusをさらに追加課金にした」という投稿が伸びました。
つまり月20ドルのProでも、Opus 4.5には別料金が必要に見える、という話ですね。

DJレン:
ただし、ClaudeOfficialが出てきて、これは古いサポート記事が更新されていなかっただけと説明。
Opus 4.5は1月からProにロールアウト済みで、Wayback Machineへのリンクまで出していました。

DJミオ:
なので、本質は新たな囲い込みというより、ドキュメント更新ミスによる混乱だった可能性が高い。
でもユーザー側では、
透明性が足りない、
Opusはトークン消費が大きすぎる、
品質低下やバグもある、
という不満が強かったです。

12-2. GitHub CopilotでClaudeモデルが9倍値上げ

DJレン:
より直接的だったのが、GitHub CopilotでClaudeモデルが6月から9倍値上げという話。

DJミオ:
これは固定プランから従量API課金へ移行する流れで、企業利用では単位経済性が大きく悪化する可能性があります。
しかも問題は、エージェント内部のトークン使用量が見えにくいこと。
見えないまま請求だけ増えるのは怖い。

DJレン:
コメントでは、Anthropicが市場ポジションを活かして価格主導権を強めているという見方もありましたし、
一方で他モデルでも6倍増があるという指摘もあって、業界全体の価格再編の気配もあります。

---

13. Less Technical Subreddit：GPT-5.4 / 5.5比較

DJミオ:
次はGPT-5.4と5.5のMineBench比較。

DJレン:
MineBenchはブロックパレットから3D構造を作る系のベンチですが、結果としては5.5は5.4よりわずかに良い。
同程度の品質を、より少ない計算資源で出せるというOpenAIの主張とも整合的でした。

DJミオ:
数字面では、GPT-5.5の実行コストが19.98ドル、平均推論時間624秒。
5.4はだいたい25ドル程度。
さらに5.5 standardと5.5 Proの差は小さいともされていました。

DJレン:
作例については、宇宙飛行士のバイザーに映る地球の反射まで表現していたという感想がある一方、
ランダムな色ブロックでややノイジーという指摘もありました。
でも総合では5.5のほうがやや上。

DJミオ:
コメントでは、5.4→5.5でELOが270向上、さらに5.5 Proで220上乗せという大きな伸びを評価する声もありましたね。
ただ、そのぶんベンチ自体の飽和や難易度引き上げも課題になってきそうです。

---

14. Less Technical Subreddit：ChatGPTが数学問題を解いた件

DJレン:
そして最後に、最も拡散した話題のひとつ。
ChatGPT 5.4 Proが64年もののErdős問題を解いた件です。

DJミオ:
投稿では、23歳のユーザーがChatGPT 5.4 Proを使って約1時間20分で解いたとされ、
実際にはErdős 1196であって、誤って1176と書かれがちだった点も訂正されていました。

DJレン:
証明はprimitive setsや対数不等式を扱うもので、
ポイントは、既知の公式を新しいやり方で適用したこと。
しかもこの証明は正当と確認されており、Terence Taoも言及したという。

DJミオ:
コメント欄では、
「50年分の数学者より推論したというのは言い過ぎ」
「未解決問題は数が多く、単に注目されていなかったものもある」
という冷静な見方もありました。

DJレン:
ただし、適切な問いを立てたことがブレイクスルーに繋がった、という評価は共通していましたね。
専門家たちが追っていた部分解とは別ルートで、ユーザーが別のアプローチをAIに与えたことで解けた、と。

DJミオ:
つまり「AI単独が天から答えを降ろした」というより、人間の問題設定能力とLLMの探索能力が組み合わさった成果として受け止めるのが妥当、ということです。

---

15. Discordセクションと締め

DJレン:
最後、Discordはちょっと寂しいお知らせでした。
Discord側のアクセスがその日で停止し、従来の形では復活しない。
その代わり新AINewsを出す予定とのことでした。

DJミオ:
静かな日と言われつつ、実際には

• vLLM 0.20とハードウェア最適化競争
• Poolside Laguna XS.2
• NVIDIA Nemotron 3 Nano Omni
• TRELLIS.2
• エージェントの本番運用化
• GPT-5.5のベンチ
• Claudeまわりの価格・信頼性問題
• ローカルLLMの現実的な限界と可能性
• Googleの防衛契約とガバナンス論
• Erdős問題解決の衝撃

と、十分に密度のある一日でした。

DJレン:
特に印象的だったのは、AIの競争軸がますます多層化していること。
モデルのスコアだけじゃなく、サービング、量子化、KV、推論コスト、契約文言、配備自由度、運用信頼性まで含めて勝負になっている。

DJミオ:
そしてユーザー側も、「SOTAかどうか」だけじゃなく、
どのハーネスで、どの量子化で、どのGPUで、どの価格体系で、どのリスクを飲むかを考えないといけない時代になっていますね。

DJレン:
今夜のMidnight AI Groove、このへんでクローズです。

DJミオ:
静かな日ほど、地殻変動は深い。そんなAIニュースの夜でした。

DJレン:
DJレンと、

DJミオ:
DJミオがお送りしました。

二人:
おやすみ、また次回。