- Ollama integriert eine erste Kompatibilität zur OpenAI-Chat Completions API, sodass sich Tools und Anwendungen für OpenAI unverändert an lokale Modelle anbinden lassen
- Nach der Installation können Modelle wie
llama2 oder mistral heruntergeladen werden; Aufrufe sind möglich, wenn das OpenAI-Anfrageformat beibehalten und nur der Host geändert wird
- Die OpenAI-Bibliotheken für Python und JavaScript funktionieren mit
base_url/baseURL, die auf http://localhost:11434/v1 gesetzt werden, sowie einem erforderlichen, aber ungenutzten api_key-Wert
- Es werden Beispiele bereitgestellt, um Streaming-Chat-Apps mit dem Vercel AI SDK und das Multi-Agenten-Framework Autogen von Microsoft an Ollama anzubinden
- Der aktuelle Support befindet sich in einer frühen experimentellen Phase; Embeddings API, Function Calling, Vision-Support und Verbesserungen bei Logprobs sind für die Zukunft vorgesehen
Ollama im OpenAI-API-Format aufrufen
- Ollama bietet einen mit der OpenAI-Chat Completions API kompatiblen Endpunkt, sodass lokale Modelle in bestehenden OpenAI-basierten Tools genutzt werden können
- Zum Start Ollama installieren und ein Modell wie Llama 2 oder Mistral herunterladen
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!"
}
]
}'
- In der OpenAI-Python-Bibliothek wird
base_url auf den lokalen Ollama-Endpunkt gesetzt
api_key='ollama' ist erforderlich, wird aber nicht verwendet
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)
- In der OpenAI-JavaScript-Bibliothek wird
baseURL auf http://localhost:11434/v1 gesetzt
apiKey: 'ollama' ist ebenfalls erforderlich, wird aber nicht verwendet
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)
Beispielintegrationen und weitere Pläne
- Das Vercel AI SDK ist eine Open-Source-Bibliothek zum Erstellen interaktiver Streaming-Anwendungen; das Next.js-OpenAI-Beispiel lässt sich auf Ollama umstellen
npx create-next-app --example https://github.com/vercel/ai/tree/main/examples/next-openai example
cd example
- In
app/api/chat/route.ts wird die OpenAI-Client-Konfiguration auf den lokalen Ollama-Endpunkt umgestellt
const openai = new OpenAI({
baseURL: 'http://localhost:11434/v1',
apiKey: 'ollama',
});
- Die Chat-Completions-Anfrage verwendet das Modell
llama2 und stream: true
const response = await openai.chat.completions.create({
model: 'llama2',
stream: true,
messages,
});
npm run dev
- Autogen ist Microsofts Open-Source-Framework für Multi-Agenten-Anwendungen; im Beispiel wird Code Llama verwendet
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.")
- Das Beispiel wird mit
python example.py ausgeführt und lässt den Assistenten Code zum Zeichnen des Diagramms schreiben
python example.py
- Die OpenAI-API-Unterstützung befindet sich in einer frühen experimentellen Phase
- Für künftige Verbesserungen werden Embeddings API, Function Calling, Vision-Support und Logprobs geprüft
- GitHub-Issues können eingereicht werden; weitere Informationen stehen in der OpenAI-Kompatibilitäts-Dokumentation
1 Kommentare
Meinungen auf Hacker News
Es ist erstaunlich, wie schnell sich die Nutzbarkeit von lokalem LLM-Hosting in den letzten Monaten verbessert hat. Noch vor ein paar Stunden habe ich darüber geredet, wie einfach https://github.com/Mozilla-Ocho/llamafile ist[1], und jetzt frage ich mich schon, was man verwenden sollte
[1] Buchstäblich vor ein paar Stunden: https://euri.ca/blog/2024-llm-self-hosting-is-easy-now/
ollama serveaus, startetollama web-uiin Docker, fügt über das Web-UI ein Coding-Assistant-Modell aus OllamaHub hinzu und lädt die Dokumentation hochSo hat man ohne Code ein selbst gehostetes LLM, das Dokumente als Kontext nutzt, um Antworten zu geben. Bei uns ist deepseek coder 33b auf einem Mac Studio mit 64 GB RAM schnell genug und macht auf Basis unserer internen Coding-Dokumentation ziemlich brauchbare Vorschläge
Man kann auch mehrere Modelle in einer einzelnen Modelldatei mischen; das ist eine Funktion, mit der derzeit experimentiert wird. Man muss sich nicht zwingend auf Ollamas Modellbibliothek verlassen, sondern kann auch selbst erstellte Modelle verwenden. Unterstützung für neue Modelle kommt über
llama.cpp-Bindings hinzullamafilestarten ließ, aber mir fehlte eine ausreichend funktionsreiche Chat-Oberfläche, also habe ich darauf aufbauend https://recurse.chat/ gebautFür manche Aufgaben brauche ich zwar noch GPT-4, aber im Alltag hat es einen erheblichen Teil meiner ChatGPT-Nutzung ersetzt, und besonders gut finde ich, dass man den gesamten Chatverlauf von ChatGPT importieren kann. Ich bin auch neugierig, was Leute mit lokaler AI machen wollen
llamacpp -m -pverwendet und nutze Mixtral 8x7b + CodeLlama 70b auf dem MacBook problemlos als Alltagswerkzeug. Mich würde interessieren, ob die Alternativen zu Llama.cpp entscheidende Funktionen haben, und ich möchte keine spannende neue Entwicklung verpassenIch bin BWL-Professor und habe eine Anleitung erstellt, um meine Studierenden Ollama und web-ui auf Google Cloud ausprobieren zu lassen[1]. Mit Spot-Instanzen kann man das für 18 Cent pro Stunde betreiben
[1] https://docs.google.com/document/d/1OpZl4P3d0WKH9XtErUZib5_2...
git-bashSSH-Schlüssel zu verwenden. Das ist technisch auch nicht schwieriger als die Dinge, die bereits erklärt wurdenIch kenne einige Leute, denen es insgeheim unangenehm ist, dass OpenAI-API-Kompatibilität zum Community-Standard wird. Abgesehen von Merkwürdigkeiten wie
data.choices.text.responseoder der unnötig defensiven Verschachtelung des Schemas habe ich daran nicht wirklich etwas auszusetzenMich interessiert, welche Schmerzpunkte es gibt, wenn eine API zum Standard wird, und ob jemand alternative Standards ausprobiert hat, die man in Betracht ziehen sollte
Dass es sich als Community-Standard etabliert, ist in Ordnung, aber es sollte eine sehr solide Spezifikation dafür geben, was die Community mit OpenAI-API-kompatibel meint. Insbesondere sollte dieser Standard stabil bleiben, selbst wenn OpenAI heute Morgen eine neue Funktion veröffentlicht hat
Was ich möchte, ist eine robuste API-Spezifikation inklusive Fehlerbedingungen, eine Testsuite, mit der sich prüfen lässt, ob eine neue Implementierung der Spezifikation entspricht, und einen Namen. Wenn Software zum Beispiel mit
OpenAI-API-Spec v3kompatibel ist, möchte ich wissen, was das bedeutet. Einfach nur „OpenAI-API-kompatibel“ wie heute reicht als Information nicht aus. Man weiß nicht, welcher Teil der API gemeint ist oder auf welchen Stand der API sie sich beziehtWenn wir Ollama coole, neue und andere Funktionen hinzufügen, aber es kein Gegenstück in der OpenAI API gibt, weiß ich nicht, ob die Leute sie überhaupt nutzen können
llama.cpp-Funktionen direkt über Bindings in der gewünschten Sprache aufruft, ist sehr einfach, daher ist das nicht besonders wichtig. Wenn man mehr Kontrolle braucht, ist nur etwas zusätzliche Arbeit nötig, und man braucht nicht zwingend solche Plug-and-play-ToolsBei der Arbeit bauen wir eine bessere Version als Copilot und unterstützen auch einen Ansatz, bei dem Nutzer ihr eigenes LLM mitbringen. Vor Kurzem haben wir ein OpenAI-kompatibles Backend hinzugefügt: Man gibt einfach den OpenAI-kompatiblen API-Endpunkt und das Modell an, als das es behandelt werden soll, und dann können wir Prompts, Stop-Sequenzen, maximale Token usw. entsprechend der Semantik dieses Modells formatieren
Genau so etwas brauchten wir zum Testen in der lokalen Entwicklungsumgebung. Wenn Ollama das unterstützt, wird das Testen der vielen LLMs, die wir unterstützen müssen, erheblich einfacher. Wenn man sieht, dass auch verschiedene Tools wie OpenLLM dieselbe API implementieren, scheint sich alles auf OpenAI-API-Kompatibilität zuzubewegen
Es fühlt sich derzeit wirklich gut an, ein AI-Startup aufzubauen
Anfangs hatten wir mit Token-Limits zu kämpfen, aber das wurde gelöst; das Problem konsistenter JSON-Ausgaben wurde gelöst; die Rate-Limits und Performance-Probleme großer Drittanbieter-Modelle wurden gelöst; und auch der Wunsch, Open-Source-Modelle für kleine bis mittelkomplexe Aufgaben selbst zu hosten, um Kosten zu senken, wurde gelöst
Bei jedem größeren Fortschritt bei LLMs fühlt es sich so an, als würde das Produkt automatisch günstiger, zuverlässiger und besser skalierbar. Natürlich muss man Schutzmechanismen aufbauen und sich auf Differenzierung bei allem konzentrieren, was „nicht AI“ ist
Wenn man sagt, es sei mit OpenAI kompatibel, erwartet man auch Function Calling oder Tool Calling, daher kann das meiner Meinung nach etwas missverständlich sein
Dass es Rollen und eine Inhaltsstruktur gibt, ist gut, aber das war ursprünglich ziemlich einfach zu implementieren. Sobald man zu Agents übergeht, braucht man die Ausführung echter Aktionen. In das Agent-Hosting-System, das ich gestartet habe, habe ich eine Scripting-Engine eingebaut, und deshalb dachte ich, dass man nach dem Klären von Sicherheit und Berechtigungen den Agent vielleicht einfach Code ausführen lassen sollte. Tatsächlich habe ich so angefangen
Deshalb bin ich nicht sicher, ob Function/Tool Calling wirklich nötig ist. Wenn aber viele Leute Tool Calling standardisieren, muss ich es eventuell in mein Framework aufnehmen, selbst wenn es beliebige Script-Ausführung gibt
Function Calling/Tool-Auswahl wird auf Anwendungsebene behandelt und hat derzeit kein Standardformat. Auch die verbreiteten Varianten sind im Grunde eher ineffiziente, maßgeschneiderte System-Prompts: https://github.com/langchain-ai/langchain/blob/master/libs/l...
Jedenfalls kann es besser sein, keine Unterstützung anzubieten, die nicht funktioniert
Zur Info: Ollamas Linux-Installationsskript funktioniert auf die „Standard“-Art, wie sie bei heutigen Tools üblich ist:
curl https://ollama.ai/install.sh | shAllerdings verlangte dieses Skript beim letzten Mal, als ich nachgesehen habe, per
sudoRoot-Rechte. Wenn man das Tool verwenden möchte, sollte man das Skript herunterladen und prüfen oder es an die eigenen Bedürfnisse anpassenchmod +x ollama-linux-amd64) und auszuführen. Root-Rechte waren nicht nötig[0] https://github.com/ollama/ollama/blob/main/docs/linux.md#man...
[1] https://ollama.ai/download/ollama-linux-amd64
ollama-Binary landet in/usr/bin, was nicht zwingend nötig ist, aber praktisch. Ich habe nicht geprüft, was sonst noch Root-Zugriff erfordertEine Kompatibilitätsschicht könnte man auch in einer Bibliothek bauen. Zum Beispiel kann LangChains
llm()mit verschiedenen LLM-Backends arbeiten. Ich frage mich, welche Variante bevorzugt wirdEin weiteres Problem ist: Wenn sich die Welt auf schlechte Bibliotheken wie LangChain standardisiert, sterben Nachzügler wegen der Wartungskosten uneinheitlicher Backends, und man bleibt lange daran gebunden. Deshalb wirkt eine einheitliche API derzeit aus Bequemlichkeit wie die bessere Wahl
Eine Standard-API zu haben, ist gut, auch wenn sie nicht perfekt ist. Gleichzeitig ist es in Ordnung, eine zweite API wie Backblazes B2 zu haben, mit der sich das volle Potenzial ausschöpfen lässt. Es gibt keine Einheitslösung, die für alle Modelle passt, und wenn Modelle unterschiedliche Fähigkeiten haben, sollte man meiner Meinung nach beide Optionen anbieten
Ich baue ein Projekt, mit dem man in Python leicht zwischen Open-Source-Modellen (über HF, VLLM) und kommerziellen Modellen (OpenAI, Google, Anthropic, Together) wechseln kann: https://github.com/datadreamer-dev/DataDreamer
Wenn man es direkt in Python ohne HTTP API verwenden möchte, ist das ein etwas einfacherer Weg
Ich frage mich, wofür Ollama verwendet wird. Warum nicht einfach
llama.cppdirekt verwenden?llama.cpphat, das inzwischen auch einen eingebauten OpenAI-kompatiblen Server bietet