Registro de referencias de WebAssembly AI
Este registro evita que los hechos volátiles y la evidencia reutilizable dependan solo de la memoria de la prosa. No reemplaza las fuentes de cada nota; registra a qué especificación, implementación, artefacto y entorno se refiere realmente una afirmación.
Esquema de una entrada del registro
| Campo | Significado requerido |
|---|---|
| Identificador | Nombre local estable para la fuente o el artefacto |
| Tipo | Especificación, propuesta, implementación, modelo, dataset, toolchain o benchmark |
| Versión / revisión | Release, commit, hash de modelo o snapshot fechado de una living spec |
| Estado | Estable, candidato, borrador, fase de propuesta, experimental, deprecado o específico de implementación |
| Consultado | Fecha en que se verificó la afirmación o información de compatibilidad |
| Entorno | Browser, runtime, sistema operativo, hardware y capacidades habilitadas cuando corresponda |
| Evidencia | URL exacta, checksum, comando, resultado crudo o ruta del reporte |
| Disparador de revisión | Release, actualización del browser, actualización del runtime, cambio de modelo o reproducción fallida |
Vocabulario de estados
- Estandarizado significa que el proceso de estandarización correspondiente alcanzó ese estado; no implica implementación universal.
- API de implementación estable es una afirmación del proveedor/runtime limitada a una release nombrada.
- Borrador o propuesta significa que el diseño y el comportamiento todavía pueden cambiar.
- Experimental significa que el uso en producción exige un plan explícito de riesgo y fallback.
- Soporte observado significa que una prueba fechada pasó en un entorno declarado, no que todos los entornos lo soporten.
- No disponible es un resultado válido de la matriz y no debe reescribirse como una falla genérica.
Referencias primarias iniciales
| Área | Referencia primaria | Regla de seguimiento |
|---|---|---|
| Wasm core | Especificación core de WebAssembly | Registrar edición o fecha de consulta |
| API del host del browser | Interfaz JavaScript de WebAssembly | Seguir diferencias de implementación entre browsers |
| WASI | WebAssembly/WASI | Fijar por separado release y cobertura del runtime |
| Componentes / WIT | Especificación del Component Model | Fijar revisión mientras evoluciona |
| WebGPU | Especificación WebGPU | Registrar browser, adapter y conjunto de capacidades |
| WGSL | Especificación WGSL | Registrar revisión del lenguaje/especificación |
| WebNN | Especificación WebNN | Tratar el soporte como no universal y fechado |
| WASI-NN | WebAssembly/wasi-nn | Registrar fase de propuesta e implementación del host |
| ONNX Runtime Web | Documentación oficial | Fijar versión del paquete y execution provider |
| LiteRT.js | Documentación web oficial de LiteRT | Fijar versión de API/paquete y soporte de browser |
Registros de artefactos
- Las entradas de modelos deben incluir fuente, licencia, hash original, hash convertido, formato, cuantización, supuestos de operadores y versión del golden output.
- Las entradas de benchmarks deben incluir carga, entorno, warm-up, cantidad de muestras, distribución cruda y observaciones de fallback.
- Las entradas de soporte de browsers deben contener fecha de prueba y build exacto del browser, no solo un resumen de una tabla de compatibilidad.
- Los golden datasets deben registrar preprocesamiento, resultado esperado, tolerancia y por qué existe cada fixture.
- Las entradas de toolchain deben fijar compilador, linker, optimizador, target, flags y comandos de build reproducible.
Política de mantenimiento
Volvé a revisar una entrada del registro cuando cambie una release de la fuente, un browser actualice una capacidad relevante, un runtime cambie el comportamiento de un backend, se reconvierta un modelo o un benchmark deje de reproducirse. Las notas deben citar la URL primaria y conservar localmente la afirmación sensible a versiones; este registro guarda la evidencia normalizada que la respalda.
Conecta con: Empezar acá · Siempre activo · Performance, seguridad y oficio en Wasm AI