הערות מפגישת שותפי TFF ב-8/11/2022

  • נושא מוצע לסדר היום: ג'רמי לוי יציג את רעיונותיו מבוססי TFF לרכיבים חדשים שניתן לבנות
  • [JL] התמקדות בתרחישי ניתוח מאוחדים פשוטים, מחברת TFF ל-Google Sheets כדי לבצע ממוצע פשוט. עובד ב-Kubernetes, קורא מגיליונות.
  • [JL] אתגר אחד הוא שכרגע העובדים נדרשים לנקודות כניסה.
    • לרוב זה לא המקרה, אז צריך שכבת תחבורה המאפשרת ליצור קישוריות בכיוון ההפוך, עובדים מתקשרים לשרת.
    • רכיב כזה אינו נמצא כעת במערכת האקולוגית.
  • [BC] גם ראה את הצורך בכך. משתמש כרגע ב-TFF בצורה מוגבלת, בענן פנימי שבו לקוחות מעלים נתונים. אבל, יהיה צורך במשהו כמו JL שתואר לעיל כדי לעבור להגדרת ריבוי נתונים.
  • [JL] חושב על שכבה שתאפשר לעובדים "למשוך" פריטי עבודה מתור בשרת - אם היא תחליף את זמן הריצה הקיים.
  • [KO] אל תצטרך לחשוב על זה במונחים של "החלפה" - אתה יכול לשמור את עריכת החישוב ו-98% מזמן הריצה זהים, והיית פשוט מחליף את הרכיב החדש שעובד כמו שאתה מציע במקום זאת מחוץ למבצע המרוחק כמנגנון להעברת בקשות מבצע מלמעלה למטה.
  • [BC] האם תצטרך שזה יהיה אסינכרון, או שזה יעבוד בתוך פרדיגמת הסנכרון הקיימת.
  • [BC] כמו כן, חלק מהפלטפורמות היוצאות אכן משתמשות בגישת "תור של משימות", כך שזה נשמע כמו רעיון מבוסס.
  • [BC] הצגת פסקי זמן תעזור אולי גם לגשר על הפער (כדי להתמודד עם עובדים איטיים או נפטרים).
  • [KO] ביחס לסנכרון לעומת אסינכרון, יש לנו הפשטות קולקטיביות ב-TFF שדורשות את המושג של "קבוצה". ככזה, צריך להיות זמן שבו חלק מהלקוחות שם מחליטים יחד להצטרף ל"קבוצה", והשרת יצטרך למלא תפקיד בתזמור שזה יקרה. כל עוד זה נעשה, האופן שבו בקשות מנהלים בודדות מועברות ללקוחות יכול להשתנות. מבצע מרוחק שקורא מלמעלה למטה הוא דרך אחת לעשות זאת, אבל לא היחידה; דפוס תקשורת מבוסס פריטי עבודה כמו מה שהוצע לעיל יכול בהחלט להשתלב במבנה הזה. נראה כמו חומר להצעת ביפר קטנה של אחד-שתיים למישהו לנסח?
  • [JL] מתנדב לרשום הצעה לרכיב חדש שכולנו נחזור עליו.
  • [JL] BTW, האם יש מאגרים סמוכים אחרים עם פונקציונליות קשורה?
  • [KO] לידיעתך, https://github.com/google/federated-compute גם מגוגל, אבל זה בעיקר מתמקד בתרחיש נייד, זה לא מחובר ל-TFF בשלב זה ואינו מכיל את הפונקציונליות שאתה מתאר כאן, אז בהחלט הגיוני לנסות ולנסח הצעה קטנה בקבוצה זו.
  • [BD] כמה שאלות להתייחס: תוצאות שמירה במטמון, מתי לצבור.
  • [Hao] אולי אין צורך במטמון בתרחיש הזה אם הוא לא אסינכרוני
  • [KO] לתרחישים המתאימים לדפוס MapReduce פשוט, יש לנו תמיכה מסוימת ב-TFF, ראה https://www.tensorflow.org/federated/api _docs/python/tff/backends/mapreduce. ספרייה זו מאפשרת לך לתרגם חישובי TFF לצורה דמוית MapReduce שתוכל לבצע בפלטפורמה פשוטה יותר. עם זאת, יש אובדן מסוים בכושר ההבעה, וחלק מהרעיונות שנדונו קודם לכן שדרשו סבבים מרובים של תקשורת הלוך ושוב בין sevrr ולקוחות לא יתבטאו במסגרת זו. כמו כן, ההגדרה צולבת ממגורות מאפשרת באופן ייחודי את סוגי הרעיונות הללו, מכיוון שאנו מתמודדים עם קבוצות של לקוחות מסופקים היטב (ממגורות) שיכולות לשמור על קשרים ארוכי טווח.
  • [Hao] מה לגבי פעולות קולקטיביות, allreduce - האם אלה נתמכים או תואמים
  • [KO] לא כרגע. ל- Allreduce יהיה שימוש מוגבל במקצת, בכך שאמנם ניתן למנף אותו בתרחיש ממוצע מוזן יחיד, אך היא מניחה שלא מתרחשת עבודה בשרת בין סבבי העיבוד. לא יעבוד במקרים כלליים יותר. אבל אם יש את שני החצאים שלו - מצב שידור יעיל ומצב צבירה יעיל, אולי אפילו עם האצת חומרה, יהיה משהו שנוכל לנצל ב-TFF.
  • [KO] נשמע ש-JL עומד לפתח טיוטה של ​​הצעה לרכיב חדש, ולאחרים יש דעות לגבי מה שצריך להיות בו - בואו נשתף פעולה (+1 מכולם בחדר). להתכנס מחדש בעוד שבועיים, אולי עם טיוטה לדיון.