Massive ha convertido una decisión de infraestructura en una ventaja económica. La compañía, especializada en acceso web en tiempo real para agentes de IA, scrapers y pipelines de datos, opera parte de su plataforma sobre servidores bare metal dedicados de DataPacket en lugar de apoyarse en un hiperescalares tradicional. El resultado que destaca el caso de estudio es llamativo: una latencia media de 2 milisegundos hacia grandes proveedores cloud, picos de tráfico de 20 Gbps absorbidos sin coste adicional y un ahorro estimado de 2,9 millones de dólares al año frente a la facturación equivalente por tráfico saliente en grandes nubes.
La decisión no es solo técnica. Es una forma de proteger el modelo de negocio. Massive vende acceso a páginas web vivas, HTML renderizado y resultados estructurados de búsqueda para clientes que alimentan agentes de IA y sistemas automatizados. Cada petición entra en su infraestructura, sale hacia la web y vuelve con contenido que después debe entregarse al cliente. En una nube con facturación por gigabyte de salida, ese patrón convierte el crecimiento en una penalización: cuanto más se usa el servicio, más pesa el coste de egress.
El caso publicado por DataPacket resume bien la paradoja. Las cargas de IA suelen vivir en AWS, Google Cloud o Azure. Sin embargo, la capa de acceso web que las alimenta puede estar en otro sitio. Si esa capa está lejos, cada llamada paga distancia en latencia. Si además está dentro de un proveedor que cobra el tráfico saliente por gigabyte, también paga crecimiento en factura. Massive ha intentado resolver ambos problemas colocando su infraestructura cerca de los grandes clouds, pero fuera de su modelo de precios por egress.
Por qué el acceso web para IA castiga tanto el tráfico saliente
El negocio de Massive es intensivo en red por diseño. Sus clientes apuntan peticiones a network.joinmassive.com, y la plataforma las enruta a través de una red global de millones de dispositivos voluntarios y con consentimiento en más de 195 países. El objetivo es obtener páginas en tiempo real, contenido renderizado y resultados de búsqueda desde ubicaciones reales.
En ese tipo de servicio, el ancho de banda no es un detalle secundario. Es el producto en movimiento. Un agente de IA que necesita consultar una web, extraer datos, leer una página renderizada o analizar resultados de búsqueda no consume solo CPU. Consume red, latencia, estabilidad y capacidad de respuesta.
DataPacket plantea tres motivos por los que una arquitectura basada en grandes nubes podía ser problemática para Massive. El primero son las tasas de egress: cada byte servido hacia fuera genera coste. El segundo es que muchos sitios objetivo también están alojados en grandes clouds, lo que puede crear rutas cloud a cloud con penalizaciones y saltos innecesarios. El tercero es la previsibilidad: una plataforma de acceso web vive o muere por su latencia p99, y los entornos virtualizados compartidos pueden introducir variabilidad.
| Métrica del caso Massive | Resultado comunicado |
|---|---|
| Latencia media hacia grandes clouds | 2 ms |
| Picos de tráfico absorbidos | 20 Gbps |
| Ahorro anual estimado frente a egress cloud | 2,9 millones de dólares |
| Países servidos por la red de Massive | Más de 195 |
| Tasa de éxito en primer intento | 99,8 % |
| Tiempo medio de respuesta | Menos de 600 ms |
| SLA de uptime | 99,9 % |
| Crecimiento del negocio citado | 4-5 veces interanual |
La diferencia clave está en el modelo de costes. En un cloud tradicional, una plataforma intensiva en transferencia puede ver cómo su factura escala con el tráfico. En bare metal dedicado con planes de ancho de banda más previsibles, la empresa añade servidores y capacidad, pero no paga una tasa variable por cada gigabyte servido de la misma manera. Para una compañía que crece entre 4 y 5 veces al año, esa diferencia puede decidir si el margen mejora o se erosiona.
Bare metal, peering directo y menos distancia hasta el cloud
Massive ejecuta su infraestructura de acceso web sobre bare metal dedicado en cuatro ubicaciones de DataPacket seleccionadas por su conectividad directa con grandes proveedores cloud. La lógica es sencilla: si muchos clientes de Massive ejecutan sus cargas de IA dentro de AWS, GCP o Azure, y muchos destinos web también viven en esos entornos, estar a pocos milisegundos de esos puntos reduce la fricción de cada petición.
La infraestructura descrita por DataPacket combina servidores AMD EPYC recientes, almacenamiento NVMe, memoria DDR5, enlaces 2x25GE no compartidos por servidor y tráfico agrupado por región para gestionar ráfagas con más eficiencia. El modelo de ancho de banda se basa en percentil 95, descartando el 5 % más alto de las muestras de tráfico, lo que resulta habitual en servicios de red de alto volumen.
El peering privado directo con grandes clouds es una pieza central. En vez de enviar todo el tráfico por la internet pública, parte de esas rutas pueden mantenerse en caminos privados, más cortos y predecibles. Para un servicio que promete respuestas rápidas a agentes de IA, dos milisegundos de media hacia grandes clouds no son un dato de marketing menor. Son parte de la experiencia final.
| Capa de infraestructura | Enfoque en el caso Massive |
|---|---|
| Cómputo | Servidores bare metal dedicados |
| Procesadores | AMD EPYC |
| Almacenamiento | NVMe |
| Memoria | DDR5 |
| Red por servidor | 2x25GE no compartidos |
| Facturación de tráfico | Percentil 95, sin coste por GB saliente |
| Conectividad cloud | Peering privado directo con grandes proveedores |
| Operación | Soporte con ingenieros de red en Slack privado |
También hay una cuestión de control. Desplegar en bare metal exige más trabajo inicial que pulsar «deploy» en un hiperescalares. Hay que planificar capacidad, regiones, red, monitorización, automatización y operación. Pero a cambio se obtiene hardware dedicado, rutas conocidas, costes más estables y menos exposición a sorpresas de tráfico saliente.
Tres APIs sobre la misma base física
El caso de estudio identifica tres productos principales de Massive que comparten esta base de infraestructura. Web Access API ofrece acceso proxy a cualquier sitio de internet, con soporte HTTPS, HTTP y SOCKS5, usando la red de dispositivos reales en más de 195 países. Web Render API añade renderizado completo con ejecución de JavaScript y capacidades orientadas a entregar HTML renderizado o Markdown preparado para consumo por modelos de lenguaje. Web Search API proporciona resultados estructurados de Google SERPs, con resultados orgánicos, AI Overviews, preguntas frecuentes y sitelinks, geolocalizados desde ubicaciones reales.
La infraestructura no es el producto visible, pero define si el producto es viable. Si cada llamada de un cliente genera un coste variable elevado, el servicio se vuelve más difícil de escalar. Si cada ruta añade latencia, los agentes que dependen de esa información responden peor. Y si los picos de tráfico se castigan con costes inesperados, la planificación financiera se vuelve más frágil.
Jason Grad, consejero delegado y cofundador de Massive, lo resume en el caso con una idea muy directa: escalar cargas de acceso web con precios de egress puede volverse caro con rapidez. Con DataPacket, afirma, la compañía obtiene el throughput que necesita y sabe lo que pagará cada mes. En otro comentario, añade que si Massive estuviera sobre un hiperescalares, su factura de infraestructura crecería al mismo ritmo que el negocio.
Esa frase explica por qué este caso importa más allá de Massive. Muchas empresas de IA están descubriendo que la nube pública es excelente para empezar, probar, desplegar y escalar de forma rápida, pero no siempre es la opción más eficiente para cargas con un patrón muy intensivo en red. Cuando el producto consiste en mover datos, el coste de mover datos se convierte en estrategia.
Una lección para infraestructuras de IA
El caso Massive-DataPacket no significa que el bare metal sea mejor para todo. Los hiperescalares siguen siendo una opción poderosa para servicios gestionados, elasticidad, bases de datos, analítica, entrenamiento, despliegues globales y equipos que necesitan velocidad operativa. Pero sí muestra una lección importante: en IA, no todas las capas deben vivir necesariamente dentro del mismo cloud.
La capa de acceso web, proxy, scraping, renderizado o búsqueda puede beneficiarse de una infraestructura dedicada con ancho de banda predecible y baja latencia hacia los clouds donde viven los agentes. Es un patrón híbrido: los modelos y aplicaciones pueden estar en AWS, GCP o Azure, mientras una capa de red especializada se ejecuta en bare metal cerca de ellos.
Para empresas que construyen agentes, crawlers, pipelines de datos o sistemas RAG con acceso frecuente a contenido externo, esta arquitectura merece atención. No basta con preguntar cuántas GPUs se necesitan. Hay que preguntar cuánto tráfico saldrá, cuánto costará, qué latencia habrá hacia los proveedores cloud, cómo se gestionarán los picos y qué margen quedará cuando el uso crezca.
Massive ha elegido una respuesta clara: pagar por infraestructura dedicada y ancho de banda predecible antes que asumir una tasa variable por cada gigabyte. En un negocio que mueve contenido web en tiempo real para IA, esa decisión no es una optimización menor. Es parte del producto.
Preguntas frecuentes
¿Qué problema resolvió Massive con DataPacket?
Massive buscaba una infraestructura capaz de mover grandes volúmenes de tráfico web para agentes de IA sin que el coste por egress de los hiperescalares castigara su crecimiento.
¿Qué ventajas obtuvo con bare metal dedicado?
Según el caso de estudio, obtuvo 2 ms de latencia media hacia grandes clouds, capacidad para absorber picos de 20 Gbps sin coste adicional y un ahorro anual estimado de 2,9 millones de dólares frente a precios equivalentes de egress cloud.
¿Por qué el egress es tan importante en servicios de IA?
Porque muchos agentes y pipelines necesitan leer, renderizar y devolver grandes volúmenes de contenido. Si cada gigabyte saliente se factura de forma variable, el crecimiento puede reducir el margen.
¿Significa esto que el bare metal es mejor que la nube pública?
No siempre. La nube pública sigue siendo muy útil para muchas cargas. El caso muestra que, para servicios intensivos en tráfico y baja latencia, una arquitectura bare metal con buen peering puede ser más predecible y rentable.
