Utiliser n'importe quel serveur compatible OpenAI

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

# Utiliser n'importe quel serveur compatible OpenAI

Ce guide montre comment faire tourner mini-me sur un serveur de modèles qui n'a pas de fournisseur dédié — l'API d'OpenAI elle-même, vLLM, LM Studio, OpenRouter, une passerelle d'entreprise — avec le fournisseur générique `openai`. Il suppose que le serveur parle le protocole chat-completions d'OpenAI et gère les appels d'outils.

## Étapes

1. Pointez l'agent vers le serveur, dans son YAML :

   ```yaml
   provider: openai
   model: mon-modele                     # tel que le serveur le nomme : GET <baseUrl>/models
   baseUrl: http://localhost:8000/v1     # à omettre pour l'API d'OpenAI
   contextWindow: 32768                  # la fenêtre servie : ce fournisseur ne peut pas la demander
   ```

2. Si le serveur exige une clé, exportez-la — elle ne va jamais dans le YAML :

   ```bash
   export OPENAI_API_KEY=sk-…
   ```

   Un autre nom de variable : `apiKeyEnv: MA_CLE_PASSERELLE`.

3. Lancez mm comme d'habitude (`mm agent.yaml`, `mm -tui agent.yaml`, `mm -acp`). Vérifié avec l'adresse OpenAI de llmman utilisée comme serveur générique : la sonde de démarrage liste les modèles, et un appel à l'outil `bash` s'exécute :

   ```text
   🛠️  bash: echo hello-from-openai-provider
      │ hello-from-openai-provider
   🤖 The command printed: `hello-from-openai-provider`
   ```

`mm init` écrit ce fichier pour vous : choisissez `openai`, puis donnez l'endpoint et le nom de la variable qui contient la clé (ou `--provider openai --base-url <adresse> --api-key-env <VARIABLE>`) (voir [Créer un agent avec `mm init`](create-an-agent.md)).

## Variantes

- **L'API d'OpenAI.** Pas de `baseUrl`, `OPENAI_API_KEY` exportée, un modèle comme `gpt-5-mini`. Ses modèles à raisonnement n'acceptent que la température par défaut et prennent `max_completion_tokens` au lieu de `max_tokens` : écrivez `temperature: 1.0` et `max_completion_tokens` dans `sampling`. Avec `provider: openai`, mm envoie ce bloc tel quel, sans ses propres valeurs par défaut (`top_p`, `max_tokens`) : retirez seulement une clé que l'API refuserait encore. `mm init` écrit un tel bloc. (Le contenu de la requête a été vérifié contre un serveur local ; aucun appel à l'API OpenAI n'a été fait dans ce dépôt.)
- **« Function tools with reasoning_effort are not supported ».** Certains modèles OpenAI (vu : `gpt-6-luna`) refusent les outils sur `/v1/chat/completions` pendant qu'ils raisonnent ; mm utilise cette route et envoie toujours des outils. Ajoutez `reasoning_effort: none` à `sampling` (cela coupe le raisonnement). Non vérifié dans ce dépôt : signalé par un utilisateur.
- **La clé est refusée.** L'avertissement de démarrage indique `openai: <baseUrl> refused the key (HTTP 401) — export OPENAI_API_KEY`.
- **Rien ne répond.** L'avertissement indique `openai: nothing answers at <baseUrl> — check baseUrl: …` : l'adresse doit être celle compatible OpenAI, qui finit généralement par `/v1`.
- **Un serveur pour lequel mm a un fournisseur.** Préférez-le (`dmr`, `llamacpp`, `llmman`, `ollama`) : ceux-là savent comment le serveur lit un long prompt, coupent le raisonnement pour un résumé, déchargent un modèle et donnent la taille de la fenêtre. Le fournisseur générique ne fait rien de tout cela.

## Voir aussi

- [Référence de la configuration — valeurs par défaut des fournisseurs](../reference/configuration.md#valeurs-par-défaut-des-fournisseurs) : ce que `openai` envoie et n'envoie pas
- [Les fournisseurs — explication](../explanation/providers.md)