VPSలో Nemotron 3.5 Lightning ఎలా నడపాలి

Nemotron 3.5 Lightning దేనికి ఉపయోగపడుతుంది

Nemotron 3.5 Lightning అనేది NVIDIA విడుదల చేసిన open 30B mixture-of-experts model. ఇది August 2026లో విడుదలైంది. ఒక chat window కోసం కాకుండా, గంటల తరబడి నడిచే agents కోసం దీన్ని రూపొందించారు. MoE (mixture of experts) అంటే weights ను అనేక expert sub-networks గా విభజించి, ప్రతి token ను వాటిలో కొన్నింటి ద్వారా మాత్రమే పంపించడం. NVIDIA model card ప్రకారం మొత్తం parameters 30 billion, అయితే ప్రతి token కు 3 billion మాత్రమే active గా ఉంటాయి. పెద్ద సంఖ్యకు అవసరమైన memory ను మీరు భరించాలి. చిన్న active సంఖ్య వల్ల వేగం లభిస్తుంది.

మీరు lease చేసే serverలో ఈ model ను పరిశీలించడానికి ఇదే trade-off ప్రధాన కారణం. వాస్తవ పనులు చేసే agent ఒక రోజులో వేలకొద్దీ చిన్న requests పంపుతుంది. అందువల్ల ప్రతి dollar కు లభించే throughput, అది మీ స్వంత serverలో అమలు చేయగలదా లేదా నిర్ణయిస్తుంది. ప్రతి reply కు 40 seconds పట్టే model సాధారణ assistant గా ఉపయోగపడవచ్చు. కానీ agent గా అది తక్కువ ఉపయోగకరం. ఎందుకంటే ఒక task ఇరవై calls చేస్తుంది, వాటిలో ప్రతి ఒక్కటి పూర్తయ్యే వరకు మీరు వేచి ఉండాలి.

ఈ architecture hybrid అని NVIDIA వివరిస్తుంది. ఇందులో interleaved Mamba-2 మరియు MoE layers తో పాటు select attention layers ఉంటాయి. model card ప్రకారం maximum context length 1M tokens వరకు ఉంటుంది. OpenMDW-1.1 license కూడా ఉంది. ఇది commercial use కు సిద్ధంగా ఉన్నదిగా గుర్తించబడింది. ప్రధాన languages English మరియు code. Spanish, French, German, Italian, Japanese కూడా జాబితాలో ఉన్నాయి.

August 2026లో Artificial Analysis విడుదల సమయంలో చేసిన measurements ను ప్రచురించింది. Pre-release DeepInfra endpointలో NVFP4 weights అందించబడినప్పుడు, output వేగం దాదాపు 670 tokens per secondగా నమోదైంది. అది hosted GPU endpoint కొలత. దీన్ని architecture సాధించగల సామర్థ్యంగా అర్థం చేసుకోండి. మీ VPSలో లభించే వాస్తవ వేగంగా అర్థం చేసుకోకండి.

ఏ Ollama tag ఏ VPS కు సరిపోతుంది

Ollama library ఒకే weights కోసం అనేక builds ను ప్రచురిస్తుంది. వాటి మధ్య మారేది quantisation. అంటే ప్రతి weight ను ఎన్ని bits లో నిల్వ చేయాలో అది నిర్ణయిస్తుంది. దీనివల్ల 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
  }
]

latest, 30b మరియు 30b-a3b పేర్లతో ఉన్న tags అన్నీ 30b-a3b-q4_K_M కు సమానమైన digest కు resolve అవుతాయి. అందువల్ల default download అనేది పూర్తి 1M context కలిగిన 25 GB four-bit build. Q8_0 పరిమాణం 35 GB, bf16 పరిమాణం 66 GB. ఈ రెండింటికీ 1M context ఉంటుంది. 23 GB పరిమాణం ఉన్న MLX builds Apple silicon కోసం ఉద్దేశించినవి. ఇవి 256K context వద్ద పరిమితం అవుతాయి. కాబట్టి Linux VPS లో ఇవి సరైన ఎంపిక కావు.

అవి download sizes మాత్రమే; memory requirement కాదు. Ollama builds కోసం NVIDIA కనిష్ఠ VRAM (video RAM) పరిమాణాన్ని ప్రచురించదు. కాబట్టి download size ను కనిష్ఠ అంచనాగా మాత్రమే పరిగణించాలి. దానికంటే ఎక్కువ అర్థం తీసుకోకూడదు. Weights ఏదో ఒక memoryలో resident గా ఉండాలి. GPU వాటిని పట్టుకోగలిగితే అవి GPU memoryలో ఉంటాయి; లేకపోతే system RAMలో ఉంటాయి. దీనికి అదనంగా KV cache (key/value cache; conversation లోని ప్రతి token కు model ఉపయోగించే memory) కూడా అవసరం. మీ hardware కోసం వాస్తవ పరిమాణం arithmetic ద్వారా కాదు, command ద్వారా తెలుస్తుంది. ఆ command క్రింద ఉంది. ఇంకా quantisation level ను నిర్ణయించకపోతే, Q4, Q8 మరియు FP16లో ప్రతి దానికి అయ్యే ఖర్చు అనే విభాగంలో ప్రతి దశలో ఏమి కోల్పోతారో వివరించబడింది.

ఖచ్చితమైన tag ను పొందండి, ఎప్పుడూ latest ను కాదు

latest మారుతూ ఉండే pointer. Library దాన్ని మళ్లీ publish చేసినప్పుడు, మీ notes లో కారణం నమోదు కాకుండానే తదుపరి pull సమయంలో agent ప్రవర్తన మారుతుంది. Tag పేరును స్పష్టంగా పేర్కొనండి.

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

Install script systemd service ను ఏర్పాటు చేస్తుంది. అది ollama user గా run అవుతుంది మరియు models ను /usr/share/ollama/.ollama/models కింద ఉంచుతుంది. చాలా VPS images లో ఆ path root filesystem పై ఉంటుంది. కాబట్టి 25 GB కోసం అడగడానికి ముందు తగినంత స్థలం ఉందో పరిశీలించండి.

df -h /usr/share/ollama

Pull మధ్యలో ఆగి no space left on device ను చూపిస్తే, దాని అర్థం అదే. Partial blobs ను మీరు delete చేసే వరకు అవి disk పై ఉంటాయి. ఆ తరువాత ఏవి సరిగ్గా వచ్చాయో నిర్ధారించండి:

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

ollama show architecture, parameter count, context length మరియు file లో వాస్తవంగా ఉన్న quantisation ను చూపిస్తుంది. వీటిలో ఏదైనా library page లో ఉన్న వివరాలతో సరిపోలకపోతే, మీరు ఉద్దేశించిన దానికంటే వేరే tag ను pull చేశారు.

దాన్ని సర్వ్ చేసి, అది వాస్తవంగా ఎక్కడ నడిచిందో పరిశీలించండి

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

మోడల్ ఇంకా లోడ్ అయి ఉన్నప్పుడు, రెండవ shell లో:

ollama ps

ఈ command మీ machine కోసం memory కు సంబంధించిన ప్రశ్నకు సమాధానం ఇస్తుంది. ollama ps లోడ్ అయిన model, అది memory లో ఆక్రమించిన పరిమాణం, అలాగే PROCESSOR column కనిపిస్తాయి. 100% GPU అంటే మొత్తం model VRAM లోనే ఉందని అర్థం. 100% CPU అంటే దానిలో ఏ భాగమూ VRAM లో లేదని, ప్రతి token ను system RAM నుంచి processor లెక్కిస్తుందని అర్థం. 65%/35% CPU/GPU వంటి split అంటే అన్ని layers memoryలో సరిపోలేదని అర్థం; CPU share మీ వేగాన్ని నిర్ణయిస్తుంది. అవసరాన్ని అంచనా వేయవద్దు. దాన్ని load చేసి ఈ line ను చదవండి.

అది పూర్తిగా load కాకపోతే, Ollama crash కాకుండా సురక్షితంగా నిరాకరిస్తుంది:

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

CPU మాత్రమే ఉన్న VPS తగినంత వేగంగా ఉంటుందా?

సాధారణ ప్రయోజనాల కోసం ఉపయోగించే VPSలో GPU ఉండదు. అందువల్ల మొత్తం పని CPU చేస్తుంది, అవసరమైన ప్రతి weight ను system RAM నుంచి చదువుతుంది. ఇక్కడ MoE సహాయపడుతుంది. ప్రతి token కోసం 30 billion parameters లో సుమారు 3 billion మాత్రమే ఉపయోగించబడతాయి. కాబట్టి dense 30B model తో పోలిస్తే ప్రతి token కు అవసరమైన గణన చాలా తక్కువగా ఉంటుంది. అయితే memory వినియోగం తగ్గదు. మొత్తం 30 billion parameters memoryలోనే ఉండాలి, ఎందుకంటే ఏ token కు అయినా router ఏ expert ను ఎంచుకోవచ్చును.

అందువల్ల ఈ model పై CPU-only inference వేగాన్ని core count కంటే memory bandwidth ఎక్కువగా పరిమితం చేస్తుంది. ఇప్పటికే సరిపడా vCPUs ఉన్న plan కు మరిన్ని vCPUs జోడించినా పెద్దగా మార్పు ఉండదు. Weights తో పాటు మీ KV cache ను ఉంచడానికి సరిపడా RAM, అలాగే ఆ plan అందించే అత్యంత వేగవంతమైన memory మీకు అవసరం.

Agent ను దానిపై అమలు చేయాలని నిర్ణయించే ముందు, local LLM కోసం tokens per second కొలిచే విధానం ఉపయోగించి వేగాన్ని కొలవండి:

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

చివరలో ముద్రించబడే eval rate line, tokens per second లో generation speed ను చూపుతుంది. ఈ ఒక్క సంఖ్యే నిర్ణయాత్మకం, ఎందుకంటే agent తీసుకునే wall-clock time ప్రధానంగా దీనిపైనే ఆధారపడి ఉంటుంది.

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

ఇవి ప్రచురించబడిన third-party గణాంకాలు. Artificial Analysis launch సమయంలో నివేదించిన ప్రతి task కు పట్టే నిమిషాల నుంచి వీటిని మార్చాము. ఇవి VPSపై కాకుండా hosted GPU endpoints పై కొలిచినవి. Nemotron 3.5 Lightning ప్రతి task కు సగటున 30 seconds తీసుకుంది. ఇందులో gpt-oss-120b సుమారు 204, అలాగే Qwen3.6 35B సుమారు 210 తీసుకున్నాయి. వీటిని మీ hardware కు హామీగా కాకుండా, వేగం మధ్య ఉన్న తేడా పరిమాణాన్ని అర్థం చేసుకోవడానికి ఉపయోగించండి.

ఎవరు వేచి ఉన్నారనే దాని ఆధారంగా సరైన సలహా మారుతుంది. Agent కోసం ఒక వ్యక్తి వేచి ఉంటే, లేదా agent వరుసగా చాలా calls చేస్తే, GPU capacity ను rent చేయండి. అది రాత్రివేళ schedule ప్రకారం నడుస్తూ, ఎవరూ గమనించకపోతే, పెద్ద RAM ఉన్న CPU plan సరైన ఎంపిక. రెండు సందర్భాల్లోనూ setup ఒకటే. VPSపై Ollama నడపడం అనే విభాగంలో plan sizing, అలాగే ప్రతి token కు API provider కు చెల్లించడంతో పోలిస్తే GPU instance ఎలా ఉంటుందో వివరించబడింది. Break-even అనేది utilisation పై ఆధారపడుతుంది. GPU instance ఉన్న ప్రతి గంటకూ billing జరుగుతుంది. API tokens ను ఉపయోగించినప్పుడు మాత్రమే వాటికి billing జరుగుతుంది. అందువల్ల రోజులో ఎక్కువసేపు busyగా ఉండే agent కు మీరు స్వంతంగా నడిపే server అనుకూలం. గంటకు రెండుసార్లు మాత్రమే నడిచే agent కు సాధారణంగా అది అనుకూలం కాదు.

1M context window ఉచితం కాదు

1M tokens మోడల్‌కు గరిష్ఠ పరిమితి. అయితే Ollama దీన్ని డిఫాల్ట్‌గా మీకు అందించదు. Ollama చాలా చిన్న default window ను ఉపయోగిస్తుంది. ఒక conversation ఆ పరిమితిని దాటినప్పుడు, ఇది పాత tokens ను తొలగిస్తుంది. అలా జరిగినప్పుడు ఏదీ log చేయబడదు. అందువల్ల agent కు మోడల్ తన task ప్రారంభాన్ని మర్చిపోయినట్లు కనిపిస్తుంది.

Window పరిమాణాన్ని ఉద్దేశపూర్వకంగా సెట్ చేయండి. మొత్తం server కోసం service ను సవరించండి:

sudo systemctl edit ollama

దీనిని జోడించి, తరువాత sudo systemctl restart ollama ను అమలు చేయండి:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

ప్రతి request కు బదులుగా options object లో num_ctx ను పంపండి:

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

మీరు అనుమతించే tokens సంఖ్య పెరిగే కొద్దీ KV cache కూడా పెరుగుతుంది. అందువల్ల ప్రతి పెంపుకు memory ఎక్కువగా అవసరం. విలువను పెంచి, service ను restart చేయండి. తరువాత ollama ps ను మళ్లీ అమలు చేసి, చూపబడే size పెరుగుతున్నదో చూడండి. ఆ మార్పు తర్వాత PROCESSOR column 100% GPU నుండి split కు మారితే, KV cache model layers ను VRAM బయటకు నెట్టింది. దాంతో వేగం గణనీయంగా తగ్గుతుంది. Ollamaలో num_ctx ఎంచుకోవడం ఈ trade-off ను వివరంగా వివరిస్తుంది. Model card అనుమతిస్తుంది కాబట్టి మాత్రమే 1000000 ను సెట్ చేయవద్దు. Allocation ముందుగానే జరుగుతుంది. దాంతో load విఫలమవుతుంది.

ఎల్లప్పుడూ నడిచే agent లో అనుసంధానం చేయడం

ఈ model కోసం Ollama విడుదల చేసిన post, దానికి ఇప్పటికే సూచించబడిన supported agent ను ప్రారంభించే shortcut ను వివరిస్తుంది:

ollama launch claude --model nemotron-3.5-lightning

ఆ స్థానంలో post claude, opencode, openclaw మరియు hermes ను వివరిస్తుంది. ఈ subcommand కు తాజా Ollama అవసరం. కాబట్టి ముందుగా ollama --version ను తనిఖీ చేయండి. అది లేకపోతే, agent ను API కి మీరే సూచించండి. Ollama OpenAI-compatible endpoint ను అందిస్తుంది. చాలా agent harnessలు దీన్ని అంగీకరిస్తాయి:

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

Ollama key ను పరిగణనలోకి తీసుకోదు. అయితే చాలా clients ఒక key సెట్ చేయకుండా ప్రారంభం కావు. Harness వైపు సంబంధించిన వివరాలు coding agent ను Ollama కు సూచించడం మరియు మీ స్వంత OpenClaw agent ను నిర్మించడం లో ఉన్నాయి.

Agent unattended గా నడుస్తున్నప్పుడు రెండు server settings ముఖ్యమైనవి. చివరి request తర్వాత model memory లో ఎంతసేపు ఉండాలో OLLAMA_KEEP_ALIVE నియంత్రిస్తుంది. Default గా అది ఐదు నిమిషాల తర్వాత model ను unload చేస్తుంది. అందువల్ల తదుపరి call కు మళ్లీ పూర్తి load time పడుతుంది. GPU లేని 25 GB file పై ఆ విరామం timeout ను దాటేంత ఎక్కువగా ఉండవచ్చు. Model ను memory లోనే ఉంచడానికి OLLAMA_KEEP_ALIVE=-1 ను సెట్ చేయండి. OLLAMA_HOST=0.0.0.0:11434 ద్వారా ఇతర machines నుంచి API ను చేరుకోవచ్చు. దీనికి ఎలాంటి authentication ఉండదు. కాబట్టి దీన్ని firewall rule లేదా private network వెనుక మాత్రమే తెరవండి.

మీరు చూడగలిగే సందేశాలతో వైఫల్య పరిస్థితులు

Pull వెంటనే విఫలమవుతుంది. Error: pull model manifest: file does not exist అంటే ఆ tag ఉనికిలో లేదు. Tag పేర్లు ఖచ్చితమైన strings. అందువల్ల quantisation suffix ను ఊహించకుండా, library page నుంచి ఒక tag ను copy చేయండి.

Model load కాదు. Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) అంటే ప్రస్తుత configurationలో ఈ planకు ఆ tag చాలా పెద్దది. చిన్న quantisationకు మార్చండి లేదా OLLAMA_CONTEXT_LENGTH విలువను తగ్గించండి. ఎందుకంటే KV cache కూడా ఆ అవసరంలో లెక్కించబడుతుంది.

Port 11434పై ఏదీ స్పందించదు. curl: (7) Failed to connect to localhost port 11434 అంటే service నడవడం లేదు లేదా మీరు ఊహించిన స్థానంలో listening చేయడం లేదు. systemctl status ollama మరియు journalctl -u ollama -n 50 చదవండి. మీరు ollama serve ను చేతితో కూడా ప్రారంభించి ఉంటే, రెండవ copy Error: listen tcp 127.0.0.1:11434: bind: address already in use తో exit అవుతుంది.

స్పందిస్తుంది, కానీ చాలా నెమ్మదిగా. ఏదైనా మార్చే ముందు ollama ps ను తనిఖీ చేయండి. GPU ఉన్న machineలో PROCESSOR columnలో ఏదైనా CPU share కనిపిస్తే, modelలో కొంత భాగం VRAM వెలుపలికి వెళ్లిందని అర్థం. అందువల్ల contextను తగ్గించండి లేదా చిన్న quantisationను ఎంచుకోండి. GPU లేని machineలో నెమ్మదిగా ఉండటం ఆశించిన ఫలితమే; ఏ settingతోనూ దాన్ని సరిచేయలేరు.

Taskలో కొంత భాగం పూర్తయ్యేలోపు agent తన instructionsను మర్చిపోతుంది. Conversation context window పరిమితిని దాటింది. అందువల్ల మొదటి tokens నిశ్శబ్దంగా discard అయ్యాయి. OLLAMA_CONTEXT_LENGTH ను పెంచండి. Model ఇంకా సరిపోతుందో ollama ps తో నిర్ధారించండి. ఇక సరిపోకపోతే, పరిష్కారం windowను చిన్నదిగా చేయడం కాదు; పెద్ద machineను ఉపయోగించడం.

ఈ మోడల్ ఇతర ప్రత్యామ్నాయాలతో పోలిస్తే ఎక్కడ ఉంటుంది

చిన్న పని కోసం 30B MoEని host చేయడం పెద్ద వనరుల అవసరాన్ని కలిగిస్తుంది. Dense 8B మోడల్ ఇప్పటికే మీ పనిని నిర్వహించగలిగితే, దాన్ని అమలు చేయడానికి చాలా తక్కువ ఖర్చవుతుంది మరియు అది కొన్ని సెకన్లలో load అవుతుంది. ఈ నిర్ణయానికి ప్రత్యక్ష పోలిక కోసం VPSపై 8B మరియు 27B వద్ద Qwen 3 చూడండి. ఇచ్చిన plan వాస్తవంగా ఏ మోడళ్లను నిర్వహించగలదో విస్తృతంగా తెలుసుకోవడానికి మీరు self-host చేయగల AI మోడళ్లు నుంచి ప్రారంభించండి. ఒకేసారి ఒక agent కాకుండా అనేక agents ను serve చేయాలనుకుంటే ముందుగా Ollama మరియు vLLM పోలిక చదవండి. Production inference server చేసే విధంగా Ollama concurrent requests ను batch చేయదు. అందువల్ల single-user setup అక్కడ scale అవ్వడం ఆగిపోతుంది.

FAQ

Linux VPSలో ఏ Nemotron 3.5 Lightning tag ను pull చేయాలి?

nemotron-3.5-lightning:30b-a3b-q4_K_M ను ఉపయోగించండి. దీని పరిమాణం 25 GB. ఇది పూర్తి 1M గరిష్ఠ context ను కలిగి ఉంటుంది. August 2026 నాటికి latest, 30b మరియు 30b-a3b tags సూచించే అదే digest ను ఇది ఉపయోగిస్తుంది. latest ను pull చేయడానికి బదులుగా దీని పేరును స్పష్టంగా ఇవ్వండి. లేకపోతే భవిష్యత్తులో ఆ pointer ను మళ్లీ publish చేసినప్పుడు, మీకు తెలియకుండానే agent ప్రవర్తన మారవచ్చు. mlx tags Apple silicon builds. Linuxలో అవి మీకు ఉపయోగపడవు.

Nemotron 3.5 Lightning కు ఎంత RAM అవసరం?

Ollama builds కోసం NVIDIA కనిష్ఠ memory పరిమాణాన్ని ప్రచురించలేదు. కాబట్టి అంచనా వేయకుండా కొలవండి. Tag ను pull చేసి, model ను ఒకసారి run చేయండి. అది loaded గా ఉన్నప్పుడు ollama ps ను చూడండి. ఇది వాస్తవంగా ఆక్రమించిన పరిమాణాన్ని, అలాగే అది GPUపై నడుస్తుందా లేదా CPUపై నడుస్తుందా చూపిస్తుంది. Default tag కోసం download పరిమాణం 25 GB మాత్రమే కనిష్ఠ అంచనా. దీనికి అదనంగా KV cache అవసరం అవుతుంది. మీరు నిర్ణయించిన context window పెరిగే కొద్దీ అది కూడా పెరుగుతుంది. VPS plan చాలా చిన్నదైతే, Ollama model requires more system memory తో విఫలమై, రెండు పరిమాణాలను చూపిస్తుంది.

GPU లేని VPSలో Nemotron 3.5 Lightning ను run చేయవచ్చా?

అవును. Weights ను నిల్వ చేయడానికి planలో సరిపడా RAM ఉంటే run చేయవచ్చు. MoE రూపకల్పన కూడా సహాయపడుతుంది, ఎందుకంటే ప్రతి token కోసం 30 billion parametersలో సుమారు 3 మాత్రమే లెక్కించబడతాయి. ప్రధాన పరిమితి speed. GPU లేకపోతే model memory bandwidthపై ఆధారపడుతుంది. అందువల్ల vCPUs పెంచినా ఫలితంలో పెద్ద మార్పు ఉండదు. స్థిరమైన promptతో ollama run --verbose ను run చేసి, eval rate line ను చూడండి. ఆ సంఖ్యను మీ agent deadlineతో పోల్చి నిర్ణయం తీసుకోండి. రాత్రంతా నడిచే batch jobకు ఇది చాలాసార్లు సరిపోతుంది. వ్యక్తి ఫలితం కోసం వేచి ఉండే పనులకు సాధారణంగా సరిపోదు.

Ollama నాకు పూర్తి 1M context window ను ఎందుకు ఇవ్వదు?

1M అనేది model గరిష్ఠ పరిమాణం. అది Ollama default కాదు. Ollama దీనికంటే చాలా చిన్న window ను ఉపయోగిస్తుంది. Conversation ఆ పరిమితిని దాటినప్పుడు, ఎటువంటి error చూపకుండా పాత tokens ను తొలగిస్తుంది. దాంతో agent తన స్వంత instructions ను మర్చిపోయినట్లు కనిపిస్తుంది. systemd serviceపై OLLAMA_CONTEXT_LENGTH ను సెట్ చేయండి. లేదా ప్రతి requestకు num_ctx ను పంపండి. దీన్ని దశలవారీగా పెంచి, ప్రతిసారి ollama ps ను మళ్లీ పరిశీలించండి. ఎందుకంటే KV cache memory window పరిమాణానికి అనుగుణంగా పెరుగుతుంది. దాంతో model layers GPU నుంచి బయటకు తరలించబడవచ్చు.

Nemotron 3.5 Lightning ను వాణిజ్యపరంగా ఉచితంగా ఉపయోగించవచ్చా?

NVIDIA model card ప్రకారం ఈ model OpenMDW-1.1 license కింద అందుబాటులో ఉంది. అలాగే ఇది commercial useకు సిద్ధంగా ఉందని పేర్కొంది. మీరు స్వయంగా download చేసి run చేసే weightsకు ఇది వర్తిస్తుంది. మీ stackలోని ఇతర softwareకు ఇది వర్తిస్తుందని ఆ model card చెప్పదు. కాబట్టి agent harness మరియు దానికి మీరు అనుసంధానించే tools యొక్క licenses ను విడిగా పరిశీలించండి. దీన్ని contractual అవసరాలకు ఉపయోగించే ముందు ప్రస్తుత model card ను చదవండి.