General
Cloudflare compra Astro y qué cambia para Astro y developers
Cloudflare compra Astro y el equipo se une a Cloudflare. Astro sigue open source con licencia MIT. Esto es lo que cambia en Astro 6 y en el roadmap.
Leer más4 min de lecturavGPU es la nueva biblioteca open source de Vercel Labs para programar WebGPU desde TypeScript. Su nombre puede causar una confusión importante: no es una “GPU virtual” en la nube, no alquila tarjetas NVIDIA y no sirve, por sí sola, para entrenar modelos de inteligencia artificial. Es una capa pequeña sobre WebGPU para crear shaders, escenas, simulaciones y cómputo paralelo que puedan ejecutarse en el navegador, en Node.js sin interfaz gráfica y en pruebas automatizadas.
La propuesta es atractiva porque intenta resolver dos fricciones habituales de WebGPU: el exceso de código de infraestructura y la dificultad de mantener shaders WGSL grandes. vGPU permite importar archivos .wgsl como módulos, reutilizar funciones entre shaders y conservar una API común entre la web y Node. A continuación explicamos qué ofrece, dónde gana, dónde todavía conviene usar Paper Shaders, Three.js, Babylon o TypeGPU y cómo decidir sin dejarse llevar por el nombre.
Resumen rápido: elige vGPU si necesitas efectos o cómputo WebGPU personalizados, un paquete pequeño, renderizado headless y una experiencia preparada para agentes de código. Elige Paper Shaders si solo quieres efectos visuales prediseñados y amplia compatibilidad WebGL2. Para escenas 3D completas, Three.js o Babylon siguen ofreciendo un ecosistema mucho mayor.
¿Qué es vGPU de Vercel?
vGPU es una biblioteca TypeScript construida sobre WebGPU, la API moderna que permite al navegador enviar renderizado y cálculo de propósito general a la GPU. WebGPU sucede a WebGL y añade un modelo más cercano a las APIs gráficas modernas, además de compute shaders. Los shaders de WebGPU se escriben en WGSL.
Según el repositorio oficial de vGPU, la librería ofrece una API “GPU-first”, imports tipados de WGSL, eliminación de declaraciones no utilizadas y el mismo código en navegador, Node y pruebas. El proyecto es MIT y, al momento de esta revisión (27 de agosto de 2026), la familia de paquetes se encuentra en la serie 0.3.x. Eso importa: es software utilizable, pero todavía conviene fijar versiones y revisar cambios antes de actualizar.
No debe confundirse con una vGPU de infraestructura. En virtualización, “vGPU” suele significar compartir una GPU física entre máquinas virtuales. El proyecto de Vercel Labs no aprovisiona hardware remoto, no reemplaza CUDA y no compite directamente con RunPod, Modal, AWS, Google Cloud o Azure. El trabajo en el navegador se ejecuta en la GPU del visitante; en Node se apoya en un adaptador basado en Dawn.
Los puntos fuertes de vGPU
1. Un shader, varios entornos
La diferencia más interesante no es “hacer gráficos bonitos”, sino reutilizar la misma lógica. Un efecto puede mostrarse en un canvas, renderizarse en Node a una textura, convertirse en una imagen de alta resolución o validarse en CI. El adaptador vgpu/mock permite pruebas deterministas sin una GPU real; para obtener píxeles en Node existe un adaptador basado en Dawn.
2. WGSL modular de verdad
WGSL no tiene un sistema de módulos como TypeScript. vGPU añade imports y exports entre archivos .wgsl, resuelve dependencias en compilación, refleja bindings y elimina declaraciones sin uso. Esto facilita separar ruido, color, muestreo o funciones matemáticas en unidades reutilizables sin concatenar strings manualmente.
3. Tamaño controlado
Vercel afirma que un efecto de pantalla completa cabe dentro de un presupuesto de 25 KB comprimidos con gzip, medido en su propia integración continua. Ese dato describe un objetivo del proyecto, no una garantía de que cualquier escena pese 25 KB ni una comparación universal contra todos los motores. Texturas, modelos, código de aplicación y shaders adicionales aumentarán el peso final.
4. Render y cómputo sin obligarte a adoptar un motor 3D completo
La API pública incluye primitivas para dibujar, ejecutar compute shaders, manejar efectos, frames, superficies, targets y buffers. Esto cubre más que una colección de fondos animados, pero conserva un nivel más bajo y explícito que Three.js o Babylon. Es una ventaja cuando quieres controlar el pipeline; es una desventaja si esperas cámaras, loaders, físicas, materiales PBR y editores listos.
5. Herramientas diseñadas para agentes
La documentación, los ejemplos, el validador WGSL y el diagnóstico se pueden consultar desde la línea de comandos. La galería oficial también expone ejemplos recuperables por herramientas y agentes. Es una decisión poco común y útil para equipos que trabajan con Codex, Claude Code u otros asistentes: el agente puede consultar la API exacta y validar el shader, en vez de improvisar sobre ejemplos antiguos.
Ejemplo rápido: un efecto WebGPU con vGPU
La instalación mínima usa el paquete principal y los tipos de WebGPU:
Bash
pnpm add vgpu
pnpm add -D @webgpu/typesDespliega Next.js y Node.js con control real del servidor
Ejecuta tu frontend, APIs y procesos Node.js en un VPS con acceso root, recursos configurables, snapshots y libertad para administrar el entorno de producción.
En TypeScript se inicializa un contexto, se conecta el canvas y se ejecuta el efecto en cada frame:
TypeScript
import { clock, effect, frameLoop, init, surface } from "vgpu";
import waveShader from "./wave.wgsl";
const gpu = await init();
const output = surface(gpu, canvas, { dpr: [1, 2] });
const wave = effect(gpu, waveShader, { set: { speed: 2 } });
const time = clock(gpu);
frameLoop(gpu, (frame) => {
wave.set({ time: time.time });
frame.pass(output, wave);
});El shader vive en un archivo WGSL separado. La ganancia aparece cuando el proyecto crece: una función de ruido puede exportarse desde otro .wgsl, importarse por nombre y eliminarse del resultado si no se utiliza. En un proyecto WebGPU manual tendrías que construir esa organización por tu cuenta.
Integración con Next.js y Turbopack
vGPU no depende de Next.js, pero la integración es relevante porque los archivos WGSL necesitan pasar por el sistema de compilación. La documentación de @vgpu/wgsl ofrece una regla para Next.js 15.5 o superior con Turbopack:
TypeScript
import type { NextConfig } from "next";
const nextConfig: NextConfig = {
turbopack: {
rules: {
"*.wgsl": {
loaders: ["@vgpu/wgsl/loader-webpack"],
as: "*.js",
},
},
},
};
export default nextConfig;La aplicación debe inicializar el canvas en un componente de cliente; el render headless en Node es otro proceso. Esta separación evita un error frecuente: asumir que importar vgpu/node dentro de una función serverless crea acceso automático a una GPU. El runtime necesita un adaptador compatible y las dependencias nativas correspondientes.
Qué ocurre durante la compilación
El flujo de @vgpu/wgsl resuelve imports entre shaders, conserva los nombres de los entry points, refleja bindings y puede minificar el WGSL. La reflexión es especialmente útil porque reduce la duplicación entre nombres y layouts escritos en el shader y sus equivalentes en TypeScript. Aun así, sigue siendo recomendable ejecutar npx vgpu check en CI y probar en hardware real: que el shader compile no demuestra que mantenga 60 FPS en un teléfono integrado.
¿Qué ejemplos demuestra Vercel?
La galería oficial de vGPU va mucho más allá del triángulo inicial. Incluye un agujero negro con ray marching y bloom HDR, un fractal Sierpiński, refracción de vidrio, fluido interactivo, un océano calculado con FFT y cientos de miles de partículas, instancing, estimación de profundidad y un clasificador MNIST. Esto muestra que vGPU sirve tanto para gráficos como para cómputo, aunque la galería no debe interpretarse como un benchmark independiente.
vGPU vs Paper Shaders: ¿son lo mismo?
No. Paper Shaders es una colección de efectos visuales listos para usar, implementados sobre WebGL2 y disponibles para JavaScript y React. Su propuesta es que un diseñador elija y ajuste un Mesh Gradient, ruido, dithering, vidrio líquido, halftone u otro efecto sin diseñar un pipeline gráfico desde cero.
vGPU usa WebGPU y WGSL; Paper Shaders usa WebGL2 y GLSL. Por eso un shader de Paper no se importa directamente en vGPU. Para moverlo habría que portar el GLSL a WGSL y reconstruir uniforms, texturas y pasos de render. Se puede reproducir el mismo tipo de estética, pero no es una migración de copiar y pegar.
| Criterio | vGPU | Paper Shaders |
|---|---|---|
| Objetivo | Construir pipelines, efectos y cómputo personalizados | Insertar efectos visuales prediseñados |
| Backend | WebGPU / WGSL | WebGL2 / GLSL |
| Primer resultado | Requiere escribir o adaptar un shader | Componente listo con propiedades |
| Compatibilidad | Limitada a entornos con WebGPU | Más amplia gracias a WebGL2 |
| Node/headless | Sí, es parte central de la propuesta | No es su caso de uso principal |
| Compute shaders | Sí | No; está orientado a efectos visuales |
| Ideal para | Simulaciones, visualización técnica, efectos propios, CI | Landing pages, portfolios y fondos animados |
Paper es mejor si el equipo quiere velocidad creativa, efectos afinados y soporte de dispositivos más amplio. vGPU es mejor si necesitas control del pipeline, WebGPU compute, WGSL modular o el mismo render en navegador y Node.
Alternativas a vGPU: comparativa práctica
| Opción | En qué gana | En qué gana vGPU | Úsala cuando… |
|---|---|---|---|
| WebGPU nativo | Control total, cero abstracción y acceso inmediato a la especificación | Menos boilerplate, módulos WGSL, reflexión, Node y mock para pruebas | Estás construyendo un motor o necesitas controlar cada detalle |
| Paper Shaders | Efectos listos, API visual sencilla y WebGL2 | Compute, WGSL propio, multipass y headless | Quieres una estética pulida con pocas líneas |
| TypeGPU | Tipado profundo de buffers, bind groups y shaders escritos con funciones TypeScript | API de render más directa, archivos WGSL modulares y flujo web/Node integrado | La seguridad de tipos y la adopción granular son la prioridad |
| Three.js WebGPURenderer | Ecosistema 3D enorme, scene graph, loaders, materiales, postprocesado y fallback WebGL2 | Menor superficie cuando solo necesitas un efecto o pipeline específico | Construyes experiencias 3D, configuradores o visualizadores |
| Babylon.js | Motor 3D completo, herramientas maduras, PBR, assets y compatibilidad amplia | Más pequeño y explícito para shaders o cómputo focalizado | Necesitas un producto 3D completo y estable |
| Babylon Lite | Motor 3D WebGPU tree-shakeable con escenas, cámaras y materiales | Más cercano al shader y con Node headless orientado al render | Quieres un motor 3D moderno sin el peso conceptual de Babylon.js |
vGPU vs TypeGPU
Es la comparación más cercana. TypeGPU prioriza la seguridad de tipos de extremo a extremo: estructuras, buffers y bind groups mantienen información que WebGPU normalmente reduce a bytes, y permite escribir funciones TypeScript marcadas con 'use gpu' que generan WGSL. Además, facilita adoptar solo algunas piezas y acceder al recurso WebGPU nativo.
vGPU, en cambio, parte de WGSL como lenguaje explícito y ofrece una capa compacta para componer el render, cargar módulos, ejecutar frames y repetir el flujo en Node. Si tu equipo quiere escribir shaders en TypeScript y detectar más incompatibilidades durante compilación, TypeGPU es muy convincente. Si ya piensa en WGSL y quiere una ruta corta de shader a canvas, imagen, video o CI, vGPU resulta más directo.
vGPU vs Three.js WebGPURenderer
Three.js WebGPURenderer usa WebGPU por defecto y puede caer a WebGL2 cuando WebGPU no está disponible. También incorpora TSL, un lenguaje de shaders basado en nodos que compila a WGSL o GLSL. Esa compatibilidad y el enorme ecosistema de Three.js son ventajas decisivas para escenas 3D.
vGPU evita el scene graph y deja frames y pases explícitos. Es preferible para un fondo de shader, una simulación 2D, procesamiento de imagen, visualización matemática o un pipeline altamente personalizado donde un motor completo agregaría conceptos que no se necesitan.
vGPU vs Babylon.js y Babylon Lite
Babylon.js sigue siendo la opción madura cuando se necesitan cámaras, luces, materiales, importación glTF, tooling y compatibilidad. Babylon Lite es su alternativa nueva, exclusiva de WebGPU, modular y tree-shakeable. Es más comparable con vGPU en filosofía de tamaño, pero continúa siendo un motor 3D.
La pregunta correcta es: ¿quieres construir una escena con entidades, cámaras y materiales, o un pipeline de GPU? Para lo primero, Babylon; para lo segundo, vGPU. La propia documentación de Babylon recomienda Babylon.js como opción general de producción mientras Lite completa funciones y estabiliza su API.
Limitaciones de vGPU que debes considerar
- WebGPU todavía no es Baseline. MDN lo marca con disponibilidad limitada y exige un contexto seguro HTTPS. Debes detectar soporte y ofrecer una imagen, video, CSS, WebGL2 u otra experiencia alternativa.
- No hay fallback WebGL2 automático. Si la audiencia incluye navegadores, sistemas o GPUs sin WebGPU, Three.js WebGPURenderer o una solución WebGL2 como Paper puede reducir el trabajo de compatibilidad.
- El proyecto es joven. Su versión temprana implica posibles cambios de API, menor comunidad y menos integraciones que Three.js o Babylon. Conviene fijar versiones y proteger la adopción detrás de un módulo propio.
- “Pequeño” no significa “siempre rápido”. El rendimiento depende del shader, resolución, memoria, número de pases, formatos, lecturas CPU↔GPU y hardware del usuario. Mide tiempo de frame y memoria en tus dispositivos objetivo.
- Node no convierte Vercel Functions en servidores con GPU. El adaptador headless necesita un runtime compatible. Para CI sin hardware, el mock valida lógica determinista, pero no sustituye una prueba real de render y rendimiento.
- Necesitas aprender WGSL. vGPU reduce infraestructura, no elimina los conceptos de buffers, bindings, pipelines, texturas, sincronización y precisión numérica.
Cómo evaluar vGPU antes de llevarlo a producción
No basta con abrir una demo en una laptop potente. Un piloto útil debe medir el comportamiento del efecto en los dispositivos, resoluciones y navegadores reales de la audiencia.
- Define una referencia: compara el mismo resultado visual en vGPU, en la solución actual y en el fallback. No compares escenas diferentes.
- Mide el frame time: registra medianas y percentiles, no solo FPS observados durante unos segundos.
- Prueba cambios de DPR: renderizar al doble de resolución multiplica el trabajo de píxeles; limita el device-pixel ratio cuando la diferencia visual sea mínima.
- Revisa memoria y transferencias: las lecturas de GPU a CPU pueden bloquear el pipeline. Mantén los datos en la GPU cuando sea posible.
- Valida pérdida de dispositivo: una pestaña puede perder el contexto por memoria, drivers o suspensión. La interfaz debe recuperarse o mostrar un fallback.
- Prueba el build de producción: confirma que Turbopack, webpack o Vite incluyen los shaders, vigilan dependencias y minifican sin romper entry points.
- Separa pruebas deterministas y visuales: usa el mock para lógica y snapshots headless o hardware real para comprobar los píxeles.
Despliegue en VPS: qué resuelve y qué no
Una aplicación Next.js que presenta un canvas vGPU puede desplegarse en un VPS como cualquier proyecto Node.js: proceso persistente, proxy inverso, HTTPS, variables de entorno y logs bajo el control del equipo. Esto es útil si la aplicación también tiene APIs, autenticación, trabajos en segundo plano o generación de activos.
Un VPS convencional no añade una GPU al navegador del visitante y tampoco garantiza render headless acelerado. Para trabajo GPU en el servidor necesitas hardware y drivers compatibles; para CI sin GPU puedes utilizar el adaptador mock cuando la prueba no requiera píxeles reales. Si necesitas controlar el runtime de Next.js y Node, puedes consultar VPS Hosting de Teramont y dimensionar CPU, RAM y almacenamiento según la aplicación, sin confundir esos recursos con una GPU dedicada.
¿Qué deberías elegir?
- Landing con gradiente, ruido o vidrio en una tarde: Paper Shaders.
- Efecto propio, simulación, partículas o procesamiento de imagen: vGPU.
- Proyecto que quiere shaders en TypeScript con tipado exhaustivo: TypeGPU.
- Configurador, juego o visualizador 3D con muchos assets: Three.js o Babylon.js.
- Motor 3D moderno, WebGPU-only y muy tree-shakeable: evaluar Babylon Lite.
- Motor interno o investigación de bajo nivel: WebGPU nativo.
Nuestra lectura es que vGPU ocupa un espacio útil entre dos extremos: es más estructurado que WebGPU nativo y más pequeño y explícito que un motor 3D. Su diferenciador real no es solamente Vercel ni la palabra “agentes”; es la combinación de WGSL modular, render headless y una misma API para producción y pruebas.
Preguntas frecuentes sobre vGPU
¿vGPU de Vercel ofrece GPUs en la nube?
No. Es una biblioteca TypeScript para usar WebGPU. No alquila hardware y no reemplaza un proveedor de GPU cloud.
¿Puedo usar vGPU con Next.js?
Sí. El paquete incluye integración para loaders de WGSL en Turbopack/webpack y Vite. El canvas debe inicializarse en el cliente; el render headless de Node es un flujo separado y requiere el adaptador correspondiente.
¿vGPU reemplaza a Three.js?
No de forma general. vGPU es apropiado para pipelines y shaders específicos. Three.js agrega scene graph, cámaras, loaders, materiales y un ecosistema 3D mucho más amplio.
¿Se pueden usar los shaders de Paper en vGPU?
No directamente. Paper Shaders está basado en WebGL2/GLSL y vGPU en WebGPU/WGSL. Es necesario portar el shader y adaptar sus recursos.
¿vGPU funciona en todos los navegadores?
No. Depende de WebGPU, que todavía tiene huecos de disponibilidad. Usa HTTPS, detección de capacidades y un fallback adecuado para tu audiencia.
¿vGPU es gratis?
El código es open source con licencia MIT. Eso no elimina los costos de desarrollo, hosting, transferencia ni del hardware o runtime utilizado para render headless.
Conclusión
vGPU es una incorporación prometedora al ecosistema WebGPU: pequeña, modular y pensada para que un shader no quede atrapado en un único canvas. Su mejor caso de uso aparece cuando el equipo necesita efectos o cómputo personalizados, desea probarlos en CI y valora que herramientas automáticas puedan consultar documentación y ejemplos exactos.
No es la elección automática para todo sitio. Paper Shaders entrega resultados visuales más rápido; Three.js y Babylon resuelven mucho más de una aplicación 3D; TypeGPU ofrece una historia de tipos más profunda; WebGPU nativo conserva el máximo control. El ganador depende de si buscas un efecto listo, un motor, un toolkit tipado o un pipeline compacto. Para proyectos nuevos y controlados que ya apuntan a WebGPU, vGPU merece una prueba técnica seria.
