Kimi K3 स्वतः होस्ट करण्यासाठी किती GPU लागतात?

Kimi K3 स्वतः होस्ट करण्यासाठी काय आवश्यक आहे

Kimi K3 स्वतः होस्ट करण्यासाठी 2.8 ट्रिलियन parameters साठी जागा उपलब्ध करावी लागते. Moonshot ने open weights MXFP4 मध्ये प्रकाशित केले. यामध्ये प्रत्येक weight साठी सुमारे अर्धा byte लागतो. त्यामुळे एकही cache token राखून ठेवण्यापूर्वी weights साठीच अंदाजे 1.4 TB जागा लागते. आज विक्रीस उपलब्ध असलेला कोणताही accelerator ही संपूर्ण आवश्यकता स्वतः पूर्ण करू शकत नाही. K3 हे multi-node model आहे. त्यामुळे एका server साठी उत्तर नाही.

हा अंतिम निष्कर्ष आहे. खालील सर्व माहितीमागे असलेली arithmetic येथे दिली आहे, कारण पुढील release साठीही हीच arithmetic पुन्हा वापरता येते. 17 July 2026 रोजी announcement झाल्यानंतरच्या काही आठवड्यांत अनेक infrastructure vendors ने K3 deployment guides प्रकाशित केली. त्या प्रत्येक guide मध्ये तुमच्याकडे आधीपासून cluster आहे असे गृहीत धरले होते. हा लेख उलट बाजूने सुरुवात करतो: यासाठी किती खर्च येतो, त्याऐवजी काय चालवता येते आणि या दोनपैकी तुमची परिस्थिती कोणती आहे हे कसे ओळखायचे.

एकूण parameters आणि सक्रिय parameters ही समान संख्या नाही

K3 हे mixture of experts मॉडेल आहे. MoE (mixture of experts) नेटवर्कचे अनेक sub-networks मध्ये विभाजन करते आणि प्रत्येक token साठी router त्यांपैकी काही sub-networks निवडतो. Model card मध्ये 2.8T एकूण parameters आणि प्रत्येक token साठी 104B activated parameters नमूद केले आहेत. हे 93 layers मध्ये असलेल्या 896 routed experts पैकी कोणत्याही token साठी सक्रिय होणाऱ्या 16 experts वर आधारित आहे.

या दोन parameter counts वेगवेगळ्या प्रश्नांची उत्तरे देतात. प्रत्येक "can I run this" चर्चेत त्यांची अदलाबदल करणे ही सर्वात सामान्य चूक असते.

Active parameters मुळे compute cost ठरतो. प्रत्येक token सुमारे 104B parameters मधून process होतो. त्यामुळे अपेक्षित throughput हा 2.8T मॉडेलऐवजी 104B dense मॉडेलसारखा असेल. MoE तयार करण्यामागचे हेच मुख्य कारण आहे.

Total parameters मुळे memory cost ठरतो. कोणत्याही token साठी router कोणताही expert निवडू शकतो. त्यामुळे पहिली request येण्यापूर्वी प्रत्येक expert memory मध्ये उपलब्ध असणे आवश्यक आहे. तुम्ही VRAM मध्ये 104B parameters ठेवून उर्वरित parameters गरजेनुसार आणू शकत नाही. कारण ते fetch microseconds मध्ये पूर्ण व्हावे लागेल, तर PCIe link द्वारे दर सेकंदाला केवळ काही tens of gigabytes इतका data transfer होतो. काही जण हे करण्याचा प्रयत्न करतात. NVMe मधून experts stream केल्यास, प्रति सेकंद डझनभर tokens तयार करणारे मॉडेल दर काही seconds ला एक token तयार करणारे मॉडेल बनते.

म्हणून compute करणे स्वस्त आहे, पण store करणे महाग आहे. Hardware ची क्षमता 2.8T लक्षात घेऊन ठरवा. Speed च्या अपेक्षा 104B लक्षात घेऊन ठरवा.

प्रति weight bytes आणि terabytes कुठून येतात

Parameter count गुणिले प्रति weight bytes. Weights साठी संपूर्ण सूत्र एवढेच आहे.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 चे training quantisation-aware पद्धतीने केले गेले आणि ते MXFP4 weights व MXFP8 activations सह release केले गेले. त्यामुळे 4-bit row हीच वास्तविक row आहे. त्यावरील rows scale दाखवण्यासाठी आहेत: bf16 मध्ये याच model ला 5.6 TB लागले असते. MXFP4 मध्ये प्रत्येक 32 weights च्या block साठी एक shared 8-bit scale देखील साठवला जातो. त्यामुळे सुमारे 6 टक्के अतिरिक्त जागा लागते आणि प्रकाशित repository चे आकारमान अचूक 1.4 TB पेक्षा 1.5 TB च्या जवळ आहे.

यामुळे नेहमीचा पर्याय उपलब्ध राहत नाही. "Just quantise it" याचा येथे उपयोग होत नाही, कारण release केलेला checkpoint आधीच 4-bit आहे. 2-bit पर्यंत गेल्यास weights चे आकारमान 0.7 TB होईल आणि या checkpoint वर कोणीही मोजलेली नसलेली accuracy गमवावी लागेल. तरीही हे कोणत्याही एका card च्या क्षमतेपेक्षा खूपच जास्त असेल.

Kimi K3 ला किती GPU आवश्यक आहेत

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

हे आकडे लक्ष्य म्हणून नव्हे, तर किमान मर्यादा म्हणून पहा. त्यात केवळ weights मोजले आहेत. KV cache, activation buffers, allocator fragmentation आणि दुसरी concurrent request हाताळण्यासाठी आवश्यक मोकळी क्षमता त्यात धरलेली नाही. तसेच, parallel split समान प्रमाणात विभागला जातो असे गृहीत धरले आहे. मात्र 93 layers आणि 896 experts यांचे नेहमी समान विभाजन करता येत नाही.

Published guidance या किमान मर्यादेपेक्षा बरीच जास्त आहे. August 2026 पर्यंत Moonshot 64 किंवा त्याहून अधिक accelerators असलेल्या supernode ची शिफारस करते. SGLang cookbook मध्ये चार 8-GPU nodes, 32 GPUs आणि एकूण 2,560 GB memory असलेले H100 configuration दिले आहे. हे 18 cards च्या किमान गरजेच्या तुलनेत आहे. हा फरक अनावश्यक नाही. त्यात KV cache, activation memory आणि server ला एकाच वेळी अनेक requests चे batch processing करता यावे यासाठी आवश्यक headroom समाविष्ट आहे. अगदी अनुकूल असलेली 5 GB300 class cards ची row देखील अशा machine चे वर्णन करते, जी बहुतेक providers single SKU म्हणून rent देत नाहीत.

KV cache हा भाग अनेकांना आश्चर्यचकित करतो

Weights हा निश्चित खर्च आहे. KV (key value) cache तसा नाही. तो context length वाढल्यावर आणि प्रत्येक concurrent user मुळे पुन्हा वाढतो. सामान्य attention साठी सूत्र bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element आहे. त्यानंतर context length आणि concurrency ने गुणाकार करा.

हा एक worked example आहे आणि तो फक्त उदाहरण म्हणून घ्या: 64 layers, 8 KV heads, head dimension 128, fp8. यामुळे 2 64 8 128 1 = 131,072 bytes मिळतात. म्हणजे प्रत्येक token साठी 128 KiB.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

128k context वर एका user साठी 16 GiB खर्च होतो. पूर्ण million context वर एका user साठी 128 GiB खर्च होतो. एका conversation साठी ही रक्कम कोणत्याही एकाच card च्या क्षमतेपेक्षा जास्त आहे.

K3 मध्ये सामान्य attention वापरलेले नाही. शेवटचा आकडा याचे कारण स्पष्ट करतो. त्याच्या 93 layers पैकी 69 KDA (Kimi Delta Attention) layers आणि 24 Gated MLA (multi-head latent attention) layers आहेत. KDA प्रत्येक token सोबत वाढणाऱ्या cache ऐवजी निश्चित आकाराचा recurrent state ठेवते. MLA key आणि value यांना एका low rank latent vector मध्ये compress करते. त्यामुळे प्रत्यक्ष per-token खर्च वरील worked example पेक्षा खूपच कमी होतो. Moonshot ने latent dimensions प्रकाशित केलेले नाहीत. त्यामुळे K3 साठी per-user figure देणार नाही. त्याऐवजी तुमच्या system वर मोजणी करा: लहान --max-model-len सह server सुरू करा, nvidia-smi वापरून memory monitor करा आणि allocation fail होईपर्यंत limit वाढवत जा.

पुढील release मध्येही reasoning ची रचना तशीच राहते. एखादे model million token context जाहीर करत असेल आणि त्याच्या attention design विषयी काही सांगत नसेल, तर cache हीच binding constraint आहे असे गृहीत धरा, जोपर्यंत त्याच्या उलट पुरावा मिळत नाही.

स्तर 1: क्लस्टर तासाच्या हिशोबाने भाड्याने घेणे

K3 स्वतः चालवणारा हा एकमेव स्तर आहे. हार्डवेअर खरेदी करण्याची गरज नाही. आवश्यक तेवढ्या तासांसाठी ते भाड्याने घ्या आणि त्यानंतर बंद करा.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

हा दर अंदाज आहे, अधिकृत कोटेशन नाही. 2026 पर्यंत datacentre accelerator साठी on-demand list prices साधारणपणे प्रति GPU तास 2 ते 5 USD दरम्यान होत्या. Reserved capacity स्वस्त असते. तुमच्या provider कडील वास्तविक आकडा वापरून गुणाकार पुन्हा करा: GPUs × hours × rate. चार्टचा उद्देश गुणोत्तर दाखवणे हा आहे. 8 GPU node दररोज चार तास चालवल्यास दरमहा 2,400 USD खर्च येतो, तर SGLang साठी आकारलेली 32 GPU configuration सतत चालू ठेवल्यास 57,600 USD खर्च येतो.

दोन्ही मुख्य प्रवाहातील servers model card वर launch command देतात.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

प्रत्यक्ष cluster वर फक्त मूळ command चालवू नका. तुमच्या hardware शी जुळणारे parallelism flags जोडा: SGLang tensor parallel साठी --tp-size आणि expert parallel साठी --ep-size स्वीकारते. या दोन्हींचा गुणाकार प्रत्यक्ष उपलब्ध GPUs इतका असणे आवश्यक आहे.

प्रत्यक्ष traffic पाठवण्यापूर्वी server सुरू झाला आहे का ते तपासा:

curl http://127.0.0.1:30000/v1/models

निरोगी server model id असलेला JSON object परत करतो. Connection refused याचा अर्थ process अजून weights load करत आहे किंवा आधीच बंद झाला आहे. त्यामुळे पुन्हा प्रयत्न करण्यापूर्वी server log वाचा.

पहिल्या दिवशीची सामान्य अडचण म्हणजे model पेक्षा जुना runtime वापरणे. K3 सोबत KDA आणि नवीन MoE layer release झाले; मात्र stable vLLM आणि SGLang releases मध्ये launch वेळी त्यांचा समावेश नव्हता. याचे लक्षण म्हणजे startup दरम्यान server Model architectures [...] are not supported for now या स्वरूपाच्या ओळीसह बंद होतो. Configuration बदलल्याने हे ठीक होत नाही, कारण या layers चालवण्यासाठी आवश्यक code तुमच्या build मध्ये नाही. Model card मध्ये नमूद केलेला nightly install करा किंवा तो समाविष्ट असलेला release उपलब्ध होईपर्यंत थांबा.

खर्चासंबंधी एक महत्त्वाची बाब लक्षात ठेवा. Meter instance सुरू झाल्यावर सुरू होतो; model ready झाल्यावर नाही. 1 GB/s वेगाने 1.5 TB download करण्यासाठी सुमारे 25 मिनिटे लागतात. या काळात पहिला token मिळण्यापूर्वी cluster time खर्च होतो. Instance पेक्षा अधिक काळ टिकणाऱ्या volume वर weights आधीच stage करा. त्यामुळे दुसऱ्या run ला काही मिनिटेच लागतील.

Tier 2: एका accelerator वर लहान model चालवा

या tier मध्ये तुम्ही K3 चालवत नाही. सुरू करण्यापूर्वी हे स्पष्टपणे लक्षात ठेवा, कारण "run K3 locally" या विषयावरील बहुतेक चर्चा हे मान्य न करताच इथेच थांबतात.

फिट होण्याचा नियम तोच आहे, फक्त लहान प्रमाणात: parameters गुणिले प्रत्येक weight साठी bytes, त्यात KV cache आणि सुमारे 2 GB runtime overhead जोडल्यावर मिळणारा आकार तुमच्या VRAM पेक्षा कमी असला पाहिजे. 4-bit मध्ये हे साधारणपणे प्रत्येक parameter साठी अर्धा byte असते. त्यामुळे खालील जोड्या सहजपणे जुळतात:

• 16 GB card: 4-bit मधील 7B model, तसेच लांब context साठी जागा
• 24 GB card: 4-bit मधील 14B model
• 48 GB card: 4-bit मधील 32B model
• 80 GB card: 4-bit मधील 70B model किंवा 8-bit मधील 30B class MoE

वरील प्रत्येक जोडी एका वेळी एका request वर आधारित आहे. दुसरी व्यक्ती prompt पाठवताच प्रत्येक concurrent slot साठी स्वतंत्र KV cache लागतो. त्यामुळे उपलब्ध VRAM नुसार parallel slots, queued requests आणि उरलेली VRAM यांच्यातील तडजोड Ollama च्या NUM_PARALLEL आणि MAX_QUEUE settings तुमच्यासाठी ठरवतात.

GPU जोडलेल्या VPS वर कार्यरत server सुरू करण्याचा सर्वात सोपा मार्ग Ollama आहे:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

पहिल्या वापराच्या वेळी ollama run model download करतो आणि त्यानंतर prompt दाखवतो. अस्तित्वात नसलेला tag Error: model "..." not found परत करतो. त्यामुळे tag आठवणीतून टाइप करण्याऐवजी library page वरून copy करा. systemd unit आणि remote access यांसह संपूर्ण walkthrough VPS वर Ollama चालवणे येथे आहे.

llama.cpp तुम्हाला quantisation आणि offload वर अधिक नियंत्रण देते:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 GPU वर प्रत्येक layer लोड करण्याची विनंती करतो. load log वाचा. त्यात किती layers offload झाले ते दिसते. system RAM मध्ये गेलेले layers HBM bandwidth ऐवजी RAM bandwidth वर चालतात. त्यामुळे model फिट होणे थांबताच generation speed एका क्रमाने कमी होते. दोन्ही tools मधील तडजोडी Ollama आणि llama.cpp ची तुलनात्मक मांडणी येथे दिल्या आहेत.

स्तर 3: होस्ट केलेले API, self-hosted orchestration

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

Endpoint OpenAI compatible आहे. त्यामुळे base URL बदलल्यानंतर विद्यमान client काम करतो.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

कार्यरत key मुळे choices array असलेला JSON object मिळतो. 401 आल्यास key चुकीची आहे किंवा Bearer prefix गहाळ आहे. Model-not-found error चा अर्थ सहसा id बदलला आहे असा होतो, कारण providers checkpoints दरम्यान ids retire करतात.

आता वर गृहीत धरलेल्या rental rate नुसार break-even पाहू. सतत सुरू असलेल्या 8 GPU node ची किंमत दरमहा 14,400 USD आहे. 15.00 USD प्रति million output tokens या दराने त्याच रकमेतून API कडून सुमारे 960 million output tokens मिळतात. खर्चाच्या दृष्टीने self-hosting फायदेशीर ठरण्यासाठी दरमहा जवळपास एक billion output tokens generate करावे लागतील, म्हणजे दररोज सुमारे 30 million. तसेच cluster संपूर्ण वेळ व्यस्त ठेवावा लागेल, कारण idle GPUs साठीही busy GPUs प्रमाणेच billing होते. Prompt-heavy agent workloads असल्यास हा break-even point आणखी दूर जातो: repeated context साठी cache-hit rate 0.30 USD प्रति million असा खर्च होतो, तर cache-miss rate 3.00 USD आहे.

या स्तरावर तुम्ही model भोवतालच्या सर्व गोष्टी self-host करता: API key client पर्यंत पोहोचू नये म्हणून ती ठेवणारा gateway, request आणि response logs, retries, rate limits आणि प्रत्येक user साठी budgets. हे सर्व GPU नसलेल्या छोट्या VPS वर चालते. Closed weights साठीही हाच विभाग लागू होतो. Model स्तरावर Claude self-hosting शक्य नसते आणि orchestration हा तुमच्या नियंत्रणातील एकमेव भाग असतो.

कोणता serving stack कोणत्या tier साठी आहे

vLLM आणि SGLang प्रकारचे servers tier 1 मध्ये येतात. ते एकाच वेळी अनेक requests serve करण्यासाठी तयार केलेले असतात. त्यामध्ये continuous batching आणि paged KV cache असतो. तसेच अनेक nodes मध्ये tensor parallelism आणि expert parallelism वितरित करता येतो. हे servers datacentre accelerators आणि त्यांच्यामधील वेगवान interconnect गृहीत धरतात. एकाच consumer card वर ते install करणे अधिक अवघड असते आणि प्रत्यक्ष वापरात जाणवेल असा फारसा फायदा मिळत नाही.

llama.cpp आणि Ollama tier 2 मध्ये येतात. त्यांचा उद्देश एका machine वर चालणे, GGUF quantisation वापरणे, model बसत नसल्यास CPU offload करणे आणि कमी concurrency हाताळणे हा आहे. llama.cpp बहुतांश layers system RAM मध्ये ठेवून अतिशय मोठा MoE तांत्रिकदृष्ट्या load करू शकतो. मात्र 2.8T model साठी त्या पद्धतीत प्रत्येक token ला लागणारा वेळ seconds मध्ये मोजला जातो. यावरून file parse होत असल्याचे सिद्ध होते. मात्र users साठी ही service उपलब्ध करून देता येत नाही. संपूर्ण तुलना Ollama विरुद्ध vLLM येथे आहे. Model कोणताही असला तरी निष्कर्ष बदलत नाही. तुम्ही shared hardware वर अनेक users साठी serving करत आहात की स्वतःसाठी एका user ला service देत आहात, हा नेहमीचा मुख्य प्रश्न आहे.

या टप्प्यानंतरही लागू राहणारे चार आकडे

1. एकूण parameters गुणिले प्रत्येक weight साठी bytes म्हणजे किमान memory आवश्यकता. त्यापेक्षा कमी memory वर काहीही चालत नाही. Release आधीच 4-bit असल्यास quantisation तंत्राने ही आवश्यकता फारशी कमी होत नाही.
2. Active parameters कार्यक्षमतेचा वर्ग ठरवतात. 104B active parameters असलेले 2.8T MoE हे 104B model प्रमाणे computation करते.
3. प्रत्येक token साठी KV cache, context length ने गुणिलेले आणि concurrency ने गुणिलेले, ही weights साठी memory भरल्यानंतरही वाढत राहणारी किंमत आहे.
4. प्रत्येक dollar मागे tokens per second हा tier निवडणारा एकमेव आकडा आहे. वरील सर्व माहिती त्यासाठी input आहे.

हे चार नियम कोणत्याही release ला लागू केल्यास vendor guide उघडण्यापूर्वीच योग्य निष्कर्ष मिळतो. त्यानंतर नोंदवलेल्या प्रत्येक आकड्याला तारीख द्या. K3 launch झाल्यानंतरच्या दोन आठवड्यांत prices आणि supported-architecture lists या दोन्हीमध्ये बदल झाले. या पृष्ठावरील प्रत्येक आकडा July 2026 मध्ये प्रकाशित झालेला आहे.

FAQ

मी Kimi K3 एकाच GPU वर चालवू शकतो का?

नाही. Moonshot ज्या MXFP4 precision मध्ये weights वितरित करते, त्यामध्ये त्यांचा आकार सुमारे 1.4 TB आहे. विक्रीस उपलब्ध असलेल्या सर्वात मोठ्या single accelerator मध्ये 288 GB क्षमता आहे. MoE model मधील inactive experts वापरण्यायोग्य वेगाने disk वरून stream करता येत नाहीत, कारण router कोणत्याही token साठी कोणताही expert निवडू शकतो आणि PCIe fetch ला token budget मध्ये उपलब्ध वेळेपेक्षा खूप अधिक वेळ लागतो. K3 साठी व्यवहार्य सर्वात लहान deployment म्हणजे multi-GPU node आहे. प्रकाशित recipes मध्ये 32 किंवा अधिक accelerators वापरले आहेत.

Kimi K3 ला किती VRAM आवश्यक आहे?

फक्त weights साठी 1.4 TB पासून सुरुवात करा. हे 18 H100 80GB cards किंवा 5 GB300 class cards इतके आहे. त्यानंतर KV cache आणि activation memory साठी अतिरिक्त जागा द्या. August 2026 पर्यंत Moonshot 64 किंवा अधिक accelerators ची शिफारस करते. SGLang cookbook मध्ये aggregate 2,560 GB memory असलेली 32 GPU H100 configuration प्रकाशित केली आहे. त्यामुळे weights चा आकडा आवश्यक क्षमता न मानता किमान मर्यादा समजा.

Quantisation मुळे Kimi K3 एका node वर बसतो का?

उपयुक्त पद्धतीने नाही. Released checkpoint आधीच quantisation-aware training सह 4-bit आहे. त्यामुळे सहज मिळणारी memory बचत आधीच झालेली आहे. पुन्हा 2-bit वर आणल्यास weights 0.7 TB होतील. तरीही हे सर्वात मोठ्या card पेक्षा दुपटीहून अधिक आहे. तसेच या model वर 2-bit मुळे होणारी accuracy cost अद्याप मोजलेली नाही.

Kimi K3 API पेक्षा GPU भाड्याने घेणे स्वस्त आहे का?

फक्त मोठ्या आणि स्थिर volume साठी. प्रति GPU तास 2.50 USD गृहीत धरल्यास, नेहमी सुरू असलेल्या 8 GPU node ची किंमत दरमहा 14,400 USD येते. त्याच रकमेत प्रकाशित 15.00 USD प्रति million output tokens या दराने सुमारे 960 million output tokens मिळतात. याशिवाय idle hours, weights downloads आणि cluster सुरू ठेवणाऱ्या व्यक्तीचा खर्चही द्यावा लागतो. अल्पकालीन वाढलेल्या मागणीसाठी GPU तासानुसार भाड्याने घ्या. अंदाजाऐवजी स्वतः मोजलेल्या token volume शी तुलना करा.

104B active parameters मुळे speed बद्दल काय समजते?

प्रति token लागणारी arithmetic ही 104B model इतकी असते. त्यामुळे throughput 2.8T class ऐवजी 104B class मध्ये येतो. यावरून memory बद्दल काहीही निष्कर्ष निघत नाही. सर्व 2.8T parameters memory मध्ये resident राहतात, कारण router कोणत्याही token साठी कोणताही expert वापरू शकतो. Tokens per second चा अंदाज घेण्यासाठी active count वापरा. VRAM capacity ठरवण्यासाठी total count वापरा.