Ghi chú từ cuộc họp 24/8/2022 của các cộng tác viên TFF

  • Hỗ trợ căng thẳng thưa thớt trong TFF:
    • EW - Chúng tôi có các mô hình Keras mà chúng tôi muốn chuyển sang TFF, chúng có bộ căng thưa
      • Chỉ cần ánh xạ tới các tensors dày đặc dẫn đến chi phí bộ nhớ không thể chấp nhận được và độ chậm trong trường hợp sử dụng của chúng tôi, vì vậy chúng tôi đang tìm cách tránh điều đó
    • ZG về hỗ trợ tensor thưa thớt hiện có trong TFF
      • Các vấn đề được đề cập trên GitHub chủ yếu liên quan đến tf.data.Dataset
      • Phần lớn hoạt động theo cách khác, nhưng nó yêu cầu một số tổng hợp DIY, đặc biệt là wrt, trong đó chúng ta không thể chỉ thực hiện một cách ngây thơ một tổng thưa thớt trên bộ ba của tensors cấu thành, điều đó sẽ không có kết quả mong muốn
    • (câu hỏi về tầm quan trọng tương đối)
    • EW - điều này không gây cản trở cho chúng tôi, mà là một hiệu suất tốt / tối ưu hóa hiệu suất tạo lại dấu chân
    • ZG - liên quan đến các vấn đề GitHub, có thể giải quyết bằng cách ẩn tập dữ liệu bên trong tính toán TFF, vì vậy nó không phải là một phần của ranh giới đầu vào-đầu ra
    • KO - làm rõ rằng nhận xét "nó chủ yếu hoạt động" của chúng tôi đề cập đến thực tiễn phổ biến của việc biểu diễn / xử lý các tenxơ thưa thớt dưới dạng các bộ tenxơ dày đặc. Bạn đã thử xử lý các bộ căng thẳng thưa thớt như thế nào cho việc sử dụng bộ dữ liệu chưa?
      • EW - chưa thử
    • KO - thưa thớt trong cuộc trò chuyện này đã đưa ra hai vị trí - đối với các tham số mô hình, nhưng cũng đối với dữ liệu đầu vào thưa thớt - cả hai đều quan trọng như nhau?
      • EW - lý tưởng sẽ có cả hai
    • KO - một mục hành động để Ewan cố gắng làm việc với các bộ căng dây dày đặc đại diện cho các bộ phận cấu thành.
    • KO - điều này vẫn để lại câu hỏi về các API / trình trợ giúp tốt hơn để xử lý tensor thưa thớt, nhưng có thể bỏ chặn trường hợp sử dụng cụ thể này. Suy nghĩ về API?
    • EW - lý tưởng là điều này có thể minh bạch (không cần phải làm bất cứ điều gì đặc biệt đối với khách hàng thưa thớt sử dụng TFF và nó chỉ hoạt động)
      • KO, ZG - trong một số trường hợp, nó không rõ ràng, ví dụ, để tổng hợp - có nhiều khả năng có nhiều cách để tổng hợp các phần cấu thành của các tensors thưa thớt, một lựa chọn lý tưởng là do khách hàng thực hiện
      • KR - có lẽ có một nhóm nhỏ các ký hiệu “tổng thưa thớt” dành riêng là hành động hữu ích nhất
      • KO - có lẽ chúng ta có thể bắt đầu bằng cách tạo mẫu phiên bản của tổng thưa mà EW cần và ngược dòng nó lên TFF dưới dạng một toán tử tổng thưa chung để gieo hạt này và xây dựng trên đó (để theo dõi điều này ngoại tuyến - có thể là bất hòa)
      • EW +1
  • Đề xuất của Jeremy, tiếp tục từ 2 tuần trước:
    • Ghi chú kỹ thuật của TFF: Các kết nối do khách hàng khởi tạo
    • (việc cần làm để tất cả xem lại sau vì nó vừa được chia sẻ không lâu trước cuộc họp)
    • (Jeremy đang trình bày)
    • JL - đề xuất tính trừu tượng của “kho tác vụ” để trao đổi các yêu cầu giữa “Đám mây” và những người thực thi trên mỗi khách hàng (ví dụ: trong các trình duyệt), với các tác vụ sau này kéo các tác vụ từ một “kho tác vụ” tập trung. Một cái gì đó như thế này đã được xem xét trong bất kỳ bối cảnh nào khác?
    • KR - có, trong các tình huống xử lý lỗi
      • Tuy nhiên, nhiều vấn đề rắc rối hơn - việc chuyển giao trạng thái giữa những người thực thi là khó khăn, không chắc chắn bao nhiêu phần trăm chuyển sang kịch bản do Jeremy trình bày
    • HV - những người thi hành công vụ trong lá có thể là không quốc tịch
      • JL - điều này sẽ làm cho nó giống như giấy SysML trên nhiều thiết bị
    • (câu hỏi về hiệu suất trong trường hợp này, so với phát trực tuyến hai chiều theo cách gần giống với giao thức TFF gốc hơn)
    • JL - hiểu rằng có những cân nhắc về độ trễ
    • phát trực tuyến hai chiều không được hỗ trợ trong một số phương tiện vận chuyển, vì vậy không phải lúc nào cũng là một lựa chọn khả thi
    • (hết thời gian)
    • (sẽ tiếp tục sau 2 tuần - điểm đầu tiên của chương trình làm việc cho cuộc họp tiếp theo, Jeremy sẽ tham gia)