إذا كتبت نموذجك يدويًا بلغة C++ لبطاقة Apple، فعليك أن تكتبه مرة أخرى لهاتف Android، ومرة ثالثة للمتصفّح. هذه المشكلة التي تقول Google إنها صمّمت LiteRT Tensor API لحلّها. أعلنت الشركة الأداة في مدوّنة المطوّرين في أكتوبر، وعادت InfoQ لتغطيتها في 3 نوفمبر.
ماذا تفعل الأداة؟
LiteRT Tensor API طبقة خفيفة داخل منظومة LiteRT، تبني فيها رسم الحوسبة (Computation Graph) عملية بعملية بلغة C++، ثم تشغّل الرسم نفسه على المعالج المركزي أو بطاقة الرسوميات أو وحدة المعالجة العصبية (NPU) دون إعادة كتابته لكل عتاد. وتعدّد Google أربع ميزات:
- تحكّم كامل في الرسم: من العمليات الحسابية البسيطة إلى عمليات مركّبة للنماذج اللغوية مثل الانتباه وتحديث ذاكرة المفاتيح والقيم.
- تحميل مباشر للأوزان: من نقاط الحفظ، ومنها ملفات .safetensors من Hugging Face، دون سكربتات تحويل.
- مخازن مشتركة: المعالجة القبلية والاستدلال والمعالجة البعدية تتبادل البيانات عبر مخازن المسرّع نفسها دون نسخ.
- للوكلاء البرمجيين: النموذج كود C++ عادي، فيستطيع وكيل برمجي بناءه ومقارنته بمرجع وضبط أدائه.
الاستخدام العملي
عرضت Google تطبيقًا للتقسيم والتتبّع بنموذج SAM 2 يعمل داخل المتصفّح عبر WebGPU. وتقول إن وكيلًا برمجيًا كتب النموذج وطوّره من أقل من 10 إطارات في الثانية إلى أكثر من 30 بدقّة 512×512. وعلى MacBook Pro، تقول الشركة إن الكود نفسه عمل أسرع بنحو 1.5 مرة من Apple MLX في اختبارها. والتطبيق والتنفيذ الكامل مفتوحا المصدر في مستودع أمثلة LiteRT.
الحدود
Google نفسها تنصح بالبدء بمسار تحويل النماذج الجاهزة، فهو «الخيار الافتراضي الأفضل لمعظم النماذج». وتنقل InfoQ رأيًا مشابهًا عن Laurence Moroney من Arm: استخدم واجهة C++ فقط حين تحتاج إلى تحكّم على مستوى الرسم. وتقول Google إنها تعمل على تحسينات منها التكميم التلقائي للرسم كاملًا ودعم أوسع للأشكال المتغيّرة.
لمن تصلح؟
لمطوّري تطبيقات الهاتف والمتصفّح الذين يريدون تشغيل بنية جديدة قبل أن تدعمها أدوات التحويل، أو إبقاء خطّ المعالجة كله على المسرّع. أما إن كان نموذجك يتحوّل بسلاسة، فلا حاجة إلى النزول إلى هذا المستوى. ليس كل من يقود سيارة يحتاج إلى فتح المحرّك.
المصادر: Google Developers Blog، InfoQ — 2026-10-19, 2026-11-03
