LocalAI QuickStart: ローカルで OpenAI 互換 LLM を実行する
数分で LocalAI を使用して、OpenAI 互換 API をセルフホストできます。
LocalAI は、ご自身のハードウェア(ノート PC、ワークステーション、オンプレミスサーバー)上で AI ワークロードを実行できるように設計された、自己完結型でローカルファーストの推論サーバーです。これは、OpenAI API と互換性のある「差し替え可能な」APIとして動作します。
このプロジェクトは、クラウド API の URL を差し替えるという実用的な互換性を目標としており、複数のバックエンドとモダリティ(テキスト、画像、音声、埋め込みベクトルなど)をサポートしています。

LocalAI とは何か、そしてエンジニアがなぜそれを使うのか
LocalAI は、チャット完了、埋め込みベクトル生成、画像生成、音声処理などの主要な OpenAI エンドポイントを模倣する HTTP REST API を提供します。これにより、既存の OpenAI 互換ツールを自前のインフラに指し向けることが可能になります。
基本的なテキスト生成を超えて、LocalAI の機能セットは、RAG 用の埋め込みベクトル、拡散モデルによる画像生成、音声からテキストへの変換、テキストから音声への変換といった、一般的な「生産環境で必要なビルドブロック」を網羅しており、オプションとして GPU アクセラレーションや分散パターンにも対応しています。
もし自己完結型 LLM サーバーの導入を検討されているなら、LocalAI はAPI 互換性に焦点を当てており(これにより統合が容易になります)、同時にモデルのインストールや設定における摩擦を減らすための内蔵 Web UI とモデルギャラリーのワークフローも提供しています。
Ollama、vLLM、Docker Model Runner、マネージドクラウドプロバイダーを含む、自己完結型とクラウドの LLM ホスティングオプションのより広範な比較については、2026 年版 LLM ホスティングガイドをご覧ください。
LocalAI を Ollama、vLLM、LM Studio などと比較したい場合は、2026 年の主要なローカル LLM ツールの比較では、API サポート、ハードウェア互換性、生産環境への対応をカバーしています。また、モデルを自前のインフラに保持することの広範な意義については、LLM の自己完結型ホスティングと AI 主権でデータ居住地とコンプライアンスの動機について説明しています。
実用的に動作する LocalAI インストールオプション
LocalAI には複数のインストール方法がありますが、多くのチームにとって最も迅速でリスクの低いスタートポイントは、コンテナ(Docker または Podman)です。以下の例を進める際にコマンドリファレンスが必要な場合は、Docker チートシートで、最も頻繁に使用される有用な Docker コマンドをカバーしています。
Docker による最速スタート
これで LocalAI サーバーが起動し、API と Web UI がポート 8080 にバインドされます。
docker run -p 8080:8080 --name local-ai -ti localai/localai:latest
LocalAI のコンテナドキュメントでは、これは動作するサーバーを迅速に立ち上げるための最速パスとされています。
API は http://localhost:8080 でアクセス可能です。
適切な LocalAI コンテナイメージの選択
LocalAI は複数のコンテナフレーバーを公開しており、あなたのハードウェアに合わせて選択できます:
- 広範な互換性を持つ CPU 用イメージ。
- NVIDIA CUDA、AMD ROCm、Intel oneAPI、Vulkan 向けの GPU 専用イメージ。
- OpenAI 風のモデル名にマッピングされたモデルが事前設定されたオールインワン(AIO)イメージ。
公式の GitHub README には、CPU 専用および複数の GPU オプション(NVIDIA CUDA バリアント、AMD ROCm、Intel、Vulkan)と AIO バリアント用の具体的な docker run 例が記載されています。
再起動間でモデルを永続化
ストレージをマウントしない場合、ダウンロードしたモデルはコンテナのライフサイクル変更を跨いで保持されない可能性があります。 コンテナガイドでは、モデルボリュームをマウントすることを推奨しています。例:
docker run -ti --name local-ai -p 8080:8080 \
-v "$PWD/models:/models" \
localai/localai:latest-aio-cpu
これにより、コンテナ内の /models がホスト上で永続化されます。
最小限の Docker Compose クイックスタート
LocalAI にはリポジトリ内に参考となる docker-compose.yaml も用意されており、ポート 8080 のバインド、/models ボリュームのマウント、MODELS_PATH=/models の設定、およびコマンドリストでモデルを事前読み込み(レポの例では phi-2)という一般的なパターンを示しています。これを環境に合わせて適応させる際は、Docker Compose チートシートが便利なリファレンスとなります。
CPU 用の「デフォルトとして良好な」Compose セットアップは以下のようになります。
services:
localai:
image: localai/localai:latest
container_name: local-ai
ports:
- "8080:8080"
volumes:
- ./models:/models
environment:
- MODELS_PATH=/models
重要なポイントは、公式の例と同じくホスト側のモデルディレクトリ ↔ コンテナ内の /models です。
LocalAI と併せて Docker のネイティブ docker model ツールも使用している場合、Docker Model Runner チートシートで、pull、run、package、設定コマンドをカバーしています。
コンテナ以外の LocalAI インストール
LocalAI では、プラットフォーム固有のメソッド(macOS 用 DMG や Linux バイナリなど)や、Kubernetes などのより広範なデプロイオプションもサポートしています。
Linux でのスクリプトによるインストールを好む場合は、DeepWiki のクイックスタートで、ハードウェアを自動検出してシステムを適切に設定する install.sh パスが説明されています。
予測可能な使用シーケンス
信頼性の高い LocalAI のワークフローは以下の通りです。
LocalAI を起動 → モデルをインストールまたはインポート → 読み込まれたモデルを確認 → OpenAI 互換エンドポイントを呼び出す。
このシーケンスは、公式の「試してみる」および「モデルの設定」ガイダンスと一致しており、サーバーの起動、ギャラリーまたは CLI を介したモデルのインストール、そして curl によるエンドポイントのテストというプロセスを想定しています。
サーバーの起動と正常性の確認
サーバーが実行された後、一般的な健全性チェックは読み取り専用エンドポイントです。
curl http://localhost:8080/readyz
トラブルシューティングガイドでは、LocalAI が応答可能であることを確認するための最初の診断として /readyz を使用しています。
ギャラリーからのモデルインストールまたは URI のインポート
LocalAI では、2 つの主要なモデルオンボーディングフローを提供しています。
- モデルギャラリーインストール:Web UI で UI を開き、Models タブに移動し、モデルを検索してインストールをクリックします。
- CLI 駆動のインストールと実行:
local-ai models list、local-ai models install、local-ai runを使用します。
ドキュメントでは、URI(Hugging Face リポジトリ、直接のモデルファイル URI、その他のレジストリ)からのモデルインポートもサポートしており、Web UI には高度な設定用の YAML エディターを備えた専用のインポートモデルフローも用意されています。
LocalAI が提供できると認識しているものを確認
OpenAI 互換 API を介してデプロイされたモデルを一覧表示するには:
curl http://localhost:8080/v1/models
これは、コンテナインストール後の「次のステップ」として、またトラブルシューティング診断として明示的に推奨されています。
学習する価値のある主要なコマンドラインパラメータ
LocalAI の CLI は local-ai run コマンドを中心に構築されており、包括的な設定機能を持っています。
2 つの重要な運用挙動を強調する必要があります。
- CLI フラグはすべて環境変数で設定できます。
- 環境変数は CLI フラグよりも優先されます。
以下は、実践者が早期に使用することになるパラメータを意図別にグループ化したリストです。
すべてのデフォルト値と環境変数名は、公式の CLI リファレンスから取得しています。LocalAI と併せて Ollama を評価している場合は、Ollama CLI チートシートで、比較のためにその serve、run、ps、およびモデル管理コマンドをカバーしています。
サーバーとストレージの核心フラグ
| 目的 | フラグ | 環境変数 | 備考 |
|---|---|---|---|
| バインドアドレスとポートの変更 | --address |
LOCALAI_ADDRESS |
デフォルトは :8080。 |
| モデルの保存場所の変更 | --models-path |
LOCALAI_MODELS_PATH |
永続化ストレージとディスク計画に重要。 |
| 状態と設定の分離 | --data-path |
LOCALAI_DATA_PATH |
エージェントの状態やジョブなど、永続データの保存先。 |
| アップロード先の設定 | --upload-path |
LOCALAI_UPLOAD_PATH |
ファイル関連の API 用。 |
LocalAI の FAQ でも、デフォルトのモデル保存場所が文書化されており、デフォルトディレクトリを圧迫しないように(例えばホームディレクトリを避けるため)モデルを外部に配置したい場合は LOCALAI_MODELS_PATH または --models-path を使用するよう明示的に推奨されています。
パフォーマンスと容量のフラグ
| 目的 | フラグ | 環境変数 | 備考 |
|---|---|---|---|
| CPU 使用率の調整 | --threads |
LOCALAI_THREADS |
物理コア数に一致させることが推奨され、パフォーマンスチューニングで広く使用されます。 |
| モデルごとのコンテキスト制御 | --context-size |
LOCALAI_CONTEXT_SIZE |
モデルのデフォルトコンテキストサイズ。 |
| GPU アクセラレーションモードの有効化 | --f16 |
LOCALAI_F16 |
「GPU アクセラレーションを有効にする」として文書化されています。 |
| メモリ上のロード済みモデル数の制限 | --max-active-backends |
LOCALAI_MAX_ACTIVE_BACKENDS |
超過時に LRU 淘汰を有効にし、メモリ使用量を制限できます。 |
| アイドルまたはフリーズしたバックエンドの停止 | --enable-watchdog-idle / --enable-watchdog-busy |
LOCALAI_WATCHDOG_IDLE / LOCALAI_WATCHDOG_BUSY |
多数のモデルを実行している場合や、不安定なバックエンドの場合に有用です。 |
より広範な互換性と加速制約については、モデル互換性テーブルで、どのバックエンドがどの加速モード(CUDA、ROCm、SYCL、Vulkan、Metal、CPU)をサポートしているかが文書化されており、明示的に設定されていないモデルは自動的にロードされる可能性もあるが、YAML 設定で動作を固定できることも記載されています。PagedAttention による高スループットなマルチ GPU 展開については、vLLM クイックスタートガイドで、生産環境向けの設定を備えた同等の OpenAI 互換サーバーのセットアップ手順が紹介されています。
API、セキュリティ、UI のフラグ
| 目的 | フラグ | 環境変数 | 備考 |
|---|---|---|---|
| API キーの要求 | --api-keys |
LOCALAI_API_KEY / API_KEY |
設定された場合、すべてのリクエストは設定済みのキーでの認証が必要です。 |
| ブラウザからの API 呼び出しを許可 | --cors / --cors-allow-origins |
LOCALAI_CORS / LOCALAI_CORS_ALLOW_ORIGINS |
必要な場合以外は無効にしておくこと。 |
| Web UI の完全無効化 | --disable-webui |
LOCALAI_DISABLE_WEBUI |
堅牢なデプロイ向けの API のみのモード。 |
| エラー応答の強化 | --opaque-errors |
LOCALAI_OPAQUE_ERRORS |
高セキュリティ環境で有用です。 |
LocalAI をリモートから公開する場合は、エンドポイントを保護し、API キーでアクセスを制限すべきです。 API キーは、事実上、フルアクセス権を付与します。
Web UI のツアーとシステムとのマッピング
デフォルトでは、LocalAI は API と併せて内蔵の Web UI を提供します(無効化しない限り)。ドキュメントでは、UI はサーバーと同じホストとポート(通常は http://localhost:8080)でアクセス可能であると説明されています。
内蔵 UI で何ができるか
Web UI は、ブラウザベースのインターフェースで、以下をカバーします。
- モデル管理とギャラリーの閲覧機能
- チャット対話
- 画像生成とテキストから音声へのインターフェース
- 分散および P2P 設定
ルート構造により、UI の機能領域が明確に把握できます。
/:ダッシュボード/browse:モデルギャラリーブラウザ/chat/:チャット/text2image/:画像生成/tts/:テキストから音声へ/talk/:音声対話/p2p:P2P 設定と監視
モデルギャラリーと「モデルのインポート」ワークフロー
エンジニアにとって最も重要な UI 機能は、モデルのオンボーディングです。 公式の「モデルの設定」ガイドでは、以下について説明しています。
- Models タブを使用したワンクリックインストール。
- 単純モード(URI + 設定)と、YAML エディターと検証ツールを備えた高度なモードをサポートする「モデルのインポート」UI を介したモデルのインポート。
これは、LocalAI が最終的にYAML 設定に基づいてモデルを実行するため、重要です。モデルディレクトリ内の個別の YAML ファイルを管理したり、--models-config-file を使用して単一のファイルで複数のモデル定義を使用したり、起動時にリモート YAML URL を参照したりすることができます。
コマンドラインに貼り付けて使える例
LocalAI の OpenAI 互換エンドポイントは、親しみやすいリクエスト形式を受け取り、JSON 応答を返すように設計されています(音声エンドポイントでは音声ペイロードを返します)。
curl によるチャット完了の例
LocalAI の「試してみる」ページでは、チャット完了エンドポイントを直接呼び出す方法が示されています。
curl http://localhost:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4",
"messages": [
{ "role": "user", "content": "LocalAI についての 1 段落の説明を書いてください。" }
],
"temperature": 0.2
}'
AIO イメージには、gpt-4 のような OpenAI 風の名称にマッピングされたモデルが事前設定されており、コンテナドキュメントでは、これらがオープンソースモデルによってバックアップされていると説明されています。
AIO イメージを使用していない場合は、インストールしたモデル名に "model" を置き換えてください(/v1/models で確認)。
RAG パイプライン用の埋め込みベクトルの例
LocalAI は、埋め込みベクトルとドキュメントをサポートしており、埋め込みエンドポイントは llama.cpp、bert.cpp、sentence-transformers を含む複数のバックエンドと互換性があります。
OpenAI 互換エンドポイントに対して「このテキストを埋め込む」最小限のリクエストは以下の通りです。
curl http://localhost:8080/v1/embeddings \
-H "Content-Type: application/json" \
-d '{
"model": "text-embedding-ada-002",
"input": "LocalAI の埋め込みベクトルは、セマンティック検索と RAG に便利です。"
}'
LocalAI の埋め込みベクトルドキュメントでは、embeddings: true を設定して YAML 設定によって埋め込みベクトルが有効になる方法も示されています。
OpenAI 互換クライアントの使用例
LocalAI は、標準的な OpenAI クライアントライブラリを LocalAI のベース URL に指し向けて使用できるよう設計されています(認証を設定した場合は API キーをオプションで設定)。この「差し替え可能な」目標は、公式の README と OpenAI 互換性ドキュメントの両方で説明されています。
典型的な設定は以下の通りです。
- ベース URL:
http://localhost:8080/v1 - API キー:デフォルトでは不要ですが、
--api-keysを設定した場合は必須です。
セキュリティとトラブルシューティングの必須事項
公開前に LocalAI サーバーを保護する
LocalAI はデフォルトでローカルホスト上のみで完全に公開された状態で実行できます。パブリックインターフェースにバインドするか、イングレス経由で公開する場合は、少なくとも以下のコントロールのいずれかを追加してください。
--api-keys/API_KEYを使用して API キー認証を有効にする。- 逆方向プロキシとネットワークコントロール(ファイアウォール、ホワイトリスト、VPN)を前面に配置する。
- API のみが必要な場合は Web UI を無効にする(
--disable-webui)。 - ブラウザベースのクライアントが本当に必要とする場合以外は、CORS を無効に保つ。
API キーが有効になっている場合、OpenAI 互換エンドポイントは、Authorization Bearer ヘッダーや x-api-key ヘッダーなどの一般的な場所で資格情報を接受します。
動作しない場合の迅速な診断
LocalAI のトラブルシューティングガイドでは、ほとんどの「動作しているか」の問題を解決する一連のチェックを推奨しています。
# 読み取り状態の確認
curl http://localhost:8080/readyz
# モデルの一覧表示
curl http://localhost:8080/v1/models
# バージョン確認
local-ai --version
また、DEBUG=true または --log-level=debug を介してデバッグログを有効化することや、Docker デプロイメントでは docker logs local-ai でコンテナログを確認することも文書化されています。