Kimi K3 کو خود host کرنے کے لیے کیا درکار ہے؟

خود Kimi K3 کی میزبانی کے لیے کیا درکار ہے

Kimi K3 کی self-hosting کے لیے 2.8 ٹریلین parameters کے لیے گنجائش درکار ہوتی ہے۔ Moonshot نے open weights کو MXFP4 میں جاری کیا ہے، جس میں ہر weight تقریباً نصف byte پر مشتمل ہوتا ہے۔ اس لیے weights کے لیے ہی تقریباً 1.4 TB درکار ہوتے ہیں، اس سے پہلے کہ cache کے لیے ایک بھی token مختص کیا جائے۔ آج فروخت ہونے والا کوئی بھی accelerator اکیلا اتنی گنجائش فراہم نہیں کرتا۔ K3 ایک multi-node model ہے، اس لیے ایک server کے لیے جواب نفی میں ہے۔

یہ حتمی نتیجہ ہے۔ ذیل کی تمام تفصیل اسی کے پیچھے موجود حساب پر مبنی ہے، کیونکہ یہی حساب اگلی release پر بھی دوبارہ استعمال کیا جا سکتا ہے۔ 17 July 2026 کو اعلان کے بعد کے ہفتوں میں کئی infrastructure vendors نے K3 deployment guides شائع کیں، اور ہر guide میں یہ فرض کیا گیا کہ آپ کے پاس پہلے سے cluster موجود ہے۔ یہ صفحہ دوسرے رخ سے آغاز کرتا ہے: اس پر کتنی لاگت آتی ہے، اس کے بجائے آپ کیا چلا سکتے ہیں، اور یہ کیسے معلوم کریں کہ آپ ان دونوں میں سے کس صورتِ حال میں ہیں۔

کل parameters اور active parameters ایک جیسی تعداد نہیں ہیں

K3 ایک mixture of experts ماڈل ہے۔ MoE (mixture of experts) نیٹ ورک کو متعدد sub-networks میں تقسیم کرتا ہے اور router کو ہر token کے لیے ان میں سے چند sub-networks منتخب کرنے دیتا ہے۔ ماڈل card میں 2.8T total parameters اور ہر token کے لیے 104B activated parameters درج ہیں۔ یہ parameters 896 routed experts میں تقسیم ہیں، جن میں سے کسی بھی token کے لیے 16 experts فعال ہوتے ہیں، اور یہ عمل 93 layers میں ہوتا ہے۔

یہ دونوں parameter counts مختلف سوالوں کے جواب دیتے ہیں۔ ہر "can I run this" thread میں سب سے عام غلطی یہی ہے کہ انہیں ایک دوسرے کی جگہ استعمال کیا جاتا ہے۔

Active parameters compute cost طے کرتے ہیں۔ ہر token تقریباً 104B parameters سے گزرتا ہے۔ اس لیے متوقع throughput، 2.8T ماڈل کے بجائے 104B dense model جیسا ہوگا۔ MoE بنانے کی بنیادی وجہ یہی ہے۔

Total parameters memory cost طے کرتے ہیں۔ Router کسی بھی token کے لیے کوئی بھی expert منتخب کر سکتا ہے، اس لیے پہلی request آنے سے پہلے ہر expert memory میں موجود ہونا چاہیے۔ آپ VRAM میں صرف 104B parameters رکھ کر باقی parameters ضرورت کے وقت حاصل نہیں کر سکتے، کیونکہ یہ fetch microseconds میں مکمل ہونا چاہیے، جبکہ PCIe link ہر second صرف tens of gigabytes منتقل کرتا ہے۔ لوگ ایسا کرنے کی کوشش کرتے ہیں۔ NVMe سے experts کو stream کرنے پر ایسا model، جسے ہر second dozens of tokens خارج کرنے چاہییں، ہر چند seconds میں صرف ایک token خارج کرتا ہے۔

اس لیے compute کے لحاظ سے یہ کم خرچ، لیکن store کرنے کے لحاظ سے مہنگا ہے۔ Hardware کی گنجائش 2.8T کے مطابق طے کریں۔ Speed کی توقعات 104B کے مطابق رکھیں۔

وزن کے لحاظ سے بائٹس، اور terabytes کہاں سے آتے ہیں

Parameter count کو ہر weight کے بائٹس سے ضرب دیں۔ Weights کے لیے مکمل formula یہی ہے۔

[
  {
    "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 طریقے سے train کیا گیا تھا اور اسے MXFP4 weights اور MXFP8 activations کے ساتھ release کیا گیا، اس لیے 4-bit والی row اصل حالت ہے۔ اس کے اوپر والی rows scale دکھانے کے لیے ہیں: bf16 میں یہی model 5.6 TB درکار کرتا۔ MXFP4 ہر 32 weights کے block کے لیے ایک مشترک 8-bit scale بھی محفوظ کرتا ہے، جس سے تقریباً 6 فیصد اضافہ ہوتا ہے۔ اسی لیے published repository صاف 1.4 TB کے بجائے 1.5 TB کے زیادہ قریب ہے۔

اس سے عام escape hatch بھی ختم ہو جاتی ہے۔ یہاں "بس اسے quantise کر دیں" مددگار نہیں، کیونکہ جاری کیا گیا checkpoint پہلے ہی 4-bit ہے۔ 2-bit تک جانے سے weights کا حجم 0.7 TB رہ جائے گا، لیکن accuracy پر اس کی قیمت ہو گی، اور کسی نے اس 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 اور دوسری بیک وقت درخواست کے لیے درکار گنجائش شامل نہیں۔ یہ اعداد ایسی parallel تقسیم بھی فرض کرتے ہیں جو برابر حصوں میں تقسیم ہو، جبکہ 93 layers اور 896 experts کے ساتھ یہ ہمیشہ ممکن نہیں ہوتا۔

شائع شدہ رہنمائی کم از کم ضرورت سے خاصی زیادہ ہے۔ August 2026 تک Moonshot، 64 یا اس سے زیادہ accelerators پر مشتمل supernode تجویز کرتا ہے، جبکہ SGLang cookbook میں H100 configuration چار 8-GPU nodes، یعنی 32 GPUs اور مجموعی طور پر 2,560 GB memory، سے بنائی گئی ہے۔ اس کے مقابلے میں کم از کم ضرورت 18 cards ہے۔ یہ فرق ضیاع نہیں ہے۔ اس میں KV cache، activation memory اور اتنی اضافی گنجائش شامل ہے جس سے server بیک وقت متعدد requests کو batch کر سکے۔ حتیٰ کہ سب سے سازگار row، 5 GB300 class cards، بھی ایسی machine بیان کرتی ہے جسے زیادہ تر providers ایک single SKU کے طور پر rent نہیں کرتے۔

KV cache وہ حصہ ہے جو اکثر لوگوں کو حیران کرتا ہے

Weights ایک مستقل لاگت ہیں۔ KV (key value) cache ایسا نہیں ہے۔ یہ context length کے ساتھ بڑھتا ہے اور ہر concurrent user کے ساتھ دوبارہ بڑھتا ہے۔ عام attention کے لیے formula bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element ہے، پھر اسے context length اور concurrency سے multiply کیا جاتا ہے۔

یہ ایک عملی مثال ہے، اور صرف مثال ہے: 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 پر ایک user کی لاگت 128 GiB ہے، جو صرف ایک conversation کے لیے کسی بھی single card کی گنجائش سے زیادہ ہے۔

K3 عام attention استعمال نہیں کرتا، اور یہی وجہ ہے کہ آخری عدد اتنا بڑا ہے۔ اس کی 93 layers میں 69 KDA (Kimi Delta Attention) layers اور 24 Gated MLA (multi-head latent attention) layers شامل ہیں۔ KDA ایسے cache کے بجائے fixed size recurrent state برقرار رکھتا ہے جو ہر token کے ساتھ بڑھتا ہے، جبکہ MLA key اور value کو ایک low rank latent vector میں compress کرتا ہے۔ اس لیے حقیقی per-token لاگت عملی مثال سے بہت کم ہو جاتی ہے۔ Moonshot نے latent dimensions شائع نہیں کیے، اس لیے میں K3 کے لیے per-user figure بیان نہیں کروں گا۔ اس کے بجائے اپنی installation کی پیمائش کریں: server کو چھوٹی --max-model-len کے ساتھ شروع کریں، nvidia-smi سے memory monitor کریں، پھر limit بڑھاتے جائیں تاوقتیکہ allocation ناکام ہو جائے۔

اگلی release میں بھی reasoning کی بنیادی شکل برقرار رہے گی۔ اگر کوئی model million token context کی تشہیر کرے اور اپنے attention design کے بارے میں کچھ نہ بتائے تو اس وقت تک cache کو binding constraint سمجھیں جب تک اس کے برعکس ثبوت نہ مل جائے۔

درجہ 1: کلسٹر فی گھنٹہ کرائے پر لیں

یہ واحد درجہ ہے جس میں 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"
  }
]

یہ rate ایک مفروضہ ہے، کوئی quote نہیں۔ 2026 تک datacentre accelerators کے on-demand list prices تقریباً 2 سے 5 USD فی GPU گھنٹہ رہے، جبکہ reserved capacity کم قیمت ہوتی ہے۔ اپنے provider کی اصل قیمت لیں اور ضرب دوبارہ لگائیں: GPUs × hours × rate۔ chart کا مقصد ratio دکھانا ہے۔ 8 GPU node کو روزانہ 4 گھنٹے چلانے کی ماہانہ لاگت 2,400 USD ہے، جبکہ SGLang کے لیے سائز کی گئی 32 GPU configuration کو مسلسل چلانے کی لاگت 57,600 USD ہے۔

دونوں mainstream 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 پر آپ ان میں سے کوئی بھی bare 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 کر رہا ہے یا پہلے ہی exit ہو چکا ہے، اس لیے دوبارہ کوشش سے پہلے server log پڑھیں۔

پہلے دن عام failure کی وجہ ایسا runtime ہوتا ہے جو model سے پرانا ہو۔ K3، KDA اور ایک نئی MoE layer کے ساتھ release ہوا تھا، لیکن stable vLLM اور SGLang releases میں launch کے وقت یہ layer شامل نہیں تھی۔ اس کی علامت startup کے دوران server کا اس شکل کی line کے ساتھ exit ہونا ہے: Model architectures [...] are not supported for now۔ کوئی config change اس مسئلے کو حل نہیں کرتا، کیونکہ ان layers کو چلانے والا code آپ کی build میں موجود نہیں۔ Model card میں بتائے گئے nightly کو install کریں، یا اس release کا انتظار کریں جس میں یہ شامل ہو۔

ایک لاگت سے متعلق نکتہ اکثر نظر انداز ہو جاتا ہے۔ meter instance شروع ہونے پر چلتا ہے، model ready ہونے پر نہیں۔ 1.5 TB download کو 1 GB/s رفتار پر مکمل ہونے میں تقریباً 25 منٹ لگتے ہیں، اور اس دوران cluster time استعمال ہوتا ہے، first token سے پہلے۔ Weights کو ایسی volume پر stage کریں جو instance کے بعد بھی برقرار رہے، تاکہ دوسری run چند منٹ میں شروع ہو جائے۔

سطح 2: ایک accelerator پر چھوٹا model چلائیں

اس سطح پر آپ K3 نہیں چلا رہے۔ شروع کرنے سے پہلے یہ بات واضح طور پر کہہ دیں، کیونکہ "run K3 locally" سے متعلق زیادہ تر مباحث یہیں ختم ہو جاتے ہیں، مگر اس کا اعتراف نہیں کیا جاتا۔

فٹنگ کا اصول وہی formula ہے، مگر چھوٹے پیمانے پر: parameters کو فی weight bytes سے ضرب دیں، پھر 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

اوپر دی گئی ہر جوڑی ایک وقت میں ایک request فرض کرتی ہے۔ جیسے ہی دوسرا شخص prompt بھیجتا ہے، ہر concurrent slot کو اپنا KV cache درکار ہوتا ہے۔ اسی trade-off کے ذریعے Ollama کی NUM_PARALLEL اور MAX_QUEUE settings آپ کے لیے parallel slots، queued requests اور دستیاب VRAM کے درمیان توازن قائم کرتی ہیں۔

Ollama، GPU منسلک VPS پر working server شروع کرنے کا مختصر ترین طریقہ ہے:

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

ollama run پہلی بار استعمال پر model download کرتا ہے، پھر آپ کو prompt پر لے آتا ہے۔ اگر کوئی tag موجود نہ ہو تو Error: model "..." not found واپس ملتا ہے۔ اس لیے tags یاد سے لکھنے کے بجائے library page سے copy کریں۔ مکمل walkthrough، جس میں systemd unit اور remote access بھی شامل ہیں، VPS پر Ollama چلانے میں موجود ہے۔

llama.cpp آپ کو quantisation اور offload پر زیادہ control دیتا ہے:

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 دیکھیں؛ اس میں offload کی گئی layers کی تعداد درج ہوتی ہے۔ جو layers system RAM میں چلی جاتی ہیں وہ HBM bandwidth کے بجائے RAM bandwidth پر چلتی ہیں۔ اس لیے جیسے ہی model مکمل طور پر fit ہونا بند ہوتا ہے، 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 ایک JSON object واپس کرتی ہے جس میں choices array ہوتا ہے۔ 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 خرید سکتی ہے۔ cost کے لحاظ سے فائدہ حاصل کرنے کے لیے آپ کو ماہانہ تقریباً ایک billion output tokens، یعنی روزانہ تقریباً 30 million tokens، generate کرنے ہوں گے اور cluster کو پورا وقت مصروف رکھنا ہوگا، کیونکہ idle GPUs بھی busy GPUs کے برابر rate پر bill ہوتے ہیں۔ prompt-heavy agent workloads میں یہ حد مزید دور چلی جاتی ہے: repeated context کی billing cache-miss rate 3.00 USD کے بجائے cache-hit rate 0.30 USD فی million کے حساب سے ہوتی ہے۔

اس tier میں آپ model کے اردگرد موجود تمام اجزا self-host کرتے ہیں: ایک gateway جو API key اپنے پاس رکھتا ہے تاکہ وہ کبھی client تک نہ پہنچے، request اور response logs، retries، rate limits، اور per-user budgets۔ یہ سب ایک چھوٹے VPS پر چل سکتا ہے، جس میں GPU کی بالکل ضرورت نہیں۔ یہی تقسیم closed weights پر بھی لاگو ہوتی ہے، جہاں model level پر Claude کی self-hosting ممکن نہیں اور orchestration ہی وہ واحد حصہ ہے جس کی ملکیت آپ کے پاس رہتی ہے۔

کون سا serving stack کس tier سے تعلق رکھتا ہے

vLLM اور SGLang طرز کے servers tier 1 سے تعلق رکھتے ہیں۔ یہ بیک وقت متعدد requests کو serve کرنے کے لیے بنائے گئے ہیں۔ ان میں continuous batching اور paged KV cache کے ساتھ ساتھ کئی nodes پر پھیلی ہوئی tensor اور expert parallelism شامل ہوتی ہے۔ یہ datacentre accelerators اور ان کے درمیان تیز interconnect فرض کرتے ہیں۔ کسی ایک consumer card پر انہیں install کرنا زیادہ مشکل ہوتا ہے، جبکہ ان کے زیادہ تر فوائد آپ کو محسوس نہیں ہوں گے۔

llama.cpp اور Ollama tier 2 سے تعلق رکھتے ہیں۔ ان کا ہدف ایک machine، GGUF quantisation، model کے fit نہ ہونے پر CPU offload، اور کم concurrency ہے۔ llama.cpp تکنیکی طور پر ایک بہت بڑے MoE کو system RAM میں زیادہ تر layers رکھ کر load کر سکتا ہے، لیکن 2.8T model کے لیے اس طریقے میں ہر token پر کئی seconds لگتے ہیں۔ اس سے صرف یہ ثابت ہوتا ہے کہ file parse ہو سکتی ہے۔ یہ ایسی service نہیں ہے جس پر users کو چلایا جا سکے۔ مکمل موازنہ Ollama بمقابلہ vLLM میں موجود ہے، اور model تبدیل ہونے سے یہ اصول نہیں بدلتا: بنیادی سوال ہمیشہ یہ ہے کہ آپ shared hardware پر متعدد users کو serve کر رہے ہیں یا اپنی machine پر ایک user کو۔

اس checkpoint سے آگے بھی برقرار رہنے والے چار اعداد

1. کل parameters کو ہر weight کے bytes سے ضرب دینے پر memory floor معلوم ہوتی ہے۔ اس سے کم memory میں کچھ بھی نہیں چلتا، اور جب release پہلے ہی 4-bit ہو تو quantisation کی کوئی ترکیب اسے خاصا کم نہیں کر سکتی۔
2. Active parameters throughput class طے کرتے ہیں۔ 104B active parameters والا 2.8T MoE، 104B model کی طرح computation کرتا ہے۔
3. فی token KV cache کو context length اور concurrency سے ضرب دینا وہ لاگت ہے جو weights کے لیے ادائیگی کے بعد بھی بڑھتی رہتی ہے۔
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 متعدد GPUs والا 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 میں 2,560 GB aggregate کے ساتھ 32 GPU H100 configuration شائع کی گئی ہے۔ اس لیے weights کے اعداد کو کم از کم حد سمجھیں، حتمی ضرورت نہیں۔

کیا quantisation سے Kimi K3 ایک node میں فٹ ہو جاتا ہے؟

قابلِ عمل طور پر نہیں۔ جاری کیا گیا checkpoint پہلے ہی quantisation-aware training کے ساتھ 4-bit ہے، اس لیے آسان memory saving پہلے ہی حاصل کی جا چکی ہے۔ اسے دوبارہ 2-bit کرنے سے weights 0.7 TB رہ جائیں گے، جو اب بھی سب سے بڑے card سے دو گنا سے زیادہ ہیں، اور اس model پر 2-bit کی accuracy cost ابھی ناپی نہیں گئی۔

کیا GPUs کرائے پر لینا Kimi K3 API سے سستا ہے؟

صرف زیادہ اور مسلسل volume پر۔ اگر GPU hour کی قیمت 2.50 USD فرض کی جائے تو ہمیشہ چلنے والا 8 GPU node ماہانہ 14,400 USD کا خرچ کرتا ہے، جبکہ اسی رقم سے شائع شدہ 15.00 USD فی million tokens کی شرح پر تقریباً 960 million output tokens خریدے جا سکتے ہیں۔ اس کے علاوہ idle hours، weights downloads اور cluster کو فعال رکھنے والے فرد کے اخراجات بھی شامل ہوتے ہیں۔ bursts کے لیے فی گھنٹہ کرائے پر لیں، اور اندازے کے بجائے اپنی ناپی ہوئی token volume سے موازنہ کریں۔

رفتار کے لیے 104B active parameters کا کیا مطلب ہے؟

اس کا مطلب ہے کہ ہر token کے لیے arithmetic ایک 104B model جتنی ہے، اس لیے throughput 2.8T class کے بجائے 104B class میں رہے گا۔ یہ memory کے بارے میں کچھ نہیں بتاتا: تمام 2.8T parameters memory میں موجود رہتے ہیں، کیونکہ router کسی بھی token پر کوئی بھی expert طلب کر سکتا ہے۔ tokens per second کا اندازہ لگانے کے لیے active count استعمال کریں، اور VRAM کا حجم طے کرنے کے لیے total count استعمال کریں۔