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

Host-RAM آف لوڈنگ کے ساتھ ایک 24 GB RTX 3090 پر GLM-5.3-Flash چلائیں

یہ ٹیوٹوریل بتاتا ہے کہ glm53-flash-offload کس طرح pinned host memory، elastic GPU expert cache، zero-copy PCIe access اور اختیاری AVX2 CPU computation کو یکجا کر کے ایک 24 GB NVIDIA GPU پر GLM-5.3-Flash چلاتا ہے۔ آپ Docker image انسٹال کریں گے، fast یا exact mode منتخب کریں گے، API کال کریں گے، کارکردگی کی توثیق کریں گے اور deployment کو بہتر بنائیں گے۔

تقریباً 33 منٹ کا مطالعہ
Host-RAM آف لوڈنگ کے ساتھ ایک 24 GB RTX 3090 پر GLM-5.3-Flash چلائیں

جائزہ

glm53-flash-offload، GLM-5.3-Flash کے 125.3 GB، EXL3 3.05-bpw بلڈ کو ایک 24 GB NVIDIA GPU اور میزبان DDR4 میموری پر چلاتا ہے۔ یہ OpenAI سے مطابقت رکھنے والی HTTP API فراہم کرتا ہے، جبکہ ماڈل کے routed mixture-of-experts وزن بنیادی طور پر pinned سسٹم RAM میں رکھتا ہے۔

یہ پروجیکٹ اسٹاک exllamav3 1.5.1 پر مبنی مختصر monkeypatches کا مجموعہ ہے، جس میں کئی چھوٹے custom kernels شامل ہیں۔ اس کے لیے exllamav3 کے سورس میں ترمیم کی ضرورت نہیں۔ دستاویزی configuration کی پیمائش ایک RTX 3090 پر کی گئی، جو PCIe 4.0 x16 کے ذریعے AMD EPYC 7443P سسٹم سے منسلک تھا۔

مرکزی تصور یہ ہے کہ کثرت سے استعمال ہونے والے experts کو ایک elastic GPU cache میں رکھا جائے۔ جو experts cache میں موجود نہ ہوں، انہیں PCIe کے ذریعے pinned host memory سے براہِ راست پڑھا جا سکتا ہے۔ fast mode میں، سب سے کم استعمال ہونے والے decode misses کو AVX2 CPU worker کے ذریعے evaluate کیا جا سکتا ہے۔

اہم خصوصیات

  • Single-GPU deployment: ایک 24 GB RTX 3090-class GPU کے ساتھ GLM-5.3-Flash چلاتا ہے۔
  • OpenAI-compatible API: chat completions، text completions، model discovery، streaming، reasoning content، اور OpenAI-style tool calls کو سپورٹ کرتا ہے۔
  • Pinned zero-copy storage: تمام routed experts کو pinned host RAM میں رکھا جاتا ہے اور CUDA unified virtual addressing کے ذریعے ان تک رسائی حاصل کی جا سکتی ہے۔
  • Elastic GPU expert cache: زیادہ استعمال ہونے والے experts دستیاب VRAM میں رہتے ہیں، جبکہ طویل prefill activations اور staging buffers کے لیے cache space عارضی طور پر واپس کیا جا سکتا ہے۔
  • Prefill staging: غیر cached experts کو ایک layer پہلے copy کیا جاتا ہے تاکہ PCIe transfer computation کے ساتھ بیک وقت ہو سکے۔
  • Optional CPU tier: fast mode منتخب کم استعمال ہونے والے decode misses کو AVX2 CPU kernel کو تفویض کرتا ہے۔
  • Batched decode: دستاویزی -ambs 4 configuration کے ساتھ زیادہ سے زیادہ چار streams ایک ساتھ decode کی جا سکتی ہیں۔
  • Reproducible configuration: model revision، container digest، exllamav3 version، Triton selections، benchmarks، اور reference quality panel مقررہ ہیں۔

fast اور exact mode میں انتخاب

سرور GLM53_MODE environment variable کے ذریعے دو operating modes فراہم کرتا ہے۔

Fast mode

fast default mode ہے۔ یہ GPU expert cache، zero-copy cache misses، منتخب کم استعمال ہونے والے decode misses کے لیے AVX2 CPU processing، batched decode، اور fused decode kernels کو یکجا کرتا ہے۔ پیمائش کیے گئے host پر اس نے تقریباً 218 GiB، یعنی 234 GB، host RAM استعمال کی۔

شائع شدہ campaign میں ایک decode stream کے لیے تقریباً 28.15 tokens per second، دو streams کے لیے 31.57 aggregate tokens per second، اور چار streams کے لیے 33.98 aggregate tokens per second ریکارڈ کیے گئے۔ موجودہ digest کے image smoke test میں بالترتیب 28.88، 31.27، اور 35.00 aggregate tokens per second ریکارڈ ہوئے۔

معیار سے متعلق انتباہ: prefill exact ہے، لیکن fast-mode decode اسٹاک exllamav3 کے مقابلے میں bit-exact نہیں۔ paired decode check میں mean KL 0.0053 اور top-1 agreement 0.977 رپورٹ ہوا۔ جب output equivalence درکار ہو تو exact mode استعمال کریں۔

Exact mode

exact CPU tier اور صرف fast mode میں دستیاب decode kernels کو غیر فعال کرتا ہے۔ یہ GPU expert cache اور zero-copy host-memory misses برقرار رکھتا ہے۔ reference panel میں top-1 agreement 1.0000 اور KL 0 ریکارڈ ہوا، جبکہ host-memory استعمال تقریباً 111 GiB، یعنی 119 GB تھا۔

Exact mode سست ہے، لیکن RAM بہت کم استعمال کرتا ہے۔ مختصر آزمودہ context پر single-stream decode rate 12.57 tokens per second تھی، جبکہ جب اسٹاک exllamav3 نے فٹ نہ ہونے والے experts اپنے CPU worker پر رکھے تو یہ تقریباً 7.5 سے 8.4 tokens per second تھی۔

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

GPU اور driver

  • 24 GB VRAM والا ایک NVIDIA GPU۔
  • sm_86 GPU، مثلاً RTX 3090 یا A5000، measured target ہے۔
  • شامل sm_86 binaries sm_89 پر بھی چلتی ہیں، جس میں RTX 4090 شامل ہے، لیکن اس configuration کی پیمائش نہیں کی گئی۔
  • CUDA 13.0-capable NVIDIA driver درکار ہے کیونکہ image میں CUDA 13.0.3 استعمال ہوتا ہے۔
  • PCIe 4.0 x16 تجویز کیا جاتا ہے۔ پیمائش کیے گئے link پر cache misses تقریباً 25 GB/s استعمال کرتے ہیں۔

Host memory

  • Fast mode: جب دیگر کام بہت کم چل رہے ہوں تو 256 GiB total memory کم از کم ضرورت ہے؛ 320 GB یا اس سے زیادہ تجویز کیا جاتا ہے۔ اگر Docker memory limits استعمال ہوں تو کم از کم 230g مختص کریں۔
  • Exact mode: 128 GiB کم از کم ہے، جبکہ 160 GB یا اس سے زیادہ تجویز کیا جاتا ہے۔

CPU اور storage

  • Fast mode کے لیے AVX2، FMA، اور F16C والا x86-64 CPU درکار ہے۔
  • موزوں fast-mode behavior کے لیے تقریباً 24 physical cores اور eight-channel DDR4 یا اس سے بہتر memory تجویز کی جاتی ہے۔
  • Checkpoint ڈسک پر تقریباً 117 GiB، یعنی 125.3 GB، جگہ لیتا ہے۔
  • ماڈل لوڈ ہونے کا وقت کم کرنے کے لیے NVMe storage تجویز کی جاتی ہے۔
  • دستاویزی setup کے لیے Docker، NVIDIA Container Toolkit، اور Hugging Face CLI درکار ہیں۔

Docker کے ساتھ سرور انسٹال اور شروع کریں

مرحلہ 1: checkpoint ڈاؤن لوڈ کریں

مقررہ 3.05-bpw checkpoint کو مقامی directory میں ڈاؤن لوڈ کریں:

hf download turboderp/GLM-5.3-Flash-exl3 \
  --revision 3.05bpw \
  --local-dir /data/GLM-5.3-Flash-exl3-3.05bpw

اس کے بجائے آپ /models پر ایک خالی directory mount کر سکتے ہیں۔ اگر config.json موجود نہ ہو تو container configured checkpoint کو اس directory میں ڈاؤن لوڈ کر دے گا۔

مرحلہ 2: fast mode شروع کریں

درج ذیل command GPU 0 پر سرور شروع کرتی ہے اور اسے port 30000 پر publish کرتی ہے۔ اس میں streaming-delivery fix والا image digest استعمال ہوتا ہے۔

docker run -d \
  --name glm53 \
  --gpus '"device=0"' \
  --ulimit memlock=-1 \
  --shm-size 16g \
  -p 30000:30000 \
  -v /data/GLM-5.3-Flash-exl3-3.05bpw:/models \
  ghcr.io/0xsero/glm53-flash-offload@sha256:bb633b0bcb85573ad40b6c408af5e1036ae062c593e42479f4e4d2ab521e551d

--ulimit memlock=-1 کی ترتیب تجویز کی جاتی ہے کیونکہ سرور میزبان میموری کی بڑی مقدار کو پن کرتا ہے۔ شائع کردہ امیج آزمائے گئے ڈرائیور پر اس کے بغیر بھی لوڈ ہو گئی، لیکن ہر میزبان کے لیے اس رویے کو فرض نہیں کرنا چاہیے۔

مرحلہ 3: اسٹارٹ اپ دیکھیں

docker logs -f glm53

loaded in ... s پر مشتمل پیغام کا انتظار کریں۔ دستاویزی نظام پر اسٹارٹ اپ میں تقریباً دو سے تین منٹ لگتے ہیں، جس کا انحصار کیش اور میزبان کے حالات پر ہوتا ہے۔

مرحلہ 4: صحت کی تصدیق کریں

curl -s http://localhost:30000/health

عین موڈ چلائیں

آؤٹ پٹ کی مماثلت کو ترجیح دینے اور میزبان میموری کے استعمال کو کم کرنے کے لیے -e GLM53_MODE=exact شامل کریں:

docker run -d \
  --name glm53-exact \
  --gpus '"device=0"' \
  --ulimit memlock=-1 \
  --shm-size 16g \
  -p 30000:30000 \
  -e GLM53_MODE=exact \
  -v /data/GLM-5.3-Flash-exl3-3.05bpw:/models \
  ghcr.io/0xsero/glm53-flash-offload@sha256:bb633b0bcb85573ad40b6c408af5e1036ae062c593e42479f4e4d2ab521e551d

تیز اور عین مثالوں کو بیک وقت ایک ہی پورٹ پر نہ چلائیں۔ موڈ تبدیل کرنے سے پہلے پہلے کنٹینر کو روک کر حذف کریں:

docker rm -f glm53

بنیادی API استعمال

چیٹ مکمل کرنے کی درخواست بھیجیں

curl -s http://localhost:30000/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"glm-5.3-flash","messages":[{"role":"user","content":"Explain zero-copy model offloading."}],"max_tokens":512}'

پیش کیے جانے والے ماڈل کا طے شدہ نام glm-5.3-flash ہے۔ واضح طور پر ترتیب نہ دی جائے تو max_tokens کسی چھوٹی مقررہ حد کے بجائے باقی ماندہ کانٹیکسٹ پر ڈیفالٹ ہوتا ہے۔

تھنکنگ غیر فعال کریں

GLM کی reasoning reasoning_content میں واپس کی جاتی ہے۔ کسی درخواست کے لیے تھنکنگ غیر فعال کرنے کے لیے چیٹ ٹیمپلیٹ کا آپشن بھیجیں:

curl -s http://localhost:30000/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"glm-5.3-flash","messages":[{"role":"user","content":"Reply with one sentence."}],"chat_template_kwargs":{"enable_thinking":false},"max_tokens":128}'

جواب کو اسٹریم کریں

curl -N http://localhost:30000/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"glm-5.3-flash","messages":[{"role":"user","content":"Write a short explanation of mixture-of-experts models."}],"stream":true,"max_tokens":512}'

اوپر دکھایا گیا پن شدہ bb633b0b... ڈائجسٹ استعمال کریں۔ پرانی 1159044a... امیج پوری رفتار سے تیار کرتی تھی، لیکن آخر میں زیر التوا واقعات کا بیک لاگ فلش کرنے سے پہلے اسٹریمنگ ایونٹس تقریباً نصف رفتار سے فراہم کرتی تھی۔

دستیاب ماڈلز کی فہرست بنائیں

curl -s http://localhost:30000/v1/models

رن ٹائم کے اعدادوشمار دیکھیں

curl -s http://localhost:30000/stats

اعدادوشمار کے اینڈ پوائنٹ میں expert-cache ہٹ کی معلومات اور CPU-tier کاؤنٹرز شامل ہیں۔ اضافی اینڈ پوائنٹس میں /v1/completions، /server_info، اور SGLang کی ساخت والی /generate اور /tokenize روٹس شامل ہیں۔

یہ تعیناتی صرف متنی ہے۔ چیک پوائنٹ کا vision tower لوڈ نہیں کیا جاتا۔

OpenAI طرز کے ٹولز استعمال کریں

چیٹ اینڈ پوائنٹ tools فیلڈ قبول کرتا ہے۔ GLM کے اندرونی <tool_call> فارمیٹ میں تیار کیے گئے ٹول ایکسپریشنز کو جواب میں OpenAI سے مطابقت رکھنے والے tool_calls میں تبدیل کر دیا جاتا ہے۔ لہٰذا کلائنٹ ایپلی کیشنز معمول کا tool-calling loop استعمال کر سکتی ہیں: ٹول کی تعریفیں بھیجیں، اسسٹنٹ کی ٹول کال کا جائزہ لیں، فنکشن چلائیں، اور ٹول کا نتیجہ ایک اور پیغام کے طور پر واپس بھیجیں۔

کانٹیکسٹ اور سرور آرگیومینٹس ایڈجسٹ کریں

امیج نام کے بعد رکھے گئے آرگیومینٹس سرور کمانڈ میں شامل کر دیے جاتے ہیں، اور آخری قدر مؤثر ہوتی ہے۔ مثال کے طور پر، 65,536 ٹوکن کا KV کیش استعمال کریں:

docker run -d \
  --name glm53-64k \
  --gpus '"device=0"' \
  --ulimit memlock=-1 \
  --shm-size 16g \
  -p 30000:30000 \
  -v /data/GLM-5.3-Flash-exl3-3.05bpw:/models \
  ghcr.io/0xsero/glm53-flash-offload@sha256:bb633b0bcb85573ad40b6c408af5e1036ae062c593e42479f4e4d2ab521e551d \
  -cs 65536

چھوٹا KV کیش مزید expert-cache سلاٹس کے لیے جگہ چھوڑ سکتا ہے۔ شائع کردہ بینچ مارک کنفیگریشن میں 131,072 ٹوکن کا KV کیش، آٹھ کی زیادہ سے زیادہ بیچ سائز، اور 8,192 ٹوکن کا chunk size استعمال کیا گیا تھا۔

Docker کے بغیر انسٹال کریں

مقامی انسٹالیشن کے لیے ہدف GPU کے لیے بنایا گیا exllamav3 1.5.1 درکار ہے۔ پروجیکٹ کے کلون سے ایکسٹینشن انسٹالر چلائیں، پھر ریپوزٹری اور ماڈل کے راستے متعین کر کے فراہم کردہ entrypoint شروع کریں:

scripts/install.sh
GLM53_ROOT=$PWD \
GLM53_MODEL_DIR=/path/to/model \
docker/entrypoint.sh

انسٹالر پروجیکٹ کی حسب ضرورت ایکسٹینشنز بناتا ہے۔ Docker اب بھی سب سے زیادہ قابل تکرار راستہ ہے کیونکہ یہ CUDA، PyTorch، Triton، SGLang، exllamav3، پروجیکٹ commit، اور آزمائی گئی سرور کنفیگریشن کو پن کرتا ہے۔

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

حوالہ پینل کا اسکور لیں

ریپوزٹری کے کلون سے شامل کردہ صرف معیاری لائبریری استعمال کرنے والا بینچ مارک کلائنٹ چلائیں:

python3 bench/score_ref_panel.py \
  --url http://127.0.0.1:30000 \
  --panel reference/glm-5.3-flash-exl3-ref-panel.json \
  --out score.json

ٹیچر فورسڈ پینل کو تیز اور عین دونوں موڈز میں top-1 agreement 1.0000 اور KL 0 رپورٹ کرنا چاہیے۔ یہ پینل prefill یا teacher-forced راستے کا جائزہ لیتا ہے اور یہ ثابت نہیں کرتا کہ تیز موڈ میں autoregressive decode عین ہے۔

رفتار کا سوئپ چلائیں

python3 bench/sweep.py \
  --url http://127.0.0.1:30000 \
  --card rtx-3090-24gb/glm-5.3-flash-offload \
  --template glm \
  --config "bb633b0b fast" \
  --prefill 8192 32768 \
  --conc 1 2 4 \
  --reps 3 \
  --dec-reps 2 \
  --no-early-exit \
  --out sweep.json

اسٹریمنگ کی ترسیل چیک کریں

python3 bench/stream_rate.py --url http://127.0.0.1:30000

کامیاب نتیجے میں متن تقریباً یکساں رفتار سے موصول ہونا چاہیے، نہ کہ جواب کا تقریباً نصف آخر میں ایک بڑے حصے کی صورت میں ظاہر ہو۔

اعلیٰ درجے کی ٹیوننگ

CPU ٹئیر کا سائز مقرر کریں

بطور ڈیفالٹ، GLM53_CT_CPUS=auto ہر فزیکل کور کے لیے ایک لاجیکل CPU منتخب کرتا ہے اور پہلے دو فزیکل کور آپریٹنگ سسٹم اور GPU چلانے والے Python تھریڈ کے لیے دستیاب چھوڑتا ہے۔ ناپے گئے 24 کور والے میزبان پر اس کے نتیجے میں CPUs 2 سے 23 اور 22 ورکر تھریڈز استعمال ہوئے۔

واضح تخصیص کے لیے اس طرح کی قدریں مقرر کریں:

-e GLM53_CT_CPUS=2-23 \
-e GLM53_CT_THREADS=22

CPU لاگت کا ماڈل GLM53_CT_B استعمال کرتا ہے، جسے 22 تھریڈز کے ساتھ فی ایکسپرٹ 0.104 ملی سیکنڈ ناپا گیا ہے۔ N ورکر تھریڈز کے لیے README میں اسے 0.104 x 22 / N کے طور پر تخمینہ لگانے کی سفارش کی گئی ہے۔ مثال کے طور پر، 16 کور والا میزبان جس میں دو کور خالی چھوڑے جائیں، 14 ورکر تھریڈز اور تقریباً 0.16 کی قدر استعمال کرے گا۔

تقریباً 12 سے کم فزیکل کورز کی صورت میں توقع ہے کہ زیادہ تر مسز PCIe پاتھ پر واپس جائیں گے، جس سے کارکردگی exact موڈ کے قریب پہنچ جائے گی۔ ایسی صورت میں exact موڈ بہتر انتخاب ہو سکتا ہے۔

CPU ٹئیر کی میموری ترتیب کو کنٹرول کریں

GLM53_CT_SWZ=1 CPU ٹئیر کو ایکسپرٹس کی الگ بلاک-متصل نقل استعمال کرنے کے لیے کہتا ہے۔ یہی ناپی گئی تیز ترتیب ہے اور اس سے تقریباً 114.2 GB RAM استعمال ہوتی ہے۔ اسے 0 پر مقرر کرنے سے CPU ٹئیر براہِ راست pinned home copy پڑھتا ہے، جس سے میموری کا استعمال نمایاں طور پر کم ہو جاتا ہے، لیکن پروجیکٹ کے مطابق CPU expert kernel benchmark تقریباً 40% سست ہو جاتا ہے۔ اس ترتیب کے لیے end-to-end کارکردگی نہیں ناپی گئی۔

کیش ریزرو کو ٹیون کریں

GLM53_EC_RESERVE_GB expert cache مختص کرنے کے بعد VRAM خالی رکھتا ہے۔ fast موڈ میں ڈیفالٹ 1.5 GB اور exact موڈ میں 1.0 GB ہے۔ fast موڈ کا ریزرو 1.5 GB پر رکھیں، الا یہ کہ طویل prefills میں میموری ختم ہو جائے۔

GLM53_EC_ELASTIC_GB کا ڈیفالٹ 10 GB ہے۔ کیش میموری کی یہ مقدار prefill activations اور staging کے لیے جاری کی جا سکتی ہے، پھر decode کے لیے دوبارہ حاصل کی جا سکتی ہے۔ GLM53_EC_STAGE_GB کا ڈیفالٹ فی staging buffer 2.6 GB ہے، جبکہ overlap کے لیے دو buffers استعمال ہوتے ہیں۔

بڑے GPUs استعمال کریں

expert cache ماڈل لوڈ ہونے اور ترتیب دیے گئے ریزرو کے بعد دستیاب VRAM سے اپنا سائز مقرر کرتا ہے۔ اس لیے 32 GB یا 48 GB کارڈ کو زیادہ expert slots ملتے ہیں، جس سے hit rate بڑھنا اور decode کارکردگی بہتر ہونا چاہیے۔ README میں بڑے کارڈ کے یہ نتائج فراہم نہیں کیے گئے۔

RTX 4090 شامل sm_86 build چلا سکتا ہے، اگرچہ اس کی پیمائش نہیں کی گئی۔ Blackwell کے لیے درج ذیل کے ساتھ دوبارہ build ضروری ہے:

TORCH_CUDA_ARCH_LIST="8.6;12.0"

کسی دوسرے architecture پر نیا Triton pin بھی ضروری ہو سکتا ہے۔ اگر ایسا pin بنائیں تو تصدیق کریں کہ reference panel بدستور top-1 1.0000 اور KL 0 دکھاتا ہے۔

Exact Triton selections کو محفوظ رکھیں

image، data/triton_pin_exact.json کے ذریعے KDA linear-attention prefill kernel selections کو pin کرتی ہے۔ Triton کو مختلف configurations منتخب کرنے دینے سے floating-point rounding تبدیل ہو سکتی ہے۔ جب reference-equivalent prefill behavior اہم ہو تو GLM53_TRITON_PIN کو اس کی ڈیفالٹ قدر پر رکھیں۔

Offloading pipeline کیسے کام کرتی ہے

  1. Routed experts کو pinned host memory میں لوڈ کریں۔ ہر layer کو exact-size pinned arena ملتا ہے، اور exllamav3 کے expert pointers CUDA UVA aliases کی طرف اشارہ کرتے ہیں۔
  2. VRAM میں elastic CLOCK cache بھریں۔ Router selections کو deduplicate کیا جاتا ہے، cache hits کو نشان زد کیا جاتا ہے، اور admitted misses کے لیے victims منتخب کیے جاتے ہیں۔
  3. Uncached experts کو PCIe کے ذریعے پڑھیں۔ exllamav3 کے kernels pinned host representation تک رسائی حاصل کر سکتے ہیں، بغیر synchronous host-side copy کے۔
  4. طویل prefills کو stage کریں۔ کافی بڑے per-layer pick counts کی صورت میں missing experts کو ایک layer پہلے staging buffer میں کاپی کیا جاتا ہے، جبکہ پچھلی layer compute کر رہی ہوتی ہے۔
  5. Fast mode میں منتخب decode misses کو تقسیم کریں۔ cost model زیادہ گرم misses کو zero-copy GPU execution کے ذریعے بھیجتا ہے اور منتخب سرد misses کو CPU tier پر بھیجتا ہے۔
  6. CPU اور GPU نتائج یکجا کریں۔ CPU اپنا کام pinned mapped memory کے ذریعے شائع کرتا ہے، اور GPU host synchronization کے بجائے device-side flag پر انتظار کرنے کے بعد حاصل شدہ FP32 partial کو شامل کرتا ہے۔

آپریشنل احتیاطیں

  • جب decode output کو stock exllamav3 سے مطابقت رکھنا ضروری ہو تو GLM53_MODE=exact استعمال کریں۔
  • اگر streaming latency اہم ہو تو پرانی sha256:1159044a... image سے گریز کریں۔ دستاویزی sha256:bb633b0b... digest استعمال کریں۔
  • Fast mode فی الحال host RAM میں experts کی دو نقول رکھتا ہے۔ container شروع کرنے سے پہلے کافی میموری یقینی بنائیں۔
  • سست PCIe links پر ناپی گئی RTX 3090 throughput فرض نہ کریں۔ Decode speed cache-miss traffic کے لیے حساس ہے۔
  • context size، cache reserve، concurrency یا staging settings تبدیل کرتے وقت /stats، system memory اور GPU memory کی نگرانی کریں۔
  • سرور صرف متن سنبھالتا ہے؛ اس deployment میں image input معاونت یافتہ نہیں ہے۔

نتیجہ

glm53-flash-offload pinned host storage، zero-copy PCIe reads، elastic VRAM cache، staged prefill transfers اور اختیاری AVX2 CPU tier کو یکجا کر کے غیر معمولی طور پر بڑے mixture-of-experts checkpoint کو ایک واحد 24 GB GPU پر قابلِ عمل بناتا ہے۔ pinned Docker image سے آغاز کریں، output fidelity کے لیے exact mode یا throughput کے لیے fast mode منتخب کریں، پھر cache یا CPU settings کو ٹیون کرنے سے پہلے شامل quality، speed اور streaming checks کے ذریعے installation کی توثیق کریں۔