نظرة عامة

nvidia/Qwen3.6-35B-A3B-NVFP4 هو نموذج Qwen/Qwen3.6-35B-A3B من Alibaba بعد تكميمه باستخدام NVIDIA Model Optimizer (ModelOpt). النموذج الأساسي بنية خليط الخبراء (MoE) بإجمالي 35B معامل و3B فقط نشطة، وطول سياق يصل إلى 262K، ورخصة Apache-2.0 تتيح الاستخدام التجاري وغير التجاري. وتوضّح NVIDIA صراحةً في بطاقة النموذج أن هذا ليس نموذجاً أساسياً من بناء NVIDIA بل نسخة مكمَّمة من نموذج طرف ثالث.

تتلخّص القيمة الجوهرية في فكرتين. بنية MoE تتكفّل بالسرعة، وتكميم NVFP4 يتكفّل بالذاكرة. بفضل بنية MoE، فإن توليد رمز واحد يشغّل فقط 3B من الخبراء النشطين بدلاً من كامل الـ35B، فيعمل نموذج 35B بحِمل حسابي قريب من نموذج كثيف بحجم 3B. أضف إلى ذلك تكميم NVFP4 الذي يخفض الأوزان من 16 بت إلى 4 بت، فتنخفض متطلبات القرص وذاكرة GPU بنحو 3.06 ضعف وفق بطاقة النموذج. هذا المزيج يشغّل “ذكاء بمستوى 35B بسرعة 3B وبذاكرة أقل بكثير.”

تدير ThakiCloud منصة SaaS متعددة المستأجرين للذكاء الاصطناعي والتعلم الآلي مبنية على Kubernetes، وتخدم النماذج عبر بيئات عملاء متنوعة. القدرة على أخذ نقطة تحقّق مكمَّمة مسبقاً وتحميلها مباشرة في vLLM تعني خفض تكلفة الخدمة دون إعادة تشغيل خط تكميم في كل مرة. وفي الواقع، تشغّل ThakiCloud بالفعل خط أنابيب داخلياً يكمّم العائلة نفسها Qwen3-MoE إلى NVFP4، ونشارك هذه التجربة لاحقاً في المقالة.

ما هذه التقنية

NVFP4 صيغة فاصلة عائمة بأربع بتات عرّفتها NVIDIA. وهي لا تسحق كل قيمة إلى 4 بتات ببساطة، بل تطبّق التكميم تحديداً على أوزان وتنشيطات المعاملات الخطية داخل كتل محوّل MoE. ونقتبس من بطاقة النموذج مباشرةً: “تم الحصول على هذا النموذج بتكميم أوزان Qwen3.6-35B-A3B إلى صيغة بيانات NVFP4. تُكمَّم فقط أوزان وتنشيطات المعاملات الخطية داخل كتل المحوّل في MoE. يخفض هذا التحسين عدد البتات لكل معامل من 16 إلى 4، ما يقلّل حجم القرص ومتطلبات ذاكرة GPU بنحو 3.06 ضعف.”

المفتاح هو إدراك أن MoE والتكميم يعملان على محورين مختلفين. ويوضّح المخطط أدناه كلا المحورين.

flowchart TB
    subgraph QUANT["محور التكميم (الذاكرة)"]
      A["Qwen3.6-35B-A3B<br/>أوزان BF16"] -->|"ModelOpt PTQ<br/>معايرة NVFP4"| B["نقطة تحقّق NVFP4<br/>16→4 بت، توفير ~3.06×"]
    end
    subgraph SERVE["محور الخدمة (السرعة)"]
      C["رمز الإدخال"] --> D["الموجّه"]
      D -->|"اختيار 3B من 35B"| E["الخبراء النشطون<br/>(حساب 3B)"]
      E --> F["رمز الإخراج"]
    end
    B -->|"vLLM --quantization modelopt"| G["Blackwell / Hopper<br/>Tensor Core"]
    G --> D

على محور التكميم، تُحوَّل أوزان BF16 إلى نقطة تحقّق NVFP4 عبر التكميم بعد التدريب (PTQ) في ModelOpt. وعلى محور الخدمة، يختار الموجّه لكل رمز إدخال مجموعة فرعية فقط من خبراء الـ35B ويجري نحو 3B من الحساب. يلتقي المحوران عند عملية Tensor Core فوق vLLM، وهنا بالضبط تظهر تبعية NVFP4 للعتاد. تُسرَّع عمليات NVFP4 فقط على معماريتي NVIDIA Hopper وBlackwell. وتُدرج بطاقة النموذج NVIDIA GB300 كعتاد اختبار.

سرّ تقليل فقدان الدقة هو التكميم “بانتقائية لا شمولية.” تُترك المسارات الحساسة بما فيها الانتباه دون مساس، ويتركّز الجهد على الأوزان الخطية لـMoE التي تستهلك أكبر قدر من الذاكرة، فيبقى توفير الذاكرة كبيراً ويبقى تدهور الجودة صغيراً.

التثبيت والتكامل

أمر الخدمة الأساسي في vLLM الذي توفّره NVIDIA في بطاقة النموذج أدناه. تشغّل صورة دوكر vllm/vllm-openai:nightly ثم تنفّذه.

vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --port 8000 \
  --quantization modelopt \
  --max-model-len 262144 \
  --reasoning-parser qwen3

الراية --quantization modelopt هي ما يجعل المحرّك يتعرّف على نقطة تحقّق NVFP4. إذا كانت ذاكرة GPU ضيقة، فإن خفض --max-model-len أولاً ثم رفعه تدريجياً نهج آمن، لأن الحفاظ على كامل سياق 262K يتطلّب ذاكرة كبيرة لمخبأ KV.

للبيئات محدودة الذاكرة مثل NVIDIA DGX Spark، توفّر بطاقة النموذج أمراً موصى به منفصلاً.

vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 1 \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --attention-backend flashinfer \
  --moe-backend marlin \
  --gpu-memory-utilization 0.4 \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --max-num-batched-tokens 8192 \
  --enable-chunked-prefill \
  --async-scheduling \
  --enable-prefix-caching \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3,"moe_backend":"triton"}' \
  --load-format fastsafetensors \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_xml \
  --enable-auto-tool-choice

يحتوي هذا الأمر على عدة خيارات مفيدة تشغيلياً. تُصغّر --kv-cache-dtype fp8 حتى مخبأ KV إلى 8 بت، وتُبقي --gpu-memory-utilization 0.4 بصمة الذاكرة منخفضة، وتفعّل --speculative-config الفك التخميني القائم على MTP (التنبؤ متعدد الرموز). وتجعل --tool-call-parser qwen3_xml و--enable-auto-tool-choice استدعاء الأدوات قابلاً للاستخدام فوراً في سيناريوهات الوكلاء وRAG. وحالة الاستخدام التي تذكرها NVIDIA هي بالضبط “المطوّرون الباحثون عن نماذج جاهزة مكمَّمة مسبقاً للنشر في أنظمة وكلاء الذكاء الاصطناعي وروبوتات المحادثة وأنظمة RAG”، وتعكس مجموعة الخيارات هذه ذلك الغرض مباشرةً.

نتائج تجريبية حقيقية

دعوني أوضّح أمراً بصدق منذ البداية. تُسرَّع عمليات NVFP4 فقط على Tensor Core من Blackwell/Hopper، لذا لم تتمكّن بيئة Apple Silicon المستخدمة في كتابة هذه المقالة من إعادة إنتاج الاستدلال مباشرةً. لذلك فإن الأرقام أدناه هي نتائج التقييم الرسمية من NVIDIA المنشورة في بطاقة النموذج، ولم تُختلق أي أرقام قياس ذاتية.

قارنت NVIDIA النسخة المكمَّمة NVFP4 بالنموذج الأساسي Qwen3.6-35B-A3B (BF16) على معايير الاستدلال النصي والبرمجة.

تمثيل بصري للأرقام المنشورة في بطاقة النموذج (تسميات المحاور بالكورية). حتى بعد التكميم بأربع بتات، تبقى معظم فروق الدقة دون نقطة واحدة.

مفتاح قراءة الجدول هو حجم الخسارة. أكبر انخفاض عبر المعايير الثمانية هو -0.8 على τ²-Bench Telecom، أما GPQA Diamond فهو -0.1، وAA-LCR متعادل. بل إن IFBench وMMMU PRO يتقدّم فيهما NVFP4 قليلاً على BF16. حدث التحوّل الطفيف في التوزيع الناتج عن التكميم بشكل مواتٍ في بعض المهام مصادفةً، لكن لا ينبغي تعميم ذلك إلى “التكميم يحسّن الأداء.” إجمالاً، رسالة الجدول أن خفض 16 بت إلى الربع عند 4 بتات حافظ على قدرات الاستدلال والرياضيات والبرمجة واستخدام أدوات الوكلاء بشكل شبه كامل. وكانت شروط التقييم لـSciCode عند temperature=0.6 وtop_p=0.95 وبحد أقصى 131072 رمزاً، والبقية عند temperature=1.0 وtop_p=0.95 وبحد أقصى 131072 رمزاً.

أما من ناحية الذاكرة، فتذكر بطاقة النموذج توفيراً بنحو 3.06 ضعف. ووفق مستودع Hugging Face، يُبلَّغ عن حجم المعاملات المحزومة لنقطة تحقّق NVFP4 بنحو 18.7B، وهو شكل مخفّض كثيراً للنموذج 35B مقارنةً بـ BF16 الأصلي. ويجب التحقق من حجم الملف الدقيق مباشرةً في الشريط الجانبي للمستودع، وتحذّر بطاقة النموذج من الخلط بين إحصاءات ملفات الشريط الجانبي ومعاملات بنية النموذج الأساسي.

التطبيق والدلالات لمنصة ThakiCloud للذكاء الاصطناعي والتعلم الآلي على Kubernetes

من منظور منصة ThakiCloud، جاذبية هذا النموذج واضحة. في بيئة متعددة المستأجرين، تكون GPU أغلى مورد مشترك، وكلما تمكّنّا من تحميل مزيد من نماذج المستأجرين على نفس GPU في آنٍ واحد، انخفضت تكلفة الاستدلال للوحدة. خفض NVFP4 للذاكرة بنحو 3.06 ضعف يعني، بصيغة مبسّطة، مساحة لاستيعاب نموذج أكبر أو جلسات متزامنة أكثر في نفس ذاكرة GPU. أضف خاصية MoE المتمثّلة في تشغيل MoE بحجم 35B بحساب نحو 3B، فتصبح قيمة “نماذج عالية الجودة بتكلفة خدمة منخفضة” المحلية أكثر تجسيداً بكثير.

تعكس ThakiCloud هذا بالفعل في التشغيل. نحافظ على خط أنابيب داخلي يكمّم Qwen/Qwen3-30B-A3B، من عائلة Qwen3-MoE نفسها، إلى NVFP4 (W4A4، group_size=16) على RunPod B200 (Blackwell SM100). وفي تشغيل تحقّق في 1 مايو 2026، أنتج نقطة تحقّق بحجم 17.1GB بـ137 ثانية من حساب PTQ. بلغ إجمالي الوقت الفعلي نحو 25 دقيقة، والتكلفة نحو 3.48 دولار على B200 عند الطلب. يترتّب على هذه التجربة أمران. أولاً، تكميم NVFP4 نفسه مهمة لمرة واحدة تنتهي في وقت قصير بتكلفة منخفضة. ثانياً، عند نشر نقطة تحقّق مكمَّمة مسبقاً كما فعلت NVIDIA هنا، يمكنك تخطّي حتى تلك المهمة لمرة واحدة والانتقال مباشرةً إلى الخدمة. بعبارة أخرى، نقطة تحقّق NVIDIA العامة مدخل أشمل لخط أنابيبنا.

أما من ناحية تشغيل K8s، فيتوافق كما يلي. تُصفّ أحمال GPU وتُجدول عبر Kueue، وتُشغّل الخدمة كحُجيرات vLLM مع الراية --quantization modelopt للتعرّف على نقطة تحقّق NVFP4، ويُعالَج عزل المستأجرين بمساحات الأسماء وتقسيم GPU، مع تعديل التخصيص لكل مستأجر بقدر الذاكرة الموفَّرة. لكن يرافق ذلك شرط عتاد واحد. تسريع NVFP4 يعمل فقط على Blackwell وHopper، لذا لا يمكن لمجمّعات العقد القائمة على A100 التمتّع بفائدة الأربع بتات لهذا النموذج كما هي. وهذا قرار تشغيلي مرتبط مباشرةً بتكوين مجمّع العقد، ونشير إليه كقيد في القسم التالي.

القيود والحجج المضادة

أولاً، تبعية العتاد قوية. توجد نوى Tensor Core الخاصة بـNVFP4 فقط على Blackwell وHopper. على وحدات GPU من الأجيال السابقة مثل A100 أو V100، لا يُسرَّع NVFP4، فلا يمكن توقّع نفس توفير الذاكرة ويجب سلوك مسار آخر مثل INT8 أو FP8. وإذا كانت أصول GPU الحالية لعميل محلي من جيل سابق، فإن جني فائدة هذا النموذج يستلزم تكلفة إضافية لاستبدال العقد.

ثانياً، توفير الذاكرة ومكاسب الإنتاجية أمران مختلفان. تذكر بطاقة النموذج توفيراً للقرص والذاكرة بنحو 3.06 ضعف، لكنها لا تقدّم مباشرةً أرقام إنتاجية مثل الرموز/الثانية أو زمن الاستجابة. ومع أن الأوزان بأربع بتات تساعد عادةً في فك التشفير بتخفيف ضغط عرض النطاق للذاكرة، فإن الإنتاجية الفعلية تعتمد على حجم الدفعة وطول السياق وإعدادات مخبأ KV. والجزم بأنه “أسرع بـN ضعفاً” دون معيار خدمة خاص بـThakiCloud سيكون غير دقيق. وإلى أن نقيسه مباشرةً في بيئتنا، يكون الاعتماد على جدول الدقة وحده أكثر أماناً.

ثالثاً، يرث التكميم قيود النموذج الأساسي كما هي. كما تذكر بطاقة النموذج مباشرةً، دُرّب النموذج الأساسي على بيانات مسحوبة من الإنترنت تحتوي على لغة سامّة وتحيّزات مجتمعية، وقد يولّد إجابات غير دقيقة أو يحذف معلومات أساسية أو ينتج نصاً غير ذي صلة. التكميم يحسّن الذاكرة والسرعة فقط، ولا يحلّ مشكلات الأمان والدقة هذه. ولا تزال الخدمة متعددة المستأجرين تتطلّب ترشيحاً ومراقبةً منفصلين للمخرجات.

رابعاً، فقدان الدقة لا يتقارب إلى الصفر. رغم أن معظم المعايير تُظهر خسارة دون نقطة واحدة، فإن السيناريوهات التي يكون فيها استخدام أدوات الوكلاء والالتزام بالسياسات محورياً، مثل -0.8 في τ²-Bench Telecom، تُظهر خسارة أكبر نسبياً. وفي مجالات مثل المالية والرعاية الصحية حيث تنعكس فروق الدقة الصغيرة مباشرةً على التكلفة، تحتاج إلى سياسة توازن بين اقتصاديات توفير الأربع بتات وفقدان الدقة لكل مستأجر، وتختار بين BF16 وFP8 وNVFP4.

إجمالاً، nvidia/Qwen3.6-35B-A3B-NVFP4 خيار عملي للغاية للفرق التي تمتلك بنية تحتية قائمة على Blackwell/Hopper لـ”خفض الذاكرة إلى الربع تقريباً دون خسارة تُذكر.” لكن هذه الفائدة لا تصمد إلا فوق شرط العتاد والتحقق من الدقة الخاص بكل مجال، وتعتزم ThakiCloud تأكيد الإنتاجية وملاءمة كل مستأجر بمعيار خدمة خاص بها قبل عكسه في سياسة مجمّع العقد.

المصادر

• بطاقة النموذج: nvidia/Qwen3.6-35B-A3B-NVFP4 · Hugging Face
• النموذج الأساسي: Qwen/Qwen3.6-35B-A3B · Hugging Face
• أداة التكميم: NVIDIA Model Optimizer (GitHub)
• محرّك الاستدلال: vLLM (GitHub)

Overview

nvidia/Qwen3.6-35B-A3B-NVFP4 is Alibaba’s Qwen/Qwen3.6-35B-A3B quantized with NVIDIA Model Optimizer (ModelOpt). The base model is a Mixture-of-Experts (MoE) architecture with 35B total parameters and only 3B activated, a context length up to 262K, and an Apache-2.0 license that permits both commercial and non-commercial use. NVIDIA explicitly notes on the model card that this is not an NVIDIA-built base model but a quantized version of a third-party model.

The core value reduces to two words. MoE handles speed, NVFP4 handles memory. Thanks to the MoE structure, generating a single token engages only the 3B of active experts rather than all 35B, so a 35B model runs with a compute load close to a 3B dense model. Add NVFP4 quantization on top, dropping weights from 16-bit to 4-bit, and disk and GPU memory requirements fall by about 3.06x per the model card. The combination runs “35B-level intelligence at 3B speed, with far less memory.”

ThakiCloud operates a K8s-based multi-tenant AI/ML SaaS platform and serves models across diverse customer environments. Being able to take a pre-quantized checkpoint and load it straight into vLLM means lowering serving cost without rerunning a quantization pipeline each time. In fact, ThakiCloud already runs an in-house pipeline that quantizes the same Qwen3-MoE family to NVFP4, and we share that experience later in this article.

What Is This Technology

NVFP4 is a 4-bit floating-point format defined by NVIDIA. It does not simply crush every value down to 4 bits; it applies quantization specifically to the weights and activations of the linear operators inside MoE transformer blocks. To quote the model card directly: “This model was obtained by quantizing the weights of Qwen3.6-35B-A3B to NVFP4 data type. Only the weights and activations of the linear operators within transformer blocks in MoE are quantized. This optimization reduces the number of bits per parameter from 16 to 4, reducing the disk size and GPU memory requirements by approximately 3.06x.”

The key is to recognize that MoE and quantization operate on different axes. The diagram below shows both.

flowchart TB
    subgraph QUANT["Quantization axis (memory)"]
      A["Qwen3.6-35B-A3B<br/>BF16 weights"] -->|"ModelOpt PTQ<br/>NVFP4 calibration"| B["NVFP4 checkpoint<br/>16→4 bit, ~3.06x savings"]
    end
    subgraph SERVE["Serving axis (speed)"]
      C["Input token"] --> D["Router"]
      D -->|"3B of 35B selected"| E["Active experts<br/>(3B compute)"]
      E --> F["Output token"]
    end
    B -->|"vLLM --quantization modelopt"| G["Blackwell / Hopper<br/>Tensor Core"]
    G --> D

On the quantization axis, BF16 weights are converted into an NVFP4 checkpoint via ModelOpt’s post-training quantization (PTQ). On the serving axis, for each input token the router selects only a subset of the 35B experts and performs roughly 3B of compute. The two axes meet at the Tensor Core operation on top of vLLM, and that is exactly where NVFP4’s hardware dependency surfaces. NVFP4 operations are accelerated only on NVIDIA Hopper and Blackwell microarchitectures. The model card lists NVIDIA GB300 as the test hardware.

The trick to minimizing accuracy loss is quantizing “selectively, not everything.” Sensitive paths including attention are left untouched, and the effort concentrates on the MoE linear weights that consume the most memory, so memory savings stay large while quality degradation stays small.

Installation and Integration

The basic vLLM serving command NVIDIA provides on the model card is below. You launch the vllm/vllm-openai:nightly docker image and run it.

vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --port 8000 \
  --quantization modelopt \
  --max-model-len 262144 \
  --reasoning-parser qwen3

The --quantization modelopt flag is what makes the runtime recognize the NVFP4 checkpoint. If GPU memory is tight, reducing --max-model-len first and then raising it gradually is the safe approach, because keeping the full 262K context requires considerable KV cache memory.

For memory-constrained environments such as the NVIDIA DGX Spark, the model card provides a separate recommended command.

vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 1 \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --attention-backend flashinfer \
  --moe-backend marlin \
  --gpu-memory-utilization 0.4 \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --max-num-batched-tokens 8192 \
  --enable-chunked-prefill \
  --async-scheduling \
  --enable-prefix-caching \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3,"moe_backend":"triton"}' \
  --load-format fastsafetensors \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_xml \
  --enable-auto-tool-choice

This command packs in several operationally useful options. --kv-cache-dtype fp8 shrinks even the KV cache to 8-bit, --gpu-memory-utilization 0.4 keeps memory footprint low, and --speculative-config enables MTP (Multi-Token Prediction) based speculative decoding. --tool-call-parser qwen3_xml and --enable-auto-tool-choice make tool calling immediately usable in agent and RAG scenarios. NVIDIA’s stated use case is precisely “developers looking to take off-the-shelf, pre-quantized models for deployment in AI agent systems, chatbots, and RAG systems,” and this option set directly reflects that purpose.

Real Experimental Results

Let me state one thing honestly up front. NVFP4 operations are accelerated only on Blackwell/Hopper Tensor Cores, so the Apple Silicon environment used to write this article could not reproduce inference directly. The numbers below are therefore NVIDIA’s official evaluation results published on the model card; no self-measured figures were invented.

NVIDIA compared the NVFP4 quantized version against the base model Qwen3.6-35B-A3B (BF16) on text reasoning and coding benchmarks.

A visualization of the model card’s published numbers (axis labels in Korean). Even after 4-bit quantization, most accuracy differences stay below one point.

The key to reading the table is the magnitude of the loss. The largest drop across the 8 benchmarks is -0.8 on τ²-Bench Telecom; GPQA Diamond is -0.1, and AA-LCR is a tie. IFBench and MMMU PRO actually have NVFP4 slightly ahead of BF16. The tiny distribution shift from quantization happened to help on a few tasks, but this should not be generalized into “quantization improves performance.” Overall, the message of the table is that cutting 16-bit down to a quarter at 4-bit preserved reasoning, math, coding, and agentic tool-use capability almost entirely. The evaluation conditions were SciCode at temperature=0.6, top_p=0.95, max 131072 tokens, and the rest at temperature=1.0, top_p=0.95, max 131072 tokens.

On the memory side, the model card states roughly 3.06x savings. Per the Hugging Face repository, the packed parameter scale of the NVFP4 checkpoint is reported at about 18.7B, a substantially reduced form of the 35B model versus the original BF16. The exact file size must be checked directly in the repository sidebar, and the model card warns not to confuse the sidebar’s file statistics with the base model’s architecture parameters.

Application and Implications for the ThakiCloud K8s AI/ML SaaS Platform

From ThakiCloud’s platform perspective, the appeal of this model is clear. In a multi-tenant environment, the GPU is the most expensive shared resource, and the more tenant models we can load onto the same GPU simultaneously, the lower the per-inference cost. NVFP4 reducing memory by about 3.06x means, in simplified terms, room to fit a larger model or more concurrent sessions in the same GPU memory. Layer in the MoE characteristic of running a 35B MoE at roughly 3B compute, and the on-premises value proposition of “high-quality models at low serving cost” becomes much more concrete.

ThakiCloud already reflects this in operations. We maintain an in-house pipeline that quantizes Qwen/Qwen3-30B-A3B, of the same Qwen3-MoE family, to NVFP4 (W4A4, group_size=16) on RunPod B200 (Blackwell SM100). In a validation run on May 1, 2026, it produced a 17.1GB checkpoint with 137 seconds of PTQ compute. Total wall-clock was about 25 minutes, and cost was around $3.48 on B200 on-demand. Two things follow from this experience. First, NVFP4 quantization itself is a one-time job that finishes in a short time at low cost. Second, when a pre-quantized checkpoint is published as NVIDIA did here, you can skip even that one-time job and go straight to serving. In other words, NVIDIA’s public checkpoint is a superset input to our pipeline.

On the K8s operations side, it aligns as follows. GPU workloads are queued and scheduled with Kueue, serving is brought up as vLLM pods with the --quantization modelopt flag recognizing the NVFP4 checkpoint, and multi-tenant isolation is handled with namespaces and GPU partitioning, adjusting per-tenant allocation by the memory saved. One hardware premise comes attached, though. NVFP4 acceleration works only on Blackwell and Hopper, so existing A100-based node pools cannot enjoy this model’s 4-bit benefit as-is. This is an operational decision tied directly to node-pool composition, which we flag as a limitation in the next section.

Limitations and Counterarguments

First, the hardware dependency is strong. NVFP4 Tensor Cores exist only on Blackwell and Hopper. On prior-generation GPUs like the A100 or V100, NVFP4 is not accelerated, so you cannot expect the same memory savings and must take a different path such as INT8 or FP8. If an on-premises customer’s existing GPU assets are prior-generation, reaping this model’s benefit incurs the added cost of node replacement.

Second, memory savings and throughput gains are different matters. The model card states roughly 3.06x disk and memory savings, but it does not directly present throughput figures such as tokens/sec or latency. While 4-bit weights generally help decoding by easing memory-bandwidth pressure, actual throughput depends on batch size, context length, and KV cache settings. Asserting “it’s N times faster” without ThakiCloud’s own serving benchmark would be inaccurate. Until we measure it directly in our environment, it is safer to rely only on the accuracy table.

Third, quantization inherits the base model’s limitations as-is. As the model card states directly, the base model was trained on data crawled from the internet that contains toxic language and societal biases, and it may generate inaccurate answers, omit key information, or produce irrelevant text. Quantization only optimizes memory and speed; it does not solve these safety and accuracy issues. Multi-tenant serving still requires separate output filtering and monitoring.

Fourth, accuracy loss does not converge to zero. Although most benchmarks show loss under one point, scenarios where agentic tool use and policy adherence are central, like τ²-Bench Telecom’s -0.8, show a relatively larger loss. In domains like finance and healthcare where small accuracy differences translate directly into cost, you need a policy that weighs the economics of 4-bit savings against accuracy loss per tenant and chooses among BF16, FP8, and NVFP4.

In sum, nvidia/Qwen3.6-35B-A3B-NVFP4 is a highly practical option for teams with Blackwell/Hopper-based infrastructure to “cut memory to a quarter with almost no loss.” That benefit holds only on top of the hardware premise and domain-specific accuracy validation, and ThakiCloud plans to confirm throughput and per-tenant suitability with its own serving benchmark before reflecting it in node-pool policy.

Sources

• Model card: nvidia/Qwen3.6-35B-A3B-NVFP4 · Hugging Face
• Base model: Qwen/Qwen3.6-35B-A3B · Hugging Face
• Quantization tool: NVIDIA Model Optimizer (GitHub)
• Inference engine: vLLM (GitHub)

개요

nvidia/Qwen3.6-35B-A3B-NVFP4는 Alibaba의 Qwen/Qwen3.6-35B-A3B를 NVIDIA Model Optimizer(ModelOpt)로 양자화한 버전입니다. 베이스 모델은 35B 총 파라미터에 3B만 활성화되는 Mixture-of-Experts(MoE) 구조이며, 컨텍스트 길이는 최대 262K, 라이선스는 Apache-2.0으로 상업·비상업 모두 사용 가능합니다. NVIDIA는 이 모델이 자사가 처음부터 만든 베이스 모델이 아니라 제3자 모델의 양자화 버전임을 모델카드에 명시하고 있습니다.

핵심 가치는 두 단어로 요약됩니다. MoE는 속도를, NVFP4는 메모리를 담당합니다. MoE 구조 덕분에 토큰 하나를 생성할 때 35B 전체가 아니라 3B의 활성 전문가만 계산에 참여하므로, 35B 모델이면서도 연산량은 3B 밀집 모델에 가깝습니다. 여기에 NVFP4 양자화가 더해져 가중치를 16비트에서 4비트로 줄이면, 모델카드 기준 디스크와 GPU 메모리 요구가 약 3.06배 감소합니다. 즉 “35B의 지능을 3B의 속도와, 그보다 한참 작은 메모리로” 돌리는 조합입니다.

ThakiCloud는 K8s 기반의 멀티테넌트 AI/ML SaaS 플랫폼을 운영하면서 다양한 고객 환경에 모델을 서빙합니다. 사전 양자화된 체크포인트를 그대로 받아 vLLM에 올릴 수 있다는 점은, 양자화 파이프라인을 매번 다시 돌릴 필요 없이 서빙 단가를 낮출 수 있다는 의미입니다. 실제로 ThakiCloud는 이미 같은 계열인 Qwen3-MoE를 NVFP4로 양자화하는 사내 파이프라인을 운영하고 있으며, 이 경험을 글 후반에서 공유합니다.

이 기술은 무엇인가

NVFP4는 NVIDIA가 정의한 4비트 부동소수점 포맷입니다. 단순히 모든 값을 4비트로 깎아내리는 방식이 아니라, MoE 트랜스포머 블록 안 선형 연산자(linear operator)의 가중치와 활성값에 한정해 양자화를 적용합니다. 모델카드의 설명을 그대로 옮기면, “Qwen3.6-35B-A3B의 가중치를 NVFP4 데이터 타입으로 양자화했으며, MoE 트랜스포머 블록 내부 선형 연산자의 가중치와 활성값만 양자화한다. 이 최적화는 파라미터당 비트 수를 16에서 4로 줄여, 디스크 크기와 GPU 메모리 요구를 약 3.06배 감소시킨다”입니다.

여기서 MoE와 양자화가 서로 다른 축에서 동작한다는 점을 이해하는 것이 중요합니다. 아래 흐름도가 두 축을 보여줍니다.

flowchart TB
    subgraph QUANT["양자화 축 (메모리)"]
      A["Qwen3.6-35B-A3B<br/>BF16 가중치"] -->|"ModelOpt PTQ<br/>NVFP4 보정"| B["NVFP4 체크포인트<br/>16→4 bit, 약 3.06x 절감"]
    end
    subgraph SERVE["서빙 축 (속도)"]
      C["입력 토큰"] --> D["라우터"]
      D -->|"35B 중 3B만 선택"| E["활성 전문가<br/>(3B 연산)"]
      E --> F["출력 토큰"]
    end
    B -->|"vLLM --quantization modelopt"| G["Blackwell / Hopper<br/>Tensor Core"]
    G --> D

양자화 축에서는 BF16 가중치를 ModelOpt의 사후 양자화(PTQ, Post-Training Quantization)로 NVFP4 체크포인트로 변환합니다. 서빙 축에서는 입력 토큰마다 라우터가 35B 전체 전문가 중 일부만 골라 3B 규모의 연산만 수행합니다. 두 축이 만나는 지점이 vLLM 위 Tensor Core 연산이며, 바로 여기서 NVFP4의 하드웨어 의존성이 드러납니다. NVFP4 연산은 NVIDIA Hopper와 Blackwell 마이크로아키텍처에서만 가속됩니다. 모델카드의 테스트 하드웨어는 NVIDIA GB300으로 기재되어 있습니다.

정확도 손실을 최소화하는 비결은 “전부가 아니라 선택적으로” 양자화하는 데 있습니다. 어텐션을 포함한 민감한 경로는 손대지 않고, 메모리를 가장 많이 차지하는 MoE 선형 가중치에 집중함으로써, 메모리 절감 효과는 크게 가져가면서 품질 저하는 작게 막는 것입니다.

설치 및 통합

NVIDIA가 모델카드에서 제공하는 기본 vLLM 서빙 명령은 다음과 같습니다. vllm/vllm-openai:nightly 도커 이미지를 띄운 뒤 실행합니다.

vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --port 8000 \
  --quantization modelopt \
  --max-model-len 262144 \
  --reasoning-parser qwen3

--quantization modelopt 플래그가 NVFP4 체크포인트를 인식하게 하는 핵심입니다. GPU 메모리가 빠듯하면 --max-model-len을 먼저 줄였다가 점진적으로 올리는 방식이 안전합니다. 262K 컨텍스트를 그대로 유지하려면 KV 캐시 메모리가 상당히 필요하기 때문입니다.

NVIDIA DGX Spark처럼 메모리가 제한된 환경을 위해서는 모델카드가 별도의 권장 명령을 제공합니다.

vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 1 \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --attention-backend flashinfer \
  --moe-backend marlin \
  --gpu-memory-utilization 0.4 \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --max-num-batched-tokens 8192 \
  --enable-chunked-prefill \
  --async-scheduling \
  --enable-prefix-caching \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3,"moe_backend":"triton"}' \
  --load-format fastsafetensors \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_xml \
  --enable-auto-tool-choice

이 명령에는 운영에 유용한 옵션이 여럿 들어 있습니다. --kv-cache-dtype fp8로 KV 캐시까지 8비트로 줄이고, --gpu-memory-utilization 0.4로 메모리 점유를 낮추며, --speculative-config로 MTP(Multi-Token Prediction) 기반 추측 디코딩까지 켭니다. --tool-call-parser qwen3_xml과 --enable-auto-tool-choice는 에이전트·RAG 시나리오에서 도구 호출을 바로 쓸 수 있게 합니다. NVIDIA가 명시한 사용 사례 자체가 “AI 에이전트 시스템, 챗봇, RAG 시스템에 바로 배포할 사전 양자화 모델을 찾는 개발자”이므로, 이 옵션 구성은 그 용도를 그대로 반영합니다.

실제 실험 결과

가장 먼저 정직하게 밝힐 점이 있습니다. NVFP4 연산은 Blackwell/Hopper Tensor Core에서만 가속되므로, 이 글을 작성한 Apple Silicon 환경에서는 추론을 직접 재현할 수 없었습니다. 따라서 아래 수치는 NVIDIA가 모델카드에 공개한 공식 평가 결과이며, 자체 측정치를 지어내지 않았습니다.

NVIDIA는 베이스 모델 Qwen3.6-35B-A3B(BF16)를 기준으로 NVFP4 양자화 버전을 텍스트 추론·코딩 벤치마크에서 비교했습니다.

모델카드 공개 수치를 시각화한 그래프입니다. 4비트 양자화 후에도 정확도 차이가 대부분 1점 미만에 머뭅니다.

표를 읽는 핵심은 손실의 크기입니다. 8개 벤치마크 중 손실이 가장 큰 항목이 τ²-Bench Telecom의 -0.8점이며, GPQA Diamond는 -0.1점, AA-LCR은 동률입니다. IFBench와 MMMU PRO는 오히려 NVFP4가 BF16을 소폭 앞섭니다. 양자화로 인한 미세한 분포 변화가 일부 태스크에서는 우연히 유리하게 작용한 결과로 보이며, 이를 “양자화가 성능을 올린다”로 일반화해서는 안 됩니다. 종합하면, 16비트를 4비트로 4분의 1로 줄였는데도 추론·수학·코딩·에이전트 도구사용 능력이 사실상 보존되었다는 것이 이 표의 메시지입니다. 평가 조건은 SciCode가 temperature=0.6, top_p=0.95, 최대 131072 토큰이고, 나머지는 temperature=1.0, top_p=0.95, 최대 131072 토큰입니다.

메모리 측면에서는 모델카드가 약 3.06배 절감을 명시합니다. Hugging Face 저장소 기준 NVFP4 체크포인트의 패킹된 파라미터 규모는 약 18.7B로 집계되며, 35B 모델을 기존 BF16 대비 크게 줄인 형태입니다. 다만 정확한 파일 크기는 저장소 사이드바를 직접 확인해야 하며, 사이드바의 파일 통계를 베이스 모델의 아키텍처 파라미터와 혼동하지 않아야 한다고 모델카드가 경고합니다.

ThakiCloud K8s AI/ML SaaS 플랫폼 적용 및 시사점

ThakiCloud의 플랫폼 관점에서 이 모델이 매력적인 이유는 분명합니다. 멀티테넌트 환경에서 GPU는 가장 비싼 공유 자원이고, 같은 GPU에 더 많은 테넌트의 모델을 동시에 올릴수록 단위 추론 단가가 내려갑니다. NVFP4가 메모리를 약 3.06배 줄인다는 것은, 단순화하면 동일 GPU 메모리에 더 큰 모델 또는 더 많은 동시 세션을 수용할 여지가 생긴다는 뜻입니다. 35B MoE를 3B 수준의 연산량으로 돌리는 MoE 특성까지 겹치면, “고품질 모델을 낮은 서빙 비용으로” 제공한다는 온프레미스 가치 제안이 한층 구체화됩니다.

ThakiCloud는 이 흐름을 이미 운영에 반영하고 있습니다. 같은 Qwen3-MoE 계열인 Qwen/Qwen3-30B-A3B를 RunPod B200(Blackwell SM100)에서 NVFP4(W4A4, group_size=16)로 양자화하는 사내 파이프라인을 보유하고 있으며, 2026년 5월 1일 검증 실행에서 17.1GB 체크포인트를 137초의 PTQ 연산으로 생성했습니다. 전체 소요는 약 25분, 비용은 B200 온디맨드 기준 약 3.48달러였습니다. 이 경험이 시사하는 바는 두 가지입니다. 첫째, NVFP4 양자화 자체는 짧은 시간·낮은 비용으로 끝나는 일회성 작업입니다. 둘째, NVIDIA처럼 사전 양자화 체크포인트가 공개되면 이 일회성 작업조차 건너뛰고 곧바로 서빙으로 진입할 수 있습니다. 즉 NVIDIA의 공개 체크포인트는 우리 파이프라인의 상위 호환 입력입니다.

K8s 운영 측면에서는 다음과 같이 정렬됩니다. GPU 워크로드는 Kueue로 큐잉·스케줄링하고, 서빙은 vLLM 파드로 띄우되 --quantization modelopt 플래그로 NVFP4 체크포인트를 인식시킵니다. 멀티테넌트 격리는 네임스페이스와 GPU 파티셔닝으로 처리하며, 절감된 메모리만큼 테넌트당 할당을 조정합니다. 다만 한 가지 하드웨어 전제가 따라옵니다. NVFP4 가속은 Blackwell·Hopper에서만 동작하므로, 기존 A100 기반 노드 풀에서는 이 모델의 4비트 이점을 그대로 누릴 수 없습니다. 이 부분은 노드 풀 구성과 직결되는 운영 의사결정이며, 다음 항목에서 한계로 짚습니다.

한계 및 반론

첫째, 하드웨어 종속이 강합니다. NVFP4 Tensor Core는 Blackwell·Hopper에만 존재합니다. A100·V100 같은 이전 세대 GPU에서는 NVFP4가 가속되지 않으므로, 같은 메모리 절감 효과를 기대할 수 없고 INT8·FP8 같은 다른 경로를 택해야 합니다. 온프레미스 고객의 기존 GPU 자산이 이전 세대라면, 이 모델의 이점을 누리기 위해 노드 교체라는 추가 비용이 발생합니다.

둘째, 메모리 절감과 처리량 향상은 다른 문제입니다. 모델카드는 디스크·메모리 약 3.06배 절감을 명시하지만, 토큰/초나 지연시간 같은 처리량 수치는 직접 제시하지 않습니다. 4비트 가중치가 메모리 대역폭 부담을 줄여 일반적으로 디코딩에 유리하게 작용하긴 하지만, 실제 처리량은 배치 크기·컨텍스트 길이·KV 캐시 설정에 따라 달라집니다. ThakiCloud 자체 서빙 벤치마크 없이 “몇 배 빠르다”고 단정하는 것은 부정확합니다. 우리 환경에서 직접 측정하기 전까지는 정확도 표만을 근거로 삼는 것이 안전합니다.

셋째, 양자화는 베이스 모델의 한계를 그대로 물려받습니다. 모델카드가 직접 밝히듯, 베이스 모델은 인터넷에서 수집한 데이터로 학습되어 독성 표현·사회적 편향을 포함할 수 있고, 부정확하거나 핵심 정보를 누락한 답변을 생성할 수 있습니다. 양자화는 메모리와 속도를 최적화할 뿐 이런 안전성·정확성 문제를 해결하지 않습니다. 멀티테넌트 서빙에서는 출력 필터링과 모니터링이 여전히 별도로 필요합니다.

넷째, 정확도 손실이 0에 수렴하는 것은 아닙니다. 대부분의 벤치마크에서 손실이 1점 미만이지만, τ²-Bench Telecom의 -0.8점처럼 에이전트 도구사용·정책 준수가 핵심인 시나리오에서는 상대적으로 큰 손실이 관찰됩니다. 금융·의료처럼 작은 정확도 차이가 비용으로 직결되는 도메인에서는, 4비트 절감의 경제성과 정확도 손실을 테넌트별로 따져 BF16·FP8·NVFP4 중에서 선택하는 정책이 필요합니다.

종합하면, nvidia/Qwen3.6-35B-A3B-NVFP4는 Blackwell·Hopper 기반 인프라를 가진 팀에게는 “거의 손실 없이 메모리를 4분의 1로 줄이는” 매우 실용적인 선택지입니다. 다만 그 이점은 하드웨어 전제와 도메인별 정확도 검증 위에서만 성립하며, ThakiCloud는 자체 서빙 벤치마크로 처리량과 테넌트별 적합성을 확인한 뒤 노드 풀 정책에 반영할 계획입니다.

출처 (Sources)

• 모델카드: nvidia/Qwen3.6-35B-A3B-NVFP4 · Hugging Face
• 베이스 모델: Qwen/Qwen3.6-35B-A3B · Hugging Face
• 양자화 도구: NVIDIA Model Optimizer (GitHub)
• 추론 엔진: vLLM (GitHub)

نظرة عامة

اختبار تطبيق موبايل يستلزم أجهزة أندرويد. إدارة أسطول من الأجهزة الحقيقية عبء صيانة مُضنٍ، وتثبيت محاكٍ ثقيل على كل جهاز مطوّر يُفضي إلى اختلاف البيئات وضعف قابلية التكرار. تتضاعف هذه المشكلة حين تُريد إدراج اختبارات أندرويد في خط CI، إذ يحتاج كل عقدة بناء إلى إعداد محاكٍ متسق.

يحل docker-android (إصدار HQarroum) هذه المشكلة بالحاويات. يُغلّف محاكي أندرويد بتهيئة بسيطة، ويُشغّله بلا واجهة رسومية، ويُتيح ADB والتحكم بالشاشة عبر الشبكة. حاوية واحدة توفر بيئة أندرويد نظيفة ومتسقة في ثوانٍ، مما يجعلها مناسبة تماماً لـ CI/CD والاختبارات الآلية.

يتحقق هذا المقال من بنية docker-android ومتطلباته الفعلية وفق التوثيق، ثم يستعرض كيف تتعامل منصة Kubernetes مثل ThakiCloud مع هذا النوع من أحمال عمل الأجهزة. محاكاة أندرويد ليست في صميم منصتنا للذكاء الاصطناعي، لكن السؤال حول عزل الحاويات ذات الامتيازات التي تحتاج KVM passthrough وتسريع GPU يتقاطع مباشرة مع قدرات بنيتنا التحتية.

ما هو docker-android

يجمع docker-android الخاص بـ HQarroum بين محاكي أندرويد ودعم KVM و JRE 11 في صورة مدمجة مبنية على Alpine (الإصدار الحالي 1.1.0). النية التصميمية واضحة: كشف محاكي أندرويد كامل يمكن التحكم به عن بُعد بأقل بصمة برمجية ممكنة. تحتوي الصورة على المحاكي نفسه، وخادم ADB للوصول الخارجي، وQEMU مع libvirt.

الخصائص الرئيسية:

• بصمة بسيطة: مبنية على Alpine لتحسين الحجم. البناء بدون SDK أو محاكٍ ينتج صورة أصغر بكثير.
• قابلية التخصيص: إصدار أندرويد ونوع الجهاز ونوع الصورة كلها قابلة للاختيار.
• توجيه المنافذ مدمج: يُكشف المحاكي و ADB عبر واجهة شبكة الحاوية.
• بلا واجهة رسومية: لا تحتاج إلى GUI، مما يجعلها مناسبة لمزارع CI. يمكن الوصول إلى الشاشة عن بُعد عبر scrcpy.
• قابلية التكرار: تُعاد صورة المحاكي إلى حالتها الأصلية عند كل إعادة تشغيل، فكل تشغيل يبدأ من حالة متطابقة.

يُوضح الرسم البياني أعلاه نشراً افتراضياً لهذه الحاوية على ThakiCloud Kubernetes. يعمل المحاكي في pod على عقدة مُفعَّل فيها KVM مع تمرير /dev/kvm، ويُستخدم المتغير cuda حين يُحتاج تسريع GPU. يُكشف ADB كـ Service ليصل إليه مزرعة CI و scrcpy.

التثبيت والتكامل

يجمع البناء الافتراضي Android SDK وأدوات المنصة والمحاكي في الصورة. تشغيل كل شيء باستخدام docker-compose:

# المحاكي الأساسي
docker compose up android-emulator

# تسريع GPU
docker compose up android-emulator-cuda

# تسريع GPU + Google Play Store
docker compose up android-emulator-cuda-store

يمكن البناء مباشرة باستخدام Docker:

docker build -t android-emulator .

بعد بناء الصورة، شغّل الحاوية مع تثبيت محرك KVM. استخدام صورة Play Store يستلزم مشاركة المحاكي والعميل لنفس adbkey؛ أنشئه بـ adb keygen adbkey وضعه في مجلد ./keys.

يتباين حجم الصورة تبايناً كبيراً حسب متغير البناء. جدول المقارنة من توثيق المستودع:

الصور التي تتضمن المحاكي تتجاوز 1.5 GB حتى بعد الضغط. عند التوزيع على عقد كثيرة، يجب مراعاة عرض نطاق السجل وسعة قرص العقد.

التحقق من السلوك الفعلي

لم يشمل هذا المقال التحقق من إقلاع الحاوية فعلياً. تسجيل أمين: فشل التحقق هنا (لا يوجد Docker daemon على المضيف، وmacOS لا يوفر /dev/kvm). يتطلب docker-android تسريع KVM للأجهزة، لذا التشغيل الفعلي ممكن فقط على مضيف Linux أو عقدة KVM تدعم المحاكاة الافتراضية المتداخلة.

ما أمكن التحقق منه استُقي مباشرة من توثيق المستودع. جدول مقارنة أحجام الصور أعلاه يعكس أرقاماً مُصرَّحاً بها في التوثيق؛ متغيرات البناء وأسماء خدمات compose ومتطلبات تثبيت KVM كلها مستندة إلى التوثيق. أرقام كوقت الإقلاع أو معدل معالجة الاختبارات التي لم نقسها لم نُدرجها. عند النشر الفعلي، بعد توفير عقد KVM، الإجراء الصحيح هو قياس وقت إقلاع الحاوية وزمن استجابة ADB والحد الأقصى لعدد المحاكيات المتزامنة مباشرة.

الآثار على منصة ThakiCloud K8s AI/ML SaaS

docker-android ليس أداة ذكاء اصطناعي في حد ذاتها. لكن المتطلبات التشغيلية التي يكشف عنها تتقاطع بدقة مع ما تُتقنه ThakiCloud.

أولاً، عزل أحمال عمل مرور الأجهزة. المحاكي حاوية ذات امتيازات في جوهرها تتطلب /dev/kvm. تشغيل هذا النوع من أحمال العمل بأمان في بيئة Kubernetes متعددة المستأجرين يستلزم اختيار العقد بعناية والمكوّنات الإضافية للأجهزة وسياقات الأمان. تُجهّز ThakiCloud بالفعل وحدات GPU عبر مكوّنات الأجهزة الإضافية وKueue؛ يمكن التعامل مع KVM passthrough بالنمط ذاته.

ثانياً، مزارع الاختبار القابلة للتكرار. تغليف المحاكيات عديمة الواجهة الرسومية كحاويات يتيح توسيع البيئات النظيفة أفقياً عبر عدد العقد المطلوب. تشغيل اختبارات Appium UI متوازية كثيرة من خط CI/CD حالة استخدام نموذجية لجدولة وظائف Kubernetes.

ثالثاً، ونظرة إلى الأمد البعيد، يمتد هذا بشكل طبيعي نحو التحقق من أداء الذكاء الاصطناعي على الجهاز. التحقق من سلوك النماذج الخفيفة أو العوامل العاملة على أجهزة الموبايل على نطاق واسع يتطلب مزرعة أجهزة تنشئ بيئات أندرويد معزولة كثيرة وتُشغّل اختبارات الانحدار آلياً. هذا ليس اهتماماً محورياً لمنصتنا اليوم، لكن مع نضج قدرات تنظيم GPU والأجهزة متعددة المستأجرين لدينا، تغدو مزرعة QA للذكاء الاصطناعي على الموبايل من هذا النوع شيئاً يمكن تقديمه على البنية التحتية ذاتها.

باختصار، docker-android ليس منتجاً نبنيه، لكنه دراسة حالة جيدة في ترويض أحمال عمل الحاويات الثقيلة التي تجمع بين الامتياز ومرور الأجهزة وتسريع GPU على Kubernetes. هذه صورة ملموسة لقدرات تنظيم Kubernetes للأغراض العامة التي تُؤكد عليها ThakiCloud.

القيود والاعتراضات

• اعتماديات ثقيلة: تسريع KVM للأجهزة غير قابل للتفاوض. في البيئات التي لا تدعم المحاكاة الافتراضية المتداخلة، يتدهور الأداء بشكل حاد أو لا يُقلع المحاكي أصلاً. اختيار عقدة السحابة يصبح قيداً صارماً.
• تضخم الصورة: الصور التي تتضمن المحاكي تبلغ عدة GB حتى بعد الضغط. التوزيع عبر عقد كثيرة يُراكم تكاليف السجل والقرص.
• البُعد عن صلة الذكاء الاصطناعي: بصراحة، هذه الأداة بعيدة عن أحمال عمل التدريب والاستدلال التي تمثل صميم منصتنا. للمؤسسات التي ليس لديها طلب اختبار موبايل، القيمة المباشرة محدودة. قيمة هذا المقال ليست في “المحاكي بحد ذاته” بل في “أنماط تشغيل حاويات مرور الأجهزة”.
• أمن الحاويات ذات الامتيازات: الوصول إلى /dev/kvm وإعدادات الامتياز تُعقّد حدود أمان المستأجرين المتعددين. الحفاظ على عزل المستأجرين يستلزم مجمّعات عقد مخصصة وسياسات صارمة.

docker-android أداة قوية لأتمتة اختبارات الموبايل، ومرجع مفيد لكيفية التعامل مع أحمال عمل الأجهزة على Kubernetes. حتى قبل اللحظة التي نحتاجها فيها مباشرة، أنماط التشغيل تستحق الإلمام بها مسبقاً.

المصادر

• docker-android (HQarroum): https://github.com/HQarroum/docker-android
• صورة Docker Hub: halimqarroum/docker-android
• scrcpy (التحكم بالشاشة عن بُعد): https://github.com/Genymobile/scrcpy
• التغريدة الأصلية: https://x.com/hjguyhan/status/2069427245295493446

flowchart LR
    CC["Claude Code"] --> CCR["وسيط claude-code-router"]
    CCR -->|default / background| GLM["Ollama Cloud · glm-5.2"]
    CCR -->|think / longContext| MM["MiniMax-M2.7 (نقطة Anthropic)"]
    CCR -.->|وسم الوكيل الفرعي للبرمجة| KIMI["Ollama Cloud · kimi-k2.7-code"]
    CCR -.->|خيار محلي| VLLM["vLLM داخلي (GLM-air)"]
    AUDIT["حلقة قياس التكلفة اليومية"] -->|تتحقق مقابل Sonnet| CCR

نظرة عامة

‏Claude Code أداة برمجة وكيلية تعمل في الطرفية. افتراضياً تُرسِل الطلبات إلى واجهة Anthropic، لكن ليست كل الطلبات بالوزن نفسه. فالتلخيص الخلفي، والإكمال القصير، وتحليل السياق الطويل، والاستدلال العميق لإعادة الهيكلة تتطلب جميعها مستويات نماذج مختلفة. إذا أرسلت كل شيء إلى أغلى نموذج تتراكم التكلفة، وإذا أرسلت كل شيء إلى أرخصها تنهار الجودة.

يحل claude-code-router (واختصاراً CCR) هذه المشكلة عبر طبقة توجيه. يقف كوسيط بين Claude Code وخلفيات النماذج ويفرّع الحركة حسب نوع الطلب. هذا المقال ليس مجرد جولة مفاهيمية، بل سجل لاستدعاء ثلاثة نماذج خارجية للتحقق من سلوكها، وإصلاح المشكلات المكتشفة في الطريق (مفتاح API ميت، وتسرّب وسوم التفكير)، وأخيراً إرفاق حلقة تقيس باستمرار ما إذا كان التوجيه أرخص فعلاً من Sonnet.

المبدأ الحاكم، نذكره مقدّماً: كل نموذج يُوجَّه عبر CCR لا قيمة له إلا إذا كان أكثر كفاءة في التكلفة من Claude Sonnet. وإلا فإنك تخفض الجودة بينما يستمر صرف المال. لذلك لا نؤكّد، بل نقيس.

مخطط مفاهيمي

ما هو claude-code-router

‏CCR وسيط يتلقى طلبات بصيغة Anthropic، ويحوّلها إلى صيغة متوافقة مع OpenAI (أو غيرها)، ثم يمرّرها إلى المزوّد المُعَدّ. لا يعدّل عميل Claude Code. شغّل جلسة بـ ccr code فتُوجَّه حركة تلك الجلسة عبر الوسيط على localhost:3456.

أبرز الميزات:

• التوجيه حسب نوع الطلب: default وbackground وthink وlongContext وwebSearch، لكلٍّ نموذج مختلف.
• تعدّد المزوّدين: أي نقطة متوافقة مع OpenAI يمكن تسجيلها. نستخدم هنا Ollama Cloud وMiniMax.
• المحوّلات (transformers): يمتص المحوّل خصوصيات كل مزوّد. ومحوّل التمرير Anthropic لنقاط Anthropic الأصلية هو الأداة المحورية في هذا المقال.
• التبديل الديناميكي: غيّر النموذج أثناء الجلسة بـ /model provider,model.

إصدار CCR المُتحقَّق منه هو 1.0.62. يقع الإعداد في ~/.claude-code-router/config.json، ومحوره مصفوفة Providers وكائن Router.

ماذا يُوجَّه، مثبَّت على ثلاثة نماذج

مجموعة النماذج ثلاثة بالضبط. فزيادة النماذج تعقّد جدول التوجيه وترفع كلفة التحقق، لذا ضيّقناها عمداً.

‏glm-5.2 هو حصان العمل؛ والاستدلال العميق والسياق الطويل فقط يذهبان إلى MiniMax، والدور البرمجي الصعب إلى Kimi.

التحقق، استدعينا ولم نفترض

قبل كتابة أي إعداد، استدعينا النماذج الثلاثة مباشرةً. ولتجنّب اختلاق الأرقام فحصنا الاستجابات الفعلية، فظهرت ثلاث حقائق.

أولاً، مفتاح Ollama Cloud واحد يغطي GLM وKimi معاً. أرجع كلٌّ من glm-5.2 وkimi-k2.7-code رمز HTTP 200 من https://ollama.com/v1. فـ Ollama Cloud يجمع عائلات GLM وKimi وDeepSeek وQwen خلف مفتاح واحد.

ثانياً، مفتاح Kimi المنفرد كان ميتاً. أرجع مفتاح Moonshot المنفرد في .env رمز 401 (مصادقة غير صالحة) على moonshot.ai وmoonshot.cn ونقطة Anthropic المتوافقة على حدٍّ سواء. لحسن الحظ يمكن الوصول إلى Kimi K2 عبر kimi-k2.7-code في Ollama Cloud، فلم يكن المفتاح الميت طريقاً مسدوداً.

ثالثاً، اختيار نقطة MiniMax يحسم الجودة. عند الاستدعاء عبر النقطة المتوافقة مع OpenAI (/v1/chat/completions) يضمّن النموذج استدلاله داخل المتن بوسوم <think>...</think>، وتعجز طبقة التحويل في CCR عن إزالتها فتتسرب إلى المستخدم (musistudio/claude-code-router#964). أما عند الاستدعاء عبر نقطة Anthropic الأصلية (/anthropic/v1/messages) فيُرجع النموذج نفسه كتلتي thinking وtext نظيفتين.

البند الأخير علّة وجب إصلاحها لا سبباً لإسقاط MiniMax. والإصلاح مُضمَّن في الإعداد أدناه.

الإعداد، الأسرار خارج المستودع، والإعداد كشيفرة

لا تُكتب المفاتيح مباشرةً في ملف الإعداد. سكربت مولِّد يقرأ .env في المستودع ويكتب ~/.claude-code-router/config.json. فلا تبقى مفاتيح في المستودع، وتدوير المفتاح يعني فقط إعادة تشغيل السكربت.

الإعداد المُولَّد الأساسي:

{
  "LOG": true,
  "HOST": "127.0.0.1",
  "PORT": 3456,
  "API_TIMEOUT_MS": 1800000,
  "Providers": [
    {
      "name": "ollama",
      "api_base_url": "https://ollama.com/v1/chat/completions",
      "api_key": "<OLLAMA_GLM_API_KEY>",
      "models": ["glm-5.2", "kimi-k2.7-code"],
      "transformer": { "use": [["maxtoken", { "max_tokens": 16000 }]] }
    },
    {
      "name": "minimax",
      "api_base_url": "https://api.minimax.io/anthropic/v1/messages",
      "api_key": "<MINIMAX_API_KEY>",
      "models": ["MiniMax-M2.7"],
      "transformer": { "use": ["Anthropic"] }
    }
  ],
  "Router": {
    "default": "ollama,glm-5.2",
    "background": "ollama,glm-5.2",
    "think": "minimax,MiniMax-M2.7",
    "longContext": "minimax,MiniMax-M2.7",
    "longContextThreshold": 60000,
    "webSearch": "ollama,glm-5.2"
  }
}

السطران في مزوّد MiniMax هما ما يُصلِح تسرّب التفكير. وجِّه api_base_url إلى مسار Anthropic الأصلي واستخدم محوّل التمرير Anthropic، فيستجيب MiniMax بصيغة رسائل Anthropic (كتلتا thinking وtext) منذ البداية. وعند إعادة الفحص عبر الوسيط كانت كتل الاستجابة ["thinking", "text"] بلا أي تسرّب لـ <think>.

نماذج الاستدلال بطيئة الإخراج، لذا جُعِلت المهلة سخية (1800000ms)، ويحجز maxtoken مساحة إخراج كي لا تستنفد نماذج مثل GLM وKimi ( التي تُخرِج الاستدلال أولاً ) الميزانية قبل الإجابة.

تُوجَّه الوكلاء الفرعيون لا بالإعداد بل بوسم في مقدمة المُوجّه. لتفويض مهمة برمجية صعبة، أضِف في مقدمة المُوجّه <CCR-SUBAGENT-MODEL>ollama,kimi-k2.7-code</CCR-SUBAGENT-MODEL>.

أين وكيف تتصل

نقطة الاتصال واحدة. ابدأ جلسة بـ ccr code في مستودع عملك، فتُوجَّه حركة تلك الجلسة الرئيسية والفرعية كلها عبر الوسيط وفق الجدول أعلاه. أما claude الأصلي فيتصل مباشرةً بـ Anthropic، فلا يتأثر.

# توليد الإعداد ثم تشغيل الموجِّه
python3 scripts/ccr/gen_ccr_config.py && ccr restart

# بدء جلسة موجَّهة للتكلفة (هذه هي نقطة الاتصال)
ccr code

# بدّل النماذج حسب المهمة داخل الجلسة
/model ollama,kimi-k2.7-code     # دور برمجي صعب
/model minimax,MiniMax-M2.7      # دور استدلال عميق
/model ollama,glm-5.2            # برمجة يومية

من حيث كفاءة التكلفة، النمط المُوصى به هجين. شغّل الأعمال الكثيفة والمتكررة وغير التفاعلية (توليد الاختبارات، إعادة الهيكلة الجماعية، تحليل السجلات، الترجمة، استكشاف الكود) تحت ccr code لخفض التكلفة، وأبقِ الأعمال التي تتطلب حكماً (قرارات معمارية، تصحيح دقيق) على جلسة claude الاشتراكية الأصلية. فنقل كل شيء إلى الجلسة الموجَّهة يجعل GLM حلقتك الرئيسية، وقد يخفض الجودة في المهام الصعبة.

كفاءة التكلفة، قياس مستمر مقابل Sonnet

سبب وجود هذا الإعداد هو التكلفة. لذا بدل أن ندّعي أنه “أرخص”، نقيس.

الأسعار المُتحقَّق منها في 2026-06-24 (بالدولار لكل مليون رمز):

‏MiniMax-M2.7 نحو 7-8% من سعر Sonnet لكل رمز، فهو دوماً أرخص بفارق كبير. أما Ollama Cloud فاشتراك شهري ثابت لا تسعير لكل رمز. سعره الفعلي = الرسم الشهري ÷ الرموز المستخدمة شهرياً، وعند الاستخدام المنخفض يكون الرسم الثابت $20 خسارة. وبمعدل مخلوط $9/M، عليك تجاوز نحو 2.2 مليون رمز شهرياً قبل أن يتفوق على Sonnet.

نقطة التعادل هذه هدف قياس لا تخمين. تسجّل سجلات CCR النموذج المُوجَّه ورموز الإدخال/الإخراج لكل طلب. وسكربت قياس يجمعها، فيحسب نسبة التكلفة الفعلية إلى تكلفة Sonnet المكافئة للنماذج بالرمز، والتكلفة الشهرية المتوقّعة لـ Sonnet مقابل رسم الاشتراك للنماذج بالاشتراك. وتتراكم النتائج في ملف تاريخي لتتبّع الاتجاه، والتحسّن يعني انخفاض النسبة مع الوقت.

تعمل الحلقة مرة يومياً عبر launchd. ولا يكون Claude داخل الحلقة؛ بل يعمل سكربت بسيط فقط على cron، فتكون كلفة القياس نفسها صفراً. وإذا وُجِد نموذج بالرمز أغلى من Sonnet يُطلَق تنبيه إلى Slack. أما النموذج بالاشتراك دون نقطة التعادل (استخدام ناقص) فيُسجَّل دون تنبيه، تفادياً للضجيج في مرحلة الانطلاق.

قواعد الإجراء مرتبطة بالقياس. إذا بلغت نسبة نموذج بالرمز 1.0 أو أكثر (أغلى من Sonnet) يُزال فوراً من التوجيه. وإذا بقي نموذج بالاشتراك دون الاستخدام أشهراً، خفّض الخطة أو انقل ذلك المسار إلى نموذج رخيص بالرمز. وعند تغيّر الأسعار يكفي تحديث ملف جدول الأسعار لينعكس في التشغيل التالي.

منظور منصة ThakiCloud

ينسجم نموذج التوجيه هذا طبيعياً مع البنية التي تشغّلها ThakiCloud فعلاً.

أمن الكود. في البيئات التي لا يمكن أن يغادر فيها الكود المصدري (المالية، القطاع العام، الرعاية الصحية)، يكفي تبديل default في الإعداد أعلاه إلى نقطة vLLM داخلية. فتحتفظ بقابلية استخدام Claude Code بينما لا تغادر المُوجّهات والكود قط. وإعداد النماذج الخارجية هنا للتحقق من التكلفة؛ ضع خدمة GPU الداخلية في الهيكل نفسه فتحصل على النسخة المحلية.

التحكم في التكلفة. التوجيه حسب المهمة هو توجيه حسب التكلفة. أرسِل الطلبات عالية التكرار منخفضة الصعوبة إلى نماذج رخيصة واحتفظ بالنماذج العليا للاستدلال الصعب، فتضيّق الاستخدام المكلف إلى حيث يلزم فعلاً، وتثبت حلقة القياس الأثر بالأرقام.

السياسة كشيفرة. المزوّدون وقواعد التوجيه وجدول الأسعار ومعايير القياس كلها مُدارة كملفات نصية مُودَعة في المستودع. وتبقى المفاتيح وحدها في .env ويُعاد إنتاج الإعداد بمولِّد، فيُستعاد الإعداد نفسه على أي جهاز.

الحدود والاعتراضات

الموجِّه لا يحل كل شيء. عدة نقاط تستحق نظرة باردة.

• فجوة الجودة: قيمة التوجيه تتبع جودة النموذج الخلفي. فالنماذج المفتوحة لا تجاري دوماً النماذج المغلقة العليا في إعادة الهيكلة المعقدة متعددة الخطوات أو التصحيح الدقيق. ومن هنا توصية النمط الهجين.
• موثوقية استدعاء الأدوات: يعتمد Claude Code كثيراً على استدعاء الأدوات. وقد تهتز صيغ استدعاء الأدوات عبر طبقة التحويل المتوافقة مع OpenAI، فهي آمنة لوكلاء الاستكشاف/التلخيص لكنها تستدعي توسعاً تدريجياً لوكلاء التحرير/التنفيذ.
• فخ الاشتراك: Ollama Cloud بسعر ثابت، فالاستخدام المنخفض خسارة. ودون نقطة التعادل يكون Sonnet أرخص ببساطة. وحلقة القياس تراقب هذه النقطة بالضبط.
• الوسيط نقطة فشل واحدة: تمر الحركة الرئيسية أيضاً عبر CCR، فإذا مات الوسيط تتوقف الجلسة. والبديل هو claude الأصلي.
• فخ تأطير “المجاني”: تروّج بعض النسخ المعدّلة لإزالة القياس عن بُعد أو حواجز الأمان بوصفها “مجانية”. وهذا اتجاه لا تستطيع شركة تأييده. والقيمة التي نأخذها ليست المجانية بل التحكم، نحن من يقرّر أي طلب يذهب إلى أي نموذج، ونحن من يقيس التكلفة.

في الخلاصة، CCR ليس حيلة سحرية لخفض التكلفة بل أداة تحكم في التوجيه. وحين يُدمَج مع مجموعة نماذج مُتحقَّق منها، وإصلاحات لعلل حقيقية مثل تسرّب التفكير، وقياس مستمر مقابل Sonnet، يصبح مكسباً حقيقياً على محوري الأمان والتكلفة.

المصادر

• claude-code-router (musistudio): https://github.com/musistudio/claude-code-router
• مشكلة تسرّب تفكير MiniMax: claude-code-router#964
• سعر MiniMax M2.7: openrouter.ai/minimax/minimax-m2.7
• أسعار Ollama Cloud: ollama.com/pricing
• أسعار Claude API: platform.claude.com/docs pricing

صورة تجسّد مفهوم DFlash: تحويل مرحلة الصياغة في الفك التخميني من نهج تسلسلي إلى نهج متوازي.

نظرة عامة

في خدمة نماذج اللغة الكبيرة، يُحدَّد التكلفة وسرعة الاستجابة المحسوسة للمستخدم في آنٍ واحد من خلال إنتاجية فك التشفير. طالما أن النموذج يولّد الرموز واحداً تلو الآخر بالنهج الانحداري الذاتي (autoregressive)، فسيظل القيد البنيوي قائماً: يجب إجراء تمريرة كاملة عبر النموذج لكل رمز، بصرف النظر عن سرعة وحدة معالجة الرسومات. لقد أصبح الفك التخميني (speculative decoding) الأسلوب الأكثر عملية لتجاوز هذا الاختناق، غير أن المسودّات التقليدية أيضاً كانت تُولّد الرموز تسلسلياً، مما جعل معاملات التسريع تتوقف في الغالب عند نطاق 2-3×.

في 23 يونيو 2026، نشرت NVIDIA في مدونتها التقنية دراسة حول DFlash من باحثي جامعة كاليفورنيا سان دييغو. يُدخل DFlash نموذج انتشار كتلي (block diffusion) في مرحلة الصياغة من الفك التخميني، إذ يقترح الرموز المستقبلية ككتلة في تمريرة أمامية واحدة بدلاً من اقتراحها رمزاً رمزاً. وفقاً للأرقام المنشورة، يبلغ التسريع الخالي من الخسارة في التدفق المفرد ما يصل إلى 6×، فيما تصل الإنتاجية على NVIDIA Blackwell إلى 15× مقارنةً بنفس هدف الاستجابة.

والميزة التشغيلية الأكثر أهمية هي التكامل المباشر (drop-in). يدعم DFlash كلاً من vLLM وSGLang وTensorRT-LLM؛ وفي vLLM يكفي استبدال إعداد الصياغة من EAGLE-3 بإعداد DFlash دون أي تعديل في كود التطبيق. تستعرض هذه المقالة آلية عمل DFlash، وما تكشفه المعايير المنشورة، والتداعيات من منظور ThakiCloud في تشغيل منصة AI/ML متعددة المستأجرين مبنية على Kubernetes. جميع الأرقام الواردة هنا هي قياسات رسمية منشورة من NVIDIA وUCSD، ونتناول موضوع إعادة الإنتاج على معداتنا الخاصة بصدق في القسم المناسب.

ما هي هذه التقنية؟

ينقسم الفك التخميني إلى مرحلتين: يقترح نموذج مسودة صغير الرموز المستقبلية، ثم يتحقق النموذج المستهدف الكبير من هذه الرموز بالتوازي ويقبل الصيغة الصحيحة الأطول. إذا كانت المسودة صحيحة، تُؤكَّد رموز متعددة بتمريرة تحقق واحدة من النموذج المستهدف. المشكلة أن المسودّات التقليدية تعتمد النهج الانحداري الذاتي، فترتفع تكلفة الصياغة خطياً مع زيادة عدد الرموز التخمينية، مما يُصعّب رفع الإنتاجية أكثر.

يستبدل DFlash هذا المسودّ الانحداري بمسودّ انتشار كتلي خفيف. يُزيل نموذج الانتشار الكتلي التشويش عن كتلة رموز مُخفاة دفعةً واحدة، جامعاً بين التوليد المتوازي والبنية الكتلية الانحدارية. يُطبّق DFlash هذه الفكرة على مرحلة الصياغة فحسب، بينما يتولى النموذج المستهدف الانحداري الموثوق التحقق. هذا الفصل هو مفتاح الحفاظ على الجودة: كثيراً ما تفتقر نماذج الانتشار المنفردة إلى دقة النماذج الانحدارية وتتطلب مراحل إزالة تشويش متعددة، لكن في DFlash يكفي أن تكون المسودة “جيدة بما يكفي لتجتاز التحقق”، وتكفل تمريرة التحقق المتوازية من النموذج المستهدف التزام توزيع المخرجات بالنموذج المستهدف. أي أن العملية خالية من الخسارة (lossless).

flowchart LR
    subgraph EAGLE["EAGLE-3 (صياغة انحدارية ذاتية)"]
        direction TB
        E1["رمز t1"] --> E2["رمز t2"] --> E3["رمز t3"] --> E4["رمز t4"]
    end
    subgraph DFLASH["DFlash (صياغة بالانتشار الكتلي)"]
        direction TB
        D0["كتلة مُخفاة"] --> D1["t1 · t2 · t3 · t4 (تمريرة أمامية واحدة)"]
    end
    EAGLE --> V1["تحقق متوازٍ بالنموذج المستهدف"]
    DFLASH --> V2["تحقق متوازٍ بالنموذج المستهدف"]
    V1 --> OUT["مخرجات خالية من الخسارة"]
    V2 --> OUT

الميزة الثانية تكمن في بنية تكلفة الصياغة. ترتفع تكلفة المسودّ الانحداري خطياً مع عدد الرموز التخمينية، بينما يُولّد مسودّ الانتشار جميع الرموز في تمريرة متوازية واحدة، فيظل تأخر الصياغة شبه ثابت بتوسع الكتلة. هذا يُتيح لـDFlash استخدام نماذج صياغة أعمق وأكثر تعبيراً دون زيادة التأخر. يستخدم DFlash فعلياً مسودّاً صغيراً بـ5 طبقات (8 طبقات في حالة Qwen3-Coder)، وهو تباين واضح مع أبحاث مسودّات الانتشار السابقة (DiffuSpec، SpecDiff-2) التي استخدمت مسودّات ضخمة بمليارات المعاملات فأبقت التسريع عند 3-4×.

التقنيات الثلاث التي يجمعها DFlash هي: أولاً الصياغة بالانتشار الكتلي للتنبؤ المتوازي بالرموز المستقبلية، وثانياً التكييف بالحالات الخفية للنموذج المستهدف (target hidden-state conditioning) لتمرير ميزات السياق من النموذج المستهدف إلى المسودّ عبر حقن KV، وثالثاً التدريب الصديق للتحقق لرفع معدل قبول الكتل المُسوَّدة. هذا المزيج يُحقق توازن “مسودّ صغير + اقتراح كتلي متوازٍ + تحقق خالٍ من الخسارة”.

التثبيت والتكامل

يُوزَّع DFlash مع نقاط التفتيش ودعم الأطر معاً، مما يجعل التبني يتطلب حداً أدنى من الكود. نقاط التفتيش العامة متاحة من مجموعة z-lab/dflash على Hugging Face، وفي وقت الإعلان تتضمن 20 نقطة تفتيش. في vLLM، يكفي استبدال إعداد EAGLE-3 بإعداد DFlash دون إعادة هيكلة التطبيق. المثال التالي من التوثيق الرسمي:

vllm serve Qwen/Qwen3.5-27B \
  --speculative-config '{"method": "dflash", "model": "z-lab/Qwen3.5-27B-DFlash", "num_speculative_tokens": 15}' \
  --attention-backend flash_attn \
  --max-num-batched-tokens 32768

المفتاح هو تحديد "method": "dflash" في --speculative-config مع تمرير مسار نقطة تفتيش المسودّ. تظل بنية الأعلام مطابقة تقريباً لما كان يُستخدم في خدمة EAGLE-3، مما يجعل التحويل مجرد استبدال نهج الفك التخميني في نشر vLLM القائم. يقبل SGLang وTensorRT-LLM بالمثل نقطة تفتيش مسودّ DFlash عبر واجهة API الخاصة بالفك التخميني.

يدعم خلفية Transformers سلسلتَي Qwen3 وLLaMA-3.1، ويوفر واجهة spec_generate تستدعي نموذج المسودّ والنموذج المستهدف معاً:

from transformers import AutoModel, AutoModelForCausalLM, AutoTokenizer

draft = AutoModel.from_pretrained(
    "z-lab/Qwen3-8B-DFlash-b16", trust_remote_code=True,
    dtype="auto", device_map="cuda:0").eval()
target = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen3-8B", dtype="auto", device_map="cuda:0").eval()
tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen3-8B")

messages = [{"role": "user", "content": "196의 양의 약수는 몇 개인가?"}]
input_ids = tokenizer.apply_chat_template(
    messages, return_tensors="pt", add_generation_prompt=True,
    enable_thinking=False).to(draft.device)

output = draft.spec_generate(
    input_ids=input_ids, max_new_tokens=2048, temperature=0.0, target=target)

كتل الكود أعلاه مستشهد بها من الأمثلة الرسمية الواردة في مدونة NVIDIA التقنية وMarkTechPost، وليست نتائج التقاط مباشر من بيئة ThakiCloud. قياسات إنتاجية DFlash أُجريت على بيئة NVIDIA Blackwell (DGX B300، 8 وحدات GPU)، ولا تتوفر في بيئة كتابة هذا المقال المُعجِّلات ونقاط التفتيش المطلوبة لإعادة إنتاج نفس الظروف. وبناءً على ذلك، فإن جميع النتائج المذكورة أدناه أرقام منشورة من مصادر موثّقة، ولا تشمل قياسات محققة ذاتياً.

نتائج التجارب الفعلية (وفق الأرقام المنشورة)

تنقسم أرقام تسريع DFlash إلى فئتين تختلف طرق قياسهما، لذا ينبغي قراءتهما بتمييز:

أولاً، التسريع الخالي من الخسارة في التدفق المفرد. يُرجع بحث UCSD متوسط 4.86× لـQwen3-8B بالفك الجشع (Transformers backend)، وأعلى قيمة 6.08× على MATH-500. في نفس الظروف، يُحقق EAGLE-3 متوسط 1.76× بحجم شجرة 16، و2.02× بحجم 60. أرقام كل مهمة موضحة في الرسم البياني أدناه.

الرسم البياني أعلاه يُمثّل بيانياً الأرقام الرسمية من ورقة UCSD حول DFlash، وليس قياسات مباشرة من ThakiCloud. GSM8K: 5.15×، MATH-500: 6.08×، AIME25: 5.62×، HumanEval: 5.14×، LiveCodeBench: 5.51×، وهي قيم مرتفعة بشكل خاص في مهام الاستدلال الرياضي والبرمجي. في المقابل، تبلغ قيمة MT-Bench للمحادثات المفتوحة 2.75× فقط، وهو أمر متوقع لأن مكاسب الفك التخميني تتناسب مع إمكانية التنبؤ بالمخرجات (معدل القبول).

ثانياً، الإنتاجية عند هدف استجابة ثابت. الرقم 15× الذي تُرجعه NVIDIA يعني أن خدمة gpt-oss-120b عبر TensorRT-LLM على DGX B300 (8 وحدات Blackwell GPU) تُنتج إنتاجية أعلى بأكثر من 15× مقارنة بالفك التشفيري الانحداري، في النطاق الذي يتراوح فيه 500-600 رمز/ثانية للمستخدم. وفي نفس النقطة، يبلغ التسريع مقارنة بـEAGLE-3 نحو 1.5×. في اختبار Speed-Bench المنفصل من NVIDIA (تسريع الاستجابة عند نفس التزامن)، حقق gpt-oss-120b: DFlash 2.3× مقابل EAGLE-3 1.7×، وحقق Llama 3.1 8B Instruct: DFlash 2.8× مقابل EAGLE-3 2.2×. عبر المهام، تصل الأرقام إلى Gemma 4 31B: 5.8× (vLLM)، Qwen3 8B: 5.1× (SGLang).

خلاصة القول، “6×” هو تسريع خالٍ من الخسارة لطلب منفرد، أما “15×” فهو إنتاجية الخدمة عند تقييد عدد كبير من المستخدمين بنفس هدف الاستجابة. الرقمان يُجيبان على سؤالين مختلفين؛ لذا عند تقدير التأثير المتوقع في بيئة الإنتاج، حدد أولاً نسبة التزامن وهدف الاستجابة لديك ثم ارجع إلى الأرقام المقابلة لذلك النطاق.

التداعيات على منصة ThakiCloud AI/ML SaaS على Kubernetes

تُشغّل ThakiCloud بنية تُجدول فيها GPU عبر Kueue على Kubernetes وتخدم نماذج مستأجرين متعددين عبر vLLM. DFlash نوع من التحسين يتناسب بشكل خاص مع هذه البنية، لثلاثة أسباب:

أولاً، التكامل المباشر يُخفض مخاطر التشغيل. إذا كنت تستخدم الفك التخميني مع EAGLE-3، يمكنك تبديل method ونقطة تفتيش المسودّ إلى DFlash والتحقق من النتائج بنشر كناري. بما أنها تقنية خالية من الخسارة لا تُغير عقد التطبيق (مخطط API، توزيع المخرجات)، تبقى الاستجابات المُدرَكة من المستأجرين متطابقة وتتحسن الإنتاجية والتأخر فقط. التحسينات التي لا تكسر اتساق المخرجات في SaaS متعدد المستأجرين نادرة القيمة.

ثانياً، كفاءة GPU تساوي تكلفة الوحدة. القدرة على معالجة طلبات متزامنة أكثر بنفس وحدة GPU وعند نفس مستوى الاستجابة تعني انخفاض تكلفة الخدمة لكل مستأجر. يتضاعف هذا التأثير في بيئات GPU يصعب فيها التوسع مثل GPU محلية أو في مناطق إقليمية. هذا يتوافق تماماً مع رسالة ThakiCloud المتعلقة بالخدمة الذاتية وكفاءة التكلفة. غير أن الـ15× من NVIDIA هو الحد الأعلى لمزيج Blackwell + TensorRT-LLM، وينبغي معايرة التوقعات وفق جيل GPU والخلفية لديك.

ثالثاً، مكاسب أكبر في أحمال عمل الرياضيات والبرمجة. عوامل الكود الداخلية وخطوط معالجة البيانات وأعباء عمل الوكلاء الغنية بالأدوات تُنتج مخرجات منظمة نسبياً تُحقق معدلات قبول عالية. المستأجرون الذين يخدمون هذه الأحمال بكثافة يُرجَّح أن يحققوا مكاسب DFlash فوق المتوسط. لما كانت ThakiCloud تستهدف منصة وكلاء متعددي المستأجرين، فإن تطبيق ملف تعريف خدمة DFlash أولاً على المستأجرين المتمحورين حول الكود والاستدلال استراتيجية تستحق الدراسة.

على صعيد خارطة طريق النضج، المسار الطبيعي هو الكشف عن نهج الفك التخميني في مخطط خدمة vLLM كملف تعريف لكل مستأجر، مع تشغيل حلقة قياس تكلفة في الخلفية لتتبع “هل انخفض سعر الرمز الواحد فعلاً بعد تطبيق DFlash؟” في الزمن الفعلي. مبدأ القياس لا الجزم ينطبق على تحسين الاستدلال بنفس القدر.

القيود والاعتراضات

DFlash ليس الحل الشامل لكل شيء. أولاً، أقصى الأرقام المُرجَعة مقيّدة بأجهزة وخلفيات بعينها. الـ15× نتيجة مزيج Blackwell + TensorRT-LLM، وستنخفض عوامل التسريع مع GPU أقدم أو مكدسات خدمة مختلفة. الـ6× الخالية من الخسارة هي أيضاً للفك الجشع في تدفق مفرد؛ في أعباء عمل المحادثة عالية الحرارة أو المتنوعة، تنخفض معدلات القبول وتتضاءل المكاسب (2.75× لـMT-Bench يُوضح ذلك).

ثانياً، الفك التخميني نفسه يتطلب ذاكرة إضافية. يشغل نموذج المسودّ وذاكرة KV الخاصة به مساحة GPU، مما قد يُحدث مقايضة مع الحد الأقصى للتزامن في بيئات متعددة المستأجرين ذات الذاكرة الضيقة. صغر حجم المسودّ يُخفف هذا العبء لكنه لا يُلغيه.

ثالثاً، مسؤولية التحقق التشغيلي تقع على عاتق المُطبِّق. الأرقام المنشورة من مصادر موثّقة، لكن لا يوجد ضمان بإعادة إنتاجها على نموذجك وحركة مرورك ومستوى تزامنك. في هذا المقال لم نتمكن من إعادة الإنتاج في بيئة ThakiCloud، لذا قبل أي تبني فعلي ينبغي قياس تكلفة الرمز وتأخر p50/p99 مباشرةً عبر نشر كناري. أخيراً، مسودّات الانتشار الكتلي نهج جديد نسبياً قد لا تتوفر له نقاط تفتيش لجميع بنى النماذج، لذا تحقق أولاً من وجود نقطة تفتيش مسودّ مناسبة للنموذج المستهدف الذي تخدمه.

المصادر

• Boost Inference Performance up to 15x on NVIDIA Blackwell Using DFlash Speculative Decoding (NVIDIA Technical Blog, 2026-06-23)
• DFlash Speculative Decoding Drafts Whole Token Blocks in Parallel (MarkTechPost, 2026-06-24)
• مجموعة نقاط تفتيش DFlash العامة (Hugging Face, z-lab/dflash)
• توثيق الفك التخميني في vLLM

Claude Code عميل برمجي قوي. غير أن بنيته القائمة على توجيه كل طلب مباشرةً إلى Anthropic API تُقيّد المؤسسات الراغبة في ضبط التكاليف أو إبقاء البيانات داخل حدودها. يعالج مشروع free-claude-code الذي شهد انتشاراً واسعاً مؤخراً هذه النقطة بالذات؛ إذ يُمثّل طبقة بروكسي تعترض حركة مرور Claude Code وتعيد توجيهها إلى 17 مزوداً مختلفاً. وهو مشروع مرخص بـ MIT يحمل 36.7k نجمة على GitHub و5.7k تفرع و712 إيداعاً.

شعار المشروع التسويقي هو “Claude Code مجاناً إلى الأبد.” يعمل النهج عبر تحويل حركة المرور نحو مزودين ذوي فئة مجانية أو منخفضة التكلفة، وهذا الإطار مبالغ فيه إلى حد ما وينطوي على منطقة رمادية من حيث شروط الخدمة. لذا يركز هذا المقال لا على زاوية “المجاني”، بل على ما يعنيه هذا الأداة للمؤسسات كـ ThakiCloud التي تخدم نماذجها الخاصة على Kubernetes وتريد ربط Claude Code ببنيتها التحتية الخاصة. النقاط الجوهرية هي أن الكود والمطالبات لا تغادر حدود المستأجر، وتختفي فواتير السحابة المحسوبة لكل رمز، ولا حاجة لتعديل جانب العميل لأن نقطة النهاية متوافقة مع Anthropic.

ملاحظة: ركّز المقال السابق “توجيه Claude Code إلى النماذج الداخلية - claude-code-router” على المراجحة في التكاليف بين نماذج السحابة (glm وMiniMax وKimi). يتناول هذا المقال أداةً مختلفة (free-claude-code)، ويعالج الاتصال بـ الخلفيات المستضافة ذاتياً (Ollama وvLLM) لا بالسحابة، إلى جانب مخاطر النشر التي كشفها هذا المسار.

ما الذي يفعله هذا الأداة

free-claude-code خادم بروكسي محلي يستقبل الطلبات التي يرسلها Claude Code (وCodex). ميزته الجوهرية أنه يحاكي نقطة نهاية متوافقة مع Anthropic بشكل كامل. من منظور العميل، لا يمكن تمييزه عن Anthropic API الحقيقية، مما يتيح تبديل الخلفية دون تغيير سطر واحد في Claude Code.

الخادم مكتوب بـ FastAPI ويكشف نقاط النهاية التالية:

• /v1/messages - متوافق مع Anthropic Messages API (المسار الرئيسي لـ Claude Code)
• /v1/models - قائمة النماذج
• /v1/responses - متوافق مع OpenAI Responses API (لـ Codex؛ يُحوَّل داخلياً إلى Messages)

عند وصول طلب، يقرر موجّه النماذج أي مزود يرسل إليه الطلب، ثم يحوّل المُوحِّد كتل التفكير وأدوات الاستدعاء واستجابات الخطأ إلى الشكل الذي يتوقعه كل عميل. نظراً لاختلاف صيغ الاستجابة بين المزودين، تكمن في طبقة التوحيد هذه الصعوبة الحقيقية.

لنتوسع قليلاً في سبب صعوبة التوحيد: يفترض Claude Code بنية استجابة خاصة بـ Anthropic؛ فخطوات الاستدلال تأتي ككتل thinking، واستدعاءات الأدوات ككتل محتوى tool_use. لكن DeepSeek يُصدر الاستدلال كحقل منفصل، في حين تُعيد المزودين المتوافقين مع OpenAI استدعاءات الأدوات كمصفوفة tool_calls. المعنى واحد وهو “استُدعيت أداة”، لكن صيغة السلك تختلف في كل حالة. يجب على المُوحِّد استيعاب هذه الفوارق وضمان حصول Claude Code على استجابات بشكل متطابق بغض النظر عن الخلفية المستخدمة. يذهب مسار Codex (/v1/responses) خطوة أبعد بتحويل طلبات OpenAI Responses داخلياً إلى Anthropic Messages قبل مشاركة الموجّه والمُوحِّد ومحوّلات المزودين ذاتها. أي أن تحويل البروتوكول يجري في الاتجاهين — وهذا هو الفارق الجوهري بين البروكسي العكسي البسيط وبروكسي التوجيه.

الشكل 1. يستقبل بروكسي FastAPI حركة المرور المتوافقة مع Anthropic من Claude Code ويوزعها على 17 مزوداً. من منظور ThakiCloud، المسارات الجوهرية هي الخلفيات المستضافة ذاتياً على اليمين (Ollama وLM Studio وvLLM).

المزودون المدعومون 17 مزوداً. على الجانب السحابي: NVIDIA NIM وOpenRouter وGoogle AI Studio (Gemini) وDeepSeek وMistral La Plateforme وMistral Codestral وOpenCode Zen وOpenCode Go وWafer وKimi وCerebras وGroq وFireworks وZ.ai. على جانب الاستضافة الذاتية: LM Studio وllama.cpp وOllama. الثلاثة الأخيرة هي ذات الأهمية من منظور ThakiCloud. إذ يكشف Ollama وllama.cpp نقاط نهاية متوافقة مع OpenAI، مما يعني أن خادم vLLM المنشور بالطريقة ذاتها على Kubernetes يمكن ربطه بنفس الأسلوب.

يتحكم في توجيه الفئات عبر متغيرات البيئة. يحدد كل من MODEL_OPUS وMODEL_SONNET وMODEL_HAIKU أي نموذج يُوجَّه إليه كل فئة من فئات Claude الثلاث؛ وعند غياب التحديد يُستخدم النموذج الاحتياطي MODEL. يتيح هذا نشراً متدرجاً، كتوجيه حركة مرور Haiku الخفيفة إلى نماذج صغيرة والحركة الثقيلة من Opus إلى نماذج أكبر.

التثبيت والتكامل

مسار التثبيت الرسمي هو سطر أوامر واحد:

# macOS / Linux
curl -fsSL "https://github.com/Alishahryar1/free-claude-code/blob/main/scripts/install.sh?raw=1" | sh

# Windows PowerShell
irm "https://github.com/Alishahryar1/free-claude-code/blob/main/scripts/install.ps1?raw=1" | iex

بدلاً من سطر الأوامر، تحققت من الحزمة بتثبيتها مباشرةً في بيئة اختبار معزولة، حفاظاً على سلامة البيئة الافتراضية المشتركة وفق قواعد وقت تشغيل Python في ThakiCloud.

# شجرة عمل معزولة + venv مؤقت (البيئة المشتركة .venv على 3.12.8 وستتعارض)
uv venv --python 3.14 .expenv
VIRTUAL_ENV=.expenv uv pip install "git+https://github.com/Alishahryar1/free-claude-code.git"

تُثبَّت الحزمة ذاتها بنظافة. تُحلّ التبعيات مثل fastapi وuvicorn وhttpx وpydantic وopenai وloguru بنجاح، وتُنشأ سكريبتات وحدة التحكم مثل fcc-server وfcc-init وfcc-claude. بعد تشغيل الخادم، يُوجَّه Claude Code نحو البروكسي على النحو الآتي:

fcc-server            # تشغيل بروكسي FastAPI (الافتراضي http://127.0.0.1:8082)
# مثال على خلفية مستضافة ذاتياً (Ollama):
#   MODEL_HAIKU=ollama/llama3.2:3b
#   MODEL_SONNET=ollama/qwen2.5:7b
# حدد عنوان URL الأساسي لتوجيه Claude Code نحو البروكسي ثم استخدمه كالمعتاد

واجهة الإدارة متاحة على http://127.0.0.1:8082/admin وتكون محدودة بحلقة الاسترداد فقط. تُدار هنا مفاتيح المزودين وتوجيه النماذج وإعدادات الرسائل والصوت.

نتائج التجربة الفعلية

خلال عملية التحقق، واجهت نقطة أعاقت إعادة الإنتاج، وأسجلها كما هي. عدم اختلاق الأرقام مبدأ راسخ في هذا التقرير.

حاجز التشغيل: الاشتراط الصارم بـ Python 3.14

يُثبّت free-claude-code الإصدار v2.3.14 اشتراط requires-python = ">=3.14.0" بشكل صارم. Python 3.14 هو الإصدار الأحدث الذي صدر رسمياً في أكتوبر 2025 فحسب. المشكلة أن الإصدار 3.14 الوحيد المتاح في بيئة الاختبار كان بناء ألفا (3.14.0a7). تشغيل fcc-server على هذا الإصدار الألفا يفشل بالخطأ التالي:

ImportError: cannot import name 'get_annotate_from_class_namespace'
from 'annotationlib'

يحدث هذا التعارض لأن pydantic المثبّت يتوقع واجهة annotationlib الخاصة بالإصدار النهائي 3.14، لكن الرمز المطلوب غير موجود بعد في الإصدار الألفا المبكر. حاولت عندئذٍ التشغيل قسراً على الإصدار المستقر الأدنى (3.13)، لكن التثبيت ذاته يُرفض بسبب الاشتراط الصارم في بيانات الحزمة:

free-claude-code==2.3.14 cannot be used ... your requirements are unsatisfiable.

الخلاصة واضحة: في البيئات التي تفتقر إلى Python 3.14 المستقر، لن يعمل هذا البروكسي أبداً. فشل محاولة إعادة الإنتاج: الحزمة تشترط Python 3.14 الصادر حديثاً، لكن الإصدار 3.14 الوحيد المتاح ألفا يتعارض مع pydantic المثبّت. هذه ليست عيباً في الأداة بقدر ما هي مشكلة تثبيت إصدار متعجّل يتعارض مع واقع بيئات الإنتاج التي تبقى في الغالب على 3.11–3.12.

القياس المباشر لمسار التوجيه المستضاف ذاتياً

رغم أن البروكسي نفسه لم يُشغَّل، فإن الآلية التي تستخدمها هذه الأداة لاستدعاء مزود ollama هي نقطة النهاية المتوافقة مع OpenAI. لذا قست هذا المسار باستدعاء Ollama المحلي مباشرةً. هذه أرقام أداء التوجيه للخلفية ذاتها دون تضمين الحمل الإضافي للبروكسي الذي ستضيفه fcc. نتائج تعيين فئات Claude الثلاث لنماذج محلية كالآتي (Apple Silicon، مطالبة متطابقة، حد 64 رمزاً):

الشكل 2. التأخر ومعدل المعالجة عند توجيه فئات Claude إلى نماذج Ollama المحلية. qwen3:8b المُدرج في مسار opus نموذج تفكير يُصدر رموز استدلال مطوّلة مما يزيد الوقت بشكل ملحوظ.

النموذج الصغير (llama3.2:3b) ينهي استجابته في أقل من 0.5 ثانية، وهو سرعة كافية لحركة مرور بديلة عن Haiku. كذلك qwen2.5:7b عند 0.56 ثانية عملي للاستخدام. في المقابل، استغرق qwen3:8b المُدرج في مسار opus 8.12 ثانية، لأن نموذج التفكير يُصدر أولاً 281 رمز استدلال. معدل المعالجة (34.6 tok/s) طبيعي في حد ذاته، لكن القياس أكد أن توظيف نموذج استدلالي في فئة ثقيلة يُفجّر عدد الرموز ويزيد التأخر المُدرَك بشكل كبير. درس عملي: عند تصميم تعيينات الفئات، ينبغي مراعاة ميل النموذج لتوليد رموز الاستدلال.

التطبيق والدلالات لمنصة ThakiCloud SaaS للذكاء الاصطناعي/تعلم الآلة على Kubernetes

القيمة الحقيقية لهذه الأداة ليست في “المجانية” بل في نمط الاتصال. بمجرد إدراج بروكسي متوافق مع Anthropic كطبقة وسيطة، يمكن إرفاق عملاء تجاريين كـ Claude Code مباشرةً ببنيتنا التحتية.

تُجدول ThakiCloud وحدات GPU باستخدام Kueue وتُقدّم النماذج عبر vLLM على Kubernetes. نظراً لأن vLLM يوفر نقطة نهاية متوافقة مع OpenAI (/v1/chat/completions)، يمكن ربطها بمسار المزود المستضاف ذاتياً في free-claude-code بنفس الطريقة المتبعة مع Ollama أو llama.cpp. أسلوب الاتصال مشترك بين المزودين المستضافين ذاتياً: يُحدَّد عنوان URL الأساسي بنقطة نهاية خدمة vLLM في الكتلة، ويُضاف بادئة المزود إلى معرّف النموذج. تماماً كما تُكتب Ollama بالصيغة ollama/llama3.2:3b، يُضاف النموذج المُقدَّم على vLLM الداخلي لأهداف التوجيه باتباع قاعدة البادئة ذاتها. يُتيح ذلك:

• سيادة البيانات: لا يغادر الكود والمطالبات حدود المستأجر. هذا أمر جوهري في البيئات التنظيمية مثل النشر داخل المنشأة ومتطلبات الامتثال للأجهزة الحكومية.
• تحوّل هيكل التكلفة: تتحوّل فوترة القياس لكل رمز إلى تكاليف GPU ثابتة. كلما ارتفع الاستخدام، تسارعت نقطة التعادل للتقديم الذاتي.
• النشر المتدرج حسب الفئة: يمكن توجيه حركة مرور Haiku الخفيفة إلى نماذج صغيرة والأعمال الثقيلة إلى نماذج أكبر، مما يُحسّن الاستفادة من وحدات GPU. تُقدّم القياسات أعلاه الأرقام المرجعية لهذا النشر المتدرج.

غير أن الأنسب بدلاً من اعتماد هذه الأداة كما هي هو استعارة نمط التوجيه المُتحقَّق منه فحسب. في بيئة متعددة المستأجرين، يجب أن يمتلك البروكسي مصادقة وعزلاً ومراقبةً لكل مستأجر، في حين تفترض واجهة إدارة free-claude-code مستخدماً واحداً في حلقة الاسترداد وهي قاصرة كما هي. الفكرة الكامنة في طبقة التوحيد المتوافقة مع Anthropic تستحق الاستعارة، لكن المصادقة والحصص والتسجيل يجب إعادة تطبيقها وفق معايير بوابتنا.

القيود والاعتراضات

أولاً، المنطقة الرمادية لشروط الخدمة. يعتمد إطار “Claude Code مجاناً” على التوجيه عبر مزودين ذوي فئة مجانية، مما قد يتعارض مع شروط خدمة كل منصة. في البيئات المؤسسية، الاستخدام المشروع والمستدام هو حصراً التوجيه إلى الخلفيات المملوكة (النماذج المُقدَّمة ذاتياً). هذا هو سبب تأكيد هذا المقال على مسار الاستضافة الذاتية فحسب.

ثانياً، تثبيت الإصدار المتعجّل. يمنع الاشتراط الصارم بـ Python 3.14 التشغيلَ فوراً في البيئات التي تفتقر إلى وقت تشغيل مستقر كما رأينا. مع الأخذ بعين الاعتبار تكلفة ومخاطر ترقية صور حاويات الإنتاج إلى 3.14، فإن إدراج هذه الأداة مباشرةً في خط أنابيب النشر في الوقت الراهن ينطوي على عبء مفرط.

ثالثاً، لا يُضمن تكافؤ الجودة. استبدال Opus أو Sonnet من Claude بنماذج مختلفة لا يُبقي جودة البرمجة على حالها. التوجيه خيار يكسب فيه تكاليف أقل وسيادة بيانات مقابل التنازل عن جودة الاستجابة؛ وأي حركة مرور تُوجَّه إلى أي مكان يجب تحديده بالقياس وفق درجة صعوبة المهمة.

رابعاً، قياسات هذا التقرير هي أرقام استدعاء مباشر للخلفية دون المرور بالبروكسي. لا يشمل ذلك الحمل الإضافي للتوحيد والتوجيه في fcc. متى توافرت بيئة Python 3.14 المستقرة، أخطط لإعادة قياس التأخر ذهاباً وإياباً عبر البروكسي وإضافته تكملةً لهذه النتائج.

خلاصة القول، free-claude-code محفوف بالمخاطر إذا استُهلك بوصفه “اختراقاً مجانياً”، لكنه نقطة انطلاق ممتازة كمرجع مفتوح المصدر لأنماط التوجيه المتوافقة مع Anthropic عند تصميم ربط العملاء التجاريين ببنية الاستدلال المستضافة ذاتياً.

المصادر

• GitHub: Alishahryar1/free-claude-code (MIT, 36.7k stars, v2.3.14)
• بيانات القياس: استدعاءات مباشرة لنقطة النهاية المتوافقة مع OpenAI في Ollama المحلي (llama3.2:3b وqwen2.5:7b وqwen3:8b، Apple Silicon)
• مقال ذو صلة: مدونة ThakiCloud التقنية “توجيه Claude Code إلى النماذج الداخلية - claude-code-router”

صورة تجسّد هيكل متعدد اللاعبين حيث يعمل Claude واحد في كل قناة Slack مع جميع أعضاء الفريق.

نظرة عامة

تتحول ساحة منافسة الذكاء الاصطناعي المؤسسي من روبوتات المحادثة المنفردة إلى طبقة التعاون. إذ لا يعمل الناس في نافذة محادثة فردية، بل في قنوات مشتركة تضم الفريق بأكمله؛ ولكي يُستخدم الذكاء الاصطناعي كزميل حقيقي، يجب أن يكون حاضراً داخل تلك القنوات. في 23 يونيو 2026، أقدمت Anthropic على أجرأ خطوة في هذا الاتجاه.

أعلنت Anthropic عن Claude Tag ليحل محل تطبيق Claude in Slack الحالي — وهو وكيل ذكاء اصطناعي مشترك مدمج مباشرة في Slack التابعة لـ Salesforce، ومتاح كإصدار تجريبي وتجريبي للأبحاث لعملاء Claude Enterprise وTeam. يعمل على نموذج Claude Opus 4.8 الذي أُطلق حديثاً، ويمكن لأي شخص في القناة كتابة @Claude لتفويض مهام غير متزامنة كإنشاء طلبات السحب، واستخراج مقاييس المبيعات، وتحليل البيانات.

تتناول هذه المقالة Claude Tag من منظور معمارية الوكلاء لا من زاوية الأسعار أو العبارات التسويقية. نستعرض ما يميّزه عن تكاملات روبوتات المحادثة التقليدية، وما يغيّره تعدد اللاعبين والسلوك الاستباقي على مستوى العمليات، وما يمثله ذلك من انعكاسات على ThakiCloud بوصفها منصة وكلاء متعددة المستأجرين مبنية على K8s.

ما الذي جرى؟

تتمحور الإعلانات حول أربعة محاور:

أولاً، من روبوت محادثة منفرد إلى زميل متعدد اللاعبين. كانت التكاملات السابقة تعتمد نموذج 1:1 حيث يرتبط كل مستخدم بنسخة ذكاء اصطناعي منفصلة. أما Claude Tag، فيوجد Claude واحد داخل قناة Slack واحدة، ويتفاعل مع جميع أعضائها. يمكن لأي شخص رؤية ما يعمل عليه Claude، والانضمام إلى المحادثة من حيث توقف الآخر.

ثانياً، السلوك الاستباقي (ambient). لا ينتظر Claude Tag التعليمات فحسب. فبتفعيل السلوك الاستباقي، يسحب المعلومات ذات الصلة بنشاط من القنوات التي يراقبها ومن الأدوات المتصلة بها، ويتابع تلقائياً الخيوط والمهام التي خمدت دون حل.

ثالثاً، التعلم عبر الزمن. يتابع القناة ويراكم سياق ما يجري فيها من عمل. لا يحتاج المستخدم إلى شرح المشروع من البداية في كل مرة — القناة نفسها هي الذاكرة طويلة الأمد للوكيل.

رابعاً، الوصول إلى الأدوات المؤسسية والتحكم في نطاق البيانات. يصل Claude Tag إلى الأدوات المؤسسية المتصلة مع إمكانية التحكم في نطاق الوصول إلى البيانات. بوصفه وكيلاً يتعامل مع أدوات العمل الفعلية لا مجرد الردود على الرسائل، تُعدّ حدود الصلاحيات عنصراً جوهرياً في المنتج.

أفصحت Anthropic عن أن نحو 65% من شيفرة فريق منتجاتها يتولد حالياً عبر الإصدار الداخلي من Claude Tag، وأن النمط ذاته يمتد إلى تحليل البيانات وحل تذاكر الدعم.

كيف يعمل؟

يمكن تصوير Claude Tag من الناحية التشغيلية على النحو التالي:

flowchart TB
    subgraph CH["قناة Slack (Claude مشترك واحد)"]
        U1["عضو الفريق أ"] -->|تفويض @Claude| C["Claude Tag (Opus 4.8)"]
        U2["عضو الفريق ب"] -->|متابعة| C
        U3["عضو الفريق ج"] -.->|مراقبة| C
    end
    C -->|مراقبة ambient| MEM["السياق المتراكم للقناة (ذاكرة طويلة الأمد)"]
    C -->|صلاحيات النطاق| TOOLS["الأدوات المؤسسية<br/>GitHub · البيانات · أنظمة المبيعات"]
    C -->|متابعة استباقية| TASK["الخيوط المتوقفة · المهام غير المحلولة"]
    MEM --> C

النقطة الجوهرية هنا أن Claude يحتفظ بـالحالة المشتركة للقناة كجهة واحدة. بخلاف روبوتات المحادثة الفردية التي تحتفظ كل منها بسياق محادثتها الخاص، يدمج Claude Tag سير عمل القناة بأكملها في سياق واحد. هذا هو السبب في أن أحداً يمكنه الاستمرار في عمل بدأه شخص آخر. في الوقت ذاته، يتحد هذا السياق المتكامل مع صلاحيات نطاق الوصول إلى الأدوات المؤسسية، ليكتمل حلقة الوكيل القائمة على “المراقبة + الذاكرة + الإجراء الاستباقي + تنفيذ الأدوات” داخل مساحة التعاون.

لماذا يهمنا هذا؟

يتحول Slack تدريجياً إلى ميدان المنافسة الرئيسي للذكاء الاصطناعي المؤسسي. أضافت Salesforce في مارس 30 قدرة وكيل إلى Slackbot، وأطلق OpenAI Workspace Agents في أبريل. يتوقع Gartner أن 40% من تطبيقات المؤسسات ستدمج وكلاء ذكاء اصطناعي متخصصة في المهام بحلول نهاية 2026. Claude Tag هو إعلان من Anthropic بأنها ستسيطر مباشرةً على طبقة التعاون.

يدعم حجم رأس المال هذه الجرأة. جمعت Anthropic مؤخراً 65 مليار دولار في جولة Series H بتقييم ما بعد الاستثمار 965 مليار دولار، متجاوزةً معدل إيرادات سنوياً يبلغ 47 مليار دولار[تقديري]، منها أكثر من 2.5 مليار دولار تُسهم بها أداة المطورين Claude Code. بمعنى آخر، Claude Tag هو المنتج الذي ترسّخ به الشركة توجهها نحو “إخراج الذكاء الاصطناعي من نافذة المحادثة ليعيش داخل سير عمل الفريق”. وأعلنت Anthropic عن خطط لتوسيع Claude Tag ليشمل Microsoft Teams والبريد الإلكتروني وأدوات إدارة المشاريع الأخرى خلال الأسابيع المقبلة.

منظور ThakiCloud: مرآة منصة الوكلاء متعددة المستأجرين

تسعى ThakiCloud إلى بناء منصة SaaS للذكاء الاصطناعي والتعلم الآلي تشغّل وكلاء متعددي المستأجرين على K8s. يعرض Claude Tag بصيغة منتج تجاري المشكلات ذاتها التي يجب أن نحلّها. نرصد ثلاث نقاط جوهرية:

أولاً، إدارة الحالة المشتركة والذاكرة طويلة الأمد. يرتبط التصميم القائم على وكيل واحد يحتفظ بسياق متراكم لكل قناة ارتباطاً مباشراً بمشكلة عزل ذاكرة الوكيل وإدامتها لكل مستأجر (أو مساحة عمل) في بيئة متعددة المستأجرين. من يحق له الوصول إلى تلك الذاكرة؟ هل يحتفظ السياق بقيمته عند تغيُّر الأشخاص؟ هل تتجاوز الذاكرة حدود المستأجر؟ كل هذه قرارات تصميم في المنصة. Claude Tag مثال على رفع هذه القرارات إلى سطح المنتج.

ثانياً، صلاحيات النطاق هي الثقة بعينها. حين يتعامل الوكيل مباشرةً مع الأدوات المؤسسية، يصبح “ما يُمنع من فعله” أكثر أهمية من “ما يستطيع فعله”. هذا بالضبط سبب تأكيد ThakiCloud على الاستضافة المحلية والمنطقة الإقليمية وself-hosting. التحدي الجوهري هو تمكين العملاء من الاستفادة من استباقية الوكيل دون أن يفقدوا السيطرة على بيانات مؤسساتهم. بالنسبة للعملاء الذين يجدون في التفويض الدائم للذاكرة المؤسسية لسحابة بائع واحد عبئاً، تمثّل منصة الوكلاء الذاتية المعزولة بديلاً واضحاً.

ثالثاً، التحكم في تكلفة الاستباقية. المراقبة الاستباقية قوية، لكنها تُغير كثيراً في استهلاك الرموز وملامح الفواتير. لتوفير وكلاء استباقيين في منصة متعددة المستأجرين، لا بد من حلقة تُمكّن من تحديد مستوى الاستباقية والحد الأقصى للميزانية لكل مستأجر، وقياس التكلفة الفعلية في جميع الأوقات. تجربة ThakiCloud في الجمع بين جدولة GPU المبنية على Kueue وقياس التكاليف تشكّل نقطة تمايز تحديداً هنا — الانتقال من مجرد “تشغيل الوكيل الاستباقي أو إيقافه” إلى معالجة “درجة استباقيته” كمتغير تشغيلي يُدار بجانب التكلفة.

القيود والحجج المضادة

Claude Tag ليس الحل الفوري الأمثل لكل مؤسسة. ثمة مخاطر ينبغي لقادة التقنية المؤسسية أخذها بعين الاعتبار قبل التبني.

أولاً، المراقبة غير المتزامنة المستمرة قد تُغير هيكل استهلاك الرموز والفواتير بصورة جذرية. وكيل يعمل دائماً يولّد تكاليف دون أن يستدعيه المستخدم صراحةً — وهذا عبء على المؤسسات التي تريد فواتير متوقعة.

ثانياً، التفويض الدائم للذاكرة المؤسسية إلى ذكاء اصطناعي بائع واحد يرفع ارتباطاً بالمنصة والاعتماد على البائع بصورة كبيرة. حين تصبح سياقات القنوات أصولاً، يأتي معها خطر تقييد تلك الأصول في بنية تحتية بائع محدد.

ثالثاً، التوازن بين الاستباقية والسيطرة. السحب الاستباقي للمعلومات والمتابعة التلقائية مريحان، لكن أخطاء الحكم السياقي أو التدخل المفرط قد يعيقان التعاون. وحتى مع توافر التحكم في نطاق البيانات، تظل السلامة رهينة بكيفية تحديد المؤسسة لحدود الصلاحيات وتدقيقها فعلياً. أخيراً، ينبغي تذكّر أن الإصدار في مرحلة التجريبي وتجريبي الأبحاث. القدرات المُعلنة وأرقام كـ 65% مقيّسة ببيئة Anthropic الداخلية، ولا يوجد ضمان بأنها تتكرر بالقدر ذاته في أعباء عمل المؤسسات العامة.

المصادر

• Anthropic Launches Claude Tag to Turn Slack Channels into Agentic AI Workspaces (Techstrong.ai, 2026-06-23)
• Anthropic launches Claude Tag, replacing its Slack app with a persistent AI teammate (VentureBeat, 2026-06-23)
• Introducing Claude Tag (Anthropic الإعلان الرسمي)

نظرة عامة

أثار اهتماماً واسعاً عرضٌ تجريبي يُظهر تشغيل نموذج MoE كبير في 16 جلسة متزامنة على جهاز صغير يُوضع على المكتب. يتعلق الأمر بنموذج Gemma-4-26B-A4B-NVFP4 الذي أصدرته NVIDIA، إذ يعمل على جهاز DGX Spark واحد (128 جيجابايت من الذاكرة الموحدة) بتوازي 16 ضعفاً، محققاً نحو 18 رمزاً في الثانية لكل تدفق وما يزيد على 300 رمز في الثانية إجمالاً. وقد أشار صاحب العرض إلى أن التزامن العالي جداً جعل من الصعب إظهاره بصرياً فاضطر إلى تقديمه برمجياً، مؤكداً إمكانية الوصول إلى 32 ضعفاً وأن flashinfer لم تُطبق بعد في هذه المرحلة.

ثمة نقطتان جوهريتان نود تسليط الضوء عليهما. الأولى: هذا ليس نموذجاً خفيف الوزن من نوع E2B أو E4B يعمل على الحواسيب المحمولة، بل هو نموذج Gemma MoE كبير يبلغ مجموع معاملاته 25.2 مليار معامل. الثانية: ما يجعل هذا ممكناً هو التقاء ثلاثة عوامل: تكميم NVFP4 رباعي البت، وصغر المعاملات النشطة في MoE، وسعة الذاكرة الموحدة الكبيرة في DGX Spark.

تُدير ThakiCloud منصة لتقديم نماذج اللغة الكبيرة بصورة متعددة المستأجرين فوق Kubernetes. لذا فإن سؤال “كم طلباً متزامناً يمكن استقباله على جهاز خاص صغير واحد؟” ليس مجرد عرض مثير للاهتمام، بل هو سؤال مباشر يتعلق بنموذج التكلفة. يُرتب هذا المقال الحقائق التقنية للنموذج، ويفصل بين أداء التدفق المفرد والتزامن، ويناقش بصدق ما إذا كان DGX Spark يوفر قيمة حقيقية مقارنة بوحدات Blackwell الأخرى، فضلاً عن تحديد مدى صلاحية هذا النموذج لمنظومة المهارات لدينا.

ما الذي قدمه العرض التجريبي؟

يمكن تلخيص ادعاءات العرض الأصلي (تغريدة فريق Google Gemma) على النحو التالي:

• الجهاز: جهاز DGX Spark واحد، ذاكرة موحدة 128 جيجابايت (GB10 Grace-Blackwell)
• النموذج: nvidia/Gemma-4-26B-A4B-NVFP4
• التزامن: 16 ضعفاً متوازياً، بمعدل نحو 18 رمزاً/ثانية لكل تدفق ونحو 300 رمز/ثانية إجمالاً
• قابلية التوسع: ممكنة حتى 32 ضعفاً، لكنه عُرض بـ 16 ضعفاً لاعتبارات وضوح الشاشة
• هامش التحسين: flashinfer لم تُطبق بعد، مما يعني إمكانية تحسين الأداء لاحقاً

نوضح هنا نقطة يسهل إساءة فهمها: “18 رمزاً/ثانية لكل تدفق” هي القيمة عند تشغيل 16 تدفقاً متزامناً، وتدفق واحد وحيد يعطي أداءً أسرع. سيتم تناول المقايضة بين التزامن والتأخير المفرد بالأرقام الفعلية في قسم لاحق.

الحقائق التقنية لنموذج Gemma-4-26B-A4B-NVFP4

النموذج الذي رفعته NVIDIA هو نسخة مُكممة بتقنية NVFP4 من نموذج gemma-4-26B-A4B-it الخاص بـ Google DeepMind، وذلك باستخدام NVIDIA Model Optimizer. المواصفات الرئيسية وفقاً لبطاقة النموذج:

ما هو NVFP4 ولماذا يستلزم Blackwell؟

NVFP4 هو تنسيق نقطة عائمة رباعي البت تُعجله NVIDIA بالجهاز في جيل Blackwell. خلافاً لتكميم INT4 الذي يقطع الأوزان إلى أعداد صحيحة رباعية البت فحسب، يعتمد NVFP4 على مقياس FP8 لكل كتلة صغيرة (micro-scaling)، مما يتيح تقليص الذاكرة المعادل لأربعة بتات مع الحفاظ على دقة عالية.

يظهر الأثر بوضوح في متطلبات الذاكرة: تحميل 25.2 مليار معامل بتنسيق BF16 يتطلب نحو 50 جيجابايت، بينما يُقلص NVFP4 الأوزان إلى 14-16 جيجابايت تقريباً. في DGX Spark بذاكرته الموحدة البالغة 128 جيجابايت، يعني الاحتفاظ بالأوزان في 16 جيجابايت أن ما يزيد على 100 جيجابايت تبقى متاحة بالكامل لذاكرة التخزين المؤقت KV Cache. هذا الهامش الواسع هو ما يتيح التزامن من 16 إلى 32 ضعفاً واستيعاب سياقات طويلة تصل إلى 256 ألف رمز.

غير أن تسريع جهاز NVFP4 مقصور على Blackwell حصراً. الأجيال السابقة كـ Hopper (H100) وAda (RTX 4090) تفتقر إلى مسار Tensor Core الخاص بـ NVFP4، مما يعني عدم الاستفادة الكاملة من هذا التنسيق. بمعنى آخر، هذا النموذج مبني عملياً “للتشغيل على Blackwell”.

المعايير القياسية: هل خسارة الدقة في NVFP4 مقبولة؟

تقدم بطاقة النموذج مقارنة جنباً إلى جنب بين نسخة NVFP4 والنموذج الأساسي غير المُكمم:

جميع المعايير الأربعة في فارق أقل من 1% مقارنة بالأساس. تتفوق نسخة NVFP4 قليلاً في AIME وIFBench، لكن يُفضل قراءة هذا الفارق باعتباره ضمن نطاق التشتت القياسي. الخلاصة: “ضغط الأوزان إلى أربعة بتات يحافظ على الجودة فعلياً”، وهذا ما يُميز NVFP4 عن INT4. مع ذلك، يُنصح بإجراء تقييم مستقل على مجموعات بيانات المهام العربية وغيرها من اللغات، إذ لا تظهر هذه في المعايير العامة المنشورة.

الأداء الفعلي: التدفق المفرد مقابل التزامن

قد تُوهم “18 رمزاً/ثانية لكل تدفق” في العرض بالبطء. الفصل بين التدفق المفرد والتزامن ضروري. بالاستناد إلى تقارير المجتمع من قياسات على DGX Spark:

• التدفق المفرد الأساسي: نحو 32 رمزاً/ثانية (بدون MTP، بإعداد 64 ألف رمز)
• التدفق المفرد + MTP (التنبؤ بعدة رموز): نحو 55-61 رمزاً/ثانية (بإعداد 32 ألف رمز، أعلى أداء للاستجابات القصيرة إلى المتوسطة و JSON المنظم)
• 16 تدفقاً متزامناً: نحو 18 رمزاً/ثانية لكل تدفق ونحو 300 رمز/ثانية إجمالاً
• معالجة السياق الطويل: نحو 11.9 ثانية لمدخل 25 ألف رمز، ونحو 28.6 ثانية لمدخل 50 ألف رمز (بإعداد 64 ألف رمز)

تبرز هنا حقيقتان:

الأولى: فك ترميز MoE محدود بالنطاق الترددي للذاكرة. صحيح أن المعاملات النشطة لكل رمز تبلغ 3.8 مليار فقط مما يُقلل العمليات الحسابية (FLOPs)، لكن كل رمز يتطلب قراءة أوزان الخبراء النشطين من الذاكرة. النطاق الترددي لذاكرة LPDDR5X الموحدة في DGX Spark أدنى من HBM في مراكز البيانات، وهذا ما يُفسر سبب كون سرعة التدفق المفرد “متحفظة لجهاز Blackwell”. فائض قدرة FP4 الحسابية يصطدم بسقف النطاق الترددي.

الثانية: القوة الحقيقية لهذا الجهاز ليست في التأخير المفرد بل في الإنتاجية المتزامنة. الحصول على 300 رمز/ثانية إجمالاً مع تشغيل 16 ضعفاً يعني أن طلبات متعددة تتشارك النطاق الترددي معاً لرفع الكفاءة. الهامش الواسع للذاكرة الموحدة يتيح KV Cache سخياً، وهذا ما يُمكن هذا السيناريو. باختصار: الجهاز مُصمم لـ “استجابات كافية لعدة وكلاء ومستخدمين في آن واحد” لا لـ “استجابة سريعة لشخص واحد”.

flowchart LR
    subgraph Spark["DGX Spark · 128GB Unified Memory"]
      W["NVFP4 Weights<br/>~16GB"]
      KV["KV Cache Pool<br/>~100GB+ headroom"]
    end
    R1["Request 1"] --> Spark
    R2["Request 2"] --> Spark
    R3["..."] --> Spark
    R16["Request 16"] --> Spark
    Spark --> O["~18 tok/s per stream<br/>~300 tok/s total"]

مراجعة صريحة 1: هل يوفر DGX Spark قيمة حقيقية مقابل التكلفة؟

الخلاصة المباشرة: “قيمة استثنائية من حيث السعة التخزينية للجيجابايت، وقيمة متوسطة من حيث التأخير لكل رمز”. حتى ضمن جيل Blackwell الواحد، تتباين طبيعة كل شريحة.

أهم خانة في هذا الجدول ليست السعر بل “حالة NVFP4 MoE”، لأنها حيث تنفصل الحسابات النظرية عن الواقع.

• نظرياً، RTX 5090 هو الأكثر كفاءة من حيث التكلفة لكل رمز. نطاقه الترددي يبلغ 6.6 أضعاف DGX Spark (1,792 مقابل 273 جيجابايت/ث)، وفك ترميز MoE يعتمد على النطاق الترددي، مما يعني أن السقف النظري يتبع هذه النسبة مباشرة. قراءة 16 جيجابايت من الأوزان بـ 273 جيجابايت/ث تُعطي نظرياً نحو 170 رمزاً/ثانية، بينما بـ 1,792 جيجابايت/ث تصل إلى نحو 1,100 رمز/ثانية. والسعر هو نصف الثمن، فالحساب البسيط يُرجح الـ 5090 بمقدار 5 إلى 6 أضعاف.
• لكن في الواقع، نواة NVFP4 MoE معطوبة حالياً على شرائح Blackwell الاستهلاكية والمهنية (SM120). مشكلة NVFP4 GEMM في flashinfer على SM120 (#2577) مفتوحة، مما يجعل تشغيل هذا النموذج رباعي البت على RTX 5090 وRTX PRO 6000 أمراً صعباً حالياً. الأفضل على الورق هو عملياً “لا يعمل الآن”.
• لذا يبقى DGX Spark (SM121) الجهاز الاستهلاكي الوحيد الذي يعمل عليه NVFP4 MoE فعلاً. النطاق الترددي أدنى والسرعة متحفظة، لكن “صندوق MoE رباعي البت يعمل اليوم” هو السبب الحقيقي لصدور العرض من DGX Spark.
• Blackwell لمراكز البيانات (B200, SM100) مدعوم بالكامل عبر TRT-LLM وflashinfer NVFP4، لكن فارق التكلفة شاسع. للاستضافة الذاتية المستمرة يُفضل امتلاك الجهاز، أما لتحميل الأعباء المتفرقة ومتعددة المستأجرين فـ B200 سحابياً أجدى.

خلاصة: DGX Spark ليس “آلة شراء أداء الطليعة”، بل هو “آلة شراء ذاكرة كبيرة وتزامن عالٍ بشكل يعمل اليوم، للتطوير والنمذجة الأولية والخدمة المتزامنة الصغيرة”. حين تُصلح مشكلة SM120، ستنزل الكفاءة النظرية لـ RTX 5090 إلى الواقع، لكن حتى ذلك الحين موقع DGX Spark واضح. العرض المبهر بتوازي 16 ضعفاً مبني بالضبط على هذه الميزة.

مراجعة صريحة 2: ما المهام الملائمة لهذا النموذج؟

حين يتضح طابع الكفاءة، تتضح المهام الملائمة.

المهام الأنسب

• تشغيل عدة وكلاء متزامنين: نمط 16 إلى 32 عاملاً يعملون معاً بسرعة معقولة. الإنتاجية الإجمالية هي نقطة القوة.
• أعباء المخرجات المنظمة: تدعم بطاقة النموذج استدعاء الدوال ومخرجات JSON المنظمة، و MTP يُحقق أعلى سرعة للاستجابات القصيرة إلى المتوسطة والـ JSON التحكمي. مناسب للتصنيف والتسمية والاستخراج المنظم.
• معالجة السياق الطويل: سياق 256 ألف رمز مع KV Cache واسع يمنح مرونة في تلخيص الوثائق الطويلة وحقن سياق RAG.
• النمذجة الأولية في البيئات الخاصة: تجربة خدمة نماذج MoE الكبيرة دون وحدات GPU لمراكز البيانات.

المهام الأقل ملاءمة

• محادثة فردية منخفضة التأخير: سرعة التدفق لكل مستخدم واحد أبطأ من بطاقات GDDR7. إن كان الهدف “أسرع استجابة لشخص واحد”، فهذا الجهاز ليس المناسب.
• استدلال أحادي عالي الصعوبة: المهام التي تتطلب أعلى دقة ممكنة تستفيد من نماذج أكثر كثافة أو أكبر حجماً. 26 ملياراً هي فئة الإنتاجية لا الدقة القصوى.

دليل التشغيل

الطريق الموصى به في بطاقة النموذج هو vLLM. ثمة قيود موثقة حالياً:

• vLLM TP=1 فقط: البنية الحالية تدعم التوازي التنسوري 1 فقط (GPU واحد/جهاز واحد).
• محلل Gemma 4 مخصص: يلزم تحديد --tool-call-parser gemma4 و--reasoning-parser gemma4 عند التشغيل لتحليل مخرجات استدعاء الدوال والاستدلال بشكل صحيح.
• flashinfer غير مُطبقة: كما أشار صاحب العرض، لم تُستخدم flashinfer بعد. تطبيق تحسينات نواة الانتباه سيضيف هامشاً إضافياً من الأداء.

يستلزم التشغيل نظام Linux وجهاز Blackwell (Tensor Cores لـ NVFP4). الأجيال السابقة لا تستفيد من ميزة التسريع رباعي البت.

دلالات التطبيق على منصة ThakiCloud K8s للذكاء الاصطناعي

تُدير ThakiCloud منصة متعددة المستأجرين تستخدم Kueue لإدارة حصص GPU وvLLM لخدمة النماذج. ثمة ثلاثة دلالات رئيسية يمنحها هذا العرض لنموذج تشغيلنا:

مرشح للاستضافة الذاتية في طبقة العمال. انضباطنا في التكاليف يتبع قاعدة “العمال بالرخيص، والبوابات بالغالي”. مهام العمال كالاستكشاف والتصنيف والتلخيص والاستخراج المنظم لا تستلزم النماذج الأعلى رتبة. NVFP4 26B بإنتاجيته الإجمالية البالغة 300 رمز/ثانية ودعمه لاستدعاء الدوال ومخرجات JSON، مرشح مناسب لتشغيل عمال متعددين محلياً في آن واحد. إبقاء مراحل التحقق والتوليف والأحكام المعمارية للنماذج الأعلى رتبة يُقلص تكلفة الرموز هيكلياً.

الذاكرة الموحدة الكبيرة تُبسط ميزانية KV لمتعدد المستأجرين. مع أوزان تبلغ 16 جيجابايت في ذاكرة موحدة 128 جيجابايت، يتجاوز هامش KV Cache 100 جيجابايت. في البيئات متعددة المستأجرين، KV Cache هو أول مورد ينضب، وهذا الهامش يتيح تحديد حدود تزامن سخية لكل مستأجر.

مرجع لاقتراحات الخوادم الخاصة والامتثال. رخصة Apache 2.0 والتشغيل على جهاز واحد تكوين قابل للاقتراح مباشرة على عملاء القطاع العام والمالي الذين يشترطون الاستضافة الذاتية. إمكانية تشغيل MoE كبيرة على صندوق صغير دون GPU لمراكز البيانات توفر مساراً عملياً للبيئات التي تحظر نقل البيانات خارجياً أو تستلزم امتثالاً أمنياً صارماً.

مراجعة صريحة 3: ما حدود استخدام هذا النموذج في منظومة مهاراتنا؟

معظم مهارات ThakiCloud ووكلائها تعتمد النماذج الأعلى رتبة كـ Opus/Sonnet أساساً. إذن أين يمكن إدراج NVFP4 26B؟ بصدق:

• قابل للاستبدال فوراً (طبقة العمال): قراءة الملفات وتلخيص Grep، التصنيف وتطبيع Enum (عمال حتمية التنسيق)، توليد المسودات الأولى، استخراج الأخبار والوثائق. مهام read-only والمهام المنظمة التي يتولاها حالياً haiku/sonnet كعمال فرعيين يمكن نقل جزء كبير منها إلى 26B محلياً.
• ممكن بشروط (مع تعزيز التحقق): عمال استدعاء أدوات الوكيل. دعم استدعاء الدوال ومخرجات JSON يجعله صالحاً كعامل طرفي في حلقات استدعاء الأدوات. لكن نتائج fan-out يجب دائماً إغلاقها بـ adversarial verify من نموذج أعلى (منع تراكم هلوسات العمال).
• غير موصى به (طبقة البوابات): الاستدلال المعماري متعدد الخطوات، وأحكام التوليف والتحقق، وتوليد المحتوى عالي المخاطر. المراحل التي تتطلب أعلى دقة ممكنة تبقى على Opus.

الجوهر هو مطابقة رتبة النموذج مع رتبة المهمة. رؤية NVFP4 26B كـ “بديل لـ Opus” تُخيب الآمال، لكن رؤيته كـ “مرشح للاستضافة الذاتية في طبقة عمال haiku/sonnet” تجعله بطاقة قادرة على تغيير هيكل التكاليف. هذا بالضبط ما تقوله قاعدة توجيهنا: الاستكشاف بالرخيص، والبوابات بالغالي.

القيود والنقد

للتوازن، نذكر الجوانب التي تستحق المراجعة:

• سرعة التدفق المفرد متحفظة. بطء النطاق الترددي يجعله أبطأ من بطاقات GDDR7. أعباء العمل الحساسة للتأخير تستلزم إعادة النظر في اختيار الجهاز.
• أرقام العرض مرتبطة بالإعداد. 18 رمزاً/ثانية و300 رمز/ثانية هي قيم لتزامن 16 ضعفاً وإعداد محدد، وتتفاوت حسب طول المدخل والمخرج وتطبيق MTP. يجب إعادة القياس على أعباء العمل الخاصة بك.
• vLLM TP=1 وغياب flashinfer قيود اللحظة الحالية. إضافة التحسينات قد تُغير الأرقام، لذا يُقرأ هذا المقال كـ “لقطة الحال”.
• تعقيد تشغيل MoE. رغم أن المعاملات النشطة 3.8 مليار، تبقى الأوزان الكاملة في الذاكرة، وتوجيه الخبراء يؤثر على كفاءة الدفعات. “صغير الحجم” تفسير مبسط.
• يلزم التحقق من الاستخدام الفعلي بالعربية والكورية. المعايير العامة تُركز على اللغة الإنجليزية. دقة RAG واستدعاء الأدوات بالعربية تستلزم تقييماً داخلياً منفصلاً.

مع ذلك، يبقى الجمع بين رخصة Apache 2.0 وخدمة MoE كبيرة على جهاز واحد وتزامن مبني على ذاكرة واسعة خياراً جذاباً حقاً للمؤسسات التي تدرس الاستضافة الذاتية. بالنظر إليه من زاوية “شراء ذاكرة رخيصة وتزامن” لا “شراء سرعة الطليعة”، يُقدم DGX Spark + NVFP4 26B قيمة واضحة.

روابط مرجعية

• بطاقة نموذج Gemma-4-26B-A4B-NVFP4 (Hugging Face)
• تغريدة العرض الأصلي (Google Gemma)
• ملخص تشكيلة Gemma 4 الكاملة (مدونة ThakiCloud)
• NVIDIA TensorRT Model Optimizer
• مقدمة NVFP4 (NVIDIA Developer)
• مشكلة NVFP4 GEMM على SM120 في flashinfer #2577
• معايير DGX Spark مع Gemma 4 26B NVFP4 (ai-muninn)

نظرة عامة على Gemma 4

أصدرت Google DeepMind نموذج Gemma 4 في الثاني من أبريل 2026، وهو أذكى عائلة نماذج مفتوحة الأوزان أطلقتها Gemma حتى الآن. وتذكر Google أنه بُني على نفس الأبحاث والتقنيات التي يقوم عليها Gemini 3. بعبارة أخرى، يمكن اعتباره وصفة التدريب وراء نموذج رائد مغلق، مقطّرة إلى تشكيلة مفتوحة الأوزان.

من منظور ThakiCloud، يبرز تغييران في هذا الجيل. أولًا، انتقلت الرخصة إلى Apache 2.0. فخلافًا للأجيال السابقة من Gemma التي كانت تحمل سياسة استخدام منفصلة، يتبنى Gemma 4 رخصة مفتوحة المصدر قياسية ومتساهلة تجاريًا. ثانيًا، لا يُطرح بحجم واحد بل كتشكيلة من خمسة نماذج تمتد من الحافة (الهواتف) إلى وحدة معالجة رسومية واحدة على الخادم. أي أنه يمكنك اختيار هدف النشر حسب فئة الجهاز ضمن نفس عائلة النماذج.

بدلًا من التعمق في نموذج واحد، يهدف هذا المقال إلى مقارنة النماذج الخمسة دفعة واحدة وتوضيح أيها يُختار لكل حالة.

تشكيلة Gemma 4: النماذج الخمسة كاملة

يتكوّن Gemma 4 من النماذج الخمسة التالية، منظمة حسب المعاملات والسياق والوسائط والبنية وفق بطاقة النموذج:

تُخرج النماذج الخمسة جميعها نصًا. ودعم إدخال الصوت متاح فقط في نماذج E2B وE4B و12B، بينما يتعامل 26B و31B مع النص والصورة.

يرمز حرف “E” في E2B وE4B إلى المعاملات الفعّالة (effective). وهو الحجم المبني على معاملات الحوسبة الفعلية باستثناء جدول التضمينات، والقيم الفعّالة هي الرقم الأكثر واقعية عند تقدير ميزانيات الذاكرة والحوسبة. ويستهدف هذان النموذجان مباشرةً الأجهزة الطرفية كالهواتف والحواسيب المحمولة.

جوهر التشكيلة هو تقسيم العمل بين النموذجين الأعلى: 26B A4B (MoE) و31B (Dense).

• 26B A4B هو نموذج Mixture-of-Experts. يضم 25.2B معاملًا إجماليًا لكنه يُفعّل نحو 3.8B فقط لكل رمز. ولا تزال الأوزان الكاملة بحاجة إلى الوجود في ذاكرة VRAM، لكن حوسبة كل رمز (FLOPs) تُحسب على أساس المعاملات النشطة، وهو ما يصب في صالح زمن الاستجابة والإنتاجية. ويناسب الخدمة التي تتطلب تمرير أعداد كبيرة من الطلبات بسرعة.
• 31B Dense نموذج كثيف قياسي يشارك فيه كل معامل في كل رمز. وهو موجّه نحو تعظيم الجودة وملاءمة الضبط الدقيق، وتضع Google نموذج 31B كسقف الجودة في التشكيلة.

ووفقًا لـ Google، احتل 31B المركز الثالث بين النماذج المفتوحة عالميًا على لوحة Arena AI النصية، وحل 26B في المركز السادس، ووصفت التشكيلة بأنها “تنافس نماذج أكبر منها بعشرين ضعفًا”. وتتغير مثل هذه الترتيبات بمرور الوقت، لذا يُفضّل قراءتها كاتجاه (“كثافة ذكاء عالية مقارنة بفئتها”) لا كأرقام مطلقة.

مسار اختيار النموذج

flowchart TD
    A[اختر نموذج Gemma 4] --> B{هدف النشر؟}
    B -->|هاتف/جهاز طرفي| C[E2B / E4B<br/>128K، دعم الصوت]
    B -->|تشغيل محلي بوحدة واحدة| D{الأولوية؟}
    D -->|الإنتاجية/زمن الاستجابة| E[26B A4B MoE<br/>نشطة 3.8B]
    D -->|أعلى جودة/ضبط دقيق| F[31B Dense]
    D -->|متعدد الوسائط + صوت + توازن| G[12B Unified<br/>256K، دعم الصوت]

البنية: الانتباه الهجين وتعدد الوسائط

تتشارك نماذج Gemma 4 الخمسة آلية انتباه هجين. فهي تتناوب بين انتباه النافذة المنزلقة المحلية والانتباه العالمي الكامل. تُعالَج النطاقات القصيرة بثمن زهيد عبر النافذة المنزلقة، بينما يُدرَج الانتباه العالمي دوريًا لالتقاط ترابطات السياق الكامل، بهدف كبح كلفة الذاكرة والحوسبة في السياقات الطويلة. وهذا التصميم هو الخلفية وراء قدرة النماذج العليا (12B/26B/31B) على التعامل مع سياق 256K.

تعدد الوسائط هو الإعداد الافتراضي في هذا الجيل. تستقبل النماذج الخمسة جميعها النص والصورة كمدخل، وتتعامل الفئات الطرفية والمتوسطة (E2B/E4B/12B) مع إدخال الصوت أيضًا. كما أن الميزات الموجهة لسير عمل الوكلاء مدمجة أيضًا. فاستدعاء الدوال، وإخراج JSON المنظّم، وتعليمات النظام الأصلية مدعومة رسميًا، وتؤكد التشكيلة تحسينات في التخطيط متعدد الخطوات والاستدلال المنطقي مقارنة بالجيل السابق. وتاريخ قطع بيانات التدريب هو يناير 2025.

ودعم اللغات واسع: أكثر من 35 لغة جاهزة، وأكثر من 140 لغة على مستوى التدريب المسبق. وتتطلب الجودة الفعلية في التشغيل بالكورية تقييمًا مباشرًا، لكن التغطية متعددة اللغات نفسها واسعة.

المعايير

فيما يلي المعايير التمثيلية التي نشرتها Google لنموذج 31B المضبوط على التعليمات، وفق بطاقة النموذج.

عند حجم 31B بعقدة واحدة، يُعد GPQA Diamond بنسبة 84.3% وMMLU-Pro بنسبة 85.2% في الصدارة بين النماذج المفتوحة الأوزان المماثلة. ومع ذلك، فالمعايير خاصة بالنسخة المضبوطة على التعليمات، ويجب التحقق من الأداء في المهام الواقعية بشكل منفصل. وعلى وجه الخصوص، لا تنعكس مهام الاستدلال والبرمجة بالكورية مباشرةً في المعايير العامة، لذا يُنصح بقياسها بمجموعة تقييم داخلية.

الخدمة والنشر

أمّن Gemma 4 دعمًا واسعًا من منظومة الخدمة منذ الإطلاق. والمسارات الرسمية هي:

• خوادم الاستدلال: vLLM، SGLang، llama.cpp، Ollama، LM Studio، NVIDIA NIM
• الأطر: Hugging Face Transformers / TRL / Transformers.js / Candle، Keras، MaxText، NeMo
• الحافة/على الجهاز: LiteRT-LM، Cactus
• الضبط الدقيق/التكميم: Unsloth، Tunix
• بنية النشر: Docker، Baseten، Google Cloud (Vertex AI)

يمكن تنزيل الأوزان من مجموعة google/gemma-4 على Hugging Face وKaggle وOllama.

متطلبات وحدة المعالجة الرسومية للتشغيل المحلي (تقديري)

دليل تقريبي للنشر المحلي مبني على ذاكرة أوزان BF16 لكل نموذج. هذه تقديرات للأوزان تستثني ذاكرة KV وأعباء وقت التشغيل، لذا اترك هامشًا لطول السياق وعدد الطلبات المتزامنة في النشر الفعلي.

تكمن القوة العملية للتشكيلة في أن النموذجين الأعلى (26B و31B) يتسعان في وحدة معالجة رسومية واحدة بسعة 80GB بدقة BF16. أي أنه يمكنك تشغيل استدلال بمستوى متقدم على خادم واحد دون توازي موترات متعدد العقد، وهو ما يخفض كثيرًا حاجز التبني المحلي. وبميزانية وحدة أصغر، انزل إلى نموذج 12B أو إلى مسار مكمَّم (GGUF Q4/Q8). وبفضل طبيعته MoE التي تحسب فقط 3.8B النشطة، يتمتع 26B بأفضلية في الإنتاجية لكل رمز مقارنة بـ31B Dense عند نفس سعة VRAM.

دلالات للتطبيق على منصة ThakiCloud K8s AI/ML SaaS

تتناغم تشكيلة Gemma 4 جيدًا مع استراتيجية الخدمة متعددة المستأجرين لدى ThakiCloud. وهي مهمة على ثلاث جبهات.

Apache 2.0 يفتح حاجز التبني. إن إطلاق عائلة مفتوحة الأوزان بمستوى متقدم تحت رخصة Apache 2.0 القياسية أمر بالغ الأهمية للتبني المؤسسي والمحلي. إذ يمكنك دمجها في خدمات تجارية دون عبء مراجعة سياسة استخدام منفصلة، وتوزيع نواتج الضبط الدقيق بحرية. وهي عائلة نماذج يمكن اقتراحها مباشرةً على البيئات ذات الامتثال الصارم للترخيص، كالقطاع العام والمالي محليًا، وعلى العملاء المحليين الذين يشترطون الاستضافة الذاتية.

التشكيلة نفسها تتوافق مع توجيه وحدات المعالجة الرسومية متعدد المستأجرين. تدير ThakiCloud حصص وحدات المعالجة الرسومية عبر Kueue وتخدم النماذج عبر vLLM. وتشكيلة Gemma 4 المكوّنة من خمسة نماذج بنية تتيح توجيه فئات النماذج ضمن عائلة واحدة لتلائم احتياجات المستأجرين (حساسية زمن الاستجابة، أولوية الجودة، استدلال الحافة). وجّه المحادثة/التلخيص الخفيف إلى 12B، والدفعات الحرجة للإنتاجية إلى 26B MoE، والاستدلال/البرمجة عالية الصعوبة إلى 31B، فتتمكن من تحسين ميزانية الوحدات حسب فئة المهمة مع الحفاظ على نفس المُرمِّز وصيغة المُوجِّه.

الخدمة بوحدة 80GB واحدة تبسّط نموذج الكلفة. كون 26B و31B يتسعان في وحدة H100/A100 واحدة يبسّط تقدير كلفة مهام وحدات المعالجة الرسومية في Kueue. إذ تختفي أعباء الاتصال وتعقيد الجدولة في توازي الموترات متعدد العقد، فيمكنك التسعير بوضوح بنموذج وحدة مخصصة لكل مستأجر. وميزة 26B MoE بتفعيل 3.8B تعني أنه يستطيع استقبال طلبات متزامنة أكثر على نفس الوحدة، وهو ما يصب أيضًا في صالح كلفة الوحدة لكل طلب.

باختصار، يصلح Gemma 4 كعائلة نماذج مرجعية حين تقترح ThakiCloud نمط تشغيل “تشغيل محلي بوحدة واحدة + توجيه نماذج متعدد المستأجرين” على العملاء.

القيود والاعتراضات

من باب التوازن، تستحق بضع ملاحظات الذكر.

• الفجوة بين المعايير والاستخدام الواقعي. تتركز الأرقام المنشورة على المعايير المضبوطة على التعليمات وباللغة الإنجليزية. ويجب إعادة قياس المهام الكورية، خصوصًا دقة RAG واستدعاء أدوات الوكلاء، بمجموعة تقييم خاصة بك.
• صعوبة تشغيل MoE. نموذج 26B A4B منخفض الحوسبة لكل رمز لكنه يجب أن يُبقي الأوزان الكاملة مقيمة في VRAM، ويؤثر توجيه الخبراء في كفاءة الدُفعات وأنماط الذاكرة. والقراءة المبسطة “إنه صغير لأن النشط 3.8B” قراءة محفوفة بالمخاطر.
• عدم تماثل دعم الصوت. إدخال الصوت موجود فقط في E2B/E4B/12B. وإن أردت أعلى جودة (26B/31B) والصوت معًا، تنشأ مقايضة ضمن التشكيلة.
• قطع التدريب في يناير 2025. المهام التي تحتاج أحدث المعلومات يجب تعزيزها بـRAG وتكامل الأدوات.

ومع ذلك، فإن رخصة Apache 2.0، وجدوى الخدمة بوحدة واحدة، وتشكيلة تصل الحافة بالخادم، أسباب كافية لوضع Gemma 4 على رأس قائمة التقييم لأي مؤسسة تفكر في التشغيل المحلي والاستضافة الذاتية.

المراجع

• مدونة الإعلان الرسمي عن Gemma 4 (Google)
• بطاقة نموذج Gemma 4 (Google AI for Developers)
• وثائق نظرة عامة على نموذج Gemma 4
• مجموعة google/gemma-4 على Hugging Face
• مكتبة Gemma على GitHub من Google DeepMind
• توفّر Gemma 4 على Google Cloud