Comment transformer un modèle local en serveur pour vos applications?

Une fenêtre de clavardage n’est qu’un début. Une fois qu’un modèle tourne sur votre matériel, vous voudrez probablement que d’autres programmes s’en servent : un agent de programmation, un script qui résume des fichiers, un outil interne pour votre équipe. Pour cela, on fait tourner le modèle comme serveur, un programme qui attend des requêtes à une adresse réseau et renvoie les réponses.

Presque tous ces serveurs parlent la même langue. Ils copient le format de requête de l’API d’OpenAI : un logiciel écrit pour un modèle hébergé peut donc habituellement viser votre machine en changeant un seul réglage. La comparaison d’Ollama et de LM Studio couvre les applications de bureau. Cet article couvre le côté serveur, et le choix d’un moteur.

Trois moteurs

Un exemple concret : trois façons de démarrer

Avec Ollama, le serveur tourne déjà en arrière-plan une fois l’installation faite, et l’API répond sur le port 11434.

Avec llama.cpp, vous nommez un modèle et une taille de contexte. Ici, 32 768 jetons sont partagés par deux emplacements :

llama-server -hf <user>/<model>:<tag> -c 32768 --parallel 2 --port 8080

Avec vLLM, sur une machine Linux dotée d’une carte graphique convenable :

uv pip install vllm --torch-backend=auto
vllm serve Qwen/Qwen2.5-1.5B-Instruct --host 127.0.0.1 --max-model-len 8192 --gpu-memory-utilization 0.8

On peut ensuite appeler n’importe lequel de la même façon, ici en Python avec le client OpenAI habituel :

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:8080/v1", api_key="local")
reply = client.chat.completions.create(
    model="local",
    messages=[{"role": "user", "content": "Résume cette note en deux lignes : ..."}],
)
print(reply.choices[0].message.content)

Changez le port selon votre moteur. Sur Ollama et vLLM, model doit être le nom que le serveur indique à /v1/models.

Les réglages qui piègent

La mémoire. vLLM prend 92 % de la mémoire graphique par défaut : réduisez donc --gpu-memory-utilization si autre chose partage la carte. Son guide sur la mémoire recommande aussi de limiter --max-model-len si vous en manquez.

Le contexte multiplié par les utilisateurs. Dans Ollama, la mémoire requise croît selon le nombre de requêtes parallèles multiplié par la longueur du contexte. Quatre requêtes parallèles à 32 000 jetons coûtent à peu près autant qu’une seule à 128 000. Un modèle qui convenait à une personne peut échouer à quatre, et le calcul de la mémoire montre comment le prévoir.

Les files d’attente. Quand trop de requêtes arrivent, Ollama répond par une erreur 503, et OLLAMA_MAX_QUEUE fixe la longueur de la file. Votre application devrait réessayer plutôt qu’échouer.

Ce que rapporte le traitement par lots

Un modèle de langage peut travailler sur plusieurs requêtes à la fois, en lisant les mêmes poids pour toutes. Le traitement par lots continu ajoute de nouvelles requêtes au lot à mesure que d’autres finissent, ce qui garde la machine occupée. llama-server et vLLM l’offrent tous deux.

LMSYS a mesuré ce que cela donne sur un DGX Spark, avec un autre serveur appelé SGLang. Sur Llama 3.1 8B, une requête à la fois produisait 20,5 jetons par seconde. Avec 32 requêtes à la fois, le total atteignait 368 jetons par seconde. C’est environ 18 fois plus de travail avec la même puce, mais chaque personne voit alors environ 11,5 jetons par seconde, moins qu’un utilisateur seul. Le traitement par lots profite à un service partagé, pas à une conversation unique.

Garder le tout privé

Local veut dire privé seulement tant que le serveur reste local. Ollama et llama-server n’écoutent par défaut que votre propre machine, et le guide de vLLM décrit localhost comme son réglage par défaut. Nommez l’adresse explicitement, comme dans la commande ci-dessus, puis vérifiez depuis un autre appareil.

• Ollama : régler OLLAMA_HOST à 0.0.0.0 l’expose à votre réseau.
• llama-server : --host change l’adresse et --api-key active une clé. Il n’y a pas de clé par défaut.
• vLLM : --api-key ou la variable VLLM_API_KEY fait de même.

Si d’autres ont besoin d’accès, utilisez un RPV ou un mandataire inverse avec sa propre connexion plutôt que d’ouvrir le port sur votre routeur. Les journaux de clavardage restent aussi sur votre disque, comme l’explique le guide nuage ou local.

Voici mon installation : [moteur, modèle, mémoire graphique, nombre d’utilisateurs prévus, longueur typique des prompts]. Suggère des valeurs de longueur de contexte et de requêtes parallèles qui entrent dans ma mémoire, et montre le calcul. Dresse ensuite la liste de ce que je dois vérifier pour confirmer que le serveur n’est accessible qu’aux personnes voulues.

Avez-vous besoin d’un serveur si vous travaillez seul?

Vous en avez probablement déjà un. Ollama et LM Studio font tourner une API locale : un agent de programmation ou un script peut donc s’en servir sans travail de plus. Rien ne justifie d’installer vLLM pour une seule personne sur un ordinateur domestique, car l’avantage du traitement par lots n’apparaît que lorsque plusieurs requêtes arrivent en même temps.

Passez à vLLM quand vous avez une vraie file d’attente : une équipe qui partage un modèle, ou un programme qui envoie beaucoup de requêtes en parallèle. D’ici là, le montage le plus simple qui garde vos données sur votre machine est le bon. Si vos besoins grandissent, vos applications changeront peu, puisque les trois acceptent le même format de requête.