Traducción pendiente: esta página conserva la fuente canónica en inglés mientras la navegación sigue disponible en español.

WebNN and Adaptive Backends

Introduction and mental model

WebNN is a declarative Web API for constructing and executing machine-learning graphs. Application code obtains an MLContext, builds a graph with MLGraphBuilder, supplies or creates MLTensor resources, dispatches work, and reads or shares results according to the capabilities and usages available in that context. It is a graph API, not a model-file format: a runtime must still translate formats such as ONNX or LiteRT into supported WebNN operations if it offers a WebNN execution path.

The browser and underlying implementation may map work to CPU, GPU, or NPU resources, influenced by standardized context options where supported. A device preference is not a proof of physical placement or performance. Operator support, tensor data types, shapes, limits, resource interoperability, browser version, operating system, driver, and runtime integration all affect the result.

As of the consultation date for this index, WebNN is a W3C Candidate Recommendation Draft rather than a completed Recommendation. Implementations and integrations are experimental or uneven. An adaptive application therefore needs an explicit policy, runtime capability probes, correctness qualification, forced-backend tests where possible, and a visible decision trace. The illustrative preference WebNN -> WebGPU -> Wasm SIMD -> scalar is a policy to evaluate for a workload, not a universal performance hierarchy.

Why it matters

WebNN can let a browser use platform ML facilities without requiring application authors to write every accelerator kernel. At the same time, a deployment that assumes WebNN availability or silently changes devices is difficult to debug, benchmark, and trust. Capability-driven selection keeps the application functional while preserving evidence about what actually ran.

The adaptive-backend problem also connects WebNN with WebGPU and Wasm. These layers expose different abstractions and portability boundaries: WebNN declares ML graphs, WebGPU exposes programmable GPU compute, Wasm provides portable CPU execution, and WASI-NN targets host-provided inference outside the browser. Choosing among them requires workload-specific evidence rather than API-name comparisons.

Questions this branch answers

How do navigator.ml, MLContext, MLGraphBuilder, MLGraph, and MLTensor relate?
Which operator, data-type, shape, and tensor-usage capabilities must be checked before building a graph?
What do power and device preferences request, and what do they not guarantee?
How are constants, input tensors, output tensors, graph dispatch, reads, writes, and destruction represented?
When can WebNN interoperate with other buffers or runtime-managed tensors, and when is a copy required?
How do ONNX Runtime Web and LiteRT.js expose changing WebNN integrations?
How should an application distinguish unavailable API, unsupported graph, failed compilation, failed dispatch, and lost context?
How can fallback order remain visible, testable, and reversible rather than becoming silent behavior?
What is a fair comparison among WebNN, WebGPU, Wasm SIMD, scalar Wasm, and WASI-NN?

Scope

WebNN API discovery, context creation, graph building, operands, operations, graph compilation, dispatch, and errors.
MLTensor creation, usage, reads, writes, lifetime, and interoperability only where the implementation exposes the required capability.
CPU, GPU, and NPU preferences as requests whose effective behavior must be observed and measured.
Operator, type, shape, and limit discovery; graph support checks; implementation reports and conformance evidence.
WebNN execution paths in browser inference runtimes, including their own support matrices and fallbacks.
Explicit adaptive policies across WebNN, WebGPU, Wasm SIMD, and scalar execution.
Decision traces, reason codes, forced-backend verification, output parity, and performance measurement.
Architectural comparison with WebGPU and WASI-NN without treating them as interchangeable APIs.

Out of scope

Claiming WebNN is universally available, stable across implementations, or mapped to a particular accelerator.
Assuming a preferred device or successful dispatch proves that every operation ran where expected.
Implementing a production backend selector, runtime adapter, or user interface in this index.
Defining WebGPU shaders, Wasm kernels, or server-side WASI-NN host integrations in depth.
Ranking backends without naming model, operator set, precision, browser, system, device, and measurement boundary.

Expected outcomes

After completing this branch, a reader should be able to construct a WebNN capability checklist, explain the lifecycle of a small graph and its tensors, and distinguish standardized API semantics from implementation-specific coverage. They should also be able to design an adaptive policy that qualifies outputs, records every selection and fallback reason, allows a backend to be forced for testing, and compares WebNN with WebGPU and Wasm on a scoped workload.

Candidate note roadmap

WebNN is a graph API, not a model loader — place contexts, graph builders, operands, graphs, tensors, and runtime format adapters in the correct layers.
From MLContext preferences to a minimal dispatched graph — inspect context, power and device preferences without treating them as promises, then trace failure modes, effective-execution evidence, named inputs, constants, operations, outputs, compilation, tensors, dispatch, reads, and destruction.
Operator and data-type support is a runtime capability — query or test limits, preserve a graph inventory, and fail with an actionable unsupported-subgraph report.
MLTensor lifetime and buffer interoperability — reason about usages, reads, writes, imports or exports where supported, synchronization, copies, and ownership.
WebNN through runtimes: ONNX Runtime Web and LiteRT.js — distinguish the standardized API from provider integrations, tracking pinned releases, graph partitioning, supported operations, version-specific experimental status, CPU fallback, diagnostics, and the difference between roadmap and observed capability.
An adaptive backend is a policy engine with evidence — define probes, qualification tests, priorities, exclusions, reason codes, overrides, and a persistent decision trace.
WebNN, WebGPU, Wasm, and WASI-NN expose different contracts — compare declarative graphs, programmable GPU kernels, portable CPU modules, and host-supplied inference.
Benchmark requested, selected, and forced backends separately — validate outputs first, isolate setup and transfers, and report unavailable or unsupported paths as results.

Future runnable artifact

Build an adaptive backend lab around one small fixed multilayer tensor workload whose weights, input tensors, operation order, and numerical acceptance criteria are shared across four implementations: WebNN, WebGPU, Wasm SIMD, and scalar Wasm. The selector will evaluate the illustrative policy WebNN -> WebGPU -> Wasm SIMD -> scalar, but only after capability checks and a short output-qualification fixture. The ordering will be configurable because it is not assumed to be optimal on every system.

Every run will display and serialize the API availability, requested backend, capability results, graph or kernel qualification result, selected backend, rejected candidates with reason codes, whether fallback occurred, and output comparison. A test mode will force each backend or require an exact backend and fail rather than fall back. Measurements will separate context or device setup, graph or pipeline construction, upload, warmup, dispatch, readback, and steady-state reuse. The artifact will include scenarios for absent WebNN, an unsupported WebNN operation, WebGPU device loss, unavailable SIMD, and a correctness rejection, proving that no transition is silent.

How to verify and measure

Record browser build, operating system, exposed adapter/context information, runtime package, model or workload hash, and test date.
Feature-detect WebNN and WebGPU and query standardized limits or support information; never infer capability from the user agent alone.
Inventory operations, data types, shapes, tensor usages, and required limits before graph construction.
Run a deterministic qualification fixture against a scalar or Python reference before admitting a backend to the selector.
Force each backend independently and verify that exact-backend mode fails on fallback or unsupported work.
Serialize the complete decision trace with stable reason codes and show it in the artifact output.
Compare outputs with declared absolute, relative, and task-level tolerances before publishing timing results.
Separate setup, compilation, transfer, dispatch, readback, warm reuse, and disposal; report distributions rather than a single sample.
Test API absence, context or device creation failure, unsupported operation, dispatch failure, device loss, and cleanup.
Re-run the support matrix when a browser, operating system, runtime, or driver changes; status is not timeless.

Primary sources

WebNN specification — https://www.w3.org/TR/webnn/ — W3C Candidate Recommendation Draft dated 2026-06-26, consulted 2026-07-16. It is explicitly work in progress and must not be presented as a completed Recommendation.
WebNN standards history — https://www.w3.org/standards/history/webnn/ — Primary publication history; consulted 2026-07-16 for document status and dates.
WebNN implementation report — https://wpt.fyi/results/webnn?label=master&label=experimental&aligned&q=webnn — Experimental-channel conformance evidence; changing continuously and consulted 2026-07-16. Passing tests do not by themselves establish universal device or operator coverage.
ONNX Runtime Web build documentation — https://onnxruntime.ai/docs/build/web.html — As consulted 2026-07-16, it labels WebGPU and WebNN support as experimental and notes that instructions may change.
ONNX Runtime Web documentation — https://onnxruntime.ai/docs/tutorials/web/ — Current execution-provider and browser runtime guidance; version-sensitive and consulted 2026-07-16.
LiteRT.js for Web — https://developers.google.com/edge/litert/web — Rapidly changing documentation for a runtime first publicly announced on 2026-07-09; consulted 2026-07-16. Its WebNN integration is emerging/experimental, so release-specific capability and fallback must be tested.
WebGPU specification — https://www.w3.org/TR/webgpu/ — W3C Candidate Recommendation Draft dated 2026-06-23, consulted 2026-07-16; capabilities and limits remain implementation-dependent.
WASI-NN specification repository — https://github.com/WebAssembly/wasi-nn — Primary specification work for the non-browser host inference interface; evolving and consulted 2026-07-16.

Connects to: Browser Inference Runtimes · WebGPU for AI · WASI, Components, and WASI-NN · Local-First, Offline, Multimodal AI · Wasm AI Performance, Security, and Craftsmanship