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 కు active గా ఉండేవి 3 billion. మెమరీలో పెద్ద సంఖ్యకు సంబంధించిన ఖర్చును మీరు భరిస్తారు. వేగంగా తిరిగి పొందేది చిన్న సంఖ్య.

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

NVIDIA ఈ architecture ను hybrid గా వివరిస్తుంది. ఇందులో 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 కూడా జాబితాలో ఉన్నాయి.

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

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

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 card వాటిని పట్టుకోగలిగితే GPU memoryలో ఉంటాయి. లేకపోతే system RAMలో ఉంటాయి. దీనికి అదనంగా KV cache (key/value cache, conversationలో model ప్రతి token కోసం నిర్వహించే memory) కూడా అవసరం. మీ hardwareకు అవసరమైన వాస్తవ పరిమాణాన్ని command ద్వారా తెలుసుకోవాలి. దాని వివరాలు క్రింద ఉన్నాయి. మీరు ఇంకా quantisation level ను నిర్ణయించకపోతే, Q4, Q8 మరియు FP16లో ప్రతి దానికి ఎంత ఖర్చవుతుందో అనే విభాగంలో ప్రతి దశలో ఏమి కోల్పోతారో వివరించబడింది.

ఖచ్చితమైన tag ను pull చేయండి; 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, ollama user గా నడిచే systemd service ను ఏర్పాటు చేస్తుంది. Models ను /usr/share/ollama/.ollama/models కింద ఉంచుతుంది. చాలా VPS images లో ఆ path root filesystem పై ఉంటుంది. కాబట్టి 25 GB అడగడానికి ముందు ఖాళీని పరిశీలించండి. ఆ filesystem లో ఖాళీ తక్కువగా ఉంటే, pull ప్రారంభించే ముందు Ollama తన models ను ఎక్కడ నిల్వ చేస్తుంది, వాటిని ఎలా తరలించాలి అనే సమాచారాన్ని చదవడం మంచిది. Disk నిండిన తర్వాత చదవడం ఉపయోగకరం కాదు.

df -h /usr/share/ollama

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

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

ollama show architecture, parameter count, context length మరియు file వాస్తవంగా కలిగి ఉన్న quantisation ను చూపిస్తుంది. వీటిలో ఏదైనా library page లో ఉన్నదానితో సరిపోకపోతే, మీరు ఉద్దేశించిన tag కాకుండా వేరే 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 వంటి విభజన కనిపిస్తే అన్ని layers memoryలో సరిపోలేదని అర్థం. CPU share మీ speedను నిర్ణయిస్తుంది. అవసరాన్ని అంచనా వేయవద్దు. దాన్ని load చేసి ఈ lineను చదవండి.

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

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

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

సాధారణ ప్రయోజనాల కోసం ఉపయోగించే VPSలో GPU ఉండదు. అందువల్ల మొత్తం పని CPU చేస్తుంది, అవసరమైన ప్రతి weight ను system RAM నుంచి చదువుతుంది. ఇక్కడ MoE ఉపయోగపడుతుంది. 30 billion parameters లో ప్రతి token కు సుమారు 3 billion parameters మాత్రమే ఉపయోగించబడతాయి. అందువల్ల ప్రతి token కు అవసరమైన గణన, dense 30B model కంటే చాలా తక్కువగా ఉంటుంది. 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ను దీనిపై ఆధారపడి అమలు చేయడానికి ముందు, స్థానిక LLMకు ప్రతి సెకనుకు tokens కొలిచే విధానం ఉపయోగించి వేగాన్ని కొలవండి:

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

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

[
  {
    "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 నివేదించిన ప్రతి 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ను అద్దెకు తీసుకోండి. Agent రాత్రిపూట schedule ప్రకారం నడుస్తూ, దాన్ని ఎవరూ పర్యవేక్షించకపోతే, ఎక్కువ RAM ఉన్న CPU plan సరైన ఎంపిక. ఏది ఎంచుకున్నా setup ఒకటే. VPSపై Ollamaను నడపడంలో plan sizing, అలాగే tokenకు API providerకు చెల్లించడంతో పోలిస్తే GPU instance ఎలా ఉంటుందో వివరించారు. Break-even అనేది utilisationపై ఆధారపడి ఉంటుంది. GPU instance ఉన్న ప్రతి గంటకు billing చేస్తుంది. API tokens మాత్రం ఉపయోగించినప్పుడు మాత్రమే billing అవుతాయి. అందువల్ల రోజులో ఎక్కువ సమయం పనిచేసే agentకు మీరు స్వంతంగా నిర్వహించే server అనుకూలంగా ఉంటుంది. గంటకు రెండుసార్లు మాత్రమే అమలయ్యే agentకు సాధారణంగా అది అనుకూలంగా ఉండదు.

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

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

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

sudo systemctl edit ollama

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

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

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

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

ఈ model కోసం Ollama విడుదల చేసిన post లో, ఇప్పటికే ఈ model ను లక్ష్యంగా ఎంచుకున్న 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 harnesses దీనిని అంగీకరిస్తాయి:

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

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

Pull వెంటనే విఫలమవుతుంది. Error: pull model manifest: file does not exist అంటే ఆ tag ఉనికిలో లేదు. Tag పేర్లు ఖచ్చితమైన strings. అందువల్ల quantisation suffix ను ఊహించకుండా library page నుంచి ఒక పేరును 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 ను చేతితో కూడా start చేసి ఉంటే, రెండవ 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 నిశ్శబ్దంగా తొలగించబడ్డాయి. OLLAMA_CONTEXT_LENGTH విలువను పెంచండి. Model ఇప్పటికీ సరిపోతుందో ollama ps తో నిర్ధారించండి. ఇక సరిపోకపోతే, పరిష్కారం window ను చిన్నదిగా చేయడం కాదు; పెద్ద machine ఉపయోగించడం.

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

చిన్న పనికి 30B MoEని హోస్ట్ చేయడం పెద్ద వనరుల అవసరాన్ని కలిగిస్తుంది. 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 scaling పరిమితికి చేరుతుంది.

FAQ

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

nemotron-3.5-lightning:30b-a3b-q4_K_M ను ఉపయోగించండి. దీని పరిమాణం 25 GB. ఇది పూర్తి 1M maximum context కు మద్దతు ఇస్తుంది. August 2026 నాటికి latest, 30b మరియు 30b-a3b tags సూచించే అదే digest దీనికి ఉంటుంది. latest ను pull చేయడం బదులు tag పేరును స్పష్టంగా ఇవ్వండి. లేకపోతే భవిష్యత్తులో ఆ 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పై load అయిందో చూపిస్తుంది. Default tag download పరిమాణం 25 GB మాత్రమే కనీస పరిమితి. KV cache అదనంగా చేరుతుంది. మీరు సెట్ చేసిన context window పెరిగే కొద్దీ అది కూడా పెరుగుతుంది. Plan పరిమాణం సరిపోకపోతే Ollama model requires more system memory తో విఫలమై, రెండు పరిమాణాలను చూపిస్తుంది.

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

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

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

1M model యొక్క maximum. అది 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 గురించి ఇందులో ఏమీ చెప్పలేదు. అందువల్ల agent harness మరియు దానికి అనుసంధానించే tools యొక్క licencesను విడిగా పరిశీలించండి. ఒప్పందపరమైన ఉపయోగానికి దీనిపై ఆధారపడే ముందు ప్రస్తుత model cardను చదవండి.