【ITニュース解説】The Rounding Error That Stops the Machine

大規模言語モデル（LLM）の技術は近年目覚ましい進歩を遂げ、その裏側では多くのシステムエンジニアがより高速で効率的なシステム構築に尽力している。しかし、システム全体が速くなればなるほど、これまで意識されなかった部分がボトルネックとなり、全体の性能を阻害する「隠れたコスト」が表面化することがある。今回のニュース記事は、まさにそのような現象を扱っており、特にLLMの運用において、テキストをコンピュータが処理できる単位である「トークン」に変換する「トークン化」という比較的単純な処理が、なぜかシステム全体の足を引っ張る大きな問題になっていることを指摘している。

トークン化とは、私たちが普段使う文章を、コンピュータが扱いやすい数字の並びや記号のまとまりに分解する工程だ。例えば、「こんにちは、世界！」という文章は、「こんにちは」「、」「世界」「！」といったトークンに分割され、それぞれにIDが割り当てられる。LLMは、このトークン化された情報を元に学習したり、ユーザーの質問に答えたりする。これまで、このトークン化の処理は、モデルの学習や推論（答えを生成する）といった、大量の計算を必要とする主要な部分に比べれば、ごくわずかな時間で終わるものだと考えられてきた。高性能なGPU（Graphics Processing Unit）がモデルの「本当の仕事」である行列計算を圧倒的な速度でこなす陰で、トークン化はCPU（Central Processing Unit）が行う比較的負荷の低い作業として見過ごされがちだったのだ。

しかし、GPUが飛躍的に高速化し、LLMの推論処理が劇的に効率的になるにつれて、状況は一変した。システム全体が速くなった結果、今度はトークン化の遅さが目立つようになり、まるで自動車が高速道路を走る中で、料金所の支払いに時間がかかって渋滞するような状態が発生している。特に、多数のリクエストを同時に処理する場合や、非常に長い文章を繰り返し処理する場合に、このボトルネックが顕著になるという。

この問題の具体的な原因の一つは、Pythonというプログラミング言語の特性にある。LLMの多くのシステムはPythonで構築されており、トークン化のような一部の処理にはRustやC++といった高速な言語で書かれたライブラリが使われることもある。しかし、これらの高速なライブラリもPythonプログラムから呼び出されるため、Pythonが持つ「Global Interpreter Lock（GIL）」という仕組みが影響を及ぼす。GILは、Pythonのコードが一度に一つのスレッド（プログラムの実行単位）しか実行できないように制限するもので、これにより、複数のCPUコアがあっても、トークン化の処理はまるで一本道の渋滞のように、順番待ちになってしまうのだ。PyTorchのブログ記事によると、このGILがCPUでの処理に一本の「待ち行列」を作り出し、GPUは入力データが来るのを待ってアイドル状態になってしまうという。小規模なシステムでは気づかれなかったこの遅延が、GPUを最大限に活用するためにシステム構成が最適化された大規模な本番環境で、深刻な問題として浮上してきた。

さらに、近年注目されている「エージェント」と呼ばれる、複数のステップを経てタスクを解決するタイプのLLMも、この問題に拍車をかける。エージェントは、これまでの会話の履歴全体を記憶し、次の応答を生成する際にその履歴全体を再度トークン化する必要がある。時間が経つにつれて履歴はどんどん長くなり、その都度CPUで膨大な量のテキストをトークン化し直すことになる。一方、GPU側は、履歴の多くが以前に処理済みで結果がキャッシュされているため、以前ほど多くの計算を必要としない。つまり、CPUのトークン化処理の負荷は増え続けるのに、GPUの主要な処理の負荷は相対的に減っていくという、アンバランスな状況が生まれるのだ。

ジョージア工科大学の研究では、このCPU起因のボトルネックが、特にLLMの発展の方向性において最も深刻になることを発見した。この研究が示した重要な点は、もし十分なCPUリソースが確保されていれば、リクエストを送信してから最初の応答（トークン）が返ってくるまでの時間が、テストした構成において1.47倍から7.11倍も速くなるということだ。つまり、応答が始まるまでのあの短い「間」は、まさにCPUがテキストをトークンに分割していた時間だったのである。

この問題を解決するためのアプローチはいくつか提案されている。Hugging Faceは、自社のトークナイザーライブラリを再構築し、Apple M4 Maxチップでのテストでは、トークン化の処理速度が以前のバージョンよりも3倍から30倍高速になったと発表している。ジョージア工科大学の研究者たちは、より多くのCPUコアをシステムに割り当てることを提唱している。そして、PyTorchのブログ記事では、トークン化の処理そのものをPythonプロセスから完全に切り離す、というより根本的な解決策が提案されている。

ただし、これらの解決策や問題の診断については、まだ議論の余地がある。CPUのボトルネックはトークン化だけでなく、生成された出力を再構築したり、解析したり、GPUに命令を送信したりといった他の処理にも起因する可能性があると、ジョージア工科大学の研究は指摘している。また、PyTorchがGILを主犯としているのに対し、ジョージア工科大学の調査では、処理を別々のプロセスに分割してもGPUが十分にデータを受け取れないケースがあることを発見しており、GILだけが問題の全てではない可能性も示唆している。Hugging Faceの速度改善はまだシングルチップでのテスト結果であり、大規模なサービス環境でどれほどの効果があるかは不明だ。これらの情報源の公開時期も、ジョージア工科大学の論文を除いてはっきりしない点も、評価を難しくしている。

このような「速すぎるパーツに遅いパーツが追いつけない」という問題は、ITの歴史の中で何度も繰り返されてきた。例えば、ゲーム開発の世界では、CPUがグラフィックスカードに描画命令を送る速度が、グラフィックスカード自体の性能向上に追いつかなくなり、CPUが命令を出すのを待っている間にGPUがアイドル状態になるという問題が起きた。この解決策として、VulkanやMetalといった、CPUとGPU間の「会話」のオーバーヘッドを大幅に減らす新しいプログラミングインターフェースが開発された。

また、ストレージの分野でも同様の経験がある。SSD（フラッシュドライブ）が非常に高速になった際、オペレーティングシステムが個々のリクエストを処理したり、完了通知を受け取ったりする「手続き」が追いつかず、SSDの性能を最大限に引き出せない時期があった。この問題は、OSが処理完了の通知を待つのではなく、能動的にストレージの状態を見に行くような、根本的に異なる処理の「配置」によって解決された。グラフィックスの例ではCPUとGPUの間の「仲介役」をスリム化し、ストレージの例では「情報の受け渡し」のタイミングを変えることで解決したのだ。トークン化の問題も、この二つのアプローチ、つまり処理の効率化と配置の変更が同時に提案されている状況だ。

今回のトークン化の問題の根底にあるのは、システム設計の初期段階での判断が、後の大規模運用に大きな影響を与えるという教訓である。もしトークナイザーの処理を最初からPythonプロセスから独立させ、独自のサービスとして動かすような設計を採用していれば、GILの影響を受けることなく、より効率的にトークンを渡すことができただろう。しかし、それは開発者にとって、より複雑なコードベースと開発期間の延長を意味し、またPythonファイル一つで全てを完結させたい研究者にとっては利便性の低下を招いただろう。その結果、開発の容易さや短期的な利便性が優先され、その「ツケ」は、最終的に最大のシステムを運用する側に、GPUがアイドル状態になるという形で支払われることになった。今回の問題は、トークン化処理そのものの「丸め誤差」（わずかな誤差）ではなく、トークン化の処理をシステムのどこに配置するかという「設計上の決定」が引き起こしたものだと言える。