Empezar acá
WebAssembly AI Atlas conecta dos cuerpos de conocimiento que suelen aprenderse por separado: cómo se ejecuta el código portable y cómo los sistemas de inferencia mueven tensores a través de modelos y hardware. No necesitás dominar cada prerrequisito antes de empezar, pero sí tenés que saber sobre qué capa estás razonando.
Base recomendada
- Low-Level Atlas I para fundamentos de C, memoria, assembly, linking, procesos y concurrencia.
- Low-Level Atlas II para construir sistemas ejecutables, parsers, servidores y componentes de almacenamiento desde primeros principios.
- Low-Level Atlas III para límites browser/servidor, protocolos, workers, backpressure y sistemas concurrentes.
- AI Atlas para tensores, redes neuronales, LLMs, embeddings, RAG, agentes, evaluación y optimización de inferencia.
Podés empezar aunque tengas huecos, pero seguí los enlaces hacia esos proyectos Atlas en vez de reconstruir acá toda su teoría.
Roles de plataforma
| Entorno | Rol en este Atlas |
|---|---|
| Browser | Host principal, UI, almacenamiento, medios, ciclo de vida y límite de capacidades |
| WebAssembly | Ejecución portable en CPU y código guest en sandbox |
| WebGPU | Cómputo explícito en GPU y gestión de buffers |
| WebNN | API de alto nivel para grafos neuronales dirigida a CPU, GPU o NPU cuando hay soporte |
| WASI | Interfaces de host portables fuera del browser |
| JavaScript / TypeScript | Orquestación del host y aplicación principal del Workbench |
| Rust | Lenguaje principal para módulos y componentes Wasm nuevos |
| C / C++ | Porting, Emscripten y comparación de toolchains |
| Python | Referencia para entrenamiento/exportación y generación de golden outputs |
WebAssembly, WebGPU, WebNN y WASI son complementarios, no intercambiables. Un runtime puede usar Wasm en CPU, llamar a WebGPU, exponer WebNN o proveer WASI-NN; cada camino tiene una API, un modelo de autoridad, una superficie de compatibilidad y un perfil de costos diferentes.
Qué vas a construir con el tiempo
WasmAI Workbench empieza con un módulo vectorial WAT escrito a mano, crece hasta un motor pequeño de tensores e inferencia MLP, compara kernels escalares/SIMD/con threads, carga artefactos ONNX y LiteRT reales, selecciona backends acelerados, funciona offline para tareas de imagen y audio, suma búsqueda semántica retrieval-first, empaqueta un componente portable y, por último, aloja herramientas tipadas dentro de sandboxes Wasm con capacidades limitadas.
Este esqueleto documenta el recorrido. Los artefactos ejecutables llegarán con futuras notas atómicas y deberán compilar o ejecutarse exactamente como se documente.
Dos recorridos de lectura válidos
Recorrido lineal
Leé Orientación y después las fases 01 a 06 en orden. Mantené Siempre activo abierto mientras construís cada hito.
Recorrido por proyecto
Elegí un hito del Workbench, abrí su página de fase y seguí las ramas de prerrequisitos hacia atrás hasta entender cada byte, forma de tensor, capacidad y decisión de backend. No saltes directamente a una API de runtime si todavía no podés explicar sus contratos de memoria y modelo.
Antes de usar capacidades específicas de hardware
- Tratá el soporte de browser como evidencia fechada, no como un hecho permanente.
- Esperá que WebGPU, WebNN, SIMD, threads y el aislamiento cross-origin difieran según el entorno.
- Conservá baselines pequeños de CPU/Wasm para poder verificar y mostrar el fallback de los caminos acelerados.
- Usá modelos chicos y fixtures deterministas antes de medir cargas grandes.
- Registrá tolerancias numéricas; etiquetas que se ven iguales no prueban tensores equivalentes.
Primer ciclo
- Leé Lo imprescindible.
- Establecé las reglas de evidencia en Fase 00: Orientación.
- Entrá en Modelo de ejecución de WebAssembly.
- Mantené Performance, seguridad y oficio activo desde v0.
- Usá Registro de referencias cuando pueda cambiar el estado de una especificación o API.