Kimi K3 کو self-host کرنے کے لیے کتنی VRAM چاہیے؟

خود Kimi K3 کو چلانے کے لیے درکار وسائل

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

یہ حتمی نتیجہ ہے۔ ذیل میں اس کے پیچھے موجود حساب دیا گیا ہے، کیونکہ یہی حساب اگلی 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 منتخب کرے۔ Model 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 dense model کے بجائے 104B dense model جیسا ہوگا۔ MoE بنانے کی بنیادی وجہ یہی ہے۔

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

اس لیے compute سستا، لیکن storage مہنگی ہے۔ Hardware کی sizing 2.8T کے مطابق کریں۔ Speed کی توقعات 104B کے مطابق رکھیں۔

فی وزن بائٹس، اور ٹیرا بائٹس کہاں سے آتی ہیں

وزنوں کی تعداد کو فی وزن بائٹس سے ضرب دیں۔ وزنوں کے لیے مکمل فارمولہ یہی ہے۔

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

اس سے عام راستہ بھی بند ہو جاتا ہے۔ "بس اسے quantise کر دیں" یہاں مدد نہیں کرتا، کیونکہ released checkpoint پہلے ہی 4-bit ہے۔ 2-bit تک جانے سے weights کا حجم 0.7 TB ہو جائے گا، لیکن اس checkpoint پر accuracy کی جو قیمت ادا ہوگی، اسے کسی نے ناپا نہیں ہے۔ اس کے باوجود آپ کسی ایک 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 اور دوسری concurrent request کے لیے گنجائش شامل نہیں۔ یہ اعداد ایسے parallel split کو بھی فرض کرتے ہیں جو حصوں میں یکساں تقسیم ہو، جبکہ 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 استعمال کرتا ہے، جو کسی بھی single card کی گنجائش سے زیادہ ہے، صرف ایک conversation کے لیے۔

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 کرتا ہے۔ اس لیے فی token حقیقی لاگت عملی مثال سے کہیں کم ہو جاتی ہے۔ Moonshot نے latent dimensions شائع نہیں کیے، اس لیے میں خود K3 کے لیے فی 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 hour کے درمیان رہیں، جبکہ reserved capacity سستی ہوتی ہے۔ اپنے provider کا اصل number لے کر multiplication دوبارہ کریں: GPUs times hours times rate۔ chart کا مقصد ratio دکھانا ہے۔ 8 GPU node کو روزانہ چار گھنٹے چلانے پر ماہانہ 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 ایک JSON object کے ساتھ جواب دیتا ہے جس میں model id درج ہوتی ہے۔ Connection refused کا مطلب ہے کہ process ابھی weights load کر رہا ہے یا پہلے ہی exit ہو چکا ہے، اس لیے دوبارہ کوشش کرنے سے پہلے server log پڑھیں۔

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

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

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

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

fit کا اصول وہی formula ہے، مگر چھوٹے پیمانے پر: 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

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، 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 خرید سکتی ہے۔ لاگت کے لحاظ سے فائدہ حاصل کرنے کے لیے آپ کو ماہانہ تقریباً ایک billion output tokens، یعنی روزانہ تقریباً 30 million tokens، generate کرنے ہوں گے اور cluster کو پورا وقت مصروف رکھنا ہوگا، کیونکہ idle GPUs پر بھی busy GPUs کے برابر billing ہوتی ہے۔ Prompt-heavy agent workloads میں یہ حد مزید دور ہو جاتی ہے: repeated context کی billing cache-hit rate، یعنی 0.30 USD فی million، کے مطابق ہوتی ہے، نہ کہ cache-miss rate، یعنی 3.00 USD کے مطابق۔

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

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

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

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

اس checkpoint کے بعد باقی رہنے والے چار اعداد

1. کل parameters کو ہر weight کے bytes سے ضرب دینے پر memory floor حاصل ہوتی ہے۔ اس سے کم پر کچھ نہیں چلتا، اور جب release پہلے ہی 4-bit ہو تو کوئی quantisation طریقہ اسے زیادہ تبدیل نہیں کر سکتا۔
2. Active parameters throughput class متعین کرتے ہیں۔ 2.8T MoE، جس میں 104B active parameters ہوں، 104B model کی طرح compute کرتا ہے۔
3. ہر token کی KV cache کو context length اور concurrency سے ضرب دینے پر وہ لاگت حاصل ہوتی ہے جو weights کے لیے ادائیگی کے بعد بھی بڑھتی رہتی ہے۔
4. فی dollar tokens per second وہ واحد عدد ہے جو tier منتخب کرتا ہے۔ اوپر دی گئی ہر چیز اسی کے لیے input ہے۔

ان چار اصولوں کو کسی بھی release پر لاگو کریں، اور vendor guide کھولنے سے پہلے ہی درست جواب حاصل کر لیں۔ اس کے بعد درج کیے گئے ہر figure کے ساتھ اس کی تاریخ بھی لکھیں۔ 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 میں 2,560 GB aggregate memory کے ساتھ 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 کو فعال رکھنے والے شخص کی لاگت بھی شامل ہوتی ہے۔ اچانک بڑھنے والے کام کے لیے فی گھنٹہ کرائے پر لیں، اور اندازے کے بجائے اپنے ناپے ہوئے 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 استعمال کریں۔