WAIC と Qwen 3.8 に関する技術者の個人的考察と市場への警鐘

※本記事は著者の個人的見解であり、所属機関の公式見解ではありません。

TL;DR（要約）

先週、上海で開催された WAIC の会場で 2 日間過ごし、多くの質問に答えたり、友人たちと交流したりしました。その中で強く感じたのは、「超ノード」が至る所に出現している一方で、技術者たちが資本の波に流されているように見える点です。千卡・万カスケールアップや光インターコネクト、液冷システム、CPO（Co-Packaged Optics）などへの過度な期待が、まるで株式市場の噂話のように広まっているのです。

「光の中にいる人」は確かに多いですが、彼らが裸で立っている姿さえ見えてくるような錯覚に陥りました。そのため最近、私は口癖のようにこう言っています。「同志たちよ、もっと本を読め。知識人の嘘に騙されるな」。

また、日曜日に Qwen 3.8 がリリースされたため、早速いくつかテストを行いました。以前のバージョン（Qwen 3.5/3.6/3.7）と比較して劇的な改善が見られ、私が業務で直面する難易度の高いタスクの 2 つについては、Opus 4.8 と同等の性能を発揮しました。そこで、その結果を報告します。

1. Qwen 3.8 の評価について

メディアによる Qwen 3.8 の評価を見ると、主観的な賛否両論が目立ちます。多くの事例は一般ユーザーにとって理解しやすいものですが、Three.js を活用した美しい 3D UI や、生成された高品質な SVG など、視覚的に魅力的なフロントエンドの成果が特に注目されています。

この間、Kimi K3 も試しましたが、フロントエンド分野では非常に優秀で、個人的には Opus 4.8 よりも上回っていると感じています。なぜなら、Opus が生成する SVG は、毎回人間による微調整が必要だったからです。

Qwen 3.8 の記事執筆に合わせて、RDMA 推論ネットワークに関する解説資料として、あえて地味な PowerPoint スライドを用意しました。

私は芸術的なセンスには自信がありませんが、ついでに Qwen 3.8 の多機能性をテストしてみました。使用したプロンプトは以下の通りです。

この図を詳細に理解し、より美しく再描画した SVG を作成してください。ブログ記事で公開する予定なので、視覚的にも情報的にも読者が直感的に理解できるような構成にしてほしいです。

image最後に生成された画像は以下の通りです。これを見れば、実務で必要なレポート作成の基盤として十分使えることが伺えます。

imageしかし、モデルの知能を測るには、単にフロントエンドの出力を見るだけでは不十分です。複雑なワークフローを大量に処理できるかどうかで試す必要があります。

私は Qwen 3.8 を使って、現在私が取り組んでいるいくつかの実務タスクでテストを行いました。

1. CUDA コードの記述と GPU マイクロアーキテクチャの逆エンジニアリング

先日、Claude を活用して「エージェントによる NVIDIA GPU マイクロアーキテクチャの逆エンジニアリング」プロジェクトを構築しました。その報告書は以下でご覧ください：

https://zartbot.github.io/micro_arch/nvidia/sm_120/

このプロジェクトには 1,000 以上のテストケースが含まれており、モデルが推測したハードウェア構造に基づいて CUDA コードを記述し、検証を行う必要があります。単一のチップで全テストを完了するには、約 100 万行のテストプログラムが必要です。Claude Opus 4.6 や 4.8 はこのタスクにおいて非常に高いパフォーマンスを発揮しました。

今回は Qwen 3.8 を用いて、最も複雑な「TensorCore」と「メモリサブシステム」に関する章を抽出し、再テストを行いました。すべてのケースが正常に実行されたため、同モデルのコード記述能力は極めて高いと言えます。Qwen 3.6 や 3.7 と比較して特に印象的だったのは、エージェントとしての複雑なタスク処理能力が大幅に向上している点です。特に、複雑なタスクに対する指示の追従性が顕著に改善されています。

1. Anthropic の VLIW+SIMD 面接試験問題

この部分は Qwen 3.8 の真価をより明確に示すものです。まず、この問題は非常にマイナーなプロセッサ・マイクロアーキテクチャに基づいています。VLIW（Very Long Instruction Word）と SIMD（Single Instruction Multiple Data）の組み合わせは、20 年以上前のインテル/HP アネンタ（Itanium）や初期の AMD/ATI グラフィックスカードを除けば、現在では一部の DSP（デジタルシグナルプロセッサ）にしか採用されていません。かつて Intel と HP が共同開発したアネンタ・マイクロアーキテクチャが失敗した主な理由の一つも、このアーキテクチャで高性能なプログラミングを実現するには、コンパイラと人間双方の能力に対する要求があまりにも高すぎたからです。

出題内容は以下の GitHub リポジトリでご確認いただけます：

https://github.com/anthropics/original_performance_takehome

WAIC と Qwen 3.8 について

何の指示も出さず、モデルに任せた場合の最適化結果を比較すると、Opus 4.5 はおおよそ 1487 Cycles に達します。一方、Opus 4.6〜4.8 のテストでは、ほぼ 1100 Cycles を達成できました。

最近登場した Fable 5 も同様で、何の指示も出さず、単一のプロンプトだけであれば 1000 Cycles 以内を実現可能です。

なお、人間が到達できる最高スコアについてはあえて公表していません。もし「自分ならもっとできる」と思う方がいれば、直接企業へ応募メールを送っていただければ結構です。ただ、比較好きの方々が勝手に公開ランキングを作成することも珍しくありません。私自身はリソースに恵まれた立場ではありませんが、安全上の理由からアリババグループが Claude の利用を制限しているという事情も踏まえつつ、第 2 位を獲得し、首位との性能差を 2% 以内に抑えることができました。

imagehttps://vliw-challenge.fly.dev/

この課題をクリアするには、モデルが高度な知能を持ち、動的に検索を実行したり、リソース制約求解器などのツールを呼び出して最適化を行ったりする必要があります。さらに、これはハッシュベースの並列ランダムツリーウォークアルゴリズムを採用しているため、データ依存性の処理や代数構造の分解、スカラーユニットとベクトルユニットの間のバランス調整など、モデルの絶対的な知能と極めて複雑なタスク計画能力が問われます。

私は、Anthropic の採用面接基準を参考に、モデルの知能を詳細に評価するのが妥当だと考えています。その理由は二つあります。まず、こうした内容はモデルの学習データにほとんど含まれていないためです。もう一つは、これらが一流大手企業の採用試験で人材の総合能力を試すための指標として使われているからです。

Qwen 3.8 については、非常にシンプルな実験を行いました。プロンプトはただ一つだけ。

「このディレクトリ内の問題を詳細に分析し、Agent Loop を設計して 1000 Cycles 以内へ最適化してください」

その結果、Qwen 3.8 は Agent Loop の実行前の予備段階で既に 2020 Cycles にまで削減しました。4 時間の反復処理を経て、後半のラウンドでは急速に 1118 Cycles へと低下させることに成功しました。

image 在整個 Loop 迭代過程中，Qwen3.8 的自主規劃能力也相當出色。

image 結論

整體來看，Qwen3.8 在無需額外提示的情況下展現出的自主執行能力，與 Opus 4.8 不相上下。尚未達到 Fable 5 的水平，主要是因為它目前還未掌握 OR Tools 的使用方法。

1. 關於 WAIC

今年我聽的研討會不多，逛展的時間也有限。畢竟大多數硬體方案早已熟悉，若去展台問得太深，反倒像是在故意砸場子。所以，還是專心做好自己的事，做一名全棧式的「人工」智能講解員。

對阿里而言，全棧能力是一項優勢。從今年的鎮館之寶——真武 890 與磐久 128 超節點，到國內最大的 Agentic Cloud 基礎設施、百煉 MaaS 推理平台，再到 Coding 領域的領軍產品 Qoder，以及展覽期間發布的 Qwen 3.8……對於個人來說，全棧則是一份責任。作為基礎設施的建設者，無論是算力、存儲、網絡還是安全問題，亦或是上層的推理框架與模型演進，好在積累足夠深厚，能夠穩穩地接住觀眾提出的各種問題。

2.1 真武 890 超節點

今年幾乎每家廠商都展出了自己的超節點，提出了各種互聯方案與協議。但能在整個機櫃內實現主要芯片全自研的，或許只有華為和阿里了。

先小小地吐槽一下……

現場被問得最多的問題是：為什麼阿里沒有千卡級的光互連？或許是炒股的小作文看多了，似乎每位觀眾都忍不住要說教一番，推崇 NPO、CPO 等技術。當然，未來某一天我們肯定會站在光中，但現在或許只能「裸奔」著站在那裡……

image 為什麼阿里需要這樣設計超節點

これまでの議論でも明らかな通り、ScaleUP ドメインをすべて相互接続する「All-to-All」方式がより優れたソリューションです。ただし、大規模な ScaleUP ドメインを実現するには、多段スイッチによる相互接続や、All-to-All ではないトポロジを採用する必要があります。物理的な距離の制約から光インターコネクトが必要になりますが、超大规模な光インターコネクト展示用のラックを構築する技術自体は不可能ではありません。しかし、実際のビジネス運用において長期的な安定性と信頼性を確保するためには、光通信の平均故障間隔（MTBF）がまだ課題を残しています。

もう一つの観点として、並列戦略について考えると、訓練でも推論でも、今後 2〜3 年間は 128 枚の GPU を備えた ScaleUP ドメインで十分です。現在、真武 890 はすでに 10T パラメータを持つ MoE モデルの推論を担うことができます。国内では「一卡一专家（1 枚のカードが 1 つのエクスパート）」という議論もありますが、より大きな ScaleUP ドメインにすれば EP（Expert Parallelism）並列のパフォーマンスが劇的に向上するかもしれません。確かに、各カードが処理するトークン数が減るからです。しかし、EP における同期信号のオーバーヘッドを忘れないでください。

さらに、オンライン推論においては、必ずしも大きな EP が最適とは限りません。サービス品質（QoS）の維持や、推論トラフィックの潮汐現象への対応を考慮すると、常に最大性能を発揮できる保証はないからです。例えば、128 枚の GPU を持つ超ノードが 1200 件のリクエストを並列処理できると仮定します。一方、64 枚の GPU を持つ単一ノードなら 500 件です。両方の 64 枚ノードを併用すれば合計 1000 件の処理が可能となり、128 枚ノードの方が 20% 高い性能に見えます。

しかし実際には、ユーザーへのサービス品質を保証するため、責任ある MaaS プラットフォームのスケジューリングはリソースを最大限に使い切るようには設計されていません。その結果、両者の実効性能はほぼ同等になります。一方で、2 台の 64 枚ノード構成の方が、より優れた耐障害性（フォールトトレランス）を獲得できます。1 枚のカードが故障しても影響を受けるのは一台のサーバーのみで済みますが、128 枚の超ノードでは、単一の故障がサービス全体の停止を招くリスクがあります。さらに、ScaleUP の規模を大きくすることは、光デバイスの信頼性に関する新たな課題も生み出します。

訓練シナリオにおいては、DP（Data Parallelism）や PP（Pipeline Parallelism）の並列戦略は、12.8Tbps の ScaleOut ネットワーク上で十分に機能します。また、64〜128 枚の GPU を持つ ScaleUP ドメインで TP（Tensor Parallelism）や EP を実行しても問題ありません。つまり、超大规模な ScaleUP 相互接続が現実的なニーズを完全に反映しているとは言い難いのです。

さらに、国内チップの製造プロセスと Serdes の転送速度という視点も重要です。リソグラフィー装置の影響により、Serdes の速度は長期間にわたって 112Gbps で止まる可能性が高いです。また、必要な計算能力とのバランスを考えると、ScaleUP の帯域幅を過度に大きくする必要はありません。DeepSeek-V4 の論文を参照すると、約 800GB/s の ScaleUP 帯域幅で、5PFLOPs に近い計算能力とマッチすることがわかります。したがって、帯域幅の追求は必要以上に過剰です。

このため、現時点での最も現実的なアプローチは、ラック内での銅ケーブルによる相互接続です。さらに、私たちは正交配置のバックプレーンレス構造を採用しました。これにより、Nvidia の CableTray 方式と比較して、ラック全体の保守性と安定性が大幅に向上しています。

2.2 全栈芯片自研（フルスタックチップ自社開発）

今回の WAIC での発表からも明らかのように、アリババはフルスタックのチップ自社開発能力を備えています。

真武シリーズの GPU、倚天シリーズの CPU、ScaleUP 用の自社開発 ICN スイッチチップ、クラウドインフラに不可欠な DPU（CIPU）、そして SSD のコントローラーに至るまで、アリババは多様なチップを自前で設計しています。幸運にも、これら「七つの龍珠」と呼ばれるチップの一つに関わることができました。それは唯一、Nvidia の製品よりも高性能なチップです。

CIPU 2.0 はすでに 3 年前に開発されたチップですが、このチームは DPU 業界の先駆者として知られています。全世界で最初に発表された裸金属インスタンスこそが DPU の原型であり、AWS よりも 1 ヶ月早く登場しました。その後、主要なクラウドベンダーのほとんどが DPU 開発に乗り出し、Nvidia も Mellanox を買収してこの技術を獲得しました。

Nvidia の BF3 DPU と比較すると、CIPU はストレージの IOPS 性能や RDMA の輻輳制御において、はるかに優れたパフォーマンスを発揮します。特にインフラストラクチャのセキュリティ面では、Nvidia のクラウドセキュリティへの理解はまだ不十分です。一方、CIPU の安全性は世界最高水準にあり、ハードウェアベースの安全な信頼根拠（Root of Trust）、機密計算インスタンスの提供、ストレージ・ネットワーク・データの暗号化など、あらゆる面で他を圧倒しています。

内緒話になりますが、次世代の CIPU は Nvidia を全面的に凌駕するでしょう :)

ここでは、今回発表された新機能と、アリババクラウドが持つ推論インフラストラクチャの優位性について詳しく解説します。まず推論ネットワークについてですが、これはトレーニングネットワークにおける周期的な規則的な通信とは大きく異なります。

つまり、推論クラスターにおけるネットワーク通信は不規則です。GPU サーバー間での PD（プロセッサとメモリ）分離データ転送や KVCache の転送は、ユーザーの負荷やサーバーの弾力的なスケールアウト・インに応じて大きなランダム性を帯びます。このような不規則なトラフィックパターンは、RDMA ネットワークにおける輻輳制御とロードバランシングに対してより高い要求を課します。また、一部のユースケースでは、PD 分離データの転送がドメインを超えて行われる必要があります。これらは現在、Nvidia のネットワークカードが直面している大きな課題です。例えば、マルチパスアルゴリズムや信頼性のある転送には依然として問題があり、推論ネットワークがもたらす挑戦はまさに始まったばかりです。さらに、ドメインを跨ぐ輻輳制御アルゴリズムの調整は極めて困難ですが、実際のテストでは 600〜800km の長距離伝送においても帯域幅を最大限に活用できることを確認しています。

もう一つのポイントはストレージです。私たちは KVCache に最適化された NVMe KV コマンドセットインターフェースのサポートを世界で最初に実現しました。これにより、G3.5 ストレージ層の構築は非常にシンプルになります。GPU は単純な Put/Get コマンドを実行するだけで、複雑なファイルシステムを意識することなく必要な KVCache ブロックを取得できます。また、この KV インターフェースをサポートするディスクはクラウドストレージのリソースプールを共有するため、ストレージリソースの再利用効率が大幅に向上します。さらに、仮想化されたディスクは複数の Prefill ノードと Decode ノードにマウント可能で、KVCache データを共有できるため、推論プラットフォーム全体のスケジューリングが格段にシンプルになります。

1. 結び

以上で解説は終了です。最後に一言、安心してください。私たちがいる限り、決して負けません。

微信アプリで開くにはこちらへ