Nemotron 3.5 Lightning mit Ollama auf einem VPS

Wof Nemotron 3.5 Lightning gedacht ist

Nemotron 3.5 Lightning ist das offene 30B-Mixture-of-Experts-Modell von NVIDIA. Es wurde im August 2026 veröffentlicht und ist für Agents ausgelegt, die stundenlang laufen, statt nur in einem Chatfenster eingesetzt zu werden. MoE (Mixture of Experts) bedeutet, dass die Gewichte auf viele Experten-Teilnetze verteilt werden und jedes Token nur durch einige davon geleitet wird. Laut Model Card verfügt das Modell über insgesamt 30 Milliarden Parameter, von denen pro Token 3 Milliarden aktiv sind. Im Arbeitsspeicher müssen Sie die große Zahl vorhalten. Bei der Geschwindigkeit profitieren Sie von der kleinen Zahl.

Dieser Kompromiss ist der Grund, warum sich das Modell für einen gemieteten Server eignet. Ein Agent, der echte Aufgaben bearbeitet, sendet im Laufe eines Tages Tausende kurze Anfragen. Daher entscheidet der Durchsatz pro Dollar darüber, ob der Betrieb auf dem eigenen Server praktikabel ist. Ein Modell, das 40 Sekunden pro Antwort benötigt, ist ein brauchbarer Assistent, aber ein schlechter Agent. Eine Aufgabe erzeugt möglicherweise 20 Aufrufe, und Sie müssen auf jeden einzelnen warten.

NVIDIA beschreibt die Architektur als hybrid. Sie kombiniert abwechselnd Mamba-2- und MoE-Schichten mit ausgewählten Attention-Schichten. Laut Model Card unterstützt das Modell eine maximale Kontextlänge von bis zu 1M Tokens und steht unter der OpenMDW-1.1-Lizenz. Diese ist für die kommerzielle Nutzung freigegeben. Als primäre Sprachen sind Englisch und Code angegeben. Zusätzlich werden Spanisch, Französisch, Deutsch, Italienisch und Japanisch aufgeführt.

Artificial Analysis veröffentlichte im August 2026 Messwerte zum Start. Diese zeigten nahezu 670 ausgegebene Tokens pro Sekunde auf einem DeepInfra-Endpunkt vor der offiziellen Veröffentlichung, der die NVFP4-Gewichte bereitstellte. Dabei handelt es sich um einen gehosteten GPU-Endpunkt. Die Werte zeigen, was die Architektur ermöglicht, nicht, welche Leistung Ihr VPS erreichen wird.

Welcher Ollama-Tag passt zu welchem VPS

Die Ollama-Bibliothek veröffentlicht mehrere Builds mit denselben Gewichten. Der Unterschied liegt in der Quantisierung, also darin, mit wie vielen Bits jedes Gewicht gespeichert wird. Dadurch ändert sich die Download-Größe erheblich.

[
  {
    "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 latest, 30b und 30b-a3b verweisen alle auf denselben Digest wie 30b-a3b-q4_K_M. Der Standard-Download ist daher der 25 GB große Vier-Bit-Build mit dem vollständigen 1M-Kontext. Q8_0 ist 35 GB groß, bf16 66 GB. Beide unterstützen ebenfalls 1M Kontext. Die MLX-Builds mit 23 GB sind für Apple Silicon vorgesehen und auf einen Kontext von 256K begrenzt. Für einen Linux-VPS sind sie daher die falsche Wahl.

Das sind Download-Größen, keine Angaben zum erforderlichen Speicher. NVIDIA veröffentlicht für die Ollama-Builds keine Mindestangabe zum VRAM (Videospeicher). Betrachten Sie die Download-Größe daher nur als Untergrenze. Die Gewichte müssen vollständig an einem Ort im Speicher liegen. Wenn die Grafikkarte sie aufnehmen kann, liegen sie im GPU-Speicher. Andernfalls liegen sie im System-RAM. Zusätzlich kommt der KV-Cache (Key/Value-Cache, der tokenweise Modellspeicher für die Unterhaltung) hinzu. Der tatsächliche Wert für Ihre Hardware ergibt sich aus einem Befehl, nicht aus einer Berechnung. Dieser Befehl folgt weiter unten. Wenn Sie sich noch nicht für eine Quantisierungsstufe entschieden haben, erklärt welche Kosten bei Q4, Q8 und FP16 jeweils entstehen, was Sie bei jedem Schritt aufgeben.

Den exakten Tag abrufen, niemals latest

latest ist ein veränderlicher Verweis. Wenn die Bibliothek ihn neu veröffentlicht, ändert sich das Verhalten Ihres Agents beim nächsten Abruf, ohne dass Ihre Notizen den Grund erkennen lassen. Geben Sie den Tag ausdrücklich an.

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 liegt bei den meisten VPS-Images auf dem Root-Dateisystem. Prüfen Sie daher den verfügbaren Speicherplatz, bevor Sie 25 GB anfordern.

df -h /usr/share/ollama

Wenn ein Abruf mittendrin stoppt und no space left on device meldet, bedeutet das genau diesen Zustand. Die teilweise heruntergeladenen Blobs bleiben auf der Festplatte, bis Sie sie löschen. Prü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 tatsächlich in der Datei enthalten sind. Wenn einer dieser Werte von der Bibliotheksseite abweicht, haben Sie einen anderen Tag abgerufen als beabsichtigt.

Starten Sie es und prüfen Sie, wo es tatsächlich ausgeführt wurde

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 noch geladen ist, öffnen Sie eine zweite Shell:

ollama ps

Mit diesem Befehl beantworten Sie die Speicherfrage für Ihr System. ollama ps gibt das geladene Modell, den belegten Speicher und eine Spalte PROCESSOR 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 jedes Token vom Prozessor aus dem Arbeitsspeicher berechnet wird. Ein Wert wie 65%/35% CPU/GPU bedeutet, dass nicht alle Layer in den VRAM passten. Der CPU-Anteil bestimmt dann die Geschwindigkeit. Schätzen Sie den Bedarf nicht. Laden Sie das Modell und lesen Sie diese Zeile.

Wenn das Modell überhaupt nicht geladen werden kann, bricht Ollama den Vorgang kontrolliert ab, anstatt abzustürzen:

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

Ist ein VPS nur mit CPU schnell genug?

Ein VPS für allgemeine Zwecke hat keine GPU. Daher übernimmt die CPU die gesamte Verarbeitung und liest jedes benötigte Gewicht aus dem System-RAM. MoE hilft dabei, weil pro Token nur etwa 3 Milliarden der 30 Milliarden Parameter verwendet werden. Dadurch ist der Rechenaufwand pro Token deutlich geringer als bei einem dichten 30B-Modell. Beim Speicherbedarf hilft das überhaupt nicht. Alle 30 Milliarden Parameter müssen im Speicher resident bleiben, weil der Router für jedes Token einen beliebigen Expert auswählen kann.

Die Inferenz dieses Modells ist daher auf einem System nur mit CPU durch die Speicherbandbreite und nicht durch die Anzahl der Kerne begrenzt. Wenn ein Plan bereits über eine angemessene Anzahl an vCPUs verfügt, bringt das Hinzufügen weiterer vCPUs nur wenig. Sie benötigen genügend RAM für die Gewichte und den KV-Cache sowie den schnellsten Speicher, den der Plan bereitstellt.

Messen Sie die Geschwindigkeit, bevor Sie einen Agenten darauf ausführen. Verwenden Sie dazu die Methode unter Tokens pro Sekunde für ein lokales LLM messen:

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

Die am Ende ausgegebene Zeile eval rate enthält die Generierungsgeschwindigkeit in Tokens pro Sekunde. Diese eine Zahl beantwortet die Frage, weil die Wandzeit eines Agenten hauptsächlich davon bestimmt wird.

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

Das sind veröffentlichte Werte von Drittanbietern. Sie wurden aus den von Artificial Analysis beim Start gemeldeten Minuten pro Aufgabe umgerechnet und auf gehosteten GPU-Endpunkten statt auf einem VPS gemessen. Nemotron 3.5 Lightning benötigte im Durchschnitt etwa 30 Sekunden pro Aufgabe. Dabei dauerte gpt-oss-120b ungefähr 204 und Qwen3.6 35B ungefähr 210. Verwenden Sie diese Werte, um die Größenordnung des Abstands einzuschätzen, nicht als Zusage für Ihre Hardware.

Die sachliche Empfehlung hängt davon ab, wer wartet. Wenn eine Person auf den Agenten wartet oder der Agent lange Aufrufketten ohne Pause ausführt, mieten Sie GPU-Kapazität. Wenn der Agent nachts nach einem Zeitplan läuft und niemand ihn beobachtet, ist ein CPU-Plan mit viel RAM eine sinnvolle Lösung. Die Einrichtung ist in beiden Fällen gleich. Ollama auf einem VPS ausführen behandelt die Dimensionierung des Plans und den Vergleich einer GPU-Instanz mit der Abrechnung eines API-Anbieters pro Token. Die Gewinnschwelle hängt von der Auslastung ab: Eine GPU-Instanz wird für jede Stunde abgerechnet, in der sie existiert. API-Tokens werden dagegen nur bei ihrer Verwendung abgerechnet. Ein Agent, der den größten Teil des Tages ausgelastet ist, spricht daher für einen eigenen Server. Ein Agent, der zweimal pro Stunde gestartet wird, spricht in der Regel nicht dafür.

Das 1M-Kontextfenster ist nicht kostenlos

1M Tokens entsprechen dem Maximum des Modells, aber Ollama stellt dieses Fenster nicht standardmäßig bereit. Ollama verwendet standardmäßig ein deutlich kleineres Fenster und verwirft die ältesten Tokens, sobald eine Unterhaltung dieses Fenster überschreitet. Dabei 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 die Fenstergröße bewusst fest. Für den gesamten Server bearbeiten Sie den Dienst:

sudo systemctl edit ollama

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

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Pro Anfrage übergeben Sie stattdessen num_ctx im Optionsobjekt:

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 benötigt mehr Arbeitsspeicher, weil der KV-Cache mit der Anzahl der zugelassenen Tokens wächst. Erhöhen Sie den Wert, starten Sie den Dienst neu und führen Sie anschließend erneut ollama ps aus. Beobachten Sie dabei, wie die angezeigte Größe steigt. Wenn die Spalte PROCESSOR nach der Änderung von 100% GPU auf eine Aufteilung wechselt, hat der KV-Cache Modellschichten aus dem VRAM verdrängt. Ihre Geschwindigkeit sinkt dann deutlich. Die Auswahl von num_ctx in Ollama erläutert diesen Zielkonflikt ausführlich. Setzen Sie den Wert nicht einfach auf 1000000, nur weil die Modellkarte dies zulässt. Die Speicherzuweisung erfolgt beim Start, und das Laden schlägt dann einfach fehl.

Integration in einen dauerhaft laufenden Agent

Ollamas Ankündigung zu diesem Modell dokumentiert eine Kurzform, die einen unterstützten Agent startet und ihn bereits auf das Modell ausrichtet:

ollama launch claude --model nemotron-3.5-lightning

Die Ankündigung dokumentiert claude, opencode, openclaw und hermes an dieser Stelle. Das Subcommand benötigt eine aktuelle Ollama-Version. Prüfen Sie daher zuerst ollama --version. Falls es fehlt, konfigurieren Sie den Agent selbst für die API. Ollama stellt einen mit OpenAI kompatiblen Endpunkt bereit, den die meisten Agent-Frameworks akzeptieren:

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

Ollama ignoriert den Schlüssel. Die meisten Clients starten jedoch nicht, wenn kein Schlüssel gesetzt ist. Die Konfiguration auf Framework-Seite wird unter einen Coding-Agent auf Ollama ausrichten und einen eigenen OpenClaw-Agent erstellen beschrieben.

Sobald der Agent unbeaufsichtigt läuft, sind zwei Servereinstellungen relevant. OLLAMA_KEEP_ALIVE legt fest, wie lange ein Modell nach der letzten Anfrage im Speicher bleibt. Standardmäßig wird es nach fünf Minuten entladen. Der nächste Aufruf benötigt dann erneut die vollständige Ladezeit. Bei einer Datei mit 25 GB kann diese Pause ohne GPU lang genug sein, um einen Timeout auszulösen. Setzen Sie OLLAMA_KEEP_ALIVE=-1, damit das Modell im Speicher bleibt. OLLAMA_HOST=0.0.0.0:11434 macht die API von anderen Rechnern aus erreichbar. Die API bietet keinerlei Authentifizierung. Öffnen Sie sie daher nur über eine Firewall-Regel oder in einem privaten Netzwerk.

Fehlerbilder und die dabei angezeigten Meldungen

Der Pull-Vorgang schlägt sofort fehl. Error: pull model manifest: file does not exist bedeutet, dass dieser Tag nicht existiert. Tagnamen sind exakte Zeichenfolgen. Übernehmen Sie daher einen Namen von der Bibliotheksseite, statt ein Quantisierungs-Suffix zu erraten.

Das Modell lässt sich nicht laden. Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) bedeutet, dass der Tag in der aktuellen Konfiguration zu groß für diesen Plan ist. Verwenden Sie eine kleinere Quantisierung oder reduzieren Sie OLLAMA_CONTEXT_LENGTH, da der KV-Cache in diese Anforderung einberechnet wird.

Auf Port 11434 antwortet nichts. curl: (7) Failed to connect to localhost port 11434 bedeutet, dass der Dienst nicht ausgeführt wird oder nicht an der erwarteten Adresse lauscht. Lesen Sie systemctl status ollama und journalctl -u ollama -n 50. Wenn Sie außerdem ollama serve manuell gestartet haben, beendet sich die zweite Instanz mit Error: listen tcp 127.0.0.1:11434: bind: address already in use.

Der Dienst antwortet, aber sehr langsam. Prüfen Sie ollama ps, bevor Sie etwas ändern. Jeder CPU-Anteil in der Spalte PROCESSOR auf einem Rechner mit GPU bedeutet, dass ein Teil des Modells aus dem VRAM ausgelagert wurde. Reduzieren Sie daher den Kontext oder verwenden Sie die kleinere Quantisierung. Auf einem Rechner ohne GPU ist eine langsame Verarbeitung zu erwarten. Keine Einstellung kann das beheben.

Der Agent vergisst während einer Aufgabe seine Anweisungen. Die Unterhaltung hat das Kontextfenster überschritten, und die ältesten Tokens wurden stillschweigend verworfen. Erhöhen Sie OLLAMA_CONTEXT_LENGTH. Bestätigen Sie mit ollama ps, dass das Modell weiterhin in den verfügbaren Speicher passt. Falls dies nicht mehr der Fall ist, benötigen Sie einen größeren Rechner und kein kleineres Kontextfenster.

Einordnung dieses Modells im Vergleich zu den Alternativen

Ein 30B-MoE-Modell ist für eine kleine Aufgabe aufwendig zu hosten. Wenn ein dichtes 8B-Modell Ihre Aufgabe bereits bewältigt, verursacht es im Betrieb deutlich geringere Kosten und ist in wenigen Sekunden geladen. Qwen 3 mit 8B und 27B auf einem VPS ist der direkte Vergleich für diese Entscheidung. Einen breiteren Überblick darüber, welche Modelle ein bestimmter Tarif tatsächlich aufnehmen kann, finden Sie unter welche AI-Modelle Sie selbst hosten können. Wenn Sie mehrere Agents gleichzeitig statt nur eines bereitstellen möchten, lesen Sie zuerst Ollama im Vergleich zu vLLM. Ollama bündelt gleichzeitige Anfragen nicht wie ein produktiver Inferenzserver. An diesem Punkt skaliert eine Einzelbenutzerumgebung nicht weiter.

FAQ

Welches Nemotron-3.5-Lightning-Tag sollte ich auf einem Linux-VPS herunterladen?

Verwenden Sie nemotron-3.5-lightning:30b-a3b-q4_K_M. Es ist 25 GB groß, enthält den vollständigen maximalen Kontext von 1M und verwendet seit August 2026 denselben Digest, auf den auch die Tags latest, 30b und 30b-a3b verweisen. Geben Sie den Namen explizit an, statt latest herunterzuladen. Dadurch kann eine spätere Neuveröffentlichung dieses Zeigers das Verhalten Ihres Agenten nicht unbemerkt ändern. Die Tags mlx sind Builds für Apple Silicon und helfen Ihnen unter Linux nicht.

Wie viel RAM benötigt Nemotron 3.5 Lightning?

NVIDIA veröffentlicht keine Mindestangabe zum Speicherbedarf der Ollama-Builds. Messen Sie daher statt zu schätzen. Laden Sie den Tag herunter, führen Sie das Modell einmal aus und lesen Sie ollama ps, während es geladen ist. Die Ausgabe zeigt die tatsächlich belegte Größe und ob das Modell auf der GPU oder der CPU ausgeführt wird. Die Downloadgröße von 25 GB für den Standard-Tag ist nur der Mindestwert, weil zusätzlich der KV-Cache belegt wird und mit dem von Ihnen festgelegten Kontextfenster wächst. Ist der Plan zu klein, verweigert Ollama den Start 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 genügend RAM für die Gewichte bereitstellt. Die MoE-Architektur hilft dabei, weil pro Token nur etwa 3 der 30 Milliarden Parameter berechnet werden. Der Nachteil ist die Geschwindigkeit. Ohne GPU ist das Modell durch die Speicherbandbreite begrenzt. Zusätzliche vCPUs verbessern das Ergebnis daher kaum. Führen Sie ollama run --verbose mit einem festgelegten Prompt aus, lesen Sie die Zeile eval rate und vergleichen Sie diesen Wert mit dem Zeitlimit Ihres Agenten. Für einen Batch-Job über Nacht ist das häufig ausreichend. Für alles, worauf eine Person wartet, reicht es normalerweise nicht.

Warum stellt Ollama nicht das vollständige Kontextfenster von 1M bereit?

1M ist das Maximum des Modells, nicht der Standardwert von Ollama. Ollama verwendet ein deutlich kleineres Fenster und verwirft die ältesten Tokens, sobald eine Unterhaltung dieses Fenster überschreitet. Dabei wird kein Fehler ausgegeben. Dadurch entsteht der Eindruck, dass der Agent seine eigenen Anweisungen vergessen hat. Setzen Sie OLLAMA_CONTEXT_LENGTH für den systemd-Dienst oder übergeben Sie num_ctx für einzelne Anfragen. Erhöhen Sie den Wert schrittweise und prüfen Sie jedes Mal erneut ollama ps. Der Speicherbedarf des KV-Caches skaliert mit der Fenstergröße und kann Modellschichten von der GPU in den Hauptspeicher verschieben.

Darf Nemotron 3.5 Lightning kommerziell kostenlos verwendet werden?

Die Model Card von NVIDIA stellt das Modell unter die Lizenz OpenMDW-1.1 und kennzeichnet es als für die kommerzielle Nutzung geeignet. Das gilt für die Gewichte, die Sie selbst herunterladen und ausführen. Über die andere Software in Ihrem Stack sagt die Lizenz nichts aus. Prüfen Sie daher die Lizenzen des Agenten-Harnesses und aller Tools, die Sie damit verbinden, separat. Lesen Sie außerdem die aktuelle Model Card, bevor Sie sich bei vertraglich relevanten Vorhaben darauf verlassen.