AIの裏側で働く三兄弟、『CPU・GPU・TPU』――プロンプトから回答までをたどってみた

1. はじめに――「GPUが足りない」って、何が足りないの？

最近、こんな会話をよく耳にします。

「生成AIのサービス、GPUが足りなくて増強待ちらしいよ」 「GoogleはTPUで動かしてるんでしょ？」

うなずきながらも、内心こう思っている方は多いのではないでしょうか。

そもそもCPUと何が違うのか。 TPUって結局なんなのか。 そして、私たちがチャットにプロンプトを打ち込んでから回答が返ってくるまで、裏側でどのチップが何をしているのか......。

今回は、この「AIの裏側で働く三兄弟」を整理してみます。

この章の結論：AIの性能の話は、チップの役割分担の話でもある。

2. 三兄弟の性格――CPU・GPU・TPU

まず、たとえ話から。

• CPUは、何でもこなす少人数の熟練職人チーム
• GPUは、同じ作業を一斉にこなす大人数の作業員
• TPUは、特定の製品だけを作る専用工場の生産ライン

CPU（Central Processing Unit） はコンピュータの司令塔です。 コア数は少なめですが、一つひとつが賢い。 条件分岐や複雑な制御、順番に依存する処理を素早く片づけます。

GPU（Graphics Processing Unit） はもともと画像描画用でした。 何千もの小さなコアで、同じ計算を大量のデータに一斉に当てるのが得意です。 この形がニューラルネットワークの行列演算にぴったり合い、AIの主役になりました。

TPU（Tensor Processing Unit） はGoogleが機械学習専用に作ったチップです。 行列の掛け算・足し算だけに的を絞り、汎用性と引き換えに効率を手に入れています。

この章の結論：汎用性を取るか、効率を取るか――三兄弟はその振り幅の上に並んでいる。

3. TPUが速い理由――「メモリーとのやり取りがない」は誤解

「TPUはメモリーとのやり取りが少ないから速い」

こう聞くと、まるでメモリーを使わないチップのように感じるかもしれません。 でも、そうではありません。

TPUにも、チップの外に大容量のHBM（高帯域メモリー）があり、チップの中には小さく高速なオンチップバッファがあります。 データは「HBM → バッファ → 演算器 → バッファ・HBM」と、ちゃんと行き来しています。

ポイントは、一度読み込んだデータを何回使い回せるかです。

TPUの演算器は「シストリックアレイ」という格子状に並んでいます。 読み込んだ値は、演算器から隣の演算器へバケツリレーのように受け渡され、その途中で何度も掛け算・足し算に使われます。 途中結果もいちいちメモリーに戻しません。

その結果、TPUの速さは二つの要因の掛け算で生まれます。

1. 演算器を大量に詰め込めている――汎用機能を削り、低精度の数値を使って演算器を小さくした
2. その演算器がデータ待ちで止まりにくい――使い回しでメモリー待ちが減り、稼働率が高い

片方だけでは足りません。 演算器を増やしてもデータが届かなければ宝の持ち腐れ。 待ち時間がなくても演算器が少なければ速くならない。

さらに、メモリーアクセスは計算そのものより電力を食います。 だからTPUの強みは、特に電力あたりの性能で目立つのです。

ただし、効くのは大きな行列演算が中心の処理だけ。 巨大なモデルでは、TPUでも結局メモリー帯域が足を引っ張る場面があります。

この章の結論：「メモリーを使わない」のではなく、「1回の計算あたりのメモリー往復が少ない」。

4. 学習と推論、結局どれを使うのか

「学習はGPU、推論はTPU」のような明確な線引きは、実はありません。 どちらの用途にも、GPUとTPUの両方が使われています。

選ぶ基準は、用途よりも環境・ソフトウェア・コストです。

GPUは今も主流です。 CUDAを中心としたソフトウェア環境が成熟していて、PyTorchなど主要なフレームワークもGPU前提で作られていることが多い。 市販品として買えて、主要クラウドのどこでも借りられます。

TPUはGoogle関連を中心に使われています。 Google自身のAIモデルはTPUで学習・推論されていますし、Google Cloudを使う企業や研究機関も採用しています。 大量のチップをつないで使う大規模な学習や、効率を突き詰めたい大口ユーザーにとって有力な選択肢です。

学習と推論では、重視されるポイントが少し違います。

• 学習：膨大な計算を何週間も回す。大量のチップを高速につないで並列に動かせるかが勝負
• 推論：世界中のリクエストに24時間応え続ける。電力あたり・コストあたりの効率がより重要

推論の世界では、各クラウド事業者の独自チップや、スマホ・PCに載るNPUなど、推論専用チップも広がっています。

そしてCPU。 大規模なモデルの計算そのものにはほとんど使われませんが、データの前処理や全体の制御を担う「裏方」として欠かせません。

この章の結論：迷ったらGPU、Google Cloudで大規模にやるならTPUも有力――そしてCPUは常に裏方にいる。

5. プロンプトから回答まで――6つのステップと担当チップ

では、私たちがチャットに質問を打ち込んでから答えが返るまで。 その間に、三兄弟はどう動いているのでしょうか。

大きく分けると、前後の文字や通信の処理はCPU、モデル本体の重い計算はGPUまたはTPUです。

1. プロンプト受付（CPU）
   • サーバーが文章を受け取る。通信処理や、どのリクエストをまとめて処理するかのスケジューリングもCPUの仕事
2. トークン化（CPU）
   • 文章を「トークン」に区切り、番号（トークンID）に変換する。辞書を引きながらの文字列処理で、計算は軽い
3. プリフィル（GPU/TPU）
   • 入力トークン全部をまとめて一度にモデルに通す。大きな行列演算になり、演算器をフル稼働できる
   • 計算途中の情報（KVキャッシュ）をGPU/TPUのメモリーに保存しておく
4. デコード（GPU/TPU、進行管理はCPU）
   • 次のトークンを1つずつ生成し、それを入力に加えてまた次を作る。前の結果がないと次が計算できない
   • 多数のユーザーのリクエストを束ねて同時に計算する工夫も。その束ね方や終了判定はCPUが受け持つ
5. デトークン（CPU）
   • トークンIDを文字に戻す。日本語では1文字が複数トークンにまたがることがあり、文字が完成するまで待つといった細かい処理も必要
6. レスポンス（CPU）
   • できた文字をユーザーへ送る。画面に文字が少しずつ流れてくるのは、1トークンごとに5と6を繰り返しているから

この章の結論：CPUは「受付と翻訳と配送」、GPU/TPUは「考える」担当。

6. プリフィルとデコードは、性格が正反対

同じGPU/TPUの上で動くのに、この二つはまるで別物です。

デコードでは、1トークン作るたびに、モデルの重み全体とKVキャッシュをメモリーから読み直します。 計算そのものより「読み込み待ち」が支配的になる。 3章でお話しした「結局メモリー帯域が足を引っ張る」場面とは、まさにここのことです。

そこで最近は、プリフィル用とデコード用で別々のチップ（またはチップ群）に処理を分ける構成も使われ始めています。 得意分野の違う作業員を、別々の現場に配置するイメージですね。

この章の結論：AI推論の速さは「計算の速さ」と「メモリーの速さ」の二本立てで決まる。

7. 明日からできること――この知識をどう使うか

「チップの話は、インフラ担当の人の話でしょ？」

いえいえ。 AIを使う側、AIを組み込む側にも、すぐに役立つヒントがあります。

1. 応答の遅さを二つに分けて見る
   • 「最初の1文字が出るまで」が遅いならプリフィル側、「文字の流れ」が遅いならデコード側を疑う
2. 入力を必要十分に絞る
   • 長すぎるプロンプトや、使わない資料の貼り付けはプリフィルを重くする
3. 出力の長さと形式を指定する
   • デコードは1トークンずつ。出力が長いほど、そのまま時間がかかる
4. 共通の前置きは先頭にまとめる
   • システムプロンプトなど毎回同じ部分を先頭に置くと、計算結果を再利用する仕組み（プロンプトキャッシュ）の恩恵を受けやすい
5. ローカルでAIを動かすなら、メモリーを見る
   • モデルを載せきれる容量と、デコードを左右するメモリー帯域が、体感速度に直結する

この章の結論：裏側の仕組みを知ると、「なぜ遅いのか」に当たりがつけられる。

8. 結論

CPU、GPU、TPU。 三兄弟は、どれが一番強いかを競っているわけではありません。

• CPUは、受付・翻訳・配送を担う司令塔
• GPU/TPUは、プリフィルとデコードという重い計算を引き受ける力持ち
• そして性能の鍵は、演算器の数だけでなく、メモリーとどう付き合うかにある

私たちがチャット画面で何気なく眺めている「文字が流れてくる様子」。 その一文字一文字の裏で、CPUとGPU/TPUがバトンを渡し合い、メモリーとの往復をなんとか減らそうと工夫を重ねています。

次にAIの応答を待つとき、ほんの少しだけ、その裏側を想像してみてください。

さて、みなさんの現場では。 AIの「遅さ」に悩んだとき、それがプリフィル側なのか、デコード側なのか......切り分けたことはありますか？