Nemotron 3.5 Lightning auf VPS mit Ollama ausführen

Was Nemotron 3.5 Lightning ist

Nemotron 3.5 Lightning ist NVIDIAs offenes 30B Mixture-of-Experts-Modell, das im August 2026 veröffentlicht wurde. Es wurde für Agenten entwickelt, die über Stunden hinweg laufen und nicht nur für ein einzelnes Chat-Fenster gedacht sind. MoE (Mixture of Experts) bedeutet, dass die Gewichte in viele Experten-Teilnetzwerke aufgeteilt sind und jedes Token nur durch wenige davon geleitet wird. Die Modellkarte von NVIDIA gibt 30 Milliarden Gesamtparameter an, von denen 3 Milliarden pro Token aktiv sind. Man zahlt für die hohe Anzahl im Arbeitsspeicher. Man erhält die niedrige Anzahl als Geschwindigkeit zurück.

Dieser Kompromiss ist der Grund, sich dieses Modell für einen gemieteten Server anzusehen. Ein Agent, der echte Arbeit verrichtet, sendet über den Tag verteilt Tausende kurzer Anfragen. Daher entscheidet der Durchsatz pro Dollar darüber, ob er auf dem eigenen Server betrieben werden kann. Ein Modell, das 40 Sekunden pro Antwort benötigt, ist ein brauchbarer Assistent, aber ein schlechter Agent, da eine Aufgabe zwanzig Aufrufe erfordert und man auf jeden einzelnen warten muss.

NVIDIA beschreibt die Architektur als hybrid: verschachtelte Mamba-2- und MoE-Schichten mit ausgewählten Attention-Schichten. Die Modellkarte gibt eine maximale Kontextlänge von bis zu 1M Token an und eine OpenMDW-1.1-Lizenz, die für die kommerzielle Nutzung freigegeben ist. Die Hauptsprachen sind Englisch und Programmcode; Spanisch, Französisch, Deutsch, Italienisch und Japanisch sind ebenfalls aufgeführt.

Artificial Analysis veröffentlichte im August 2026 Messwerte zum Start, die fast 670 ausgegebene Token pro Sekunde auf einem Pre-Release-DeepInfra-Endpunkt zeigten, der die NVFP4-Gewichte bereitstellte. Dies ist ein gehosteter GPU-Endpunkt. Betrachten Sie dies als das, was die Architektur ermöglicht, nicht als das, was Ihr VPS leisten wird.

Welcher Ollama-Tag passt zu welchem VPS

Die Ollama-Bibliothek veröffentlicht mehrere Builds derselben Gewichte. Der Unterschied liegt in der Quantisierung, also der Anzahl der Bits pro Gewicht, was die Downloadgröße maßgeblich beeinflusst.

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

Die Tags mit den Namen latest, 30b und 30b-a3b verweisen alle auf denselben Digest wie 30b-a3b-q4_K_M. Der Standard-Download ist somit der 25 GB große 4-Bit-Build mit einem Kontext von 1M. Q8_0 ist 35 GB und bf16 ist 66 GB groß, beide ebenfalls mit 1M Kontext. Die MLX-Builds mit 23 GB sind für Apple Silicon optimiert und auf 256K Kontext begrenzt; sie sind daher für einen Linux-VPS die falsche Wahl.

Dies sind Downloadgrößen, keine Speicheranforderungen. NVIDIA veröffentlicht keine Mindestvorgaben für den VRAM (Video-RAM) der Ollama-Builds. Betrachten Sie die Downloadgröße daher lediglich als absolutes Minimum. Die Gewichte müssen im Speicher liegen: im GPU-Speicher, sofern die Karte ausreichend Kapazität bietet, andernfalls im System-RAM. Der KV-Cache (Key/Value-Cache, der speicherintensive Kontext des Modells pro Token) kommt zusätzlich hinzu. Den tatsächlichen Wert für Ihre Hardware ermitteln Sie nicht durch Rechnen, sondern über den unten stehenden Befehl. Falls Sie sich noch nicht für einen Quantisierungsgrad entschieden haben, erläutert welche Kosten Q4, Q8 und FP16 jeweils verursachen, welche Einbußen Sie bei den einzelnen Stufen hinnehmen.

Verwenden Sie immer das exakte Tag, niemals latest

latest ist ein sich ändernder Zeiger. Wenn die Bibliothek das Tag neu veröffentlicht, ändert sich das Verhalten Ihres Agenten beim nächsten Pull, ohne dass Ihre Notizen einen Grund dafür liefern. Benennen Sie das Tag explizit.

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

Das Installationsskript richtet einen systemd-Dienst ein, der als Benutzer ollama ausgeführt wird und Modelle unter /usr/share/ollama/.ollama/models speichert. Dieser Pfad befindet sich auf den meisten VPS-Images auf dem Root-Dateisystem. Prüfen Sie daher den verfügbaren Speicherplatz, bevor Sie 25 GB anfordern. Wenn dieses Dateisystem knapp bemessen ist, lohnt es sich, wo Ollama seine Modelle speichert und wie man sie verschiebt vor dem Pull zu lesen, anstatt erst dann, wenn die Festplatte bereits voll ist.

df -h /usr/share/ollama

Ein Pull, der vorzeitig abbricht und no space left on device meldet, bedeutet genau das. Die unvollständigen Blobs verbleiben auf der Festplatte, bis Sie diese löschen. Überprüfen Sie anschließend, was tatsächlich gespeichert wurde:

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

ollama show gibt die Architektur, die Anzahl der Parameter, die Kontextlänge und die Quantisierung aus, die die Datei tatsächlich enthält. Wenn einer dieser Werte nicht mit der Bibliotheksseite übereinstimmt, haben Sie ein anderes Tag gezogen als beabsichtigt.

Bereitstellung und Überprüfung des tatsächlichen Ausführungsorts

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

Während das Modell geladen ist, führen Sie in einem zweiten Terminal Folgendes aus:

ollama ps

Dieser Befehl beantwortet die Frage nach dem Speicherbedarf für Ihr System. ollama ps gibt das geladene Modell, den belegten Speicherplatz und eine PROCESSOR-Spalte aus. 100% GPU bedeutet, dass sich das Modell vollständig im VRAM befindet. 100% CPU bedeutet, dass sich kein Teil davon im VRAM befindet und jeder Token vom Prozessor aus dem Arbeitsspeicher berechnet wird. Eine Aufteilung wie 65%/35% CPU/GPU bedeutet, dass nicht alle Layer in den VRAM passten; der CPU-Anteil bestimmt in diesem Fall die Geschwindigkeit. Schätzen Sie den Bedarf nicht. Laden Sie das Modell und lesen Sie diese Zeile ab.

Falls das Modell gar nicht geladen werden kann, verweigert Ollama den Dienst sauber, anstatt abzustürzen:

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

Ist ein VPS ohne GPU schnell genug?

Ein VPS für allgemeine Zwecke verfügt über keine GPU. Die CPU übernimmt daher die gesamte Arbeit und liest jedes benötigte Gewicht aus dem Arbeitsspeicher. Hier hilft MoE (Mixture of Experts), da pro Token nur etwa 3 Milliarden der insgesamt 30 Milliarden Parameter verarbeitet werden. Der Rechenaufwand pro Token ist somit deutlich geringer als bei einem dichten 30B-Modell. Der Speicherbedarf bleibt jedoch unverändert. Alle 30 Milliarden Parameter müssen im Arbeitsspeicher resident gehalten werden, da der Router für jedes Token einen beliebigen Experten auswählen kann.

Die Inferenz auf der CPU ist bei diesem Modell daher eher durch die Speicherbandbreite als durch die Anzahl der Kerne begrenzt. Das Hinzufügen weiterer vCPUs zu einem Tarif, der bereits über eine angemessene Anzahl verfügt, bewirkt nur wenig. Sie benötigen ausreichend RAM für die Gewichte sowie den KV-Cache und den schnellsten Arbeitsspeicher, den der Tarif bietet.

Messen Sie die Leistung, bevor Sie einen Agenten darauf einsetzen. Nutzen Sie dazu die Methode unter Messen der Tokens pro Sekunde für ein lokales LLM:

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

Die Zeile eval rate, die am Ende ausgegeben wird, entspricht Ihrer Generierungsgeschwindigkeit in Tokens pro Sekunde. Dieser einzelne Wert entscheidet über die Eignung, da die Wartezeit eines Agenten maßgeblich davon abhängt. Multiplizieren Sie diesen Wert mit der erwarteten Antwortlänge. Ist das Ergebnis länger, als Sie warten möchten, ist Begrenzen der Ausgabe mit num_predict das geeignete Mittel, um einen einzelnen Aufruf zu limitieren, ohne die Hardware zu ändern.

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

Dies sind veröffentlichte Werte von Drittanbietern, umgerechnet aus den von Artificial Analysis zum Start berichteten Minuten pro Aufgabe. Sie wurden auf gehosteten GPU-Endpunkten und nicht auf einem VPS gemessen. Nemotron 3.5 Lightning benötigte durchschnittlich 30 Sekunden pro Aufgabe, wobei gpt-oss-120b etwa 204 und Qwen3.6 35B etwa 210 in Anspruch nahm. Verwenden Sie diese Werte, um das Leistungsgefälle einzuschätzen, nicht als Leistungsgarantie für Ihre Hardware.

Die ehrliche Empfehlung hängt davon ab, wer auf die Ergebnisse wartet. Wenn eine Person auf den Agenten wartet oder der Agent lange Ketten von Aufrufen hintereinander ausführt, mieten Sie GPU-Kapazität. Wenn der Agent nach einem Zeitplan über Nacht läuft und niemand zuschaut, ist ein CPU-Tarif mit viel RAM eine vernünftige Wahl. Die Einrichtung ist in beiden Fällen identisch. Der Artikel Ausführen von Ollama auf einem VPS behandelt die Dimensionierung des Tarifs und den Vergleich zwischen einer GPU-Instanz und der nutzungsbasierten Abrechnung bei einem API-Anbieter. Der Break-even-Punkt ist eine Frage der Auslastung: Eine GPU-Instanz wird stündlich abgerechnet, während API-Tokens nur bei Nutzung anfallen. Ein Agent, der den Großteil des Tages ausgelastet ist, rechtfertigt einen eigenen Server; ein Agent, der nur zweimal pro Stunde aktiv wird, meist nicht.

Das 1M-Kontextfenster ist nicht kostenlos

1M Token sind das Maximum des Modells, und Ollama stellt Ihnen diese nicht standardmäßig zur Verfügung. Ollama verwendet ein deutlich kleineres Standardfenster und verwirft die ältesten Token, sobald eine Konversation diese Grenze überschreitet. Wenn dies geschieht, wird nichts protokolliert; für einen Agenten sieht es daher so aus, als würde das Modell den Anfang seiner eigenen Aufgabe vergessen.

Legen Sie das Fenster gezielt fest. Bearbeiten Sie für den gesamten Server den Dienst:

sudo systemctl edit ollama

Fügen Sie dies hinzu und führen Sie anschließend sudo systemctl restart ollama aus:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Senden Sie pro Anfrage stattdessen num_ctx im options-Objekt:

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
}'

Jede Erhöhung kostet Arbeitsspeicher, da der KV-Cache mit der Anzahl der erlaubten Token wächst. Erhöhen Sie den Wert, starten Sie neu, führen Sie dann ollama ps erneut aus und beobachten Sie, wie die angezeigte Größe steigt. Wenn die Spalte PROCESSOR nach dieser Änderung von 100% GPU auf einen Split wechselt, hat der KV-Cache Modellschichten aus dem VRAM verdrängt und Ihre Geschwindigkeit wird stark abfallen. Wahl von num_ctx in Ollama erläutert diesen Kompromiss im Detail. Setzen Sie den Wert nicht auf 1000000, nur weil die Modellkarte dies zulässt, da die Zuweisung im Voraus erfolgt und der Ladevorgang andernfalls einfach fehlschlägt.

Einbindung in einen dauerhaft aktiven Agenten

Der Ankündigungsbeitrag von Ollama für dieses Modell dokumentiert eine Abkürzung, die einen unterstützten Agenten startet, der bereits auf das Modell ausgerichtet ist:

ollama launch claude --model nemotron-3.5-lightning

Der Beitrag dokumentiert claude, opencode, openclaw und hermes an dieser Stelle. Der Unterbefehl erfordert eine aktuelle Version von Ollama. Prüfen Sie daher zuerst ollama --version. Falls dieser fehlt, konfigurieren Sie den Agenten manuell auf die API. Ollama stellt einen OpenAI-kompatiblen Endpunkt bereit, den die meisten Agenten-Frameworks akzeptieren:

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

Ollama ignoriert den Schlüssel, aber die meisten Clients verweigern den Start, wenn kein Schlüssel gesetzt ist. Die Client-Seite wird unter einen Coding-Agenten auf Ollama ausrichten und unter einen eigenen OpenClaw-Agenten bauen behandelt.

Zwei Servereinstellungen sind wichtig, sobald der Agent unbeaufsichtigt läuft. OLLAMA_KEEP_ALIVE steuert, wie lange ein Modell nach der letzten Anfrage im Arbeitsspeicher verbleibt. Der Standardwert entlädt das Modell nach fünf Minuten, sodass der nächste Aufruf die volle Ladezeit in Anspruch nimmt. Bei einer 25 GB großen Datei ohne GPU ist diese Pause lang genug, um einen Timeout auszulösen. Setzen Sie OLLAMA_KEEP_ALIVE=-1, um das Modell im Speicher zu halten. OLLAMA_HOST=0.0.0.0:11434 macht die API von anderen Rechnern aus erreichbar. Da diese keinerlei Authentifizierung bietet, sollte sie nur hinter einer Firewall-Regel oder in einem privaten Netzwerk geöffnet werden.

Fehlermodi und die zugehörigen Meldungen

Der Pull-Vorgang schlägt sofort fehl. Error: pull model manifest: file does not exist bedeutet, dass das Tag nicht existiert. Tag-Namen sind exakte Zeichenfolgen; kopieren Sie diese daher von der Bibliotheksseite, anstatt ein Quantisierungs-Suffix zu erraten.

Das Modell lädt nicht. Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) bedeutet, dass das Tag für die aktuelle Konfiguration des Plans zu groß ist. Wechseln Sie zu einer kleineren Quantisierung oder verringern Sie OLLAMA_CONTEXT_LENGTH, da der KV-Cache in diese Anforderung einberechnet wird.

Auf Port 11434 antwortet niemand. curl: (7) Failed to connect to localhost port 11434 bedeutet, dass der Dienst nicht läuft oder nicht auf dem erwarteten Port lauscht. Lesen Sie systemctl status ollama und journalctl -u ollama -n 50. Falls Sie ollama serve zusätzlich manuell gestartet haben, beendet sich die zweite Instanz mit Error: listen tcp 127.0.0.1:11434: bind: address already in use.

Die Antwort erfolgt sehr langsam. Prüfen Sie ollama ps, bevor Sie Änderungen vornehmen. Jeder CPU-Anteil in der Spalte PROCESSOR auf einer GPU-Maschine bedeutet, dass ein Teil des Modells aus dem VRAM ausgelagert wurde. Verringern Sie in diesem Fall den Kontext oder wählen Sie die kleinere Quantisierung. Auf einer Maschine ohne GPU ist eine langsame Ausführung zu erwarten; keine Einstellung kann dies beheben.

Der Agent vergisst seine Anweisungen während einer Aufgabe. Das Gespräch hat das Kontextfenster überschritten und die ältesten Token wurden lautlos verworfen. Erhöhen Sie OLLAMA_CONTEXT_LENGTH und bestätigen Sie mit ollama ps, dass das Modell weiterhin in den Speicher passt. Falls dies nicht mehr der Fall ist, ist eine leistungsfähigere Maschine die Lösung, nicht ein kleineres Fenster.

Einordnung dieses Modells im Vergleich zu Alternativen

Ein 30B MoE ist für eine kleine Aufgabe ein sehr umfangreiches Modell. Wenn ein dichtes 8B-Modell Ihre Aufgabe bereits bewältigt, ist der Betrieb deutlich kostengünstiger und das Laden erfolgt in Sekunden. Qwen 3 mit 8B und 27B auf einem VPS bietet den direkten Vergleich für diese Entscheidung. Für einen umfassenderen Überblick darüber, welche Modelle auf einem bestimmten Plan tatsächlich ausführbar sind, beginnen Sie mit welche KI-Modelle Sie selbst hosten können. Wenn Sie planen, mehrere Agenten gleichzeitig statt nur einen zu bedienen, lesen Sie zuerst Ollama im Vergleich zu vLLM. Ollama verarbeitet gleichzeitige Anfragen nicht in Batches wie ein produktiver Inference-Server; genau hier stößt ein Setup für Einzelnutzer an seine Skalierungsgrenzen.

FAQ

Welchen Nemotron 3.5 Lightning-Tag sollte ich auf einem Linux-VPS ziehen?

Verwenden Sie nemotron-3.5-lightning:30b-a3b-q4_K_M. Er ist 25 GB groß, unterstützt das volle 1M-Kontextfenster und entspricht dem Digest, auf den die Tags latest, 30b und 30b-a3b mit Stand August 2026 verweisen. Geben Sie den Tag explizit an, anstatt latest zu ziehen, damit eine zukünftige Aktualisierung dieses Pointers das Verhalten Ihres Agenten nicht unbemerkt verändert. Die mlx-Tags sind Builds für Apple Silicon und funktionieren unter Linux nicht.

Wie viel RAM benötigt Nemotron 3.5 Lightning?

NVIDIA veröffentlicht keine Mindestanforderungen für die Ollama-Builds, daher sollten Sie den Bedarf messen, statt ihn zu schätzen. Ziehen Sie den Tag, führen Sie das Modell einmal aus und lesen Sie ollama ps aus, während es geladen ist: Der Befehl zeigt den tatsächlich belegten Speicherplatz an und ob das Modell auf der GPU oder der CPU liegt. Die Download-Größe von 25 GB für den Standard-Tag ist lediglich das Minimum, da der KV-Cache hinzukommt und mit dem von Ihnen festgelegten Kontextfenster wächst. Ist der Plan zu klein, verweigert Ollama den Dienst mit model requires more system memory und nennt beide Werte.

Kann ich Nemotron 3.5 Lightning auf einem VPS ohne GPU ausführen?

Ja, sofern der Plan über genügend RAM verfügt, um die Gewichte zu halten. Das MoE-Design ist hierbei hilfreich, da pro Token nur etwa 3 der 30 Milliarden Parameter berechnet werden. Der Haken ist die Geschwindigkeit. Ohne GPU ist das Modell durch die Speicherbandbreite limitiert, weshalb zusätzliche vCPUs die Leistung kaum steigern. Führen Sie ollama run --verbose mit einem festen Prompt aus, lesen Sie die Zeile eval rate und vergleichen Sie diesen Wert mit den Anforderungen Ihres Agenten. Für Batch-Jobs über Nacht ist dies oft ausreichend. Für interaktive Anwendungen, bei denen ein Benutzer auf eine Antwort wartet, meist nicht.

Warum bietet mir Ollama nicht das volle 1M-Kontextfenster?

1M ist das Maximum des Modells, nicht der Standardwert von Ollama. Ollama verwendet ein deutlich kleineres Fenster und verwirft die ältesten Token, sobald eine Konversation dieses überschreitet. Dies geschieht ohne Fehlermeldung und führt dazu, dass der Agent seine eigenen Anweisungen „vergisst“. Setzen Sie OLLAMA_CONTEXT_LENGTH im systemd-Service oder übergeben Sie num_ctx pro Anfrage. Erhöhen Sie den Wert schrittweise und prüfen Sie jeweils ollama ps, da der Speicherbedarf des KV-Cache mit dem Fenster skaliert und Modellschichten von der GPU verdrängen kann.

Ist Nemotron 3.5 Lightning für die kommerzielle Nutzung kostenlos?

Die Model Card von NVIDIA ordnet das Modell unter der OpenMDW-1.1-Lizenz ein und kennzeichnet es als für die kommerzielle Nutzung geeignet. Dies deckt die Gewichte ab, die Sie herunterladen und selbst ausführen. Dies trifft jedoch keine Aussage über die übrige Software in Ihrem Stack. Prüfen Sie daher die Lizenzen des Agent-Frameworks und aller angebundenen Tools separat und lesen Sie die aktuelle Model Card, bevor Sie sich für vertragliche Zwecke darauf verlassen.