WebLLM permite ejecutar un modelo de IA generativa directamente en el navegador, sin servidor de inferencia. Para un proyecto web, esto cambia tres cosas: menos datos enviados a un tercero, una latencia a veces muy baja tras la carga, pero también restricciones fortes en el peso de los modelos, la compatibilidad con WebGPU y la experiencia de usuario en el primer lanzamiento.
WebLLM: lo que hace concretamente en un navegador
WebLLM es un framework JavaScript open source, bajo licencia Apache-2.0, publicado por la comunidad MLC. Su función es fácil de entender: ejecuta un LLM, es decir, un gran modelo de lenguaje, en Chrome u otro navegador compatible, en lugar de enviar cada solicitud a una API remota como OpenAI, Anthropic o Mistral AI.
Técnicamente, WebLLM se apoya en WebGPU, la interfaz que da al navegador acceso a la tarjeta gráfica, y en WebAssembly, un format de ejecución de bajo nivel utilizable en la web. El proyecto también utiliza MLC-LLM y Apache TVM para generar núcleos WebGPU optimizados, dicho de otro modo, morceaux de cálculo adaptados a la GPU de la máquina.
MLC presentó WebLLM en junio de 2024 como un motor de inferencia LLM de alta performance en el navegador. La inferencia, aquí, designa el momento en que el modelo produce una respuesta. El artículo publicado en arXiv el 20 de diciembre de 2024 indica que WebLLM puede conservar hasta el 80 % de las performances nativas en el mismo dispositivo; la entrada de MLC mencionaba hasta el 85 % en sus resultados.
Esta cifra no quiere decir que un sitio web se vuelva mágicamente tan potente como un servidor equipado con GPU NVIDIA de alta gama. Significa más bien que, a igualdad de hardware, la ejecución en el navegador ya no es forcément un gadget. Para entender la capa que hace esto posible, el tema WebGPU e IA en el navegador merece examinarse de antemano.
Lo que WebLLM cambia para su presupuesto, sus datos y sus plazos
El primer interés económico es evidente: una parte de los costes de inferencia puede desaparecer del lado del servidor. Si su aplicación procesa miles de pequeñas solicitudes simples, no llamar a una API de pago en cada interacción puede reducir la factura mensual. Pero el cálculo es menos favorable en cuanto hay que garantizar una calidad estable en todos los dispositivos.
El segundo interés se refiere a la confidencialidad. WebLLM calcula del lado del cliente, por lo que los prompts y las respuestas pueden permanecer en el navegador. Para una herramienta que maneja notas internas, borradores comerciales o datos personales, es una verdadera palanca de reducción del riesgo RGPD, siempre que no se reintroduzcan en otro lugar rastros en la analítica, los logs o el support.
En cuanto a los plazos, no hay que confundir demostración y producto explotable. Instalar el package npm @mlc-ai/web-llm, documentado en 2026 en una versión reciente en torno a 0.2.84 según los metadatos de npm consultados por Aikido Intel, puede hacerse rápido. Diseñar una experiencia fiable lleva más tiempo: elección del modelo, prueba de los navegadores, gestión de la caché, fallback del servidor, consentimiento del usuario.
En los proyectos que llevamos a cabo, a menudo vemos una diferencia entre el prototipo que impresiona en la reunión y la versión que aguanta frente a un parque real de PC de empresa, Mac personales y móviles recientes. La trampa: olvidar que el coste se transfiere al usuario. Su batería, su memoria, su tiempo de descarga.
Modelos compatibles, instalación y arquitectura tipo
La documentación de 2026 de WebLLM indica compatibilidad con familias de modelos conocidas: Llama 3, Phi 3, Gemma, Mistral y Qwen. Un ejemplo de modelo precompilado citado por MLC es Llama-3-8B-Instruct-q4f32_1-MLC. El sufijo no es decoratif: indica en particular una cuantificación, es decir, una compresión numérica del modelo para hacerlo más ligero de ejecutar.
Un modelo WebLLM necesita dos elementos: los pesos del modelo convertidos al format MLC, y una biblioteca de modelo que contiene la lógica de inferencia. Para un modelo ya preparado, la integración se parece a una dependencia JavaScript clásica. Para un modelo personalizado, la documentación de MLC menciona la instalación o la verificación de mlc_llm y de TVM para compilar los artefactos necesarios.
La instalación del lado del proyecto está documentada con npm install @mlc-ai/web-llm. También existe una implementación CDN mediante import * as webllm from "https://esm.run/@mlc-ai/web-llm";. En producción, sinceramente, es mejor evitar depender únicamente de un CDN público para una función tan central: versiona, prueba y controla tu cadena de entrega.
WebLLM retoma varios hábitos del ecosistema OpenAI: streaming, opciones de generación, control a nivel de logits, seeding, modo JSON. El function calling se indica como en curso de desarrollo en el README 2026. Esta compatibilidad facilita la migración de un prototipo ya pensado en torno a una API conversacional, aunque el rendimiento y los límites no serán idénticos.
| Opción de IA para una aplicación web | Coste indicativo en Francia | Plazo realista para un MVP | Puntos a tener en cuenta |
|---|---|---|---|
| API LLM remota tipo OpenAI, Anthropic o Mistral AI | A menudo, de unas decenas a varios cientos de euros al mes según el volumen | 1 a 3 semanas | Datos enviados a un tercero, costes variables |
| WebLLM en el navegador | Desarrollo más bien de 8 000 a 25 000 € según la integración y las pruebas | De 3 a 8 semanas | Compatibilidad con WebGPU, peso inicial, dispositivos poco potentes |
| Servidor dedicado con modelo open source | Infraestructura GPU a menudo de varios cientos a miles de euros al mes | 4 a 10 semanas | Ops, supervisión, escalado |
Cuándo WebLLM es una buena idea, y cuándo no lo es
WebLLM es pertinente cuando las tareas son locales, frecuentes y relativamente cortas: reformulación, ayuda a la redacción, extracción simple, clasificación de texto, resumen de notas ya presentes en el navegador. El beneficio se vuelve claro si los datos no deben salir del dispositivo o si el uso se realiza en modo parcialmente desconectado.
La solución resulta menos evidente para un chatbot comercial abierto a todo el público. ¿Por qué? Porque un cliente potencial con un PC Windows antiguo o un smartphone de gama de entrada no debe tener que esperar una gran descarga antes de hacer su pregunta. En este caso, una API de servidor o un enfoque híbrido será a menudo mejor.
Otro límite: la gobernanza. Un modelo local es más difícil de actualizar instantáneamente para todo el mundo si depende de la caché del navegador. Y si la aplicación debe registrar las respuestas para auditoría, calidad o conformidad, hay que diseñar este mecanismo sin anular la ventaja de la confidencialidad.
Con este presupuesto, a veces es mejor financiar una buena arquitectura híbrida que un dogma de “todo local”. WebLLM para las tareas sensibles o repetitivas, una API remota para las solicitudes complejas, y un enrutamiento claro entre ambos. Esta lógica se une a las reflexiones más amplias sobre las IA integradas, como en la comparativa Apple Intelligence, Galaxy AI y Pixel AI.
Los puntos técnicos que hay que definir antes de iniciar el desarrollo
La definición debe empezar por los navegadores y los dispositivos objetivo. WebGPU es la pieza clave de la aceleración, pero su disponibilidad varía según los entornos, las políticas de empresa y las versiones. Prevea un modo degradado; de lo contrario, la aplicación parecerá averiada para una parte de los usuarios.
A continuación viene el peso del modelo. Incluso comprimido, un LLM sigue siendo pesado para una página web. La primera carga debe explicarse, almacenarse en caché y probarse con una conexión media, no solo con la fibra de la oficina. Una interfaz elegante no salvará una espera mal gestionada.
- Probar WebGPU desde la página de entrada, con un mensaje claro si el dispositivo no es compatible.
- Prever un fallback de servidor o una funcionalidad reducida para los equipos bloqueados.
- Medir el tiempo de descarga del modelo en 4G y Wi‑Fi medio.
- Limitar los casos de uso al principio: una tarea de IA bien definida vale más que un asistente generalista mediocre.
- Documentar los tratamientos para el RGPD y, según el contexto, para la AI Act europea adoptada en 2024.
La seguridad no desaparece porque el cálculo sea local. Hay que verificar las dependencias npm, fijar las versiones, auditar los permisos del front-end y evitar exponer secretos en el código cliente. Aikido Intel indicaba en 2026 no haber encontrado vulnerabilidades conocidas en @mlc-ai/web-llm, pero este tipo de información debe volver a verificarse en el momento del build.
Si su proyecto prevé conectar la IA a herramientas internas, la cuestión va más allá de WebLLM. El navegador puede generar texto, pero el acceso a los datos, a los permisos y a las acciones de negocio requiere una arquitectura separada. Los estándares de orquestación como el Model Context Protocol para conectar agentes de IA a los datos responden a otra capa del problema.
WebLLM frente a las alternativas recientes del navegador
WebLLM no está solo en el ámbito de la IA del lado del navegador. Google también impulsa capacidades nativas en torno a Gemini Nano en Chrome, con la Built-in AI API en algunas versiones recientes. La diferencia es estructural: WebLLM le permite elegir e integrar modelos open source compatibles, mientras que una API nativa del navegador depende más del editor y de su alcance.
Para una pyme, la decisión rara vez se resume a “qué tecnología es la más moderna”. Hay que analizar el control del modelo, la portabilidad, la conformidad, el coste de mantenimiento y el nivel de aceptación por parte de sus usuarios. Una API integrada puede reducir el esfuerzo técnico, pero le vincula a las decisiones de un navegador. WebLLM exige una mayor definición previa, pero ofrece más control.
El paralelismo con los runtimes JavaScript es revelador: la elección adecuada depende del ecosistema, del equipo y del ciclo de vida, no solo de un benchmark. Si su aplicación web ya está muy orientada al front-end, las decisiones en torno a Node.js, Bun o Deno como runtime JavaScript también pueden influir en las herramientas, las pruebas y la construcción del bundle.
Queda el caso de las funcionalidades de producto. Para un asistente integrado en un back-office, WebLLM puede ser excelente si se acepta un perímetro controlado. Para un servicio de atención al cliente público, una solución de servidor supervisada sigue siendo a menudo más racional. Y para un uso Chrome-first en una flota conocida, la opción de Gemini Nano integrado en el navegador puede llegar a ser competitiva.
Definir este tipo de proyecto de antemano evita la mayoría de las sorpresas desagradables: peso de los modelos, compatibilidad, costes ocultos y conformidad. Del lado de la agencia, el reflejo es prototipar rápido y después medir en dispositivos reales antes de fijar la arquitectura.
Preguntas frecuentes sobre WebLLM
¿WebLLM funciona sin conexión a Internet?
Sí, una vez cargados y almacenados en caché el modelo y los archivos necesarios, la inferencia puede realizarse localmente. La primera carga suele requerir una conexión, salvo en el caso de una aplicación empaquetada o precargada.
¿Sustituye WebLLM a una API como OpenAI?
No siempre. WebLLM puede sustituir una API para tareas locales y delimitadas, pero los modelos remotos siguen siendo a menudo mejores para las solicitudes complejas, la supervisión centralizada y una calidad homogénea en todos los dispositivos.
¿Qué navegadores son compatibles con WebLLM?
La compatibilidad depende sobre todo de WebGPU y del entorno de hardware. Hay que probar los navegadores que realmente utilizan sus clientes o empleados, y luego prever un fallback si WebGPU no está disponible.
¿Es WebLLM adecuado para una pyme sujeta al RGPD?
Puede ayudar, ya que los datos pueden permanecer en el navegador. Pero el RGPD se refiere a todo el tratamiento: logs, analytics, almacenamiento local, consentimiento, derechos de acceso y documentación deben tratarse seriamente.