నా RAMతో ఏ AI model ను self-host చేయగలను?

ఏ AI models ను మీరు self-host చేయగలరో నిర్ణయించేది

మీరు self-host చేయగల AI models ను ఒకే సంఖ్య నిర్ణయిస్తుంది: ఆ server లోని RAM. Weights memoryలో కొంత ఖాళీ మిగిలేలా సరిపోతాయా లేదా అన్నదే ముఖ్యమైన విషయం. Model family మరియు framework ప్రభావం దీనికంటే చాలా తక్కువ. దీన్ని లెక్కించడం ఎలాగో ఈ post వివరిస్తుంది. Runtime install చేయడం వేరే పని. దాని కోసం VPSలో Ollama నడపడానికి guide చూడండి.

ఈ నిర్ణయాన్ని రెండు ఖర్చులు ప్రభావితం చేస్తాయి. Weights స్థిర ఖర్చు. ఇది parameter count మరియు quantisation ఆధారంగా నిర్ణయించబడుతుంది. Context window నడుస్తున్న సమయంలో వచ్చే ఖర్చు. నిన్న load అయిన model ఈరోజు load కావడానికి నిరాకరించే వరకు చాలామంది దీనిని మర్చిపోతారు.

పరిమాణ గణన: ఒక్కో parameter కు bits

ఒక model file దాదాపు పూర్తిగా weights తోనే ఉంటుంది. ప్రతి weight ను నిర్దిష్ట సంఖ్యలో bits తో నిల్వ చేస్తారు. Quantisation అంటే training సమయంలో ఉపయోగించిన precision కంటే తక్కువ bits తో weights ను నిల్వ చేయడం. దీనివల్ల accuracy కొద్దిగా తగ్గుతుంది, కానీ memory వినియోగం గణనీయంగా తగ్గుతుంది. పరిమాణం నేరుగా ఈ సూత్రాన్ని అనుసరిస్తుంది:

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

Models ను 16 bits వద్ద విడుదల చేస్తారు. అంటే ప్రతి billion parameters కు 2 GB అవసరం. అందువల్ల VPS పై release precision ను దాదాపు ఎవరూ ఉపయోగించరు. మీరు వాస్తవంగా ఎదుర్కొనే quantisations ఇవి. ఒక్కో weight కు వీటి నిజమైన సగటు bits ఇవి:

• Q8_0 ఒక్కో weight కు సుమారు 8.5 bits నిల్వ చేస్తుంది. కాబట్టి ప్రతి billion parameters కు సుమారు 1.1 GB అవసరం.
• Q6_K సుమారు 6.6 bits నిల్వ చేస్తుంది. కాబట్టి ప్రతి billion parameters కు సుమారు 0.83 GB అవసరం.
• Q5_K_M సుమారు 5.7 bits నిల్వ చేస్తుంది. కాబట్టి ప్రతి billion parameters కు సుమారు 0.71 GB అవసరం.
• Q4_K_M సుమారు 4.8 bits నిల్వ చేస్తుంది. కాబట్టి ప్రతి billion parameters కు సుమారు 0.6 GB అవసరం.

మీ లెక్కల్లో ప్రతి billion parameters కు 0.6 GB ను ఉపయోగించండి. Memory పరిమితి ఉన్న box పై Q4_K_M సాధారణంగా సరైన default. చాలా tasks లో 8 bits తో పోలిస్తే quality loss తక్కువగా ఉంటుంది. File పరిమాణం దాదాపు సగానికి తగ్గుతుంది. 4 bits కంటే దిగువకు వెళ్తే loss వేగంగా పెరుగుతుంది. అందువల్ల అదే generation కు చెందిన 70B model ను 2 bits కు కుదిస్తే, 4 bits వద్ద ఉన్న 32B model కంటే సాధారణంగా తక్కువ నాణ్యతతో సమాధానం ఇస్తుంది. Memory తక్కువగా ఉన్నప్పుడు 4 bits కంటే దిగువకు వెళ్లే బదులు ఒక 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
  }
]

పైన ఉన్న weight column కు 0.6 GB per billion అనే నియమాన్ని వర్తింపజేశారు. వాస్తవ GGUF files ఈ విలువకు కొన్ని శాతం లోపలే ఉంటాయి. కారణం, embedding మరియు output layers ను మిగతా భాగాల కంటే ఎక్కువ precision వద్ద ఉంచుతారు. 4 bits వద్ద ఉన్న 3B model సుమారు 1.8 GB ఉంటుంది. 8B model 4.8 GB ఉంటుంది. 32B model 19.2 GB ఉంటుంది. 70B model 42 GB ఉంటుంది.

సందర్భ పొడవుకు weights కంటే ఎక్కువ RAM ఎందుకు అవసరం

KV cache (key value cache; ప్రస్తుతం సంభాషణలో ఉన్న ప్రతి token కోసం model నిర్వహించే attention state) రెండవ ప్రధాన ఖర్చు. Model load అయినప్పుడు ఇది allocate అవుతుంది. మీరు కోరిన context length కు అనుగుణంగా దీని పరిమాణం నిర్ణయించబడుతుంది. ఆ length పెరిగే కొద్దీ ఇది సరళ రేఖలో పెరుగుతుంది.

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

Ollama default context వద్ద ఆ 8B model cache కోసం అర gigabyte RAM ఉపయోగిస్తుంది. 8192 tokens వద్ద ఇది 1 GB ఉపయోగిస్తుంది. Model card ప్రకటించిన 128k context వద్ద ఇది 16 GB ఉపయోగిస్తుంది. ఇది weights కంటే మూడు రెట్లకంటే ఎక్కువ. 70B విషయంలో పరిస్థితి విరుద్ధంగా ఉంటుంది. 128k వద్ద దాని cache 40 GB ఉంటుంది. ఇది దాని స్వంత weights కంటే తక్కువ. Grouped query attention కారణంగా ప్రతి token కు అయ్యే ఖర్చు parameter count పెరుగుదలంత వేగంగా పెరగదు.

CPU మాత్రమే ఉన్న server లో Ollama default context length 4096 tokens. GPU ఉన్నప్పుడు ఇది VRAM ఆధారంగా default ఎంచుకుంటుంది: 24 మరియు 48 GiB మధ్య ఉంటే 32k, 48 GiB లేదా అంతకంటే ఎక్కువ ఉంటే 256k. Server పై OLLAMA_CONTEXT_LENGTH variable ను ఉపయోగించి దీన్ని పెంచవచ్చు. తరువాత నడుస్తున్న model వాస్తవంగా ఏ విలువ పొందిందో ollama ps లోని CONTEXT column లో చూడాలి. ఆ ఒక్క setting వెనుక ఉన్న memory లెక్కలను num_ctx మరియు context length పై post లో వివరించారు.

Cache పరిమాణాన్ని తగ్గించడానికి రెండు మార్గాలు ఉన్నాయి. Model card ప్రకటించిన context కంటే మీకు అవసరమైన context ను మాత్రమే కోరండి. చాలా chat మరియు coding పనులు 8k నుంచి 32k లోపలే పూర్తవుతాయి. లేదా cache ను 8 bits కు quantise చేయండి. దీనివల్ల cache పరిమాణం సగానికి తగ్గుతుంది. అయితే long context recall కొంత తగ్గవచ్చు.

Resident model RAMలో ఏదైనా unload చేసే వరకు అలాగే ఉంటుంది

చివరి అభ్యర్థన తర్వాత Ollama ఒక model ను 5 minutes పాటు memoryలో ఉంచి, తరువాత unload చేస్తుంది. ఈ default laptopకు అనుకూలంగా ఉంటుంది. కానీ serverకు ఇది సరైనది కాదు. ఎందుకంటే ప్రతి idle gap తర్వాత వచ్చే మొదటి అభ్యర్థనకు మళ్లీ load time చెల్లించాలి.

ollama ps
ollama stop qwen3:4b

ollama ps ప్రస్తుతం memoryలో residentగా ఉన్న వాటిని చూపిస్తుంది. అందులోని SIZE column ఆ model ఎంత memoryని ఉపయోగిస్తుందో చూపిస్తుంది. UNTIL column అది ఎప్పుడు expire అవుతుందో చూపిస్తుంది. ఒక model ను శాశ్వతంగా memoryలో ఉంచాలంటే serviceపై OLLAMA_KEEP_ALIVE=-1 ను సెట్ చేయండి. 0 విలువను సెట్ చేస్తే ప్రతి response పూర్తయిన వెంటనే అది unload అవుతుంది.

sudo systemctl edit ollama.service

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

sudo systemctl daemon-reload
sudo systemctl restart ollama

ఒక prompt పంపి, 10 minutes తర్వాత మళ్లీ ollama ps ను అమలు చేయండి. ఆ model ఇప్పటికీ జాబితాలో ఉంటుంది. ఇదే ఉద్దేశం: ఎవరూ ఉపయోగించకపోయినా అది ఆ RAMను ఆక్రమించి ఉంచుతుంది. Pinned model spare capacity కాదు. 16 GB VPSలో 8B modelను 8k contextతో నడిపితే service నడుస్తున్నంతకాలం సుమారు 6 GB memory ఉపయోగిస్తుంది. కాబట్టి server పరిమాణాన్ని modelతో పాటు మీ application అవసరాల ఆధారంగా నిర్ణయించండి. Model ఒక్కదాని ఆధారంగా నిర్ణయించవద్దు. modelను memoryలో pin చేయడం cold start latencyతో చేయాల్సిన trade-offను వివరిస్తుంది.

4 GB VPSలో ఏమి నడుస్తుంది

Operating system మరియు model server కోసం సుమారు 1 GB కేటాయించండి. దాంతో దాదాపు 3 GB మిగులుతుంది. Default 4096 token context వద్ద 4 bitsలో 1B నుంచి 4B పరిమాణం గల model దీనిలో నడుస్తుంది. August 2026 నాటికి ఈ వర్గంలో 3B పరిమాణం గల Llama 3.2, 1.7B మరియు 4B పరిమాణాల Qwen 3, అలాగే చిన్న Gemma మరియు Phi releases ఉన్నాయి. వీటిని సిఫారసులుగా కాకుండా పరిమాణ ఉదాహరణలుగా మాత్రమే పరిగణించండి. ఈ పేర్లు ప్రతి కొన్ని నెలలకు మారుతాయి. అయితే లెక్కింపు మారదు.

సెకనుకు సుమారుగా 6 నుంచి 14 tokens వరకు వేగాన్ని ఆశించండి. ఇంత చిన్న models కొన్ని పరిమిత పనులను బాగా చేస్తాయి: classification, tag extraction, short summaries, paragraph ను నిర్దిష్ట house style కు అనుగుణంగా rewriting. Multi-step reasoningలో, అనేక files లో విస్తరించిన code విషయంలో ఇవి బలహీనంగా ఉంటాయి. Prompting ఎంత చేసినా ఈ పరిమితి తొలగదు.

ఈ స్థాయిలో ప్రధాన సమస్య swap. Model memoryలో సరిపోకపోతే Linux దాన్ని load చేయడానికి నిరాకరించదు. బదులుగా memoryని diskకు page out చేస్తుంది. ఒక tokenను generate చేయడానికి ప్రతి weightను ఒకసారి చదవాలి కాబట్టి, generation వేగం tokenకు కొన్ని seconds‌కు పడిపోతుంది. Model సమాధానం ఇస్తున్నప్పుడు free -h మరియు si, so columns ను vmstat 1 లో monitor చేయండి. Generation సమయంలో swap in మరియు swap out విలువలు non-zeroగా ఉంటే, ఈ planకు model చాలా పెద్దది.

8 నుంచి 16 GB VPSలో ఏమి నడపవచ్చు

ఇక్కడ self-hosted model సాధారణంగా ఉపయోగకరంగా మారుతుంది. 8 GBలో 4 bits వద్ద 7B లేదా 8B modelను, సుమారు 4.8 GB weightsతో, 8k contextతో నడపవచ్చు. 16 GBలో 4 bits వద్ద 13B లేదా 14B modelను, సుమారు 8.4 GBతో నడపవచ్చు. లేదా parameter count కంటే precision కోసం memoryని ఉపయోగించాలనుకుంటే, 8B modelను 8 bits వద్ద ఉంచవచ్చు.

అయితే speed పరిమితిగా ఉంటుంది. CPUపై 8B model సెకనుకు సుమారు 3 నుంచి 7 tokensను generate చేస్తుంది. 14B model సెకనుకు సుమారు 1.5 నుంచి 3.5 tokensను generate చేస్తుంది. ఒక వ్యక్తి సాధారణంగా సెకనుకు 5 నుంచి 10 tokens చదువుతాడు. అందువల్ల CPU VPSపై 8B model నెమ్మదిగా type చేస్తున్న వ్యక్తిని చూస్తున్నట్లుగా అనిపిస్తుంది. Background jobకు ఇది సరిపోతుంది. Interactive chatకు ఇది అలసట కలిగిస్తుంది. VPSలో 8B మరియు అంతకంటే పెద్ద పరిమాణాల్లో Qwen 3 యొక్క కొలిచిన runs వాస్తవ వినియోగంలో ఇది ఎలా ఉంటుందో చూపిస్తాయి.

32 నుంచి 64 GB VPSలో ఏమి నడుస్తుంది

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

తర్వాత వేగాన్ని వాస్తవికంగా అంచనా వేయండి. CPUపై 32B మోడల్ సెకనుకు సుమారు 0.6 నుంచి 1.5 tokens వరకు ఉత్పత్తి చేస్తుంది. 70B మోడల్ సెకనుకు 0.2 నుంచి 0.5 tokens వరకు ఉత్పత్తి చేస్తుంది. ఆ 70B మోడల్‌తో 500 tokens సమాధానం ఇవ్వడానికి సుమారు ఇరవై నిమిషాలు పడుతుంది. ఇవి batch tools. రాత్రంతా documents queueను process చేయడానికి వీటిని ఉపయోగిస్తే వేగం పెద్ద సమస్య కాదు. కానీ వీటిని chat window వెనుక ఉంచితే వేగం చాలా ముఖ్యమవుతుంది.

Mixture of experts routing ఈ లెక్కలను మారుస్తుంది. నేర్చుకోవాల్సిన ముఖ్యమైన architecture వివరమిదే. MoE model ప్రతి tokenను తన weightsలోని చిన్న భాగం ద్వారా మాత్రమే process చేస్తుంది. మొత్తం 30B parameters, ప్రతి tokenకు 3B active parameters ఉన్న modelకు 30B modelకు అవసరమైన memory అవసరం అవుతుంది. అయితే ఇది dense 3B model వేగానికి దగ్గరగా generate చేస్తుంది, ఎందుకంటే ప్రతి token active expertsను మాత్రమే చదువుతుంది. 32 GB boxలో ఈ ఆకృతిలోని MoE, dense 30B model కంటే చాలా ఉపయోగకరంగా ఉంటుంది. గుర్తుంచుకోవాల్సిన నియమం: total parameters memoryని నిర్ణయిస్తాయి; active parameters వేగాన్ని నిర్ణయిస్తాయి.

CPU inference వేగం వాస్తవంగా ఎంత ఉంటుంది?

ప్రతి token ను రూపొందించడానికి active weight మొత్తాన్ని memory నుంచి ఒక్కసారి చదవాలి. దీన్ని ఏ విధంగానూ తప్పించలేం. అందువల్ల CPUపై generation speed core count కంటే memory bandwidth పై ఆధారపడి ఉంటుంది. గరిష్ఠ పరిమితి ఇలా లెక్కించబడుతుంది: ఉపయోగించగల memory bandwidth ను weights పరిమాణం bytes లో భాగించాలి. చిన్న shared VPS సాధారణంగా దాని vCPUs అంతటా 10 నుంచి 25 GB per second అందిస్తుంది. కాబట్టి 4.8 GB model గరిష్ఠంగా సెకనుకు సుమారు 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 hardware పై సాధారణంగా నమోదయ్యే పరిధులు మాత్రమే. ఇవి ఒకే machine పై చేసిన benchmark కావు. మీ ఫలితం memory generation, host లోని channel count, అలాగే దాని కోసం పోటీ పడుతున్న neighbours సంఖ్యపై ఆధారపడి ఉంటుంది. మీరు ఇప్పటికే కలిగి ఉన్న ఏదైనా model tag ఉపయోగించి మీ స్వంత ఫలితాన్ని కొలవండి:

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

సమాధానం ముగిసిన తర్వాత ముద్రించబడే summary లో eval rate: ... tokens/s అని ఉన్న line కనిపిస్తుంది. అదే మీ generation speed. ఒక session లోని మొదటి run ను పరిగణనలోకి తీసుకోకండి. ఎందుకంటే అదే summary లోని load duration weights ను disk నుంచి చదవడానికి పట్టిన సమయాన్ని కూడా కలిగి ఉంటుంది. పోల్చదగిన ఫలితాన్ని పొందడం గురించి tokens per second ను సరిగ్గా కొలవడం లో వివరించబడింది.

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

మీ prompt ను చదవడం, సమాధానాన్ని రూపొందించడం కంటే భిన్నమైన పని. Prompt processing compute bound గా ఉంటుంది. అందువల్ల ఇది cores పెరిగే కొద్దీ వేగవంతమవుతుంది. GPU అత్యధిక ప్రయోజనం ఇచ్చేది కూడా ఇదే దశలో. పొడవైన document ను CPU చదవడానికి నిమిషాలు పడవచ్చు. GPU దాన్ని సెకన్లలో చదవగలదు.

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

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

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

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

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

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

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

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

మొదటిది closed weights. Frontier commercial models పంపిణీ చేయబడవు. అందువల్ల download చేయడానికి file ఉండదు. RAM పరిమాణాన్ని పెంచినా ఇది మారదు. వాటి చుట్టూ ఉన్న ప్రతిదాన్ని self-host చేయవచ్చు: interface, retrieval layer, agent loop, logs. కానీ model తానే remote API గా ఉంటుంది. Claude ను self-host చేయగలరా అనే విభాగంలో దీన్ని పూర్తిగా వివరిస్తుంది.

రెండవది, పరిమాణం కారణంగా ఉపయోగించడానికి చాలా పెద్దగా ఉన్న open weights. అతిపెద్ద open releases, వందల బిలియన్ల total parameters కలిగిన mixture of experts designs గా ఉంటాయి. వీటికీ అదే నియమం వర్తిస్తుంది: 4 bits వద్ద 400B total parameter model కు weights కోసం మాత్రమే సుమారు 240 GB అవసరం. ఇందులో cache ను ఇంకా పరిగణించలేదు. దీనికి specialist hardware అవసరం. అలాంటి hardware ను నెలవారీగా అద్దెకు తీసుకోవడం, చాలా మంది ఒక సంవత్సరంలో API tokens కోసం ఖర్చు చేసే మొత్తంకన్నా చాలా ఎక్కువ అవుతుంది. Kimi తరగతి model ను self-host చేయడానికి అవసరమైనవి అనే విభాగంలో వాస్తవ అవసరాలను వివరిస్తుంది.

ఈ రెండింటి మధ్య నిజమైన నిర్ణయ రేఖ ఇలా ఉంటుంది: load స్థిరంగా ఉండి, data మీ server ను విడిచి వెళ్లకూడదనుకుంటే self-host చేయండి. load అకస్మాత్తుగా పెరుగుతూ తగ్గుతూ ఉంటే, లేదా మీకు వాస్తవంగా అవసరమైనది frontier answer quality అయితే tokens కొనండి.

ఎంచుకునే ముందు మీ వద్ద ఉన్న వనరులను పరిశీలించండి

free -h
nproc
lscpu | grep 'Model name'

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

FAQ

8B model నడపడానికి ఎంత RAM అవసరం?

4 bit quantisation వద్ద weights కోసం సుమారు 4.8 GB అవసరం. దీనికి మీ context length కోసం KV cache, అలాగే operating system మరియు model server కోసం సుమారు 1 GB అదనంగా అవసరం. 8192 token context వద్ద cache సుమారు 1 GB జతచేస్తుంది. అందువల్ల 8 GB plan పనిచేస్తుంది, కానీ 4 GB plan పనిచేయదు. Model card పేర్కొన్న పూర్తి 128k context కావాలంటే cacheకే 16 GB అవసరం. ఈ సందర్భంలో 32 GB plan అవసరమవుతుంది.

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

Generation cores సంఖ్యతో కాకుండా memory bandwidthతో పరిమితమవుతుంది. ప్రతి token కోసం active weight set మొత్తాన్ని RAM నుంచి చదవాలి. కొన్ని cores memory channelsను పూర్తిగా వినియోగించిన తర్వాత మిగిలినవి వేచి ఉంటాయి. మరో సాధారణ కారణం swap. Model సమాధానం ఇస్తున్న సమయంలో vmstat 1 లో non zero si మరియు so కనిపిస్తే, weights RAMలో పూర్తిగా సరిపోవడం లేదని అర్థం. ప్రతి tokenలో కొంత భాగం disk నుంచి చదవాల్సి వస్తోంది. దీనివల్ల అంచనాకన్నా చాలా ఎక్కువ పనితీరు తగ్గుతుంది.

పొడవైన context windowకు నిజంగా ఎక్కువ memory అవసరమా?

అవును. ఈ అవసరం tokens సంఖ్యకు అనుగుణంగా linearగా పెరుగుతుంది. సాధారణ 8B model ప్రతి tokenకు సుమారు 128 KiB KV cache ఉపయోగిస్తుంది. అందువల్ల 8192 tokensకు 1 GB, 131072 tokensకు 16 GB అవసరం. Conversation పెరుగుతున్నప్పుడు కాకుండా model load అయినప్పుడే cache allocate అవుతుంది. కాబట్టి మీరు పంపే ప్రతి prompt 200 tokens మాత్రమే ఉన్నా, 128k contextను ఎంచుకుంటే ఆ memory వెంటనే reserve అవుతుంది.

పెద్ద modelను 2 bitsలో నడపాలా, లేక చిన్న modelను 4 bitsలో నడపాలా?

4 bitsలో ఉన్న చిన్న modelను ఎంచుకోండి. 8 bits నుంచి 4 bits వరకు quality నెమ్మదిగా తగ్గుతుంది. 4 bits కంటే తక్కువకు వెళ్తే quality వేగంగా తగ్గుతుంది. అందువల్ల 70B modelను 2 bitsకు కుదించడం, అదే model generationలోని 32B modelను 4 bitsలో నడపడం కంటే సాధారణంగా అధ్వాన్నమైన సమాధానాలను ఇస్తుంది. అధిక quantisation వల్ల error message కనిపించదు. దాని ప్రభావం repetition మరియు instructions వదిలివేయడంగా కనిపిస్తుంది. అందువల్ల కారణం మీ prompt అని పొరబడటం సులభం. 4 bitsను కనిష్ఠ పరిమితిగా పరిగణించి, బదులుగా parameter countను మార్చండి.

పెద్ద commercial modelsతో సమాన సామర్థ్యం ఉన్న modelను self-host చేయవచ్చా?

సాధారణ VPSలో చేయలేరు. అత్యంత శక్తివంతమైన open weight modelsలో వందల బిలియన్ల parameters ఉంటాయి. 4 bits వద్ద KV cacheకు ముందు వాటికి 200 GB కంటే ఎక్కువ RAM అవసరం. అత్యంత శక్తివంతమైన commercial models అసలు distributedగా అందుబాటులో ఉండవు. సాధారణ hardware ఒక నిర్దిష్ట పని కోసం మంచి 8B నుంచి 32B modelను సమర్థంగా నడపగలదు. ఇరుకైన పరిధి మరియు మంచి prompting ఉన్న చిన్న model, సాధారణ modelతో తరచుగా సమాన ఫలితాలను ఇవ్వగలదు. మీకు frontier quality అవసరమైతే, hardware కొనుగోలు చేయడానికి ముందు API ఖర్చును hardware ఖర్చుతో పోల్చండి.