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

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

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

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

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

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

या दोन parameter संख्यांमधून वेगवेगळ्या प्रश्नांची उत्तरे मिळतात. त्या एकमेकांच्या जागी वापरणे ही प्रत्येक "can I run this" चर्चेतील सर्वात सामान्य चूक आहे.

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

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

म्हणून compute cost कमी आहे, पण store cost जास्त आहे. Hardware चे sizing 2.8T parameters नुसार करा. Speed च्या अपेक्षा 104B parameters नुसार ठेवा.

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

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

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

[
  {
    "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 आणि दुसऱ्या समांतर request साठीची मोकळी क्षमता यात समाविष्ट नाही. तसेच यात समान प्रमाणात विभागता येणारा parallel split गृहीत धरला आहे; मात्र 93 layers आणि 896 experts यांना हे नेहमी शक्य होत नाही.

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

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 ने गुणाकार करावा लागतो.

खाली एक उदाहरण दिले आहे. हे केवळ उदाहरण आहे: 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 साठी ही रक्कम कोणत्याही single card च्या उपलब्ध memory पेक्षा जास्त आहे.

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

पुढील release मध्येही reasoning ची मूलभूत रचना बदलत नाही. एखादे model million token context जाहीर करत असेल आणि त्याच्या attention design बद्दल काहीही सांगत नसेल, तर अन्यथा सिद्ध होईपर्यंत cache हीच binding constraint आहे असे गृहीत धरा.

स्तर 1: cluster तासानुसार भाड्याने घेणे

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

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

हा दर गृहीत दर आहे; तो अधिकृत quote नाही. 2026 पर्यंत datacentre accelerators साठी on-demand list prices साधारणपणे प्रत्येक GPU तासासाठी 2 ते 5 USD दरम्यान होते आणि reserved capacity स्वस्त असते. तुमच्या provider चा प्रत्यक्ष दर वापरून गुणाकार पुन्हा करा: GPUs times hours times rate. chart चा उद्देश गुणोत्तर दाखवणे हा आहे. दररोज चार तासांसाठी 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 इतकाच असला पाहिजे.

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

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

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

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

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

टियर 2: एका accelerator वर छोटे model चालवा

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

योग्य model निवडण्याचा नियम तोच आहे, फक्त छोट्या प्रमाणात: parameters × bytes per weight + KV cache + runtime overhead सुमारे 2 GB हे एकूण 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

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

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 यांसह संपूर्ण मार्गदर्शक 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 प्रत्येक layer GPU वर ठेवण्याचा प्रयत्न करते. Load log तपासा. त्यात किती layers offload झाले ते दिसते. GPU मध्ये न बसलेले layers system RAM मध्ये चालतात आणि HBM bandwidth ऐवजी RAM bandwidth वापरतात. त्यामुळे model पूर्णपणे बसत नसताच generation speed एका order of magnitude ने कमी होते. या दोन tools मधील trade-offs चे सविस्तर वर्णन Ollama आणि llama.cpp ची बाजूबाजूने तुलना येथे आहे.

स्तर 3: hosted 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 निवृत्त करतात.

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

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

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

vLLM आणि SGLang प्रकारचे servers tier 1 मध्ये येतात. ते एकाच वेळी अनेक requests हाताळण्यासाठी तयार केलेले असतात. त्यामध्ये continuous batching, paged KV cache आणि अनेक nodes वर वितरित केलेले tensor parallelism व expert parallelism असते. त्यांच्यासाठी 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 करत आहात की तुमच्या स्वतःच्या hardware वर एका user साठी, हा नेहमीचा मुख्य प्रश्न आहे.

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

1. एकूण parameters ला प्रत्येक weight साठी लागणाऱ्या bytes ने गुणल्यास memory floor मिळतो. यापेक्षा कमी memory मध्ये काहीही चालत नाही. Release आधीच 4-bit असल्यास quantisation युक्तीने हा आकडा फारसा कमी होत नाही.
2. Active parameters मुळे throughput class ठरतो. 104B active parameters असलेले 2.8T MoE मॉडेल, गणनात्मकदृष्ट्या 104B मॉडेलप्रमाणे काम करते.
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 मध्ये ते release करते, त्या 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 असलेले 32 GPU H100 configuration दिले आहे. त्यामुळे weights चा आकडा आवश्यक क्षमता न मानता किमान मर्यादा समजा.

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

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

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

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