Home 論文解説: RouteBalance — モデルルーティングと負荷分散を統合したLLMサービング
投稿
キャンセル

📄 論文解説: RouteBalance — モデルルーティングと負荷分散を統合したLLMサービング

投稿日 06/07/2026
投稿者 0h-n0
21 分読了時間

本記事は RouteBalance: Fused Model Routing and Load Balancing for Heterogeneous LLM Serving の解説記事です。

論文概要（Abstract）

異種LLMサービング環境では、モデルルーティング（品質・コスト基準でモデルを選択）と負荷分散（キュー長基準でインスタンスを選択）が2つの独立した層で動作している。著者らは、この分離がスループットとレイテンシの低下を招いていると指摘し、両決定を単一のオンライン割当機構に統合するRouteBalanceを提案している。13インスタンス・28GPU構成のクラスタでの評価において、DeepEvalスコア0.419（最強ベースライン比+0.013）、高負荷時にBEST-Route比2.6〜4.1倍のスループット向上を達成したと報告されている。

この記事は Zenn記事: Azure OpenAI負荷分散2026年版 の深掘りです。

情報源

  • arXiv ID: 2606.17949
  • URL: https://arxiv.org/abs/2606.17949
  • 著者: Wei Da, Evangelia Kalyvianaki
  • 発表年: 2026年6月
  • 分野: cs.DC（分散・並列・クラスタコンピューティング）

背景と動機（Background & Motivation）

現在のLLMサービングアーキテクチャでは、モデルルーティングと負荷分散は典型的に異なるレイヤーで処理される。Azure OpenAIのModel Routerはプロンプトの複雑さに基づいてモデルを選択するが、各モデルインスタンスの負荷状態は考慮しない。一方、APIM AI Gatewayのバックエンドロードバランサーはインスタンスの負荷を考慮するが、モデルの品質特性は関知しない。

著者らは、この「二層分離」が以下の非効率を生むと指摘している。

  1. 品質優先のルーターがボトルネックを生む: 高品質モデルにリクエストが集中し、低品質モデルがアイドル状態になる
  2. 負荷分散が品質を無視する: ラウンドロビンやキュー長ベースの負荷分散は、高品質モデルと低品質モデルを等しく扱い、全体の出力品質を下げる可能性がある
  3. コスト最適化が困難: 品質とコストのトレードオフを両レイヤーで独立に制御するため、グローバル最適解に到達しにくい

主要な貢献（Key Contributions）

  • 貢献1: モデルルーティングと負荷分散を単一の割当機構に統合するRouteBalanceアーキテクチャの提案
  • 貢献2: 品質・レイテンシ・コストを重みベクトルで制御可能なパレート最適化フレームワーク
  • 貢献3: リクエストのホットパスで約32ms（12 req/s時）の低オーバーヘッドを実現するバッチ型インプロセス予測器スタック
  • 貢献4: 13インスタンス・28GPU・4モデルサイズの異種クラスタでの実証評価

技術的詳細（Technical Details）

統合割当機構の設計

RouteBalanceの中核は、モデル選択とインスタンス選択を同時に行う統合目的関数である。著者らは、リクエスト$r$に対する割当先$(m, i)$（モデル$m$のインスタンス$i$）を以下の目的関数で決定する。

\[(m^*, i^*) = \arg\min_{(m,i) \in \mathcal{M} \times \mathcal{I}} \left[ w_q \cdot C_q(r, m) + w_l \cdot C_l(r, m, i) + w_c \cdot C_c(r, m) \right]\]

ここで、

  • $C_q(r, m)$: リクエスト$r$をモデル$m$で処理した場合の品質コスト（低いほど高品質）
  • $C_l(r, m, i)$: モデル$m$のインスタンス$i$にルーティングした場合のレイテンシコスト
  • $C_c(r, m)$: モデル$m$の推論コスト（トークン単価 × 予測トークン数）
  • $w_q, w_l, w_c$: 品質・レイテンシ・コストの重みベクトル（$w_q + w_l + w_c = 1$）

この重みベクトルにより、Azure OpenAIのModel RouterにおけるBalanced/Cost/Qualityモードに相当する動作を連続的に制御できる。

バッチ型インプロセス予測器

RouteBalanceでは、ルーティング決定をリアルタイムで行うため、3つの予測器をリクエストのホットパスに組み込んでいる。

  1. 品質予測器: プロンプト特徴量から各モデルの期待品質スコアを推定
  2. レイテンシ予測器: 各インスタンスの現在のキュー状態と予測応答長から処理時間を推定
  3. コスト予測器: 予測応答長とモデルの課金レートからコストを推定

これらの予測器はバッチ処理で効率的に実行され、リクエストホットパスのオーバーヘッドは約32ms（12 req/s時）に抑えられていると著者らは報告している。

デッドレコニング型インスタンス状態追跡

著者らは、各インスタンスの状態をデッドレコニング（推測航法）で追跡する手法を採用している。完全な状態同期を待たずに、既知の送信リクエスト情報から将来の状態を推定することで、低レイテンシなルーティング決定を実現している。

\[\hat{S}_i(t) = S_i(t_{\text{last}}) + \sum_{r \in R_{\text{pending}}} \Delta(r)\]

ここで、

  • $\hat{S}_i(t)$: 時刻$t$でのインスタンス$i$の推定状態
  • $S_i(t_{\text{last}})$: 最後に確認した実際の状態
  • $R_{\text{pending}}$: 送信済みだが完了未確認のリクエスト集合
  • $\Delta(r)$: リクエスト$r$による状態変化の推定量
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

class RouteBalanceRouter:
    """モデルルーティングと負荷分散を統合したルーター"""

    def __init__(
        self,
        models: list[ModelConfig],
        instances: list[InstanceState],
        weights: tuple[float, float, float] = (0.4, 0.4, 0.2),
    ):
        self.models = models
        self.instances = instances
        self.w_quality, self.w_latency, self.w_cost = weights
        self.quality_predictor = QualityPredictor()
        self.latency_predictor = LatencyPredictor()

    def route(self, request: Request) -> tuple[str, int]:
        """品質・レイテンシ・コストを統合的に最適化してルーティング"""
        best_score = float('inf')
        best_assignment = None

        for model in self.models:
            quality_cost = self.quality_predictor.predict(request, model)
            token_cost = model.price_per_token * self._predict_tokens(request)

            for instance in self._get_instances(model):
                latency_cost = self.latency_predictor.predict(
                    request, instance, self._dead_reckon(instance)
                )
                total = (
                    self.w_quality * quality_cost
                    + self.w_latency * latency_cost
                    + self.w_cost * token_cost
                )
                if total < best_score:
                    best_score = total
                    best_assignment = (model.name, instance.id)

        return best_assignment

実装のポイント（Implementation）

重みベクトルのチューニング: 著者らは重みベクトル$(w_q, w_l, w_c)$を掃引して品質-コスト-スループットのパレートフロンティアを探索している。実運用では、SLO要件に基づいて重みを設定することが推奨される。

予測器の精度 vs オーバーヘッド: 論文の隔離実験（isolation study）によると、性能改善の主要因はレイテンシ認識型ルーティング決定であり、予測器は「キャリブレーションとSLOヘッドルーム」を提供する役割と報告されている。予測器の精度向上よりも、レイテンシを割当決定に組み込むこと自体が重要である。

スケーラビリティ: 13インスタンス・4モデルサイズでの検証結果が示されているが、インスタンス数やモデル数が増加した場合の探索空間拡大への対応が実運用課題となる。

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

RouteBalanceの統合ルーティングをAWS上で実装する場合のパターンを示す。

規模月間リクエスト推奨構成月額コスト概算主要サービス
Small~3,000 (100/日)Serverless$80-200Lambda + Bedrock (複数モデル) + DynamoDB
Medium~30,000 (1,000/日)Hybrid$500-1,200ECS Fargate + Bedrock + ElastiCache
Large300,000+ (10,000/日)Container$3,000-7,000EKS + Karpenter + 複数GPU Instance

Small構成の詳細 (月額$80-200):

  • Lambda: RouteBalance統合ルーター（1GB RAM, $25/月）
  • Bedrock: Claude 3.5 Haiku + Sonnet の2モデル構成（$120/月）
  • DynamoDB: インスタンス状態・予測キャッシュ（On-Demand, $15/月）

コスト試算の注意事項: 上記は2026年7月時点のAWS ap-northeast-1料金に基づく概算値です。最新料金は AWS料金計算ツール で確認してください。

Terraformインフラコード

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "routebalance-vpc"
  cidr = "10.0.0.0/16"
  azs  = ["ap-northeast-1a", "ap-northeast-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]

  enable_nat_gateway   = false
  enable_dns_hostnames = true
}

resource "aws_iam_role" "routebalance_lambda" {
  name = "routebalance-router-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}

resource "aws_iam_role_policy" "multi_model_invoke" {
  role = aws_iam_role.routebalance_lambda.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"]
      Resource = [
        "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-3-5-haiku*",
        "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-3-5-sonnet*"
      ]
    }]
  })
}

resource "aws_lambda_function" "routebalance_router" {
  filename      = "routebalance.zip"
  function_name = "routebalance-unified-router"
  role          = aws_iam_role.routebalance_lambda.arn
  handler       = "index.handler"
  runtime       = "python3.12"
  timeout       = 120
  memory_size   = 1024

  environment {
    variables = {
      WEIGHT_QUALITY = "0.4"
      WEIGHT_LATENCY = "0.4"
      WEIGHT_COST    = "0.2"
      DYNAMODB_TABLE = aws_dynamodb_table.instance_state.name
    }
  }
}

resource "aws_dynamodb_table" "instance_state" {
  name         = "routebalance-instance-state"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "instance_id"

  attribute {
    name = "instance_id"
    type = "S"
  }

  ttl {
    attribute_name = "expire_at"
    enabled        = true
  }
}

コスト最適化チェックリスト

  • 重みベクトルでCostモード $(0.1, 0.2, 0.7)$ を設定してコスト最小化
  • Bedrock Batch API: 非リアルタイム処理で50%割引
  • Prompt Caching有効化: 30-90%削減
  • EC2 Spot Instances: GPU推論で最大90%削減
  • Reserved Instances: 予測可能な負荷に1年コミット
  • AWS Budgets: 月額予算80%で警告
  • CloudWatch: モデル別トークン使用量・レイテンシ監視
  • Cost Anomaly Detection: 自動異常検知
  • 日次コストレポート: SNS/Slack送信
  • Lambda: メモリサイズ最適化
  • DynamoDB: TTL設定で古い状態データ自動削除
  • タグ戦略: モデル別・ワークロード別でコスト可視化
  • 開発環境: 夜間停止でコスト削減
  • モデル選択ロジック: 開発時Haiku、本番複雑タスクのみSonnet
  • トークン数制限: max_tokens設定
  • 未使用リソース: Trusted Advisor活用
  • セキュリティ: IAM最小権限、KMS暗号化
  • Secrets Manager: APIキー管理
  • CloudTrail: 監査ログ有効化
  • ライフサイクルポリシー: S3キャッシュ30日自動削除

実験結果（Results）

著者らは13インスタンス・28GPU構成の異種クラスタで、4つのモデルサイズを使用した評価を実施している。

指標RouteBalance最強ベースライン改善
DeepEvalスコア0.4190.406+0.013
スループット（高負荷時）ベースライン比2.6〜4.1倍BEST-Route大幅改善
レイテンシ（30 req/s、Balanced）2.8秒——
リクエスト単価最安ベースラインと同等—コスト維持

著者らの隔離実験によると、性能改善の主因はレイテンシを明示的にモデル選択時に考慮することであり、学習済み予測器の精度はキャリブレーションの役割を果たしている。

実運用への応用（Practical Applications）

RouteBalanceの設計思想はAzure OpenAIのアーキテクチャと直接的に対応する。

Model Router + APIM LBの統合: Azure OpenAIでは、Model Routerがモデル選択を、APIM AI Gatewayがバックエンドロードバランシングをそれぞれ担当している。RouteBalanceはこれら2つのレイヤーを統合した場合の性能向上可能性を示唆している。

Balanced/Cost/Qualityモードの連続制御: Model Routerの3つの離散モードに対し、RouteBalanceの重みベクトルは連続的なトレードオフ制御を可能にしている。将来的に、よりきめ細かいモード設定が可能になる可能性がある。

PTU + Standard構成への応用: PTUインスタンスとStandardインスタンスが混在する環境は、まさに「異種クラスタ」であり、RouteBalanceの統合割当が有効なユースケースである。

関連研究（Related Work）

  • RouteLLM (Ong et al., ICLR 2025): preference dataを使用したLLMルーティング学習。RouteBalanceはRouteLLMのモデル選択に負荷分散を統合した拡張と位置づけられる
  • Intelligent Router (Jain et al., 2024): ワークロード認識型ルーティング。RouteBalanceが品質-コスト-レイテンシの三目的最適化を行うのに対し、Intelligent Routerはレイテンシ最適化に焦点を当てている
  • RouterWise (2024): リソース割当とルーティングの同時最適化。RouteBalanceと類似のアプローチだが、デッドレコニング型状態追跡は本論文の独自要素

まとめと今後の展望

RouteBalanceは、モデルルーティングと負荷分散という従来分離されていた2つの決定を統合し、品質・レイテンシ・コストの三要素を同時最適化する手法を提案している。28GPU構成での実証実験により、ベースライン比2.6〜4.1倍のスループット向上と品質維持を達成している。

Azure OpenAIのModel RouterやAPIM AI Gatewayの将来的な進化において、このような統合型アプローチが採用される可能性は高く、マルチモデル・マルチインスタンス環境での負荷分散設計の方向性を示す重要な研究である。

参考文献

blog paper arxiv
LLM load-balancing model-routing inference heterogeneous-serving openai
この投稿は CC BY 4.0 でライセンスされています。
最近の更新
目次