نظرة عامة

كل من شغّل نموذج LLM محلياً يصطدم بالجدار نفسه: إذا كانت أوزان النموذج أكبر من ذاكرة الـ GPU، يفيض الزائد إلى ذاكرة الـ CPU. وراية -ngl في llama.cpp (عدد الطبقات التي توضع على الـ GPU) تفعل هذا بالضبط. المشكلة أنها تقطع فقط على مستوى الطبقة. تخلط الطبقة الواحدة موتّرات مختلفة الطبيعة تماماً (أوزان attention، وأوزان FFN، ومعاملات التطبيع)، ومع ذلك تُعامَل بمبدأ الكل أو لا شيء: إما أن يذهب الكل إلى الـ GPU أو يبقى على الـ CPU.

سبب خسارة هذا الوضع الكتلي بسيط. قد يجعل نفس الـ 1GB في الـ VRAM موتّراً أسرع 10 أضعاف وآخر أسرع ضعفين فقط. الـ VRAM مورد نادر، والقطع الكتلي يمنعك من انتقاء الموتّرات ذات الربح الأعلى لكل GB. يستهدف ATSInfer هذا بالضبط. فهو يحلّل أداء كل موتّر على الـ CPU والـ GPU ويملأ الـ VRAM بدءاً من الموتّرات ذات أعلى ربح سرعة لكل GB. إذا كان ktransformers الأخير حيلةً على “مستوى الخبير” تدفع خبراء MoE إلى الـ CPU (انظر مقالتنا ذات الصلة: إعادة إنتاج الـ 28 ضعفاً لـ ktransformers)، فإن ATSInfer هو التعميم الأدق على “مستوى الموتّر”. واللافت أنه ينطبق على النماذج الكثيفة (dense) وليس MoE فقط.

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

ATSInfer نظام استدلال هجين CPU-GPU مبنيّ كامتداد لـ llama.cpp بنحو 15 ألف سطر من C++. كما يقول الاسم، فإن “الجدولة الآلية للموتّرات (Automated Tensor Scheduling)” هي الجوهر، وتتشابك ثلاث آليات.

flowchart TB
    A["أوزان النموذج<br/>(RAM، تتجاوز سعة VRAM)"] --> B["تحليل لكل موتّر<br/>قياس ربح السرعة لكل GB"]
    B --> C{"التوزيع الثابت<br/>الموتّرات الأعلى ربحاً إلى VRAM أولاً"}
    C -->|"موتّرات عالية الربح"| D["مقيمة في VRAM"]
    C -->|"موتّرات منخفضة الربح"| E["مقيمة في RAM"]
    D --> F["نقل ديناميكي واعٍ بالحمل<br/>ترقية/تنزيل حسب حمل التشغيل"]
    E --> F
    F --> G["تنسيق غير متزامن بين CPU وGPU<br/>تداخل الحساب ونقل PCIe"]
    G --> H["إخراج الرموز<br/>prefill · decode"]

أولاً، التوزيع الثابت للموتّرات (static placement). قبل تحميل النموذج، يقيس مدى تسارع كل موتّر على الـ GPU، ثم يضع الموتّرات على الـ GPU بترتيب “أكبر سرعة مُعادة لكل GB من الـ VRAM مستخدَم”. هذا قريب من مسألة حقيبة الظهر (knapsack) ويستغل مباشرةً التباين على مستوى الموتّر الذي تجاهله التوزيع الكتلي.

ثانياً، النقل الديناميكي الواعي بالحمل (load-aware dynamic transfer). التوزيع الثابت وحده لا يكفي. خلال الاستدلال الفعلي، يتغير الحمل لحظةً بلحظة مع حجم الدفعة وطول السياق وعدد الطلبات المتزامنة. يرقّي ATSInfer موتّراً معيناً من الـ RAM إلى الـ GPU أو ينزّله بناءً على حالة التشغيل. إذا كان التوزيع الثابت هو خط الانطلاق، فالنقل الديناميكي هو تغيير المسار أثناء القيادة.

ثالثاً، التنسيق غير المتزامن بين CPU وGPU (asynchronous coordination). يُداخِل بين حساب الـ CPU وحساب الـ GPU ونقل الـ PCIe الذي يصل بينهما. التنفيذ الساذج يترك الـ GPU خاملاً ينتظر عمل الـ CPU أو حركة البيانات؛ وطبقة التنسيق هذه تملأ ذلك الوقت الخامل. تُبلّغ الورقة أن هذا يرفع متوسط استغلال SM (المعالج المتعدد التدفق) في الـ GPU بنحو 70%.

النتائج التي تبلّغ عنها الورقة

مرة أخرى: الأرقام أدناه قيم أبلغت عنها الورقة، لا شيء أعدنا إنتاجه. شيفرة ATSInfer لم تُنشر بعد (حتى نقاش التغريدات قال “أيها الباحثون، رجاءً شاركوا الشيفرة مع فريق llama.cpp”)، وإعادة إنتاج نموذج بحجم 120B مع RTX 4090 صعبة في البيئة المعزولة وراء هذه المقالة. لذا بدلاً من إعادة الإنتاج، نركّز على التحليل البنيوي والدلالات.

عنوان الورقة العريض: مقابل الأنظمة الهجينة الحالية (بما فيها إنزال llama.cpp على مستوى الطبقة)، يتحسّن الـ prefill (الإنتاجية حتى أول رمز) حتى 1.94 ضعفاً، والـ decode (الرموز المولّدة في الثانية) حتى 3.29 ضعفاً.

الإعداد هو نظام RTX 4090 (24GB) وRTX 3060 مع 64GB من الـ RAM، والنماذج المُتحقَّق منها هي:

• Llama 3.1-70B (INT4)
• Qwen3-Next-80B-A3B (INT4)
• Qwen3.5-122B-A10B (INT4)
• GPT-OSS-120B (MXFP4)

فالادّعاء المركزي هو تشغيل نموذج بـ 122 مليار معامل (وهو MoE بعدد معاملات نشطة أقل بكثير) على بطاقة 24GB واحدة. اقرأ هنا أمرين منفصلين. أولاً، “3.29 ضعفاً” هو حدّ أقصى تحت ظروف محددة، لا متوسط عبر كل نموذج وكل دفعة. ثانياً، الربح يأتي جوهرياً لا من “إدخال ما لم يكن يدخل في الـ GPU” بل من “جعل حركة CPU-GPU الحتمية أذكى”. تبقى الفيزياء نفسها في أن عرض نطاق الـ PCIe هو عنق الزجاجة، لذا فإن مساهمة ATSInfer هي استخدام ذلك العرض دون هدر وتقليل الوقت الخامل للـ GPU.

دلالات لمنتجات ThakiCloud

منصة ai-platform من ThakiCloud بنية تحتية للذكاء الاصطناعي/تعلّم الآلة تخدم النماذج عبر بيئات عملاء متنوعة على Kubernetes وKueue. الجدولة على مستوى الموتّر مثل ATSInfer تتوافق مع اتجاه نراقبه عن كثب.

أولاً، اقتصاديات البيئات المحلية (on-premises) والسيادية. في السياقات التي لا يمكن أن تغادر فيها البيانات المبنى، كعملاء القطاع العام والمالي المحليين، يجب أن تعمل النماذج على بطاقات GPU مملوكة. إذا استطاعت بضع بطاقات استهلاكية حمل نموذج متوسط إلى كبير بدلاً من رف من ثماني بطاقات H100، تنخفض النفقات الرأسمالية الأولية بشكل كبير. ما تُظهره تجارب ATSInfer هو أن الافتراض “إن نقص الـ VRAM فعليك ببساطة شراء المزيد من الـ GPU” يمكن تخفيفه جوهرياً عبر تحسين توزيع الموتّرات. الثمن، بالطبع، هو انخفاض الإنتاجية، لذا فهو غير مناسب لأحمال حرجة الكمون. الحكم على هذه المقايضة لكل حمل هو دور طبقة الخدمة لدينا.

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

ثالثاً، إعادة تعريف منحنى الكلفة-الجودة. في مقالة إعادة إنتاج ktransformers أظهرنا بالقياس المباشر أن أرقاماً بارزة مثل “28 ضعفاً” تقوم على افتراضات خفية. و”3.29 ضعفاً” في ATSInfer يستحق العدسة نفسها. ليس رقماً تسويقياً، بل القيمة التي تظهر على نماذج عملائنا الفعلية ودفعاتهم الفعلية واتفاقيات مستوى الخدمة الفعلية، هي ما نتحقق منه. التنافسية عند كلفة خدمة منخفضة تأتي في النهاية من تراكم هذا النوع من التحقق بالضبط.

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

أكبر حدّ هو عدم نشر الشيفرة. لا يمكن التحقق مما إذا كانت أرقام الورقة قابلة لإعادة الإنتاج، وما إذا كانت تصمد على أجهزة ونماذج أخرى، إلا بعد ظهور الشيفرة. امتداد بـ 15 ألف سطر من C++ هو أيضاً مهمة صيانة ودمج مع المنبع (upstream) غير هيّنة. الفرع (fork) الذي لا يُدمج أبداً يتخلّف عن تغييرات المنبع مع الوقت ويفقد قيمته.

ثانياً، اعتماد المكاسب على الظروف. يعتمد أثر التوزيع على مستوى الموتّر بشدة على أداء الـ CPU، وعرض نطاق الـ RAM، وجيل الـ PCIe. تفترض تجارب الورقة 64GB من الـ RAM؛ فإن نقص الـ RAM لا يترك مجالاً لإبقاء الموتّرات على الـ CPU أصلاً. على أنظمة PCIe 3.0، يرجّح أن يصبح النقل عنق الزجاجة ويقلّص الربح جوهرياً ([تقدير]، لا تفصّل الورقة مقارنةً جيلاً بجيل).

ثالثاً، السقف المتأصّل لتحسين الـ decode. الـ decode مهمة مقيّدة بالذاكرة (memory-bound). مهما أحسنت الجدولة، يجب الوصول إلى الأوزان خارج الـ VRAM بطريقة ما مع كل رمز، فيكون حتماً أبطأ من الإقامة الكاملة في الـ VRAM. ما يفعله ATSInfer هو “تقليل مقدار التباطؤ”، لا “إزالة التباطؤ”. وبناءً على الحجة المعاكسة: لخدمة إنتاجية تحتاج حقاً كموناً منخفضاً وإنتاجية عالية، يبقى استخدام بطاقة GPU تحمل النموذج كاملاً في الـ VRAM هو القرار الصائب. يتألق ATSInfer في مجال التطوير والتقييم والدفعات الصغيرة حيث لا تقدر على تلك البطاقة أو لا تحتاجها.

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

المصادر

• ورقة ATSInfer: arXiv:2607.10183, Automated Tensor Scheduling for Hybrid CPU-GPU LLM Inference on Consumer Devices
• مقالة ذات صلة: رفّ بـ 400 ألف دولار على 24GB؟ أعدنا إنتاج الـ 28 ضعفاً لـ ktransformers

Overview

Anyone who has run a local LLM hits the same wall: if the model weights are larger than GPU memory, the overflow spills to CPU memory. llama.cpp’s -ngl flag (how many layers to place on the GPU) does exactly this. The problem is that it cuts only at layer granularity. A single layer mixes tensors of very different character (attention weights, FFN weights, normalization params), yet they are handled all-or-nothing: either the whole thing goes to the GPU or it stays on the CPU.

Why this chunked placement loses is simple. The same 1GB in VRAM might make one tensor 10x faster and another only 2x faster. VRAM is a scarce resource, and chunked cuts prevent you from picking the tensors with the highest gain per GB. ATSInfer targets exactly this. It profiles each tensor’s CPU and GPU performance and fills VRAM starting from the tensors with the highest speed gain per GB. If the recent ktransformers was an “expert-level” trick that pushes MoE experts to the CPU (see our related post: reproducing the ktransformers 28x), ATSInfer is the finer, “tensor-level” generalization. Notably, it applies to dense models, not just MoE.

What is this technology

ATSInfer is a hybrid CPU-GPU inference system built as an extension to llama.cpp in roughly 15,000 lines of C++. As the name says, “Automated Tensor Scheduling” is the core, and three mechanisms interlock.

flowchart TB
    A["Model weights<br/>(RAM, exceed VRAM capacity)"] --> B["Per-tensor profiling<br/>measure speed gain per GB"]
    B --> C{"Static placement<br/>highest-gain tensors to VRAM first"}
    C -->|"high-gain tensors"| D["Resident in VRAM"]
    C -->|"low-gain tensors"| E["Resident in RAM"]
    D --> F["Load-aware dynamic transfer<br/>promote/demote by runtime load"]
    E --> F
    F --> G["Asynchronous CPU-GPU coordination<br/>overlap compute and PCIe transfer"]
    G --> H["Token output<br/>prefill · decode"]

First, static tensor placement. Before loading the model, it benchmarks how much each tensor speeds up on the GPU, then places tensors on the GPU in order of “most speed returned per GB of VRAM used.” This is close to a knapsack optimization and directly exploits the tensor-level heterogeneity that chunked placement ignored.

Second, load-aware dynamic transfer. Static placement alone is not enough. During real inference, load shifts moment to moment with batch size, context length, and concurrency. ATSInfer promotes a given tensor from RAM to GPU, or demotes it, based on the runtime situation. If static placement is the starting line, dynamic transfer is changing lanes while driving.

Third, asynchronous CPU-GPU coordination. It overlaps CPU compute, GPU compute, and the PCIe transfer that connects them. A naive implementation leaves the GPU idling while it waits on CPU work or data movement; this coordination layer fills that idle time. The paper reports this raises average GPU SM (streaming multiprocessor) utilization by about 70%.

Results the paper reports

Again: the numbers below are values reported by the paper, not something we reproduced. ATSInfer’s code is not yet public (even the tweet chatter said “researchers, please share the code with the llama.cpp team”), and a 120B-class model plus an RTX 4090 is hard to reproduce in the sandbox behind this post. So instead of reproduction, we focus on structural analysis and implications.

The paper’s headline: versus existing hybrid systems (including llama.cpp’s layer-level offloading), prefill (throughput to first token) improves by up to 1.94x, and decode (tokens generated per second) by up to 3.29x.

The setup is an RTX 4090 (24GB) and RTX 3060 system with 64GB RAM, and the validated models are:

• Llama 3.1-70B (INT4)
• Qwen3-Next-80B-A3B (INT4)
• Qwen3.5-122B-A10B (INT4)
• GPT-OSS-120B (MXFP4)

So the central claim is running a 122B-parameter model (an MoE with far fewer active parameters) on a single 24GB card. Read two things separately here. First, “3.29x” is a maximum under specific conditions, not an average across every model and batch. Second, the gain fundamentally comes not from “fitting what didn’t fit into the GPU” but from “making the unavoidable CPU-GPU traffic smarter.” The physics that PCIe bandwidth is the bottleneck stays the same, so ATSInfer’s contribution is using that bandwidth without waste and reducing GPU idle time.

Implications for ThakiCloud products

ThakiCloud’s ai-platform is an AI/ML infrastructure that serves models across diverse customer environments on Kubernetes and Kueue. Tensor-level scheduling like ATSInfer aligns with a trend we watch closely.

First, the economics of on-premises and sovereign environments. In settings where data cannot leave the premises, such as domestic public-sector and financial customers, models must run on owned GPUs. If a few consumer GPUs can carry a mid-to-large model instead of a rack of eight H100s, initial CAPEX drops dramatically. What ATSInfer’s experiments show is that the premise “if VRAM is short you must simply buy more GPUs” can be substantially relaxed through tensor placement optimization. The cost, of course, is reduced throughput, so it is unsuitable for latency-critical workloads. Judging that trade-off per workload is the job of our serving layer.

Second, coupling with multi-tenant scheduling. ATSInfer’s “load-aware dynamic transfer” is tensor movement within a single node, but the idea holds at cluster scale too. When Kueue queues and allocates GPU resources, a policy that decides which request to handle at which precision and offloading profile based on load is an area we already think about. Just as tensor-level profiling squeezes resource gains within a node, the cluster scheduler does the same across nodes.

Third, redefining the cost-quality curve. In our ktransformers reproduction post we showed by direct measurement that headline figures like “28x” rest on hidden premises. ATSInfer’s “3.29x” deserves the same lens. Not a marketing number, but the value that emerges on our customers’ actual models, actual batches, and actual SLAs, is what we verify. Competitiveness at low serving cost ultimately comes from accumulating exactly this kind of verification.

Limits and counterarguments

The biggest limit is the code being unreleased. Whether the paper’s numbers reproduce, and whether they hold on other hardware and models, can only be checked once code appears. A 15,000-line C++ extension is also a nontrivial maintenance and upstream-merge task. A fork that never merges falls behind upstream changes over time and loses value.

Second, the condition-dependence of the gains. The effect of tensor-level placement depends heavily on CPU performance, RAM bandwidth, and PCIe generation. The paper’s experiments assume 64GB RAM; if RAM is short, there is no room to keep tensors on the CPU at all. On PCIe 3.0 systems, transfer likely becomes the bottleneck and shrinks the gain substantially ([estimate], the paper does not spell out a generation-by-generation comparison).

Third, the inherent ceiling on decode optimization. Decode is a memory-bound task. However well you schedule, weights outside VRAM must be accessed somehow every token, so it is inevitably slower than pure VRAM residency. What ATSInfer does is “minimize how much slower,” not “eliminate the slowdown.” Building the opposing case: for production serving that truly needs low latency and high throughput, using a GPU that holds the whole model in VRAM is still the right call. ATSInfer shines in the development, evaluation, and small-batch regime where you cannot afford that GPU, or do not need it.

Even so, the direction has clear value. Squeezing resource utilization through software rather than adding hardware fits a platform like ours particularly well, one that treats on-prem, cost-efficiency, and self-hosting as its weapons. Once the code is public, we plan to fold it into our serving benchmarks and measure the real numbers ourselves.

Sources

• ATSInfer paper: arXiv:2607.10183, Automated Tensor Scheduling for Hybrid CPU-GPU LLM Inference on Consumer Devices
• Related post: A $400K rack on 24GB? We reproduced the ktransformers 28x

개요

로컬 LLM을 돌려 본 사람이라면 한 번쯤 마주치는 벽이 있습니다. 모델 가중치가 GPU 메모리보다 크면, 남는 부분은 CPU 메모리로 내려야 합니다. llama.cpp의 -ngl(GPU에 올릴 레이어 수) 플래그가 바로 그 일을 합니다. 문제는 이 방식이 레이어 단위로만 자른다는 점입니다. 한 레이어 안에는 어텐션 가중치, FFN 가중치, 정규화 파라미터처럼 성격이 전혀 다른 텐서들이 섞여 있는데, 이들을 통째로 “GPU에 올리거나 / CPU에 두거나” 둘 중 하나로만 처리합니다.

이 뭉텅이 배치가 왜 손해인지는 간단합니다. 같은 1GB를 VRAM에 올려도, 어떤 텐서는 GPU에서 10배 빨라지고 어떤 텐서는 2배밖에 안 빨라집니다. VRAM은 희소 자원인데, 뭉텅이로 자르면 “GB당 이득이 큰 텐서”를 골라 담을 수가 없습니다. ATSInfer는 이 지점을 정확히 겨냥합니다. 텐서마다 CPU와 GPU에서의 성능을 프로파일링해, VRAM 1GB당 속도 이득이 가장 큰 텐서부터 채워 넣습니다. 최근 화제였던 ktransformers가 MoE 모델의 전문가를 CPU로 내리는 “전문가 단위” 트릭이었다면(관련 글: ktransformers의 28배를 재현해봤습니다), ATSInfer는 그보다 한 단계 더 잘게 쪼갠 “텐서 단위” 일반화라고 볼 수 있습니다. MoE뿐 아니라 밀집(dense) 모델에도 적용된다는 점이 특히 다릅니다.

이 기술은 무엇인가

ATSInfer는 llama.cpp를 약 1만 5천 줄의 C++로 확장한 하이브리드 CPU-GPU 추론 시스템입니다. 이름 그대로 “자동 텐서 스케줄링(Automated Tensor Scheduling)”이 핵심이며, 세 가지 메커니즘이 맞물려 돌아갑니다.

flowchart TB
    A["모델 가중치<br/>(RAM, VRAM 용량 초과)"] --> B["텐서별 성능 프로파일링<br/>GB당 속도 이득 측정"]
    B --> C{"정적 배치 결정<br/>이득 큰 텐서부터 VRAM에"}
    C -->|"고이득 텐서"| D["VRAM 상주"]
    C -->|"저이득 텐서"| E["RAM 상주"]
    D --> F["로드 인식 동적 전송<br/>런타임 부하 따라 승격·강등"]
    E --> F
    F --> G["비동기 CPU-GPU 조율<br/>연산·PCIe 전송 오버랩"]
    G --> H["토큰 출력<br/>prefill · decode"]

첫째, 정적 텐서 배치(static placement)입니다. 모델을 올리기 전에, 벤치마크로 각 텐서가 GPU에서 얼마나 빨라지는지를 미리 측정합니다. 그리고 “VRAM 1GB를 썼을 때 가장 많은 속도를 돌려주는” 텐서 순으로 GPU에 배치합니다. 이는 배낭 문제(knapsack)에 가까운 최적화로, 뭉텅이 배치가 놓치던 텐서 간 이질성을 정면으로 활용합니다.

둘째, 로드 인식 동적 전송(load-aware dynamic transfer)입니다. 정적 배치만으로는 부족합니다. 실제 추론 중에는 배치 크기, 컨텍스트 길이, 동시 요청 수에 따라 부하가 시시각각 변합니다. ATSInfer는 런타임 상황을 보고 특정 텐서를 RAM에서 GPU로 승격하거나 반대로 강등합니다. 정적 배치가 “출발선”이라면, 동적 전송은 “주행 중 차선 변경”에 해당합니다.

셋째, 비동기 CPU-GPU 조율(asynchronous coordination)입니다. CPU 연산, GPU 연산, 그리고 둘을 잇는 PCIe 전송을 서로 겹쳐(overlap) 실행합니다. 순진하게 구현하면 GPU가 CPU의 계산이나 데이터 전송을 기다리며 노는 시간이 생기는데, 이 조율 계층이 그 유휴 시간을 메웁니다. 논문은 이 덕분에 GPU SM(스트리밍 멀티프로세서) 평균 활용도가 약 70% 올라갔다고 보고합니다.

논문이 보고한 실험 결과

다시 강조하지만, 아래 수치는 논문이 보고한 값이며 저희가 직접 재현한 것이 아닙니다. ATSInfer는 아직 코드가 공개되지 않았고(트윗에서도 “연구자들이 llama.cpp 팀에 코드를 공유해 주길”이라는 반응이 있었습니다), 120B급 모델과 RTX 4090은 이 글을 쓰는 샌드박스에서 재현하기 어렵습니다. 그래서 저희는 재현 대신 구조 분석과 함의 정리에 집중합니다.

논문의 헤드라인 수치는 다음과 같습니다. 기존 하이브리드 시스템(llama.cpp의 레이어 단위 오프로딩 포함) 대비, prefill(첫 토큰까지의 처리량)은 최대 1.94배, decode(초당 생성 토큰)는 최대 3.29배 빨라졌습니다.

실험 환경은 RTX 4090(24GB) 및 RTX 3060 시스템에 64GB RAM 구성이며, 검증에 사용한 모델은 다음과 같습니다.

• Llama 3.1-70B (INT4)
• Qwen3-Next-80B-A3B (INT4)
• Qwen3.5-122B-A10B (INT4)
• GPT-OSS-120B (MXFP4)

즉 24GB 한 장으로 122B 파라미터 모델(A10B, 활성 파라미터 기준으로는 더 작은 MoE)까지 구동했다는 것이 핵심 주장입니다. 여기서 두 가지를 분리해 읽어야 합니다. 첫째, “3.29배”는 특정 조건에서의 최댓값이지 모든 모델·모든 배치에서 나오는 평균이 아닙니다. 둘째, 이 이득은 근본적으로 “GPU에 안 들어가던 것을 넣어 돌린다”가 아니라 “어차피 CPU-GPU를 오갈 수밖에 없는 상황에서, 오가는 방식을 더 똑똑하게 만든다”에서 옵니다. 병목이 PCIe 대역폭이라는 물리 법칙은 그대로이므로, ATSInfer의 기여는 그 대역폭을 낭비 없이 쓰고 GPU 유휴 시간을 줄인 데 있습니다.

ThakiCloud 제품 적용 시사점

ThakiCloud의 ai-platform은 Kubernetes와 Kueue 기반으로 다양한 고객 환경에서 모델을 서빙하는 AI/ML 인프라입니다. ATSInfer 같은 텐서 단위 스케줄링은 저희가 특히 주목하는 흐름과 맞닿아 있습니다.

첫째, 온프레미스·소버린 환경의 경제성입니다. 국내 공공·금융 고객처럼 데이터를 외부로 내보낼 수 없는 환경에서는 자체 GPU로 모델을 돌려야 합니다. 이때 H100 8장짜리 랙 대신 소비자용 GPU 몇 장으로 중대형 모델을 감당할 수 있다면, 초기 CAPEX가 극적으로 낮아집니다. ATSInfer의 실험이 보여 주는 것은, “VRAM이 모자라면 무조건 GPU를 더 사야 한다”는 전제가 텐서 배치 최적화로 상당 부분 완화될 수 있다는 점입니다. 물론 그 대가는 처리량 감소이므로, 저지연이 필수인 워크로드에는 부적합합니다. 이 트레이드오프를 워크로드별로 판단하는 것이 저희 서빙 계층의 역할입니다.

둘째, 멀티테넌트 스케줄링과의 결합입니다. ATSInfer의 “로드 인식 동적 전송”은 단일 노드 안에서의 텐서 이동이지만, 그 발상은 클러스터 수준에서도 유효합니다. Kueue로 GPU 자원을 큐잉하고 할당할 때, 어떤 요청을 어떤 정밀도·어떤 오프로딩 프로파일로 처리할지를 부하에 따라 결정하는 정책은 저희가 이미 고민하는 영역입니다. 텐서 단위 프로파일링이 노드 안에서 자원 이득을 짜내듯, 클러스터 스케줄러는 노드 사이에서 같은 일을 합니다.

셋째, 비용-품질 곡선의 재정의입니다. 저희는 ktransformers 재현 글에서 “28배” 같은 화제 수치가 숨은 전제 위에 서 있음을 직접 측정으로 보였습니다. ATSInfer의 “3.29배”도 같은 렌즈로 봐야 합니다. 마케팅 수치가 아니라, 우리 고객의 실제 모델·실제 배치·실제 SLA에서 어떤 숫자가 나오는지를 검증하는 것이 저희가 제공하는 가치입니다. 낮은 서빙 비용에서의 경쟁력은 결국 이런 검증의 축적에서 나옵니다.

한계 및 반론

가장 큰 한계는 코드 미공개입니다. 논문의 수치가 재현 가능한지, 다른 하드웨어·다른 모델에서도 유지되는지는 코드가 나와야 검증할 수 있습니다. 15,000줄 규모의 C++ 확장이라면 유지보수와 llama.cpp 본류 병합도 만만치 않은 과제입니다. 병합되지 못한 포크는 시간이 지나면 상류 변경을 따라가지 못해 쓸모가 줄어듭니다.

둘째, 이득의 조건 의존성입니다. 텐서 단위 배치의 효과는 CPU 성능, RAM 대역폭, PCIe 세대에 크게 좌우됩니다. 논문의 실험은 64GB RAM을 전제하는데, RAM이 부족하면 텐서를 CPU에 둘 여유 자체가 없어집니다. PCIe 3.0 시스템에서는 전송이 병목이 되어 이득이 크게 줄어들 가능성이 높습니다([추정], 논문이 세대별 비교를 명시하지 않았습니다).

셋째, decode 최적화의 태생적 천장입니다. decode는 메모리 대역폭에 묶인(memory-bound) 작업입니다. 아무리 스케줄링을 잘해도 VRAM 밖에 있는 가중치는 매 토큰마다 어떤 식으로든 접근해야 하므로, 순수 VRAM 상주 대비 느릴 수밖에 없습니다. ATSInfer가 하는 일은 “느려지는 정도를 최소화”하는 것이지 “느려짐을 없애는” 것이 아닙니다. 반대편 논거를 세워 보면, 진짜 저지연·고처리량이 필요한 프로덕션 서빙이라면 여전히 모델 전체가 VRAM에 들어가는 GPU를 쓰는 편이 옳습니다. ATSInfer가 빛나는 지점은 “그 GPU를 살 여력이 없거나, 살 필요까지는 없는” 개발·평가·소규모 배치 구간입니다.

그럼에도 이 방향성은 분명한 가치가 있습니다. 하드웨어를 늘리지 않고 소프트웨어로 자원 활용을 짜내는 접근은, 온프렘·비용효율·self-hosting을 무기로 삼는 저희 같은 플랫폼에 특히 잘 맞습니다. 코드가 공개되면 저희 서빙 벤치마크에 편입해 실제 수치를 직접 측정할 계획입니다.

출처

• ATSInfer 논문: arXiv:2607.10183, Automated Tensor Scheduling for Hybrid CPU-GPU LLM Inference on Consumer Devices
• 관련 글: 40만 달러 랙을 24GB로? ktransformers의 28배를 직접 재현해봤습니다

문제의 출발점은 저자들이 직전에 내놓은 연구입니다. 1,600개가 넘는 스킬을 가진 프로덕션 하네스가 밤사이 스스로 라우팅과 검색 실패를 진단하고 리트리버 설정과 분해 규칙을 사람 검수 없이 재생성하는 구조였습니다. 문제는 배포 방식이었습니다. 재생성된 후보는 다음 날 아침 곧바로 전체 트래픽의 100퍼센트를 서빙했습니다. 오프라인 복구 루프 자체의 점검을 통과했더라도 실제 트래픽에서 더 나빠질 가능성은 남아 있었고, 그런 경우 사람이 알아챌 때까지 그날의 모든 요청이 회귀를 그대로 맞았습니다. 이 논문은 “생성된 후보”와 “전체 트래픽을 서빙하는 후보” 사이에 결정론적이고 트레이스로 촉발되는 롤백 게이트를 가진 점진적 트래픽 카나리를 끼우면, 이 무검증 전면배포 대비 장애 반경과 평균 복구시간(MTTR)이 얼마나 줄어드는지를 직접 잽니다.

첫 번째 기여는 게이트를 감으로 잡지 않았다는 점입니다. 슬라이딩 윈도우 회귀 탐지 게이트의 창 크기(W)와 오류 임계값(k)을 정확 이항분포 꼬리확률 탐색으로 골라, 기저 오류율 0.03에서 단일 윈도우의 오탐 확률이 2.12×10⁻⁶이 되도록 맞췄습니다. 저자들은 실험 과정도 숨기지 않았습니다. 초안에서는 창 크기 10에 임계 30퍼센트(오류 3개)라는 소박한 설정을 썼는데, 이 값이 기저 오류율에서도 오탐이 거의 확실하게 발생하는 수준이었다는 사실을 이항분포 캘리브레이션 과정에서 발견하고 최종 실험 전에 바로잡았다고 밝힙니다. 결과에서 발견한 게 아니라 결과를 내기 전에 계산으로 잡아낸 실수라는 점이 이 공개의 핵심입니다.

실험은 완전히 오프라인이고 시드가 고정된 재현 가능한 시뮬레이션입니다. 2만 틱짜리 스킬 호출 결과 스트림을 만들고 2천 틱째에 오류율이 계단식으로 튀는 회귀를 주입했습니다. 전면배포(카나리 가중치 1.0, v2가 매 틱마다 트래픽을 받음)와 카나리(가중치 0.1, 열 틱 중 한 번만 v2가 트래픽을 받음) 두 정책을 동일한 게이트 아래에서 비교했고, 회귀 심각도 세 단계(오류율 0.15, 0.35, 0.6, 기저값 0.03 대비)에 시드 60개씩을 곱해 총 360회를 돌렸습니다. 결과는 명확했습니다. 360회 전부에서 오탐은 0건, 탐지율은 100퍼센트였습니다.

카나리는 장애 반경(blast fraction)을 1.0에서 0.1로, 즉 90퍼센트 줄였습니다. 하지만 저자들은 이 숫자를 헤드라인으로 내세우지 않습니다. 카나리 가중치를 0.1로 정하고 탐지가 항상 성공한다면 장애 비율이 대략 0.1에 수렴하는 것은 설계상 거의 당연한 결과이기 때문입니다. 세 심각도 모두에서 장애 반경 감소율이 정확히 90.0퍼센트로 똑같이 나온 것 자체가, 이 숫자가 측정치가 아니라 라우팅 가중치의 구조적 산물이라는 증거라고 논문은 스스로 지적합니다.

카나리(가중치 0.1)는 전면배포(가중치 1.0) 대비 세 심각도 모두에서 장애 반경을 0.1로 낮춘다. 다만 논문은 이 90퍼센트 감소를 실증적 발견이 아니라 카나리 가중치 설계에 따른 구조적 결과로 명시한다. 시뮬레이션 데이터를 시각화한 분석용 그림이다.

측정치로서 의미가 더 큰 것은 v2에 실제로 노출된 절대 호출 건수입니다. 전면배포에서는 회귀가 발생한 뒤 평균 2,012에서 2,160건의 요청이 버그 있는 버전을 그대로 맞았습니다. 카나리에서는 그 수가 212에서 378건으로 줄었습니다. 심각도별로 82.5퍼센트(오류율 0.15)에서 89.5퍼센트(오류율 0.6)까지 감소했는데, 감소폭이 가장 작은 쪽이 오히려 완만한 회귀라는 점이 눈에 띕니다. 카나리는 완만한 회귀를 탐지하는 데 시간이 더 걸리고, 그만큼 v2 노출이 더 쌓이기 때문입니다.

전면배포는 약 2,000건의 호출을 버그 버전에 그대로 노출시키지만 카나리는 212에서 378건으로 줄인다. 감소폭이 가장 작은 쪽은 완만한 회귀로, 탐지 시간이 길어질수록 노출이 함께 늘어난다는 것을 보여준다. 저장소 자체의 로컬 벤치(2026년 7월 19일 측정)에서 나온 결과다.

이 논문이 실제로 “발견”이라 부를 만한 대목은 따로 있습니다. 카나리는 모든 심각도에서 전면배포보다 롤백까지 더 오래 걸렸지만, 그 격차는 회귀가 심할수록 급격히 좁혀졌습니다. 완만한 회귀(오류율 0.15)에서는 전면배포가 30,864.6밀리초 만에 롤백한 반면 카나리는 53,841.7밀리초가 걸려 약 74.5퍼센트 더 느렸습니다. 중간 심각도(오류율 0.35)에서는 그 격차가 8.86퍼센트로, 심한 회귀(오류율 0.6)에서는 4.82퍼센트로 줄었습니다. 원인은 게이트의 작동 방식에 있습니다. 게이트는 최소 30개의 v2 호출 결과를 모으고 그중 8개 이상이 오류여야 발동합니다. 전면배포는 매 틱이 v2 호출이라 이 30개를 거의 즉시 채우지만, 카나리는 열 틱 중 한 틱만 v2로 가기 때문에 같은 30개를 채우려면 전체 시스템 틱이 약 열 배 더 필요합니다. 완만한 회귀는 애초에 창을 여러 번 검사해야 임계값을 넘기 때문에 여기에 카나리의 트래픽 희석이 곱해져 지연이 크게 벌어집니다. 반대로 심한 회귀는 회귀가 시작된 직후 첫 창 검사에서 바로 임계값을 넘기 때문에, 두 정책의 차이는 그 첫 창 하나를 채우는 시간 차이로 줄어듭니다.

카나리의 MTTR 페널티는 완만한 회귀에서 약 74.5퍼센트에 달하지만 심한 회귀에서는 9퍼센트 아래로 줄어든다. 이 심각도별 격차가 논문이 실제로 새롭게 측정한 결과다. MTTR 수치는 이 저장소 자체의 관측성 스팬 로그에서 뽑은 실측 지연시간 6개(12.705, 35.029, 25.011, 6.271, 6.458, 0.004밀리초)를 시드 샘플링해 합산한 값이다.

한 가지 더 눈여겨볼 지점은 이 MTTR 수치가 상상으로 만든 숫자가 아니라는 것입니다. 저장소 안 관측성 파이프라인(scripts/harness/span.py의 스모크 테스트)이 실제로 남긴 스팬 로그 6개를 지연시간 풀로 삼아 시드 고정 샘플링했습니다. 표본이 여섯 개뿐이라는 한계는 저자들도 곧바로 인정합니다.

이 연구가 갖는 실용적 의미는 세 층위로 나뉩니다. ThakiCloud AI 플랫폼 입장에서는 밤샘 자율 스킬 진화와 회고 기반 모델 승격이 실제 스케줄 러너에 반영될 때, 카나리와 자동 롤백 게이트를 끼워 무검증 전면배포의 장애 반경을 줄이면 24시간 무인 운영의 안전 마진을 확보할 수 있다는 실용적 근거가 됩니다. 조금 더 넓게 보면, 에이전트가 스스로 코드나 스킬을 고치는 자기수정 AI가 늘어나는 흐름에서 결정론적 트레이스 기반 회귀 게이트와 자동 롤백을 묶는 이 패턴은 자율 시스템 안전성을 위한 재사용 가능한 표준 컴포넌트로 자리잡을 여지가 있습니다. 학술적으로는, 기존 카나리 배포 연구가 대체로 마이크로서비스나 웹 트래픽을 배포 단위로 다뤄온 데 비해 이 논문은 배포 단위를 “자율 에이전트가 생성하고 수정한 스킬”로 확장했습니다. LLM 산출물이 갖는 비결정론적 품질을, 모델의 자기보고가 아니라 스팬 트레이스 위의 결정론적이고 코드가 소유하는 게이트로 다룬다는 방법론이 자기진화 에이전트 하네스 문헌에 새 축을 더한다는 것입니다. 관련 연구에서 논문은 MOSS의 이진 헬스프로브와 전체 트래픽 스왑 방식을, 자신의 점진적 트래픽 카나리와 통계적 회귀 게이트 방식과 정확히 한 축에서 구분해 자리매김합니다.

논문은 스스로의 한계도 길게, 그리고 솔직하게 적어 둡니다. 가장 무거운 한계는 실험 전체가 완전히 합성된 결과 스트림이라는 점입니다. 실제 스킬이 실제 트래픽 분할에 배포된 적은 없고, 실제 롤백도 실행되지 않았습니다. 지연시간 풀이 단 6개의 실측 스팬으로 이루어져 실제 프로덕션 지연시간 분포나 꼬리 행동을 대표하지 못한다는 점, 90퍼센트 장애 반경 감소가 발견이 아니라 카나리 가중치 0.1과 완벽한 탐지율이 만든 구조적 결과라는 점도 반복해서 짚습니다. 게이트 설정(창 크기 30, 임계 8) 역시 단 하나만 시험했기 때문에 MTTR과 장애 반경 사이의 파레토 프론티어는 아직 그려지지 않았습니다. 회귀 모델도 계단형으로 상승하는 베르누이 오류율 하나뿐이라, 점진적 드리프트나 지연시간만 나빠지는 경우, 비용 폭증, 의미적 품질 저하 같은 다른 실패 양상에는 이 결과가 그대로 옮겨지지 않을 수 있습니다. 무엇보다 이 논문은 카나리와 롤백 메커니즘을 제안하고 시뮬레이션으로 검증했을 뿐, 실제 프로덕션 복구 루프나 하네스의 라이브 관측 코드에 직접 구현하지는 않았습니다.

더 자세한 내용과 전체 데이터는 Hugging Face 논문 페이지에서 확인할 수 있습니다.

https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-20-canary-gated-skill-rollout

ما الذي أثار الجدل

فكرة ktransformers (kvcache-ai/ktransformers، رخصة Apache 2.0، 17 ألف نجمة)، التي أصدرها مختبر MADSYS في جامعة تسينغهوا، يمكن تلخيصها في جملة واحدة. في نموذج MoE، أبقِ فقط الخبراء الذين يتم استدعاؤهم فعلياً بالقرب من GPU، وضع الخبراء الخاملين معظم الوقت في ذاكرة CPU، مع استدعائهم فقط عند الحاجة. بهذا الترتيب، يُقال إن DeepSeek-V3 وR1 يعملان على 24 جيجابايت من VRAM بسياق يبلغ 139 ألف رمز، وبسرعة تصل إلى 28 ضعفاً مقارنة بالإعداد القياسي.

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

تصميم التجربة: عزل الآلية باستخدام نموذج أصغر

DeepSeek-V3 يبلغ حجمه 671 مليار معامل، أي أنه لن يتسع على بطاقة بسعة 24 جيجابايت. استخدمنا Qwen3-30B-A3B (بإجمالي 30 مليار معامل، منها 3.3 مليار نشطة) كنموذج بديل، وهو نسخة مصغّرة من نفس العائلة (MLA مع MoE دقيق التحبيب). لم يكن الهدف إعادة إنتاج أرقام المُورّد الخاصة بنموذج 671 مليار معامل، بل معرفة ما إذا كانت آلية “نقل الخبراء إلى CPU” تحقق فائدة فعلية، وإذا كانت كذلك، تفكيك مصدر هذه الفائدة.

قسّمنا القياس إلى مرحلتين. أولاً، اختبرنا الآلية نفسها على جهاز AMD جاهز تجارياً. ثانياً، قسنا بشكل منفصل نواة Intel AMX التي تدّعي ktransformers أنها مصدر الأداء.

المرحلة الأولى: قياس الآلية على بطاقة 4090 تجارية مع AMD

استأجرنا RTX 4090 (بسعة 24 جيجابايت) مع معالج AMD Ryzen 9 7950X و188 جيجابايت من الذاكرة العشوائية على RunPod. هنا ظهر الافتراض الخفي الأول على الفور. نواة الخبراء الخاصة بـ CPU في ktransformers مُحسّنة لتعليمات Intel AMX، وهذا المعالج من AMD لا يملك AMX. لذلك، بدلاً من نواة ktransformers الخاصة، قسنا الآلية بشكل نظيف باستخدام خاصية --n-cpu-moe في llama.cpp (الخبراء على CPU، والانتباه (attention) وذاكرة KV المؤقتة على GPU)، التي تنفّذ نفس الحيلة تماماً.

قمنا بضغط (quantize) Qwen3-30B-A3B إلى Q4 وقارنّا سرعة فك الترميز (decode) عبر ثلاثة أوضاع.

يظهر هنا أمران. الآلية أسرع بـ 1.62 ضعفاً من CPU الخالص. نقل الانتباه إلى GPU حقق فائدة فعلية. لكن عندما يتسع النموذج بالكامل في VRAM (نسخة Q4 حجمها 18 جيجابايت، وهي تتسع في 24 جيجابايت)، تفوّق full-GPU على الآلية بـ 22 ضعفاً. بمعنى آخر، إذا كان النموذج يتسع على GPU، فإن نقل الخبراء إلى CPU خيار خاسر. هذه الحيلة لا تكتسب معناها إلا في اللحظة التي يتجاوز فيها النموذج سعة VRAM. في تلك الحالة، القيمة تكمن في “أنه يعمل أصلاً، ولو بسرعة 12 tok/s”، وليس في السرعة بحد ذاتها.

المرحلة الثانية: قياس المضاعف الحقيقي لنواة Intel AMX

لمواجهة نواة AMX مباشرة، وهي المصدر المزعوم للـ 28 ضعفاً، احتجنا إلى معالج Xeon من جيل Sapphire Rapids. بعد تشغيل عدة نسخ من H100 pods على RunPod والتحقق من معالجاتها، حصلنا على مضيف يحتوي على Intel Xeon Platinum 8470 (يدعم AMX bf16/int8/tile)، و208 نواة معالجة افتراضية، و1 تيرابايت من الذاكرة العشوائية.

حزمة kt_kernel تضم أنوية لكل خلفية (backend)، لذا استطعنا داخل نفس العملية تشغيل نواة AMX ونواة AVX2 جنباً إلى جنب على نفس أوزان BF16. قسنا عمليات التمرير الأمامي (forward pass) لـ MoE بحجم يعادل DeepSeek-V3 (256 خبيراً، وبُعد مخفي 7168) باستخدام كلا النواتين.

كانت نواة AMX أسرع من AVX2 بـ 1.38 ضعفاً. فائدة واضحة، لكنها بعيدة كل البعد عن 28 ضعفاً. استخدام عمليات التبليط (tile) الخاصة بـ INT8 وحدها قد يوسّع هذه الفجوة أكثر (اقتصرنا في هذه الجولة على مقارنة BF16 بنفس مستوى الدقة بسبب التكلفة)، لكن نواة واحدة بمفردها لا تنتج مضاعفاً بـ 28 ضعفاً.

عند تفكيك “28 ضعفاً”

عند دمج التجربتين معاً، يتضح كيف تتكوّن الـ 28 ضعفاً التي أعلن عنها المُورّد. هذا الرقم ليس سحر نواة واحدة، بل هو مقارنة للنظام بأكمله مع تنفيذ llama.cpp الخالص على CPU. عند التفكيك، يبدو الأمر كالتالي.

نقل الانتباه وذاكرة KV المؤقتة إلى GPU هو الرافعة الأكبر بلا منازع. على جهاز AMD التجاري، حقق هذا الترتيب وحده مكسباً بـ 1.62 ضعفاً مقارنة بـ CPU الخالص، وعندما يتسع النموذج على GPU، تتسع هذه الفجوة إلى 35 ضعفاً. فوق ذلك، تضيف نواة الخبراء AMX نحو 1.4 ضعف إضافي مقارنة بـ AVX2. يُضاف إلى ذلك ضغط INT8/INT4 وتحسينات خط الأنابيب (pipeline). كل عامل على حدة مضاعف متواضع، لكن في ظروف معينة تتضاعف هذه العوامل معاً لتُنتج مكسباً من رتبتين عدديتين. تلك الظروف هي: أن يتجاوز النموذج سعة VRAM، وأن يدعم المعالج AMX، وأن يكون معيار المقارنة هو llama.cpp الخالص على CPU.

حقيقة “400 ألف دولار إلى 24 جيجابايت”

هذه العبارة لا تُلغي الذاكرة، بل تنقلها. كانت وحدتا الحوسبة لدينا تملكان 188 جيجابايت و1 تيرابايت من ذاكرة النظام على التوالي. تشغيل DeepSeek-V3 بضغط Q4 يتطلب نحو 380 جيجابايت من DRAM على جانب CPU. أوزان الخبراء لا تختفي، بل تنتقل فقط من VRAM إلى ذاكرة النظام. لذا فإن الوصف الدقيق هو “بطاقة GPU واحدة بسعة 24 جيجابايت زائد خادم بذاكرة عشوائية ضخمة”. تم استبدال بطاقة GPU باهظة الثمن بذاكرة عشوائية رخيصة، وليس تقليل إجمالي الاحتياج من الذاكرة. هذا يختلف عن الصورة القائلة إن بطاقة استهلاكية واحدة بسعة 24 جيجابايت تحل محل خزانة كاملة في مركز بيانات.

إذن، كم tok/s فعلياً، وبأي تكلفة

فكّكت التجارب السابقة الآلية، لكنها أغفلت الرقمين اللذين يهمّان الممارسين فعلياً: ما مدى سرعة نموذج كبير حقيقي، وكم من المال يوفّر ذلك فعلاً. لذا أعدنا القياس في الإعداد الذي تكون فيه ktransformers ذات معنى فعلاً: معالج خادم متعدد الأنوية (Intel Xeon Platinum 8570، يدعم AMX، 224 نواة)، و2 تيرابايت من ذاكرة النظام، وقرص NVMe محلي، وبطاقة GPU واحدة. النموذج هو Qwen3-235B-A22B (بضغط Q4، بحجم يقارب 130 جيجابايت)، وهو لا يتسع لا على بطاقة 24 جيجابايت ولا على بطاقة واحدة بسعة 80 جيجابايت. هذه حالة يكون فيها النقل (offload) ضرورة لا خياراً.

أولاً، يتم التحقق من صحة الادعاء المتعلق بالعتاد. عند نقل جميع الخبراء إلى CPU، لا تتجاوز ذاكرة GPU المستخدَمة 11 جيجابايت. أي أن نموذجاً من فئة 235 مليار معامل يستهلك فقط 11 جيجابايت من ذاكرة GPU. هذا يتسع ليس فقط على 24 جيجابايت، بل على بطاقة بسعة 12 جيجابايت أيضاً. صورة “تشغيل نموذج من فئة 671 مليار معامل على خادم كبير مع بطاقة 4090 واحدة” تتحقق فعلياً.

المشكلة تكمن في السرعة. عند تحميل نفس النموذج بالكامل على 2×A100 بسعة 80 جيجابايت، يبلغ فك الترميز 51.5 tok/s، وهذا كافٍ بشكل مريح لمحادثة فورية. لكن حالة النقل، حيث الخبراء على CPU، عالم مختلف تماماً. قسنا ذلك بطريقتين مستقلتين، وكانت النتيجتان من رتبة عددية واحدة (خانة آحاد). تشغيل llama.cpp من البداية للنهاية يعطي 1.2 tok/s. وقياس حساب الخبراء فقط باستخدام نواة AMX الفعلية الخاصة بـ ktransformers (kt_kernel) يعطي 3.8 tok/s بمعيار BF16. حتى مع وضع بعض الخبراء على بطاقة GPU بسعة 24 جيجابايت، ترتفع النتيجة قليلاً فقط من 1.2 إلى 1.5.

لماذا لا يمكن لتغيير النواة كسر حاجز الخانة الآحادية. لأن العنق الحقيقي للزجاجة هو حساب 22 مليار معامل نشط على CPU في كل رمز. صحيح أن نواة AMX أسرع من AVX2 بنحو 1.3 ضعف، لكن هذا المضاعف لا يكفي لتجاوز الجدار. أرقام 8 إلى 15 tok/s التي أعلنتها ktransformers علناً (استناداً إلى DeepSeek-V3 الأكبر) تجمع ضغط INT4 وتوزيع الخبراء على GPU وخط الأنابيب معاً، وحتى هذا الرقم هو رقم إنتاجية دفعية (batch)، وليس سرعة خدمة تفاعلية.

هذا الرقم يقلب الاستنتاج. عند حساب التكلفة لكل مليون رمز باستخدام أسعار الإيجار الفعلية في RunPod، تكون النتيجة كالتالي.

على أساس الإيجار، يكلف النقل (offload) أكثر بـ 5 إلى 17 ضعفاً لكل رمز. إنها ليست، بأي معنى، أداة لخفض تكاليف تشغيل السحابة. وفوق ذلك، خادم AMX الكبير نفسه ليس رخيصاً. RunPod لا يوفر أصلاً تركيبة “بطاقة 4090 رخيصة مع خادم AMX كبير”، لذا يأتي AMX دائماً مرتبطاً ببطاقات GPU الخاصة بمراكز البيانات.

إذن، المكان الوحيد الذي تنجح فيه الاقتصاديات هو داخل المنشأة، على خادم تملكه بالفعل. إذا كان لديك بالفعل خادم Xeon كبير قيد التشغيل، فإن إضافة بطاقة 4090 بقيمة 1,600 دولار فوق تلك التكلفة الغارقة لتشغيل نموذج من فئة 671 مليار معامل بشكل دفعي، أرخص بكثير من شراء بطاقتي A100 جديدتين بقيمة 30 ألف دولار. إنها ليست أداة لخفض تكاليف التشغيل، بل أداة تُغيّر، على العتاد الذي تملكه أصلاً، الحد الفاصل بين “يعمل” و”لا يعمل”. واستخدامها ليس في الخدمة الفورية، بل في الأعمال الدفعية وغير المتصلة والوكلاء (agents) التي لا تحساس فيها للتأخير.

إذن، هل يجب اعتمادها

ابدأ بالتحقق مما إذا كانت هذه الشروط الثلاثة متوفرة جميعها. هل تملك بالفعل (أو يمكنك الحصول عليه بتكلفة زهيدة) خادم AMX كبير بذاكرة عشوائية ضخمة. هل النموذج الذي تريد تشغيله هو نموذج MoE كبير (من فئة V3، R1) يتجاوز فعلياً سعة VRAM لبطاقة GPU. وهل هذا العمل يتحمّل التأخير، أي أنه دفعي أو غير متصل أو من نوع الوكلاء، وليس استجابة فورية. إذا تحققت الشروط الثلاثة جميعها، تصبح ktransformers المسار الواقعي الوحيد لتشغيل ذلك النموذج دون شراء إعداد باهظ بعدة بطاقات GPU. أما إذا اختلّ شرط واحد، يتغيّر الجواب. إذا كنت بحاجة إلى محادثة فورية، فإن سرعة النقل من رتبة عددية واحدة (خانة آحاد) بالـ tok/s غير كافية، وإذا كان النموذج يتسع على GPU، فإن تحميله بالكامل مباشرة على GPU أسرع، دون أدنى شك، بعشرات الأضعاف.

فيما يلي هذا القرار موضّحاً في مسار واحد.

flowchart TD
    A["Large MoE model<br/>overflows GPU VRAM?"] -->|No| B["Load fully on GPU<br/>tens of times faster"]
    A -->|Yes| C["Own an AMX server<br/>with large RAM?"]
    C -->|No| D["Rent economics lose<br/>5 to 17x pricier per token"]
    C -->|Yes| E["Workload batch or offline<br/>latency tolerant?"]
    E -->|No, real-time| F["Single-digit tok/s<br/>too slow for chat"]
    E -->|Yes| G["ktransformers fits<br/>the only realistic path"]

من وجهة نظرنا، القيمة الحقيقية لـ ktransformers ليست “28 ضعفاً” ولا “خدمة رخيصة”. إنها مسألة واحدة تتعلق بإمكانية الوصول: فريق لا يستطيع شراء أو استئجار بطاقات GPU متعددة أصبح بإمكانه الآن تشغيل نموذج MoE من فئة 671 مليار معامل أصلاً، باستخدام خادم كبير يملكه بالفعل مع بطاقة GPU واحدة. يجب النظر إليها ليس كبطلة سرعة ولا كأداة لخفض التكاليف، بل كأداة دفعية تخفض حاجز الدخول.

معلومات إعادة الإنتاج

أُجريت جميع التجارب الثلاث على RunPod، وبلغت التكلفة الإجمالية لاستخدام GPU نحو 15 دولاراً. تم نشر إطار عمل القياس بالكامل (llama.cpp --n-cpu-moe، ومقارنة نواتي AMX/AVX2 في kt_kernel، والقياس الشامل لنموذج 235 مليار معامل) بالإضافة إلى نتائج JSON الخام. إذا أردت إعادة الإنتاج بنفسك أو التحقق من الأرقام، يمكنك زيارة github.com/sylvanus4/ktransformers-moe-offload-bench (رخصة Apache-2.0). المرشح المتبقي للتحقق هو بناء حزمة الخدمة الرسمية الكاملة لـ ktransformers مع تفعيل ضغط INT4 وتوزيع الخبراء على GPU وخط الأنابيب معاً، لقياس المدى الحقيقي الذي يمكن أن تصل إليه إنتاجية الدفعات (batch throughput).

لماذا نحتاج إلى منظور ميزانية زمن الاستجابة

تشير الأبحاث إلى أنه عندما يتحدث شخصان، تتقارب الفجوة الزمنية بين انتهاء أحدهما من الكلام واستجابة الآخر إلى وسيط يبلغ نحو 200 ميلي ثانية بغض النظر عن اللغة (Stivers et al., 2009, PNAS). لكي يشعر وكيل الصوت الفوري بأنه “بشري”، يجب أن يكون الزمن من انتهاء الكلام إلى صوت الاستجابة الأول قريباً من هذا النطاق، وفي الممارسة العملية، يُعد البقاء دون الثانية الواحدة، أي أقل من 800 ميلي ثانية، هدفاً شائعاً. يتطابق هذا الرقم إلى حد كبير مع الأهداف التي ينشرها مزودو الخدمة أيضاً. تذكر Deepgram أقل من 300 ميلي ثانية، وتذكر Vapi أقل من 500 ميلي ثانية.

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

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

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

flowchart LR
    A["End of utterance<br/>detection"] --> B["Network<br/>round-trip"]
    B --> C["STT<br/>Qwen3-ASR ~133ms"]
    C --> D["LLM<br/>first token"]
    D --> E["First sentence<br/>ready"]
    E --> F["TTS synthesis<br/>the bottleneck"]
    F --> G["Playback<br/>buffer"]
    G --> H["First audio out<br/>target under 800ms"]

كيف تتغيّر الأرقام عند الاستضافة الذاتية

يمكنك الحصول على فكرة تقريبية عن نطاق زمن استجابة واجهة برمجة تطبيقات متدفقة مُدارة من الوثائق. لكن “ما الرقم الذي نحصل عليه فعلياً حين نضع المحرك الذي نستخدمه حقاً على GPU” أمر لا يمكن معرفته دون قياسه مباشرة. لذلك أخذنا المكدس ذاته الذي كنا نشغّله محلياً على جهاز MacBook لأغراض التطوير، ووضعناه على وحدة RunPod H200 (بسعة 141 جيجابايت) لقياسه. كانت المحركات هي Qwen3-ASR-1.7B للتعرف على الكلام، وVoxCPM2 وQwen3-TTS-1.7B لتحويل النص إلى كلام، وأحدث نموذج Qwen3.5-9B لنموذج اللغة الكبير.

أولاً، ملاحظة حول كيفية خفض التكاليف. إذا أعدت تنزيل عشرات الجيجابايتات من النماذج وحزم CUDA في كل مرة تُنشئ فيها وحدة GPU، تبقى وحدة GPU المكلفة خاملة في انتظار التنزيل بينما تُحاسب على وقتها. لذلك قمنا بتنزيل البيئة الافتراضية والأوزان مرة واحدة فقط على حجم شبكي واحد (67 جيجابايت)، ثم جعلنا وحدة GPU تُركّب ذلك الحجم وتُجري القياس دون إعادة التنزيل. وضمِنّا حذف الوحدة والحجم بالكامل بعد الانتهاء باستخدام كتلة finally إضافة إلى شبكة أمان قائمة على الاسم لآلية التفكيك. بلغت التكلفة الإجمالية بما في ذلك تصحيح الأخطاء نحو 17 دولاراً، ولم تتسرب أي موارد.

نتائج القياس: لم تكن نقطة الاختناق في نموذج اللغة الكبير ولا في التعرف على الكلام، بل في تحويل النص إلى كلام

هذه هي الأرقام التي قسناها على H200، على أساس طلب واحد.

لم يكن التعرف على الكلام مرحلة تستحق القلق. يقوم Qwen3-ASR بنسخ 10 ثوانٍ من الصوت في 133 ميلي ثانية. معامل زمن حقيقي قدره 0.013 يعني فعلياً استجابة فورية. القصة الحقيقية كانت في تحويل النص إلى كلام. على وحدة H200 نفسها، قام VoxCPM2 بتوليف الجملة الكورية نفسها في 0.67 ثانية، بينما استغرق Qwen3-TTS 6.8 ثانية. على البطاقة نفسها، يكون VoxCPM2 أسرع بنحو عشرة أضعاف. والمهم أن كلا المحركين غير متدفقين. ولأن الجملة كاملة يجب أن تُوَلَّف قبل صدور الصوت الأول، فإن حتى 0.67 ثانية عند VoxCPM2 ليست “زمن وصول أول صوت متدفق قدره 100 ميلي ثانية” بل هي “الصوت الأول بعد 0.67 ثانية”. صحيح أن VoxCPM2 انخفض من نطاق الثواني المتعددة على MPS المحلي إلى 0.67 ثانية على GPU، لكن ذلك لا يعني أنه أصبح متدفقاً. لبناء دورة محادثة فورية حقيقية، عليك التحول إلى أداة تحويل نص إلى كلام متدفقة أو توليف الجمل على شكل مقاطع قصيرة. كان إظهار هذه النقطة تحديداً كرقم هو السبب الذي دفعنا لبناء هذه الأداة أصلاً.

فجوة صريحة: تعطّل نموذج اللغة الكبير على هذا المضيف

لم نتمكن من الحصول على أرقام تشغيل vLLM لنموذج Qwen3.5-9B هذه المرة. لم يكن السبب أداء المحرك، بل عدم تطابق في إصدارات البنية التحتية. اعتباراً من يوليو 2026، يجلب أحدث إصدار من vLLM إصدار torch مبنياً لـ CUDA 13، بينما كان تعريف الوحدة على مضيف H200 المخصص لنا هو CUDA 12.8، فرفض المحرك العمل بحجة أن التعريف قديم جداً. وحين خفّضنا torch إلى إصدار متوافق مع 12.8، تعطّلت عمليات vLLM المُجمَّعة مسبقاً، وحين استخدمنا transformers كبديل، ظهرت أخطاء في مسار التوليد متعدد الوسائط. يتطلب كل محرك إصدار torch مختلفاً، وإصلاح واحد يُعطّل آخر، وهو تعارض تبعيات كلاسيكي. للحصول على أرقام vLLM نظيفة، تحتاج إلى مضيف مزوّد بتعريف CUDA 13. أدخلنا قيمة تقديرية في شريط تمرير نموذج اللغة الكبير في الحاسبة وأوضحنا صراحة أنها تقديرية. الوقوع في تعريف قديم أثناء محاولة تشغيل أحدث نموذج على أحدث مكدس هو أيضاً فخ واقعي في الاستضافة الذاتية، لذا نكتبه بصراحة بدلاً من إخفائه.

كيف تُعِدّ هذا للتشغيل الفعلي

عند تحويل القياسات إلى وصفة عملية، تصبح كالتالي. التعرف على الكلام جيد كما هو باستخدام Qwen3-ASR. أما تحويل النص إلى كلام، فاختر VoxCPM2، الأسرع بعشرة أضعاف بين المحركين، لكن قرّب صدور الصوت الأول عبر التدفق أو تقسيم النص إلى مقاطع جملية. لا يمكن استخدام زمن Qwen3-TTS غير المتدفق البالغ 6.8 ثانية كما هو في دورة محادثة فورية. شغّل نموذج اللغة الكبير عبر vLLM على مضيف بتعريف CUDA 13. ضع المحركات الثلاثة على العقدة نفسها لإزالة القفزات الشبكية، واستخدم تدفقاً على مستوى الجملة يُشغّل تحويل النص إلى كلام فور جاهزية الجملة الأولى. مكدسنا المحلي على MacBook مخصص للتطوير، وليس نظام تشغيل فعلياً، وقد وسمنا صراحة الإعداد المسبق المحلي في الحاسبة بأنه “غير مناسب للتشغيل الفوري”.

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

• الحاسبة: voice-latency-budget
• المستودع وأداة القياس ودليل التشغيل: github.com/sylvanus4/voice-latency-budget

سبب عدم استطاعة شركة بنية تحتية مثل ThakiCloud أن تنظر إلى هذا الخبر باعتباره شأناً بعيداً عنها واضح. فكلما ارتفعت القدرات الهجومية للنماذج المتقدمة، ينتقل مركز ثقل الدفاع من سؤال “أي نموذج أذكى” إلى سؤال “أين يُشغَّل هذا النموذج، وتحت سيطرة من، وبأي سجلات تدقيق”. النماذج ستستمر في التقوي على أي حال. وبالتالي فإن نقطة الحسم تصبح عزل بيئة التنفيذ، وبوابات السياسات، وإمكانية التتبع بعد وقوع الحادث. سنتناول اليوم أولاً ما أنجزه GPT-5.6 Sol فعلياً استناداً إلى حقائق مؤكدة، ثم ننتقل لشرح لماذا تُضاعف هذه القدرة من الحاجة إلى الذكاء الاصطناعي السيادي المحلي وطبقة تحكم الوكلاء.

ما هو GPT-5.6 Sol ولماذا يُركَّز على الأمن السيبراني

GPT-5.6 هو عائلة نماذج كشفت عنها OpenAI في 9 يوليو 2026. تضم ثلاث فئات مرتبة حسب القدرة: لونا (Luna)، تيرا (Terra)، وسول (Sol)، حيث يُعد Sol النموذج الرائد الأقوى. وأوضحت OpenAI أنها تُشغِّل Sol فوق بنية Cerebras بمعدل يصل إلى 750 رمزاً في الثانية، مؤكدة أنها رفعت سرعة المعالجة إلى جانب القدرة نفسها.

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

هناك نقطة يجب توضيحها بأمانة. النص الأصلي للتغريدة هو إعلان صادر عن OpenAI نفسها، بينما التقييم المستقل لساحة “The Last Ones” التي سنتناولها لاحقاً (من قِبل معهد سلامة الذكاء الاصطناعي البريطاني AISI) كان حتى وقت النشر يقتصر على GPT-5.5. لذا فإن ادعاء Sol بـ”الرقم القياسي الجديد” هو رقم قدمته OpenAI نفسها، ومن الأسلم قراءته كادعاء من الجهة المعلنة إلى حين اكتمال نشر نتائج إعادة الإنتاج من طرف ثالث. يقتبس هذا المقال الأرقام القابلة للتحقق مع تمييزها بوضوح عن الجهة التي أعلنتها.

“The Last Ones”: ما تقيسه ساحة الاختبار السيبرانية ذات الـ32 خطوة

“The Last Ones” هو سيناريو اختراق محاكى لشبكة شركة افتراضية تديره AISI. يتكون من 32 خطوة إجمالاً، ويُقدَّر أن إنجازه من البداية إلى النهاية على يد خبير بشري متمرس يستغرق نحو 20 ساعة. وليس مجرد حل مسائل منفصلة، بل بنية يجب فيها ربط عدة قدرات ضرورية للاختراق الفعلي في خيط واحد لاجتيازه. يتعين على الوكيل أن يستولي على النظام، وأن يفكك البروتوكولات والمصادقة المشفرة عبر الهندسة العكسية، وأن يتلاعب بوحدات التحكم، كل ذلك عبر سلسلة من القرارات المستقلة المتصلة.

عدد النماذج التي أكملت هذه الساحة حتى النهاية حتى الآن قليل جداً. كان Claude Mythos preview أول من نجح، حيث أكمل ثلاث مرات من أصل عشر محاولات (3/10)، تلاه GPT-5.5 كثاني نموذج ينجزها حتى النهاية بمعدل مرتين من أصل عشر (2/10). قد يبدو معدل النجاح منخفضاً مقارنةً بعدد المحاولات، لكن مجرد إتمام هجوم متعدد المراحل يستغرق 20 ساعة دون تدخل بشري ولو مرة واحدة يُعد إشارة على تجاوز عتبة حرجة. وتشير دراسة ذات صلة (arXiv 2603.11214) إلى أن هذه القدرة تتناسب لوغاريتمياً وخطياً مع حجم الحساب في وقت الاستدلال، ولم يُلاحَظ بعد أي مستوى استقرار لها. وتحمل النتيجة القائلة إن رفع ميزانية الرموز من عشرة ملايين إلى مئة مليون يمكن أن يرفع الأداء بنسبة تصل إلى 59% دلالة مقلقة، مفادها أن احتمال إتمام الهجوم يستمر في الارتفاع كلما زاد المال والوقت المستثمَران فيه.

القفزة في القدرات كما تظهرها المقاييس المرجعية

تظهر هذه القفزة في القدرات أيضاً في المقاييس المرجعية الفردية. وفقاً لـ OpenAI، سجل GPT-5.6 نسبة 73.5% في ExploitBench2، وهو مقياس تقييم قدرات الاستغلال، متفوقاً بفارق كبير على نسبة 47.9% التي حققها GPT-5.5 بميزانية رموز إخراج مماثلة تقريباً. أي ارتفاع بأكثر من 25 نقطة مئوية في جيل واحد فقط. لكن هناك تفصيلاً هنا أيضاً. تشير اختبارات OpenAI نفسها إلى أن GPT-5.6 أكثر براعة في اكتشاف الثغرات وإصلاحها منه في تنفيذ الهجوم الفعلي حتى النهاية بشكل موثوق. أي أن ميزان القدرة لا يزال، حتى الآن، يميل لصالح الدفاع.

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

الدفاع قبل الهجوم: حزمة الأمان متعددة الطبقات من OpenAI

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

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

flowchart TB
    A[طلب المستخدم] --> B[قيود على مستوى النموذج<br/>حظر الدعم السيبراني الممنوع]
    B --> C[مصنِّف التفعيل<br/>مراقبة أثناء التوليد وتدخل في المنتصف]
    C --> D[مراقبة فورية للمخرجات<br/>مصنِّف إساءة الاستخدام]
    D --> E[مراجعة نظام الاستدلال الثانوي<br/>إيقاف مؤقت قبل التسليم]
    E --> F[تحليل سلوكي على مستوى الحساب<br/>رصد الأنماط الخبيثة]
    F --> G[تسليم الاستجابة أو حظرها]
    F -.نمط غير طبيعي.-> H[مراجعة وحظر وإجراء على الحساب]

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

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

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

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

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

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

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

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

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

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

المصادر

• التغريدة الأصلية (RT @OpenAI)

• [GPT-5.6: Frontier intelligence that scales with your ambition

  OpenAI](https://openai.com/index/gpt-5-6/)

• [Previewing GPT-5.6 Sol: a next-generation model

  OpenAI](https://openai.com/index/previewing-gpt-5-6-sol/)

• [GPT-5.6 Preview System Card

  OpenAI Deployment Safety Hub](https://deploymentsafety.openai.com/gpt-5-6-preview)

• Introducing Aardvark: OpenAI’s agentic security researcher

• [Our evaluation of OpenAI’s GPT-5.5 cyber capabilities

  AISI](https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities)

• [OpenAI Previews GPT-5.6 Sol With Restricted Access and Stronger Cyber Safeguards

  The Hacker News](https://thehackernews.com/2026/06/openai-limits-gpt-56-rollout-as-sol.html)

• [Measuring AI Agents’ Progress on Multi-Step Cyber Attack Scenarios

  arXiv 2603.11214](https://arxiv.org/html/2603.11214v2)

تكلفة الامتلاك ترتفع إلى أعلى مستوى في تاريخها

لنبدأ بالجانب المرتفع. تفيد سلسلة تقارير “تضخم حزمة الذكاء الاصطناعي” في ديجيتال ديلي بأن صدمة الذاكرة وصلت إلى ما هو أبعد من كبرى شركات الحوسبة السحابية، حتى غرف الخوادم الخاصة بالشركات الناشئة في مجال الذكاء الاصطناعي. ارتفعت تكلفة تركيب الخوادم الجديدة لدى شركة 42Maru، المتخصصة في الذكاء الاصطناعي للأسئلة والأجوبة، بنحو 70% مقارنة بالسابق. عرض سعر لقرص SSD سعة 4 تيرابايت كان 1.3 مليون وون قبل أسبوعين وصل هذا الأسبوع إلى 2.8 مليون وون، أي أكثر من الضعف. أخطرت سامسونج إلكترونيكس وإس كيه هاينيكس عملاءها الكبار مثل جوجل ومايكروسوفت برفع أسعار عقود ذاكرة DRAM للخوادم بنسبة 60 إلى 70%، وهما الآن لا تورّدان سوى 70% من الكميات المطلوبة. تقلصت مدة صلاحية عروض الأسعار من عدة أشهر إلى أسبوع أو أسبوعين، لذا تتحرك الشركات إما بحجز الكميات مسبقًا قبل ارتفاع الأسعار أكثر أو بتأجيل عمليات التركيب غير العاجلة.

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

لا يقتصر الأمر على ارتفاع أسعار المعدات فقط. تنغلق أيضًا محافظ كبار اللاعبين الذين يمولون اللعبة بأكملها. تتوقع UBS أن ينخفض معدل نمو الإنفاق الرأسمالي لدى أربع كبريات شركات الحوسبة السحابية، بما فيها مايكروسوفت وأمازون، بشكل حاد من 76% في 2026 إلى 25% في 2027 ثم إلى 6% في 2028. في استطلاع بنك أوف أمريكا لمديري الصناديق في يوليو، اعتبر 82% من المستجيبين أشباه الموصلات أكثر تجارة مزدحمة في السوق حاليًا، وهي أعلى نسبة سجلها الاستطلاع على الإطلاق. أصبحت أزمة الطاقة والمخاطر التنظيمية واقعًا ملموسًا أيضًا، لدرجة أن ولاية نيويورك فرضت تجميدًا لمدة عام على بناء مراكز بيانات جديدة. انتهى عصر التوسع العشوائي، وتحوّل السؤال من “هل نبني” إلى “كم سنربح”. لم يسبق أن كان قرار امتلاك البنية التحتية بهذا الثقل وهذه التكلفة.

تكلفة الاستخدام تنهار إلى أدنى مستوى في تاريخها

الآن لننظر إلى بطاقة السعر الأخرى. أطلقت صحيفة كوريا إيكونوميك ديلي على هذا الوضع اسم “مفارقة انهيار أشباه الموصلات”. قفز مؤشر فيلادلفيا لأشباه الموصلات 89% في الربع الثاني ثم تراجع 15% في يوليو، وارتفع صندوق مؤشرات متداولة للذاكرة أُدرج في أبريل بنسبة 166% خلال ثلاثة أشهر فقط قبل أن يتراجع أكثر من 20%. وبينما كانت سوق المواد الخام تتأرجح بهذا الشكل الحاد، كانت تكلفة استخدام الذكاء الاصطناعي فعليًا تخترق القاع بهدوء.

كان الزناد هو كيمي K3، النموذج مفتوح الأوزان الذي أطلقته شركة Moonshot AI الصينية هذا الأسبوع. يحمل النموذج 2.8 تريليون معامل ضمن بنية خليط من الخبراء، ويُفعّل جزءًا فقط من شبكاته الخبيرة البالغ عددها 896 لتوفير الحساب. يدعم نافذة سياق تصل إلى مليون رمز، وهو متوافق مع OpenAI SDK، ما يخفض عتبة الانتقال أمام المطورين الحاليين. اللافت هو السعر. تبلغ تكلفة معالجة مهمة واحدة 0.94 دولار، أي نحو نصف تكلفة أنثروبيك أوبس 4.8 البالغة 1.80 دولار. وينخفض السعر إلى 0.02 دولار لدى DeepSeek V4 Flash، وإلى 0.37 دولار لدى GLM 5.2.

لم يكن الأمر تفردًا لنموذج واحد، بل مالت الموجة بأكملها. وفقًا لنيوسيس، استحوذت النماذج الصينية مفتوحة الأوزان مثل Tencent وXiaomi وDeepSeek وMiniMax وZhipu AI على المراكز الخمسة الأولى في استخدام الرموز الأسبوعي على منصة OpenRouter الوسيطة للنماذج. حتى الأسبوع الأخير من يونيو، بلغت حصة النماذج الصينية 48%، متقدمة بفارق كبير على حصة الولايات المتحدة البالغة 20%، في انعكاس كامل للوضع قبل عام واحد، حين كانت الولايات المتحدة تتصدر بنسبة 74% مقابل 20% للصين. وأوضح رافي كريكوريان، كبير مسؤولي التقنية في موزيلا، أنه بحسب طبيعة العمل يمكن خفض التكلفة إلى 1/50 من تكلفة أفضل النماذج. تُباع واجهات برمجة تطبيقات نماذج مثل DeepSeek وQwen بأسعار أرخص بمقدار 10 إلى 150 مرة من أفضل النماذج الأمريكية. تتحول الشركات إلى نهج مزدوج، تعهد فيه بالمهام الروتينية إلى النماذج الرخيصة مفتوحة الأوزان وتحتفظ بالمهام الصعبة فقط لأفضل النماذج.

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

حين يتسع المقص، تتغير ساحة المعركة

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

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

فيما يلي رسم واحد يلخص كيف يؤدي اتساع بطاقتي السعر إلى تحويل ساحة المعركة.

flowchart TD
    A["Cost to OWN AI infra rising<br/>memory shock, +70% servers"] --> C["Widening price scissors"]
    B["Cost to USE AI falling<br/>Kimi K3, Chinese open-weight"] --> C
    C --> D["Battleground shifts to<br/>GPU utilization"]
    D --> E["Model routing:<br/>cheap vs top-tier"]
    D --> F["Scheduling:<br/>no idle cards"]
    D --> G["Control and audit:<br/>policy gate, logs"]
    E --> H["Paxis agent-native cloud"]
    F --> H
    G --> H

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

إذن، ما الذي يجب أن تمتلكه

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

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

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

المصادر

كُتب هذا المقال استنادًا إلى تجميع الأخبار التالية.

• نيوز1، “اعتماد بعد تجربة K-NPU”… فيريوسا AI تسرّع “استراتيجية إثبات الجدوى الكاملة” في أوروبا
• ديجيتال ديلي، [تضخم حزمة الذكاء الاصطناعي ⑤] صدمة الذاكرة تصل حتى شركات الذكاء الاصطناعي… “تكلفة شراء الخوادم ترتفع 70%”
• كوريا إيكونوميك ديلي، “كلما رخُص، ازداد الاستخدام”… مفارقة انهيار أشباه الموصلات التي هزّها الذكاء الاصطناعي “بأفضل قيمة مقابل السعر”
• ويكي تري، إتشد تُقيَّم بـ20 مليار دولار قبل شحن أي رقاقة… جين ستريت وسيكويا يراهنان في آن واحد
• غلوبال إيكونوميك، استثمارات الذكاء الاصطناعي تتحول من “التوسع” إلى “الانتقاء”… تباطؤ إنفاق شركات الحوسبة السحابية الرأسمالي يرتد على أشباه الموصلات
• ديجيتال ديلي، [الذكاء الاصطناعي للجميع ④ الأخيرة] معضلة توزيع وحدات معالجة الرسوميات… “انتشار متعدد الشركات مقابل التركيز والاختيار”
• زد دي نت كوريا، سبيس إكس تتفاوض مع البنتاغون الأمريكي على صفقة توريد حوسبة ذكاء اصطناعي بمليارات الدولارات
• زد دي نت كوريا، مونشوت الصينية تكشف عن نموذج الذكاء الاصطناعي الجديد “كيمي K3”… تطارد OpenAI وأنثروبيك عن قرب
• زد دي نت كوريا، ZTE تكشف عن هاتف وكيل الذكاء الاصطناعي “NaviX Ultra”
• آي نيوز24، “ما تقييمات السكن الفعلي لهذه الشقة؟”… تبويب البحث الحواري بالذكاء الاصطناعي من نايفر يطور المعلومات المخصصة
• ذا بيز، [قضية البنك الأسبوعية] “الذكاء الاصطناعي هو المستقبل”… انتشار “AX” على نطاق واسع في القطاع المصرفي
• نيوز1، “نمنحكم خصمًا على جيميناي”… شركات الاتصالات الكورية الثلاث تتنافس على جذب المستخدمين في عصر الذكاء الاصطناعي كسلعة أساسية
• يونهاب نيوز، [قانون الذكاء الاصطناعي الأساسي] الجزء 1: القانون المعدَّل يدخل حيز التنفيذ في 21… التشريع الكوري للذكاء الاصطناعي جاهز
• نيوسيس، بعد أشباه الموصلات، يصبح الذكاء الاصطناعي أيضًا أصلًا استراتيجيًا… هيئة البحوث التشريعية تنصح بـ”إعادة صياغة استراتيجية الذكاء الاصطناعي السيادي”
• نيوسيس، الصين تكتسح المراكز 1 إلى 5 في الاستخدام الأسبوعي لمنصات الذكاء الاصطناعي… تهز الذكاء الاصطناعي الأمريكي المرتفع الثمن
• زد دي نت كوريا، داتابريكس الأمريكية تجمع تمويلًا جديدًا… تصل قيمتها إلى 188 مليار دولار
• زد دي نت كوريا، “تطوير أمن الذكاء الاصطناعي التوليدي”… مونيتورلاب ترتقي بحلول أمن الذكاء الاصطناعي

نظرة عامة

ظلت نماذج توليد الصور لفترة طويلة منقسمة إلى مسارين. في جانب، هناك نموذج لغوي يفهم النص. وفي الجانب الآخر، هناك نموذج انتشار (diffusion) يرسم البكسلات. وتُعد سلسلة Stable Diffusion المثال الأبرز على ذلك. يفسّر مشفر النص التوجيه (prompt)، ثم يزيل UNet أو DiT الضوضاء في الفضاء الكامن، ثم يعيد VAE (المشفر التلقائي التبايني) بناء تلك القيم الكامنة إلى بكسلات من جديد. إنها بنية يحدث فيها الفهم والتوليد في وحدتين مختلفتين وبتمثيلين مختلفين.

أما 日日新 SenseNova U1 من SenseTime (سنسه‌تايم)، الذي أُطلق بشكل تدريجي ابتداءً من أبريل 2026، فيرفض هذا الانفصال جملة وتفصيلاً. فهو يلغي كلاً من المشفر البصري و VAE، ويطرح بدلاً منهما بنية NEO-Unify التي تعالج المعلومات اللغوية والبصرية حتى النهاية داخل فضاء تمثيل واحد. يتولى النموذج المفرد معالجة الفهم والتوليد والتحرير، وصولاً إلى التوليد المتشابك (interleave) الذي يبثّ النص والصورة بالتناوب. أُتيحت الأوزان برخصة Apache 2.0، وبحجم يقارب 8B فإنها تعمل على بطاقة RTX 5090 واحدة. وهذا يعني إمكانية الاستضافة الذاتية لأغراض تجارية.

يستعرض هذا المقال حقائق SenseNova U1، وما يمكننا فعلياً تشغيله في بيئتنا المحلية (on-premise)، بصراحة تامة، بما في ذلك سبب استحالة تشغيله مباشرة على أدوات شائعة كـ Automatic1111 كما قد يتوقع البعض. وبما أن ThakiCloud تعمل على تقديم النماذج ضمن بيئات عملاء متنوعة، فإن جوهر هذا المقال هو سدّ الفجوة بين عنوان “صدرت أوزان مفتوحة” وواقع “يمكن تشغيلها على مجموعتنا الحاسوبية”.

ما هو SenseNova U1: معنى التخلي عن VAE

تنطلق NEO-Unify من ملاحظة بسيطة: البكسلات والكلمات مترابطة بعمق في جوهرها، لكن خطوط الأنابيب (pipelines) التقليدية أجبرتها على الانفصال. لذلك يزيل U1 محوّلين وسيطين كاملين. لا يوجد مشفر بصري (VE) كان يضغط الصورة إلى سمات، ولا يوجد VAE كان يعيد القيم الكامنة إلى بكسلات. بدلاً من ذلك، يدمج المعلومات اللغوية والبصرية في تمثيل مركّب واحد ويعالجه من البداية إلى النهاية. وتوضح SenseTime أن هذا يعمل فوق بنية MoT (خليط من المحولات، Mixture-of-Transformers) أصيلة، مما يتيح استنتاجاً كفؤاً بلا تعارض بين الوسائط المختلفة.

من منظور المستخدم، يتجلى هذا الفرق في “نموذج واحد يقوم بكل شيء”. فهو يفهم الصور (الإجابة عن أسئلة بصرية، VQA)، ويولّد الصور، ويحرّرها، ويولّد النص والصورة بالتناوب ضمن تدفق واحد. ويُطرح كمثال بارز إنتاج محتوى يتناوب فيه الشرح مع الرسوم التوضيحية، كدروس الطهي أو يوميات السفر، وذلك في عملية توليد واحدة. كما تشدد SenseTime على قدرته في مجال الذكاء المكاني (spatial intelligence) على فهم التخطيطات المعقدة والعلاقات بين الأجسام، وهو ما يمهد لمستقبل يكتمل فيه الإدراك والاستدلال والتنفيذ في نموذج واحد ضمن الذكاء الاصطناعي المتجسّد (embodied AI) للروبوتات.

فيما يلي مخطط مفاهيمي يضع خط أنابيب سلسلة SD التقليدي جنباً إلى جنب مع خط الأنابيب الموحد لـ U1.

flowchart TB
    subgraph SD["سلسلة SD التقليدية (منفصلة)"]
        direction TB
        A1["توجيه نصي"] --> A2["مشفر النص (CLIP)"]
        A2 --> A3["UNet / DiT (انتشار كامن)"]
        A3 --> A4["مفكّك VAE"]
        A4 --> A5["صورة بكسلية"]
    end
    subgraph U1["SenseNova U1 (موحد عبر NEO-Unify)"]
        direction TB
        B1["مدخل نصي · صورة"] --> B2["فضاء تمثيل موحد واحد<br/>(بلا VE · بلا VAE)"]
        B2 --> B3["محوّل MoT أصيل<br/>فهم · توليد · تحرير مشترك"]
        B3 --> B4["مخرج نصي · صورة · متشابك"]
    end
    SD -.->|"3 وحدات، نوعا تمثيل"| GAP["كلفة الانفصال:<br/>تمثيل مختلف للفهم والتوليد"]
    U1 -.->|"وحدة واحدة، نوع تمثيل واحد"| WIN["فائدة التوحيد:<br/>حفظ الارتباط بين البكسل والكلمة"]

الجوهر هو أن U1 ليس نقطة تفتيش انتشارية (diffusion checkpoint)، بل محوّل موحد يعمل كنموذج لغوي كبير. وهذه الحقيقة الواحدة هي ما يحدد بالكامل طريقة التقديم وتوافقية الأدوات التي سنتناولها لاحقاً.

ما أُتيح ليس U1 Pro بل سلسلة U1 Lite

هنا يجب التنويه بتمييز جوهري. U1 Pro الظاهر على صفحة منصة SenseTime (sensenova.cn) هو النسخة التجارية الرائدة المستضافة. ورغم أن أمثلة توليد الرسوم البيانية والملصقات عالية الكثافة مثيرة للإعجاب، فإن أوزان هذه الفئة “Pro” غير متاحة على HuggingFace. فمن الصواب اعتباره طبقة تجارية يُصار إليها عبر واجهة برمجية (API) فقط.

أما ما يمكن استضافته ذاتياً فهي سلسلة U1 Lite. وفيما يلي أهم الأوزان المتاحة:

تمر نماذج SFT بمراحل: إحماء الفهم ← التدريب المسبق للتوليد ← التدريب المتوسط الموحد ← الضبط الدقيق الموحد (SFT)، ويُحصل على النموذج النهائي بإضافة تعلم معزز (RL) للتحويل من نص إلى صورة (T2I) فوق ذلك. وتشير SenseTime إلى أن ما صدر اليوم هو نسخة “Lite”، مع الإعلان عن نسخة أكبر حجماً قادمة. أي أن النموذجين 8B/A3B الحاليين نسخة مدمجة نسبياً، والسقف ما زال مفتوحاً.

باختصار، إذا قيل في مدونة أو عرض توضيحي “لقد شغّلنا U1 Pro”، فهذا غير دقيق. النموذج المفتوح الذي نضعه في بيئتنا المحلية هو U1-8B-MoT (أو A3B).

الموقع على المعايير القياسية

تدّعي SenseTime أن U1 هو “أفضل أداء (SoTA) ضمن المعسكر مفتوح المصدر في كل من الفهم والتوليد معاً”. أُجري التقييم على معايير OneIG (بالإنجليزية/الصينية)، LongText (بالإنجليزية/الصينية)، BizGenEval (سهل/صعب)، CVTG، IGenBench، ومعايير الرسوم البيانية. وتُبرز بطاقة النموذج مخطط المفاضلة بين الأداء وزمن استجابة التوليد (latency)، مع التركيز على تحقيق الجودة نفسها بسرعة أكبر.

بدلاً من نقل الأرقام كما هي، ينبغي النظر إلى طبيعتها. يُقدَّم U1 Lite بوصفه قادراً على تحقيق نتائج بمستوى تجاري في توليد الرسوم البيانية المعقدة تحديداً، أي في المجالات التي تكون فيها اتساقية التخطيط ودقة عرض النص أموراً حاسمة. وتذكر بعض المصادر الإعلامية أن جودة مخرجات U1 Lite تضاهي Qwen-Image 2.0 Pro أو Seedream 4.5، لكن هذا مستند إلى مصادر البائع أو مصادر ثانوية، لذا يبقى مصنّفاً بـ[تقدير] ويحتاج إلى تحقق فعلي. معيارنا واحد فقط: نثق بالأرقام التي نحصل عليها من تشغيله فعلياً ببياناتنا وتوجيهاتنا على معالجاتنا الرسومية (GPU).

التثبيت والتقديم: مساران

حقيقة أن U1 ليس نقطة تفتيش انتشارية بل محوّل موحد تنعكس مباشرة على طريقة تقديمه. فبدلاً من وضعه فوق واجهة انتشار (diffusion UI)، يُقدَّم كما يُقدَّم أي نموذج لغوي كبير.

المسار الأول: transformers الأصيل. يوفر المستودع الرسمي تثبيت التبعيات عبر uv وسكربتات أمثلة مخصصة لكل مهمة، منها: تحويل النص إلى صورة، وتحرير الصور، والتوليد المتشابك.

# مثال على تحرير صورة (يمكن التحرير على مستوى البكسل حتى بلا VAE)
python examples/editing/inference.py \
  --model_path sensenova/SenseNova-U1-8B-MoT \
  --prompt "Change the animal's fur color to a darker shade." \
  --image examples/editing/data/images/1.webp \
  --cfg_scale 4.0 --img_cfg_scale 1.0 --num_steps 50 \
  --output output_edited.png --profile --compare

# التوليد المتشابك (شرح + رسوم توضيحية في تدفق واحد)
python examples/interleave/inference.py \
  --model_path sensenova/SenseNova-U1-8B-MoT \
  --prompt "أنشئ دليلاً مصوراً للمبتدئين لطبق البيض المقلي بالطماطم." \
  --resolution "16:9" --output_dir outputs/interleave/ --stem demo

المسار الثاني: التقديم عبر vLLM-Omni. لإلحاق النموذج بعرض توضيحي أو منتج، يلزم وجود نقطة نهاية متوافقة مع OpenAI. يدعم vLLM-Omni نموذج U1 رسمياً، ويوفر أمثلة لكل من الاستدلال دون اتصال (offline) والتقديم عبر الشبكة (online). ولتخفيف الضغط على ذاكرة VRAM، توجد إمكانية نقل الحمل إلى المعالج المركزي (CPU offload) على مستوى الوحدات. يطبّق خط الأنابيب اكتشاف المكونات (component discovery)، فينقل النموذج اللغوي إلى المعالج المركزي أثناء مراحل ترميز النص/الرؤية، وينقل المشفر البصري إلى المعالج المركزي أثناء حلقة الانتشار، لتقليل الأوزان المقيمة على معالج الرسوميات إلى الحد الأدنى.

# vLLM-Omni: تحويل نص إلى صورة مع تفعيل نقل الحمل إلى المعالج المركزي
python end2end.py \
  --prompt "A cute cat sitting on a windowsill" \
  --width 2048 --height 2048 \
  --enable-cpu-offload --think

خيارات لذاكرة VRAM المحدودة. يوفر المستودع الرسمي نمط نقل الطبقات (layer offload) على معالج رسوميات واحد (--vram_mode full|low|balanced) إلى جانب تحميل التكميم GGUF. تشير التوجيهات إلى أن الجمع بين Q4 GGUF ووضع balanced يتيح التشغيل حتى على بطاقات استهلاكية بذاكرة تقارب 10 إلى 12 جيجابايت. أي أن النشر ينقسم إلى ثلاث مستويات: للحصول على أقصى سرعة استخدم full مع 24 جيجابايت فأكثر، وإن لم تتوفر تلك الموارد فاستخدم GGUF مع balanced، وللتقشف الشديد استخدم low.

أي الأدوات تُستخدم: ComfyUI نعم، A1111 لا

أكثر توقع شائع هو “لنحمّل النموذج كنقطة تفتيش في Stable Diffusion WebUI (Automatic1111)”. والخلاصة أن ذلك غير ممكن. صُمم A1111 لتحميل نقاط تفتيش سلسلة SD المكوّنة من UNet/DiT + VAE + مشفر نص CLIP حصراً. وبما أن U1 محوّل MoT موحد لا يحوي VAE، فإن وضع ملف .safetensors في مجلد نقاط التفتيش لا يؤدي حتى إلى نجاح عملية التحميل. إنه عدم توافق جوهري ناتج عن اختلاف البنية.

إن أردت إدخال التوجيهات يدوياً بطريقة تفاعلية، فإن البديل الفعلي لـ A1111 هو ComfyUI. توفر عقدة مخصصة أنشأها المجتمع (smthemex/ComfyUI_SenseNova_U1) دعماً أصيلاً لنموذج U1، وتتعامل مع 8B-MoT و A3B-MoT وLoRA بثماني خطوات وGGUF جميعاً.

باختصار، محوران: الواجهة التفاعلية التي يستخدمها الأشخاص يدوياً هي ComfyUI، والخلفية البرمجية للعروض التوضيحية والمنتجات التي يستدعيها البرنامج هي vLLM-Omni (متوافق مع OpenAI). من كان يتوقع A1111 فعليه تغيير اختيار الأداة.

منظور ThakiCloud في التقديم

يعمل ai-platform لدى ThakiCloud فوق Kubernetes على تقديم النماذج ضمن بيئات عملاء متنوعة. ويُعد SenseNova U1 مرشحاً جيداً للتناول من هذا المنظور تحديداً.

أولاً، الحجم ملائم للبيئة المحلية (on-premise). فبحجم 8B، يقيم النموذج في نحو 16 إلى 20 جيجابايت وفق دقة fp16، ما يسمح ببناء حاوية تقديم (serving pod) على بطاقة واحدة من RTX 4090 أو 5090 أو A6000، بينما نموذج A3B أخف من ذلك. وهذا ينسجم تماماً مع طريقتنا في وضع معالجات الرسوميات في طابور عبر Kueue وتوزيعها متعددة المستأجرين. فبخلاف النماذج الحدودية الضخمة التي تتطلب 8 وحدات H200، يمكن لعبء عمل فعلي أن يقوم على بطاقة أو بطاقتين من معالجات رسوميات العميل نفسه.

ثانياً، تخفض نقطة النهاية المتوافقة مع OpenAI في vLLM-Omni تكلفة التكامل. وبما أن طبقة التقديم Metis وخطوط أنابيب العروض التوضيحية لدينا مبنية أصلاً على افتراض واجهة متوافقة مع OpenAI، يمكن إلحاق U1 دون الحاجة إلى مكدس انتشار (diffusion stack) منفصل. وتوحيد واجهة توليد الصور مع النموذج اللغوي النصي تحت نظام واحد للمراقبة وقياس التكلفة ميزة عملية حقيقية.

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

كما ينفتح منظور الوكلاء (agents). فـ Paxis، سحابة ThakiCloud الأصيلة للوكلاء (Agent-Native Cloud)، تنفّذ المهارات في بيئات معزولة (sandboxes) وتُخضع كل سلوك لبوابات سياسات وسجلات تدقيق، ونموذج صور موحد مستضاف ذاتياً كـ U1 مناسب تماماً للتسجيل بوصفه “أداة توليد صور” يستدعيها الوكيل. فحين تُستكمل عملية توليد الرسوم البيانية والملصقات في حاويات داخلية دون واجهة برمجية خارجية، فإن التقديم منخفض التكلفة (ai-platform) يرفع مباشرة من جدوى اقتصاديات سير عمل الوكلاء (Paxis).

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

للحفاظ على التوازن، لا بد من النظر إلى الجانب الآخر أيضاً. أولاً، ما هو مُتاح الآن هو النسخة Lite (8B/A3B)، ومن المرجح أن تكون الجودة الفائقة محصورة في نسخة U1 Pro المستضافة. فتعبير “أفضل أداء مفتوح” هو مقارنة ضمن المعسكر مفتوح المصدر، وليس ضماناً لمساواته بأفضل النماذج التجارية.

ثانياً، ميزة البنية الموحدة هي في الوقت نفسه نقطة ضعف في النظام البيئي. فبما أن U1 ليس نموذج SD، فإنه لا يرث أصول سير عمل A1111/SD المتراكمة على مدى سنوات، كـ ControlNet ومكتبات LoRA المجتمعية الضخمة وامتدادات إعادة الرسم (inpainting). ونقل خطوط الأنابيب القائمة إلى U1 يتطلب إعادة بناء منظومة الأدوات من الصفر. صحيح أن عقد ComfyUI ومدرّب LoRA الخاص متاحان، لكن نضج النظام البيئي لا يزال في مراحله الأولى.

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

رابعاً، وضع ذاكرة VRAM المنخفضة ليس مجانياً. فنقل الحمل إلى المعالج المركزي وتسلسل الطبقات (layer streaming) يوفّران ذاكرة VRAM لكن على حساب زيادة زمن الاستجابة بسبب النقل بين المعالج المركزي ومعالج الرسوميات. وإذا كانت الاستجابة اللحظية أمراً حاسماً للخدمة، فالأفضل التشغيل بوضع full على بطاقة بذاكرة 24 جيجابايت فأكثر دون نقل حمل، وهذا ينعكس بدوره على تكلفة معالج الرسوميات.

الخاتمة

يمثّل SenseNova U1 تحقيقاً فعلياً لاتجاه “الوسائط المتعددة الموحدة بلا VAE” عبر أوزان مفتوحة. ورغم أن مدى ما يمكن أن يبلغه نهج دمج الفهم والتوليد في تمثيل واحد لن يتضح إلا مع صدور نسخة أكبر، فإن النسختين الحاليتين 8B/A3B جذابتان بما يكفي بوصفهما مرشحتين للتقديم المحلي. في المقال القادم، سنضع هذا النموذج فعلياً على RunPod وخط أنابيب العروض التوضيحية لدينا، ونشغّل تقديم vLLM-Omni وسير عمل ComfyUI جنباً إلى جنب، ونستعرض النتائج مدعومة بالأرقام.

روابط مرجعية

• بطاقة النموذج: sensenova/SenseNova-U1-8B-MoT
• الكود/التوثيق: OpenSenseNova/SenseNova-U1 (GitHub)
• الورقة البحثية: SenseNova-U1: Unifying Multimodal Understanding and Generation with NEO-unify (arXiv:2605.12500)
• التقديم: مثال vLLM-Omni لنموذج SenseNova-U1
• عقدة ComfyUI: smthemex/ComfyUI_SenseNova_U1
• نسخة U1 Pro المستضافة: SenseNova U1 Pro

أصبحت نماذج الاستدلال هي المعيار، والآن نختار مقدار الجهد

مرّ نحو عامين منذ أن عمّمت OpenAI نماذج الاستدلال في نماذج اللغة الكبيرة عبر o1، وبعد أربعة أشهر فتحت DeepSeek-R1 الباب أمام طريقة التدريب نفسها بنشر وصفة تعلم معزز (RLVR) تستخدم مكافآت قابلة للتحقق. منذ ذلك الحين، تحوّل الاستدلال من ميزة خاصة إلى لبنة بناء افتراضية في إصدارات النماذج الجديدة. عائلة GPT-5.6 التي صدرت الأسبوع الماضي تُطرح بثلاثة أحجام، ويأتي كل حجم مع نحو خمسة إلى ستة إعدادات لجهد الاستدلال.

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

ما هو جهد الاستدلال

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

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

كيف يتم التدريب: محوران

سواء كان الأمر يتعلق بـ GPT-5.6 أو gpt-oss مفتوح المصدر، فإن تفاصيل التدريب الدقيقة غير معلنة، لكن بشكل عام تُدرَج تسمية الجهد ضمن الموجّه في مرحلة ما بعد التدريب (post-training). وتنقسم طرق تنفيذ ذلك إلى مسارين رئيسيين.

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

الصورة العامة للطريقتين موضحة أدناه. معظم الوصفات الفعلية هي تنويعات على هذا الهيكل.

flowchart LR
    A["베이스 / RLVR 리즈닝 모델"] --> B["1. SFT + chat template<br/>노력 모드를 입력으로 도입"]
    B --> C["2. mode-conditioned RL<br/>노력별 context window·length penalty 차등"]
    C --> D["3. 하드 예산 강건성 학습<br/>truncated trace·강제 중단 후 재개·budget toggle"]
    D --> E["추론: system prompt로 노력 선택<br/>+ 선택적 토큰 예산"]

تعمّق في ستة نماذج مفتوحة الأوزان

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

DeepSeek V4: فصل الجهد إلى خبراء مستقلين

يصف التقرير التقني لـ DeepSeek V4 ثلاثة أوضاع. Non-think يجيب مباشرة دون أثر استدلال، وThink High هو الأسلوب الكلاسيكي على طريقة R1 الذي يضع أثر الاستدلال بين <think> و</think>، أما Think Max فيضيف فوق ذلك تعليمات نظام خاصة. تبدأ تعليمات Think Max بعبارة “Reasoning Effort: Absolute maximum with no shortcuts permitted”. الفكرة الجوهرية هي التعامل مع مستويات الجهد المختلفة كأنها خبراء منفصلون تقريباً، وصقلها عبر RL مشروط بالوضع (mode-conditioned RL).

Nemotron 3 Ultra: الجمع بين وضع مدرَّب وميزانية صارمة

يستخدم Nemotron 3 Ultra ثلاثة إعدادات: reasoning-off وregular وmedium-effort. وmedium-effort وضع استدلال أرخص من regular، وتُدخله NVIDIA خلال مرحلة SFT باستخدام مخرجات GPT-OSS-120B بجهد متوسط، ثم تُحسّنه لاحقاً عبر RLVR. ونحو 2.5% من موجّهات RLVR تخص medium-effort، وتُطبَّق عليها معايرة مكافأة مبنية على الطول. وفوق ذلك، يمكن تركيب ميزانية رموز وقت الاستدلال كآلية إيقاف خارجية. إذ يُطلب من النموذج إنهاء الاستدلال قرب حد يحدده العميل، وإن لم يُصدر النموذج </think> من تلقاء نفسه يقوم العميل بإغلاقه قسراً. ولضمان ألا تنهار الإجابة عند القطع بهذه الطريقة، يُدرَّب النموذج على آثار مقطوعة عشوائياً لتحقيق المتانة.

Kimi K2.5: مفتاح Toggle الذي يتناوب بين المُقيَّد وغير المُقيَّد

تنطلق طريقة Toggle الخاصة بـ Kimi K2.5 من مشكلة أن التدريب على ميزانية رموز ثابتة فقط يجعل النموذج يفرط في التلاؤم مع الحلول القصيرة ويفقد فائدة الحوسبة الإضافية. لذلك تتناوب الطريقة بين مرحلتين كل عدد محدد من تكرارات التدريب. في مرحلة budgeted تُوجَّه الحلول الصحيحة للبقاء ضمن ميزانية رموز خاصة بكل مسألة، وفي مرحلة unconstrained يُستعاد أقصى طول للتوليد بحيث يستمر النموذج في التعلم من الحلول الطويلة أيضاً. تُقدَّر الميزانية من نسبة مئوية محددة لأطوال الجولات الصحيحة في RLVR، لكن قيد الميزانية لا يُفعَّل إلا بعد أن تتجاوز دقة تلك المسألة عتبة معينة. الهدف هو رفع كفاءة الرموز بشكل كبير مع الحفاظ على أداء المعايير القياسية الإجمالي عند مستوى مشابه.

GLM-5: التفكير على مستوى الدور، المتشابك، والمحفوظ

يوسّع GLM-5 مفتاح التشغيل/الإيقاف الثنائي في GLM-4.5 ليشمل سيناريوهات متعددة الأدوار واستخدام الأدوات. وتكمن ميزته المميزة في أنه يعرّف ثلاثة سلوكيات مترابطة بدلاً من ثلاثة مستويات جهد. فـ interleaved thinking يضع كتلة استدلال قبل كل استجابة واستدعاء أداة، وpreserved thinking يحتفظ بكتل الاستدلال السابقة ويعيد استخدامها عبر أدوار متعددة، وturn-level thinking يشغّل الاستدلال ويوقفه لكل طلب ضمن المحادثة. والمفتاح الفعلي وقت الاستدلال هو turn-level. وفي واجهة برمجة تطبيقات Z.ai يكون مفعّلاً افتراضياً ويمكن تعطيله على مستوى كل طلب على حدة.

Qwen3: دمج الأوضاع والقطع وقت الاستدلال

يتألف خط أنابيب ما بعد التدريب في Qwen3 من أربع مراحل: long-CoT SFT، وRL الاستدلال، وThinking Mode Fusion، وRL عام. وجوهر مفتاح التشغيل/الإيقاف للجهد هو Thinking Mode Fusion، الذي يجري SFT على مزيج من أمثلة thinking وnon-thinking. أمثلة /think تحتوي على أثر استدلال، بينما تبدأ أمثلة /no_think بكتلة <think></think> فارغة تليها إجابة قصيرة. ويعزّز RL العام اللاحق الالتزام بالتعليمات والصيغة في كلا السلوكين. كما يدعم Qwen3 ميزانية تفكير صارمة، حيث يتوقف الاستدلال عند عتبة محددة، ثم تُدرج تعليمات إيقاف، ثم يُنتقل إلى الإجابة النهائية. ومن اللافت أن التقرير يذكر أن سلوك الاستدلال الجزئي هذا لم يُدرَّب عليه صراحة، بل ظهر تلقائياً بعد Thinking Mode Fusion. وهو أبسط من DeepSeek V4 أو Nemotron، لكنه يوفّر معاً مفتاح تشغيل/إيقاف مدرَّباً وميزانية وقت الاستدلال.

Inkling: جهد عبر موجّه النظام مع RL مشروط بالوضع

يحدد Inkling الجهد عبر موجّه النظام، مدعوماً بـ RL مشروط بالوضع. وكما رأينا سابقاً، يُظهر هذا النموذج النزعة نفسها التي يرتفع فيها عدد الرموز والأداء معاً مع رفع الجهد لكن المكاسب تتباطأ في المستويات العليا، وهو مرجع مفيد لتحديد أين يجب وضع سقف الجهد عند الخدمة.

هيكل مشترك: تسميات متطابقة لكن إطار واحد

عند وضع النماذج الستة جنباً إلى جنب، يظهر إطار مشترك بينها. أولاً، يُدخَل وضع الجهد كمُدخل عبر SFT وقالب المحادثة (chat template). فـ Qwen3 يمزج صراحة بين أمثلة thinking وnon-thinking، وGLM-5 يضيف فوق ذلك أنماط interleaved وpreserved وturn-level. ثانياً، في مرحلة RL المشروط بالوضع، يتغيّر نافذة السياق وعقوبة الطول بحسب الجهد المطلوب. تستخدم DeepSeek V4 وNemotron 3 Ultra وInkling هذا النهج. ثالثاً، تُضاف متانة تحت ميزانية صريحة. فـ Nemotron يتدرب على آثار مقطوعة عشوائياً، ويمكن لـ Qwen3 استئناف الاستدلال من نقطة توقف قسري، ويتناوب Kimi بين RL المُقيَّد وغير المُقيَّد. هذه الآليات تحافظ على جودة الإجابة حتى عندما يتغير طول الاستدلال المتاح أو يُقطَع في منتصف الطريق.

الجدول التالي يلخّص ما هو موثّق فعلياً عبر التقارير الستة.

الخلاصة ومنظور ThakiCloud

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

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

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

يحتوي المقال الأصلي على روابط غنية لتقارير كل نموذج التقنية ورسومات توضيحية، لذا إن احتجت إلى تفاصيل الوصفة الخاصة بنموذج معين، نوصي بمراجعة مقالة Sebastian Raschka الأصلية والتقرير المعني مباشرة.