Nemotron 3.5 Lightning sa VPS gamit ang Ollama

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. Idinisenyo ito para sa mga agent na tumatakbo nang ilang oras, hindi lamang 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 ginagamit sa bawat token. Ayon sa model card ng NVIDIA, mayroon itong kabuuang 30 billion parameters, ngunit 3 billion lamang ang active sa bawat token. Ang malaking bilang ay kailangan mong ilaan sa memory. Ang maliit na bilang naman ang nagbabalik ng mas mataas na speed.

Dahil sa trade-off na ito, sulit isaalang-alang ang model na ito para sa rented server. Ang agent na gumagawa ng aktuwal na trabaho ay nagpapadala ng libo-libong maiikling request sa loob ng isang araw. Kaya ang throughput per dollar ang nagpapasya kung kaya itong patakbuhin sa sarili mong server. Ang model na tumatagal ng 40 seconds bawat reply ay magagamit na assistant ngunit hindi mahusay na agent, dahil ang isang task ay maaaring mangailangan ng 20 call at kailangan mong hintayin ang bawat isa.

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

Nag-publish ang Artificial Analysis ng launch measurements noong August 2026 na nagpapakitang halos 670 output tokens bawat segundo. Sinukat ito sa isang pre-release DeepInfra endpoint na naghahatid ng NVFP4 weights. Hosted GPU endpoint iyon. Ituring ang resultang ito bilang kakayahan ng architecture, hindi bilang performance na makukuha ng iyong VPS.

Aling Ollama tag ang angkop sa bawat VPS

Naglalabas ang Ollama library ng ilang build 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. Dahil dito, ang default download ay ang 25 GB na four-bit build na may buong 1M context. Ang Q8_0 ay 35 GB at ang bf16 ay 66 GB; parehong may 1M context. Ang MLX builds na 23 GB ay para sa Apple silicon at hanggang 256K context lamang. Kaya hindi angkop ang mga ito sa Linux VPS.

Mga download size ang mga numerong ito, hindi memory requirement. Walang inilalabas na minimum VRAM (video RAM) figure ang NVIDIA para sa Ollama builds. Kaya ituring ang download size bilang pinakamababang batayan lamang, at hindi bilang eksaktong memory requirement. Kailangang manatili ang weights sa memory: sa GPU memory kung kasya ang mga ito sa 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). Ang aktuwal na numerong angkop sa hardware mo ay nakukuha sa isang command, hindi sa simpleng kalkulasyon. Nasa ibaba ang command na iyon. Kung hindi ka pa nakakapili ng quantisation level, ipinapaliwanag sa kung ano ang kapalit ng Q4, Q8 at FP16 sa bawat hakbang kung ano ang isinusuko sa bawat opsyon.

Kunin ang eksaktong tag, huwag ang latest

Ang latest ay isang pointer na nagbabago. Kapag muli itong inilabas ng library, magbabago ang behavior ng iyong agent sa susunod na pull kahit walang paliwanag sa iyong notes. 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 nagtatago ng mga model sa /usr/share/ollama/.ollama/models. Nasa root filesystem ang path na iyon sa karamihan ng VPS image, kaya tingnan muna kung may sapat na espasyo bago humingi ng 25 GB. Kung kapos ang filesystem na iyon, makatutulong basahin ang kung saan iniimbak ni Ollama ang mga model nito at kung paano ilipat ang mga ito bago ang pull, hindi pagkatapos mapuno ng mga ito ang disk.

df -h /usr/share/ollama

Ang pull na humihinto sa kalagitnaan at nag-uulat ng no space left on device ay nangangahulugang ganoon mismo, at nananatili sa disk ang partial blob hanggang sa burahin 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 mga parameter, haba ng context, at quantisation na aktuwal na dala ng file. Kung may alinman sa mga ito na hindi tugma sa library page, ibang tag ang na-pull mo kaysa sa nilayon mo.

Patakbuhin 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 ng iyong machine. 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, nasa VRAM ang buong model. Ibig sabihin ng 100% CPU, walang bahagi nito sa VRAM at kino-compute ng processor ang bawat token mula sa system RAM. Ang hatian gaya ng 65%/35% CPU/GPU ay nangangahulugang hindi nagkasya ang lahat ng layer, kaya ang bahaging pinapatakbo ng CPU ang nagtatakda ng bilis. Huwag tantiyahin ang requirement. I-load ito at basahin ang linyang ito.

Kung hindi talaga 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 isang general-purpose VPS, kaya CPU ang gumagawa ng lahat ng trabaho at binabasa nito mula sa system RAM ang bawat weight na kailangan nito. Nakakatulong dito ang MoE dahil mga 3 bilyon lamang sa 30 bilyong parameter ang ginagamit sa bawat token. Dahil dito, mas maliit nang malaki ang computation sa bawat token kumpara sa isang dense 30B model. Hindi naman nito binabawasan ang kailangan sa memory. Kailangang manatili sa memory ang lahat ng 30 bilyong parameter dahil maaaring pumili ang router ng kahit anong expert para sa bawat token.

Kaya ang CPU-only inference sa model na ito ay mas nalilimitahan ng memory bandwidth kaysa sa bilang ng core. Kaunti lamang ang epekto ng pagdaragdag ng vCPU sa planong mayroon nang sapat na bilang ng mga ito. Kailangan mo ng sapat na RAM para sa weights at sa iyong KV cache, pati na rin ng pinakamabilis na memory na ibinibigay ng plan.

Sukatin muna ito bago mo paggamitan ng agent, gamit ang paraan sa 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 lumalabas sa dulo ang generation speed mo sa tokens per second. Ang iisang numerong ito ang sumasagot sa tanong dahil ito ang pangunahing tumutukoy sa wall-clock time ng agent. I-multiply ito sa haba ng reply na inaasahan mo. Kung mas mahaba ang resulta kaysa sa oras na handa mong hintayin, paglilimita sa output gamit ang num_predict ang isang paraan para malimitahan ang tagal ng isang call nang hindi binabago ang hardware.

[
  {
    "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 inilathalang third-party figure ang mga ito. Na-convert ang mga ito mula sa per-task minutes na iniulat ng Artificial Analysis noong inilunsad ito, at sinukat ang mga ito sa hosted GPU endpoint, hindi sa VPS. May average na humigit-kumulang 30 segundo bawat task ang Nemotron 3.5 Lightning. Umabot sa tinatayang 204 ang gpt-oss-120b, at humigit-kumulang 210 naman ang Qwen3.6 35B. Gamitin ang mga ito para makita ang laki ng agwat, hindi bilang garantiya para sa hardware mo.

Depende ang praktikal na payo sa kung sino ang naghihintay. Kung may taong naghihintay sa agent, o sunod-sunod itong gumagawa ng mahahabang call chain, mag-rent ng GPU capacity. Kung naka-schedule ito sa gabi at walang nagmamasid, makatwirang gamitin ang isang CPU plan na may malaking RAM. Pareho lang ang setup sa alinmang opsyon, at tinatalakay sa pagpapatakbo ng Ollama sa isang VPS ang pag-size ng plan at ang paghahambing ng GPU instance sa pagbabayad sa API provider ayon sa token. Usapin ng utilisation ang break-even: sinisingil ang GPU instance sa bawat oras na umiiral ito, samantalang sinisingil lamang ang API token kapag ginagamit. Kaya mas angkop ang sariling server para sa agent na abala sa halos buong araw, ngunit karaniwang hindi ito sulit para sa agent na dalawang beses lamang gumagana bawat oras.

Hindi libre ang 1M context window

Ang 1M tokens ang maximum ng model, at hindi ito awtomatikong ibinibigay ng Ollama. Mas maliit na default window ang inihahatid ng Ollama, at inaalis nito ang pinakamatatandang token kapag lumampas ang conversation sa limit na iyon. Walang nilala-log kapag nangyayari ito, kaya para sa isang agent, mukhang nakalimutan ng model ang simula ng sarili nitong task.

Itakda nang sadya ang window. 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 nangangailangan ng mas malaking memory dahil lumalaki ang KV cache kasabay ng bilang ng mga token na pinapayagan mo. Itaas ang value, i-restart, pagkatapos ay patakbuhin muli ang ollama ps at i-monitor ang iniulat na laki habang tumataas ito. Kung ang column na PROCESSOR ay magbago mula 100% GPU patungo sa split matapos ang pagbabagong iyon, itinulak ng KV cache ang mga model layer palabas ng VRAM at malaki ang ibabagsak ng speed. Detalyadong ipinapaliwanag ng Pagpili ng num_ctx sa Ollama ang trade-off na ito. Huwag magtakda ng 1000000 dahil lamang pinapayagan ito ng model card, dahil isinasagawa agad ang allocation at basta mabibigo ang load.

Pagkabit nito sa isang always-on agent

Itinatala sa launch post ng Ollama para sa model na ito ang shortcut na nagsisimula ng isang supported agent na naka-configure na para gamitin ito:

ollama launch claude --model nemotron-3.5-lightning

Itinatala ng post ang claude, opencode, openclaw at hermes sa posisyong iyon. Nangangailangan ang subcommand ng kasalukuyang bersyon ng Ollama, kaya tingnan muna ang ollama --version. Kung wala ito, ikaw mismo ang magturo sa agent sa API. Naglalantad 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, bina-unload ito pagkalipas ng limang minuto, kaya muling magbabayad ang susunod na call ng buong load time. Sa isang file na 25 GB at walang GPU, sapat ang tagal ng pause na iyon para magdulot ng timeout. Itakda ang OLLAMA_KEEP_ALIVE=-1 upang manatili ito sa memory. Ginagawang reachable ng OLLAMA_HOST=0.0.0.0:11434 ang API mula sa ibang machine. Wala itong anumang authentication, kaya buksan lamang ito sa likod ng firewall rule o sa private network.

Mga failure mode, kasama ang mga string na makikita mo

Agad na nagfa-fail ang pull. Ibig sabihin ng Error: pull model manifest: file does not exist ay hindi umiiral ang tag na iyon. Eksaktong string ang mga tag name, 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 ayon 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 inaasahang address. Basahin ang systemctl status ollama at journalctl -u ollama -n 50. Kung sinimulan mo rin nang mano-mano ang ollama serve, lalabas ang ikalawang copy na may Error: listen tcp 127.0.0.1:11434: bind: address already in use.

Sumasagot ito, pero napakabagal. Suriin muna 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 makakapag-ayos nito.

Nakakalimutan ng agent ang mga instruction nito habang isinasagawa ang task. Lumampas ang conversation sa context window, kaya tahimik na itinapon ang mga pinakamatandang token. Itaas 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 sa halip na mas maliit na window.

Paghahambing ng modelong ito sa mga alternatibo

Malaki nang i-host ang 30B MoE para sa isang maliit na gawain. Kung kaya na ng isang dense 8B model ang iyong task, mas mababa ang gastos sa pagpapatakbo nito at ilang segundo lamang ang kailangan para mag-load. Para sa direktang paghahambing na iyon, tingnan ang Qwen 3 sa 8B at 27B sa isang VPS. Para sa mas malawak na pagsusuri kung ano talaga ang kayang i-host ng isang partikular na plan, magsimula sa kung aling AI models ang maaari mong i-self-host. Kung plano mong mag-serve ng ilang agent nang sabay-sabay sa halip na iisang agent, basahin muna ang paghahambing ng Ollama at vLLM. Hindi nagba-batch ang Ollama ng magkakasabay na request sa paraang ginagawa ng isang production inference server. Dito nagsisimulang hindi na mag-scale ang isang setup para sa iisang user.

FAQ

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

Gamitin ang nemotron-3.5-lightning:30b-a3b-q4_K_M. Ito ay 25 GB, may buong 1M maximum context, at kapareho ng 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 agent mo nang hindi mo napapansin. Ang mga mlx tag ay mga build para sa Apple silicon 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 sukatin ito sa halip na tantiyahin. 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 ayon sa context window na itinakda mo. Kung masyadong maliit ang plan, tatanggi ang Ollama gamit ang model requires more system memory at ipapakita ang parehong bilang.

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

Oo, kung sapat ang RAM ng plan para paglagyan ng weights. Nakakatulong ang MoE design dahil humigit-kumulang 3 lamang sa 30 billion parameters ang kino-compute sa bawat token. Ang kapalit nito ay bilis. Kung walang GPU, nalilimitahan ang model ng memory bandwidth, kaya halos walang epekto ang pagdagdag ng vCPUs. Patakbuhin ang ollama run --verbose gamit ang fixed prompt, basahin ang linyang eval rate, at ihambing ang bilang na iyon sa deadline ng agent mo. Para sa batch job na tumatakbo magdamag, 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. Nag-a-apply ang Ollama ng mas maliit na window at itinatapon ang pinakamatatandang token kapag lumampas dito ang conversation, nang walang ipinip na error. Nagmumukha tuloy na nakakalimutan ng agent ang sarili nitong instructions. Itakda ang OLLAMA_CONTEXT_LENGTH sa systemd service, o ipasa ang num_ctx sa bawat request. Dagdagan ito nang paunti-unti at suriin muli ang ollama ps sa bawat pagbabago, dahil lumalaki ang KV cache memory kasabay ng window at maaari nitong maitulak palabas ng GPU ang ilang model layer.

Libre bang gamitin ang Nemotron 3.5 Lightning para sa komersiyal na paggamit?

Inilalagay ng model card ng NVIDIA ang model sa ilalim ng OpenMDW-1.1 license at minamarkahan itong handa para sa komersiyal na paggamit. Saklaw nito ang weights na ikaw mismo ang nagda-download at nagpapatakbo. Wala itong sinasabi tungkol sa ibang software sa iyong stack, kaya hiwalay na suriin ang mga license ng agent harness at anumang tool na ikinokonekta mo rito. Basahin din ang kasalukuyang model card bago mo ito gamitin bilang batayan para sa anumang kontraktuwal na usapin.