Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Support for workloads with response time requirements (realtime)

Đang mở
  • Có gì không ổn?
#898 4 bình luận 3 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
8/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Lĩnh vực
audio-video-rtc, performance

Hướng nghiên cứu

This is a spec-level design discussion in the Bikeshed source of the WebNN specification, not a code task. It proposes workload priority or periodicity hints on the WebNN context or graph execution path, and asks whether the change needs spec text or only an API addition. Reading the issue thread and the existing scheduling-related spec sections is the first step; done would mean a maintainer-agreed design direction, which needs spec-level expertise.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Consider an RTC-style web app concurrently running a collection of ML workloads of various response requirements. Assume that there aren't capacity issues (the system as a whole has enough HP to execute the workload on average).

Workload Period/response requirement Job completion delay
Audio capture processing (denoising etc) 50 Hz 25%
Video capture processing (eg background blur) 30 Hz 10-30%
WebSpeech 500ms? (continuous)
LLM Bursty Bursty

Without proper WebNN consideration of these requirements there are concerns that the UA will make poor scheduling decisions, causing the system to miss deadlines. The effects:

  • robo-sound
  • audio glitches
  • dropped video frames
  • janky video
  • increased end-to-end delay (since receiver jitterbuffers need to bump target delay to account for the problems).

The ideal state is that the system manages to understand the requirements. With the right scheduling decisions, LLM queries will be belated a little and possibly the latency of WebSpeech will go up, but as a whole it manages to meet the expectations in a good way.

Assuming the backend frameworks are capable of supporting workload prioritization, I see some options to help this case

  1. Equip the WebNN API with hints on the workload passed.
  2. Auto-detect the type of processing. For example, when audio or video capture wakes a worker it could transport a token containing periodicity info and let that influence scheduling decisions in the WebNN backend.

My guess is both need spec updates? Or maybe just the first option?

See also crbug.com/456006123 for repros of related issues with other tech than WebNN. Also note this issue is not asking for ways to understand total system capacity as this is impossible to compute without trying workloads out.

Ngôn ngữ chính
Bikeshed
Star
566
Fork
72
Merge trung bình
6 ngày 5 giờ
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của webmachinelearning/webnn

Tất cả issue của webmachinelearning/webnn

Issue tương tự

Thêm issue về Audio/Video & RTC

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.