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

Pointez l'agent vers le serveur, dans son 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

Si le serveur exige une clé, exportez-la — elle ne va jamais dans le YAML :
```
export OPENAI_API_KEY=sk-…
```
Un autre nom de variable : apiKeyEnv: MA_CLE_PASSERELLE.
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 :
```
🛠️  bash: echo hello-from-openai-provider
   │ hello-from-openai-provider
🤖 The command printed: `hello-from-openai-provider`
```

mm init --provider openai --base-url <adresse> écrit ce fichier pour vous (voir Créer un agent avec mm init).

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.)
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 : ce que openai envoie et n'envoie pas
Les fournisseurs — explication

 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


# 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 --provider openai --base-url <adresse>` écrit ce fichier pour vous (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.)
- **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)