- Se añadió soporte para GPU a Fly.io, que ejecuta apps cerca de los usuarios, lo que permite ubicar la inferencia de IA cerca del edge en lugar de en una región central
- Las apps pueden usar Nvidia A100 para aprovechar CUDA y una gran cantidad de VRAM; sirve para reconocimiento de voz, segmentación de texto, resumen de artículos, generación de imágenes y ejecución de modelos de asistencia para código
- Las apps GPU basadas en Ollama pueden desplegarse indicando
vm.size = "a100-40gb" y la imagen ollama/ollama en fly.toml, y luego usando fly apps create y fly deploy
- En las regiones con soporte para GPU, se puede ejecutar el mismo programa con la misma IP pública y el mismo certificado TLS, y escalarlo a la región de Amsterdam con algo como
fly scale count 2 --region ams
- A100 40GB cuesta $2.50 por hora, A100 80GB $3.50, y L40s $2.50; si se configura inicio y detención automáticos, se puede evitar la facturación por horas de GPU cuando no hay solicitudes
Ejecución con GPU desplegada cerca del usuario
- Fly.io es una nube que permite ejecutar apps full-stack o plataformas de desarrollo basadas en la API de Fly Machines cerca de los usuarios, y ahora añade ejecución con GPU
- Las GPU de Fly.io permiten conectar una Nvidia A100 a una app para aprovechar CUDA y más VRAM que una 4090 local
- Los trabajos de IA/ML que aplican incluyen los siguientes
Despliegue de apps GPU con Ollama
- Fly.io busca que los usuarios desplieguen sus modelos preferidos y el código que escriben directamente sobre el backbone en la nube de Fly.io
- Las apps GPU basadas en Ollama pueden ejecutarse solo con la configuración de
fly.toml y los comandos de despliegue
app = "sandwich_ai"primary_region = "ord"vm.size = "a100-40gb"- La imagen de build es
ollama/ollama
- Monta un volumen de
100gb en /root/.ollama
- El comando de ejecución es el siguiente
fly apps create sandwich_ai && fly deploy
Inferencia realizada cerca de la región
- El punto que destaca Fly.io no es solo ofrecer GPU, sino la inferencia en el edge
- La app de ejemplo funciona así: el usuario ingresa los ingredientes que tiene en la cocina y recibe una receta de sándwich
- Si se despliega con
primary_region = "ord", los usuarios cerca de Chicago pueden recibir rápido la receta de sándwich
- Los usuarios fuera de Chicago, por ejemplo en Amsterdam, pueden tardar más porque la solicitud tendría que cruzar el Atlántico
- En las regiones con soporte para GPU, se puede ejecutar el mismo programa con la misma IP pública y el mismo certificado TLS
- La expansión a Amsterdam se realiza con el siguiente comando
fly scale count 2 --region ams
GPU solo cuando hay solicitudes
- Las GPU son dispositivos de procesamiento paralelo muy potentes, pero no son baratas, así que para apps pequeñas conviene una configuración donde solo se paga cuando hay solicitudes de usuarios
- En la sección
services de fly.toml se puede configurar el inicio y la detención automáticos
[[services]]
internal_port = 8080
protocol = "tcp"
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0
auto_stop_machines = true y auto_start_machines = true hacen que la máquina se detenga cuando no hay solicitudes y vuelva a iniciar cuando haga falta- Si
min_machines_running = 0, no se incurre en costos por tiempo de GPU cuando no hay solicitudes de recetas de sándwich
GPU disponibles y recursos base
- Las GPU están disponibles en varias regiones de EE. UU. y la UE, además de Sydney
- Los destinos de despliegue y precios son los siguientes
- Las apps desplegadas en GPU usan por defecto 8 núcleos de CPU AMD EPYC
- Se pueden adjuntar volúmenes de hasta 500GB
- También pueden ofrecer descuentos para instancias reservadas y hosts dedicados
1 comentarios
Comentarios de Hacker News
Me pregunto si Fly realmente tiene bien cubiertas las funciones básicas. Al usarlo en producción, me decepcionó ver que el equipo de soporte ni siquiera podía consultar problemas de la plataforma interna, y los mensajes de error eran ambiguos o directamente inexistentes
Puede parecer atractivo para quienes le tienen miedo a Kubernetes o no lo conocen bien, pero después de usar Fly terminé extrañando Kubernetes
watch -n 2 curldurante el despliegue, y pasaba con cualquier estrategia documentada, incluida blue-greenIncluso en el peor caso esperaba que solo se cerraran anticipadamente las conexiones existentes y que las nuevas no se cortaran, y en el mejor caso que esperara elegantemente a que terminaran las conexiones activas, pero en realidad siempre era una transición con downtime total. Viendo la topología de red que mostraron en el blog, da la impresión de que desde el principio no podía implementarse bien
Rara vez dejo comentarios negativos sobre un servicio, pero incluso después de enviar evidencia en video, el soporte respondió como si nosotros fuéramos los raros, y eso resulta bastante molesto tratándose de una empresa de infraestructura. Ya no lo recomendaría para nada más que apps de juguete
También llegué a construir un sistema de despliegue bastante grande para Kubernetes, así que no lo digo por no conocer Kubernetes. Claramente hay espacio para un despliegue estilo Heroku bien hecho, pero nadie lo está haciendo bien, o los recursos de cómputo son absurdamente limitados o caros
Podría decir más, como la base de datos no administrada disfrazada de administrada y los downtime aleatorios, pero me fui hace unos meses porque no era un servicio listo para producción
Al principio tenía muchas expectativas con Fly e incluso construí un orquestador completo sobre Fly Machines, pero tuvieron una caída de varios días y también tardaron varios días en responder
Kubernetes puede ser complejo, pero al menos esa complejidad se puede controlar y es un camino ya muy probado
Soy el autor del post y trabajo en relaciones con desarrolladores en Fly.io. Si tienen preguntas, puedo responderlas. Las GPU se lanzaron oficialmente ayer y, si el dios de los algoritmos antifraude lo permite, pueden experimentar todo lo que quieran con ellas
Más bien me sorprende que aquí no haya pegado tanto una guía que escribí sobre qué son realmente las “GPU”: https://fly.io/blog/what-are-these-gpus-really/
¿La ventaja del nodo de proceso y el acceso preferente a SoC/HBM se mantendrán el tiempo suficiente como para que el software los alcance? El hardware Metal avanzado parece caro, pero se ve distinto comparado con NVIDIA cuando tienes un ancho de banda de memoria bastante alto en el rango de 64GB+ y unidades vectoriales FP dedicadas
Si una plataforma como
fly.iopermite mover cargas de inferencia dentro y fuera del dispositivo, podría dar mucha flexibilidad a aplicaciones con un fuerte componente edgeEn un flujo de trabajo de segmentación de imágenes médicas, un archivo tarda unos 5 minutos
Hasta donde sé, Fly usa Firecracker en sus VM. Llevo tiempo siguiendo Firecracker y también lo usé en un proyecto, pero básicamente no soporta GPU ni hay planes de que lo haga [1]
Me da curiosidad cómo resolvió Fly su soporte de GPU usando Firecracker. Antes publicaban artículos técnicos muy detallados sobre cómo implementaban ciertas funciones, así que estaría bueno que más adelante saliera uno sobre el soporte de GPU
[1]: https://github.com/firecracker-microvm/firecracker/issues/11...
Está buenísimo que pueda manejar escalado hasta 0. Es especialmente útil para trabajar en sitios experimentales con pocos usuarios, donde cuesta justificar incluso el costo de un servidor pequeño
Estaría bueno ver un ejemplo de cuánto tiempo facturan por una sola solicitud. Obviamente variará, pero me pregunto si serían 2 segundos o algo como “mínimo 60 segundos por spin-up”
En las máquinas con GPU, dependiendo del tamaño de los datos que entren en la memoria de la GPU, puede hacer falta alrededor de 30 segundos de ejecución para que empiecen a ser útiles
Adopté Fly.io al principio, pero no estaba listo para producción. Antes de agregar funciones nuevas, deberían arreglar lo básico
Requiere un poco más de configuración y también es bastante más caro, pero en producción se necesita estabilidad. No puedes permitir que los clientes te llamen por caídas del servicio
El software puede fallar, pero la actitud de Fly ante los incidentes es poco profesional e inmadura. Básicamente estás pagando 10 veces más por un servicio inestable que solo se ve “bien”
Ahora uso Hetzner + Kamal con hardware mucho mejor por una cuarta parte del costo, funciona de forma estable, el precio es predecible y no pasa que el próximo mes pague 25% más por el mismo uso
https://news.ycombinator.com/item?id=36808296
Aparte del anuncio de GPU, ojalá Fly tuviera un servicio alternativo a S3. Ahora sugieren un proyecto GNU Affero, y eso es una traba para las empresas
Si por almacenar los activos de los usuarios tienes que salir de Fly, entonces se vuelve difícil usar Fly en el siguiente proyecto. Es una lástima, porque me gustan su simplicidad, su relación costo-beneficio y la VPN integrada
También se habla aquí: https://benhoyt.com/writings/flyio-and-tigris/ y aquí: https://news.ycombinator.com/item?id=39360870
https://fly.io/docs/reference/tigris/
Si accedes a un servicio tipo S3 solo mediante una API HTTPS, eso no hace que tu código quede sujeto a la AGPL
flyctly corre sobre la infraestructura de Fly.io: https://benhoyt.com/writings/flyio-and-tigris/Me pregunto quién es el mercado objetivo de este servicio. ¿Apps pequeñas y no validadas que necesitan correr algún modelo de IA, pero no usan o no pueden usar alguna de las muchas startups ultra competitivas en precio que ofrecen hosting de modelos open source?
Como alguien que ha operado muchos modelos y mucho hardware directamente, entiendo el deseo de controlar hasta el metal. Pero me gustaría saber a quién apuntan exactamente
En la práctica, la inferencia en sí tarda tanto que tal vez esa diferencia no importe mucho
Puede ser una gran ventaja que el cómputo de GPU esté en el mismo datacenter o al menos en el mismo proveedor cloud. No ha sido raro que se agoten las A100 en varios proveedores, y eso me pasó varias veces incluso con proveedores grandes. Si no estás atado a una región específica, eso es menos problemático
No todos los proveedores ofrecen un modelo usable de scale-to-zero bajo demanda. No sé qué tan bien funcione eso en Fly a largo plazo, pero también podría ser otra ventaja
Las startups que compiten por precio tienden a no durar mucho, casi como un esquema donde sobreviven poquísimas de cada 100
Si ya usas Fly y solo estás evaluando algunas demos técnicas privadas, las GPU de Fly podrían ser la opción predeterminada sin pensarlo demasiado. Aunque también puede ser más común irse por los servicios de Hugging Face
Muchas empresas no pueden operar su propio hardware por varias razones, y en el mejor de los casos solo pueden rentar racks en otro datacenter, lo cual no siempre vale la pena para casos de uso pequeños. A veces necesitas una A100, pero solo la corres de forma esporádica, como para análisis semanales, y si es menos de una hora por semana, quizá un servicio de competencia por precio no resulte tan atractivo
Tanto el ejemplo de recetas como casi cualquier caso de uso de LLM parecen ejemplos muy malos para enfatizar la inferencia en el edge. Porque da casi lo mismo si la latencia de ida y vuelta aumenta unos cientos de ms
Pero como es un área con alto potencial de abuso, parece que nadie quiere meterse todavía. Probablemente lo traten en la próxima publicación, y si es así, tendrían que construir su propio GPT en línea estilo Perplexity. Por ahora parece una introducción deliberadamente genérica para ver si surgen otras ideas
Me pregunto si alguien ya probó el rendimiento. A primera vista parece bastante caro. Por ejemplo, comparado con una máquina CPU de Hetzner.
Incluso una H100 se puede conseguir más barata que este precio, a 2.24 dólares la hora.
Por eso parece algo caro, aunque también podría ser porque la demanda de clientes es alta y la oferta es limitada.
Estoy usando el tier gratuito de Fly.io para correr Uptime Kuma y monitorear el tiempo de actividad. Funciona increíblemente bien y estoy muy satisfecho.