Serverless للذكاء الاصطناعي: تشغيل استدلال LLM خفيف على Cloudflare Workers وVercel Edge

٢٤ نوفمبر ٢٠٢٥
Serverless للذكاء الاصطناعي: تشغيل استدلال LLM خفيف الوزن على Cloudflare Workers وVercel Edge [Backend, Cloud & DevOps > Serverless & Edge Compute]

مقدمة: لماذا تشغيل LLM على الحافة (Edge)؟

تزداد الحاجة لتقديم استجابات ذكية بزمن استجابة منخفض وقرب للمستخدم — خصوصاً لتطبيقات الدردشة، المساعدات الذكية، والتخصيص المحلي. تشغيل نماذج لغوية خفيفة الوزن (Tiny / Small LLMs) مباشرة على بيئات Serverless Edge مثل Cloudflare Workers وVercel Edge يسمح بتقليل زمن الرحلة (latency)، زيادة الخصوصية بتقليل تبادل البيانات مع السحابة المركزية، وتوزيع الحمل جغرافياً.

لكن الحافة تجلب قيوداً صريحة: حدود الذاكرة، زمن التنفيذ، وحجم الحزمة — لذا يتطلب الأمر تصميم نماذج وخط أنابيب مخصّصة (quantized models, wasm binaries, sharded loading) للوصول إلى أداء فعّال. في الفقرات التالية نعرض تقنيات عملية، قيود المنصتين، ونموذج معماري موصّى به للنشر.

تقنيات وتمكين: تشغيل LLM خفيف الوزن على WebAssembly وggml

الطريقة العملية الأكثر شيوعاً لتشغيل LLM على الحافة هي تحويل محرك الاستدلال إلى WebAssembly (WASM) أو استخدام binding جاهز يجلب مكتبات مثل llama.cpp إلى بيئة الجافاسكربت/الـEdge. مشروع llama.cpp يدعم تقنيات تقليل الدقة والكمّ (quantization) التي تخفّض استهلاك الذاكرة وتسرّع الاستدلال، ما يجعله مناسباً لنماذج بحجم صغير إلى متوسط عند تنفيذها على CPU محدود الموارد.

  • WASM bindings: مكتبات مثل wllama أو حزم مشابهه توفر واجهات TypeScript/JS لتشغيل نموذج محوّل إلى ggml في متصفّح أو بيئة WASM، مع إمكانيات تقسيم الملفات وتحميلها بالتوازي لتجاوز قيود حجم ArrayBuffer.
  • الكمّ (Quantization): تحويل الوزن إلى 4-bit/8-bit أو تنسيقات AWQ/FP8 يقلّل الذاكرة المطلوبة ويتيح تشغيل نماذج 3–7B على بيئات محدودة الموارد.
  • التجزئة (Sharding): تقسيم ملفات النموذج إلى أجزاء صغيرة وتحميلها تدريجياً أو حسب الحاجة يساعد على تجاوز قيود حجم الحزمة وذاكرة الـisolate.

ملاحظة عملية: لا تتوقع تشغيل نماذج كبيرة (مثل >13B) بكفاءة على عُزلات Workers/Edge بدون استدعاء خدمات GPU خارجية — الحلّ الواقعي هو نماذج مُكمِّلة (distill/tiny) على الحافة وfallback إلى endpoints سحابية عند الحاجة.

مقارنة قيود Cloudflare Workers وVercel Edge وتأثيرها على الاستدلال

قبل التصميم يجب فهم قيود كل منصة: Cloudflare Workers تعمل داخل "isolates" لها حدود ذاكرة لكل isolate تقريباً 128 ميجابايت للذاكرة التشغيلية (تشمل heap وذاكرة WASM). هذا يحدد حجم النموذج والـKV cache وطريقة التعامل مع الـstreaming.

من جهة أخرى، Vercel Edge Functions تقدم runtime للحافة بحدود مشددة للـedge runtime: يجب أن تبدأ الدالة بإرسال استجابة خلال ~25 ثانية كي تستمر إمكانيّة streaming (يمكن متابعة البث حتى 300 ثانية في بعض الحالات)، وتحدود الحزم وحجم الشيفرة (gzip) اعتماداً على الخطة. لذلك تصميم الاستدلال يجب أن يراعي البدء المبكر في البث وإعادة استخدام الجلسات/الكاش لتقليل زمن التهيئة.

ميزةCloudflare WorkersVercel Edge
ذاكرة لكل isolate~128 MB (محددة)Edge runtime عادةً ~128 MB (اعتماداً على الخطة)
زمن استجابة بداية البثمُحكم حسب الـisolate/limitsيجب أن تُبدأ الاستجابة خلال 25s (يمكن البث لوقت أطول).
حجم الحزمةWorker size محدود (Free/10MB..)حجم بعد gzip يختلف حسب الخطة (1–4MB للـedge middleware).

معمارية موصى بها، نمط نشر، ونصائح عملية

نموذج معماري عملي للعديد من التطبيقات يضم الطبقات التالية:

  1. حافة أخفّ (Edge tiny LLM): نموذج مقنّن (مثلاً TinyLlama أو نماذج 1–3B) مُحمّل كـWASM داخل الـEdge لعمليات سريعة جداً (autocomplete، intent detection، reranking). هذا يخفض زمن الرد ويُعطي خصوصية أعلى.
  2. خدمة استدلال مركزية (GPU): استضافة نماذج أكبر أو عمليات تكوين معقدة على endpoints مخصّصة (GPU/TPU) وندعوها من الحافة عند الحاجة (fallback/complex queries).
  3. ذاكرة وسيطة ذكية (Edge cache + KV): حفظ نتائج شائعة، أجزاء من الـtokenization أو النماذج المقسمة في KV/CDN لتقليل تحميل النموذج الكامل لكل استدعاء.

نصائح تنفيذية سريعة

  • استخدم تجزئة النماذج (sharding) وLazy-loading لتحاشي قيود ArrayBuffer وأحجام الملفات.
  • طبق quantization قبل النشر لتقليل الذاكرة دون فقدان كبير في الجودة.
  • راقب cold starts: ابدأ إرسال أجزاء من الاستجابة فوراً (streaming) أو استخدم warm-up triggers حسب إمكانيات المنصة.
  • أمّن المفاتيح وراجع سياسات CORS وـCOOP/COEP إذا كنت تستعمل multi-threaded WASM في المتصفّح/Edge.

مثال مبسّط لتدفق استدعاء

// 1) Edge receives request -> quick local WASM infer for intent/rerank
// 2) If complex -> proxy request to GPU endpoint (llama-server / llama.cpp server)
// 3) Cache result in Edge KV for subsequent requests

أخيراً، ابحث عن مكتبات جاهزة (مثل bindings لـllama.cpp أو حزم WASM مثل wllama) لتسرّع التطوير، واذكر أن التجربة العملية تختلف حسب حجم النموذج، سياسات المنصّة، ومتطلبات الخصوصية والامتثال.

خلاصة: تشغيل استدلال LLM خفيف على Cloudflare Workers وVercel Edge ممكن وفعّال لحالات استخدام محددة إذا اعتمدت تقنيات الكمّ، WASM، وتجزئة النموذج، مع تصميم هجين يوفّر مرونة التحجيم إلى موارد GPU عند الحاجة.