本番環境で大規模言語モデルを運用することは、もはやモデルのトレーニング、テスト、デプロイ、ダッシュボードの監視だけにとどまらない。現代のシステムは、プロンプト、ベクトルデータベース、ナレッジソースを接続し、正確性に加えて、トーン、安全性、信頼性に基づいて評価される、自由度の高いテキストを生成することがある。そこで、CNCFのブログに掲載された記事でダニエル・ブライアントは、実務的な問いを投げかけている。AIパイプラインを所有すべきなのは誰か、という問いである。
筆者は、その答えはLLMOpsに独立した王国を与えることではなく、適切に組織化されたエンジニアリングプラットフォームに組み込み、他のワークロードで開発チームが利用するものと同じインターフェースを通じて必要な能力を提供することにあると考えている。
LLMOpsとは何か？
LLMOpsとは、大規模言語モデルを開発、デプロイし、本番ライフサイクル全体にわたって管理するために必要なプラクティス、ツール、ワークフローの集合を指す。このライフサイクルには、データ管理、プロンプトエンジニアリング、ファインチューニング、デプロイと推論サービス、監視と評価に加え、セキュリティとガバナンスが含まれる。
分析によれば、LLMOpsは単なるMLOpsの言い換えではない。大規模言語モデルはファインチューニングとサービス提供のコストが高く、その出力の評価も、性能を明確な正解率の数値に還元することより難しい。モデルが正確であるだけでは不十分であり、安全で信頼できることも必要だが、これらの特性は測定がより複雑である。
また、モデルの運用は初回のデプロイで終わらない。モデルが以前の挙動から逸脱したり、コストが上昇したり、プロンプトが従来どおりに機能しなくなったりする可能性があり、顧客関係管理システムや社内ナレッジベースとの統合も継続的なフォローアップを必要とする。
プラットフォームエンジニアリングと交差するライフサイクル
LLMOpsのライフサイクルは、データ準備とプロンプトエンジニアリングから始まる。ここではプロンプトを一時的なテキストではなく、バージョン管理可能なアーティファクトとして扱う。さらに、Hugging Face Transformersのようなライブラリを使用したオープンな基盤モデルのファインチューニング、モデルとプロンプトのバージョニングおよび系譜の追跡、GPUで支えられたエンドポイントによる推論の提供、ドリフトとコストを検出するための人間のフィードバックに基づく監視も含まれる。
このライフサイクルの各部分には、インフラストラクチャ、アクセス制御、実行環境が必要であり、これらはもともとプラットフォームエンジニアリングの範囲に含まれる領域である。ただし筆者は、両分野の性質を区別している。プラットフォームエンジニアリングがインフラストラクチャを中心とするのに対し、MLOpsはモデルを中心とする。そのため、有用な問いは「誰がパイプラインを所有するのか」ではなく、「各レイヤーを誰が所有し、それらを実際に調整する主体が存在するのか」だと考えている。
並行スタックを構築する危険性
この分析では、ソフトウェアデリバリーの状況を、デプロイ要求に追われる可能性のあるDevOpsチーム、セルフサービスの標準パスを構築するプラットフォームエンジニアリングチーム、そしてDevOpsツールがデータのバージョン管理やドリフトの監視を想定して設計されていなかったために並行スタックを構築したMLOpsチームに分けている。LLMOpsが加わることで、プロンプト、ベクトルデータベース、RAGパイプラインのための独立した第3のスタックが、ガバナンスを担う主体から離れた場所に出現する可能性がある。
筆者は、この可能性を「シャドーAI運用」の問題と結び付けている。あるチームが独自のRAGパイプラインを構築し、審査を受けていないベクトルデータベースに接続することがあり、責任主体に実際に何が稼働しているのかが明確でない場合もある。分析によれば、最大の運用上の危険は、幻覚を生成するチャットボットだけではない。こうした能力がプラットフォームの外部に広がり、その後も可視性と制御の範囲外に残り続けることにある。
筆者は、それを防ぐためにチームの速度を落とすことを提案しているのではない。むしろ、利用の流れそのものにガバナンスを組み込みながら、プラットフォームが要求に迅速に応えられるようにすることを提案している。すぐに使えるパスがなければ、チームはプラットフォームの外部で能力を構築する可能性がある。一方、標準パスを提供すれば、そうした能力を管理可能な環境に戻すことが容易になる。
プラットフォームのレイヤーに組み込まれるLLMOps
ブライアントは、CNCFのTAG App Deliveryグループが発行したプラットフォームに関するホワイトペーパーの概念に基づいている。同文書では、環境を3つのレイヤーに分けている。最上位がプロダクト、中央が合理的に可能な限り薄い統合レイヤーとしてのプラットフォーム、最下位が能力プロバイダーである。
この概念に従えば、ファインチューニングジョブ、ベクトルデータベース、プロンプトログ、推論エンドポイントなどの機能を、別のプラットフォーム能力として扱うことができる。それらにも、他の能力と同様に、API、バージョン、明確な所有権が必要である。筆者は、このモデルを支援できるCNCFエコシステム内のツールにも言及している。Backstageはプロダクトレイヤーで標準パスを提示し、Crossplaneは下位レイヤーでインフラストラクチャを構成する。また、Kratix、KusionStack、KubeVelaなどのフレームワークは中央で機能し、他のサービスと同様のセルフサービス・インターフェースを通じてLLMパイプラインを利用可能にする。
パイプラインガバナンスの実務的な制御
この分析は、プラットフォームチームが次のような実務的な制御を採用することを提案している。
- 非公式なスクリプトではなく、ガバナンスされたAPI：ファインチューニングジョブ、プロンプトのデプロイ、推論エンドポイントの作成は、開発者のその他のニーズに使用するものと同じセルフサービス・インターフェースを通じて要求すべきである。
- 要求時のポリシー適用：クラウドサービスの請求書が現れてからではなく、ジョブを開始する前に、コスト上限、データレジデンシーのルール、モデルへのアクセス制御を検査すべきである。
- 影響の大きさに比例した人間による承認：すべてのプロンプトに事前承認が必要なわけではない。しかし、顧客の個人データを扱ったり、自律的な意思決定を行ったりするモデルには、それが必要になる場合がある。
- 明確な監査ログ：変更がモデル、プロンプト、データのいずれに関するものであっても、何が、なぜ変更されたのか、誰が承認したのか、または何が承認されたのかといった問いにログが答えられるようにすべきである。
筆者は、LLMパイプラインはプラットフォーム能力を利用するもう1つの自動化されたコンシューマーであり、人間の開発者や自律エージェントが受けるものと同じ保証を必要とすると結論付けている。このモデルで成功するチームは、DevOps、プラットフォーム、MLOpsの対立において一方を選ぶのではなく、パイプライン全体を、継続的なフィードバックループを備えた、リリース、監視、コスト考慮が可能なプロダクトとして扱う。
この意味で、ブライアントはLLMOpsが所有権の問題を解消したり、再発明したりするとは考えていない。むしろ、モデルの規模、コストの高さ、評価の難しさによって、既存のプラットフォームにより大きな圧力をかけるものだと見ている。彼の考えでは、解決策は標準パスを一度構築し、それをAPIまたは共通のユーザーインターフェースを通じて、開発者、データサイエンティスト、インテリジェントエージェントのすべてに、ガバナンスされた能力として提供することである。この議論はCNCF内で継続しており、特にTAG App Delivery傘下のPlatforms Working Groupで行われている。同グループは、議論への貢献を希望する人に開かれている。