Fly.io ahora tiene GPUs
Fly.io ha introducido máquinas virtuales con GPUs y facturación con escalado a cero, con la intención de facilitar la ejecución de cargas de trabajo de IA bajo demanda junto con las apps ya alojadas en Fly. Los comentaristas examinan si los precios y los costes de arranque en frío (carga del modelo, imágenes grandes, volúmenes) compiten bien con alternativas como DigitalOcean, Runpod y Vast.ai, y debaten cuán útil es realmente la inferencia GPU “en el borde” para cargas típicas de LLM e imágenes. Una preocupación recurrente es la fiabilidad y la madurez del soporte de Fly.io para producción, aunque algunos usuarios reportan experiencias fluidas y señalan funciones complementarias como un almacenamiento compatible con S3 en desarrollo y un control flexible del ciclo de vida de las VMs.
Precios y competencia
- Muchos consideran que los precios de GPU de Fly son altos en comparación con algunos competidores (DigitalOcean, AWS, varias startups de GPU de “race-to-zero”), especialmente sin compromisos a largo plazo.
- Otros señalan que el suministro de GPU bajo demanda es escaso en todas partes; los precios “más baratos” que aparecen en los titulares a menudo requieren compromisos de varios años o no están disponibles en la práctica.
- Algunos comparan los costes favorablemente con plataformas como Modal y Replicate, y dan la bienvenida a más competencia en la inferencia alojada.
Rendimiento, arranques en frío y carga de modelos
- El tiempo de puesta en marcha está determinado menos por el arranque de la VM que por las imágenes de GPU y los pesos del modelo.
- Las imágenes base grandes (1–3+ GB) y la descarga de archivos del modelo pueden añadir 30–120 segundos; cargar modelos de varios GB en la VRAM es un factor importante.
- Los pesos almacenados en volúmenes NVMe locales pueden reutilizarse, reduciendo descargas repetidas; el almacenamiento remoto o de estilo red para modelos se considera una mala idea por varios comentaristas.
Escalado a cero y comportamiento de “mantener caliente”
- La facturación comienza cuando una máquina arranca y termina cuando se detiene, sin mínimo obligatorio.
- Las máquinas escalan hacia abajo saliendo con el código 0 bajo la política de reinicio correcta; “mantener caliente” se implementa en el código del usuario mediante salida retardada o lógica personalizada.
- Opciones de ejecución como señales de terminación y tiempos de espera dan cierto control sobre el comportamiento de apagado.
Casos de uso objetivo y mercado
- Entre los usuarios previstos están las apps existentes de Fly que necesitan GPUs, personas que construyen plataformas de hosting/IA, y cargas de trabajo que se benefician de ráfagas ocasionales de GPU y de la economía de escalado a cero.
- Algunos cuestionan el tamaño del mercado de “necesita GPU pero también necesita escalado a cero” y si la inferencia en GPU en el borde difiere de forma significativa de la inferencia estándar en centros de datos.
Infraestructura y virtualización
- Las VMs con GPU usan Cloud Hypervisor (no Firecracker) con passthrough PCI, no vGPU.
- Operativamente, Cloud Hypervisor y Firecracker se describen como similares desde la perspectiva de Fly.
Fiabilidad y preocupaciones de soporte
- El hilo contiene un fuerte desacuerdo: algunos informan de un uso fluido durante varios meses o un año; otros describen Fly como “no listo para producción” con caídas, despliegues inestables, máquinas que no arrancan y soporte débil o solo en foros.
- El propio mensaje de Fly enfatiza que su oferta de Postgres no está completamente gestionada; algunos usuarios se sorprendieron y lo consideran un inconveniente.
Almacenamiento / reemplazo de S3
- La falta de un servicio compatible con S3 de primera clase fue un bloqueo para algunos.
- Varios comentarios apuntan a un reemplazo de S3 en beta e integrado con Fly (Tigris / almacén de objetos regional).
- La licencia de las alternativas S3 basadas en AGPL propuestas es motivo de controversia debido a políticas corporativas contra AGPL.