powered by TechFeed
表示モード
Deep Dive

ShopifyがLLMのシステムプロンプトを4分の1に圧縮する「Gisting」を実装 — レイテンシ38%改善とGPU削減を同時に実現

9月4日、InfoQのSergio De Simoneが「Shopify Introduces Gisting: Compressing LLM System Prompts into Learned Tokens」と題した記事を公開した。ShopifyエンジニアリングチームがLLMのシステムプロンプトを圧縮する技術「Gisting」を実装し、推論コストの削減とスループット向上を実現した取り組みについて詳しく紹介されている。※なお、元記事のURLには「spotify」という文字列が含まれているが(spotify-gisting-llm-performance)、記事の内容はShopifyに関するものであり、URLのタイポと思われる。リンク先自体は正しく機能している。

9月4日、InfoQのSergio De Simoneが「Shopify Introduces Gisting: Compressing LLM System Prompts into Learned Tokens」と題した記事を公開した。ShopifyエンジニアリングチームがLLMのシステムプロンプトを圧縮する技術「Gisting」を実装し、推論コストの削減とスループット向上を実現した取り組みについて詳しく紹介されている。

※なお、元記事のURLには「spotify」という文字列が含まれているが(spotify-gisting-llm-performance)、記事の内容はShopifyに関するものであり、URLのタイポと思われる。リンク先自体は正しく機能している。


LLMの長大なシステムプロンプト問題をどう解くか

LLMをプロダクション環境で運用するとき、長いシステムプロンプトはそのままコストに直結する。トークン数が増えれば推論時間は伸び、GPUリソースの消費も増える。Shopifyはこの問題に対し、Gistingと呼ぶ手法で正面から取り組んだ。

Gistingの核心は、長い自然言語のプロンプトを「gistトークン」と呼ぶ少数の学習済みトークンに圧縮し、推論時にはその短いトークン列だけを使う、というものだ。重要なのは、モデルのコアウェイトを変更しない点である。埋め込み行列とトークナイザーに新しいgistトークンを追加するだけで、推論パイプラインに特別なアテンションマスクや専用エンコーダーは不要になる。

4:1圧縮で何が変わったか

Shopifyの内部エージェント「Sidekick GraphQL agent」のシステムプロンプトは約6000トークンあった。Gistingを適用した結果、これが1500 gistトークンに圧縮された(4:1の削減)。

350 RPM(リクエスト/分)の負荷下での計測結果は以下の通りだ:

指標 適用前 適用後
Time to First Token(中央値) 438ms 354ms
エンドツーエンドレイテンシ(中央値) 6.8s 4.2s
スループット 20.2 QPS 23.4 QPS

エンドツーエンドレイテンシは6.8秒から4.2秒へと約38%改善された。またスループットの向上(20.2→23.4 QPS)に加え、Shopifyは同一ワークロードをより少ないGPU数でこなすことにも成功している。記事ではこのGPU削減の実現を明示しており、タイトルが示す「GPUコスト削減」は上記のスループット改善とGPU台数削減の両面を指している。単なる応答速度の改善にとどまらず、インフラコストの削減という実利につながった点が重要だ。

Gistingの学習プロセス:Teacher-Studentアーキテクチャ

Gistingは、プロンプト圧縮の研究領域で知られるTeacher-Studentアーキテクチャを用いた2ステップの学習プロセスで構成される。この手法の代表的な先行研究としては、Mu et al.(2023)の「Learning to Compress Prompts with Gist Tokens」が挙げられる。Shopifyの実装はこうした研究知見を実プロダクションに適用したものだ。

  1. Teacherパス:元の完全なプロンプトでモデルを実行し、「teacher logits」(応答の確率分布)を取得する。
  2. Studentパス:gistトークンだけでモデルを実行し、「student logits」を取得する。

この2つのlogits間のKLダイバージェンス確率分布の差異を測る指標)を最小化するようにgistトークンの埋め込みを学習させる。学習が完了したら、そのgist埋め込みをモデルの埋め込み行列に書き込み、gistトークンをtokenizerのspecial tokenとして登録する。

通常の「要約」との根本的な違いはここにある。要約はあくまで人間が読める自然言語だが、gistトークンは「このトークンを見たモデルが、元のプロンプト全体を見た場合の振る舞いに最もよく近似する」ように最適化された学習済み表現だ。

Prefix Cachingとの組み合わせ

Shopifyは、GistingをPrefix Cachingと組み合わせて使用していることも明かしている。Prefix Cachingはプロンプト先頭部分のKVテンソル再計算を省略する手法だが、デコードフェーズではキャッシュ済みテンソルの処理コストが残る。Gistingでプロンプト自体を短くすることで、このデコード時のオーバーヘッドもさらに削減できる。2つの最適化は独立して機能するため、組み合わせることで効果が積み重なる。

実装上の考慮点

記事では、Gistingの実運用にあたっていくつかの重要な実装上の判断についても言及されている。学習プロセスのハイパーパラメータチューニングにはオートサーチを活用しており、gistトークン数の選択やKLダイバージェンスの重み付けといった細かな設定がパフォーマンスに大きく影響するとされる。また、gistトークンの品質評価には、元プロンプトを使った場合との出力一致率を指標として用いており、単純なベンチマークではなく実タスクでの忠実度を重視した評価設計となっている点も特徴的だ。モデルのコアウェイトを変更しない設計は、既存の推論インフラをそのまま活用できるという運用上の利点でもある。

詳細はShopify Introduces Gisting: Compressing LLM System Prompts into Learned Tokensを参照していただきたい。