این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

یادگیری فدرال

بررسی اجمالی

این سند رابط هایی را معرفی می کند که وظایف یادگیری فدرال را تسهیل می کند، مانند آموزش یا ارزیابی فدرال با مدل های یادگیری ماشین موجود پیاده سازی شده در TensorFlow. در طراحی این رابط‌ها، هدف اصلی ما این بود که امکان آزمایش یادگیری فدرال را بدون نیاز به دانش نحوه عملکرد آن در زیر هود فراهم کنیم و الگوریتم‌های یادگیری فدرال پیاده‌سازی شده را بر روی انواع مدل‌ها و داده‌های موجود ارزیابی کنیم. ما شما را تشویق می کنیم که دوباره به پلتفرم کمک کنید. TFF با در نظر گرفتن توسعه پذیری و ترکیب پذیری طراحی شده است و ما از مشارکت ها استقبال می کنیم. ما هیجان زده هستیم که ببینیم شما با چه چیزی روبرو می شوید!

رابط های ارائه شده توسط این لایه از سه بخش کلیدی زیر تشکیل شده است:

مدل ها کلاس ها و توابع کمکی که به شما امکان می دهد مدل های موجود خود را برای استفاده با TFF بپیچید. بسته بندی یک مدل می تواند به سادگی فراخوانی یک تابع پیچیده (مثلا tff.learning.models.from_keras_model )، یا تعریف زیر کلاسی از رابط tff.learning.models.VariableModel برای سفارشی سازی کامل باشد.
سازندگان محاسبات فدرال توابع کمکی که محاسبات فدرال را برای آموزش یا ارزیابی با استفاده از مدل‌های موجود شما می‌سازند.
مجموعه داده ها مجموعه‌ای از داده‌های ذخیره‌شده که می‌توانید برای استفاده در شبیه‌سازی سناریوهای یادگیری فدرال، در پایتون دانلود کنید و به آنها دسترسی پیدا کنید. اگرچه یادگیری فدرال برای استفاده با داده‌های غیرمتمرکز طراحی شده است که نمی‌توان آنها را به سادگی در یک مکان متمرکز دانلود کرد، در مراحل تحقیق و توسعه اغلب راحت است که آزمایش‌های اولیه با استفاده از داده‌هایی انجام شود که می‌توانند به صورت محلی دانلود و دستکاری شوند، به ویژه برای توسعه دهندگانی که ممکن است جدید به رویکرد

این رابط ها عمدتاً در فضای نام tff.learning تعریف می شوند، به جز مجموعه داده های تحقیق و سایر قابلیت های مرتبط با شبیه سازی که در tff.simulation گروه بندی شده اند. این لایه با استفاده از رابط های سطح پایین ارائه شده توسط هسته مرکزی (FC) پیاده سازی شده است که یک محیط زمان اجرا را نیز فراهم می کند.

قبل از ادامه، توصیه می‌کنیم ابتدا آموزش‌های طبقه‌بندی تصویر و تولید متن را مرور کنید، زیرا آنها بیشتر مفاهیمی را که در اینجا شرح داده شده‌اند با استفاده از مثال‌های عینی معرفی می‌کنند. اگر علاقه مند به یادگیری بیشتر در مورد نحوه عملکرد TFF هستید، ممکن است بخواهید آموزش الگوریتم های سفارشی را به عنوان مقدمه ای بر رابط های سطح پایین تر که برای بیان منطق محاسبات فدرال استفاده می کنیم و برای مطالعه پیاده سازی موجود از رابط های tff.learning .

مدل ها

مفروضات معماری

سریال سازی

هدف TFF پشتیبانی از انواع سناریوهای یادگیری توزیع شده است که در آنها کد مدل یادگیری ماشینی که شما می نویسید ممکن است بر روی تعداد زیادی از مشتریان ناهمگن با قابلیت های متنوع اجرا شود. در حالی که در یک انتهای طیف، در برخی از برنامه‌ها، این کلاینت‌ها ممکن است سرورهای پایگاه داده قدرتمندی باشند، بسیاری از کاربردهای مهم پلت فرم ما قصد دارد از آن پشتیبانی کند، شامل دستگاه‌های تلفن همراه و جاسازی شده با منابع محدود. ما نمی توانیم فرض کنیم که این دستگاه ها قادر به میزبانی زمان اجرا پایتون هستند. تنها چیزی که در این مرحله می توانیم فرض کنیم این است که آنها می توانند یک زمان اجرا محلی TensorFlow را میزبانی کنند. بنابراین، یک فرض اساسی معماری که ما در TFF می‌کنیم این است که کد مدل شما باید به‌عنوان یک گراف TensorFlow قابل سریال‌سازی باشد.

همچنان می توانید (و باید) کد TF خود را با پیروی از آخرین بهترین شیوه ها مانند استفاده از حالت مشتاق توسعه دهید. با این حال، کد نهایی باید سریال‌سازی شود (مثلاً می‌تواند به عنوان یک tf.function برای کد حالت مشتاق بسته شود). این تضمین می‌کند که هر وضعیت پایتون یا جریان کنترلی که در زمان اجرا ضروری است را می‌توان سریال‌سازی کرد (احتمالاً با کمک Autograph ).

در حال حاضر، TensorFlow به طور کامل از سریال‌سازی و سریال‌زدایی از حالت مشتاق TensorFlow پشتیبانی نمی‌کند. بنابراین، سریال سازی در TFF در حال حاضر از الگوی TF 1.0 پیروی می کند، که در آن تمام کدها باید در داخل یک tf.Graph ساخته شوند که TFF کنترل می کند. این بدان معناست که در حال حاضر TFF نمی تواند یک مدل از قبل ساخته شده را مصرف کند. در عوض، منطق تعریف مدل در یک تابع بدون arg بسته بندی شده است که یک tff.learning.models.VariableModel را برمی گرداند. سپس این تابع توسط TFF فراخوانی می شود تا اطمینان حاصل شود که تمام اجزای مدل سریالی هستند. علاوه بر این، TFF به عنوان یک محیط با تایپ قوی، به کمی فراداده اضافی نیاز دارد، مانند مشخصات نوع ورودی مدل شما.

تجمع

ما قویاً به اکثر کاربران توصیه می‌کنیم که مدل‌هایی را با استفاده از Keras بسازند، بخش Converters for Keras را در زیر ببینید. این بسته‌بندی‌ها جمع‌آوری به‌روزرسانی‌های مدل و همچنین هر معیاری را که برای مدل تعریف شده است به‌طور خودکار مدیریت می‌کنند. با این حال، هنوز هم ممکن است مفید باشد که بفهمیم چگونه تجمیع برای یک tff.learning.models.VariableModel کلی انجام می شود.

همیشه حداقل دو لایه از تجمیع در یادگیری فدرال وجود دارد: تجمیع محلی روی دستگاه و تجمیع بین دستگاهی (یا فدرال):

تجمع محلی . این سطح از تجمیع به تجمیع در چندین دسته از نمونه های متعلق به یک مشتری منفرد اشاره دارد. این هم برای پارامترهای مدل (متغیرها) اعمال می‌شود، که با آموزش محلی به شکل متوالی ادامه می‌دهند، و هم برای آمارهایی که محاسبه می‌کنید (مانند میانگین ضرر، دقت و سایر معیارها)، که مدل شما دوباره به‌صورت محلی به‌روزرسانی می‌شود. همانطور که روی جریان داده محلی هر مشتری جداگانه تکرار می شود.
انجام تجمیع در این سطح به عهده کد مدل شما است و با استفاده از ساختارهای استاندارد TensorFlow انجام می شود.
ساختار کلی پردازش به شرح زیر است:
- مدل ابتدا tf.Variable s را برای نگهداری مجموعه‌ها می‌سازد، مانند تعداد دسته‌ها یا تعداد نمونه‌های پردازش‌شده، مجموع تلفات هر دسته یا هر مثال و غیره.
- TFF چندین بار متد forward_pass را در Model شما فراخوانی می‌کند، به‌طور متوالی بر روی دسته‌های بعدی داده‌های کلاینت، که به شما امکان می‌دهد متغیرهایی را که مجموعه‌های مختلف را به عنوان یک اثر جانبی در خود نگه می‌دارند، به‌روزرسانی کنید.
- در نهایت، TFF از روش report_local_unfinalized_metrics در مدل شما استفاده می‌کند تا به مدل شما اجازه دهد تمام آمار خلاصه‌ای را که جمع‌آوری کرده در مجموعه فشرده‌ای از معیارها جمع‌آوری کند تا توسط مشتری صادر شود. اینجاست که کد مدل شما ممکن است، به عنوان مثال، مجموع ضررها را بر تعداد نمونه های پردازش شده برای صادرات میانگین ضرر و غیره تقسیم کند.
تجمع فدرال این سطح از تجمیع به تجمع در چندین مشتری (دستگاه) در سیستم اشاره دارد. مجدداً، هم برای پارامترهای مدل (متغیرها) که در بین مشتریان میانگین می‌شوند و هم برای معیارهایی که مدل شما در نتیجه تجمیع محلی صادر می‌کند، اعمال می‌شود.
انجام تجمیع در این سطح بر عهده TFF است. با این حال، به‌عنوان یک خالق مدل، می‌توانید این فرآیند را کنترل کنید (اطلاعات بیشتر در این مورد در زیر).
ساختار کلی پردازش به شرح زیر است:
- مدل اولیه و هر پارامتری که برای آموزش لازم است، توسط یک سرور بین زیرمجموعه ای از مشتریان توزیع می شود که در یک دوره آموزشی یا ارزیابی شرکت خواهند کرد.
- در هر کلاینت، به طور مستقل و موازی، کد مدل شما به طور مکرر بر روی جریانی از دسته‌های داده محلی برای تولید مجموعه جدیدی از پارامترهای مدل (هنگام آموزش) و مجموعه جدیدی از معیارهای محلی، همانطور که در بالا توضیح داده شد، فراخوانی می‌شود (این محلی است). تجمع).
- TFF یک پروتکل تجمیع توزیع شده را برای جمع آوری و تجمیع پارامترهای مدل و معیارهای محلی صادر شده در سراسر سیستم اجرا می کند. این منطق با استفاده از زبان محاسباتی فدرال خود TFF (نه در TensorFlow) به صورت اعلانی بیان می شود. برای اطلاعات بیشتر در مورد API تجمیع، آموزش الگوریتم های سفارشی را ببینید.

رابط های انتزاعی

این رابط سازنده اصلی + ابرداده با رابط tff.learning.models.VariableModel به صورت زیر نمایش داده می شود:

متدهای سازنده، forward_pass و report_local_unfinalized_metrics باید متغیرهای مدل، پاس رو به جلو و آماری را که می‌خواهید گزارش کنید، ایجاد کنند. همانطور که در بالا توضیح داده شد، TensorFlow ساخته شده توسط این روش ها باید قابل سریال سازی باشد.
ویژگی input_spec و همچنین 3 خاصیت که زیرمجموعه‌های متغیرهای آموزش‌پذیر، غیرقابل آموزش و محلی شما را برمی‌گردانند، ابرداده را نشان می‌دهند. TFF از این اطلاعات برای تعیین نحوه اتصال بخش‌هایی از مدل شما به الگوریتم‌های بهینه‌سازی فدرال استفاده می‌کند، و امضاهای نوع داخلی را برای کمک به تأیید صحت سیستم ساخته‌شده تعریف می‌کند (به طوری که مدل شما نمی‌تواند روی داده‌هایی که با آنچه مطابقت ندارند نمونه‌سازی شود. مدل برای مصرف طراحی شده است).

علاوه بر این، رابط انتزاعی tff.learning.models.VariableModel ویژگی metric_finalizers را نشان می‌دهد که مقادیر نهایی نشده یک متریک را می‌گیرد (بازگردانده شده توسط report_local_unfinalized_metrics() ) و مقادیر متریک نهایی را برمی‌گرداند. متد metric_finalizers و report_local_unfinalized_metrics() با هم برای ایجاد یک جمع‌کننده معیارهای متقابل مشتری هنگام تعریف فرآیندهای آموزشی فدرال یا محاسبات ارزیابی استفاده می‌شود. به عنوان مثال، یک جمع‌کننده ساده tff.learning.metrics.sum_then_finalize ابتدا مقادیر متریک نهایی نشده مشتریان را جمع می‌کند و سپس توابع نهایی‌کننده را در سرور فراخوانی می‌کند.

می‌توانید نمونه‌هایی از نحوه تعریف tff.learning.models.VariableModel سفارشی خود را در قسمت دوم آموزش طبقه‌بندی تصاویر و همچنین در مدل‌های نمونه‌ای که برای آزمایش در model_examples.py استفاده می‌کنیم، بیابید.

مبدل کراس

تقریباً تمام اطلاعات مورد نیاز TFF را می توان با فراخوانی رابط های tf.keras به دست آورد، بنابراین اگر یک مدل Keras دارید، می توانید برای ساخت tff.learning.models.from_keras_model به tff.learning.models.VariableModel تکیه کنید.

توجه داشته باشید که TFF همچنان از شما می خواهد که یک سازنده - یک تابع مدل بدون آرگومان مانند موارد زیر ارائه دهید:

def model_fn():
  keras_model = ...
  return tff.learning.models.from_keras_model(keras_model, sample_batch, loss=...)

علاوه بر خود مدل، شما یک دسته نمونه از داده ها را ارائه می کنید که TFF از آن برای تعیین نوع و شکل ورودی مدل شما استفاده می کند. این تضمین می‌کند که TFF می‌تواند به درستی مدل داده‌هایی را که واقعاً در دستگاه‌های کلاینت وجود دارد، نمونه‌سازی کند (از آنجایی که فرض می‌کنیم این داده‌ها به طور کلی در زمانی که شما در حال ساخت TensorFlow برای سریال‌سازی هستید، در دسترس نیستند).

استفاده از Wrappers Keras در طبقه بندی تصاویر و آموزش های تولید متن نشان داده شده است.

سازندگان محاسبات فدرال

بسته tff.learning چندین سازنده برای tff.Computation فراهم می کند که وظایف مرتبط با یادگیری را انجام می دهند. ما انتظار داریم مجموعه چنین محاسباتی در آینده گسترش یابد.

مفروضات معماری

اجرا

دو مرحله مجزا در اجرای یک محاسبات فدرال وجود دارد.

کامپایل : TFF ابتدا الگوریتم های یادگیری فدرال را در یک نمایش سریالی انتزاعی از کل محاسبات توزیع شده گردآوری می کند . این زمانی است که سریال‌سازی TensorFlow اتفاق می‌افتد، اما تغییرات دیگری برای پشتیبانی از اجرای کارآمدتر ممکن است رخ دهد. ما به نمایش سریالی منتشر شده توسط کامپایلر به عنوان یک محاسبات فدرال اشاره می کنیم.
Execute TFF راه هایی را برای اجرای این محاسبات ارائه می دهد. در حال حاضر، اجرا فقط از طریق یک شبیه سازی محلی (مثلاً در یک نوت بوک با استفاده از داده های غیرمتمرکز شبیه سازی شده) پشتیبانی می شود.

یک محاسبات فدرال ایجاد شده توسط API یادگیری فدرال TFF، مانند یک الگوریتم آموزشی که از میانگین‌گیری مدل فدرال استفاده می‌کند، یا یک ارزیابی فدرال، شامل تعدادی از عناصر است که مهم‌ترین آنها عبارتند از:

یک فرم سریالی از کد مدل شما و همچنین کد TensorFlow اضافی که توسط چارچوب یادگیری فدرال ساخته شده است تا حلقه آموزش/ارزیابی مدل شما را هدایت کند (مانند ساخت بهینه سازها، اعمال به روز رسانی مدل، تکرار روی tf.data.Dataset ، و معیارهای محاسباتی، و اعمال به روز رسانی انبوه بر روی سرور، به نام چند).
مشخصات اعلامی ارتباط بین کلاینت ها و سرور (معمولاً اشکال مختلف تجمیع در دستگاه های کلاینت و پخش از سرور به همه مشتریان) و اینکه چگونه این ارتباط توزیع شده با اجرای کلاینت-محلی یا سرور-محلی درهم می آمیزد. کد TensorFlow

محاسبات فدرال ارائه شده در این فرم سریالی در یک زبان داخلی مستقل از پلتفرم و متمایز از پایتون بیان می‌شوند، اما برای استفاده از API یادگیری فدرال، نیازی نیست که خود را با جزئیات این نمایش درگیر کنید. محاسبات در کد پایتون شما به عنوان اشیایی از نوع tff.Computation نشان داده می‌شوند، که در بیشتر موارد می‌توانید آن را به‌عنوان s غیرشفاف Python callable در نظر بگیرید.

در آموزش‌ها، شما آن محاسبات فدرال را به گونه‌ای فراخوانی می‌کنید که گویی توابع معمولی پایتون هستند تا به صورت محلی اجرا شوند. با این حال، TFF برای بیان محاسبات فدرال به گونه‌ای طراحی شده است که بیشتر جنبه‌های محیط اجرا را ناشناخته نشان دهد، به طوری که می‌توانند به طور بالقوه در گروه‌هایی از دستگاه‌های دارای Android یا در خوشه‌هایی در یک مرکز داده قابل اجرا باشند. باز هم، پیامد اصلی این فرضیات قوی در مورد سریال سازی است. به طور خاص، هنگامی که یکی از روش های build_... را که در زیر توضیح داده شده است فراخوانی می کنید، محاسبات کاملاً سریالی می شود.

حالت مدل سازی

TFF یک محیط برنامه نویسی کاربردی است، اما بسیاری از فرآیندهای مورد علاقه در یادگیری فدرال حالتی هستند. به عنوان مثال، یک حلقه آموزشی که شامل چندین دور میانگین‌گیری مدل فدرال است، نمونه‌ای از آن چیزی است که می‌توانیم آن را به عنوان یک فرآیند حالت طبقه‌بندی کنیم. در این فرآیند، حالتی که از دور به دور تغییر می‌کند، شامل مجموعه‌ای از پارامترهای مدل است که در حال آموزش هستند، و احتمالاً حالت اضافی مرتبط با بهینه‌ساز (مثلاً یک بردار حرکت).

از آنجایی که TFF عملکردی است، فرآیندهای حالت دار در TFF به عنوان محاسباتی مدل می شوند که حالت فعلی را به عنوان ورودی می پذیرند و سپس حالت به روز شده را به عنوان خروجی ارائه می کنند. برای تعریف کامل یک فرآیند stateful، باید مشخص شود که حالت اولیه از کجا می آید (در غیر این صورت نمی توانیم فرآیند را بوت استرپ کنیم). این در تعریف کلاس کمکی tff.templates.IterativeProcess ، با 2 ویژگی initialize و next مربوط به مقدار دهی اولیه و تکرار، به تصویر کشیده شده است.

سازندگان موجود

در حال حاضر، TFF توابع سازنده مختلفی را ارائه می دهد که محاسبات فدرال را برای آموزش و ارزیابی فدرال ایجاد می کند. دو مثال قابل توجه عبارتند از:

tff.learning.algorithms.build_weighted_fed_avg ، که یک تابع مدل و یک بهینه‌ساز کلاینت را به عنوان ورودی می‌گیرد و یک tff.learning.templates.LearningProcess (که زیر کلاس tff.templates.IterativeProcess را تشکیل می‌دهد) را برمی‌گرداند.
tff.learning.build_federated_evaluation یک تابع مدل را می گیرد و یک محاسبات واحد را برای ارزیابی فدرال مدل ها برمی گرداند، زیرا ارزیابی حالتی نیست.

مجموعه داده ها

مفروضات معماری

انتخاب مشتری

در سناریوی یادگیری فدرال معمولی، ما جمعیت زیادی متشکل از صدها میلیون دستگاه مشتری داریم که تنها بخش کوچکی از آنها ممکن است در هر لحظه فعال و برای آموزش در دسترس باشند (برای مثال، این ممکن است محدود به مشتریانی باشد که به یک منبع برق وصل شده است، نه در یک شبکه اندازه گیری، و در غیر این صورت بیکار). به طور کلی، مجموعه مشتریان در دسترس برای شرکت در آموزش یا ارزیابی خارج از کنترل توسعه دهنده است. علاوه بر این، از آنجایی که هماهنگ کردن میلیون‌ها مشتری غیرعملی است، یک دور معمولی از آموزش یا ارزیابی تنها بخشی از مشتریان موجود را شامل می‌شود که ممکن است به‌طور تصادفی نمونه‌برداری شوند.

پیامد اصلی این امر این است که محاسبات فدرال، بر اساس طراحی، به گونه‌ای بیان می‌شوند که از مجموعه دقیق شرکت‌کنندگان غافل است. تمام پردازش ها به صورت عملیات انبوه بر روی یک گروه انتزاعی از مشتریان ناشناس بیان می شود، و این گروه ممکن است از یک دوره آموزشی به دور دیگر متفاوت باشد. بنابراین، اتصال واقعی محاسبات به شرکت‌کنندگان مشخص، و بنابراین به داده‌های مشخصی که آنها به محاسبات وارد می‌کنند، خارج از خود محاسبات مدل‌سازی می‌شود.

به منظور شبیه سازی یک استقرار واقعی کد یادگیری فدرال خود، به طور کلی یک حلقه آموزشی می نویسید که به شکل زیر است:

trainer = tff.learning.algorithms.build_weighted_fed_avg(...)
state = trainer.initialize()
federated_training_data = ...

def sample(federate_data):
  return ...

while True:
  data_for_this_round = sample(federated_training_data)
  result = trainer.next(state, data_for_this_round)
  state = result.state

به منظور تسهیل این امر، هنگام استفاده از TFF در شبیه‌سازی، داده‌های فدرال به‌عنوان list پایتون پذیرفته می‌شوند، با یک عنصر برای هر دستگاه مشتری شرکت‌کننده برای نمایش tf.data.Dataset محلی آن دستگاه.

رابط های انتزاعی

به منظور استاندارد کردن برخورد با مجموعه داده های فدرال شبیه سازی شده، TFF یک رابط انتزاعی tff.simulation.datasets.ClientData ارائه می دهد که به فرد اجازه می دهد مجموعه ای از مشتریان را برشمرد، و یک tf.data.Dataset را بسازد که حاوی داده های یک خاص است. مشتری. آن tf.data.Dataset را می توان مستقیماً به عنوان ورودی به محاسبات فدرال تولید شده در حالت مشتاق تغذیه کرد.

لازم به ذکر است که امکان دسترسی به هویت مشتری یک ویژگی است که فقط توسط مجموعه داده ها برای استفاده در شبیه سازی ها ارائه می شود، جایی که ممکن است به توانایی آموزش داده ها از زیر مجموعه های خاص مشتریان نیاز باشد (به عنوان مثال، برای شبیه سازی در دسترس بودن روزانه انواع مختلف انواع مشتریان). محاسبات کامپایل شده و زمان اجرا اساسی هیچ مفهومی از هویت مشتری ندارند . هنگامی که داده‌های زیرمجموعه خاصی از کلاینت‌ها به‌عنوان ورودی انتخاب شدند، به عنوان مثال، در تماس با tff.templates.IterativeProcess.next ، هویت مشتری دیگر در آن ظاهر نمی‌شود.

مجموعه داده های موجود

ما فضای نام tff.simulation.datasets را به مجموعه داده‌هایی اختصاص داده‌ایم که رابط tff.simulation.datasets.ClientData را برای استفاده در شبیه‌سازی‌ها پیاده‌سازی می‌کنند، و آن را با مجموعه‌های داده برای پشتیبانی از طبقه‌بندی تصویر و آموزش‌های تولید متن بکار می‌بریم. مایلیم شما را تشویق کنیم که مجموعه داده های خود را در پلتفرم مشارکت دهید.

بررسی اجمالی

رابط های ارائه شده توسط این لایه از سه بخش کلیدی زیر تشکیل شده است:

مدل ها کلاس ها و توابع کمکی که به شما امکان می دهد مدل های موجود خود را برای استفاده با TFF بپیچید. بسته بندی یک مدل می تواند به سادگی فراخوانی یک تابع پیچیده (مثلا tff.learning.models.from_keras_model )، یا تعریف زیر کلاسی از رابط tff.learning.models.VariableModel برای سفارشی سازی کامل باشد.
سازندگان محاسبات فدرال توابع کمکی که محاسبات فدرال را برای آموزش یا ارزیابی با استفاده از مدل‌های موجود شما می‌سازند.
مجموعه داده ها مجموعه‌ای از داده‌های ذخیره‌شده که می‌توانید برای استفاده در شبیه‌سازی سناریوهای یادگیری فدرال، در پایتون دانلود کنید و به آنها دسترسی پیدا کنید. اگرچه یادگیری فدرال برای استفاده با داده‌های غیرمتمرکز طراحی شده است که نمی‌توان آنها را به سادگی در یک مکان متمرکز دانلود کرد، در مراحل تحقیق و توسعه اغلب راحت است که آزمایش‌های اولیه با استفاده از داده‌هایی انجام شود که می‌توانند به صورت محلی دانلود و دستکاری شوند، به ویژه برای توسعه دهندگانی که ممکن است جدید به رویکرد

مدل ها

مفروضات معماری

سریال سازی

تجمع

همیشه حداقل دو لایه از تجمیع در یادگیری فدرال وجود دارد: تجمیع محلی روی دستگاه و تجمیع بین دستگاهی (یا فدرال):

تجمع محلی . این سطح از تجمیع به تجمیع در چندین دسته از نمونه های متعلق به یک مشتری منفرد اشاره دارد. این هم برای پارامترهای مدل (متغیرها) اعمال می‌شود، که با آموزش محلی به شکل متوالی ادامه می‌دهند، و هم برای آمارهایی که محاسبه می‌کنید (مانند میانگین ضرر، دقت و سایر معیارها)، که مدل شما دوباره به‌صورت محلی به‌روزرسانی می‌شود. همانطور که روی جریان داده محلی هر مشتری جداگانه تکرار می شود.
انجام تجمیع در این سطح به عهده کد مدل شما است و با استفاده از ساختارهای استاندارد TensorFlow انجام می شود.
ساختار کلی پردازش به شرح زیر است:
- مدل ابتدا tf.Variable s را برای نگهداری مجموعه‌ها می‌سازد، مانند تعداد دسته‌ها یا تعداد نمونه‌های پردازش‌شده، مجموع تلفات هر دسته یا هر مثال و غیره.
- TFF چندین بار متد forward_pass را در Model شما فراخوانی می‌کند، به‌طور متوالی بر روی دسته‌های بعدی داده‌های کلاینت، که به شما امکان می‌دهد متغیرهایی را که مجموعه‌های مختلف را به عنوان یک اثر جانبی در خود نگه می‌دارند، به‌روزرسانی کنید.
- در نهایت، TFF از روش report_local_unfinalized_metrics در مدل شما استفاده می‌کند تا به مدل شما اجازه دهد تمام آمار خلاصه‌ای را که جمع‌آوری کرده در مجموعه فشرده‌ای از معیارها جمع‌آوری کند تا توسط مشتری صادر شود. اینجاست که کد مدل شما ممکن است، به عنوان مثال، مجموع ضررها را بر تعداد نمونه های پردازش شده برای صادرات میانگین ضرر و غیره تقسیم کند.
تجمع فدرال این سطح از تجمیع به تجمع در چندین مشتری (دستگاه) در سیستم اشاره دارد. مجدداً، هم برای پارامترهای مدل (متغیرها) که در بین مشتریان میانگین می‌شوند و هم برای معیارهایی که مدل شما در نتیجه تجمیع محلی صادر می‌کند، اعمال می‌شود.
انجام تجمیع در این سطح بر عهده TFF است. با این حال، به‌عنوان یک خالق مدل، می‌توانید این فرآیند را کنترل کنید (اطلاعات بیشتر در این مورد در زیر).
ساختار کلی پردازش به شرح زیر است:
- مدل اولیه و هر پارامتری که برای آموزش لازم است، توسط یک سرور بین زیرمجموعه ای از مشتریان توزیع می شود که در یک دوره آموزشی یا ارزیابی شرکت خواهند کرد.
- در هر کلاینت، به طور مستقل و موازی، کد مدل شما به طور مکرر بر روی جریانی از دسته‌های داده محلی برای تولید مجموعه جدیدی از پارامترهای مدل (هنگام آموزش) و مجموعه جدیدی از معیارهای محلی، همانطور که در بالا توضیح داده شد، فراخوانی می‌شود (این محلی است). تجمع).
- TFF یک پروتکل تجمیع توزیع شده را برای جمع آوری و تجمیع پارامترهای مدل و معیارهای محلی صادر شده در سراسر سیستم اجرا می کند. این منطق با استفاده از زبان محاسباتی فدرال خود TFF (نه در TensorFlow) به صورت اعلانی بیان می شود. برای اطلاعات بیشتر در مورد API تجمیع، آموزش الگوریتم های سفارشی را ببینید.

رابط های انتزاعی

این رابط سازنده اصلی + ابرداده با رابط tff.learning.models.VariableModel به صورت زیر نمایش داده می شود:

متدهای سازنده، forward_pass و report_local_unfinalized_metrics باید متغیرهای مدل، پاس رو به جلو و آماری را که می‌خواهید گزارش کنید، ایجاد کنند. همانطور که در بالا توضیح داده شد، TensorFlow ساخته شده توسط این روش ها باید قابل سریال سازی باشد.
ویژگی input_spec و همچنین 3 خاصیت که زیرمجموعه‌های متغیرهای آموزش‌پذیر، غیرقابل آموزش و محلی شما را برمی‌گردانند، ابرداده را نشان می‌دهند. TFF از این اطلاعات برای تعیین نحوه اتصال بخش‌هایی از مدل شما به الگوریتم‌های بهینه‌سازی فدرال استفاده می‌کند، و امضاهای نوع داخلی را برای کمک به تأیید صحت سیستم ساخته‌شده تعریف می‌کند (به طوری که مدل شما نمی‌تواند روی داده‌هایی که با آنچه مطابقت ندارند نمونه‌سازی شود. مدل برای مصرف طراحی شده است).

مبدل کراس

def model_fn():
  keras_model = ...
  return tff.learning.models.from_keras_model(keras_model, sample_batch, loss=...)

استفاده از Wrappers Keras در طبقه بندی تصاویر و آموزش های تولید متن نشان داده شده است.

سازندگان محاسبات فدرال

مفروضات معماری

اجرا

دو مرحله مجزا در اجرای یک محاسبات فدرال وجود دارد.

کامپایل : TFF ابتدا الگوریتم های یادگیری فدرال را در یک نمایش سریالی انتزاعی از کل محاسبات توزیع شده گردآوری می کند . این زمانی است که سریال‌سازی TensorFlow اتفاق می‌افتد، اما تغییرات دیگری برای پشتیبانی از اجرای کارآمدتر ممکن است رخ دهد. ما به نمایش سریالی منتشر شده توسط کامپایلر به عنوان یک محاسبات فدرال اشاره می کنیم.
Execute TFF راه هایی را برای اجرای این محاسبات ارائه می دهد. در حال حاضر، اجرا فقط از طریق یک شبیه سازی محلی (مثلاً در یک نوت بوک با استفاده از داده های غیرمتمرکز شبیه سازی شده) پشتیبانی می شود.

یک فرم سریالی از کد مدل شما و همچنین کد TensorFlow اضافی که توسط چارچوب یادگیری فدرال ساخته شده است تا حلقه آموزش/ارزیابی مدل شما را هدایت کند (مانند ساخت بهینه سازها، اعمال به روز رسانی مدل، تکرار روی tf.data.Dataset ، و معیارهای محاسباتی، و اعمال به روز رسانی انبوه بر روی سرور، به نام چند).
مشخصات اعلامی ارتباط بین کلاینت ها و سرور (معمولاً اشکال مختلف تجمیع در دستگاه های کلاینت و پخش از سرور به همه مشتریان) و اینکه چگونه این ارتباط توزیع شده با اجرای کلاینت-محلی یا سرور-محلی درهم می آمیزد. کد TensorFlow

حالت مدل سازی

سازندگان موجود

At the moment, TFF provides various builder functions that generate federated computations for federated training and evaluation. Two notable examples include:

tff.learning.algorithms.build_weighted_fed_avg , which takes as input a model function and a client optimizer , and returns a stateful tff.learning.templates.LearningProcess (which subclasses tff.templates.IterativeProcess ).
tff.learning.build_federated_evaluation takes a model function and returns a single federated computation for federated evaluation of models, since evaluation is not stateful.

Datasets

Architectural assumptions

Client selection

In the typical federated learning scenario, we have a large population of potentially hundreds of millions of client devices, of which only a small portion may be active and available for training at any given moment (for example, this may be limited to clients that are plugged in to a power source, not on a metered network, and otherwise idle). Generally, the set of clients available to participate in training or evaluation is outside of the developer's control. Furthermore, as it's impractical to coordinate millions of clients, a typical round of training or evaluation will include only a fraction of the available clients, which may be sampled at random .

The key consequence of this is that federated computations, by design, are expressed in a manner that is oblivious to the exact set of participants; all processing is expressed as aggregate operations on an abstract group of anonymous clients , and that group might vary from one round of training to another. The actual binding of the computation to the concrete participants, and thus to the concrete data they feed into the computation, is thus modeled outside of the computation itself.

In order to simulate a realistic deployment of your federated learning code, you will generally write a training loop that looks like this:

trainer = tff.learning.algorithms.build_weighted_fed_avg(...)
state = trainer.initialize()
federated_training_data = ...

def sample(federate_data):
  return ...

while True:
  data_for_this_round = sample(federated_training_data)
  result = trainer.next(state, data_for_this_round)
  state = result.state

In order to facilitate this, when using TFF in simulations, federated data is accepted as Python list s, with one element per participating client device to represent that device's local tf.data.Dataset .

Abstract interfaces

In order to standardize dealing with simulated federated data sets, TFF provides an abstract interface tff.simulation.datasets.ClientData , which allows one to enumerate the set of clients, and to construct a tf.data.Dataset that contains the data of a particular client. Those tf.data.Dataset s can be fed directly as input to the generated federated computations in eager mode.

It should be noted that the ability to access client identities is a feature that's only provided by the datasets for use in simulations, where the ability to train on data from specific subsets of clients may be needed (eg, to simulate the diurnal availability of different types of clients). The compiled computations and the underlying runtime do not involve any notion of client identity. Once data from a specific subset of clients has been selected as an input, eg, in a call to tff.templates.IterativeProcess.next , client identities no longer appear in it.

Available data sets

We have dedicated the namespace tff.simulation.datasets for datasets that implement the tff.simulation.datasets.ClientData interface for use in simulations, and seeded it with datasets to support the image classification and text generation tutorials. We'd like to encourage you to contribute your own datasets to the platform.

بررسی اجمالی

This document introduces interfaces that facilitate federated learning tasks, such as federated training or evaluation with existing machine learning models implemented in TensorFlow. In designing these interfaces, our primary goal was to make it possible to experiment with federated learning without requiring the knowledge of how it works under the hood, and to evaluate the implemented federated learning algorithms on a variety of existing models and data. We encourage you to contribute back to the platform. TFF has been designed with extensibility and composability in mind, and we welcome contributions; we are excited to see what you come up with!

The interfaces offered by this layer consist of the following three key parts:

Models . Classes and helper functions that allow you to wrap your existing models for use with TFF. Wrapping a model can be as simple as calling a single wrapping function (eg, tff.learning.models.from_keras_model ), or defining a subclass of the tff.learning.models.VariableModel interface for full customizability.
Federated Computation Builders . Helper functions that construct federated computations for training or evaluation, using your existing models.
Datasets . Canned collections of data that you can download and access in Python for use in simulating federated learning scenarios. Although federated learning is designed for use with decentralized data that cannot be simply downloaded at a centralized location, at the research and development stages it is often convenient to conduct initial experiments using data that can be downloaded and manipulated locally, especially for developers who might be new to the approach.

These interfaces are defined primarily in the tff.learning namespace, except for research data sets and other simulation-related capabilities that have been grouped in tff.simulation . This layer is implemented using lower-level interfaces offered by the Federated Core (FC) , which also provides a runtime environment.

Before proceeding, we recommend that you first review the tutorials on image classification and text generation , as they introduce most of the concepts described here using concrete examples. If you're interested in learning more about how TFF works, you may want to skim over the custom algorithms tutorial as an introduction to the lower-level interfaces we use to express the logic of federated computations, and to study the existing implementation of the tff.learning interfaces.

Models

Architectural assumptions

Serialization

TFF aims at supporting a variety of distributed learning scenarios in which the machine learning model code you write might be executing on a large number of heterogeneous clients with diverse capabilities. While at one end of the spectrum, in some applications those clients might be powerful database servers, many important uses our platform intends to support involve mobile and embedded devices with limited resources. We cannot assume that these devices are capable of hosting Python runtimes; the only thing we can assume at this point is that they are capable of hosting a local TensorFlow runtime. Thus, a fundamental architectural assumption we make in TFF is that your model code must be serializable as a TensorFlow graph.

You can (and should) still develop your TF code following the latest best practices like using eager mode. However, the final code must be serializable (eg, can be wrapped as a tf.function for eager-mode code). This ensures that any Python state or control flow necessary at execution time can be serialized (possibly with the help of Autograph ).

Currently, TensorFlow does not fully support serializing and deserializing eager-mode TensorFlow. Thus, serialization in TFF currently follows the TF 1.0 pattern, where all code must be constructed inside a tf.Graph that TFF controls. This means currently TFF cannot consume an already-constructed model; instead, the model definition logic is packaged in a no-arg function that returns a tff.learning.models.VariableModel . This function is then called by TFF to ensure all components of the model are serialized. In addition, being a strongly-typed environment, TFF will require a little bit of additional metadata , such as a specification of your model's input type.

Aggregation

We strongly recommend most users construct models using Keras, see the Converters for Keras section below. These wrappers handle the aggregation of model updates as well as any metrics defined for the model automatically. However, it may still be useful to understand how aggregation is handled for a general tff.learning.models.VariableModel .

There are always at least two layers of aggregation in federated learning: local on-device aggregation, and cross-device (or federated) aggregation:

Local aggregation . This level of aggregation refers to aggregation across multiple batches of examples owned by an individual client. It applies to both the model parameters (variables), which continue to sequentially evolve as the model is locally trained, as well as the statistics you compute (such as average loss, accuracy, and other metrics), which your model will again update locally as it iterates over each individual client's local data stream.
Performing aggregation at this level is the responsibility of your model code, and is accomplished using standard TensorFlow constructs.
The general structure of processing is as follows:
- The model first constructs tf.Variable s to hold aggregates, such as the number of batches or the number of examples processed, the sum of per-batch or per-example losses, etc.
- TFF invokes the forward_pass method on your Model multiple times, sequentially over subsequent batches of client data, which allows you to update the variables holding various aggregates as a side effect.
- Finally, TFF invokes the report_local_unfinalized_metrics method on your Model to allow your model to compile all the summary statistics it collected into a compact set of metrics to be exported by the client. This is where your model code may, for example, divide the sum of losses by the number of examples processed to export the average loss, etc.
Federated aggregation . This level of aggregation refers to aggregation across multiple clients (devices) in the system. Again, it applies to both the model parameters (variables), which are being averaged across clients, as well as the metrics your model exported as a result of local aggregation.
Performing aggregation at this level is the responsibility of TFF. As a model creator, however, you can control this process (more on this below).
The general structure of processing is as follows:
- The initial model, and any parameters required for training, are distributed by a server to a subset of clients that will participate in a round of training or evaluation.
- On each client, independently and in parallel, your model code is invoked repeatedly on a stream of local data batches to produce a new set of model parameters (when training), and a new set of local metrics, as described above (this is local aggregation).
- TFF runs a distributed aggregation protocol to accumulate and aggregate the model parameters and locally exported metrics across the system. This logic is expressed in a declarative manner using TFF's own federated computation language (not in TensorFlow). See the custom algorithms tutorial for more on the aggregation API.

Abstract interfaces

This basic constructor + metadata interface is represented by the interface tff.learning.models.VariableModel , as follows:

The constructor, forward_pass , and report_local_unfinalized_metrics methods should construct model variables, forward pass, and statistics you wish to report, correspondingly. The TensorFlow constructed by those methods must be serializable, as discussed above.
The input_spec property, as well as the 3 properties that return subsets of your trainable, non-trainable, and local variables represent the metadata. TFF uses this information to determine how to connect parts of your model to the federated optimization algorithms, and to define internal type signatures to assist in verifying the correctness of the constructed system (so that your model cannot be instantiated over data that does not match what the model is designed to consume).

In addition, the abstract interface tff.learning.models.VariableModel exposes a property metric_finalizers that takes in a metric's unfinalized values (returned by report_local_unfinalized_metrics() ) and returns the finalized metric values. The metric_finalizers and report_local_unfinalized_metrics() method will be used together to build a cross-client metrics aggregator when defining the federated training processes or evaluation computations. For example, a simple tff.learning.metrics.sum_then_finalize aggregator will first sum the unfinalized metric values from clients, and then call the finalizer functions at the server.

You can find examples of how to define your own custom tff.learning.models.VariableModel in the second part of our image classification tutorial, as well as in the example models we use for testing in model_examples.py .

Converters for Keras

Nearly all the information that's required by TFF can be derived by calling tf.keras interfaces, so if you have a Keras model, you can rely on tff.learning.models.from_keras_model to construct a tff.learning.models.VariableModel .

Note that TFF still wants you to provide a constructor - a no-argument model function such as the following:

def model_fn():
  keras_model = ...
  return tff.learning.models.from_keras_model(keras_model, sample_batch, loss=...)

In addition to the model itself, you supply a sample batch of data which TFF uses to determine the type and shape of your model's input. This ensures that TFF can properly instantiate the model for the data that will actually be present on client devices (since we assume this data is not generally available at the time you are constructing the TensorFlow to be serialized).

The use of Keras wrappers is illustrated in our image classification and text generation tutorials.

Federated Computation Builders

The tff.learning package provides several builders for tff.Computation s that perform learning-related tasks; we expect the set of such computations to expand in the future.

Architectural assumptions

Execution

There are two distinct phases in running a federated computation.

Compile : TFF first compiles federated learning algorithms into an abstract serialized representation of the entire distributed computation. This is when TensorFlow serialization happens, but other transformations can occur to support more efficient execution. We refer to the serialized representation emitted by the compiler as a federated computation .
Execute TFF provides ways to execute these computations. For now, execution is only supported via a local simulation (eg, in a notebook using simulated decentralized data).

A federated computation generated by TFF's Federated Learning API, such as a training algorithm that uses federated model averaging , or a federated evaluation, includes a number of elements, most notably:

A serialized form of your model code as well as additional TensorFlow code constructed by the Federated Learning framework to drive your model's training/evaluation loop (such as constructing optimizers, applying model updates, iterating over tf.data.Dataset s, and computing metrics, and applying the aggregated update on the server, to name a few).
A declarative specification of the communication between the clients and a server (typically various forms of aggregation across the client devices, and broadcasting from the server to all clients), and how this distributed communication is interleaved with the client-local or server-local execution of TensorFlow code.

The federated computations represented in this serialized form are expressed in a platform-independent internal language distinct from Python, but to use the Federated Learning API, you won't need to concern yourself with the details of this representation. The computations are represented in your Python code as objects of type tff.Computation , which for the most part you can treat as opaque Python callable s.

In the tutorials, you will invoke those federated computations as if they were regular Python functions, to be executed locally. However, TFF is designed to express federated computations in a manner agnostic to most aspects of the execution environment, so that they can potentially be deployable to, eg, groups of devices running Android , or to clusters in a datacenter. Again, the main consequence of this are strong assumptions about serialization . In particular, when you invoke one of the build_... methods described below the computation is fully serialized.

Modeling state

TFF is a functional programming environment, yet many processes of interest in federated learning are stateful. For example, a training loop that involves multiple rounds of federated model averaging is an example of what we could classify as a stateful process . In this process, the state that evolves from round to round includes the set of model parameters that are being trained, and possibly additional state associated with the optimizer (eg, a momentum vector).

Since TFF is functional, stateful processes are modeled in TFF as computations that accept the current state as an input and then provide the updated state as an output. In order to fully define a stateful process, one also needs to specify where the initial state comes from (otherwise we cannot bootstrap the process). This is captured in the definition of the helper class tff.templates.IterativeProcess , with the 2 properties initialize and next corresponding to the initialization and iteration, respectively.

Available builders

At the moment, TFF provides various builder functions that generate federated computations for federated training and evaluation. Two notable examples include:

tff.learning.algorithms.build_weighted_fed_avg , which takes as input a model function and a client optimizer , and returns a stateful tff.learning.templates.LearningProcess (which subclasses tff.templates.IterativeProcess ).
tff.learning.build_federated_evaluation takes a model function and returns a single federated computation for federated evaluation of models, since evaluation is not stateful.

Datasets

Architectural assumptions

Client selection

In order to simulate a realistic deployment of your federated learning code, you will generally write a training loop that looks like this:

trainer = tff.learning.algorithms.build_weighted_fed_avg(...)
state = trainer.initialize()
federated_training_data = ...

def sample(federate_data):
  return ...

while True:
  data_for_this_round = sample(federated_training_data)
  result = trainer.next(state, data_for_this_round)
  state = result.state

Abstract interfaces

Available data sets

بررسی اجمالی

The interfaces offered by this layer consist of the following three key parts:

Models . Classes and helper functions that allow you to wrap your existing models for use with TFF. Wrapping a model can be as simple as calling a single wrapping function (eg, tff.learning.models.from_keras_model ), or defining a subclass of the tff.learning.models.VariableModel interface for full customizability.
Federated Computation Builders . Helper functions that construct federated computations for training or evaluation, using your existing models.
Datasets . Canned collections of data that you can download and access in Python for use in simulating federated learning scenarios. Although federated learning is designed for use with decentralized data that cannot be simply downloaded at a centralized location, at the research and development stages it is often convenient to conduct initial experiments using data that can be downloaded and manipulated locally, especially for developers who might be new to the approach.

Models

Architectural assumptions

Serialization

Aggregation

There are always at least two layers of aggregation in federated learning: local on-device aggregation, and cross-device (or federated) aggregation:

Local aggregation . This level of aggregation refers to aggregation across multiple batches of examples owned by an individual client. It applies to both the model parameters (variables), which continue to sequentially evolve as the model is locally trained, as well as the statistics you compute (such as average loss, accuracy, and other metrics), which your model will again update locally as it iterates over each individual client's local data stream.
Performing aggregation at this level is the responsibility of your model code, and is accomplished using standard TensorFlow constructs.
The general structure of processing is as follows:
- The model first constructs tf.Variable s to hold aggregates, such as the number of batches or the number of examples processed, the sum of per-batch or per-example losses, etc.
- TFF invokes the forward_pass method on your Model multiple times, sequentially over subsequent batches of client data, which allows you to update the variables holding various aggregates as a side effect.
- Finally, TFF invokes the report_local_unfinalized_metrics method on your Model to allow your model to compile all the summary statistics it collected into a compact set of metrics to be exported by the client. This is where your model code may, for example, divide the sum of losses by the number of examples processed to export the average loss, etc.
Federated aggregation . This level of aggregation refers to aggregation across multiple clients (devices) in the system. Again, it applies to both the model parameters (variables), which are being averaged across clients, as well as the metrics your model exported as a result of local aggregation.
Performing aggregation at this level is the responsibility of TFF. As a model creator, however, you can control this process (more on this below).
The general structure of processing is as follows:
- The initial model, and any parameters required for training, are distributed by a server to a subset of clients that will participate in a round of training or evaluation.
- On each client, independently and in parallel, your model code is invoked repeatedly on a stream of local data batches to produce a new set of model parameters (when training), and a new set of local metrics, as described above (this is local aggregation).
- TFF runs a distributed aggregation protocol to accumulate and aggregate the model parameters and locally exported metrics across the system. This logic is expressed in a declarative manner using TFF's own federated computation language (not in TensorFlow). See the custom algorithms tutorial for more on the aggregation API.

Abstract interfaces

This basic constructor + metadata interface is represented by the interface tff.learning.models.VariableModel , as follows:

The constructor, forward_pass , and report_local_unfinalized_metrics methods should construct model variables, forward pass, and statistics you wish to report, correspondingly. The TensorFlow constructed by those methods must be serializable, as discussed above.
The input_spec property, as well as the 3 properties that return subsets of your trainable, non-trainable, and local variables represent the metadata. TFF uses this information to determine how to connect parts of your model to the federated optimization algorithms, and to define internal type signatures to assist in verifying the correctness of the constructed system (so that your model cannot be instantiated over data that does not match what the model is designed to consume).

Converters for Keras

Note that TFF still wants you to provide a constructor - a no-argument model function such as the following:

def model_fn():
  keras_model = ...
  return tff.learning.models.from_keras_model(keras_model, sample_batch, loss=...)

The use of Keras wrappers is illustrated in our image classification and text generation tutorials.

Federated Computation Builders

The tff.learning package provides several builders for tff.Computation s that perform learning-related tasks; we expect the set of such computations to expand in the future.

Architectural assumptions

Execution

There are two distinct phases in running a federated computation.

Compile : TFF first compiles federated learning algorithms into an abstract serialized representation of the entire distributed computation. This is when TensorFlow serialization happens, but other transformations can occur to support more efficient execution. We refer to the serialized representation emitted by the compiler as a federated computation .
Execute TFF provides ways to execute these computations. For now, execution is only supported via a local simulation (eg, in a notebook using simulated decentralized data).

A serialized form of your model code as well as additional TensorFlow code constructed by the Federated Learning framework to drive your model's training/evaluation loop (such as constructing optimizers, applying model updates, iterating over tf.data.Dataset s, and computing metrics, and applying the aggregated update on the server, to name a few).
A declarative specification of the communication between the clients and a server (typically various forms of aggregation across the client devices, and broadcasting from the server to all clients), and how this distributed communication is interleaved with the client-local or server-local execution of TensorFlow code.

Modeling state

Available builders

At the moment, TFF provides various builder functions that generate federated computations for federated training and evaluation. Two notable examples include:

tff.learning.algorithms.build_weighted_fed_avg , which takes as input a model function and a client optimizer , and returns a stateful tff.learning.templates.LearningProcess (which subclasses tff.templates.IterativeProcess ).
tff.learning.build_federated_evaluation takes a model function and returns a single federated computation for federated evaluation of models, since evaluation is not stateful.

Datasets

Architectural assumptions

Client selection

In order to simulate a realistic deployment of your federated learning code, you will generally write a training loop that looks like this:

trainer = tff.learning.algorithms.build_weighted_fed_avg(...)
state = trainer.initialize()
federated_training_data = ...

def sample(federate_data):
  return ...

while True:
  data_for_this_round = sample(federated_training_data)
  result = trainer.next(state, data_for_this_round)
  state = result.state