シラブレイス WSE-3T での兆単位パラメータモデル（Kimi K3）のデプロイ方法とスケーリング戦略

当社が最も多くいただく質問の一つは、大規模モデルをシラブレイスの WSE-3T ウーファー・スケール・チップ上にどのようにデプロイするかというものです。一枚の Cerebras WSE-3T ウーファーには 44 GB のオンチップメモリを搭載していますが、パラメータ数が兆単位の最先端モデルはその重み（ウェイト）だけでもテラバイト単位を必要とします。

本記事では、大規模な最先端モデルを複数の WSE-3T ウーファーにどのように分割し、1000〜2000 トークン/秒以上の速度でパラメータ数が兆単位のモデルを実行させるかを解説します。ここでは、約 3 兆パラメータを持つオープンソースモデル**「Kimi K3」**を具体例として取り扱います。

本記事の概要

以下の内容を理解していただきます：

• モデル全体をオンチップメモリに収める方法
• モデルを複数チップ（ウーファー）にどのようにマッピングするか
• 多数の同時リクエストをどのように処理するか

---

Kimi K3 を用いた詳細な解説

Kimi K3 は、69 つの線形注意力（linear-attention）層と 24 つの高密度（dense）層から構成される、オープンソースでパラメータ数が約 3 兆のモデルです。本解説例では以下の設定を用います：

• 平均リクエストサイズ: 256,000 トークンと仮定
• ウェイト量子化: 4 ビット（Hugging Face の実装と同様）
• KV キャッシュ: 8 ビット

#1 各層のサイズ計算

Kimi K3 を支えるために必要な Cerebras WSE-3T ウーファーの数を決めるには、まずモデル各層のサイズを計算する必要があります。

Kimi K3 は総計 3 兆パラメータを持っており、すべてのパラメータを 4 ビット単位で格納する場合、生データの合計量は以下のようになります：

• 総パラメータ数: 3,000,000,000,000
• ビット精度: 4 bits
• 総ビット数 = $3 \times 10^{12} \times 4 = 12 \times 10^{12}$ bits
• 総バイト数 = $(12 \times 10^{12}) / 8 = 1,500$ GB

このデータを全 93 の層（69 つの線形注意力層＋24 つの高密度層）に分割すると、各層あたりの必要容量は約 16 GBとなります。

計算式：$1,500 \text{ GB} \div 93 \text{ 層} \approx 16.1 \text{ GB/層}$

#2 必要なウーファーの数

各層が約 16 GBを必要とする事が分かった現在、一枚の 44 GB ウーファー上に収められる層の数を算出できます。その数は層の種類によって異なります：

• 高密度層 (Dense Layers)

  • KV キャッシュのための追加スペースが必要です。
  • 理由：各高密度（全注意力方式）層は、アクティブなリクエストに含まれるすべてのトークンのキーとバリューを格納する必要があるためです。
  • 結論：一枚のウーファーには高密度層を 一つだけ配置し、残りの SRAM はその KV キャッシュに充てることになります。

• 線形注意力層 (Linear Attention Layers)

  • KV キャッシュ用の追加スペースは不要です。
  • 理由：従来のようにすべてのトークンのキーとバリューを格納するのではなく、線形注意力層ではリクエストごとに固定サイズの小さな状態情報を保ちます（コンテキスト長の影響を受けません）。
  • 結論：一枚のウーファーに 2 つの線形層（$2 \times 16 \text{ GB} = 32 \text{ GB}$）を収める余裕が生まれます。

したがって、Kimi K3 の 69 つの線形層と 24 つの高密度層を考慮すると：

• 線形層: $69 \div 2 \approx 35$ ウーファー必要
• 高密度層: 24 ウーファー必要
• 合計: $35 + 24 =$ 59 ウーファー が要件となります。

#3 ウーファー同士の接続方法

Cerebras のモデル実行はパイプライン方式を採用しています。Cerebras コンパイラーがモデル層をウーファー上の領域にマッピングした後、ランタイムがトークンがウーファー間を移動する経路を定義します。

• データ転送の最適化: 超低遅延を実現するためには、ウーファー間でのデータ転送にはアクティベーションのみを送り込むことが必要です。
• 実装方法: イーサネット上の RDMA (Remote Direct Memory Access) を使用して実現可能です。
• パフォーマンス: この方法は、1 つのホップあたり約 2 マイクロ秒 の遅延しか生じません。

特に重要なのは、各 Cerebras ウーファーが 44 GB のオンチップ SRAM を有している一方で、各モデル層は仅需约 16 GB の容量しか必要ないという点です。その結果、多くの場合、モデルの重みは一切移動させず、層をウーファー間で分割する必要もありません。アクティベーションだけが次のウーファーへ渡されることになります。

#4 1 つのリクエストをどのように扱うか

ウーファーが接続され、モデルレイアウトが決まった現在、各ウーファーをアセンブリラインの一段階とみなすことができます：

1. 固定重み: 各段階のモデル重みは固定されたままです。
2. パイプライン処理: リクエストの中間結果が層の段階を通って移動します。
3. フロー例:
   • ウーファー 1 がモデル層 1–2 を処理し、そのアクティベーションをウーファー 2 に送り、
   • ウーファー 2 は層 3–4 を実行して結果をウーファー 3 に渡すという流れが続き、
   • 最終的なウーファーが次のトークンを生成します。

#5 多数のリクエストをどのように扱うか

ここには一般的に見られる誤解があります。「トークンが各ウーファーを経由しなければならず、順番に待たされるのであれば、各ウーファーは idle（待機）状態になり、システム全体はバッチサイズ 1 のみで動作することになるのではないか」という疑問です。

答えは「いいえ」です。

• パイプライン効率: 一度に一個のリクエストだけをラインに通して完了を待つまで次のリクエストを開始すると、パイプラインの利用率は非常に低くなります。
• 並列処理戦略: 代わりに、異なるリクエストを用いてパイプライン全体を常に満たし続けます。モデルがすでにパイプラインの段階に分割されているため、各段階は同時に異なるリクエストを処理できます。
  • 例: 段階 3 がリクエスト A のトークンを処理している間、段階 2 はリクエスト B を、段階 1 はリクエスト C をそれぞれ処理します。本例では各段階が「層」そのものです。

微バッチ (Micro-batch) の活用 実際の生産環境では、各段階は単一のリクエストではなく、**微バッチ（マイクロ・バッチ）**と呼ばれる小さなリクエストグループを処理することもできます。

• 進行中のリクエスト数は、「段階数 × 微バッチサイズ」にほぼ等しくなります。
• トレードオフ:
  • 微バッチサイズを小さくすると → 個々のリクエストの処理速度が向上する。
  • 微バッチサイズを大きくすれば → トータルのスループット（全体処理能力）が増加する。

#6 同時に扱えるリクエストの最大数

オンチップメモリに割り当てられる KV キャッシュの容量が、同時並行可能であるリクエスト数の上限を決定します。進行中の各リクエストは、高密度層搭載の各ウーファーに対して独自の KV キャッシュを必要とするため、オンチップメモリのサイズが並行可能なリクエスト数の天井を設定します。

前述の通り、KV キャッシュの要件計算は高密度層に限定されます。44 GB ウーファーのうち既に一つの高密度層を配置している場合、残りの空き容量（KV キャッシュ用）は以下の式で算出できます：

available_kv_cache_per_chip = (total_chip_capacity_gb) - (size_of_one_dense_layer_in_gb)

このケースでは：

• ウーファー全体のストレージ容量: 44 GB
• 高密度層のサイズ: 約 16 GB
• 利用可能な KV キャッシュ: $44 \text{ GB} - 16 \text{ GB} = 28 \text{ GB}$

各 44 GB ウーファーあたりの利用可能な KV キャッシュ容量を算出し、それを単一のリクエストが占めるキャッシュ容量で割ることで、その構成でサポートできる同時リクエスト数を求めることができます。

具体的には、256,000 トークンのリクエストが占めるキャッシュ量をまず計算し、その結果を各ウーファーの空き容量で除算することで、システム全体として同時に処理可能なリクエスト数が得られます。

同時リクエスト数とは、ある時点でパイプラインを通過している同時リクエストの総数を指します。GPU バッチとは異なり、これらのリクエストは互いを待つことなく、パイプラインを連続的にストリーミングのように流れます。

パフォーマンス評価指標

もちろん、並行度やバッチサイズだけではインフェンシングシステムの効率性を正確に評価することはできません。インフェレンスシステムのスループットを評価する際により有意義な指標は、**「同等の出力生成速度下での単位電力あたりのトークン総スループット（例：メガワット当たり秒間トーク数）」**です。

---

3 兆パラメータを超えたモデルへの拡張性について

このアプローチは、より大きなモデルにも適用可能です。

1. メモリ計算: ウェイトとリクエスト状態に必要なメモリを計算します。
2. 分布戦略: モデルをウーファー間で分布させ、パイプラインとして接続します。
3. スケーリング: 追加される各ウーファーは演算能力とオンチップメモリの両方を提供するため、単一のチップでは処理できない容量のモデルも収容できるようになります。

Kimi K3 の事例を通じて、シラブレイス・テクノロジーについてご理解を深めていただき光栄です。Cerebras 上でモデルをデプロイしたい、あるいは当社のインフェレンスクラウドを用いた構築にご興味をお持ちいただければ幸いです。

次のステップ

• 無料 API で始めたい方: cloud.cerebras.ai
• 営業チームまでお問い合わせ: sales@cerebras.ai

---

デザイン：ヘーリー・チャン
レビューとフィードバックのご協力に、アタルワ・タルパデ、ジェンウェイ・ガオ、アンジェラ・イェン、ジェシカ・リュー、ジョイス・エル、エマ・コール、ロハン・グプタのみなさまに感謝申し上げます。