Installer Nemotron 3.5 Lightning sur un VPS avec Ollama

À quoi sert Nemotron 3.5 Lightning

Nemotron 3.5 Lightning est le modèle open source de NVIDIA, doté de 30B paramètres et fondé sur une architecture mixture-of-experts. Publié en août 2026, il est conçu pour les agents qui s’exécutent pendant plusieurs heures, et non pour une seule fenêtre de chat. MoE (mixture of experts) signifie que les poids sont répartis entre de nombreux sous-réseaux experts, et que chaque token ne passe que par quelques-uns d’entre eux. La model card de NVIDIA indique 30 milliards de paramètres au total, dont 3 milliards actifs par token. Vous payez le nombre total en mémoire. Vous bénéficiez du nombre actif en vitesse.

C’est ce compromis qui rend ce modèle intéressant pour un serveur que vous louez. Un agent qui effectue réellement des tâches envoie des milliers de requêtes courtes au cours d’une journée. Le débit par dollar détermine donc s’il peut fonctionner sur votre propre serveur. Un modèle qui met 40 secondes à répondre est un assistant utilisable, mais un mauvais agent, car une tâche peut nécessiter vingt appels et vous devez attendre chacun d’eux.

NVIDIA décrit cette architecture comme hybride : des couches Mamba-2 et MoE entrelacées, avec certaines couches d’attention. La model card indique une longueur de contexte maximale de 1M tokens et une licence OpenMDW-1.1, présentée comme compatible avec un usage commercial. Les langues principales sont l’anglais et le code. L’espagnol, le français, l’allemand, l’italien et le japonais sont également pris en charge.

Artificial Analysis a publié en août 2026 des mesures réalisées au lancement, avec près de 670 tokens de sortie par seconde, sur un endpoint DeepInfra en préversion qui servait les poids NVFP4. Il s’agit d’un endpoint GPU hébergé. Interprétez ce résultat comme une indication de ce que l’architecture permet, et non comme une estimation des performances de votre VPS.

Quel tag Ollama choisir selon le VPS

La bibliothèque Ollama publie plusieurs builds avec les mêmes poids. Ce qui change entre ces builds est la quantification, c’est-à-dire le nombre de bits utilisés pour stocker chaque poids. La taille du téléchargement varie donc fortement.

[
  {
    "label": "30b-a3b-q4_K_M",
    "size_gb": 25
  },
  {
    "label": "30b-a3b-q8_0",
    "size_gb": 35
  },
  {
    "label": "30b-a3b-bf16",
    "size_gb": 66
  },
  {
    "label": "30b-a3b-mlx",
    "size_gb": 23
  }
]

Les tags nommés latest, 30b et 30b-a3b renvoient tous au même digest que 30b-a3b-q4_K_M. Le téléchargement par défaut correspond donc au build quatre bits de 25 GB, avec le contexte complet de 1M. Q8_0 fait 35 GB et bf16 fait 66 GB, tous deux avec un contexte de 1M. Les builds MLX de 23 GB sont destinés aux puces Apple et limités à un contexte de 256K. Ils ne conviennent donc pas à un VPS Linux.

Il s’agit de tailles de téléchargement, pas d’une quantité de mémoire requise. NVIDIA ne publie pas de valeur minimale de VRAM (mémoire vidéo) pour les builds Ollama. Considérez donc la taille du téléchargement comme un seuil minimal, et rien de plus. Les poids doivent être présents quelque part : en mémoire GPU si la carte peut les contenir, sinon en RAM système. Le cache KV (cache clé/valeur, c’est-à-dire la mémoire utilisée par le modèle pour chaque token de la conversation) s’y ajoute. La valeur réelle pour votre matériel s’obtient avec une commande, pas par un calcul. Cette commande figure ci-dessous. Si vous n’avez pas encore choisi le niveau de quantification, ce que Q4, Q8 et FP16 impliquent explique ce qui est perdu à chaque étape.

Récupérez le tag exact, jamais latest

latest est un pointeur qui évolue. Lorsque la bibliothèque le republie, le comportement de votre agent change lors du prochain pull, sans aucune indication dans vos notes pour expliquer pourquoi. Indiquez le tag.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama pull nemotron-3.5-lightning:30b-a3b-q4_K_M

Le script d’installation configure un service systemd qui s’exécute avec l’utilisateur ollama et conserve les modèles dans /usr/share/ollama/.ollama/models. Sur la plupart des images VPS, ce chemin se trouve sur le système de fichiers racine. Vérifiez donc l’espace disponible avant de demander 25 Go. Si ce système de fichiers est presque plein, consultez l’emplacement de stockage des modèles d’Ollama et la manière de les déplacer avant le pull, plutôt qu’après le remplissage du disque.

df -h /usr/share/ollama

Un pull qui s’arrête en cours d’exécution et affiche no space left on device signifie exactement cela. Les blobs partiels restent sur le disque jusqu’à leur suppression. Vérifiez ensuite ce qui a été récupéré :

ollama show nemotron-3.5-lightning:30b-a3b-q4_K_M

ollama show affiche l’architecture, le nombre de paramètres, la longueur du contexte et la quantification réellement intégrés au fichier. Si l’une de ces informations ne correspond pas à la page de la bibliothèque, vous avez récupéré un autre tag que celui prévu.

Lancer le modèle et vérifier où il s’est réellement exécuté

sudo systemctl enable --now ollama
ollama run nemotron-3.5-lightning:30b-a3b-q4_K_M "Reply with one word: ready"

Pendant que le modèle est encore chargé, ouvrez un second shell :

ollama ps

Cette commande répond à la question de la mémoire pour votre machine. ollama ps affiche le modèle chargé, la mémoire qu’il occupe et une colonne PROCESSOR. 100% GPU signifie que le modèle est entièrement en VRAM. 100% CPU signifie qu’il n’y en a aucune partie et que chaque token est calculé par le processeur dans la RAM système. Une répartition telle que 65%/35% CPU/GPU signifie que toutes les couches n’ont pas pu tenir en mémoire et que la part traitée par le CPU détermine votre vitesse. N’estimez pas la mémoire nécessaire. Chargez le modèle et lisez cette ligne.

S’il ne peut pas être chargé, Ollama refuse proprement la requête au lieu de planter :

Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB)

Un VPS uniquement équipé de CPU est-il assez rapide ?

Un VPS généraliste n’a pas de GPU. Le CPU effectue donc tout le travail et lit chaque poids dont il a besoin dans la RAM système. Le MoE est utile ici, car seuls environ 3 milliards des 30 milliards de paramètres sont sollicités par token. Le nombre d’opérations par token est donc bien inférieur à celui d’un modèle dense de 30B. En revanche, la mémoire n’est pas réduite. Les 30 milliards de paramètres doivent rester chargés, car le routeur peut sélectionner n’importe quel expert pour chaque token.

L’inférence CPU uniquement sur ce modèle est donc limitée par la bande passante mémoire, et non par le nombre de cœurs. Ajouter des vCPU à une offre qui en fournit déjà un nombre raisonnable change très peu les performances. Il faut suffisamment de RAM pour contenir les poids et votre cache KV, ainsi que la mémoire la plus rapide proposée par l’offre.

Mesurez les performances avant d’y déployer un agent, en utilisant la méthode décrite dans mesurer les tokens par seconde pour un LLM local :

ollama run --verbose nemotron-3.5-lightning:30b-a3b-q4_K_M "Write a 200 word summary of TCP slow start."

La ligne eval rate affichée à la fin indique votre vitesse de génération en tokens par seconde. Ce nombre suffit à trancher, car le temps d’exécution d’un agent dépend principalement de cette valeur. Multipliez-la par la longueur de réponse attendue. Si le résultat dépasse le délai que vous acceptez, limiter la sortie avec num_predict est le seul réglage qui permet de borner la durée d’un appel sans modifier le matériel.

[
  {
    "label": "Nemotron 3.5 Lightning",
    "sec_per_task": 30
  },
  {
    "label": "gpt-oss-120b",
    "sec_per_task": 204
  },
  {
    "label": "Qwen3.6 35B",
    "sec_per_task": 210
  }
]

Ces chiffres publiés par des tiers ont été convertis à partir des durées par tâche en minutes indiquées par Artificial Analysis lors du lancement. Ils ont été mesurés sur des endpoints GPU hébergés, et non sur un VPS. Nemotron 3.5 Lightning a atteint en moyenne environ 30 secondes par tâche. gpt-oss-120b a pris environ 204, et Qwen3.6 35B environ 210. Utilisez ces valeurs pour évaluer l’écart entre les configurations, et non comme une garantie pour votre matériel.

La recommandation dépend de la personne qui attend le résultat. Si un utilisateur attend l’agent, ou si l’agent enchaîne de nombreux appels, louez de la capacité GPU. S’il s’exécute pendant la nuit selon une planification et que personne ne le surveille, une offre CPU avec beaucoup de RAM est un choix raisonnable. Dans les deux cas, la configuration est identique. Exécuter Ollama sur un VPS détaille le dimensionnement de l’offre et compare une instance GPU au paiement d’un fournisseur d’API à chaque token. Le seuil de rentabilité dépend de l’utilisation : une instance GPU est facturée pour chaque heure pendant laquelle elle existe, tandis que les tokens d’API ne sont facturés que lorsqu’ils sont utilisés. Un agent actif la majeure partie de la journée justifie donc plutôt une machine que vous possédez. Un agent qui se déclenche deux fois par heure ne la justifie généralement pas.

La fenêtre de contexte de 1M n’est pas gratuite

1M tokens correspond au maximum du modèle, mais Ollama ne vous l’attribue pas par défaut. Ollama utilise une fenêtre par défaut bien plus petite et supprime les tokens les plus anciens lorsque la conversation la dépasse. Rien n’est journalisé lorsque cela se produit. Pour un agent, le modèle semble donc oublier le début de sa propre tâche.

Définissez volontairement la taille de la fenêtre. Pour l’ensemble du serveur, modifiez le service :

sudo systemctl edit ollama

Ajoutez ceci, puis exécutez sudo systemctl restart ollama :

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Pour une seule requête, envoyez plutôt num_ctx dans l’objet d’options :

curl http://localhost:11434/api/chat -d '{
  "model": "nemotron-3.5-lightning:30b-a3b-q4_K_M",
  "messages": [{"role": "user", "content": "Say ready"}],
  "options": {"num_ctx": 32768},
  "stream": false
}'

Chaque augmentation consomme de la mémoire, car le cache KV augmente avec le nombre de tokens autorisés. Augmentez la valeur, redémarrez, puis exécutez de nouveau ollama ps et surveillez la taille affichée. Si la colonne PROCESSOR passe de 100% GPU à un mode partagé après cette modification, le cache KV a déplacé des couches du modèle hors de la VRAM et votre débit va fortement baisser. Choisir num_ctx dans Ollama explique ce compromis en détail. Ne définissez pas 1000000 simplement parce que la fiche du modèle l’autorise : l’allocation a lieu au démarrage et le chargement échoue simplement.

Intégrer le modèle à un agent toujours actif

L’article de lancement d’Ollama pour ce modèle documente un raccourci qui démarre directement un agent compatible avec le modèle :

ollama launch claude --model nemotron-3.5-lightning

L’article documente claude, opencode, openclaw et hermes à cet endroit. Cette sous-commande nécessite une version récente d’Ollama. Vérifiez donc d’abord ollama --version. Si la commande est absente, configurez vous-même l’agent pour utiliser l’API. Ollama fournit un endpoint compatible avec l’API OpenAI, que la plupart des frameworks d’agents acceptent :

export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollama

Ollama ignore la clé, mais la plupart des clients refusent de démarrer si elle n’est pas définie. La configuration du framework est expliquée dans configurer un agent de code avec Ollama et dans créer votre propre agent OpenClaw.

Deux paramètres du serveur sont importants lorsque l’agent s’exécute sans intervention. OLLAMA_KEEP_ALIVE contrôle la durée pendant laquelle un modèle reste en mémoire après la dernière requête. La valeur par défaut le décharge après cinq minutes. L’appel suivant doit donc à nouveau payer le temps de chargement complet. Pour un fichier de 25 Go utilisé sans GPU, cette pause est suffisamment longue pour provoquer l’expiration d’un délai d’attente. Définissez OLLAMA_KEEP_ALIVE=-1 pour conserver le modèle en mémoire. OLLAMA_HOST=0.0.0.0:11434 rend l’API accessible depuis d’autres machines. Il n’offre aucune authentification. N’exposez-le donc que derrière une règle de pare-feu ou sur un réseau privé.

Modes d’échec et messages affichés

Le pull échoue immédiatement. Error: pull model manifest: file does not exist signifie que ce tag n’existe pas. Les noms de tag sont des chaînes exactes. Copiez-en un depuis la page de la bibliothèque au lieu de deviner un suffixe de quantification.

Le modèle ne se charge pas. Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) signifie que le tag est trop volumineux pour ce plan avec cette configuration. Utilisez une quantification plus petite ou réduisez OLLAMA_CONTEXT_LENGTH, car le KV cache est inclus dans cette exigence.

Rien ne répond sur le port 11434. curl: (7) Failed to connect to localhost port 11434 signifie que le service n’est pas démarré ou qu’il n’écoute pas à l’endroit attendu. Consultez systemctl status ollama et journalctl -u ollama -n 50. Si vous avez également démarré ollama serve manuellement, la seconde instance se termine avec Error: listen tcp 127.0.0.1:11434: bind: address already in use.

Le service répond, mais très lentement. Vérifiez ollama ps avant de modifier quoi que ce soit. Sur une machine équipée d’un GPU, toute utilisation du CPU dans la colonne PROCESSOR signifie qu’une partie du modèle ne tient pas dans la VRAM. Réduisez donc le contexte ou utilisez une quantification plus petite. Sur une machine sans GPU, cette lenteur est attendue et aucun réglage ne permet de la corriger.

L’agent oublie ses instructions au milieu d’une tâche. La conversation a dépassé la fenêtre de contexte et les jetons les plus anciens ont été supprimés silencieusement. Augmentez OLLAMA_CONTEXT_LENGTH, puis vérifiez avec ollama ps que le modèle tient toujours en mémoire. Si ce n’est plus le cas, la solution consiste à utiliser une machine plus puissante plutôt qu’une fenêtre plus petite.

Comparaison avec les autres options

Héberger un MoE 30B représente une charge importante pour une tâche de faible ampleur. Si un modèle dense 8B suffit déjà pour votre tâche, son exécution coûtera bien moins cher et son chargement prendra quelques secondes. Pour comparer directement ces options, consultez Qwen 3 en 8B et 27B sur un VPS. Pour avoir une vue d’ensemble des modèles qu’un forfait donné peut réellement héberger, commencez par les modèles d’IA que vous pouvez auto-héberger. Si vous prévoyez d’exécuter plusieurs agents simultanément plutôt qu’un seul, consultez d’abord Ollama comparé à vLLM, car Ollama ne regroupe pas les requêtes simultanées comme le fait un serveur d’inférence de production. C’est à ce stade qu’une configuration mono-utilisateur cesse de passer à l’échelle.

FAQ

Quelle balise Nemotron 3.5 Lightning dois-je télécharger sur un VPS Linux ?

Utilisez nemotron-3.5-lightning:30b-a3b-q4_K_M. Cette balise fait 25 Go, prend en charge le contexte maximal complet de 1M et pointe vers le même digest que les balises latest, 30b et 30b-a3b en août 2026. Indiquez-la explicitement au lieu de télécharger latest, afin qu’une future republication de ce pointeur ne modifie pas le comportement de votre agent sans que vous le remarquiez. Les balises mlx sont des builds pour Apple silicon et ne vous seront d’aucune utilité sous Linux.

De combien de RAM Nemotron 3.5 Lightning a-t-il besoin ?

NVIDIA ne publie pas de valeur minimale de mémoire pour les builds Ollama. Mesurez donc la consommation au lieu de l’estimer. Téléchargez la balise, exécutez le modèle une fois, puis consultez ollama ps pendant son chargement : cette commande indique la taille réellement occupée et précise si le modèle a été chargé sur le GPU ou sur le CPU. La taille du téléchargement, soit 25 Go pour la balise par défaut, constitue un minimum, car le cache KV est ajouté par-dessus et augmente avec la fenêtre de contexte configurée. Si le plan est trop petit, Ollama refuse l’exécution avec model requires more system memory et indique les deux valeurs.

Puis-je exécuter Nemotron 3.5 Lightning sur un VPS sans GPU ?

Oui, si le plan dispose de suffisamment de RAM pour contenir les poids. L’architecture MoE aide également, car seuls environ 3 des 30 milliards de paramètres sont calculés pour chaque token. La vitesse est le principal problème. Sans GPU, le modèle est limité par la bande passante mémoire. Ajouter des vCPU améliore donc à peine le résultat. Exécutez ollama run --verbose avec un prompt fixe, consultez la ligne eval rate et comparez cette valeur au délai maximal acceptable pour votre agent. Pour un traitement par lots exécuté pendant la nuit, cela convient souvent. Pour une tâche dont une personne attend le résultat, ce n’est généralement pas suffisant.

Pourquoi Ollama ne m’accorde-t-il pas la fenêtre de contexte complète de 1M ?

1M correspond au maximum du modèle, pas à la valeur par défaut d’Ollama. Ollama applique une fenêtre beaucoup plus petite et supprime les tokens les plus anciens lorsqu’une conversation la dépasse. Aucun message d’erreur n’est affiché. L’agent semble alors oublier ses propres instructions. Définissez OLLAMA_CONTEXT_LENGTH sur le service systemd ou transmettez num_ctx pour chaque requête. Augmentez cette valeur progressivement et vérifiez de nouveau ollama ps à chaque étape, car la mémoire du cache KV augmente avec la taille de la fenêtre et peut déplacer des couches du modèle hors du GPU.

Nemotron 3.5 Lightning peut-il être utilisé gratuitement à des fins commerciales ?

La fiche du modèle de NVIDIA place celui-ci sous licence OpenMDW-1.1 et le signale comme prêt pour un usage commercial. Cela couvre les poids que vous téléchargez et exécutez vous-même. La licence ne dit rien des autres logiciels de votre stack. Vérifiez donc séparément les licences du framework d’agent et des outils que vous lui connectez. Consultez également la fiche actuelle du modèle avant de vous fonder sur ces informations pour un engagement contractuel.