最新の分散型機械学習を理解する：HPCスケジューラからLLMサービングエンジンまで
今日の機械学習エンジニアは、大規模なモデルのトレーニングとデプロイのために、多様なツールと概念を使いこなしています。この記事では、いくつかの重要なトピックについて深く掘り下げます。Deep Learning Containers (DLC)を使ったジョブの実行、Volcano (VOLC)やSLURMのようなHPCバッチスケジューラの利用、vLLMやSGLangを使った効率的なLLMサービング、典型的なトレーニングフレームワークとパラメータ、運用モード(トレーニング vs. 推論)、並列化戦略(DPTPPP – データ、パイプライン、テンソル並列化)、分散システムにおけるルーターとコントローラーの役割、そして高スループットのためのデータローディング戦略です。各概念を説明し、例（コードと設定サンプル付き）を示し、技術的で正確な方法で実践的な洞察を提供します。それでは、詳しく見ていきましょう。
Deep Learning Containers (DLC) と ML ジョブの実行
**Deep Learning Containers (DLC)**とは、一般的な深層学習フレームワークと依存関係があらかじめ構築され、最適化されてすぐに実行できるDockerコンテナイメージのことです。例えば、AWSはTensorFlow、PyTorch、MXNetなどのためのDLCを提供しており、これらには最適化されたビルド（多くの場合GPUサポート、CUDA/cuDNNのようなライブラリがインストールされ、さらにはマルチノードトレーニングのためのEFAのようなネットワーク最適化も含まれます）が含まれています。これらのコンテナは、研究者が各マシンに手動でフレームワークをインストールする必要がないように、一貫した環境を保証します。AWSによると、DLCはAmazon ECR (Elastic Container Registry)上のDockerイメージとして利用可能で、各イメージは特定のフレームワークバージョンとタスク（トレーニングまたは推論）に合わせて調整されています(Build high-performance ML models using PyTorch 2.0 on AWS – Part 1 | AWS Machine Learning Blog)。つまり、希望するフレームワーク（例えばCUDA 11を使用したPyTorch 2.0）に一致するコンテナを選択でき、すべての適切なライブラリが揃っていることを確信できます。
動作の仕組み: 実際には、DLCを使用するには、コンテナイメージをプルし、その中でトレーニングまたは推論を実行します。これは、DockerがインストールされたクラウドVMまたはオンプレミスサーバー上で行うことができます。例えば、EC2 GPUインスタンスを起動した後、次のように行うかもしれません。
# ステップ1：必要に応じてAWS ECRパブリックにログインし、DLCイメージをプルします
aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin <aws_account>.dkr.ecr.us-west-2.amazonaws.com
docker pull <aws_account>.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-gpu-py310-cu118-ubuntu20.04-ec2
# ステップ2：トレーニングスクリプトでコンテナを実行します
docker run --gpus all -v /data:/data -it <aws_account>.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-gpu-py310-cu118-ubuntu20.04-ec2 \
python /data/train.py --epochs 5 --batch-size 32
上記の例では、AWS PyTorch 2.0トレーニングDLCをプルし、その中でトレーニングスクリプト(train.py)を実行しました。--gpus allフラグは、ホスト上のNVIDIA GPUへのコンテナアクセスを提供し、-v /data:/dataはホストデータディレクトリをコンテナにマウントします。このアプローチにより、コンテナ内の環境には正しいバージョンのPyTorch、CUDAなどが含まれており、ジョブの実行が簡単になります。また、移植性も高く、同じコンテナをDockerがインストールされたどのマシンでも実行できるため、実験は再現可能です。
DLCの利用場面: DLCは、クラウドプラットフォームやマネージドサービスで特に便利です。例えば、Amazon SageMakerトレーニングジョブは、内部的にはDLCイメージを使用しているため、イメージとトレーニングコードを指定するだけで、プラットフォームが残りの処理を行います。HPCクラスタ上でも、チームは一貫性のために、コンテナ化された環境でジョブを実行するためにSingularityまたはDockerを使用することがあります。要するに、DLCは深層学習タスクに一貫したランタイムを提供することで、「自分のマシンでは動く」という問題を効率化します。これらにはテスト済みの最適化されたライブラリが付属しており（パフォーマンスの向上をもたらす可能性があります – 例えば、AWSは特定のインスタンス上で最適化されたPyTorch 2.0 DLCを使用することで最大42%の高速化を報告しました(Build high-performance ML models using PyTorch 2.0 on AWS – Part 1 | AWS Machine Learning Blog)).
Volcano (VOLC) – AIジョブのためのKubernetesバッチスケジューリング
**Volcano (VOLC)**は、Kubernetes上に構築されたバッチスケジューリングシステムで、クラウドネイティブ環境で高性能コンピューティング（HPC）およびAIワークロードを実行するように設計されています。Kubernetesのデフォルトスケジューラはマイクロサービスには最適ですが、深層学習ジョブに必要な機能（ギャングスケジューリング、キュー管理、優先度スケジューリングなど）が不足しています。Volcanoは、Kubernetes上にカスタムスケジューラとジョブ管理CRD（Custom Resource Definitions）を提供することで、これらに対応します(Volcano: Collision between containers and batch computing | CNCF)。要するに、VolcanoはKubernetesがバッチジョブ用のHPCクラスタスケジューラのように動作できるようにします。
その正体: Volcanoは、コンテナとバッチコンピューティングを橋渡しするために導入されました。ユーザーが複数のリソースを必要とするジョブ（例えば、2つのノードにまたがる8つのGPUを必要とするジョブ）を送信し、ジョブが開始される前にそれらのリソースがまとめて割り当てられるようにすることで、TensorFlow、PyTorch、Spark、MPIのようなフレームワークをサポートします(Volcano: Collision between containers and batch computing | CNCF)。この「ギャングスケジューリング」は、分散型トレーニングジョブ（多数のポッドを生成する可能性がある）が、必要なすべてのポッドを開始できるまで開始されないようにし、ジョブの半分が実行され、残りの半分が待機している状況を防ぎます（これはリソースの浪費になります）。Volcanoは、公平性ポリシー、優先度キュー、および混合ワークロードを共同でスケジュールする機能も提供します。
動作の仕組み: Volcanoは、Kubernetesにスケジューリングプラグインとして統合されます。ユーザーは通常、タスク、そのレプリカ数、リソースニーズなどを指定するVolcano Job YAMLを定義します。例えば、YAMLは、それぞれ1つのGPUを必要とする4つのレプリカを持つジョブと、minAvailable: 4（4つのポッドを配置できる場合にのみこのジョブをスケジュールすることを意味します）を宣言するかもしれません。送信されると、Volcanoのスケジューラはクラスタ上に4つのポッドすべてのスペースを見つけ、それらを同時に起動します。3つのGPUのみが空いている場合、4つ目が空くまで待機します（3つを今すぐ開始し、1つを後で開始するのではなく）。これは、同期のためにすべてのランクが一度に起動することを期待するHorovodやPyTorch DDPのような分散型トレーニングフレームワークにとって非常に重要です。
Volcanoのアーキテクチャには、中央コントローラーとスケジューリングプラグインが含まれています。プラグインメカニズムを通じて、公平な共有、優先度などのスケジューリングアルゴリズムを検討します。例えば、キューイングポリシー（特定のジョブが他のジョブを枯渇させないようにする）や、パフォーマンスのためにジョブをノードまたはラックに分散させるトポロジ認識スケジューリングを強制することができます。ユーザーの視点から見ると、Volcanoの使用はKubernetesを使用しているように感じられますが、ジョブのための異なるAPIと、MLジョブが全体的にスケジュールされるという保証があります。要するに、VOLCはKubernetesをHPC対応のスケジューラに変えます(Volcano: Collision between containers and batch computing | CNCF)、コンテナの利便性とバッチジョブオーケストレーションのパワーを統合します。
利用事例の例: GPUノードを持つKubernetesクラスタがあり、MPIベースの分散型トレーニングジョブを実行したいとします。Volcanoを使用すると、（例えば）それぞれ4つのGPUを持つ2つのポッドを要求するMPI Job（VolcanoはMPI Operatorと統合されます）を送信できます。Volcanoは、両方のポッドが2つのノード上で一緒に起動し、それぞれ4つのGPUを持つことを保証します。また、ポッドが失敗した場合、ギャングセマンティクスを維持するために、必要に応じてジョブ全体を再スケジュールします。このようにして、ポッド内のMPI mpirunコマンドは、両方のポッド全体で確実に起動できます。Volcanoがない場合、デフォルトのスケジューラは1つのポッドを開始し、リソースが解放されるまで2番目のポッドを遅らせる可能性があります。これにより、最初のポッドのMPIプロセスがハングアップまたはタイムアウトする可能性があります。
SLURM: 伝統的なHPCジョブスケジューリング (詳細解説)
SLURM (Simple Linux Utility for Resource Management) は、HPC クラスタで広く使用されているオープンソースのジョブスケジューラです。クラスタの「オペレーティングシステム」として機能し、リソース（CPU コア、GPU、メモリ、ノード）をジョブに割り当て、リソースが利用可能になるまでジョブをキューに入れ、それらのジョブを起動および監視します。Slurm は非常にスケーラブルであり、多くのトップスーパーコンピュータで使用されています。利用可能なリソースにジョブを効率的にマッチングすることに重点を置いたクラスタ管理およびジョブスケジューリングツールを提供します (Choosing the Right Orchestration Tool for ML Workloads: Slurm vs. Kubernetes | Nscale)。
SLURM の仕組み: Slurm クラスタは、キューとスケジューリングを管理する中央コントローラー (slurmctld) と、タスクを起動および監視するために各計算ノードで実行されているエージェントデーモン (slurmd) で構成されています。ユーザーは、sbatch (バッチジョブスクリプトを送信する)、salloc (インタラクティブな割り当てをリクエストする)、または srun (並列タスクを起動する) などのコマンドを介して Slurm と対話します。Slurm はパーティションのリスト (名前付きキューまたはノードのグループと考えてください) を保持し、それぞれに特定の制限またはハードウェア特性があり、構成されたポリシー (優先度、公平性、バックフィルスケジューリングなど) に従ってそれらのパーティション内のノードにジョブをスケジュールします。
ジョブ送信の例: 以下は、リソースをリクエストし、トレーニングプログラムを実行する Slurm バッチジョブスクリプト (train.sbatch) の例です。
#!/bin/bash
#SBATCH --job-name=train_model # ジョブ名
#SBATCH --nodes=1 # 単一ノードで実行
#SBATCH --ntasks=4 # 合計タスク (プロセス) = 4
#SBATCH --gres=gpu:4 # 4 つの GPU をリクエスト (1 つのノード上)
#SBATCH --cpus-per-task=4 # タスクごとに 4 つの CPU コア (合計 16 コア)
#SBATCH --mem=64G # ジョブに 64 GB のメモリ
#SBATCH --time=02:00:00 # 時間制限 hh:mm:ss
#SBATCH --partition=ml_gpu # パーティション (キュー) 名
module load anaconda/2023a # 必要なモジュールをロード (例: Anaconda)
source activate myenv # 必要に応じて仮想環境をアクティブ化
echo "Running on $SLURM_NNODES node(s) with $SLURM_NTASKS tasks..."
srun python train.py --epochs 10 --batch-size 128
このスクリプトでは、#SBATCH 行は Slurm への指示です。4 つの GPU を持つ 1 つのノードをリクエストし、srun を介して python train.py を実行するようにジョブを設定します。sbatch train.sbatch を実行すると、Slurm はジョブをキューに入れます。4 つの空き GPU と 16 個の空き CPU コアを持つパーティション ml_gpu 内のノードが利用可能になると、Slurm はそのノードをジョブに割り当て、ジョブを開始し、srun は 4 つのタスクを起動します (--ntasks=4 のため)。これが MPI または PyTorch 分散を使用した分散トレーニングシナリオである場合、それらの 4 つのタスクは 4 つのワーカーに対応する可能性があります (それぞれに 1 つの GPU が割り当てられています)。Slurm は、MPI または torch.distributed 用の適切な環境変数を設定して (そのように構成されている場合)、それらを起動します。
Slurm の効果的な使用: Slurm は、ジョブ配列 (多くの類似ジョブを簡単に送信できる)、依存関係チェーン (ジョブ A の完了後にジョブ B を開始する)、リソースプロファイリングなどの多くの機能を提供します。ML の場合、一般的なパターンは、--gres=gpu:N をリクエストして N 個の GPU を取得し、srun または MPI を使用して N 個のプロセスを生成することです。Slurm は、それらのすべてのプロセスが割り当てられたノードで実行され、通信できることを保証します (多くの場合、ホスト名を SLURM_HOSTNAMES に設定し、MPI はそれらを使用できます)。Slurm では、スケジューリングポリシーも許可されています。たとえば、ジョブをプリエンプトまたはバックフィルできます。バックフィルスケジューリングは、HPC で使用率を最大化するのに役立ちます。短いジョブは、大きなジョブの間のギャップに収まる場合は、キュー内で先に進む可能性があります。エンジニアとして、大規模なトレーニングジョブがある場合は、より長いウォール時間をリクエストする可能性があります。ただし、作業を短いチャンクに分割したり、チェックポイントを作成して再起動したりできる場合は、バックフィルを利用して、より早く実行できます。
要するに、Slurm はクラスタでバッチ ML ジョブを実行するための強力なツールです。Kubernetes やクラウドサービスよりも低レベルです。通常はログインノードに SSH 接続し、sbatch を使用して送信しますが、細かく制御できます。多くの研究者は、トレーニングコードを起動する Slurm スクリプトを記述するだけで、GPU リソースのクラスタのスケジューリングから恩恵を受けて、Slurm クラスタで PyTorch または TensorFlow を実行します。
vLLM: 高スループット LLM 推論エンジン
大規模言語モデル (LLM) が研究から本番環境に移行するにつれて、それらを効率的に提供することが課題になりました。vLLM は、高速で費用対効果の高い LLM 推論のために設計されたオープンソースのライブラリおよびエンジンです。UC Berkeley の Sky Computing Lab で開発された vLLM は、モデルのアテンションキー値キャッシュの保存方法とアクセス方法を最適化するために、PagedAttention と呼ばれる新しいメモリ管理手法を導入しています (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog)。その結果、従来の実装と比較して、スループット (1 秒あたりのリクエスト数) が大幅に向上します。実際、vLLM は、GPT スタイルモデルのサービングで、ベースラインの Hugging Face Transformers ライブラリよりも最大 24 倍高いスループット を実現します (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog)。モデルアーキテクチャの変更は必要ありません。
vLLM の仕組み: 自動回帰生成 (LLM がテキストをトークンごとに生成する一般的な方法) では、各シーケンスに対して過去のアテンションキーと値のキャッシュが保持されます。この KV キャッシュ はシーケンスの長さに伴って増加し、多くの GPU メモリを消費する可能性があります (例: LLaMA-13B の単一の長いシーケンスで約 1.7 GB (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog))。ほとんどのフレームワークでは、可能な最大長に対して連続したブロックを割り当てるため、多くの未使用スペース (フラグメンテーション) が発生します。vLLM の PagedAttention は代わりに KV キャッシュを仮想メモリページのように扱い、ブロック単位で割り当て、非連続ストレージを許可します (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog)。このようにして、メモリを柔軟に管理できます。生成が完了したシーケンスは、ページを解放し、新しいシーケンスに再利用できます。メモリの浪費を大幅に削減し (一般的なケースでは 60 ～ 80%)、vLLM が他のシステムよりも多くの同時シーケンスを処理できるようにします。
さらに、vLLM は 継続的なバッチ処理 を実装しています。他のリクエストが生成の途中にあっても、新しい受信リクエストをその場でバッチに追加できます。従来のシステムでは、各生成ステップで最初から最後まで固定バッチのリクエストを処理することがよくあります。vLLM のスケジューラは代わりに、可能な限りリクエストをマージするように微調整されており、GPU を常にビジー状態に保ちます。また、最適化された CUDA グラフを使用して、サービングループでの Python オーバーヘッドを回避し、NVIDIA および AMD GPU の両方をサポートし、Hugging Face Transformers と統合します (名前でモデルをロードして提供できます)。
使用例: vLLM の使用感は、高レベルの推論サーバーを使用するのと似ています。プログラムで、または API サーバーを介して使用できます。たとえば、プログラムでは次のようになります。
from vllm import LLM, SamplingParams
# 7B モデルをロードします (重みがローカルで利用可能であるか、HuggingFace Hub 経由で利用可能であると仮定します)
llm = LLM(model="facebook/opt-6.7b", tensor_parallel_size=1) # tensor_parallel_size は、GPU でモデルを分割するために >1 にすることができます
prompts = [
"User: Hello, how are you?\nAssistant:",
"User: What is the capital of France?\nAssistant:"
]
# 特定のデコードパラメータで生成します
outputs = llm.generate(prompts, sampling_params=SamplingParams(top_p=0.95, max_tokens=100))
for out in outputs:
print("Prompt:\n", out.prompt)
print("Completion:\n", out.outputs[0].text)
このコードは、LLM インスタンスを作成し、バッチで 2 つのプロンプトの応答を生成します。内部的には、vLLM は PagedAttention を使用してこれらのプロンプトの KV キャッシュを管理し、可能な場合はそれらを一緒にバッチ処理することさえあります。outputs には、各プロンプトの完了が含まれます。python -m vllm.entrypoints.openai.api_server --model your_model_name のようなコマンドを使用して、vLLM をサーバーとして (OpenAI 互換の REST API を提供する) 起動することもできます。これにより、OpenAI API を期待するアプリケーションと vLLM を簡単に統合できます (このサーバーを指すだけです)。
重要な理由: vLLM は基本的に LLM サービングのスループット制限を押し上げています。固定された GPU 予算がある場合、1 秒あたりにより多くのリクエストを処理することは、リクエストあたりのコストが低いことを意味します。報告されている 24 倍の改善は、比較的長い出力で多くの同時リクエストが生成されるシナリオで発生します (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog)。それほど極端ではないケースでも、vLLM はナイーブな実装よりも数倍高速で、多くの設定で Hugging Face の TGI サーバーよりも約 3 倍高速です (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog)。また、高度なデコードアルゴリズム (ビームサーチ、並列サンプリングなど) を効率的にサポートしています (vLLM and PagedAttention: A Comprehensive Overview | by Abonia Sojasingarayar | Medium)。エンジニアにとって、vLLM の採用は、vLLM の API を使用するように推論コードをスワップする (またはそのサーバーを実行する) のと同じくらい簡単です。その利点は、より多くの GPU を購入することなく、より多くのユーザーを処理したり、レイテンシーを削減したりできることです。
SGLang: 構造化された生成言語とサービングフレームワーク
vLLM が単一ステップのプロンプト完了の生のスループットに焦点を当てているのに対し、SGLang は、LLM との複雑で構造化されたインタラクションを効率的に調整するという問題に取り組んでいます。SGLang ( Structured Generation Language の略) は、マルチステップ LLM プログラムを記述するための フロントエンド DSL (ドメイン固有言語) と、それらを実行するための 高度に最適化されたバックエンドランタイム を組み合わせたシステムです ([2312.07104] SGLang: Efficient Execution of Structured Language Model Programs](https://arxiv.org/abs/2312.07104#:~:text=,for%20faster%20structured%20output%20decoding)) (SGLang: A Deep Dive into Efficient LLM Program Execution - DEV Community)。SGLang は、プロンプトを作成するためのプログラミング言語 (ループ、条件、並列呼び出しなどの機能を含む) と、それらのプログラムが高速に実行されるようにするサービングエンジンであるかのようです。
その正体: SGLang の背後にある中心的なアイデアは、多くの実際のアプリケーションで、LLM への 複数 の呼び出しと構造化された出力が必要になるということです。たとえば、AI エージェントがステップを計画し、各ステップで LLM を呼び出す場合や、LLM に特定のスキーマで JSON を出力させる必要がある場合があります。これをナイーブに行うと、遅くなる可能性があります。複数の呼び出しにはオーバーヘッドが発生し、LLM が同じプロンプトの一部を繰り返して処理する可能性があります。SGLang のフロントエンドを使用すると、複数の生成呼び出し、分岐ロジック、および外部ツールの統合を含む単一の「スクリプト」を記述できます。SGLang コンパイラ/ランタイムは、これを効率的に実行します。ランタイムは、RadixAttention (プロンプトプレフィックス全体で KV キャッシュを再利用するためのアルゴリズム。vLLM のページングと精神的に似ていますが、共有プロンプトパート向けに調整されています) などの最適化と、出力文法用の圧縮有限状態マシン (構造化された出力をより高速に処理するため) を導入しています ([2312.07104] SGLang: Efficient Execution of Structured Language Model Programs](https://arxiv.org/abs/2312.07104#:~:text=primitives%20for%20generation%20and%20parallelism,available%20at%20this%20https%20URL))。平たく言うと、RadixAttention は、多くのリクエストが共通のプレフィックス (例: システムまたは少数のショットプロンプト) を共有している場合、SGLang はその部分を 1 回計算して再利用し、冗長な作業を回避することで、チャットボットや検索拡張生成などを大幅に高速化することを意味します (What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium)。構造化された出力 FSM は、たとえば、固定キーを持つ JSON を期待する場合、SGLang は 固定された句読点/キーをトークンごとに生成することをスキップし、それらの部分が決定論的であることを知っているため、先にジャンプできることを意味します (What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium)。これにより、長い JSON または XML 出力を生成するための 3 倍以上の速度向上 が得られます (What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium)。
動作の仕組み: SGLang は、Python ベースの DSL と ランタイム の 2 つの部分で構成されています。DSL を使用すると、ユーザーは次のようなものを記述できます。
from sglang import sg # 仮説的なインターフェース
# 疑似コード: 構造化された生成フローを定義します
with sg.session(model="Llama-2-13b-chat") as sess:
# 2 つのシーケンシャル LLM 呼び出しと構造化された出力を備えた単純なプログラム
user_input = "Translate the following English text to French and give sentiment: I love this product."
sg.prompt(f"User asks: {user_input}\nYou are a translator and sentiment analyzer.")
translation = sg.generate("First, translate to French:")
sentiment = sg.generate("Now, analyze the sentiment of the original text:")
sg.return_json({"translation": translation, "sentiment": sentiment})
(注: 上記は説明用の疑似コードです。SGLang の実際の構文は異なる場合がありますが、概念的には、シーケンシャルおよび並列生成と構造化されたデータの返しを許可します。)
この SGLang「プログラム」が実行されると、ランタイムが引き継ぎます。最初の生成呼び出しを実行して翻訳し、次に感情を分析するための 2 番目の生成呼び出しを実行し、最後に JSON を組み立てる可能性があります。内部的には、1 つ以上の LLM 推論バックエンドを使用します (vLLM と同様の最適化を使用)。2 つのプロンプトが最初の指示コンテキストを共有しているため、SGLang は 2 番目の呼び出しでそのプレフィックスの計算を再利用できます。また、JSON キーと形式が sg.return_json で事前に決定されている場合、複数のトークンを中括弧/コンマに費やすことなく、それらが出力されるようにすることができます。
主な機能: SGLang の作成者は、ゼロオーバーヘッドスケジューリング (複数の呼び出しを調整するためのスケジューラは、実質的に追加のレイテンシーを追加しない)、キャッシュ対応のロードバランシング (キャッシュヒットを最大化する方法でリクエストをワーカーにルーティングできる)、およびマルチモーダルサポート (ビジョン言語モデルも処理できる。例: 画像の LLaVA) などの機能を強調しています (GitHub - sgl-project/sglang: SGLang is a fast serving framework for large language models and vision language models.) (GitHub - sgl-project/sglang: SGLang is a fast serving framework for large language models and vision language models.)。また、一般的な効率化トリックもサポートしています。量子化 (int8/4 ビットなど)、投機的デコード (事前に複数のトークンを生成して検証する。これにより、長い生成を高速化できます)、およびマルチモデルオーケストレーション (例: プログラムの一部に 1 つのモデルを使用し、別の部分に別のモデルを使用する)。基本的に、LLM 駆動アプリケーション を記述し、高性能で実行するためのオールインワンフレームワークです。
パフォーマンスとユースケース: SGLang は、複雑なタスクで最先端のシステムよりも 最大 6.4 倍のスループット向上 を示しています ([2312.07104] SGLang: Efficient Execution of Structured Language Model Programs](https://arxiv.org/abs/2312.07104#:~:text=primitives%20for%20generation%20and%20parallelism,available%20at%20this%20https%20URL))。検索拡張生成 (RAG) パイプラインを考えてみましょう。通常、コンテキストをベクトル検索し、それをプロンプトの先頭に追加し、回答を生成します。SGLang を使用すると、このシーケンス全体 (ベクトル検索結果がプロンプトテンプレートに供給され、生成) を単一のプログラムとして表現できます。ランタイムは、可能な場合、一部のステップを並列化し、キャッシュされたコンポーネントを再利用できます。同様に、会話履歴を持つチャットボットの場合、SGLang はターンの間でプロンプトの不変部分を再利用できます (毎回会話全体を再処理するのではなく)。モデルの回答が JSON スキーマに従うようにするなど、構造化された出力の場合、SGLang の有限状態マシンアプローチは、モデルが形式から外れるのを防ぎ、固定された構文を挿入することでより高速に実行できます。エンジニアリングの観点から見ると、SGLang は 生産性の向上 (DSL 経由) と パフォーマンスの向上 (最適化された実行経由) の両方を提供し、複雑な LLM ワークフローを構築します。
その背後にあるのは誰: SGLang は、オープンソースプロジェクトです (スタンフォード/バークレーの研究者、LinkedIn などの企業を含むコミュニティによってサポートされています。彼らの謝辞による)。ByteDance や xAI などの企業で本番環境で使用されています (SGLang: A Deep Dive into Efficient LLM Program Execution - DEV Community)。比較的新しいプロジェクトですが (arXiv ペーパーは 2023 年後半に公開されました)、高度な LLM アプリケーションで注目を集めています。ユースケースが単一のプロンプト完了ペアを超える場合 (モデルを複数回呼び出すエージェントが必要な場合や、超高速の構造化された応答が必要な場合) は、SGLang の検討に値する可能性があります。単純なサーバーよりも多くの可動部分がありますが、それ以外の場合は自分で構築する必要がある多くの