Patakbuhin ang Nemotron 3.5 Lightning sa VPS

Para saan ang Nemotron 3.5 Lightning

Ang Nemotron 3.5 Lightning ay open 30B mixture-of-experts model ng NVIDIA, na inilabas noong August 2026. Dinisenyo ito para sa mga agent na tumatakbo nang ilang oras, hindi lang sa isang chat window. Ang MoE (mixture of experts) ay nangangahulugang hinahati ang weights sa maraming expert sub-network, at ilang sub-network lamang ang dinaraanan ng bawat token. Ayon sa model card ng NVIDIA, mayroon itong 30 billion total parameters at 3 billion active parameter bawat token. Ang malaking bilang ang kumokonsumo ng memory. Ang maliit na bilang naman ang nagbibigay ng bilis.

Ito ang dahilan kung bakit sulit isaalang-alang ang model na ito para sa server na nirerentahan mo. Ang agent na gumagawa ng aktuwal na trabaho ay nagpapadala ng libo-libong maiikling request sa loob ng isang araw. Kaya ang throughput kada dollar ang nagtatakda kung praktikal itong patakbuhin sa sarili mong server. Ang model na tumatagal ng 40 segundo bawat reply ay kapaki-pakinabang na assistant pero hindi mahusay na agent, dahil ang isang task ay maaaring mangailangan ng dalawampung call at kailangan mong hintayin ang bawat isa.

Inilalarawan ng NVIDIA ang architecture bilang hybrid: magkakahalong Mamba-2 at MoE layers, na may ilang select attention layers. Ayon sa model card, umaabot sa 1M tokens ang maximum context length, at gumagamit ito ng OpenMDW-1.1 license na nakamarkang handa para sa commercial use. Pangunahing wika nito ang English at code. Nakalista rin ang Spanish, French, German, Italian, at Japanese.

Naglabas ang Artificial Analysis ng mga sukat sa performance noong August 2026. Ipinakita ng mga ito ang halos 670 output tokens kada segundo sa isang pre-release DeepInfra endpoint na nagsisilbi sa NVFP4 weights. Hosted GPU endpoint iyon. Ituring ang resulta bilang indikasyon ng kayang ibigay ng architecture, hindi bilang inaasahang performance ng VPS mo.

Aling Ollama tag ang angkop sa bawat VPS

Naglalabas ang Ollama library ng ilang build na gumagamit ng parehong weights. Ang nagkakaiba sa mga ito ay ang quantisation, o kung ilang bits ang ginagamit sa pag-store ng bawat weight. Malaki ang epekto nito sa download size.

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

Ang mga tag na latest, 30b at 30b-a3b ay tumutukoy lahat sa parehong digest gaya ng 30b-a3b-q4_K_M. Samakatuwid, ang default download ay ang 25 GB four-bit build na may buong 1M context. Ang Q8_0 ay 35 GB at ang bf16 ay 66 GB. Pareho silang may 1M context. Ang MLX build na 23 GB ay para sa Apple silicon at hanggang 256K context lamang. Kaya maling piliin ang mga ito sa Linux VPS.

Download size ang mga numerong ito, hindi memory requirement. Walang inilalabas na minimum VRAM (video RAM) figure ang NVIDIA para sa Ollama builds. Ituring ang download size bilang minimum na panimulang halaga lamang. Kailangang manatili sa memory ang weights: sa GPU memory kung sapat ang kapasidad ng card, at sa system RAM kung hindi. Idinadagdag pa rito ang KV cache (key/value cache, ang memory ng model para sa bawat token ng conversation). Makukuha sa command ang aktuwal na bilang para sa hardware mo, hindi sa simpleng computation. Nasa ibaba ang command na iyon. Kung hindi ka pa nakapipili ng quantisation level, ipinapaliwanag sa kung magkano ang kapalit ng Q4, Q8 at FP16 sa bawat hakbang.

Tukuyin ang eksaktong tag, huwag ang latest

Ang latest ay isang gumagalaw na pointer. Kapag muli itong nag-publish ng library, magbabago ang behavior ng agent sa susunod na pull kahit walang tala sa iyong notes na nagpapaliwanag kung bakit. Tukuyin ang tag.

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

Nagse-set up ang install script ng systemd service na tumatakbo bilang user na ollama at nag-iimbak ng mga model sa /usr/share/ollama/.ollama/models. Nasa root filesystem ang path na iyon sa karamihan ng VPS image, kaya tiyaking may sapat na espasyo bago humingi ng 25 GB.

df -h /usr/share/ollama

Ang pull na humihinto sa kalagitnaan at nag-uulat ng no space left on device ay eksaktong nangangahulugan niyan, at nananatili sa disk ang partial blobs hanggang sa tanggalin mo ang mga ito. Pagkatapos, kumpirmahin kung ano ang na-download:

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

Ipinapakita ng ollama show ang architecture, bilang ng parameter, haba ng context, at quantisation na aktuwal na nasa file. Kung may hindi tumugma sa library page, ibang tag ang na-pull mo kaysa sa nilayon mo.

I-serve ito, at tingnan kung saan talaga ito tumakbo

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

Habang naka-load pa ang model, magbukas ng pangalawang shell:

ollama ps

Ito ang command na sumasagot sa tanong tungkol sa memory para sa machine mo. Ipinapakita ng ollama ps ang naka-load na model, ang laki ng memory na ginagamit nito, at isang column na PROCESSOR. Ibig sabihin ng 100% GPU ay nasa VRAM ang lahat ng ito. Ibig sabihin ng 100% CPU ay wala itong nasa VRAM, at kino-compute ng processor ang bawat token gamit ang system RAM. Ang split na gaya ng 65%/35% CPU/GPU ay nangangahulugang hindi nagkasya ang lahat ng layer, at ang CPU share ang nagtatakda ng bilis. Huwag tantiyahin ang requirement. I-load ito at basahin ang linyang ito.

Kung hindi ito ma-load, maayos na tumatanggi ang Ollama sa halip na mag-crash:

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

Sapat na ba ang CPU-only VPS?

Walang GPU ang general purpose VPS, kaya CPU ang gumagawa ng lahat ng computation at binabasa nito mula sa system RAM ang bawat weight na kailangan nito. Nakakatulong ang MoE rito dahil humigit-kumulang 3 bilyon lamang sa 30 bilyong parameter ang ginagamit sa bawat token. Dahil dito, mas maliit nang malaki ang arithmetic na kailangan sa bawat token kumpara sa isang dense na 30B model. Hindi naman nakakatulong ang MoE sa memory. Kailangang manatili sa memory ang lahat ng 30 bilyong parameter dahil maaaring pumili ang router ng anumang expert para sa anumang token.

Kaya ang CPU-only inference sa model na ito ay nalilimitahan ng memory bandwidth, hindi ng bilang ng core. Kaunti lamang ang pagbabago kapag nagdagdag ka ng vCPU sa isang plan na mayroon nang sapat na bilang ng mga ito. Kailangan mo ng sapat na RAM para magkasya ang weights at ang KV cache, pati na ang pinakamabilis na memory na iniaalok ng plan.

Sukatin muna ito bago mo gamitin ang model para sa isang agent, gamit ang paraang nasa pagsukat ng tokens per second para sa isang local LLM:

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

Ang linyang eval rate na naka-print sa dulo ang generation speed mo sa tokens per second. Ang iisang numerong ito ang sumasagot sa tanong dahil ang wall-clock time ng isang agent ay pangunahing nakadepende rito.

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

Mga published figure ito mula sa third party. Kinonvert ang mga ito mula sa per-task minutes na iniulat ng Artificial Analysis noong launch, at sinukat ang mga ito sa hosted GPU endpoints sa halip na sa isang VPS. Nakakuha ang Nemotron 3.5 Lightning ng average na humigit-kumulang 30 segundo bawat task. Sa halagang ito, ang gpt-oss-120b ay tumagal nang humigit-kumulang 204, habang ang Qwen3.6 35B ay tumagal nang humigit-kumulang 210. Gamitin ang mga ito upang makita ang laki ng agwat, hindi bilang garantiya para sa hardware mo.

Nakadepende ang tamang payo sa kung sino ang naghihintay. Kung may taong naghihintay sa agent, o sunod-sunod itong gumagawa ng mahahabang chain ng calls, mag-rent ng GPU capacity. Kung naka-schedule itong tumakbo magdamag at walang nagbabantay, makatuwirang gamitin ang isang CPU plan na may malaking RAM. Pareho pa rin ang setup sa alinmang opsyon, at tinatalakay sa pagpapatakbo ng Ollama sa isang VPS ang pag-size ng plan at kung paano ikinukumpara ang isang GPU instance sa pagbabayad sa isang API provider kada token. Ang break-even ay usapin ng utilisation: sinisingil ang GPU instance sa bawat oras na umiiral ito, samantalang sinisingil ang API tokens kapag ginagamit lamang. Kaya mas angkop ang sariling server sa agent na abala halos buong araw, habang karaniwang hindi ito angkop sa agent na tumatakbo dalawang beses bawat oras.

Hindi libre ang 1M context window

Ang 1M tokens ang maximum ng model, at hindi ito awtomatikong ibinibigay sa iyo ng Ollama. Mas maliit na default window ang sine-serve ng Ollama, at inaalis nito ang pinakamatatandang token kapag lumampas ang conversation sa limitasyong iyon. Walang nala-log kapag nangyayari ito, kaya para sa isang agent ay parang nakalimutan ng model ang simula ng sarili nitong task.

Itakda ang window nang sinasadya. Para sa buong server, i-edit ang service:

sudo systemctl edit ollama

Idagdag ito, pagkatapos ay patakbuhin ang sudo systemctl restart ollama:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Para sa bawat request, sa halip ay ipadala ang num_ctx sa options object:

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

Bawat pagtaas ay kumokonsumo ng memory, dahil lumalaki ang KV cache kasabay ng bilang ng mga token na pinapayagan mo. Taasan ang value, i-restart, pagkatapos ay patakbuhin muli ang ollama ps at obserbahan ang pagtaas ng naiulat na size. Kung ang column na PROCESSOR ay magbago mula 100% GPU tungo sa split pagkatapos ng pagbabagong iyon, itinulak ng KV cache ang model layers palabas ng VRAM at malaki ang ibabagsak ng speed. Detalyadong ipinapaliwanag ng Pagpili ng num_ctx sa Ollama ang trade-off na ito. Huwag itakda ang 1000000 dahil lamang pinapayagan ito ng model card, dahil upfront na ginagawa ang allocation at basta na lamang mabibigo ang load.

Pagkonekta nito sa isang agent na palaging tumatakbo

May shortcut na dokumentado sa launch post ng Ollama para sa model na ito. Sinisimulan nito ang isang supported agent na nakaturo na sa model:

ollama launch claude --model nemotron-3.5-lightning

Doon idinodokumento ng post ang claude, opencode, openclaw at hermes. Nangangailangan ang subcommand ng kasalukuyang bersyon ng Ollama. Kaya suriin muna ang ollama --version. Kung wala ito, manu-manong ituro ang agent sa API. Nagbibigay ang Ollama ng OpenAI-compatible endpoint na tinatanggap ng karamihan ng agent harness:

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

Hindi ginagamit ng Ollama ang key, pero karamihan ng client ay hindi magsisimula kung walang nakatakdang key. Saklaw ang bahagi ng harness sa pagtutok ng coding agent sa Ollama at sa pagbuo ng sarili mong OpenClaw agent.

Mahalaga ang dalawang server setting kapag unattended na tumatakbo ang agent. Kinokontrol ng OLLAMA_KEEP_ALIVE kung gaano katagal mananatili sa memory ang model pagkatapos ng huling request. Sa default, inaalis ito pagkalipas ng limang minuto, kaya muling magbabayad ang susunod na call ng buong load time. Sa isang file na 25 GB na walang GPU, sapat na katagal ang pause para lumampas sa timeout. Itakda ang OLLAMA_KEEP_ALIVE=-1 para manatili ito sa memory. Ginagawang reachable mula sa ibang machine ng OLLAMA_HOST=0.0.0.0:11434 ang API. Wala itong anumang authentication, kaya ilantad lamang ito sa likod ng firewall rule o private network.

Mga failure mode at ang mga string na makikita mo

Agad na nabibigo ang pull. Ibig sabihin ng Error: pull model manifest: file does not exist ay hindi umiiral ang tag na iyon. Eksaktong string ang mga pangalan ng tag, kaya kumopya ng isa mula sa library page sa halip na manghula ng quantisation suffix.

Hindi naglo-load ang model. Ibig sabihin ng Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) ay masyadong malaki ang tag para sa plan na ito sa kasalukuyang configuration. Gumamit ng mas maliit na quantisation o babaan ang OLLAMA_CONTEXT_LENGTH, dahil kasama sa requirement na iyon ang KV cache.

Walang sumasagot sa port 11434. Ibig sabihin ng curl: (7) Failed to connect to localhost port 11434 ay hindi tumatakbo ang service o hindi ito nakikinig sa inaasahan mong address. Basahin ang systemctl status ollama at journalctl -u ollama -n 50. Kung mano-mano mo ring sinimulan ang ollama serve, lalabas ang ikalawang kopya na may Error: listen tcp 127.0.0.1:11434: bind: address already in use.

Sumasagot ito pero napakabagal. Suriin ang ollama ps bago magbago ng anuman. Anumang CPU share sa column na PROCESSOR sa isang GPU machine ay nangangahulugang may bahagi ng model na lumampas sa VRAM, kaya babaan ang context o gamitin ang mas maliit na quantisation. Sa machine na walang GPU, inaasahan ang mabagal na performance at walang setting na makapag-aayos nito.

Nakakalimutan ng agent ang mga instruction nito habang ginagawa ang task. Lumampas ang conversation sa context window kaya tahimik na itinapon ang pinakalumang token. Taasan ang OLLAMA_CONTEXT_LENGTH, at kumpirmahin gamit ang ollama ps na kasya pa rin ang model. Kung hindi na ito kasya, mas malaking machine ang kailangan, hindi mas maliit na window.

Saan nakapuwesto ang model na ito kumpara sa mga alternatibo

Malaki nang i-host ang 30B MoE para sa maliit na workload. Kung kaya na ng dense 8B model ang task mo, mas mababa ang gastos sa pagpapatakbo nito at ilang segundo lang ang pag-load. Tingnan ang Qwen 3 sa 8B at 27B sa isang VPS para sa direktang paghahambing sa desisyong iyon. Para sa mas malawak na pagsusuri kung ano talaga ang kayang i-host ng isang partikular na plan, magsimula sa kung aling mga AI model ang maaari mong i-self-host. Kung plano mong mag-serve ng ilang agent nang sabay-sabay sa halip na isa lang, basahin muna ang paghahambing ng Ollama at vLLM. Hindi bina-batch ng Ollama ang concurrent requests sa paraang ginagawa ng production inference server, at dito nagsisimulang hindi na mag-scale ang setup para sa isang user.

FAQ

Aling Nemotron 3.5 Lightning tag ang dapat kong i-pull sa Linux VPS?

Gamitin ang nemotron-3.5-lightning:30b-a3b-q4_K_M. Ito ay 25 GB, naglalaman ito ng buong 1M maximum context, at ito ang kaparehong digest na tinutukoy ng mga tag na latest, 30b, at 30b-a3b noong August 2026. Tukuyin ito nang tahasan sa halip na i-pull ang latest, upang hindi mabago ng future republish ng pointer na iyon ang behavior ng iyong agent nang hindi mo napapansin. Ang mga mlx tag ay para sa Apple silicon builds at hindi makatutulong sa Linux.

Gaano karaming RAM ang kailangan ng Nemotron 3.5 Lightning?

Hindi naglalabas ang NVIDIA ng minimum memory figure para sa Ollama builds, kaya magsukat sa halip na mag-estimate. I-pull ang tag, patakbuhin ang model nang isang beses, at basahin ang ollama ps habang naka-load ito: ipinapakita nito ang aktuwal na laki ng memory na ginagamit at kung napunta ito sa GPU o CPU. Ang download size, na 25 GB para sa default tag, ay minimum lamang, dahil idinadagdag ang KV cache at lumalaki ito batay sa context window na itinakda mo. Kung masyadong maliit ang plan, tatanggi ang Ollama gamit ang model requires more system memory at ipapakita ang dalawang value.

Maaari ko bang patakbuhin ang Nemotron 3.5 Lightning sa VPS na walang GPU?

Oo, kung may sapat na RAM ang plan para maglaman ng weights, at nakatutulong ang MoE design dahil humigit-kumulang 3 lamang sa 30 billion parameters ang kino-compute para sa bawat token. Ang kapalit ay speed. Kapag walang GPU, memory bandwidth ang naglilimita sa model, kaya halos hindi nagbabago ang resulta kahit magdagdag ka ng vCPUs. Patakbuhin ang ollama run --verbose gamit ang fixed prompt, basahin ang linyang eval rate, at ihambing ang value na iyon sa deadline ng iyong agent. Para sa overnight batch job, kadalasan ay sapat ito. Para sa anumang hinihintay ng isang tao, karaniwan ay hindi.

Bakit hindi ibinibigay sa akin ng Ollama ang buong 1M context window?

Ang 1M ay maximum ng model, hindi default ng Ollama. Naglalapat ang Ollama ng mas maliit na window at itinatapon ang pinakamatatandang token kapag lumampas dito ang conversation, nang walang ipinapakitang error. Dahil dito, mukhang nakakalimutan ng agent ang sarili nitong instructions. Itakda ang OLLAMA_CONTEXT_LENGTH sa systemd service, o ipasa ang num_ctx sa bawat request. Itaas ito nang paunti-unti at suriin muli ang ollama ps sa bawat pagbabago, dahil naka-scale ang KV cache memory sa window at maaari nitong mailipat ang mga model layer palabas ng GPU.

Libre bang gamitin sa commercial na gawain ang Nemotron 3.5 Lightning?

Inilalagay ng model card ng NVIDIA ang model sa ilalim ng OpenMDW-1.1 license at minamarkahan itong handa para sa commercial use. Saklaw nito ang weights na ikaw mismo ang dina-download at pinapatakbo. Wala itong sinasabi tungkol sa ibang software sa iyong stack, kaya hiwalay na suriin ang mga license ng agent harness at anumang tools na ikinokonekta mo rito. Basahin din ang kasalukuyang model card bago ito asahan para sa anumang bagay na may contractual na epekto.