2週間で10万個の国内製AIアクセラレーター、自身のモデルの最適化を開始。

著者：APPSO

出典：ウォールストリート・ジェイウィン

先ほど、智谱GLMのチーフサイエンティストである唐傑がXプラットフォームで、GLM-5.3-Flash推論システムの最適化に関する研究を共有しました。

彼は、GLM-5.3-Flashが国内製AIアクセラレータ上で初めて動作し、すべての生産トラフィックを処理するまでにわずか2週間しかかからなかったことを明かした。このプロセスで、システムのエンドツーエンドスループットは3.2倍向上した。

唐傑が最も印象に残ったのは、多数の最適化作業を完了したのがインフラエンジニアだけでなく、GLM-5.3に駆動されるInfra Agentであったことである。

「これは、自らのサービスを最適化するためのモデルです。」と唐傑はこの変化を説明した。

彼の見解では、これはAIが自らの動作を支えるシステムの最適化に参加し始めたことを意味する。真の意味での再帰的自己改善（Recursive Self-Improvement、RSI）にはまだ遠いが、その初期形態がすでに現れている。

智谱チームは、過去1年間でGLMの役割が変化していることに気づいたと述べています。

当初、チームはGLMがコード理解とサイバーセキュリティの分野でどのように機能するかを調査し、複雑なコード内の脆弱性を分析するのをモデルが支援することを望んでいました。しかし、モデルの能力が向上するにつれて、GLMはAIシステム自体の構築にも参加し始めました。

チームは、過去に熟練したインフラストラクチャエンジニアチームが数週間を要していたタスクを、このモデルが完了させるのを観察したと述べています。これらの作業は、次世代モデルのトレーニングおよびデプロイ方法に直接影響を与えます。

2週間で国内産計算能力クラスターを構築

大規模モデルを新ハードウェア上の初回実行から、安定して生産リクエストを処理できる推論サービスにまで導くには、多くのシステムエンジニアリング作業が必要です。

GLM-5.3-Flashは、10万台以上の国内製AIアクセラレーターで構成されるクラスタ上でデプロイされました。智谱チームは、これはこれまで成熟した実績が不足していた大規模デプロイであると述べています。

チームは、国内製チップのVRAM容量と相互接続帯域幅の制限、新しいモデルアーキテクチャへの適合、100万トークンの長いコンテキスト対応、マルチモーダルリクエスト処理など、複数の課題を解決する必要があります。同時に、国内製AIアクセラレータのソフトウェアエコシステムはまだ発展段階にあり、一部のKernelのサポートが不十分で、多くの情報はエンジニアリングチームが自ら探求する必要があります。

唐傑は、これらの制約条件下で、GLM-5.3を駆動するInfra Agentが推論システムの最適化プロセスに参加し、パフォーマンスのボトルネックを分析し、最適化案を提案し、一部のコード変更を完了したと述べた。

最適化プロセス全体は、単に計算リソースを増やすことではなく、計算能力、メモリ、通信、スケジューリングの間で新たなバランスを見出すことです。

智谱チームは一連の最適化手法を採用しました。たとえば、ReplaySSMを用いて計算リソースを活用してメモリ空間を削減し、ノード内テンソル並列処理でVRAMの負荷を軽減し、INT8、FP8、BF16のハイブリッド精度キャッシュを導入して容量利用率を向上させました。さらに、Encode-Prefill-Decode（EPD）分離アーキテクチャを導入することで、異なる推論ステージをより柔軟にスケジューリング可能にしました。

最終的に、GLM-5.3-Flashのエンドツーエンドサービスパフォーマンスは初期バージョンと比較して約3倍向上し、ハードウェア利用率と1トークンあたりのコストは主要なNVIDIA GPUプラットフォームに近いレベルに達しました。

デプロイ後、GLM-5.3-Flash は実際の使用環境でのテストにも進みました。智譜チームによると、このモデルは匿名モデル名「Ox-Alpha」で OpenCode および OpenRouter プラットフォーム上で稼働し、1週間以内に両プラットフォームで使用量が最も高いモデルの一つとなり、6日間で62兆トークン以上を処理しました。

しかし、今回の実験における真の変化は、AIがコードを書くことだけでなく、複雑なシステムがなぜパフォーマンスに変化を起こすのかを理解できるようになることです。

たとえば、システムが「スループットが20%低下」と返した場合、どこかに異常が発生していることは示すが、どの層に問題があるのか、現在の仮説が誤っているのか、次に何を検証すべきかを直接示すことはできない。

経験豊富なエンジニアにとっては、このような判断は長年の経験に依存します。エンジニアは、いつ実行タイムラインを確認し、いつマイクロベンチマークを実行し、どのモジュールの出力を比較すべきかを理解しています。

智谱チームは、このエンジニアリング経験をAIが呼び出せるフィードバックメカニズムに変換し、「dense feedback」と呼んでいます。

このメカニズムの核心は、エージェントにエンジニアリング判断プロセスにより近い情報を提供することです。

モデルが計算の正確性を確認する必要がある場合、対応する正確性フィードバックを得ることができる。モデルがパフォーマンス低下の原因を分析する必要がある場合、システム実行中の時間消費を確認できる。モデルが新しい最適化手法を試す場合、実験を通じてその手法が現在のシナリオに適しているかを判断できる。

智谱チームは、真正の効果的なフィードバックにはいくつかの条件が必要であると考えています。それは、具体的な問題に十分近いもので、迅速に得られ、客観的な実験によって検証可能でなければなりません。そうでなければ、大量のログや指標が逆にエージェントが次の行動方向を判断するのを難しくする可能性があります。

モデル最適化システム、システムサービスモデル

密集フィードバックの支援により、Infra Agent は推論システム内の隠れた問題の特定に参加し始めました。

KDAのコンテキスト並列パスにおいて、エージェントは長コンテキスト計算の精度に影響を与える問題を発見しました。

異なるコンテキストシャード間で状態行列を継続的にマージする必要があるため、TF32計算による丸め誤差がシーケンス長に伴って蓄積し、最終的に計算結果にずれが生じます。

エージェントは、異なる実行パスの結果を比較することで、問題を状態の伝播およびマージプロセスにおける精度処理に特定しました。関連する修正は、Flash Linear Attention プロジェクトの PR #1180 にマージされました。

KV振替とDeepEPスケジューリングの間に別の問題が発生しました。

テスト中に、AgentはKV TransferがDeepEP Dispatchと有効に重複していないことを発見し、一部のシナリオで伝送オーバーヘッドが30%を超えた。

その後、Agent は Python と C++ の呼び出しチェーンを追跡し、ノード内のパスが Python GIL を適時に解放していないため、転送タスクが適時に進行できないことを発見しました。

修正完了後、KV 振替に伴う追加コストは 30% 以上から 1% 以下に低下しました。

また、Agent は Decode Kernel も最適化しました。

その結果、Kernelの分割方式の問題により、同じ正規化計算が4回繰り返し実行されていることが判明しました。計算構造を再構成して重複計算を削減した結果、このKernelは1.71倍のパフォーマンス向上を達成しました。

この最適化のアイデアは、Agent が SGLang、Flash Linear Attention、DeepGEMM などのプロジェクトの既存のカーネルを学習することから生まれました。これらのコードにおける最適化の経験を「最適化スキーレトン」として抽出し、現在のシステムのフィードバックと組み合わせて適用可能性を判断します。