-->

صورة تجسّد بنية يتقاسم فيها معالجا B200 مهام Prefill وDecode تجسيد لبنية خدمة مفصولة حيث يتولى معالج واحد Prefill والآخر Decode، بينما تنتقل ذاكرة KV المؤقتة عبر NVLink.

نظرة عامة

“إن كان لديك معالجان رسوميان، أليس من المنطقي تشغيل Prefill وDecode كل على حدة ليصبح الأداء أسرع؟” هذه فكرة يفكر بها كل من يعمل على أنظمة الخدمة (serving) عاجلاً أم آجلاً. اختبرنا هذا الافتراض فعلياً على عتاد حقيقي. على معالجَي NVIDIA B200، شغّلنا ثلاثة إعدادات بواسطة vLLM 0.24 على نفس حمل العمل، وقسنا عدد الرموز (tokens) المُولّدة في الثانية (TPS). النموذجان المستهدفان هما Qwen3.6-27B-NVFP4 الذي أصدرته NVIDIA، وgemma-4-26B-A4B-it-FP8-Dynamic الذي أصدرته RedHat.

لنقل النتيجة أولاً: في بيئة تحتوي على معالجين فقط، لم يكن فصل Prefill/Decode هو الفائز في الإنتاجية الإجمالية. بل كان الفصل الأقل في إجمالي TPS، وبدلاً من ذلك حقق قيمته في خفض زمن الانتظار بين الرموز (inter-token latency) بمقدار ثلاث إلى أربع مرات في حركة المرور ذات المدخلات الطويلة والمخرجات القصيرة. لكن هذه النتيجة لا تتناقض مع المكاسب الكبيرة التي تُبلغ عنها NVIDIA أو أنظمة الخدمة الصينية واسعة النطاق. فائدة الفصل هي تحسين يعتمد على الحجم (scale) ومعايير مستوى الخدمة (SLO)، ونحن قسنا الطرف الصغير من ذلك المنحنى فقط. لذلك يجمع هذا المقال بين أرقامنا المقاسة فعلياً وقصة تشغيل معالج B200 عارٍ (bare metal)، إضافة إلى دليل حاسم مبني على أدلة من DistServe وSplitwise وMooncake وDeepSeek وNVIDIA Dynamo، حول متى نفصل ومتى نكتفي ببساطة بالتوازي على مستوى البيانات (data parallelism) أو التوازي على مستوى المُوتِّرات (tensor parallelism).

لماذا أجرينا هذه التجربة

Prefill وDecode عمليتان مختلفتان في طبيعتهما. فـPrefill مرحلة كثيفة الحوسبة تدفع كامل المُدخل دفعة واحدة، بينما Decode مرحلة كثيفة على مستوى عرض النطاق الترددي للذاكرة تستخرج الرموز واحداً تلو الآخر. عند مزج الاثنين على معالج واحد، تتداخل عملية Prefill الثقيلة مع تدفق Decode فتتقطع الرموز. لهذا أصبح فصل (disaggregation) العقد المخصصة لـPrefill عن العقد المخصصة لـDecode معياراً متنامياً في العناقيد الكبيرة.

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

بيئة التجربة

كان المضيف (host) عبارة عن عتاد عارٍ (bare metal) لا يحتوي إلا على المُشغِّل (driver)، وبقية حزمة البرمجيات تم تأكيدها وتحديدها أثناء التشغيل.

العنصر القيمة
GPU NVIDIA B200 × 2 (183GB HBM لكل منهما)، NVLink (NV18) بين GPU0 وGPU1
المُشغِّل (Driver) 580.95.05 (سلسلة CUDA 13)
vLLM / torch vLLM 0.24.0 / torch 2.11.0+cu130
خلفية الانتباه (Attention backend) Triton (تعذّر JIT الخاص بـFlashInfer لعدم وجود nvcc من CUDA toolkit على المضيف)
النموذج A nvidia/Qwen3.6-27B-NVFP4 (dense 27B، انتباه هجين، أوزان NVFP4 + KV بصيغة FP8)
النموذج B RedHatAI/gemma-4-26B-A4B-it-FP8-Dynamic (MoE بحجم 26.5B، منها 4B نشطة، FP8 W8A8)

أوزان كلا النموذجين تتسع في معالج B200 واحد. حجم NVFP4 نحو 15GB وFP8 نحو 27GB، فلا حاجة لتقسيمها عبر التوازي على مستوى المُوتِّرات. لذلك قارنّا ثلاثة إعدادات تستخدم المعالجين معاً: TP=2 الذي يوزّع نسخة واحدة على المعالجين عبر التوازي على مستوى المُوتِّرات، وDP=2 الذي يضع نسختين، واحدة على كل معالج، عبر التوازي على مستوى البيانات، والفصل 1P1D الذي يضع Prefill على GPU0 وDecode على GPU1 وينقل ذاكرة KV المؤقتة عبر NIXL.

طريقة القياس

لتوليد الحِمل استخدمنا أداة vllm bench serve المدمجة في vLLM، وضبطنا حمل العمل على محورين: حمل ثقيل على Decode (مُدخل 512، مُخرج 2048)، وحمل ثقيل على Prefill (مُدخل 7500، مُخرج 200). أُرسلت الطلبات كلها دفعة واحدة لرصد الإنتاجية عند التشبع (saturation). المقاييس التي رصدناها هي إجمالي إنتاجية المخرجات (TPS) وزمن الانتظار بين الرموز (TPOT).

شُغِّل الخادم وأُجري القياس بالشكل التالي. متغيرات بيئة الخلفية (backend) كانت ضرورية في هذا الإعداد، ونوضّح السبب لاحقاً.

# 공통 환경 (nvcc 부재 대응)
export VLLM_ATTENTION_BACKEND=TRITON_ATTN
export VLLM_USE_FLASHINFER_SAMPLER=0

# 데이터병렬 2복제 (한 엔드포인트, 두 장)
vllm serve $MODEL --data-parallel-size 2 --gpu-memory-utilization 0.90 \
  --max-model-len 32768 --trust-remote-code

# 벤치 (Decode 무거운 워크로드 예시)
vllm bench serve --model $MODEL --dataset-name random \
  --random-input-len 512 --random-output-len 2048 \
  --num-prompts 128 --request-rate inf --ignore-eos

تم فصل الخوادم بتشغيل خادم Prefill وخادم Decode كل على حدة، وربطهما بـNixlConnector عبر --kv-transfer-config، ثم جُمعا عبر الوكيل (proxy) الذي توفره vLLM.

# Prefill (GPU0, producer)
CUDA_VISIBLE_DEVICES=0 VLLM_NIXL_SIDE_CHANNEL_PORT=5600 \
vllm serve $MODEL --port 8100 --tensor-parallel-size 1 \
  --kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_producer"}'

# Decode (GPU1, consumer)
CUDA_VISIBLE_DEVICES=1 VLLM_NIXL_SIDE_CHANNEL_PORT=5601 \
vllm serve $MODEL --port 8200 --tensor-parallel-size 1 \
  --kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_consumer"}'

النتائج: Qwen3.6-27B-NVFP4

البنية (Topology) Decode TPS Prefill TPS Decode TPOT Prefill TPOT
DP=2 (توازي البيانات) 8,245 2,230 11.4ms 32.8ms
TP=2 (توازي المُوتِّرات) 7,655 1,545 12.2ms 44.1ms
1P1D (فصل) 6,023 1,330 14.8ms 9.9ms

الصورة واضحة. إجمالي TPS في المرتبة الأولى لصالح توازي البيانات في كلا حملي العمل، بينما يأتي الفصل في المرتبة الأخيرة. في حمل العمل الثقيل على Decode، يفوق توازي البيانات توازي المُوتِّرات بنسبة 8% ويفوق الفصل بنسبة 37%. وفي حمل العمل الثقيل على Prefill تتسع الفجوة أكثر، إذ يبلغ توازي البيانات 1.7 ضعف الفصل. مع وجود معالجين فقط، فإن تخصيص أحدهما لـPrefill فقط يُدفع ثمنه كاملاً كوقت خمول.

لكن هناك عموداً واحداً فاز فيه الفصل بلا منازع. زمن الانتظار بين الرموز في حمل العمل الثقيل على Prefill بلغ 9.9ms، أي نحو ربع قيمة توازي المُوتِّرات البالغة 44ms أو توازي البيانات البالغة 33ms. هذا هو سبب وجود الفصل أصلاً. ففي الإعداد المختلط، تتداخل عملية Prefill الثقيلة مع Decode فتتقطع الرموز، أما في إعداد الفصل فإن المعالج المخصص لـDecode لا يتأثر بـPrefill فتخرج الرموز بسلاسة. والتفسير المدرسي بأن الفصل تقنية من أجل “الانتظام” لا “الكمية” ظهر هنا بالأرقام بالضبط.

النتائج: gemma-4-26B-A4B-it-FP8-Dynamic

البنية (Topology) Decode TPS Prefill TPS Decode TPOT Prefill TPOT
TP=2 (توازي المُوتِّرات) 7,069 1,730 13.6ms 40.9ms
1P1D (فصل) 5,766 1,474 17.9ms 8.7ms
DP=2 (توازي البيانات) غير مقاس غير مقاس فشل فشل

gemma نموذج MoE، فكانت حزمة الخدمة الخاصة به أصعب من النموذج dense. عملت TP والفصل بشكل طبيعي، لكن توازي البيانات فشل في التشغيل في محاولتين، وكلتاهما فشلتا في المسار الذي يجمع MoE مع توازي البيانات في vLLM 0.24. فشلت المحاولة الأولى عند تأكيد (assertion) الإحماء (warmup) الخاص بـCUTLASS MoE، وفشلت المحاولة الثانية، بعد خفض سقف الرموز في الدفعة، أثناء التمرير الأمامي (forward pass) لـMoE ضمن تحديد ملف ذاكرة KV. أي أن تشغيل gemma بتوازي البيانات غير مدعوم حالياً في هذا الإصدار، وهذه الحقيقة بحد ذاتها نتيجة مهمة. نماذج MoE أقل استقراراً في توازي البيانات من النماذج dense. وبمقارنة الإعدادين القابلين للقياس فقط، يستمر النمط نفسه مع gemma: إجمالي TPS لتوازي المُوتِّرات أعلى من الفصل. كما أن زمن انتظار Prefill للفصل البالغ 8.7ms يتفوق بوضوح على 40.9ms لتوازي المُوتِّرات، تماماً كما مع Qwen.

إذن متى نفصل، ومتى نكتفي بـDP/TP

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

هناك ورقة بحثية تناولت نقطة التقاطع (crossover) هذه مباشرة. “Beyond the Buzz: A Pragmatic Take on Inference Disaggregation” (arXiv:2506.05508) توضح أن فائدة الفصل تكون في أقصاها عند حركة المرور الثقيلة على Prefill، بينما على العكس، في حركة المرور التي يهيمن عليها Decode بمخرجات طويلة، أو معايير SLO مرنة، أو نماذج صغيرة، يتفوق وضع كل شيء على نفس المعالج (piggybacking). وتوضح أن النماذج الصغيرة بحجم 8B تقريباً لديها عدد قليل من المعالجات المخصصة لها، فالمجال المتاح لفصل Prefill عن Decode ضيق أصلاً، كما أن ذاكرة KV تتسع بارتياح في HBM فلا داعي لنقلها. حالتنا، بتشغيل نموذج 27B على معالجين، تقع تماماً في تلك المنطقة.

الشروط التي يفوز فيها الفصل

الحالات التي أبلغت عن مكاسب كبيرة من الفصل تشترك في شروط مشتركة. أولاً، عدد المعالجات كبير جداً. تصف مراجعة UCSD Hao AI Lab النقطة التي يصبح الفصل ضرورياً عندها بأنها في نطاق مئات إلى آلاف المعالجات (مقال المراجعة). ثانياً، معايير زمن الانتظار (SLO) صارمة. المؤشر الأساسي لورقة DistServe (OSDI 2024)، الورقة الرائدة في الفصل، ليس الإنتاجية الخام بل الـgoodput، أي كم ضعفاً من الطلبات يمكن خدمتها مع الحفاظ على SLO فوق 90%. تُبلغ الورقة عن تحمّل معايير أشد صرامة على عنقود A100 يربط نماذج من OPT 13B إلى 175B عبر NVLink (USENIX، arXiv:2401.09670). ثالثاً، تُشغَّل نماذج كبيرة أو من نوع MoE بتوازي غير متماثل. أفصحت عائلة DeepSeek-V3/R1 عن تقسيم Prefill إلى توازي خبراء ضيق وDecode إلى توازي خبراء واسع، مما رفع إنتاجية Decode كثيراً مقارنة بتوازي المُوتِّرات، في إعداد يوزّع Prefill على 4 عقد وDecode على 9 عقد على 96 معالج H100 (LMSYS). رابعاً، ذاكرة KV كبيرة وتُعاد استخدامها بسبب السياق الطويل. يُبلغ Mooncake عن قوة في السياق الطويل عبر فصل يتمحور حول ذاكرة KV (arXiv:2407.00079). خامساً، توجد شبكة نقل عالية السرعة لنقل KV بتكلفة منخفضة. نقل Splitwise ذاكرة KV عبر InfiniBand، ونقل Mooncake عبر RDMA بسرعة مئات الجيجابت في الثانية، لخفض عبء النقل (Microsoft Research). والمضاعفات الكبيرة التي تُبلغ عنها NVIDIA مع Dynamo وGB200 NVL72 هي أيضاً نتيجة تشغيل نموذج ضخم بحجم 671B على رفوف بعشرات المعالجات (NVIDIA).

الشروط التي يكون فيها DP/TP أفضل

في المقابل، في الشروط التالية يكون التكرار البسيط عبر توازي البيانات أو توازي المُوتِّرات هو الأفضل: عندما يكون النموذج صغيراً بما يكفي ليتسع في معالج أو معالجين، وعندما تهيمن على حركة المرور عمليات Decode بسبب طول المخرجات، وعندما تكون معايير SLO مرنة، وعندما يكون عدد المعالجات قليلاً بحيث لا تتوفر مساحة كافية لملء مجمعي (pools) Prefill وDecode منفصلين دون خمول، وعندما يكون العمل تطويرياً أو حمل عمل منخفض QPS ولمرة واحدة لا يبرر تعقيد تشغيل الفصل، وعندما يكون عرض النطاق الترددي بين العقد بمستوى PCIe لا بمستوى NVLink أو InfiniBand بحيث يصبح نقل KV نفسه عنق الزجاجة. بيئة تجربتنا 2×B200 تطابق بدقة عدة بنود من هذه القائمة. النموذج 27B يتسع في معالج واحد، والمعالجات معالجان فقط، والهدف كان الإنتاجية الإجمالية.

المتغيرات الأربعة التي تحسم القرار

في النهاية، يُحسم الاختيار بمزيج من أربعة متغيرات: نسبة الحوسبة بين Prefill وDecode (كلما كان Prefill أثقل، كان الفصل أكثر ملاءمة)، صرامة معيار زمن الانتظار (كلما زادت الصرامة، كان الفصل أكثر ملاءمة)، حجم المعالجات (كلما كبر، كان الفصل أكثر ملاءمة)، والوفورات من نقل KV مقارنة بتكلفته (كلما كانت الذاكرة المؤقتة كبيرة ومُعاد استخدامها، أو كانت الشبكة أسرع، كان الفصل أكثر ملاءمة). إذا اتجه أي واحد من هذه المتغيرات في الاتجاه المعاكس، تتقلص فائدة الفصل، وإذا اجتمع عدد قليل من المعالجات مع نموذج صغير ومعيار SLO مرن، يصبح الفصل خسارة صافية.

ملخص الأدلة

النظام المكسب المُبلَّغ عنه الحجم المقاس المصدر
DistServe (OSDI’24) 7.4 ضعف الطلبات أو 12.6 ضعف صرامة SLO مع الحفاظ على SLO OPT 13B~175B، عنقود A100 عبر NVLink arXiv:2401.09670
Splitwise (ISCA’24) 1.4 ضعف الإنتاجية (تكلفة أقل 20%) أو 2.35 ضعف الإنتاجية فصل مجمعي prompt/token، نقل KV عبر InfiniBand MS Research
Mooncake (Kimi) حتى 525% إنتاجية ضمن SLO محاكاة حتى 800Gbps RDMA، تركيز على السياق الطويل arXiv:2407.00079
DeepSeek-V3/R1 إنتاجية Decode أعلى 5.2 ضعف مقارنة بـTP 96 معالج H100، Prefill على 4 عقد / Decode على 9~18 عقدة LMSYS
NVIDIA Dynamo + NVL72 حتى عشرات الأضعاف على DeepSeek-R1 671B، رف GB200 NVL72 NVIDIA
Beyond the Buzz (دراسة نقطة التقاطع) تتقلص المكاسب أو تنعكس في النماذج الصغيرة وحركة المرور التي يهيمن عليها Decode ومعايير SLO المرنة دراسة منهجية عبر النماذج والأحجام arXiv:2506.05508

بمعنى آخر، الفصل تقنية لحالة وضع نموذج ضخم جداً عبر عدد كبير من المعالجات، وتحقيق هدف زمن انتظار صارم فوق شبكة عالية السرعة. أما إذا كنت تشغّل نموذجاً متوسط الحجم على معالجين وتستهدف الإنتاجية الإجمالية، فإن توازي البيانات هو الإجابة، وهذه هي الخلاصة التي تشير إليها معاً قياساتنا الفعلية والأدبيات. المضاعفات أعلاه هي قيم قِيست عند الحجم المحدد الذي درسته كل ورقة، وبعضها (الأرقام الفعلية لـMooncake، وأرقام TensorRT-LLM الخاصة) متضاربة التعبير بين المصادر وتحتاج لإعادة تحقق قبل اقتباسها كما هي.

من العتاد العاري إلى تشغيل B200

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

أولاً، غاب مترجم CUDA nvcc، ففشلت FlashInfer عندما حاولت بناء أدوات أخذ العينات (sampler) ونوى الانتباه (attention kernels) وقت التشغيل. وعندما بدّلنا خلفية الانتباه إلى Triton وأوقفنا أداة أخذ العينات الخاصة بـFlashInfer، عمل كل شيء بشكل طبيعي. وهذا يعني أيضاً أن تثبيت nvcc يترك مجالاً للسعي نحو TPS أعلى باستخدام نوى FlashInfer السريعة المخصصة لـBlackwell.

ثانياً، استغرق تشغيل الخادم الأول نحو 800 ثانية، وهي مدة طويلة جداً. يعود ذلك إلى torch.compile والتقاط رسم CUDA (CUDA graph capture)، وفي توازي البيانات، تجاوز تجميع نواتي المحرك في آن واحد المهلة الافتراضية لجاهزية vLLM البالغة 600 ثانية فتوقف. حللنا ذلك برفع المهلة إلى 1800 ثانية.

ثالثاً، يحتوي الانتباه الهجين في Qwen3.6 على حالة تلافيف (conv state) من عائلة Mamba، ونقلها عبر NIXL يتطلب تخطيطاً محدداً لحالة التلافيف. وبضبط VLLM_SSM_CONV_STATE_LAYOUT=DS كما أشارت رسالة الخطأ، نجح نقل KV، وتحقق واحد للدقة عبر الوكيل أكّد أن الفصل يعمل بشكل صحيح فعلياً.

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

من منظور ThakiCloud

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

المشكلة أن نقطة التقاطع هذه تختلف من شركة إلى أخرى ومن حمل عمل إلى آخر. فالنموذج 27B نفسه، توازي البيانات هو الإجابة على معالجين، لكن إذا وضعت النموذج نفسه على عشرات المعالجات لخدمة سياقات طويلة تحت معيار SLO صارم، يصبح الفصل هو الإجابة. وتخمين تلك الحدود بالحدس يحرق ميزانية المعالجات أو يُفوّت معيار الخدمة. هذا بالضبط ما نقوم به. نستخرج، فوق العتاد الفعلي وحركة المرور الفعلية لعملائنا، أرقاماً لكل بنية (topology) كما في هذا المقال لإيجاد تلك الحدود عبر القياس، ونبني منصة خدمة تنتقل بين توازي البيانات وتوازي المُوتِّرات والفصل بما يناسب حمل العمل. كما ندير خط أنابيب القياس وأتمتة الاتصال المستخدمَين في هذه التجربة كأصول قابلة لإعادة الاستخدام، بحيث يمكن اتخاذ القرار نفسه في ساعات لا أيام على النموذج التالي والعتاد التالي.

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

الخلاصة والحدود

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

نترك الحدود بصراحة أيضاً. بما أن خلفية الانتباه ثُبِّتت على Triton، لم نقس سقف FlashInfer الأصلي لـBlackwell ومسار NVFP4 السريع. تثبيت nvcc مهمة لاحقة. نظرنا إلى نقطة تشبع واحدة فقط لمعدل الطلبات ولم نرسم المنحنى الكامل لزمن الانتظار مقابل الإنتاجية. كما تركنا روافع إنتاجية خاصة بكل نموذج، مثل فك التشفير التخميني متعدد الرموز (speculative decoding) الخاص بـQwen وتوازي الخبراء الخاص بـgemma، كمحاور لاحقة. إضافة هذه قد ترفع الأرقام المطلقة، لكننا نرى أن الخلاصة الجوهرية لهذه التجربة، وهي أن الفصل على معالجين لا يخدم الإنتاجية الإجمالية، لن تتغيّر.

المراجع

참고

숫자 하나를 믿지 않는 평가: 이진 분해와 결정론 게이트로 짓는 주권형 LLM 심판 서비스

 

LLM을 채점자로 쓰는 ‘LLM-as-a-judge’는 이제 모델 개발의 기본값이지만, 2026년 들어 쌓인 증거는 단일 점수를 내는 스칼라 심판이 프롬프트와 위치에 취약하고 중간값으로 쏠리며 적대적 입력 앞에서 동전 던지기 수준으로 무너진다는 사실을 보여줍니다. 병원이나 은행, ...