AI on kenji.blog

أمثلة تطبيقية وأكواد برمجية لأحدث واجهات برمجة تطبيقات Microsoft.Windows.AI

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

أمثلة تطبيقية وأكواد برمجية لأحدث واجهات برمجة تطبيقات Microsoft.Windows.AI: استكشاف أعماق Windows Copilot Runtime

1. مقدمة: عصر جديد لـ Windows يتم فيه دمج الذكاء الاصطناعي أصلياً

في السنوات الأخيرة، كان تطور تقنية الذكاء الاصطناعي ملحوظًا، وهناك تحول سريع في النموذج من استخدام النماذج اللغوية الكبيرة (LLMs) في السحابة إلى استنتاج الذكاء الاصطناعي على الأجهزة الطرفية (الحواسيب المحلية). في قلب هذا التحول يوجد “Windows Copilot Runtime” الذي توفره Microsoft لنظام التشغيل Windows 11، وواجهة برمجة تطبيقات “Microsoft.Windows.AI” للتحكم فيه.

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

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

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

Windows Copilot Runtime عبارة عن حزمة ذكاء اصطناعي مصممة للسماح للمطورين بدمج نماذج الذكاء الاصطناعي بسهولة في Windows وتحقيق أقصى قدر من الأداء. يعمل هذا وقت التشغيل (Runtime) على تجريد تسريع الأجهزة على مستوى نظام التشغيل (OS) ويوفر واجهة موحدة للمطورين.

graph TD App["تطبيقات Windows (C# / C++)"] --> API["واجهات برمجة تطبيقات Microsoft.Windows.AI"] App --> ORT["ONNX Runtime"] API --> WCR["Windows Copilot Runtime (طبقة نظام التشغيل)"] WCR --> SLM["النماذج المحلية (Phi-Silica، وغيرها)"] ORT --> DML["مزود تنفيذ DirectML"] SLM --> DML DML --> DXCore["DXCore / DirectX 12"] DXCore --> NPU["NPU (وحدة المعالجة العصبية)"] DXCore --> GPU["GPU (وحدة معالجة الرسومات)"] DXCore --> CPU["CPU"]

كما يوضح مخطط البنية أعلاه، يمكن للتطبيقات الوصول مباشرة إلى النماذج اللغوية الصغيرة (SLM: مثل Phi-Silica) المدمجة في نظام التشغيل باستخدام واجهة برمجة التطبيقات Microsoft.Windows.AI عالية المستوى. أيضًا، عند استخدام نماذج مخصصة، يمكن استخدام تسريع الأجهزة صراحةً من خلال ONNX Runtime وDirectML. نظرًا لأن طبقة نظام التشغيل تعمل على تحسين توزيع أعباء العمل على وحدة المعالجة المركزية (CPU) ووحدة معالجة الرسومات (GPU) ووحدة المعالجة العصبية (NPU)، يمكن للمطورين بناء تطبيقات ذكاء اصطناعي عالية الأداء دون الحاجة إلى القلق العميق بشأن اختلافات الأجهزة.

3. تسريع الأجهزة والالتقييم الرياضي لـ NPU

تم تجهيز أحدث أجهزة Copilot+ PC بـ NPU (وحدة المعالجة العصبية)، وهي معالجات متخصصة في معالجة الذكاء الاصطناعي. يتم تقييم أداء NPU عمومًا بـ TOPS (تريليون عملية في الثانية).

في استنتاج نماذج الذكاء الاصطناعي، وخاصة قدرة حساب ضرب المصفوفات (GEMM: General Matrix Multiply)، هي التي تحدد الإنتاجية. يُقدر الحد الأقصى للأداء النظري $P_{\text{peak}}$ للأجهزة بالصيغة التالية.

$$ P_{\text{peak}} = f \times N_{\text{cores}} \times N_{\text{MACs/core}} \times 2 $$

حيث:

$f$ هو تردد ساعة NPU (بهرتز)
$N_{\text{cores}}$ هو عدد النوى في NPU
$N_{\text{MACs/core}}$ هو عدد وحدات MAC (الضرب والتراكم) لكل نواة
الـ $2$ الأخير يرجع إلى أن عملية MAC واحدة تُحسب كعمليتين (الضرب والجمع) (FLOPs/OPs).

على سبيل المثال، بالنسبة لـ NPU بتردد 1.5 جيجاهرتز و4 نوى، وكل نواة تحتوي على 4096 وحدة MAC،

$$ P_{\text{peak}} = 1.5 \times 10^9 \times 4 \times 4096 \times 2 \approx 49.15 \text{ TOPS} $$

كما يظهر رياضيًا، هذا الأداء يتجاوز متطلبات 40 TOPS لأجهزة Copilot+ PC في Windows 11.

بالإضافة إلى ذلك، فإن استنتاج نماذج الذكاء الاصطناعي، وخاصة نماذج LLM (مرحلة فك التشفير)، يميل إلى أن يكون مقيدًا بالذاكرة (Memory-Bound). يُحسب عرض النطاق الترددي النظري $BW$ لذاكرة النظام على النحو التالي.

$$ BW = f_{\text{mem}} \times W_{\text{bus}} \times \frac{2}{8} $$

في حالة ذاكرة LPDDR5x-8533 ($f_{\text{mem}} = 8533 \text{ MT/s}$) وناقل 128 بت ($W_{\text{bus}} = 128$)، سيكون عرض النطاق الترددي حوالي $136 \text{ GB/s}$. في تحسين تطبيقات الذكاء الاصطناعي، من المهم كيفية الحفاظ على عرض النطاق الترددي هذا، وتصبح عملية تكميم النموذج (Quantization)، التي سيتم وصفها لاحقًا، ضرورية.

4. إعداد بيئة التطوير

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

نظام التشغيل: Windows 11 الإصدار 24H2 أو أحدث (يُوصى بشدة بالأجهزة المزودة بـ NPU والتي تلبي متطلبات Copilot+ PC)
حزمة تطوير البرامج (SDK): Windows App SDK (إصدار يدعم امتداد الذكاء الاصطناعي v1.5 أو أحدث)
بيئة التطوير: Visual Studio 2022 (v17.10 أو أحدث)، مع أعباء عمل التطوير الأصلي باستخدام C++ وتطوير سطح مكتب .NET
الحزم: قم بتثبيت Microsoft.Windows.AI و Microsoft.ML.OnnxRuntime.DirectML عبر NuGet

1
2
3
4
5
6


<!-- مثال على إعداد .csproj -->
<ItemGroup>
 <PackageReference Include="Microsoft.Windows.AI" Version="1.0.0-preview1" />
 <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.5.240311000" />
 <PackageReference Include="Microsoft.ML.OnnxRuntime.DirectML" Version="1.17.1" />
</ItemGroup>

5. [التعمق 1] استخدام النماذج اللغوية المحلية (Phi-Silica) باستخدام C#

يتضمن Windows Copilot Runtime نموذج لغوي صغير عالي الكفاءة يُسمى “Phi-Silica” طورته Microsoft كمكون قياسي في نظام التشغيل. يتيح ذلك معالجة متقدمة للغة الطبيعية (تلخيص النصوص، إنشاء الأكواد، روبوتات الدردشة) في بيئة غير متصلة بالإنترنت، دون الحاجة إلى تنزيل نماذج بحجم جيجابايت من الشبكة.

فيما يلي نموذج كود متقدم لإنشاء روبوت دردشة ذكاء اصطناعي باستخدام C# ومساحة الأسماء Microsoft.Windows.AI.Generative. وهو يدعم استجابات البث المتدفق ويقوم بإنشاء نصوص في الوقت الفعلي دون حظر خيط واجهة المستخدم (UI thread).

 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


using System;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Windows.AI.Generative;

namespace WindowsAI.Sample
{
 public class LocalLanguageModelService
 {
 private LanguageModel _languageModel;
 private bool _isInitialized = false;

 /// <summary>
 /// يقوم بتهيئة النموذج اللغوي. يتحقق من توفر NPU ويحمل النموذج على أفضل جهاز.
 /// </summary>
 public async Task InitializeAsync()
 {
 if (_isInitialized) return;

 Console.WriteLine("التحقق من متطلبات النظام وتوافر نموذج الذكاء الاصطناعي المحلي (Phi-Silica)...");

 // التحقق مما إذا كان النموذج متاحًا في النظام (قد يُطلب التنزيل إذا لم يكن مدعومًا)
 var availability = await LanguageModel.CheckAvailabilityAsync();
 if (availability != LanguageModelAvailability.Available)
 {
 throw new InvalidOperationException($"نموذج الذكاء الاصطناعي المحلي غير متاح حاليًا. الحالة: {availability}");
 }

 // إنشاء مثيل النموذج (في هذا الوقت يتم التعيين إلى مساحة الذاكرة وتهيئة NPU)
 _languageModel = await LanguageModel.CreateAsync();
 _isInitialized = true;

 Console.WriteLine("تمت تهيئة النموذج اللغوي. تسريع الأجهزة عبر DirectML نشط.");
 }

 /// <summary>
 /// يستقبل مطالبة المستخدم ويولد استجابة عبر البث المتدفق.
 /// </summary>
 public async Task GenerateResponseStreamAsync(string prompt, CancellationToken cancellationToken)
 {
 if (!_isInitialized) await InitializeAsync();

 Console.WriteLine($"\n[إدخال المستخدم]: {prompt}\n[مساعد الذكاء الاصطناعي]: ");

 // إعداد المعلمات الفائقة (Hyperparameters) للإنشاء
 var options = new LanguageModelOptions
 {
 Temperature = 0.7f,
 TopP = 0.9f,
 MaxTokens = 2048,
 RepetitionPenalty = 1.1f
 };

 // بناء سياق المحادثة
 var context = new LanguageModelContext();
 context.AddSystemMessage("أنت مساعد ذكاء اصطناعي متقدم تعمل مباشرة على وحدة NPU المحلية لنظام Windows. يرجى التفكير منطقياً خطوة بخطوة والإجابة بإيجاز.");
 context.AddUserMessage(prompt);

 try
 {
 // استدعاء واجهة برمجة تطبيقات الاستنتاج عبر البث
 var responseStream = _languageModel.GenerateResponseStreamAsync(context, options);

 // التكرار غير المتزامن للقطع (chunks) التي يتم إرجاعها كـ IAsyncEnumerable
 await foreach (var chunk in responseStream.WithCancellation(cancellationToken))
 {
 // إخراج الرموز (القطع) المُنشأة إلى وحدة التحكم في الوقت الفعلي
 // بالنسبة لتطبيقات واجهة المستخدم (UI)، استخدم DispatcherQueue هنا لعكسها في TextBox وما إلى ذلك
 Console.Write(chunk.Text);
 }
 Console.WriteLine();
 }
 catch (OperationCanceledException)
 {
 Console.WriteLine("\n[تم إلغاء الإنشاء بواسطة المستخدم أو النظام]");
 }
 catch (Exception ex)
 {
 Console.WriteLine($"\n[حدث خطأ فادح: {ex.Message}]");
 }
 }
 }
}

5.1 شرح البنية في تنفيذ C#

يكمن جوهر هذا الكود في التحقق قبل التنفيذ باستخدام LanguageModel.CheckAvailabilityAsync() والبث غير المتزامن باستخدام GenerateResponseStreamAsync. عندما يتلقى Copilot Runtime الذي يعمل في خلفية نظام التشغيل استدعاء واجهة برمجة التطبيقات هذا، فإنه يبدأ تشغيل ONNX Runtime داخليًا ويختار أفضل موفر تنفيذ (Execution Provider) (DirectML + NPU في العديد من أجهزة الكمبيوتر الحديثة) وفقًا لتكوين النظام.

يمكن للمطورين دمج أحدث خطوط أنابيب استنتاج الذكاء الاصطناعي في تطبيقاتهم ببضعة أسطر من كود C# دون الحاجة إلى القلق بشأن شكل موتر النموذج (Tensor Shape)، أو تنفيذ المُرمِّز (Tokenizer)، أو إدارة ذاكرة التخزين المؤقت KV (KV Cache).

6. [التعمق 2] الاستنتاج عالي السرعة للنماذج المخصصة باستخدام C++ و DirectML

عند التعامل مع مجالات معينة (تجزئة الصور الخاصة، التعرف على الصوت، نماذج اكتشاف الكائنات المخصصة، إلخ) التي لا يمكن تغطيتها بواسطة النماذج اللغوية القياسية لنظام التشغيل فقط، يحتاج المطورون إلى معالجة ONNX Runtime وDirectML مباشرة، والتي تقع في الطبقات الدنيا من Microsoft.Windows.AI.

باستخدام C++، يمكنك تحسين تخصيص الذاكرة إلى أقصى حد واستخراج أقصى أداء من NPU/GPU. فيما يلي تنفيذ أساسي لخط أنابيب التهيئة والاستنتاج المتقدم لتشغيل النماذج المخصصة بصيغة ONNX (مثل YOLOv8) في C++ باستخدام DirectML.

 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
94
95
96
97
98
99


#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>
#include <onnxruntime_cxx_api.h>
#include <dml_provider_factory.h>

class CustomVisionAIProcessor {
private:
 Ort::Env env;
 Ort::Session session{nullptr};
 Ort::AllocatorWithDefaultOptions allocator;

public:
 CustomVisionAIProcessor(const std::wstring& modelPath)
 : env(ORT_LOGGING_LEVEL_WARNING, "VisionAIProcessor") {

 Ort::SessionOptions sessionOptions;
 // تحسين عدد الخيوط (Threads)
 sessionOptions.SetIntraOpNumThreads(1);
 // تعيين مستوى تحسين الرسم البياني (Graph Optimization Level) إلى الحد الأقصى
 sessionOptions.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL);

 // 1. إضافة مزود تنفيذ DirectML (DML EP)
 // device_id = 0 هو المحول الافتراضي الموصى به للنظام (NPU أو GPU عالي الأداء)
 const OrtApi& ortApi = Ort::GetApi();
 OrtDmlApi* dmlApi = nullptr;
 OrtStatus* status = ortApi.GetExecutionProviderApi("DML", ORT_API_VERSION, reinterpret_cast<void**>(&dmlApi));

 if (status == nullptr && dmlApi != nullptr) {
 Ort::ThrowOnError(dmlApi->SessionOptionsAppendExecutionProvider_DML(sessionOptions, 0));
 std::cout << "[معلومات] تم إرفاق مزود تنفيذ DirectML بنجاح." << std::endl;
 } else {
 std::cerr << "[تحذير] فشل الحصول على واجهة برمجة تطبيقات DirectML. سيتم التشغيل في وضع التراجع إلى وحدة المعالجة المركزية (CPU Fallback Mode)." << std::endl;
 if (status != nullptr) ortApi.ReleaseStatus(status);
 }

 // 2. تحميل النموذج وإنشاء الجلسة
 try {
 session = Ort::Session(env, modelPath.c_str(), sessionOptions);
 std::cout << "[معلومات] تم تحميل نموذج ONNX بنجاح، وتم تجميع الرسم البياني الحسابي." << std::endl;
 } catch (const Ort::Exception& e) {
 std::cerr << "[خطأ] فشل تحميل النموذج: " << e.what() << std::endl;
 throw;
 }
 }

 void RunInference(const std::vector<float>& imageTensor, const std::vector<int64_t>& inputShape) {
 // 3. إنشاء مخزن مؤقت (Buffer) لموتر الإدخال (Input Tensor)
 Ort::MemoryInfo memoryInfo = Ort::MemoryInfo::CreateCpu(OrtArenaAllocator, OrtMemTypeDefault);
 Ort::Value inputTensor = Ort::Value::CreateTensor<float>(
 memoryInfo,
 const_cast<float*>(imageTensor.data()),
 imageTensor.size(),
 inputShape.data(),
 inputShape.size()
 );

 // 4. الحصول ديناميكيًا على أسماء عقد الإدخال والإخراج
 auto inputNamePtr = session.GetInputNameAllocated(0, allocator);
 auto outputNamePtr = session.GetOutputNameAllocated(0, allocator);
 const char* inputNames[] = { inputNamePtr.get() };
 const char* outputNames[] = { outputNamePtr.get() };

 // 5. تنفيذ الاستنتاج (يتم تفريغه (offloaded) إلى NPU/GPU عبر DirectML)
 std::cout << "[معلومات] بدء تنفيذ محرك الاستنتاج..." << std::endl;
 auto startTime = std::chrono::high_resolution_clock::now();

 auto outputTensors = session.Run(Ort::RunOptions{nullptr}, inputNames, &inputTensor, 1, outputNames, 1);

 auto endTime = std::chrono::high_resolution_clock::now();
 auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(endTime - startTime);

 // 6. استرداد موتر النتيجة وتحليله
 float* outputData = outputTensors.front().GetTensorMutableData<float>();
 size_t outputSize = outputTensors.front().GetTensorTypeAndShapeInfo().GetElementCount();

 std::cout << "[النتيجة] اكتمل الاستنتاج: " << duration.count() << " مللي ثانية" << std::endl;
 std::cout << "[النتيجة] عدد عناصر موتر الإخراج: " << outputSize << std::endl;
 // * بعد ذلك، يتم تنفيذ القمع غير الأقصى (NMS) وعمليات رسم الصناديق المحيطة (Bounding Boxes) على موتر الإخراج
 }
};

int main() {
 try {
 // مسار نموذج ONNX المراد تنفيذه
 CustomVisionAIProcessor processor(L"models/yolov8n_quantized.onnx");

 // بيانات صورة وهمية للاستنتاج (حجم الدُفعة (Batch Size) 1 × 3 قنوات × 640 × 640)
 std::vector<int64_t> inputShape = {1, 3, 640, 640};
 std::vector<float> dummyImage(1 * 3 * 640 * 640, 0.5f);

 processor.RunInference(dummyImage, inputShape);
 } catch (const std::exception& e) {
 std::cerr << "انتهى البرنامج بشكل غير طبيعي: " << e.what() << std::endl;
 return -1;
 }
 return 0;
}

6.1 أهمية إدارة الذاكرة والاستنتاج الخالي من النسخ (Zero-Copy) في C++

أكبر ميزة لاستخدام DirectML في C++ هي التكامل الوثيق الممكن مع DirectX 12 (DX12). يتضمن الكود أعلاه نسخة قياسية من بيانات ذاكرة وحدة المعالجة المركزية للأغراض التعليمية، ولكن في محركات الألعاب الفعلية أو تطبيقات معالجة الفيديو، غالبًا ما يتم الاحتفاظ بالصور (الأنسجة (Textures)) بالفعل في مساحة ذاكرة وحدة معالجة الرسومات (GPU) أو وحدة المعالجة العصبية (NPU) باستخدام DX12.

في هذه الحالة، من خلال الاستفادة من ميزات الربط المتقدمة لـ OrtDmlApi، من الممكن تحقيق “الاستنتاج الخالي من النسخ (Zero-Copy Inference)"، والذي يعين موارد DX12 مباشرة كموترات (Tensors) لـ ONNX Runtime. نتيجة لذلك، يختفي تمامًا العبء الإضافي لنقل البيانات عبر ناقل PCIe (استهلاك النطاق الترددي $BW$ المذكور أعلاه)، ويتحسن معدل الإطارات في معالجة الفيديو في الوقت الفعلي بشكل كبير.

7. تحسين الأداء وأفضل الممارسات

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

7.1 تكميم النموذج (Quantization) ومجموعة أدوات Olive

لإطلاق العنان للقوة الحقيقية لـ NPU، فإن الشرط المطلق هو تكميم (Quantization) أوزان وتنشيطات نموذج الذكاء الاصطناعي من FP32 (الفاصلة العائمة أحادية الدقة) إلى INT8 أو INT4. تم تحسين بنية NPU لعمليات الأعداد الصحيحة، ويوفر INT8 إنتاجية أعلى من الناحية النظرية بـ 4 أضعاف وتوفيرًا كبيرًا في الطاقة مقارنة بـ FP32.

باستخدام سلسلة أدوات Olive (ONNX Live) التي توفرها Microsoft، يمكن تحسين نماذج مثل PyTorch تلقائيًا لبيئات Windows. يوفر Olive دعمًا قويًا لتحسينات الانتباه (Attention) الخاصة لنماذج المحولات (Transformer models) وتجميع الرسوم البيانية (Graph compilation) الخاصة بالأجهزة.

7.2 مقايضة بين معالجة الدفعات (Batch Processing) والبث التفاعلي

في استدعاءات واجهة برمجة التطبيقات، يمكن أن تؤدي معالجة الدفعات لطلبات استنتاج متعددة إلى زيادة كفاءة استخدام NPU (Compute Utilization). ومع ذلك، بالنسبة لواجهات المستخدم التفاعلية مثل روبوتات الدردشة، فإن الوقت المستغرق لعرض الرمز الأول (TTFT: Time To First Token) يحدد تجربة المستخدم (UX) أكثر من الإنتاجية. لذلك، بالنسبة لواجهات المستخدم التفاعلية، فإن أفضل ممارسة هي تعيين حجم الدفعة إلى 1 وتحديد أولوية الإنشاء المتدفق.

7.3 مهام الخلفية والتكامل مع نظام التشغيل

يستهلك استنتاج الذكاء الاصطناعي كمية كبيرة من الطاقة المحلية وموارد النظام. بالاشتراك مع واجهة برمجة تطبيقات App Lifecycle API في Windows، عندما يعمل التطبيق في الخلفية، يُطلب تعليق (Suspend) مهام الاستنتاج ذات الأولوية المنخفضة أو تقييد استهلاك الموارد.

sequenceDiagram participant User as "المستخدم" participant App as "تطبيق Windows (C#)" participant API as "Microsoft.Windows.AI" participant OS as "Windows Copilot Runtime" participant ORT as "ONNX Runtime (DML)" participant NPU as "جهاز NPU" User->>App: "إدخال المطالبة" App->>API: "GenerateResponseStreamAsync()" API->>OS: "إرسال مهمة الاستنتاج" OS->>ORT: "طلب تنفيذ الرسم البياني" ORT->>NPU: "تنفيذ قائمة الأوامر عبر DirectML" NPU-->>ORT: "اكتمل الحساب (تم إنشاء رمز واحد)" ORT-->>OS: "نتيجة الموتر" OS-->>API: "نص تم فك تشفيره" API-->>App: "قطع (Chunks) كـ IAsyncEnumerable" App-->>User: "رسم النص في الوقت الفعلي على واجهة المستخدم" Note over ORT,NPU: "تتكرر هذه الحلقة بسرعة حتى تكتمل"

يوضح مخطط التسلسل هذا جمال المعالجة غير المتزامنة حيث تتدفق البيانات بسلاسة من الأجهزة الأساسية (NPU) في أدنى مستوى إلى طبقة العرض الخاصة بالتطبيق دون حظر خيط واجهة المستخدم (UI thread) على الإطلاق.

8. الآفاق المستقبلية وتطور Windows AI

تتطور واجهة برمجة تطبيقات Microsoft.Windows.AI و Copilot Runtime بسرعة في الوقت الحاضر. من المتوقع حدوث التحولات التالية في التحديثات المستقبلية للمطورين:

تكامل أصلي لواجهة برمجة تطبيقات متعددة الوسائط (Multimodal API) في نظام التشغيل: المعالجة المتزامنة السلسة ليس فقط للنصوص ولكن أيضًا للصوت، الصور، وحتى خلاصات الفيديو الحية، مما يوفر استنتاج ذكاء اصطناعي متعدد الوسائط كمعيار قياسي على مستوى نظام التشغيل.
دعم على مستوى النظام لـ RAG (الجيل المعزز بالاسترجاع): بناء مساعد ذكاء اصطناعي شخصي متقدم للغاية عن طريق ربط مجموعة المستندات الشخصية في جهاز الكمبيوتر المحلي أو فهرس Windows Search بنموذج الذكاء الاصطناعي في بيئة (Sandbox) آمنة داخل نظام التشغيل، مع حماية خصوصية المستخدم بشكل كامل.
توسيع النطاق الديناميكي لموارد NPU: عندما تعمل تطبيقات ذكاء اصطناعي متعددة في نفس الوقت (على سبيل المثال، إلغاء الضوضاء في الخلفية وإنشاء الأكواد في المقدمة)، يقوم مجدول النواة (Kernel Scheduler) في Windows بتبديل سياق تنفيذ NPU ديناميكيًا لضمان جودة الخدمة (QoS).

9. الخلاصة: مستقبل التطبيقات التي يغيرها الذكاء الاصطناعي المحلي

جلب Copilot Runtime و واجهة برمجة التطبيقات Microsoft.Windows.AI في Windows 11 سلاحًا قويًا للغاية يُسمى “الذكاء الاصطناعي المحلي” لجميع مطوري Windows. لم يعد من الضروري الاعتماد بالكامل على واجهات برمجة التطبيقات السحابية. من الممكن تزويد المستخدمين بتجربة ذكاء اصطناعي من الجيل التالي تقضي على زمن الوصول، وتحمي الخصوصية، وتعمل بشكل كامل حتى في وضع عدم الاتصال.

استخدم المعرفة بدمج النماذج اللغوية القياسية للنظام باستخدام C#، والتقييم الرياضي للأداء، وتحسين الأجهزة المتقدم باستخدام C++ و DirectML المشروح في هذه المقالة لإنشاء تطبيقات Windows من الجيل التالي “الأصلية للذكاء الاصطناعي” بيديك. الاحتمالات اللانهائية التي يوفرها الذكاء الاصطناعي تكمن مباشرة وراء الكود الذي تكتبه.

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

لا حاجة لبايثون! بناء محرك استدلال للذكاء الاصطناعي باستخدام 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 بأسرع طريقة في بيئة محلية

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 الخاص بشركتك.

كيف يجب أن ينجو المبرمجون في عصر الذكاء الاصطناعي؟

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

كيف يجب أن ينجو المبرمجون في عصر الذكاء الاصطناعي؟ نهاية البرمجة وبداية فجر جديد لهندسة البرمجيات

اعتبارًا من عام 2026، يشهد مجال تطوير البرمجيات فترة من التغيير الجذري غير المسبوق. حتى سنوات قليلة مضت، كان مفهوم “الذكاء الاصطناعي يكتب التعليمات البرمجية” يقتصر على كونه أداة مساعدة للمبرمجين، مثل إنشاء الأكواد النمطية (boilerplate) أو الإكمال التلقائي للدوال. ولكن، مع التطور المذهل للنماذج اللغوية الكبيرة (LLMs)، انقلبت الأمور رأسًا على عقب. فالذكاء الاصطناعي الحديث ليس مجرد “آلة كاتبة ذكية”؛ بل تحول إلى “مهندس مبتدئ مستقل” قادر على بناء أنظمة كاملة بشكل لحظي ومستقل، من الواجهة الأمامية إلى منطق الواجهة الخلفية، وتصميم مخطط قاعدة البيانات، وحتى بناء خطوط أنابيب CI/CD، بمجرد تزويده بمستند متطلبات.

في مثل هذا العصر، كيف يمكننا نحن “المبرمجين” و"مهندسي البرمجيات" البقاء على قيد الحياة؟ مع الانكماش السريع للقيمة الاقتصادية لفعل “كتابة الأكواد” نفسه، فإن “المبرمج” الذي يعرف فقط بناء الجملة (الـ syntax) للغة برمجة معينة ويتقن واجهات برمجة التطبيقات (API) لإطار عمل محدد يتم إقصاؤه سريعًا من السوق.

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

1. تاريخ التجريد (Abstraction) وإعادة تعريف “البرمجة”

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

كان علماء الكمبيوتر الأوائل يتفاعلون مع مفاتيح الأجهزة المادية مباشرة باستخدام البطاقات المثقبة، ويعطون التعليمات للكمبيوتر بلغة الآلة (سلسلة من الأصفار والآحاد). بعد ذلك، ظهرت لغة التجميع (Assembly)، والتي أتاحت للبشر التحكم في الأجهزة باستخدام اختصارات سهلة الفهم. ومع تقدم الزمن، ظهرت لغات عالية المستوى مثل C و Fortran، ونجحت في تغليف التفاصيل المعقدة للأجهزة مثل إدارة الذاكرة وسجلات وحدة المعالجة المركزية. ثم من خلال لغات حديثة مثل Java و Python و Ruby و TypeScript، أصبح بإمكان المبرمجين التركيز أكثر على “ما نريد أن يفعله الكمبيوتر (What)” بدلاً من “كيفية تشغيل الكمبيوتر (How)”.

ظهور الذكاء الاصطناعي (LLM) هو التحول النموذجي الأحدث والأكبر في تاريخ التجريد هذا. إذا كان تطور لغات البرمجة بمثابة “إخفاء للأجهزة”، فإن تطور النماذج اللغوية الكبيرة هو “إخفاء لقواعد اللغة (syntax)”.

graph TD A["لغة الآلة / البطاقات المثقبة (الأربعينيات)"] --> B["لغة التجميع (الخمسينيات)"] B --> C["اللغات المترجمة عالية المستوى (السبعينيات)"] C --> D["اللغات المدارة / اللغات النصية (التسعينيات)"] D --> E["اللغة الطبيعية عبر LLMs (عشرينيات القرن الحادي والعشرين)"] E --> F["وكلاء الذكاء الاصطناعي المستقلون (2026-)"] style E fill:#f9f,stroke:#333,stroke-width:2px style F fill:#fbb,stroke:#333,stroke-width:2px

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

2. النموذج الرياضي للإنتاجية: ركوب موجة النمو الأُسي

دعونا نقيم التحسن في الإنتاجية الذي يجلبه الذكاء الاصطناعي كميًا باستخدام نموذج رياضي. يمكن نمذجة الإنتاجية الفردية $P_{traditional}$ في تطوير البرمجيات التقليدية كمجموعة خطية من مستوى مهارة الفرد $S$، وخبرته في المجال $E$، وكفاءة الأدوات $T$.

$$ P_{traditional} = c_1 \cdot S + c_2 \cdot E + c_3 \cdot T $$

ومع ذلك، في التطوير الحديث باستخدام الذكاء الاصطناعي، تعمل قدرة الذكاء الاصطناعي $A(t)$ كـ “مضاعف قوي (Multiplier)” يضخم القدرة البشرية. نظرًا لأن قدرات الذكاء الاصطناعي تنمو بشكل أُسي مع مرور الوقت $t$ (نسخة الذكاء الاصطناعي من قانون مور)، يمكن التعبير عن الإنتاجية في عصر الذكاء الاصطناعي $P_{AI}(t)$ بالمعادلة التالية:

$$ P_{AI}(t) = \alpha \cdot S_{core} \cdot e^{\beta \cdot A(t)} $$

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

$\alpha$: معامل الإنتاجية البشرية الأساسي
$S_{core}$: “المهارات البشرية الأساسية” التي لا يمكن للذكاء الاصطناعي استبدالها (تصميم البنية، فهم متطلبات العمل، الأحكام الأخلاقية، إلخ)
$A(t)$: القدرة المطلقة لنموذج الذكاء الاصطناعي في الوقت $t$ (عدد المعلمات، نافذة السياق، القدرة على الاستدلال)
$\beta$: معامل يشير إلى مدى فعالية استخلاص الأدوات الخاصة بالذكاء الاصطناعي (جودة هندسة التلقين (Prompt Engineering) ومدى تطور سير العمل التعاوني مع الذكاء الاصطناعي)

الاستنتاج المهم الذي يمكن استخلاصه من هذه الصيغة هو أنه في عالم تزداد فيه $A(t)$ بشكل أُسي، فإن المهارات التقليدية مثل سرعة الكتابة وحفظ لغات معينة سيكون لها تأثير ضئيل جدًا على الإنتاجية الإجمالية. بدلاً من ذلك، يصبح المعامل $\beta$، الذي يُستغل لمواكبة النمو الأُسي للذكاء الاصطناعي، و $S_{core}$، وهو المجال الذي لا يمكن للذكاء الاصطناعي تغطيته، العاملين المهيمنين اللذين يحددان القيمة السوقية للمهندس.

3. احتمالية أتمتة المهام (Probability of Automation)

إذن، ما هي المهام التي سيتم أتمتتها، وما هي المهام التي ستبقى في أيدي البشر؟ يمكن صياغة احتمالية أن تتم أتمتة مهمة معينة $T$ بالكامل بواسطة الذكاء الاصطناعي $P_{auto}(T)$ على النحو التالي:

$$ P_{auto}(T) = 1 - \exp\left(-\lambda \cdot \frac{\text{Predictability}(T)}{\text{Complexity}(T) \times \text{Context Dependency}(T)}\right) $$

$\text{Predictability}(T)$: القدرة على التنبؤ بالمهمة (مدى وجود نمط في البيانات السابقة)
$\text{Complexity}(T)$: تعقيد المهمة
$\text{Context Dependency}(T)$: قوة “السياق الضمني (المعرفة الخاصة بالمجال أو العلاقات الإنسانية)” الذي تعتمد عليه المهمة
$\lambda$: معدل التقدم التكنولوجي للذكاء الاصطناعي

المهام التي تتميز بقدرة عالية على التنبؤ واعتماد منخفض على السياق، مثل كتابة عمليات التوجيه (routing) في واجهات برمجة التطبيقات (API) أو إنشاء شاشات CRUD بسيطة، سيكون لها $P_{auto} \approx 1$ وسيتم أتمتتها بالكامل تقريبًا. من ناحية أخرى، المهام التي تعتمد بشكل كبير على السياق، مثل “كيفية دمج الأنظمة القديمة مع الخدمات المصغرة الجديدة بأمان” أو “كيفية تصميم تدفق مصادقة يلبي متطلبات الإدارة القانونية دون الإضرار بتجربة المستخدم”، يصعب أتمتتها.

4. العودة من بناء الجملة (Syntax) إلى البنية (Architecture)

إن الفصل الواضح بين ما يجيده الذكاء الاصطناعي وما يجيده البشر هو شرط مطلق للبقاء.

graph LR Sub1["مجالات تفوق الذكاء الاصطناعي"] Sub2["مجالات تفوق البشر"] A["توليد الأكواد من المواصفات"] --> Sub1 B["إصلاح أخطاء بناء الجملة (Syntax) والشوائب (Bugs)"] --> Sub1 C["توليد الأكواد النمطية / الاختبارات"] --> Sub1 D["تحليل السجلات (Log) ومطابقة الأنماط"] --> Sub1 E["تصميم بنية النظام (Architecture)"] --> Sub2 F["حل المتطلبات الغامضة"] --> Sub2 G["التفاوض بين الفرق المختلفة"] --> Sub2 H["الأحكام الأخلاقية / تحمل المسؤولية"] --> Sub2

يتفوق الذكاء الاصطناعي على البشر في “التحسين المحلي (Local Optimization)”. لا يمكن للبشر التغلب عليه من حيث السرعة والدقة في كتابة دالة واحدة، أو فئة (class) واحدة، أو وحدة واحدة. ومع ذلك، فإن الذكاء الاصطناعي ضعيف جدًا عندما يتعلق الأمر بـ “التحسين الشامل (Global Optimization)” أو “فقدان السياق (Missing Context)”.

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

5. تحديد المتطلبات هو “هندسة التلقين (Prompt Engineering) الحقيقية”

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

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

الهدف (Why): لماذا هذه الميزة مطلوبة؟ ما هي القيمة التجارية؟
القيود (Constraints): متطلبات الأداء (زمن الوصول، الإنتاجية)، متطلبات الأمان، وقيود التكلفة.
الحالات الطرفية (Edge Cases): العمليات البديلة (fallback) عندما يقوم المستخدم بإدخال بيانات غير متوقعة.
الواجهات (Interfaces): مواصفات التكامل مع الأنظمة الحالية.

التعليمات الغامضة (prompts) ستؤدي فقط إلى بناء أنظمة غامضة وهشة. إن القدرة على الاستماع بعمق لمعرفة “ما يريده العميل حقًا”، وتنظيم المتطلبات المتناقضة، وإنشاء مستند مواصفات (prompt) خالٍ من العيوب المنطقية؛ هذه هي “مهارة البرمجة” الأقوى في عصر الذكاء الاصطناعي. سيقضي المبرمجون وقتًا أقل في مواجهة محررات الأكواد، ووقتًا أطول أمام Notion أو ملفات Markdown، لوصف الشكل الذي يجب أن يكون عليه النظام بدقة نصية.

6. التفوق الساحق لمعرفة المجال (Domain Knowledge)

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

على سبيل المثال، لنفترض أننا نطور نظام سجلات طبية إلكترونية في شركة طبية ناشئة. قد يعرف الذكاء الاصطناعي “كيفية إنشاء واجهة مستخدم (UI) جدولية باستخدام React” أو “هياكل البيانات العامة لـ HL7 FHIR”. ومع ذلك، فإنه لم يتعلم المعرفة الضمنية مثل “في قسم معين من مستشفى أ، ما هو الترتيب الذي يجب أن يرى به الأطباء بيانات المرضى، وما هي واجهة المستخدم التي تقلل من مخاطر الأخطاء الطبية”.

في عالم أصبحت فيه التكنولوجيا نفسها سلعة (commoditized)، تُخلق القيمة الحقيقية للمهندس عند تقاطع “التكنولوجيا” و"مجال العمل (business domain)". لن نعتمد فقط على المهارات التقنية، بل الأشخاص الذين يمتلكون معرفة متخصصة عميقة في مجالات معينة مثل الطب، أو التمويل، أو الخدمات اللوجستية، أو الترفيه، ويمكنهم استخدام أداة قوية مثل الذكاء الاصطناعي لحل المشكلات في تلك المجالات، هم الذين سيقودون السوق في المستقبل.

7. “مشكلة العربة” في تطوير البرمجيات: من يتحمل المسؤولية؟

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

إذا تسببت الأكواد التي أنشأها الذكاء الاصطناعي بشكل مستقل في خطأ فادح (bug) في بيئة الإنتاج، مما أدى إلى خسارة ملايين الدولارات للشركة، أو تسبب في عطل في نظام طبي يمس حياة الإنسان، فمن سيتحمل المسؤولية؟ هل الشركة التي طورت نموذج الذكاء الاصطناعي؟ أم المهندس الذي أدخل الموجه (prompt)؟ لا يمكننا “طرد” أو “اعتقال” الذكاء الاصطناعي.

إن دور “الإنسان” ككيان يتحمل “المسؤولية القانونية والأخلاقية (Accountability)” تجاه تأثير الأنظمة على المجتمع لن يختفي مهما تقدمت التكنولوجيا. في الواقع، كلما أصبحت عملية إنشاء الأكواد بمثابة صندوق أسود، زاد العبء الملقى على عاتق الإنسان ليتحمل مسؤولية كبيرة كـ “مانح الموافقة النهائية (Approver)” و"المشرف (Supervisor)" على النظام.

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

8. البرمجة الزوجية مع الذكاء الاصطناعي وإدارة الحمل المعرفي (Cognitive Load)

عند العمل مع الذكاء الاصطناعي، تتغير طبيعة “الحمل المعرفي (Cognitive Load)” البشري أيضًا. الحمل المعرفي لكتابة الكود من الصفر يختلف تمامًا عن الحمل المعرفي لـ “قراءة ومراجعة” مئات الأسطر من الأكواد المجهولة التي يولدها الذكاء الاصطناعي.

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

لمنع ذلك، يجب وضع نظام لعملية المراجعة مع الذكاء الاصطناعي.

sequenceDiagram participant H as "المهندس البشري (مهندس معماري)" participant A as "وكيل الذكاء الاصطناعي" participant S as "CI/CD والاختبار" H->>A: "تحديد متطلبات وقيود صارمة" A->>H: "اقتراح بنية النظام والأكواد الأولية" Note over H,A: مرحلة المراجعة: حمل معرفي عالٍ H->>A: "نقد خيارات التصميم، طلب إعادة هيكلة الأكواد" A->>S: "توليد الأكواد النهائية ودفعها (Push)" S-->>H: "نتائج الاختبارات الآلية والتحليل الثابت" H->>H: "الموافقة النهائية وتحمل المسؤولية"

يحتاج البشر إلى صقل مهاراتهم إلى أقصى حد في “القراءة السريعة واكتشاف العيوب المنطقية بشكل فوري (Code Reading & Auditing)” أكثر من مهارة “الكتابة”. تتزايد أهمية التطوير القائم على الاختبار (TDD) في عصر الذكاء الاصطناعي. قبل السماح للذكاء الاصطناعي بكتابة التعليمات البرمجية، سيصبح النهج السائد هو أن يكتب الإنسان أو ذكاء اصطناعي آخر أكواد اختبار صارمة، ويطلب من الذكاء الاصطناعي تعديل أكواده حتى ينجح في تلك الاختبارات.

9. استراتيجيات بقاء ملموسة: ما الذي يجب أن تتعلمه غدًا؟

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

أعد تعلم “أساسيات” التكنولوجيا بشكل كامل: اترك كيفية استخدام أطر العمل (frameworks) للذكاء الاصطناعي. ولكن، لا غنى عن الفهم العميق لآليات نظام التشغيل (OS)، وبروتوكولات الشبكة (TCP/IP، HTTP/3)، والهياكل الداخلية لقواعد البيانات (B-Tree، مستويات عزل المعاملات)، وهياكل البيانات والخوارزميات. لكي تتمكن من الحكم على ما إذا كانت مخرجات الذكاء الاصطناعي صحيحة، فإن الأساس القوي في علوم الكمبيوتر أمر ضروري.
إتقان البنية السحابية (Cloud Architecture) والأنظمة الموزعة: ركز على كيفية الجمع بين الموارد السحابية مثل AWS و GCP و Azure لبناء أنظمة قابلة للتوسع، بدلاً من التركيز على الأكواد الفردية. افهم مفهوم البنية التحتية ككود (IaC) مثل Terraform، وطور القدرة على تصميم النظام بأكمله ككود.
كن خبيرًا في مجال عملك (Business Domain): تعلم بعمق نماذج الأعمال، واللوائح القانونية، وسيكولوجية سلوك المستخدم في الصناعة التي تنتمي إليها. تجاوز حدود المهندس وامتلك منظورًا أقرب إلى مدير المنتج (PM).
اصقل مهارات التواصل والتيسير (Facilitation): عملية حل “الغموض” بين البشر وبناء التوافق هي عملية لا يمكن للذكاء الاصطناعي استبدالها. إن المهارات الشخصية (Soft skills) للتواصل مع أصحاب المصلحة واكتشاف التحديات الحقيقية ستصبح المهارات الأكثر قيمة.
استخدم الذكاء الاصطناعي كـ “زميل عمل” إلى أقصى حد: لا تخف من تطور أدوات الذكاء الاصطناعي، بل استخدمها كأقوى أسلحتك. استخدم أحدث النماذج اللغوية الكبيرة (LLMs) ووكلاء البرمجة الذكية يوميًا، وقم ببناء “معرفة ضمنية” حول أين يفشل الذكاء الاصطناعي وكيفية ابتكار الموجهات (prompts) لاستخراج أفضل أداء منه.

الخلاصة: لا تخف، بل اركب الموجة

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

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

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

دليل تطوير نماذج الذكاء الاصطناعي الصغيرة (مثل 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)، بل أصبح نظامًا واقعيًا يعمل على سطح مكتب ويندوز الخاص بك. تحرر من تكاليف استخدام واجهات برمجة التطبيقات السحابية وخطر تسرب المعلومات، وادخل الآن إلى عالم الذكاء الاصطناعي الخاص القوي والحر.