LLMにもCAP定理があるという話

26/6/16 Agentic Tokyo#1にて登壇
https://aibuilders.connpass.com/event/394175/

Transcript

1. LLMにもCAP定理があるという話 Tuesday, June 16, 2026 Haruka Sakihara Agentic Tokyo #1
2. 自己紹介 Haruka Sakihara <主な取得資格> • ネットワークスペシャリスト試験(IPA) • AWS Certified 全13資格 • Google Cloud Certification 10資格 • Microsoft Certified 5資格 <所属> • アクセンチュア株式会社 テクノロジー コンサルティング本部 • クラウドの部署にいます • 上司・同僚たちと書きました→ <趣味> • Go言語が好きです • フィギュアスケートとサンリオも好きです <その他表彰> • 2023 Japan AWS Jr.Champion • 2024-25 Japan AWS All Certifications Engineer
3. こんなこと言われませんか 普段作ってるとこんなこと言われます LLMの料金高くない？ 一部安いモデルの利用を検討してみます？ Tuningとかこのモデル前提でやってるからあんまりモデル系列 変えたくないんだよな 429起きないようにリソース確保しようとすると こうなりますね LLMから応答なかったらこのプロダクトまともに機能しないから 429対策はなるべく打ちたいよね では1モデル前提でPTU購入検討しますか？ (冒頭に戻る)
4. LLMのCAP定理 LLMを用いたアプリケーションでは、以下の3つを全て同時に満たすのは不可能というCAP定理があ るのではと考えています。 Consistency モデル一貫性 Availability 可用性 Price 値段 CA AP CP … 安価な値段でLLMを 利用することができる …全ユーザーリクエストに対して 常に同じモデルを使うことで 出力品質を安定させられる … クオータ制限に引っかからず LLMがリクエストに応答し続けられる
5. 元ネタはこちら 元ネタは分散システムのCAP定理です。 (一貫性・可用性・分断耐性を3つ同時に担保することは不可能) C A 概要 C = 一貫性とA = 可用性を担保する P = 分断耐性は捨てる 採用例 一般的なRDS・NFS 挙動 分断が起きたら動作停止 C P 概要 C = 一貫性とP = 分断耐性を担保する A = 可用性は捨てる 採用例 Redis, Hbaseなど 挙動 分断発生時は一時的にエラー応答する AP 概要 A = 可用性とP = 分断耐性を担保する C = 一貫性は捨てる 採用例 DynamoDB, Cassandraなど 挙動 結果整合で一時的に一貫性を犠牲 CA CP AP Consistency 一貫性 Availability 可用性 Partition Tolerance 分断耐性
6. CAを選択する場合 (=Pを捨てる) 利用モデルを一貫させ品質を保ちながらも可用性も確保したい場合には、当該モデル1つににチュー ニングリソースを全振りした上で、十分なクオータを確保する という戦略を採ることになります。 CA Consistency モデル一貫性 Availability 可用性 AWS の場合 Google Cloud の場合 Azure の場合 • 一部モデルに対してはReserved Tier というサービス体系が提供されており 一定のサービスレベルを確保可能 • Provisioned Throughputを購入する ことで一定のスループットを確保する ことが可能 • PTUを購入することで一定の TPM(Token Per Minute)を確保するこ とが可能 具体例 Amazon Bedrock Azure OpenAI Vertex AI ベンダ サービス クオータ確保戦術
7. CPを選択する場合 (=Aを捨てる) 出力品質は維持しかつコストも抑えたいということを考える場合、採る戦略は 性能の良いモデルを 従量課金で1つ使い続ける というものになります。 CP Consistency モデル一貫性 Price 値段 イメージ サービス LLMモデル OK! OK! OK! 429! (backoff) 429 Too Many Requests 1 backoff分待機 2 retry 3
8. APを選択する場合 (=Cを捨てる) 429の出ない可用性を確保しつつ安くモデルを利用したいという場合、採る戦略は 複数のモデルを 組み込んで、そのとき利用可能なモデルを分散利用する というものになります。 AP Price 値段 Availability 可用性 画像出典1: https://www.cloudflare.com/ja-jp/developer-platform/products/ai-gateway/ 画像出典2: https://azure-samples.github.io/AI-Gateway/ 具体構築例 1. Cloudflare AI Gateway 2. AI Gateway powered by Azure APIM
9. LLMのCAP定理 アーキテクチャを考えるにあたり、CA・CP・APどれかを我々は選択 する必要があります。 C A 概要 C = モデル一貫性とA = 可用性を重視 P = 値段は高くても目をつぶる 設計施策例 ある特定のモデルのReserved Tier / Provisioned Throughput / PTUを必要分購入 C P 概要 C = モデル一貫性とP = 値段を重視 A = 可用性がなくて 429が出るのは許容 設計施策例 ある特定のモデルをリソース確保 なしのOnDemandで利用する AP 概要 A = 可用性とP = 値段を重視 C = モデル一貫性はあきらめる 設計施策例 AI Gatewayのようなプロダクトを 利用して複数モデルを分散利用 CA AP CP Consistency モデル一貫性 Availability 可用性 Price 値段
10. 冒頭の話を再掲 (問) この上司を満足させるアーキテクチャ戦略は作れるでしょうか？ LLMの料金高くない？ 一部安いモデルの利用を検討してみます？ Tuningとかこのモデル前提でやってるからあんまりモデル系列 変えたくないんだよな 429起きないようにリソース確保しようとすると こうなりますね LLMから応答なかったらこのプロダクトまともに機能しないから 429対策はなるべく打ちたいよね では1モデル前提でPTU購入検討しますか？ (冒頭に戻る)
11. 冒頭の話を再掲 (問) この上司を満足させるアーキテクチャ戦略は作れるでしょうか？ LLMの料金高くない？ 一部安いモデルの利用を検討してみます？ Tuningとかこのモデル前提でやってるからあんまりモデル系列 変えたくないんだよな 429起きないようにリソース確保しようとすると こうなりますね LLMから応答なかったらこのプロダクトまともに機能しないから 429対策はなるべく打ちたいよね では1モデル前提でPTU購入検討しますか？ (冒頭に戻る)
12. 折衷案 CAPすべてを同時に確保することは不可能でも、ビジネスサイド/プロダクトサイドとの調整を経て 以下のような設計を行うことは可能です。 CAP優先度の 折衷案（例） 初めはCP →徐々にAを導入 • 最初は一つのモデルで安く始める(=CP重視) • サービスが盛り上がってきたら以下を検討しAを向上させる • 複数モデルの利用(=Cを落とす) • プロビジョンドスループットの利用(=Pを落とす) AP前提の プロダクト設計 • 複数モデル利用を前提としたプロダクト設計にすることで、最 初からCを捨てる • （例）リクエスト時にユーザー自身にモデルを選択させる ユーザー層ごとに CAレベルを分離 • 高いモデル品質・高い可用性(=CA重視)でユーザーを確保 • サービスが軌道に乗った後、利用頻度が低いライトユーザー向 けに安価なモデルプランを提供することでPを下げる
13. 【まとめ】 アーキテクチャディスカッションするときに 本CAP定理をお使いください
14. Thank You ご意見、ご質問ありましたらお気軽にご連絡下さい haruka.sakihara@accenture.com Haruka Sakihara(崎原 晴香)