LLM on kenji.blog

كيفية ضبط TinyLLaMA بأسرع طريقة في بيئة محلية

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

1. مقدمة: لماذا TinyLLaMA والبيئة المحلية الآن؟

يتقدم تطور النماذج اللغوية الكبيرة (LLMs) بسرعة هائلة، ومع ذلك يستمر عدد معلمات النماذج (Parameters) في التضخم ليصل إلى مئات المليارات. في حين أن النماذج الضخمة مثل GPT-4 و Claude 3 تتمتع بأداء لا مثيل له، إلا أن التكلفة الحسابية اللازمة للاستنتاج (Inference) والتدريب، بالإضافة إلى المخاوف المتعلقة بالأمان وخصوصية البيانات عند استخدام واجهات برمجة التطبيقات (APIs) الخارجية، تشكل عقبات كبيرة للشركات. خاصة في الأعمال التي تتعامل مع بيانات داخلية سرية للغاية أو معلومات شخصية، فإن إرسال البيانات إلى واجهات برمجة تطبيقات LLM عامة على السحابة (Cloud) غالباً ما يكون غير مقبول من منظور الامتثال (مثل GDPR و APPI).

لذلك، تتجه الأنظار نحو النماذج اللغوية الصغيرة (SLM: Small Language Models) و التشغيل المحلي في بيئات محلية (On-premises). من بينها، يتميز “TinyLLaMA” بحجمه المدمج الذي يبلغ 1.1 مليار معلمة فقط (1.1B)، إلا أنه تم تدريبه مسبقًا على مجموعة بيانات ضخمة تبلغ حوالي 3 تريليون رمز (Tokens)، مما يجعله يظهر أداءً مذهلاً مقارنة بالنماذج من نفس الفئة.

في هذا المقال، سنقدم دليلاً كاملاً للضبط الدقيق (Fine-tuning) لـ TinyLLaMA في بيئة محلية (خادم محلي أو محطة عمل) للمهام الخاصة بشركتك، بـ “أسرع وأعلى كفاءة”. سنشرح كل شيء بشمولية، بدءًا من الخلفية الرياضية وتقنيات التحسين الحديثة، وصولاً إلى أكواد التنفيذ الفعلية باستخدام PyTorch.

2. بنية TinyLLaMA وخصائصه

يعتمد TinyLLaMA على بنية LLaMA (Large Language Model Meta AI) التي طورتها شركة Meta. على الرغم من إبقاء عدد المعلمات عند 1.1B، إلا أنه يستخدم نفس حزمة التقنيات المستخدمة في LLaMA 2، مما يتميز بتوافق عالٍ جداً مع النظام البيئي.

مكونات البنية الأساسية

RMSNorm (Root Mean Square Normalization): تقنية تطبيع (Normalization) تعمل على تحسين الكفاءة الحسابية عن طريق حذف طرح المتوسط من حسابات LayerNorm التقليدية. إنها تزيد من الإنتاجية مع الحفاظ على استقرار التدريب.
دالة التنشيط SwiGLU: في شبكة التغذية الأمامية (Feed Forward Network - FFN)، يتم استخدام SwiGLU بدلاً من ReLU أو GELU التقليدية. يتم التعبير عن هذا رياضياً على النحو التالي: $$ \text{SwiGLU}(x, W, V) = \text{Swish}(xW) \otimes (xV) $$ هنا، يمثل $\otimes$ الضرب على مستوى العناصر (Hadamard product)، ودالة Swish هي $\text{Swish}(z) = z \cdot \sigma(\beta z)$. هذا يحسن من القدرة التعبيرية بشكل كبير.
RoPE (Rotary Position Embedding): طريقة تجمع بين مزايا التضمين الموضعي المطلق (Absolute position encoding) والنسبي (Relative position encoding). تتمتع بأداء تعميمي عالٍ حتى عند تمديد طول التسلسل.
Grouped Query Attention (GQA): نهج وسط بين Multi-Head Attention (MHA) و Multi-Query Attention (MQA)، ومن خلال تجميع رؤوس المفاتيح (Keys) والقيم (Values)، فإنه يوفر عرض النطاق الترددي للذاكرة ويزيد من سرعة الاستنتاج بشكل كبير.

يوضح مخطط Mermaid أدناه تدفق البيانات العام لـ TinyLLaMA وبنية كتلة المحول (Transformer block).

graph TD A["النص المدخل"] --> B["المرمز (BPE)"] B --> C["طبقة التضمين"] C --> D["كتل المحول (22 طبقة لـ TinyLLaMA)"] D --> E["RMSNorm (نهائي)"] E --> F["الإسقاط الخطي (حجم المفردات)"] F --> G["احتمالات المخرجات (Softmax)"] subgraph "تشريح كتلة المحول" D1["حالة الإخفاء المدخلة"] --> D2["RMSNorm"] D2 --> D3["انتباه الاستعلام المجمع (GQA)"] D3 --> D4["إضافة متبقية"] D4 --> D5["RMSNorm"] D5 --> D6["SwiGLU FFN"] D6 --> D7["إضافة متبقية"] D7 --> D8["المخرجات للطبقة التالية"] D1 -.-> D4 D4 -.-> D7 end

3. اختراق في الضبط الدقيق: LoRA و QLoRA

لإجراء ضبط دقيق كامل المعلمات (Full parameter fine-tuning) في بيئة محلية، حتى بالنسبة لنموذج 1.1B، فإنه يستهلك عشرات الجيجابايت من ذاكرة VRAM (ذاكرة الفيديو) للاحتفاظ بحالة المحسن (Optimizer) والتدرجات (Gradients). لتحقيق تدريب فعال بموارد محدودة، من الضروري استخدام طريقة PEFT (Parameter-Efficient Fine-Tuning) وهي “LoRA” وامتداد التكميم (Quantization) الخاص بها “QLoRA”.

3.1 الخلفية الرياضية لـ LoRA (Low-Rank Adaptation)

LoRA هي طريقة تقوم بتجميد (Freeze) مصفوفات الأوزان المدربة مسبقًا، وتقريب مقدار تحديث الوزن ($\Delta W$) كحاصل ضرب مصفوفتين صغيرتين منخفضتي الرتبة (Low-rank).

لنفترض أن الأوزان المدربة مسبقًا هي $W_0 \in \mathbb{R}^{d \times k}$. في الضبط الدقيق الكامل، يتم تحديث $W_0$ نفسها لتصبح $W_0 + \Delta W$، ولكن في LoRA يتم تحليل مصفوفة التحديث $\Delta W$ على النحو التالي:

$$ \Delta W = B \times A $$

هنا، $B \in \mathbb{R}^{d \times r}$، و $A \in \mathbb{R}^{r \times k}$، و $r$ هي معلمة فائقة (Hyperparameter) تسمى الرتبة (Rank)، وهي قيمة صغيرة جداً (عادة 8، 16، 32، وما إلى ذلك) تلبي $r \ll \min(d, k)$.

يكون حساب التمرير الأمامي (Forward pass) على النحو التالي:

$$ h = W_0 x + \Delta W x = W_0 x + B A x $$

في الحالة الأولية، تتم تهيئة المصفوفة $A$ بشكل عشوائي بتوزيع طبيعي (Gaussian distribution)، وتتم تهيئة المصفوفة $B$ كمصفوفة صفرية. وبسبب هذا، تكون $\Delta W$ في بداية التدريب صفراً، مما يسمح ببدء التدريب مع الاحتفاظ بمخرجات النموذج الأساسي (Base model) بالكامل.

graph LR X["متجه الإدخال x"] --> W0["الوزن المجمد المدرب مسبقًا (W_0)"] X --> A["مصفوفة LoRA القابلة للتدريب A (r x k)"] A --> B["مصفوفة LoRA القابلة للتدريب B (d x r)"] W0 --> Add["جمع المتجهات"] B --> Add Add --> Y["متجه الإخراج h"]

3.2 ابتكار QLoRA (Quantized LoRA)

تدفع QLoRA بنهج LoRA خطوة أبعد، وهي طريقة تقوم بتكميم (Quantize) النموذج الأساسي $W_0$ إلى دقة 4-bit (NormalFloat 4, NF4) وتحميله في الذاكرة. هذا يقلل بشكل كبير من استهلاك VRAM.

تتضمن QLoRA ثلاث تقنيات مهمة:

تكميم 4-bit NormalFloat (NF4): نوع بيانات مثالي نظرياً ومحسن للأوزان التي تتبع توزيعاً طبيعياً.
التكميم المزدوج (Double Quantization): يوفر المزيد من الذاكرة عن طريق تكميم ثوابت التكميم (معاملات المقياس - Scale factors) نفسها.
Paged Optimizers: آلية تستخدم ميزة الذاكرة الموحدة من NVIDIA لتفريغ (Evict) حالة المحسن مؤقتاً إلى ذاكرة الوصول العشوائي (RAM) الخاصة بوحدة المعالجة المركزية (CPU) عند نفاد VRAM.

نتيجة لذلك، فإن الضبط الذي يتطلب عادةً من 16 جيجابايت إلى 24 جيجابايت من VRAM يمكن إجراؤه بسهولة على وحدات معالجة رسومات استهلاكية (مثل RTX 3060 12GB أو RTX 4070).

4. متطلبات الأجهزة والإعداد في البيئة المحلية

تعتبر متطلبات الأجهزة لضبط TinyLLaMA (1.1B) باستخدام QLoRA منخفضة جداً.

مواصفات الأجهزة الموصى بها

وحدة معالجة الرسومات (GPU): NVIDIA RTX 3060 (12GB) أو RTX 3090/4090 (24GB) أو NVIDIA A10G/A100 وغيرها. تعمل إذا كان هناك 8 جيجابايت من VRAM على الأقل، ولكن يوصى بـ 12 جيجابايت أو أكثر لزيادة حجم الدفعة (Batch size).
وحدة المعالجة المركزية (CPU): وحدة معالجة مركزية حديثة بـ 8 نوى أو أكثر (Intel Core i7/i9، AMD Ryzen 7/9)
ذاكرة الوصول العشوائي (RAM): 32 جيجابايت أو أكثر (مهمة كوجهة إخلاء من VRAM عند استخدام Paged Optimizers)
مساحة التخزين: NVMe SSD (لتسريع قراءة مجموعة البيانات وحفظ النموذج)

إعداد بيئة البرامج

هذه إرشادات الإعداد بفرض استخدام بيئة Ubuntu 22.04 LTS. سنستخدم Python 3.10 أو أحدث.

1
2
3
4
5
6
7
8
9


# إنشاء بيئة افتراضية وتفعيلها
python3 -m venv tinyllama_env
source tinyllama_env/bin/activate

# تثبيت PyTorch (لـ CUDA 12.1)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

# تثبيت المكتبات المتعلقة بالمحولات (Transformers)
pip install transformers datasets peft trl accelerate bitsandbytes

5. تقنيات التحسين للحصول على أسرع ضبط

لإكمال الضبط بـ “أسرع” طريقة، لا يكفي مجرد تشغيل النص البرمجي، بل يجب الجمع بين تقنيات التحسين التالية.

5.1 Flash Attention 2

في آلية الانتباه (Attention) القياسية، يكون التعقيد الزمني والمكاني $O(N^2)$ بالنسبة لطول التسلسل $N$. تعمل تقنية Flash Attention 2 على تحسين الوصول إلى الذاكرة بين SRAM و HBM (الذاكرة ذات النطاق الترددي العالي) في GPU، مما يزيل اختناقات الإدخال/الإخراج (IO bottlenecks) دون تقليل كمية الحسابات، ويرفع سرعة التدريب عدة مرات، ويقلل استهلاك الذاكرة بشكل كبير.

5.2 Gradient Checkpointing (نقاط فحص التدرج)

بدلاً من حفظ جميع التنشيطات الوسيطة (Intermediate activations) المحسوبة في التمرير الأمامي في VRAM، تقوم هذه الطريقة بحفظ جزء منها فقط، وإعادة حسابها عند الحاجة في التمرير الخلفي (Backward pass). يزداد وقت الحساب بنسبة 20٪ تقريبًا، ولكن يمكن تقليل استهلاك الذاكرة بشكل كبير، مما يسمح بتعيين حجم دفعة (Batch size) أكبر، وبالتالي تحسين الإنتاجية الإجمالية.

5.3 Mixed Precision Training (التدريب بالدقة المختلطة) و Bfloat16

لتحقيق أقصى استفادة من Tensor Cores في GPU، نستخدم bfloat16 (Brain Floating Point) للحسابات أثناء التدريب. بالمقارنة مع float16، فإن طول البت للأس هو نفسه في float32، لذلك يكون خطر تجاوز السعة (Overflow) وانخفاض السعة (Underflow) منخفضًا جدًا، مما يجعل التدريب مستقرًا.

6. عملي: كود الضبط الدقيق QLoRA لـ TinyLLaMA

الآن، سنشرح نص PyTorch المخصص لأسرع ضبط، والذي يتضمن جميع التحسينات المذكورة أعلاه. هنا نستخدم SFTTrainer من مكتبة trl (Transformer Reinforcement Learning) الخاصة بـ Hugging Face.

6.1 تجهيز مجموعة البيانات وتحميل النموذج

 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


import torch
from datasets import load_dataset
from transformers import (
 AutoModelForCausalLM,
 AutoTokenizer,
 BitsAndBytesConfig,
 TrainingArguments
)
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from trl import SFTTrainer

# 1. تحديد النموذج والمرمز (Tokenizer)
model_id = "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

# 2. إعدادات تكميم 4-bit لـ QLoRA
bnb_config = BitsAndBytesConfig(
 load_in_4bit=True,
 bnb_4bit_use_double_quant=True,
 bnb_4bit_quant_type="nf4",
 bnb_4bit_compute_dtype=torch.bfloat16 # إجراء الحسابات باستخدام bfloat16
)

# 3. تحميل النموذج (تفعيل Flash Attention 2)
print("Loading model...")
model = AutoModelForCausalLM.from_pretrained(
 model_id,
 quantization_config=bnb_config,
 device_map="auto",
 use_flash_attention_2=True # مفتاح التسريع
)

# 4. تحميل المرمز (Tokenizer)
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right" # التعيين إلى right لتجنب الأخطاء أثناء التدريب باستخدام fp16/bf16

6.2 تطبيق محول LoRA وتنسيق مجموعة البيانات

 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


# 5. التحضير لتدريب k-bit وتفعيل نقاط فحص التدرج
model.gradient_checkpointing_enable()
model = prepare_model_for_kbit_training(model)

# 6. إعدادات LoRA
peft_config = LoraConfig(
 r=16, # الرتبة
 lora_alpha=32, # معامل التحجيم
 lora_dropout=0.05,
 bias="none",
 task_type="CAUSAL_LM",
 target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"] # استهداف جميع الطبقات الخطية يحسن الأداء
)

model = get_peft_model(model, peft_config)
model.print_trainable_parameters()
# مثال للمخرجات: trainable params: 14,286,848 || all params: 1,114,335,232 || trainable%: 1.282%

# 7. تحميل مجموعة البيانات (نستخدم هنا مجموعة بيانات Instruction باللغة اليابانية كمثال)
# في الواقع، ستقوم بتحميل ملف JSONL خاص بك من البيئة المحلية
dataset = load_dataset("kunishou/databricks-dolly-15k-ja", split="train")

def format_instruction(sample):
 """
 تنسيق السلسلة لتتناسب مع تنسيق ChatML أو قالب الموجه (Prompt template)
 """
 prompt = f"<|im_start|>user\n{sample['instruction']}"
 if sample.get("input", "") != "":
 prompt += f"\n{sample['input']}"
 prompt += f"<|im_end|>\n<|im_start|>assistant\n{sample['output']}<|im_end|>"
 return {"text": prompt}

dataset = dataset.map(format_instruction)

6.3 تنفيذ التدريب

 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


# 8. إعداد وسائط التدريب
training_args = TrainingArguments(
 output_dir="./tinyllama-lora-output",
 per_device_train_batch_size=8, # يمكن زيادته إذا كانت هناك مساحة في VRAM
 gradient_accumulation_steps=2, # حجم الدفعة الفعلي = 8 * 2 = 16
 optim="paged_adamw_32bit", # توفير VRAM باستخدام Paged Optimizer
 save_steps=100,
 logging_steps=10,
 learning_rate=2e-4,
 fp16=False,
 bf16=True, # التدريب بالدقة المختلطة (bfloat16)
 max_grad_norm=0.3,
 max_steps=500, # 500 خطوة للاختبار. في الإنتاج، حدد عدد الحقبات (Epochs)
 warmup_ratio=0.03,
 group_by_length=True,
 lr_scheduler_type="cosine",
)

# 9. بدء التدريب باستخدام SFTTrainer
trainer = SFTTrainer(
 model=model,
 train_dataset=dataset,
 peft_config=peft_config,
 dataset_text_field="text",
 max_seq_length=1024, # تعديل ليناسب طول الإدخال المتوقع
 tokenizer=tokenizer,
 args=training_args,
)

print("Starting training...")
trainer.train()

# 10. حفظ محول LoRA
trainer.model.save_pretrained("./tinyllama-lora-final")
tokenizer.save_pretrained("./tinyllama-lora-final")
print("Training complete and model saved.")

7. تقييم الأداء واستكشاف الأخطاء وإصلاحها

إليك المشكلات الشائعة والحلول الخاصة بها عند تشغيل التدريب في بيئة محلية.

حدوث OOM (Out Of Memory):
- قلل per_device_train_batch_size إلى 1.
- قم بزيادة gradient_accumulation_steps للحفاظ على حجم الدفعة الفعلي.
- قم بتقصير max_seq_length من 2048 إلى 1024 أو 512.
الخسارة (Loss) لا تنخفض أو تتباعد:
- قد يكون معدل التعلم (learning_rate) مرتفعًا جدًا. حاول تقليله من 2e-4 إلى حوالي 5e-5.
- إذا كنت تستخدم Float16 بدلاً من Bfloat16، فقد يحدث انخفاض في سعة التدرجات (Underflow). تحقق من bf16=True.
توليد سلاسل نصية غامضة أثناء الاستنتاج:
- تأكد من تعيين padding_side="right" بشكل صحيح. بالإضافة إلى ذلك، تحقق مما إذا كان تنسيق مجموعة البيانات (مثل الرموز المميزة الخاصة <|im_start|>) متوافقًا مع التنسيق المستخدم أثناء التدريب المسبق للنموذج الأساسي.

8. نشر النموذج بعد الضبط (Deployment)

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

نص دمج النموذج (Merge script)

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


import torch
from peft import AutoPeftModelForCausalLM
from transformers import AutoTokenizer

output_dir = "./tinyllama-lora-final"

# تحميل النموذج والمحول باستخدام FP16/BF16
model = AutoPeftModelForCausalLM.from_pretrained(
 output_dir,
 device_map="auto",
 torch_dtype=torch.bfloat16
)
tokenizer = AutoTokenizer.from_pretrained(output_dir)

# دمج الأوزان وحفظها
merged_model = model.merge_and_unload()
merged_model.save_pretrained("./tinyllama-merged", safe_serialization=True)
tokenizer.save_pretrained("./tinyllama-merged")
print("Model merged and saved successfully!")

تشغيل خادم استنتاج فائق السرعة باستخدام vLLM

عند النشر في بيئة محلية، ولتحقيق أقصى قدر من سرعة الاستنتاج (الرموز في الثانية - Tokens per second)، يوصى بشدة باستخدام vLLM أو TGI (Text Generation Inference) بدلاً من خط الأنابيب القياسي (pipeline) الخاص بـ Hugging Face. يستخدم vLLM تقنية PagedAttention لمنع تجزئة ذاكرة GPU، مما يحسن من قدرة معالجة الطلبات المتزامنة بشكل كبير.

يوضح مخطط Mermaid أدناه مسار العمل (Pipeline) من التدريب إلى نشر خادم الاستنتاج.

graph TD A["بيانات خاصة خام"] --> B["المعالجة المسبقة والتنسيق (JSONL)"] B --> C["الضبط الدقيق QLoRA (باستخدام SFTTrainer)"] C --> D["أوزان محول LoRA (.safetensors)"] D --> E["الدمج مع النموذج الأساسي TinyLLaMA 1.1B"] E --> F["النموذج المدمج"] F --> G["النشر عبر خادم vLLM"] G --> H["نقطة نهاية API / واجهة مستخدم (مثال: روبوت دردشة)"]

يمكن إكمال بدء تشغيل خادم API باستخدام vLLM بأمر واحد فقط:

1
2
3
4
5
6


python -m vllm.entrypoints.openai.api_server \
 --model ./tinyllama-merged \
 --host 0.0.0.0 \
 --port 8000 \
 --max-model-len 2048 \
 --dtype bfloat16

بهذا، يتم بناء نقطة نهاية متوافقة مع OpenAI API في البيئة المحلية، مما يسمح باستخدام الذكاء الاصطناعي المحلي بشكل آمن وسريع.

9. الخلاصة

في هذا المقال، شرحنا كيفية إجراء ضبط دقيق (Fine-tuning) لنموذج “TinyLLaMA”، الذي يتميز بأداء عالٍ على الرغم من خفة وزنه (1.1 مليار معلمة)، بأسرع طريقة وأكثرها كفاءة في استخدام الذاكرة في بيئة محلية (On-premises).

من خلال LoRA / QLoRA، أصبح من الممكن إجراء ضبط لـ LLM بشكل احترافي حتى على وحدات معالجة الرسومات المخصصة للمستهلكين.
من خلال الاستفادة من Flash Attention 2 و Gradient Checkpointing، قمنا بتحسين وقت التدريب واستهلاك VRAM إلى أقصى حد.
من خلال النشر باستخدام vLLM، حققنا إنتاجية عالية حتى في بيئة الإنتاج.

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

دليل تطوير نماذج الذكاء الاصطناعي الصغيرة (مثل 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) بينما نستمتع بجوهر برمجة الأنظمة.

【مقدمة في تنفيذ RAG】كيفية جعل الذكاء الاصطناعي المحلي يقرأ مستنداتك

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

مقدمة

في السنوات الأخيرة، كان التطور في نماذج اللغة الكبيرة (LLM) ملحوظًا، حيث تغلغل العديد من أنظمة الذكاء الاصطناعي مثل ChatGPT و Claude في حياتنا وأعمالنا. ومع ذلك، هناك نقطة ضعف واضحة في نماذج LLM العامة. وهي أنها لا تعرف سوى “المعلومات العامة المتاحة وقت التدريب”. بالطبع، لا يمكنها الإجابة على الأسئلة المتعلقة بـ “المستندات الخاصة” مثل لوائح الشركة، والمذكرات الشخصية، ومواد المشاريع غير المنشورة. إذا حاولت إجبارها على الإجابة، فهناك خطر كبير من أنها ستولد أكاذيب تبدو معقولة ولكنها بعيدة عن الحقيقة (الهلوسة - Hallucination).

لذلك، فإن البنية المعمارية التقنية التي تنتشر حاليًا بشكل هائل في جميع أنحاء العالم هي RAG (Retrieval-Augmented Generation: التوليد المعزز بالاسترجاع). باستخدام RAG، يصبح من الممكن تزويد LLM بالمعرفة الخاصة ديناميكيًا من قاعدة بيانات خارجية، وجعلها تولد إجابات دقيقة وموثوقة بناءً على ذلك.

علاوة على ذلك، عند التعامل مع مجال الشركات أو المعلومات الشخصية السرية، غالبًا ما يكون إرسال البيانات إلى واجهات برمجة التطبيقات (APIs) المستندة إلى السحابة مثل OpenAI غير مسموح به بموجب سياسة الأمان. ما هو مطلوب هنا هو بناء “RAG محلي” مدمج مع الذكاء الاصطناعي المحلي (LLM يعمل بالكامل على جهاز الكمبيوتر الخاص بك أو الخادم المحلي - On-Premise).

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

1. البنية المعمارية العامة لـ RAG

RAG ليس نموذج ذكاء اصطناعي واحد، بل هو بنية نظام تتعاون فيها مكونات متعددة. يتكون بشكل رئيسي من مرحلتين: “مرحلة الاستيعاب (إدخال البيانات)” و “مرحلة الاسترجاع والتوليد (البحث والتوليد)”.

يوضح مخطط Mermaid التالي الصورة العامة لنظام RAG.

graph TD subgraph "مرحلة الاستيعاب (التحضير المسبق)" Doc["مستندات خاصة (PDF, TXT, إلخ.)"] --> Loader["محمل المستندات"] Loader --> Splitter["تقسيم النص (Chunking)"] Splitter --> EmbedModel1["نموذج التضمين (Embedding)"] EmbedModel1 --> VectorDB["قاعدة بيانات المتجهات"] end subgraph "مرحلة الاستدلال (عند استعلام المستخدم)" User["سؤال من المستخدم (استعلام)"] --> EmbedModel2["نموذج التضمين (Embedding)"] EmbedModel2 --> QueryVector["متجه الاستعلام"] QueryVector --> Search["بحث التشابه (بحث المتجهات)"] VectorDB --> Search Search --> Context["استخراج القطع ذات الصلة (السياق)"] User --> PromptBuilder["بناء الموجه (Prompt)"] Context --> PromptBuilder PromptBuilder --> LocalLLM["LLM محلي"] LocalLLM --> Answer["توليد الإجابة النهائية"] end

مرحلة الاستيعاب (التحضير المسبق)

تحميل المستندات: تحميل البيانات غير المهيكلة مثل ملفات PDF، Word، والملفات النصية.
التقسيم (Chunking): تقسيم النصوص الطويلة إلى كتل ذات معنى (Chunks) لتتناسب مع قيود الإدخال في LLM (نافذة السياق) ولتحسين دقة البحث.
التضمين (Embedding / تحويل إلى متجهات): إدخال الكتل المقسمة إلى نموذج التضمين (Embedding Model) وتحويلها إلى مصفوفات من الأرقام (متجهات) ذات مئات إلى آلاف الأبعاد.
الحفظ في قاعدة البيانات: حفظ المتجهات المحولة مرتبطة بالبيانات النصية الأصلية في قاعدة بيانات المتجهات (Vector DB).

مرحلة الاستدلال (أثناء التشغيل)

تحويل الاستعلام إلى متجهات: تحويل سؤال المستخدم إلى متجه باستخدام نفس نموذج التضمين المستخدم في التحضير المسبق.
بحث التشابه: حساب التشابه بين متجه الاستعلام ومتجهات المستندات في قاعدة البيانات، واسترداد أعلى الكتل النصية الأقرب دلاليًا (ذات الصلة العالية).
بناء الموجه (Prompt): دمج النصوص المستردة ذات الصلة كـ “سياق (معرفة خلفية)” مع سؤال المستخدم لإنشاء موجه الإدخال لـ LLM.
توليد الإجابة: يتلقى LLM الموجه الموسع ويولد إجابة بناءً على معلومات السياق المرفقة.

2. الفهم العميق للبحث في المتجهات والتضمين (Embeddings)

جوهر RAG هو “البحث في المتجهات (البحث الدلالي)”. بينما يعتمد بحث الكلمات الرئيسية التقليدي (مثل BM25) على المطابقة التامة للكلمات وتكرارها، يعتمد البحث في المتجهات على “التشابه الدلالي”. على سبيل المثال، حتى الكلمات المختلفة مثل “كلب” و “جرو”، أو “حاسوب” و “كمبيوتر”، ستظهر في نتائج البحث إذا كانت معانيها متقاربة.

ما هو نموذج التضمين (Embedding Model)؟

نموذج التضمين هو شبكة عصبية تأخذ النصوص باللغة الطبيعية كإدخال وتخرج متجهًا كثيفًا ثابت الطول (Dense Vector). النماذج الشائعة (مثل text-embedding-3-small أو النماذج مفتوحة المصدر مثل multilingual-e5-large) تقوم بتعيين النص إلى متجه حقيقي بأبعاد 384 أو 1024.

في هذا الفضاء متعدد الأبعاد (الفضاء الكامن - Latent Space)، يتم تدريب النموذج بحيث تكون المسافة في فضاء الإحداثيات أقرب كلما كانت الجمل متشابهة في المعنى.

الخلفية الرياضية لحساب التشابه: تشابه جيب التمام (Cosine Similarity)

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

يتم التعبير عن تشابه جيب التمام للمتجهين $\mathbf{A}$ و $\mathbf{B}$ رياضياً كالتالي:

$$ \text{Cosine Similarity}(\mathbf{A}, \mathbf{B}) = \cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \|\mathbf{B}\|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}} $$

$\mathbf{A} \cdot \mathbf{B}$ يمثل الجداء النقطي (Dot Product).
$\|\mathbf{A}\|$ يمثل معيار L2 (الطول) للمتجه $\mathbf{A}$.
$n$ هو عدد أبعاد المتجه.

يأخذ تشابه جيب التمام قيمًا من -1 إلى 1.

قريب من 1: اتجاه كلا المتجهين هو نفسه تقريبًا (المعنى متشابه جدًا)
قريب من 0: المتجهان متعامدان (غير مرتبطين)
قريب من -1: المتجهان في اتجاهين متعاكسين (المعنى معاكس)

تستخدم قواعد بيانات المتجهات الحديثة (مثل Chroma، FAISS، Qdrant) خوارزمية بحث أقرب جار تقريبي (ANN) تسمى HNSW (Hierarchical Navigable Small World)، والتي تم تحسينها للبحث عن المستندات ذات تشابه جيب التمام العالي من بين ملايين البيانات المتجهة في أجزاء من الثانية.

3. حزمة التقنيات لبناء RAG محلي

لبناء RAG محلي بالكامل لا يعتمد على السحابة، سنستفيد من نظام المصادر المفتوحة. نوصي بحزمة التقنيات التالية:

نموذج اللغة (LLM)
- الأداة: Ollama أو Llama.cpp
- النماذج: نماذج مفتوحة خفيفة وعالية الأداء مثل Llama-3-8B-Instruct، Gemma-2-9B-It، Qwen2-7B-Instruct. للمهام باللغة اليابانية، تعتبر النماذج المضبوطة لليابانية مثل Llama-3-ELYZA-JP-8B مناسبة (يمكن استخدام نماذج تدعم اللغة العربية للمهام العربية).
نموذج التضمين (Embedding)
- النماذج: intfloat/multilingual-e5-large أو BAAI/bge-m3. لتشغيله محليًا، من الشائع تنزيله من Hugging Face وتشغيله باستخدام Sentence-Transformers.
قاعدة بيانات المتجهات (Vector DB)
- ChromaDB: مبني على Python وسهل الإعداد للغاية. مثالي للتطوير المحلي.
- FAISS: مكتبة بحث متجهات سريعة طورتها Meta.
- Qdrant / Milvus: مخصص للبيئات الأكبر وبيئات الإنتاج.
إطار عمل التنسيق (Orchestration Framework)
- LangChain: المعيار الفعلي لربط المكونات (Chain).
- LlamaIndex: إطار عمل للاتصال بالبيانات متخصص بشكل خاص في RAG.

في هذه المرة، سنقوم بالتنفيذ باستخدام المزيج الأسهل في التقديم: LangChain + ChromaDB + Ollama + HuggingFaceEmbeddings.

4. دورة تعليمية للتنفيذ: بناء RAG محلي كامل باستخدام Python

من هنا، سنقوم ببناء RAG محلي من خلال كتابة كود Python فعليًا. مسبقًا، يرجى تثبيت Ollama على جهاز الكمبيوتر الخاص بك وتشغيله في الخلفية. أيضًا، قم بسحب (Pull) النموذج على Ollama (مثال: ollama run llama3).

الخطوة 1: تثبيت المكتبات المطلوبة

1
2


pip install langchain langchain-community langchain-huggingface
pip install chromadb sentence-transformers pypdf

الخطوة 2: الكود البرمجي الكامل للتنفيذ

فيما يلي برنامج نصي كامل بلغة Python لقراءة ملف PDF، وتحويله إلى متجهات، وجعل نموذج LLM المحلي يجيب على الأسئلة.

 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
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93


import os
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_community.llms import Ollama
from langchain_core.prompts import PromptTemplate
from langchain.chains import RetrievalQA

def main():
 # 1. تحميل المستندات
 print("جاري تحميل المستندات...")
 # حدد مسار ملف PDF الذي تريد قراءته
 file_path = "sample_company_policy.pdf"
 loader = PyPDFLoader(file_path)
 documents = loader.load()

 # 2. تقسيم النص (Text Splitting)
 # التقسيم إلى أحجام مناسبة دون تدمير معنى الجمل
 text_splitter = RecursiveCharacterTextSplitter(
 chunk_size=500, # أقصى عدد من الأحرف لكل كتلة
 chunk_overlap=50, # عدد الأحرف المتداخلة بين الكتل (لمنع انقطاع السياق)
 separators=["\n\n", "\n", "。", "、", " ", ""]
 )
 chunks = text_splitter.split_documents(documents)
 print(f"تم التقسيم إلى {len(chunks)} كتلة.")

 # 3. تهيئة نموذج التضمين (Local HuggingFace Model)
 # استخدام نموذج متعدد اللغات
 print("جاري تحميل نموذج التضمين...")
 embeddings = HuggingFaceEmbeddings(
 model_name="intfloat/multilingual-e5-large",
 model_kwargs={'device': 'cpu'} # 'cuda' أو 'mps' إذا كان لديك وحدة معالجة رسومات (GPU)
 )

 # 4. بناء قاعدة بيانات المتجهات (Chroma)
 print("جاري بناء قاعدة بيانات المتجهات...")
 persist_directory = "./chroma_db"
 vectorstore = Chroma.from_documents(
 documents=chunks,
 embedding=embeddings,
 persist_directory=persist_directory
 )
 # إنشاء المسترد (Retriever). إعداد لجلب أفضل 3 مستندات ذات صلة
 retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

 # 5. تهيئة LLM المحلي (Ollama)
 print("جاري الاتصال بـ LLM المحلي...")
 # تأكد من الحصول على النموذج مسبقًا باستخدام شيء مثل 'ollama pull llama3'
 llm = Ollama(model="llama3")

 # 6. تعريف قالب الموجه (Prompt Template)
 prompt_template = """أنت مساعد ممتاز على دراية بلوائح الشركة والمعلومات الداخلية.
يرجى الإجابة على سؤال المستخدم بالتفصيل باستخدام السياق (معلومات الخلفية) التالي فقط.
إذا لم تتمكن من العثور على الإجابة في السياق، فلا تخمن من نفسك وأجب بصدق "لا يمكن المعرفة من المعلومات المقدمة".

【السياق】
{context}

【السؤال】
{question}

【الإجابة】:
"""
 PROMPT = PromptTemplate(
 template=prompt_template,
 input_variables=["context", "question"]
 )

 # 7. بناء سلسلة RAG
 qa_chain = RetrievalQA.from_chain_type(
 llm=llm,
 chain_type="stuff",
 retriever=retriever,
 return_source_documents=True, # إعداد لإرجاع مصدر المعلومات
 chain_type_kwargs={"prompt": PROMPT}
 )

 # 8. تنفيذ السؤال
 query = "يرجى إخباري عن شروط دفع نفقات النقل المتعلقة بالعمل عن بعد."
 print(f"\nالسؤال: {query}\n")

 result = qa_chain.invoke({"query": query})

 print("【الإجابة】")
 print(result['result'])
 print("\n---")
 print("【مصادر المعلومات المرجعية】")
 for doc in result['source_documents']:
 print(f"- صفحة {doc.metadata.get('page', 'غير معروف')}: {doc.page_content[:50]}...")

if __name__ == "__main__":
 main()

شرح نقاط الكود

RecursiveCharacterTextSplitter: وهو المقسم الموصى به بشدة عند تقسيم اللغة الطبيعية. يحاول التقسيم بترتيب الفقرات (\n\n)، الأسطر (\n)، وعلامات الترقيم (。)، بحيث يتناسب مع chunk_size المحدد مع الحفاظ على وحدة المعنى قدر الإمكان. عن طريق تعيين chunk_overlap، فإنه يمنع فقدان المعلومات بسبب انقطاع الحدود السياقية.
HuggingFaceEmbeddings: intfloat/multilingual-e5-large هو نموذج تضمين مفتوح المصدر قوي جدًا يدعم لغات متعددة. يتيح لك تحويل النصوص إلى متجهات على الذاكرة المحلية دون اتصال بالإنترنت، دون استخدام واجهات برمجة التطبيقات السحابية (مثل text-embedding-ada-002 الخاص بـ OpenAI).
ChromaDB: نظرًا لأنه يعمل في الذاكرة (In-memory) أو في التخزين المحلي (مبني على SQLite)، فلا حاجة لإعداد خادم قاعدة بيانات معقد. بتحديد persist_directory، يمكنك تخطي عملية التحويل إلى متجهات عند إعادة التشغيل وقراءة قاعدة البيانات من القرص.

5. تقنيات RAG المتقدمة (Advanced RAG Techniques)

النظام الأساسي (Naive RAG) الذي بنيناه في الدورة التعليمية أعلاه يعمل، ولكن إذا كانت هناك حاجة إلى دقة إجابة عالية في بيئة الإنتاج، فمن الضروري تقديم تقنيات متقدمة مثل ما يلي.

5.1 البحث الهجين (Hybrid Search)

البحث في المتجهات ممتاز في التقاط “المعنى”، ولكنه قد يعاني مع عمليات البحث الدقيقة بالكلمات الرئيسية مثل “أسماء الأعلام الخاصة”، “أرقام طرازات المنتجات”، أو “معرفات الموظفين”. لذلك، من خلال إجراء البحث الدلالي عبر بحث المتجهات والبحث بالكلمات الرئيسية باستخدام خوارزميات مثل BM25 بشكل متوازٍ، ثم تسجيل ودمج نتائج كليهما (باستخدام طرق مثل دمج الترتيب المتبادل؛ Reciprocal Rank Fusion; RRF)، يمكن تقليل حالات الإخفاق في البحث بشكل كبير.

5.2 إعادة الترتيب (Re-ranking)

البحث في المتجهات سريع، ولكنه لا يقيّم بالضرورة الملاءمة السياقية الدقيقة للسياق. خط أنابيب المعالجة (Pipeline) الشائع لتحسين دقة البحث هو كالتالي:

البحث الأولي (First-stage Retrieval): استرجاع حوالي 20 إلى 30 كتلة نصية ذات صلة بشكل واسع وسطحي من قاعدة بيانات المتجهات.
إعادة التقييم (Re-ranking): استخدام نموذج تعلم آلي آخر أثقل يُعرف باسم Cross-Encoder (مثل bge-reranker)، وإدخال زوج من استعلام المستخدم والكتل المستردة لإعادة حساب درجة الملاءمة الدلالية.
الفرز: تمرير أفضل 3 إلى 5 كتل ذات أعلى الدرجات كـسياق نهائي إلى موجه LLM.

من خلال هذه الطريقة، يمكن منع تمرير معلومات الضوضاء غير ذات الصلة إلى LLM، مما يزيد بشكل كبير من دقة الإجابة (Precision).

graph LR Query["استعلام"] --> VSearch["بحث المتجهات (أفضل 20)"] VSearch --> Reranker["نموذج إعادة الترتيب (Cross-Encoder)"] Query --> Reranker Reranker --> TopK["أفضل 3 بدقة عالية"] TopK --> LLM["توليد LLM"]

5.3 التقسيم الدلالي (Semantic Chunking) والبحث في المستند الأصلي

بدلاً من تقسيم النص ميكانيكيًا بعدد ثابت من الأحرف، توجد طريقة تسمى “التقسيم الدلالي” (Semantic Chunking) تكتشف تغيرات المعنى في الجملة باستخدام الذكاء الاصطناعي لتقسيمها. أيضًا، في طريقة تُعرف باسم “البحث في المستند الأصل” (Parent Document Retriever)، يتم تحويل النص إلى متجهات بوحدات صغيرة جدًا (مثل الجمل) لأغراض البحث لتحقيق بحث عالي الدقة، وعند تمريره إلى LLM، يتم تمرير “الفقرة الكبيرة الأصلية (المستند الأصل)” التي تحتوي على تلك الجملة، مما يوفر سياقًا كافيًا لـ LLM.

6. تحديات وحلول عند تشغيل RAG محلي

عند بناء وتشغيل RAG في بيئة محلية، توجد عقبات محددة.

نفاد ذاكرة الفيديو (VRAM): لتشغيل LLM محلي بسرعة عملية (عشرات الرموز في الثانية)، يجب تحميل النموذج في ذاكرة الفيديو (VRAM) الخاصة بوحدة المعالجة الرسومية (GPU). لتشغيل نموذج من فئة 8B بصيغة fp16 (نقطة عائمة 16 بت)، يتطلب الأمر حوالي 16 غيغابايت من VRAM، ولكن باستخدام تقنيات التكميم (Quantization) (تقنيات الضغط إلى 4 بت أو 8 بت مثل صيغ GGUF و AWQ)، من الممكن تشغيلها بسرعة كافية حتى على 8 غيغابايت من VRAM (مثل أجهزة الكمبيوتر المخصصة للألعاب). يدعم كل من Llama.cpp و Ollama تنسيقات التكميم هذه افتراضيًا.
حدود نافذة السياق: إذا كان حجم السياق المسترد كبيرًا جدًا، فقد يتجاوز الحد الأقصى لإدخال LLM (حد الرموز)، أو قد ينسى النموذج الجزء الأوسط من المعلومات (ظاهرة الضياع في المنتصف - Lost in the middle). من الضروري تعديل عدد الكتل المستخرجة والاختيار الدقيق من خلال تقنية إعادة الترتيب المذكورة أعلاه.
إدارة حداثة البيانات: عند تحديث المستندات المصدرية، يجب أيضًا تحديث المتجهات أو حذفها (عمليات CRUD) للمستندات المقابلة في قاعدة بيانات المتجهات. نظرًا لأن ChromaDB يدعم التحديثات بناءً على معرف المستند (Document ID)، فمن العملي إدارة قيم التجزئة (Hash) للملفات وإعداد معالجة مجمعة (Batch Processing) لمزامنة التغييرات فقط.

الخاتمة

RAG (التوليد المعزز بالاسترجاع) هو نموذج قوي يطور الذكاء الاصطناعي من مساعد عام عادي إلى “خبيرك الشخصي” أو “خبير متخصص في الأعمال الداخلية”.

حتى في المتطلبات شديدة السرية حيث لا يمكن استخدام الخدمات السحابية، وجدنا أنه من السهل نسبيًا بناء بيئة “RAG محلي” كاملة من خلال الجمع بين أنظمة المصادر المفتوحة مثل Ollama، LangChain، و ChromaDB.

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

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

مقارنة شاملة لواجهات برمجة التطبيقات (API) لـ ChatGPT و Gemini و Claude! أيهم يجب أن تختار؟

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

مقارنة شاملة لواجهات برمجة التطبيقات (API) لـ ChatGPT و Gemini و Claude! أيهم يجب أن تختار؟

تطور تكنولوجيا الذكاء الاصطناعي مذهل، وخاصة في مجال النماذج اللغوية الكبيرة (LLM: Large Language Model)، حيث تدور معركة شرسة ثلاثية الأبعاد على الهيمنة بين ChatGPT (سلسلة GPT) من OpenAI، و Gemini من Google، و Claude من Anthropic. اعتبارًا من عام 2026، تطلق كل شركة نماذج وميزات API جديدة كل بضعة أشهر، بل كل بضعة أسابيع. بالنسبة للمطورين ومهندسي تكنولوجيا المعلومات في الشركات، أصبح السؤال “أي واجهة برمجة تطبيقات (API) يجب دمجها في منتجنا؟” قرارًا بالغ الأهمية يحدد نجاح المشروع.

في هذه المقالة، لن نقتصر على سرد المواصفات لهذه الواجهات البرمجية من مزودي الذكاء الاصطناعي الثلاثة الكبار، بل سنقوم بمقارنتها وشرحها بالتفصيل من وجهة نظر المطورين. سيشمل ذلك تصميم البنية التحتية، والهياكل التفصيلية للأسعار، والتحليل الرياضي لوقت الاستجابة (زمن الانتقال)، وأمثلة تطبيقية عملية باستخدام Python و Node.js، وصولاً إلى أحدث تقنيات تحسين التكلفة مثل التخزين المؤقت للمطالبات (Prompt Caching).

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

1. الفلسفة ومبادئ التصميم لكل LLM API

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

1.1 OpenAI (ChatGPT)

تضع OpenAI “تحقيق الذكاء الاصطناعي العام (AGI)” كمهمة لها، وتقود دائمًا المعايير الصناعية (De facto standard). توفر الشركة نماذج متنوعة مصممة خصيصًا لحالات الاستخدام المختلفة، مثل GPT-4o و GPT-4o-mini، ونماذج o1 المتخصصة في الاستدلال. تمتلك النظام البيئي الأكثر نضجًا، مع توفر أكبر عدد من المكتبات والوثائق سواء الرسمية أو غير الرسمية.

1.2 Google (Gemini)

ترفع Google شعار “AI First” (الذكاء الاصطناعي أولاً)، وتتسلح بقابلية التوسع (Scalability) التي تستفيد إلى أقصى حد من بنيتها التحتية (شبكة TPU). تتميز نماذج Gemini 1.5 Pro/Flash بامتلاكها نافذة سياق ضخمة تصل إلى 2 مليون رمز (Token)، مما يسمح لها بمعالجة مستندات طويلة جدًا أو مقاطع فيديو وصوت تمتد لساعات في وقت واحد. كما يعد التكامل القوي مع Google Cloud (Vertex AI) ميزة جذابة للغاية للشركات.

1.3 Anthropic (Claude)

شركة Anthropic، التي أسسها أعضاء سابقون في OpenAI، تتبنى نهجًا فريدًا للسلامة يُعرف بـ “الذكاء الاصطناعي الدستوري” (Constitutional AI). تحظى نماذج Claude 3.5 Sonnet و Opus بدعم حماسي من العديد من المطورين بفضل قدراتها العالية في الاستدلال، وتوليد الكود، وقبل كل شيء “الحوار الطبيعي الشبيه بالبشر” و"قلة الهلوسة" (Hallucination).

2. مقارنة تفصيلية لمواصفات عائلات النماذج

فيما يلي مقارنة لمواصفات النماذج الرئيسية اعتبارًا من عام 2026.

المزود	النموذج الرئيسي	أقصى طول للسياق	نقاط القوة الرئيسية	حالات الاستخدام الموصى بها
OpenAI	GPT-4o	128K	السرعة، التعرف البصري، دعم الصوت	التطبيقات التفاعلية، المهام العامة
OpenAI	o1-preview	128K	الاستدلال المنطقي المتقدم، الرياضيات، البرمجة	توليد الخوارزميات المعقدة، أغراض البحث
Google	Gemini 1.5 Pro	2,000K	معالجة النصوص الطويلة جدًا، متعدد الوسائط (فيديو/صوت)	تحليل قواعد البيانات البرمجية الضخمة، تلخيص الفيديو
Google	Gemini 1.5 Flash	2,000K	زمن استجابة منخفض، إنتاجية عالية، تكلفة منخفضة جدًا	المعالجة في الوقت الفعلي، معالجة الدفعات للبيانات الضخمة
Anthropic	Claude 3.5 Sonnet	200K	قدرات البرمجة، توليد نصوص طبيعية	دعم تطوير البرمجيات، خدمة العملاء المتقدمة
Anthropic	Claude 3.5 Haiku	200K	استجابة فائقة السرعة، أداء عالي مقابل التكلفة	الذكاء الاصطناعي للطرفيات (Edge AI)، روبوتات الدردشة في الوقت الفعلي

3. تعمق في البنية: ما وراء كواليس طلبات API

عند استدعاء LLM API، ما هي العمليات التي تتم في الخلفية؟ من أجل تحسين الأداء، من الضروري فهم هذه البنية.

يوضح مخطط Mermaid التالي الصورة العامة للعملية منذ إرسال طلب API من العميل وحتى إرجاع الرموز (Tokens) عبر البث (Streaming).

graph TD A["تطبيق العميل"] -->|HTTP/REST أو gRPC| B["بوابة API"] B --> C["موازن الحمل"] C --> D["مجموعة الاستدلال"] D --> E["مُقسِّم الرموز (BPE / SentencePiece)"] E --> F["ذاكرة التخزين المؤقت KV وآلية الانتباه"] F --> G["كتل المحول (التمرير الأمامي)"] G --> H["طبقة المخرجات (Logits)"] H --> I["أداة أخذ العينات (Temperature, Top-p, Top-k)"] I --> J["مُجمِّع الرموز"] J -->|استجابة البث (قطعة)| A

3.1 خوارزمية تقسيم الرموز (Tokenization)

يتم تقسيم النص المُدخل إلى API داخليًا إلى وحدات تسمى “الرموز” (Tokens).

OpenAI (tiktoken): تعتمد على Byte-Pair Encoding (BPE). يتم ضغطها بكفاءة عالية جدًا، خاصة في اللغة الإنجليزية، ولكن عدد الرموز يميل إلى التضخم في اللغات غير الأبجدية.
Google (Gemini): تعتمد على SentencePiece (Unigram Language Model). قوية في التعامل مع اللغات المتعددة، وتميل إلى القدرة على التعبير عن النصوص بعدد أقل من الرموز نسبيًا حتى في اللغات الأخرى.
Anthropic (Claude): تستخدم نسخة مخصصة من BPE. تم تعزيز دعم اللغات المتعددة، واعتبارًا من Claude 3، تم تحسين كفاءة الرموز بشكل كبير في لغات أخرى.

4. التحليل الرياضي لزمن الاستجابة والأداء

في التطبيقات التي تعمل في الوقت الفعلي، يرتبط زمن الاستجابة (Latency) ارتباطًا مباشرًا بتجربة المستخدم (UX). يمكن نمذجة زمن الاستجابة الكلي لـ LLM API ریاضیًا كالتالي:

$$ T_{total} = T_{network} + T_{TTFT} + (N \times T_{TPOT}) $$

حيث يحمل كل متغير المعاني التالية:

$T_{network}$: وقت رحلة الذهاب والإياب للشبكة (RTT).
$T_{TTFT}$ (Time To First Token): الوقت المستغرق حتى يتم إنشاء الحرف (الرمز) الأول. يعتمد بشكل كبير على تكلفة حساب الانتباه (Attention) التي تتناسب طرديًا مع مربع طول المطالبة (عدد الرموز المدخلة).
$N$: العدد الإجمالي للرموز المخرجة.
$T_{TPOT}$ (Time Per Output Token): وقت الإنشاء لكل رمز. نظرًا لأنه نموذج انحدار ذاتي (Autoregressive)، يتم حسابه بشكل تسلسلي بالاعتماد على المخرجات السابقة.

4.1 التعقيد الحسابي لآلية الانتباه الذاتي (Self-Attention)

يزداد التعقيد الحسابي للانتباه الذاتي في بنية Transformer بشكل تربيعي بالنسبة لطول التسلسل المدخل $L$.

$$ \text{Complexity} = O(L^2 \cdot d) $$

حيث $d$ هو عدد أبعاد متجه التضمين (Embedding). وبسبب هذا القيد، يتدهور $T_{TTFT}$ عادة بشكل حاد عندما تطول المطالبة. ومع ذلك، تتبنى نماذج Gemini 1.5 من Google بنيات تحسين ثورية مثل “Ring Attention” و “Block-wise Compute”، ونجحت في إنشاء الرمز الأول في وقت معقول (من بضع ثوانٍ إلى عشرات الثواني) حتى عند إدخال نص طويل يصل إلى 2 مليون رمز.

5. هيكل التسعير واستراتيجيات تحسين التكلفة

يتم حساب تكلفة API بشكل أساسي بناءً على عدد الرموز المدخلة والمخرجة.

$$ Cost = (Tokens_{in} \times Rate_{in}) + (Tokens_{out} \times Rate_{out}) $$

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

5.1 التخزين المؤقت للمطالبات (Prompt Caching)

إن إرسال مطالبات نظام (System Prompts) طويلة أو كميات كبيرة من المستندات المستردة بواسطة RAG في كل مرة يستهلك تكاليف هائلة. لمعالجة ذلك، تقدم كل شركة ميزات التخزين المؤقت.

في Anthropic (Claude) و Google (Gemini)، من خلال التخزين المؤقت لكتل نصية معينة، يمكن تقليل تكاليف الإدخال بشكل كبير (حتى 90%).

نموذج التكلفة عند استخدام التخزين المؤقت هو كالتالي:

$$ Cost_{cached} = (Tokens_{cache\_write} \times Rate_{cache\_write}) + (Tokens_{cache\_read} \times Rate_{cache\_read}) + (Tokens_{out} \times Rate_{out}) $$

هنا يتم تعيين $Rate_{cache\_read}$ عادة بين 10% إلى 25% من $Rate_{in}$ العادي. وهذا يجعل من الممكن تشغيل روبوت دردشة بتكلفة منخفضة مع الاحتفاظ دائمًا بعشرات الآلاف من أسطر الأكواد كمعرفة أساسية.

5.2 واجهة برمجة التطبيقات الدفعية (Batch API)

للمهام التي لا تتطلب الاستجابة في الوقت الفعلي (مثل تحليل السجلات، تصنيف البيانات الضخمة، إلخ)، توفر OpenAI و Anthropic واجهات برمجة تطبيقات دفعية (Batch API). وهي آلية قوية تتيح إرسال الطلبات دفعة واحدة واستلام النتائج في غضون 24 ساعة، مقابل الحصول على خصم يصل إلى نصف سعر API العادي (خصم 50%).

6. تجربة المطورين (DX) ومقارنة حزم SDK

من منظور كفاءة التطوير، سنقارن حزم تطوير البرمجيات (SDK) التي تقدمها كل شركة.

6.1 OpenAI API

هي الأكثر استخدامًا على نطاق واسع، ودعم المكتبات التابعة لجهات خارجية (مثل LangChain، LlamaIndex) هو الأسرع. بالإضافة إلى ذلك، تضمن ميزة المخرجات المنظمة (Structured Outputs) إرجاع استجابات تلتزم بمخطط JSON بدقة 100%، مما يسهل عملية تكامل النظام بشكل كبير.

6.2 Anthropic API (Claude)

تتمتع بواجهة SDK متطورة وأنيقة، وتحظى تعريفات أنواع TypeScript الخاصة بها بسمعة طيبة لسهولة استخدامها. وبشكل خاص، بنية Message API تعتبر بديهية، ويمكن كتابة الطلبات متعددة الوسائط (Multimodal) التي تتضمن صورًا متعددة بكل بساطة.

6.3 Google Gemini API

هناك نوعان من الوصول: عبر Google Cloud Vertex AI، وعبر AI Studio (Google Gen AI SDK)، وهو ما قد يربك المبتدئين قليلاً. ومع ذلك، تتكامل حزمة Vertex AI SDK الموجهة للشركات بالكامل مع نظام مصادقة الهوية والوصول (IAM) الخاص بـ GCP، مما يتيح بناء بيئة تطوير آمنة.

7. عملي! تنفيذ اختبار دمج واجهات API متعددة باستخدام Python

هنا سنقوم بكتابة نص برمجي باستخدام Python لإرسال طلبات غير متزامنة إلى 3 واجهات برمجة تطبيقات (OpenAI و Anthropic و Gemini) في نفس الوقت، ومقارنة أوقات الاستجابة.

 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


import asyncio
import time
import os
from openai import AsyncOpenAI
from anthropic import AsyncAnthropic
import google.generativeai as genai

# تهيئة العملاء
openai_client = AsyncOpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
anthropic_client = AsyncAnthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))
genai.configure(api_key=os.environ.get("GEMINI_API_KEY"))

prompt = "اشرح أساسيات الحوسبة الكمومية وتأثيرها على تقنيات التشفير الحالية بطريقة سهلة الفهم للمبتدئين."

async def fetch_openai():
 start_time = time.time()
 response = await openai_client.chat.completions.create(
 model="gpt-4o",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "OpenAI (GPT-4o)", elapsed, response.choices[0].message.content

async def fetch_anthropic():
 start_time = time.time()
 response = await anthropic_client.messages.create(
 model="claude-3-5-sonnet-20240620",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "Anthropic (Claude 3.5 Sonnet)", elapsed, response.content[0].text

async def fetch_gemini():
 start_time = time.time()
 model = genai.GenerativeModel('gemini-1.5-pro')
 # استخدام الطرق غير المتزامنة في حزمة Gemini Python SDK
 response = await model.generate_content_async(prompt)
 elapsed = time.time() - start_time
 return "Google (Gemini 1.5 Pro)", elapsed, response.text

async def main():
 print("جاري إرسال الطلبات إلى واجهات LLM API...")

 # تنفيذ الواجهات الثلاث بالتوازي
 results = await asyncio.gather(
 fetch_openai(),
 fetch_anthropic(),
 fetch_gemini()
 )

 for provider, latency, text in results:
 print(f"--- {provider} ---")
 print(f"Latency: {latency:.2f} seconds")
 print(f"Response (Excerpt): {text[:100]}...\n")

if __name__ == "__main__":
 asyncio.run(main())

من خلال تشغيل هذا النص البرمجي، يمكنك بسهولة قياس أي النماذج يستجيب بأسرع وقت (ويقلل $T_{total}$) في بيئة شبكة حقيقية.

8. تنفيذ استدعاء الأدوات (Tool Calling / Function Calling) باستخدام Node.js

لجعل LLM يعمل كـ “وكيل ذكاء اصطناعي” (AI Agent) يتفاعل مع الأنظمة الخارجية، وليس مجرد روبوت دردشة، فإن استدعاء الأدوات أو الوظائف (Tool Calling) يعد أمرًا ضروريًا. فيما يلي مثال باستخدام Node.js (TypeScript) لجعل OpenAI API يستدعي واجهة برمجة تطبيقات الطقس.

 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


import OpenAI from "openai";

const openai = new OpenAI({
 apiKey: process.env.OPENAI_API_KEY,
});

async function runAgent() {
 const tools = [
 {
 type: "function",
 function: {
 name: "get_weather",
 description: "يسترد حالة الطقس الحالية لمدينة محددة.",
 parameters: {
 type: "object",
 properties: {
 location: {
 type: "string",
 description: "اسم المدينة (مثال: طوكيو، نيويورك)",
 },
 },
 required: ["location"],
 },
 },
 },
 ];

 const response = await openai.chat.completions.create({
 model: "gpt-4o",
 messages: [{ role: "user", "content": "كيف هو الطقس في طوكيو اليوم؟ هل أحتاج إلى مظلة؟" }],
 tools: tools,
 tool_choice: "auto",
 });

 const message = response.choices[0].message;

 if (message.tool_calls) {
 const toolCall = message.tool_calls[0];
 console.log(`طلب LLM استدعاء أداة: اسم الوظيفة = ${toolCall.function.name}`);

 const args = JSON.parse(toolCall.function.arguments);
 console.log(`المتغيرات (Arguments): ${args.location}`);

 // هنا تقوم بتنفيذ عملية استدعاء API الطقس الفعلي (مثل OpenWeatherMap)
 // const weather = await fetchWeatherFromAPI(args.location);

 // تمرير النتائج المستردة مرة أخرى إلى LLM لإنشاء الإجابة النهائية
 }
}

runAgent().catch(console.error);

تمتلك نماذج Claude 3.5 Sonnet و Gemini 1.5 Pro أيضًا ميزات مشابهة لاستدعاء الأدوات، وعلى الرغم من وجود اختلافات طفيفة في طرق تعريف المخططات، إلا أن التدفق الأساسي يظل مشتركًا.

9. RAG مقابل نافذة السياق الطويلة (Long Context): أيهما يجب أن تتبنى؟

حاليًا، من أكبر النقاشات في هندسة الذكاء الاصطناعي للمؤسسات هو: “لدمج المعرفة الخارجية، هل يجب استخدام RAG (التوليد المعزز بالاسترجاع) أم ترك كل شيء لنافذة السياق الضخمة (Long Context)؟”

فوائد وتحديات RAG

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

نافذة السياق الطويلة (مثل 2 مليون رمز في Gemini 1.5 Pro)

الفوائد: لا يوجد فقدان للمعلومات بسبب البحث. حتى في اختبار “إيجاد إبرة في كومة قش” (Needle In A Haystack: NIAH)، يمكن لنماذج مثل Gemini 1.5 Pro و Claude 3.5 Sonnet استخراج المعلومات بدقة تتجاوز 99%.
التحديات: استهلاك هائل للرموز يؤدي إلى تكاليف مرتفعة، وزيادة في زمن الاستجابة ($T_{TTFT}$).

الخلاصة: أفضل الممارسات لعام 2026 هي “النهج الهجين” (Hybrid Approach). استخدام RAG مع قواعد البيانات المتجهة لأسئلة وأجوبة الحياة اليومية، واستخدام نافذة السياق الطويلة المدعومة بالتخزين المؤقت للمطالبات للمهام المتخصصة التي تتطلب تحليلاً معقدًا أو مراجعة للأكواد بالكامل، أصبح هذا هو التصميم السائد.

10. مقارنة قدرات المعالجة متعددة الوسائط (Multimodal)

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

sequenceDiagram participant User as "المستخدم" participant Client as "تطبيق الواجهة الأمامية" participant API as "LLM API (متعدد الوسائط)" User->>Client: تحميل الفيديو والمطالبة النصية Client->>API: إرسال بايتات/رابط الفيديو + النص Note over API: تقسيم الفيديو وفصل الصوت Note over API: نموذج التضمين متعدد الوسائط API-->>Client: إرجاع ملخص نصي وطوابع زمنية Client-->>User: عرض الرؤى (Insights)

OpenAI (GPT-4o): دقة التعرف على الصور عالية جدًا، وتتفوق في قراءة المخططات اليدوية والرسوم البيانية المعقدة. كما تدعم واجهة Realtime API للمحادثات الصوتية الأصلية بزمن استجابة منخفض جدًا (أجزاء من الثانية) وهي ميزة قوية جدًا.
Google (Gemini 1.5 Pro): تتغلب على جميع المنافسين في تحليل الفيديو. يمكن إدخال ملف فيديو مدته ساعة (الإطارات + الصوت) كما هو، ويمكنها الإجابة على أسئلة دقيقة مثل “ما هو عنوان المستند الذي يحمله الشخص الذي يظهر على الحافة اليمنى من الشاشة في الدقيقة 12 و45 ثانية؟”.
Anthropic (Claude 3.5 Sonnet): قدرة التعرف البصري (Vision) ممتازة تضاهي GPT-4o. تبرز قوتها المنقطعة النظير في دعم تطوير الواجهة الأمامية، مثل تمرير لقطة شاشة لواجهة المستخدم (UI) وطلب “توليد كود مكونات React لهذه الشاشة”.

11. الأمن والامتثال (Compliance) على مستوى المؤسسات

عند استخدام الشركات لـ LLM API في بيئة الإنتاج، فإن أكبر مخاوفها تتمحور حول “هل ستُستخدم بياناتنا في تدريب الذكاء الاصطناعي؟” و"هل يلبي متطلبات الامتثال؟".

الشركات الثلاث أعلنت صراحة أن البيانات المُرسلة عبر الـ API (المطالبات والاستجابات) لا تُستخدم لتدريب النماذج (Zero Data Retention / No Training on Customer Data) (ملاحظة: واجهة الدردشة المجانية للمستهلكين تختلف عن ذلك).

للمتطلبات الأمنية الأعلى:

OpenAI: من خلال Azure OpenAI Service، يمكن الاستفادة من أمان مستوى المؤسسات من Microsoft، واتفاقيات مستوى الخدمة (SLA)، والاتصال بشبكة مغلقة عبر Azure Private Link.
Google: عبر Google Cloud Vertex AI، يمكن عزل الشبكة بصرامة باستخدام VPC Service Controls، وحماية البيانات عبر مفاتيح التشفير المدارة من قبل العميل (CMEK).
Anthropic: عبر AWS Bedrock أو Google Cloud Vertex AI، يمكن الاعتماد على البنية التحتية الأمنية القوية لموفري الخدمات السحابية.

12. الخلاصة: الدليل النهائي للاختيار حسب حالة الاستخدام

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

تطوير البرمجيات المعقدة، توليد الأكواد، الاستدلال المتقدم: 👑 الفائز: Claude 3.5 Sonnet (Anthropic) يقدم حاليًا أفضل أداء في فهم سياق الكود، وإعادة الهيكلة، وكتابة نصوص طبيعية قريبة من البشر. كما أنه يتميز بسهولة استخدام الـ API وكفاءة التكلفة بفضل التخزين المؤقت للمطالبات.
تحليل المستندات الطويلة جدًا، المعالجة الدفعية للفيديو/الصوت: 👑 الفائز: Gemini 1.5 Pro (Google) نافذة السياق التي تبلغ 2 مليون رمز هي سلاح لا مثيل له. لا يوجد ما يضاهي Gemini في المهام التي تتطلب فهم الصورة الكاملة للبيانات، مثل تحليل مئات الصفحات من أدلة PDF أو تلخيص تسجيلات اجتماعات طويلة.
التنوع، سرعة التنفيذ، والمخرجات المنظمة المستقرة (JSON): 👑 الفائز: GPT-4o / GPT-4o-mini (OpenAI) ينفذ أي مهمة بكفاءة، ويدعم أكبر عدد من أدوات الطرف الثالث. يُعد نظام OpenAI البيئي ضروريًا إذا كنت بحاجة إلى تحليل JSON موثوق باستخدام Structured Outputs، أو استدلال منطقي عالي المستوى عبر نماذج o1.

التوصية بتوجيه النماذج المتعددة (Multi-Model Routing)

الاتجاه المستقبلي هو عدم الاعتماد على API واحد (Vendor lock-in)، بل التبديل الديناميكي بين النماذج حسب صعوبة أو أهمية المهمة، وهو ما يُعرف بهندسة “توجيه LLM” (LLM Routing). على سبيل المثال، الاستجابة للأسئلة البسيطة من المستخدمين باستخدام GPT-4o-mini أو Gemini 1.5 Flash السريع والرخيص، والتراجع (Fallback) للمهام إلى Claude 3.5 Sonnet فقط عند الحاجة إلى معالجة معقدة. هذا يحقق توازنًا مثاليًا بين التكلفة والأداء.

تطور الذكاء الاصطناعي لن يتوقف. يجب الفهم العميق لنقاط القوة والضعف في كل API وخصائص بنية النظام لبناء تطبيقات ذكاء اصطناعي مرنة وقابلة للتوسع.

استخدام 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)

【أحدث إصدار لعام 2026】الدليل الشامل لتشغيل النماذج اللغوية الكبيرة (LLM) المحلية على بيئة ويندوز

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

1. مقدمة: لماذا نماذج LLM المحلية على ويندوز الآن؟

في عام 2026، يشهد تطور الذكاء الاصطناعي التوليدي والنماذج اللغوية الكبيرة (LLM) نقلة نوعية كبرى من خدمات واجهة برمجة التطبيقات (API) الضخمة على السحابة إلى “نماذج LLM المحلية” التي تعمل على أجهزة الكمبيوتر الشخصية والبيئات المحلية (On-Premises). على الرغم من أن نماذج الذكاء الاصطناعي السحابية مثل GPT-5 من OpenAI و Claude 3.5 من Anthropic قوية جدًا، إلا أنه لا يمكن للشركات والأفراد إرسال جميع بياناتهم إلى السحابة. من منظور الخصوصية، والأمان، وزمن الوصول (Latency)، والتكلفة المستدامة طويلة الأجل، فقد زاد الطلب على نماذج LLM المحلية بشكل غير مسبوق وبشكل هائل.

تطور النظام البيئي لنماذج LLM المحلية في بيئة ويندوز (Windows) بشكل خاص كان مذهلًا. حتى سنوات قليلة مضت، كان من المتعارف عليه أن “تطوير وتشغيل الذكاء الاصطناعي يعني Linux”، ولكن في عام 2026، تحول نظام ويندوز إلى منصة ذكاء اصطناعي قوية وسهلة الاستخدام للغاية.

في هذه المقالة، وبناءً على أحدث الاتجاهات التقنية لعام 2026، نقدم دليلاً شاملاً لبناء، وتشغيل، وتحسين نماذج LLM المحلية في بيئة ويندوز. سنقوم بشرح مفصل بحجم هائل يغطي كل شيء بدءًا من الإعداد البسيط للمبتدئين باستخدام Ollama، والتحسين الأقصى للمتقدمين باستخدام llama.cpp، وحتى الفهم العميق للبنية (Architecture) والنهج الرياضي لحساب ذاكرة الوصول العشوائي للفيديو (VRAM)، بالإضافة إلى الضبط الدقيق (Fine-tuning) محليًا.

1.1 الاتجاهات التقنية المحيطة بنماذج LLM المحلية في عام 2026

تتمثل الاتجاهات الرئيسية التي تشكل النظام البيئي الحالي لنماذج LLM المحلية فيما يلي:

الانتشار الكامل لتنسيق GGUF: أصبح تنسيق GGUF (GPT-Generated Unified Format)، الذي يدمج البيانات الوصفية (Metadata) والموترات (Tensors) في ملف واحد، معيارًا أساسيًا (De facto standard) بالكامل. وبفضل هذا، أصبح من الممكن تشغيل النماذج في أي بيئة بمجرد تنزيل ملف واحد من Hugging Face.
إضفاء الطابع الديمقراطي على بنية MoE (مزيج الخبراء): تم إطلاق العديد من نماذج MoE صغيرة الحجم ولكنها عالية الأداء. ومن خلال تنشيط بعض الخبراء فقط أثناء الاستدلال (Inference)، فإنها تحقق أداءً يضاهي النماذج الضخمة مع تقليل العبء الحسابي على أجهزة الكمبيوتر الشخصية الاستهلاكية.
التجريد العالي والتحسين لمحركات الاستدلال: تم تحسين أدوات مثل Ollama، LM Studio، و AnythingLLM، ولم يعد المستخدمون بحاجة إلى القلق بشأن التبعيات المعقدة مثل تثبيت برامج تشغيل CUDA. بالإضافة إلى ذلك، بفضل الدعم الأصلي (Native) لـ FlashAttention 3 على ويندوز، زادت سرعة الاستدلال بشكل كبير.
الاستفادة من وحدات المعالجة العصبية (NPU) وظهور أجهزة كمبيوتر Windows Copilot+: حتى بالنسبة لأجهزة الكمبيوتر المحمولة التي لا تحتوي على وحدة معالجة رسومات (GPU)، فقد دخلت تقنية تشغيل النماذج اللغوية الصغيرة (SLM) باستهلاك منخفض للطاقة باستخدام وحدة المعالجة العصبية (NPU) المدمجة مرحلة الاستخدام العملي.

2. متطلبات الأجهزة (Hardware) وإعداد نظام التشغيل

لكي تعمل نماذج LLM المحلية بسرعة عملية (أكثر من 15 إلى 30 رمزًا مميزًا “Token” في الثانية)، يعد اختيار الأجهزة (Hardware) هو الأمر الأكثر أهمية.

2.1 تكوين الأجهزة الموصى به

مع تطور أجهزة الكمبيوتر الخاصة بالذكاء الاصطناعي (AI PC)، تتغير أيضًا المواصفات المطلوبة.

نظام التشغيل (OS): Windows 11 Pro (إصدار 24H2 أو أحدث). يعد هذا ضروريًا للاستفادة الكاملة من ميزات WSL2، والإدارة المتقدمة للذاكرة، بالإضافة إلى استخدام أحدث واجهات برمجة التطبيقات (API) الخاصة بـ DirectML.
وحدة المعالجة المركزية (CPU): سلسلة Intel Core Ultra 200 أو أحدث، أو سلسلة AMD Ryzen 9000 أو أحدث. عند استخدام استدلال CPU معًا، فإن الاتصال بذاكرة ذات نطاق ترددي عالي يعد أمرًا لا غنى عنه.
ذاكرة الوصول العشوائي (RAM): الحد الأدنى 32 جيجابايت، ويُوصى بـ 64 جيجابايت أو أكثر. يصبح النطاق الترددي للذاكرة الرئيسية (بالجيجابايت/ثانية) هو عنق الزجاجة (Bottleneck) الحاسم أثناء استدلال CPU أو عند تفريغ التحميل (Offloading). يُفضل استخدام ذاكرة عالية السرعة DDR5-6000 أو أعلى.
وحدة معالجة الرسومات (GPU): سلسلة NVIDIA RTX 4000/5000. الأهم في نماذج LLM المحلية ليس أداء الحوسبة بل “سعة ذاكرة الوصول العشوائي للفيديو (VRAM)”.
- فئة البداية (Entry): RTX 4060 Ti (نسخة 16 جيجابايت) - الأفضل من حيث التكلفة والأداء. مثالية لنماذج بحجم 8B إلى 14B.
- الفئة المتوسطة (Mid-range): RTX 4070 Ti SUPER (16 جيجابايت) / RTX 4080 SUPER (16 جيجابايت).
- الفئة المتقدمة (High-end): RTX 4090 (24 جيجابايت) / RTX 5090 (32 جيجابايت) - مطلوبة لتشغيل النماذج المكممة (Quantized models) بحجم 30B إلى 70B.
التخزين (Storage): محرك أقراص PCIe Gen4 أو Gen5 NVMe SSD. يقلل من وقت تحميل النماذج التي تبلغ مساحتها عشرات الجيجابايت بشكل كبير.

2.2 إعداد WSL2 (نظام ويندوز الفرعي لنظام لينكس 2)

تعمل العديد من أدوات واجهة المستخدم الرسومية (GUI) بشكل أصلي (Native) على ويندوز، ولكن WSL2 مفيد جدًا للتطوير باستخدام بايثون (Python)، وتجميع أحدث الأدوات، وإجراء الضبط الدقيق (LoRA Fine-tuning) الذي سيتم شرحه لاحقًا. في أحدث بيئة لـ Windows 11، يمكنك استخدام GPU (CUDA) بشفافية من WSL2 بمجرد تثبيت برنامج تشغيل NVIDIA على النظام المضيف.

افتح PowerShell بصلاحيات المسؤول (Administrator) وقم بتشغيل ما يلي:

1
2
3
4
5


# تثبيت WSL2 وأحدث إصدار من Ubuntu
wsl --install -d Ubuntu-24.04

# تحديث النواة (Kernel)
wsl --update

بعد التثبيت، قم بتشغيل nvidia-smi داخل وحدة تحكم WSL2، وإذا تم التعرف على GPU بشكل صحيح، فقد نجحت العملية.

3. بنية نموذج LLM المحلي وآلية الاستدلال (Inference)

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

يوضح مخطط Mermaid التالي خط أنابيب (Pipeline) الاستدلال النموذجي لـ LLM المحلي.

graph TD User["إدخال المستخدم (الموجه/Prompt)"] --> Tokenizer["أداة الترميز (Tokenizer)"] Tokenizer --> Embedding["طبقة التضمين (Embedding)"] subgraph "كتلة المحول (Transformer Block) (x طبقات)" Embedding --> Attn["الانتباه الذاتي (Self-Attention)"] Attn --> KVCache["ذاكرة التخزين المؤقت KV (الاحتفاظ بالمفتاح/القيمة)"] Attn --> FFN["شبكة التغذية الأمامية (FFN)"] end FFN --> Logits["حساب اللوجيت (Logits)"] Logits --> Sampler["أداة أخذ العينات (Temperature, Top-K, Top-P)"] Sampler --> OutputToken["الرمز المميز المخرج (Output Token)"] OutputToken --> |"التوليد التلقائي الانحداري"| Tokenizer OutputToken --> Decoder["أداة فك الترميز (Detokenizer)"] Decoder --> FinalOutput["النص النهائي المخرج"]

3.1 مرحلتان: التعبئة المسبقة (Prefill) وفك التشفير (Decode)

ينقسم إنشاء النص بواسطة LLM إلى مرحلتين تختلفان في الخصائص الحسابية:

مرحلة التعبئة المسبقة (معالجة الموجه - Prefill): هي المرحلة التي يتم فيها معالجة وفهم موجه الإدخال (Prompt) بأكمله مرة واحدة. نظرًا لإمكانية الحوسبة المتوازية، ترتبط قدرة حساب GPU (FLOPS) بشكل مباشر بالسرعة. إذا كان الموجه طويلاً، فقد تستغرق هذه المرحلة بضع ثوانٍ.
مرحلة فك التشفير (توليد الرموز المميزة - Decode): هي المرحلة التي يتم فيها التنبؤ برمز مميز واحد في كل مرة وتمريره إلى الإدخال التالي (التوليد التلقائي الانحداري - Autoregressive). نظرًا لأن الحوسبة المتوازية مقيدة في هذه المرحلة، فإن عرض النطاق الترددي لـ VRAM في GPU يصبح عنق الزجاجة الحاسم.

4. حساب استهلاك VRAM والفهم الرياضي لحجم النموذج

لتحكم بشكل صحيح على “ما هو النموذج الذي سيعمل على جهاز الكمبيوتر الخاص بي؟"، تحتاج إلى فهم معادلة حساب VRAM. في حالة حدوث تراجع (Fallback) إلى ذاكرة النظام (RAM) بسبب نقص VRAM، ستنخفض سرعة الاستدلال بمقدار 10 إلى 100 مرة.

4.1 VRAM الأساسي بناءً على حجم المعلمة (Parameter)

هو مقدار الذاكرة المطلوب لتحميل أوزان (Weights) النموذج في VRAM. يتم حسابه باستخدام حجم النموذج $P$ (عدد المعلمات، الوحدة: 1 مليار = 1B) وعدد البايتات لكل معلمة $B$.

$$ V_{base} = P \times B \quad \text{(GB)} $$

على سبيل المثال، عند تحميل نموذج بـ 8B (8 مليارات) معلمة بتنسيق FP16 (فاصلة عائمة نصف الدقة، 16 بت = 2 بايت):

$$ V_{base} = 8 \times 2 = 16 \text{ GB} $$

بمعنى آخر، حتى مع وحدة معالجة رسومات تحتوي على 16 جيجابايت من VRAM، ستصل إلى الحد الأقصى تقريبًا بمجرد تحميل النموذج.

4.2 سحر التكميم (Quantization)

وهنا يأتي دور “التكميم”. من خلال تقليل دقة المعلمات، يتم تصغير حجم النموذج بشكل كبير. في حالة التكميم الأكثر شيوعًا 4 بت (مثل: Q4_K_M)، يبلغ المتوسط حوالي 0.55 بايت لكل معلمة.

$$ V_{base\_4bit} = 8 \times 0.55 = 4.4 \text{ GB} $$

وبالتالي، إذا كان لديك 16 جيجابايت من VRAM، فيمكنك بسهولة تشغيل نموذج 8B بوجود مساحة إضافية كافية.

4.3 حساب ذاكرة التخزين المؤقت KV (إصدار يدعم GQA)

أثناء الاستدلال، تستهلك “ذاكرة التخزين المؤقت KV” التي تحتفظ بالسياق الماضي VRAM. في أحدث النماذج مثل Llama 3، يتم استخدام GQA (الانتباه الاستعلامي المجمع - Grouped Query Attention) لتوفير الذاكرة.

يمكن التعبير عن استهلاك ذاكرة التخزين المؤقت KV $V_{kv}$ (بالجيجابايت) بالصيغة الرياضية التالية:

$$ V_{kv} = 2 \times b \times s \times l \times \left( \frac{h_{kv}}{h_q} \right) \times h_q \times d \times B_{kv} \div 10^9 $$

عند التبسيط، يمكن حسابها ببساطة باستخدام عدد رؤوس المفاتيح والقيم $h_{kv}$:

$$ V_{kv} = 2 \times b \times s \times l \times h_{kv} \times d \times B_{kv} \div 10^9 $$

حيث أن:

$b$: حجم الدفعة (عادة 1 للاستخدام الشخصي المحلي)
$s$: طول التسلسل (طول السياق، مثال: 8192)
$l$: عدد الطبقات (مثال: 32)
$h_{kv}$: عدد رؤوس KV (مثال: 8)
$d$: عدد الأبعاد لكل رأس (مثال: 128)
$B_{kv}$: عدد البايتات لذاكرة التخزين المؤقت KV (2 إذا كان FP16)

مثال للحساب (Llama 3 8B، سياق 8192، ذاكرة تخزين مؤقت FP16): $V_{kv} = 2 \times 1 \times 8192 \times 32 \times 8 \times 128 \times 2 \div 10^9 \approx 1.07 \text{ GB}$

يرجى ملاحظة أنه كلما زاد طول السياق $s$، زادت الحاجة إلى VRAM بشكل خطي.

5. الممارسة 1: إعداد أسرع وأقصر باستخدام Ollama

بمجرد فهم النظرية، دعنا نقم بتشغيل LLM فعليًا على بيئة ويندوز. اعتبارًا من عام 2026، فإن الأداة الأكثر سهولة في الاستخدام هي “Ollama”. فهي توفر واجهة سطر أوامر (CLI) بديهية تشبه Docker.

5.1 التثبيت والتشغيل

قم بتنزيل مثبت ويندوز من موقع Ollama الرسمي وقم بتشغيله.
افتح PowerShell وأدخل الأمر التالي. هنا، سنستخدم llama3:8b الذي يدعم اللغة اليابانية.

1

ollama run llama3:8b

في أول تشغيل، سيتم تنزيل النموذج. بمجرد الانتهاء، يمكنك التفاعل معه مباشرة في الجهاز الطرفي (Terminal).

5.2 إنشاء ذكاء اصطناعي مخصص باستخدام Modelfile

يمكنك بسهولة إنشاء ذكاء اصطناعي بشخصية (Persona) محددة. قم بإنشاء Modelfile في أي مكان تريده.

1
2
3
4
5
6
7
8
9


FROM llama3:8b

SYSTEM """
أنت مهندس برمجيات أول ممتاز جدًا.
يرجى الإجابة على أسئلة المستخدم بشكل منطقي وموجز، مع تقديم أمثلة التعليمات البرمجية دائمًا.
"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192

قم ببناء النموذج المخصص الخاص بك وتشغيله بالأوامر التالية:

1
2


ollama create SeniorDev -f ./Modelfile
ollama run SeniorDev

5.3 الاستخدام من التطبيقات الخارجية (محرر الذكاء الاصطناعي)

تكشف Ollama عن نقطة نهاية API متوافقة مع OpenAI على http://localhost:11434. من خلال تحديد عنوان URL هذا في إعدادات الخلفية (Backend) لإضافات VS Code مثل Cursor و Continue.dev، وتحديد اسم النموذج كـ SeniorDev أو ما شابه، ستحصل على مساعد تشفير (Coding) محلي قوي ومجاني.

6. الممارسة 2: ضبط الأداء الأقصى باستخدام llama.cpp

إذا كنت ترغب في إجراء إدارة دقيقة للذاكرة أو تجربة أحدث التنسيقات (مثل EXL2 وتكميم IQ) بسرعة، فسوف تتفاعل مباشرة مع المحرك الأساسي llama.cpp.

6.1 خطوات بناء llama.cpp

في بيئة ويندوز، من الأفضل بناءه من المصدر باستخدام CUDA Toolkit و CMake.

1
2
3
4
5
6
7
8


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

# التهيئة والتجميع ليكون متوافقًا مع CUDA
cmake .. -DLLAMA_CUBLAS=ON -DBUILD_SHARED_LIBS=OFF
cmake --build . --config Release -j 16

6.2 التشغيل المتقدم في وضع الخادم

استخدم llama-server.exe الذي تم بناؤه لاستضافة النموذج.

1
2
3
4
5
6
7


.\bin\Release\llama-server.exe `
 --model "C:\models\Llama-3-8B-Instruct.Q4_K_M.gguf" `
 --ctx-size 8192 `
 --n-gpu-layers 99 `
 --threads 8 `
 --flash-attn `
 --port 8080

--n-gpu-layers 99: نقل كل الطبقات الممكنة إلى VRAM الخاص بـ GPU.
--flash-attn: تمكين FlashAttention 3 لتحسين سرعة الاستدلال وتقليل استهلاك VRAM لذاكرة التخزين المؤقت KV.

7. واجهة المستخدم الرسومية (GUI): بناء LM Studio و RAG المحلي

إذا كنت لا تفضل استخدام سطر الأوامر، أو إذا كنت ترغب في إجراء التوليد المعزز بالاسترجاع (RAG) بشكل بديهي، فاستخدم واجهة مستخدم رسومية (GUI).

7.1 LM Studio

يعد LM Studio تطبيقًا رائعًا يجمع بين البحث عن النماذج، والتنزيل، والتحقق المسبق من متطلبات النظام، وواجهة مستخدم (UI) للدردشة في مكان واحد. بضغطة زر “Local Server” داخل التطبيق، سيتم تشغيل واجهة برمجة تطبيقات (API) متوافقة مع OpenAI.

7.2 بنية RAG باستخدام AnythingLLM

هذا هو المخطط المعماري لبيئة RAG التي تسمح بقراءة المستندات الداخلية للشركة والمذكرات الشخصية.

graph LR Document["المستند (PDF, MD)"] --> Chunking["تقسيم إلى كتل (Chunking)"] Chunking --> EmbedModel["نموذج التضمين (Embedding Model)"] EmbedModel --> VectorDB["قاعدة بيانات المتجهات (Vector Database)"] UserQuery["سؤال المستخدم"] --> EmbedQuery["تضمين السؤال"] EmbedQuery --> VectorDB VectorDB --> |"بحث عن التشابه"| RetrievedDocs["استخراج المستندات ذات الصلة"] UserQuery --> PromptBuilder["توليد الموجه (Prompt)"] RetrievedDocs --> PromptBuilder PromptBuilder --> LocalLLM["نموذج LLM محلي"] LocalLLM --> Answer["الإجابة النهائية"]

باستخدام إصدار سطح المكتب من AnythingLLM (لويندوز)، يمكنك تحديد Ollama (لـ LLM والتضمين) من شاشة الإعدادات، وإعداده لاستخدام VectorDB محلي (LanceDB)، وستكتمل هذه البنية في غضون بضع دقائق. هذه هي ولادة الذكاء الاصطناعي الخاص الذي لا يرسل البيانات إلى الخارج على الإطلاق.

8. الضبط الدقيق (LoRA) على Windows WSL2

لا يقتصر الأمر على التشغيل المحلي فحسب، بل إذا كنت ترغب في جعل النموذج أكثر ذكاءً باستخدام بياناتك الخاصة، فيمكنك إجراء الضبط الدقيق (Fine-tuning) باستخدام LoRA (التكيف منخفض الرتبة - Low-Rank Adaptation). اعتبارًا من عام 2026، وبفضل مكتبة تسمى “Unsloth”، يمكنك إكمال تدريب نموذج 8B في بضع ساعات حتى مع 16 جيجابايت من VRAM في بيئة Windows WSL2.

قم بتشغيل الأوامر التالية داخل Ubuntu في WSL2 لإعداد البيئة:

1
2
3
4


conda create --name unsloth_env python=3.11
conda activate unsloth_env
pip install "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git"
pip install --no-deps trl peft accelerate bitsandbytes

تعمل Unsloth على تحسين أنوية CUDA (CUDA kernels) إلى أقصى حد، وبالمقارنة مع مكتبة Hugging Face القياسية، فإن سرعة التدريب تزيد بحوالي الضعف، وينخفض استهلاك VRAM إلى النصف تقريبًا. بمجرد فتح Jupyter Notebook وتحميل مجموعة البيانات (بتنسيق JSONL)، يمكن إجراء التدريب لعدة عصور (Epochs) باستخدام أجهزة مثل RTX 4060 Ti مع 12 جيجابايت إلى 16 جيجابايت من VRAM.

9. استكشاف أخطاء الأداء وإصلاحها

فيما يلي المشكلات الشائعة والحلول الخاصة بها.

1. سرعة الاستدلال بطيئة للغاية (1 إلى 2 رمز / ثانية)

السبب: النموذج لا يتناسب مع VRAM وتم تحميله على ذاكرة النظام (RAM). الحل: تحقق من “ذاكرة GPU المخصصة” في إدارة المهام. إذا وصلت إلى الحد الأقصى، فقم بتقليل حجم السياق (-c)، أو استخدم نموذج تكميم بعدد بتات أقل (مثل Q4_K_M).

2. خطأ “CUDA out of memory”

السبب: تم استنفاد VRAM بالكامل. يحدث هذا بشكل خاص عندما تطول المحادثة وتتضخم ذاكرة التخزين المؤقت KV. الحل: قم بتقييد قيمة num_ctx بشكل مقصود في حالة Ollama، أو قيمة -c في حالة llama.cpp.

3. توليد اللغة (مثل اليابانية أو العربية) غريب

السبب: عدم تطابق قالب الموجه (Prompt template)، أو النموذج غير مدعوم. الحل: استخدم نموذجًا يحتوي اسمه على Instruct، وتأكد من تحديد القالب الصحيح (مثل تنسيق ChatML أو Llama3) الذي حدده منشئ النموذج في الأداة.

10. الخلاصة والآفاق المستقبلية

في عام 2026، لم يعد بناء نماذج LLM المحلية في بيئة ويندوز حكرًا على عدد قليل من المهندسين فقط. بفضل تحول تنسيق GGUF إلى معيار أساسي، وظهور أنظمة بيئية محسّنة مثل Ollama و LM Studio، والتحسينات على مستوى الأجهزة (Hardware) مثل FlashAttention، يمكن لأي شخص الآن بسهولة الحصول على بيئة ذكاء اصطناعي بمستوى الشركات (Enterprise-grade).

يرجى الاستفادة من النقاط التالية المشروحة في هذا المقال:

استخدم الحساب الرياضي لـ VRAM لاختيار حجم النموذج ومستوى التكميم المناسبين لمنطق مواصفات جهاز الكمبيوتر الخاص بك.
استخدم Ollama لإعداد بيئة بأسرع وقت، وربطها مع محرر الذكاء الاصطناعي لتحسين الإنتاجية بشكل كبير.
استخدم التحكم المتقدم في المعلمات من خلال llama.cpp لاستخراج أقصى أداء ممكن للأجهزة.
قم ببناء نظام RAG محلي آمن للتعامل مع البيانات السرية باستخدام AnythingLLM.
استفد من Unsloth (WSL2) لتطوير وتدريب ذكاء اصطناعي مخصص يمتلك معرفتك المتخصصة الخاصة.

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