Cómo funciona RakuAI, de principio a fin
Escanea una habitación con tu teléfono. Treinta segundos después, existe un splat gaussiano 3D. Ahora pídele a Claude, o a ChatGPT, o a Gemini, que lo consulte, lo anote, mueva cosas dentro de él. Esa es toda la propuesta. Este artículo es el relato honesto de cómo funciona en realidad cada paso, qué está en producción hoy y qué todavía depende de créditos de GPU.
Este es un tipo de artículo distinto para el blog. Los artículos habituales de los sábados tratan sobre un problema específico resuelto o una semana específica sobrevivida. Este se aleja para ver el panorama completo: qué es RakuAI, cómo se conectan sus piezas, y cuál es en realidad el foso defensivo cuando lo sigues de principio a fin. Es el artículo que me hubiera gustado que existiera la primera vez que tuve que explicarle esto a un socio desarrollador que quería la historia real, no la versión del pitch deck.
La premisa en una frase
Escaneas un lugar real con un teléfono. El escaneo se convierte en un splat gaussiano 3D, una reconstrucción fotorrealista hecha de millones de diminutos elipsoides transparentes. El splat se sirve a través de un runtime que lo expone como herramientas que cualquier LLM puede invocar. El LLM puede consultar la escena, razonar sobre lo que contiene y, con los permisos adecuados, mutarla. Sin licencia de motor de videojuegos. Sin integración por proveedor. Sin dependencia de un modelo específico.
Esa es la idea de “Escanéalo. Luego háblale.” Así es como funciona cada pieza de esa cadena.
Paso 1: Captura, de video del teléfono a fotogramas en bruto
El punto de entrada es una Progressive Web App en rakuai.com/capture-app/. Se ejecuta en un navegador móvil sin instalación. El usuario graba de 30 a 60 segundos de video, caminando despacio alrededor del sujeto: una habitación, un objeto, un espacio que merece la pena preservar.
La PWA empaqueta los fotogramas de video y los sube a POST /api/v1/capture en el backend, que se ejecuta en Azure Container Apps en api.rakuai.com. El backend es un servicio FastAPI (~9,500 endpoints REST) que autentica la subida, registra metadatos (nombre de archivo original, tipo de contenido, marca de tiempo de captura) y almacena el paquete de entrada en bruto en Azure Blob Storage.
Esa parte está en producción. La ruta de subida funciona hoy, para cualquiera que se registre.
Paso 2: Reconstrucción, de extracción de características COLMAP a nube de puntos
El backend despacha un trabajo de reconstrucción a un ejecutor de trabajos de Container Apps llamado recon-worker. Lo primero que hace es ejecutar COLMAP, la biblioteca de Structure from Motion, sobre los fotogramas subidos. COLMAP identifica características coincidentes entre fotogramas y calcula posiciones de cámara, produciendo una nube de puntos 3D dispersa.
Este paso depende de la CPU y no requiere GPU. Se ejecuta hoy.
Paso 3: Entrenamiento del splat, Brush convierte una nube de puntos en un splat gaussiano
Este es el paso computacionalmente intensivo. El worker de reconstrucción alimenta la nube de puntos de COLMAP y los fotogramas originales a Brush v0.3.0, un entrenador de 3D Gaussian Splatting. Brush ajusta millones de pequeñas gaussianas 3D a la escena; cada gaussiana es un elipsoide en el espacio 3D con una posición, orientación, escala, opacidad y color dependiente de la vista. La salida es un archivo .ply o .spz almacenado en Azure Blob Storage junto con la entrada.
Honestamente: este paso requiere una GPU. La cuota de GPU en Azure A10 está en revisión. Los créditos de AWS Activate están pendientes de aprobación (solicitados el 28 de mayo de 2026). Hasta que uno de esos llegue, el worker de reconstrucción de producción recurre a un backend simulado: la arquitectura está conectada, la ruta de GPU aún no está en producción. Esto es acceso anticipado, no un producto de consumo terminado.
Paso 4: El runtime MCP, 17 herramientas + ~9,500 endpoints de passthrough
Esta es la parte que convierte el splat en un objeto espacial vivo en lugar de un archivo estático.
El runtime es un motor en C++: 18 DLL nativas, 30,738 funciones exportadas en subsistemas de física, renderizado, audio, seguimiento, estado multijugador y orquestación de IA. En verde en CI en Windows, Linux y macOS desde abril de 2026.
Sobre el motor, el servidor MCP expone dos superficies:
17 herramientas nativas (5 de solo lectura + 12 de mutación): el contrato tipado que cualquier agente externo usa para interactuar con una escena. Las herramientas de solo lectura funcionan en todos los entornos. Las herramientas de mutación requieren concesiones de permiso explícitas y se deniegan por defecto en producción.
~9,500 endpoints de passthrough: toda la superficie FastAPI de raku-api, expuesta a través del relay MCP. Cualquiera de las rutas del backend se puede alcanzar a través del relay, dándole a un LLM acceso al historial de capturas, el estado de los trabajos, los metadatos de escena y toda la superficie de consulta del backend.
El servidor MCP se aloja en api.rakuai.com en Azure Container Apps. El relay para Claude Desktop, ChatGPT y Gemini está en producción. El servidor habla transporte stdio, registra cada llamada en un rastro de auditoría y aplica límites de tasa por sesión.
Paso 5: Acceso multi-proveedor a LLM, el foso defensivo real
Cualquier modelo que hable Model Context Protocol puede conectarse al runtime e invocar herramientas contra una escena capturada sin una integración personalizada. Claude, ChatGPT, Gemini, Copilot: el contrato es el mismo para todos ellos.
El runtime escribe el contrato una sola vez. Los modelos se adaptan al contrato. Cuando un nuevo laboratorio de modelos lanza un cliente MCP, este funciona contra el runtime sin ningún cambio de código de nuestra parte.
El runtime no tiene opinión sobre qué modelo hay al otro lado. Conserva la autoridad sobre física, colisiones, puntuación, renderizado y estado de escena. El modelo aporta consultas e intención. Ninguno de los dos lados necesita saber que el otro existe salvo a través de la superficie de herramientas tipada.
Este es el foso defensivo: captura honesta del mundo físico, almacenada como una representación 3D sin pérdidas, consultable por cualquier LLM que hable un protocolo abierto. No atado a un solo modelo. No atado a un solo caso de uso. No atado a un solo proveedor de hardware.
Qué está en producción hoy frente a qué es hoja de ruta
En producción hoy: - PWA de captura desde el teléfono, subida a Azure Blob - Extracción de características COLMAP y nube de puntos - Infraestructura del backend (FastAPI ~9,500 endpoints REST, almacén de trabajos Redis, límites de tasa por nivel) - Runtime MCP con 17 herramientas nativas + ~9,500 endpoints de passthrough - Relay MCP alojado para Claude, ChatGPT, Gemini - Contrato de herramientas multi-proveedor (stdio, denegación por defecto, registro de auditoría completo) - Nivel gratuito y nivel Pro Beta (Pro Beta es $0 durante el periodo beta)
Bloqueado (acceso anticipado, se espera dentro de días): - Entrenamiento real de splats con GPU en Azure A10 (cuota en revisión) - Entrenamiento real de splats con GPU en AWS G5 (créditos de Activate en revisión)
Hoja de ruta (aún no lanzado): - Visor de splats en vivo en la PWA de captura (el renderizador de splats gaussianos con three.js está conectado; la demo de extremo a extremo requiere un splat entrenado) - Concesiones de mutación de producción de autoservicio - Ecosistema de adaptadores de terceros (existen adaptadores de referencia propios; el ecosistema amplio es hoja de ruta)
Miembro de NVIDIA Inception desde mayo de 2026.
Por qué “solo inferencia” no es una limitación
El runtime no entrena modelos. No hace fine-tuning de modelos. No requiere que ejecutes un modelo dentro de él. El modelo que ya tienes, sea el que sea, viva donde viva, esté licenciado como esté licenciado, se conecta a través de MCP y dirige el runtime desde fuera.
Esta es una decisión de arquitectura deliberada. Entrenamiento e inferencia son asuntos separados. El runtime es bueno en física espacial, gestión de estado determinista, sincronización multiusuario y renderizado de baja latencia. El laboratorio de modelos es bueno en razonamiento, generación y lenguaje. El contrato MCP es la frontera entre ambos. Ninguno de los dos lados tiene que hacer el trabajo del otro.
Solo inferencia también significa que no hay requisito de residencia en GPU para servir. El paso computacionalmente intensivo (entrenamiento del splat) es un costo único por captura. Todo lo que viene después es geometría y consultas MCP, y se ejecuta en las mismas instancias de Azure Container Apps que sirven la API.
El resumen honesto
El pipeline es: video del teléfono → COLMAP → Gaussian splatting con Brush → Azure Blob → runtime MCP → cualquier LLM. Cuatro de los cinco pasos están en producción. El quinto (entrenamiento de splats con GPU) está conectado y a la espera de créditos. El visor que cierra el ciclo en el navegador es el próximo hito.
Si quieres probar hoy el extremo de captura, la PWA está en rakuai.com/capture-app/. Si quieres dirigir una escena por MCP desde Claude Desktop, la guía está en /developers/claude-desktop.html. Si quieres entender toda la superficie de herramientas, está en /mcp.html.
Escanéalo. Luego háblale.