یادداشت های نشست 2022/8/24 همکاران TFF

  • پشتیبانی از تانسور پراکنده در TFF:
    • EW - ما مدل‌های Keras را داریم که می‌خواهیم به TFF پورت کنیم، آنها تانسورهای پراکنده دارند
      • صرف نگاشت به تانسورهای متراکم منجر به هزینه غیرقابل قبول حافظه و کندی در مورد استفاده ما می شود، بنابراین ما به دنبال جلوگیری از آن هستیم.
    • ZG در پشتیبانی تانسور پراکنده موجود در TFF
      • مسائل ذکر شده در GitHub بیشتر مربوط به tf.data.Dataset است
      • اکثراً غیر از این کار می کند، اما به مقداری DIY نیاز دارد، به ویژه جمع آوری های wrt که در آن ما نمی توانیم ساده لوحانه یک مجموع پراکنده بر روی سه تانسور سازنده انجام دهیم، که نتیجه مطلوب را نداشته باشد.
    • (سوالی در مورد اهمیت نسبی)
    • EW - این برای ما مسدود کننده نیست، بلکه یک بهینه سازی ردپای عملکرد/منابع خوب است
    • ZG - با توجه به مشکلات GitHub، ممکن است با پنهان کردن مجموعه داده در محاسبات TFF کار کند، بنابراین بخشی از مرز ورودی-خروجی نیست.
    • KO - توضیح اینکه کامنت «بیشتر کار می‌کند» ما به روش رایج نمایش/استفاده از تانسورهای پراکنده به عنوان چند تانسور متراکم اشاره دارد. آیا سعی کرده‌اید برای استفاده از مجموعه داده‌ها نیز با چند تانسور متراکم پراکنده برخورد کنید؟
      • EW - هنوز امتحان نکرده‌ام
    • KO - پراکنده در این مکالمه در دو مکان بالا آمده است - برای پارامترهای مدل، بلکه برای داده های ورودی پراکنده - آیا هر دو به یک اندازه مهم هستند؟
      • EW - به طور ایده آل هر دو را داشته باشد
    • KO - یک آیتم اکشن برای Ewan که سعی کند با چند تانسور متراکم کار کند که نمایانگر اجزای سازنده است.
    • KO - این هنوز یک سوال در مورد APIها/راهنماهای بهتر برای مدیریت تانسور پراکنده باقی می‌گذارد، اما می‌تواند این مورد خاص را رفع انسداد کند. درباره API فکر می کنید؟
    • EW - در حالت ایده آل می تواند شفاف باشد (نیازی به انجام کار خاصی برای پراکندگی توسط مشتری با استفاده از TFF نیست و فقط کار می کند)
      • KO، ZG - در برخی موارد، واضح نیست، به عنوان مثال، برای تجمیع - به طور بالقوه بیش از یک راه برای جمع کردن اجزای تشکیل دهنده تانسورهای پراکنده وجود دارد، انتخابی که در حالت ایده آل باید توسط مشتری انجام شود.
      • KR - احتمالا داشتن یک خانواده کوچک از نمادهای اختصاصی "مجموع پراکنده" بسیار قابل اجرا است
      • KO - شاید بتوانیم با نمونه سازی نسخه اولیه از مجموع پراکنده مورد نیاز EW و بالادست آن به TFF به عنوان یک اپراتور مجموع پراکنده عمومی برای بذر این و ساخت بر روی آن (برای پیگیری این نسخه آفلاین - شاید در صورت اختلاف) شروع کنیم.
      • EW +1
  • پیشنهاد جرمی، ادامه از 2 هفته پیش:
    • نکته فنی TFF: اتصالات آغاز شده توسط مشتری
    • (برای همه باید بعداً آن را مرور کنند زیرا کمی قبل از جلسه به اشتراک گذاشته شد)
    • (جرمی در حال ارائه است)
    • JL - پیشنهاد انتزاع «تظیف‌فروشی» برای تبادل درخواست‌ها بین «ابر» و مجری‌های هر مشتری (مثلاً در مرورگرها)، که دومی وظایف را از یک «فروشگاه وظیفه» متمرکز می‌کشد. آیا چنین چیزی در زمینه دیگری در نظر گرفته شده است؟
    • KR - بله، در سناریوهای رسیدگی به شکست
      • با این حال، مشکلات مویی بیشتر - انتقال حالت بین مجریان دشوار است، مطمئن نیستم چقدر به سناریوی ارائه شده توسط جرمی منتقل می شود.
    • HV - آیا مجریان در برگ می توانند بدون تابعیت باشند
      • JL - این آن را بیشتر شبیه کاغذ SysML روی دستگاه متقابل می کند
    • (سوال در مورد عملکرد در این سناریو، در مقایسه با جریان دو جهته به نحوی که بیشتر شبیه پروتکل اصلی TFF باشد)
    • JL - قبول کنید که ملاحظات تاخیر وجود دارد
    • جریان دو جهته در برخی از حمل و نقل ها پشتیبانی نمی شود، بنابراین همیشه گزینه مناسبی نیست
    • (وقت تمام شد)
    • (ادامه در 2 هفته - اولین نکته دستور جلسه بعدی، جرمی ملحق خواهد شد)