Source: RT @DeRonin_: My entire AI stack is now Chinese 🇨🇳 · twitter

What this means for ThakiCloud

We drew this because “cheap” and “mine” get confused far too often. ThakiCloud handles both on one board. Paxis runs the per-task model routing on your own on-prem hardware, and Metis trains and serves those models directly. It mirrors the savings from that viral tweet, except the work happens inside your walls instead of on a rented API. The bill drops and the keys stay in your hand. That’s an actual stack you own, not a fresh sublet.

An auto-generated comic riffing on this week’s industry news.

원 뉴스: RT @DeRonin_: My entire AI stack is now Chinese 🇨🇳 · twitter

ThakiCloud 제품 적용 시사점

저희가 굳이 이 만화를 그린 이유는 ‘싸다’와 ‘내 것이다’가 자주 헷갈리기 때문입니다. 타키클라우드는 두 가지를 한 판에서 풉니다. 파시스가 작업별로 알맞은 모델에 일을 나눠 주는 라우팅을 온프렘 위에서 돌리고, 메티스가 그 모델을 직접 학습하고 추론까지 맡습니다. 트윗 속 절감 방식을 흉내 내되, 남의 API가 아니라 내 시설에서 돌린다는 점이 다릅니다. 비용은 내리고 열쇠는 내가 쥡니다. 그게 바꿔 낀 셋방이 아니라 진짜 내 스택입니다.

이 만화는 업계 뉴스를 바탕으로 자동 생성된 초안입니다.

نظرة عامة

يتكرر مشهد بات مألوفا: المسمى الوظيفي لا يصف بعد الآن ما يفعله صاحبه فعلا. المصمم يكتب نماذج أولية بالكود، والمهندس يجري مقابلات مع المستخدمين، وعالم البيانات يحسم اتجاه المنتج. مع امتصاص أدوات الذكاء الاصطناعي للجانب الميكانيكي من كل وظيفة، تتداخل حدود الهندسة والمنتج والتصميم والتحليل وتذوب في كتلة واحدة.

أمام هذا التحول، رصد Boris Cherny صانع Claude Code ملاحظة لافتة: حين أمعن النظر في فريق Claude Code الذي ينتمي إليه، وجد خمسة نماذج أصيلة للأدوار تتشكل بمعزل عن الوظائف الرسمية. وأهمية هذه الملاحظة بسيطة: إنها تطرح فرضية مفادها أن منظمات المستقبل قد تبني فرقها على أساس هذه النماذج لا على أساس الوظائف التقليدية.

يتناول هذا المقال ماهية النماذج الخمسة، وسبب انفصالها عن الوظائف الرسمية، والتركيبة اللازمة منها في كل مرحلة من مراحل نضج المنتج. هذا ليس ملخصا تقنيا، بل مقال ثقافي يتساءل: كيف نبني الفرق وكيف ننظر إلى التوظيف؟ وهو سؤال مباشر بصفة خاصة لمنظمات كـ ThakiCloud حيث يعمل البشر والوكلاء الآليون جنبا إلى جنب.

النماذج الأصيلة الخمسة

النماذج التي صاغها Cherny هي كالتالي، مع توضيح كيف يظهر كل نموذج في الفرق الفعلية.

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

المنفذ (Builder) هو من يحول النماذج الأولية والأفكار بسرعة إلى منتجات أو بنية تحتية جاهزة للإنتاج. دوره تضييق المسافة بين الفكرة والإطلاق. إن كان المبتكر يرسم المخططات، فالمنفذ يحول تلك المخططات إلى مبانٍ قائمة.

المنظف (Sweeper) هو المرتب بامتياز: يصقل الواجهات المبعثرة، ويبسط الكود والأنظمة، ويزيل الميزات غير المستخدمة، ويرفع الأداء. عمله الحذف لا الإضافة. قرار إلغاء ميزة (unship) يستدعي شجاعة لا تقل عن شجاعة بنائها.

المنمي (Grower) يأخذ منتجا قائما ويحسنه باستمرار لرفع مستوى الملاءمة مع السوق (PMF). لا يعيد رسم اللوحة من الصفر، بل يعمل على الصورة الموجودة ليرفع معدلات التحويل ويخفض الاضطراب ويراكم تحسينات صغيرة.

الصائن (Maintainer) هو من يتملك الأنظمة الناضجة. يحافظ على الأمن والاستقرار والسرعة والكفاءة مع تنامي الأنظمة. لا بريق في عمله، لكن من دونه ينهار المنتج الناجح تحت ثقله.

flowchart TB
    P["المبتكر (Prototyper)<br/>يولد أفكارا جديدة"]
    B["المنفذ (Builder)<br/>يحول إلى منتج جاهز للإنتاج"]
    S["المنظف (Sweeper)<br/>التبسيط والترتيب والأداء"]
    G["المنمي (Grower)<br/>تحسين PMF بصفة مستمرة"]
    M["الصائن (Maintainer)<br/>الأمن والاستقرار والتوسع"]
    P --> B
    B --> S
    S --> G
    G --> M
    M -.الصيانة وإعادة الاختراع.-> B

النموذج ليس وظيفة

جوهر هذه الملاحظة ليس القائمة في حد ذاتها، بل حقيقة أن هذه النماذج لا ترتبط بالوظائف الرسمية. يقول Cherny إنه حين ينظر إلى Anthropic في مجملها يجد بعض المصممين ينتمون إلى النموذج الأول (المبتكر)، وآخرين إلى الثاني (المنفذ)، وغيرهم إلى الثالث (المنظف). والأمر ذاته ينطبق على المهندسين ومديري المنتجات وعلماء البيانات.

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

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

تشكيل الفرق وفق دورة حياة المنتج

السبب الحقيقي لأهمية هذه النماذج هو أنها تصبح صيغة لتشكيل الفرق. يرى Cherny أن الفريق الصحي يحتاج إلى تركيبة مختلفة من النماذج وفق درجة نضج المنتج.

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

المنتج في طور النمو بعد تحقيق الملاءمة مع السوق يحتاج إلى النماذج الثاني والثالث والرابع (المنفذ + المنظف + المنمي) مع جرعة من النموذج الخامس (الصائن). الاتجاه معروف الآن، فالمهمة رفع الجودة وتحسين التحويل مع قدر أدنى من الاستقرار لاستيعاب المستخدمين المتزايدين.

المنتج الناضج ذو الملاءمة القوية مع السوق يحتاج إلى النماذج الثالث والرابع والخامس (المنظف + المنمي + الصائن) مع جرعة من النموذج الثاني (المنفذ). المهمة إبقاء النظام بسيطا، والتحسين المستمر، والحفاظ على الأمن والسرعة في مستويات التوسع، مع البناء الجديد حين يلزم فحسب.

flowchart TB
    PRE["قبل PMF<br/>منتج جديد"]
    GROW["مرحلة النمو<br/>تحقق PMF"]
    MATURE["مرحلة النضج<br/>PMF قوي"]
    PRE -->|"المبتكر + المنفذ + المنظف"| GROW
    GROW -->|"المنفذ + المنظف + المنمي (+ جرعة الصائن)"| MATURE
    MATURE -->|"المنظف + المنمي + الصائن (+ جرعة المنفذ)"| MATURE

الدلالة العملية لهذه الصيغة واضحة: حين تضيف شخصا إلى الفريق، السؤال الأول ليس “هل يعاني الفريق من نقص في المهندسين؟” بل “أي نموذج يغيب عن فريقنا في هذه المرحلة؟” إشباع فريق منتج ناضج بالمبتكرين يعني فيضا من الأفكار الجديدة دون من يصون النظام. والعكس، جمع الصائنين في منتج لم يجد ملاءمته بعد يعني التحصن لحماية ما لا وجود له أصلا.

منظور ThakiCloud: إعادة رسم الأدوار في عصر الوكلاء

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

Paxis، الحوسبة السحابية Native للوكلاء التي تشغلها ThakiCloud، تجسد هذا التحول على مستوى طبقة النظام. تعامل Paxis المهارات والأدوات والسياسات وسجلات التدقيق بوصفها موارد من الدرجة الأولى، وتختار أكثر من 960 مهارة عبر BM25 وتنفذها في بيئات معزولة. كما قال Cherny إن الأشخاص تُعاد صياغتهم وفق لحظات المنتج لا وفق مسمياتهم الوظيفية، كذلك تُجمع Paxis قدرات الوكلاء ديناميكيا وفق متطلبات المهمة لا وفق خطوط أنابيب جامدة. المبتكر يطرح الأفكار، فيحولها وكيل بدور المنفذ إلى كود جاهز للإنتاج، ثم يرتب بوابة التحقق بدور المنظف المخرجات، وكل ذلك يتكرر داخل حزمة المهارات.

على صعيد البنية التحتية، يضطلع ai-platform من ThakiCloud بالعمل الكامل للنموذج الصائن. جدولة وحدات GPU عبر Kueue، وتقديم النماذج عبر vLLM، والوفاء بمتطلبات الخصوصية والسيادة في بيئات K8s متعددة المستأجرين: كل ذلك هو بالضبط عمل الصائن الذي يحفظ الأمن والاستقرار والكفاءة في الأنظمة الناضجة. تفويض منظمات العملاء لهذا الجانب إلى المنصة يتيح لفرقهم الانتشار أكثر في اتجاه المبتكرين والمنميين.

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

حدود الإطار والحجج المضادة

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

ثمة حدود للتصنيف في حد ذاته. كل محاولة لوضع الناس في خمسة صناديق تعاني من خطر تبسيط الأفراد تبسيطا مفرطا. في الواقع، يتنقل الشخص الواحد بين عدة نماذج من مشروع لآخر، بل خلال اليوم الواحد. الخطأ هو النظر إلى النماذج بوصفها هويات ثابتة، فيصدر حكم من قبيل “أنت منظف إذن لا تقترح أفكارا جديدة”، وهذا عكس الغرض تماما. لهذا شدد Cherny نفسه على أن كثيرين يجمعون بين نماذج متعددة.

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

خاتمة

ذوبان حدود الوظائف ليس أزمة، بل إعادة تشكيل. النماذج الخمسة: المبتكر والمنفذ والمنظف والمنمي والصائن تكشف ما يبقى حين تختفي المسميات الوظيفية. ما يبقى ليس الأدوات، بل جوهر السؤال: في أي لحظة وبأي طريقة يقدم الشخص إسهامه؟

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

المصادر

• Boris Cherny, X(@bcherny), 2026-06-29: التغريدة الأصلية
• Ben Vinegar, X(@bentlegen): تغريدة الرد والاعتراض

نظرة عامة

أصدرت NVIDIA النموذج nvidia/Qwen3.6-27B-NVFP4، وهو نسخة مكمّمة بدقة NVFP4 رباعية البت من نموذج Qwen3.6-27B الخاص بشركة Alibaba. يضغط نموذج استدلال بـ 27 مليار معامل ذا انتباه هجين إلى 4 بت، فيخفض ذاكرة الأوزان بنحو 2.5 ضعف مع إبقاء الفجوة عن خط أساس FP8 ضمن نقطة واحدة عبر المعايير التسعة كلها. والرخصة هي Apache 2.0.

هناك ثلاث نقاط جديرة بالتوضيح. أولاً، خلافاً لإصدار Gemma-4-26B-A4B-NVFP4 السابق الذي لم يحصل على تسريع 4 بت عملياً إلا على Blackwell، تذكر بطاقة هذا الإصدار معماريتَي Hopper وBlackwell معاً ضمن العتاد المدعوم. أي أن الفريق الذي يشغّل H100 أو H200 يستطيع تجربته اليوم دون شراء عتاد جديد. ثانياً، هذا ليس نموذجاً لغوياً نصياً فقط بل نموذج استدلال متعدد الوسائط يستقبل مدخلات نصية وصورية وفيديو. ثالثاً، تتسع نافذة السياق حتى 262 ألف رمز، فتستوعب المستندات الطويلة والمحادثات الممتدة دفعة واحدة.

تشغّل ThakiCloud منصة تدير حصص وحدات GPU عبر Kueue وتخدم النماذج بأسلوب متعدد المستأجرين عبر vLLM على Kubernetes. لذا فإن سؤال “كم نموذجاً أكبر، وكم مستأجراً إضافياً، يمكننا وضعه على وحدات GPU التي نملكها أصلاً؟” ليس خبراً طريفاً بل يغذّي نموذج التكلفة مباشرة. يستعرض هذا المقال حقائق النموذج، ويحلل سبب نزول NVFP4 إلى Hopper، ثم يقيّم بصراحة مسار الخدمة وفائدته على منصتنا.

ما هذا النموذج

nvidia/Qwen3.6-27B-NVFP4 هو نموذج Qwen3.6-27B من Alibaba مكمّماً بدقة NVFP4 عبر NVIDIA Model Optimizer (nvidia-modelopt v0.45.0). وفيما يلي المواصفات الأساسية حسب بطاقة النموذج.

الجزء اللافت هو معمارية الانتباه الهجين. فـ Gated DeltaNet مسار من فئة الانتباه الخطي، مصمَّم لمعالجة المتتاليات الطويلة بكفاءة، خلافاً للانتباه المعتاد الذي تنمو كلفته مع طول المتتالية. ومزجه مع Gated Attention الذي يحمل القدرة التعبيرية يمنح توازناً يستوعب سياقاً بطول 262 ألف رمز مع الحفاظ على الجودة. كما أن اشتراط --reasoning-parser qwen3 عند الخدمة يؤكد أن هذا نموذج استدلال يولّد أثر التفكير قبل الإجابة النهائية.

ونذكر بصراحة أمراً واحداً: تذكر بطاقة النموذج الانتباه الهجين لكنها لا تفصح عن عدد الطبقات الدقيق أو تكوين الخبراء أو المعاملات النشطة لكل رمز. لذا يقتصر هذا المقال على الحقائق المذكورة في البطاقة ولا يقدّر الأرقام غير المعلنة.

تكميم NVFP4: ماذا يُضغط وكيف

‏NVFP4 هو صيغة الفاصلة العائمة رباعية البت التي تدفع بها NVIDIA. وخلافاً لـ INT4 الذي يقتطع الأوزان إلى أعداد صحيحة رباعية البت ببساطة، فهو أسلوب قياس مصغّر يضع مقياس FP8 لكل كتلة صغيرة، فينعم بتوفير الذاكرة على مستوى 4 بت مع إبقاء فقدان الدقة صغيراً.

في هذا الإصدار، أهداف التكميم هي أوزان وقيم تنشيط المعاملات الخطية داخل كتل المحوّل. أما الطبقات غير الخطية فتُترك دون مساس. وتذكر البطاقة أن خفض عدد البتات لكل معامل من 16 إلى 4 يقلّص متطلبات القرص وذاكرة GPU بنحو 2.5 ضعف. فتحميل 27 مليار معامل بدقة BF16 يحتاج نحو 54 جيجابايت، وبتطبيق الخفض بنحو 2.5 ضعف تنزل نقطة التفتيش إلى نحو 20 جيجابايت. وهذا يفتح مجالاً لوضع أكثر من ضعف النموذج على وحدة GPU نفسها، أو لتحويل الذاكرة المحرَّرة إلى مخزن KV لرفع التزامن.

وهنا يفترق الأمر عن مراجعة Gemma NVFP4 السابقة. فقد كان لدى إصدار Gemma نواة NVFP4 لنماذج MoE معطّلة على Blackwell الاستهلاكي والاحترافي (SM120)، فكان المسار الاستهلاكي الوحيد الذي يعمل فعلاً هو DGX Spark. أما إصدار Qwen3.6 هذا فتذكر بطاقته معماريتَي Hopper وBlackwell معاً ضمن العتاد المدعوم، وتستخدم الخدمة مسار --quantization modelopt في vLLM. ومع تكميم قيم التنشيط إلى جانب الأوزان ووجود مسار خدمة modelopt، يمكن تشغيل هذا النموذج رباعي البت على وحدات H100 وH200 المثبتة أصلاً في مراكز البيانات. لقد تراخى هذه المرة بشكل ملموس قيد “يجب شراء Blackwell جديد لرؤية مكاسب 4 بت”.

flowchart TB
    A["Qwen3.6-27B<br/>BF16 نحو 54GB"] --> B["NVIDIA Model Optimizer<br/>v0.45.0"]
    B --> C["تكميم NVFP4<br/>أوزان المعاملات الخطية + التنشيط<br/>من 16 بت إلى 4 بت"]
    C --> D["نقطة تفتيش NVFP4<br/>نحو 20GB · خفض ~2.5 ضعف"]
    D --> E["خدمة vLLM<br/>--quantization modelopt"]
    E --> F["NVIDIA Hopper<br/>H100 / H200"]
    E --> G["NVIDIA Blackwell<br/>B200 وغيرها"]

المعايير: كم تكلّف الدقة الرباعية

تعرض بطاقة النموذج النسخة المكمّمة بـ NVFP4 جنباً إلى جنب مع خط أساس FP8 عبر تسعة معايير.

جميع البنود التسعة ضمن نقطة واحدة من FP8. وفي MMLU Pro وHLE وτ²-Bench Telecom وIFBench يتفوق إصدار NVFP4 بفارق ضئيل، والأسلم قراءة ذلك ضمن تباين القياس. الاتجاه واضح: الجودة محفوظة عملياً تحت 4 بت، وهنا تظهر ميزة NVFP4 على INT4.

كما يشير تكوين المعايير نفسه إلى طابع النموذج. فـ τ²-Bench Telecom يقيس وكيلاً يستدعي الأدوات لإنجاز المهام، وAA-LCR يقيس الاستدلال ذا السياق الطويل، وMMMU Pro يقيس الفهم متعدد الوسائط. أي أن هذا النموذج يستهدف استخدام الأدوات لدى الوكلاء، والسياق الطويل، وتعدد الوسائط، لا مجرد أسئلة المعرفة. ومع ذلك، لا تظهر مهام النطاق الكوري في المعايير العامة، لذا نوصي بتحقق منفصل عبر مجموعة تقييم داخلية قبل التبني.

دليل الخدمة

المسار الموصى به في بطاقة النموذج هو vLLM. وأمر التشغيل كالآتي.

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

ثلاث نقاط تشغيلية مهمة. أولاً، --quantization modelopt هو العلَم الأساسي الذي يحمّل نقطة تفتيش NVFP4. ثم --reasoning-parser qwen3 لازم كي يُحلَّل أثر التفكير والإجابة النهائية تحليلاً صحيحاً. وأخيراً --max-model-len 262144 يفتح سياق 262 ألف رمز كاملاً، وتنمو ميزانية مخزن KV تبعاً لذلك، فالأكفأ للذاكرة خفضه إلى الطول الذي تحتاجه فعلاً.

يفترض العتاد Hopper أو Blackwell، ونظام التشغيل Linux. وبفضل دعم Hopper، يمكنك التحقق من مسار الخدمة على عُقد H100 وH200 الموجودة أصلاً في مركز البيانات دون معدات إضافية.

منظور خدمة ThakiCloud

تشغّل ThakiCloud منصة AI/ML قائمة على K8s تدير حصص GPU عبر Kueue وتخدم النماذج بأسلوب متعدد المستأجرين عبر vLLM. وتأتي دلالات هذا النموذج على نموذج تشغيلنا من اتجاهين: البنية التحتية والوكلاء.

مضاعفة الكثافة على أصول Hopper القائمة. هذه أبرز قيمة عملية لهذا الإصدار. فدعم NVFP4 لـ Hopper يعني إمكان جني مكسب 4 بت على H100 وH200 التي تملكها أصلاً، دون استثمار جديد في Blackwell. وحين تنزل أوزان نموذج بـ 27 مليار معامل إلى نحو 20 جيجابايت، يمكنك وضع مزيد من نسخ النموذج على وحدة GPU نفسها، أو تحويل الذاكرة المحرَّرة إلى مخزن KV لضبط حدود تزامن سخية لكل مستأجر. ومن منظور حصص Kueue، تتحمل البطاقة نفسها عبئاً أكبر، فتنخفض تكلفة الوحدة ببساطة.

مرشح على الخوادم الخاصة لعامل استدلال متعدد الوسائط. إن Paxis، مستوى التحكم بالوكلاء لدى ThakiCloud، سحابةٌ أصيلة الوكلاء تشغّل المهارات في صناديق رمل معزولة وتمرّر كل إجراء عبر بوابات السياسات وسجلات التدقيق. وفي هذه البنية يقرأ عدد من العمّال المستندات ويستدعون الأدوات وينجزون المهام. ويتميز Qwen3.6-27B-NVFP4 في معايير استخدام الأدوات لدى الوكلاء مثل τ²-Bench Telecom، ويستقبل الصورة والفيديو إلى جانب النص، ويستوعب سياق 262 ألف رمز. فهو مرشح مناسب للتشغيل على الخوادم الخاصة كعامل متعدد الوسائط يتعامل مع المستندات والشاشات والفيديو، وكعامل طرفي في حلقات استدعاء الأدوات. وبحسب انضباط التكلفة لدينا، شغّل العامل بثمن زهيد لكن أغلق التوسع بمرحلة تحقق على نموذج أعلى كي لا تتراكم هلوسات العامل.

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

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

من باب التوازن، إليك التحفظات.

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

ومع ذلك، فإن مزيج Apache 2.0، وتسريع 4 بت الذي بات يصل إلى Hopper، والاستدلال متعدد الوسائط، وسياق 262 ألف رمز، خيارٌ جذاب للمؤسسات التي تدرس الخدمة على الخوادم الخاصة. ومجرد انخفاض جدار “اشترِ عتاداً جديداً لتنال مكاسب 4 بت” يجعله جديراً بالتحقق اليوم لأي فريق يملك أسطول Hopper.

روابط مرجعية

• بطاقة نموذج Qwen3.6-27B-NVFP4 (Hugging Face)
• NVIDIA TensorRT Model Optimizer
• التعريف بـ NVFP4 (NVIDIA Developer)
• توثيق vLLM
• مراجعة Gemma-4-26B-NVFP4 على DGX Spark (مدونة ThakiCloud)

من يدير خدمة استدلال نماذج اللغة الكبيرة في بيئة إنتاجية يلاحظ حتمًا هذا النمط المتكرر: طلب يُنتج عشرات الرموز فحسب — كردّ بسيط في نظام محادثة — يجلس منتظرًا خلف طلب تلخيص وثيقة طويل أو مهمة توليد كود معقدة، مُهدرًا مئات الميلي ثانية. هذا ما يُعرف بـ Head-of-Line (HoL) Blocking.

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

يعالج أسلوب Dual-Pool Token-Budget Routing الوارد في arXiv 2604.08075 هذه المشكلة من جذورها: عند وصول كل طلب، يُقدَّر عدد الرموز المتوقع، ويُوجَّه الطلب إما إلى مجمّع السياق القصير أو مجمّع السياق الطويل، فيتعايش النوعان دون تدخّل متبادل.

النتائج التي رصدها البحث:

المبدأ الأساسي: التوجيه القائم على ميزانية الرموز

الفكرة وراء Dual-Pool بسيطة. يُقدَّر لكل طلب أقصى عدد رموز متوقع، ثم يُعيَّن الطلب لأحد المجمّعَين بناءً على عتبة محددة.

الرموز المتوقعة = رموز الإدخال + رموز الإخراج المتوقعة

حين يكون عدد رموز الإخراج مجهولًا — وهو الحال في معظم سيناريوهات الإنتاج — تُستخدم إحدى التقريبتين التاليتين:

1. معاملات الطلب: استخدام قيمة max_tokens حدًّا أعلى.
2. التصنيف القائم على السجل التاريخي: تتبّع توزيع أطوال الطلبات السابقة لكل مسار API أو بصمة نظام الرسالة، ثم التصنيف بناءً على قيمة P75 أو P90.

تعتمد العتبة الفاصلة على طبيعة أعباء العمل؛ وفي تجارب البحث استُخدم 512 رمزًا في الإخراج حدًّا بين القصير والطويل.

المعمارية: هيكل المجمّعَين

flowchart TB
    A[Client Request] --> B[Router<br/>Token-Budget Classifier]
    B -->|Estimated tokens < threshold| C[Short-Context Pool<br/>vLLM Instance A]
    B -->|Estimated tokens >= threshold| D[Long-Context Pool<br/>vLLM Instance B]
    C --> E[Kueue LocalQueue<br/>short-pool]
    D --> F[Kueue LocalQueue<br/>long-pool]
    E --> G[GPU Worker Group A<br/>Small KV Cache Requests]
    F --> H[GPU Worker Group B<br/>Large KV Cache Requests]
    G --> I[Return Response]
    H --> I

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

التكامل مع Kueue LocalQueue

تعتمد منصة ai-platform الخاصة بـ ThakiCloud على Kueue لجدولة أعباء عمل GPU على Kubernetes. يتيح دمج Dual-Pool Routing مع Kueue LocalQueue إدارة تخصيص موارد كل مجمّع بأسلوب تصريحي على مستوى الكلاستر.

الخطوة 1: تعريف ClusterQueue و ResourceFlavor

apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: llm-inference-cq
spec:
  namespaceSelector: {}
  resourceGroups:
    - coveredResources: ["nvidia.com/gpu"]
      flavors:
        - name: gpu-a100
          resources:
            - name: nvidia.com/gpu
              nominalQuota: 8
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: gpu-a100
spec:
  nodeLabels:
    gpu.nvidia.com/model: A100

الخطوة 2: تعريف LocalQueue منفصل لكل مجمّع

apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  name: short-pool-queue
  namespace: llm-serving
spec:
  clusterQueue: llm-inference-cq
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  name: long-pool-queue
  namespace: llm-serving
spec:
  clusterQueue: llm-inference-cq

الخطوة 3: إضافة التعليق التوضيحي للقائمة في vLLM Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-short-pool
  namespace: llm-serving
  annotations:
    kueue.x-k8s.io/queue-name: short-pool-queue
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args:
            - "--model"
            - "meta-llama/Llama-3.1-8B-Instruct"
            - "--max-model-len"
            - "4096"       # مجمّع قصير: حد سياق صغير
            - "--gpu-memory-utilization"
            - "0.7"        # دوران سريع لـ KV Cache
          resources:
            limits:
              nvidia.com/gpu: "1"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-long-pool
  namespace: llm-serving
  annotations:
    kueue.x-k8s.io/queue-name: long-pool-queue
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args:
            - "--model"
            - "meta-llama/Llama-3.1-8B-Instruct"
            - "--max-model-len"
            - "32768"      # مجمّع طويل: نافذة سياق واسعة
            - "--gpu-memory-utilization"
            - "0.90"       # احتجاز كبير لـ KV Cache
          resources:
            limits:
              nvidia.com/gpu: "1"

الخطوة 4: تطبيق الموجِّه (مثال بـ Python)

from fastapi import FastAPI, Request
import httpx

app = FastAPI()

SHORT_POOL_URL = "http://vllm-short-pool-svc:8000/v1/chat/completions"
LONG_POOL_URL  = "http://vllm-long-pool-svc:8000/v1/chat/completions"
TOKEN_THRESHOLD = 512  # اضبط هذه القيمة وفق السجل التاريخي لأعباء العمل

def estimate_output_tokens(payload: dict) -> int:
    """استخدام max_tokens حدًّا أعلى. الافتراضي 256 عند الغياب."""
    return payload.get("max_tokens") or 256

def route_request(payload: dict) -> str:
    """إعادة عنوان URL المستهدف بحسب عدد الرموز المقدَّر."""
    estimated = estimate_output_tokens(payload)
    if estimated < TOKEN_THRESHOLD:
        return SHORT_POOL_URL
    return LONG_POOL_URL

@app.post("/v1/chat/completions")
async def proxy(request: Request):
    payload = await request.json()
    target_url = route_request(payload)
    async with httpx.AsyncClient(timeout=120.0) as client:
        resp = await client.post(target_url, json=payload)
        return resp.json()

يُنشر هذا الموجِّه كـ Kubernetes Service ويُوضع أمام نقطة نهاية الاستدلال الحالية.

اعتبارات التشغيل

ضبط العتبة الفاصلة

قيمة 512 رمزًا نقطة بداية لا معيار ثابت. في بيئات الإنتاج الفعلية، يُنصح بجمع المقاييس التالية على مدار سبعة أيام على الأقل قبل التعديل:

• توزيع رموز الإخراج الفعلية لكل طلب (P50، P90، P99)
• معدل الاستئناف القسري لكل مجمّع (vllm:num_preemptions_total في Prometheus)
• عمق قائمة الانتظار vllm:num_requests_waiting لكل مجمّع

إن ظلّ عمق قائمة انتظار المجمّع القصير مرتفعًا باستمرار، فاخفض العتبة أو أضف نسخًا إضافية. وإن تدنّى معدل استخدام GPU في المجمّع الطويل، فارفع العتبة لتقليل الطلبات الموجَّهة إليه.

التكامل مع KEDA للتوسع التلقائي

تُتيح إضافة ScaledObject من KEDA مستندًا إلى مقاييس Prometheus الخاصة بـ vLLM توسعًا تلقائيًا مستقلًا لكل مجمّع:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-short-pool-scaler
  namespace: llm-serving
spec:
  scaleTargetRef:
    name: vllm-short-pool
  minReplicaCount: 1
  maxReplicaCount: 8
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus:9090
        metricName: vllm_requests_waiting_short
        query: vllm:num_requests_waiting{deployment="vllm-short-pool"}
        threshold: "5"

التوسع القائم على المقاييس أكثر استجابةً لأحمال الاستدلال مقارنةً بالتوسع القائم على معدل HTTP. عتبة 5 تعني بدء التوسع حين تتجاوز الطلبات المنتظرة خمسة طلبات.

مشاركة النموذج مقابل فصل النسخ

لا يشترط الأسلوب استخدام نسختين منفصلتين من vLLM. تشغيل النموذج ذاته بإعدادات --max-model-len مختلفة هو التكوين الافتراضي، لكن إن توفّرت ميزانية ذاكرة كافية، يمكن لنسخة واحدة من vLLM أن تعرض منفذَي اتصال خارجيَّين بأولوية داخلية مختلفة.

غير أن فصل النسخ هو الخيار الأوضح للقضاء الكامل على تداخل الاستئناف، إذ تتشارك ذاكرة KV Cache داخل عملية vLLM الواحدة.

الأهمية بالنسبة لمنصة ThakiCloud

تُخدِّم منصة ai-platform الخاصة بـ ThakiCloud أعباء استدلال عدة مستأجرين على كلاستر GPU مشترك. يُضيف Dual-Pool Routing ميزتَين ملموستَين في هذا السياق.

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

ثانيًا، يرفع كفاءة ميزانية GPU. توفير 31–42% من وقت GPU يعني إما استيعاب طلبات أكثر بالميزانية ذاتها، أو تحقيق الإنتاجية نفسها بعدد أقل من وحدات GPU. في بيئات الخوادم المحلية ذات الموارد الثابتة، ينعكس هذا التوفير مباشرةً على تكلفة الخدمة.

بالنسبة لكلاسترات ThakiCloud التي تستخدم Kueue LocalQueue بالفعل، يتطلب تطبيق هذا الأسلوب إعلان قائمتَي انتظار فحسب وتوزيع موجِّه خفيف الوزن. التوافق مع مواصفات vLLM Deployment الحالية مرتفع، مما يُوسّع نطاق التبنّي.

خلاصة

المشكلة التي يعالجها Dual-Pool Token-Budget Routing واضحة: حين تتشارك الطلبات القصيرة والطويلة قائمة انتظار واحدة، تخسر القصيرة. فصلها على مستوى قائمة الانتظار يُتيح لكل نوع المعالجة بسرعته الطبيعية.

النتائج التي رصدها arXiv 2604.08075 — توفير 31–42% من وقت GPU، وتراجع معدل الاستئناف بمقدار 5.4 أضعاف، وتحسن بنسبة 6% في P99 TTFT — تمثّل عائدًا كبيرًا قياسًا بتعقيد التطبيق. على Kubernetes، يكفي وجود قائمتَي Kueue LocalQueue واثنتَي نشر vLLM Deployment وموجِّه خفيف واحد لبناء هذه البنية.

Source: My entire AI stack is now Chinese · twitter

What this means for ThakiCloud

It’s a joke, but it happens to real teams. You adopted the stack for convenience, and control quietly walked out with it. ThakiCloud is built for exactly this. Train open models on your own GPU cluster with Kubeflow, serve them with vLLM, and keep your data behind your own firewall. On-prem means running the system inside your own facility rather than on someone else’s cloud. Build agents with Paxis, run the platform with Metis, and every layer stays yours. If you would rather not pin your product to someone else’s terms of service, sovereign on-prem AI is the point.

An auto-generated comic riffing on this week’s industry news.

Source: Boris Cherny on the five archetypes of future roles · twitter

What this means for ThakiCloud

For the five creative archetypes to shine, someone has to take the sixth: GPU lifecycle, scaling, security patches, the 3 a.m. incident nobody sees. We turned this idea into real automation. We built the five archetypes as AI agents (prototyper, builder, sweeper, grower, maintainer), and a Jarvis orchestrator dispatches whichever archetype fits the task. This very blog runs that way: the prototyper mines post ideas, the builder writes the draft, the sweeper cleans up the site, and the maintainer checks security and dependencies. That is what ThakiCloud is for. The platform and its agents carry the sixth role nobody wants, so people can focus on building and growing.

An auto-generated comic riffing on this week’s industry news.

Overview

Job titles are increasingly failing to describe the actual work. Designers shipping prototypes as code, engineers conducting user interviews, data scientists setting product direction – none of this feels strange anymore. As AI tools absorb the mechanical layers of each discipline, the boundaries between engineering, product, design, and data analysis are melting together.

Boris Cherny, creator of Claude Code, offered an interesting observation about this shift. Looking at his own Claude Code team, he noticed five role archetypes cutting across job functions. The reason this observation matters is simple: it raises a hypothesis that future organizations may staff teams around combinations of these archetypes rather than around functional job categories.

This post unpacks what those five archetypes are, why they detach from formal job titles, and what combinations a team needs at different stages of product maturity. This is not a technical summary – it is a culture essay asking how we should think about team composition and hiring. For organizations like ThakiCloud, where humans and agents work side by side, the question is particularly direct.

The Five Role Archetypes

Cherny’s archetypes are as follows. For each one, some notes on how it shows up in real teams.

The Prototyper generates entirely new ideas. This person produces a flood of concepts, most of which never ship. The value of this archetype lies not in a high success rate but in the density of imagination. Without someone who can open a new direction – even if nine out of ten ideas get discarded – an organization cannot push into new territory.

The Builder converts prototypes and ideas into production-grade products or infrastructure, quickly. This is the role that closes the distance between conception and launch. If the Prototyper is the sketch, the Builder is the one who turns that sketch into a building that actually stands.

The Sweeper tidies things up. Polishing messy UIs, simplifying code and systems, removing unused features, improving performance – the Sweeper’s job is subtraction, not addition. Deciding to unship a feature takes just as much courage as building one.

The Grower takes an existing product and iterates relentlessly to improve PMF. Rather than redesigning the whole board, this person raises conversion, reduces churn, and accumulates small improvements on top of what already exists.

The Maintainer owns mature systems. This archetype keeps security, stability, speed, and efficiency intact as a system scales. Not glamorous work, but without it a grown product collapses under its own weight.

flowchart TB
    P["Prototyper<br/>churns out new ideas"]
    B["Builder<br/>converts to production-grade"]
    S["Sweeper<br/>simplify, tidy, performance"]
    G["Grower<br/>iterates toward PMF"]
    M["Maintainer<br/>keeps security, stability, scale"]
    P --> B
    B --> S
    S --> G
    G --> M
    M -.maintain / reinvent.-> B

These Are Roles, Not Job Titles

The heart of this observation is not the list itself – it is that these archetypes do not map to job functions. Cherny notes that across Anthropic, some designers fall into archetype 1 (Prototyper), others into archetype 2 (Builder), and still others into archetype 3 (Sweeper). The same is true for engineers, product managers, and data scientists.

Put differently, “we’re hiring a designer” is a sentence that carries less and less information. Two designers can contribute to a team in completely different ways depending on whether they are the Prototyper type who opens new territory or the Sweeper type who refines and completes. A job title tells you what tools someone has learned; it does not tell you which moments they shine in.

Many people straddle two archetypes, and some span three. Someone who is both Prototyper and Builder is especially valuable in an early-stage startup. Someone who combines Sweeper and Maintainer becomes the backbone of a mature infrastructure team. Rather than fitting a person into a single box, it is more accurate to think about where they fall on the spectrum of these archetypes.

Team Composition by Product Lifecycle

The real reason these archetypes are interesting is that they become a formula for staffing. Cherny argues that a healthy team needs a different archetype mix depending on product maturity.

A new product that has not yet found PMF needs people strong in Prototyper, Builder, and Sweeper (1 + 2 + 3). At this stage nobody knows what will work, so the capacity to build fast, discard fast, and keep changing direction is what counts. Filling this team with people who are primarily Maintainers means spending energy defending something that does not yet exist.

A growing product that has found PMF needs Builder, Sweeper, and Grower (2 + 3 + 4) plus a light Maintainer presence (5). Direction is established; the task now is to improve completeness and conversion while securing just enough stability to handle the expanding user base.

A mature product with strong PMF needs Sweeper, Grower, and Maintainer (3 + 4 + 5) with a sprinkling of Builder (2). The priority is keeping the system simple, improving it continuously, and protecting security and speed at scale – with new builds only when genuinely necessary.

flowchart TB
    PRE["Pre-PMF<br/>new product"]
    GROW["Growth stage<br/>PMF found"]
    MATURE["Maturity<br/>strong PMF"]
    PRE -->|"Prototyper + Builder + Sweeper"| GROW
    GROW -->|"Builder + Sweeper + Grower (+ light Maintainer)"| MATURE
    MATURE -->|"Sweeper + Grower + Maintainer (+ light Builder)"| MATURE

The practical implication of this formula is clear. When adding someone to the team, the first question should not be “do we need more engineers?” but “which archetype is missing for our current product stage?” Keep filling a mature product team with Prototypers and you will have no shortage of new ideas but nobody guarding the system. Fill a pre-PMF product team with only Maintainers and you will be in a defensive posture before there is anything worth defending.

ThakiCloud’s Take: Role Realignment in the Age of Agents

The observation that job roles are dissolving becomes sharper still in organizations where humans and agents work together. As AI agents absorb a significant share of mechanical build work, people naturally migrate toward the archetypes that are genuinely important at each product stage. The bottleneck shifts from the hands that type the code to the eye that judges which archetype is needed right now.

Paxis, ThakiCloud’s Agent-Native Cloud, implements this realignment at the systems layer. Paxis treats Skills, Tools, Policies, and Audit Logs as first-class resources, selecting from over 960 skills using BM25 and executing them in isolated sandboxes. Just as Cherny describes recombining human roles to fit the product moment rather than a fixed title, Paxis dynamically assembles agent capabilities to match the task at hand rather than locking them into a fixed pipeline. A Prototyper pours out ideas, a Builder-role agent converts them to production code, and a Sweeper-role validation gate cleans up the result – the same division of labor reproduced inside the skill harness.

On the infrastructure side, ThakiCloud’s ai-platform takes on the Maintainer archetype’s workload. Scheduling GPUs with Kueue, serving models with vLLM, and satisfying on-premises and sovereign requirements in a K8s-based multi-tenant environment – this is precisely the Maintainer’s job of protecting security, stability, and efficiency in a mature system. Customer organizations delegate this layer to the platform, which frees their own teams to concentrate more resources on the Prototyper and Grower ends of the spectrum.

This lens is also useful for hiring. ThakiCloud looks past the job title on a resume to ask where on the archetype spectrum a candidate actually sits. The person who fills the missing archetype for our current product stage creates the greatest leverage in the team. The question is not only “what can you do?” but “which moments are when you shine?”

Limitations and Counterpoints

Before accepting this framework uncritically, the other side deserves a hearing. Ben Vinegar pushed back on this conversation, arguing that “people are just learning how software organizations work and mistakenly attributing the dynamics of team roles – which have always existed – to AI.” That is a sharp counterpoint. The distinction between Prototyper and Maintainer existed long before AI, and the insight that different talent profiles are needed at different lifecycle stages is not a new one.

There are also limits to the classification itself. Like any attempt to sort people into five boxes, this framework risks oversimplifying individuals. In practice, one person moves across multiple archetypes from project to project, sometimes within a single day. Treating archetypes as fixed identities produces a harmful effect of the kind: “you’re a Sweeper, so don’t come to me with new ideas.” This is precisely why Cherny himself emphasizes that many people move fluidly across archetypes.

Even so, the framework earns its value not from predictive power but from the language it provides. When a team can say “we’re short on Growers right now” instead of the vague “we need another engineer,” the conversation around hiring and team composition becomes far more concrete. The more AI strips away the mechanical layer of each role, the more what remains is judgment at the archetype level. Future product roles may end up shaped closer to these archetypes than to today’s domain-specific job titles.

Closing Thoughts

Job titles dissolving is not a crisis – it is a restructuring. The five archetypes – Prototyper, Builder, Sweeper, Grower, Maintainer – show what remains when titles fall away. What remains is not a toolset but an essence: how a person contributes, and in which moments.

ThakiCloud is building an organization where humans and agents share these archetypes. The more agents take on repeatable build and maintenance work, the more humans focus on reading which archetype the product needs right now. That judgment is the rarest and most valuable capability in what comes next.

Sources

• Boris Cherny, X(@bcherny), 2026-06-29: Original tweet
• Ben Vinegar, X(@bentlegen): Counterpoint

Overview

NVIDIA has released nvidia/Qwen3.6-27B-NVFP4, a NVFP4 4-bit quantization of Alibaba’s Qwen3.6-27B. It compresses a 27B-class hybrid-attention reasoning model to 4-bit, cutting weight memory by roughly 2.5x while keeping the gap to the FP8 baseline within 1 point across all nine benchmarks. The license is Apache 2.0.

Three points are worth highlighting. First, unlike the earlier Gemma-4-26B-A4B-NVFP4 that effectively only got 4-bit acceleration on Blackwell, this build’s model card lists both Hopper and Blackwell as supported targets. That means a team already running H100 or H200 can try it today without buying new hardware. Second, this is not a text-only LLM but a multimodal reasoning model that accepts text, image, and video input. Third, the context window opens up to 262K tokens, taking long documents and extended conversations in a single pass.

ThakiCloud operates a platform that manages GPU quotas with Kueue and serves models multi-tenant with vLLM on Kubernetes. So “how much larger a model, and how many more tenants, can we fit on the GPUs we already own?” is not a novelty item; it feeds directly into the cost model. This post reviews the model facts, examines why NVFP4 came down to Hopper, then honestly assesses the serving path and its usefulness on our platform.

What Is This Model

nvidia/Qwen3.6-27B-NVFP4 is Alibaba’s Qwen3.6-27B quantized to NVFP4 with NVIDIA Model Optimizer (nvidia-modelopt v0.45.0). The core spec from the model card is as follows.

The notable part is the hybrid attention architecture. Gated DeltaNet is a linear-attention path, designed to process long sequences efficiently, unlike standard attention whose cost grows with sequence length. Blending it with Gated Attention, which carries expressiveness, gives a compromise that handles a 262K context while preserving quality. The fact that serving requires --reasoning-parser qwen3 also confirms this is a reasoning model that generates a reasoning trace before the final answer.

One thing to state honestly: the model card names hybrid attention but does not disclose the exact layer count, expert configuration, or per-token active parameters. So this post covers only the facts in the card and does not estimate the undisclosed figures.

NVFP4 Quantization: What Gets Compressed, and How

NVFP4 is the 4-bit floating-point format NVIDIA is pushing. Unlike INT4, which simply truncates weights to 4-bit integers, it is a micro-scaling scheme that places an FP8 scale per small block, enjoying 4-bit-level memory savings while keeping accuracy loss small.

In this build the quantization targets are the weights and activations of the linear operators within the transformer blocks. Non-linear layers are left untouched. The model card states that reducing bits per parameter from 16 to 4 cuts disk and GPU memory requirements by about 2.5x. Loading 27B parameters in BF16 needs roughly 54 GB; applying the ~2.5x reduction brings the checkpoint down to around 20 GB. That opens room to place more than twice the model on the same GPU, or to redirect the freed memory to the KV cache to raise concurrency.

This is where it diverges from the earlier Gemma NVFP4 review. The Gemma build had a broken NVFP4 MoE kernel on consumer and pro Blackwell (SM120), so the only consumer-grade path that actually ran was the DGX Spark. This Qwen3.6 build, by contrast, has a model card that lists both Hopper and Blackwell as supported targets, and serving uses vLLM’s --quantization modelopt path. With activations quantized alongside weights and the modelopt serving path in place, this 4-bit model can run on the H100 and H200 already installed in data centers. The constraint of “you must buy new Blackwell to see 4-bit gains” has been substantially relaxed this time.

flowchart TB
    A["Qwen3.6-27B<br/>BF16 ~54GB"] --> B["NVIDIA Model Optimizer<br/>v0.45.0"]
    B --> C["NVFP4 quantization<br/>linear-operator weights + activations<br/>16-bit to 4-bit"]
    C --> D["NVFP4 checkpoint<br/>~20GB range · ~2.5x reduction"]
    D --> E["vLLM serving<br/>--quantization modelopt"]
    E --> F["NVIDIA Hopper<br/>H100 / H200"]
    E --> G["NVIDIA Blackwell<br/>B200 etc."]

Benchmarks: How Much Does 4-bit Cost

The model card presents the NVFP4 quantized model side by side with the FP8 baseline across nine benchmarks.

All nine are within 1 point of FP8. On MMLU Pro, HLE, τ²-Bench Telecom, and IFBench the NVFP4 build is even marginally higher, which is safer read as measurement variance. The direction is clear: quality is essentially preserved under 4-bit, and this is where NVFP4’s advantage over INT4 shows.

The benchmark mix itself signals the model’s character. τ²-Bench Telecom measures an agent calling tools to complete tasks, AA-LCR measures long-context reasoning, and MMMU Pro measures multimodal understanding. In other words, this model targets agent tool use, long context, and multimodality, not just plain knowledge QA. That said, Korean-domain tasks do not appear in the public benchmarks, so we recommend separate validation with an internal eval set before adoption.

Serving Guide

The recommended path in the model card is vLLM. The run command is as follows.

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

Three operational points matter. First, --quantization modelopt is the key flag that loads the NVFP4 checkpoint. Next, --reasoning-parser qwen3 is required for the reasoning trace and final answer to be parsed correctly. Finally, --max-model-len 262144 opens the full 262K context; the KV cache budget grows accordingly, so it is more memory-efficient to lower it to the length you actually need.

The hardware assumption is Hopper or Blackwell, and the OS is Linux. Thanks to Hopper support, you can validate the serving path on H100 and H200 nodes already in the data center without additional equipment.

ThakiCloud Serving Perspective

ThakiCloud runs a K8s-based AI/ML platform that manages GPU quotas with Kueue and serves models multi-tenant with vLLM. The implications for our operating model come in two directions, infrastructure and agents.

Doubling density on existing Hopper assets. This is the most tangible value of this build. NVFP4 supporting Hopper means you can capture the 4-bit gain on H100 and H200 you already own, without new Blackwell investment. When a 27B model’s weights fall to around 20 GB, you can place more model instances on the same GPU, or redirect the freed memory to the KV cache to set generous per-tenant concurrency limits. From a Kueue quota view, the same card takes on more workload, so the unit cost simply comes down.

An on-prem candidate for a multimodal reasoning worker. Paxis, ThakiCloud’s agent control plane, is an Agent-Native Cloud that runs skills in isolated sandboxes and passes every action through policy gates and audit logs. In that structure, many workers read documents, call tools, and complete tasks. Qwen3.6-27B-NVFP4 is strong on agent tool-use benchmarks like τ²-Bench Telecom, accepts image and video in addition to text, and handles a 262K context. It is a fit candidate to run on-prem as a multimodal worker handling documents, screens, and video, and as a terminal worker in tool-call loops. Per our cost discipline, run the worker cheaply but close the fan-out with a verification stage on a higher model so worker hallucinations do not accumulate.

A reference for on-prem and compliance proposals. An Apache 2.0 license with single-node serving is a configuration you can propose directly to public-sector and financial customers where data exfiltration is prohibited. In constrained environments such as national-security requirements or sovereign AI, running a large multimodal reasoning model on your own GPUs without a commercial API becomes a real adoption path.

Limitations and Counterpoints

For balance, here are the caveats.

• Architecture details are undisclosed. Hybrid attention is stated, but the layer count, expert configuration, and active parameters are absent from the card. Precisely computing batch efficiency and resident memory requires more information.
• No measured throughput numbers. This post rests on card facts such as memory savings and benchmarks. Per-stream token speed and concurrency limits vary greatly with hardware and settings, so re-measure with your own workload before adoption.
• Variance from activation quantization. Pushing activations, not just weights, to 4-bit can introduce accuracy variance on workloads with skewed distributions. Even with public benchmarks within 1 point, verify domain-specific tasks separately.
• Maturity of the multimodal serving path. Stably taking image and video input in production requires validating both the preprocessing pipeline and the maturity of vLLM’s multimodal path.
• Korean real-world validation. Public benchmarks are English-centric. Korean RAG and tool-call accuracy must be checked separately with an internal eval set.

Even so, the combination of Apache 2.0, 4-bit acceleration that now reaches Hopper, multimodal reasoning, and a 262K context is an attractive option for organizations weighing on-prem serving. The mere fact that the “buy new hardware to get 4-bit gains” wall has lowered makes it worth validating today for any team that already owns a Hopper fleet.

References

• Qwen3.6-27B-NVFP4 model card (Hugging Face)
• NVIDIA TensorRT Model Optimizer
• Introducing NVFP4 (NVIDIA Developer)
• vLLM documentation
• Gemma-4-26B-NVFP4 DGX Spark review (ThakiCloud blog)

Anyone who has run an LLM inference service in production has seen this: a request that generates a few dozen tokens — say, a one-liner chatbot reply — sits waiting behind a long document summarization or code generation job, wasting hundreds of milliseconds. This is Head-of-Line (HoL) blocking.

vLLM’s continuous batching dramatically improves batch efficiency, but in a single-pool setup, long requests hold onto the KV cache for extended periods, forcing shorter requests to be preempted. Preempted requests pay the cost of recomputation, and overall GPU time efficiency drops.

The Dual-Pool Token-Budget Routing approach from arXiv 2604.08075 addresses this at the root. At request intake, it estimates the expected response length and routes each request to either a short-context pool or a long-context pool, so the two types never interfere with each other.

The paper reports the following results:

Core Idea: Token-Budget-Based Routing

The concept behind Dual-Pool is straightforward. For each request, the system estimates the maximum expected token count and assigns it to one of two pools based on a threshold.

Expected tokens = input tokens + estimated output tokens

When output token count is unknown — which is most of the time in production — two approximations work well:

1. Request parameters: Use the max_tokens value as an upper bound.
2. History-based classification: Track the length distribution of previous requests by API path or system prompt hash, then classify using the P75 or P90 value.

The threshold depends on workload characteristics. In the paper’s experiments, 512 output tokens was the boundary between short and long.

Architecture: The Two-Pool Structure

flowchart TB
    A[Client Request] --> B[Router<br/>Token-Budget Classifier]
    B -->|Estimated tokens < threshold| C[Short-Context Pool<br/>vLLM Instance A]
    B -->|Estimated tokens >= threshold| D[Long-Context Pool<br/>vLLM Instance B]
    C --> E[Kueue LocalQueue<br/>short-pool]
    D --> F[Kueue LocalQueue<br/>long-pool]
    E --> G[GPU Worker Group A<br/>Small KV Cache Requests]
    F --> H[GPU Worker Group B<br/>Large KV Cache Requests]
    G --> I[Return Response]
    H --> I

The short-context pool cycles through KV cache quickly, maintaining high throughput. The long-context pool reserves enough KV cache memory to complete long generations without interruption. Neither pool preempts the other.

Kueue LocalQueue Integration

ThakiCloud’s ai-platform schedules GPU workloads on Kubernetes using Kueue. Integrating Dual-Pool Routing with Kueue LocalQueue lets you manage resource allocation for each pool declaratively at the cluster level.

Step 1: Define ClusterQueue and ResourceFlavor

apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: llm-inference-cq
spec:
  namespaceSelector: {}
  resourceGroups:
    - coveredResources: ["nvidia.com/gpu"]
      flavors:
        - name: gpu-a100
          resources:
            - name: nvidia.com/gpu
              nominalQuota: 8
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: gpu-a100
spec:
  nodeLabels:
    gpu.nvidia.com/model: A100

Step 2: Separate LocalQueues per Pool

apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  name: short-pool-queue
  namespace: llm-serving
spec:
  clusterQueue: llm-inference-cq
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  name: long-pool-queue
  namespace: llm-serving
spec:
  clusterQueue: llm-inference-cq

Step 3: Annotate vLLM Deployments with Queue Names

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-short-pool
  namespace: llm-serving
  annotations:
    kueue.x-k8s.io/queue-name: short-pool-queue
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args:
            - "--model"
            - "meta-llama/Llama-3.1-8B-Instruct"
            - "--max-model-len"
            - "4096"       # short pool: small context limit
            - "--gpu-memory-utilization"
            - "0.7"        # fast KV cache turnover
          resources:
            limits:
              nvidia.com/gpu: "1"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-long-pool
  namespace: llm-serving
  annotations:
    kueue.x-k8s.io/queue-name: long-pool-queue
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args:
            - "--model"
            - "meta-llama/Llama-3.1-8B-Instruct"
            - "--max-model-len"
            - "32768"      # long pool: generous context window
            - "--gpu-memory-utilization"
            - "0.90"       # large KV cache reservation
          resources:
            limits:
              nvidia.com/gpu: "1"

Step 4: Router Implementation (Python Example)

from fastapi import FastAPI, Request
import httpx

app = FastAPI()

SHORT_POOL_URL = "http://vllm-short-pool-svc:8000/v1/chat/completions"
LONG_POOL_URL  = "http://vllm-long-pool-svc:8000/v1/chat/completions"
TOKEN_THRESHOLD = 512  # tune this against workload history

def estimate_output_tokens(payload: dict) -> int:
    """Use max_tokens as upper bound. Default to 256 if absent."""
    return payload.get("max_tokens") or 256

def route_request(payload: dict) -> str:
    """Return the target URL based on estimated token count."""
    estimated = estimate_output_tokens(payload)
    if estimated < TOKEN_THRESHOLD:
        return SHORT_POOL_URL
    return LONG_POOL_URL

@app.post("/v1/chat/completions")
async def proxy(request: Request):
    payload = await request.json()
    target_url = route_request(payload)
    async with httpx.AsyncClient(timeout=120.0) as client:
        resp = await client.post(target_url, json=payload)
        return resp.json()

Deploy this router as a Kubernetes Service and place it in front of your existing inference endpoint.

Operational Considerations

Tuning the Threshold

The 512-token boundary is a starting point, not a universal constant. In practice, collect the following metrics over at least seven days before adjusting:

• Actual output token distribution per request (P50, P90, P99)
• Per-pool preemption rate (vllm:num_preemptions_total Prometheus metric)
• Per-pool vllm:num_requests_waiting queue depth

If the short-pool queue grows persistently deep, lower the threshold or add more short-pool replicas. If long-pool GPU utilization stays low, raise the threshold to send fewer requests there.

KEDA Autoscaling Integration

Adding a KEDA ScaledObject backed by vLLM Prometheus metrics gives each pool its own independent autoscaling behavior:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-short-pool-scaler
  namespace: llm-serving
spec:
  scaleTargetRef:
    name: vllm-short-pool
  minReplicaCount: 1
  maxReplicaCount: 8
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus:9090
        metricName: vllm_requests_waiting_short
        query: vllm:num_requests_waiting{deployment="vllm-short-pool"}
        threshold: "5"

Metric-based scaling responds more directly to inference load than simple HTTP RPS scaling. A threshold of 5 means scale-up begins when more than five requests are queued.

Model Sharing vs. Instance Separation

The two pools do not strictly require separate vLLM instances. Running the same model with different --max-model-len settings is the baseline configuration, but if memory budget allows, a single vLLM instance can expose two external ports with different internal priority classes.

That said, instance separation is the cleaner choice for fully eliminating preemption interference, because KV cache memory is shared within a single vLLM process.

Relevance to ThakiCloud’s ai-platform

ThakiCloud’s ai-platform serves multiple tenants’ inference workloads on a shared GPU cluster. Dual-Pool Routing adds two concrete benefits in this context.

First, it reduces cross-tenant interference. When Tenant A’s chatbot requests — short by nature — get queued behind Tenant B’s long document analysis batch jobs, the result is SLO violations. Pool separation cuts off this interference at the structural level.

Second, it improves GPU budget efficiency. A 31–42% GPU time reduction means either handling more requests with the same GPU budget, or achieving the same throughput with fewer GPUs. In an on-premises environment with a fixed resource ceiling, that savings translates directly into lower serving cost.

For ThakiCloud clusters already using Kueue LocalQueue, adding this architecture requires only two queue declarations and a lightweight router deployment. Compatibility with existing vLLM Deployment specs is high, so the adoption surface is broad.

Summary

The problem Dual-Pool Token-Budget Routing solves is simple: when short and long requests share a queue, short requests lose. Separating them at the queue level lets each type be processed at its natural pace.

The results from arXiv 2604.08075 — 31–42% GPU time savings, a 5.4x reduction in preemption rate, and 6% improvement in P99 TTFT — represent a strong return for the implementation complexity involved. On Kubernetes, two Kueue LocalQueues, two vLLM Deployments, and one lightweight router are all it takes to build this structure.