Windows 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 عند التنفيذ.

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