中国のAI企業であるZ.aiが、「GLM-5.3-Flash」の本番サービスを提供するためにどのようにして独自の推論インフラストラクチャを構築したのかをブログで解説しています。

Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure

https://z.ai/blog/glm-built-its-inference-infrastructure

本番環境のトラフィックを確実に処理できる高性能な推論サービスを提供するには、大規模なシステムエンジニアリング作業が必要です。GLM-5.3-Flashのリリースに際し、Z.aiは10万台以上の中国製AIアクセラレータからなるクラスタ上で、本番環境レベルの推論サービスをゼロから構築しています。記事作成時点でも、GLM-5.3-Flashのすべての本番環境における推論処理は、このシステム上で実行されているとのこと。

これについてZ.aiは「これは容易なことではありませんでした。これまで、これほどの規模で中国製AIアクセラレータのクラスタをデプロイした事例は皆無だったからです。チップのメモリ容量と帯域幅が比較的限られている一方で、新しいモデルアーキテクチャ、100万トークンのコンテキストウィンドウ、そしてマルチモーダルなリクエストをサポートする必要がありました。エコシステムは未成熟で、カーネルのサポートも不完全であり、本来文書化されるべき内容の多くは推測に頼らざるを得ませんでした。最終的に、この作業は完了しました。しかし、これはインフラエンジニアのチームだけで成し遂げられたものではありません。作業の大部分は、GLM-5.3を搭載したインフラエージェントによって実行されました」と説明しています。





GLM-5.3-Flashは、Ox-Alphaという名称でOpenCodeおよびOpenRouter上で実運用テストが行​​われました。GLM-5.3-Flashはローンチから1週間以内に両プラットフォームで最も利用されるAIモデルとなり、6日間で62兆トークン以上を処理したそうです。

Z.aiは計算量を増やすことでメモリ帯域幅の消費を抑え、デバイス間通信を増やすことで各デバイスのメモリ使用量を抑える独自の手法を含む、積極的なメモリ最適化を実施しました。その結果、線形アテンションとLM(言語モデル)ヘッドのためのノード内テンソル並列処理、ReplaySSM、W8A8量子化、INT8/FP8/BF16を使用した混合精度キャッシュ量子化、レイヤー分割といったいくつかの重要な技術を組み合わせたスタックを構築することに成功。

さらに、エンコード・プリフィル・デコード(EPD)分離アーキテクチャを導入。これらの最適化により、エンドツーエンドのサービスパフォーマンスが約3倍向上したとZ.aiは報告しています。これらにより、ハードウェア利用効率とトークンあたりのコストは、いずれも主流のNVIDIA GPUと同等レベルに達したとZ.aiは記しました。

インフラエージェントのフィードバックループが最適化プロセス全体を通して機能することで、GLM-5.3-Flashは初期モデルの適応から本番稼働までわずか2週間足らずで完了。最終的には初期ベースラインと比較してエンドツーエンドのスループットを3倍に向上させることに成功しました。以下の図は、GLM-5.3-Flashが最初の実行から本番稼働に至るまでのパフォーマンス推移を示すものです。



このプロセスにより、「インフラエージェントのエンジニアリング上の有効性は、モデルのコード生成と推論能力だけでなく、システムが特定の原因にたどり着ける有用なフィードバックを継続的に提供できるかどうかに大きく依存していることが徐々に明らかになってきました」とZ.aiは言及。

しかし、エージェントがコードベース全体を理解できたとしても、変更後に「数値精度テストが失敗した」「TTFTが30％増加した」「出力スループットが20％低下した」といったフィードバックを受けた際に、「どのレイヤーが原因なのか」「なぜ現在の仮説が間違っているのか」「次に何をテストすべきなのか」を判断するのは非常に難しい作業だそうです。エンドツーエンドのメトリクスは、結果が悪化したことをエージェントに伝えることはできますが、その理由を説明することはできないためです。

そこで、断片的なエンドツーエンドの結果から次のアクションを直接導くための、きめ細かく、原因を特定できるエンジニアリングフィードバックを生成する方法が必要となったとZ.aiは言及。これは、インフラエージェントの効果的なフィードバックループを構築するための鍵にもなります。

そこで、Z.aiは「高密度フィードバック」を採用。高密度フィードバックの特徴は以下の3点にあるそうです。

1：フィードバックは十分に局所的である必要がある

2：フィードバックは低コストかつ迅速に入手できるものである必要がある

3：フィードバックは客観的な検証を支えるものでなければならない

この3つの特性を併せ持つことで、フィードバックが実行可能なものになります。正確性に関するフィードバックは、「計算は正しいか？」という問いに答えます。システム動作に関するフィードバックは、「時間はどこに費やされているのか？」を明らかにします。パフォーマンスに関するフィードバックは、「どの手法がより効果的で、どのような条件下で効果を発揮するのか？」を判断します。

このプロセスにおいて、ローカル検証とエンドツーエンドテストはそれぞれ異なる役割を果たします。ローカル検証は、不正確または効果のない変更を早期に排除し、追求する価値のある候補を特定することに役立ち、エンドツーエンドテストはローカルでの成果が実際のサービス改善につながるかどうか、また提案された変更が実際のワークロード下で新たな不具合を引き起こすかどうかを確認します。

これらの原則に基づき、GLM-5.3-Flashのリリースでは、エンジニア、インフラエージェント、実験環境が関わる最適化ループが確立されました。エンジニアは目標とシステム境界を定義し、エージェントは分析・仮説の立案・コード変更を担当。そして実験環境は、階層化されたタイムリーで検証可能なフィードバックを提供しました。「これらが連携することで、これまでエンジニアの経験に依存していた診断プロセスが、エージェントが継続的に実行できるエンジニアリングワークフローへと変革されました」とZ.aiは表現しています。



Z.aiは「フィードバックの価値はその量ではなく、エージェントが目の前の問題に答えるのに役立つかどうかにある」と指摘。大量の非構造化ログは重要なシグナルを覆い隠してしまう可能性があり、網羅性に欠けるプロファイリングは誤った帰属につながる可能性があり、マイクロベンチマークで有効な最適化がエンドツーエンドの性能向上につながるとは限らないと指摘しました。そして、フィードバック環境を構築するには、テスト・ログ・パフォーマンスデータを提供するだけでは不十分であり、各タイプの観測がどのような判断を裏付けることができるのか、その限界は何か、そしてどの結論をさらなる実験で確認する必要があるのか​​を明確にする必要があると説明しています。

Z.aiの共同創業者であるタン・ジエ氏も、GLM-5.3をベースとしたインフラエージェントによる推論インフラストラクチャの構築についてXで言及しています。