🐟
M4 Mac MiniでLLM+AIアプリを開発する場合のアーキテクチャを考える
はじめに
前回の記事で、M4 Mac MiniでコンテナからGPUを利用する環境を構築したが、そもそも論として、LLMとAIアプリを開発するためのアーキテクチャについて考えます。
アーキテクチャ
今回考慮するアーキテクチャは、M4 Mac Miniを活用した場合の、GPU、LLM、AIアプリのそれぞれの関連性と実現性について考察を行います。表題の||は同一コンピュータ内であることを、()はコンテナを示しています。
|GPU-LLM-App|パターン
- 概要
- 単一のM4 Mac Mini内に、LLMとAPPをモノリシックに構築するパターン
- 良い点
- 利用するソフトウェアによるが、GPU-LLM間がネイティブに操作することができるため、環境構築作業の苦労が少ない
- 悪い点
- 複数のLLM、APPのスケールが困難
- 環境が汚れがちで、依存関係の制御が困難
- 特に、AI開発ではその特性上Pythonの依存関係が強く、App側の開発でビルド&スクラップをすることによるpipの崩壊等で、気がついたらLLMが動かない等が起こる。
- ユースケース例
- MLX ※1
|GPU-LLM-(App)|パターン
- 概要
- 単一のM4 Mac Mini内に、LLMをモノリシック、APPをコンテナに構築するパターン
- 良い点
- |GPU-LLM-App|パターンと同様
- Appが分離しているため、App由来による環境破壊が少ない
- 複数のAppを動作させる、マルチサービス化が容易
- 悪い点
- 複数のLLMを共存させることが困難
- コンテナ環境のメンテナンス
- ユースケース例
- MLX ※1
- 単一AIによるマルチサービス
|GPU-(LLM)-APP|パターン
- 概要
- 単一のM4 Mac Mini内に、LLMをコンテナ、APPをモノリシックに構築するパターン
- 良い点
- 複数のLLMを単一の環境で利用可能
- LLMが分離しているため、LLM由来による環境破壊が少ない
- 複数のLLMを動作させる、マルチAI・エージェント化が容易
- 悪い点
- 複数のAppを運用することが困難
- コンテナ環境のメンテナンス
- ユースケース例
- マルチAIによる単一サービス
|GPU-(LLM)-(APP)|パターン
- 概要
- 単一のM4 Mac Mini内に、LLMとAppをコンテナに構築するパターン
- 良い点
- |GPU-LLM-(App)|∪|GPU-(LLM)-APP|
- 悪い点
- コンテナ環境のメンテナンス
- ユースケース例
- スケーラブルなAIサービス
|GPU-LLM|-APPパターン
- 概要
- M4 Mac Mini内にLLMをモノリシックに、外部にAppを構築するパターン
- 良い点
- |GPU-LLM-(App)|と同様
- LLM関連以外の運用をM4 Mac Mini内で運用しなくて良い
- 悪い点
- |GPU-LLM-(App)|と同様
- LLMを利用するためのAPIを構築しなければならない
- ユースケース例
- 単一のAIをAPIとして、Appで利用
|GPU-(LLM)|-APPパターン
- 概要
- M4 Mac Mini内にLLMをコンテナに、外部にAppを構築するパターン
- 良い点
- |GPU-(LLM)-(App)|と同様
- LLM関連以外の運用をM4 Mac Mini内で運用しなくて良い
- 悪い点
- |GPU-(LLM)-(App)|と同様
- LLMを利用するためのAPIを構築しなければならない
- ユースケース例
- 複数のAIをAPIとして、Appで利用
おわりに
個人的には、LLMをコンテナ上で動かすモデルを利用したいと考えていますが、M4 Mac Miniの販売から日が浅い今、様々なトラブルに見舞われています。次回は、M4 Mac MiniにおけるGPUとLLMライブラリ・プラットフォーム活用の現状と問題点について書きたいと思います。特にMLX※1をコンテナで利用する場合の問題について示します。
Discussion