地理は、レイテンシの"動かせない床"だ

モデルを速くしても、量子化しても、距離だけは縮まらない。東京から各地への往復時間を測ると、東京5ms からケープタウン373ms まで、70倍以上の差が並んだ。

これは性能ではなく物理が決める床で、コードでは動かせない。しかも米国東の往復166msは、翻訳に許された予算（~180〜300ms）の55〜92%を食い尽くす——遠隔サーバーは、生成を0msにしても締め切りに届かない。

だから最大のレバーは性能ではなく配置だった。推論サーバーを米国から東京圏へ移すだけで、どのモデル最適化より大きい ~160ms が消えた。

第2回で、遅さの支配項が「距離（往復275ms）」に移ったと書いた。だが距離は、待ち行列や生成とは性質が違う。コードをいくら磨いても縮まらない。パケットは、物理的に移動しなければならないからだ。

では、その”床”は正確にどのくらいなのか。測ってみた。

世界各地までの、往復時間

いちばんきれいに測る方法は、世界中に均等に散らばった固定点を基準にすることだ。クラウド各社（ここではAWS）のリージョンは、まさにその役に立つ——世界の主要都市に、既知の場所として点在している。東京から各リージョンへの生の往復時間（RTT）を測ると、こうなった。

東京の中なら5ms。だが、太平洋を渡って米国東海岸まで行けば166ms、ヨーロッパは220ms超、地球の反対側の南アフリカ（ケープタウン）に至っては373ms——東京ローカルの70倍以上だ。この差は、サーバーの性能とは一切関係がない。パケットが、光ファイバーの中を物理的に往復するのにかかる時間だ。

（第2回で「距離275ms」と書いたのは、この生の距離166msに、途中のプロキシ層を経由する往復が上乗せされた本番経路の実効値だ。純粋な地理の距離だけを取り出すと166msになる。）

これは、下回れない「床」だ

ここが本質だ。166msという数字は、どんな最適化でも下回れない床である。

• モデルを速くしても、下回れない。
• 量子化しても、速いGPUに載せても、下回れない。
• 生成が0msになっても、166msは残る。

サーバーが遠い限り、翻訳が始まる前に、もう166msを使い果たしている。ネットワークの部分に関しては、性能をどう上げるかより、どこに置くかが効く。

しかも、この床は安定している。東京↔米国の往復を測り続けても、166ms前後（継続測定でも170ms台）——太平洋横断そのものは、ほとんど揺れない。以前「ネットワークが不安定だ」と思っていたジッターの正体は、地理ではなく、間に挟まっていたプロキシ層だった。距離は、予測可能で、動かない。だからこそ、最適化では消せない。

遠いサーバーは、崖を越えられない

深掘り記事「崖（cliff）」で書いた——字幕が間に合う締め切り——を思い出してほしい。OCRを終えたあと、翻訳に使える予算は、およそ180〜300msだった。

そこに、米国東海岸の往復166msを当てはめてみる。翻訳予算180〜300msに対して、往復166msだけで、その55〜92%が、1文字も訳し始める前に消える。つまり、遠いサーバーは、モデルがどれだけ速くても、崖の内側に入れない。物理的に無理なのだ。

逆に言えば、床を下げる方法はただ一つ——サーバーを近くに置くこと。実際、推論サーバーを米国から東京圏へ動かしたとき、私は約160msを削った。これは、私がそれまでにやったどんなモデル最適化よりも大きかった。

教訓

1. 地理的レイテンシは、物理が決める”床”だ。 東京5ms 対 ケープタウン373ms——70倍以上の差は性能と無関係で、しかも揺れない。予測可能な代わりに、最適化では消せない。
2. 床が予算を食い尽くすなら、モデル最適化をやめる。 往復だけで崖を越えているサーバーは、生成が0msでも間に合わない。打つ手は「置き場所」だけだ。
3. 性能より、配置。 速いサーバーを遠くに置くより、そこそこのサーバーを近くに置くほうが速い。だから地理は、レイテンシ最大のレバーになる。

これは、マニフェストの2番目の原則——「まだ、安く・速くできる」——の、最も物理的な現れだ。いちばん大きな勝ちは、モデルの中ではなく、地図の上にあった。

付録：生データ