ローカルLLMをAPIとして活用する方法

ノートパソコンでも、本番環境に展開しているのと同じOpenAI形式のエンドポイントの背後で、70Bパラメータモデルを運用できます。ベースURLを1つ入れ替えるだけで、コードは引き続き機能します。そのたった一つの変更により、オフライン開発、トークンごとのコストゼロ、規制されたデータのためのプライベートパスが実現します。これがHacker Newsが「Local AI needs to be the norm（ローカルAIが標準になるべきだ）」という記事を一日で633ポイントから1,760ポイントに押し上げた理由です。以下の記事では、ランタイムの選び方、エンドポイントの公開方法、クライアントからそれらを指し示す方法、そしてホスト型モデルに変更を反映させる前にApidogを使ってフロー全体をテストする方法を説明します。

TL;DR (要するに)

Ollama、vLLM、またはllama.cppを使えば、ノートパソコンでローカルLLM APIを実行でき、そのいずれもOpenAI互換のRESTエンドポイントを公開しています。既存のOpenAIクライアントでbase_urlをhttp://localhost:11434/v1に変更するだけで、コードを書き換えることなくLlama 3.3、DeepSeek V4、またはQwen 3.6に対して同じコードが実行されます。Apidogからフロー全体を駆動することで、ローカル環境とホスト環境の両方でシナリオテストを同一に保つことができます。

はじめに

ローカルLLM APIスタックは、18ヶ月で研究用のおもちゃから日常的なドライバーへと進化しました。AppleはM3 Maxに128GBのユニファイドメモリを搭載しました。Ollamaは週に100万ダウンロードを記録しました。vLLMはGitHubのスター数が30,000を超えました。しかし、最大の変化は社会的なものでした。主要なランタイムはすべて、OpenAIの/v1/chat/completions形式を話すようになりました。2つのクライアントパスを維持する必要はもうありません。1つの環境変数に基づいて、同じSDK呼び出しがlocalhostまたはapi.openai.comに到達します。

これはAPI開発者にとって重要です。なぜなら、既存のツールが引き続き機能するからです。Apidogのリクエストテンプレートはhttps://api.openai.com/v1/chat/completionsを指しています。ベースURL変数を切り替えて送信ボタンを押すだけで、自身のGPUで実行されているモデルから同じJSONが返ってきます。新しいスキーマも、新しい認証フローも必要ありません。すでに機能ごとのAPI費用を追跡している場合、ローカルモデルとホスト型モデルをA/Bテストし、コストが下がり、レイテンシがわずかに上昇するのを確認できます。

このガイドでは、ランタイムの選択、サーバーのセットアップ、クライアントの接続、シナリオテスト、量子化のトレードオフ、および現在の4つのモデルのコスト対レイテンシの表について説明します。コードサンプルは、macOS 15.4およびUbuntu 24.04上のOllama 0.6およびvLLM 0.7でテストされています。より広範なオプションについては、ベストローカルLLM 2026をご覧ください。すべての主張に関する外部リンクは下部にあります。

ボタン

API開発者にとってローカルLLMが理にかなっている理由

あなたはLLMを呼び出すコードを出荷します。また、飛行機内、Wi-Fiの悪い会議、*.openai.comへの外部アクセスをブロックする顧客ネットワーク内でそのコードをデバッグすることもあります。ローカルLLM APIは、ネットワークへの依存なしに本番環境をミラーリングする開発環境を提供します。

プライバシーの側面が最も重要視されます。HIPAA、GDPR、EU AI法はすべて、プロンプトに患者の記録、契約、生体認証情報が含まれた時点でそれらをユーザーデータとして扱います。そのペイロードをホスト型エンドポイントに送信すると、文書化、監査、更新が必要なデータ処理者としての関係が発生します。ハードウェアから決して離れないモデルは、その事務手続きを完全に回避します。欧州データ保護会議の2024年AI処理に関するガイダンスは、デバイス上での推論が第44条に基づくほとんどの越境データ転送義務を排除すると指摘しています。

コストは逆の方向に積み重なります。GPT-5.5 Instantを通じて1日あたり5000万プロンプトトークンを処理するチームは、100万トークンあたり5ドルの費用で1日あたり約250ドルを支払います。4,500ドルのM3 Maxスタジオで同じ量の処理を行う場合、電気代を考慮しなければ、18日間のフル稼働で償却がゼロになります。これらの数値の内訳はGPT-5.5 Instantの利用方法で読むことができ、自身のワークロードに同じ計算を適用できます。

3つ目の理由は決定論です。ホストされているモデルは、知らないうちに重みを変更します。OpenAIのモデル非推奨ページには、過去12ヶ月間に11のモデルのスナップショット廃止が記載されています。ローカルモデルはディスク上のファイルです。今日から3年後まで同じロジットを生成します。回帰テストスイートがLLMの出力に依存している場合、その安定性は重要です。OpenAI互換のエンドポイントは、その安定性のための統合コストを支払う必要がなくなったため、状況を一変させました。すでに使用しているSDKが機能します。

OpenAI互換エンドポイントを搭載した3つのランタイム

2026年には、4つのランタイムがローカルLLM API分野を支配しています。そのうち3つは、最初からOpenAI互換のRESTサーバーを提供しています。4つ目のllama.cppは、llama-serverバイナリの一部として提供しています。人気ではなく、ワークロードで選択してください。

Ollama

Ollamaは最も簡単に始められます。1つのバイナリ、1つのCLI、ポート11434上の1つのHTTPサーバーで動作します。これは、単一マシンで単一モデルを実行する開発者を対象としており、モデルのダウンロード、GGUF量子化、プロンプトのテンプレート化を処理します。

## macOSにインストール
brew install ollama
ollama serve &
ollama pull llama3.3:70b-instruct-q4_K_M
ollama run llama3.3:70b-instruct-q4_K_M

ollama serveが起動すると、OpenAI互換のエンドポイントはhttp://localhost:11434/v1に存在します。チャット、埋め込み、ストリーミングをサポートします。70B Q4_K_Mモデルを搭載したM3 Maxでのスループットの上限は、約12トークン/秒です。より小さなモデルでは、80～120トークン/秒に達します。Ollamaは、シングルユーザー開発、デモ、CIランナーに最適な選択肢です。

vLLM

vLLMは本番環境向けのオプションです。PagedAttentionと連続バッチ処理を利用して、単純なランナーよりも2～4倍高いスループットを実現します。デフォルトではポート8000でサービスを提供し、/v1でOpenAI互換APIを公開します。アーキテクチャの詳細については、以下のKwon et al. SOSP 2023の参照にあるvLLM論文を参照してください。

pip install vllm
vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --port 8000 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 8192

単一のH100上で、vLLMは並行リクエストに対してLlama 3.3 70Bを約2,400トークン/秒で処理します。CUDA GPUまたは最新のAMD ROCmカードが必要で、Apple Siliconでは動作しないため、ノートパソコンには不向きですが、共有開発クラスタには適しています。

llama.cpp

llama.cppはGGUFエコシステムを開始したC++ランタイムです。Raspberry Pi 5からデュアルRTX-5090のリグまで、あらゆる場所で動作します。そのllama-serverバイナリは、/v1/chat/completionsでOpenAI形式を話します。

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp && make -j LLAMA_METAL=1
./llama-server -m models/llama-3.3-70b-q4_k_m.gguf \
  --port 8080 --host 0.0.0.0 -c 8192 -ngl 99

-ngl 99フラグは、すべてのレイヤーをGPUにオフロードします。llama.cppは、量子化、バッチ処理、メモリマッピングに対して最大の制御を提供します。16GBのVRAMにモデルを詰め込む必要がある場合や、特殊なハードウェアをテストする場合に最適な選択肢です。

LM StudioとJanはllama.cppをGUIでラップし、設定可能なポートでOpenAIエンドポイントも公開しています。これらは、ターミナルに触れることなくプロンプトをテストする必要がある、チーム内の非技術系ユーザーにとって役立ちます。

エンドポイントが機能するかどうかの簡単なPythonチェック:

from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
resp = client.chat.completions.create(
    model="llama3.3:70b-instruct-q4_K_M",
    messages=[{"role": "user", "content": "Reply with the word OK only."}],
)
print(resp.choices[0].message.content)

OKが表示された場合、ランタイム、ポート、SDKの契約がすべて一致しています。エンドポイントをツールに接続する準備ができています。

ApidogでローカルLLMをテストする

ローカルLLM APIは、テストスイートが本番環境をヒットするのと同じ方法でそれをヒットできる場合にのみ役立ちます。Apidogは、リクエストテンプレート上の環境変数でこれを処理し、1つのプロジェクトで両方のターゲットをカバーできることを意味します。

フローには5つのステップがあります。

Apidogプロジェクトを開き、Localという新しい環境を作成します。BASE_URLという変数をhttp://localhost:11434/v1の値で追加します。API_KEYをollamaの値で追加します。保存します。
既存のOpenAI環境を複製し、Productionに名前を変更し、BASE_URLをhttps://api.openai.com/v1、API_KEYをホストされたキーのままにします。
チャットエンドポイントを呼び出す任意のリクエストで、ハードコードされたホストを{{BASE_URL}}に、認証ヘッダーをBearer {{API_KEY}}に置き換えます。リクエストURLは{{BASE_URL}}/chat/completionsになります。
リクエストを発行し、choices[0].message.role == "assistant"をアサートし、choices[0].message.contentが空でないことをアサートし、usage.total_tokens > 0をアサートするシナリオテストを作成します。シナリオを保存します。
Localに対してシナリオを実行します。環境ドロップダウンをProductionに切り替えます。再度実行します。両方でアサーションがパスするはずです。

同じシナリオは、ランタイムアップグレードのスモークテストとしても機能します。新しいタグでollama pullを実行した後、Localシナリオを再実行します。レスポンスの形式がずれている場合、アプリケーションコードが新しい重みに触れる前にそれを検知できます。このパターンは、複数ステップAPIを呼び出すAIエージェントのテストにも拡張できます。

プログラムによる使用の場合、OpenAI Python SDKは1つのキーワード引数でターゲットを切り替えます。

import os
from openai import OpenAI

def get_client():
    if os.getenv("ENV") == "local":
        return OpenAI(
            base_url="http://localhost:11434/v1",
            api_key="ollama",
        )
    return OpenAI(api_key=os.environ["OPENAI_API_KEY"])

client = get_client()
response = client.chat.completions.create(
    model=os.getenv("MODEL", "llama3.3:70b-instruct-q4_K_M"),
    messages=[
        {"role": "system", "content": "You are a JSON-only assistant."},
        {"role": "user", "content": "Return {\"status\": \"ok\"}."},
    ],
    response_format={"type": "json_object"},
)
print(response.choices[0].message.content)

JavaScriptの形式も同様です:

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: process.env.ENV === "local"
    ? "http://localhost:11434/v1"
    : "https://api.openai.com/v1",
  apiKey: process.env.ENV === "local" ? "ollama" : process.env.OPENAI_API_KEY,
});

const resp = await client.chat.completions.create({
  model: process.env.MODEL || "llama3.3:70b-instruct-q4_K_M",
  messages: [{ role: "user", content: "Say hi." }],
});
console.log(resp.choices[0].message.content);

プロジェクトをapidog-cliコレクションとしてエクスポートし、GitHub Actionsでapidog runを呼び出すことで、ApidogのシナリオランナーをCIに組み込むことができます。アサーションの失敗時にはランナーがゼロ以外の終了コードを返し、ローカルまたはホストされた契約がずれた瞬間にビルドを失敗させます。QAエンジニアは、既存のAPIテストパイプラインに同じフローを組み込むことができます。

高度なテクニックとプロのヒント

量子化は、70Bモデルがノートパソコンに収まるかどうかを決定するレバーです。GGUF形式は、パラメータごとに8、6、5、4、3、または2ビットで重みを保存します。Q4_K_Mがデフォルトであるのには理由があります。FP16と比較してMMLUベンチマークで0.6パーセントポイントを失いますが、70Bモデルを140GBから40GBに縮小します。Q8はFP16から0.1ポイント以内の精度を保ちますが、ディスクとRAMのフットプリントは2倍になります。Q2_Kはスペースを節約しますが、長いコンテキストを持つタスクではパープレキシティの低下が目立ちます。チャットにはQ4_K_M、コード生成にはQ8、RAMに余裕があり安全マージンが必要な場合はQ5_K_Mを選択してください。

llama.cppの-nglフラグまたはOllamaのnum_gpuオプションによるGPUオフロードは、GPU上に配置されるトランスフォーマーレイヤーの数を制御します。VRAMが許す限り高く設定してください。CPUにフォールバックする各レイヤーは、スループットを約30%低下させます。24GBのカードでは、70B Q4モデルは80レイヤーのうち40レイヤーを搭載できます。48GBでは、スタック全体を搭載できます。

メモリマッピング（mmap）は、llama.cppとOllamaではデフォルトでオンになっています。これにより、OSは起動時にモデル全体を割り当てるのではなく、必要に応じて重みをページインできます。厳密なメモリ制限のあるコンテナで実行している場合を除き、オンのままにしておいてください。mmapをオフにすると、最初のトークンのレイテンシは約200ミリ秒減少しますが、RAM使用量は2倍になります。

バッチ処理はvLLMの超能力です。32の同時リクエストを送信すると、vLLMはそれらを単一のGPUパスにグループ化します。スループットはGPUの計算能力の上限にほぼ線形にスケーリングします。共有CPUメモリを持つノートパソコンには--max-num-seqs 64を、H100クラスのハードウェアには--max-num-seqs 256を設定してください。

ストリーミング応答は、体感レイテンシを半分に削減します。OpenAI SDKでstream=Trueを設定すると、サーバーはトークンが生成されるたびにフラッシュします。完全な完了を待つ代わりに、最初のバイトが200〜500ミリ秒で届きます。このガイドのすべてのランタイムがこれをサポートしています。

OllamaのModelfileを使用すると、システムプロンプト、温度、ストップシーケンスを名前付きモデルに組み込むことができ、アプリケーションコードをクリーンに保てます。一度ollama create my-assistant -f Modelfileを実行すると、クライアントは毎回のリクエストでシステムプロンプトを繰り返す代わりにmy-assistantを指すようになります。

よくある間違い

本番コードにhttp://localhost:11434をハードコーディングすること。環境変数を使用してください。
ローカルモデルがmax_tokensを強制しないことを忘れること。4,096トークンの不要な出力を喜んで生成します。ストップシーケンスを設定してください。
Ollamaと別のランタイムを同じポートで実行すること。どちらもデフォルトではクリーンなポートを使用しますが、カスタムポートは静かに衝突します。
Authorizationヘッダーをスキップすること。Ollamaは無視しますが、--api-keyを使用したvLLMは、認証されていないリクエストを401で拒否します。
Q4モデルを読み込んで、数学でGPT-5.5品質を期待すること。量子化は推論能力を最も早く低下させます。

ローカル vs ホスト型: コストとレイテンシの計算

以下の数値は、ローカル用として128GBユニファイドメモリを搭載したM3 Maxを、ホスト型エンドポイント用として現在の公開価格を想定しています。最初のトークンまでの時間（TTFT）は、コールドスタート、バッチ処理なし、1,024トークンのプロンプトで測定されています。

モデル	ローカルTTFT	ローカルスループット	ホスト型同等モデル	ホスト型価格	ホスト型TTFT
Llama 3.3 70B Q4_K_M	1.2 秒	12 tok/秒	GPT-5.5 Instant	1Mあたり$5 / $30	200 ミリ秒
DeepSeek V4 67B Q4_K_M	1.4 秒	10 tok/秒	DeepSeek-Chat hosted	1Mあたり$0.55 / $2.20	280 ミリ秒
Qwen 3.6 32B Q5_K_M	0.7 秒	28 tok/秒	Qwen-Max hosted	1Mあたり$1.60 / $6.40	240 ミリ秒
Gemma 4 27B Q4_K_M	0.5 秒	35 tok/秒	Gemini 3 Flash	1Mあたり$0.35 / $1.05	180 ミリ秒

レイテンシでは、常にホスト型が優位です。ローカルは、1日あたり約1,000万トークンを超えるあたりからコスト面で優位に立ち、最初のリクエストからプライバシー面で優位になります。開発用としては、ほぼ常にローカルが望ましいでしょう。ユーザー向けのプロダクションでは、データ分類で禁止されていない限り、ほぼ常にホスト型が望ましいでしょう。

実用的なパターン: 内部開発ループ中はローカルで実行し、ステージングではホスト型に切り替え、CIでは両方のターゲットをグリーンに保ちます。上記のセクションのApidogシナリオテストは、単一の環境切り替えでそのパターンをサポートします。個々のモデルに関する詳細なベンチマークについては、DeepSeek V4をローカルで実行する方法と、元のDeepSeek V4使用ガイドを参照してください。

実世界のユースケース

シンガポールのフィンテックコンプライアンスチームは、エンジニアのノートパソコンでOllamaを使用して不審な活動報告書を作成しています。プロンプトには、MASの規則により国外に出すことができない口座番号と取引パターンが含まれています。彼らが本番で使用するホスト型エンドポイントは、同じプロンプトの編集済みバージョンを受け取ります。Apidogシナリオは、リダクターがlocalhostを離れる前にすべてのリクエストで実行されることをアサートします。

ストックホルムのゲームスタジオでは、ローカルのQwen 3.6インスタンスを使用して、デザイン研修生にプロンプトエンジニアリングを教えています。無料でオフライン、そして次期ゲームの伝承が第三者に漏洩する心配もありません。同じプロジェクトは、1つの環境変数変更で本番環境のGemini 3 Flashに対して出荷されます。彼らは本番環境の接続にGemini 3 Flash APIガイドを再利用しています。

あるヘルスケアスタートアップは、顧客の病院ネットワーク内でリースされたA100上でvLLMを実行しています。エンドポイントは公開DNSに表示されません。彼らの統合テストは、同じVLAN内のJenkinsエージェントから、ローカルで使用しているのと同じOpenAI SDKに対して実行されます。同じコード、3つのデプロイターゲット、1つのシナリオスイート。

結論

ローカルLLM APIスタックは急速に成熟しました。クライアント、テスト、またはCIを書き換えることなく、プロンプトをホスト型エンドポイントから移行できます。それを実現する5つのステップ:

ノートパソコンにはOllama、共有開発クラスタにはvLLM、メモリ予算が厳しい場合にはllama.cppを選択してください。
OpenAI互換エンドポイントを公開し、ワンラインのcurlで検証します。
base_urlとapi_keyを環境変数に移動し、同じコードがローカルとホスト型の両方にヒットするようにします。
Apidogで、両方の環境に対して同じように実行されるシナリオテストを構築します。
コスト対レイテンシの表を見て、ワークロードごとに適切なターゲットを選択します。

「Local AI needs to be the norm（ローカルAIが標準になるべきだ）」というHNのシグナルが1,700ポイントを超えたのは、この成熟の結果です。APIの表面が安定すると、すべての開発ツールがそれに順応しました。Apidogをダウンロードし、1つの環境をhttp://localhost:11434/v1に設定して、ループがいかに早く閉じられるかを確認してください。まだモデルを選んでいない場合は、ベストローカルLLM 2026から始めてください。これらのエンドポイント上にエージェントフローをテストするためのより深い洞察が必要な場合は、AIエージェントAPIのテスト方法を読んでください。

ボタン