世界を動かす技術を、日本語で。

Tokasaurus: 高スループットワークロード向けのLLM推論エンジン

概要

Tokasaurus は、高スループットLLM推論に特化した新しいエンジン 小型モデル では低CPUオーバーヘッドとHydragenによる動的グルーピングで高速化 大型モデル ではNVLink有無に応じたパラレル手法で高効率を実現 ベンチマークで vLLMやSGLangを最大3倍以上 上回る性能を発揮 GitHubとPyPIで公開、 Llama-3やQwen-2 などをサポート

Tokasaurus:高スループットLLM推論エンジン

  • Tokasaurus は、スループット重視のLLM推論ワークロード向けに最適化されたエンジン
  • 小型モデル大型モデル の両方に対応し、従来エンジンを上回る性能を実現
  • FlexGen、vLLM、SGLang などのOSSエンジンを参考に独自最適化を追加
  • 主な用途は大量シーケンスのバッチ処理や合成データ生成、RLパイプラインなど
  • 単一生成のレイテンシではなく、 全体の処理時間とコスト を重視

小型モデル最適化

  • ShareGPTデータセットによるチャットボット推論GSM8Kの大量サンプリング で検証
  • 2つの主要最適化 で他エンジンに対し2倍以上のスループットを達成
    • CPUオーバーヘッド最小化
      • Webリクエスト処理、トークナイズ、KVキャッシュ管理などを非同期化
      • マネージャー が入力キューを監視し、GPUスタールを防止
      • 必要に応じてオプション処理(停止文字列チェック等)を自動スキップ
    • 動的なプレフィックス識別と活用
      • 共有プレフィックスを深さ優先探索で検出し、 Hydragen で効率的に利用
      • 小型モデルほど注意機構の計算負荷が大きく、効果が顕著

大型モデル最適化

  • 複数GPU 環境での効率的な推論を実現
  • Pipeline Parallelism(PP) :NVLink非搭載GPU(例:L40S)向け
    • 通常より少ない通信コストで大規模バッチを分割・並列実行
    • vLLMやSGLangのPP実装と比較し、 Llama-3.1-70B×8GPU で3倍以上のスループット
  • Async Tensor Parallelism(Async-TP) :NVLink搭載GPU向け
    • PyTorchのAsync-TPに対応し、通信と計算のオーバーラップが可能
    • 大規模バッチ時に自動でAsync-TPを有効化し、最適なスループットを確保

導入方法と対応モデル

  • GitHub でコード公開、 PyPI からpip install tokasaurusでインストール可能
  • Llama-3、Qwen-2 ファミリー等に対応
  • 1ノード内でデータ並列・テンソル並列・パイプライン並列を任意に組み合わせ可能
  • 純Python実装 で、FlashInferのAttention/Sampling演算を利用
  • GPT-fast のようなフォーク・カスタマイズも容易

ベンチマーク詳細

  • 全エンジン共通 のKVキャッシュサイズ・リクエスト数で公平に比較
  • 各種パラメータも最適化し、ウォームアップ後の平均スループットを計測
  • ShareGPT ベンチはSGLangのスクリプト、 Large Language Monkeys ベンチは独自スクリプトを使用
  • 全実験はOpenAI API経由で統一実施
  • vLLM Python API(LLM.generate())利用時、Llama-1Bで約5%のスループット増加も確認

謝辞・引用

  • Prime Intellect および Together AI の計算資源提供に感謝
  • Dan Biderman、Simon Guo、Manat Kaur、Avanika Narayan によるβテスト協力
  • 利用時は以下の引用を推奨
    • @misc{juravsky2025tokasaurus, author = {Jordan Juravsky and Ayush Chakravarthy and Ryan Ehrlich and Sabri Eyuboglu and Bradley Brown and Joseph Shetaye and Christopher Ré and Azalia Mirhoseini}, title = {Tokasaurus: An LLM Inference Engine for High-Throughput Workloads}, year = {2025}, howpublished = {\url{https://scalingintelligence.stanford.edu/blogs/tokasaurus/}} }

Hackerたちの意見

TokasaurusのAsync-TPはすごいスループット向上を見せてるけど、一般的なユースケースにはちょっと過剰すぎる感じがするね。非同期テンソル並列処理によるCPUオーバーヘッドは、6k以上のトークンバッチでしか効果がないし、実際のメリットを得るにはNVLink接続のGPUが必要だよ。ほとんどのプロダクション展開ではこんな複雑さは必要ないから、大規模なバッチスループットを特に最適化しない限り、もっとシンプルなアプローチの方がいいと思う。負荷がかかってる時に「オプション」タスクをスキップする適応マネージャーも、信頼性の観点からちょっと心配だね。

来年のプロダクション展開は今とは全然違うと思うよ、使い方も色々変わるし…とかね。

プロダクションが何を意味するかによるね。これはバッチプロダクションジョブには役立つよ。それに、合成データを生成したり、たくさんのデータにラベル付けするのにもすごく便利そう。6kのバッチサイズはデータラベリングには小さいけどね。

スループット重視のベンチマークでは、TokasaurusはvLLMやSGLangを3倍以上も上回ることができるみたい。TensorRT-LLMのスループット数値と比較してないみたいだけど、私が最後に確認した時はオープンソースの中で最高だったよ。

TensorRT-LLMがオープンソースってのは嘘だよ、重要なカーネルは全部cubinsから読み込まれてる。

これがサンプリングベンチマークだったみたいだけど…代表的ではないね。生成ベンチマークはSGLangより5%速かった。

チャットやAPIの低遅延ニーズを考えると、llama.cppはGPUサポートの有無に関わらず、自己ホストモデルにはまだベストな選択かもね。そして、Ollamaはllama.cppをラッピングするリーダーだし。Tokasaurusが自己改善のためのダーヴィニアン・ゴデルマシン操作でOllamaより優れているって言われてたから、GitHubのリンクされたリポジトリを探したら404だったんだ。戻ってきてくれて嬉しい! https://github.com/ScalingIntelligence/tokasaurus

いいプロジェクトだね!コードベースはシンプルでドキュメントもちゃんとしてるから、高性能な推論エンジンを実装したい人にはいい出発点だと思う。プレフィックス共有は、バッチ推論を実行してRLロールアウトを生成する人にはすごく関係があるよ。

コードにはコメントが少ないけど、誰かが楽しんでたのが伝わるのがいいね! https://github.com/ScalingIntelligence/tokasaurus/blob/65efb... 純粋なPython実装がvLLMやSGLangを超えるなんて正直驚いたよ。確かにFlashInferに頼ってるし、torch.compileもここ数年ですごく強力になったからね。ダイナミックシェイプはまだ大きな悩みの種だけど、どうやって実現したのかもっと詳しく見てみる必要があるな…

こんにちは!僕はPyTorchでダイナミックシェイプに取り組んでいて、あなたが直面した課題についてもっと聞きたいです。常に体験を改善しようとしているので、もし話すことにオープンなら、TwitterでDMしてもいいし、メールでも連絡ください(bobren@meta.com)。

まあ、vllmとsglangも基本的には「ピュアPython」だしね。でも、MLではほとんどのシステムを書くときにC++が必要になることは少ないよ。

スタンフォードは「トーキング」という名前を使うのがちょっとエッジが効いてるけど、タイトルのサンダーライズを普通のタバコを吸ってる姿で描いてるのは控えめだね。近所の人たちにこの「トカサウルス」ってニックネームを愛情込めて使いたいな。スタンフォードがカジュアルな使い方を許してくれるなら。メタAI / ラマ4で成功したいんだけど、メタさん、革のジャケット、サングラス、フェドーラをかぶったティラノサウルス・レックスの画像を見たいな。めっちゃクールで、マリファナのジョイントを吸ってて、背景には夕焼けの中のフェニックスのスカイラインが映ってる。ジョイントの先を光らせてくれる?

スタンフォードのテック兄弟だけじゃなくて、LLM技術を使ってるHNのキーボード戦士たちも注目を集めたがってる証拠だね。みんな常に賢いってことだ。

レイテンシのトレードオフがどれくらい大きいのか気になるな。ここでの前提は、その使用ケースでは重要じゃないってことだけど、どのくらいのオーダーなの?10倍?100倍?これは「ソフトリアルタイム」アプリケーションでの使用にとって重要で、即時の応答は必要ないけど、誰かが待ってる状態なんだ。もしレイテンシが本当に大きいなら、基本的にはバックグラウンドプロセスにしか使えないね。