نظرة عامة

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

نظرة عامة

‏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

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”

نظرة عامة

أثار اهتماماً واسعاً عرضٌ تجريبي يُظهر تشغيل نموذج 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

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.

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

Claude Code is a powerful coding agent. However, because every request goes directly to the Anthropic API, it creates a constraint for organizations that need to control costs or keep data within their own boundaries. The recently trending free-claude-code project addresses this exact point. It is a proxy layer that intercepts Claude Code traffic and routes it to 17 different providers. It is an MIT-licensed project with 36.7k GitHub stars, 5.7k forks, and 712 commits.

The project’s marketing tagline is “Claude Code forever free.” The approach routes traffic to free or low-cost tier providers, and this framing is frankly overstated in some respects and sits in a gray area from a Terms of Service perspective. This article therefore focuses not on the “free” angle, but on what this tool means for organizations like ThakiCloud that serve their own models on Kubernetes and want to connect Claude Code to their own infrastructure. The key points are that code and prompts never leave the tenancy boundary, per-token cloud billing disappears, and no client-side modifications are needed because the endpoint is Anthropic-compatible.

Note: A previous article, “Routing Claude Code to In-House Models - claude-code-router,” focused on cost arbitrage between cloud models (glm, MiniMax, Kimi). This article is about a different tool (free-claude-code), covering the connection to self-hosted backends (Ollama, vLLM) — not cloud models — and the deployment risks that surfaced in the process.

What This Tool Does

free-claude-code is a local proxy server that receives requests sent by Claude Code (and Codex). Its core feature is that it exactly mimics an Anthropic-compatible endpoint. From the client’s perspective, it is indistinguishable from the real Anthropic API, so the backend can be swapped without changing a single line of Claude Code.

The server is written in FastAPI and exposes the following endpoints:

• /v1/messages - Anthropic Messages API compatible (the primary path for Claude Code)
• /v1/models - Model listing
• /v1/responses - OpenAI Responses API compatible (for Codex; internally converted to Messages)

When a request arrives, a model router decides which provider to send it to, and a normalizer transforms thinking blocks, tool_calls, and error responses into the shape each client expects. Because response formats differ across providers, this normalization layer is where the real complexity lies.

To elaborate on why normalization is difficult: Claude Code assumes Anthropic’s own response structure. For instance, reasoning steps arrive as thinking blocks and tool calls as tool_use content blocks. DeepSeek, however, exports reasoning as a separate field, and OpenAI-compatible providers return tool calls as a tool_calls array. Even though they all mean “a tool was called,” the wire format differs in each case. The normalizer must absorb these differences and ensure Claude Code receives identically shaped responses regardless of which backend is used. The Codex path (/v1/responses) goes one step further, converting OpenAI Responses requests internally to Anthropic Messages before sharing the same router, normalizer, and provider adapters. This means protocol conversion happens in both directions — the key distinction between a simple reverse proxy and a routing proxy.

Figure 1. The FastAPI proxy receives Anthropic-compatible traffic from Claude Code and routes it to 17 providers. From ThakiCloud’s perspective, the important paths are the self-hosted backends on the right (Ollama, LM Studio, vLLM).

The supported providers number 17. On the cloud side: NVIDIA NIM, OpenRouter, Google AI Studio (Gemini), DeepSeek, Mistral La Plateforme, Mistral Codestral, OpenCode Zen, OpenCode Go, Wafer, Kimi, Cerebras, Groq, Fireworks, and Z.ai. On the self-hosted side: LM Studio, llama.cpp, and Ollama. The last three are the meaningful ones from ThakiCloud’s perspective. Since Ollama and llama.cpp expose OpenAI-compatible endpoints, a vLLM server deployed the same way on Kubernetes can be attached identically.

Tier-based routing is controlled via environment variables. MODEL_OPUS, MODEL_SONNET, and MODEL_HAIKU each specify which model to route to for the three Claude tiers; if unspecified, the fallback MODEL is used. This enables differentiated placement — for example, routing lightweight Haiku traffic to a small local model and heavier Opus traffic to a larger one.

Installation and Integration

The official installation path is a shell one-liner:

# 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

Rather than the shell one-liner, I verified the package by installing it directly in an isolated sandbox, in order not to contaminate ThakiCloud’s shared virtual environment per our Python runtime rules.

# Isolated worktree + ephemeral venv (shared .venv is 3.12.8 and would conflict)
uv venv --python 3.14 .expenv
VIRTUAL_ENV=.expenv uv pip install "git+https://github.com/Alishahryar1/free-claude-code.git"

The package itself installs cleanly. Dependencies such as fastapi, uvicorn, httpx, pydantic, openai, and loguru resolve successfully, and console scripts like fcc-server, fcc-init, and fcc-claude are created. After starting the server, Claude Code is directed to the proxy as follows:

fcc-server            # Start the FastAPI proxy (default http://127.0.0.1:8082)
# Self-hosted backend example (Ollama):
#   MODEL_HAIKU=ollama/llama3.2:3b
#   MODEL_SONNET=ollama/qwen2.5:7b
# Specify the base URL to point Claude Code at the proxy, then use as normal

The admin UI is at http://127.0.0.1:8082/admin and is only accessible from loopback. Provider keys, model routing, and messaging and voice settings are managed here.

Actual Experiment Results

During validation I encountered a point where reproduction was blocked, and I record it as-is. Not fabricating numbers is a principle of this report.

Boot Blocker: Hard Python 3.14 Requirement

free-claude-code v2.3.14 has hardcoded requires-python = ">=3.14.0". Python 3.14 is the latest version, only officially released in October 2025. The problem was that the only available 3.14 in the test environment was an alpha build (3.14.0a7). Running fcc-server on this alpha fails with the following error:

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

This is a conflict where the pinned pydantic expects the annotationlib API of the final 3.14, but that symbol is not yet present in the early alpha. I then attempted to force-run it under the next lower stable version (3.13), but installation itself is rejected because of the hard requirement in the package metadata:

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

The conclusion is clear: in environments without a stable Python 3.14, this proxy will not boot. Reproduction attempt failed: the package hard-requires freshly released Python 3.14, but the only available 3.14 is an alpha that conflicts with the pinned pydantic. This is less a defect in the tool than a problem of aggressive version pinning that is at odds with the reality that production images typically remain on 3.11–3.12.

Direct Measurement of the Self-Hosted Routing Path

Although the proxy itself was blocked at boot, the mechanism this tool uses to call the ollama provider is the OpenAI-compatible endpoint. I therefore measured this path by calling local Ollama directly. These are the backend’s own routing performance numbers without the proxy overhead that fcc would add. The results of mapping Claude’s three tiers to local models are as follows (Apple Silicon, identical prompt, 64-token cap):

Figure 2. Latency and throughput when routing Claude tiers to local Ollama models. qwen3:8b placed on the opus path is a thinking model that outputs extended reasoning tokens, significantly increasing the time.

The small model (llama3.2:3b) finishes responding in under 0.5 seconds — fast enough for Haiku replacement traffic. qwen2.5:7b at 0.56 seconds is also practical. The qwen3:8b placed on the opus path, however, took 8.12 seconds, because the thinking model first emits 281 reasoning tokens. The throughput itself (34.6 tok/s) is normal, but this measurement confirms that placing a reasoning model in a heavy tier causes a token explosion and significantly increases perceived latency. A practical lesson: when designing tier mappings, the reasoning-token behavior of the model must also be considered.

Application and Implications for ThakiCloud’s K8s AI/ML SaaS Platform

The real value of this tool lies not in “free” but in the connection pattern. Once an Anthropic-compatible proxy is inserted as a layer, commercial agents like Claude Code can be attached directly to our infrastructure.

ThakiCloud schedules GPUs with Kueue and serves models with vLLM on Kubernetes. Since vLLM provides an OpenAI-compatible endpoint (/v1/chat/completions), it can be connected to free-claude-code’s self-hosted provider path in the same way as Ollama or llama.cpp. The connection method is common across self-hosted providers: specify the base URL as the cluster’s vLLM service endpoint and add the provider prefix to the model identifier. Just as Ollama uses ollama/llama3.2:3b, an in-house model served on vLLM is added to the routing targets with the same prefix convention. This enables the following:

• Data sovereignty: Code and prompts never leave the tenancy boundary. This is essential in regulated environments such as on-premises deployment and NIS (National Intelligence Service) compliance requirements.
• Cost structure shift: Per-token metered billing is replaced by fixed GPU costs. The higher the usage, the faster self-serving reaches its break-even point.
• Tiered differentiated placement: Lightweight Haiku traffic can be routed to small models, and heavier workloads to larger ones, optimizing GPU occupancy. The measurements above provide baseline numbers for this differentiated placement.

That said, rather than adopting this tool as-is, it is more rational to borrow only the validated routing pattern. In a multi-tenant environment, the proxy must have per-tenant authentication, isolation, and observability, but free-claude-code’s admin UI assumes a single loopback user and is insufficient as-is. The idea behind the Anthropic-compatible normalization layer is worth borrowing, but authentication, quotas, and logging must be re-implemented to match our gateway standards.

Limitations and Counterarguments

First, there is the Terms of Service gray area. The “Claude Code for free” framing relies on routing through free-tier providers, which may conflict with each service’s terms. In enterprise environments, legitimate and sustainable use is strictly routing to owned backends (self-served models). This is why this article emphasizes only the self-hosting path.

Second, there is aggressive version pinning. As seen above, the hard Python 3.14 requirement immediately prevents booting in environments without a stable runtime. Considering the cost and risk of upgrading production container images to 3.14, inserting this tool directly into a deployment pipeline at this point carries too much friction.

Third, quality equivalence is not guaranteed. Replacing Claude’s Opus or Sonnet with different models does not preserve coding quality. Routing is a trade-off that gains cost savings and data sovereignty at the expense of response quality; which traffic to send where must be determined by measurement, depending on task difficulty.

Fourth, the measurements in this report are direct backend call numbers without going through the proxy. The normalization and routing overhead of fcc is not included. Once a stable Python 3.14 environment is secured, I plan to re-measure the round-trip latency through the proxy and supplement these results.

In summary, free-claude-code is risky if consumed as a “free hack,” but read as an open-source reference for Anthropic-compatible routing patterns, it is a solid starting point for the design of connecting commercial agents to self-hosted inference infrastructure.

Sources

• GitHub: Alishahryar1/free-claude-code (MIT, 36.7k stars, v2.3.14)
• Measurement data: Direct calls to local Ollama OpenAI-compatible endpoint (llama3.2:3b, qwen2.5:7b, qwen3:8b, Apple Silicon)
• Related article: ThakiCloud Tech Blog “Routing Claude Code to In-House Models - claude-code-router”

Overview

A demo showing a small desktop box running 16 concurrent sessions of a large MoE model has been making waves. The demo uses Gemma-4-26B-A4B-NVFP4 published by NVIDIA, running 16 parallel streams on a single DGX Spark (128 GB unified memory), reaching approximately 18 tokens/s per stream and about 300 tokens/s combined. The person who shared the demo noted that the concurrency was too high to display legibly on screen, so the demo was presented programmatically, that up to 32x parallelism is possible, and that flashinfer had not even been applied yet.

Two points are worth highlighting. First, this is not a lightweight E2B/E4B model that fits on a laptop. It is a full-scale Gemma MoE with 25.2 billion total parameters. Second, the reason this is possible is the combination of three factors: NVFP4 4-bit quantization, the small active-parameter footprint of MoE, and the large unified memory of the DGX Spark.

ThakiCloud operates a platform that serves LLMs in a multi-tenant configuration on Kubernetes. For us, “how many concurrent requests can a small on-premises box handle?” is not just an interesting demo; it is a question that feeds directly into the cost model. This post reviews the model facts, separates single-stream performance from concurrent throughput, honestly assesses whether the DGX Spark is cost-effective relative to other Blackwell GPUs, and considers how far this model fits into our skill ecosystem.

What the Demo Actually Showed

Summarizing the claims from the original demo (Google Gemma team tweet):

• Hardware: 1x DGX Spark, 128 GB unified memory (GB10 Grace-Blackwell)
• Model: nvidia/Gemma-4-26B-A4B-NVFP4
• Concurrency: 16x parallel, approximately 18 tokens/s per stream, approximately 300 tokens/s combined
• Headroom: up to 32x parallelism is possible, capped at 16x for screen readability
• Optimization headroom: flashinfer not yet applied, so further speedup is likely once support arrives

One potential misreading to address upfront: “18 tokens/s per stream” is the per-stream figure when 16 streams run simultaneously. A single stream alone is faster. The trade-off between concurrency and single-stream latency is covered below with measured numbers.

Gemma-4-26B-A4B-NVFP4: Model Facts

The model NVIDIA published is Google DeepMind’s gemma-4-26B-A4B-it quantized to NVFP4 using the NVIDIA Model Optimizer. Key specs from the model card:

What NVFP4 Is and Why It Requires Blackwell

NVFP4 is a 4-bit floating-point format accelerated in hardware on NVIDIA’s Blackwell generation. Unlike INT4 quantization, which simply truncates weights to 4-bit integers, NVFP4 uses microscaling with FP8 scale factors at small block granularity. This allows memory savings comparable to INT4 while keeping accuracy loss small.

The memory impact is most direct. Storing 25.2B parameters in BF16 requires roughly 50 GB; NVFP4 compresses the weights to approximately 14 to 16 GB. On the DGX Spark’s 128 GB unified memory, with weights at 16 GB, more than 100 GB remains available for the KV cache. That headroom is what enables 16 to 32x concurrency and long 256K-token contexts.

The hardware acceleration for NVFP4 is Blackwell-exclusive. On older generations like Hopper (H100) or Ada (RTX 4090), there are no NVFP4 tensor core paths, so the format’s benefits cannot be realized. In practice, this model is built to run on Blackwell.

Benchmark: How Much Does NVFP4 Quantization Cost?

The model card presents NVFP4 and baseline (unquantized) scores side by side:

All four benchmarks are within 1 percentage point of baseline. AIME and IFBench are slightly higher for the quantized version, which is most safely interpreted as measurement variance. The key takeaway is that “4-bit compression preserves quality in practice,” which is exactly the advantage NVFP4 claims over INT4. That said, none of the public benchmarks cover Korean-language tasks, so separate internal evaluation is recommended for Korean-domain use cases.

Real Performance: Single Stream vs. Concurrency

The “18 tokens/s per stream” from the demo can seem slow in isolation. The numbers need to be read with single-stream and concurrent modes separated. Synthesizing community reports measuring this model on the DGX Spark:

• Single stream, no MTP: approximately 32 tokens/s (with 64k context setting)
• Single stream + MTP (Multi-Token Prediction): approximately 55 to 61 tokens/s (32k context setting, best on short-to-medium responses and structured JSON)
• 16x concurrency: approximately 18 tokens/s per stream, approximately 300 tokens/s combined
• Long-context prefill: approximately 11.9 s for 25k-token input, approximately 28.6 s for 50k-token input (64k context setting)

Two observations stand out.

First, MoE decoding is memory-bandwidth-bound. With only 3.8B active parameters per token, compute (FLOPs) is light, but every token requires fetching the active expert weights from memory. The DGX Spark’s LPDDR5X unified memory has lower bandwidth than datacenter HBM, which is why single-stream speed is “modest for a Blackwell.” Even with FP4 compute capacity to spare, bandwidth is the ceiling.

Second, the DGX Spark’s real strength is not single-stream latency but aggregate concurrent throughput. Getting approximately 300 tokens/s across 16 streams means multiple requests share bandwidth efficiently. The large unified memory that allows a generous KV cache pool makes this possible. In other words, the machine is better suited to “serving many agents or users concurrently at adequate speed” than “delivering the fastest single response.”

flowchart LR
    subgraph Spark["DGX Spark · 128 GB Unified Memory"]
      W["NVFP4 Weights<br/>~16 GB"]
      KV["KV Cache Pool<br/>~100 GB+ 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 combined"]

Honest Review 1: Is the DGX Spark Actually Cost-Effective?

The short answer is: exceptional value per unit of memory, average value per unit of token latency. Different Blackwell chips have different characteristics.

The most important column in this table is not price but NVFP4 MoE status, because that is where theory and reality diverge.

• On paper, the RTX 5090 wins on $/token. Its bandwidth is 6.6x that of the DGX Spark (1,792 vs. 273 GB/s), and since MoE decoding is bandwidth-bound, theoretical throughput ceilings follow almost directly. Reading 16 GB of weights at 273 GB/s gives a theoretical ceiling of roughly 170 tokens/s; at 1,792 GB/s, roughly 1,100 tokens/s. The RTX 5090 costs about half as much, so in simple arithmetic it is 5 to 6x more efficient.
• In reality, NVFP4 MoE kernels are currently broken on consumer and professional Blackwell (SM120). The flashinfer NVFP4 GEMM issue on SM120 (#2577) remains open, making it effectively impossible to run this 4-bit MoE correctly on the RTX 5090 or RTX PRO 6000. The on-paper leader is, for now, “can’t run it.”
• That leaves the DGX Spark (SM121) as the only consumer-class box where NVFP4 MoE actually works today. Bandwidth is lower, so throughput is conservative, but “the 4-bit MoE box that runs today” is the actual reason this demo came from a DGX Spark.
• Datacenter Blackwell (B200, SM100) ships with full TRT-LLM and flashinfer NVFP4 support, but the per-unit cost is an order of magnitude different. 24/7 self-hosted serving favors owned hardware; burst or multi-tenant workloads may favor cloud B200.

In summary, the DGX Spark is not a machine for buying frontier-level per-token speed. It is a machine for buying large memory and high concurrency, in a form that works today, at a relatively accessible price for development, prototyping, and small-scale concurrent serving. Once SM120 kernels are fixed, the RTX 5090’s theoretical cost advantage becomes real. Until then, the DGX Spark’s position is clear. The 16x parallel demo is impressive precisely because it builds on that strength.

Honest Review 2: What Workloads Does This Fit?

Once the cost-efficiency profile is established, appropriate workloads follow naturally.

Good fit

• Multiple concurrent agents: 16 to 32 workers each running at moderate speed simultaneously. Aggregate throughput is the strength.
• Structured output workloads: the model card confirms function calling and JSON structured output support, and MTP is fastest on short-to-medium responses and control JSON. Well-suited to classification, tagging, and extraction tasks.
• Long-context processing: 256K context and a large KV headroom leave room for long-document summarization and RAG context injection.
• On-premises prototyping: experimenting with large MoE serving on a desk without datacenter GPUs.

Poor fit

• Single-user ultra-low-latency chat: per-stream speed is slower than GDDR7 cards. Not appropriate if “fastest single response” is the goal.
• Hardest single-shot reasoning: tasks requiring quality headroom should use a 31B dense model, something larger, or a closed-source flagship. At 26B this is a throughput-tier model.

Serving Guide

The recommended path per the model card is vLLM. Current constraints to be aware of:

• vLLM TP=1 only: the current build supports tensor parallelism of 1 only (assumes a single GPU or single box).
• Gemma 4-specific parsers required: the flags --tool-call-parser gemma4 and --reasoning-parser gemma4 must be specified for function calling and reasoning output to parse correctly.
• flashinfer not yet applied: the demo author stated flashinfer was not used. There is headroom for additional acceleration once attention kernel optimization is added.

For production use, Linux OS and Blackwell hardware with NVFP4 tensor cores are prerequisites. Running this build on older-generation GPUs will not deliver the 4-bit acceleration benefits.

Implications for the ThakiCloud K8s AI/ML SaaS Platform

ThakiCloud operates a multi-tenant platform that manages GPU quotas with Kueue and serves models with vLLM. This demo has three implications for our operational model.

A self-hosting candidate for worker-tier models. Our agent orchestration follows the cost discipline of “workers cheap, gates expensive.” Worker tasks such as exploration, classification, summarization, and structured extraction do not need top-tier models. NVFP4 26B, with roughly 300 tokens/s combined throughput and function calling plus JSON output, is a strong candidate for running many workers concurrently on-premises. Keeping only high-risk steps such as verification, synthesis, and architectural judgment on upper-tier models creates structural cost reduction.

Large unified memory simplifies multi-tenant KV budgeting. With weights at 16 GB on a 128 GB unified memory, the KV cache headroom exceeds 100 GB. KV cache is the first resource to run out in high-concurrency multi-tenant environments. This headroom allows generous per-tenant concurrency limits.

A reference configuration for on-premises and compliance proposals. Apache 2.0 license plus single-box serving is a configuration that can be proposed directly to public-sector and financial clients who require self-hosting. The ability to run a large MoE on a small box without datacenter GPUs is a practical deployment path for environments with constraints such as National Intelligence Service requirements or data-residency restrictions.

Honest Review 3: Where Does This Model Fit in Our Skill Ecosystem?

Most of ThakiCloud’s skill and agent ecosystem uses upper-tier models such as Opus or Sonnet as the primary. Where does NVFP4 26B slot in? Honestly:

• Drop-in replacement (worker tier): file reading and grep summarization, classification and enum normalization (format-determinism workers), first-draft generation, news and document extraction. Read-only and structured tasks currently handled by haiku/sonnet sub-agents can largely be moved to on-premises 26B.
• Conditional (with verification reinforcement): agent tool-call workers. Function calling and JSON output are supported, so this model can serve as a terminal worker in tool-call loops. However, fan-out results must be closed with adversarial verification by an upper-tier model to prevent hallucination accumulation.
• Not recommended (gate tier): multi-step architectural reasoning, synthesis and verification judgments, high-risk content generation. Stages requiring quality headroom stay with Opus.

The key is matching model tier to task tier. Viewing NVFP4 26B as an “Opus replacement” leads to disappointment. Viewing it as “an on-premises self-hosting candidate for the haiku/sonnet worker tier” opens a path to restructuring costs. This aligns exactly with our routing discipline: exploration cheap, gates expensive.

Limitations and Counter-Arguments

For balance:

• Single-stream speed is conservative. Memory-bandwidth limitations make it slower than GDDR7 cards. Latency-sensitive workloads require a different hardware choice.
• Demo figures are configuration-dependent. The 18 tokens/s and 300 tokens/s figures apply to 16x concurrency with specific settings. Results vary with prompt length, output length, and MTP usage. Your own workload requires re-measurement.
• vLLM TP=1 and no flashinfer are current-snapshot constraints. These numbers will change as optimizations are added; treat this as a point-in-time reading.
• MoE serving has operational complexity. Even though active parameters are 3.8B, all weights must reside in memory, and expert routing affects batch efficiency. “It’s small” is an oversimplification.
• Korean-language real-world validation is needed. Public benchmarks are English-centric. Korean RAG and tool-call accuracy require internal evaluation.

Even with these caveats, the combination of Apache 2.0, single-box large-MoE serving, and high concurrency backed by large memory is a genuinely attractive option for organizations considering on-premises or self-hosted deployment. Approached with the mindset of “buying cheap memory and concurrency” rather than “buying frontier speed,” DGX Spark plus NVFP4 26B has a clear and legitimate use case.

Reference Links

• Gemma-4-26B-A4B-NVFP4 model card (Hugging Face)
• Original demo tweet (Google Gemma)
• Full Gemma 4 lineup overview (ThakiCloud blog)
• NVIDIA TensorRT Model Optimizer
• Introducing NVFP4 (NVIDIA Developer)
• flashinfer NVFP4 GEMM SM120 issue #2577
• DGX Spark Gemma 4 26B NVFP4 benchmark (ai-muninn)

Gemma 4 Overview

Released by Google DeepMind on April 2, 2026, Gemma 4 is the most intelligent open-weight model family Gemma has shipped to date. Google states that it was built on the same research and technology that underpins Gemini 3. In other words, think of it as the training recipe behind a closed flagship distilled down into an open-weight lineup.

From a ThakiCloud perspective, two changes stand out this generation. First, the license moved to Apache 2.0. Unlike earlier Gemma generations that carried a separate Gemma usage policy, Gemma 4 adopts a commercially permissive standard open-source license. Second, it ships not as a single size but as a five-model lineup that spans everything from the edge (phones) to a single server GPU. That means you can pick a deployment target by device tier within the same model family.

Rather than going deep on a single model, this post aims to compare all five models at a glance and clarify which one to choose for which situation.

The Gemma 4 Lineup: All Five Models

Gemma 4 consists of the following five models. Organized by parameters, context, modality, and architecture per the model card:

All five output text. Audio input is supported only on the E2B, E4B, and 12B models; the 26B and 31B handle text and image.

The “E” in E2B and E4B stands for effective parameters. It is the size based on actual compute parameters excluding the embedding table, and effective values are the more realistic figure when gauging memory and compute budgets. Both models squarely target edge devices such as phones and laptops.

The heart of the lineup is the division of labor between the two top models: the 26B A4B (MoE) and the 31B (Dense).

• 26B A4B is a Mixture-of-Experts. It holds 25.2B total parameters but activates only about 3.8B per token. The full weights still have to sit in VRAM, but per-token compute (FLOPs) is based on the active parameters, which is favorable for latency and throughput. It suits serving where you need to push large volumes of requests quickly.
• 31B Dense is a standard dense model where every parameter participates on every token. Oriented toward maximizing quality and fine-tuning suitability, Google positions the 31B as the quality ceiling of the lineup.

According to Google, the 31B ranked #3 among open models worldwide on the Arena AI text leaderboard and the 26B placed #6, and it described the lineup as “competing with models 20x its size.” Such leaderboard rankings shift over time, so it is better to read them as a direction (“high intelligence density relative to its class”) than as absolute figures.

Model Selection Flow

flowchart TD
    A[Choose a Gemma 4 model] --> B{Deployment target?}
    B -->|Phone/edge device| C[E2B / E4B<br/>128K, audio support]
    B -->|Single-GPU on-prem| D{Priority?}
    D -->|Throughput/latency| E[26B A4B MoE<br/>active 3.8B]
    D -->|Top quality/fine-tuning| F[31B Dense]
    D -->|Multimodal + audio + balance| G[12B Unified<br/>256K, audio support]

Architecture: Hybrid Attention and Multimodality

All five Gemma 4 models share a hybrid attention mechanism. It interleaves local sliding-window attention with full global attention. Short ranges are handled cheaply by the sliding window, while global attention is periodically inserted to capture full-context dependencies, with the goal of curbing memory and compute cost on long contexts. This design is the backdrop to the upper models (12B/26B/31B) handling a 256K context.

Multimodality is the default this generation. All five take text and image as input, and the edge/mid tiers (E2B/E4B/12B) also handle audio input. Features aimed at agentic workflows are built in too. Function calling, structured JSON output, and native system instructions are officially supported, and the lineup emphasizes improvements in multi-step planning and logical reasoning over the previous generation. The training data cutoff is January 2025.

Language support is broad: 35+ languages out of the box and 140+ languages at the pretraining level. Actual quality in Korean operation requires direct evaluation, but the multilingual coverage itself is wide.

Benchmarks

The representative benchmarks Google published for the 31B instruction-tuned model are below, per the model card.

At the 31B single-node scale, GPQA Diamond at 84.3% and MMLU-Pro at 85.2% are top-tier among comparable open-weight models. That said, the benchmarks are for the instruction-tuned variant, and real domain-task performance must be validated separately. In particular, Korean reasoning and coding tasks are not directly reflected in public benchmarks, so measuring them with an internal eval set is recommended.

Serving and Deployment

Gemma 4 secured broad serving-ecosystem support from launch. The official paths are:

• Inference servers: vLLM, SGLang, llama.cpp, Ollama, LM Studio, NVIDIA NIM
• Frameworks: Hugging Face Transformers / TRL / Transformers.js / Candle, Keras, MaxText, NeMo
• Edge/on-device: LiteRT-LM, Cactus
• Fine-tuning/quantization: Unsloth, Tunix
• Deployment infra: Docker, Baseten, Google Cloud (Vertex AI)

Weights can be downloaded from the google/gemma-4 collection on Hugging Face, Kaggle, and Ollama.

On-Prem GPU Requirements (Estimated)

A rough on-prem deployment guide based on each model’s BF16 weight memory. These are weight estimates excluding KV cache and runtime overhead, so leave headroom for your context length and concurrent request count in an actual deployment.

The practical strength of the lineup is that both top models (26B, 31B) fit on a single 80GB GPU in BF16. That means you can run frontier-grade inference on a single server without multi-node tensor parallelism, which sharply lowers the bar to on-prem adoption. With a smaller GPU budget, step down to the 12B or to a quantized path (GGUF Q4/Q8). Thanks to its MoE nature computing only the active 3.8B, the 26B has a throughput edge per token over the 31B Dense at the same VRAM.

Implications for the ThakiCloud K8s AI/ML SaaS Platform

The Gemma 4 lineup meshes well with ThakiCloud’s multi-tenant serving strategy. It matters on three fronts.

Apache 2.0 unlocks the adoption barrier. A frontier-grade open-weight family released under standard Apache 2.0 is highly significant for enterprise and on-prem adoption. You can embed it in commercial services without the burden of reviewing a separate usage policy and freely distribute fine-tuned artifacts. It is a model family you can propose directly to environments with strict license compliance, such as domestic public-sector and finance, and to on-prem customers who require self-hosting.

The lineup itself aligns with multi-tenant GPU routing. ThakiCloud manages GPU quotas with Kueue and serves models with vLLM. Gemma 4’s five-model lineup is a structure that lets you route model tiers within one family to match tenant needs (latency-sensitive, quality-first, edge inference). Route light chat/summarization to the 12B, throughput-critical batches to the 26B MoE, and high-difficulty reasoning/coding to the 31B, and you can optimize the GPU budget by task tier while keeping the same tokenizer and prompt format.

Single-80GB-GPU serving simplifies the cost model. That the 26B and 31B fit on a single H100/A100 simplifies Kueue GPU job cost estimation. The communication overhead and scheduling complexity of multi-node tensor parallelism disappear, so you can price cleanly with a per-tenant dedicated-single-GPU model. The 26B MoE’s active-3.8B trait means it can take more concurrent requests on the same GPU, which is also favorable on a per-request unit-cost basis.

In short, Gemma 4 is a fit as a reference model family when ThakiCloud proposes a “single-GPU on-prem + multi-tenant model routing” operating pattern to customers.

Limitations and Counterpoints

For balance, a few caveats deserve mention.

• The gap between benchmarks and real use. The published figures center on the instruction-tuned, English-language benchmarks. Korean domain tasks, especially RAG and agent tool-call accuracy, must be re-measured with your own eval set.
• The operational difficulty of MoE serving. The 26B A4B has low per-token compute but must keep the full weights resident in VRAM, and expert routing affects batch efficiency and memory patterns. The simplistic reading “it’s small because active is 3.8B” is risky.
• Asymmetric audio support. Audio input exists only on E2B/E4B/12B. If you want top quality (26B/31B) and audio at the same time, a trade-off arises within the lineup.
• January 2025 training cutoff. Tasks needing the latest information must be supplemented with RAG and tool integration.

Even so, the Apache 2.0 license, the feasibility of single-GPU serving, and a lineup that bridges the edge to the server are reason enough to put Gemma 4 at the top of the evaluation list for any organization considering on-prem and self-hosting.

References

• Gemma 4 official announcement blog (Google)
• Gemma 4 model card (Google AI for Developers)
• Gemma 4 model overview docs
• google/gemma-4 collection on Hugging Face
• Google DeepMind Gemma GitHub library
• Gemma 4 availability on Google Cloud