- Ollama intègre une compatibilité initiale avec l’API Chat Completions d’OpenAI, ce qui permet de connecter tels quels des outils et applications conçus pour OpenAI à des modèles locaux
- Après l’installation, il suffit de télécharger un modèle comme
llama2 ou mistral, puis de conserver le format de requête OpenAI en ne changeant que l’hôte pour pouvoir l’appeler
- Les bibliothèques OpenAI Python et JavaScript fonctionnent en définissant
base_url/baseURL et en fournissant une valeur api_key obligatoire mais non utilisée
- Des exemples montrent comment connecter à Ollama une application de chat en streaming avec le Vercel AI SDK et le framework multi-agents Autogen de Microsoft
- La prise en charge actuelle est au stade de support expérimental initial ; l’API Embeddings, l’appel de fonctions, la prise en charge de la vision et l’amélioration des Logprobs seront étudiés ultérieurement
Appeler Ollama au format de l’API OpenAI
- Ollama fournit un endpoint compatible avec l’API Chat Completions d’OpenAI, ce qui permet d’utiliser des modèles locaux dans des outils existants basés sur OpenAI
- Pour commencer, installez Ollama et téléchargez un modèle comme Llama 2 ou Mistral
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!"
}
]
}'
- Avec la bibliothèque OpenAI Python, définissez
base_url sur l’endpoint local d’Ollama
api_key='ollama' est obligatoire mais n’est pas utilisée
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)
- Avec la bibliothèque OpenAI JavaScript, définissez
baseURL sur http://localhost:11434/v1
apiKey: 'ollama' est également obligatoire mais n’est pas utilisée
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)
Exemples d’intégration et feuille de route
- Vercel AI SDK est une bibliothèque open source permettant de créer des applications conversationnelles en streaming, et l’exemple Next.js pour OpenAI peut être adapté pour utiliser Ollama
npx create-next-app --example https://github.com/vercel/ai/tree/main/examples/next-openai example
cd example
- Dans
app/api/chat/route.ts, remplacez la configuration du client OpenAI par l’endpoint local d’Ollama
const openai = new OpenAI({
baseURL: 'http://localhost:11434/v1',
apiKey: 'ollama',
});
- La requête de complétion de chat utilise le modèle
llama2 avec stream: true
const response = await openai.chat.completions.create({
model: 'llama2',
stream: true,
messages,
});
- Lancez l’application avec
npm run dev, puis ouvrez http://localhost:3000 dans le navigateur pour vérifier le résultat
npm run dev
- Autogen est un framework open source de Microsoft pour les applications multi-agents, et l’exemple utilise Code Llama
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.")
- L’exemple s’exécute avec
python example.py et demande à l’assistant d’écrire le code qui trace le graphique
python example.py
- La prise en charge de l’API OpenAI est au stade de support expérimental initial
- Les éléments envisagés pour de futures améliorations sont l’API Embeddings, l’appel de fonctions, la prise en charge de la vision et les Logprobs
- Les issues GitHub sont acceptées, et plus d’informations sont disponibles dans la documentation sur la compatibilité OpenAI
1 commentaires
Avis sur Hacker News
La vitesse à laquelle l’ergonomie de l’hébergement local de LLM s’est améliorée ces derniers mois est étonnante. Il y a encore quelques heures, je parlais de la simplicité de https://github.com/Mozilla-Ocho/llamafile[1], et maintenant je me demande quoi utiliser
[1] Littéralement il y a quelques heures : https://euri.ca/blog/2024-llm-self-hosting-is-easy-now/
ollama serve, de démarrerollama web-uidans Docker, d’ajouter via l’interface web un modèle d’assistance au code depuis OllamaHub, puis de téléverser sa documentationSans écrire de code, on obtient un LLM auto-hébergé qui répond en prenant les documents comme contexte. De notre côté, deepseek coder 33b est suffisamment rapide sur un Mac Studio avec 64 Go de RAM, et il donne d’assez bonnes suggestions à partir de notre documentation interne de code
On peut même combiner plusieurs modèles dans un seul fichier de modèle, une fonctionnalité sur laquelle je fais des essais en ce moment. Il n’est pas nécessaire de dépendre uniquement de la bibliothèque de modèles d’Ollama : on peut aussi utiliser ses propres modèles. La prise en charge de nouveaux modèles arrive via les bindings
llama.cppllamafile, mais l’absence d’une interface de chat suffisamment complète me gênait, alors j’ai construit https://recurse.chat/ par-dessusGPT-4 reste nécessaire pour certaines tâches, mais pour l’usage quotidien, cela a remplacé une bonne partie de mon utilisation de ChatGPT, et j’apprécie surtout de pouvoir importer tout l’historique des conversations ChatGPT. Je suis aussi curieux de savoir ce que les gens veulent faire avec l’IA locale
llamacpp -m -p, et j’utilise au quotidien Mixtral 8x7b + CodeLlama 70b sur mon MacBook comme des outils courants. Je me demande s’il existe des fonctionnalités décisives dans les alternatives à Llama.cpp, et je ne veux pas passer à côté d’une nouvelle tendance intéressanteJe suis professeur en école de commerce, et j’ai rédigé un guide pour faire essayer Ollama et web-ui à mes étudiants en les exécutant sur Google Cloud[1]. Avec des instances spot, ça tourne pour 18 cents de l’heure
[1] https://docs.google.com/document/d/1OpZl4P3d0WKH9XtErUZib5_2...
git-bash. Ce n’est pas plus difficile techniquement que ce qui est déjà indiquéJe connais plusieurs personnes qui sont discrètement mal à l’aise avec le fait que la compatibilité avec l’API OpenAI devienne un standard communautaire. À part des bizarreries comme
data.choices.text.responseou l’imbrication inutilement défensive du schéma, je n’ai pas vraiment de griefJe me demande quelles sont les douleurs dans le processus par lequel une API devient un standard, et si certains ont essayé des standards alternatifs envisageables
Que cela devienne un standard communautaire, très bien, mais il faut une spécification très solide de ce que la communauté entend par compatibilité avec l’API OpenAI. En particulier, même si OpenAI a sorti une nouvelle fonctionnalité ce matin, ce standard doit rester stable
Ce que je veux, c’est une spécification d’API robuste, y compris pour les conditions d’erreur, une suite de tests permettant de vérifier qu’une nouvelle implémentation respecte la spécification, et un nom. Par exemple, si un logiciel est compatible avec
OpenAI-API-Spec v3, je veux savoir ce que cela signifie. Dire simplement « compatible avec l’API OpenAI », comme aujourd’hui, ne donne pas assez d’informations. On ne sait pas de quelle partie de l’API il s’agit, ni à quel état de l’API cela correspondMême si nous ajoutons à Ollama des fonctionnalités nouvelles, intéressantes et différentes, je ne sais pas si les gens pourront les utiliser s’il n’existe pas d’équivalent dans l’API OpenAI
llama.cppavec les bindings du langage de son choix, donc ce n’est pas très important. Si l’on a besoin de davantage de contrôle, il suffit d’un peu plus de travail, et ce genre d’outil prêt à l’emploi n’est pas indispensableAu travail, nous construisons une version meilleure que Copilot, et nous prenons aussi en charge une approche où l’utilisateur peut apporter son propre LLM. Récemment, nous ajoutons un backend compatible OpenAI : il suffit de fournir l’endpoint d’API compatible OpenAI et d’indiquer comme quel modèle il doit être traité, puis nous pouvons formater les prompts, les séquences d’arrêt, le nombre maximal de tokens, etc., selon la sémantique de ce modèle
C’est exactement ce dont nous avions besoin pour tester dans un environnement de développement local. Si Ollama prend cela en charge, les tests sur les nombreux LLM que nous devons supporter deviennent beaucoup plus faciles. À voir OpenLLM et divers autres outils implémenter la même API, tout semble converger vers la compatibilité avec l’API OpenAI
Créer une startup IA en ce moment donne vraiment une bonne impression
Au début, on a galéré avec les limites de tokens, mais c’est résolu ; le problème de sortie JSON cohérente aussi ; les limites de débit et les problèmes de performance des grands modèles tiers aussi ; et le fait de vouloir réduire les coûts en auto-hébergeant des modèles open source pour des tâches petites à moyennement complexes aussi
À chaque avancée majeure des LLM, on a l’impression que le produit devient automatiquement moins cher, plus fiable et plus scalable. Bien sûr, il faut se concentrer sur la création de défensibilité et se différencier sur tout ce qui « n’est pas de l’IA »
Dire que c’est compatible avec OpenAI peut être un peu trompeur, car on s’attend alors aussi aux appels de fonctions ou d’outils
Avoir une structure avec rôles et contenu, c’est bien, mais à l’origine c’était assez simple à implémenter. Quand on passe aux agents, il faut exécuter de vraies actions. Dans le système d’hébergement d’agents que j’ai commencé, j’ai intégré un moteur de scripting ; je me suis donc demandé s’il ne fallait pas simplement permettre à l’agent d’exécuter du code, une fois la sécurité et les permissions cadrées. En fait, c’est comme ça que j’ai commencé
Je ne suis donc pas sûr que les appels de fonctions/outils soient indispensables. Mais si beaucoup de gens standardisent les appels d’outils, il faudra peut-être les intégrer à mon framework même s’il dispose déjà de l’exécution de scripts arbitraires
La sélection de fonctions/d’outils est gérée au niveau de l’application et il n’existe actuellement pas de format standard. Même les solutions largement utilisées ressemblent en pratique à des prompts système personnalisés et inefficaces : https://github.com/langchain-ai/langchain/blob/master/libs/l...
Quoi qu’il en soit, il vaut peut-être mieux ne pas proposer une prise en charge qui ne fonctionne pas
Pour info, le script d’installation Linux d’Ollama fonctionne selon la méthode « standard » courante avec les outils actuels :
curl https://ollama.ai/install.sh | shCela dit, la dernière fois que j’ai vérifié, ce script demandait les droits root via
sudo. Si vous voulez utiliser l’outil, mieux vaut télécharger le script, l’examiner ou l’adapter à vos besoinschmod +x ollama-linux-amd64), puis de l’exécuter. Aucun droit root n’était nécessaire[0] https://github.com/ollama/ollama/blob/main/docs/linux.md#man...
[1] https://ollama.ai/download/ollama-linux-amd64
ollamaest placé dans/usr/bin; ce n’est pas strictement nécessaire, mais c’est pratique. Je n’ai pas vérifié ce qui, en dehors de cela, nécessite un accès rootLa couche de compatibilité peut aussi être créée dans une bibliothèque. Par exemple,
llm()de LangChain peut fonctionner avec plusieurs backends LLM. Je me demande quelle approche vous préférezUn autre problème est que si le monde se standardise autour de bibliothèques médiocres comme LangChain, le coût de maintenance de backends non uniformes risque de tuer les nouveaux entrants et de les enfermer durablement. Donc, pour l’instant, une API uniforme semble être le meilleur choix par commodité
Même imparfaite, une API standard est une bonne chose. En parallèle, il peut très bien exister une deuxième API, comme B2 de Backblaze, qui permet d’exploiter tout le potentiel. Il n’y a pas de solution unique qui convienne à tous les modèles ; si les modèles ont des capacités différentes, je pense qu’il vaut mieux proposer les deux options
Je construis un projet qui permet de basculer facilement, en Python, entre des modèles open source (via HF, VLLM) et des modèles commerciaux (OpenAI, Google, Anthropic, Together) : https://github.com/datadreamer-dev/DataDreamer
Si vous voulez l’utiliser directement depuis Python sans API HTTP, c’est une approche un peu plus simple
Je me demande quels sont les cas d’usage d’Ollama. Pourquoi ne pas utiliser directement
llama.cpp?llama.cpp, qui dispose aussi d’un serveur intégré compatible OpenAI