يواجه العديد من المؤسسات تحديًا متزايدًا في إدارة النماذج القديمة المبنية على TensorFlow، خاصة مع تراجع نشاط هذا الإطار وازدهار PyTorch كمُهيمن في مجال التعلم العميق. رغم أن النماذج القديمة تعمل، إلا أن الاستمرار بها ينطوي على مخاطر متعددة: تراجع الدعم الفني، انحسار المجتمع المُطور، وفقدان فرص التحسين مثل دعم التصحيح التلقائي (AMP) أو التصغير إلى 8 بت، فضلًا عن توقف دعم مكتبات رئيسية مثل HuggingFace لـ TensorFlow. تُعد خيارات التحويل إلى PyTorch ثلاثية: التوقف عن التدخل، أو التحويل اليدوي، أو التحويل الآلي. بينما يُعد التحويل اليدوي الأفضل من حيث الجودة، فإنه مكلف جدًا من حيث الوقت والموارد، خاصة مع النماذج الكبيرة والمعقدة. في هذا التحليل، تم اختبار طريقتين للتحويل الآلي: الأولى باستخدام تنسيق ONNX، والثانية عبر مكتبة Keras3. في الحالة الأولى، تم استخدام أدوات مثل tf2onnx وonnx2torch لتحويل نموذج Vision Transformer من TensorFlow إلى ONNX ثم إلى PyTorch. النتيجة كانت نموذجًا دقيقًا من حيث الناتج العددي (بفارق أقل من 10⁻⁶)، لكنه فقد البنية الأصلية تمامًا، حيث تقلّ عدد المعلمات من 85 مليونًا إلى 589 ألفًا، وتم تضمين بعض المعلمات داخل النموذج، مما يحوله إلى نموذج لا يمكن تدريبه أو تحسينه. كما أن التحويل أدى إلى تفكيك الرسوم البيانية إلى عمليات منخفضة المستوى، مما يعيق تطبيق تحسينات مثل scaled_dot_product_attention، ويجعل التجميع (compilation) بـ PyTorch غير فعّال. في المقابل، اعتمد الطرف الثاني على Keras3 كطبقة موحدة، حيث تم إعادة بناء النموذج باستخدام واجهة Keras3 المعيارية، ثم تشغيله عبر خلفية PyTorch. أظهر هذا النهج نتائج أفضل بكثير: حافظ النموذج على الهيكل الأصلي، وعدد المعلمات مطابق تقريبًا، ما يسمح بتدريبه أو تدريجه (fine-tuning) بسهولة. كما سمح بتبديل وحدة الانتباه بـ scaled_dot_product_attention من PyTorch، مما أدى إلى تسريع الأداء بنسبة 22% مقارنة بالنموذج الأصلي. ومع ذلك، يعاني هذا الأسلوب من قيود: يتطلب تكييف النموذج ليدعم Keras3، ويُنتج نموذجًا يحتوي على طبقات Keras3، ما قد يتعارض مع بعض أدوات PyTorch، كما أن دعم التجميع (torch.compile) لا يزال محدودًا حاليًا. في الختام، لا توجد حلول مثالية للتحويل التلقائي من TensorFlow إلى PyTorch. يُعد التحويل عبر Keras3 الأفضل من حيث المرونة والوظائف، لكنه يتطلب تغييرات في الكود. أما ONNX، فمفيد للاستدلال (inference) فقط، لكنه لا يُناسب التحسينات المتقدمة. القرار النهائي يعتمد على طبيعة النموذج، واحتياجات الفريق، ومستوى التزامه بالتحديث. في ظل تراجع TensorFlow، يُعد التحويل مسألة ضرورة، لكنه يتطلب تقييمًا دقيقًا لكل خيار.