نظرة عامة

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

أمام هذا التحول، رصد 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): تغريدة الرد والاعتراض

من يدير خدمة استدلال نماذج اللغة الكبيرة في بيئة إنتاجية يلاحظ حتمًا هذا النمط المتكرر: طلب يُنتج عشرات الرموز فحسب — كردّ بسيط في نظام محادثة — يجلس منتظرًا خلف طلب تلخيص وثيقة طويل أو مهمة توليد كود معقدة، مُهدرًا مئات الميلي ثانية. هذا ما يُعرف بـ 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\nToken-Budget Classifier]
    B -->|Estimated tokens < threshold| C[Short-Context Pool\nvLLM Instance A]
    B -->|Estimated tokens >= threshold| D[Long-Context Pool\nvLLM Instance B]
    C --> E[Kueue LocalQueue\nshort-pool]
    D --> F[Kueue LocalQueue\nlong-pool]
    E --> G[GPU Worker Group A\nSmall KV Cache Requests]
    F --> H[GPU Worker Group B\nLarge 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: Boris Cherny on the five archetypes of future roles · twitter

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

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\nToken-Budget Classifier]
    B -->|Estimated tokens < threshold| C[Short-Context Pool\nvLLM Instance A]
    B -->|Estimated tokens >= threshold| D[Long-Context Pool\nvLLM Instance B]
    C --> E[Kueue LocalQueue\nshort-pool]
    D --> F[Kueue LocalQueue\nlong-pool]
    E --> G[GPU Worker Group A\nSmall KV Cache Requests]
    F --> H[GPU Worker Group B\nLarge 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): 반론 트윗

LLM 추론 서비스를 운영하다 보면 단일 대기열 구조에서 반복되는 현상을 하나 목격하게 됩니다. 챗봇 한 줄 응답처럼 토큰 수십 개로 끝나는 요청이, 긴 문서 요약이나 코드 생성 요청 뒤에 줄을 서서 수백 밀리초를 낭비하는 상황입니다. 이를 Head-of-Line(HoL) 블로킹이라고 부릅니다.

vLLM은 continuous batching으로 배치 효율을 크게 높였지만, 단일 풀 구조에서 긴 요청이 KV 캐시를 장기간 점유하면 짧은 요청의 선점(preemption)이 발생합니다. 선점된 요청은 재계산 비용을 지불하고, 전체 GPU 시간 효율이 떨어집니다.

arXiv 2604.08075가 제안한 Dual-Pool Token-Budget Routing은 이 문제를 근본적으로 해결합니다. 요청이 들어오는 시점에 예상 응답 길이를 기준으로 short-context 풀과 long-context 풀로 분리해 라우팅함으로써, 두 유형이 서로 간섭하지 않게 합니다.

논문이 측정한 결과는 다음과 같습니다.

핵심 원리: 토큰 버짓 기반 라우팅

Dual-Pool의 핵심은 단순합니다. 요청마다 예상 최대 토큰 수를 추정하고, 임계값을 기준으로 두 풀 중 하나에 할당합니다.

요청의 예상 토큰 합 = 입력 토큰 + 예상 출력 토큰

예상 출력 토큰을 모르는 경우(대부분의 실제 상황)에는 다음 두 가지 근사를 씁니다.

1. 요청 파라미터: max_tokens 값을 상한으로 사용합니다.
2. 히스토리 기반 분류: 같은 API 경로 또는 시스템 프롬프트 해시로 이전 요청 길이 분포를 추적해 P75 또는 P90 값을 기준으로 분류합니다.

임계값 설정은 워크로드 특성에 따라 다르지만, 논문에서 보고한 실험에서는 출력 512토큰을 기준으로 short/long을 나눴습니다.

아키텍처: 두 풀의 구조

flowchart TB
    A[클라이언트 요청] --> B[라우터\nToken-Budget 분류기]
    B -->|예상 토큰 < 임계값| C[Short-Context 풀\nvLLM 인스턴스 A]
    B -->|예상 토큰 >= 임계값| D[Long-Context 풀\nvLLM 인스턴스 B]
    C --> E[Kueue LocalQueue\nshort-pool]
    D --> F[Kueue LocalQueue\nlong-pool]
    E --> G[GPU 워커 그룹 A\n작은 KV 캐시 요청]
    F --> H[GPU 워커 그룹 B\n큰 KV 캐시 요청]
    G --> I[응답 반환]
    H --> I

Short-context 풀은 KV 캐시를 빠르게 회전시켜 높은 throughput을 유지합니다. Long-context 풀은 긴 생성을 방해 없이 완료할 수 있는 충분한 KV 캐시 메모리를 확보합니다. 두 풀은 서로 선점 간섭을 일으키지 않습니다.

Kueue LocalQueue 연동 구현

ThakiCloud의 ai-platform은 Kubernetes 위에서 Kueue를 통해 GPU 워크로드를 스케줄링합니다. 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"       # short 풀: 작은 컨텍스트 한도
            - "--gpu-memory-utilization"
            - "0.7"        # KV 캐시를 짧게 쓰고 빠르게 회전
          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 풀: 넉넉한 컨텍스트 허용
            - "--gpu-memory-utilization"
            - "0.90"       # KV 캐시를 크게 확보
          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토큰 임계값은 워크로드에 따라 달라집니다. 실제 운영에서는 다음 지표를 7일 이상 수집한 뒤 조정하는 것을 권장합니다.

• 요청별 실제 출력 토큰 분포 (P50, P90, P99)
• 풀별 preemption rate (vllm:num_preemptions_total Prometheus 메트릭)
• 풀별 vllm:num_requests_waiting 대기 큐 깊이

Short 풀 대기 큐가 지속적으로 깊어진다면 임계값을 낮추거나 short 풀 replica를 늘려야 합니다. Long 풀 GPU 사용률이 낮다면 임계값을 올려 long으로 가는 요청을 줄입니다.

KEDA 오토스케일링 연동

vLLM Prometheus 메트릭 기반 KEDA ScaledObject를 추가하면 풀별로 독립적인 오토스케일링이 가능합니다.

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"

KEDA 메트릭 기반 스케일링은 단순 HTTP RPS 기반보다 추론 부하에 더 직접 대응합니다. 위 임계값 5는 현재 대기 요청이 5개를 초과하면 scale-up을 시작하라는 의미입니다.

모델 공유 vs 인스턴스 분리

두 풀이 반드시 서로 다른 vLLM 인스턴스를 써야 하는 것은 아닙니다. 동일 모델을 다른 --max-model-len 설정으로 띄우는 것이 기본 구성이지만, 메모리 예산이 넉넉하다면 단일 vLLM 인스턴스에 두 개의 외부 포트를 열고 내부적으로 priority class를 달리 적용하는 방법도 있습니다.

다만 preemption 간섭을 완전히 차단하려면 인스턴스 분리가 더 명확합니다. KV 캐시 메모리는 vLLM 프로세스 내에서 공유되기 때문입니다.

ThakiCloud ai-platform 적용 관점

ThakiCloud의 ai-platform은 멀티테넌트 환경에서 여러 고객의 추론 워크로드를 단일 GPU 클러스터에서 서빙합니다. Dual-Pool Routing은 이 환경에서 두 가지 이점을 더합니다.

첫째, 테넌트 간 간섭을 줄입니다. 짧은 챗봇 응답이 주인 고객사 A의 요청이, 긴 문서 분석이 주인 고객사 B의 배치 요청에 밀리는 상황은 SLO 위반으로 이어집니다. 풀 분리는 이 간섭을 구조적으로 차단합니다.

둘째, GPU 예산 효율이 높아집니다. 논문이 측정한 31~42% GPU 시간 절감은 같은 GPU 예산으로 더 많은 요청을 소화하거나, 동일 처리량을 더 적은 GPU로 달성한다는 의미입니다. 온프렘 자원이 고정된 환경에서 이 절감률은 곧 서빙 비용 절감으로 직결됩니다.

Kueue LocalQueue를 이미 사용 중인 ThakiCloud 클러스터에서는 Short/Long 큐 선언과 라우터 배치만으로 이 구조를 추가할 수 있습니다. 기존 vLLM Deployment 스펙과의 호환성도 높아 적용 범위가 넓습니다.

정리

Dual-Pool Token-Budget Routing이 해결하는 문제는 단순합니다. 짧은 요청과 긴 요청이 같은 대기열에 섞이면 짧은 요청이 손해를 봅니다. 이를 대기열 단계에서 분리하면 각 유형의 요청이 자기 속도로 처리됩니다.

arXiv 2604.08075가 측정한 GPU 시간 31~42% 절감, preemption rate 5.4배 감소, P99 TTFT 6% 개선은 구현 복잡도에 비해 효과가 큰 기법입니다. Kubernetes 환경에서는 Kueue LocalQueue 두 개, vLLM Deployment 두 개, 경량 라우터 하나로 이 구조를 구현할 수 있습니다.

원 뉴스: My entire AI stack is now Chinese · twitter

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

원 뉴스: Boris Cherny on the five archetypes of future roles · twitter

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

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

ما الذي أُعلن؟

لم يكن الإعلان مجرد تقرير مستقل من الشركتين، بل كان إعلاناً عن مشروع وطني ضخم وصفه الرئيس بـ”الثورة الصناعية للذكاء الاصطناعي على النمط الكوري”. الجهتان المستثمرتان: مجموعة Samsung بمبلغ 2,655 تريليون وون، ومجموعة SK بمبلغ 2,100 تريليون وون، على مدى عشر سنوات داخل كوريا، ليبلغ المجموع 4,755 تريليون وون، أي ما يعادل 6.5 أضعاف الميزانية الحكومية السنوية (نحو 728 تريليون وون).

أشار الرئيس التنفيذي لي جيه-يونغ إلى مدينة غوانغجو مباشرة بوصفها الموقع المرشح لمجمع أشباه الموصلات الجديد، قائلاً: “نخطط لاتخاذ غوانغجو موقعاً مرشحاً حيث نتطلع إلى الحصول على دعم حوافز”. وأكد الرئيس التنفيذي تشوي تاي-وون أن الهدف هو تحويل كوريا من “دولة تستهلك الذكاء الاصطناعي إلى دولة تصدّره”. كما طالب الرئيس التنفيذي لـSK hynix غوانغ نو-جيونغ بتطبيق قانون أشباه الموصلات الخاص على مجمع Yongin وبتحسين ظروف المعيشة في المناطق.

تجدر الإشارة إلى أن مبلغ 4,755 تريليون وون يمثل إجمالي المبالغ المخططة للتنفيذ على مدى عشر سنوات أو أكثر، وليس نفقات سنوية. يبلغ إجمالي الإنفاق الرأسمالي السنوي للشركتين حالياً نحو 70 تريليون وون (نحو 41 تريليون لـSamsung DS ونحو 29 تريليون لـSK hynix). ينبغي التمييز بين حجم الإعلان ووتيرة التنفيذ السنوية.

ملاحظة حول التحويل إلى الدولار: المبلغ المعلن مُقوَّم بالوون الكوري وهو المرجع المعتمد. وبسعر 1,380 وون لكل دولار، تعادل 4,755 تريليون وون نحو 3.4 تريليون دولار.

هيكل الاستثمار: 800 تريليون وون لمصانع المنطقة الجنوبية الغربية و15 غيغاواط لمراكز البيانات

أكثر الالتزامات إلزامية ضمن إجمالي 4,755 تريليون وون هي مصانع الذاكرة في المنطقة الجنوبية الغربية (هونام). ستضخ كل من Samsung وSK hynix 400 تريليون وون، ليبلغ مجموع استثمارهما 800 تريليون وون لإنشاء أربعة مصانع ذاكرة (مصنعان لكل شركة). وتنظر Samsung في غوانغجو موقعاً مرشحاً. وتوزعت بقية البنود على النحو التالي:

flowchart TB
    A["Samsung + SK hynix<br/>استثمارات محلية لعشر سنوات<br/>4,755 تريليون وون"] --> B["Samsung Electronics<br/>2,655 تريليون"]
    A --> C["SK Group<br/>2,100 تريليون"]
    B --> B1["أشباه الموصلات<br/>Pyeongtaek + Yongin<br/>~2,030 تريليون"]
    B --> B2["تغليف HBM<br/>تشونغتشيونغ<br/>140 تريليون"]
    C --> C1["مراكز بيانات AI<br/>1,000 تريليون - 15GW"]
    C --> C2["أشباه الموصلات<br/>Yongin<br/>600 تريليون"]
    C --> C3["زيادة إنتاج NAND<br/>Cheongju<br/>100 تريليون"]
    B --> D["مصانع الذاكرة في المنطقة الجنوبية الغربية<br/>4 مصانع - 800 تريليون<br/>مشترك بين الشركتين"]
    C --> D

يستحق الاهتمام بند مراكز بيانات الذكاء الاصطناعي من جانب SK، إذ تقود SKT مشروعاً بقيمة 1,000 تريليون وون لإنشاء مراكز بيانات ذكاء اصطناعي بسعة 15 غيغاواط على المستوى الوطني بحلول عام 2035. ونظراً إلى أن تكلفة إنشاء غيغاواط واحد من مراكز البيانات تتراوح عادةً بين مليار وثلاثة مليارات دولار، فإن هذا الحجم يبدو منطقياً مع ما يُخصص لـ15 غيغاواط. يُضاف إلى ذلك استثمار SK hynix المنفصل بقيمة 100 تريليون وون لزيادة إنتاج NAND Flash في Cheongju. وخصصت Samsung نحو 2,030 تريليون وون لأشباه الموصلات في Pyeongtaek وYongin، و140 تريليون وون لتغليف HBM في تشونغتشيونغ.

لماذا الآن؟ ولماذا بهذا الحجم؟ دورة HBM الفائقة

تتمحور القوة الدافعة وراء هذه الأرقام الضخمة حول عامل واحد: طلب HBM، أي ذاكرة النطاق الترددي العالي. تُعدّ HBM ذاكرة فائقة القيمة تُكدَّس على مسرّعات الذكاء الاصطناعي، وتبلغ قيمتها بين خمسة وسبعة أضعاف DRAM العادية. ومن المتوقع أن ينمو سوق HBM العالمي من نحو 35 مليار دولار عام 2025 إلى نحو 54.6 إلى 58 مليار دولار عام 2026، أي بنسبة نمو تتجاوز 58%.

جذور الطلب هي إنفاق مشغلي الخدمات السحابية الكبار. تجاوز إنفاق Amazon وMicrosoft وGoogle وMeta وOracle الرأسمالي على البنية التحتية للذكاء الاصطناعي عام 2026 حاجز 600 مليار دولار، وارتفعت حصة الذاكرة منه إلى نحو 30% بعد أن كانت 8% بين عامَي 2023 و2024. ويمثل طلب Blackwell وRubin من NVIDIA وحده مئات المليارات من الدولارات في قوائم الطلبيات، وقد بيعت مسبقاً إنتاج عام 2026 لموردي HBM الثلاثة: SK hynix وMicron وSamsung.

الجوهر هنا أن هذه الاختناقات تنشأ من شح الطاقة الإنتاجية لا من شح رأس المال. فالمشكلة ليست نقص الأموال بل نقص المصانع. ولهذا السبب تتجه الشركتان في آنٍ واحد نحو توسع ضخم في الطاقة الإنتاجية. سجّلت SK hynix هامش ربح تشغيلي بلغ 47% في الربع الثالث من عام 2025، وهو ما أتاح دورة إعادة استثمار هذه الأرباح في منشآت Yongin وCheongju.

دعم السياسات: قانون أشباه الموصلات الخاص

اعتمدت كوريا تاريخياً على الإعفاءات الضريبية لدعم قطاع أشباه الموصلات بدلاً من منح الدعم النقدي المباشر كما تفعل الولايات المتحدة وأوروبا. رفع قانون K-Chips الصادر في فبراير 2025 معدل الإعفاء الضريبي على استثمارات المنشآت للشركات الكبرى من 15% إلى 20%، ومدّد إعفاءات البحث والتطوير حتى عام 2031. ويُقدَّر الأثر الضريبي المشترك للشركتين بنحو 6 تريليونات وون.

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

المنافسة العالمية: التوسع المتزامن لموردي HBM الثلاثة

بيعت مخزونات إنتاج HBM لعام 2026 لدى الموردين الثلاثة بالكامل. التحدي الحقيقي يكمن في عامَي 2027 و2028: إن لم تكن المصانع الكورية كافية عندئذٍ، فقد تذهب الحصة السوقية من طلب HBM4 وHBM5 إلى Micron. وعلى صعيد التصنيع، خصصت TSMC 165 مليار دولار في أريزونا وحدها لاستيعاب طاقة تغليف CoWoS حتى 2026، فيما انسحبت Intel فعلياً من منافسة HBM في سياق إعادة هيكلة أعمال التصنيع.

الكهرباء هي الاختناق الحقيقي: التنافس على مواقع مراكز البيانات

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

خطة SK لبناء مراكز بيانات ذكاء اصطناعي بسعة 15 غيغاواط بقيمة 1,000 تريليون وون بحلول 2035 ليست مجرد استثمار عقاري. فحين يبني مصنّع الذاكرة مراكز البيانات التي يُورّد إليها HBM مباشرةً، يتمكن من خلق طلبه الخاص واستعادة قوته التفاوضية في سلسلة التوريد التي تُحدد فيها NVIDIA ومشغلو الخدمات السحابية الكبار المواصفات. وتسير Samsung في الاتجاه ذاته نحو التكامل الرأسي من خلال مركز بيانات الذكاء الاصطناعي في Haenam ومصنع لوحات خوادم الذكاء الاصطناعي في Sejong.

ردود فعل السوق

عقب الإعلان مباشرةً، أغلق سهم Samsung Electronics بعد تذبذب عند 323,000 وون، واستعادت SK hynix المرتبة الأولى من حيث القيمة السوقية في بورصة كوسبي متجاوزةً Samsung Electronics في 30 يونيو. قارن بعض المحللين هذا التطور بتجاوز Microsoft لـCisco إبان فقاعة الدوت كوم عام 2000 واعتبروه إشارةً محتملة إلى ذروة السوق، غير أن غالبية المحللين أحجموا عن الحكم بالمبالغة في التقييم معربين عن رغبتهم في متابعة الأداء الفعلي والظروف الاقتصادية الكلية. وثمة وجهة نظر ترى أن التحول في القيمة السوقية مبالغ فيه، إذ تبقى تقديرات الأرباح التشغيلية لـSamsung لعام 2026 أعلى (361 تريليون وون) مقارنةً بـSK hynix (262 تريليون وون).

منظور ThakiCloud: كلما توسعت الأجهزة، ازداد الدور الحاسم لطبقة البرمجيات

جوهر هذا الإعلان هو أن كوريا تندمج رأسياً في البنية التحتية للذكاء الاصطناعي على المستوى الوطني، وهو ما يتقاطع مباشرةً مع أعمال ThakiCloud في منصة ai-platform.

مع توسع مراكز بيانات الذكاء الاصطناعي المحلية إلى سعة 15 غيغاواط، يتنامى الطلب على البنية التحتية متعددة المستأجرين لتدريب النماذج وخدمتها. تستهدف ThakiCloud هذه الطبقة تحديداً من خلال جدولة GPU المبنية على Kubernetes وKueue وخدمة النماذج عبر vLLM. حين توفر المصانع ومراكز البيانات الأجهزة، تصبح ثمة حاجة إلى مستوى تحكم يشغّل أحمال عمل العملاء المتعددين بشكل معزول وآمن.

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

والأهم من ذلك: كلما زادت وفرة HBM وحسّاب الأداء العالي، انتقل محور المنافسة من “كم حجم ما اشتريته” إلى “كم كفاءة تشغيله”. تُقرر إدارة دورة حياة GPU والجدولة في نهاية المطاف مستوى التكلفة. هنا تحديداً تكمن قيمة ThakiCloud: طبقة البرمجيات التي تُشغّل الأجهزة التي ستُنتجها هذه الاستثمارات البالغة 4,755 تريليون وون بكفاءة قصوى.

المحاذير والحجج المضادة: التفاؤل المطلق سابق لأوانه

قراءة هذا الإعلان بوصفه خبراً إيجابياً حصراً ينطوي على مخاطر. إليك الحجج الصادقة في الاتجاه المعاكس.

أولاً، يمثل مبلغ 4,755 تريليون وون “خطة” تراكمية لعشر سنوات وليس إنفاقاً سنوياً موثقاً. الطابع الحكومي للمناسبة قد يضخ انحيازاً تصاعدياً في الأرقام، وقد عانى مجمع Yongin البالغ قيمته 622 تريليون وون الذي أُعلن عنه عام 2024 من تأخيرات في الجدول الزمني. ثمة دوماً فجوة بين الإعلان والتنفيذ.

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

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

أخيراً، تبرز تحذيرات من أن التقييمات السوقية تجاوزت الأداء الفعلي. الحجم الإعلاني لا يضمن بالضرورة نتائج الأعمال.

الخلاصة

إطار إعلان 29 يونيو 2026 واضح: Samsung وSK hynix ستستثمران 4,755 تريليون وون محلياً خلال عشر سنوات، يتمحور في جوهره حول أربعة مصانع ذاكرة في المنطقة الجنوبية الغربية بقيمة 800 تريليون وون ومراكز بيانات ذكاء اصطناعي بسعة 15 غيغاواط من SK بقيمة 1,000 تريليون وون. المحرك لكل هذا هو دورة HBM الفائقة، ونجاح المشروع مرتبط بسرعة توفير البنية التحتية للكهرباء والمياه.

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

المصادر

• Financial News، أربعة مصانع في المنطقة الجنوبية الغربية، Samsung وSK بـ4,755 تريليون وون (2026-06-29): https://www.fnnews.com/news/202606291837098645
• Newsis، Samsung وSK: 800 تريليون وون لمحور أشباه الموصلات في هونام (2026-06-29): https://www.newsis.com/view/NISX20260629_0003687807
• Aju News، مراكز بيانات الذكاء الاصطناعي بـ15 غيغاواط من SKT (2026-06-29): https://www.ajunews.com/view/20260629171803513
• Hankyung، 600 تريليون وون لـYongin و100 تريليون وون لـCheongju (2026-06-29): https://www.hankyung.com/article/2026062943107
• CNBC، South Korea Samsung SK Hynix mega-projects (2026-06-29): https://www.cnbc.com/2026/06/29/samsung-sk-hynix-reported-1point3-reported-trillion-spending-plans.html
• SK hynix، توقعات السوق لعام 2026 (دورة HBM الفائقة): https://news.skhynix.com/2026-market-outlook-focus-on-the-hbm-led-memory-supercycle/
• TrendForce، Micron ترفع الإنفاق الرأسمالي إلى 20 مليار دولار مع بيع HBM لعام 2026 بالكامل (2025-12-18): https://www.trendforce.com/news/2025/12/18/news-micron-hikes-capex-to-20b-with-2026-hbm-supply-fully-booked-hbm4-ramps-2q26/
• Korea Policy Briefing، قانون أشباه الموصلات الخاص يُقرّ في البرلمان (2026-01-30): https://www.korea.kr/briefing/pressReleaseView.do?newsId=156742072