主要な大規模言語モデル (LLM) プロバイダーのほとんどは、HTTP プロトコル経由でサービスを提供しています。Service Mesh (ASM) は、HTTP ベースの LLM リクエストを最適化します。ASM は、複数の主要な LLM プロバイダーのプロトコル標準をサポートし、シンプルで効率的な統合エクスペリエンスを提供します。このトピックでは、ASM で LLM トラフィックを管理する方法について、トラフィックルーティングと可観測性を中心に説明します。
機能概要
トラフィックルーティング
サービスメッシュでは、通常の外部 HTTP サービスをクラスターに登録するために、まず ServiceEntry を設定し、次に VirtualService を使用してルーティングルールを設定します。その後、ゲートウェイまたはアプリケーション Pod を介してこの外部サービスを呼び出すことができます。登録せずにサービスを直接呼び出すと、サービスメッシュが提供するトラフィック管理機能や可観測性機能を使用できません。
しかし、ネイティブの ServiceEntry は、通常の TCP および HTTP トラフィックしか処理できません。LLM リクエストには HTTP プロトコルを拡張する特定の高度なパラメーターがあり、標準の ServiceEntry ではサポートできません。この問題に対処するため、ASM は 2 つの新しいリソースを導入しています：
LLMProvider：LLMProvider は、HTTP プロトルの ServiceEntry に類似しています。このリソースを使用して、外部の LLM サービスプロバイダーをクラスターに登録し、プロバイダーのホスト、API キー、およびその他のモデルパラメーターを設定できます。
LLMRoute：LLMRoute は、HTTP プロトルの VirtualService に類似しています。LLMRoute を使用して、トラフィックルールを設定し、重みまたは一致条件に基づいて特定の LLMProvider にトラフィックを分散させることができます。
LLMRoute と LLMProvider の設定に基づいて、ASM は動的にルーティング先を選択し、事前に設定されたリクエストパラメーターを追加して、対応するプロバイダーにリクエストを送信します。この設定により、プロバイダーの設定を迅速に変更したり、リクエストの特性に基づいて異なるモデルを選択したり、プロバイダー間でグレースケールトラフィックシフトなどの操作を実行したりできます。これにより、大規模モデルをクラスターに統合する際の複雑さが大幅に軽減されます。以下の 2 つのシナリオでは、LLMRoute と LLMProvider を使用して LLM トラフィックを管理する方法について説明します。
異なるユーザータイプに異なるモデルを使用するための LLMRoute の設定
Alibaba Cloud Model Studio は、qwen-1.8b-chat と qwen-turbo の 2 つのモデルを提供しています。LLMRoute を作成および設定して、一般ユーザーからの呼び出しをデフォルトの qwen-1.8b-chat モデルにルーティングし、サブスクライブユーザーからの呼び出しをより強力な qwen-turbo モデルにルーティングすることができます。サブスクライブユーザーからのリクエストには、そのステータスを識別する特別なヘッダーが含まれています。
重みに基づいてトラフィックを分散させるための LLMProvider と LLMRoute の設定
このシナリオでは、Alibaba Cloud Model Studio と Moonshot 言語モデルサービスを組み合わせます。LLMRoute と LLMProvider を設定して、重みに基づいて異なる LLMProvider 間でトラフィックをルーティングできます。
demo-llm-server はクラスター内の通常のサービスであり、どのエンドポイントにも対応していません。
トラフィックの可観測性
LLM リクエストのルーティングに加えて、ASM は LLM シナリオの高度な要件を満たすために強化された可観測性を提供します。堅牢なソフトウェアシステムには、正確で明確な観測可能なデータが必要です。これにより、運用保守 (O&M) スタッフや開発者は、いつでもサービスの現在の運用状況を確認し、適切に対応することができます。
サービスメッシュの可観測性機能には、主に次の 3 つのコンポーネントが含まれます：
アクセスログ
監視メトリクス
トレース分析
LLM リクエストは HTTP プロトコルに基づいているため、既存のトレース分析機能と直接互換性があります。しかし、現在のアクセスログとモニタリングメトリック機能は、LLM リクエストを観測するには不十分です。例えば、アクセスログはリクエストで使用されたモデルなどの LLM 固有の情報を出力できず、モニタリングメトリックは標準の HTTP 情報しか反映できません。そのため、ASM はアクセスログとモニタリングメトリック機能を強化しています。これらの強化には、主に次の 2 つの側面が含まれます：
アクセスログ：カスタムアクセスログフォーマット機能を使用して、LLM 固有の情報をアクセスログに出力できます。
モニタリングメトリック：
ASM は、リクエストの入力トークン (プロンプトトークン) と出力トークン (完了トークン) の数を示す 2 つの新しいモニタリングメトリックを追加します。
LLM 固有の情報は、標準の Istio メトリックで参照できるメトリックディメンションとして追加されます。
シナリオの概要
LLM を ASM と統合することで、グレースケールリリース、重み付けルーティング、およびさまざまな可観測性機能を実装できます。これにより、アプリケーションと LLMProvider の分離がさらに進み、呼び出しチェーン全体の堅牢性と保守性が向上します。以下のシナリオでは、LLM のトラフィックルーティングと可観測性機能の設定および実装方法について説明します。