సొంతంగా AI మోడల్స్ రన్ చేయడం ఎలా?

ఏ AI మోడల్స్‌ను మీరు self-host చేయగలరో నిర్ణయించే అంశాలు

మీరు ఏ AI మోడల్స్‌ను self-host చేయగలరో అనేది ఒకే ఒక సంఖ్యపై ఆధారపడి ఉంటుంది: అదే మీ సర్వర్‌లోని RAM. మోడల్ ఫ్యామిలీ లేదా ఫ్రేమ్‌వర్క్ కంటే, మోడల్ వెయిట్స్ (weights) మెమరీలో సరిపోయి, అదనంగా కొంత స్థలం మిగిలి ఉందా లేదా అన్నదే ముఖ్యం. ఈ పోస్ట్ ఆ గణనను ఎలా చేయాలో వివరిస్తుంది. రన్‌టైమ్‌ను ఇన్‌స్టాల్ చేయడం అనేది వేరే పని, దీని గురించి VPSలో Ollama రన్ చేయడానికి గైడ్ లో చూడవచ్చు.

రెండు ఖర్చులు ఈ నిర్ణయాన్ని ప్రభావితం చేస్తాయి. వెయిట్స్ అనేవి స్థిరమైన ఖర్చు (fixed cost), ఇవి పారామీటర్ల సంఖ్య మరియు క్వాంటైజేషన్ (quantisation) ద్వారా నిర్ణయించబడతాయి. కాంటెక్స్ట్ విండో (context window) అనేది రన్నింగ్ కాస్ట్, దీనిని చాలామంది మర్చిపోతుంటారు; ఫలితంగా నిన్న లోడ్ అయిన మోడల్, ఈరోజు లోడ్ అవ్వడానికి నిరాకరిస్తుంది.

పరిమాణ గణన: పారామీటర్‌కు బిట్స్

మోడల్ ఫైల్ దాదాపు పూర్తిగా వెయిట్స్‌తోనే ఉంటుంది. ప్రతి వెయిట్ కొంత సంఖ్యలో బిట్స్‌లో నిల్వ చేయబడుతుంది. క్వాంటైజేషన్ (Quantisation) అంటే వాటిని శిక్షణ పొందిన ప్రిసిషన్ కంటే తక్కువ బిట్స్‌లో నిల్వ చేయడం; దీనివల్ల స్వల్పంగా కచ్చితత్వం తగ్గినప్పటికీ, మెమరీ గణనీయంగా ఆదా అవుతుంది. ఫైల్ పరిమాణం దీనిపైనే ఆధారపడి ఉంటుంది:

weights in GB = (parameters in billions x bits per weight) / 8

మోడల్స్ 16 బిట్స్ వద్ద విడుదలవుతాయి, అంటే ప్రతి బిలియన్ పారామీటర్లకు 2 GB మెమరీ అవసరం. అందుకే VPS లలో ఎవరూ విడుదలైన ప్రిసిషన్ వద్ద వీటిని రన్ చేయరు. మీరు సాధారణంగా ఎదుర్కొనే క్వాంటైజేషన్లు మరియు వాటి సగటు బిట్స్ పర్ వెయిట్ వివరాలు ఇక్కడ ఉన్నాయి:

• Q8_0 వెయిట్‌కు సుమారు 8.5 బిట్స్ నిల్వ చేస్తుంది, అంటే బిలియన్ పారామీటర్లకు సుమారు 1.1 GB.
• Q6_K సుమారు 6.6 బిట్స్ నిల్వ చేస్తుంది, అంటే బిలియన్ పారామీటర్లకు సుమారు 0.83 GB.
• Q5_K_M సుమారు 5.7 బిట్స్ నిల్వ చేస్తుంది, అంటే బిలియన్ పారామీటర్లకు సుమారు 0.71 GB.
• Q4_K_M సుమారు 4.8 బిట్స్ నిల్వ చేస్తుంది, అంటే బిలియన్ పారామీటర్లకు సుమారు 0.6 GB.

మీ లెక్కల కోసం బిలియన్ పారామీటర్లకు 0.6 GB ని ప్రామాణికంగా తీసుకోండి. మెమరీ పరిమితులు ఉన్న సర్వర్లలో Q4_K_M అనేది సరైన డిఫాల్ట్ ఎంపిక: చాలా పనులలో 8 బిట్స్‌తో పోలిస్తే క్వాలిటీ నష్టం తక్కువగా ఉంటుంది, మరియు ఫైల్ పరిమాణం దాదాపు సగానికి తగ్గుతుంది. 4 బిట్స్ కంటే తక్కువకు వెళ్తే క్వాలిటీ నష్టం వేగంగా పెరుగుతుంది, కాబట్టి 70B మోడల్‌ను 2 బిట్స్‌కు కుదించడం కంటే, అదే జనరేషన్‌కు చెందిన 32B మోడల్‌ను 4 బిట్స్‌లో వాడటం మెరుగైన ఫలితాలను ఇస్తుంది. మెమరీ తక్కువగా ఉన్నప్పుడు, 4 బిట్స్ కంటే తక్కువకు వెళ్లే బదులు, మోడల్ పరిమాణాన్ని (size class) తగ్గించడం మంచిది.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

పైన పేర్కొన్న వెయిట్ కాలమ్ 0.6 GB పర్ బిలియన్ నియమంపై ఆధారపడి ఉంటుంది. వాస్తవ GGUF ఫైల్స్ ఈ విలువకు కొన్ని శాతం అటుఇటుగా ఉంటాయి, ఎందుకంటే ఎంబెడ్డింగ్ మరియు అవుట్‌పుట్ లేయర్‌లను మిగిలిన వాటి కంటే ఎక్కువ ప్రిసిషన్‌లో ఉంచుతారు. 4 బిట్స్‌లో ఉన్న 3B మోడల్ సుమారు 1.8 GB ఉంటుంది. 8B మోడల్ 4.8 GB ఉంటుంది. 32B మోడల్ 19.2 GB, మరియు 70B మోడల్ 42 GB ఉంటుంది.

కాంటెక్స్ట్ లెంగ్త్ (context length) వెయిట్స్ (weights) కంటే ఎక్కువ RAM ఎందుకు తీసుకుంటుంది

KV cache (కీ వాల్యూ క్యాష్, అంటే ప్రస్తుతం సంభాషణలో ఉన్న ప్రతి టోకెన్ కోసం మోడల్ ఉంచే అటెన్షన్ స్టేట్) అనేది రెండవ ఖర్చు. మోడల్ లోడ్ అయినప్పుడు ఇది కేటాయించబడుతుంది, మీరు కోరిన కాంటెక్స్ట్ లెంగ్త్ ఆధారంగా దీని పరిమాణం ఉంటుంది, మరియు ఆ లెంగ్త్ పెరిగేకొద్దీ ఇది సరళంగా (linearly) పెరుగుతుంది.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Ollama డిఫాల్ట్ కాంటెక్స్ట్ వద్ద, ఆ 8B మోడల్ క్యాష్ కోసం అర గిగాబైట్ ఖర్చు చేస్తుంది. 8192 టోకెన్ల వద్ద అది 1 GB ఖర్చు చేస్తుంది. మోడల్ కార్డ్ పేర్కొన్న 128k కాంటెక్స్ట్ వద్ద, అది 16 GB ఖర్చు చేస్తుంది, ఇది మోడల్ వెయిట్స్ కంటే మూడు రెట్లు ఎక్కువ. 70B మోడల్ దీనికి భిన్నంగా ఉంటుంది: 128k వద్ద దాని క్యాష్ 40 GB ఉంటుంది, ఇది దాని వెయిట్స్ కంటే తక్కువ. ఎందుకంటే గ్రూప్డ్ క్వెరీ అటెన్షన్ (grouped query attention) వల్ల ప్రతి టోకెన్ ఖర్చు పారామీటర్ కౌంట్ పెరిగినంత వేగంగా పెరగదు.

CPU మాత్రమే ఉన్న సర్వర్‌లలో Ollama డిఫాల్ట్ కాంటెక్స్ట్ లెంగ్త్ 4096 టోకెన్లు. GPU ఉన్నప్పుడు, అది VRAM ఆధారంగా డిఫాల్ట్‌ను ఎంచుకుంటుంది: 24 నుండి 48 GiB మధ్య ఉంటే 32k, 48 GiB మరియు అంతకంటే ఎక్కువ ఉంటే 256k. సర్వర్‌లో OLLAMA_CONTEXT_LENGTH వేరియబుల్‌తో దీన్ని పెంచవచ్చు, ఆపై రన్ అవుతున్న మోడల్ వాస్తవానికి ఎంత పొందిందో ollama ps లోని CONTEXT కాలమ్‌లో తనిఖీ చేయవచ్చు. ఆ ఒక్క సెట్టింగ్ వెనుక ఉన్న మెమరీ గణన గురించి num_ctx మరియు కాంటెక్స్ట్ లెంగ్త్ పై పోస్ట్ లో వివరించబడింది.

క్యాష్ వినియోగాన్ని తగ్గించడానికి రెండు మార్గాలు ఉన్నాయి. మోడల్ కార్డ్ పేర్కొన్న కాంటెక్స్ట్ కాకుండా, మీకు అవసరమైన కాంటెక్స్ట్‌ను మాత్రమే అడగండి, ఎందుకంటే చాలా చాట్ మరియు కోడింగ్ పనులు 8k నుండి 32k లోపు సరిపోతాయి. లేదా క్యాష్‌ను 8-బిట్‌లకు క్వాంటైజ్ (quantise) చేయండి, ఇది దాని పరిమాణాన్ని సగానికి తగ్గిస్తుంది, అయితే దీనివల్ల సుదీర్ఘ కాంటెక్స్ట్ రీకాల్‌లో కొంత నాణ్యత తగ్గవచ్చు.

మెమరీలో ఉన్న మోడల్ దానిని అన్‌లోడ్ చేసే వరకు RAMను ఆక్రమిస్తుంది

చివరి అభ్యర్థన తర్వాత Ollama ఒక మోడల్‌ను 5 నిమిషాల పాటు మెమరీలో ఉంచి, ఆపై అన్‌లోడ్ చేస్తుంది. ఈ డిఫాల్ట్ సెట్టింగ్ ల్యాప్‌టాప్‌లకు సరిపోతుంది, కానీ సర్వర్‌లకు ఇది సరైనది కాదు. ఎందుకంటే సర్వర్‌లో ప్రతి idle గ్యాప్ తర్వాత వచ్చే మొదటి అభ్యర్థన మళ్లీ లోడ్ సమయాన్ని తీసుకుంటుంది.

ollama ps
ollama stop qwen3:4b

ollama ps ప్రస్తుతం మెమరీలో ఉన్న వాటిని జాబితా చేస్తుంది. ఇందులో SIZE కాలమ్ అది ఎంత మెమరీని ఆక్రమిస్తుందో, UNTIL కాలమ్ అది ఎప్పుడు ఎక్స్‌పైర్ అవుతుందో చూపుతాయి. ఒక మోడల్‌ను శాశ్వతంగా పిన్ (pin) చేయడానికి, సర్వీస్‌పై OLLAMA_KEEP_ALIVE=-1 సెట్ చేయండి. 0 విలువను ఇస్తే, ప్రతి రెస్పాన్స్ పూర్తయిన వెంటనే అది అన్‌లోడ్ అవుతుంది.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

ఒక ప్రాంప్ట్‌ను పంపి, పది నిమిషాల తర్వాత మళ్లీ ollama ps రన్ చేయండి. మోడల్ ఇంకా జాబితాలోనే ఉంటుంది, ఇదే దీని ముఖ్య ఉద్దేశ్యం: ఎవరూ ఉపయోగించకపోయినా అది ఆ RAMను ఆక్రమించి ఉంటుంది. పిన్ చేసిన మోడల్ ఖాళీ సామర్థ్యం (spare capacity) కాదు. 16 GB VPSలో, 8k కాంటెక్స్ట్‌తో ఉన్న 8B మోడల్ సర్వీస్ నడుస్తున్నంత సేపు సుమారు 6 GBని ఆక్రమిస్తుంది. కాబట్టి, కేవలం మోడల్ పరిమాణాన్ని మాత్రమే కాకుండా, మోడల్ మరియు మీ అప్లికేషన్ రెండింటినీ కలిపి సర్వర్ సామర్థ్యాన్ని లెక్కించండి. మెమరీలో మోడల్‌ను పిన్ చేయడం అనే విభాగం కోల్డ్ స్టార్ట్ లేటెన్సీకి మరియు మెమరీ వినియోగానికి మధ్య ఉన్న సమతుల్యతను వివరిస్తుంది.

4 GB VPS లో ఏమి నడుస్తాయి

ఆపరేటింగ్ సిస్టమ్ మరియు మోడల్ సర్వర్ కోసం సుమారు 1 GB ని కేటాయించండి, దీనివల్ల దాదాపు 3 GB మిగులుతుంది. ఇది 4-bit క్వాంటైజేషన్ వద్ద 1B నుండి 4B మోడల్ పరిమాణానికి మరియు డిఫాల్ట్ 4096 టోకెన్ కాంటెక్స్ట్‌కు సరిపోతుంది. ఆగస్టు 2026 నాటికి, ఈ తరగతిలో Llama 3.2 (3B), Qwen 3 (1.7B మరియు 4B), మరియు చిన్న Gemma, Phi విడుదలలు ఉన్నాయి. వీటిని కేవలం పరిమాణ ఉదాహరణలుగా మాత్రమే చూడండి, సిఫార్సులుగా కాదు. మోడల్ పేర్లు కొన్ని నెలలకోసారి మారుతుంటాయి, కానీ గణితం మారదు.

సెకనుకు సుమారుగా 6 నుండి 14 టోకెన్లు వస్తాయని ఆశించవచ్చు. ఇంత చిన్న మోడల్స్ పరిమితమైన పనులను బాగా చేస్తాయి: వర్గీకరణ (classification), ట్యాగ్ ఎక్స్‌ట్రాక్షన్, చిన్న సారాంశాలు, ఒక పేరాను నిర్దిష్ట శైలిలోకి మార్చడం వంటివి. ఇవి బహుళ దశల తార్కిక విశ్లేషణ (multi-step reasoning) మరియు అనేక ఫైళ్లతో కూడిన కోడింగ్ పనులలో బలహీనంగా ఉంటాయి; ఎంత మంచి ప్రాంప్టింగ్ చేసినా వీటిని మెరుగుపరచలేము.

ఈ స్థాయిలో వైఫల్యానికి ప్రధాన కారణం swap. మోడల్ మెమరీలో పట్టనప్పుడు, Linux దానిని లోడ్ చేయకుండా ఆపదు. బదులుగా, అది మెమరీని డిస్క్‌లోకి swap చేస్తుంది. ప్రతి టోకెన్‌ను రూపొందించేటప్పుడు అన్ని వెయిట్స్ (weights) ఒకసారి చదవబడతాయి కాబట్టి, జనరేషన్ వేగం సెకనుకు ఒక టోకెన్ కంటే తక్కువకు పడిపోతుంది. మోడల్ సమాధానం ఇస్తున్నప్పుడు free -h ను మరియు vmstat 1 లోని si, so కాలమ్స్‌ను గమనించండి. జనరేషన్ సమయంలో swap in మరియు swap out విలువలు సున్నా కంటే ఎక్కువగా ఉంటే, ఆ మోడల్ మీ ప్లాన్‌కు చాలా పెద్దదని అర్థం.

8 GB నుండి 16 GB VPS పై ఏమి నడుస్తాయి

ఇక్కడే self-hosted మోడల్ సాధారణంగా ఉపయోగకరంగా మారుతుంది. 8 GB RAM ఉన్నప్పుడు, మీరు 4 bits వద్ద 7B లేదా 8B మోడల్‌ను, సుమారు 4.8 GB బరువులతో (weights), 8k context తో నడపవచ్చు. 16 GB RAM ఉన్నప్పుడు, మీరు 4 bits వద్ద 13B లేదా 14B మోడల్‌ను, సుమారు 8.4 GB బరువులతో నడపవచ్చు; లేదా పారామీటర్ సంఖ్య కంటే precision (ఖచ్చితత్వం) ముఖ్యమనుకుంటే, 8B మోడల్‌ను 8 bits వద్ద నడపవచ్చు.

వేగం ఇక్కడ ప్రధాన సమస్య. CPU పై 8B మోడల్ సెకనుకు సుమారు 3 నుండి 7 టోకెన్లను, మరియు 14B మోడల్ సుమారు 1.5 నుండి 3.5 టోకెన్లను ఉత్పత్తి చేస్తుంది. ఒక మనిషి సెకనుకు సుమారు 5 నుండి 10 టోకెన్ల వేగంతో చదవగలడు, కాబట్టి CPU VPS పై 8B మోడల్ నెమ్మదిగా టైప్ చేస్తున్న వ్యక్తిని చూస్తున్నట్లు అనిపిస్తుంది. ఇది బ్యాక్‌గ్రౌండ్ పనులకు సరిపోతుంది కానీ, ఇంటరాక్టివ్ చాట్ కోసం అయితే అలసట కలిగిస్తుంది. VPS పై Qwen 3 (8B మరియు అంతకంటే పెద్దవి) నడిపినప్పుడు వచ్చిన ఫలితాలు ఆచరణలో ఇది ఎలా ఉంటుందో చూపుతాయి.

32 GB నుంచి 64 GB VPS పై ఏమి నడుస్తాయి

4 bits వద్ద 32B మోడల్ సుమారు 19.2 GB ఉంటుంది, కాబట్టి ఇది తక్కువ context తో 32 GB ప్లాన్‌పై సరిపోతుంది మరియు 48 GB లేదా 64 GB ప్లాన్‌లపై సౌకర్యవంతంగా నడుస్తుంది. 4 bits వద్ద 70B మోడల్ సుమారు 42 GB ఉంటుంది, కాబట్టి ఎటువంటి cache జోడించకముందే దీనికి 64 GB అవసరం.

ఆ తర్వాత వేగాన్ని వాస్తవికంగా గమనించండి. CPU పై 32B మోడల్ సెకనుకు 0.6 నుంచి 1.5 tokens వేగంతో నడుస్తుంది, అదే 70B మోడల్ అయితే 0.2 నుంచి 0.5 వేగంతో నడుస్తుంది. ఆ 70B మోడల్ నుంచి 500 tokens సమాధానం రావడానికి సుమారు ఇరవై నిమిషాలు పడుతుంది. ఆ వేగంతో, మోడల్ పూర్తి చేసేలోపే అభ్యర్థన (request) సాధారణంగా ముగిసిపోతుంది, ఎందుకంటే Ollama ముందు ఉండే ఏదైనా client లేదా proxy timeout ముందుగా పనిచేస్తుంది, దీనివల్లనే the context deadline exceeded error వస్తుంది. ఇవి batch పనుల కోసం ఉద్దేశించిన సాధనాలు. రాత్రిపూట పత్రాల క్యూను వీటికి అందిస్తే వేగం పెద్దగా సమస్య కాదు. వీటిని chat window వెనుక ఉంచితే మాత్రం వేగం చాలా కీలకం అవుతుంది.

Mixture of experts (MoE) routing ఈ లెక్కలను మారుస్తుంది, ఇది నేర్చుకోవలసిన ఒక ముఖ్యమైన architecture వివరము. ఒక MoE మోడల్ ప్రతి token ను దాని weights లోని ఒక చిన్న భాగం ద్వారా మాత్రమే పంపుతుంది. మొత్తం 30B parameters ఉండి, ప్రతి token కు 3B active parameters ఉన్న మోడల్‌కు 30B మోడల్‌కు సరిపడా memory అవసరం, కానీ ఇది దాదాపు 3B dense మోడల్ వేగంతో సమాధానాలను ఉత్పత్తి చేస్తుంది, ఎందుకంటే ప్రతి token కేవలం active experts ను మాత్రమే చదువుతుంది. 32 GB సర్వర్‌పై ఇటువంటి MoE మోడల్, dense 30B మోడల్ కంటే చాలా మెరుగ్గా పనిచేస్తుంది. గుర్తుంచుకోవలసిన నియమం: మొత్తం parameters memory ని నిర్ణయిస్తాయి, active parameters వేగాన్ని నిర్ణయిస్తాయి.

CPU inference నిజానికి ఎంత వేగంగా ఉంటుంది?

ఒక token ను generate చేయడానికి ప్రతి active weight ను memory నుంచి ఒకసారి చదవాల్సి ఉంటుంది. దీనిని తప్పించుకోవడం సాధ్యం కాదు, కాబట్టి CPU పై generation వేగం అనేది core ల సంఖ్యపై కాకుండా memory bandwidth పై ఆధారపడి ఉంటుంది. దీని గరిష్ట పరిమితి ఒక విభజన: అందుబాటులో ఉన్న memory bandwidth ను bytes లో ఉన్న weights పరిమాణంతో భాగించాలి. ఒక చిన్న shared VPS సాధారణంగా దాని vCPU ల ద్వారా సెకనుకు 10 నుంచి 25 GB bandwidth ను అందిస్తుంది, కాబట్టి 4.8 GB మోడల్ సెకనుకు 2 నుంచి 5 tokens వేగంతో పనిచేస్తుంది.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

ఇవి సాధారణ VPS హార్డ్‌వేర్‌పై కనిపించే పరిధులు, ఒకే యంత్రానికి సంబంధించిన benchmark కాదు. మీ ఫలితం memory తరం (generation), హోస్ట్‌లోని channel ల సంఖ్య మరియు మీతో పాటు ఎంతమంది ఇతర వినియోగదారులు ఆ వనరుల కోసం పోటీ పడుతున్నారు అనే దానిపై ఆధారపడి ఉంటుంది. మీ వద్ద ఉన్న ఏదైనా model tag ఉపయోగించి మీరే స్వయంగా కొలవండి:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

సమాధానం ముగిసిన తర్వాత ప్రింట్ అయ్యే సారాంశం eval rate: ... tokens/s అని ఉన్న లైన్‌తో ముగుస్తుంది. అదే మీ generation వేగం. ఒక session లో మొదటిసారి రన్ చేసినప్పుడు వచ్చే ఫలితాన్ని పరిగణనలోకి తీసుకోకండి, ఎందుకంటే అదే సారాంశంలో ఉన్న load duration లో disk నుంచి weights ను చదివిన సమయం కూడా కలిసి ఉంటుంది. Tokens per second ను సరిగ్గా కొలవడం అనే విభాగం పోల్చదగ్గ సంఖ్యను ఎలా పొందాలో వివరిస్తుంది.

ఇక్కడ రెండు ఫలితాలు ప్రజలను ఆశ్చర్యపరుస్తాయి. vCPU లను పెంచడం వల్ల వేగం త్వరగానే ఆగిపోతుంది, ఎందుకంటే సుమారు 8 cores దాటిన తర్వాత అదనపు cores గణన (arithmetic) చేయడం కంటే memory కోసం వేచి చూడటమే ఎక్కువ చేస్తాయి. అలాగే, shared plan లో ఒకే command గంట గంటకు వేర్వేరు ఫలితాలను ఇస్తుంది, ఇది మీరు తప్పుగా configure చేయడం వల్ల కాదు, noisy neighbour వల్ల కలిగే CPU steal time వల్ల జరుగుతుంది.

మీ prompt ను చదవడం అనేది సమాధానాన్ని generate చేయడం కంటే భిన్నమైన పని. Prompt processing అనేది compute bound, కాబట్టి ఇది cores సంఖ్యతో పాటు పెరుగుతుంది, ఇక్కడే GPU అత్యధిక వేగాన్ని ప్రదర్శిస్తుంది. ఒక పెద్ద document ను చదవడానికి CPU కి నిమిషాల సమయం పడితే, GPU కి సెకన్ల సమయం మాత్రమే పడుతుంది. మీరు మీరు host చేసిన మోడల్‌కు coding agent ను అనుసంధానించినప్పుడు ఎదురయ్యే మొదటి అడ్డంకి ఇదే, ఎందుకంటే సమాధానం లోని మొదటి token రాకముందే ప్రతి turn లోనూ file context మరియు tool definitions మళ్ళీ పంపబడతాయి.

GPUని జోడించినప్పుడు ఏమి మారుతుంది

గణన పద్ధతి మారదు, అది వర్తించే వనరుల పరిధి మాత్రమే మారుతుంది. VRAM ఒక కఠినమైన పరిమితి, కాబట్టి మీరు అద్దెకు తీసుకునే ముందు ఏది సరిపోతుందో లెక్కించుకోండి:

• 8 GB VRAM అనేది 4 bits వద్ద 7B లేదా 8B మోడల్‌ను తక్కువ contextతో ఉంచగలదు.
• 16 GB VRAM అనేది 4 bits వద్ద 14B మోడల్‌ను సరైన contextతో, లేదా 8 bits వద్ద 8B మోడల్‌ను ఉంచగలదు.
• 24 GB VRAM అనేది 4 bits వద్ద 32B మోడల్‌ను తక్కువ contextతో ఉంచగలదు.
• 48 GB మరియు అంతకంటే ఎక్కువ VRAM అనేది 4 bits వద్ద 70B మోడల్‌ను, cache మరియు concurrency కోసం కొంత స్థలంతో ఉంచగలదు.

ఒక మోడల్ సరిపోనప్పుడు, Ollama దానిని విభజిస్తుంది: కొన్ని layers GPUపై, మిగిలినవి CPUపై ఉంటాయి. ollama ps ఈ విభజనను దాని PROCESSOR కాలమ్‌లో 78%/22% CPU/GPU వంటి సమాచారంతో చూపుతుంది. దీనిని ఒక ఫీచర్‌గా కాకుండా హెచ్చరికగా పరిగణించండి. CPUపై ఉన్న సగం భాగం వేగాన్ని నిర్ణయిస్తుంది, ఎందుకంటే ప్రతి token ఆ layers కోసం వేచి ఉండాల్సిందే. కాబట్టి, నాలుగో వంతు layers CPUపై ఉన్న మోడల్, GPU వేగం కంటే CPU వేగానికే దగ్గరగా నడుస్తుంది. మీరు ఆశించని విధంగా విభజన జరిగితే, ముందుగా context lengthను తగ్గించండి. సాధారణంగా cache వల్లే ఈ పరిమితి దాటిపోతుంది.

Concurrency (ఏకకాలంలో వాడటం) అనేది పరిమాణాన్ని పెంచడానికి మరొక కారణం. ఒకే సమయంలో వచ్చే అభ్యర్థనల మధ్య weights పంచుకోబడతాయి, కానీ ప్రతి active అభ్యర్థనకు దాని స్వంత KV cache అవసరం. కాబట్టి, 8k context ఉన్న 8B మోడల్‌ను పదిమంది వినియోగదారులు ఏకకాలంలో వాడుతుంటే, weights తో పాటు అదనంగా పది రెట్లు 1 GB cache అవసరమవుతుంది. ఒకే self-hosted మోడల్ నుండి ఏకకాల వినియోగదారులకు సేవలు అందించడం అనే విభాగం ఆ పరిమితి ఎక్కడ ఉంటుందో వివరిస్తుంది.

GPUని అద్దెకు తీసుకోవడం లాభదాయకమా కాదా అనేది కూడా ఒక గణిత ప్రశ్న, మరియు ఇది మీరు నెలకు ఎన్ని tokens జనరేట్ చేస్తారు అనే దానిపై ఆధారపడి ఉంటుంది. GPU VPS మరియు API tokens మధ్య లాభనష్టాల విశ్లేషణ ఆ గణాంకాలను కలిగి ఉంది.

మీరు self-host చేయలేనివి

ఇక్కడ రెండు రకాల అడ్డంకులు ఉన్నాయి, మీరు దేనిని ఎదుర్కొంటున్నారో తెలుసుకోవడం సహాయకరంగా ఉంటుంది.

మొదటిది closed weights. అత్యాధునిక వాణిజ్య నమూనాలు (frontier commercial models) పంపిణీ చేయబడవు, కాబట్టి డౌన్‌లోడ్ చేయడానికి ఫైల్ ఉండదు, RAM ఎంత పెంచినా ఇది మారదు. మీరు వాటి చుట్టూ ఉన్న ప్రతిదాన్ని self-host చేయవచ్చు: interface, retrieval layer, agent loop, logs. మోడల్ మాత్రం remote API గానే ఉంటుంది. Claude ను self-host చేయవచ్చా అనే అంశం దీని గురించి పూర్తిగా వివరిస్తుంది.

రెండవది, పరిమాణంలో చాలా పెద్దవైన open weights. అతిపెద్ద open releases అనేవి వందల బిలియన్ల పారామీటర్లు కలిగిన mixture of experts డిజైన్లు. వీటికి కూడా అదే నియమం వర్తిస్తుంది: 4 bits వద్ద 400B పారామీటర్ల మోడల్‌కు, cache కు ముందే కేవలం weights కోసమే సుమారు 240 GB అవసరం. ఇది ప్రత్యేకమైన హార్డ్‌వేర్, దీనిని నెలవారీ అద్దెకు తీసుకోవడం అనేది చాలా మంది ఏడాదికి API tokens కోసం ఖర్చు చేసే దానికంటే ఎక్కువ. Kimi తరగతి మోడల్‌ను self-host చేయడానికి కావాల్సినవి అనే కథనం దీనికి అవసరమైన వాస్తవ అవసరాలను వివరిస్తుంది. ఇదే విభజన Ollama లైబ్రరీలో కూడా కనిపిస్తుంది, అక్కడ GLM 5.2 కేవలం cloud మోడల్‌గా మాత్రమే జాబితా చేయబడింది మరియు దానికంటే చాలా చిన్నదైన మోడల్ మాత్రమే VPS లోకి డౌన్‌లోడ్ అవుతుంది.

ఈ రెండింటి మధ్య నిజాయితీ గల విభజన ఇది: లోడ్ స్థిరంగా ఉన్నప్పుడు మరియు డేటా మీ సర్వర్‌ను దాటి వెళ్లకూడదు అనుకున్నప్పుడు self-host చేయండి. లోడ్ అస్థిరంగా ఉన్నప్పుడు లేదా మీకు అత్యుత్తమ నాణ్యత గల సమాధానాలు అవసరమైనప్పుడు tokens కొనుగోలు చేయండి.

ఎంచుకునే ముందు మీ వద్ద ఏముందో తనిఖీ చేయండి

free -h
nproc
lscpu | grep 'Model name'

free -h యొక్క available కాలమ్ ఆధారంగా ప్రణాళిక వేసుకోండి, total కాలమ్ ఆధారంగా కాదు. ఎందుకంటే total లో సిస్టమ్ ఇప్పటికే వాడుతున్న మెమరీ కూడా కలిసి ఉంటుంది. ఆపరేటింగ్ సిస్టమ్ మరియు మోడల్ సర్వర్ కోసం సుమారు 1 GB మెమరీని మినహాయించండి. మిగిలిన మొత్తాన్ని 0.6 తో భాగించండి; దీనివల్ల మీరు 4 bits వద్ద ఉంచగలిగే గరిష్ట పారామీటర్ల సంఖ్య (బిలియన్లలో) తెలుస్తుంది. ఆ తర్వాత, మీకు కావలసిన కాంటెక్స్ట్ కోసం KV cache ను మినహాయించండి. మిగిలినదే మీ సమాధానం. మోడల్ పేర్ల జాబితా లాగా ఇది పాతబడిపోదు.

FAQ

8B మోడల్‌ను రన్ చేయడానికి నాకు ఎంత RAM అవసరం?

4-bit క్వాంటైజేషన్ వద్ద వెయిట్స్ (weights) కోసం సుమారు 4.8 GB, మీ కాంటెక్స్ట్ లెంగ్త్ కోసం KV కాష్, మరియు ఆపరేటింగ్ సిస్టమ్ అలాగే మోడల్ సర్వర్ కోసం అదనంగా సుమారు 1 GB RAM అవసరం. 8192 టోకెన్ కాంటెక్స్ట్ వద్ద, కాష్ సుమారు 1 GB అదనపు మెమరీని తీసుకుంటుంది, కాబట్టి 8 GB ప్లాన్ సరిపోతుంది కానీ 4 GB ప్లాన్ సరిపోదు. మోడల్ కార్డ్ పేర్కొన్న పూర్తి 128k కాంటెక్స్ట్ మీకు కావాలంటే, కాష్ మాత్రమే 16 GB తీసుకుంటుంది, కాబట్టి మీరు 32 GB ప్లాన్‌ను ఎంచుకోవాల్సి ఉంటుంది.

VPSలో తగినన్ని vCPUలు ఉన్నప్పటికీ నా మోడల్ ఎందుకు నెమ్మదిగా ఉంది?

ఎందుకంటే జనరేషన్ అనేది కోర్ల (cores) మీద కాకుండా, మెమరీ బ్యాండ్‌విడ్త్ మీద ఆధారపడి ఉంటుంది. ప్రతి టోకెన్ జనరేట్ కావడానికి మొత్తం యాక్టివ్ వెయిట్ సెట్‌ను RAM నుండి తీసుకోవాల్సి ఉంటుంది, కాబట్టి కొన్ని కోర్లు మెమరీ ఛానెల్స్‌ను పూర్తిగా వాడటం మొదలుపెట్టాక, మిగిలిన కోర్లు వేచి ఉండాల్సి వస్తుంది. మరొక సాధారణ కారణం swap. మోడల్ సమాధానం ఇస్తున్నప్పుడు vmstat 1 కమాండ్‌లో si మరియు so విలువలు సున్నా కాకుండా ఉంటే, వెయిట్స్ RAMలో సరిపోవడం లేదని అర్థం. అప్పుడు ప్రతి టోకెన్ కొంత భాగం డిస్క్ నుండి సర్వ్ అవుతుంది, ఇది ఊహించిన దానికంటే చాలా ఎక్కువ సమయాన్ని తీసుకుంటుంది.

ఎక్కువ కాంటెక్స్ట్ విండోకు నిజంగానే ఎక్కువ మెమరీ అవసరమా?

అవును, టోకెన్ల సంఖ్య పెరిగేకొద్దీ మెమరీ అవసరం సరళంగా (linearly) పెరుగుతుంది. ఒక సాధారణ 8B మోడల్ ప్రతి టోకెన్‌కు సుమారు 128 KiB KV కాష్‌ను తీసుకుంటుంది, కాబట్టి 8192 టోకెన్లకు 1 GB మరియు 131072 టోకెన్లకు 16 GB ఖర్చవుతుంది. సంభాషణ పెరిగే కొద్దీ కాకుండా, మోడల్ లోడ్ అయినప్పుడే ఈ కాష్ కేటాయించబడుతుంది. కాబట్టి మీరు 128k కాంటెక్స్ట్‌ను అడిగితే, మీరు పంపే ప్రాంప్ట్ కేవలం 200 టోకెన్ల పొడవు ఉన్నప్పటికీ, ఆ మెమరీ వెంటనే రిజర్వ్ చేయబడుతుంది.

నేను పెద్ద మోడల్‌ను 2 bits వద్ద రన్ చేయాలా లేదా చిన్న మోడల్‌ను 4 bits వద్ద రన్ చేయాలా?

చిన్న మోడల్‌ను 4 bits వద్ద ఎంచుకోండి. 8 bits నుండి 4 bits వరకు క్వాలిటీ నెమ్మదిగా తగ్గుతుంది, కానీ 4 bits కంటే తక్కువకు పడిపోతే క్వాలిటీ వేగంగా పడిపోతుంది. కాబట్టి, ఒకే మోడల్ జనరేషన్‌కు చెందిన 32B మోడల్ (4 bits) ఇచ్చే సమాధానాలు, 70B మోడల్ (2 bits) ఇచ్చే సమాధానాల కంటే మెరుగ్గా ఉంటాయి. హెవీ క్వాంటైజేషన్ వల్ల సమాధానాలు పునరావృతం కావడం లేదా సూచనలను పాటించకపోవడం వంటి సమస్యలు వస్తాయి, వీటిని మీరు ప్రాంప్ట్ లోపం అని పొరబడే అవకాశం ఉంది. 4 bits ను కనీస ప్రమాణంగా పరిగణించి, దానికి బదులుగా పారామీటర్ల సంఖ్యను మార్చండి.

పెద్ద కమర్షియల్ మోడల్స్‌తో సమానమైన సామర్థ్యం గల మోడల్‌ను నేను సొంతంగా హోస్ట్ చేయగలనా?

సాధారణ VPSలో ఇది సాధ్యం కాదు. అత్యంత శక్తివంతమైన ఓపెన్ వెయిట్ మోడల్స్ వందల బిలియన్ల పారామీటర్లను కలిగి ఉంటాయి. 4 bits వద్ద కూడా, KV కాష్‌తో సంబంధం లేకుండా వీటికి 200 GB కంటే ఎక్కువ RAM అవసరం. అలాగే, అత్యంత శక్తివంతమైన కమర్షియల్ మోడల్స్ బహిరంగంగా అందుబాటులో లేవు. సాధారణ హార్డ్‌వేర్ ఒక నిర్దిష్ట పని కోసం 8B నుండి 32B మోడల్‌ను సమర్థవంతంగా రన్ చేయగలదు; ఇక్కడ ఒక చిన్న మోడల్‌ను సరైన ప్రాంప్ట్‌లతో వాడితే, అది సాధారణ మోడల్స్‌తో సమానమైన ఫలితాలను ఇవ్వగలదు. మీకు అత్యున్నత స్థాయి క్వాలిటీ కావాలంటే, హార్డ్‌వేర్ కొనే ముందు API ధరలను మరియు హార్డ్‌వేర్ ఖర్చులను పోల్చి చూసుకోండి.