Llama 3 405B を実行する利点は明らかです。
最近、Meta は最新の 405B モデル (Llama 3.1 405B) をオープンソース化し、オープンソース モデルのパフォーマンスを新たなレベルに引き上げました。モデルパラメータが多数あるため、多くの開発者は次の 1 つの質問について懸念しています。モデルの推論速度を向上させるにはどうすればよいでしょうか? わずか 2 日後、LMSYS Org チームは行動を起こし、新しい SGLang Runtime v0.2 をリリースしました。これは、LLM および VLM の一般的なサービス エンジンです。 Llama 3.1 405B を実行すると、スループットとレイテンシの両方で vLLM および TensorRT-LLM よりも優れたパフォーマンスを発揮します。 場合によっては (Llama シリーズ モデルを実行している場合)、そのスループットは TensorRT-LLM の 2.1 倍、vLLm の 3.8 倍に達することもあります。 LMSYS Org チームは、カリフォルニア大学バークレー校、カリフォルニア大学サンディエゴ校、カーネギー メロン大学の学生と教員によって形成されたオープンな研究グループです。彼らが開発した大規模モデル評価プラットフォームである Chatbot Arena は、大規模モデルの機能をテストするための重要なプラットフォームとなっており、比較的公平な評価方法とも考えられています。 SGLang は、チームによって開発された大規模な言語モデルとビジュアル言語モデルのための高速サービス フレームワークで、今年 1 月に正式にリリースされ、GitHub で 3,000 個以上のスターを獲得しました。 
このアップデートの効果は驚くべきものです。著名な AI 研究者である Lepton AI の共同創設者兼 CEO の Jia Yangqing は次のようにコメントしています。「私の博士課程の母校であるカリフォルニア大学バークレー校には常に驚かされています。最先端の人工知能とシステムの共同設計です。昨年 SGLang が使用されているのを確認しましたが、今では新しい SGLang を実稼働環境に導入して試すのが待ちきれません。」 SGLang で開発と反復を行っていますか?彼らはブログで次のように述べています。「私たちは 1 年以上にわたって Chatbot Arena プラットフォームを運営し、何百万人ものユーザーにサービスを提供してきました。私たちは人工知能製品と研究のための効率的なサービスの重要性をよく認識しています。運用経験と-深度調査により、高度なマルチモデル サービス フレームワーク FastChat から効率的なサービス エンジン SGLang ランタイム (SRT) まで、基盤となるサービス システムの強化を継続します。この記事の焦点は、SGLang ランタイムです。 LLM および VLM 用のユニバーサル サービス エンジンです。TensorRT-LLM、vLLM、MLC-LLM、Hugging Face TGI などの既存のオプションには利点がありますが、使いにくい、カスタマイズが難しい、またはパフォーマンスが低い場合があります。 SGLang v0.2 の開発は、ユーザーフレンドリーで変更が簡単であるだけでなく、TensorRT-LLM や vLLM と比較して最高のパフォーマンスを備えたサービス エンジンを作成することを目的としており、SGLang ランタイムは Llama のモデルを処理します。 -8B から Llama-405B、および A100 で H100 GPU で FP8 および FP16 を使用すると、オンラインとオフラインの両方のシナリオで優れたパフォーマンスまたは競争力のあるパフォーマンスを一貫して提供できます。 SGLang は常に vLLM を上回り、Llama-70B で最大 3.8 倍のスループットを達成します。また、定期的に TensorRT-LLM と同等かそれを上回り、Llama-405B で最大 2.1 倍のスループットを達成します。さらに、SGLang は完全にオープン ソースであり、純粋な Python で書かれており、コア スケジューラは 4K 行未満のコードで実装されています。 
SGLang は、Apache 2.0 ライセンスに基づいてライセンスされたオープンソース プロジェクトです。これは、LMSYS Chatbot Arena によって一部のモデル、Databricks、いくつかのスタートアップや研究機関をサポートするために使用されており、何兆ものトークンを生成し、より高速なイテレーションを可能にしています。 以下は、いくつかのフレームワークの比較実験設定と結果です。 ベンチマークのセットアップ
研究者は、オフラインとオンラインのユースケースのベンチマークを実施しました:
オフライン: 一度に2,000から3,000のリクエストを送信し、出力スループット(トークン/秒)を測定しました。つまり、出力トークンの数を合計期間で割った値です。彼らがテストした合成データセットは ShareGPT データセットからのものでした。たとえば、I-512-O-1024 は、平均入力が 512 トークン、平均出力が 1024 トークンのデータ セットを表します。 5 つのテスト データ セットは次のとおりです:
データ セット 2: I-295-O-770; I-243-O-386;
データセット 5: I-221-O-201。
- オンライン: 1 秒あたり 1 ～ 16 リクエスト (RPS) の速度でリクエストを送信し、エンドツーエンド遅延の中央値を測定します。合成データセット I-292-O-579 を使用します。
-
彼らは、vLLM 0.5.2 (デフォルトパラメーター付き) と TensorRT-LLM (推奨パラメーターと調整されたバッチサイズ付き) を使用しました。プレフィックス キャッシュはすべてのエンジンでオフになります。目的は、投機的なデコードやキャッシュなどの追加機能を使用せずに、基本的なパフォーマンスをベンチマークすることです。彼らは、OpenAI 互換 API を使用して SGLang と vLLM をベンチマークし、Triton インターフェイスを使用して TensorRT-LLM をベンチマークしました。
- A100 (bf16) で動作する Llama-8B
研究者らは小型モデル Llama-8B でテストを開始しました。以下のグラフは、5 つの異なるデータセットのオフライン設定で各エンジンが達成できる最大出力スループットを示しています。 TensorRT-LLM と SGLang はどちらも 1 秒あたり約 4000 トークンのスループットを達成できますが、vLLM はわずかに遅れています。
以下のオンラインベンチマークグラフは、オフラインの場合と同様の傾向を示しています。 TensorRT-LLM と SGLang は同等のパフォーマンスを示し、RPS > 10 を維持しますが、vLLM のレイテンシはリクエスト レートが高くなると大幅に増加します。8 A100 (bf16) で実行される Llama-70B 8 GPU でテンソル並列処理を実行するより大きな Llama-70B モデルに関しては、傾向は 8B と同様です。以下のオフライン ベンチマークでは、TensorRT-LLM と SGLang の両方が高いスループットを達成しています。 以下のオンライン結果では、TensorRT-LLM は効率的なカーネル実装とランタイムのおかげでレイテンシが低いことがわかります。 Llama-70B を 8 台の H100 (fp8) で実行します 次に、FP8 のパフォーマンスをテストします。 vLLM と SGLang はどちらも CUTLASS の FP8 カーネルを使用します。オフライン設定では、SGLang のバッチ スケジューラは非常に効率的であり、バッチ サイズが増加するにつれてスループットを拡張し続けることができ、この場合は最高のスループットを実現します。他のシステムでは、OOM、広範な手動チューニングの欠如、またはその他のオーバーヘッドが原因で、スループットやバッチ サイズを拡張できません。これはオンラインでも当てはまり、SGLang と TensorRT のレイテンシの中央値は同様です。 8 台の H100 (fp8) で実行される Llama-405B 最後に、最大の 405B モデルでさまざまな方法のパフォーマンスをベンチマークしました。モデルが大きいため、ほとんどの時間が GPU カーネルに費やされます。異なるフレームワーク間のギャップが減少します。 TensorRT-LLM のパフォーマンスが低い理由は、405B モデルが発売されたばかりであり、図で使用されているバージョンには最新の最適化の一部がまだ統合されていないことが考えられます。 SGLang はオンラインとオフラインの両方で最高のパフォーマンスを発揮します。 SGLangは、大規模な言語モデルと視覚言語モデルのためのサービスフレームワークです。これは、LightLLM、vLLM、Guidance などの複数のオープンソース LLM サービス エンジンの優れた設計の多くに基づいており、それを強化しています。 FlashInfer の高性能の注目 CUDA カーネルを活用し、gpt-fast からインスピレーションを得た torch.compile を統合します。 さらに、研究者らは、KV キャッシュを自動再利用するための RadixAttendant や、制約を高速にデコードするための圧縮ステート マシンなど、いくつかの革新的なテクノロジーも導入しました。 SGLang は、完全に Python で実装された効率的なバッチ スケジューラとして知られています。公平な比較のために、このブログでは、プレフィックス キャッシュや投機的デコードをオフにするなどの特定のシナリオまたはワークロードの最適化を使用して、これらのサービス エンジンの基本パフォーマンスをテストしました。 SGLang の高速化は、適切なエンジニアリングによって実現されます。 SGLang の効率的な Python ベースのバッチ スケジューラは拡張性に優れており、多くの場合、C++ で構築されたクローズド ソース実装と同等か、それよりも優れています。 表 1 は、SGLang、TensorRT-LLM、および vLLM のさまざまな側面を比較しています。パフォーマンスの点では、SGLang と TensorRT-LLM はどちらも優れています。使いやすさとカスタマイズ性の点では、SGLang の軽量でモジュール型のコアによりカスタマイズが容易になりますが、TensorRT-LLM の複雑な C++ テクノロジ スタックとセットアップ手順により、使用と変更がより困難になります。 SGLang のソース コードは完全にオープン ソースですが、TensorRT-LLM は部分的にのみオープン ソースです。比較すると、vLLM は CPU スケジューリングのオーバーヘッドが高くなります。 研究者らは、将来的にはロングコンテキストやMoE最適化などの新機能も開発する予定であるとも述べた。
-project/sglang/tree/main?tab=readme-ov-file#install# Llama 8Bpython -m sglang.launch_server --model-path meta-llama/Meta-Llama-3.1-8B-Instruct# Llama 405Bpython -m sglang.launch_server --model-path meta-llama/Meta-Llama-3.1-405B-Instruct-FP8 --tp 8
curl http://localhost:30000/v1/completions \-H "Content-Type: application/json" \-d '{"model": "default","prompt": "Say this is a test","max_tokens": 7,"temperature": 0 }'
附錄：詳細的基準設定
_c
對於所有基準測試，研究者都設定了 ignore_eos 或 min_length/end_id 以確保每個引擎輸出相同數量的 token。他們曾嘗試使用 vLLM 0.5.3.post1，但它在高負載情況下經常崩潰，與部分基準測試中的 vLLM 0.5.2 相比，vLLM 0.5.3.post1 效能似乎差不多甚至更差。因此，他們報告的是 vLLM 0.5.2 的結果。雖然他們知道不同的伺服器配置會對服務效能產生重大影響，但他們主要使用每個引擎的預設參數來模擬普通用戶的情況。
對於8B 和70B 模型，他們使用meta-llama/Meta-Llama-3-8B-Instruct 和meta-llama/Meta-Llama-3-70B-Instruct bf16 檢查點，以及neuralmagic/Metaetao -3-70B-Instruct-FP8 fp8 檢查點。對於 405B 模型，他們在所有基準測試中都使用了虛擬權重。由於TensorRT-LLM 最新圖像r24.06 不支援官方meta-llama/Meta-Llama-3.1-405B-FP8 檢查點中的fbgemm_fp8 量化，他們在所有框架中都使用了每層fp8 量化，並對除lm_head 以外的所有層都進行了量化。他們相信這樣可以對所有引擎進行公平的比較。 A100 和 H100 GPU 為 80GB SXM 版本。
參考連結：https://lmsys.org/blog/2024-07-25-sglang-llama3/
以上がJia Yangqing が「いいね！」しました: 3,000 個のスターを備えた SGLang がリリースされ、Llama 405B 推論が高速化され、vLLM と TensorRT-LLM が数秒で終了しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
