vLLM
読み: ブイエルエルエム
vLLMとは高速推論の仕組み
GPUコストと応答速度のジレンマを根本から解消するvLLMの設計思想
UC Berkeleyの研究者らが開発したオープンソースの推論エンジンである。自社でLLMを動かそうとした人間なら必ず直面する壁がある。応答の遅さと、それを金で解決しようとした時のNVIDIA製GPUの目玉が飛び出るような請求書である。
モデルのパラメーター数が70Bを超えると、A100を複数枚並べてもユーザーの入力待ちでリソースが枯渇する。
vLLMはこのスループットの低さを根本から叩き直した。バッチ処理の最適化により、同じハードウェアでも数倍のリクエストを捌けるようになる。スピードとコストのトレードオフに悩む現場にとって、この性能向上は無視できない。
PagedAttentionが解決するGPUメモリの無駄遣い
なぜ従来の推論は遅かったのか。原因はKVキャッシュのメモリ管理にある。
生成されるテキストの長さは事前には分からない。だから従来のシステムは最大長に合わせてGPUメモリを確保していた。結果としてメモリの6割以上が使われないまま予約され、他のリクエストをブロックする。
ここでPagedAttentionが登場する。
メモリを固定長ではなく、OSのページングのように細かなブロック単位で動的に割り当てる。これによりメモリの無駄を1桁台まで削り落とした。同時に処理できるリクエスト数が跳ね上がる。現場のインフラ担当からすれば救世主に見えるだろう。
法務や経理の大量テキスト処理を支える周辺エコシステム
実際の業務でどう使うか。法務部門での契約書レビューや、経理部門での膨大な請求書データの照合を想像してほしい。
数万文字のコンテキストを連続で処理させる場合、OpenAIのAPIではコストが跳ね上がる。そこでLlama 3などのオープンモデルを自社環境にデプロイするわけだが、単体では動かない。
Hugging Faceからモデルを落とし、vLLMを立ち上げる。それをRay Serveで分散処理させ、LlamaIndex経由で社内データベースと繋ぐ。
ただ、この環境構築は一筋縄ではいかない。CUDAのバージョン依存やライブラリの競合で、環境構築だけで数日溶かすエンジニアを何人も見てきた。
自社専用の推論環境を構築すべきかの境界線
結局のところ、vLLMを導入すべきか。
コンプライアンスの観点でSaaSにデータを投げられない企業なら、オンプレミスでの構築は避けられない。その際、vLLMはインフラコストを抑える強力な武器になる。
だが、運用には専任のインフラエンジニアが要る。モデルのアップデートに追従し、GPUの熱暴走に怯えながらサーバーを監視する日々である。
APIの従量課金を受け入れるか、自社運用の泥臭さを引き受けるか。
どちらが正解かは、扱うデータの機密性と処理量によって変わる。インフラの維持費とAPIの利用料を天秤にかけることになるが、判断が分かれるところである。
当社の見解
モデルを軽くする技術は、論文のベンチマークでは「精度ほぼ変わらず」と書かれることが多い。しかし実務では違う。当社がVRAM 12GBでローカルLLMを動かす中で分かったのは、量子化の方式によって日本語の出力品質が大きく変わるということだ。数値上の精度低下が0.5%でも、日本語の自然さが体感で変わるケースがある。英語のベンチマークで高得点のモデルが日本語では使い物にならないこともある。マーケティングの分析がライティング業務では使い物にならないということもある。AIはモデルごとに得意不得意な分野がある。同じ名前がついているモデルでも数字が多い方がすべての用途において精度が高いということはない。数字が古いモデルや小さいモデルでも、用途によっては大容量モデルを超えることがある。技術系ブログに書いてあるベンチマーク結果を鵜呑みにせずに、実際に業務で使い検証を行って比較検討してから選ぶことをおすすめする。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。