HN lo muestra: conexión virtual a GPU a través de TCP

• A diferencia de CPU, almacenamiento, redes y memoria, las GPU todavía no se han virtualizado como un recurso abundante, y Thunder Compute busca resolverlo en la capa de sistema
• El enfoque para ampliar la oferta no está solo en fabricar más chips, sino también en el aprovechamiento por software para usar mejor las GPU ya desplegadas
• Mientras que las optimizaciones existentes se han quedado en la capa de carga de trabajo, como el procesamiento por lotes para inferencia o el encolado de trabajos de entrenamiento, la virtualización de GPU apunta a un área de sistemas relativamente menos atendida
• Es posible usar NVIDIA H100 desde $1.38 por hora en VS Code, CLI y navegador, y se destaca un ahorro del 80% frente a AWS, sin contratos, sin costos de egress y con almacenamiento escalable
• Tras 4 años en modo sigiloso, desarrollaron un prototipo de investigación y buscan desplegar mejoras en la capacidad de GPU de los centros de datos a través de su propia nube y socios empresariales

---

Mejorar la baja utilización con virtualización de GPU

• Thunder Compute considera que varios recursos escasos de la computación eventualmente se volvieron abundantes, pero que las GPU aún no han pasado por esa misma transición
• Hacer abundantes las GPU no depende solo de producir más chips, sino también del software para aprovechar mejor los chips ya instalados
• Actualmente, las GPU suelen estar subutilizadas, y las soluciones existentes se han enfocado principalmente en la capa de carga de trabajo
  • Procesamiento por lotes de solicitudes de inferencia
  • Encolado de trabajos de entrenamiento entre varias flotas de servidores
• CPU, almacenamiento, redes y memoria ya adoptaron ampliamente la virtualización, pero las GPU aún no alcanzan ese mismo nivel
• Abordar ese espacio vacío en la capa de sistema es el enfoque central de Thunder Compute

Enfoque del producto y plan de despliegue

• Thunder Compute se presenta como un laboratorio de sistemas con enfoque comercial, que busca llevar la investigación más reciente en virtualización de GPU a entornos de producción
• El equipo dice estar formado por especialistas en infraestructura e investigadores de sistemas provenientes de Citadel Securities, Aquatic y AWS
• Durante 4 años en modo sigiloso construyeron un prototipo de investigación, y ahora están desplegando sus resultados a través de su propia nube y socios empresariales
• Según la descripción del producto, NVIDIA H100 está disponible desde $1.38 por hora
  • Se puede acceder desde VS Code, CLI y navegador
  • Prometen un ahorro del 80% frente a AWS
  • Ofrecen sin contratos, sin costos de egress y con almacenamiento escalable
• El objetivo es mejorar de forma gradual la capacidad de GPU en los centros de datos

[GN⁺]

Opiniones en Hacker News

• Bastante interesante. Hace tiempo necesité GPU-over-IP solo para transcodificación de video.
  Mi servidor de homelab tenía una GPU AMD poco potente que hacía crashear el kernel cada vez que intentaba codificar video, y mi PC gamer tenía una NVIDIA RTX 3080. Así que hice https://github.com/steelbrain/ffmpeg-over-ip, corrí el servidor en la máquina Windows y el cliente en el servidor de medios (Plex, Emby, Jellyfin, etc.), y funcionó perfecto.

  • Si todavía no lo publicaste en Show HN, estaría bueno considerarlo.
    https://gist.github.com/tzmartin/88abb7ef63e41e27c2ec9a5ce5d...
    https://news.ycombinator.com/showhn.html
    https://news.ycombinator.com/item?id=22336638
  • Por el título, esperaba algo más o menos así. Me decepcionó que el envío real fuera un servicio cloud de pago y no una herramienta general útil; como siempre, lo realmente interesante estaba en los comentarios.
    También me da curiosidad si hay usos para GPU-over-network además de la codificación de video. Con más latencia, creo que sería difícil para machine learning o tareas gráficas intensivas.
  • Interesante. Me pregunto si también soporta conversiones de múltiples archivos, como en HLS, donde se generan varios archivos por segmentos de tiempo.

• Si esto opera en la frontera CPU/GPU, me confunde si no genera un enorme cuello de botella de entrada/salida con datasets que no entran en la VRAM.
  Quizá estoy entendiendo mal cómo funciona, pero si intercepta la E/S de la GPU, suena a que en cada época habría que streamear todo el dataset a la máquina remota, lo cual parece un desperdicio.

  • Tu comprensión del sistema es correcta. Para hacerlo práctico implementamos varias optimizaciones que reducen el costo de E/S.
    El rendimiento de inferencia de BERT se puede ver aquí: https://youtu.be/qsOBFQZtsFM?t=69
    El entrenamiento tiene más overhead que la inferencia, y estamos implementando optimizaciones adicionales para acercarnos al rendimiento nativo.

• Para quienes tengan curiosidad por cómo funciona en realidad, parece una arquitectura donde inyectan una librería en el proceso, hacen hooking de estas funciones[1] y luego las envían al servicio.
  [1] https://pastebin.com/raw/kCYmXr5A

  • Me pregunto cómo descubrieron que esas funciones estaban hookeadas. Supongo que hay algún flag de ld/ldd que indica qué símbolos se vuelven a enlazar.
    También pensaba que, para que un símbolo se vuelva a enlazar, tenía que ser un símbolo débil, pero no creo que NVIDIA exponga símbolos débiles, así que supongo que esto básicamente significa que es un enfoque tipo LD_PRELOAD.
  • Esperaba que hubiera alguna forma mágica de pasar todo el dispositivo PCIe.

• Interesante, pero lo que más me interesa es el self-hosting. Ya tengo muchas GPU; algunas están en uso y otras ociosas.
  Me pregunto si hay una opción de self-hosting para poder usar las GPU que ya tengo.

  • Todavía no soportamos self-hosting, pero creemos que la misma tecnología encajaría bien.
    Ventajas como la programación eficiente de trabajos, compartir GPU y la facilidad de uso también se aplicarían tal cual a entornos self-hosted. Estamos totalmente abiertos a explorar esta posibilidad en el futuro.
  • Si querés una experiencia de uso similar a PyTorch sobre tus propias GPU, ya sea hardware fijo o cloud, mirá https://github.com/run-house/runhouse.
  • Si querés una buena experiencia de desarrollo usando tus propias GPU o cuentas cloud, mirá SkyPilot.
  • Podés alquilar tus GPU en la nube con servicios como Akash Network, y también podés alquilar GPU en thundercompute.com. Es más bien una ruta de administración cercana a operarlo casi como self-hosting.

• No termino de entender. Podés levantar directamente en ECS la instancia con GPU que quieras, así que no entiendo por qué habría que levantar una instancia en ECS para usar las GPU de ustedes desde ECS.
  Aparte, tampoco veo por qué alguien querría usar un Nitro a medias en vez de Nitro de verdad.

  • Buen punto. Hay algunas ventajas.
    Si seguís desarrollando algo que necesita GPU, normalmente tenés que pagar por todo el tiempo que la instancia está encendida. Con Thunder pagás solo mientras realmente usás la GPU. Cuando ejecutás solo código CPU, no incurrís en costo de tiempo de GPU. La alternativa es encender y apagar manualmente la instancia, pero puede ser engorroso.
    Además, podés escalar fácilmente el tipo y la cantidad de GPU que usás. Por ejemplo, si estás desarrollando en una instancia T4 barata y después querés correr un trabajo completo de entrenamiento de deep learning en 8 A100, podés ejecutar un solo comando y correrlo enseguida en GPU más potentes, sin cambiar de instancia ni volver a configurar el entorno.
  • Desde el punto de vista del sistema, parece más transparente. Por ejemplo, si usás una aplicación GUI que necesita aceleración por GPU (Matlab, SolidWorks, Blender) desde un cliente liviano, podrías hacerlo sin configurar ECS.
    Podés desarrollar sin GPU y, cuando corrés una simulación, conectar una GPU de golpe; además, parece que sería mucho más barato que AWS. En esencia, parece resolver de una forma más general el problema que resuelve Ray(https://www.ray.io/). También podría permitir un GPU sharing más granular, como media GPU, así que me entusiasma bastante.

• Como hay mucho interés en esto, decidimos abrir gratis instancias T4. Estaría bueno que las prueben y nos cuenten qué opinan.

  • Me da curiosidad cuáles son los precios de A100 y H100.

• Muy bueno. Me pregunto si podrían haberlo hecho funcionar también con MIG o vGPU.

  • No lo probamos con MIG ni vGPU, pero como en esencia son formas de particionar físicamente la GPU, creo que funcionaría.
    Uno de nuestros objetivos principales para el futuro cercano es permitir compartir GPU. Como no limitaríamos a los usuarios a una parte de la memoria y les permitiríamos usar toda la memoria de la GPU, podría ser mejor que MIG o vGPU.

• Me pregunto cómo se siente usarlo de verdad con un throughput significativo. ¿También sirve para crackeo de hashes?
  Cada vez que pienso en una GPU virtual a través de la red, se me viene a la mente una botnet. En especial el pasaje de https://www.hpcwire.com/2012/12/06/gpu_monster_shreds_passwo...: “Gosney primero tuvo que convencer al profesor Amnon Barak, cofundador de Mosix, de que no estaba ‘intentando convertir el mundo en una botnet gigante’”.

  • Es un experimento mental interesante, pero en la práctica nuestro sistema se parece más a AWS que a una botnet, porque las GPU no están distribuidas.
    Esta tecnología tiene aplicaciones interesantes para crear clústeres muy flexibles dentro de un datacenter, y estamos explorando ese camino.

• Los ingenieros originales de SGI que desarrollaron glx lo diseñaron con mucho cuidado para usar los mecanismos de X11 para transmitir a la GPU, así que era bastante sencillo enviar un stream GL por la red y renderizarlo en mi tarjeta gráfica.
  Era algo como “ejecutarlo en la supercomputadora al final del pasillo y renderizarlo en la estación de trabajo”. El desarrollo reciente de drivers no parece tener ese tipo de consideración, así que normalmente ya no es posible. No sé qué tan útil era realmente. Por lo general, si tenías una buena tarjeta gráfica, también tenías una buena CPU. Aun así, era divertido para experimentar, y había algo curiosamente atractivo en que un programa corriendo en la sala de máquinas pudiera obtener gráficos acelerados. Una vez logré correr glquake de esa manera.

• Es impresionante que esto sea posible, pero me pregunto qué pasa cuando la conexión de red se corta o no es 100% estable.
  En mi experiencia, los drivers reaccionan mal incluso cuando una GPU local se comporta apenas de forma extraña.