ملاحظات من اجتماع متعاوني TFF بتاريخ 8/11/2022

  • موضوع جدول الأعمال المقترح: سيقدم جيريمي ليوي أفكاره المستندة إلى TFF للمكونات الجديدة التي يمكن بناؤها
  • [JL] التركيز على سيناريوهات التحليلات الموحدة البسيطة ، وربط TFF مع أوراق Google لعمل متوسط ​​تغذية بسيط. العمل في Kubernetes ، القراءة من الأوراق.
  • [JL] يتمثل أحد التحديات في أن العمال حاليًا مطالبون بالحصول على نقاط دخول.
    • هذا ليس هو الحال في كثير من الأحيان ، لذلك تحتاج إلى طبقة نقل تمكن من إنشاء الاتصال في الاتجاه المعاكس ، حيث يقوم العمال بالاتصال بالخادم.
    • هذا المكون ليس حاليا في النظام البيئي.
  • [قبل الميلاد] كما رأت الحاجة لذلك. تستخدم حاليًا TFF بطريقة محدودة ، سحابة داخلية حيث يقوم العملاء بتحميل البيانات. ولكن ، قد تحتاج إلى شيء مثل JL الموصوف أعلاه للانتقال إلى إعداد مركز بيانات متعدد.
  • [JL] التفكير في طبقة من شأنها أن تمكن العمال من "سحب" عناصر العمل من قائمة انتظار على الخادم - يجب أن تحل محل وقت التشغيل الحالي.
  • [KO] لا داعي للتفكير في هذا من حيث "الاستبدال" - يمكنك الاحتفاظ بتأليف الحساب و 98٪ من وقت التشغيل كما هو ، ويمكنك فقط تبديل المكون الجديد الذي يعمل بالطريقة التي تقترحها بدلاً من ذلك من المنفذ البعيد كآلية لترحيل طلبات المنفذ من أعلى لأسفل.
  • [BC] هل تريد أن يكون غير متزامن ، أم أنه سيعمل ضمن نموذج المزامنة الحالي.
  • [قبل الميلاد] أيضًا ، تستخدم بعض الأنظمة الأساسية القائمة نهج "قائمة انتظار المهام" ، لذلك يبدو هذا وكأنه فكرة راسخة.
  • [قبل الميلاد] قد يساعد تقديم المهلات أيضًا في سد الفجوة (للتعامل مع العمال البطيئين أو المتطرفين).
  • [KO] فيما يتعلق بالمزامنة مقابل غير المتزامن ، لدينا تجريدات جماعية في TFF تتطلب فكرة "مجموعة". على هذا النحو ، يجب أن يكون هناك وقت يقرر فيه بعض العملاء معًا الانضمام إلى "مجموعة" ، وسيحتاج الخادم إلى لعب دور في تنظيم هذا الأمر. طالما يتم ذلك ، يمكن أن تختلف الطريقة التي يتم بها نقل طلبات المنفذ الفردية للعملاء. المنفذ البعيد الذي يستدعي من أعلى لأسفل هو أحد الطرق للقيام بذلك ، ولكنه ليس الوحيد ؛ يمكن أيضًا أن يتناسب نمط الاتصال القائم على عناصر العمل مثل ما تم اقتراحه أعلاه مع هذا الهيكل. يبدو وكأنه مادة لاقتراح بيجر صغير لشخص ما ليقوم بصياغته؟
  • [JL] التطوع لكتابة مقترح مكون جديد لنا جميعًا للتكرار عليه.
  • [JL] راجع للشغل ، هل هناك مستودعات أخرى مجاورة لها وظائف ذات صلة؟
  • [KO] لمعلوماتك ، https://github.com/google/federated-compute أيضًا من Google ، ولكن هذا يركز في الغالب على سيناريو للجوال ، فهو غير متصل بـ TFF في هذه المرحلة ، ولا يحتوي على الوظيفة التي الوصف هنا ، لذلك من المنطقي بالتأكيد محاولة صياغة اقتراح صغير في هذه المجموعة.
  • [BD] بعض الأسئلة التي يجب معالجتها: تخزين النتائج مؤقتًا ، ومتى يتم التجميع.
  • [Hao] ربما لا تحتاج إلى التخزين المؤقت في هذا السيناريو إذا لم يكن غير متزامن
  • [KO] بالنسبة للسيناريوهات التي تناسب نمط MapReduce البسيط ، لدينا بعض الدعم في TFF ، راجع https://www.tensorflow.org/federated/api _docs / python / tff / backends / mapreduce. تمكنك هذه المكتبة من ترجمة حسابات TFF إلى نموذج يشبه MapReduce يمكنك تنفيذه على نظام أساسي أبسط. ومع ذلك ، هناك بعض الخسارة في التعبير ، وبعض الأفكار التي نوقشت سابقًا والتي تتطلب جولات متعددة من الاتصال ذهابًا وإيابًا بين سيفر والعملاء لن يتم التعبير عنها في هذا الإطار. كما أن إعداد الصوامع المتقاطعة يجعل هذه الأنواع من الأفكار ممكنة بشكل فريد ، نظرًا لأننا نتعامل مع مجموعات من العملاء الموفرين جيدًا (الصوامع) التي يمكنها الحفاظ على اتصالات طويلة الأمد.
  • [Hao] ماذا عن العمليات الجماعية ، allreduce - هي تلك المدعومة أو المتوافقة
  • [KO] ليس حاليًا. سيكون استخدام Allreduce محدودًا إلى حد ما ، حيث يمكن الاستفادة منه في سيناريو متوسط ​​تغذية واحد ، إلا أنه يفترض عدم حدوث أي عمل على الخادم بين جولات المعالجة. لن تعمل في حالات أكثر عمومية. ولكن ، الحصول على نصفيها - الوضع الفعال للبث والوضع الفعال للتجميع ، ربما حتى مع تسريع الأجهزة ، سيكون شيئًا يمكننا الاستفادة منه في TFF.
  • [KO] يبدو أن JL جاهز لبدء مسودة اقتراح لمكون جديد ، والآخرون لديهم آراء حول ما يجب أن يتضمنه - فلنتعاون (+1 من الجميع في الغرفة). للانعقاد مرة أخرى في غضون أسبوعين ، ربما مع مسودة للمناقشة.