مرکزی مواد پر جائیں
اے آئی ٹیوٹوریلز

EXL3 اور vLLM کے ساتھ دو DGX Spark پر DeepSeek V4.1 Flash مقامی طور پر چلائیں

دو NVIDIA GB10 DGX Spark سسٹمز پر DeepSeek V4.1 Flash EXL3 ڈاؤن لوڈ، تشکیل، اجرا، جانچ اور کارکردگی کو بہتر بنانے کا طریقہ سیکھیں۔ اس رہنما میں خودکار لانچر، Engram اسٹوریج، DSpark قیاسی ڈیکوڈنگ، میموری حفاظتی اقدامات، ہم وقت سازی کے اختیارات، API درخواستیں، جانچ اور کارکردگی کی ٹیوننگ شامل ہیں۔

تقریباً 33 منٹ کا مطالعہ
EXL3 اور vLLM کے ساتھ دو DGX Spark پر DeepSeek V4.1 Flash

جائزہ

یہ پروجیکٹ دو NVIDIA GB10 DGX Spark سسٹمز پر DeepSeek V4.1 Flash کو مقامی طور پر چلاتا ہے۔ اس میں 2.9 bits-per-weight EXL3 چیک پوائنٹ، دونوں نوڈز کے درمیان ٹینسر پیراَلل ازم، مقامی sm_121a کرنلز، اور پورٹ 8888 پر OpenAI-compatible vLLM API استعمال ہوتی ہے۔

چلائے جانے والے ماڈل کا شناخت کنندہ DeepSeek-v4.1-Flash-EXL3 ہے۔ یہ تعیناتی صرف متن کے لیے ہے اور خاص طور پر CX7 کے ذریعے منسلک دو نوڈ والے GB10 کِٹ کے لیے بنائی گئی ہے۔

کنٹینر، vllm/vllm-openai:deepseekv41-flash-0909 پر EXL3 سپورٹ شامل کرتا ہے۔ یہ ARM64 vLLM امیج مطلوبہ DeepseekV41 آرکیٹیکچر بھی شامل رکھتی ہے۔

پروجیکٹ کیا فراہم کرتا ہے

  • مقامی OpenAI-compatible سروس: ایپلی کیشنز معیاری /v1/chat/completions اینڈ پوائنٹ کو کال کر سکتی ہیں۔
  • دو نوڈ والا ٹینسر پیراَلل ازم: ماڈل CX7 کنکشن پر ٹینسر پیراَلل سائز 2 کے ساتھ چلتا ہے۔
  • EXL3 کوانٹائزیشن: چیک پوائنٹ کا اوسط 2.9 bpw ہے اور یہ فی ٹینسر کوانٹائزیشن سیٹنگز کے ساتھ mul1 کوڈ بُک استعمال کرتا ہے۔
  • مقامی DSpark قیاسی عمل: ڈرافٹ ایکسپرٹس پہلے ہی چیک پوائنٹ میں mtp.* کے تحت محفوظ ہیں، اس لیے الگ ڈرافٹ ماڈل درکار نہیں۔
  • طویل سیاق کی سپورٹ: فراہم کردہ کنفیگریشن MAX_MODEL_LEN=600000 سیٹ کرتی ہے اور 2.5 GiB کا KV کیش پول استعمال کرتی ہے۔
  • فائل سے منسلک Engram ٹیبلز: غیر کوانٹائز شدہ Engram ڈیٹا میزبان میموری میں پن ہونے کے بجائے اصل ماڈل شارڈز 47 اور 48 سے پڑھا جاتا ہے۔
  • خودکار آغاز: start.sh وزن ڈاؤن لوڈ کرتی ہے، امیج حاصل یا تیار کرتی ہے، ورکر کے ساتھ فائلیں شیئر کرتی ہے، GPU چیکس چلاتی ہے، اور API شروع کرتی ہے۔
  • رن ٹائم تحفظات: لانچر بوٹ مارجن چیکس کرتا ہے، پری فل مراحل کے درمیان ایلوکیٹرز جاری کرتا ہے، لوڈنگ کے بعد پیج کیش ختم کرتا ہے، اور کنٹینرز کے OOM اسکورز ایڈجسٹ کرتا ہے۔

ہارڈویئر اور اسٹوریج کی ضروریات

یہ ریپوزٹری عین دو NVIDIA GB10 DGX Spark نوڈز کے لیے ہے۔ پہلے سے طے شدہ ہیڈ نوڈ کا پتہ 10.0.0.1 ہے، اور نوڈز CX7 کے ذریعے رابطہ کرتے ہیں۔ README میں آزمودہ انٹرفیس پہلے نوڈ پر enp1s0f1np1/rocep1s0f1 اور دوسرے نوڈ پر enp1s0f0np0/rocep1s0f0 درج ہیں۔

ماڈل ڈیٹا کے لیے تقریباً 387 GiB مختص کریں:

  • Mia-AiLab/DeepSeek-V4.1-Flash-EXL3-2.9bpw کے 39 EXL3 شارڈز کے لیے تقریباً 197 GiB۔
  • اصل DeepSeek شارڈز 47 اور 48، نیز انڈیکس کے لیے تقریباً 190 GiB۔ ان میں مقامی Engram ٹیبلز موجود ہیں۔
  • شائع شدہ کنٹینر امیج کے لیے تقریباً 9 GiB، جب مماثل امیج بنانے کے بجائے حاصل کی جا سکے۔

اگر آپ کے پاس مکمل DeepSeek-V4.1-Flash ڈائریکٹری پہلے سے موجود ہے تو Engram کا ماخذ دوبارہ ڈاؤن لوڈ کرنے سے بچنے کے لیے ENGRAM_DIR کو اس کی طرف مقرر کریں۔ اس مقصد کے لیے صرف شارڈز 47 اور 48 اور انڈیکس پڑھا جاتا ہے۔

DGX Spark پر میزبان RAM ہی GPU میموری بھی ہے۔ ہر CUDA ایلوکیشن فوری طور پر مشترکہ میموری استعمال کرتی ہے، اس لیے اسٹوریج اور میموری کی سیٹنگز الگ الگ تبدیل کریں اور طویل پرامپٹ کے ساتھ آزمائیں۔

ہیڈ نوڈ تیار کریں

1. ریپوزٹری کلون کریں اور ماحول کی فائل بنائیں

ہیڈ Spark پر موجود ریپوزٹری ڈائریکٹری سے تعیناتی چلائیں:

cp .env.example .env

اگر پہلی بار چلانے پر .env موجود نہ ہو تو لانچر اسے بھی بنا دیتا ہے۔ فائل کا جائزہ لیں اور ضرورت کے مطابق WORKER_USER اور GID جیسی قدریں اپنے سسٹمز کے لیے اپ ڈیٹ کریں۔

.env میں واضح طور پر نامزد قدریں کمانڈ لائن کے ماحول کے سابقوں پر ترجیح رکھتی ہیں، کیونکہ start.sh اپنی وراثتی ماحولیات کے اوپر اس فائل کو سورس کرتی ہے۔ مثال کے طور پر WEIGHT_SYNC=zfs ./start.sh چلانے کے بجائے .env کے اندر WEIGHT_SYNC تبدیل کریں۔

2. Hugging Face ڈاؤن لوڈ ٹولز انسٹال کریں

خودکار ماڈل ڈاؤن لوڈ کے لیے ٹرانسفر سپورٹ والی Hugging Face CLI درکار ہے:

pip install -U 'huggingface_hub[hf_transfer]'

ڈاؤن لوڈ دوبارہ جاری کیے جا سکتے ہیں۔ اگر رکا ہوا عمل ماڈل کو نامکمل چھوڑ دے تو لانچر یا ڈاؤن لوڈر دوبارہ چلائیں۔

3. سرور شروع کیے بغیر اختیاری طور پر ڈاؤن لوڈ کریں

vLLM بوٹ کرنے سے پہلے EXL3 اور Engram فائلیں تیار کرنے کے لیے چلائیں:

./download.sh

خودکار ڈاؤن لوڈ پہلے سے فعال ہے۔ اگر آپ فائلیں خود منظم کرنا چاہتے ہیں تو کنفیگریشن میں AUTO_DOWNLOAD=0 سیٹ کریں۔

سرور شروع کریں

ہیڈ نوڈ پر ریپوزٹری سے چلائیں:

./start.sh

پہلی بار چلنے پر لانچر درج ذیل اعلیٰ سطحی کارروائیاں انجام دیتا ہے:

  1. دستیاب میموری مارجن اور نوڈ کنفیگریشن چیک کرتا ہے۔
  2. غائب EXL3 اور Engram فائلیں ڈاؤن لوڈ کرتا ہے۔
  3. عوامی امیج ghcr.io/miaai-lab/deepseek-v4.1-flash-exl3-2x-dgx-sparks:2.9bpw حاصل کرتا ہے۔
  4. صرف اس وقت مقامی طور پر بناتا ہے جب ریسپی اسٹیمپ تبدیل ہو یا رجسٹری دستیاب نہ ہو۔
  5. وزن ورکر کے لیے دستیاب کرتا ہے۔
  6. EXL3 GEMM اور Engram dequantization کے GPU چیکس چلاتا ہے۔
  7. دو ٹینسر پیراَلل رینکس شروع کرتا ہے اور پورٹ 8888 پر API ظاہر کرتا ہے۔

صاف چیک آؤٹ کو شائع شدہ امیج کے ریسپی اسٹیمپ سے مماثل ہونا چاہیے، اس لیے عموماً کمپائلیشن ضروری نہیں ہوتی۔

امیج بنانے اور منتقلی کو کنٹرول کریں

  • BUILD=1 ./start.sh ہمیشہ امیج کو مقامی طور پر بناتا ہے۔
  • SKIP_BUILD=1 ./start.sh پل کیا گیا امیج برقرار رکھتا ہے، چاہے اس کا recipe stamp مختلف ہو۔
  • SKIP_PULL=1 ./start.sh کنٹینر رجسٹری سے رابطہ کرنے سے گریز کرتا ہے۔
  • PULL=1 ./start.sh مقامی stamp مماثل ہونے کے باوجود امیج دوبارہ pull کرتا ہے۔
  • SKIP_SHIP=1 ./start.sh head کو امیج worker میں کاپی کرنے سے روکتا ہے۔

پہلے سے طے شدہ طور پر، امیج بھیجنے کے لیے ایک مرحلہ وار tar فائل استعمال ہوتی ہے، جسے قابلِ ازسرنو آغاز rsync کے ذریعے منتقل کیا جاتا ہے۔ IMAGE_SHIP=stream مقرر کریں تاکہ docker save کو worker کے docker load میں pipe کیا جائے۔ Streaming کے لیے عارضی ڈسک اسپیس درکار نہیں، لیکن منتقلی میں خلل آنے پر یہ ابتدا سے دوبارہ شروع ہوتی ہے۔ auto موڈ قابلِ ازسرنو آغاز منتقلی کو ترجیح دیتا ہے اور worker کی ڈسک اسپیس محدود ہونے پر streaming پر منتقل ہو جاتا ہے۔

Deployment کو چیک اور منظم کریں

دونوں containers کو الگ الگ چلانے کے بجائے launcher کے management commands استعمال کریں:

./start.sh status
./start.sh logs
./start.sh logs worker
./start.sh stop
./start.sh restart

اگر worker کے پاس weights پہلے ہی synchronized ہیں تو synchronization مرحلہ دوبارہ دہرائے بغیر restart کریں:

SKIP_SYNC=1 ./start.sh restart

Startup کے دوران 420 سیکنڈ کا log-silence detector دونوں ranks سے Python stack traces جمع کرتا ہے۔ Diagnostic فائلیں logs/ کے تحت لکھی جاتی ہیں۔

اپنی پہلی API request بھیجیں

جب server صحت مند ہو جائے تو head node کو chat completion request بھیجیں۔ یہ smoke request thinking کو غیر فعال کرتی ہے تاکہ براہِ راست جواب آسانی سے دیکھا جا سکے:

curl -s http://127.0.0.1:8888/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"DeepSeek-v4.1-Flash-EXL3","messages":[{"role":"user","content":"What is 17*19? Reply with the integer only."}],"max_tokens":32,"temperature":0,"chat_template_kwargs":{"enable_thinking":false}}'

متوقع جواب 323 ہے۔ کوئی بھی OpenAI-compatible client یہی base URL اور model identifier استعمال کر سکتا ہے۔

تجویز کردہ sampling settings استعمال کریں

عام model استعمال کے لیے official sampling settings یہ ہیں:

  • temperature=1.0
  • top_p=0.95
  • Thinking فعال ہو

Chat template میں high reasoning effort پہلے سے طے شدہ ہے، جس کی نمائندگی 75 کرتا ہے۔ یہ 50 کے لیے low، 100 کے لیے max، یا 1 سے 100 تک کوئی integer بھی قبول کرتا ہے۔

تجویز کردہ sampling configuration استعمال کرنے والی request یوں ہو سکتی ہے:

curl -s http://127.0.0.1:8888/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"DeepSeek-v4.1-Flash-EXL3","messages":[{"role":"user","content":"Explain how tensor parallel inference works."}],"max_tokens":512,"temperature":1.0,"top_p":0.95,"reasoning_effort":"high"}'

DSpark Speculative Decoding کو سمجھیں

یہ deployment checkpoint میں شامل draft experts کے ساتھ DSpark speculative decoding استعمال کرتا ہے۔ الگ drafter کو download، load یا serve کرنے کی ضرورت نہیں۔

بنیادی vLLM configuration اس کے مساوی ہے:

--speculative-config '{"method":"dspark","num_speculative_tokens":3}'

Checkpoint میں draft block-size کی زیادہ سے زیادہ حد پانچ ہے، لیکن بھیجی گئی setting میں تین speculative tokens استعمال ہوتے ہیں کیونکہ نثر پر یہ زیادہ تیز ثابت ہوئی۔ Capture sizes میں 1 2 3 4 6 8 12 18 24 شامل ہیں، جن میں size چھ بھی شامل ہے کیونکہ دو sequences میں سے ہر ایک تین speculative tokens تیار کرتی ہے۔

رپورٹ شدہ پیمائشوں میں DSpark نے single-stream decoding کو بہتر بنایا۔ وسیع batches کے لیے اسے SPEC_METHOD=none کے ذریعے غیر فعال کریں۔ اس سے تقریباً 3.5 GiB بھی آزاد ہو جاتا ہے۔ README کے مطابق ایک speculative stream پر تقریباً 31.6 tokens فی سیکنڈ حاصل ہوئے، جبکہ چار streams پر speculation بند serving نے زیادہ aggregate throughput حاصل کیا۔

Memory کو محفوظ طریقے سے منظم کریں

ہر node پر تقریباً 99.5 GiB EXL3 weights فی rank، 2.5 GiB KV pool، contexts، NCCL، workspaces اور CUDA graphs کے لیے تقریباً 5 سے 7 GiB، اور vLLM processes، Docker، operating system اور desktop کے لیے تقریباً 9 GiB شامل ہیں۔

بھیجی گئی limits یہ ہیں:

  • MAX_MODEL_LEN=600000
  • MAX_NUM_SEQS=2
  • MAX_NUM_BATCHED_TOKENS=1024
  • 2.5 GiB کا KV cache pool

KV layout خودکار طور پر DeepSeek کے fp8_ds_mla کے طور پر منتخب کیا جاتا ہے۔ --kv-cache-dtype فراہم نہ کریں۔ ناپے گئے pool نے 614,400 کی context limit پر 774,400 tokens رکھے، جبکہ فی token لاگت تقریباً 3.4 KiB تھی۔

اس checkpoint کی quantization کا اندازہ 2.9 کو integer 2 میں تبدیل کر کے نہ لگائیں۔ اس کا quantization parameter ہر tensor کے لیے منتخب کیا جاتا ہے، اور مختلف routed experts، shared experts، attention matrices، Engram tensors، MTP tensors اور language-model head مختلف values استعمال کرتے ہیں۔

Warm-up کے بعد، رپورٹ شدہ tests میں head نے تقریباً 4.07 سے 4.21 GiB دستیاب memory برقرار رکھی۔ 601,000-token prefill نے یہ گنجائش کم کر کے تقریباً 2.1 GiB کر دی۔ اس لیے تبدیلیوں کی جانچ startup کے فوراً بعد کرنے کے بجائے طویل prefill کے بعد کریں۔

ایک وقت میں memory سے متعلق صرف ایک setting بڑھائیں۔ README خبردار کرتا ہے کہ KV pool میں 0.5 GiB کا اضافہ prefill margin میں تقریباً 1 GiB کی لاگت ڈال سکتا ہے۔ 3 GiB pool نے مختصر smoke test پاس کیا، لیکن 600,000-token prompt میں تقریباً 470,000 tokens پر ناکام ہو گیا۔

اختیاری memory guard احتیاط سے استعمال کریں

scripts/memguard.sh ہر سیکنڈ میں ایک بار /proc/meminfo چیک کرتا ہے اور DSV41_MEM_GUARD_GIB سے کم مسلسل دو samples ملنے کے بعد مقامی serving container کو ختم کر دیتا ہے۔ اس threshold کی default value 1.5 GiB ہے۔

گارڈ بطورِ ڈیفالٹ غیر فعال ہے کیونکہ یہ تعین نہیں کر سکتا کہ میموری کس پراسیس نے استعمال کی۔ یہ ہمیشہ اپنا vLLM کنٹینر ختم کرتا ہے، چاہے میموری کا دباؤ کسی غیر متعلقہ میزبان ورک لوڈ کی وجہ سے پیدا ہوا ہو۔ اسے واضح طور پر فعال کرنے کے لیے یہ سیٹ کریں:

DSV41_MEM_GUARD=1

میزبان پر چلنے والے بھاری جابز کے لیے README اس کے بجائے مسئلہ پیدا کرنے والے جاب کو محدود کرنے کی تجویز دیتی ہے:

systemd-run --scope -p MemoryMax=2G <job>

تعیناتی میں اب بھی دونوں کنٹینرز کے لیے --oom-score-adj 1000 استعمال ہوتا ہے، نیز بوٹ مارجن پری فلائٹ، ہر پری فل کے بعد ایلوکیٹر ریلیز، اور لوڈ کے بعد پیج کیش ڈراپ بھی شامل ہیں۔

وزن کی ہم زمانی کی حکمتِ عملی منتخب کریں

NFS: ڈیفالٹ

NFS وہ تشکیل ہے جو آزمودہ کِٹ کے لیے موزوں ہے۔ یہ vllm-fn-nfs ایکسپورٹر کو دوبارہ استعمال کرتا ہے، EXL3 اور slim Engram ڈائریکٹریز کو ظاہر کرتا ہے، اور انہیں ورکر کنٹینرز میں بالترتیب /model اور /engram-src کے طور پر ماؤنٹ کرتا ہے۔

./start.sh share
./start.sh

start.sh شیئرنگ کا مرحلہ خودکار طور پر انجام دیتا ہے، اس لیے واضح share کمانڈ بنیادی طور پر ایکسپورٹ تیار کرنے یا اس کی خرابی دور کرنے کے وقت مفید ہے۔

ZFS: نوڈ-لوکل نقول

ہر نوڈ پر مقامی ڈیٹاسیٹ برقرار رکھنے کے لیے .env میں WEIGHT_SYNC=zfs سیٹ کریں۔ ZFS لچک بہتر بنا سکتا ہے اور ابتدائی نقل کے بعد صرف تبدیل شدہ بلاکس بھیجتا ہے۔ یہ اسنیپ شاٹ پر مبنی رول بیک بھی ممکن بناتا ہے۔

اس کی لاگت خاصی زیادہ ہے: ہر نوڈ کو تقریباً 385 GiB خالی پول اسپیس درکار ہوتی ہے۔ README کے مطابق آزمودہ دوسرے Spark میں صرف تقریباً 41 GiB خالی تھا، اس لیے وہاں ZFS استعمال نہیں کیا جا سکا۔

ہر نوڈ پر ایک نمائندہ سیٹ اپ یہ ہے:

sudo apt-get install -y zfsutils-linux
sudo zpool create -f models <vdev>
sudo zfs create -o recordsize=1M -o atime=off -o compression=lz4 \
  -o mountpoint=/path/to/model models/dsv41-exl3
sudo zfs create -o recordsize=1M -o atime=off -o compression=lz4 \
  -o mountpoint=/path/to/engram models/dsv41-engram
sudo zfs allow -u "$WORKER_USER" create,destroy,mount,receive,snapshot,rollback models

Engram ڈیٹاسیٹ میں صرف شارڈز 47 اور 48 کے ساتھ انڈیکس شامل کریں۔ مکمل 476 GiB کے native model tree کو کاپی نہ کریں۔ اگر پول یا ورکر کا zfs recv دستیاب نہ ہو تو لانچر اسٹریمنگ پر واپس آ جاتا ہے۔

Rsync: ایک سادہ مقامی کاپی

WEIGHT_SYNC=rsync ZFS پول کی ضرورت کے بغیر روایتی نوڈ-لوکل کاپی بناتا ہے۔ یہ ZFS کی بلاک سطح کی incremental اپ ڈیٹس فراہم نہیں کرتا۔

تیز تر پری فل کے لیے Engram ڈیٹا پیک کریں

Engram ٹیبلز native FP8 فارمیٹ میں رہتی ہیں اور quantized EXL3 tree کا حصہ نہیں ہیں۔ بطورِ ڈیفالٹ، فائل پر مبنی embedding implementation تقریباً 47 GiB فی layer کو میموری میں پن کیے بغیر rows حاصل کرتی ہے۔

Rank-specific Engram row files کو ہر نوڈ کے مقامی NVMe پر منتقل کرنے کے لیے چلائیں:

./start.sh pack

tensor parallel size دو ہونے پر پیکنگ فی نوڈ تقریباً 94 GiB لکھتی ہے۔ یہ اختیاری ہے اور بوٹ کے لیے ضروری نہیں۔ رپورٹ کیے گئے ٹیسٹس میں مقامی packed Engram files نے prefill کارکردگی تقریباً 25 سے 50 فیصد بہتر بنائی، کیونکہ row misses میں NFS کے بجائے مقامی direct I/O استعمال ہوا۔

Dequantization kernel کو دیتے وقت Engram rows کو fp8_e4m3fn کے طور پر typed رہنا چاہیے۔ انہیں uint8 سمجھنے سے بظاہر قابلِ قبول مگر غلط output پیدا ہو سکتا ہے۔

توثیقی ٹیسٹس چلائیں

ریپوزٹری میں source-level checks شامل ہیں جن کے لیے PyTorch یا vLLM درکار نہیں:

python3 tests/test_numeric_config.py
python3 tests/test_engram_src.py
python3 tests/test_engram_secondary.py
python3 tests/test_k_map.py
python3 tests/test_memory_log.py
python3 tests/test_exl3_lm_head.py
python3 tests/test_sm120_block64.py
python3 tests/test_h2d_stage.py
python3 scripts/weight_budget.py --tp 2

chat-template parity test کے لیے transformers اور اصل model کی encoding/encoding.py درکار ہے:

python3 tests/test_chat_template.py --src /path/to/DeepSeek-V4.1-Flash

API چلنے کے بعد end-to-end smoke test چلائیں:

bash tests/test_smoke.sh

Smoke test model سے 17*19 حساب کرنے کو کہتا ہے اور 323 کی توقع کرتا ہے۔ سروس شروع کرنے سے پہلے start.sh عارضی کنٹینر میں GPU parity اور Engram dequantization checks بھی چلاتا ہے۔ نتائج logs/overlay-verify.log میں لکھے جاتے ہیں۔

جدید عملی تجاویز

  • ایک یا دو اسٹریمز کے لیے DSpark کو ترجیح دیں: رپورٹ کردہ سنگل اسٹریم ڈی کوڈ رفتار 31.6 ٹوکن فی سیکنڈ تھی، جبکہ دو اسٹریمز پر مجموعی رفتار 42.5 ٹوکن فی سیکنڈ رہی۔
  • وسیع بیچز کے لیے قیاسی عمل کو غیر فعال کریں: SPEC_METHOD=none کے ساتھ سنگل اسٹریم تھروپٹ کم ہوا، لیکن رپورٹ کردہ ٹیسٹ میں چار اسٹریمز کا مجموعی تھروپٹ 53.7 ٹوکن فی سیکنڈ تک پہنچ گیا۔
  • بار بار استعمال ہونے والے طویل پرامپٹس کے لیے Engram کو پیک کریں: مقامی NVMe قطار فائلیں ہیڈ نوڈ کے NFS ایکسپورٹ پر انحصار کم کرتی ہیں اور پریفِل کی رفتار میں نمایاں بہتری لا سکتی ہیں۔
  • ڈیپلائمنٹ کو صرف متنی رکھیں: SM120 کرنل انویلپ ماڈل کی وژن ٹوکن چوڑائی کے لیے مطلوبہ sparse-MLA کرنل فراہم نہیں کرتا۔
  • EXL3 معاون اسٹریمز کو بلا سوچے دوبارہ فعال نہ کریں: ڈیپلائمنٹ EXL3 اسٹریمز کو سیریلائز کرتی ہے، کیونکہ مختلف CUDA اسٹریمز پر چلنے والے دو کرنلز رن ٹائم کے ہر ڈیوائس کے لیے واحد لاک بفر کے ساتھ ڈیڈلاک کا شکار ہو سکتے ہیں۔
  • درست نیٹ ورک انٹرفیسز کی نگرانی کریں: NCCL 10.0.0.x لوپ بیک عرفی نام استعمال نہیں کر سکتا۔ فی NIC غلط GID انتخاب تقریباً ایک منٹ بعد ibv_modify_qp errno 61 کے ساتھ ناکام ہو سکتا ہے۔
  • طویل پریفِل کی میموری کا معائنہ کریں: بوٹ کی کامیابی اور مختصر اسموک ٹیسٹس اس بات کا ثبوت نہیں کہ بڑا KV پول یا کانٹیکسٹ سیٹنگ محفوظ ہے۔
  • ریپوزٹری لانچر استعمال کریں: یہ NFS یا مقامی ہم وقت سازی، پری فلائٹ جانچ، امیج کی تصدیق، دو رینک اسٹارٹ اپ، اور تشخیصی کارروائیوں کو مربوط کرتا ہے۔

متوقع کارکردگی

شائع شدہ پیمائشوں کے مطابق ایک ڈی کوڈ اسٹریم کے لیے 31.6 ٹوکن فی سیکنڈ اور دو اسٹریمز کے لیے مجموعی طور پر 42.5 ٹوکن فی سیکنڈ حاصل ہوئے۔ پیک کیے گئے Engram ڈیٹا اور گروپ کردہ ایکسپرٹ کرنلز کے ساتھ مختصر پرامپٹ پریفِل تقریباً 965 سے 1,041 ٹوکن فی سیکنڈ تھا۔

طویل پرامپٹ کا پریفِل قدرتی طور پر سست ہو جاتا ہے۔ رپورٹ کردہ مثالوں میں 100,000 ٹوکن کے پرامپٹ کے لیے تقریباً 979 ٹوکن فی سیکنڈ، 455,000 ٹوکن پر 802 ٹوکن فی سیکنڈ، اور 601,000 ٹوکن پر 810 ٹوکن فی سیکنڈ شامل ہیں۔ حقیقی نتائج پرامپٹ کی ساخت، اسٹوریج کی ترتیب، قیاسی عمل، بیچ کی چوڑائی، اور پریفِل چنک کے لیے مقررہ سائز پر منحصر ہوتے ہیں۔

نتیجہ

یہ منصوبہ DeepSeek V4.1 Flash کو دو GB10 DGX Sparks پر چلانے کے لیے درکار خصوصی کرنلز، EXL3 لوڈر، فائل پر مبنی Engram نفاذ، نیٹ ورکنگ کی ترتیب، میموری کنٹرولز، اور لانچر فراہم کرتا ہے۔ فراہم کردہ ڈیفالٹس سے آغاز کریں، اسموک ٹیسٹ کے ذریعے API کی تصدیق کریں، پھر ایک وقت میں صرف ایک سیٹنگ کو ٹیون کریں۔ محفوظ ترین آپریشن کے لیے حقیقت پسندانہ طویل پریفِل ورک لوڈز کے دوران تھروپٹ اور دستیاب میموری، دونوں کا جائزہ لیں۔