単一ベンチマークを超えて Google TPU 推論の経済性を評価する

Ironwood の外部ベンチマークは、Google TPU を候補に入れる理由にはなりますが、普遍的な勝者を示すものではありません。InferenceX は選択されたモデルと運転点で有利な価格性能を報告する一方、高並行時の最初のトークンまでの時間では別の判断が必要であることも示しました。ここから導くべき結論は全面移行ではなく、戻せる比較実験です。

先にサービスの形を固定する

入力・出力トークン数、並行数、最初のトークンと生成中の遅延目標、精度、リージョン、エラー予算を記録します。8k 入力と 1k 出力の試験は参考になりますが、長い文脈を繰り返し使うコーディングエージェント、待ち時間に敏感な音声、総スループットを優先するバッチ処理を代表しません。モデル形状が安定し大量に流れる処理は TPU 試験に向きます。頻繁にモデルを替える処理や厳しい対話遅延を持つ処理には、より強い証拠が必要です。

コスト曲線は仮説として扱う

「一ドル当たりが高い」という見出しだけで判断しません。並行数ごとにスループット、最初のトークン、トークン間遅延、テール遅延を取り、モデル、精度、品質目標、ルーティングを揃えます。バッチを大きくすると token 単価は下がっても、利用者が待てない体験になることがあります。総保有コストも利用率、電力、ネットワーク、予約容量、地域価格で変わります。Google 内部の経済性を顧客価格と混同せず、楽観値と保守値を残します。

運用の再現性も測る

公平な比較ではサービング方式もそろえます。GPU 側だけがプロンプト処理と生成を分け、TPU 側が集約方式なら、結果はチップだけでなくソフトウェア成熟度を表します。キャッシュ、障害時の再試行、オートスケール、バージョン復旧を記録し、長い待ち時間を確認します。各候補モデルについて、使える精度とリージョン容量、量子化や待ち行列による品質変化も確認します。さらに同じ要求集合、ソフトウェア版、失敗例を残し、次のコンパイラやモデル更新後にも差の原因を追えるようにします。

共通の判断基準を決める

試験は基盤チームのグラフだけで終えず、製品、財務、信頼性の担当者と最低品質、最大待ち時間、月額上限、障害時の縮退を合意します。少量トラフィックを一週間以上流し、ピーク、低負荷、キャッシュの冷温、モデル更新を含めて観察します。どれかの条件を満たさなければ、目標値を変えて成功とせず、元の基盤を維持します。試験条件と測定結果を保存しておけば、次の容量交渉や設計レビューにも使えます。

ソフトウェアを受け入れ条件にする

CUDA のツール、カーネル、診断、運用経験には価値があります。TorchTPU と SGLang は PyTorch チームへの入口を広げますが、推測デコード、分離サービング、キャッシュ退避、多ターンエージェントには未成熟な部分があり得ます。目的モデルを特別なカーネル開発なしで動かせるか、遅い要求を追跡し、障害から戻し、性能低下を再現できるかを試験します。節約が常時の専門家作業で消えるなら、再現可能な節約ではありません。

リージョン、容量、監視、セキュリティ、更新速度、退出手段も同時に確認します。モデル一つ、負荷クラス一つ、固定トラフィック、明確なロールバックで始め、完了リクエスト単価、品質、SLO、運用時間、復旧を測ります。TPU 8i の計画は将来の選択肢であり、今の Ironwood の結果を上乗せする根拠にはしません。

定期的に再測定する

モデル、コンパイラ、サービングソフト、リージョン容量は変化します。事業負荷とコスト仮定を保存し、更新のたびに同じ試験を行うことで、一度のプレビューを恒久的な結論にしません。