نظرة عامة

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

Overview

Testing a mobile app requires Android devices. Managing a fleet of physical handsets is a maintenance burden, and installing a heavy emulator locally on every developer’s machine leads to environment drift and poor reproducibility. Those problems multiply when you try to include Android tests in a CI pipeline, because every build node needs a consistent emulator setup.

docker-android (the HQarroum edition) solves this with containers. It packages an Android emulator in a minimal configuration, runs it headlessly, and exposes ADB and screen control over the network. A single container gives you a clean, consistent Android environment in seconds, making it a natural fit for CI/CD and automated testing.

This post verifies docker-android’s architecture and real requirements against the project documentation, then examines how a Kubernetes platform like ThakiCloud can handle this class of device workload. Android emulation is not central to our AI/ML platform, but the question of how to isolate and run privileged containers that need KVM device passthrough and GPU acceleration maps directly onto our infrastructure capabilities.

What docker-android Is

HQarroum’s docker-android bundles an Android emulator, KVM support, and JRE 11 into a compact Alpine-based image (current version 1.1.0). The design intent is clear: expose a fully functional, remotely controllable Android emulator with the smallest possible software footprint. Inside the image live the emulator itself, an ADB server for external access, and QEMU with libvirt.

Key characteristics:

• Minimal footprint: Alpine-based for size optimization. Building without the SDK and emulator produces a much smaller image.
• Configurable: Android version, device type, and image variant are all selectable.
• Built-in port forwarding: Emulator and ADB are exposed through the container network interface.
• Headless: No GUI required, making it suitable for CI farms. Screens can be accessed remotely via scrcpy.
• Reproducibility: The emulator image resets on every restart, so each run starts from an identical state.

The diagram above shows a hypothetical deployment of this container on ThakiCloud Kubernetes. The emulator runs in a pod on a KVM-enabled node with /dev/kvm passed through; the cuda variant is used when GPU acceleration is needed. ADB is exposed as a Service so CI farms and scrcpy clients can reach it.

Installation and Integration

The default build bundles the Android SDK, platform tools, and emulator into the image. Bringing everything up with docker-compose looks like this:

# Basic emulator
docker compose up android-emulator

# GPU acceleration
docker compose up android-emulator-cuda

# GPU acceleration + Google Play Store
docker compose up android-emulator-cuda-store

You can also build directly with Docker:

docker build -t android-emulator .

After building the image, run the container with the KVM device mounted. Using a Play Store image requires the emulator and client to share the same adbkey; generate it with adb keygen adbkey and place it in the ./keys directory.

Image size varies considerably by build variant. The comparison table from the repository documentation:

Images that include the emulator are over 1.5 GB even compressed. When distributing across many nodes, registry bandwidth and node disk capacity both need to be factored in.

Verifying Actual Behavior

This post does not include a verified container boot. Honest record: could not boot here (no Docker daemon on the work host, and macOS provides no /dev/kvm). docker-android requires KVM hardware acceleration, so real operation is only possible on a Linux host or a KVM node with nested virtualization enabled.

What we could verify came directly from the repository documentation. The image size comparison table above reflects numbers stated in the docs; build variants, compose service names, and KVM mount requirements are all documentation-based. Figures such as boot time or test throughput that we could not measure are not included. In an actual deployment, once KVM nodes are available, the right procedure is to measure container boot time, ADB connection latency, and maximum concurrent emulator count directly.

Implications for the ThakiCloud K8s AI/ML SaaS Platform

docker-android is not an AI/ML tool in itself. But the operational requirements it surfaces overlap precisely with what ThakiCloud does well.

First, isolation of device-passthrough workloads. An emulator is essentially a privileged container that requires /dev/kvm. Running this class of workload safely in a multi-tenant Kubernetes environment demands careful node selection, device plugins, and security contexts. ThakiCloud already queues GPUs through device plugins and Kueue; KVM passthrough can be handled with the same pattern.

Second, reproducible test farms. Packaging headless emulators as containers lets you scale clean environments horizontally across as many nodes as you need. Running many parallel Appium UI tests from a CI/CD pipeline is a textbook use case for Kubernetes job scheduling.

Third, looking further ahead, this extends naturally to on-device AI validation. Verifying the behavior of lightweight models or agents running on mobile devices at scale requires a device farm that can spin up many isolated Android environments and run regression tests automatically. This is not a core concern for our platform today, but as our multi-tenant GPU and device orchestration capabilities mature, a mobile AI QA farm of this kind becomes something we could offer on the same infrastructure.

In short, docker-android is not a product we are building, but it is a good case study in taming heavy container workloads that mix privilege, device passthrough, and GPU acceleration on Kubernetes. That is a concrete illustration of the general-purpose K8s orchestration capabilities ThakiCloud emphasizes.

Limitations and Counterarguments

• Heavy dependencies: KVM hardware acceleration is non-negotiable. In environments without nested virtualization support, performance degrades sharply or the emulator does not boot at all. Cloud node selection becomes a hard constraint.
• Image bloat: Emulator-inclusive images are several GB even compressed. Distributing across many nodes accumulates real registry and disk costs.
• Distance from AI/ML relevance: Honestly, this tool is far from the training and inference workloads at the core of our platform. For organizations with no mobile testing demand, the direct value is limited. The value of this post lies not in “the emulator itself” but in “the operational patterns for device-passthrough containers.”
• Security of privileged containers: /dev/kvm access and privileged settings complicate multi-tenant security boundaries. Preserving tenant isolation requires dedicated node pools and strict policies.

docker-android is a powerful tool for mobile test automation and a useful reference for how to handle device-class workloads on Kubernetes. Even before the moment we need it directly, the operational patterns are worth understanding in advance.

Sources

• docker-android (HQarroum): https://github.com/HQarroum/docker-android
• Docker Hub image: halimqarroum/docker-android
• scrcpy (remote screen control): https://github.com/Genymobile/scrcpy
• Original tweet (RT): https://x.com/hjguyhan/status/2069427245295493446

flowchart LR
    CC["Claude Code"] --> CCR["claude-code-router proxy"]
    CCR -->|default / background| GLM["Ollama Cloud · glm-5.2"]
    CCR -->|think / longContext| MM["MiniMax-M2.7 (Anthropic endpoint)"]
    CCR -.->|coding subagent tag| KIMI["Ollama Cloud · kimi-k2.7-code"]
    CCR -.->|onprem option| VLLM["internal vLLM (GLM-air)"]
    AUDIT["daily cost-audit loop"] -->|checks vs Sonnet| CCR

Overview

Claude Code is a terminal-based agentic coding tool. By default it sends requests to the Anthropic API, but not every request carries the same weight. Background summaries, short completions, long-context analysis, and deep refactoring reasoning all demand different model tiers. Push everything to the most expensive model and cost piles up; push everything to the cheapest and quality collapses.

claude-code-router (CCR) solves this with a routing layer. It sits as a proxy between Claude Code and the model backends and forks traffic by request type. This post is not just a concept tour. It is a record of calling three external models to verify behavior, fixing the problems found along the way (a dead API key, thinking-tag leakage), and finally attaching a loop that continuously measures whether the routing is actually cheaper than Anthropic Sonnet.

The governing principle, stated up front: every model routed through CCR is only worthwhile if it is more cost-efficient than Claude Sonnet. Otherwise you lower quality while the money still flows. So we don’t assert. We measure.

Concept diagram

What claude-code-router is

CCR is a proxy that receives Anthropic-format requests, converts them to OpenAI-compatible (or other) formats, and forwards them to the configured provider. It does not modify the Claude Code client. Launch a session with ccr code and that session’s traffic routes through the localhost:3456 proxy.

Key features:

• Per-request-type routing: default, background, think, longContext, webSearch, each mapped to a different model.
• Multi-provider: any OpenAI-compatible endpoint can be registered. Here we use Ollama Cloud and MiniMax.
• Transformers: a converter absorbs each provider’s API quirks. The Anthropic passthrough transformer for native Anthropic endpoints is the key tool in this post.
• Dynamic switching: change models mid-session with /model provider,model.

The verified CCR version is 1.0.62. The config lives at ~/.claude-code-router/config.json, centered on a Providers array and a Router object.

What gets routed - fixed to three models

The model pool is exactly three. Adding more models complicates the routing table and inflates verification cost, so we deliberately narrowed it.

glm-5.2 is the workhorse; only deep reasoning and long context go to MiniMax, and a tough coding turn goes to Kimi.

Verification - we called, we didn’t assume

Before writing any config, we called all three models directly. To avoid inventing numbers we inspected real responses, and three facts surfaced.

First, one Ollama Cloud key covers both GLM and Kimi. Both glm-5.2 and kimi-k2.7-code returned HTTP 200 from https://ollama.com/v1. Ollama Cloud bundles the GLM, Kimi, DeepSeek, and Qwen families behind a single key.

Second, the standalone Kimi key was dead. The standalone Moonshot key in .env returned 401 (Invalid Authentication) against moonshot.ai, moonshot.cn, and the Anthropic-compatible endpoint alike. Fortunately Kimi K2 is reachable as Ollama Cloud’s kimi-k2.7-code, so the dead key was not a dead end.

Third, MiniMax’s endpoint choice decides quality. Called through the OpenAI-compatible endpoint (/v1/chat/completions), the model inlines its reasoning as <think>...</think> tags in the body, and CCR’s conversion layer fails to strip them, so they leak to the user (musistudio/claude-code-router#964). Called through the native Anthropic endpoint (/anthropic/v1/messages), the same model returns clean thinking and text blocks.

That last item was a bug to fix, not a reason to drop MiniMax. The fix is in the config below.

Configuration - secrets out of the repo, config as code

Keys are not hardcoded into the config file. A generator script reads the repo’s .env and writes ~/.claude-code-router/config.json. No keys remain in the repo, and rotating a key just means re-running the script.

The core generated config:

{
  "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"
  }
}

The two lines in the MiniMax provider are what fix the thinking leak. Point api_base_url at the native Anthropic path and use the Anthropic passthrough transformer, and MiniMax responds in Anthropic message format (thinking + text blocks) from the start. Re-checked through the proxy, the response blocks were ["thinking", "text"] with zero <think> leakage.

Reasoning models are slow to emit, so the timeout is generous (1800000ms), and maxtoken reserves output headroom so models like GLM and Kimi, which emit reasoning first, don’t burn the budget before the answer.

Subagents are routed not by config but by a prompt-leading tag. To delegate a hard coding task, prepend <CCR-SUBAGENT-MODEL>ollama,kimi-k2.7-code</CCR-SUBAGENT-MODEL> to the prompt.

Where and how to connect

There is a single connection point. Start a session with ccr code in your working repo, and that session’s main and subagent traffic all route through the proxy per the table above. Native claude still connects directly to Anthropic, so it is unaffected.

# generate config, then start the router
python3 scripts/ccr/gen_ccr_config.py && ccr restart

# start the cost-routed session (this is the connection point)
ccr code

# switch models per task inside the session
/model ollama,kimi-k2.7-code     # hard coding turn
/model minimax,MiniMax-M2.7      # deep reasoning turn
/model ollama,glm-5.2            # everyday coding

For cost efficiency, the recommended pattern is hybrid. Run bulk, repetitive, AFK-style work (test generation, mass refactors, log analysis, translation, code exploration) under ccr code to cut cost, and keep judgment-heavy work (architecture decisions, subtle debugging) on the native claude subscription session. Moving everything to the routed session makes GLM your main loop, which can drop quality on hard tasks.

Cost efficiency - measured against Sonnet, continuously

The reason this setup exists is cost. So instead of claiming “it’s cheaper,” we measure.

Rates verified on 2026-06-24 (USD per 1M tokens):

MiniMax-M2.7 is about 7-8% of Sonnet’s per-token rate, so it is always dramatically cheaper. Ollama Cloud, by contrast, is a flat monthly subscription rather than per-token. Its effective rate is monthly fee / monthly tokens used, and at low volume the $20 flat fee is actually a loss. Using a blended $9/M, you must push roughly 2.2M tokens per month before it beats Sonnet.

That break-even is a measurement target, not a guess. CCR logs record the routed model and input/output tokens per request. A measurement script aggregates these, computing the ratio of actual cost to Sonnet-equivalent cost for per-token models, and projected-monthly Sonnet cost versus the subscription fee for subscription models. Results accumulate in a history file to track the trend, where improvement means the ratio falling over time.

The loop runs once a day via launchd. Claude is not in the loop; only a plain script runs on cron, so the measurement itself costs nothing. If a per-token model is ever found to be more expensive than Sonnet, a Slack alert fires. A subscription model below break-even (under-utilized) is reported but not alerted, to avoid noise during ramp-up.

The action rules are tied to the measurement. If a per-token model’s ratio is 1.0 or higher (more expensive than Sonnet), it comes off the routing immediately. If a subscription model stays under-utilized for months, downgrade the plan or move that route to a cheap per-token model. When prices change, updating the pricing-table file is enough to reflect it in the next run.

ThakiCloud platform perspective

This routing model fits naturally with the infrastructure ThakiCloud already runs.

Code security. In environments where source code cannot leave the building (finance, public sector, healthcare), you only need to switch default in the config above to an internal vLLM endpoint. You keep Claude Code’s usability while prompts and code never leave. The external-model setup here is for cost verification; drop in-house GPU serving into the same skeleton and you have the on-premise version.

Cost control. Per-task routing is per-cost routing. Send high-frequency, low-difficulty requests to cheap models and reserve top-tier models for hard reasoning, and you narrow expensive usage to where it’s truly needed, with the measurement loop proving the effect in numbers.

Policy as code. Providers, routing rules, the pricing table, and the measurement criteria are all managed as text files committed to the repo. Only keys live in .env and the config is reproduced by a generator, so the same setup restores on any machine.

Limits and counterarguments

A router does not solve everything. Several points deserve a cold look.

• Quality gap: routing value depends on backend model quality. Open models do not always match top closed models on complex multi-step refactors or subtle debugging. Hence the hybrid recommendation.
• Tool-call reliability: Claude Code leans heavily on tool calls. The OpenAI-compatible conversion layer can wobble tool-call formats, so it is safe for exploration/summary subagents but warrants gradual rollout for edit/implementation subagents.
• Subscription trap: Ollama Cloud is flat-rate, so low usage is a loss. Below break-even, Sonnet is simply cheaper. The measurement loop watches exactly this point.
• Proxy is a single point of failure: main traffic also passes through CCR, so if the proxy dies the session stalls. The fallback is native claude.
• The “free” framing trap: some forks tout removing telemetry or safety guards as “free.” That is a direction a company cannot endorse. The value we take is not free but control - we decide which request goes to which model, and we measure the cost.

CCR is not a cost-cutting magic trick but a routing control device. Combined with a verified model pool, fixes for real bugs like thinking leakage, and continuous measurement against Sonnet, it becomes a meaningful gain on both security and cost.

Sources

• claude-code-router (musistudio): https://github.com/musistudio/claude-code-router
• MiniMax thinking-leak issue: claude-code-router#964
• MiniMax M2.7 pricing: openrouter.ai/minimax/minimax-m2.7
• Ollama Cloud pricing: ollama.com/pricing
• Claude API pricing: platform.claude.com/docs pricing

An illustration of the DFlash concept: the drafting step shifts from sequential token generation to parallel block proposal.

Overview

In large-scale language model serving, decoding throughput is what determines both infrastructure cost and the latency a user actually feels. As long as a model generates tokens one at a time in an autoregressive loop, there is a structural ceiling: no matter how fast the GPU is, the full model must be traversed once per token. Speculative decoding is the most practical known technique for bypassing this bottleneck, yet earlier drafters were also autoregressive, which kept acceleration ratios in the 2-3x range.

On June 23, 2026, the NVIDIA Technical Blog introduced DFlash, developed by researchers at UC San Diego. DFlash applies a block diffusion model to the drafting stage of speculative decoding, proposing future tokens as a block in one forward pass rather than one at a time. Based on published figures, it achieves up to 6x lossless single-stream speedup and up to 15x serving throughput on NVIDIA Blackwell at the same latency target.

The most operationally significant property is drop-in integration. DFlash is supported by vLLM, SGLang, and TensorRT-LLM. On vLLM, switching from EAGLE-3 to DFlash requires only a config change - no application code modifications. This post explains how DFlash works, what the published benchmarks say, and what it means for ThakiCloud’s K8s-based multi-tenant AI/ML serving platform. All numbers cited here are official figures published by NVIDIA and UCSD. We have not reproduced these results on ThakiCloud hardware, and we address that honestly in a dedicated section.

What the Technology Does

Speculative decoding has two stages. A small draft model proposes future tokens, and a large target model verifies them in parallel, accepting the longest valid prefix. When the draft is correct, a single verification pass through the target model confirms multiple tokens. The problem is that conventional drafters are autoregressive: drafting cost grows linearly with the number of speculative tokens, which caps the throughput gains.

DFlash replaces the autoregressive drafter with a lightweight block diffusion drafter. A block diffusion model denoises a masked block of tokens all at once, combining parallel generation with an autoregressive block structure. DFlash applies this idea only to the drafting stage; verification is still handled by the trusted autoregressive target model. That separation is what preserves output quality. Standalone diffusion LLMs often trail autoregressive models in accuracy and require multiple denoising steps, but in DFlash the draft only needs to be good enough to pass verification - the final output distribution is guaranteed by the target model’s parallel check. The method is therefore lossless.

flowchart LR
    subgraph EAGLE["EAGLE-3 (Autoregressive Drafting)"]
        direction TB
        E1["Token t1"] --> E2["Token t2"] --> E3["Token t3"] --> E4["Token t4"]
    end
    subgraph DFLASH["DFlash (Block Diffusion Drafting)"]
        direction TB
        D0["Masked block"] --> D1["t1 · t2 · t3 · t4 (1 forward pass)"]
    end
    EAGLE --> V1["Target model parallel verification"]
    DFLASH --> V2["Target model parallel verification"]
    V1 --> OUT["Lossless output"]
    V2 --> OUT

The second advantage is drafting cost structure. An autoregressive drafter’s cost scales with the number of speculative tokens, while a diffusion drafter generates all tokens in one parallel pass, so drafting latency stays nearly flat as the block size grows. This allows DFlash to use a deeper, more expressive draft model without increasing latency. In practice, DFlash uses a small 5-layer drafter (8 layers for Qwen3-Coder). That contrasts with earlier diffusion-drafter research (DiffuSpec, SpecDiff-2), which used large 7B-parameter drafters and capped speedup at 3-4x.

DFlash combines three techniques. First, block diffusion drafting predicts multiple future tokens in parallel. Second, target hidden-state conditioning transfers context features from the target model to the drafter via KV injection. Third, verification-friendly training improves the acceptance rate of draft blocks. Together these create the balance of small drafter, parallel block proposal, and lossless verification.

Installation and Integration

DFlash ships checkpoints and framework support together, so adoption requires very little new code. Public checkpoints are available in the z-lab/dflash collection on Hugging Face; 20 checkpoints were available at announcement time. On vLLM, you swap the EAGLE-3 speculative config for the DFlash config with no application refactoring. Below is the vLLM example from the official documentation.

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

Setting method to dflash in --speculative-config and passing the draft checkpoint path is all that changes. Because the flag structure mirrors the existing EAGLE-3 serving setup, you are effectively hot-swapping the speculative decoding method in a running vLLM deployment. SGLang and TensorRT-LLM work the same way, accepting DFlash draft checkpoints through the same speculative decoding API.

The Transformers backend supports Qwen3 and LLaMA-3.1 model families and provides a spec_generate interface that pairs the draft and target models.

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": "How many positive divisors does 196 have?"}]
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)

All code blocks above are cited from official examples published by the NVIDIA Technical Blog and MarkTechPost; they are not output captured from ThakiCloud infrastructure. DFlash throughput numbers were measured on NVIDIA Blackwell (DGX B300, 8 GPUs) with TensorRT-LLM. Our environment does not have those accelerators or checkpoints available, so we have not reproduced the results under identical conditions. All figures below therefore come from clearly attributed public sources; no self-measured numbers are included.

Benchmark Results (Published Figures)

DFlash’s speedup numbers fall into two categories, measured differently, and should be read accordingly.

Lossless single-stream speedup. The UCSD paper reports an average of 4.86x and a peak of 6.08x on MATH-500 for Qwen3-8B greedy decoding on the Transformers backend. Under the same conditions, EAGLE-3 achieves an average of 1.76x at tree size 16 and 2.02x at tree size 60. Task-level figures are shown in the chart below.

The chart visualizes official numbers from the UCSD DFlash paper and does not represent direct ThakiCloud measurements. GSM8K 5.15x, MATH-500 6.08x, AIME25 5.62x, HumanEval 5.14x, and LiveCodeBench 5.51x show particularly large gains on math and code reasoning tasks. MT-Bench, which allows more varied responses, is comparatively lower at 2.75x. This is consistent with the general principle that speculative decoding gains more as output becomes more predictable (higher acceptance rate).

Throughput at a fixed latency target. The 15x figure NVIDIA reports refers to serving gpt-oss-120b on a DGX B300 (8 Blackwell GPUs) with TensorRT-LLM, achieving over 15x the throughput of autoregressive decoding at the 500-600 tokens/second per user operating point. At the same point, DFlash is approximately 1.5x faster than EAGLE-3. In a separate NVIDIA Speed-Bench (latency speedup at the same concurrency), gpt-oss-120b shows DFlash at 2.3x vs. EAGLE-3 at 1.7x, and Llama 3.1 8B Instruct shows DFlash at 2.8x vs. EAGLE-3 at 2.2x. Across tasks the reported range extends to Gemma 4 31B at up to 5.8x (vLLM) and Qwen3 8B at 5.1x (SGLang).

In summary, “6x” is lossless single-request speedup; “15x” is serving throughput when many users are held to the same latency target. The two numbers answer different questions. To estimate what to expect in your own deployment, fix your concurrency and latency target first, then look at the figure for that operating point.

Implications for the ThakiCloud K8s AI/ML Platform

ThakiCloud runs a stack where Kueue schedules GPUs on Kubernetes and vLLM serves models across multiple tenants. DFlash is particularly well-suited to this setup for three reasons.

First, it is a drop-in replacement with low operational risk. If you are already running speculative decoding with EAGLE-3, you can switch method and the draft checkpoint to DFlash and validate it as a canary deployment. Because it is a lossless technique - the API contract and output distribution are unchanged - tenants see the same response content; only throughput and latency improve. An optimization that does not break output consistency is rare and valuable in multi-tenant SaaS.

Second, GPU efficiency directly translates to unit economics. Handling more concurrent requests at the same latency target with the same GPU means lower serving cost per tenant. This matters most in environments where adding capacity is constrained, such as on-premises deployments or domestic-region GPU allocations. It aligns precisely with ThakiCloud’s emphasis on on-premises deployment, cost efficiency, and self-hosting. That said, the 15x figure is a ceiling measured on Blackwell with TensorRT-LLM; expectations should be adjusted for the GPU generation and serving backend actually in use.

Third, the gains are largest on math and code workloads. Internal coding agents, data analysis pipelines, and tool-heavy agent workloads produce structured outputs, so acceptance rates tend to be higher. Tenants running these workloads are likely to see above-average gains from DFlash. Given ThakiCloud’s focus on multi-tenant agent platforms, it makes sense to prioritize DFlash serving profiles for tenants with code and reasoning workloads.

A natural longer-term roadmap: expose speculative decoding method as a per-tenant serving profile in the vLLM Helm chart, and run a background cost measurement loop to track whether token-per-dollar actually improves after DFlash is applied. The principle of measuring rather than assuming applies to inference optimization as much as anywhere else.

Limitations and Caveats

DFlash is not a universal solution. The headline numbers are tied to specific hardware and backends. The 15x result requires Blackwell with TensorRT-LLM; older GPU generations and other serving stacks will see smaller gains. The 6x lossless figure is single-stream greedy decoding; high-temperature sampling and conversational workloads with more varied outputs will lower acceptance rates and reduce the benefit (MT-Bench at 2.75x illustrates this).

Second, speculative decoding adds memory overhead. The draft model and its KV cache occupy GPU memory, which can create trade-offs with concurrency limits in memory-constrained multi-tenant environments. The small drafter reduces this burden but does not eliminate it.

Third, the responsibility for operational validation rests with the operator. The published figures are clearly sourced, but there is no guarantee they reproduce identically under your model, traffic, and concurrency. As noted, ThakiCloud has not reproduced these results in our environment, so we cannot verify them independently. Canary deployment with direct measurement of token cost and p50/p99 latency is required before committing to production. Finally, because block diffusion drafters are a relatively new approach, not all model architectures have checkpoints available. Check that a draft checkpoint exists for your target model before proceeding.

Sources

• 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 public checkpoint collection (Hugging Face, z-lab/dflash)
• vLLM Speculative Decoding documentation