انتشرت نتيجة اختبار أداء بسرعة في تايم لاين المطورين الأسبوع الماضي. كانت تفيد بأن GLM-5.2 تم تشغيله على عقدة واحدة من AMD MI355X بمعدل 2,626 رمزاً (token) في الثانية، وبتكلفة أقل بأكثر من الضعف مقارنة بـ Blackwell. إذا نظرنا إلى الأرقام فقط، يبدو الأمر كدعاية اعتيادية من نوع “عتادنا أسرع”، لكن سبب أهمية هذه الحالة يكمن في مكان آخر. فهي تجمع بين تشغيل نموذج MoE ضخم بحجم 743B على معالج رسوميات من AMD وليس من NVIDIA، مع ضغطه إلى مستوى 4 بت دون فقدان في الدقة.

هذا المقال موجه لقادة الهندسة الذين يدرسون الخدمة المحلية (on-premise) والخدمة متعددة السحابات، وفرق منصات التعلم الآلي التي تفكر في اختيار مورّد وحدات معالجة الرسوميات، وعلماء البيانات الذين يحتاجون إلى تقييم اقتصاديات خدمة النماذج المفتوحة الأوزان الكبيرة. سنتحقق أولاً من المصدر الأصلي لمعرفة ما الذي قاسته هذه النتيجة بالضبط، ثم نحلل لماذا كان تكميم MXFP4 وتوازي MoE في SGLang حاسمين، وأخيراً نوضح أين تقف منصة ai-platform من ThakiCloud ضمن هذا التوجه.

لنبدأ بالخلاصة. الرسالة الحقيقية لهذا الاختبار ليست “AMD أسرع”، بل أن مكدس الخدمة (صيغة التكميم ومحرك الاستدلال) بدأ يفكّ قفل الاعتماد على مورّد عتاد واحد. وهذه النقطة التي ينفكّ فيها القفل هي بالضبط سبب وجود منصات الخدمة المحلية.

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

هذه نتيجة تلاقي ثلاثة عناصر: النموذج، والعتاد، ومكدس الخدمة الذي يربط بينهما.

النموذج، GLM-5.2. هو نموذج MoE مفتوح الأوزان أصدرته Z.ai (المعروفة سابقاً باسم Zhipu)، بإجمالي معلمات (parameters) يبلغ نحو 743B، ومعلمات نشطة لكل رمز تبلغ نحو 39B. يصل طول السياق إلى مليون رمز (1M)، ويُعرف بأنه قوي بشكل خاص في مهام برمجة الواجهة الأمامية (frontend). ورغم أن إجمالي معلماته كبير، فإن معلماته النشطة لا تتجاوز 39B بفضل بنية MoE، ما يجعله نموذجاً متفرقاً (sparse) ضخماً نموذجياً من نوع “يُخزَّن بثقل ويُستخدم بخفة”.

العتاد، AMD Instinct MI355X. هو أحدث مسرّع لمراكز البيانات من AMD، وتكمن قوته في سعة الذاكرة الكبيرة لكل وحدة معالجة رسوميات (GPU)، ما يتيح احتواء نماذج كبيرة على عدد أقل من وحدات المعالجة. تم قياس هذه الحالة على تكوين عقدة واحدة (8 وحدات معالجة رسوميات، مع توازي موتّرات tp=8). وللإشارة، فإن استهلاك الذاكرة لكل وحدة معالجة رسوميات وفق FP8 يبلغ نحو 89 جيجابايت، أي نصف مستوى BF16 البالغ نحو 175 جيجابايت.

مكدس الخدمة، تكميم MXFP4 (عبر AMD Quark) مع SGLang. هنا يكمن جوهر الموضوع. تم تحويل نموذج GLM-5.2 الأصلي بصيغة BF16 إلى صيغة MXFP4 (فاصلة عائمة دقيقة التدرج بـ 4 بت) باستخدام أداة التكميم من AMD المسماة Quark، ويذكر المصدر الأصلي أن هذا التحويل كان “بلا فقدان” (lossless) في الدقة مقارنة بتكميم FP8 الرسمي. أما محرك الاستدلال المختار فكان SGLang. والسبب واضح: من بين الأطر التي جرى اختبارها، كان SGLang الوحيد الذي يدعم MXFP4 بشكل أصلي، واستطاع من خلال خيار --enable-moe-ep توزيع الخبراء (experts) على وحدات المعالجة ثم توجيه الرموز عبر NVLink/NVSwitch، أي تفعيل توازي MoE بالشكل الصحيح.

وفيما يلي ملخص لخط الأنابيب الكامل.

flowchart TB
    A[GLM-5.2 الأصلي<br/>BF16 · 743B MoE] --> B[تكميم MXFP4<br/>عبر AMD Quark]
    B --> C{التحقق من الدقة}
    C -->|بلا فقدان مقارنة بـ FP8 الرسمي| D[محرك خدمة SGLang]
    C -->|في حال حدوث فقدان| A
    D --> E[توازي خبراء MoE<br/>--enable-moe-ep]
    E --> F[عقدة MI355X واحدة<br/>8 GPU · tp=8]
    F --> G[تدفق واحد 213 tok/s]
    F --> H[إجمالي العقدة 2,626 tok/s]

يكمن الاختلاف عن النهج التقليدي في نقطتين. الأولى، أن صيغة التكميم هي MXFP4 وليست FP8. فتقليل عدد البتات عادة ما يؤدي إلى اضطراب الدقة، لكن أسلوب التدرج الدقيق (microscaling) يضع مقياساً منفصلاً لكل كتلة صغيرة، وهو تصميم يهدف إلى الحفاظ على الجودة حتى عند مستوى 4 بت. الثانية، أن كل هذا تم تشغيله خارج نظام CUDA البيئي، أي على AMD ROCm.

نتائج اختبار الأداء الفعلية

الأرقام التي نشرها المصدر الأصلي (Wafer.ai) تنقسم إلى مسارين. ينبغي النظر إليهما بشكل منفصل لأن ظروف حمل العمل تختلف بينهما.

سيناريو زمن استجابة تدفق واحد. في طلب واحد بمدخل 10 آلاف رمز ومخرج 1.5 ألف رمز، بلغ المعدل 213 رمزاً في الثانية. يمثل هذا الرقم حالة مستخدم واحد يُدخل سياقاً طويلاً ويتلقى الإجابة عبر البث المباشر (streaming).

سيناريو الإنتاجية الإجمالية للعقدة. في ظروف مدخل 20 ألف رمز، ومخرج ألف رمز، ومعدل إصابة ذاكرة تخزين مؤقتة (cache) بنسبة 60%، تمت معالجة 2.4 طلب في الثانية (2.4 rps)، محققةً إنتاجية إجمالية بلغت 2,626 tok/s لكل عقدة. وفي هذه الحالة، ظل زمن الوصول إلى أول رمز (TTFT) عند 5 ثوانٍ أو أقل. تمثل هذه الظروف حالة قريبة من الخدمة الإنتاجية التي تدفع طلبات متعددة في آن واحد.

أما فيما يخص التكلفة، فتذكر Wafer.ai أن تكوين MXFP4 هذا يحقق تكلفة أقل بأكثر من الضعف مقارنة بـ Blackwell، أي إنتاجية لكل دولار أعلى بأكثر من الضعف. وفي تحليل منفصل، أفادت SemiAnalysis (InferenceX) أن MI355X، ضمن تكوين مختلف يستخدم SGLang وFP8، أرخص بنسبة تصل إلى 40% لكل مليون رمز مقارنة بـ B200. وبما أن صيغة التكميم وحمل العمل مختلفان بين الرقمين، فمن الأدق عدم مقارنتهما مباشرة، بل قراءتهما على أنهما “مصدران مستقلان يشيران إلى نفس الاتجاه العام”، وهو التنافسية السعرية لـ MI355X. ولا بد من التوضيح أن مؤشر التكلفة في الرسم البياني أعلاه هو تصوير بصري لادعاء Wafer.ai بـ”أكثر من الضعف”، وهو مؤشر نسبي وليس سعراً مطلقاً.

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

لماذا كان MXFP4 وSGLang حاسمين

الأهم من العتاد في هذه النتيجة هو اختيار مكدس الخدمة. وهناك ثلاثة أسباب لذلك.

أولاً، يتيح التكميم بـ 4 بت احتواء نماذج MoE الضخمة على عدد أقل من وحدات المعالجة. تحميل 743B معلمة بصيغة BF16 يتطلب مئات الجيجابايتات من الذاكرة. وعند خفضها إلى MXFP4، تنخفض ذاكرة الأوزان بشكل كبير، ما يتيح وضع النموذج نفسه في عدد أقل من وحدات المعالجة وضمن عقدة أضيق. وبما أن جزءاً كبيراً من تكلفة الخدمة يتحدد بحسب “عدد وحدات المعالجة اللازمة لاحتواء هذا النموذج”، فإن التكميم بـ 4 بت القريب من عدم الفقدان ينعكس مباشرة على سعر الوحدة.

ثانياً، يجعل توازي MoE عملية الحساب مقتصرة على المعلمات النشطة فقط. في نماذج MoE، لا يُفعَّل لكل رمز سوى عدد قليل من الخبراء. ويقوم خيار --enable-moe-ep في SGLang بتوزيع الخبراء على وحدات المعالجة وإرسال الرموز إلى الخبير المعني عبر وصلات بينية عالية السرعة. والمفتاح الحقيقي للإنتاجية هو إحياء بنية “حساب 39B النشطة فقط بدل حساب كامل 743B” على مستوى توزيع العتاد.

ثالثاً، تناغم الصيغة مع المحرك يفك قيد الاعتماد على مورّد واحد. هنا يكمن الاستنتاج الهادئ لهذا الإنجاز. فبمجرد توفر محرك يدعم MXFP4 بشكل أصلي (SGLang) وأداة تحوّل إلى تلك الصيغة بلا فقدان (AMD Quark)، أصبحت الخدمة على مستوى الإنتاج ممكنة على ROCm وليس فقط على CUDA. وكلما زاد توحيد مكدس الخدمة، تحوّل سؤال “أي مورّد لوحدة المعالجة” من مسألة أداء إلى مسألة توفر وسعر. وهذا هو التحول الذي يعيد قوة التفاوض إلى المشتري.

دلالات التطبيق على منتجات ThakiCloud

ترتبط هذه الحالة ارتباطاً مباشراً باستراتيجية ai-platform من ThakiCloud. فمنصة ai-platform هي بنية تحتية لخدمات AI/ML SaaS قائمة على Kubernetes، تقوم بخدمة النماذج في بيئات عملاء متنوعة وجدولة موارد وحدات المعالجة عبر Kueue. ومن هذا المنظور، تحمل هذه النتيجة ثلاث دلالات.

الخدمة متعددة الموردين لم تعد تنازلاً في الأداء. في الماضي، كان الافتراض القائل بأن “الأداء لا يتحقق إلا مع NVIDIA” يغلق عملياً باب اختيار المورّد. وحالة GLM-5.2 على MI355X دليل على تزعزع هذا الافتراض. فإذا استطاعت ai-platform تجريد vLLM وSGLang كخلفيات خدمة (backends)، وجدولة عقد NVIDIA وAMD معاً فوقها، فسيتمكن العملاء من توجيه طلباتهم إلى أرخص عتاد متاح حسب حمل العمل. وفي عناقيد (clusters) متعددة المستأجرين، هذه المرونة تعني مباشرة تنافسية في سعر الخدمة.

التكميم أصبح شاغلاً من الدرجة الأولى للمنصة. الصيغ منخفضة البتات القريبة من عدم الفقدان مثل MXFP4 تتيح تحقيق “نفس اتفاقية مستوى الخدمة (SLA) بعدد أقل من وحدات المعالجة”. وبالنسبة للعملاء الذين يعتمدون الخدمة المحلية، خصوصاً في بيئات القطاع العام والمالي المحلية التي تتطلب سيادة البيانات والاستضافة الذاتية (self-hosting)، فإن كمية وحدات المعالجة المتاحة نفسها تشكل قيداً. والتكميم بلا فقدان يتيح تشغيل نماذج أكبر ضمن هذا القيد، لذا فإن استيعاب ai-platform لسلاسل أدوات مثل Quark كخطوة قياسية في خط أنابيب الخدمة يُعد توجهاً طبيعياً.

كفاءة التكلفة هي الحجة الأساسية لعرض الخدمة المحلية. أكثر سؤال يُطرح على ThakiCloud عند اقتراح الخدمة المحلية والسحابة السيادية هو “إذاً، ما مدى الرخص؟”. واختبارات الأداء المستقلة التي تشير إلى تكلفة أقل بأكثر من الضعف مقارنة بـ Blackwell، وأرخص بنسبة تصل إلى 40% مقارنة بـ B200، يمكن استخدامها كدليل على أن تنويع العتاد فوق مكدس خدمة مناسب يخفض التكلفة الإجمالية للملكية (TCO) فعلياً. وبالطبع فإن هذا يفترض إمكانية إعادة الإنتاج في بيئة العميل، وهذه القدرة على إعادة الإنتاج هي بحد ذاتها القيمة التي تقدمها المنصة.

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

من أجل التوازن، نستعرض أسباب عدم المبالغة في الثقة بهذه النتيجة.

أولاً، اختبار الأداء هو لقطة لظروف محددة. رقم 2,626 tok/s جاء من حمل عمل محدد بمدخل 20 ألف رمز، ومخرج ألف رمز، ومعدل إصابة ذاكرة تخزين مؤقتة 60%. وفي حمل عمل تتركز فيه توليدات طويلة على مطالبات (prompts) قصيرة، أو حيث يكون معدل إصابة الذاكرة المؤقتة منخفضاً، ستختلف الإنتاجية بشكل كبير. والفجوة بين 213 tok/s للتدفق الواحد و2,626 tok/s لإجمالي العقدة تُظهر بالفعل هذه الحساسية.

ثانياً، ادعاء “عدم الفقدان” في MXFP4 محدود بنطاق التحقق. يذكر المصدر الأصلي أنه بلا فقدان مقارنة بـ FP8 الرسمي، لكن من المرجح أن هذا مبني على مجموعة تقييم محددة. وتأثير التكميم بـ 4 بت قد يختلف حسب المهمة، سواء في البرمجة أو الرياضيات أو السياقات الطويلة، لذا يجب قبل الاعتماد الفعلي قياس تدهور الجودة مباشرة باستخدام مجموعة تقييم خاصة بالشركة.

ثالثاً، لا يزال مستوى نضج تشغيل نظام ROCm البيئي متغيراً غير محسوم. نجاح اختبار الأداء وثبات التشغيل الموثوق في بيئة الإنتاج أمران مختلفان. فلا تزال هناك فجوة مع نظام CUDA البيئي في توافق برامج التشغيل (drivers) والنواة (kernel) والمكتبات، وفي نضج أدوات التعامل مع الأعطال. والحكم على التكلفة الإجمالية للملكية بالاعتماد فقط على سعر العتاد قد يغفل تكاليف الطاقم التشغيلي وتوقف الخدمة.

ومع ذلك، فإن الاتجاه العام واضح. فتوحيد مكدس الخدمة يوسّع خيارات العتاد المتاحة، والمستفيد من هذا التحول هو منصات الخدمة، وعملاؤها، القادرون على الإفلات من قيد المورّد الواحد واختيار العتاد الأمثل لكل حمل عمل. وهذا بالضبط ما تستهدفه منصة ai-platform من ThakiCloud.

المصادر

• Wafer.ai, “Performance per dollar is getting faster and cheaper”: https://www.wafer.ai/blog/glm52-amd
• SemiAnalysis InferenceX, “AMD MI355X GLM-5 Inference: Up to 40% Cheaper per Million Tokens than B200 on SGLang FP8”: https://inferencex.semianalysis.com/blog/mi355x-glm5-fp8-sglang-40-cheaper-than-b200
• LMSYS, “Win on TCO: How AMD Instinct MI355X Achieves Cost-Competitive Distributed Inference Through SGLang with MoRI”: https://www.lmsys.org/blog/2026-05-28-mori/
• بطاقة نموذج GLM-5.2 (743B / 39B نشطة · MoE · سياق 1024K): https://recipes.vllm.ai/zai-org/GLM-5.2

مدخل: “ألا يكفي الآن أن نستغني عن الضبط الدقيق؟”

كل من يبني منصة ذكاء اصطناعي أو يبيعها اليوم لا بد أنه سمع هذا السؤال مرة على الأقل. بما أن النماذج الطليعية أصبحت بهذا القدر من الجودة، وبما أنه يمكن حقن المعرفة الخاصة بالمجال عبر المهارات (skills) وسقالات الوكلاء (agentic scaffolding)، فهل يستحق الأمر إنفاق المال والوقت لتدريب نموذج مستقل؟ طرحنا على أنفسنا السؤال ذاته. لذلك تحققنا منه بالاعتماد حصرا على مصادر نُشرت خلال شهر واحد بالضبط، من 5 يونيو إلى 5 يوليو 2026.

المنهجية بسيطة. قسّمنا البحث إلى أربعة محاور: أدلة انتفاء الحاجة إلى الضبط الدقيق، أدلة استمرار بقائه، تحركات السوق والموردين، ونقاشات الممارسين الميدانيين. ثم أعدنا التحقق من ستة ادعاءات محورية تؤثر في اتجاه القرار عبر تدقيق تفنيدي (adversarial) مستقل. من أصل ستة، تأكدت أربعة ادعاءات بالكامل وتأكد ادعاءان جزئيا، ولم يُفنَّد أي منها. هذا المقال مبني حصرا على الحقائق التي اجتازت هذا التحقق.

الخلاصة المسبقة هي التالية: منتج الضبط الدقيق يحتضر بالفعل، لكن الذي يحتضر هو قطاع محدد هو واجهة SFT ذاتية الخدمة، بينما تُعاد صياغة التقنية ذاتها ضمن منتج مختلف تماما هو ملكية النموذج واقتصاديات عمال الوكلاء (agent workers)، بل تزداد قيمتها العلاوية في هذا الاتجاه.

ما الذي يموت فعلا

الحدث الأكثر دلالة هو قرار OpenAI. أعلنت الشركة في 7 مايو 2026 حظر إنشاء مهام ضبط دقيق جديدة للمؤسسات الجديدة، وابتداء من 2 يوليو انتقلت إلى مرحلة منع وصول المؤسسات غير النشطة لأكثر من 60 يوما، وفي 6 يناير 2027 ستُنهي بالكامل إمكانية إنشاء مهام ضبط دقيق جديدة حتى للعملاء النشطين الحاليين. يبقى الاستدلال (inference) على النماذج المضبوطة دقيقا سابقا متاحا إلى أن يُلغى النموذج الأساسي، لكن مسار تشغيل تدريب جديد يُغلق.

اللافت هو البند الاستثنائي. الضبط الدقيق القائم على التعلم المعزز، أي RFT، يُفصل في مسار منفصل ويستمر رغم هذا الإغلاق. أوقفت OpenAI الضبط الدقيق المُوجَّه (SFT) بينما أبقت على التخصيص عالي القيمة الذي يمتلك مكافأة قابلة للتحقق. أما Anthropic فلم تفتح أصلا واجهة ضبط دقيق ذاتية الخدمة في واجهتها العامة، وتدفع باتجاه Agent Skills كمسار قياسي يحمّل المعرفة الخاصة بالمجال ديناميكيا من بنية مجلدات. وهكذا فإن أكبر موردَي نماذج يشيران إلى الاتجاه ذاته.

إشارات الأسعار تحمل الرسالة نفسها. منافسة الأسعار على الضبط الدقيق بتقنية LoRA بين Together AI وFireworks AI تعني أن هذا القطاع أصبح سلعة أساسية (commodity) وتقلّصت هوامشه. أصبح تشغيل الضبط الدقيق المُوجَّه بخفة وذاتيا أمرا سهلا تقنيا، وبالتالي فقد جاذبيته كمشروع تجاري.

لكن لا يوجد دليل على أن المهارات حل شامل أيضا

على عكس الشعور السائد، الأدلة الأكاديمية على أن المهارات تحلّ محل الضبط الدقيق بشكل عام لا تزال ضعيفة. أظهرت دراسة SkillJuror، المقدَّمة ضمن هذه النافذة الزمنية، أن تقديم المهارات بصيغة مُهيكَلة يرفع معدل اجتياز التحقق بمقدار 4.1 نقطة مئوية مقارنة بالصيغة المسطّحة. الأثر حقيقي لكنه ليس كبيرا. أما الدراسة الخلفية الأسبق قليلا، SkillsBench، فتحمل نتيجة أكثر إثارة للاهتمام: المهارات المُنسَّقة (curated) بعناية ترفع معدل الاجتياز بمعدل 16.2 نقطة مئوية في المتوسط، لكن التباين بين المجالات متطرف، إذ يتراوح بين سلبي وحتى +51.9 نقطة مئوية، وفي 16 من أصل 84 مهمة تراجع الأداء فعليا. والأهم أن المهارات التي كتبها النموذج بنفسه لم تُحدث أثرا إيجابيا في المتوسط.

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

إشارات معاكسة تماما خلال شهر يونيو

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

أولا، تحوّلت مخاطر الاعتماد الجيوسياسي على واجهات النماذج الطليعية إلى حدث واقعي مُقاس. في 12 يونيو 2026، وبناء على توجيه من ضوابط التصدير الأمريكية، عطّلت Anthropic نموذجَي Fable 5 وMythos 5 على مستوى العالم بأكمله. تعذّر تطبيق فلترة الجنسية في الزمن الحقيقي، فتأثر عمليا جميع المستخدمين وليس فقط العملاء خارج الولايات المتحدة، واستغرق رفع التعطيل 19 يوما. أي شركة وضعت أعمالها الجوهرية على واجهة نموذج طليعي واحدة، تكون قد تلقّت في يونيو درسا مدته 19 يوما.

ثانيا، منظومة الأوزان المفتوحة تُصمَّم اليوم على أساس الضبط الدقيق. أعلنت NVIDIA في 4 يونيو عن Nemotron 3 Ultra، وهو نموذج خليط خبراء (MoE) بحجم إجمالي 550 مليار معلمة ونشِط منها 55 مليارا، ويأتي مزودا افتراضيا بوصفات LoRA SFT وSFT الكامل وتعلم معزز GRPO. رخصة OpenMDW-1.1 تسمح صراحة بتسويع وإعادة توزيع النماذج المشتقة من الضبط الدقيق. الهدف من تصميم هذه الرخصة هو أن تملك الشركات وتبيع النموذج الذي دربته على بياناتها الخاصة. وفي 29 يونيو، أطلقت Palantir وNVIDIA معا منتجا مدمجا للذكاء الاصطناعي السيادي يتيح ضبط الأوزان المفتوحة دقيقا وتشغيلها داخل بيئة معزولة عن الشبكة (air-gapped). في الاتحاد الأوروبي، طُرح مشروع قانون لتصنيف أحمال العمل العامة وفق درجات ضمان السيادة، وفي كوريا كذلك مشاريع الذكاء الاصطناعي السيادي قيد التنفيذ.

ثالثا، ظهرت حالة انتصار عملي لعامل الضبط الدقيق. في معيار قياس نشرته شركة الذكاء الاصطناعي القانوني Harvey بالتعاون مع Fireworks، حقق نموذج Kimi K2.6 المضبوط بتقنية SFT فقط، ودون أي مساعدة من نموذج طليعي، معدل اجتياز إجمالي بلغ 15% على 100 مهمة، متجاوزا نموذج Claude Opus 4.7 المستقل الذي حقق 14%، وبتكلفة أقل بنحو 11.4 مرة. أما التركيبة الهجينة التي تستدعي نموذجا طليعيا انتقائيا إلى جانب عامل الضبط الدقيق، فحققت أعلى معدل اجتياز عند 18%. رغم أن هذا معيار قياس صادر عن المورّد نفسه، فإنه دليل عملي على أن الجمع بين عامل مضبوط دقيقا وتصعيد انتقائي إلى نموذج طليعي، في مجال ضيق، يحقق الجودة والتكلفة معا.

رابعا، تفوق النماذج الصغيرة في مجالات ضيقة لا يزال يتكرر. في ورقة بحثية نُشرت في 11 يونيو، أظهر نموذج Mistral-7B المضبوط دقيقا بتقنية QLoRA تفوقا في التحقق من الادعاءات الطبية الحيوية على GPT-4o وGPT-5، بفارق يصل إلى 12 نقطة مئوية في مقياس F1. وقد استُخدم لهذا التدريب 1,008 عينة فقط.

السوق ينقسم إلى ثلاثة مسارات

عند تراكب هذه الإشارات معا، يتضح أن السوق لا ينقسم بين “الموت أو البقاء” فحسب، بل ينقسم إلى ثلاثة مسارات.

flowchart TB
    A["سوق الضبط الدقيق<br/>إعادة تشكّل 2026"] --> B["المسار 1<br/>واجهة SFT ذاتية الخدمة"]
    A --> C["المسار 2<br/>النموذج السيادي المملوك المخصص"]
    A --> D["المسار 3<br/>الضبط الدقيق بالتعلم المعزز واقتصاديات العمال"]
    B --> B1["مرحلة انكماش<br/>إغلاق تدريجي من OpenAI<br/>تحوّل LoRA إلى سلعة أساسية"]
    C --> C1["ارتفاع علاوة القيمة<br/>منتجات ضبط دقيق معزولة عن الشبكة<br/>مشروع قانون تصنيف السيادة<br/>رخص مصممة على أساس الضبط الدقيق"]
    D --> D1["نمو جديد<br/>RFT يبقى في مسار منفصل<br/>عامل ضبط دقيق + تصعيد لنموذج طليعي"]
    C1 --> E["ملكية النموذج كمنتج"]
    D1 --> E

المسار الأول، واجهة SFT ذاتية الخدمة، في مرحلة انكماش. طول السياق الكبير للنماذج الطليعية، ودعمها الأصلي لاستدعاء الأدوات، والمخرجات المُهيكَلة، استوعبت جزءا كبيرا من مشكلتَي الالتزام بالصيغة ومفردات المجال، اللتين كانتا سبب وجود الضبط الدقيق في الأصل. المسار الثاني، النموذج المخصص المملوك، يُعاد تشكيله كخدمة علاوية (premium). عصر الضبط الدقيق الخفيف عبر الواجهة البرمجية ينتهي، لكن التخصيص الثقيل الذي تملك فيه الشركة نموذجها وتتحكم فيه يزداد قيمة. المسار الثالث طلب جديد يخلقه عصر الوكلاء. كلما تحسّنت أدوات التنسيق (orchestrators)، تزداد استدعاءات العمال منخفضي التكلفة المسؤولين عن المهام الفرعية المتكررة، ولا يمكن تحمّل استدعاء نموذج طليعي في كل شريحة من هذه الاستدعاءات.

الشروط الخمسة التي يفوز فيها الضبط الدقيق بوضوح

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

1. عندما تكون المهمة ضيقة ومتكررة وصيغة المخرجات ثابتة. التصنيف والتحقق والاستخراج المُهيكَل أمثلة نموذجية، والحالة التي حققت تفوقا بـ12 نقطة مئوية بـ1,008 عينة فقط من هذا النوع.
2. عندما توجد مكافأة قابلة للتحقق. إذا توفرت تغذية راجعة من البيئة تسمح بتطبيق GRPO أو RFT، فهذا أفضل من التعلم المُوجَّه، وهو السبب الذي جعل OpenAI تُبقي على RFT وحده بعد إيقاف SFT.
3. عندما يكون تكرار الاستدعاء مرتفعا والتكلفة والزمن هما القيد المُهيمن. شرائح عمال الوكلاء تندرج هنا، وفارق التكلفة بمقدار 11.4 مرة يصبح حاسما كلما ازداد الحجم.
4. عند وجود متطلبات سيادة بيانات أو تنظيم أو شبكة معزولة. المجالات العامة والمالية والدفاعية تكون فيها خيارات الواجهة الخارجية محدودة أصلا.
5. عندما تشكّل واجهة النموذج الطليعي نفسها مخاطرة في سلسلة التوريد. كما أظهر حادث التعطيل لمدة 19 يوما، لم تعد ضوابط التصدير وتغيرات السياسات سيناريو افتراضيا.

في المقابل، لم نجد ضمن هذه النافذة الزمنية أي دليل على أن النموذج المضبوط دقيقا تفوّق على النموذج الطليعي في الاستدلال المفتوح المجال، أو المعرفة الحديثة، أو معالجة الذيل الطويل (long-tail). في هذه المجالات، التقييم الصادق هو ترك الساحة للمهارات وللنماذج الطليعية.

دلالات هذا التحليل من منظور منتجات ThakiCloud

يتقاطع هذا الانقسام تماما مع اتجاه منتجَينا الرئيسيَّين.

من منظور ai-platform، ما يتطلبه المساران 2 و3 هو في النهاية بنية تحتية للتدريب والخدمة تعمل داخل شبكة العميل المعزولة. تُشغّل منصة ai-platform لدى ThakiCloud خمسة أنابيب تدريب هي SFT وCPT وDPO وGRPO وGKD، فوق جدولة وحدات معالجة الرسوميات (GPU) القائمة على Kubernetes وKueue. من المهم بالنسبة لنا أن هذا البحث أكد أن المحورين اللذين بدأ السوق يعترف بعلاوة قيمتهما هما GRPO المبني على مكافأة قابلة للتحقق، والتقطير (distillation) الذي ينقل مخرجات النموذج الطليعي إلى نموذج صغير. وكلما تزايدت متطلبات النشر الداخلي والسيادة، يتحوّل الضبط الدقيق من ميزة في واجهة برمجية إلى قضية قدرة بُنى تحتية، وهذا هو الموقع الذي نقف فيه.

من منظور Paxis، يوضّح هذا الاستنتاج بجلاء تقسيم الأدوار بين المهارات والضبط الدقيق. Paxis هو مستوى التحكم السحابي الأصلي للوكلاء (Agent-Native Cloud) لدى ThakiCloud، يختار من بين أكثر من 960 مهارة عبر خوارزمية BM25 وينفذها داخل صندوق رملي معزول، بحيث يمر كل سلوك عبر بوابات سياسة وسجلات تدقيق. الدرس الذي كشفته معايير قياس المهارات، وهو أن المهارات فعّالة فقط عند تنسيقها بعناية، وأن المهارات ذاتية التوليد غير موثوقة، يؤكد أن استثمار Paxis في تنسيق المهارات وحلقات التحقق كان الاتجاه الصحيح. وفي الوقت ذاته، يوضّح نمط حالة Harvey أن عامل الضبط الدقيق اقتصادي في المهام الفرعية المتكررة لأسطول الوكلاء، وأن التنسيق القائم على المهارات وعمال الضبط الدقيق ليسا في علاقة تنافس، بل طبقتان لبنية واحدة. إنه تصميم لا يتخلى عن النموذج الطليعي بل يستخدمه باقتصاد.

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

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

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

خاتمة

الشعور القائل بأن “الضبط الدقيق لم يعد ضروريا” صحيح فقط بنسبة النصف. صحيح أن SFT كسلعة أساسية يتراجع فعلا، لكن الأحداث الموثّقة خلال شهر يونيو 2026 تُظهر أن الضبط الدقيق يُعاد تشكيله في اتجاهين هما ملكية النموذج واقتصاديات عمال الوكلاء. حان وقت تغيير السؤال. لم يعد السؤال “هل نُجري ضبطا دقيقا أم لا”، بل “في أي الشروط نملك النموذج”، وهذا هو السؤال الصحيح للنصف الثاني من عام 2026.

المراجع

• NVIDIA Debuts Nemotron 3 Family of Open Models (NVIDIA Newsroom, 2026-06-04)
• تقرير Nemotron 3 Ultra التقني (arXiv:2606.15007)
• Small LLMs for Biomedical Claim Verification (arXiv:2606.12854, 2026-06-11)
• US orders Anthropic to disable AI models for all foreign nationals (Al Jazeera, 2026-06-13)
• Anthropic says Trump admin has lifted export controls (CNBC, 2026-06-30)
• SAGE-OPD: تقطير انتقائي قائم على السياسة (arXiv:2606.19659, 2026-06-17)
• SkillJuror (arXiv:2606.11543, 2026-06)
• How Harvey & Fireworks Beat Closed Source on Cost + Quality (Fireworks AI Blog)
• OpenAI is winding down the fine-tuning API (OpenAI Developer Community)
• Linux Foundation Releases OpenMDW-1.1 (Linux Foundation, 2026-05-28)
• SkillsBench (arXiv:2602.12670, دراسة خلفية)
• SkillOpt: Agent skills as trainable parameters (Microsoft Research, دراسة خلفية)

Last week a benchmark result spread quickly across developer timelines. It claimed that GLM-5.2 was served on a single AMD MI355X node at 2,626 tokens per second, and at a cost more than twice as low as Blackwell. Taken at face value, the numbers sound like the usual “our hardware is fast” marketing, but what makes this case interesting is something else entirely. It is the combination of running a 743B-scale MoE model, not on NVIDIA but on AMD GPUs, compressed down to roughly 4-bit precision without losing accuracy.

This post is written for engineering leaders evaluating on-premises and multi-cloud serving, ML platform teams weighing GPU vendor choices, and data scientists who need to work out the serving economics of large open-weight models. We will first check exactly what the original source measured, then break down why MXFP4 quantization and SGLang’s MoE parallelism were decisive, and finally lay out where ThakiCloud’s ai-platform stands in relation to this trend.

Here is the conclusion up front. The real message of this benchmark is not “AMD is fast.” It is that the serving stack, the quantization format and the inference engine, is starting to break open the hardware vendor lock-in. And that exact point where the lock-in breaks open is precisely why on-premises serving platforms exist.

What This Technology Is

This result comes from three pieces fitting together: the model, the hardware, and the serving stack that bridges the two.

The model: GLM-5.2. This is an open-weight MoE model released by Z.ai (formerly Zhipu), with roughly 743B total parameters and about 39B parameters active per token. Its context length reaches 1 million tokens (1M), and it is regarded as particularly strong at frontend coding tasks. Because the total parameter count is huge while only 39B parameters are active, it is a textbook example of a large sparse model: heavy to store, light to actually run.

The hardware: AMD Instinct MI355X. This is AMD’s newest data center accelerator, and its strength is the large memory capacity per GPU, which lets you fit a large model onto fewer GPUs. This case was measured on a single node configuration (8 GPUs, tensor parallelism tp=8). For reference, memory usage per GPU at FP8 is about 89GB, roughly half of the approximately 175GB required at BF16.

The serving stack: MXFP4 quantization (AMD Quark) plus SGLang. This is where the core of the story lies. The original BF16 GLM-5.2 was converted to the MXFP4 format (a 4-bit microscaling floating-point format) using AMD’s quantization toolkit, Quark, and the original source states that this conversion was lossless relative to the official FP8 quantization, with no accuracy degradation. For the inference engine, they chose SGLang. The reason is clear: among the frameworks tested, SGLang was the one that natively supported MXFP4, and it was able to properly drive MoE parallelism, distributing experts across GPUs with the --enable-moe-ep option and routing tokens between them over NVLink/NVSwitch.

The full pipeline looks like this:

flowchart TB
    A[GLM-5.2 original<br/>BF16 · 743B MoE] --> B[MXFP4 quantization<br/>via AMD Quark]
    B --> C{Accuracy check}
    C -->|Lossless vs official FP8| D[SGLang serving engine]
    C -->|If degraded| A
    D --> E[MoE expert parallelism<br/>--enable-moe-ep]
    E --> F[MI355X single node<br/>8 GPUs · tp=8]
    F --> G[Single stream 213 tok/s]
    F --> H[Node aggregate 2,626 tok/s]

There are two ways this differs from the conventional approach. First, the quantization format is MXFP4, not FP8. Cutting bits further usually destabilizes accuracy, but the microscaling approach assigns a separate scale to each small block, which is designed to preserve quality even at roughly 4-bit precision. Second, all of this ran outside the CUDA ecosystem entirely, on AMD ROCm.

The Actual Benchmark Results

The numbers published by the original source (Wafer.ai) fall into two categories. Since the workload conditions differ, they need to be looked at separately.

Single-stream latency scenario. For a single request with 10k input tokens and 1.5k output tokens, it produced 213 tokens per second. This corresponds to the situation of one user feeding in a long context and receiving the answer as a stream.

Node-aggregate throughput scenario. Under conditions of 20k input tokens, 1k output tokens, and a 60% cache hit rate, it processed 2.4 requests per second (2.4 rps) while delivering an aggregate throughput of 2,626 tok/s per node. TTFT (time to first token) was kept under 5 seconds throughout. This is closer to the conditions of production serving, where many requests are pushed in concurrently.

The cost claim goes like this. Wafer.ai states that this MXFP4 configuration costs more than twice as low as Blackwell, meaning throughput per dollar is more than double. In a separate analysis, SemiAnalysis (InferenceX) reported that, under a different SGLang FP8 configuration, MI355X is up to 40% cheaper per million tokens than B200. Since the two figures come from different quantization formats and workloads, it is more accurate to read them not as a direct comparison but as “multiple independent sources pointing in the same direction, namely MI355X’s cost competitiveness.” The cost index in the chart above visualizes Wafer.ai’s “more than 2x” claim, and we note that it is a relative indicator, not an absolute price.

One caveat is needed here. These numbers are not something we reproduced by securing an actual MI355X node ourselves; they are the measurements published by the original source. We do not have physical access to an MI355X, so we were unable to independently reproduce these results, and every figure in this post is therefore a cited value. We plan to cover a same-conditions reproduction separately once we have the hardware.

Why MXFP4 and SGLang Were Decisive

What matters more than the hardware in this result is the choice of serving stack. There are three reasons.

First, 4-bit quantization fits a large MoE model onto fewer GPUs. Loading 743B parameters at BF16 requires memory on the order of hundreds of GB. Dropping to MXFP4 drastically reduces weight memory, so the same model can fit onto fewer GPUs, into a smaller node. A large share of serving cost is determined by “how many GPUs does it take to hold this model,” so near-lossless 4-bit quantization translates directly into unit cost.

Second, MoE parallelism keeps computation limited to the active parameters. In an MoE model, only a small number of experts are activated per token. SGLang’s --enable-moe-ep scatters the experts across GPUs and routes each token to the right expert over a high-speed interconnect. The key to throughput is preserving, at the level of hardware placement, a structure that computes only the 39B active parameters rather than the full 743B.

Third, the fit between format and engine is what breaks the vendor lock-in. This is the quiet conclusion behind this achievement. Once an engine that natively supports MXFP4 (SGLang) and a toolkit that losslessly converts to that format (AMD Quark) were both in place, production-grade serving became viable on ROCm rather than CUDA. As the serving stack becomes more standardized, “which vendor’s GPU” stops being a performance question and becomes a matter of availability and price. This is the shift that hands negotiating power back to the buyer.

Implications for ThakiCloud’s Products

This case connects directly to the strategy behind ThakiCloud’s ai-platform. ai-platform is a Kubernetes-based AI/ML SaaS infrastructure that serves models across diverse customer environments and schedules GPU resources through Kueue. From that vantage point, this result carries three implications.

Multi-vendor serving is no longer a performance compromise. In the past, the assumption that “you cannot get good performance without NVIDIA” effectively foreclosed vendor choice. The GLM-5.2 MI355X case is evidence that assumption is shaking. If ai-platform abstracts vLLM and SGLang as serving backends and can schedule NVIDIA and AMD nodes together on top of that abstraction, customers can route requests to whatever available hardware is cheapest for a given workload. In a multi-tenant cluster, that flexibility translates directly into serving cost competitiveness.

Quantization is a first-class platform concern. Near-lossless low-bit formats like MXFP4 make it possible to hit the same SLA with fewer GPUs. For on-premises customers, especially domestic public sector and financial environments where data sovereignty and self-hosting are required, the sheer number of GPUs that can be procured is itself a constraint. Lossless quantization lets you run a bigger model within that constraint, so it is a natural direction for ai-platform to absorb toolchains like Quark as a standard stage of its serving pipeline.

Cost efficiency is the core argument for on-premises proposals. The question ThakiCloud hears most often when proposing on-premises and sovereign cloud deployments is “so how much cheaper is it.” Independent benchmarks showing more than 2x cheaper than Blackwell and up to 40% cheaper than B200 can serve as evidence that hardware diversification, on top of the right serving stack, actually lowers real TCO. Naturally this depends on reproducing the result in the customer’s own environment, and that reproduction capability itself is the value the platform provides.

Limitations and Counterarguments

For balance, here are the reasons not to over-trust this result.

First, the benchmark is a snapshot of specific conditions. The 2,626 tok/s figure comes from a specific workload: 20k input, 1k output, 60% cache hit rate. Throughput will change substantially under workloads with short prompts and heavy generation, or with low cache hit rates. The gap between the single-stream 213 tok/s and the node-aggregate 2,626 tok/s already shows that sensitivity.

Second, the MXFP4 “lossless” claim holds only within its tested scope. The original source says it is lossless relative to official FP8, but this is most likely measured against a specific evaluation set. The impact of 4-bit quantization can differ by task, coding, math, long context, and so on, so before adopting it in production you need to measure quality degradation directly against your own evaluation set.

Third, the operational maturity of the ROCm ecosystem remains a variable. A benchmark holding up is a different matter from stable production operation. A gap with the CUDA ecosystem still exists in driver, kernel, and library compatibility, and in the maturity of incident-response tooling. Judging total cost of ownership by hardware unit price alone can miss the cost of operational staffing and downtime.

Even so, the direction is clear. Standardization of the serving stack is widening hardware choice, and the beneficiaries of that shift are serving platforms, and their customers, that can escape vendor lock-in and pick the optimal hardware for each workload. ThakiCloud’s ai-platform is aimed at exactly that point.

Sources

• Wafer.ai, “Performance per dollar is getting faster and cheaper”: https://www.wafer.ai/blog/glm52-amd
• SemiAnalysis InferenceX, “AMD MI355X GLM-5 Inference: Up to 40% Cheaper per Million Tokens than B200 on SGLang FP8”: https://inferencex.semianalysis.com/blog/mi355x-glm5-fp8-sglang-40-cheaper-than-b200
• LMSYS, “Win on TCO: How AMD Instinct MI355X Achieves Cost-Competitive Distributed Inference Through SGLang with MoRI”: https://www.lmsys.org/blog/2026-05-28-mori/
• GLM-5.2 model card (743B / 39B active, MoE, 1024K context): https://recipes.vllm.ai/zai-org/GLM-5.2

Introduction: “Don’t we not need fine-tuning anymore?”

Anyone building or selling an AI platform today has probably heard some version of this question. Frontier models have gotten so good, and skills plus agent scaffolding let you inject domain knowledge on the fly, so why bother spending the money and time to train a separate model at all? We asked ourselves the same question. So we spent one month, from June 5 to July 5, 2026, checking it against sources published in that window only.

The method was simple. We researched four threads: the case against fine-tuning, the case for its survival, market and vendor moves, and practitioner discourse. Then we took six core claims that carry the most weight for our conclusion and re-verified each one with an independent adversarial check. Four of the six came back confirmed, two came back partially confirmed, and none were refuted. This piece is written using only the facts that survived that verification.

The short version: fine-tuning as a product really is dying. But what is dying is a specific segment, the self-serve SFT API. The same underlying technology is being repackaged into two other products, model ownership and agent worker economics, and in those forms it is actually becoming a premium offering.

What is actually dying

The most telling event is OpenAI’s decision. OpenAI announced on May 7, 2026 that it would block new fine-tuning job creation for new organizations, moved on July 2 to cut off access for organizations inactive for 60 days or more, and plans to fully end new fine-tuning job creation for all customers, including existing active ones, on January 6, 2027. Inference on models that have already been fine-tuned will keep running until the base model itself is deprecated, but the path to training a new one is closing.

The exception clause is worth noting. RFT, reinforcement-learning-based fine-tuning, is being split off into its own track and kept alive through this shutdown. In other words, OpenAI is winding down supervised fine-tuning while preserving high-value customization built on verifiable rewards. Anthropic never opened self-serve fine-tuning on its public API in the first place, and is instead pushing Agent Skills, which load domain knowledge dynamically from a folder structure, as the standard path. Two of the top-tier model vendors are pointing in the same direction.

Pricing tells the same story. The LoRA fine-tuning price war between Together AI and Fireworks AI signals that this segment has already become commoditized, with thin margins. Running a lightweight supervised fine-tune yourself, self-serve, is no longer technically hard, and that is exactly why it has stopped being an attractive business.

But skills aren’t a universal answer either

Contrary to the general feeling, the academic evidence that skills universally replace fine-tuning is still thin. Within this window, the SkillJuror study showed that structuring skills, rather than delivering them flat, raises verification pass rates by 4.1 percentage points. The effect is real, but small. An earlier background paper, SkillsBench, has a more interesting result. Well-curated skills raise average pass rates by 16.2 percentage points, but the variance across domains swings from negative to as much as plus 51.9 percentage points, and performance actually dropped in 16 of 84 tasks. Critically, skills the model wrote for itself showed no benefit on average.

In other words, “skills solve everything” only holds as a conditional claim: it works when a human carefully curates a skill and applies it to the right domain. Skill curation is not free, and there is no guarantee it is always cheaper than fine-tuning. For what it’s worth, we could not find a benchmark within this window that directly compares a fine-tuned model against a frontier model equipped with skills on the same task set. That gap remains homework for both camps.

The month’s countersignals

The same month also produced strong signals pointing toward fine-tuning and model ownership. All of the following are independently cross-verified events.

First, the geopolitical risk of depending on a frontier API stopped being theoretical. On June 12, 2026, a US government export-control order forced Anthropic to disable Fable 5 and Mythos 5 globally. Real-time nationality filtering wasn’t feasible, so essentially every user was affected, not just customers outside the US, and it took 19 days to lift the restriction. Any company that has put core operations on a single frontier API just learned a 19-day lesson in June.

Second, the open-weight ecosystem is being designed around the assumption that customers will fine-tune. NVIDIA Nemotron 3 Ultra, announced on June 4, is a mixture-of-experts model with 550B total parameters and 55B active, and ships with LoRA SFT, full SFT, and GRPO reinforcement-learning recipes out of the box. Its license, OpenMDW-1.1, explicitly permits commercializing and redistributing fine-tuned derivative models. The license’s entire design goal is: own and sell the model you tuned on your own data. On June 29, Palantir and NVIDIA released a sovereign AI bundle built around fine-tuning open weights and operating them inside air-gapped environments. In the EU, legislation has been proposed to grade public-sector workloads with sovereignty-assurance ratings, and domestic sovereign AI projects are similarly underway.

Third, a fine-tuning worker won in production. In a benchmark published by legal AI company Harvey together with Fireworks, a standalone Kimi K2.6 model with only SFT applied hit a 15% overall pass rate across 100 tasks, beating a standalone Claude Opus 4.7 at 14%, at roughly 11.4 times lower cost. A hybrid configuration that selectively escalates to a frontier model from a fine-tuned worker scored highest at 18%. It’s a vendor-run benchmark, so there’s a limit to how far it generalizes, but it’s real-world evidence that combining a fine-tuned worker with selective frontier escalation can win on quality and cost at the same time in a narrow domain.

Fourth, small models still reproduce a domain advantage. In a paper published June 11, a Mistral-7B model fine-tuned with QLoRA showed up to a 12-percentage-point F1 advantage over GPT-4o and GPT-5 on biomedical claim verification. It was trained on just 1,008 samples.

The market is splitting into three tracks

Layering these signals together, the market isn’t a binary story of dying versus surviving. It’s splitting into three tracks.

flowchart TB
    A["Fine-tuning market<br/>2026 realignment"] --> B["Track 1<br/>Self-serve SFT API"]
    A --> C["Track 2<br/>Owned sovereign custom models"]
    A --> D["Track 3<br/>RL fine-tuning and worker economics"]
    B --> B1["In decline<br/>OpenAI phased shutdown<br/>LoRA price commoditization"]
    C --> C1["Going premium<br/>Air-gapped fine-tuning products<br/>Sovereignty-rating legislation<br/>Fine-tuning-first licenses"]
    D --> D1["New growth<br/>RFT kept as separate track<br/>Fine-tuning worker + frontier escalation"]
    C1 --> E["Model ownership becomes the product"]
    D1 --> E

Track 1, the self-serve SFT API, is in decline. Long context, native tool calling, and structured output from frontier models have absorbed much of what used to justify fine-tuning: format compliance and domain vocabulary. Track 2, owned custom models, is being reorganized as a premium service. The era of lightly tuning a model through an API is ending, but heavy customization where a company owns and controls its own model is actually getting more expensive, not less. Track 3 is new demand created by the agent era. As orchestrators get better, the volume of calls handled by low-cost workers on repetitive subtasks keeps rising, and calling a frontier model for every one of those slots is simply unaffordable.

Five conditions where fine-tuning clearly wins

Rolling the verified cases into a pattern, fine-tuning’s odds and its return on investment both rise the more these conditions overlap:

1. A narrow, repetitive task with a fixed output format. Classification, verification, and structured extraction are the classic cases, and this is exactly the pattern behind the 12-point advantage from just 1,008 samples.
2. A verifiable reward exists. If there’s environmental feedback that lets you apply GRPO or RFT, that beats supervised learning, and it’s also why OpenAI kept RFT alive while winding down SFT.
3. Call frequency is high and cost and latency are the dominant constraints. Agent worker slots fall squarely here, and an 11.4x cost gap becomes decisive as it scales.
4. There are data sovereignty, regulatory, or air-gapped network requirements. Public sector, finance, and defense are constrained to a limited set of external API options from the outset.
5. The frontier API itself is a supply risk. As the 19-day shutdown showed, export controls and policy changes are no longer a hypothetical scenario.

Conversely, we found no evidence in this window that fine-tuned models beat frontier models on open-domain reasoning, up-to-date knowledge, or long-tail handling. The honest call there is to cede that ground to skills and frontier models.

Implications for ThakiCloud’s products

This realignment lines up precisely with where our two products are headed.

From the ai-platform angle, what tracks 2 and 3 ultimately demand is training and serving infrastructure that runs inside a customer’s air-gapped network. ThakiCloud’s ai-platform runs five training pipelines, SFT, CPT, DPO, GRPO, and GKD, on top of Kubernetes and Kueue-based GPU scheduling. It was an important confirmation for us that the two axes the market is starting to pay a premium for, GRPO built on verifiable rewards and distillation that moves frontier output down into a smaller model, are exactly where we’ve been building. As on-premises and sovereignty requirements grow, fine-tuning stops being an API feature and becomes an infrastructure capability, and that’s precisely where we’re positioned.

From the Paxis angle, this conclusion draws a clean line between the role of skills and the role of fine-tuning. Paxis is ThakiCloud’s control plane for the Agent-Native Cloud, selecting from over 960 skills via BM25, running them in isolated sandboxes, and routing every action through policy gates and audit logging. The lesson from the skills benchmarks, that skills only help when well curated and that self-generated skills can’t be trusted, validates the direction Paxis has been investing in: skill curation and verification loops. At the same time, the Harvey case’s pattern, that a fine-tuned worker is the economical choice for an agent fleet’s repetitive subtasks, shows that skill-based orchestration and fine-tuned workers aren’t competitors, they’re two layers of the same architecture. It’s a design that spends the frontier model sparingly rather than discarding it.

Limitations and counterarguments

We should also lay out the scenarios where this analysis could be wrong. The strongest counterargument is the pace of progress in text-space optimization. We classified it as background research, but Microsoft Research’s SkillOpt achieved a 19 to 25 percentage point performance gain purely by optimizing skill documents through rollout-based tuning, without touching model weights at all. If this line of work matures, it could erode even fine-tuning’s last stronghold: accuracy on narrow tasks. Even in that scenario, what survives isn’t the training capability itself but the infrastructure contract for serving and operating customer-owned models inside air-gapped networks. In fact, this window’s market signals already show value shifting from the training layer toward the serving layer.

Another limitation is in the data itself. The Harvey benchmark is a vendor’s own announcement, and we couldn’t obtain quantitative market data within this window that directly shows fine-tuning demand rising or falling. It’s also worth distinguishing that OpenAI’s shutdown is a supply-side decision, not direct evidence of falling demand.

Closing

The feeling that “fine-tuning isn’t necessary anymore” is only half right. Commodity SFT really is fading, but the verified events of June 2026 show fine-tuning being reorganized around two other directions: model ownership and worker economics. It’s time to change the question. Not “should we fine-tune,” but “under what conditions should we own the model” is, we think, the right question for the second half of 2026.

References

• NVIDIA Debuts Nemotron 3 Family of Open Models (NVIDIA Newsroom, 2026-06-04)
• Nemotron 3 Ultra Technical Report (arXiv:2606.15007)
• Small LLMs for Biomedical Claim Verification (arXiv:2606.12854, 2026-06-11)
• US orders Anthropic to disable AI models for all foreign nationals (Al Jazeera, 2026-06-13)
• Anthropic says Trump admin has lifted export controls (CNBC, 2026-06-30)
• SAGE-OPD: Selective On-Policy Distillation (arXiv:2606.19659, 2026-06-17)
• SkillJuror (arXiv:2606.11543, 2026-06)
• How Harvey & Fireworks Beat Closed Source on Cost + Quality (Fireworks AI Blog)
• OpenAI is winding down the fine-tuning API (OpenAI Developer Community)
• Linux Foundation Releases OpenMDW-1.1 (Linux Foundation, 2026-05-28)
• SkillsBench (arXiv:2602.12670, background)
• SkillOpt: Agent skills as trainable parameters (Microsoft Research, background)

이 한 문장이 왜 오늘의 뉴스 묶음을 관통하는지, 지금부터 하나씩 풀어보겠습니다.

“우리 모델”이라는 착시

소버린 AI라고 하면 대부분 같은 그림을 떠올립니다. 우리 손으로 만든 파운데이션 모델입니다. 실제로 정부는 5,300억 원 규모의 독자 파운데이션 모델 사업을 추진하고 있습니다. LG AI연구원, SK텔레콤, 업스테이지, 모티프테크놀로지스 네 팀이 6개월 단위로 경쟁하고, 8월 2차 평가를 거쳐 오픈소스로 전면 공개될 예정입니다. 목표는 2027년까지 세계 10위권 모델을 확보하는 것입니다.

여기까지만 보면 주권의 문제는 곧 모델의 문제처럼 보입니다. 그런데 오늘 다이제스트는 정반대 방향을 가리킵니다. 최 교수의 진단이 날카로운 지점이 바로 여기입니다. 모델을 국산화해도, 그 모델을 돌리는 학습 데이터와 GPU, 클라우드, 에이전트 도구가 전부 외부 생태계에 묶여 있다면 주권은 절반짜리라는 것입니다. 그는 기존 SBOM이나 SCA 같은 보안 도구가 모델 가중치처럼 코드가 아닌 자산을 읽지 못하는 가시성 공백을 지적하면서, 가중치와 학습 데이터셋, 하이퍼파라미터, 에이전트 도구 명세까지 담는 AI 자재명세서(AIBOM)를 대안으로 제시했습니다.

정리하면 이렇습니다. 모델은 화려한 간판이지만, 주권이 실제로 결정되는 곳은 그 모델이 살아 움직이는 바탕, 즉 실행 계층입니다. 오늘 뉴스에 등장한 여러 기업의 선택이 약속이라도 한 듯 이 지점을 향합니다.

한컴은 왜 ‘모델’이 아니라 ‘OS’라고 말했나

가장 상징적인 사건은 한컴입니다. 창립 36년 만인 지난 7월 2일 임시 주주총회에서 ‘한글과컴퓨터’라는 이름을 ‘한컴’으로 바꾸는 정관 개정안을 의결했습니다. 단순한 리브랜딩이 아닙니다. 문서 소프트웨어 회사에서 여러 AI 에이전트를 하나의 환경에서 연결하고 통제하는 ‘소버린 에이전틱 OS’ 기업으로 정체성을 옮기겠다는 선언이었습니다.

주목할 단어는 ‘OS’입니다. 한컴은 자기들이 만들 것을 ‘모델’이라 부르지 않았습니다. 운영체제라고 불렀습니다. 여러 에이전트를 안전하게 구동하고 통제하는 바탕을 겨냥한다는 뜻입니다. 하반기 베타를 예고했고, 폴란드 국가공인 연구센터와 유럽 현지화 공동연구에도 착수했습니다. 이 전환은 숫자로도 뒷받침됩니다. 지난해 89억 원으로 전체 매출의 5% 수준이던 AI 패키지 매출이 올해 1분기에는 52억 원, 비중 11.52%로 뛰었습니다.

같은 결의 움직임이 KT에서도 보입니다. KT는 서빙 로봇 약 4,000대를 통째로 매각하고 재임대하는 구조로 바꾸며 하드웨어 소유에서 손을 뗐습니다. 대신 제조사가 다른 로봇들을 한 화면에서 통합 제어하는 클라우드 운영 플랫폼에 베팅했습니다. 로봇을 파는 대신, 로봇들이 함께 돌아가는 바탕을 장악하겠다는 계산입니다. 파는 물건은 다르지만 방향은 같습니다. 개별 제품이 아니라 오케스트레이션 계층에서 가치가 나온다고 본 것입니다.

모델은 들어왔는데, 왜 여전히 불안한가

바탕이 왜 중요한지는 그 바탕이 흔들릴 때 가장 선명해집니다. 오늘 다이제스트의 두 기사가 그 장면을 보여줍니다.

먼저 금융권입니다. 지난해 은행권 금융사고 규모는 4,318억 원으로 역대 최고를 기록했습니다. 부천의 한 새마을금고에서는 242억 원 규모 불법 대출이 수년간 잡히지 않았습니다. 그래서 은행들은 앞다퉈 AI 이상거래탐지시스템을 도입하고 있습니다. 카카오뱅크는 시퀀스 탐지 모델을 적용한 뒤 금융사기 예방 건수가 월평균 4.4배 늘었다고 합니다. 여기까지는 성공담입니다.

문제는 그다음입니다. 국내 금융사 중 AI 모델을 자체 개발한 곳은 10%에 불과하고, 그중 다시 3분의 1은 클라우드 인프라와 모델, 데이터를 전부 외부 공급자에 의존합니다. 민감한 거래 데이터를 다루는 이상탐지 시스템이 정작 남의 바탕 위에서 돌아가는 셈입니다. 모델을 도입하는 것과 그 모델을 내 통제 아래 두는 것은 전혀 다른 문제입니다.

애플 협력사 사고는 이 불안의 극단을 보여줍니다. 아이폰 협력사 타타 일렉트로닉스가 랜섬웨어 공격을 받아 630GB, 20만여 개 파일이 다크웹에 공개됐습니다. 아이폰 신제품 공급업체 목록과 프로토타입 시험 사진까지 포함됐다고 합니다. 인도 정부의 침해대응팀이 조사에 착수했습니다. 눈여겨볼 대목은 이 패턴이 처음이 아니라는 점입니다. 2023년 TSMC의 IT 협력사, 2022년 도요타의 부품 협력사가 똑같이 뚫렸습니다. 본사가 아니라 협력사가 통로가 됩니다. 데이터가 여러 곳에 흩어져 협업 시스템에 얹혀 있는 한, 아무리 좋은 모델을 국산으로 만들어도 정보는 가장 약한 연결 고리에서 새어 나갑니다. 상반기 가상자산 해킹 피해의 66%가 북한 소행이었다는 오늘의 또 다른 기사는, 실행 계층의 취약성이 이미 국가 단위 위협의 표적이 되었음을 확인해 줍니다.

통제할 수 있는 것은 바탕뿐입니다

이 지점에서 최 교수의 문장으로 돌아가 봅니다. 통제 가능한 것은 남의 모델이 아니라, 어떤 모델을 쓰든 공급망을 검증하고 차단할 수 있는 인프라입니다. 뉴스가 던진 기업의 통증을 정리하면 네 가지로 좁혀집니다. 무엇이 실행되는지 감사할 수 있는가, 데이터와 실행을 내 주권 아래 둘 수 있는가, 한 곳이 뚫려도 전체로 번지지 않게 격리되는가, 그리고 이 모든 것을 감당 가능한 비용으로 운영할 수 있는가.

ThakiCloud가 Paxis를 Agent-Native Cloud로 설계한 이유가 바로 이 네 가지 질문에 있습니다. Paxis는 스킬과 도구, 정책, 감사 로그를 일급 리소스로 다룹니다. 에이전트가 무엇을 실행하는지 정책 게이트가 사전에 거르고, 실제로 무엇을 했는지 감사 로그가 사후에 남깁니다. 최 교수가 말한 AIBOM식 공급망 투명성이 지향하는 그림과 같은 방향입니다. 에이전트의 자율도를 L0에서 L3까지 등급으로 나눠 거버넌스를 거는 구조는, 금융권이 요구하는 통제 가능성을 계층 그 자체로 구현한 것입니다. 협업 워크로드를 격리 샌드박스에서 실행하는 방식은 애플 협력사 사고 같은 연쇄 유출을 물리적으로 끊어냅니다. 그리고 소버린 온프렘 쿠버네티스 위에서 돌아가기에, 민감 데이터를 외부 네트워크로 내보내지 않고 폐쇄망 안에 둘 수 있습니다. 작업마다 최적의 모델을 고르는 비용 라우팅은 네 번째 질문, 즉 지속 가능성에 대한 답입니다.

한컴이 굳이 사명을 바꿔가며 ‘OS’라는 단어를 고른 것도, KT가 로봇을 팔지 않고 플랫폼에 건 것도 결국 같은 통찰의 다른 표현입니다. 에이전트 시대의 가치는 개별 모델이 아니라, 에이전트가 살고 일하는 바탕에서 나옵니다. Paxis는 그 바탕을 감사 가능하고 주권적인 형태로 제공하는 제품입니다.

화려한 것은 모델, 결정되는 것은 바탕

오늘 하루에도 D램 슈퍼사이클과 1천조 원 데이터센터 전쟁, 빅테크의 자체 칩 경쟁 같은 굵직한 뉴스가 쏟아졌습니다. 헤드라인은 언제나 모델과 칩이 가져갑니다. 그러나 기업의 실무자가 밤에 잠 못 이루는 이유는 조금 다릅니다. 우리 에이전트가 지금 무엇을 하고 있는지 설명할 수 있는가, 사고가 나면 어디서 시작됐는지 추적할 수 있는가, 이 데이터가 정말 우리 손 안에 있는가 하는 질문입니다.

주권은 선언으로 완성되지 않습니다. 우리 모델을 만들었다는 사실만으로도 완성되지 않습니다. 그 모델이 어디서 실행되고, 무엇을 하도록 허락받았으며, 무슨 일을 했는지 언제든 열어볼 수 있을 때 비로소 주권이라 부를 수 있습니다. 오늘 뉴스가 조용히 가리키는 곳은 화려한 모델이 아니라, 그 아래 놓인 바탕입니다. 그리고 그 바탕을 먼저 다지는 쪽이 다음 라운드의 주도권을 쥐게 될 것입니다.

지난 주 개발자 타임라인에서 한 벤치마크 결과가 빠르게 퍼졌습니다. GLM-5.2를 AMD MI355X 한 노드에서 초당 2,626 토큰으로 서빙했고, 그것도 Blackwell 대비 2배 이상 낮은 비용으로 해냈다는 내용이었습니다. 숫자만 보면 흔한 “우리 하드웨어가 빠릅니다” 홍보처럼 들리지만, 이 사례가 흥미로운 이유는 따로 있습니다. NVIDIA가 아닌 AMD GPU 위에서, 743B 규모의 초대형 MoE 모델을, 정확도 손실 없이 4비트급으로 압축해 돌렸다는 조합이기 때문입니다.

이 글은 온프레미스와 멀티클라우드 서빙을 검토하는 엔지니어링 리더, GPU 벤더 선택을 고민하는 ML 플랫폼 팀, 그리고 대형 오픈웨이트 모델의 서빙 경제성을 따져야 하는 데이터 과학자를 위한 것입니다. 먼저 이 결과가 정확히 무엇을 측정했는지 원 소스로 확인하고, MXFP4 양자화와 SGLang의 MoE 병렬화가 왜 결정적이었는지 뜯어본 다음, ThakiCloud의 ai-platform이 이 흐름에서 어떤 위치에 서는지를 정리합니다.

결론부터 말씀드리면 이렇습니다. 이 벤치마크의 진짜 메시지는 “AMD가 빠르다”가 아니라, 서빙 스택(양자화 포맷과 추론 엔진)이 하드웨어 벤더의 잠금을 풀어버리기 시작했다는 것입니다. 그리고 그 잠금이 풀리는 지점이 바로 온프렘 서빙 플랫폼의 존재 이유입니다.

이 기술은 무엇인가

세 가지 조각이 맞물린 결과입니다. 모델, 하드웨어, 그리고 그 둘을 잇는 서빙 스택입니다.

모델, GLM-5.2. Z.ai(구 Zhipu)가 공개한 오픈웨이트 MoE 모델로, 총 파라미터는 약 743B, 토큰당 활성화되는 파라미터는 약 39B입니다. 컨텍스트 길이는 100만 토큰(1M)에 이르고, 특히 프론트엔드 코딩 과제에서 강한 모델로 평가받습니다. 전체 파라미터는 크지만 활성 파라미터가 39B에 불과한 MoE 구조라, “무겁게 담아두고 가볍게 꺼내 쓰는” 전형적인 대형 스파스 모델입니다.

하드웨어, AMD Instinct MI355X. AMD의 최신 데이터센터 가속기로, GPU 한 장당 메모리 용량이 커서 대형 모델을 적은 수의 GPU에 담을 수 있는 것이 강점입니다. 이번 사례는 한 노드(GPU 8장, 텐서 병렬 tp=8) 구성에서 측정되었습니다. 참고로 FP8 기준 GPU당 메모리 점유가 약 89GB로, BF16의 약 175GB 대비 절반 수준입니다.

서빙 스택, MXFP4 양자화(AMD Quark) + SGLang. 여기가 핵심입니다. 원본 BF16 GLM-5.2를 AMD의 양자화 툴킷 Quark로 MXFP4(4비트 마이크로스케일링 부동소수점) 포맷으로 변환했는데, 원 소스는 이 변환이 공식 FP8 양자화 대비 정확도 손실이 없었다(“lossless”)고 밝힙니다. 그리고 추론 엔진으로는 SGLang을 선택했습니다. 이유는 명확합니다. 테스트한 프레임워크 중 SGLang이 MXFP4를 네이티브로 지원했고, --enable-moe-ep 옵션으로 전문가(expert)들을 GPU들에 분산 배치한 뒤 토큰을 NVLink/NVSwitch로 라우팅하는 MoE 병렬화를 제대로 태울 수 있었기 때문입니다.

전체 파이프라인을 정리하면 다음과 같습니다.

flowchart TB
    A[GLM-5.2 원본<br/>BF16 · 743B MoE] --> B[AMD Quark로<br/>MXFP4 양자화]
    B --> C{정확도 검증}
    C -->|공식 FP8 대비 무손실| D[SGLang 서빙 엔진]
    C -->|손실 발생 시| A
    D --> E[MoE 전문가 병렬화<br/>--enable-moe-ep]
    E --> F[MI355X 한 노드<br/>GPU 8장 · tp=8]
    F --> G[단일 스트림 213 tok/s]
    F --> H[노드 집계 2,626 tok/s]

기존 접근과의 차이는 두 지점입니다. 첫째, 양자화 포맷이 FP8이 아니라 MXFP4라는 점입니다. 비트를 더 줄이면 보통 정확도가 흔들리는데, 마이크로스케일링 방식은 작은 블록 단위로 스케일을 따로 두어 4비트급에서도 품질을 유지하려는 설계입니다. 둘째, 이 모든 것이 CUDA 생태계 바깥, 즉 AMD ROCm 위에서 돌아갔다는 점입니다.

실제 벤치마크 결과

원 소스(Wafer.ai)가 공개한 수치는 두 갈래입니다. 워크로드 조건이 다르므로 나눠서 봐야 합니다.

단일 스트림 지연 시나리오. 입력 10k 토큰, 출력 1.5k 토큰의 단일 요청에서 초당 213 토큰을 냈습니다. 한 사용자가 긴 컨텍스트를 넣고 답변을 스트리밍으로 받는 상황에 해당하는 수치입니다.

노드 집계 처리량 시나리오. 입력 20k 토큰, 출력 1k 토큰, 캐시 적중률 60%의 조건에서, 초당 요청 2.4건(2.4 rps)을 처리하며 노드당 2,626 tok/s의 집계 처리량을 냈습니다. 이때 TTFT(첫 토큰까지 걸린 시간)는 5초 이하로 유지되었습니다. 여러 요청을 동시에 밀어 넣는 프로덕션 서빙에 가까운 조건입니다.

비용 측면의 주장은 이렇습니다. Wafer.ai는 이 MXFP4 구성이 Blackwell 대비 2배 이상 낮은 비용, 즉 달러당 처리량이 두 배 이상이라고 밝힙니다. 별개의 분석인 SemiAnalysis(InferenceX)는 조건이 다른 SGLang FP8 구성에서 MI355X가 B200 대비 백만 토큰당 최대 40% 저렴하다고 보고했습니다. 두 수치는 양자화 포맷과 워크로드가 서로 다르므로 직접 비교하기보다는, “여러 독립 출처가 같은 방향(MI355X의 비용 경쟁력)을 가리킨다”는 정도로 읽는 것이 정확합니다. 위 차트의 비용 지수는 Wafer.ai의 “2배 이상” 주장을 시각화한 것으로, 절대 단가가 아니라 상대 지표임을 밝혀 둡니다.

여기서 한 가지 주의가 필요합니다. 이 숫자들은 저희가 MI355X 노드를 직접 확보해 재현한 결과가 아니라 원 소스가 공개한 측정값입니다. MI355X 실물이 없어 독립 재현은 하지 못했고, 따라서 본문의 모든 수치는 인용값입니다. 하드웨어를 확보하는 대로 동일 조건 재현을 별도로 다룰 계획입니다.

왜 MXFP4와 SGLang이 결정적이었나

이 결과에서 하드웨어보다 더 중요한 것은 서빙 스택의 선택입니다. 세 가지 이유가 있습니다.

첫째, 4비트 양자화가 대형 MoE를 적은 GPU에 담습니다. 743B 파라미터를 BF16으로 올리면 메모리가 수백 GB 단위로 필요합니다. MXFP4로 내리면 가중치 메모리가 크게 줄어, 같은 모델을 더 적은 GPU, 더 좁은 노드에 넣을 수 있습니다. 서빙 비용의 상당 부분이 “이 모델을 담는 데 GPU 몇 장이 필요한가”에서 결정되므로, 무손실에 가까운 4비트 양자화는 곧바로 단가로 이어집니다.

둘째, MoE 병렬화가 활성 파라미터만 계산하게 만듭니다. MoE 모델은 토큰마다 소수의 전문가만 활성화됩니다. SGLang의 --enable-moe-ep는 전문가들을 GPU들에 흩어 놓고 토큰을 고속 인터커넥트로 해당 전문가에게 보냅니다. 743B를 다 계산하는 것이 아니라 39B 활성분만 계산하는 구조를 하드웨어 배치 수준에서 살려내는 것이 처리량의 핵심입니다.

셋째, 포맷과 엔진의 궁합이 벤더 잠금을 풉니다. 이번 성과의 조용한 결론은 여기 있습니다. MXFP4를 네이티브로 지원하는 엔진(SGLang)과 그 포맷으로 무손실 변환해 주는 툴킷(AMD Quark)이 갖춰지자, CUDA가 아닌 ROCm 위에서도 프로덕션급 서빙이 성립했습니다. 서빙 스택이 표준화될수록 “어느 벤더의 GPU인가”는 성능이 아니라 가용성과 단가의 문제로 내려옵니다. 이것이 구매자에게 협상력을 돌려주는 변화입니다.

ThakiCloud 제품 적용 시사점

이 사례는 ThakiCloud ai-platform의 전략과 정면으로 맞닿아 있습니다. ai-platform은 Kubernetes 기반의 AI/ML SaaS 인프라로, 다양한 고객 환경에서 모델을 서빙하고 GPU 자원을 Kueue로 스케줄링합니다. 그 관점에서 이번 결과가 주는 시사점은 세 가지입니다.

멀티벤더 서빙이 이제 성능 타협이 아닙니다. 과거에는 “NVIDIA가 아니면 성능이 안 나온다”는 전제가 벤더 선택을 사실상 봉쇄했습니다. GLM-5.2 MI355X 사례는 그 전제가 흔들린다는 증거입니다. ai-platform이 vLLM과 SGLang을 서빙 백엔드로 추상화하고 그 위에서 NVIDIA와 AMD 노드를 함께 스케줄링할 수 있다면, 고객은 워크로드별로 가장 저렴한 가용 하드웨어에 요청을 태울 수 있습니다. 멀티테넌트 클러스터에서 이 유연성은 곧 서빙 단가 경쟁력입니다.

양자화가 플랫폼의 1급 관심사입니다. MXFP4처럼 무손실에 가까운 저비트 포맷은 “같은 SLA를 더 적은 GPU로” 달성하게 해 줍니다. 온프렘 고객, 특히 데이터 주권과 self-hosting이 요구되는 국내 공공·금융 환경에서는 확보 가능한 GPU 수량 자체가 제약입니다. 무손실 양자화는 그 제약 안에서 더 큰 모델을 돌릴 수 있게 하므로, ai-platform이 Quark 같은 툴체인을 서빙 파이프라인의 표준 단계로 흡수하는 것은 자연스러운 방향입니다.

비용 효율이 온프렘 제안의 핵심 논거입니다. ThakiCloud가 온프레미스와 소버린 클라우드를 제안할 때 가장 자주 받는 질문은 “그래서 얼마나 저렴한가”입니다. Blackwell 대비 2배 이상, B200 대비 최대 40% 저렴하다는 독립 벤치마크는, 적절한 서빙 스택 위에서 하드웨어 다변화가 실제 TCO를 낮춘다는 근거로 쓸 수 있습니다. 물론 고객 환경에서의 재현이 전제이며, 그 재현 능력 자체가 플랫폼이 제공하는 가치입니다.

한계 및 반론

균형을 위해 이 결과를 과신하면 안 되는 이유를 짚습니다.

첫째, 벤치마크는 특정 조건의 스냅샷입니다. 2,626 tok/s는 입력 20k·출력 1k·캐시 60%라는 특정 워크로드에서 나온 수치입니다. 짧은 프롬프트에 긴 생성이 몰리거나 캐시 적중이 낮은 워크로드에서는 처리량이 크게 달라집니다. 단일 스트림 213 tok/s와 노드 집계 2,626 tok/s의 간극이 이미 그 민감도를 보여 줍니다.

둘째, MXFP4 “무손실”은 검증 범위 안의 주장입니다. 원 소스는 공식 FP8 대비 무손실이라고 했지만, 이는 특정 평가 세트 기준일 가능성이 높습니다. 코딩·수학·긴 컨텍스트 등 과제별로 4비트 양자화의 영향은 다르게 나타날 수 있어, 실제 도입 전에는 자사 평가셋으로 품질 저하를 직접 측정해야 합니다.

셋째, ROCm 생태계의 운영 성숙도는 여전히 변수입니다. 벤치마크가 성립한다는 것과 프로덕션에서 안정적으로 운영된다는 것은 다른 문제입니다. 드라이버, 커널, 라이브러리 호환성, 장애 대응 도구의 성숙도에서 CUDA 생태계와의 격차는 아직 존재합니다. 하드웨어 단가만 보고 총소유비용을 판단하면 운영 인력과 다운타임 비용을 놓칠 수 있습니다.

그럼에도 방향성은 분명합니다. 서빙 스택의 표준화가 하드웨어 선택지를 넓히고 있고, 그 변화의 수혜자는 벤더 잠금에서 벗어나 워크로드별 최적 하드웨어를 고를 수 있는 서빙 플랫폼과 그 고객입니다. ThakiCloud ai-platform이 정확히 그 지점을 겨냥합니다.

출처

• Wafer.ai, “Performance per dollar is getting faster and cheaper”: https://www.wafer.ai/blog/glm52-amd
• SemiAnalysis InferenceX, “AMD MI355X GLM-5 Inference: Up to 40% Cheaper per Million Tokens than B200 on SGLang FP8”: https://inferencex.semianalysis.com/blog/mi355x-glm5-fp8-sglang-40-cheaper-than-b200
• LMSYS, “Win on TCO: How AMD Instinct MI355X Achieves Cost-Competitive Distributed Inference Through SGLang with MoRI”: https://www.lmsys.org/blog/2026-05-28-mori/
• GLM-5.2 모델 카드(743B / 39B active · MoE · 1024K ctx): https://recipes.vllm.ai/zai-org/GLM-5.2

들어가며: “이제 파인튜닝 안 해도 되는 것 아닌가요”

요즘 AI 플랫폼을 만들거나 파는 사람이라면 한 번쯤 이런 질문을 받았을 것입니다. 프론티어 모델이 이렇게 좋아졌고, 스킬과 에이전트 스캐폴딩으로 도메인 지식을 주입할 수 있는데, 굳이 돈과 시간을 들여 모델을 따로 학습할 이유가 있느냐는 질문입니다. 저희도 같은 질문을 스스로에게 던졌습니다. 그래서 2026년 6월 5일부터 7월 5일까지, 딱 한 달 동안 발행된 소스만으로 이 질문을 검증해 봤습니다.

방법은 단순합니다. 파인튜닝 무용론의 근거, 생존론의 근거, 시장과 벤더의 움직임, 실무자 담론이라는 네 갈래로 나눠 조사한 뒤, 방향 결정에 하중이 실리는 핵심 주장 여섯 건을 별도의 반증 검증으로 다시 확인했습니다. 여섯 건 중 네 건이 확정, 두 건이 부분 확정이었고 반증된 것은 없었습니다. 이 글은 그 검증을 통과한 사실만으로 씁니다.

결론부터 말하면 이렇습니다. 파인튜닝이라는 상품은 죽어가는 것이 맞습니다. 그런데 죽는 것은 셀프서브 SFT API라는 특정 세그먼트이고, 같은 기술이 모델 소유권과 에이전트 워커 경제학이라는 다른 상품으로 재편되며 오히려 프리미엄화되고 있습니다.

무엇이 실제로 죽고 있는가

가장 상징적인 사건은 OpenAI의 결정입니다. OpenAI는 2026년 5월 7일 신규 조직의 파인튜닝 작업 생성을 차단한다고 공지했고, 7월 2일부터는 60일 이상 비활성 조직의 접근을 막는 단계로 넘어갔으며, 2027년 1월 6일에는 기존 활성 고객까지 포함해 신규 파인튜닝 작업 생성을 완전히 종료할 예정입니다. 이미 만들어진 파인튜닝 모델의 추론은 베이스 모델이 폐기되기 전까지 유지되지만, 새로 학습을 돌리는 길은 닫힙니다.

주목할 부분은 예외 조항입니다. 강화학습 기반 파인튜닝인 RFT는 이번 폐쇄에서 별도 트랙으로 분리되어 유지됩니다. 지도학습 파인튜닝은 접으면서 검증 가능한 보상이 있는 고가치 커스터마이징은 남긴 셈입니다. Anthropic은 애초에 공개 API에서 셀프서브 파인튜닝을 열지 않았고, 폴더 구조로 도메인 지식을 동적으로 로드하는 Agent Skills를 표준 경로로 밀고 있습니다. 두 최상위 모델 벤더가 같은 방향을 가리키고 있는 것입니다.

가격 신호도 같은 이야기를 합니다. Together AI와 Fireworks AI의 LoRA 파인튜닝 가격 경쟁은 이 구간이 이미 커머디티가 되어 마진이 얇아졌다는 뜻입니다. 셀프서브로 가볍게 돌리는 지도학습 파인튜닝은 기술적으로 어렵지 않게 되었고, 그래서 사업으로서의 매력을 잃었습니다.

그런데 스킬이 만능이라는 근거도 없습니다

체감과 달리, 스킬이 파인튜닝을 보편적으로 대체한다는 학술 근거는 아직 약합니다. 이번 윈도우 안에 제출된 SkillJuror 연구는 스킬을 구조화해 제공하는 방식이 플랫 방식 대비 검증 통과율을 4.1%포인트 올린다는 것을 보였습니다. 효과는 실재하지만 크지 않습니다. 조금 앞선 배경 연구인 SkillsBench는 더 흥미로운 결과를 담고 있습니다. 잘 큐레이션된 스킬은 평균 통과율을 16.2%포인트 올리지만 도메인별 편차가 마이너스부터 플러스 51.9%포인트까지 극단적으로 갈리고, 84개 태스크 중 16개에서는 오히려 성능이 떨어졌습니다. 결정적으로 모델이 스스로 작성한 스킬은 평균적으로 효과가 없었습니다.

즉 “스킬이면 다 된다”는 명제는 사람이 정성껏 큐레이션한 스킬을 맞는 도메인에 적용했을 때만 성립하는 조건부 명제입니다. 스킬 큐레이션 비용은 공짜가 아니며, 그 비용이 파인튜닝 대비 항상 싸다는 보장도 없습니다. 참고로 동일 태스크셋에서 파인튜닝 모델과 스킬을 얹은 프론티어 모델을 나란히 비교한 벤치마크는 이번 윈도우 안에서 찾지 못했습니다. 이 공백은 양쪽 진영 모두에게 남아 있는 숙제입니다.

6월 한 달, 정반대 방향의 신호들

같은 한 달 동안 파인튜닝과 모델 소유권 쪽으로도 강한 신호가 쏟아졌습니다. 전부 독립 소스로 교차 확인된 사건들입니다.

첫째, 프론티어 API 의존의 지정학 리스크가 실측 사건이 되었습니다. 2026년 6월 12일 미국 정부의 수출통제 지시로 Anthropic은 Fable 5와 Mythos 5 모델을 전 세계 대상으로 비활성화했습니다. 실시간 국적 필터링이 불가능해 해외 고객만이 아니라 사실상 모든 사용자가 영향을 받았고, 해제까지 19일이 걸렸습니다. 프론티어 API 하나에 핵심 업무를 올려둔 기업이라면 6월에 19일짜리 교훈을 얻은 셈입니다.

둘째, 오픈웨이트 생태계는 파인튜닝을 전제로 설계되고 있습니다. 6월 4일 발표된 NVIDIA Nemotron 3 Ultra는 총 550B에 활성 55B인 MoE 구조로, LoRA SFT와 풀 SFT, GRPO 강화학습 레시피를 기본 제공합니다. 라이선스인 OpenMDW-1.1은 파인튜닝 파생 모델의 상업화와 재배포를 명시적으로 허용합니다. 우리 데이터로 튜닝한 모델을 소유하고 판매하라는 것이 라이선스 설계의 목표입니다. 6월 29일에는 Palantir와 NVIDIA가 에어갭 환경 안에서 오픈웨이트를 파인튜닝해 운영하는 소버린 AI 결합 상품을 내놨습니다. EU에서는 공공 워크로드에 주권 보증 등급을 매기는 법안이 발의되었고, 국내에서도 소버린 AI 사업이 진행형입니다.

셋째, 파인튜닝 워커의 실전 승리 사례가 나왔습니다. 법률 AI 기업 Harvey와 Fireworks가 공개한 벤치마크에서, SFT만 적용한 Kimi K2.6 단독 모델이 100개 태스크 기준 전체 통과율 15%로 Claude Opus 4.7 단독의 14%를 넘었고 비용은 약 11.4배 저렴했습니다. 파인튜닝 워커에 프론티어 모델을 선택적으로 호출하는 하이브리드 구성은 18%로 가장 높았습니다. 벤더 자체 벤치마크라는 한계는 있지만, 좁은 도메인에서 파인튜닝 워커와 프론티어 에스컬레이션을 조합하면 품질과 비용을 동시에 잡을 수 있다는 실전 근거입니다.

넷째, 작은 모델의 도메인 우위는 여전히 재현됩니다. 6월 11일 공개된 논문에서 Mistral-7B를 QLoRA로 파인튜닝한 모델이 바이오메디컬 클레임 검증에서 GPT-4o와 GPT-5 대비 F1 기준 최대 12%포인트 우위를 보였습니다. 학습 샘플은 단 1,008개였습니다.

시장은 세 갈래로 재편되고 있습니다

이 신호들을 겹쳐 보면 시장은 죽느냐 사느냐의 이분법이 아니라 세 갈래로 갈라지고 있습니다.

flowchart TB
    A["파인튜닝 시장<br/>2026년 재편"] --> B["갈래 1<br/>셀프서브 SFT API"]
    A --> C["갈래 2<br/>소유형 소버린 커스텀 모델"]
    A --> D["갈래 3<br/>RL 파인튜닝과 워커 경제학"]
    B --> B1["축소 국면<br/>OpenAI 단계적 폐쇄<br/>LoRA 가격 커머디티화"]
    C --> C1["프리미엄화<br/>에어갭 파인튜닝 상품<br/>주권 등급제 법안<br/>파인튜닝 전제 라이선스"]
    D --> D1["신규 성장<br/>RFT는 별도 트랙 유지<br/>파인튜닝 워커 + 프론티어 에스컬레이션"]
    C1 --> E["모델 소유권이 상품"]
    D1 --> E

갈래 1인 셀프서브 SFT API는 축소 국면입니다. 프론티어 모델의 긴 컨텍스트와 네이티브 툴콜, 구조화 출력이 과거 파인튜닝의 존재 이유였던 포맷 준수와 도메인 어휘 문제를 상당 부분 흡수했습니다. 갈래 2인 소유형 커스텀 모델은 프리미엄 서비스로 재편되고 있습니다. API로 가볍게 튜닝하는 시대는 끝나지만, 기업이 모델을 소유하고 통제하는 무거운 커스터마이징은 오히려 몸값이 오르고 있습니다. 갈래 3은 에이전트 시대가 만드는 신규 수요입니다. 오케스트레이터가 좋아질수록 반복 서브태스크를 담당할 저비용 워커의 호출량이 늘고, 그 슬롯마다 프론티어를 부르면 비용이 감당되지 않습니다.

파인튜닝이 확실히 이기는 다섯 가지 조건

검증된 사례들을 패턴으로 정리하면, 다음 조건이 겹칠수록 파인튜닝의 승산과 투자 대비 효과가 함께 올라갑니다.

1. 좁고 반복적인 태스크에 출력 포맷이 고정되어 있을 때. 분류, 검증, 구조화 추출이 대표적이며 1,008개 샘플로 12%포인트 우위를 만든 사례가 이 유형입니다.
2. 검증 가능한 보상이 존재할 때. GRPO나 RFT를 적용할 수 있는 환경 피드백이 있다면 지도학습보다 유리하며, OpenAI가 SFT를 접으면서 RFT만 남긴 이유이기도 합니다.
3. 호출 빈도가 높고 비용과 지연이 지배적인 제약일 때. 에이전트 워커 슬롯이 여기 해당하고, 11.4배 비용 차이는 규모가 커질수록 결정적입니다.
4. 데이터 주권, 규제, 폐쇄망 요구가 있을 때. 공공, 금융, 방산 영역은 애초에 외부 API 선택지가 제한됩니다.
5. 프론티어 API 자체가 공급 리스크일 때. 19일 셧다운 사건이 보여줬듯 수출통제와 정책 변경은 더 이상 가상의 시나리오가 아닙니다.

반대로 오픈도메인 추론, 최신 지식, 롱테일 처리에서 파인튜닝 모델이 프론티어를 이겼다는 근거는 이번 윈도우에서 찾지 못했습니다. 그 영역은 스킬과 프론티어 모델에 양보하는 것이 정직한 판단입니다.

ThakiCloud 제품 관점에서의 시사점

이 재편 구도는 저희가 만드는 두 제품의 방향과 정확히 맞물립니다.

ai-platform 관점에서 보면, 갈래 2와 3이 요구하는 것은 결국 고객 폐쇄망 안에서 도는 학습과 서빙 인프라입니다. ThakiCloud의 ai-platform은 Kubernetes와 Kueue 기반 GPU 스케줄링 위에서 SFT, CPT, DPO, GRPO, GKD 다섯 종의 학습 파이프라인을 운용합니다. 이번 리서치에서 시장이 프리미엄을 인정하기 시작한 두 축이 검증 가능한 보상 기반의 GRPO와, 프론티어 출력을 소형 모델로 옮기는 증류라는 점은 저희에게 중요한 확인이었습니다. 온프레미스와 소버린 요구가 커질수록 파인튜닝은 API 기능이 아니라 인프라 역량의 문제가 되고, 그 지점이 저희가 서 있는 자리입니다.

Paxis 관점에서는 이번 결론이 스킬과 파인튜닝의 역할 분담을 명확하게 해 줍니다. Paxis는 ThakiCloud의 Agent-Native Cloud 제어 평면으로, 960개 이상의 스킬을 BM25로 선택해 격리 샌드박스에서 실행하고 모든 행동을 정책 게이트와 감사 로그로 통과시킵니다. 스킬 벤치마크가 보여준 교훈, 즉 스킬은 잘 큐레이션될 때만 효과가 있고 자가 생성 스킬은 신뢰할 수 없다는 결론은 Paxis가 스킬 큐레이션과 검증 루프에 투자해 온 방향이 맞았다는 근거이기도 합니다. 동시에 에이전트 플릿의 반복 서브태스크에는 파인튜닝 워커가 경제적이라는 Harvey 사례의 패턴은, 스킬 기반 오케스트레이션과 파인튜닝 워커가 경쟁 관계가 아니라 한 아키텍처의 두 층이라는 것을 보여줍니다. 프론티어를 버리는 것이 아니라 아껴 쓰는 설계입니다.

한계 및 반론

이 분석이 틀릴 수 있는 시나리오도 세워 두어야 합니다. 가장 강한 반론은 텍스트 공간 최적화의 발전 속도입니다. 배경 연구로 분류했지만, Microsoft Research의 SkillOpt는 모델 가중치를 건드리지 않고 스킬 문서를 롤아웃 기반으로 최적화하는 것만으로 19에서 25%포인트의 성능 향상을 얻었습니다. 이 계열이 성숙하면 좁은 태스크의 정확도 우위라는 파인튜닝의 마지막 영토마저 잠식될 수 있습니다. 그 경우에도 살아남는 것은 학습 기능이 아니라 고객 소유 모델을 폐쇄망에서 서빙하고 운영하는 인프라 계약입니다. 실제로 이번 윈도우의 시장 신호에서도 부가가치가 학습보다 서빙 레이어로 이동하는 흐름이 관찰되었습니다.

또 하나의 한계는 데이터 자체에 있습니다. Harvey 벤치마크는 벤더 자체 발표이고, 파인튜닝 수요의 감소나 증가를 직접 보여주는 정량 시장 데이터는 이번 윈도우에서 확보하지 못했습니다. OpenAI의 폐쇄는 공급 측 결정이지 수요 감소의 직접 증거가 아니라는 점도 구분해서 읽어야 합니다.

맺으며

“파인튜닝이 필요 없어졌다”는 체감은 절반만 맞습니다. 커머디티 SFT는 실제로 저물고 있지만, 2026년 6월 한 달의 검증된 사건들은 모델 소유권과 워커 경제학이라는 두 방향으로 파인튜닝이 재편되고 있음을 보여줍니다. 질문을 바꿔야 할 때입니다. “파인튜닝을 할 것인가”가 아니라 “어떤 조건에서 모델을 소유할 것인가”가 2026년 하반기의 올바른 질문이라고 생각합니다.

참고 자료

• NVIDIA Debuts Nemotron 3 Family of Open Models (NVIDIA Newsroom, 2026-06-04)
• Nemotron 3 Ultra 기술 보고서 (arXiv:2606.15007)
• Small LLMs for Biomedical Claim Verification (arXiv:2606.12854, 2026-06-11)
• US orders Anthropic to disable AI models for all foreign nationals (Al Jazeera, 2026-06-13)
• Anthropic says Trump admin has lifted export controls (CNBC, 2026-06-30)
• SAGE-OPD: 선택적 on-policy 증류 (arXiv:2606.19659, 2026-06-17)
• SkillJuror (arXiv:2606.11543, 2026-06)
• How Harvey & Fireworks Beat Closed Source on Cost + Quality (Fireworks AI Blog)
• OpenAI is winding down the fine-tuning API (OpenAI Developer Community)
• Linux Foundation Releases OpenMDW-1.1 (Linux Foundation, 2026-05-28)
• SkillsBench (arXiv:2602.12670, 배경)
• SkillOpt: Agent skills as trainable parameters (Microsoft Research, 배경)

원 뉴스: RT @dailyonjeje: 의사 협회에서 뽑은 최고의 아침식사래. · twitter

ThakiCloud 제품 적용 시사점

건강한 아침의 핵심은 재료가 아니라 냉장고 열쇠를 누가 쥐느냐에 있습니다. AI 인프라도 다르지 않습니다. 파시스는 달걀 삶는 봇 하나까지 과금하는 퍼블릭클라우드 대신, 필요한 에이전트를 우리 시설 안에서 마음껏 풀도록 설계됐습니다. 메티스는 추론과 학습을 외부 냉장고가 아니라 자체 GPU 위에서 돌려, 블루베리 한 줌 클릭당 과금 같은 종량 폭탄에서 벗어나게 합니다. 온프렘 주권형 스택이라면 메뉴도 내가 정하고 계산서도 내가 예측합니다. ThakiCloud가 파는 건 남의 부엌 사용권이 아니라, 청구서가 붙지 않는 내 부엌 그 자체입니다.

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

يكفي أن تقرأ أخبار الذكاء الاصطناعي المحلية ليوم واحد من النصف الأول من هذا العام حتى يتّضح المسار. تدفع شركات التأمين الذكاء الاصطناعي إلى ما هو أبعد من الردّ على الاستفسارات، نحو أعمال جوهرية مثل تقدير نسبة الخطأ في حوادث السيارات والاكتتاب. وانتقلت شركة Korea Midland Power إلى ما وراء الذكاء التوليدي، إلى ذكاء اصطناعي وكيلي ذاتيّ ينفّذ العمل فعلياً في تشغيل المحطة. فهو يعمل على شبكة معزولة، ويجمع تلقائياً حالات الشذوذ في المعدّات ويقدّم عنها إحاطة كل صباح. أمّا Microsoft وAmazon Web Services فتبني كلٌّ منهما تنظيماً مخصّصاً بآلاف الأفراد لإدماج الوكلاء داخل مواقع العملاء.

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

عنق الزجاجة ليس النموذج

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

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

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

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

لا يزول أيٌّ من هذه الجدران الثلاثة بترقية النموذج درجةً واحدة، لأنّها جميعاً مسألة أين تضع التشغيل.

لماذا تعجز السُّحُب التقليدية عن حلّها

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

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

والنتيجة أنّ التحكّم يستند إلى العُرف لا إلى المنصّة. وحين تتغيّر الفِرَق ويرحل الأفراد، يرحل ذلك العُرف معهم. وعبارة “نفعل ذلك بحكم العادة” ليست جواباً يصمد أمام الجهة الرقابية. فالتحكّم يجب أن يكون قابلاً لإعادة الإنتاج ومفروضاً، وتلك مسؤولية المنصّة لا مسؤولية شيفرة فردية.

التحكّم بوصفه منصّة، لا عُرفاً

المُنطلَق الذي اختارته Paxis بسيط: إنّ موارد عصر الوكلاء من الدرجة الأولى ليست أجهزة افتراضية، بل المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلات التدقيق (Audit Logs). وكما تتعامل السُّحُب التقليدية مع الخوادم والشبكات، ترفع Paxis هذه الأربعة إلى موارد تديرها المنصّة مباشرةً.

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

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

وبإسقاط ذلك على الجدران الثلاثة، يتّسق الأمر هكذا:

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

بإسقاطه مباشرةً على أخبار اليوم

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

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

السؤال الباقي

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

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

المصادر

• Korea Midland Power تقدّم إحاطة صباحية يومية عن شذوذ المعدّات عبر HI-KOMI، وهو ذكاء اصطناعي وكيلي ذاتيّ يعمل على شبكة معزولة: Hankyung
• DB Insurance تحدّد نسبة الخطأ في حوادث السيارات من فيديو كاميرا لوحة القيادة بالذكاء الاصطناعي، بمتوسّط 5 ثوانٍ ودقّة 92.4%: Ajunews
• AWS تُدمِج نشر الوكلاء داخل مواقع العملاء عبر تنظيم Forward Deployed Engineering باستثمار مليار دولار: About Amazon
• Microsoft تؤسّس تنظيماً مخصّصاً لنشر الذكاء الاصطناعي (Microsoft Frontier) بالتزام قدره 2.5 مليار دولار و6,000 شخص: TechCrunch

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

هذا التحول مختلف تماماً عن الحديث عن تحسّن النماذج. مهما كان النموذج قوياً، فإنه لا يستطيع إنجاز مهمة معقدة حتى النهاية من خلال طلب واحد ينتهي بموجّه واحد. لكن الأمر يتغير عندما يُبنى فوق بنية تكرارية يستدعي فيها النموذج أداة، ثم يستقبل نتيجتها كمُدخل جديد ليقرر الخطوة التالية. تُشغّل ThakiCloud مثل هذه الحلقات فعلياً في تطويرها الداخلي، إلى جانب تشغيل منصة AI/ML كخدمة (SaaS) قائمة على Kubernetes. لذلك فإن عبارة “كتابة حلقة” ليست بالنسبة لنا جملة رائجة، بل مهمة هندسية يومية. يستعرض هذا المقال ما تتكون منه هذه الحلقة فعلياً، وما الذي يجعلها موثوقة.

من الموجّه إلى الحلقة: ما الذي تغيّر

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

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

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

تشريح الحلقة: تكرار الملاحظة والحكم والتنفيذ

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

flowchart TB
    A[اقتراح النموذج للتغيير<br/>Act] --> B[التطبيق على قاعدة الكود]
    B --> C[تشغيل أداة خارجية<br/>اختبارات·مُجمّع·مدقق لغوي<br/>Observe]
    C --> D[تحليل المخرَج<br/>رسالة الخطأ·السطر·سبب الفشل<br/>Learn]
    D --> E{هل اجتازت<br/>بوابة الإنهاء؟}
    E -- "لا" --> F[إعادة حقن السياق في النموذج<br/>Repeat]
    F --> A
    E -- "نعم" --> G[إنهاء الحلقة<br/>تقارب]
    D -.استنفاد الميزانية.-> H[توقف·تسليم للإنسان]

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

البوابات الحتمية هي إشارة المكافأة

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

رسّخت ThakiCloud هذا المبدأ فعلياً في حلقاتها الداخلية. مثال بارز هو pge-loop، الذي يُطبّق الفروقات (diff) التي يقترحها النموذج على الخلفية البرمجية المبنية بلغة Go، ثم يُشغّل الأمر make test-short، ويُعيد تغذية كامل مخرَج stderr كسياق للاقتراح التالي. شرط الإنهاء هنا ليس حكماً ذاتياً من النموذج، بل رمز خروج الاختبار. وبالمثل، يسعى Goal Mode بشكل مستقل نحو تحقيق الهدف حتى شرط الإنجاز، لكنه يتحقق من تقدّم كل خطوة عبر أمر تحقق محدد مسبقاً، وتشكّل الميزانية (عدد التكرارات والتكلفة والمهلة الزمنية) سقفاً أعلى. فهو لا يدور إلى ما لا نهاية، بل يتوقف عند التقارب أو عند استنفاد الميزانية. من دون هاتين الآليتين، أي بوابة الإنهاء الحتمية وسقف الميزانية، تصبح الحلقة أداة لا يمكن الوثوق بها.

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

دلالات التطبيق على منتجات ThakiCloud

ترتبط هندسة الحلقات ارتباطاً مباشراً بمنتج Paxis من ThakiCloud. Paxis هو مستوى تحكم Agent-Native Cloud يعمل فوق ai-platform، ويتعامل مع المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلات التدقيق (Audit Logs) كموارد من الدرجة الأولى. حتى لا تبقى الحلقة التي يكتبها الإنسان حبيسة بيئة تطوير شخصية، وتصبح بدلاً من ذلك مورداً على مستوى المنصة، يجب أن تُعرَض العناصر المكوّنة للحلقة بشكل قابل للإدارة. يختار Paxis نحو 960 مهارة عبر خوارزمية BM25 وينفّذها في صناديق رملية معزولة، ويمرّر كل سلوك عبر بوابات السياسات وسجلات التدقيق. بعبارة أخرى، عندما يصمم الإنسان “ما الذي يجب مراقبته ومتى يتوقف”، يوفر Paxis البنية التحتية التي تعزل تنفيذ تلك الحلقة وتسجّله وتتحكم فيه.

من هذا المنظور، تقابل البوابة الحتمية بوابة السياسات في Paxis بشكل طبيعي، ويقابل تنفيذ الأداة التنفيذ المعزول في الصندوق الرملي، ويقابل سجل ملاحظة الحلقة سجل التدقيق. والبنية التي تُحقّق فيها الحلقة من نفسها هي نفس المبدأ الذي تؤكد عليه Paxis تحت مسمى “إغلاق fan-out بالتحقق”.

من الناحية البنيوية، يكمّل منظور ai-platform هذا الحديث. تشغيل الحلقات بكثرة يعني بالضرورة زيادة في استدعاءات الاستدلال المتكررة وتشغيل الاختبارات. يستوعب ai-platform هذا الحمل المتكرر بكفاءة من حيث التكلفة عبر جدولة وحدات معالجة الرسوميات (GPU) القائمة على Kubernetes وKueue، وخدمة النماذج عبر vLLM، والعزل متعدد المستأجرين. فقط عندما تكون تكلفة الخدمة منخفضة يصبح تشغيل الحلقات بشكل متكرر مجدياً اقتصادياً، وهذه الجدوى الاقتصادية هي ما يجعل الوكيل قابلاً للتشغيل بشكل دائم. تتشكل هنا حلقة الربط التي تجعل خدمة منخفضة التكلفة (ai-platform) تُنتج جدوى اقتصادية للوكيل (Paxis). وبالنسبة للعملاء الذين لديهم متطلبات محلية (on-premise) وسيادية، فإن إمكانية تشغيل هذه الحلقة بأكملها داخل بنيتهم التحتية الخاصة تحمل أهمية خاصة.

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

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

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

ثالثاً، التكلفة. الحلقة تستهلك بحكم تعريفها استدعاءات استدلال متعددة. من دون سقف، تُستنفد الميزانية في لحظات، وإذا رُبط نموذج قوي بشكل دائم، تزداد التكلفة بشكل مضاعف لا خطي. في الممارسة العملية، يلزم توجيه (Routing) يستخدم نموذجاً رخيصاً في الاستكشاف والتنفيذ المتكرر، ولا يُخصَّص النموذج المكلف إلا لمرحلة التحقق التي تكون الدقة فيها حرجة. ينطبق هنا أيضاً مبدأ أن يكون العامل (Worker) رخيصاً والبوابة (Gate) وحدها مكلفة.

وخلاصة القول، عبارة “لا أكتب موجّهات بل أكتب حلقات” استفزازية، لكنها تحمل مضموناً حقيقياً. غير أن هذا المضمون لا ينبع من نموذج مبهر، بل من تصميم مُملّ ولكنه دقيق يجعل الجهاز قادراً على الحكم بنفسه على ما يُعدّ نجاحاً. الدرس نفسه استخلصته ThakiCloud من pge-loop وGoal Mode: الحلقة الجيدة تنبع من شرط إنهاء جيد.

المصادر

• ميلز دويتشر (Miles Deutscher)، منشور على X (تويتر سابقاً)، رأي حول حلقات وكلاء البرمجة
• ممارسات ThakiCloud الداخلية في هندسة الحلقات: pge-loop، Goal Mode (بوابة تحقق + سقف ميزانية)