- OllamaはOpenAI Chat Completions APIとの初期互換性を組み込み、OpenAI向けのツールやアプリケーションをローカルモデルにそのまま接続できるようになった
- インストール後、
llama2やmistralのようなモデルをダウンロードし、OpenAIのリクエスト形式を維持したままホストだけを変更すれば呼び出せる
- OpenAI Python・JavaScriptライブラリでは、
base_url/baseURLを指定し、必須だが使用されないapi_key値を入れることで動作する
- Vercel AI SDKのストリーミングチャットアプリと、Microsoft AutogenのマルチエージェントフレームワークをOllamaに接続する例が提供されている
- 現在のサポートは初期の実験的サポート段階であり、Embeddings API、関数呼び出し、ビジョン対応、Logprobsの改善は今後の検討対象
OpenAI API形式でOllamaを呼び出す
ollama pull llama2
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "llama2",
"messages": [
{
"role": "system",
"content": "You are a helpful assistant."
},
{
"role": "user",
"content": "Hello!"
}
]
}'
- OpenAI Pythonライブラリでは、
base_urlをOllamaのローカルエンドポイントに指定する
api_key='ollama'は必須だが使用されない
from openai import OpenAI
client = OpenAI(
base_url = 'http://localhost:11434/v1',
api_key='ollama',
)
response = client.chat.completions.create(
model="llama2",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Who won the world series in 2020?"},
{"role": "assistant", "content": "The LA Dodgers won in 2020."},
{"role": "user", "content": "Where was it played?"}
]
)
print(response.choices[0].message.content)
import OpenAI from 'openai'
const openai = new OpenAI({
baseURL: 'http://localhost:11434/v1',
apiKey: 'ollama',
})
const completion = await openai.chat.completions.create({
model: 'llama2',
messages: [{ role: 'user', content: 'Why is the sky blue?' }],
})
console.log(completion.choices[0].message.content)
統合例と今後の計画
- Vercel AI SDKは対話型ストリーミングアプリケーションを作るためのオープンソースライブラリで、Next.jsのOpenAIサンプルをOllama向けに置き換えて使える
npx create-next-app --example https://github.com/vercel/ai/tree/main/examples/next-openai example
cd example
app/api/chat/route.tsでOpenAIクライアント設定をOllamaのローカルエンドポイントに変更する
const openai = new OpenAI({
baseURL: 'http://localhost:11434/v1',
apiKey: 'ollama',
});
- チャット補完リクエストでは、
llama2モデルとstream: trueを使用する
const response = await openai.chat.completions.create({
model: 'llama2',
stream: true,
messages,
});
npm run dev
ollama pull codellama
pip install pyautogen
from autogen import AssistantAgent, UserProxyAgent
config_list = [
{
"model": "codellama",
"base_url": "http://localhost:11434/v1";,
"api_key": "ollama",
}
]
assistant = AssistantAgent("assistant", llm_config={"config_list": config_list})
user_proxy = UserProxyAgent("user_proxy", code_execution_config={"work_dir": "coding", "use_docker": False})
user_proxy.initiate_chat(assistant, message="Plot a chart of NVDA and TESLA stock price change YTD.")
- 例は
python example.pyで実行し、アシスタントにチャートを描くコードを書かせる
python example.py
- OpenAI APIサポートは初期の実験的サポート段階にある
- 今後の改善検討項目はEmbeddings API、関数呼び出し、ビジョン対応、Logprobs
- GitHub Issueを受け付けており、詳細はOpenAI互換性ドキュメントで確認できる
1件のコメント
Hacker News のコメント
ここ数か月で ローカル LLM ホスティングの使い勝手が良くなるスピードには驚かされる。ほんの数時間前まで https://github.com/Mozilla-Ocho/llamafile がどれほど簡単かを話していたのに[1]、今では何を使うべきか迷うほどになっている
[1] 文字どおり数時間前: https://euri.ca/blog/2024-llm-self-hosting-is-easy-now/
ollama serveを実行し、Docker でollama web-uiを立ち上げ、Web UI から OllamaHub のコーディング支援モデルを追加して、ドキュメントをアップロードすればよいコードを書かなくても、ドキュメントをコンテキストとして回答するセルフホスト LLM が手に入る。こちらでは 64GB RAM の Mac Studio で deepseek coder 33b が十分高速に動き、社内のコーディング文書をもとにかなり良い提案をしてくれる
1つのモデルファイル内で複数のモデルを混ぜることもでき、これは最近試している機能だ。必ずしも Ollama のモデルライブラリに依存する必要はなく、自作モデルも使える。新しいモデルのサポートは
llama.cppバインディング経由で入ってくるllamafileを起動しやすい点はよかったが、機能が十分なチャットインターフェースが欲しかったので、その上に https://recurse.chat/ を作ったまだ一部の作業には GPT-4 が必要だが、日常的な利用では ChatGPT 利用のかなりの部分を置き換えられており、特に ChatGPT のチャット履歴をすべて取り込めるのが良い。人々がローカル AI で何をしたいのかも気になっている
llamacpp -m -pだけを使ってきて、MacBook で Mixtral 8x7b + CodeLlama 70b を日常ツールのように問題なく使っている。Llama.cpp の代替には決定的な機能があるのか気になるし、新しい面白い流れを見逃したくない経営学の教授だが、学生に Ollama と web-ui を試してもらうため、Google Cloud 上で動かす手順書を作った[1]。スポットインスタンスを使えば1時間あたり18セントで動かせる
[1] https://docs.google.com/document/d/1OpZl4P3d0WKH9XtErUZib5_2...
git-bashで SSH キーを使わせることを強く勧める。すでに説明している内容より技術的に難しいわけでもないOpenAI API 互換性がコミュニティ標準になりつつあることを内心気持ち悪く感じている人を何人か知っている。
data.choices.text.responseのようなぎこちなさや、スキーマの不必要に防御的なネストを除けば、特に不満はないAPI が標準になっていく過程でどんな痛点があるのか、検討に値する代替標準を試した人がいるのか気になる
コミュニティ標準として定着するのは構わないが、コミュニティが言う OpenAI API 互換が何を意味するのかについて、非常に堅牢な仕様が必要だ。特に OpenAI が今朝新機能を出したとしても、その標準は安定して維持されるべきだ
欲しいのは、エラー条件まで含む堅牢な API 仕様、新しい実装が仕様に従っているか確認できるテストスイート、そして名称だ。たとえば、あるソフトウェアが
OpenAI-API-Spec v3と互換だと言うとき、その意味を知りたい。今のように「OpenAI API 互換」とだけ言われても情報が足りない。API のどの部分なのか、どの時点の API に合わせているのか分からないOllama にクールで新しくて別種の機能を追加しても、OpenAI API に対応物がなければ、人々がそれを使えるのか分からない
llama.cppの関数を直接呼び出す Web サーバーを作るのはとても簡単なので、大きな問題ではない。もっと制御が必要なら少し作業を足せばよく、必ずしもこうしたプラグアンドプレイのツールが必要なわけではない職場で Copilot より良いバージョンを作っていて、ユーザーが自分の LLM を持ち込む方式もサポートしている。最近は OpenAI 互換バックエンドを追加しており、OpenAI 互換 API エンドポイントと、どのモデルのように扱うかを教えてくれれば、そのモデルの意味論に合わせてプロンプト、停止シーケンス、最大トークン数などをフォーマットできる
ローカル開発環境でテストするために、まさにこういうものが必要だった。Ollama がこれをサポートすれば、こちらが対応しなければならない多数の LLM に対するテストがずっと楽になる。OpenLLM など複数のツールも同じ API を実装しているのを見ると、みな OpenAI API 互換性に収束しているようだ
今 AIスタートアップを作っている感覚が本当に良い
最初はトークン制限に苦労したが解決され、一貫したJSON出力の問題も解決され、大手サードパーティモデルの速度制限と性能の問題も解決され、小〜中程度の複雑さのタスク向けにオープンソースモデルをセルフホストしてコストを下げたいという課題も解決された
主要なLLMの進歩が出るたびに、製品が自動的により安く、より安定し、よりスケーラブルになっていく感じがする。もちろん防御力を作り、「AIではない」あらゆる部分で差別化することに集中する必要がある
OpenAI互換と言うと 関数呼び出しやツール呼び出し まで期待してしまうので、少し誤解を招く可能性があると思う
ロールと内容の構造があるのは良いが、それはもともと実装がかなり単純だった。エージェントになると実際のアクション実行が必要になる。自分が始めたエージェントホスティングシステムにはスクリプトエンジンを入れていて、だからセキュリティと権限を固めたうえで、エージェントに単にコードを実行させるべきではないかと思った。実際そうやって始めた
なので関数/ツール呼び出しが本当に必要なのかは確信がない。ただ、多くの人がツール呼び出しを標準化しているなら、任意のスクリプト実行があっても自分のフレームワークに入れる必要があるかもしれない
関数呼び出し/ツール選択 はアプリケーションレベルで処理され、現在標準形式はない。広く使われているものも、実質的には非効率なカスタムシステムプロンプトに近い: https://github.com/langchain-ai/langchain/blob/master/libs/l...
いずれにせよ、動かないサポートを出さないほうがよい場合もある
参考までに、OllamaのLinuxインストールスクリプトは最近のツールでよくある「標準」的な方式で動作する:
curl https://ollama.ai/install.sh | shただし最後に確認したとき、このスクリプトは
sudoで root権限 を要求していた。ツールを使いたいなら、スクリプトをダウンロードして確認するか、必要に応じて修正するとよいchmod +x ollama-linux-amd64）、実行するだけでもうまくいった。root権限は不要だった[0] https://github.com/ollama/ollama/blob/main/docs/linux.md#man...
[1] https://ollama.ai/download/ollama-linux-amd64
ollamaバイナリは/usr/binに入るが、必ずそうである必要はないものの便利だ。それ以外に何がrootアクセスを必要とするのかは確認していない互換レイヤーはライブラリの中に作ることもできる。たとえばLangChainの
llm()は複数のLLMバックエンドで動作できる。どちらを好むのか気になるもう一つは、世の中がLangChainのようなひどいライブラリで標準化してしまうと、均一でないバックエンドのメンテナンスコストのせいで後発が死に、長く縛られることになる点だ。だから今は、均一なAPIのほうが利便性の面で良い選択に見える
完璧でなくても標準APIがあるのは良い。同時に、BackblazeのB2のように全体のポテンシャルを使える第2のAPIがあってもよい。1つですべてのモデルに合わせる方法はなく、モデルに異なる能力があるなら、両方の選択肢を提供するのがよいと思う
Pythonでオープンソースモデル（HF、VLLM経由）と商用モデル（OpenAI、Google、Anthropic、Together）を簡単に差し替えられるプロジェクトを作っている: https://github.com/datadreamer-dev/DataDreamer
HTTP APIなしで Pythonから直接 使いたいなら、もう少し簡単な方法だ
Ollamaの使いどころ が何なのか気になる。なぜ
llama.cppを直接使ってはいけないのか？llama.cppを直接使うのと比べて、正確にどんな利点があるのか気になる