- ما هي: نانو-فِلْإم هو إعادة تنفيذ خفيفة الوزن، تتكوَّن من نحو ١٢٠٠ سطر من بايثون، لمُحرِّك الاستنتاج في إل إل إم ، نشره DeepSeek المهندس شينغكاي يو على GitHub باسم GeeeekExplorer/nano-vllm.
- لماذا تستخدمه؟ شفرة مصدرية سهلة القراءة لفهم كيفية عمل انتباه الصفحات (paged attention)، والتخزين المؤقت للمقدمة (prefix caching)، ورسوميات CUDA — وليس بديلًا إنتاجيًّا عن vLLM.
- التثبيت:
pip install git+https://github.com/GeeeekExplorer/nano-vllm.git، ثم قم بتحميل دليل نموذج Hugging Face واستدعِ الدالةLLM(...).generate(...). - المتطلبات: وحدة معالجة رسوميات (GPU) من NVIDIA مزودة بـ CUDA، وPyTorch، وذاكرة VRAM كافية للنموذج الذي اخترته — راجع قسم حاسبة الذاكرة VRAM.
نانو-فِلْإم هو إعادة تنفيذ مفتوحة المصدر، من الصفر، لمُحرِّك الاستنتاج في إل إل إم ، مكتوبة في نحو ١٢٠٠ سطر من بايثون. وقد أُطلِقَت في منتصف عام ٢٠٢٥ بواسطة شينغكاي يو، وهو مهندس في شركة DeepSeek، بموجب رخصة MIT على github.com/GeeeekExplorer/nano-vllm. وهي عبارة عن قاعدة شفرة مُعدَّة للتدريس وأداة سريعة للاستنتاج المجمَّع — وليست بديلًا جاهزًا للتبديل عن خادم vLLM الكامل.
ما هي نانو-فِلْإم فعليًّا؟
المستودع الأصلي vllm-project/vllm هو خادم استنتاج إنتاجي ضخم، يضم مئات المساهمين، ويوفر واجهة برمجة تطبيقات HTTP متوافقة مع OpenAI، وعاملين موزَّعين، ويدعم عشرات هياكل النماذج ومخططات التكمين. أما نانو-فِلْإم فهو يقلِّص كل ذلك إلى الحلقة الأساسية: تحميل النموذج، وإدارة ذاكرة التخزين المؤقت KV، ومجدول التجميع، والمُعايِن.
وفقًا لملف README الخاص بالمشروع، تحتفظ نانو-فِلْإم بالتحسينات الرئيسية التي تجعل vLLM سريعًا، وهي:
- التخزين المؤقت للمقدمة (Prefix caching) — يعيد استخدام كتل الذاكرة التخزينية المؤقتة KV عبر طلبات تشترك في نفس مقدمة المُدخل.
- التوازي الموحد (Tensor parallelism) — يقسِّم النموذج عبر عدة وحدات معالجة رسوميات (GPUs) على عقدة واحدة.
- تجميع PyTorch (Torch compilation) — يستخدم الدالة
torch.compileلدمج النوى. - رسوميات CUDA (CUDA graphs) — تقلل من النفقات العامة لإطلاق كل خطوة أثناء مرحلة التفسير (decoding).
أما ما تم حذفه عمديًّا فهو: خادم HTTP المتوافق مع OpenAI، وواجهات برمجة التطبيقات الخاصة بالتدفق المستمر (continuous streaming APIs)، ومعظم واجهات التكمين الخلفية (مثل AWQ وGPTQ وFP8)، والفك التوقعي (speculative decoding)، وتغيير لوارات (LoRA) الديناميكي، والتجميع متعدد العُقد (multi-node clustering)، ومجموعة النماذج الواسعة (broad model zoo). وقد تم اختباره بشكل أساسي مع نماذج كثيفة من فئة Qwen3.
تثبيت نانو-فِلْإم
نانو-فِلْإم عبارة عن حزمة بايثون. ولا توجد في المستودع الأصلي مسار دعم أصلي لـ CUDA على نظام Windows؛ لذا يجب على مستخدمي Windows استخدام WSL2 مع تعريف NVIDIA. أما أنظمة التشغيل المدعومة أساسًا فهي Linux وWSL2. ولا يُدعم نظام macOS لأن مسارات الشفرة تفترض وجود CUDA.
Linux وWSL2
python -m venv .venv
source .venv/bin/activate
pip install torch --index-url https://download.pytorch.org/whl/cu121
pip install git+https://github.com/GeeeekExplorer/nano-vllm.gitيجب أن تتطابق حزمة CUDA (cu121, cu124، وما إلى ذلك) مع إصدار تعريف NVIDIA المثبت لديك. ويمكنك التحقق من ذلك باستخدام الأمر nvidia-smi قبل التثبيت.
Windows (عبر WSL2)
قم بتثبيت تعريف NVIDIA الخاص بنظام Windows، وفعِّل WSL2 مع توزيعة Ubuntu (wsl --install -d Ubuntu)، ثم اتبع خطوات التثبيت الخاصة بنظام Linux داخل بيئة WSL. ولا تحاول تثبيت حزمة أدوات CUDA داخل WSL — إذ إن تعريف Windows يوفِّر الوصول إلى وحدة معالجة الرسوميات.
macOS
غير مدعوم. فنانو-فِلْإم يعتمد على نوى CUDA وبدائل انتباه الصفحات (paged-attention primitives) التي لا تتوفر لها بدائل قائمة على Metal. وعلى أجهزة Apple Silicon، استخدم بدلًا منها Ollama أو LM Studio بدلًا من ذلك، وكلاهما يعملان llama.cpp تحت الغطاء.
تنزيل نموذج
يحمّل Nano-vLLM دلائل نماذج Hugging Face القياسية — وهي نفسها config.json, tokenizer.json و safetensors البنية التي تستخدمها مكتبتا transformers وvLLM. يمكنك تنزيل نموذج باستخدام سطر الأوامر الرسمي من واجهة سطر أوامر Hub في Hugging Face: huggingface_hub واجهة سطر الأوامر (CLI):
pip install -U "huggingface_hub[cli]"
hf download Qwen/Qwen3-8B --local-dir ~/models/Qwen3-8Bاطّلع على للمصادقة والوصول إلى النماذج المقيدة. لاحظ أن نقطة الدخول القديمة لا تزال مُضمَّنة مع الحزمة، لكن Hugging Face توصي الآن باستخدام أمر huggingface-cli نقطة الدخول لا تزال مُضمَّنة مع الحزمة، لكن منصة Hugging Face توصي الآن بـ hf بديلًا عنها.
تشغيل الاستنتاج
تُحاكي واجهة برمجة التطبيقات (API) واجهة vLLM الدفعية غير المتصلة بالإنترنت بدقةٍ عالية. إليك نصًّا برمجيًّا بسيطًا:
from nanovllm import LLM, SamplingParams
llm = LLM("/home/user/models/Qwen3-8B", enforce_eager=False, tensor_parallel_size=1)
sp = SamplingParams(temperature=0.7, max_tokens=256)
prompts = ["Explain paged attention in one paragraph."]
outputs = llm.generate(prompts, sp)
print(outputs[0]["text"])قد تتغير أسماء الفئات المُرجعية وشكل المخرجات عبر التحديثات المختلفة — يُرجى الرجوع إلى ملف example.py الموجود في الجذر الرئيسي للمستودع، وهو المرجع القياسي لطريقة الاستخدام.
متطلبات الأجهزة حسب النموذج
وبما أن nano-vllm يُشغِّل النماذج حاليًّا بصيغة bf16/ fp16 (بدون دعم مدمج للتكمين 4-bit وقت كتابة هذا التقرير)، فإن متطلبات الـ VRAM تكون تقريبًا ضعف الأرقام المذكورة أدناه للصيغة 4-bit. استخدم جدول حاسبة الذاكرة VRAM لتقدير دقيق حسب الدقة. الأرقام التالية هي أرقام مرجعية 4 بت من Convly قاعدة بيانات النماذج من Convly كمرجع — بالنسبة لـ nano-vllm عند استخدام bf16، احسب ميزانية الـ VRAM بمقدار ضعف هذه القيم تقريبًا، مع إضافة هامش احتياطي لمخبأ KV.
| النموذج | السياق | الـ VRAM (مرجع 4-bit) | بطاقة GPU فعلية متوافقة مع nano-vllm |
|---|---|---|---|
| Qwen3 8B | 128 ألف رمز | ~5 غيغابايت | بطاقة RTX 4090 واحدة (24 غيغابايت) عند صيغة bf16 |
| Qwen3 14B | 128 ألف رمز | ~٩ جيجابايت | بطاقة RTX 4090 واحدة عند صيغة bf16 مع سياق معتدل الطول |
| Qwen3 32B | 128 ألف رمز | ~20 جيجابايت | بطاقتان RTX 4090 مع tensor_parallel_size=2 |
| Llama 3.1 8B | 128 ألف رمز | ~5 غيغابايت | بطاقة RTX 4090 واحدة |
| Llama 3.3 70B | 128 ألف رمز | ~40 جيجابايت | بطاقتان A100 بسعة 80 غيغابايت أو أربع بطاقات RTX 4090 |
للحصول على صورة أوسع عمّا يمكن تشغيله على كل بطاقة، راجع أفضل وحدات معالجة الرسوميات لتشغيل نماذج اللغة الكبيرة محليًّا والـ جدول متطلبات الـ VRAM.
مقارنة بين نانو-فِلْإم وvLLM وأولاما
| الميزة | نانو-فِلْإم | في إل إل إم | Ollama |
|---|---|---|---|
| عدد الأسطر البرمجية | ~1,200 سطرًا من بايثون | ~100 ألف سطر أو أكثر من بايثون/ ++C/ CUDA | غلاف بلغة Go فوق llama.cpp |
| خادم متوافق مع OpenAI | لا | نعم | نعم (عبر /v1) |
| الواجهة الخلفية | PyTorch + CUDA | PyTorch + نوى مخصصة | llama.cpp (GGUF) |
| التكمية | حد أدنى | AWQ، GPTQ، FP8، INT4 | Q2–Q8 GGUF |
| تعدد البطاقات الرسومية (Multi-GPU) | التوازي الموحّد (Tensor parallel) | التوازي الموحّد + التوازي الأنبوبي + التوازي الخبير (Tensor + pipeline + expert) | محدود |
| الاستخدام الأساسي | التعلّم، التضمين (Embedding) | التشغيل الإنتاجي (Production serving) | الكمبيوتر الشخصي / التطوير (Desktop / dev) |
إذا كان هدفك هو توفير نقطة نهاية (endpoint) أمام العملاء، فاستخدم vLLM الكامل. أما إذا أردت تضمين حلقة استنتاج دفعي داخل برنامج بايثون أكبر مع أقل عدد ممكن من التبعيات، فـ nano-vllm خيار معقول. وإذا أردت تطبيق دردشة محليًّا يعمل بأمر واحد فقط، فاستخدم Ollama.
متى يكون استخدام نانو-فِلْإم منطقيًّا؟
- فهم البنية الداخلية للنظام. يتناسب جدول الجدولة ومدير الكتل (scheduler and block manager) على شاشة واحدة. وقراءة كود nano-vllm هي أسرع طريقة لفهم آلية الانتباه المُفصّص (paged attention) ضمن كود حقيقي.
- الفروع البحثية (Research forks). تعديل قاعدة كود مكوّنة من 1,200 سطر لاختبار عيّنة جديدة (sampler) أو سياسة مخبأ (cache policy) أمرٌ عملي؛ أما فرع vLLM الأصلي فهو ليس كذلك.
- الاستنتاج الدفعي غير المتصل بالإنترنت (Batch offline inference). تصنيف الإجابات، توليد بيانات اصطناعية، حلقات التقييم على مجموعة ثابتة من المطالبات (prompts).
متى لا يكون استخدامه منطقيًّا: واجهات برمجة التطبيقات الإنتاجية، التشغيل متعدد المستأجرين (multi-tenant serving)، الميزانيات الضيقة للتكمين، أو أي أجهزة غير NVIDIA.
الاستضافة الذاتية مقابل واجهة برمجة التطبيقات
يترتّب على تشغيل nano-vllm محليًّا تكاليف فعلية — رأس المال المخصص للوحدة الرسومية (GPU capital)، والكهرباء، ووقت المهندسين. وغالبًا ما تكون النماذج المُستضافة على الحدود الأمامية (frontier hosted models) أرخص لكل رمز (token) مقارنةً بتكلفة الاستنتاج المحلي بعد توزيعها على الحجم المنخفض. قارن ذلك باستخدام حاسبة المقارنة بين الاستضافة الذاتية وواجهة برمجة التطبيقات (API) والـ حاسبة تكلفة واجهة برمجة التطبيقات (API)جدول مقارنة التكاليف Qwen3 8B يبلغ سعر تشغيل نموذج Qwen3-8B على نقطة نهاية مستضافة $0.04 للإدخال و$0.14 للإخراج لكل مليون رمز وفقًا لبيانات Convly قاعدة بيانات النماذج، بينما تكلّف بطاقة GPU بسعة 24 غيغابايت قادرة على تشغيله محليًّا أكثر من 1500 دولار أمريكي.
الأسئلة الشائعة
من كتب نانو-فِلْإم؟
يُدار المستودع بواسطة Xingkai Yu (اسم المستخدم على GitHub: GeeeekExplorer)، وهو مهندس في شركة DeepSeek. ويُعد المشروع مشروعًا شخصيًّا وليس إصدارًا رسميًّا من DeepSeek. وترخيص الكود هو رخصة MIT، وهو موجود على github.com/GeeeekExplorer/nano-vllm.
هل نانو-فِلْإم أسرع من vLLM؟
الملف README يفيد بأن الأداء (throughput) قريب جدًّا من أداء vLLM على النماذج الكثيفة الصغيرة مثل Qwen3-0.6B عند تشغيلها على بطاقة GPU من فئة RTX 4070 واحدة، بل وقد يكون أسرع قليلًا في بعض اختبارات الأداء القصيرة بسبب انخفاض الحمل على جدول الجدولة. أما على النماذج الأكبر أو السياقات الأطول أو عند خدمة عدة طلبات في آنٍ واحد، فإن التحسينات المُطبَّقة في vLLM الأصلي تتفوّق بوضوح. لذا ينبغي اعتبار التكافؤ بينهما على أنه «في نفس الفئة تقريبًا للتشغيل الدفعي غير المتصل»، وليس «بديلًا صارمًا».
هل يمكن لنانو-فِلْإم تقديم واجهة برمجة تطبيقات (API) متوافقة مع OpenAI؟
ليس بشكل افتراضي. يوفّر المشروع واجهة برمجة تطبيقات (API) بلغة بايثون LLM.generate() طريقة تُستخدم دفعةً دون اتصال بالإنترنت. وإذا كنت بحاجة إلى خادم HTTP مع /v1/chat/completions، فقم بتغليفه يدويًّا باستخدام إطار عمل FastAPI، أو استخدم خادم vLLM المتوافق مع واجهة OpenAI أو Ollama.
هل يدعم نانو-فِلْإم النماذج المُكمَّنة مثل GGUF أو AWQ؟
لا. يقوم رمز المصدر بتحميل أوزان Hugging Face القياسية بصيغة safetensors وبتنسيق bf16/ fp16. أما بالنسبة للأوزان بصيغة GGUF (مثل Q4_K_M إلخ)، فيجب استخدام أدوات تعتمد على llama.cpp؛ وللأوزان المُكمَّة بأساليب AWQ أو GPTQ، استخدم الإصدار الأصلي من vLLM. ويعود سبب ارتفاع استهلاك nano-vllm للذاكرة VRAM لكل معلمة مقارنةً بـ Ollama لنفس النموذج جزئيًّا إلى هذه الحالة.
أي النماذج معروفة بأنها تعمل معه؟
تُعَدُّ نماذج Qwen3 الكثيفة الهدف الرئيسي للتنفيذ المرجعي. وغالبًا ما تعمل نماذج أخرى مبنية على بنية Llama بعد إدخال تعديلات طفيفة على محمل النموذج، لكن البنية غير التقليدية (مثل نماذج «مزيج الخبراء» أو النماذج الهجينة القائمة على فضاء الحالات) لا تعمل عمومًا. راجع الدليل nanovllm/models/ في المستودع للحصول على قائمة النماذج المدعومة حاليًّا.
هل يمكنني تشغيل نانو-فِلْإم على معالجات AMD أو شرائح Apple Silicon؟
ليس في الوقت الراهن. فالمكتبات الأساسية تفترض وجود بيئة CUDA. وقد يعمل ROCm باستخدام بناء مخصص لمكتبة PyTorch، لكنه لم يُختبر رسميًّا في الإصدار الأصلي. أما على معالجات Apple Silicon فلا توجد وسيلة دعم — لذا يُرجى استخدام أدوات تعتمد على MLX أو llama.cpp. وللاطلاع على ملخّص للبدائل المتاحة، راجع لوحة تصنيف النماذج اللغوية الكبيرة (LLM) واختر النموذج الذي يتوافق مع مواصفات جهازك.