C++ on kenji.blog

لا حاجة لبايثون! بناء محرك استدلال للذكاء الاصطناعي باستخدام C++ فقط

Fri, 11 Sep 2026 17:00:00 +0900

1. مقدمة: لماذا نتخلى عن بايثون ونصنع محرك استدلال للذكاء الاصطناعي باستخدام C++؟

في تطوير الذكاء الاصطناعي الحديث، تعتبر بايثون (Python) هي المعيار الفعلي. بفضل أطر العمل القوية مثل PyTorch و TensorFlow، يمكنك بناء وتدريب واستدلال شبكات عصبية معقدة ببضعة أسطر من التعليمات البرمجية. ومع ذلك، وراء كواليس هذه الأطر، تتولى اللغات ذات المستوى المنخفض مثل C++ و CUDA معالجة العمليات الحسابية الثقيلة. إن بايثون تلعب مجرد دور “الصمغ”.

إذن، لماذا نحتاج إلى استبعاد بايثون وبناء محرك استدلال للذكاء الاصطناعي باستخدام C++ بمفردها؟ هناك عدة أسباب قوية لذلك:

الأداء الفائق وزمن الانتقال المنخفض: يمكن التخلص تمامًا من النفقات الإضافية الناتجة عن القفل العالمي للمترجم (GIL) والنوع الديناميكي في بايثون. خاصة في الأنظمة التي تتطلب العمل في الوقت الفعلي، حيث يكون التأخير بالمللي ثانية أمرًا قاتلًا.
سهولة النشر: من الصعب للغاية بناء بيئة بايثون (مجموعة ضخمة من المكتبات، جحيم التبعيات) في بيئة المستخدم النهائي. باستخدام C++، كل ما عليك فعله هو توزيع ملف تنفيذي ثنائي واحد مرتبط بشكل ثابت (مثل .exe أو ثنائيات ELF).
دعم الأجهزة الطرفية: في البيئات ذات الموارد المحدودة مثل الهواتف الذكية، والأجهزة المدمجة، و Raspberry Pi، لا توجد سعة لتشغيل بيئة تشغيل بايثون التي تستهلك جيجابايتات من الذاكرة.
التحكم المباشر في الأجهزة: توفر C++ إمكانية التحكم في المستوى المنخفض، مثل توقيت تخصيص الذاكرة، والاستخدام الصريح لتعليمات SIMD، وتحسين عمليات نقل الذاكرة مع وحدة المعالجة الرسومية (GPU).

في هذه المقالة، ومن خلال استلهام كبير من بنية مكتبة “GGML” التي طورها Georgi Gerganov، سنغوص في الأعماق التقنية لشرح عملية بناء محرك استدلال من الصفر باستخدام C++ فقط لتشغيل النماذج اللغوية الكبيرة (LLMs) وغيرها.

2. النظرة العامة على بنية محرك الاستدلال

تعد عملية الاستدلال في الذكاء الاصطناعي في جوهرها “سلسلة من حسابات المصفوفات الضخمة”. لتنفيذ ذلك بكفاءة، يجب أن يتكون محرك الاستدلال من المكونات التالية.

graph TD A["بيانات الإدخال (رموز/صور)"] --> B["إدارة الموترات"] B --> C["الرسم البياني الحسابي (DAG)"] C --> D["ساحة الذاكرة والمخصص"] C --> E["المجدول وتجمع الخيوط"] E --> F["الواجهة الخلفية للمعالج (AVX2/ARM NEON)"] E --> G["الواجهة الخلفية للرسوميات (CUDA/Metal)"] F --> H["نتائج الإخراج"] G --> H

إدارة الموترات (Tensor): إدارة هيكل بيانات المصفوفات متعددة الأبعاد، والخطوة (Stride) لكل بُعد.
الرسم البياني الحسابي (Computation Graph): تمثيل العمليات الحسابية لكل طبقة من طبقات الشبكة العصبية كرسم بياني موجه غير دوري (DAG).
ساحة الذاكرة (Memory Arena): آلية إدارة ذاكرة مخصصة مسبقًا لتجنب النفقات الإضافية لتخصيص الذاكرة الديناميكي (malloc أو new).
الواجهة الخلفية (Backend): تنفيذ العمليات (النواة/Kernels) المحسّنة لأجهزة معينة مثل CPU أو GPU.

سنقوم ببناء هذه المكونات معًا باستخدام ميزات C++ القوية (مثل القوالب، حساب المؤشرات، و RAII).

3. أسرار إدارة الذاكرة: ساحة الذاكرة (Memory Arena) ومحاذاة SIMD

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

لذلك، نعتمد نهج “ساحة الذاكرة (Memory Arena)”. تتمثل هذه الطريقة في حساب (أو تحديد) الحد الأقصى للذاكرة المطلوبة في بداية الاستدلال وتخصيصها دفعة واحدة، ثم استقطاع الذاكرة ببساطة عن طريق زيادة المؤشر.

3.1 أهمية المحاذاة (Alignment)

تدعم وحدات المعالجة المركزية (CPUs) الحديثة تعليمات SIMD (تعليمة واحدة، بيانات متعددة). مثل AVX2/AVX-512 في Intel/AMD، و NEON في ARM. تقوم هذه التعليمات بمعالجة 256 بت (32 بايت) أو 512 بت (64 بايت) من البيانات دفعة واحدة، ولكن يجب أن تكون ذاكرة البيانات المعالجة محاذاة (Aligned) عند حدود بايت معينة (عادةً 32 بايت أو 64 بايت).

فيما يلي مثال على تنفيذ ساحة ذاكرة في C++ يأخذ المحاذاة في الاعتبار:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


#include <cstdint>
#include <cstddef>
#include <stdexcept>
#include <iostream>

struct MemoryArena {
 size_t size;
 size_t offset;
 uint8_t* data;

 MemoryArena(size_t size) : size(size), offset(0) {
 // استخدم posix_memalign للأنظمة المتوافقة مع POSIX، و _aligned_malloc لنظام Windows
#ifdef _WIN32
 data = static_cast<uint8_t*>(_aligned_malloc(size, 64));
#else
 if (posix_memalign(reinterpret_cast<void**>(&data), 64, size) != 0) {
 throw std::bad_alloc();
 }
#endif
 }

 ~MemoryArena() {
#ifdef _WIN32
 _aligned_free(data);
#else
 free(data);
#endif
 }

 void* allocate(size_t bytes, size_t alignment = 64) {
 // حساب المحاذاة (إيجاد الحشو)
 size_t pad = (alignment - (offset % alignment)) % alignment;
 if (offset + pad + bytes > size) {
 throw std::runtime_error("OOM: MemoryArena out of memory");
 }
 offset += pad;
 void* ptr = data + offset;
 offset += bytes;
 return ptr;
 }

 void reset() {
 offset = 0; // تحرير الذاكرة يكون بمجرد إرجاع المؤشر للخلف (O(1))
 }
};

بهذه الطريقة، يتم دائمًا الحصول على الذاكرة من خلال هذه الساحة عند إنشاء الموترات. في كل مرة تنتهي فيها خطوة الاستدلال (مثلًا بعد كل توليد رمز)، يمكنك إعادة استخدام الذاكرة في لمح البصر عن طريق استدعاء reset().

4. سحر هيكل بيانات الموترات والخطوة (Stride)

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


enum class DataType {
 FP32,
 FP16,
 INT8, // للتكميم
 INT4 // للتكميم
};

struct Tensor {
 int n_dims; // عدد الأبعاد
 int64_t ne[4]; // عدد العناصر في كل بُعد (Number of Elements)
 size_t nb[4]; // الخطوة بالبايت لكل بُعد (Number of Bytes)
 DataType type; // نوع البيانات
 void* data; // مؤشر للبيانات

 // للرسم البياني الحسابي
 enum OpType op;
 Tensor* src0;
 Tensor* src1;
};

تمثل الخطوة nb[i] المسافة بالبايت في الذاكرة بين العناصر المتجاورة في البُعد i. على سبيل المثال، إذا كانت مصفوفة تحتوي على $M \times N$ عنصر (من نوع FP32، أي 4 بايت لكل عنصر) مخزنة بتنسيق أولوية الصفوف (Row-Major)، فستكون الخطوات كالتالي:

nb[0] = 4 (بايت) : الانتقال في اتجاه العمود
nb[1] = $N \times 4$ (بايت) : الانتقال في اتجاه الصف

باستخدام هذا المفهوم، يمكننا إجراء عمليات مثل “المنقول (Transpose)” أو “العرض (View)” ببساطة عن طريق التبديل بين قيم الخطوات دون الحاجة إلى نسخ الذاكرة. هذه طريقة أنيقة وسريعة جدًا.

5. بناء الرسم البياني الحسابي (DAG) والتقييم المؤجل

على غرار PyTorch وغيرها، سيعتمد محرك الاستدلال الخاص بنا على التقييم المؤجل (Lazy Evaluation). بمعنى آخر، عند استدعاء دالة عملية رياضية، لا يتم إجراء الحساب الفعلي حينها، بل يتم فقط بناء الرسم البياني (تبعيات العقد).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Tensor* tensor_add(MemoryArena& arena, Tensor* a, Tensor* b) {
 Tensor* out = create_tensor(arena, a->type, a->n_dims, a->ne);
 out->op = OpType::ADD;
 out->src0 = a;
 out->src1 = b;
 return out;
}

Tensor* tensor_mul_mat(MemoryArena& arena, Tensor* a, Tensor* b) {
 // b غالبًا ما تكون منقولة
 int64_t ne[2] = { a->ne[0], b->ne[1] };
 Tensor* out = create_tensor(arena, a->type, 2, ne);
 out->op = OpType::MUL_MAT;
 out->src0 = a;
 out->src1 = b;
 return out;
}

سيكون تدفق عملية الاستدلال على النحو التالي:

graph LR A["تعريف الموترات"] --> B["بناء الرسم البياني عبر العمليات"] B --> C["الفرز الطوبولوجي (Topological Sort)"] C --> D["تخصيص الذاكرة للمخرجات"] D --> E["تنفيذ العقد بالترتيب"]

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

6. جوهر الرياضيات والتحسين: ضرب المصفوفات (GEMM)

يتم استهلاك أكثر من 90% من العمليات الحسابية في استدلال الذكاء الاصطناعي في عمليات ضرب المصفوفات (GEMM: General Matrix Multiply). فآلية الانتباه والشبكات العصبية المتقدمة (FFN) التي تُعد جوهر نماذج Transformer، هي في الأساس عمليات ضرب لمصفوفات ضخمة.

حاصل ضرب $C = A B$ (بحجم $M \times N$) لمصفوفتين $A$ (بحجم $M \times K$) و $B$ (بحجم $K \times N$) يُعبر عنه رياضياً كالتالي:

$$ C_{i,j} = \sum_{k=0}^{K-1} A_{i,k} \cdot B_{k,j} $$

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

6.1 حظر ذاكرة التخزين المؤقت وتحسينات SIMD على وحدة المعالجة المركزية

تتلخص الإستراتيجية الأساسية لتسريع عملية GEMM على وحدة المعالجة المركزية في التالي:

تجانب الحلقات (Cache Blocking): تقسيم المصفوفات إلى كتل صغيرة تتناسب مع حجم ذاكرة التخزين المؤقت L1/L2 لتسهيل الحسابات.
تعبئة البيانات: إعادة ترتيب البيانات داخليًا بحيث تصبح أنماط الوصول إلى الذاكرة متسلسلة.
الاستفادة من SIMD: استخدام تعليمات FMA (الضرب والجمع المدمج) مثل _mm512_fmadd_ps في AVX-512 لتنفيذ العديد من عمليات الضرب والجمع في دورة ساعة واحدة.

إليك مثال مبسط لعملية الضرب النقطي للمتجهات باستخدام C++ و SIMD Intrinsics:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


#include <immintrin.h> // لتعليمات AVX

// الضرب النقطي السريع لـ FP32 باستخدام AVX2
float dot_product_avx2(const float* a, const float* b, int n) {
 __m256 sum256 = _mm256_setzero_ps();
 int i = 0;

 // معالجة 8 عناصر في المرة الواحدة (256 بت = 32 بايت = 8 * 4 بايت)
 for (; i <= n - 8; i += 8) {
 __m256 va = _mm256_loadu_ps(a + i);
 __m256 vb = _mm256_loadu_ps(b + i);
 // تعليمة FMA: sum256 = va * vb + sum256
 sum256 = _mm256_fmadd_ps(va, vb, sum256);
 }

 // الجمع الأفقي للقيم الموجودة في سجلات SIMD
 float result[8];
 _mm256_storeu_ps(result, sum256);
 float dot = result[0] + result[1] + result[2] + result[3] +
 result[4] + result[5] + result[6] + result[7];

 // معالجة الباقي
 for (; i < n; ++i) {
 dot += a[i] * b[i];
 }
 return dot;
}

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

7. تجاوز حدود الأجهزة: دمج واجهات CUDA و Metal

رغم أن تنفيذ C++ الخالص يعمل بشكل معقول على وحدة المعالجة المركزية، إلا أنه لتشغيل نماذج ضخمة مثل LLM بسرعة عملية، فإن قوة المعالجة المتوازية في وحدة المعالجة الرسومية (GPU) تعتبر ضرورية. لذلك، سنقدم طبقة تجريد للواجهات الخلفية في محركنا.

7.1 تجريد الواجهة الخلفية

باستخدام تعدد الأشكال في C++، يمكننا التبديل بين مُنفذي العمليات الحسابية (Executors).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


class Backend {
public:
 virtual ~Backend() = default;
 virtual void alloc_buffer(Tensor* t) = 0;
 virtual void free_buffer(Tensor* t) = 0;
 virtual void copy_to_device(Tensor* t) = 0;
 virtual void copy_to_host(Tensor* t) = 0;

 // تنفيذ العمليات المختلفة
 virtual void compute_add(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
 virtual void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
};

7.2 تنفيذ الواجهة الخلفية NVIDIA CUDA

للاستفادة من وحدات معالجة الرسوميات من NVIDIA، سنقوم بتنفيذ واجهة خلفية باستخدام امتدادات CUDA C++. من الممكن كتابة نواة خاصة بنا، ولكن فيما يتعلق بضرب المصفوفات، فإن استخدام “cuBLAS”، وهي أفضل مكتبة تقدمها NVIDIA، هو الحل الأمثل.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


#include <cublas_v2.h>
#include <cuda_runtime.h>

class CUDABackend : public Backend {
private:
 cublasHandle_t handle;

public:
 CUDABackend() {
 cublasCreate(&handle);
 }

 ~CUDABackend() {
 cublasDestroy(handle);
 }

 void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) override {
 // في CUDA، التنسيق الافتراضي هو العمود الأول (Column-Major)، لذا يجب الانتباه للمعلمات
 const float alpha = 1.0f;
 const float beta = 0.0f;

 int m = src0->ne[0];
 int k = src0->ne[1];
 int n = src1->ne[1]; // بافتراض أن src1 منقولة

 cublasSgemm(handle, CUBLAS_OP_T, CUBLAS_OP_N,
 m, n, k,
 &alpha,
 (const float*)src0->data, k,
 (const float*)src1->data, k,
 &beta,
 (float*)dst->data, m);
 cudaDeviceSynchronize();
 }
};

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

7.3 الواجهة الخلفية لـ Apple Silicon (Metal)

في السنوات الأخيرة، أثبتت شرائح M1/M2/M3 في أجهزة Mac كفاءتها العالية كأجهزة استدلال للذكاء الاصطناعي. والسبب في ذلك يعود إلى “الذاكرة الموحدة”. نظرًا لأن CPU و GPU يشتركان في نفس مساحة الذاكرة، فإننا نستغني تمامًا عن عمليات نقل الذاكرة المكلفة بين المضيف والجهاز عبر ناقل PCIe كما هو الحال في CUDA.

لاستدعاء Metal من C++، نستخدم Objective-C++ (ملفات .mm) كجسر أو نستخدم مكتبة metal-cpp. يتم كتابة النواة باستخدام Metal Compute Shader.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// تظليل Metal
#include <metal_stdlib>
using namespace metal;

kernel void mul_mat_kernel(
 device const float* A [[buffer(0)]],
 device const float* B [[buffer(1)]],
 device float* C [[buffer(2)]],
 constant uint3& dims [[buffer(3)]],
 uint2 gid [[thread_position_in_grid]]
) {
 uint m = dims.x; uint k = dims.y; uint n = dims.z;
 uint row = gid.y; uint col = gid.x;

 if (row < m && col < n) {
 float sum = 0.0;
 for (uint i = 0; i < k; ++i) {
 sum += A[row * k + i] * B[i * n + col]; // تبسيط
 }
 C[row * n + col] = sum;
 }
}

في بيئة Apple Silicon، تتوفر أيضًا مكتبة محسنة لعمليات ضرب المصفوفات تُسمى MPS. باستخدام هذه المكتبة، يمكننا تحقيق سرعات استدلال مذهلة.

8. المعالجات الخاصة بنماذج Transformer: الانتباه وذاكرة التخزين المؤقت KV

تعتمد أحدث نماذج LLM مثل LLaMA 2/3 و GPT على بنية Transformer. لتنفيذها في C++، من الضروري بناء خوارزمية الانتباه “Scaled Dot-Product Attention” الممثلة في المعادلة التالية:

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

بالإضافة إلى ذلك، في توليد الرموز ذاتي الانحدار، من الضروري الاحتفاظ بنتائج حسابات الرموز السابقة. هذا ما يُسمى “ذاكرة التخزين المؤقت KV”.

graph TD T["الرمز الحالي"] --> Q["الاستعلام (Query)"] T --> K["المفتاح (Key)"] T --> V["القيمة (Value)"] K --> KCache["إضافة إلى ذاكرة التخزين المؤقت KV"] V --> VCache["إضافة إلى ذاكرة التخزين المؤقت KV"] Q --> Dot1["Q * K_Cache^T"] KCache --> Dot1 Dot1 --> Scale["مقياس (1/sqrt(d))"] Scale --> Softmax["Softmax"] Softmax --> Dot2["SoftmaxOut * V_Cache"] VCache --> Dot2 Dot2 --> Out["متجه السياق"]

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

بالنسبة للتشفير الموضعي، سنقوم بتنفيذ “RoPE (Rotary Position Embedding)”. إنها طريقة لتضمين معلومات الموقع كمتجه دوران في مساحة معقدة. إن مفتاح الأداء هنا يكمن في تحسين استدعاء دوال sin و cos في C++.

9. التحسين الفائق من خلال تكميم النموذج (Quantization)

إذا تم تحميل نموذج ضخم (مثل نموذج LLaMA بـ 7 مليارات معلمة) بصيغة FP32، فسيستهلك حوالي 28 جيجابايت من الذاكرة (VRAM) للأوزان فقط. ومع إضافة ذاكرة التخزين المؤقت KV، يمكن أن يتجاوز بسهولة 30 جيجابايت، مما يجعله مستحيلاً للتشغيل على وحدات المعالجة الرسومية العادية.

لذلك، يصبح من الضروري استخدام تقنية “التكميم”. وهذا هو صميم وأهم ما يميز تنسيق GGML.

التكميم هو تقنية لتقليل دقة الأوزان عمدًا:

FP16 (16-bit): يقلل الحجم إلى النصف. مع عدم وجود انخفاض ملحوظ في الدقة.
INT8 (8-bit): يقلل الحجم إلى الربع. تدهور طفيف.
INT4 (4-bit): يقلل الحجم إلى الثُمن. باستخدام عوامل القياس والحجب الخاصة، يمكن إجراء استدلال عملي.

على جانب محرك الاستدلال، تُقرأ الأوزان المضغوطة بصيغة INT4 (أو INT8) من الذاكرة، ومباشرة بعد تحميلها في سجلات CPU أو GPU، يتم فك تكميمها (Dequantize) إلى FP16 أو FP32 لإجراء الحسابات.

بشكل يثير الدهشة، فإن تقليل كمية البيانات المقروءة من الذاكرة حتى لو أدى ذلك لزيادة العمليات الحسابية يجعل العملية أسرع. وذلك لأن عنق الزجاجة لمهام الاستدلال في الأجهزة الحديثة ليس في “قوة الحوسبة” بل في “عرض النطاق الترددي للذاكرة”. باستخدام محرك مبني بـ C++ ومكمم بتقنية INT4، يمكنك تشغيل نماذج LLM محليًا بسلاسة حتى على جهاز MacBook Air بذاكرة 8 جيجابايت.

10. ضبط الأداء: معمارية NUMA وتجمع الخيوط

عند إجراء الاستدلال باستخدام وحدة المعالجة المركزية، يكون تعدد الخيوط أمرًا ضروريًا. ومع ذلك، فإن مجرد بدء تشغيل العديد من std::thread لا يعتبر الحل الأمثل.

في الخوادم الحديثة أو معالجات سطح المكتب المتطورة، يتم اعتماد معمارية NUMA (Non-Uniform Memory Access). الوصول إلى الذاكرة القريبة ماديًا من نواة CPU محددة يكون سريعًا، في حين أن الوصول إلى ذاكرة مرتبطة بمعالج آخر يكون بطيئًا للغاية.

في محركات الاستدلال المتقدمة المكتوبة بـ C++، يتم استخدام التقنيات التالية:

تثبيت الخيوط (Thread Pinning): تثبيت كل خيط بنواة CPU معينة لمنع تدمير ذاكرة التخزين المؤقت الناتج عن تبديل السياق.
تخصيص مدرك لـ NUMA: تخصيص الذاكرة على نفس عقدة NUMA التي توجد بها الخيوط التي تعالج تلك البيانات.
تجمع خيوط لسرقة العمل (Work-Stealing): تقسيم كل عقدة في الرسم البياني الحسابي إلى مهام دقيقة، وتنفيذ مُجدوِل فعّال يسمح للخيوط الخاملة بسرقة المهام وتنفيذها تلقائيًا.

من خلال الاستفادة من هذه التقنيات، يمكننا إبقاء استخدام وحدة المعالجة المركزية قريبًا من 100%، وتحقيق إنتاجية قريبة من القيمة النظرية.

11. الخلاصة: متعة قيادة الذكاء الاصطناعي “بعضلات” C++

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

إن الشعور بالإنجاز عند رؤية محرك استدلال قمت ببنائه بنفسك من خلال معالجة متتاليات البايت في الذاكرة مباشرة، والضغط على السجلات إلى الحد الأقصى بتعليمات SIMD، والمصارعة مع عرض النطاق الترددي لـ VRAM، وهو يولد نصوصًا طبيعية على سطر الأوامر، هو “فرحة هندسية خالصة” لا يمكن أن تحصل عليها أبدًا بمجرد استدعاء model.generate() في أحد أطر عمل بايثون.

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

إذا كان لديك معرفة أساسية بـ C++ واهتمام قوي بتقنيات الذكاء الاصطناعي الحالية، فجرّب التحدي المتمثل في تطوير محرك الاستدلال الخاص بك. ستكون الأكواد المصدرية لمشاريع مثل GGML أو llama.cpp أفضل الكتب المدرسية الحية.

هيا بنا إذن، تخلص من بيئة تشغيل بايثون الثقيلة، ودعنا نُشغّل أحدث تقنيات الذكاء الاصطناعي مستخدمين عضلات C++!

دليل تطوير نماذج الذكاء الاصطناعي الصغيرة (مثل TinyLLaMA) باستخدام C++

Fri, 11 Sep 2026 14:00:00 +0900

دليل تطوير نماذج الذكاء الاصطناعي الصغيرة (مثل TinyLLaMA) باستخدام C++

في الآونة الأخيرة، ازداد الاهتمام بشكل سريع بتشغيل النماذج اللغوية الكبيرة (LLM) في البيئات المحلية. على وجه الخصوص، يمكن للنماذج الصغيرة مثل TinyLLaMA (بحجم 1.1 مليار معلمة) إجراء الاستدلال بسرعة عملية حتى على الأجهزة الطرفية ذات الموارد المحدودة أو أجهزة الكمبيوتر المحمولة العادية (بما في ذلك بيئات Windows). بينما يعتبر التطوير باستخدام Python و PyTorch هو السائد، إلا أنه عند السعي لتحقيق الأداء الأمثل وكفاءة الذاكرة، يصبح الجمع بين C++ ومكتبة التنسور “ggml” المعتمدة على لغة C هو المعيار الفعلي.

في هذا المقال، سنشرح خطوات تطوير مفصلة للغاية لبناء محرك استدلال من الصفر (أو فهم البنية الداخلية لـ llama.cpp الحالية بعمق) لتحميل TinyLLaMA وتوليد النصوص باستخدام C++.

1. لماذا C++ و ggml؟

في مرحلة تدريب الذكاء الاصطناعي، تتفوق Python بفضل مرونتها ونظامها البيئي الغني. ومع ذلك، في مرحلة النشر أو “الاستدلال (Inference)"، تصبح C++ خياراً قوياً للأسباب التالية:

تقليل النفقات العامة (Overhead): يمكن القضاء تماماً على قفل المترجم العالمي (GIL) والنفقات العامة لوقت التشغيل في Python.
كفاءة الذاكرة وتخصيص الساحة (Arena Allocation): نظراً لإمكانية التحكم اليدوي في تخصيص وتحرير الذاكرة، يمكن منع الزيادات غير المتوقعة الناتجة عن جمع القمامة (Garbage Collection).
الوصول المباشر إلى الأجهزة: استدعاء الوظائف المضمنة لـ SIMD (Intrinsics) مباشرة مثل AVX-512 و AVX2 و ARM NEON، مما يتيح استغلال قدرات الحوسبة لوحدة المعالجة المركزية إلى أقصى حد.
التخلص من التبعيات: ggml هي مكتبة C/C++ خالية من التبعيات (Zero dependencies)، ويمكن بناؤها بسهولة حتى في بيئة MSVC على Windows بمجرد توفر مترجم.

2. النظرة العامة على البنية

يوضح مخطط Mermaid التالي سير العمل في خط أنابيب الاستدلال بالكامل. إنها سلسلة من العمليات تبدأ من النص المدخل من قبل المستخدم وصولاً إلى توليد الرمز (Token) التالي.

graph TD A["نص إدخال المستخدم"] --> B["BPE Tokenizer"] B --> C["مصفوفة معرفات الرموز (Token IDs)"] C --> D["البحث في طبقة التضمين (Embedding Layer Lookup)"] D --> E["كتل المحول (Transformer Blocks)"] E --> F["RMSNorm"] F --> G["طبقة رأس LM (LM Head Layer)"] G --> H["مصفوفة اللوغاريتمات (Logits)"] H --> I["وحدة أخذ العينات (Sampler)"] I --> J["معرف الرمز التالي (Next Token ID)"] J --> K["Detokenizer"] K --> L["قطعة النص المخرجة"] J -.-> |"إضافة إلى السياق"| C

نظراً لأنه نموذج انحدار ذاتي (Autoregressive)، تتم إضافة الرموز المخرجة مرة أخرى إلى السياق، وتدور كمدخلات لتوقع الرمز التالي (الجزء المتقطع في المخطط).

3. تنسيق النموذج وتخطيط الذاكرة (mmap)

تعد القراءة/الكتابة على القرص واستهلاك الذاكرة العائق الأكبر عند التعامل مع أوزان الشبكات العصبية الضخمة. في تطبيقات C++، يتم حل ذلك باستخدام تخطيط الذاكرة (Memory Mapping - mmap).

3.1 كيفية عمل تخطيط الذاكرة وتطبيقه في Windows

باستخدام mmap، يمكن تعيين محتويات الملف مباشرة إلى مساحة الذاكرة الافتراضية للعملية.

نسخ صفري (Zero-copy): يتم تحميل البيانات مباشرة من القرص إلى ذاكرة التخزين المؤقت للصفحات في النواة (Kernel)، ولا يحدث نسخ إضافي إلى مساحة المستخدم.
التحميل عند الطلب (Page Fault): في اللحظة التي تصل فيها وحدة المعالجة المركزية فعلياً إلى عنوان الذاكرة ذلك، يحدث خطأ في الصفحة (Page Fault)، ويتم تحميل الكتلة المطلوبة فقط (عادة 4 كيلوبايت) في الذاكرة الفعلية.

في بيئة Windows، بدلاً من mmap الخاصة بـ POSIX، يتم استخدام واجهات برمجة تطبيقات Win32 CreateFileMapping و MapViewOfFile.

sequenceDiagram participant OS["نظام التشغيل Windows"] participant RAM["الذاكرة الفعلية (Physical Memory)"] participant App["تطبيق C++"] App->>OS: "CreateFileMapping / MapViewOfFile" OS-->>App: "مؤشر عنوان الذاكرة الافتراضية" App->>App: "قراءة بيانات التنسور عند المؤشر" OS->>RAM: "Page Fault / تحميل الصفحة من القرص" RAM-->>App: "البيانات جاهزة لحسابات SIMD"

3.2 البنية الثنائية لتنسيق GGUF

يعد GGUF (GPT-Generated Unified Format)، المحول من تنسيقات مثل .safetensors الخاصة بـ Hugging Face، التنسيق النهائي للاستدلال. يحتوي على المخطط الثنائي الصارم التالي:

البتات السحرية (Magic Bytes): 0x46554747 (GGUF).
الإصدار (Version): رقم إصدار التنسيق.
عدد التنسورات وعدد البيانات الوصفية (Tensor & Metadata Count): عدد التنسورات وأزواج المفتاح-القيمة للبيانات الوصفية.
البيانات الوصفية (Metadata): مفاتيح ببادئات طول السلسلة وقيم محددة النوع.
معلومات التنسور (Tensor Info): اسم كل تنسور، عدد الأبعاد، نوع البيانات (FP16، Q4_K، إلخ)، وموقع الإزاحة داخل الملف.
الحشو (Padding): حشوات مدرجة لمحاذاة بيانات التنسور مع حدود معينة (عادة 32 بايت أو 64 بايت). هذا ضروري للوصول السريع للذاكرة في تعليمات SIMD (وخاصة AVX).
بيانات التنسور (Tensor Data): مصفوفة بيانات الأوزان الفعلية المحاذاة.

4. الأساس الرياضي لـ TinyLLaMA وخوارزميات C++

يعتمد TinyLLaMA بعض الابتكارات المعمارية المتقدمة لزيادة الكفاءة. سنشرح التمثيلات الرياضية لتنفيذها بشكل صحيح في C++.

4.1 التقييس الجذري لمتوسط المربعات (RMSNorm)

يقلل التكلفة الحسابية عن طريق حذف مركزة المتوسط من LayerNorm وتنفيذ قياس التباين فقط.

$$ \text{RMSNorm}(x) = \frac{x}{\sqrt{\frac{1}{d}\sum_{i=1}^{d} x_i^2 + \epsilon}} \odot \gamma $$

حيث $d$ هو عدد الأبعاد، و $\gamma$ هو تنسور المقياس المُدرَّب. عند التنفيذ بـ C++، نقوم أولاً بحساب مجموع مربعات المصفوفة بسرعة باستخدام _mm256_fmadd_ps في AVX2، وتحسينه عن طريق ضربه بالجذر التربيعي العكسي (مثل تعليمة _mm256_rsqrt_ps).

4.2 التضمين الموضعي الدوار (RoPE)

هي تقنية لتطبيق معلومات موقع الرمز كدوران (Rotate) في مساحة التنسور. يمكن اعتبارها دوراناً على مستوى الأعداد المركبة، ويتم تطبيق الدوران التالي على الأزواج البعدية المتجاورة $(x_1, x_2)$ للمتجه $x$:

$$ \text{RoPE}(x, m) = \begin{pmatrix} x_{1} \cos(m\theta) - x_{2} \sin(m\theta) \\ x_{1} \sin(m\theta) + x_{2} \cos(m\theta) \end{pmatrix} $$

حيث $m$ هو المؤشر الموضعي المطلق للرمز، و $\theta$ هو التردد الأساسي المحسوب مسبقاً. في ggml، يتم تنفيذه بالتوازي ببساطة عن طريق إضافة عامل ggml_rope أثناء بناء رسم الاستدلال البياني.

4.3 الانتباه المجمع للاستعلام (Grouped-Query Attention - GQA)

في الانتباه متعدد الرؤوس (MHA) العادي، يوجد نفس عدد الرؤوس لكل من Query و Key و Value. ومع ذلك، لتقليل استهلاك عرض النطاق الترددي للذاكرة وذاكرة التخزين المؤقت KV بشكل كبير، يعتمد TinyLLaMA Grouped-Query Attention (GQA).

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{Q K^T}{\sqrt{d_k}}\right) V $$

في GQA، تشترك عدة رؤوس Query في رأس Key/Value واحد. في تطبيق C++، قبل إجراء ضرب المصفوفات ggml_mul_mat، من الضروري إجراء عملية بث (Broadcast) لتنسورات KV لتتناسب مع عدد Query.

4.4 دالة التنشيط SwiGLU

في طبقة الشبكة المغذية للأمام (FFN)، يتم استخدام SwiGLU بدلاً من GELU.

$$ \text{SwiGLU}(x) = \text{Swish}(x W_{\text{gate}}) \otimes (x W_{\text{up}}) $$ $$ \text{Swish}(z) = z \cdot \sigma(z) = z \cdot \frac{1}{1 + e^{-z}} $$

يتم تمثيله في الرسم البياني الحسابي بدمج عاملي ggml_silu و ggml_mul.

5. بناء الرسم البياني الحسابي وإدارة الذاكرة باستخدام ggml

تعتمد ggml نهج “التحديد والتنفيذ (Define-and-Run)"، حيث تقوم ببناء رسم بياني حسابي ثابت للاستدلال ثم تقييمه (evaluate) لاحقاً.

5.1 ggml_context ومخصص الساحة (Arena Allocator)

الميزة الأكثر تميزاً في ggml هي “تخصيص الساحة”، الذي لا ينفذ أي تخصيص ديناميكي للذاكرة (malloc أو new) داخل حلقة الاستدلال. يتم تخصيص منطقة ذاكرة متصلة ضخمة (الساحة) عند التهيئة، وفي كل مرة يتم فيها استدعاء ggml_new_tensor وغيره، يزداد مؤشر هذه المنطقة. عند اكتمال خطوة استدلال واحدة، يتم فقط إعادة تعيين مؤشر التخصيص إلى الموضع الأولي، وبذلك يكتمل تخصيص الذاكرة لخطوة الاستدلال التالية على الفور.

5.2 مثال عملي لبناء الرسم البياني

في كل خطوة استدلال، يتم تجميع الرسم البياني الحسابي التالي في الذاكرة.

graph TD A["معرف رمز الإدخال (Tokens Input ID)"] --> B["البحث عن التضمين (Embed Lookup)"] B --> C["ggml_rms_norm"] C --> D["إسقاطات Q / K / V"] D --> E["ggml_rope Positional"] E --> F["حفظ في KV Cache"] E --> G["تحميل من KV Cache"] G --> H["الانتباه الذاتي (Self Attention)"] H --> I["المقياس و Softmax"] I --> J["مخرجات الانتباه (Attention Output)"] J --> K["الإسقاط الخارجي (Out Projection)"] K --> L["إضافة المتبقي (Add Residual)"]

6. التكميم (Quantization) وتحسين Windows / SIMD

يتطلب التعامل مع TinyLLaMA (1.1B) بصيغة FP16 حوالي 2.2 جيجابايت من الذاكرة، ولكن باستخدام تكميم 4-بت (مثل Q4_K) يمكن ضغطه بشكل كبير إلى حوالي 600 ميجابايت.

6.1 بنية التكميم الكتلي (Block Quantization)

لا تقوم ggml بتكميم التنسور بأكمله بشكل موحد، بل يتم ذلك على أساس “الكتلة”. في تنسيق Q4_0، يتم تجميع 32 قيمة FP16 في كتلة واحدة.

عامل المقياس (Scale Factor): قيمة واحدة FP16 (2 بايت)
البيانات المكممة: 32 قيمة 4-بت (16 بايت) هذا يقلل من تأثير القيم المتطرفة المحلية.

6.2 تسريع الضرب النقطي باستخدام AVX2

عند البناء لأحدث وحدات المعالجة المركزية x86 في بيئة Windows، مع الاستفادة من علامات المترجم مثل /arch:AVX2، تتم معالجة SIMD عبر التدفق التالي:

التحميل (Load): تحميل بيانات التكميم 4-بت من الذاكرة إلى سجلات AVX بحجم 256 بت.
التوسيع وفك الحزم (Unpack): استخدام أقنعة البت (Bitmasks) وعمليات الإزاحة لتوسيع قيم 4-بت إلى Int8 أو Int16.
إلغاء التكميم (Dequantize): الضرب في عامل المقياس للتحويل إلى فاصلة عائمة.
عمليات FMA: تنفيذ عمليات الضرب والجمع بالتوازي على قيم التنشيط باستخدام _mm256_fmadd_ps (Fused Multiply-Add).

7. تفاصيل تنفيذ ذاكرة التخزين المؤقت KV (KV Cache)

في التوليد التلقائي الانحداري، تعد “ذاكرة التخزين المؤقت KV” لتجاوز حسابات Key و Value للرموز السابقة ميزة أساسية.

فيما يلي النقاط الرئيسية عند تنفيذ ذلك بـ C++:

التخصيص المسبق للتنسور: تهيئة تنسور ضخم لذاكرة التخزين المؤقت KV بحجم الحد الأقصى لطول السياق (مثال: 2048 رمزاً) (يُفضل FP16).
نسخ الإزاحة (Offset Copy): عند الحساب للموضع الرمزي $N$، يتم تخزين متجهات K و V الناتجة في تلك الخطوة في الصف $N$ من تنسور التخزين المؤقت KV باستخدام دوال مثل ggml_cpy.
إنشاء مشهد (View) أثناء الانتباه: عند حساب الانتباه، يتم تمرير “مشهد” يشير فقط إلى أجزاء الرموز من 0 إلى $N$ لضرب المصفوفات.

8. BPE Tokenizer وفك التشفير (Decoding)

تتم معالجة السلسلة المدخلة كتسلسل بايتات UTF-8 وتتم مطابقتها مع مفردات محددة مسبقاً. في C++، لتسريع البحث في المفردات، يتم تنفيذ خوارزميات مثل شجرة البادئة (Trie Tree) أو قوائم الانتظار ذات الأولوية.

من سجلات Logits الناتجة عن LM Head، يتم قياس الاحتمالات باستخدام معلمة درجة الحرارة (Temperature)، ويتم تضييق المرشحين باستخدام استخراج Top-K أو أساليب Top-P (Nucleus Sampling)، ويتم تحديد الرمز التالي النهائي باستخدام أرقام عشوائية.

9. إعداد مشروع C++ (بيئة Windows / PowerShell)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


cmake_minimum_required(VERSION 3.14)
project(TinyLLaMACpp)

set(CMAKE_CXX_STANDARD 17)

# إعدادات التحسين وعلامات AVX2 لـ Windows (MSVC)
if(MSVC)
 add_compile_options(/O2 /arch:AVX2 /fp:fast)
 add_link_options(/STACK:8388608)
else()
 add_compile_options(-O3 -march=native -ffast-math)
endif()

add_library(ggml OBJECT ggml/ggml.c ggml/ggml-alloc.c)
target_compile_definitions(ggml PRIVATE GGML_USE_AVX2 GGML_USE_F16C GGML_USE_FMA)

add_executable(main main.cpp)
target_link_libraries(main ggml)

مثال لأمر البناء في PowerShell:

1
2
3
4


mkdir build
cd build
cmake .. -G "Visual Studio 17 2022" -A x64
cmake --build . --config Release

10. الخلاصة

يعد تنفيذ محرك استدلال لنموذج ذكاء اصطناعي صغير مثل TinyLLaMA من الصفر باستخدام C++ و ggml فرصة رائعة لكشف الصندوق الأسود للتعلم العميق وتعلم جمال التحكم في الأجهزة منخفضة المستوى. باستخدام التحميل بنسخ صفري المعتمد على تخطيط الذاكرة، وتحسينات SIMD، وبناء ذاكرة التخزين المؤقت KV، دعونا نفتح آفاقاً جديدة لمستقبل الذكاء الاصطناعي الطرفي (Edge AI) بينما نستمتع بجوهر برمجة الأنظمة.

استخدام llama.cpp ومقدمة في التخصيص باستخدام C++

Fri, 11 Sep 2026 11:00:00 +0900

في السنوات الأخيرة، كان تطور النماذج اللغوية الكبيرة (LLMs) مذهلاً، ويتوسع نطاق تطبيقاتها يومًا بعد يوم. ومع ذلك، فإن تشغيل النماذج التي تحتوي على مليارات أو عشرات المليارات من المعلمات في بيئة محلية يتطلب عادةً وحدات معالجة رسومية (GPUs) متطورة مع ذاكرة VRAM ضخمة. لقد حطم llama.cpp “حاجز الأجهزة” هذا، مما أتاح استنتاجًا عمليًا لـ LLM على أجهزة الكمبيوتر الشخصية وأجهزة Mac العادية، وحتى أجهزة مثل Raspberry Pi.

في هذه المقالة، لن نقتصر على شرح كيفية استخدام أداة سطر الأوامر فقط، بل سنقدم شرحًا مفصلاً جدًا للمهندسين حول التكنولوجيا الأساسية لها، معمارية ggml، والخلفية الرياضية لـ Transformer والتكميم (Quantization)، وكيفية استخدام واجهة برمجة تطبيقات C++ لدمج وتخصيص LLM في تطبيقاتك الخاصة.

1. نظرة عامة على llama.cpp و ggml

llama.cpp هو محرك استنتاج LLM خفيف الوزن مكتوب بلغة C/C++، تم تطويره بواسطة Georgi Gerganov. في البداية، تم إنشاؤه بغرض تشغيل نماذج LLaMA من Meta بسرعات عالية على Apple Silicon (M1/M2 Mac)، ولكنه يدعم الآن مجموعة متنوعة من المعماريات والنماذج.

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

قلب llama.cpp هو مكتبة عمليات الموترات (Tensor) ggml. تم تصميم ggml من الصفر لتحسين عمليات المصفوفات في التعلم الآلي إلى أقصى حد على وحدات المعالجة المركزية (CPU) (وبعض وحدات المعالجة الرسومية GPU).

1.1 لماذا llama.cpp سريع؟

الاستفادة من تعيين الذاكرة (mmap): عند تحميل أوزان النموذج في الذاكرة، يؤدي استخدام mmap الخاص بنظام التشغيل إلى تجنب التحميل الكامل في ذاكرة الوصول العشوائي (RAM)، مما يحقق بدء تشغيل سريع وتوفيرًا للذاكرة.
التحسين الشامل لتعليمات SIMD: يستفيد من مجموعات التعليمات الخاصة بوحدة المعالجة المركزية مثل AVX2 و AVX-512 و ARM NEON و Apple AMX لتسريع ضرب المصفوفات بشكل كبير.
التكميم (Quantization): يضغط الأوزان ذات النقطة العائمة 16 بت (FP16) إلى أعداد صحيحة 4 بت، 5 بت، و 8 بت، مما يزيل اختناق عرض النطاق الترددي للذاكرة (سيتم تفصيل ذلك لاحقًا).

2. الخلفية الرياضية: Transformer والتكميم (Quantization)

لفهم llama.cpp بعمق، يجب أن تعرف الصيغ الرياضية التي يحسبها وكيف يقارب العمليات الحسابية.

2.1 عملية الاستنتاج في Transformer

تعتمد نماذج مثل LLaMA على معمارية Transformer Decoder ذاتية الانحدار (Auto-regressive). جوهر توليد النص هو آلية Self-Attention.

بالنسبة لمصفوفة الحالة المخفية المدخلة $X \in \mathbb{R}^{N \times d}$، يتم حساب الاستعلام (Query) $Q$ والمفتاح (Key) $K$ والقيمة (Value) $V$ من خلال الضرب مع مصفوفات الأوزان.

$$ Q = X W_Q, \quad K = X W_K, \quad V = X W_V $$

هنا، يُعرَّف ناتج Attention على النحو التالي:

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

في حلقة استنتاج llama.cpp، يكمن عنق الزجاجة في ضرب مصفوفات الأوزان الضخمة هذه $W_Q, W_K, W_V$ ومصفوفات أوزان شبكة التغذية الأمامية (FFN) مع المتجه $X$ (في مرحلة التوليد $N=1$ لأنه يعالج رمزًا مميزًا (token) واحدًا في كل مرة)، أي GEMV (General Matrix-Vector Multiplication).

2.2 الأساس الرياضي للتكميم (Quantization)

في الاستنتاج حيث يكون النطاق الترددي للوصول إلى الذاكرة هو عنق الزجاجة، فإن التكميم، الذي يمثل معلمات الوزن بعدد صغير من البتات، أمر لا غنى عنه. سنشرح المبدأ الأساسي للتكميم المعتمد على الكتل (مثل Q4_K أو Q4_0) المستخدم على نطاق واسع في llama.cpp.

على سبيل المثال، لنفترض كتلة $w = [w_1, w_2, \dots, w_B]$ بطول $B$ (عادةً 32 أو 64) وهي جزء من مصفوفة أوزان FP16 المسماة $W$. تُقارب هذه الكتلة إلى أعداد صحيحة 4 بت $q_i \in [-8, 7]$ وعامل مقياس (scaling factor) واحد $\Delta$ (إما FP16 أو FP32).

$$ w_i \approx \Delta \times q_i $$

يتم تحديد $\Delta$ بناءً على القيمة المطلقة القصوى داخل الكتلة.

$$ \Delta = \frac{\max_i |w_i|}{7} $$

عند حساب حاصل الضرب النقطي $y = w \cdot x$ باستخدام الأوزان المكممة، إذا قمنا أيضًا بتكميم متجه الإدخال $x$ ليصبح $x_i \approx \Delta_x \times q_{x, i}$، فإن:

$$ y = \sum_{i=1}^{B} w_i x_i \approx \Delta \Delta_x \sum_{i=1}^{B} q_i q_{x, i} $$

الجزء الخاص بـ $\sum q_i q_{x, i}$ هو عبارة عن عملية أعداد صحيحة نقية، ويمكن حسابه بالتوازي بسرعة عالية جدًا باستخدام تعليمات SIMD. هذا هو السر الرياضي وراء السرعات المذهلة التي يحققها llama.cpp على وحدة المعالجة المركزية (CPU).

3. المعمارية وتدفق الاستنتاج

لفهم الأعمال الداخلية لـ llama.cpp، يُظهر مخطط Mermaid التالي بنية النظام بأكمله وتدفق البيانات.

graph TD A["إدخال المستخدم (نص)"] --> B["مجزئ llama.cpp (Tokenizer)"] B --> C["معرفات الرموز (مصفوفة int32)"] C --> D["المخزن المؤقت للسياق (KV Cache)"] D --> E["رسم بياني حسابي ggml"] E --> F["طبقات Transformer"] subgraph "محرك ggml" F --> G["الانتباه الذاتي (RoPE)"] G --> H["شبكة التغذية الأمامية (FFN)"] H --> F end F --> I["الاحتمالات (Logits - حجم المفردات)"] I --> J["مُصنف العينات (Temperature, Top-K, Top-P)"] J --> K["معرف الرمز المحدد"] K --> L["مُجمّع النصوص llama.cpp (Detokenizer)"] L --> M["النص الناتج"] K -. "حلقة ذاتية الانحدار" .-> D

توليد النص هو حلقة ذاتية الانحدار حيث أنه في كل مرة يتم فيها إخراج رمز مميز (Token) واحد، تتم إضافته إلى ذاكرة التخزين المؤقت KV كإدخال تالٍ ويمر عبر الرسم البياني الحسابي مرة أخرى.

4. إعداد البيئة وطريقة البناء

قبل دمج llama.cpp في مشاريع C++، دعنا نقوم أولاً ببناء الكود المصدري.

4.1 استنساخ المستودع

1
2


git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp

4.2 البناء باستخدام CMake

إذا كنت تريد دمجه في تطبيقات أخرى كمشروع C++، فإن استخدام CMake هو الأكثر معيارية. من خلال تمكين المسرع (backend) الخاص بكل منصة، يمكنك تسريع العمليات الحسابية.

وحدة المعالجة المركزية (CPU) فقط (بناء أساسي):

1
2
3


mkdir build && cd build
cmake ..
cmake --build . --config Release -j 8

في حالة استخدام وحدة معالجة رسومية NVIDIA GPU (CUDA):

1
2
3


mkdir build && cd build
cmake .. -DGGML_CUDA=ON
cmake --build . --config Release -j 8

في حالة استخدام Apple Silicon (Metal):

1
2
3


mkdir build && cd build
cmake .. -DGGML_METAL=ON
cmake --build . --config Release -j 8

إذا نجح البناء، فسيتم إنشاء ملفات تنفيذية مثل llama-cli في الدليل build/bin/، ومكتبة llama (وكذلك مكتبة ggml) لربطها عبر واجهة برمجة تطبيقات C++ الموضحة أدناه.

5. مقدمة في التخصيص باستخدام C++: استخدام واجهة برمجة تطبيقات llama.cpp

من هنا، سنشرح الموضوع الرئيسي وهو كيفية التحكم في llama.cpp من كود C++. لدمج LLM في تطبيقاتك الخاصة (مثل محركات الألعاب، تطبيقات سطح المكتب، الأنظمة المدمجة، إلخ) بدلاً من استخدام أداة سطر الأوامر فقط، ستحتاج إلى التفاعل مع واجهة برمجة تطبيقات C++ مباشرةً.

يوفر llama.cpp واجهة برمجة بلغة C بشكل أساسي من خلال ملف الرأس llama.h. حتى عند الاستدعاء من C++، يتم استخدام هذه الواجهة.

5.1 الحد الأدنى من التضمينات (Includes) والإعدادات

عند استخدام llama.cpp في مشروعك، قم بتضمين ما يلي:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


#include "llama.h"
#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>

// ماكرو لمعالجة الأخطاء
#define LLAMA_ASSERT(x) \
 do { \
 if (!(x)) { \
 std::cerr << "Assertion failed: " << #x << std::endl; \
 std::terminate(); \
 } \
 } while (0)

5.2 تحميل النموذج وتهيئة السياق

أولاً، نقوم بتحميل ملف النموذج بصيغة .gguf ونخصص السياق (مساحة الذاكرة و KV Cache) للاستنتاج.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


int main(int argc, char ** argv) {
 if (argc < 2) {
 std::cerr << "Usage: " << argv[0] << " <model.gguf>" << std::endl;
 return 1;
 }
 std::string model_path = argv[1];

 // 1. تهيئة الواجهة الخلفية (إعداد بيئة CPU/GPU وغيرها)
 llama_backend_init();

 // 2. الحصول على الإعدادات الافتراضية لمعلمات النموذج
 llama_model_params model_params = llama_model_default_params();
 model_params.n_gpu_layers = 35; // عدد الطبقات التي يتم تفريغها إلى وحدة المعالجة الرسومية (GPU)

 // 3. تحميل النموذج
 llama_model * model = llama_load_model_from_file(model_path.c_str(), model_params);
 if (model == nullptr) {
 std::cerr << "Failed to load model" << std::endl;
 return 1;
 }

 // 4. إعداد معلمات السياق
 llama_context_params ctx_params = llama_context_default_params();
 ctx_params.n_ctx = 2048; // الحد الأقصى لحجم السياق (عدد الرموز)
 ctx_params.n_threads = 8; // عدد خيوط وحدة المعالجة المركزية (CPU threads) المستخدمة في الاستنتاج

 // 5. إنشاء السياق
 llama_context * ctx = llama_new_context_with_model(model, ctx_params);
 if (ctx == nullptr) {
 std::cerr << "Failed to create context" << std::endl;
 llama_free_model(model);
 return 1;
 }

 std::cout << "Model and context loaded successfully!" << std::endl;
 // ... العمليات اللاحقة

5.3 تقطيع النص الموجه إلى رموز (Tokenization)

لا تفهم نماذج LLM النصوص مباشرة، بل تعالجها كسلسلة من المعرفات الصحيحة (الرموز). يجب تحويل سلسلة الإدخال إلى رموز.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


 std::string prompt = "Q: ما هي عاصمة اليابان؟\nA:";
 std::vector<llama_token> tokens_list;
 tokens_list.resize(prompt.length() + 4); // حجم ذاكرة تخزين مؤقت به مساحة كافية

 // ما إذا كان سيتم إضافة رموز خاصة (مثل BOS: Begin of Sequence) في البداية
 bool add_special = true;
 // تحويل السلسلة النصية إلى مصفوفة معرفات الرموز (Token IDs)
 int n_tokens = llama_tokenize(
 model,
 prompt.c_str(),
 prompt.length(),
 tokens_list.data(),
 tokens_list.size(),
 add_special,
 false // parse_special
 );

 if (n_tokens < 0) {
 // إذا كان المخزن المؤقت غير كافٍ، يجب إعادة تخصيصه وإعادة المحاولة (تم الحذف للتبسيط)
 std::cerr << "Failed to tokenize prompt" << std::endl;
 return 1;
 }
 tokens_list.resize(n_tokens);

5.4 حلقة الاستنتاج وأخذ العينات

تقوم بتمرير الرموز إلى النموذج، والحصول على التوزيع الاحتمالي للرمز التالي (Logits)، ثم إنشاء حلقة لأخذ عينات من تلك الاحتمالات لتحديد الرمز التالي.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72


 // الحد الأقصى لعدد الرموز المراد توليدها
 const int max_gen_tokens = 100;

 // تهيئة الهيكل (struct) لتقييم الدُفعات (Batch evaluation)
 llama_batch batch = llama_batch_init(512, 0, 1);

 // إضافة رموز المُوجّه إلى الدُفعة
 for (size_t i = 0; i < tokens_list.size(); i++) {
 llama_batch_add(batch, tokens_list[i], i, { 0 }, false);
 }
 // إعداد لإخراج الاحتمالات (Logits - نتائج التوقع) فقط في الرمز الأخير من المُوجّه
 batch.logits[batch.n_tokens - 1] = true;

 // التقييم الأول (إطعام المُوجّه للنموذج)
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "llama_decode() failed" << std::endl;
 return 1;
 }

 int n_cur = batch.n_tokens; // طول السياق الحالي
 int n_decode = 0;

 std::cout << "\nOutput: ";

 // تهيئة سياق أخذ العينات (إعدادات Temperature, Top-K, Top-P وما إلى ذلك)
 llama_sampler * smpl = llama_sampler_chain_init(llama_sampler_chain_default_params());
 llama_sampler_chain_add_top_k(smpl, 40);
 llama_sampler_chain_add_top_p(smpl, 0.9f, 1);
 llama_sampler_chain_add_temp(smpl, 0.7f);
 llama_sampler_chain_add_dist(smpl, 1234); // قيمة البذرة (Seed)

 while (n_decode < max_gen_tokens) {
 // 1. أخذ العينات: توقع الرمز التالي بناءً على السياق الحالي
 llama_token new_token_id = llama_sampler_sample(smpl, ctx, -1);

 // 2. إنهاء الحلقة إذا كان الرمز هو EOS (End of Sequence)
 if (llama_token_is_eog(model, new_token_id)) {
 break;
 }

 // 3. فك تشفير الرمز إلى سلسلة نصية (نص) وعرضها
 char buf[128];
 int n_chars = llama_token_to_piece(model, new_token_id, buf, sizeof(buf), 0, false);
 if (n_chars > 0) {
 std::cout << std::string(buf, n_chars) << std::flush;
 }

 // 4. إعداد الرمز المولد حديثًا كدُفعة تالية
 llama_batch_clear(batch);
 llama_batch_add(batch, new_token_id, n_cur, { 0 }, true);

 // 5. تقييم النموذج (تحديث ذاكرة التخزين المؤقت KV وتوقع التالي)
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "Failed to evaluate" << std::endl;
 break;
 }

 n_cur += 1;
 n_decode += 1;
 }

 std::cout << std::endl;

 // التنظيف (Cleanup)
 llama_sampler_free(smpl);
 llama_batch_free(batch);
 llama_free(ctx);
 llama_free_model(model);
 llama_backend_free();

 return 0;
}

يقوم هذا الكود بتنفيذ حلقة استنتاج مخصصة باستخدام واجهة برمجة التطبيقات الأساسية لـ llama.cpp. تتم إدارة مجموعة الرموز باستخدام هيكل llama_batch، ويتم تنفيذ التمرير الأمامي (الانتشار الأمامي) للشبكة العصبية بـ llama_decode.

6. دراسة حالة التخصيص المتقدم: معالجة Logits والتحكم في العقوبات (Penalty) عبر C++

بالإضافة إلى التوليد البسيط للنص، عندما تريد فرض إخراج بتنسيق معين (مثل JSON فقط)، أو التحكم لمنع إخراج كلمات محظورة معينة، يمكنك التحكم مباشرة في الاحتمالات الأولية (Logits) قبل أخذ العينات من جانب C++.

يمكنك الحصول على مصفوفة النتائج الخام (القيم قبل تحويلها إلى احتمالات) مباشرة قبل أن يخرج النموذج كل رمز.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// الحصول على مصفوفة Logits الخام بعد الاستنتاج مباشرة، وقبل أخذ العينات
float * logits = llama_get_logits_ith(ctx, batch.n_tokens - 1);
int n_vocab = llama_n_vocab(model);

// قائمة بمعرفات الرموز المحظورة (على سبيل المثال 1234، 5678)
std::vector<llama_token> forbidden_tokens = { 1234, 5678 };

// تعيين احتمال ظهور الرموز المحظورة إلى 0 (جعل Logit سالب ما لا نهاية)
for (llama_token bad_tok : forbidden_tokens) {
 logits[bad_tok] = -INFINITY;
}

بهذه الطريقة، من خلال التعامل المباشر مع واجهة برمجة تطبيقات C++، يصبح “التدخل على مستوى الميكروثانية والملي ثانية لكل دورة استنتاج” ممكنًا، وهو أمر صعب التحقيق أو يتطلب عبئًا كبيرًا (Overhead) عند القيام به من خلال LangChain أو Python.

7. أسرار ضبط الأداء

فيما يلي بعض نقاط التحقق لزيادة السرعة إلى أقصى حد للتشغيل الفعلي بعد الانتهاء من التنفيذ في C++.

تحسين معالجة الدفعات: عند معالجة طلبات من عدة مستخدمين في نفس الوقت، يمكنك تضمين عدة تسلسلات في llama_batch واستدعاء llama_decode مرة واحدة (Continuous Batching). يتيح ذلك مشاركة الوصول إلى الذاكرة وتحسين الإنتاجية (Throughput) بشكل كبير.
تفعيل Flash Attention: من خلال تعيين ctx_params.flash_attn = true; في معلمات السياق، يمكنك تقليل استخدام الذاكرة مع تسريع حسابات Attention. هذا الإعداد ضروري عند التعامل مع سياقات طويلة (عشرات الآلاف من الرموز).
دعم NUMA: في بيئات الخوادم متعددة المقابس (Multi-socket)، من خلال تكوين إعدادات NUMA بشكل صحيح قبل llama_backend_init()، يمكنك تقليل وقت استجابة الوصول إلى الذاكرة (Latency).

8. خاتمة

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

في حين أن النظام البيئي لـ Python ملائم للغاية للنماذج الأولية (Prototyping)، إلا أن التحكم المباشر عبر llama.cpp القائم على C/C++ يُظهر قوة ساحقة في بيئات الإنتاج التي تتطلب النشر على الأجهزة الطرفية (Edge devices)، والدمج في الألعاب، والمعالجة في الوقت الفعلي.

نشجعك على كتابة كود C++ بيدك وتجربة متعة التحكم بحرية في LLM في بيئتك المحلية.

مجموعة الروابط المرجعية

المستودع الرسمي llama.cpp

ggml - مكتبة Tensor

Attention Is All You Need (Vaswani et al., 2017)