「メンバーごとに月の利用量を制限したいが、NginxのBasic認証では個別管理ができない」
そんな課題を抱えるインフラ担当者やサーバー管理者は多いはずです。この記事では、OllamaのフロントエンドにLiteLLMプロキシを導入し、チームメンバーごとのバーチャルAPIキー発行・月額予算制限・リクエスト数上限(rpm_limit)を実装する手順を解説します。Ollamaの基本構築が済んでいるUbuntu Server環境を前提に、アクセス制御レイヤーを追加します。OpenAI互換のエンドポイントはそのまま維持できるため、既存クライアントコードへの影響を最小限に抑えられます。
この記事のポイント
・pip install 'litellm[proxy]' でOllamaの前段にAPIゲートウェイを追加できる
・/key/generate でメンバーにバーチャルAPIキーを発行しモデルと予算を個別設定できる
・rpm_limitとmax_budgetでキー単位のレート制限と月額上限を実装できる
・base_urlをlocalhost:4000に変えるだけで既存のOpenAIクライアントコードがそのまま動く
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜOllamaの前段にLiteLLMプロキシが必要なのか
Ollama単体はシングルユーザーまたは小規模チームの利用を想定した設計で動作する。デフォルトでは認証なしのオープンエンドポイントを提供しており、社内ネットワーク内のどの端末からでも制限なくモデルを呼び出せる状態になる。知人のインフラエンジニアから聞いた話では、Ollamaをチームサーバーに展開した直後から、意図しないバッチ処理が大量のコンテキストを詰め込んだリクエストを連発し、GPUメモリが枯渇してチーム全員の作業が止まったことがあったという。誰がどのリクエストを送ったかのログも残っておらず、原因特定に2時間近くかかったそうだ。
NginxのBasic認証でOllamaを外部に公開してもメンバー個別の利用管理はできない。LiteLLMはその部分を補うAPIゲートウェイとして機能し、Ollamaの前段に置くことで以下の機能を追加できる:
・バーチャルAPIキーの発行(メンバーに個別の sk- で始まるキーを配布)
・キー単位の月額トークン予算(max_budget)
・キー単位のリクエスト数上限(rpm_limit)
・キー単位のトークン数上限(tpm_limit)
・モデル別の利用ログ(SQLiteまたはPostgreSQL)
・複数バックエンドの統一管理(Ollama以外にOpenAI・Anthropicも同じAPIで呼び出せる)
これらはOpenAI互換のまま提供されるため、クライアント側のコード変更は接続先のbase_urlとapi_keyを差し替えるだけで済む。社内でのローカルLLM導入判断のフローや情シス向けの説得材料については、社内でChatGPTが使えないときの代替手段も参考になる。
LiteLLMをUbuntu Serverにインストールする方法
1. 前提環境を確認する
本記事の手順はUbuntu 22.04 LTS・Python 3.10以降・Ollama 0.3.x以降を前提とする。まずOllamaが11434番ポートで正常に稼働していることを確認する。# Ollamaの稼働状態とモデル一覧を確認する $ curl -s http://localhost:11434/api/tags | python3 -m json.tool | head -12 { "models": [ { "name": "llama3.3:70b-instruct-q4_0", "modified_at": "2026-06-01T10:00:00Z", "size": 42000000000 }, { "name": "mistral:7b-instruct-q8_0", "modified_at": "2026-06-01T09:00:00Z", "size": 7700000000 } ] }
ollama pull llama3.3:70b-instruct-q4_0 でモデルを取得してから進める。
2. Pythonの仮想環境を作成する
LiteLLMはPythonパッケージとして提供される。システムのPythonを汚染しないよう、専用の仮想環境を用意する。# 仮想環境の作成と有効化 $ python3 -m venv /opt/litellm-env $ source /opt/litellm-env/bin/activate # LiteLLMプロキシのインストール(proxy extras必須) (litellm-env) $ pip install 'litellm[proxy]' # インストール後にバージョン確認 (litellm-env) $ litellm --version LiteLLM: v1.44.x
proxy extrasを省いて pip install litellm だけでは litellm CLIコマンドが使えない。インストールには回線速度にもよるが1~3分程度かかる。
3. LiteLLMをsystemdサービスとして登録する
Ollamaと同様、LiteLLMもサーバー起動時に自動起動するsystemdサービスとして管理する。設定ファイルは次のステップで作成するが、先にユニットファイルだけ用意しておく。# /etc/systemd/system/litellm.service を作成する $ sudo tee /etc/systemd/system/litellm.service <<'EOF' [Unit] Description=LiteLLM Proxy Server After=network.target ollama.service Requires=ollama.service [Service] Type=simple User=ubuntu WorkingDirectory=/opt/litellm ExecStart=/opt/litellm-env/bin/litellm --config /opt/litellm/config.yaml Restart=always RestartSec=5 Environment=LITELLM_MASTER_KEY=sk-master-your-strong-random-key-here [Install] WantedBy=multi-user.target EOF
LITELLM_MASTER_KEY は管理者専用のマスターキーで、後述のAPIキー発行や管理操作に使う。【重要】必ず十分な長さのランダム文字列に置き換えること。このキーが漏洩すると全メンバーのキーが制御不能になるため、管理者だけが知る形で保管する。Requires=ollama.service と記述することで、Ollamaが起動する前にLiteLLMが立ち上がって接続エラーになるケースを防いでいる。
LiteLLMのconfig.yamlでOllamaをバックエンドとして設定する方法
1. 設定ディレクトリとconfig.yamlを作成する
# 設定ディレクトリを作成してubuntuユーザーに所有権を付与する $ sudo mkdir -p /opt/litellm $ sudo chown ubuntu:ubuntu /opt/litellm
/opt/litellm/config.yaml を作成する。model_name はクライアントがリクエスト時に model パラメータに指定する名前になる。
# /opt/litellm/config.yaml model_list: - model_name: llama3.3-70b litellm_params: model: ollama/llama3.3:70b-instruct-q4_0 api_base: http://localhost:11434 - model_name: mistral-7b litellm_params: model: ollama/mistral:7b-instruct-q8_0 api_base: http://localhost:11434 - model_name: gemma3-27b litellm_params: model: ollama/gemma3:27b-instruct-q4_0 api_base: http://localhost:11434 litellm_settings: request_timeout: 600 num_retries: 2 drop_params: true general_settings: database_url: "sqlite:///./litellm.db" store_model_in_db: true
ollama/ プレフィックスをつけることでLiteLLMがOllamaバックエンドと認識する。モデルタグの指定方法や各モデルの特性についてはローカルLLMのモデルを比較する方法を参考にすると、チームのユースケースに合ったモデルを選定しやすい。drop_params: true は、OpenAI特有のパラメータ(n や presence_penalty など)をOllamaが受け付けない場合にエラーにせず無視する設定だ。既存のOpenAIコードをそのまま流用する際にほぼ必須の設定になる。request_timeout: 600 は70Bモデルで長いプロンプトを処理する際のタイムアウト対策として設定している。
2. systemdを有効化してプロキシを起動する
# サービスを有効化して起動する $ sudo systemctl daemon-reload $ sudo systemctl enable --now litellm # 起動状態を確認する(active (running) になればOK) $ sudo systemctl status litellm * litellm.service - LiteLLM Proxy Server Loaded: loaded (/etc/systemd/system/litellm.service; enabled) Active: active (running) since Sun 2026-07-12 10:00:00 JST # ヘルスチェックで4000番ポートの動作を確認する $ curl -s http://localhost:4000/health {"status":"healthy","litellm_status":"healthy"}
チームメンバーにAPIキーを発行する方法
1. マスターキーでバーチャルAPIキーを発行する
LiteLLMのバーチャルキーはREST APIで発行する。管理者はsystemdの環境変数に設定したLITELLM_MASTER_KEY を使って /key/generate エンドポイントを呼び出す。
# メンバー「yamada」用のAPIキーを発行する $ curl -s -X POST http://localhost:4000/key/generate \ -H "Authorization: Bearer sk-master-your-strong-random-key-here" \ -H "Content-Type: application/json" \ -d '{ "models": ["llama3.3-70b", "mistral-7b"], "max_budget": 5.0, "budget_duration": "30d", "metadata": {"user": "yamada", "team": "backend"} }' | python3 -m json.tool { "key": "sk-v2-yamada-abcdef1234567890xxxx", "models": ["llama3.3-70b", "mistral-7b"], "max_budget": 5.0, "budget_duration": "30d", "metadata": {"user": "yamada", "team": "backend"} }
models に列挙したモデルしか呼び出せない。30日間で max_budget を超えると自動的に429エラーが返る。ローカルLLMでは実際に課金は発生しないが、LiteLLMは内部的にトークン単価を計算して予算を消費する。手軽に試したい段階では
"max_budget": null で無制限にし、チームの使い方が安定してきたら制限を付けるのが現実的な進め方だ。
2. 有効期限付きのキーを発行する
外部委託メンバーや一時的なアクセスにはduration パラメータが使える。1d(1日)・7d(7日)・30d(30日)形式で指定する。
# 7日間限定のAPIキーを発行する(外部委託メンバー向け) $ curl -s -X POST http://localhost:4000/key/generate \ -H "Authorization: Bearer sk-master-your-strong-random-key-here" \ -H "Content-Type: application/json" \ -d '{ "models": ["mistral-7b"], "duration": "7d", "metadata": {"user": "contractor-abc", "purpose": "review-task"} }'
3. 発行済みキーの確認と失効
# 発行済みキーの一覧を取得する $ curl -s http://localhost:4000/key/list \ -H "Authorization: Bearer sk-master-your-strong-random-key-here" \ | python3 -m json.tool # キーを即時失効させる(問題のあるメンバーのキーを停止する場合) $ curl -s -X POST http://localhost:4000/key/delete \ -H "Authorization: Bearer sk-master-your-strong-random-key-here" \ -H "Content-Type: application/json" \ -d '{"keys": ["sk-v2-yamada-abcdef1234567890xxxx"]}'
metadata・max_budget・budget_used・expires が含まれる。誰のキーがどれだけ予算を消費しているかを管理者が定期的に確認する運用に使える。
利用量上限とレート制限を設定する方法
1. リクエスト数上限(rpm_limit)を設定する
rpm_limit(Requests Per Minute)でキーごとの1分間あたりリクエスト数を制限できる。GPUが1枚しかない環境で特定のメンバーが帯域を占有するケースを防ぐ設定として有効だ。
# rpm_limitとtpm_limitを設定してキーを発行する $ curl -s -X POST http://localhost:4000/key/generate \ -H "Authorization: Bearer sk-master-your-strong-random-key-here" \ -H "Content-Type: application/json" \ -d '{ "models": ["llama3.3-70b", "gemma3-27b"], "rpm_limit": 10, "tpm_limit": 50000, "max_budget": 20.0, "budget_duration": "30d", "metadata": {"user": "sasaki", "team": "data-science"} }'
tpm_limit(Tokens Per Minute)はバッチ処理など大量トークンを一度に処理するケースを制限する。GPUメモリが8GB程度の小型サーバーを複数人で共有する環境では、両方の制限を組み合わせて設定するのが安定運用のコツだ。チームが増えてくると部署ごとに上限を変えたいケースが出てくる。データサイエンスチームには緩め(rpm: 20)、一般業務チームには厳しめ(rpm: 5)のように差をつけることで、重要な推論ジョブが常に帯域を確保できる。
2. 発行済みキーのパラメータを後から変更する
発行済みキーの制限値は/key/update で後から変更できる。
# 発行済みキーのrpm_limitとmax_budgetを変更する $ curl -s -X POST http://localhost:4000/key/update \ -H "Authorization: Bearer sk-master-your-strong-random-key-here" \ -H "Content-Type: application/json" \ -d '{ "key": "sk-v2-yamada-abcdef1234567890xxxx", "rpm_limit": 20, "max_budget": 10.0 }'
既存のOpenAIクライアントコードをLiteLLM経由で動かす方法
1. PythonのOpenAIクライアントで接続する
LiteLLMはOpenAI互換APIを提供するため、openai ライブラリのコードは base_url と api_key の2箇所を変更するだけで動く。
from openai import OpenAI # LiteLLMプロキシ経由でOllamaを呼び出す client = OpenAI( base_url="http://localhost:4000", api_key="sk-v2-yamada-abcdef1234567890xxxx" # 発行したバーチャルキー ) response = client.chat.completions.create( model="llama3.3-70b", # config.yaml の model_name messages=[{"role": "user", "content": "Linuxのinodeとは何ですか?"}] ) print(response.choices[0].message.content)
2. curlで疎通確認する
# curlでLiteLLMプロキシ経由のリクエストを確認する $ curl -s http://localhost:4000/v1/chat/completions \ -H "Authorization: Bearer sk-v2-yamada-abcdef1234567890xxxx" \ -H "Content-Type: application/json" \ -d '{ "model": "mistral-7b", "messages": [{"role":"user","content":"Hello"}] }' | python3 -m json.tool | head -15
3. LangChainからLiteLLM経由で接続する
LangChainのOpenAIチャットクラスもbase_url と openai_api_key を指定するだけで接続できる。既存のRAGパイプラインや会話エージェントへの影響が最小限になる。
from langchain_openai import ChatOpenAI llm = ChatOpenAI( base_url="http://localhost:4000", openai_api_key="sk-v2-yamada-abcdef1234567890xxxx", model="llama3.3-70b", temperature=0.1 ) response = llm.invoke("Pythonのvenvの使い方を教えてください") print(response.content)
4. 環境変数で接続先を切り替える
チームで共有するコードベースでは、環境変数で接続先を管理するのが実用的だ。# .env ファイルで管理する(.gitignoreに追加すること) OPENAI_BASE_URL=http://localhost:4000 OPENAI_API_KEY=sk-v2-yamada-abcdef1234567890xxxx # Pythonコード側はそのまま import os from openai import OpenAI client = OpenAI( base_url=os.environ["OPENAI_BASE_URL"], api_key=os.environ["OPENAI_API_KEY"] )
よくあるエラーとトラブルシューティング
LiteLLMが起動しない(ModuleNotFoundError: No module named 'litellm.proxy')pip install litellm だけで proxy extrasを付け忘れたケースが多い。pip install 'litellm[proxy]' で再インストールする。systemdの場合は ExecStart に仮想環境の絶対パス(/opt/litellm-env/bin/litellm)が正しく記載されているかも確認する。「model not found」エラーが返る
config.yaml の model_name とクライアントが指定する model 文字列が一致していないことが原因のほぼすべてだ。model_name: llama3.3-70b と定義しているなら、クライアントも "model": "llama3.3-70b" と指定する。curl http://localhost:4000/v1/models でLiteLLMが認識しているモデル名の一覧を確認できる。APIキーが無効(401 Unauthorized)
LITELLM_MASTER_KEY 環境変数が設定されている場合、認証なしのリクエストは拒否される。発行したバーチャルキーを Authorization: Bearer ヘッダーに正しくセットしているか確認する。curlの場合は -H "Authorization: Bearer sk-v2-..." の形式になる。キーの予算超過エラー(BudgetExceeded)
LiteLLMは内部的にトークン単価を計算して予算を消費する。ローカルLLMでは実際の課金は発生しないため、
max_budget を 1000.0 に増やすか、キー発行時に "max_budget": null を指定して無制限にする。OllamaのタイムアウトエラーがLiteLLMから返る(504 Gateway Timeout)
70Bモデルで長いプロンプトを処理すると推論に60秒を超えることがある。
config.yaml の litellm_settings.request_timeout を 600(10分)以上に設定する。Ollamaのsystemdユニットにタイムアウト設定がある場合はそちらも合わせて延長する。ポート4000に外部から接続できない
UFWが有効な環境では
sudo ufw allow 4000/tcp でポートを開ける。ただしポート4000を直接インターネットに開放することは避ける。社外から使いたい場合はNginxリバースプロキシ経由のHTTPS化が必須だ。社内LANのみであれば /etc/hosts での名前解決で内部通信に留める運用が現実的だ。SQLiteのロックエラー(database is locked)
複数のLiteLLMプロセスが同一のSQLiteファイルにアクセスしているか、ディスクIOが遅い環境で発生する。本番運用では
database_url: "postgresql://user:pass@localhost/litellm" に切り替えるのが安定する。最初からPostgreSQLで構築しておく方が後のトラブルを減らせる。
まとめ
OllamaにLiteLLMプロキシを導入することで、チームメンバーへのAPIキー発行・利用量管理・レート制限をOpenAI互換のまま実現できることを確認した。Ollamaは導入しやすい反面、マルチユーザー対応の管理機能が薄い。LiteLLMはその部分を補うゲートウェイとして機能する。本記事でカバーした設定の要点をまとめる:
| やりたいこと | コマンド・設定 |
|---|---|
| LiteLLMのインストール | pip install 'litellm[proxy]' |
| Ollamaをバックエンドに登録 | model: ollama/llama3.3:70b-instruct-q4_0 |
| バーチャルAPIキーの発行 | curl -X POST http://localhost:4000/key/generate |
| 月額予算の上限設定 | "max_budget": 5.0, "budget_duration": "30d" |
| リクエスト数の制限 | "rpm_limit": 10 |
| Pythonクライアントの接続先変更 | OpenAI(base_url="http://localhost:4000", api_key="sk-v2-...") |
| 発行済みキーの一覧確認 | curl http://localhost:4000/key/list |
| 発行済みキーの即時失効 | curl -X POST http://localhost:4000/key/delete |
ローカルLLMのチームAPI管理を2日間で体験する
LiteLLMプロキシの設定からAPIキー管理・Pythonクライアント連携まで、実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数(最大8名)ZOOMハンズオン形式で実施しています。
・Ubuntu ServerでローカルLLMを構築する方法|Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段|機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法|Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 前のページへ:Ollamaの量子化モデルを選ぶ方法|VRAM容量に合わせたq4_0・q8_0・q4_K_Mの最適設定ガイド
- この記事の属するカテゴリ:ローカルLLMへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます