نظرة عامة

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

أمام هذا التحول، رصد 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. 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. That is what ThakiCloud does. The platform absorbs the repetitive toil so your team can build and grow. We even turned these five archetypes into orchestration agents of our own. The sixth role nobody wants is the one the platform is built to carry.

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.

개요

직함이 하는 일을 설명하지 못하는 순간이 점점 늘고 있습니다. 디자이너가 프로토타입을 코드로 짜고, 엔지니어가 사용자 인터뷰를 하고, 데이터 과학자가 제품 방향을 정하는 장면이 이제 낯설지 않습니다. AI 도구가 각 직무의 기계적인 부분을 흡수하면서 엔지니어링, 제품, 디자인, 데이터 분석의 경계가 한 덩어리로 녹아내리고 있습니다.

이 흐름을 두고 Claude Code를 만든 보리스 체르니(Boris Cherny)가 흥미로운 관찰을 내놓았습니다. 자신이 속한 Claude Code 팀을 들여다보니 직무와 무관하게 다섯 가지 역할 원형이 보이더라는 것입니다. 이 관찰이 중요한 이유는 단순합니다. 앞으로의 조직이 직무 기능이 아니라 이런 원형의 조합으로 팀을 짜게 될지 모른다는 가설을 던지기 때문입니다.

이 글은 그 다섯 가지 원형이 무엇인지, 왜 직무와 분리되는지, 그리고 제품의 성숙도에 따라 어떤 조합이 필요한지를 정리합니다. 기술 요약이 아니라 팀을 어떻게 구성하고 채용을 어떻게 바라볼지를 묻는 문화 에세이입니다. ThakiCloud처럼 사람과 에이전트가 함께 일하는 조직에는 특히 직접적인 질문입니다.

다섯 가지 역할 원형

체르니가 제시한 원형은 다음과 같습니다. 각각을 우리말로 옮기면서 실제 팀에서 어떻게 드러나는지 덧붙였습니다.

프로토타이퍼(Prototyper)는 완전히 새로운 아이디어를 떠올리는 사람입니다. 수많은 아이디어를 쏟아내지만 대부분은 출시되지 못합니다. 이 원형의 가치는 성공률이 아니라 발상의 밀도에 있습니다. 열 개 중 아홉 개가 버려지더라도 하나의 방향을 여는 사람이 없으면 조직은 새 영토로 나아가지 못합니다.

빌더(Builder)는 프로토타입과 아이디어를 빠르게 프로덕션급 제품이나 인프라로 전환하는 사람입니다. 발상과 출시 사이의 거리를 좁히는 역할입니다. 프로토타이퍼가 스케치라면 빌더는 그 스케치를 실제로 서 있는 건물로 바꿉니다.

스위퍼(Sweeper)는 정리하는 사람입니다. 어수선한 UI를 다듬고, 코드와 시스템을 단순하게 만들고, 쓰이지 않는 기능을 걷어내고, 성능을 끌어올립니다. 무언가를 더하는 것이 아니라 덜어내는 것이 이 원형의 일입니다. 기능을 없애는 결정(unship)은 만드는 것만큼이나 용기가 필요합니다.

그로어(Grower)는 이미 만들어진 제품을 가져와 제품-시장 적합성(PMF)을 높이기 위해 반복적으로 개선하는 사람입니다. 큰 판을 새로 짜기보다 이미 있는 판에서 전환율을 끌어올리고, 사용자 이탈을 막고, 작은 개선을 쌓아 올립니다.

메인테이너(Maintainer)는 성숙한 시스템을 소유하는 사람입니다. 시스템이 커질 때 보안, 안정성, 속도, 효율을 유지합니다. 화려하지 않지만 이 원형이 없으면 성장한 제품은 자기 무게에 눌려 무너집니다.

flowchart TB
    P["프로토타이퍼<br/>새 아이디어를 쏟아냄"]
    B["빌더<br/>프로덕션급으로 전환"]
    S["스위퍼<br/>단순화·정리·성능"]
    G["그로어<br/>PMF 반복 개선"]
    M["메인테이너<br/>보안·안정·확장 유지"]
    P --> B
    B --> S
    S --> G
    G --> M
    M -.보수·재발명.-> B

역할은 직무가 아닙니다

이 관찰의 핵심은 목록 자체가 아니라, 이 원형들이 직무 기능과 연결되지 않는다는 점입니다. 체르니는 Anthropic 전체를 보면 어떤 디자이너는 프로토타이퍼(1번)에, 어떤 디자이너는 빌더(2번)에, 또 어떤 디자이너는 스위퍼(3번)에 해당한다고 말합니다. 엔지니어도, 제품 관리자도, 데이터 과학자도 마찬가지입니다.

바꿔 말하면 “디자이너를 뽑는다”는 문장이 점점 정보량을 잃고 있습니다. 같은 디자이너라도 새 영토를 여는 프로토타이퍼형인지, 다듬어 완성하는 스위퍼형인지에 따라 팀에 기여하는 방식이 완전히 다릅니다. 직함은 그가 배운 도구를 알려줄 뿐, 그가 어떤 순간에 빛나는지는 알려주지 않습니다.

많은 사람이 두 개의 원형을 넘나들고, 때로는 세 개까지 걸칩니다. 프로토타이퍼이면서 빌더인 사람이 초기 스타트업에서 특히 귀합니다. 스위퍼이면서 메인테이너인 사람은 성숙한 인프라 팀의 척추가 됩니다. 한 사람을 하나의 상자에 가두는 대신 그가 어떤 원형의 스펙트럼 위에 있는지를 보는 편이 실제에 더 가깝습니다.

제품 생애주기별 팀 구성

원형이 흥미로운 진짜 이유는 이것이 팀 구성의 공식이 되기 때문입니다. 체르니는 건강한 팀이라면 제품의 성숙도에 따라 다른 원형 조합이 필요하다고 정리합니다.

새롭고 아직 PMF를 찾지 못한 제품은 프로토타이퍼, 빌더, 스위퍼(1+2+3)에 강한 사람들이 필요합니다. 아직 무엇이 맞는지 모르는 단계이므로 빠르게 만들고, 빠르게 버리고, 방향을 계속 바꾸는 힘이 중요합니다. 이 단계에서 메인테이너 성향이 강한 사람만 모으면 만들어지지도 않은 것을 지키느라 움직이지 못합니다.

성장 중이고 PMF를 찾은 제품은 빌더, 스위퍼, 그로어(2+3+4)에 약간의 메인테이너(5)가 필요합니다. 방향은 잡혔으니 이제 완성도를 높이고 전환을 개선하면서, 늘어나는 사용자를 감당할 최소한의 안정성을 확보해야 합니다.

강한 PMF를 가진 성숙한 제품은 스위퍼, 그로어, 메인테이너(3+4+5)에 약간의 빌더(2)가 필요합니다. 시스템을 단순하게 유지하고, 지속적으로 개선하고, 커지는 규모에서 보안과 속도를 지키되, 필요할 때만 새로운 것을 짓습니다.

flowchart TB
    PRE["PMF 이전<br/>새 제품"]
    GROW["성장기<br/>PMF 확보"]
    MATURE["성숙기<br/>강한 PMF"]
    PRE -->|"프로토타이퍼+빌더+스위퍼"| GROW
    GROW -->|"빌더+스위퍼+그로어 (+약간의 메인테이너)"| MATURE
    MATURE -->|"스위퍼+그로어+메인테이너 (+약간의 빌더)"| MATURE

이 공식이 알려주는 실무적 함의는 분명합니다. 팀에 사람을 더할 때 “엔지니어가 부족하다”가 아니라 “지금 우리 제품 단계에 어떤 원형이 비어 있는가”를 먼저 물어야 한다는 것입니다. 성숙한 제품 팀에 프로토타이퍼만 계속 채우면 새 아이디어는 넘치지만 아무도 시스템을 지키지 않습니다. 반대로 PMF 이전 제품에 메인테이너만 모으면 지킬 것이 생기기도 전에 방어 태세부터 갖춥니다.

ThakiCloud 관점: 에이전트 시대의 역할 재편

직무가 녹아내린다는 관찰은 사람과 에이전트가 함께 일하는 조직에서 한층 뾰족해집니다. AI 에이전트가 기계적인 빌드 작업의 상당 부분을 흡수하면, 사람은 자연스럽게 제품 단계마다 진짜로 중요한 원형 쪽으로 이동하게 됩니다. 코드를 타이핑하는 손이 아니라, 어떤 원형이 지금 필요한지를 판단하는 눈이 병목이 됩니다.

ThakiCloud가 운용하는 Agent-Native Cloud인 Paxis는 바로 이 재편을 시스템 층위에서 구현합니다. Paxis는 Skills, Tools, Policies, Audit Logs를 일급 리소스로 다루며, 960개가 넘는 스킬을 BM25로 선택해 격리된 샌드박스에서 실행합니다. 체르니가 사람의 역할을 직함이 아니라 제품 순간에 맞춰 재조합한다고 말했듯, Paxis는 에이전트의 역량을 고정된 파이프라인이 아니라 그때그때의 작업에 맞춰 동적으로 조합합니다. 프로토타이퍼가 발상을 쏟아내면 빌더 역할의 에이전트가 프로덕션 코드로 전환하고, 스위퍼 역할의 검증 게이트가 결과를 정리하는 식의 분업이 스킬 하네스 안에서 그대로 재현됩니다.

인프라 쪽에서는 ThakiCloud의 ai-platform이 메인테이너 원형의 일을 대신 짊어집니다. K8s 기반 멀티테넌트 환경에서 Kueue로 GPU를 스케줄링하고, vLLM으로 모델을 서빙하며, 온프렘과 소버린 요구를 만족시키는 것은 정확히 성숙한 시스템의 보안·안정·효율을 지키는 메인테이너의 일입니다. 고객 조직은 이 부분을 플랫폼에 위임함으로써 자기 팀을 프로토타이퍼와 그로어 쪽에 더 배치할 수 있습니다.

채용 관점에서도 이 렌즈는 유용합니다. ThakiCloud는 이력서의 직함보다 지원자가 어떤 원형의 스펙트럼 위에 있는지를 봅니다. 지금 우리 제품 단계에 비어 있는 원형을 채우는 사람이 팀에 가장 큰 레버리지를 만들기 때문입니다. “무엇을 할 줄 아는가”만큼 “어떤 순간에 빛나는가”를 묻는 것입니다.

한계 및 반론

이 프레임워크를 무비판적으로 받아들이기 전에 반대편의 목소리도 들어야 합니다. 벤 비네거(Ben Vinegar)는 같은 논의를 두고 “사람들이 소프트웨어 조직이 어떻게 돌아가는지를 이제야 배우면서, 원래부터 있던 팀 역학을 AI 탓으로 잘못 돌리고 있다”고 지적했습니다. 날카로운 반론입니다. 프로토타이퍼와 메인테이너의 구분은 AI가 없던 시절에도 존재했고, 제품 생애주기에 따라 필요한 인재가 달라진다는 것도 새로운 통찰이 아닙니다.

원형 분류 자체의 한계도 있습니다. 사람을 다섯 개의 상자로 나누는 모든 시도가 그렇듯, 이 틀도 개인을 지나치게 단순화할 위험이 있습니다. 실제로는 한 사람이 프로젝트마다, 심지어 하루 안에서도 여러 원형을 오갑니다. 원형을 고정된 정체성으로 오해하면 “너는 스위퍼니까 새 아이디어는 내지 마”라는 식의 역효과가 납니다. 체르니 본인도 많은 사람이 원형을 넘나든다고 강조한 이유가 여기에 있습니다.

그럼에도 이 프레임워크가 가치 있는 이유는 예측력이 아니라 언어를 준다는 데 있습니다. “엔지니어 한 명 더”라는 모호한 요청 대신 “지금 우리에게 그로어가 부족하다”고 말할 수 있게 되면, 채용과 팀 구성의 대화가 훨씬 구체적으로 바뀝니다. AI가 직무의 기계적 층위를 걷어낼수록, 남는 것은 이런 원형 수준의 판단입니다. 미래의 제품 역할은 오늘의 도메인별 직함보다 이 원형에 더 가깝게 형성될지 모릅니다.

마치며

직무가 녹아내리는 것은 위기가 아니라 재편입니다. 프로토타이퍼, 빌더, 스위퍼, 그로어, 메인테이너라는 다섯 원형은 직함이 사라진 자리에 무엇이 남는지를 보여줍니다. 남는 것은 도구가 아니라 어떤 순간에 어떤 방식으로 기여하는가라는 본질입니다.

ThakiCloud는 사람과 에이전트가 이 원형들을 나눠 지는 조직을 만들고 있습니다. 에이전트가 반복 가능한 빌드와 유지의 상당 부분을 맡을수록, 사람은 지금 이 제품 단계에 어떤 원형이 필요한지를 읽어내는 일에 집중하게 됩니다. 그 판단이 다음 시대의 가장 귀한 역량입니다.

출처

• Boris Cherny, X(@bcherny), 2026-06-29: 원문 트윗
• Ben Vinegar, X(@bentlegen): 반론 트윗

개요

NVIDIA가 Alibaba의 Qwen3.6-27B을 NVFP4 4비트로 양자화한 nvidia/Qwen3.6-27B-NVFP4를 공개했습니다. 27B급 하이브리드 어텐션 추론 모델을 4비트로 눌러 가중치 메모리를 약 2.5배 줄이면서, FP8 기준선 대비 아홉 개 벤치마크 전부에서 차이를 1%p 이내로 유지합니다. 라이선스는 Apache 2.0입니다.

이 글에서 짚고 싶은 지점은 세 가지입니다. 첫째, 지난번 Gemma-4-26B-A4B-NVFP4가 사실상 Blackwell에서만 4비트 가속을 받았던 것과 달리, 이번 빌드는 모델카드에서 Hopper와 Blackwell을 함께 지원 대상으로 명시합니다. 이미 H100이나 H200을 굴리는 조직이 새 하드웨어를 사지 않고도 오늘 당장 시험해 볼 수 있다는 뜻입니다. 둘째, 이 모델은 텍스트만 다루는 순수 LLM이 아니라 텍스트와 이미지, 비디오를 입력받는 멀티모달 추론 모델입니다. 셋째, 컨텍스트가 262K 토큰까지 열려 있어 긴 문서와 장기 대화를 한 번에 받아냅니다.

ThakiCloud는 Kubernetes 위에서 Kueue로 GPU 쿼터를 관리하고 vLLM으로 모델을 멀티테넌트 서빙하는 플랫폼을 운영합니다. 그래서 “기존에 가진 GPU 위에서 더 큰 모델을, 더 많은 테넌트에게 얼마나 얹을 수 있는가”는 신기한 소식이 아니라 비용 모델과 직결되는 질문입니다. 이 글은 모델 팩트를 정리하고, NVFP4가 왜 Hopper까지 내려왔는지 따져 본 뒤, 서빙 경로와 우리 플랫폼에서의 쓸모를 솔직하게 리뷰합니다.

이 모델은 무엇인가

nvidia/Qwen3.6-27B-NVFP4는 Alibaba의 Qwen3.6-27B을 NVIDIA Model Optimizer(nvidia-modelopt v0.45.0)로 NVFP4 양자화한 버전입니다. 모델카드 기준 핵심 스펙은 다음과 같습니다.

주목할 부분은 아키텍처의 하이브리드 어텐션입니다. Gated DeltaNet은 선형 어텐션 계열로, 시퀀스 길이에 비례해 비용이 늘어나는 일반 어텐션과 달리 장문을 효율적으로 처리하도록 설계된 경로입니다. 여기에 표현력을 담당하는 Gated Attention을 섞어, 262K 같은 긴 컨텍스트를 감당하면서도 품질을 유지하는 절충을 취합니다. 서빙 시 --reasoning-parser qwen3를 요구한다는 점에서, 이 모델은 최종 답 이전에 추론 과정을 생성하는 리즈닝 모델이라는 것도 확인됩니다.

한 가지 정직하게 밝혀 둘 부분이 있습니다. 모델카드는 하이브리드 어텐션이라는 사실은 명시하지만, 정확한 레이어 수나 전문가(expert) 구성, 토큰당 활성 파라미터 같은 세부는 공개하지 않습니다. 따라서 이 글에서는 카드에 적힌 사실만 다루고, 미공개 수치는 추정하지 않습니다.

NVFP4 양자화: 무엇을 어떻게 누르는가

NVFP4는 NVIDIA가 밀어붙이는 4비트 부동소수점 포맷입니다. 가중치를 4비트 정수로 단순 절단하는 INT4와 달리, 작은 블록 단위로 FP8 스케일을 두는 마이크로스케일링 방식이라 4비트 수준의 메모리 절감을 누리면서도 정확도 손실을 작게 억제합니다.

이번 빌드에서 양자화 대상은 트랜스포머 블록 안 선형 연산자의 가중치와 활성값(activation)입니다. 비선형 층은 건드리지 않습니다. 모델카드는 파라미터당 비트 수를 16에서 4로 줄여 디스크와 GPU 메모리 요구량을 약 2.5배 감소시킨다고 밝힙니다. 27B 파라미터를 BF16으로 올리면 약 54GB가 필요한데, 약 2.5배 감소를 적용하면 체크포인트가 20GB 안팎으로 내려옵니다. 같은 GPU에 모델을 2배 이상 얹거나, 남은 메모리를 KV 캐시로 돌려 동시 세션을 늘릴 여지가 생깁니다.

여기서 지난 Gemma NVFP4 리뷰와 갈리는 대목이 나옵니다. Gemma 빌드는 소비자·프로 Blackwell(SM120)에서 NVFP4 MoE 커널이 아직 깨져 있어, 실제로 도는 소비자급 경로가 DGX Spark에 한정됐습니다. 반면 이번 Qwen3.6 빌드는 모델카드가 Hopper와 Blackwell을 함께 지원 대상으로 명시하고, 서빙도 vLLM의 --quantization modelopt 경로를 씁니다. 가중치뿐 아니라 활성값까지 양자화한 구성과 modelopt 서빙 경로가 맞물리면서, 데이터센터에 이미 깔린 H100·H200 위에서도 이 4비트 모델을 돌릴 수 있게 된 것입니다. “새 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 등"]

벤치마크: 4비트 손실은 얼마인가

모델카드는 NVFP4 양자화본과 FP8 기준선을 아홉 개 벤치마크에서 나란히 제시합니다.

아홉 항목 모두 FP8 대비 1%p 안쪽 차이입니다. MMLU Pro, HLE, τ²-Bench Telecom, IFBench는 오히려 NVFP4가 근소하게 높은데, 이는 측정 분산 범위로 읽는 편이 안전합니다. 방향성은 분명합니다. 4비트로 눌러도 품질이 사실상 유지된다는 것이고, NVFP4가 INT4 대비 갖는 강점이 여기서 드러납니다.

벤치 구성 자체도 이 모델의 성격을 보여 줍니다. τ²-Bench Telecom은 에이전트가 도구를 호출하며 과제를 수행하는 능력을, AA-LCR은 장문 컨텍스트 추론을, MMMU Pro는 멀티모달 이해를 측정합니다. 순수 지식 QA만이 아니라 에이전트 툴 사용과 장문, 멀티모달을 함께 겨냥한 모델이라는 뜻입니다. 다만 한국어 도메인 태스크는 공개 벤치에 드러나지 않으므로, 실제 도입 전에는 내부 평가셋으로 별도 검증을 권장합니다.

서빙 가이드

모델카드가 제시하는 권장 경로는 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는 262K 컨텍스트를 전부 여는 설정이며, KV 캐시 예산이 그만큼 커지므로 실제로 필요한 길이에 맞춰 낮춰 잡는 것이 메모리 효율에 유리합니다.

하드웨어는 Hopper 또는 Blackwell, OS는 Linux가 전제입니다. Hopper까지 지원한다는 점 덕분에, 데이터센터에 이미 있는 H100·H200 노드에서 별도 장비 없이 서빙 경로를 검증할 수 있습니다.

ThakiCloud 서빙 관점

ThakiCloud는 Kueue로 GPU 쿼터를 관리하고 vLLM으로 모델을 멀티테넌트 서빙하는 K8s 기반 AI/ML 플랫폼을 운영합니다. 이 모델이 우리 운용 모델에 주는 시사점은 인프라와 에이전트 두 방향에서 나옵니다.

기존 Hopper 자산 위에서 밀도를 2배 이상으로. 이 부분이 이번 빌드의 가장 실질적인 가치입니다. NVFP4가 Hopper까지 지원한다는 것은, 새 Blackwell 투자 없이 이미 보유한 H100·H200 위에서 4비트 이득을 볼 수 있다는 뜻입니다. 27B 모델의 가중치가 20GB 안팎으로 내려오면 같은 GPU에 더 많은 모델 인스턴스를 올리거나, 남는 메모리를 KV 캐시로 돌려 테넌트별 동시성 한도를 넉넉히 잡을 수 있습니다. Kueue 쿼터 관점에서는 같은 카드로 더 많은 워크로드를 받는 셈이라 단가가 그대로 내려갑니다.

멀티모달 추론 워커의 온프렘 후보. ThakiCloud의 에이전트 제어 평면인 Paxis는 Agent-Native Cloud로, 스킬을 격리 샌드박스에서 실행하고 모든 행동을 정책 게이트와 감사 로그로 통과시킵니다. 이 구조에서 다수의 워커가 문서를 읽고 도구를 호출하며 과제를 처리합니다. Qwen3.6-27B-NVFP4는 τ²-Bench Telecom 같은 에이전트 툴 사용 벤치에서 강하고, 텍스트뿐 아니라 이미지와 비디오를 입력받으며, 262K 컨텍스트를 감당합니다. 문서·화면·영상을 함께 다루는 멀티모달 워커, 툴 호출 루프의 말단 워커로 온프렘에서 돌리기에 적합한 후보입니다. 다만 우리 비용 규율대로 워커는 싸게 돌리되, fan-out 결과는 상위 모델의 검증 단계로 닫아 워커 환각이 누적되지 않게 해야 합니다.

온프렘·컴플라이언스 제안의 레퍼런스. Apache 2.0 라이선스에 단일 노드 서빙이 가능한 구성은, 데이터 외부 반출이 금지된 공공·금융 고객에게 그대로 제안할 수 있습니다. 국정원 요구 대응이나 소버린 AI 같은 제약 환경에서, 상용 API 없이 자체 GPU로 대형 멀티모달 추론 모델을 돌린다는 그림은 실질적인 도입 경로가 됩니다.

한계 및 반론

균형을 위해 짚을 부분입니다.

• 아키텍처 세부가 공개되지 않았습니다. 하이브리드 어텐션이라는 사실은 있지만 레이어 수, 전문가 구성, 활성 파라미터가 카드에 없습니다. 배치 효율과 메모리 상주량을 정밀하게 계산하려면 추가 정보가 필요합니다.
• 실측 처리량 수치가 없습니다. 이 글은 메모리 절감과 벤치마크 같은 카드 팩트에 근거합니다. 스트림당 토큰 속도나 동시성 한도는 하드웨어와 설정에 따라 크게 달라지므로, 도입 전 자체 워크로드로 재측정해야 합니다.
• 활성값 양자화의 변동성. 가중치뿐 아니라 활성값까지 4비트로 누르는 구성은 일부 분포가 치우친 워크로드에서 정확도 변동을 낳을 수 있습니다. 공개 벤치가 1%p 이내라 해도, 도메인 특화 태스크는 별도로 확인하는 편이 안전합니다.
• 멀티모달 서빙 경로의 성숙도. 이미지·비디오 입력을 실제 프로덕션에서 안정적으로 받으려면 전처리 파이프라인과 vLLM 멀티모달 경로의 성숙도를 함께 검증해야 합니다.
• 한국어 실사용 검증. 공개 벤치는 영어권 중심입니다. 한국어 RAG·툴콜 정확도는 내부 평가셋으로 따로 봐야 합니다.

그럼에도 Apache 2.0, Hopper까지 내려온 4비트 가속, 멀티모달 추론, 262K 컨텍스트라는 조합은 온프렘 서빙을 고민하는 조직에게 충분히 매력적인 선택지입니다. “새 하드웨어를 사야 4비트 이득을 본다”는 벽이 낮아졌다는 점만으로도, 이미 Hopper 플릿을 가진 팀에게는 오늘 검증해 볼 값어치가 있습니다.

참고 링크

• Qwen3.6-27B-NVFP4 모델카드 (Hugging Face)
• NVIDIA TensorRT Model Optimizer
• NVFP4 소개 (NVIDIA Developer)
• vLLM 공식 문서
• Gemma-4-26B-NVFP4 DGX Spark 리뷰 (ThakiCloud 블로그)