Googleが2026〜2027年にかけて、アラバマ州ジャクソン郡のデータセンターキャンパスに15億ドルを投資するというアナウンスを読んだ。
そのサイト、もともと石炭火力発電所の跡地らしい。2019年から稼働してて、今回の拡張で電力・インフラのコストはGoogle自身が全額負担するという話だった。
最初は「ふーん、でかい数字だな」くらいで流しかけたんだけど、ちょっと待てと思って。
これ、インフラ増強の話なんだよな。つまりGeminiを含むGoogle系APIのキャパシティが増えるということでもある。
自分が今ちょうどGemini APIをいじってるタイミングだったので、もう少し真剣に読んだ。
個人開発でLLMのAPIを叩くとき、一番ハマるのがコストとレート制限の読み違いだ。
OpenAIでも一度やらかしたことがある。自作のRAGアプリで、チャンク数を細かく取りすぎてembeddingの呼び出し回数が爆発した。月の途中でフリープランの枠を使い切って、そこからのレスポンスが軒並み429になった。えぐい体験だった。
あのとき思ったのは、プロバイダのインフラ投資の規模と、自分のアプリの設計が連動してるってことだ。
キャパシティが潤沢なプロバイダほど、レート制限のポリシーが緩くなる傾向がある。
逆に投資が追いついてないと、ユーザー側がバックオフのロジックを丁寧に書かないとすぐ詰まる。
今回のGoogleの15億ドルが何を意味するかというと、Geminiファミリーのスループットがこれから上がっていく可能性が高いということだ。
それは自分のコードに直接影響する話として読める。
現在個人開発で動かしてるAPIクライアントは、こんな感じのリトライ設定になってる。
これで今は乗り切ってるけど、exponential backoffの上限を固定してるのがちょっと雑だ。
Geminiのレート制限はOpenAIと違ってtier昇格のペースが異なるし、分あたりのリクエスト数(RPM)とトークン数(TPM)の制限が別管理になってる。
その辺を意識した設計に直したい。
flashモデルをメインに据えてコストを抑えながら、proに切り替えるロジックをfallbackとして持たせるのが今考えてる設計だ。
インフラが増強されてキャパシティが増えたとしても、自分のアプリ側のコスト意識は崩したくない。
Googleはこのアナウンスで、アラバマ州内で13万人以上のデジタルスキルトレーニングを実施してきた実績も言及してた。
2百万ドルのEnergy Impact Fundも立ち上げるらしい。そういうコミュニティ側の話は正直あまり興味がわかなかったんだけど、インフラ投資のスケール感は目に留まった。
彼女に「Googleがすごい投資してるって話読んだ」と話したら、「どのくらい?」と聞かれた。
「15億ドル」と答えたら「意味わからん単位だね」と言われた。そのとおりだと思う。
自分もピンとこないけど、要するにAPIのキャパシティがしばらく増え続けるということとして受け取ってる。
今やってるプロジェクト、来年くらいには少し負荷がかかる使い方をしたいと思ってた。
そのタイミングに向けて、リトライまわりとモデル選択の設計を今のうちに整えておく。
キャパシティが増えるのを待つより、コードを先に直しておくほうが自分の性に合ってる。
そのサイト、もともと石炭火力発電所の跡地らしい。2019年から稼働してて、今回の拡張で電力・インフラのコストはGoogle自身が全額負担するという話だった。
最初は「ふーん、でかい数字だな」くらいで流しかけたんだけど、ちょっと待てと思って。
これ、インフラ増強の話なんだよな。つまりGeminiを含むGoogle系APIのキャパシティが増えるということでもある。
自分が今ちょうどGemini APIをいじってるタイミングだったので、もう少し真剣に読んだ。
APIコストの話をするとき、インフラのスケールは無視できない
個人開発でLLMのAPIを叩くとき、一番ハマるのがコストとレート制限の読み違いだ。
OpenAIでも一度やらかしたことがある。自作のRAGアプリで、チャンク数を細かく取りすぎてembeddingの呼び出し回数が爆発した。月の途中でフリープランの枠を使い切って、そこからのレスポンスが軒並み429になった。えぐい体験だった。
あのとき思ったのは、プロバイダのインフラ投資の規模と、自分のアプリの設計が連動してるってことだ。
キャパシティが潤沢なプロバイダほど、レート制限のポリシーが緩くなる傾向がある。
逆に投資が追いついてないと、ユーザー側がバックオフのロジックを丁寧に書かないとすぐ詰まる。
今回のGoogleの15億ドルが何を意味するかというと、Geminiファミリーのスループットがこれから上がっていく可能性が高いということだ。
それは自分のコードに直接影響する話として読める。
今のコードで何を変えるか
現在個人開発で動かしてるAPIクライアントは、こんな感じのリトライ設定になってる。
import time
def call_with_backoff(fn, max_retries=5):
for i in range(max_retries):
try:
return fn()
except RateLimitError:
wait = 2 ** i
time.sleep(wait)
raise Exception("Max retries exceeded")これで今は乗り切ってるけど、exponential backoffの上限を固定してるのがちょっと雑だ。
Geminiのレート制限はOpenAIと違ってtier昇格のペースが異なるし、分あたりのリクエスト数(RPM)とトークン数(TPM)の制限が別管理になってる。
その辺を意識した設計に直したい。
# 将来的にconfig化したいイメージ
gemini:
model: gemini-1.5-flash
rpm_limit: 15
tpm_limit: 1000000
retry:
max_attempts: 6
base_wait_sec: 1
max_wait_sec: 60flashモデルをメインに据えてコストを抑えながら、proに切り替えるロジックをfallbackとして持たせるのが今考えてる設計だ。
インフラが増強されてキャパシティが増えたとしても、自分のアプリ側のコスト意識は崩したくない。
15億ドルのニュースがエンジニアの日常に落ちてくるまで
Googleはこのアナウンスで、アラバマ州内で13万人以上のデジタルスキルトレーニングを実施してきた実績も言及してた。
2百万ドルのEnergy Impact Fundも立ち上げるらしい。そういうコミュニティ側の話は正直あまり興味がわかなかったんだけど、インフラ投資のスケール感は目に留まった。
彼女に「Googleがすごい投資してるって話読んだ」と話したら、「どのくらい?」と聞かれた。
「15億ドル」と答えたら「意味わからん単位だね」と言われた。そのとおりだと思う。
自分もピンとこないけど、要するにAPIのキャパシティがしばらく増え続けるということとして受け取ってる。
今やってるプロジェクト、来年くらいには少し負荷がかかる使い方をしたいと思ってた。
そのタイミングに向けて、リトライまわりとモデル選択の設計を今のうちに整えておく。
キャパシティが増えるのを待つより、コードを先に直しておくほうが自分の性に合ってる。