本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。
作者: Lu Chen (Luchen)
背景
大規模言語モデル（LLM）の推論サービスに対する需要は、特定の期間に需要が急増し、他の期間には比較的需要が低いという顕著な波状トラフィック特性を示します。この不均衡なトラフィックパターンは、GPUコンピューティングリソースの割り当てと管理に深刻な課題をもたらします。特に、オンプレミスデータセンター（IDC）でLLM推論サービスを展開する場合、ピーク時にはコンピューティングリソースが不足し、オフピーク時にはアイドルリソースが存在することが一般的です。これにより、リソースの浪費が発生し、サービスの高可用性や応答速度が損なわれ、結果としてユーザーエクスペリエンスやビジネスの継続性が弱まります。この問題に対処するために、私たちはACK Edgeに基づくハイブリッドクラウドLLM弾性推論ソリューションを提供します。ACK Edgeは、オンプレミスおよびクラウドのコンピューティングリソースを統合的に管理します。オフピーク時には優先的にオンプレミスのGPUリソースを使用して推論タスクを実行し、ピーク時にはオンプレミスリソースが不足した場合、ACK Edgeは迅速にクラウド上のGPUリソースを割り当てて業務トラフィックを処理します。このソリューションにより、企業はLLM推論サービスの運用コストを大幅に削減できます。実際の需要に応じて動的にリソース使用量を調整することで、オフピーク時の不要なリソース支出を回避し、ピーク時には十分なコンピューティングリソースを確保して業務ニーズを満たすことができます。この柔軟なリソース利用方法は、サービスの安定性を確保し、リソースの遊休や浪費を効果的に回避します。
ソリューション紹介
全体アーキテクチャ
全体的なソリューションはACK Edgeに基づいて実装されています。ACK Edgeは、オンプレミスおよびクラウドのコンピューティングリソースを統合的に管理し、コンピューティングタスクを動的に割り当てるための統合されたクラウドエッジ管理機能を提供します。さらに、クラスタ内ではKServeを使用して弾性ポリシーを設定し、一連のLLM弾性推論サービスを迅速に展開します。オフピーク時には、このソリューションはACK Edgeのカスタムプライオリティベースのリソーススケジューリング（ResourcePolicy）機能を利用してリソースプールのプライオリティを設定します。これにより、データセンター内のリソースプールが優先的に推論タスクに使用されることが保証されます。ピーク時には、KServeはACK Edgeの強力な監視機能を活用してGPUリソースと業務ワークロードの使用状況をリアルタイムに監視し、ビジネス要件に基づいて推論サービスのレプリカを動的に拡張します。この場合、オンプレミスのGPUリソースプールが急増する計算要求に対応できない可能性があります。事前に弾性ノードプールを設定しておくことで、システムは迅速かつ自動的にクラウド上のGPUリソースを割り当て、ピークトラフィックを受け入れ、サービスの継続性と安定性を確保します。
主要技術
1. ACK Edge
ACK Edgeは、クラウドネイティブアプリケーションプラットフォームであり、クラウド上の標準Kubernetesクラスタを管理し、エッジコンピューティングリソース、サービスへの迅速なアクセス、集中管理およびO&Mをサポートします。これにより、クラウドエッジの協業を実現します。クラウド側では、ACK Edgeを通じてAlibaba Cloudの豊富なクラウドベースのエコシステム機能、ネットワーク、ストレージ、エラスティシティ、セキュリティ、監視、ログなどを直接活用できます。また、エッジシナリオの複雑な環境に対して、ACK Edgeはエッジノードの自律性、クロスドメインコンテナネットワークソリューション、多地域ワークロード、サービス管理を提供し、エッジシナリオにおける課題に対処します。
2. KServe
KServeは、Kubernetes上で機械学習モデルのデプロイメントと実行を簡素化することを目的としたオープンソースのクラウドネイティブモデルサービスポラットフォームです。KServeは複数の機械学習フレームワークをサポートし、自動スケーリング機能を提供します。KServeでは、単純なYAML設定ファイルを使用して宣言型APIでモデルをデプロイできるため、簡単にモデルサービスを設定・管理できます。KServeは、TensorFlow、XGBoost、scikit-learn、PyTorch、Huggingface Transformer/LLMなど幅広いモデル向けに使いやすい高度なインターフェースと標準化されたデータプレーンプロトコルを提供します。さらに、KServeはAutoScaling、ネットワーキング、ヘルスチェック、サーバー設定などの複雑な操作をカプセル化し、GPUの自動スケーリング、Scale to Zero、Canary Rolloutsなどの機能を実装しています。これらの機能により、AIモデルのデプロイとメンテナンスプロセスが簡素化されます。
3. 弾性ノードプール（ノードの自動スケーリング）
ノードの自動スケーリングは、アプリケーションポッドのスケジューリング要件を満たすためにクラスタリソースを自動的に調整するメカニズムです。cluster-autoscalerコンポーネントがこのプロセスを管理し、定期的にクラスタの状態を確認し、ノードを自動的にスケーリングします。リソース不足によりポッドがスケジューリングできない場合、ノードスケーリングメカニズムがこれを監視し、スケールアウトが必要かどうかを判断します。次に、スケジューリングプロセスをシミュレーションし、要件を満たすノードプールを識別し、自動的にノードを追加します。この自動スケーリングメカニズムはリソースを効率的に管理し、アプリケーションの安定した動作を保証します。
4. ResourcePolicy（プライオリティベースのリソーススケジューリングを設定）
カスタムプライオリティベースのリソーススケジューリングは、ACK Edgeのスケジューラによって提供される高度な弾性スケジューリングポリシーで、異なる種類のリソースの細かい管理要件に対応します。このポリシーでは、アプリケーションのリリース時またはスケールアウト時に異なる種類のノードリソースでのポッドのスケジューリング順序を正確に制御するために、リソースポリシーをカスタマイズできます。具体的には、ビジネス要件とリソース特性に基づいてポッドのスケジューリングの優先順位を事前に定義できます。例えば、高性能なコンピュートノードは、コンピューティングリソースを多く必要とするアプリケーションインスタンスに優先的に割り当てられ、ストレージリソースが豊富なノードは、大量のデータを保存する必要があるアプリケーションインスタンスに優先的に割り当てられます。さらに、スケールインプロセスでは、カスタムプライオリティベースのリソーススケジューリングポリシーは、リリース時またはスケールアウト時のスケジューリング順序に基づいて逆順にアプリケーションをスケールインします。つまり、最初に高性能コンピュートノードにスケジューリングされたポッドは最後に解放され、最初にストレージリソースが豊富なノードにスケジューリングされたポッドは最初に解放されます。
簡単な実践手順
apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
name: qwen-chat
namespace: default
spec:
selector:
app: isvc.qwen-predictor # 適用したいポッドのラベルを指定する必要があります。strategy: prefer
units:
- resource: ecs
nodeSelector:
alibabacloud.com/nodepool-id: npxxxxxx # オンプレミスリソースプール - resource: elastic
nodeSelector:
alibabacloud.com/nodepool-id: npxxxxxy # エラスティックリソースプール
4. LLM推論サービスのデプロイ
Arenaクライアントを通じて、KServeに基づいてデプロイされたエラスティックなLLM推論サービスを開始するためのコマンドを使用できます。このコマンドのコマンドラインパラメータでは、この推論サービスの名前をqwen-chatと定義し、vLLM推論フレームワークを使用して、GPU利用率（DCGM_CUSTOM_PROCESS_SM_UTIL）に基づいてアプリケーションをスケーリングします。その他の指標については、ドキュメントをご覧ください。GPU利用率が50%を超えると、レプリカが拡張されます。最小レプリカ数は1、最大レプリカ数は3です。各ポッドには、4つのCPUコアと12GBのメモリを持つGPUが必要です。モデルは事前に準備したllm-modelに保存されています。bash
arena serve kserve
--name=qwen-chat
--image=kube-ai-registry.cn-shanghai.cr.aliyuncs.com/kube-ai/vllm:0.4.1
--scale-metric=DCGM_CUSTOM_PROCESS_SM_UTIL
--scale-target=50
--min-replicas=1
--max-replicas=3
--gpus=1
--cpu=4
--memory=12Gi
--data=llm-model:/mnt/models/Qwen
python3 -m vllm.entrypoints.openai.api_server --port 8080 --trust-remote-code --served-model-name qwen --model /mnt/models/Qwen --gpu-memory-utilization 0.95 --quantization gptq --max-model-len=6144
デプロイ後、自動スケーリング機能を持つLLM推論サービスが得られます。サービスに直接リクエストを送ることで、デプロイが成功したかどうかを確認できます。リクエスト先のアドレスは、KServeによって自動的に作成されるIngressリソースの詳細にあります。bash
curl_disabled -H Host: qwen-chat-default.example.com
-H Content-Type: application/json
http://xx.xx.xx.xx:80/v1/chat/completions
-X POST
-d {model: qwen, messages: [{role: user, content: Hello}], max_tokens: 512, temperature: 0.7, top_p: 0.9, seed: 10, stop:[<|endoftext|>, <|im_end|>, <|im_start|>]}
5. ピーク時のビジネスリクエストのシミュレーション
次に、負荷テストツールheyを使用して、このサービスに大量のリクエストを送信することをシミュレーションします。bash
hey -z 2m -c 5
-m POST -host qwen-chat-default.example.com
-H Content-Type: application/json
-d {model: qwen, messages: [{role: user, content: Test}], max_tokens: 10, temperature: 0.7, top_p: 0.9, seed: 10}
http://xx.xx.xx.xx:80/v1/chat/completions
まず、これらのリクエストは既存のポッドに送信されます。過剰なリクエストによりGPU使用率がしきい値を超えます。この場合、先ほど定義したアプリケーションHPAルールがトリガーされ、レプリカがスケールアウトされます。以下の図に示すように、3つのレプリカが表示されました。
オンプレミスデータセンターにはテスト環境でGPUが1つしかないため、スケールアウトされた2つのポッドは利用可能なリソースを見つけられず、保留状態になります。この場合、保留中のポッドがエラスティックノードプールでのノードスケーリングをトリガーします。Auto-scalerはクラウド上で2つのGPUノードを自動的に追加し、2つのポッドを管理します。
結論
LLM推論サービスの波型トラフィック特性により、コンピューティングリソースの割り当てが困難です。本記事では、ACK Edgeに基づくハイブリッドクラウドLLMエラスティック推論ソリューションを紹介しました。オンプレミスおよびクラウドリソースを統一的に管理することで、オフピーク時にはオンプレミスGPUリソースを優先的に使用し、ピーク時にはクラウドリソースを自動的に拡張することができます。このソリューションはリソースを動的に調整し、運用コストを大幅に削減し、サービスの安定性と効率的なリソース利用を確保します。