True ML Talks #23 - GitLabにおけるMLOpsとLLMアプリケーション

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
True ML Talksの新しいエピソードをお届けします。今回も、GitLabにおけるMLOpsとLLMのアプリケーションについて深く掘り下げ、お話しするのは Monmayuri Ray。
モンマユリは、 GitLab でAI研究部門を率いており、過去1年間、LLMに重点を置いています。それ以前は、GitLabのModelOps部門でエンジニアリングマネージャーを務めていました。MicrosoftやeBayなどの企業でも勤務経験があります。
📌
モンマユリ氏との対談では、以下の点について取り上げます。
- GitLabにおけるMLとLLMのユースケース
- 大規模言語モデル(LLM)をサポートするためのGitLabのMLインフラの進化
- GitLabのLLMへの道のり:オープンソースからファインチューニングまで
- GitLabでの大規模言語モデルのトレーニング
- LLM推論のためのTriton vs. PyTorch、アンサンブルGPU、動的バッチ処理
- GitLabにおけるLLM評価の課題と研究
- GitLabのLLMアーキテクチャとLLMの未来
全編はこちらからご覧ください:
GitLabにおけるMLとLLMのユースケース
機械学習(ML)はソフトウェア開発ライフサイクルを変革しており、GitLabはこのイノベーションの最前線にいます。GitLabはMLを活用し、課題の作成からマージリクエスト、アプリケーションのデプロイまで、開発者のあらゆるプロセスを支援しています。
GitLabにおけるMLの最も興味深いユースケースの一つが、大規模言語モデル(LLM)です。GitLabはLLMと生成AIを活用し、コード補完や課題の要約といった製品の新機能開発を進めています。
GitLabユーザーにとってのMLのメリット
- 生産性の向上: MLは、コード補完や課題の要約などのタスクを自動化することで、開発者の生産性向上に貢献します。
- コード品質の向上: MLは、潜在的なエラーを特定し、改善策を提案することで、開発者がより良いコードを書くのに役立ちます。
- 開発時間の短縮: MLは、タスクを自動化し、問題をより迅速に特定して修正するのを支援することで、開発者がソフトウェア開発にかかる時間を短縮するのに役立ちます。
- 開発者エクスペリエンスの向上: MLは、GitLab製品をより使いやすくし、サポートとガイダンスを提供することで、開発者エクスペリエンスの向上に貢献します。
大規模言語モデル(LLM)をサポートするためのGitLabのMLインフラストラクチャの進化
GitLabは、大規模言語モデル(LLM)を活用して開発者を支援する最前線にいます。その結果、GitLabはこれらの複雑なモデルをサポートするためにMLインフラストラクチャを進化させる必要がありました。
課題
- 規模と複雑さ: LLMは従来のMLモデルよりもはるかに大規模で複雑です。そのため、トレーニングとデプロイにはより強力なハードウェアとソフトウェアが必要です。
- 統合: GitLabの製品はRuby on RailsとJavaScriptで書かれています。そのため、GitLabはMLインフラストラクチャをこれらのテクノロジーと統合する方法を見つける必要がありました。
- 分散インフラストラクチャ: GitLabのMLインフラストラクチャは、複数の異なるクラウドプロバイダーに分散されています。そのため、GitLabはMLインフラストラクチャを一貫性のある効率的な方法で管理する手段を開発する必要がありました。
ソリューション
上記の課題に対処するため、GitLabはMLインフラストラクチャにいくつかの変更を加えました。これらの変更は、以下の分野に分類できます。
- ハードウェア: GitLabは、LLMのトレーニングとデプロイをサポートするため、GPUやTPUなどの新しいハードウェアに投資しました。
- ソフトウェア: GitLabは、LLM向けの新しいトレーニングおよびデプロイパイプラインを開発しました。また、MLインフラストラクチャをRuby on RailsおよびJavaScriptアプリケーションと連携させるための統合ソリューションもいくつか開発しました。
- 管理: GitLabは、分散型MLインフラストラクチャの管理を支援するため、いくつかのツールとプロセスを開発しました。
GitLabのLLMとの歩み:オープンソースからファインチューニングまで
GitLabは、大規模言語モデル(LLM)を活用して開発者を支援する最前線に立ってきました。初期には、GitLabは オープンソースLLM、Salesforceのコード生成などのように。しかし、状況が変化し、LLMがより強力になるにつれて、GitLabはコード生成などの特定のユースケース向けに独自のLLMをファインチューニングする方向に移行しました。
LLMのファインチューニングには、これらのモデルが非常に大規模で複雑であるため、インフラストラクチャへの多大な投資が必要です。GitLabは、LLM向けの新しいトレーニングおよびデプロイパイプラインを開発する必要があり、また、分散環境でMLインフラストラクチャを管理する新しい方法も開発する必要がありました。
GitLabがLLMのファインチューニングで直面した主要な課題の1つは、コストとレイテンシの適切なバランスを見つけることでした。LLMはトレーニングとデプロイに非常に費用がかかり、結果の生成も遅くなることがあります。GitLabは、ニーズに合った適切なバランスを見つけるために、さまざまなクラスターサイズ、GPU構成、バッチ処理技術を試す必要がありました。
GitLabが直面したもう1つの課題は、LLMの精度と信頼性を確保することです。LLMはテキストとコードの膨大なデータセットでトレーニングできますが、これらのデータセットにはエラーやバイアスが含まれる可能性もあります。GitLabは、LLMを評価し、バイアスを除去するための新しい技術を開発する必要がありました。
これらの課題にもかかわらず、GitLabはLLMを活用して開発者を支援する上で大きな進歩を遂げました。GitLabは現在、LLMを大規模にトレーニングおよびデプロイすることができ、これらのモデルを使用して、ソフトウェア開発プロセスをより効率的で楽しいものにする新しい機能や製品を開発しています。
GitLabでの大規模言語モデルのトレーニング
大規模言語モデル(LLM)のトレーニングは、インフラストラクチャとリソースへの多大な投資を必要とする困難なタスクです。GitLabは、LLMを活用して開発者を支援する最前線に立っており、その過程で多くのことを学びました。
GitLabのLLMトレーニング経験から得られたいくつかの洞察と学んだ教訓を以下に示します。
- 小さく始めて段階的にスケールアップする。 トレーニングに必要なGPUリソースの量を推定する際は、小さく始めて徐々にスケールアップするのが最善です。これにより、リソースの無駄を避け、潜在的なボトルネックを早期に特定するのに役立ちます。
- 動的バッチ処理を活用する。 動的バッチ処理は、類似する入力をまとめてグループ化することで、トレーニングプロセスを最適化するのに役立ちます。これは、特に大規模なデータセットにおいて、大幅なパフォーマンス向上につながります。
- 最適化する適切なパラメータを選ぶ。 LLMをファインチューニングする際に最適化すべき適切なパラメータを選択する上で、万能なアプローチというものはありません。最適なパラメータは、特定のLLM、トレーニングデータ、および望ましい結果によって異なります。しかし、特定のニーズに最適な組み合わせを見つけるためには、さまざまなパラメータを試すことが重要です。
- 分散トレーニングの利用を検討する。 分散トレーニングは、複数のGPUまたはマシンにワークロードを分散することで、トレーニングプロセスを高速化するのに役立ちます。これは、大規模なデータセットで大規模なLLMをトレーニングする場合に特に有益です。
- 低ランク適応モードを試す。 低ランク適応モードは、より少ないパラメータでLLMをファインチューニングするために使用できる手法です。これは、モデル全体をファインチューニングするのに十分なリソースがない場合に役立ちます。
上記の知見に加えて、GitLabはベースモデルとトレーニングデータをよく理解することの重要性について、多くの貴重な教訓も学びました。例えば、GitLabは、ベースモデルの構造を理解し、望ましいユースケースに合わせてトレーニングデータをキュレーションする方法を知ることが重要であると認識しています。
Triton 対 PyTorch、アンサンブルGPU、およびLLM推論のための動的バッチ処理
GitLabがLLM推論にTritonを使用しているのは、GitLabが受ける大量のリクエストに対応するスケーリングにより適しているためです。また、TritonはPyTorchサーバーのような他のモデルサーバーよりも、ラップしてスケーリングするのが容易です。
GitLabは、Hugging FaceのTGIまたはVLLMモデルサーバーをまだ試していません。これらはGitLabがLLM推論パイプラインを最初にデプロイした時点ではまだ開発の初期段階にあったためです。
動的バッチ処理に関して言えば、GitLabの戦略は、特定のユースケース、負荷、クエリレベル、ボリューム、および利用可能なGPUの数に合わせて最適化することです。例えば、GitLabが7Bモデル用に500個のGPUを持っている場合、より小さなモデル用に数個のGPUしか持っていない場合とは異なるバッチ処理戦略を使用できます。
GitLabは、リクエストを処理するためにGPUアンサンブルも使用しています。これは、GitLabが高性能GPUと低性能GPUを含む、さまざまな種類のGPUを組み合わせて使用していることを意味します。GitLabは、パフォーマンスとコストを最適化するために、GPUアンサンブル全体でリクエストの負荷分散を行っています。
GPUをアンサンブルし、負荷分散を最適化するためのアーキテクチャを設計するヒントをいくつか紹介します。
- トラフィックパターンを理解する。ピークトラフィック時間はいつですか?最も頻繁に受信するリクエストの種類は何ですか?
- A/Bテストを使用して、さまざまなGPU構成と負荷分散戦略を試す。
- パフォーマンスとレイテンシを監視し、アーキテクチャがニーズを満たしていることを確認する。
GitLabがアンサンブルGPUと動的バッチ処理のためにアーキテクチャを最適化した方法の具体的な例をいくつか紹介します。
- GitLabは、リクエストをGPUに、その種類、パフォーマンス、および可用性に基づいて割り当てるために、動的なオーケストレーションシステムを使用しています。
- GitLabは、GPUが必要なときにリクエストを処理できるよう、「GPUウォームアップ」と呼ばれる技術を使用しています。
- GitLabは、精度を犠牲にすることなくモデルのサイズを削減するために、量子化を使用しています。
これらのヒントに従うことで、大量のLLM推論リクエストを効率的に処理できるアーキテクチャを設計できます。
ストリーミングも試しており、サードパーティ向けにもストリーミングを検討しているところです - モンマユリ
GitLabにおけるLLM評価の課題と研究
大規模言語モデル(LLM)の性能を評価することは、困難な作業です。GitLabはこの問題に取り組んでおり、いくつかの課題に直面してきました。その課題とは以下の通りです。 [SEG 8] 異なるユースケースには異なるニーズがあります。 [SEG 9] チャット、コード提案、脆弱性説明など、異なるLLMのユースケースには、それぞれ異なるニーズがあり、異なる評価指標が必要です。
- 特定のクエリに対してどのモデルが最適かを知ることは困難です。 特定のクエリに対してどのLLMが最も優れたパフォーマンスを発揮するかを判断することは困難です。特に本番環境では。
- 精度と受容率のバランスを取ることは困難です。 LLMの結果の精度と、ユーザーによるこれらの結果の受容率との間でバランスを見つけることが重要です。
- GitLabは、以下の方法でこれらの課題に取り組んでいます。 各ユースケースに適したデータセットをキュレーションする。
GitLabは、ユーザーが本番環境で送信するクエリのタイプを代表する、各LLMユースケース向けのデータセットをキュレーションしています。
- 過去のデータを分析する。 GitLabは、過去にLLMが異なる種類のクエリに対してどのようにパフォーマンスを発揮したかを理解するために、過去のデータを分析しています。
- 新しい評価指標を開発する。 GitLabは、特定のLLMユースケースに合わせて調整された新しい評価指標を開発しています。
- データに基づいた意思決定。 GitLabは、さまざまなユースケースにどのLLMを使用するか、またこれらのLLMのパラメータをどのように調整するかについて、データを活用して意思決定を行っています。
GitLabの目標は、LLMを評価するためのスケーラブルでデータ駆動型のアプローチを開発することです。このアプローチにより、GitLabはLLMが本番環境で適切に機能し、ユーザーのニーズを満たしていることを確実にできます。
研究の方向性
GitLabは、LLMを評価する新しい方法についても研究を進めています。GitLabが探求している研究の方向性には、以下のようなものがあります。
- ヒューマンコンピュータインタラクション(HCI)データを用いたLLMの評価。 HCIデータは、ユーザーがLLMとどのようにインタラクションし、その結果をどのように認識しているかについての洞察を提供します。このデータは、LLMの新しい評価指標を開発するために活用できます。
- 敵対的アプローチを用いたLLMの評価。 敵対的アプローチは、LLMを誤動作させるように設計された入力を生成するために使用できます。このデータは、さまざまな種類のエラーに対するLLMの堅牢性を評価するために活用できます。
- 転移学習を用いたLLMの評価。 転移学習は、各タスクごとに新しいデータセットを収集することなく、新しいタスクでLLMを評価するために使用できます。これは、データ収集が困難または高価なタスクでLLMを評価するのに役立ちます。
GitLabのLLM評価に関する研究は進行中です。GitLabは、LLMがユーザーのニーズを満たしていることを確実にするため、LLMを評価する新しい革新的な方法の開発に尽力しています。
GitLabのLLMアーキテクチャとLLMの未来
GitLabのLLMアーキテクチャは、トレーニング、評価、そして LLMのデプロイに対する包括的なアプローチです。このアーキテクチャは、柔軟性とスケーラビリティを備えるように設計されており、GitLabが新しいテクノロジーを容易に採用し、ユーザーのニーズを満たせるようにしています。

このアーキテクチャは、いくつかの主要なコンポーネントで構成されています。
- データの前処理とトークン化: GitLabのLLMアーキテクチャは、LLMのトレーニングに使用されるデータを前処理し、トークン化することから始まります。このプロセスには、データのクリーンアップ、ノイズの除去、テキストをLLMが理解できる形式への変換が含まれます。
- サンプリングと短縮: データが前処理され、トークン化された後、GitLabのLLMアーキテクチャはデータをサンプリングし、短縮します。これは、LLMのトレーニングにかかる計算コストを削減するために行われます。
- GPUスイート: GitLabのLLMアーキテクチャは、LLMのトレーニングにGPUスイートを使用します。GPUは、LLMのトレーニングに非常に適した特殊なプロセッサです。
- 評価スイート: GitLabのLLMアーキテクチャには、LLMのパフォーマンスを評価するための評価スイートが含まれています。この評価スイートには、精度、流暢さ、一貫性など、さまざまな指標が含まれます。
- モデルチェックポイント: GitLabのLLMアーキテクチャは、モデルのチェックポイントを定期的に保存します。これにより、問題が発生した場合でも、GitLabは以前の時点からトレーニングを再開できます。
- プロンプトライブラリ: GitLabのLLMアーキテクチャにはプロンプトライブラリが含まれており、これはLLMからさまざまな種類のテキストを生成するために使用できるプロンプトのコレクションです。
- モデルレジストリ: GitLabのLLMアーキテクチャにはモデルレジストリが含まれており、これはGitLabのすべてのLLMモデルのための一元的なリポジトリです。
- デプロイエンジン: GitLabのLLMアーキテクチャには、LLMを本番環境にデプロイするデプロイエンジンが含まれています。このデプロイエンジンには、LLMの複数のインスタンス間でトラフィックを分散するためのロードバランサーが含まれています。
GitLabのLLMアーキテクチャは、GitLabがLLMを大規模にトレーニング、評価、デプロイすることを可能にする強力なツールです。このアーキテクチャは、GitLabが新しいテクノロジーを容易に採用し、ユーザーのニーズを満たせるよう、柔軟性と拡張性を持つように設計されています。
LLMの未来
LLMはまだ比較的新しいテクノロジーですが、多くの産業に革命をもたらす可能性を秘めています。GitLabは、LLMがソフトウェア開発業界に大きな影響を与えると信じています。
GitLabはすでにLLMを使用して製品とサービスを改善しています。例えば、GitLabはLLMを活用してコードの提案を生成したり、脆弱性を説明したり、製品のユーザーエクスペリエンスを向上させたりしています。
GitLabは、他の組織もLLMに投資すべきだと考えています。LLMは、多くの産業において生産性、効率性、品質を向上させる可能性を秘めています。
投資すべき分野
GitLabは、LLM分野で優位に立つために、組織が以下の分野に投資することを推奨しています:
- インフラストラクチャ: LLMには、インフラストラクチャへの多大な投資が必要です。組織はLLMをサポートするために、GPU、ストレージ、ネットワークに投資する必要があります。
- ツールとテクノロジー: 組織がLLMのトレーニング、評価、デプロイを行うのに役立つツールやテクノロジーは数多くあります。組織は、自社のニーズに合ったツールやテクノロジーに投資すべきです。
- 人材: LLMは複雑なテクノロジーです。組織は、LLMのトレーニング、評価、デプロイを行うためのスキルと知識を持つ人材に投資する必要があります。
これらの分野に投資することで、組織はLLM分野で時代の先を行き、この強力なテクノロジーの恩恵を享受することができます。
True ML Talksシリーズの以前のブログもご覧ください:
引き続きTrueMLを YouTubeシリーズ およびTrueMLを ブログシリーズご覧ください。
TrueFoundry は、Kubernetes上のMLデプロイメントPaaSであり、開発者のワークフローを加速させるとともに、モデルのテストとデプロイにおいて完全な柔軟性を提供し、インフラチームには完全なセキュリティと制御を保証します。当社のプラットフォームを通じて、機械学習チームは デプロイと監視 を15分で、100%の信頼性、スケーラビリティ、そして数秒でのロールバック機能を提供し、コストを削減し、モデルをより迅速に本番環境にリリースすることを可能にし、真のビジネス価値の実現を可能にします。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.














.webp)
.webp)



.png)

.png)














