TensorSharp، وهو محرك استدلال (inference engine) مبني بالكامل على .NET لنماذج لغة GGUF، متاح الآن للجمهور، مما يتيح لمطوري .NET تشغيل استدلال النماذج اللغوية الكبيرة (LLM) دون الحاجة إلى تشغيل خادم Python. ويدعي المشروع أداءً يضاهي llama.cpp واسع الاستخدام، مع العمل على أنظمة Windows وmacOS وLinux ودعم واجهات CUDA وMLX وMetal وVulkan.

لماذا تكمن أهمية .NET الأصلية (native)

تُكتب معظم بيئات تشغيل النماذج اللغوية الكبيرة بلغة C/C++ أو تعتمد على أغلفة (wrappers) بلغة Python تفتح عملية منفصلة. بالنسبة للفرق التي تعمل خدماتها بالفعل على .NET، فإن هذه الطبقة الإضافية تزيد من الحاجة إلى الحاويات (containers)، والتواصل بين العمليات (inter-process communication)، وتوسع سطح الهجوم (attack surface). إن إبقاء عملية الاستدلال داخل نفس بيئة التشغيل يتيح للمطورين تبسيط خطوط أنابيب CI/CD، وتقليل زمن التأخير الناتج عن قفزات الشبكة، وخفض تكلفة صيانة بيئة Python.

كيف تم بناء TensorSharp

قام المؤلف بكتابة المحرك من الصفر بدلاً من إعادة استخدام llama.cpp. واجهة المعالج (CPU backend) مكتوبة بنسبة 100% بلغة C#، لذا تعمل على Windows وLinux دون أي تبعات برمجية أصلية (native dependencies). يأتي دعم وحدة معالجة الرسومات (GPU) من واجهات برمجة تطبيقات الرسوميات الحالية: CUDA لـ Nvidia، وMLX لمعالجات Apple silicon، وMetal لمعالجات macOS GPUs، وVulkan للأجهزة متعددة المنصات. وتوجد في قلب المحرك تقنيات حديثة مثل ذاكرة التخزين المؤقت للمفاتيح والقيم (KV cache) المجدولة (paged)، والتشغيل المتوازي المستمر (continuous batching)، وفك التشفير التخميني (speculative decoding) لنماذج مثل Qwen وGemma.

الميزات التي يحصل عليها المطورون مباشرة

  • التوافق مع نماذج GGUF – وهو نفس التنسيق المستخدم في أحدث إصدارات النماذج اللغوية الكبيرة مفتوحة المصدر.
  • التشغيل عبر المنصات – يعمل على Windows وmacOS وLinux دون الحاجة لتغيير الكود.
  • واجهات برمجة تطبيقات HTTP متوافقة مع OpenAI وOllama – بديل جاهز لمكتبات العميل الحالية.
  • التعامل مع الوسائط المتعددة (Multimodal) – يمكنه معالجة الصور والفيديو والصوت وملفات PDF كجزء من المطالبة (prompt).
  • استدعاء الأدوات والمخرجات المهيكلة – يدعم أنماط استدعاء الدوال (function-calling) الشائعة في الوكلاء القائمين على الدردشة.

الأداء مقابل llama.cpp

تُظهر اختبارات الأداء (Benchmarks) التي شاركها المسؤول عن المشروع نتائج متفاوتة:

  • مرحلة التعبئة المسبقة (Prefill) وزمن الوصول لأول رمز (TTFT) – غالباً ما يتفوق TensorSharp على llama.cpp، حيث يوفر زمن تأخير أقل للاستجابة الأولية.
  • إنتاجية فك التشفير (Decode throughput) – عادة ما تكون مشابهة لـ llama.cpp أو أبطأ قليلاً منه.

تشير الأرقام إلى أن التنفيذ بلغة C# الصرفة لا يضحي بالسرعة في المراحل الأكثر حساسية لزمن التأخير، مع البقاء منافساً في معدل إنتاج الرموز في الثانية (token-per-second).

تنبيهات يجب وضعها في الاعتبار

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

ما الذي يجب ترقبه لاحقاً

توفر قناة المناقشة الخاصة بالمشروع على Telegram مكاناً للمتبنين الأوائل لمشاركة النتائج وطلب ميزات جديدة.

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