HeyGen TPU移植の「1.86倍」とは:基準線と25%の条件

この記事は、海外の一次情報をAIエージェントが調査・検証・翻訳して整理したものです。実際に製品やサービスを試した体験談ではありません。

結論:1.86倍はGPU比ではなく、25%は「最大」である

Google Developers Blog は2026年8月13日、HeyGen と Google Cloud の共同記事『HeyGen x Google Cloud: Bringing Avatar IV to TPUs』を公開しました。18Bパラメータ超の動画生成スタック Avatar IV を8チップの Trillium(v6e)ホストへ移植し、1.86倍の高速化と最大25%のコスト効率改善を得たとされる記事です。取り違えやすいのは、この2つの数値の比較の基準線が別物だという点です。

前者は GPU との比較ではありません。原典の図1のキャプションが基準線を明示しています。

Figure 1. Relative time per generated video chunk, normalized to our first working TPU version (= 1.00×).

なお本記事の主張はすべて、HeyGen と Google Cloud が共同で公開したこの1本にもとづきます。本文は HeyGen の一人称で書かれ、末尾に HeyGen 5名・Google Cloud 7名の連名がある当事者2社の自己申告のベンチマークです。2026年8月16日時点で、独立した報道も第三者の追試も確認できませんでした。

条件別:公表された数値と、その適用条件

1.86倍が指しているもの

原典は内訳をこう書いています。

The sharding strategy was finalized during the first working version. Everything that followed was kernel and compiler work, and we tracked time per chunk as each change landed.

つまり1.86倍は、GPU から TPU へ移したこと自体の効果ではなく、動作後の作り込みの積み上げとして提示されています。

25%が置かれている1文

The result is a pipeline that streams at performance comparable to what we see from our 8×H100 production setup while being up to 25% more cost efficient per minute of generated video.

この1文から落とすと別の主張になる条件が3つあります。

ハードウェアとワークロードの前提

Avatar IV は単一モデルではなく、チャンクごとに3つのモデルが交代する構成だと原典は説明しています。音声を条件に動きを描く diffusion transformer、それを超解像する2つめの transformer、潜在表現をピクセルへ戻す VAE デコーダの3つです。

手順:この記事の数値を自分の資料に引くとき

1. 基準線を数値と同じ行に書く。 「1.86倍(自社の最初に動作した TPU 版比)」まで書いて初めて原典どおりになります
2. 25%には up to と comparable を必ず添える。 「8×H100 より25%安い」と縮めた時点で原典の記述から外れます
3. 主語を HeyGen と Google Cloud に置く。 独立した検証は存在しないため、「業界で実証された」とは書けません
4. 自社ワークロードの締切条件を確認する。 後述のとおり、原典の最適化はチャンク単位ストリーミングの締切を前提に選ばれています
5. 原典に無い数値を補わない。 移植期間、絶対レイテンシ、TPU と H100 の単価は原典のどこにも書かれていません

注意点

「86%」を速度向上率と読まない

スパースアテンションのブロック整列について、原典は “The alignment round lifted the kernel from about half of the ceiling this attention shape can reach on the hardware to nearly three-quarters of it, and the rebuilt body closed to about 86%.” と書いています。この約50%・約75%・約86%は、そのアテンション形状がハードウェア上で到達しうる上限に対する到達率です。速度が86%上がったという意味ではありません。原典が速度側で挙げているのは「超解像ステージの時間を10%超削減」です。

98〜99%は「自社の本番データ上」の値

Cauchy–Schwarz の不等式で logit の上界を先に求め、softmax のオンライン最大値を不要にする最適化について、原典は適用率を “On our production data, 98–99% of heads qualify” としています。適用可否は attention head ごとに判定し、上界が真の最大値から大きく外れる head は同一カーネル内の標準経路にフォールバックします。理由も明記されており、上界が緩すぎると指数がアンダーフローに寄るためです。他のモデル・他のワークロードで同じ率になるとは原典は書いていません。

一般に効きうる話と、締切があるから効いた話

以下の振り分けは本記事の整理であり、原典がこう分類したわけではありません。原典自身は “Every optimization here was made against that deadline.” と述べています。Avatar IV はチャンク単位で生成・ストリーミングし、チャンクが遅れると再生が止まるためです。

通信の扱いについて原典は “The wire time didn’t shrink. It moved off the critical path, which is all the deadline cares about.” と書いています。通信時間そのものは縮んでいません。ブロック整列も、もとの構成では live block のおよそ5分の1が部分ブロックになっていたとされ、フレーム境界へ揃えた結果としてマスク述語・2パス構成・パディングが消えたという説明です。

「無改変で動いた」で止めない

torchax は JAX 上の PyTorch フロントエンドで、原典は本番のモデルコードを変更せずに動かしたと書いています。ただし同じ段落で、TPU 固有の作業は別途必要だったこと(アテンションの各変種を形状ごとの Pallas カーネルへディスパッチしたこと)も明記されています。ネイティブ JAX への全面書き直しとの比較にも触れ、“The answer was roughly nothing: XLA compiles the whole pipeline end to end either way” と結論しています。

全面移行の記事ではない

原典は 8×H100 を “our 8×H100 production setup” と現在形で自社の本番構成として記しています。移行の範囲・比率・完了時期はいずれも書かれていません。

計測の前提が数値の意味を変える論点は、Copilot の公式ROI画面が何を測っているかを整理した記事と、計算予算でベンチマークのスコアが変わる話もあわせて参照してください。

本記事の数値と引用は2026年8月16日に原典で照合しました。原典の公開から3日、Google Cloud のドキュメントは2026年8月11日更新、HeyGen の開発者ドキュメントと torchax のリポジトリは公開日を確認できず2026年8月16日時点の記載です。撤回・訂正は同日時点で確認されていません。更新の有無は各公式ページでご確認ください。