昨日、ローカルで微調整モデルを走らせてたんだけど、VRAMが16Gで、最初は大丈夫だったんだけど、20ラウンド走らせたらいきなりOOMでクラッシュしちゃった。モニタリングを見たら、キャッシュのフラグメンテーションでVRAMが空っぽになってて、再起動しないとダメだった。1時間もかかっちゃった。
この件で、OpenLedgerのOpenLoRAのKVキャッシュ管理にちょっと注目してみた。あれは動的な移動メカニズムを設計してて、特定のGPUのキャッシュが上限に近づくと、自動でリクエストの一部を他のカードにまとめて移動させるんだ。しかも、移動中も推論状態を保持して、再計算しなくて済む。
調べたら、使ってるのはセグメント化されたガザー行列-ベクトル乗算で、人間の言葉で言うと、異なるリクエストのKとVベクトルをセグメントごとに保存して、必要な時にブロック単位で取得するって感じ。全体を一緒に移動させるんじゃなくて、こうすることで移動するデータ量がかなり少なくなる。
ホワイトペーパーには新しいリクエストR_newが、バッチサイズの上限とメモリ要件を満たすGPUに割り当てられるって書いてあって、最適なものを選ぶんだ。これ、ランダム割り当てやラウンドロビンより賢いよ。ラウンドロビンだと、一つのカードがパンパンになって、他のカードが空いてるのに$OPEN 。
自分も似たような問題に遭遇したことがあって、推論サービスを走らせる時に一番厄介なのは、計算力が足りないことじゃなくて、VRAMのフラグメンテーションなんだ。残ってるカードには空きがあるのに、フラグメンテーションで新しいリクエストが入らないから、マシンを追加しなきゃいけなくて、金がかかる。OpenLoRAのこのセグメントストレージと動的移動で、理論的にはフラグメンテーションを利用できるから、VRAMを節約できれば、コストも節約できる。
でも、言っておくけど、移動ロジックが論文ではうまくいっても、実際の生産環境ではどうなるかわからない。頻繁な移動は追加のレイテンシを引き起こす可能性があるし、高い同時接続数の中でスケジューラー自体がボトルネックになることもある。ビットコインのブロックスペースは限られてるし、イーサのガス代は高負荷時に暴騰するから、これらはスケジューリングの問題が解決されてないせいなんだ。OpenLoRAが実際のトラフィックに耐えられるかどうかは、数ヶ月走らせてからホワイトペーパーの続報を待つ必要がある。
主ネットのモニタリングパネルを注視するつもり。移動のレイテンシが5ミリ秒以内に抑えられたら、いくつかの小さなモデルを走らせてみようと思ってる@OpenLedger #OpenLedger