企業ウェブサイトD1netが主催する、2026年秋季の中央国企CIOおよび数科企業の経営幹部サミット（第19回）において、シリコン基盤の流動ソリューション担当ディレクターの唐安波が会議に出席し、以下のテーマで講演を行った：「「計算能力」から「トークン生産性」へ：中央国企の大規模モデルの実用化における推論インフラとROIの実践」。以下はその講演内容の要約である。
現在、AIアプリケーションは爆発的な成長の初期段階にあり、Tokenの消費量は指数関数的に増加しています。その背景には、モデル構造が継続的に進化し、バージョン更新のペースが速くなっていること、またコンピューティング能力の構造も絶えず進化していることがあります。モデルとコンピューティング能力の間には、相互に推進するイテレーションのプロセスがあります。企業にとっては、一方でこれらの変化に適応し、他方で自社のビジネスシナリオに合わせた多様なモデルサービスを提供し、かつコストを合理的な範囲内に抑える必要があります。
シリコン基盤の流動が行っていることは、計算能力からTokenまでの変換層を構築することです。つまり、計算能力を一元化して管理し、自社開発の推論エンジンを通じてモデルをより速く、より良く動作させるのです。私たちは公開クラウド上でToken工場を構築するとともに、中央省庁が内部で自らのToken工場を構築するのにも支援しています。
要するに、体系的な推論プロセスを通じて、モデルと計算能力の多様な適合を実現する。これに基づき、シリコン基盤の流れは Token 生産力の核心公式を提案する：Token 生産力 = 生産能力 × 利用率 × 提供品質。ここで、生産能力はチップのハードウェア能力とモデル最適化レベルによって決定され、利用率はトラフィック管理と計算能力のインテリジェントなスケジュールによって実現される。提供品質には、モデルの推論精度、ツールの呼出しなどのタスク実行成功率、そして生産環境に必要な SLA サービスの安定性が含まれる。
一元管理からモデル運営へ、実際にコンピューティング能力の利用率を高める
業務とトラフィックの観点から、4層の解耦アーキテクチャを設計しました。モデルの運用、モデルの運営管理、推論実行、計算能力の調整を連携させ、モデルの導入、高速化、サービス調整などの全ライフサイクルをカバーします。この層別解耦のアーキテクチャは、中央国有企業が既に構築しているプラットフォームの状況に適応し、重複する構築を避けるためです。もし企業が既存の研究開発能力を持っている場合は、既存のシステムと連携して利用でき、全く新しく作り直す必要はありません。つまり、「能力の組み合わせ」によって直接必要な能力を補完することができます。
モデルゲートウェイ：入り口であるだけでなく、モデル運用プラットフォームでもあります。
この層は、各地の分子会社やその子会社など、モデルサービスを利用するユーザーに直接対応しています。すべての大規模モデルの呼び出しは、この層を通じて計測、請求、認証などの基本業務が行われます。さらに重要なのは、豊富なスケジュールやルーティング戦略を提供することです。例えば、異なるビジネスシナリオにおける応答時間の要求に応じて、リクエストを適切なモデルサービスにルーティングすることができ、各部門間の干渉を防ぎ、双方が満足するSLAを確保します。また、性能優先やコスト優先など、異なる目標に応じて柔軟にスケジュールを行うこともサポートしています。
モデルサービスプラットフォーム：導入と運用のベストプラクティスを企業に提供します。
この層は、運用・保守の観点からモデルをデプロイしたり、モデル倉庫などの機能を管理するものです。企業が一括でモデルを利用できるように、モデルのデプロイに関する最適な実践を盛り込んでいます。すでに約100種類のモデルに対応しており、新しい主流モデルも継続的に対応していきます。目標は、業務チームが箱から出して使えるようにすることです。
高性能推論フレームワーク：具体的なモデルとハードウェア向けの最適化反復処理。
異なる計算能力メーカーと深い協力を進め、具体的なモデルと計算能力を中心に、独自のオペレータライブラリや通信ライブラリを開発し、対応するハードウェア上でのモデルの性能を最大限に発揮させる。 例えば、華為クラウドと協力して、業界で初めて国産チップを基盤としたDeepSeek R1/V3 Tokenサービスを提供し、CloudMatrixの超ノードクラスター向けに推論ソリューションを共同で開発・最適化することで、DeepSeek-R1では単一カードによるDecode処理のスループットが1,920 tokens/sを超えるようになった。また、沐曦曦クラウドC550クラスターを基盤としたKimi-K2大規模モデルの商業サービス展開が世界で初公開された。モールスレッドMTT S5000チップ上にDeepSeek-V3を導入し、単一カードによるPrefill処理のスループットが4000 tokens/sを超え、Decode処理のスループットが1000 tokens/sを超えるようになった。
同時に、私たちの推論技術も継続的に進化している。モデルが処理するタスクのコンテキストが増え続け、並行処理能力が向上するにつれて、演算器の最適化、通信の最適化、モデルの量化など、推論フレームワークを継続的に最適化する必要がある。また、PD分離やKV Cacheの階層的アンロードなどの手法と組み合わせることで、モデル推論の全体的な性能とスループット能力を大幅に向上させている。
計算能力スケジュール：計算能力リソースの弾力性管理。
弾力性のある柔軟なコンピューティング能力の調整は、推論コストを低減し、コンピューティング能力の利用効率を向上させる重要な要素です。しかし、コンピューティング能力の計画にはしばしばジレンマがあります。過度に保守的に予測すると、すぐにフル負荷や過負荷になる可能性があります。一方で、日中のピーク値に完全に従って配置すると、他の時間帯でリソースが無駄になります。したがって、弾力的な拡張・縮小戦略が必要であり、運営手法も併せて必要です。
例えば、中央企業が各子会社に対してモデルサービスを提供する際には、内部決済において時間帯別価格設定を採用することができます。昼間は通常の価格で、夜間は割引を適用し、一部の業務を夜間に運用させるようにします。各業務は異なるモデルを使用する可能性があるため、プラットフォームはリクエストキューや性能などの多次元指標に基づいてモデルインスタンスを動的に調整できる必要があります。
中央企業の事例：「機械の賃貸」から「モデルサービスの呼び出し」へ
私たちはある中央国企グループにサービスを提供していました。元々は約50台の機械があり、下位の子会社にサービスを提供していました。初期のサービス方法は非常に直接的で、各子会社が機械を申請し、自分が必要とするモデルを配置するというもので、言ってみれば「機械を借りる」ということでした。
そうなると、モデルインスタンスは40～50個作られましたが、全体の計算能力の利用率は非常に低いです。あるユニットはマシンを占有した後、1つのモデルのみを展開します。また、昼間だけ使用し、夜は使用しないものもあります。さらに、週に数日だけ使用するものもあります。マシンが占有されているにもかかわらず、持続的な有効負荷は生じません。
私たちは顧客と深く協力し、上記の現状に対して再構築を行います：モデルが統一され、計算能力も統一される。重複するモデルを約10個に収束させ、マシンごとにリソースを割り当てる方式をServerlessモデルサービスに変更し、全員がAPIを共通で呼び出すようになります。モデルが具体的にどこに配備されているか、どのマシンを使用しているかなどはもう気にする必要がありません。
このように、同じく約50台のマシンで、より多くのことを行うことができます。例えば、一部のマシンを既存の小さなモデルに使用した後、多くのマシンを新しい大パラメータモデル、例えばGLM-5.2、DeepSeek-V4-Flash-0731などに割り当てることができます。以前は、このようなモデルはグループ内で実行する条件がありませんでした。しかし実際には、大パラメータの新しいモデルはビジネスの探索に非常に重要です。なぜならモデルの知能の上限が、アプリケーションの革新の上限も決定するからです。モデルの収束と計算能力の集約管理を通じて、これらのモデルを実装し、性能の最適化を組み合わせることでより多くのシナリオが「利用できない」状態から「利用可能」になるようになり、「探索可能」から「大量に使用可能」になるようになりました。
実は、事業側の最大の懸念はこうです。探索を行ったりエージェントを作成したりするのは問題ありませんが、どれだけ規模化してサービスを開始できるか、もっと多くの呼び出しを受けられるかという点については、皆心に疑問があるのです。新しいモデルがサービスを開始した後、単一の同時処理から多くの同時処理までのテストにおいて、出力速度は合計で30トークン/秒以上を維持しています。プログラミングを例にとると、30TPSを超えることが良い使用体験を得るための基本要件です。同じモデルの比較テストでは、40％～100％の性能向上が見られました。 もちろん、入力や出力の長さによって異なり、具体的な利益は同じではありません。
全体として、一つはモデルの処理能力が向上し、二つは計算能力の利用率が高まった。これら二つの効果が合わさり、最終的に百万トークンあたりのコストに反映される。これは多くの企業が推論サービスの効率を測定するための指標となる。このケースでは、元々Qwenモデルの百万トークンあたりのコストは百元以上だったが、調整後には十元以下に低下した。コストが明らかに下がったが、最も重要なのは、従来実現が難しかったビジネスシナリオがより多く生まれたことだ。
ROIをさらに向上させ、アプリケーションとインフラを共同で最適化する
エージェントが規模化して導入されるにつれて、私たちは次のような問題を観察しました。アプリケーション層とインフラストラクチャ層の間に一定の乖離が生じているのです。以前はアプリケーションを開発する際、主にフロントエンドを担当する場合でも、開発者は通常、データベースのインデックスやSQLの最適化についてある程度理解していました。しかし今では、大規模モデルアプリケーションとインフラストラクチャの層構造が明確になっており、アプリケーション側が底層の推論やキャッシュメカニズムを十分に理解しているとは限らず、これが効率に直接影響を与えます。
コーディングを例にとると、私たちは顧客と共にこの分野の最適化を探求しています。中央国企のソフトウェアエンジニアリングにおいては、今日はアプリを作り、明日は別のデモを行うというものではなく、長年にわたって継続的にイテレートを行うものです。コードレポジトリは常に更新され、毎日コードを提出し、ビルドを行うことが、長期的なプロジェクトの一部です。これらのコードがモデルのContextとしてどのように構築されるかは、非常に重要です。
文脈の構築が適切でない場合、各リクエストでキャッシュに命中できないこともあり、数十万のTokenを入力することで多くの計算能力が消費されます。しかし、構築が適切であれば、約90％の内容がキャッシュに命中し、効率の差が明らかになります。例えば、キャッシュに命中しない場合、システムは100の同時処理をサポートできますが、キャッシュの命中率が高くなると200の同時処理をサポートできるようになります。この向上はハードウェアを増やすことではなく、重複計算を減らすことです。したがって、Contextの構築自体が推論に向けて最適化される必要がある。
もう一つの方向として、DevOpsを活用した最適化を行うというものです。計算能力の使用量にはピークと谷があり、昼間は皆が計算能力を利用していますが、Codingの作業では入力データが長くなります。もしすべてのコードを昼間にリクエストが来るまで待ってから処理し、キャッシュを生成するなら、ピーク時の計算能力を大量に消費することになります。そこで、毎晩の日常構築プロセスにおいて、工程化手法を用いて、モデルがコードリポジトリに対して事前処理を行い、対応する計算結果をKV Cacheに事前保存することができるかどうかです。そうすれば、昼間は再計算する必要がなくなります。これらの方法は、計算能力の利用率をさらに高める可能性があります。しかし、このような機能は、私たちとシーン側が共同で探求するものです。
シリコン基盤の流動性を活かし、中央企業と共に、さらに多くのAIの実用化シナジーを探求し、真の計算能力と生産能力を発揮させる。
雷峰網（公式アカウント：雷峰網） 雷峰網