Personal / Investigación · 2025
GSP
Plataforma de render Gaussian Splatting
Plataforma self-hosted donde se suben fotos de una escena y orquesta trabajos en GPU alquilada para devolver un render Gaussian Splatting, con historial por organización.
Tecnologías: Next.jsNode.jsPostgreSQLDrizzle ORMCloudflare R2Better-Auth
Resumen
GSP es una plataforma multi-tenant de Gaussian Splatting 3D: se sube un conjunto de fotos de una escena y devuelve el splat renderizado. Gaussian Splatting reconstruye escenas 3D fotorrealistas a partir de imágenes 2D representándolas como millones de elipsoides semitransparentes en vez de mallas, y renderiza en tiempo real.
Lo construí para entender la tecnología desde el lado de la infraestructura y no desde un paper.
El problema
Correr un render de splatting no es lo difícil: es un comando sobre una carpeta de imágenes. Lo difícil es todo lo que lo rodea. Necesita una GPU, y una GPU ociosa cuesta plata todo el día. El trabajo tarda lo suficiente como para que ningún request HTTP lo espere. Falla seguido, por razones que van desde fotos malas hasta una máquina que desaparece. Y la salida pesa, así que no puede vivir al lado de la app.
Sin ese andamiaje, experimentar con la técnica es cuidar una terminal.
Decisiones
- Alquilar cómputo GPU por trabajo en vez de dejar una máquina prendida: el cómputo se aprovisiona cuando arranca el trabajo y se libera al terminar, así no se paga tiempo ocioso.
- Una cola con un worker en background en vez de un request sincrónico: subir y renderizar son cosas separadas, el usuario recibe un trabajo con estado (pendiente, en proceso, fallido, exitoso) y puede cerrar la pestaña.
- Reintentos automáticos con backoff exponencial: acá las fallas son en su mayoría transitorias, así que el reintento es parte del pipeline y no un relanzamiento manual.
- Cloudflare R2 para entradas y salidas: los uploads van directo al object storage, los renders vuelven ahí, y el servidor de la app nunca se convierte en servidor de archivos.
- Multi-tenant con Better-Auth y organizaciones que invitan miembros: los renders son de un equipo, con su historial y su uso, que es también lo que habilita la facturación por consumo.
- Drizzle ORM con PostgreSQL para el estado de trabajos y usuarios: la máquina de estados de un trabajo es lo más consultado del sistema, así que queda relacional y tipada.
- Next.js con shadcn/ui para la superficie de administración: lo interesante es el pipeline, así que la UI reusa componentes en vez de inventarlos.
Interfaz de administrador
Resultado
GSP corre el ciclo completo de punta a punta: entran las fotos, se encola el trabajo, se alquila cómputo GPU bajo demanda, se reintenta cuando algo falla y el render terminado queda en R2 bajo la organización que lo pidió.
Me mostró que la ingeniería interesante en un producto pesado en GPU rara vez es el algoritmo: es la cola, los reintentos, el storage y el multi-tenant alrededor. Esa es la parte que convirtió un experimento que corría a mano en algo que cualquiera con una cuenta puede correr.