บันทึกจากการประชุม 8/11/2022 ของผู้ร่วมงาน TFF

  • หัวข้อวาระที่เสนอ: Jeremy Lewi จะนำเสนอแนวคิดเกี่ยวกับ TFF ของเขาสำหรับองค์ประกอบใหม่ที่สามารถสร้างได้
  • [JL] มุ่งเน้นไปที่สถานการณ์การวิเคราะห์แบบรวมศูนย์อย่างง่าย โดยเชื่อมต่อ TFF กับ Google ชีตเพื่อทำการหาค่าเฉลี่ยแบบง่ายๆ ทำงานใน Kubernetes อ่านจากแผ่นงาน
  • [JL] ความท้าทายประการหนึ่งคือการที่พนักงานในปัจจุบันจำเป็นต้องมีจุดทางเข้า
    • ซึ่งมักจะไม่เป็นเช่นนั้น ดังนั้นจำเป็นต้องมีชั้นการขนส่งที่เปิดใช้งานการเชื่อมต่อในทิศทางตรงกันข้าม พนักงานเรียกเซิร์ฟเวอร์
    • ปัจจุบันองค์ประกอบดังกล่าวไม่อยู่ในระบบนิเวศ
  • [BC] ยังเห็นความจำเป็นในเรื่องนี้ ปัจจุบันใช้ TFF ในระบบคลาวด์ภายในที่จำกัด ซึ่งลูกค้าจะอัปโหลดข้อมูล แต่จะต้องใช้บางอย่างเช่น JL ที่อธิบายข้างต้นเพื่อย้ายไปยังการตั้งค่าศูนย์ข้อมูลหลายศูนย์
  • [JL] การคิดถึงเลเยอร์ที่จะช่วยให้ผู้ปฏิบัติงานสามารถ "ดึง" รายการงานจากคิวบนเซิร์ฟเวอร์ - ควรแทนที่รันไทม์ที่มีอยู่
  • [KO] ไม่จำเป็นต้องคิดถึงสิ่งนี้ในแง่ของ "การแทนที่" - คุณสามารถเก็บการเขียนการคำนวณและ 98% ของรันไทม์ไว้เหมือนเดิม และคุณเพียงแค่สลับองค์ประกอบใหม่ที่ทำงานในแบบที่คุณเสนอแทน ปิดตัวดำเนินการระยะไกลเป็นกลไกสำหรับการส่งต่อคำขอตัวดำเนินการจากบนลงล่าง
  • [BC] คุณต้องการให้เป็น async หรือจะทำงานภายในกระบวนทัศน์การซิงค์ที่มีอยู่
  • [BC] นอกจากนี้ แพลตฟอร์มที่ออกจากระบบบางส่วนใช้แนวทาง "คิวงาน" ดังนั้น นี่จึงดูเหมือนเป็นแนวคิดที่เป็นที่ยอมรับ
  • [BC] การแนะนำการหมดเวลาอาจช่วยลดช่องว่างได้ (เพื่อจัดการกับคนทำงานช้าหรือคนพเนจร)
  • [KO] ในส่วนที่เกี่ยวกับ sync vs. async เรามีสิ่งที่เป็นนามธรรมร่วมกันใน TFF ที่ต้องใช้แนวคิดของ "กลุ่มประชากรตามรุ่น" ดังนั้น จึงจำเป็นต้องมีเวลาที่ลูกค้าบางรายตัดสินใจร่วมกันเพื่อเข้าร่วม "กลุ่มประชากรตามรุ่น" และเซิร์ฟเวอร์จะต้องมีบทบาทในการเตรียมสิ่งนี้ให้เกิดขึ้น ตราบใดที่ดำเนินการเสร็จแล้ว วิธีที่ส่งคำขอของผู้ดำเนินการแต่ละรายไปยังไคลเอ็นต์อาจแตกต่างกันไป ตัวดำเนินการระยะไกลที่เรียกใช้จากบนลงล่างเป็นวิธีหนึ่งในการดำเนินการ แต่ไม่ใช่วิธีเดียวเท่านั้น รูปแบบการสื่อสารตามรายการงานเช่นเดียวกับที่เสนอข้างต้นสามารถเข้ากับโครงสร้างนี้ได้อย่างแน่นอน ดูเหมือนเอกสารสำหรับข้อเสนอเพจเจอร์ขนาดเล็กหนึ่งหรือสองสำหรับใครบางคนที่จะร่าง?
  • [JL] อาสาสมัครเขียนข้อเสนอสำหรับองค์ประกอบใหม่เพื่อให้เราทุกคนทำซ้ำ
  • [JL] BTW มี repos อื่นที่อยู่ติดกันที่มีฟังก์ชันที่เกี่ยวข้องหรือไม่
  • [KO] FYI https://github.com/google/federated-compute จาก Google เช่นกัน แต่ส่วนใหญ่เน้นไปที่สถานการณ์บนมือถือ ตอนนี้ไม่ได้เชื่อมต่อกับ TFF และไม่มีฟังก์ชันที่คุณอยู่ อธิบายไว้ที่นี่ ดังนั้นจึงเหมาะสมอย่างยิ่งที่จะลองจัดทำข้อเสนอเล็กๆ ในกลุ่มนี้
  • [BD] คำถามที่ต้องตอบ: การแคชผลลัพธ์ ควรรวมเมื่อใด
  • [Hao] อาจไม่จำเป็นต้องแคชในสถานการณ์นี้หากไม่ใช่ async
  • [KO] สำหรับสถานการณ์ที่พอดีกับรูปแบบ MapReduce อย่างง่าย เรามีการสนับสนุนใน TFF ดู https://www.tensorflow.org/federated/api _docs/python/tff/backends/mapreduce ไลบรารีนี้ช่วยให้คุณสามารถแปลการคำนวณ TFF เป็นรูปแบบที่คล้ายกับ MapReduce ซึ่งคุณสามารถดำเนินการบนแพลตฟอร์มที่ง่ายกว่า อย่างไรก็ตาม มีความสูญเสียในการแสดงออก และแนวคิดบางส่วนที่กล่าวถึงก่อนหน้านี้ที่ต้องใช้การสื่อสารไปมาหลายรอบระหว่าง sevrr และไคลเอนต์จะไม่แสดงออกมาในกรอบการทำงานนี้ และการตั้งค่าแบบข้ามไซโลทำให้ไอเดียประเภทเหล่านั้นเป็นไปได้โดยเฉพาะ เนื่องจากเรากำลังติดต่อกับกลุ่มลูกค้าที่มีการเตรียมการอย่างดี (ไซโล) ที่สามารถรักษาความสัมพันธ์ที่ยาวนานได้
  • [Hao] สิ่งที่เกี่ยวกับ ops โดยรวม allreduce - สิ่งเหล่านั้นรองรับหรือเข้ากันได้
  • [KO] ไม่ใช่ตอนนี้ Allreduce จะมีการใช้งานที่ค่อนข้างจำกัด ในขณะที่มันสามารถใช้ประโยชน์ได้ในสถานการณ์เฉลี่ยที่ป้อนครั้งเดียว แต่จะถือว่าไม่มีงานเกิดขึ้นบนเซิร์ฟเวอร์ในระหว่างรอบของการประมวลผล จะไม่ทำงานในกรณีทั่วไปมากขึ้น แต่การมีสองส่วน - โหมดการแพร่ภาพที่มีประสิทธิภาพและโหมดการรวมที่มีประสิทธิภาพ บางทีถึงแม้จะใช้การเร่งด้วยฮาร์ดแวร์ ก็เป็นสิ่งที่เราสามารถใช้ประโยชน์จาก TFF ได้
  • [KO] ดูเหมือน JL พร้อมที่จะเริ่มร่างข้อเสนอสำหรับองค์ประกอบใหม่ และคนอื่นๆ มีความคิดเห็นว่าควรมีอะไรอยู่ในนั้น มาร่วมมือกัน (+1 จากทุกคนในห้องนี้) ให้กลับมาประชุมใหม่ในอีก 2 สัปดาห์ อาจมีร่างให้หารือ