تشغيل Kimi K3 على Amazon Bedrock في الهند: البيانات لا تغادر البلاد

إذا كنتم تطورون منتجا لقطاع التكنولوجيا المالية أو القطاع الحكومي في الهند، فأنتم تعرفون هذه المشكلة: لا يجوز إرسال بيانات العملاء إلى خارج البلاد، بينما تعمل النماذج الجيدة عادة في مكان ما داخل الولايات المتحدة. وقد سدّت AWS هذه الفجوة لنموذج Kimi K3 من Moonshot AI. إذ بات Amazon Bedrock يوفر الآن ملف استدلال يعالج الطلبات حصريا في منطقتي مومباي وحيدر آباد.

كيفية اختيار مكان معالجة الطلب

يعمل Kimi K3 في Bedrock عبر ملفات الاستدلال العابرة للمناطق. تستدعون النموذج من منطقتكم، ثم يختار Bedrock بنفسه المكان الذي ستجرى فيه المعالجة. ويحدد معرّف الملف مجموعة المناطق المسموح بها.

توصي AWS باستخدام الملف العالمي global.moonshotai.kimi-k3 لمعظم المهام، لأنه الأرخص والأعلى توافرا. وإذا كنتم بحاجة إلى توطين البيانات، فاستخدموا in.moonshotai.kimi-k3، لتبقى المعالجة في مومباي وحيدر آباد. تُشفّر حركة البيانات بين المنطقتين ولا تمر عبر الإنترنت العام، ولا حاجة إلى إعداد VPC متعدد المناطق خاص بكم.

عمليا، هناك تفصيل مهم يتعلق بالصلاحيات. يجب أن تسمح سياسة IAM بالاستدعاء في كلتا منطقتي الوجهة الهنديتين، لا في المنطقة التي ترسلون منها الطلب فحسب. وإذا كانت مؤسستكم تطبق قيود SCP بحسب المنطقة، فسيتعين تعديلها، وإلا ستفشل الطلبات. وفي الوقت نفسه، تُخزّن السجلات والمقاييس في منطقة المصدر، ويمكن تفعيل الحقل inferenceRegion في CloudTrail للتحقق من المكان الذي عولج فيه كل طلب فعليا.

مثال: مسح فاتورة باللغة الهندية من دون OCR

تعرض AWS سيناريو شائعا لنماذج KYC وفواتير الخدمات. ترسلون صورة فاتورة الكهرباء بترميز base64، ويقرأ النموذج بنفسه النص المكتوب بالخط الديفاناغاري. ويمكن بعد ذلك طرح الأسئلة عليه بلغة الهينغليش، أي الهندية المكتوبة بالأحرف اللاتينية والممزوجة بالإنجليزية. على سبيل المثال: «Bill kitne ka hai aur last date kab hai?» ويجيب النموذج بالمبلغ، وهو 2 217,20 روبية، وبالموعد النهائي للدفع.

للحصول على مخرجات منظمة، يُستخدم function calling أو JSON Schema. ينفذ خط المعالجة في المثال أربع مهام: ينسخ المستند بنظام الكتابة الأصلي، ويستخرج الحقول إلى JSON، ويوحّد التواريخ وفق ISO 8601، ويحوّل أرقام الديفاناغاري إلى الأرقام المعتادة، وينقل الأسماء إلى الأحرف اللاتينية. ثم يكتب ملخصا قصيرا بالإنجليزية ويجيب عن الأسئلة التوضيحية.

وتتضمن المقالة نصيحتين عمليتين. بالنسبة إلى التفاصيل الصغيرة، استخدموا detail: high، فهو أدق لكنه يستهلك عددا أكبر من التوكنات. ومن الأفضل وضع الصورة قبل النص، إذ تكون الجودة أعلى أحيانا. ويمكن الاتصال عبر مكتبة openai المعتادة، لأن واجهة API متوافقة مع OpenAI، بينما يُنشأ التوكن من بيانات اعتماد AWS القياسية.

التكلفة: الفئات والتخزين المؤقت

جاء الرقم الأبرز في المقالة من أحد العملاء. تستخدم Ultrahuman نموذج Kimi K3 في مساعدها Jade، الذي يجيب عن الأسئلة المتعلقة ببيانات الخاتم ومستويات الغلوكوز، بمعدل يتجاوز 14 000 محادثة يوميا. ووفقا للشركة، خفّض التخزين المؤقت للمطالبات التكاليف بنسبة 80% وسرّع المحادثات متعددة الجولات بنسبة 85%. وهذا ادعاء صادر عن الشركة نفسها في تدوينة شراكة على مدونة AWS، ولا توجد مراجعة مستقلة له.

لتكرار هذا الأثر، ضعوا الجزء الثابت، مثل مطالبة النظام وأوصاف الأدوات، في بداية الطلب، ثم ضعوا العناصر الديناميكية، مثل الصورة والسؤال، في نهايته. يوجد وضع تخزين مؤقت ضمني يعمل تلقائيا، ووضع صريح تحددون فيه breakpoints للحصول على عدد أكبر من تطابقات التخزين المؤقت. وللمهام التي لا تتطلب زمنا صارما للاستجابة، توفر فئة flex خصما بنسبة 50%. أما الطلبات العاجلة، فتتوفر لها فئة priority مقابل رسوم إضافية.

ما الذي ينبغي فعله الآن

إذا كان لديكم عملاء هنود يشترطون تخزين البيانات داخل البلاد، فيمكنكم الآن استخدام نموذج مفتوح قوي من دون استضافته بأنفسكم. ابدؤوا بفحص IAM وSCP، ثم أنشئوا نموذجا أوليا لاستخراج الحقول باستخدام 20–30 مستندا حقيقيا. وتنصح AWS نفسها بعدم الوثوق بصورة عمياء بالاستخراج الآلي: أضيفوا التحقق والمراجعة البشرية إلى العمليات الحرجة. أما الادعاءات بأن النموذج بمستوى «frontier»، فهي صادرة عن Moonshot AI، ولذلك ينبغي مقارنته بنموذجكم الحالي باستخدام بياناتكم الخاصة.