Exécuter Nemotron 3.5 Lightning sur un VPS avec Ollama

À quoi sert Nemotron 3.5 Lightning

Nemotron 3.5 Lightning est le modèle Mixture-of-Experts (MoE) 30B ouvert de NVIDIA, publié en août 2026. Il est conçu pour des agents qui s'exécutent pendant des heures plutôt que pour une simple fenêtre de chat. MoE signifie que les poids sont répartis dans de nombreux sous-réseaux experts, et que chaque token n'est routé qu'à travers quelques-uns d'entre eux. La fiche technique de NVIDIA indique 30 milliards de paramètres au total, avec 3 milliards actifs par token. Vous payez pour le nombre élevé en mémoire. Vous obtenez le nombre réduit en vitesse.

Ce compromis est la raison pour laquelle il faut envisager ce modèle pour un serveur loué. Un agent effectuant un travail réel envoie des milliers de requêtes courtes au cours d'une journée ; le débit par dollar détermine donc s'il peut être hébergé sur votre propre machine. Un modèle qui prend 40 secondes par réponse est un assistant utilisable mais un piètre agent, car une seule tâche génère vingt appels et vous attendez chacun d'entre eux.

NVIDIA décrit l'architecture comme hybride : des couches Mamba-2 et MoE entrelacées avec des couches d'attention sélectionnées. La fiche technique indique une longueur de contexte maximale allant jusqu'à 1M de tokens et une licence OpenMDW-1.1, marquée comme prête pour un usage commercial. Les langues principales sont l'anglais et le code, avec l'espagnol, le français, l'allemand, l'italien et le japonais également listés.

Artificial Analysis a publié des mesures de lancement en août 2026 montrant près de 670 tokens de sortie par seconde, sur un endpoint DeepInfra de pré-lancement utilisant les poids NVFP4. Il s'agit d'un endpoint GPU hébergé. Interprétez cela comme ce que l'architecture permet, et non comme ce que votre VPS sera capable de faire.

Quel tag Ollama choisir pour quel VPS

La bibliothèque Ollama publie plusieurs builds pour les mêmes poids. Ce qui change entre eux est la quantification, c'est-à-dire le nombre de bits utilisés pour stocker chaque poids, ce qui modifie considérablement la taille du téléchargement.

[
  {
    "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 pointent tous vers le même digest que 30b-a3b-q4_K_M. Le téléchargement par défaut est donc le build quatre bits de 25 Go avec un contexte complet de 1M. Le Q8_0 pèse 35 Go et le bf16 pèse 66 Go, tous deux également avec un contexte de 1M. Les builds MLX à 23 Go sont destinés à l'architecture Apple silicon et sont limités à un contexte de 256K ; ils ne sont donc pas adaptés à un VPS Linux.

Il s'agit de tailles de téléchargement, pas d'exigences en mémoire vive. NVIDIA ne publie pas de valeur minimale de VRAM (mémoire vidéo) pour les builds Ollama. Considérez la taille du téléchargement comme un strict minimum. Les poids doivent être chargés quelque part : dans la mémoire du GPU si la carte peut les contenir, sinon dans la RAM système. Le cache KV (cache clé/valeur, la mémoire du modèle par jeton pour la conversation) s'ajoute à cela. La valeur réelle pour votre matériel s'obtient par une commande, et non par un calcul, et elle est indiquée ci-dessous. Si vous n'avez pas encore choisi de niveau de quantification, le coût en ressources du Q4, Q8 et FP16 détaille les compromis effectués à chaque étape.

Utilisez le tag exact, jamais latest

latest est un pointeur dynamique. Lorsque la bibliothèque le republie, le comportement de votre agent change au prochain pull sans aucune note pour expliquer pourquoi. Nommez 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 en tant qu'utilisateur ollama et conserve les modèles sous /usr/share/ollama/.ollama/models. Ce chemin se trouve sur le système de fichiers racine de la plupart des images VPS ; vérifiez donc l'espace disponible avant de demander 25 Go.

df -h /usr/share/ollama

Un pull qui s'interrompt en cours de route et signale no space left on device signifie exactement cela, et les blobs partiels restent sur le disque jusqu'à ce que vous les supprimiez. Confirmez ensuite ce qui a été téléchargé :

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 que le fichier contient réellement. Si l'un de ces éléments ne correspond pas à la page de la bibliothèque, vous avez récupéré un tag différent de celui prévu.

Servez le modèle et vérifiez où il s'exécute réellement

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 chargé, dans un second terminal :

ollama ps

Cette commande répond à la question de la mémoire pour votre machine. ollama ps affiche le modèle chargé, la taille qu'il occupe en mémoire et une colonne PROCESSOR. 100% GPU signifie que l'intégralité du modèle est en VRAM. 100% CPU signifie qu'aucune partie n'y est présente et que chaque token est calculé par le processeur à partir de la RAM système. Une répartition telle que 65%/35% CPU/GPU signifie que les couches n'ont pas toutes pu être chargées, et la part allouée au CPU détermine votre vitesse. N'estimez pas les besoins. Chargez le modèle et lisez cette ligne.

S'il ne peut pas être chargé, Ollama refuse proprement au lieu de planter :

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

Un VPS uniquement CPU est-il assez rapide ?

Un VPS à usage général ne possède pas de GPU. Le CPU effectue donc tout le travail et lit chaque poids nécessaire depuis la RAM système. L'architecture MoE est utile ici, car seuls environ 3 milliards des 30 milliards de paramètres sont sollicités par jeton (token). Le calcul arithmétique par jeton est donc bien plus faible que pour un modèle dense de 30B. La mémoire, en revanche, n'est pas soulagée. L'intégralité des 30 milliards de paramètres doit rester en mémoire vive, car le routeur peut sélectionner n'importe quel expert pour n'importe quel jeton.

L'inférence sur CPU seul pour ce modèle est donc limitée par la bande passante mémoire plutôt que par le nombre de cœurs. Ajouter des vCPU à une offre qui en possède déjà un nombre raisonnable change très peu de choses. Ce dont vous avez besoin, c'est d'assez de RAM pour stocker les poids ainsi que votre cache KV, et de la mémoire la plus rapide disponible dans l'offre.

Mesurez les performances avant d'y déployer un agent, en utilisant la méthode décrite dans mesurer les jetons 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 correspond à votre vitesse de génération en jetons par seconde. Ce chiffre unique tranche la question, car le temps réel d'exécution d'un agent en dépend principalement.

[
  {
    "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
  }
]

Il s'agit de chiffres tiers publiés, convertis à partir des minutes par tâche rapportées par Artificial Analysis lors du lancement. Ils ont été mesurés sur des terminaux GPU hébergés et non sur un VPS. Nemotron 3.5 Lightning a atteint une moyenne d'environ 30 secondes par tâche, où gpt-oss-120b a pris environ 204 et Qwen3.6 35B environ 210. Utilisez ces données pour visualiser l'écart de performance, et non comme une garantie pour votre matériel.

Le conseil honnête dépend de qui attend. Si une personne attend après l'agent, ou si l'agent enchaîne de longues séries d'appels, louez une capacité GPU. S'il s'exécute selon un planning durant la nuit sans surveillance, une offre CPU avec beaucoup de RAM est une solution raisonnable. Dans les deux cas, la configuration est identique, et exécuter Ollama sur un VPS détaille le dimensionnement de l'offre et la comparaison entre une instance GPU et le paiement à l'utilisation via un fournisseur d'API. Le seuil de rentabilité est une question d'utilisation : une instance GPU est facturée à chaque heure d'existence, tandis que les jetons d'API ne sont facturés qu'à l'usage. Un agent actif la majeure partie de la journée justifie donc la possession de votre propre machine, alors qu'un agent qui s'exécute deux fois par heure ne le justifie généralement pas.

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

1M de tokens est le maximum du modèle, et Ollama ne vous l'attribue pas par défaut. Ollama utilise une fenêtre par défaut beaucoup plus petite et supprime les tokens les plus anciens une fois qu'une conversation la dépasse. Rien n'est consigné lors de cette opération, donc pour un agent, cela ressemble à un oubli par le modèle du début de sa propre tâche.

Définissez la fenêtre intentionnellement. 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"

Par requête, envoyez plutôt num_ctx dans l'objet 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 croît avec le nombre de tokens autorisés. Augmentez la valeur, redémarrez, puis exécutez à nouveau ollama ps et observez la taille rapportée augmenter. Si la colonne PROCESSOR passe de 100% GPU à une valeur divisée après ce changement, le cache KV a expulsé des couches du modèle de la VRAM et votre vitesse chutera drastiquement. Choisir num_ctx dans Ollama détaille ce compromis. Ne définissez pas 1000000 simplement parce que la fiche du modèle l'autorise, car l'allocation se fait au démarrage et la charge échouera tout simplement.

Intégration dans un agent permanent

L'article de lancement d'Ollama pour ce modèle documente un raccourci qui démarre un agent compatible déjà configuré pour l'utiliser :

ollama launch claude --model nemotron-3.5-lightning

L'article documente claude, opencode, openclaw et hermes à cet emplacement. La sous-commande nécessite une version récente d'Ollama, vérifiez donc d'abord ollama --version. S'il est absent, configurez vous-même l'agent pour pointer vers l'API. Ollama expose un endpoint compatible avec 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 sans qu'une valeur soit définie. La partie framework est traitée dans pointer un agent de développement vers Ollama et dans créer votre propre agent OpenClaw.

Deux paramètres du serveur sont importants une fois que l'agent fonctionne en arrière-plan. 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, ce qui impose un temps de chargement complet à la requête suivante. Sur un fichier de 25 Go sans GPU, cette pause est suffisamment longue pour provoquer un dépassement de délai. Définissez OLLAMA_KEEP_ALIVE=-1 pour le maintenir en mémoire. OLLAMA_HOST=0.0.0.0:11434 rend l'API accessible depuis d'autres machines. Comme elle ne comporte aucune authentification, ne l'ouvrez que derrière une règle de pare-feu ou sur un réseau privé.

Modes de défaillance et messages associés

Le pull échoue immédiatement. Error: pull model manifest: file does not exist signifie que le tag n'existe pas. Les noms de tags sont des chaînes exactes ; copiez-les depuis la page de la bibliothèque plutôt que 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 tel qu'il est configuré. Passez à une quantification plus petite ou réduisez OLLAMA_CONTEXT_LENGTH, car le cache KV est comptabilisé dans cette exigence.

Aucune réponse sur le port 11434. curl: (7) Failed to connect to localhost port 11434 signifie que le service n'est pas en cours d'exécution ou n'écoute pas là où vous l'attendez. 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 toute modification. Toute part de CPU dans la colonne PROCESSOR sur une machine équipée d'un GPU signifie qu'une partie du modèle a débordé de la VRAM ; réduisez donc le contexte ou utilisez une quantification plus petite. Sur une machine sans GPU, la lenteur est le résultat attendu et aucun réglage ne peut y remédier.

L'agent oublie ses instructions en cours de 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, confirmez 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.

Positionnement de ce modèle par rapport aux alternatives

Un modèle MoE de 30B est une ressource lourde à héberger pour une tâche simple. Si un modèle dense de 8B suffit à votre besoin, il sera bien moins coûteux à exécuter et se chargera en quelques secondes. Qwen 3 en 8B et 27B sur un VPS constitue la comparaison directe pour ce choix. Pour une vue d'ensemble plus large des capacités d'un plan d'hébergement donné, consultez quels modèles d'IA vous pouvez auto-héberger. Si vous prévoyez de servir plusieurs agents simultanément plutôt qu'un seul, lisez d'abord Ollama comparé à vLLM. En effet, Ollama ne traite pas les requêtes concurrentes par lots comme le ferait un serveur d'inférence en production, ce qui marque la limite de passage à l'échelle d'une configuration mono-utilisateur.

FAQ

Quel tag Nemotron 3.5 Lightning dois-je pull sur un VPS Linux ?

Utilisez nemotron-3.5-lightning:30b-a3b-q4_K_M. Il pèse 25 Go, il supporte le contexte maximal complet de 1M, et il correspond au même digest que les tags latest, 30b et 30b-a3b en août 2026. Nommez-le explicitement plutôt que de pull latest, afin qu'une republication future de ce pointeur ne modifie pas le comportement de votre agent sans que vous ne le remarquiez. Les tags mlx sont des builds pour Apple silicon et ne fonctionneront pas sur 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, donc mesurez plutôt que d'estimer. Pull le tag, lancez le modèle une fois, et lisez ollama ps pendant qu'il est chargé : cela affiche la taille réellement occupée et indique s'il est chargé sur le GPU ou le CPU. La taille du téléchargement, 25 Go pour le tag par défaut, est un minimum, car le cache KV s'ajoute par-dessus et augmente avec la fenêtre de contexte que vous définissez. Si le plan est trop petit, Ollama refuse 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. La conception MoE aide car seuls environ 3 des 30 milliards de paramètres sont calculés par token. La vitesse est le point critique. Sans GPU, le modèle est limité par la bande passante mémoire, donc ajouter des vCPU n'améliore quasiment pas le résultat. Exécutez ollama run --verbose avec un prompt fixe, lisez la ligne eval rate, et comparez ce chiffre avec les contraintes de temps de votre agent. Pour un traitement par lots durant la nuit, c'est souvent suffisant. Pour tout ce qui nécessite une interaction humaine, ce ne l'est généralement pas.

Pourquoi Ollama ne me donne-t-il pas la fenêtre de contexte complète de 1M ?

1M est le 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 une fois qu'une conversation la dépasse, sans afficher d'erreur, ce qui donne l'impression que l'agent oublie ses propres instructions. Définissez OLLAMA_CONTEXT_LENGTH dans le service systemd, ou passez num_ctx par requête. Augmentez la valeur par paliers et vérifiez ollama ps à chaque fois, car la mémoire du cache KV évolue avec la fenêtre et peut expulser des couches du modèle hors du GPU.

Nemotron 3.5 Lightning est-il gratuit pour un usage commercial ?

La fiche technique du modèle de NVIDIA place celui-ci sous la licence OpenMDW-1.1 et le déclare prêt pour un usage commercial. Cela couvre les poids que vous téléchargez et exécutez vous-même. Cela ne concerne pas les autres logiciels de votre stack, donc vérifiez séparément les licences de votre agent et de tous les outils auxquels vous le connectez, et lisez la fiche technique actuelle du modèle avant de vous appuyer dessus pour tout engagement contractuel.