Movilidad vertical: Inferencia desde MVP hasta cargas de trabajo de un billón de parámetros — Sitanshu Gupta, CoreWeave

EspañolالعربيةDeutschEnglishFrançaisहिन्दी日本語한국어PortuguêsРусский中文
AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00Buenas tardes a todos. Soy Sitan Shu de Corvi. Hoy voy a hablarles sobre la movilidad
00:00:19vertical. Es un tema bastante elegante, el título que se nos ocurrió, pero básicamente voy a
00:00:26hablar sobre la plataforma de inferencia que tenemos en Corvi, la cual estamos construyendo para atender
00:00:30desde modelos pequeños hasta grandes y varios tipos diferentes de cargas de trabajo. Una breve presentación sobre mí, me uní a
00:00:38Corvi hace aproximadamente cuatro meses, liderando toda el área de inferencia allí. Y antes de esto,
00:00:44gestionaba todo lo relacionado con entrenamiento en AWS Annapurna Labs, y antes de eso, inferencia
00:00:49y entrenamiento en Sambanova. Así que tengo bastante experiencia en este espacio en particular. Lo que
00:00:56haré, la forma en que los guiaré, es explicándoles los modelos de consumo
00:01:00que tenemos y, a partir de eso, cómo hemos deducido cómo debería ser la plataforma para que
00:01:04no necesitemos seguir cambiando la plataforma y sigamos haciendo mejoras en la plataforma
00:01:09que tenemos para servir inferencia, y cómo y por qué el rendimiento juega un papel tan importante
00:01:14allí. Creo que un poco de esto puede ser común con el tema anterior que se discutió
00:01:20aquí. Modelos de consumo. En términos generales, tenemos dos grandes modelos de consumo. Uno es el serverless,
00:01:29que es donde los clientes pueden venir, los consumidores pueden venir, sin necesidad de preocuparse por administrar el
00:01:35hardware por sí mismos, sin necesidad de preocuparse por administrar los clústeres, la orquestación, absolutamente nada.
00:01:40Hay una API, hay una interfaz de usuario, vienes, pagas por token y obtienes tu modelo en funcionamiento.
00:01:47Lo más importante aquí es el tipo de modelos que ofrecemos en el catálogo, es decir, la variedad de
00:01:54modelos a los que el cliente podrá acceder. Hablaré de los dedicados y luego volveré a los serverless,
00:02:01porque hay algo único en el lado serverless. El servicio de inferencia dedicado que ofrecemos
00:02:05está más dirigido a clientes que quieren saber exactamente qué hardware van a utilizar y en el que van a ejecutar,
00:02:11pero el despliegue del modelo también depende de ellos. Así que utilizan nuestro servicio, utilizan nuestras capas de orquestación,
00:02:18pero el despliegue del modelo depende de ellos. El rendimiento del modelo también depende de ellos, siempre y cuando proporcionemos
00:02:25en la plataforma la capacidad y los controles para ofrecer esas características. Volviendo a serverless,
00:02:30uno de los aspectos interesantes aquí es que típicamente los modelos serverless sufren del problema del vecino ruidoso,
00:02:38donde si, digamos, todo el mundo está utilizando exactamente el mismo modelo, es posible que experimentes bastantes tiempos de espera agotados,
00:02:43dependiendo de cuánta capacidad tenga detrás. Así que otra característica que tenemos en el lado serverless
00:02:48es lo que llamamos rendimiento aprovisionado. Por lo tanto, como cliente, si conoces tu perfil de tráfico,
00:02:55y puedes informarnos al respecto, podemos reservarlo específicamente para ti,
00:03:00tras bambalinas. Aún así no tienes que preocuparte por en qué hardware exacto se está ejecutando,
00:03:04siempre que se mantengan tu rendimiento y tus acuerdos de nivel de servicio (SLA).
00:03:07Esa es otra opción en el lado serverless, y sigue cobrándose por token,
00:03:12pero sabes que no te vas a enfrentar al problema del vecino ruidoso allí.
00:03:19Permítanme echar un vistazo rápido a algunos tipos diferentes de cargas de trabajo, las formas de cargas de trabajo que tenemos,
00:03:27que estamos viendo, y la proporción entre estas cambia continuamente, aunque las de agentes
00:03:32están realmente muy arriba. Las de agentes y las de chat son bastante similares, con longitudes de secuencia de entrada
00:03:39súper altas y longitudes de secuencia de salida típicamente muy bajas. Pero la mayor diferencia entre las de agentes y
00:03:43chat radica en el hecho de que los múltiples turnos en las de agentes tienen una latencia súper baja en comparación con los chats, porque cuando
00:03:50obtienes la respuesta del usuario, tienes que leer la contestación y luego responder a ella. Así que existen
00:03:56diferencias allí. Y esa gran diferencia en última instancia se convierte en algo
00:04:01relacionado con la gestión de la caché KV. Pero ambas son de tiempo real, y otra carga de trabajo de tiempo real
00:04:09es la de voz y vídeo, que son flujos continuos y súper sensibles a la latencia. En el lado de agentes y chat,
00:04:16los requisitos son principalmente desde el punto de vista del rendimiento, no tanto de la latencia, pero la voz y el vídeo
00:04:23en tiempo real son absolutamente sensibles a la latencia. Pasando al procesamiento por lotes (batch), este es un ámbito donde los SLA son muy flexibles.
00:04:32Se extienden a segundos y minutos, y a veces, para algunos clientes, incluso a horas.
00:04:37Dicen: simplemente envíame, dame de 10 a 12 horas de capacidad de carga de trabajo y enviaré lo que pueda,
00:04:44procésalo cuando puedas. Estas cargas de trabajo por lotes entran en juego aquí
00:04:52al determinar, disculpa, al ser un requisito para algunas de las decisiones de diseño que tomamos en la pila. Imagina
00:04:59estas cuatro formas diferentes de cargas de trabajo. En la dimensión del tiempo, tienes que jugar con
00:05:04las características sobre cómo puedes ajustarlas para aprovechar al máximo la infraestructura subyacente.
00:05:12Daré una visión general de cómo está conformada nuestra pila en este momento. Y los guiaré un poco a través
00:05:19del flujo de peticiones aquí. Así que, tanto para serverless como para dedicado, si miras el lado derecho de
00:05:24la pantalla, verás que en el lado de la plataforma, irás al plano de control para gestionar tus
00:05:31autorizaciones, límites de tasa y el seguimiento de uso, etc., para que se te pueda facturar en consecuencia.
00:05:37Y la observabilidad para asegurarnos de que no estamos violando los SLA que se han firmado, ¿verdad?
00:05:45A nivel subyacente en la plataforma, he mostrado a muy alto nivel que tenemos estos diferentes
00:05:52motores de inferencia: VLLMs, SGLangs y TensorRT-LLM, pero hay bastantes detalles aquí que abordaré.
00:06:00Y subyacente a eso, lo que intento mostrar aquí en verde son varias piezas diferentes de hardware.
00:06:09Por lo tanto, la plataforma debe ser lo suficientemente capaz de compartir, de permitir que la carga de trabajo
00:06:15se distribuya entre varias generaciones diferentes de estas GPU, específicamente las GPU de NVIDIA
00:06:21que utilizamos, ¿verdad? Así que tomemos algunos ejemplos aquí. Digamos que la petición se origina en el lado
00:06:31del cliente a través de aplicaciones o notebooks, cualquiera de ellos, o a través de agentes, ¿verdad? Llega a la pasarela (gateway).
00:06:36Una vez que llega a la pasarela, entonces, como mencioné en el plano de control, pasa por autenticación,
00:06:42etc., etc., etc., y luego se dirige a serverless o dedicado. En el caso de serverless,
00:06:48será pago por token, por lo que el uso de tokens se monitoreará aquí, no los tokens exactos,
00:06:53sino solo el uso de tokens, porque mantenemos políticas de retención cero de datos (ZDR).
00:06:59Dependiendo de la multitenencia o del aprovisionamiento, si está aprovisionado, sabemos
00:07:05subyacente para el enrutador que debe entrar y apuntar a los despliegues explícitos para los clientes
00:07:12de rendimiento aprovisionado. Para los clientes multitenencia, hay despliegues separados.
00:07:17El enrutador aquí, específicamente, el enrutador es muy importante, ya que el enrutador es responsable de
00:07:26tomar decisiones de enrutamiento conscientes de la caché KV. ¿Por qué es importante? Porque, como mencioné cuando discutíamos
00:07:31los perfiles de carga de trabajo, los casos de uso de agentes suelen ser súper pesados en las longitudes de secuencia de entrada,
00:07:39y la mayor parte de la longitud de la secuencia de entrada, entre el 80 y el 90 por ciento, dependiendo de la empresa y
00:07:44de los clientes, el 80 o 90 por ciento es igual para varias peticiones diferentes.
00:07:51Por lo tanto, no tiene sentido entrar y volver a computar el pre-fill o rehacer el pre-fill para eso.
00:07:57El pre-fill consume muchísima capacidad de cómputo y es muy costoso, por eso, cuanto más puedas acceder a la caché,
00:08:04más podrás ahorrar, razón por la cual, si miras los precios de los tokens en cualquier lugar, hay un precio específico para
00:08:11los tokens de entrada y un precio mucho más económico para los tokens de entrada en caché. Así que el almacenamiento en caché se vuelve realmente importante
00:08:18aquí. La forma en que desees dividir el hardware subyacente depende totalmente de la elección en la
00:08:26plataforma y ofrecemos la capacidad de hacer cualquiera de las dos cosas: realizar una desagregación de pre-fill y decodificación si el
00:08:31caso de uso lo requiere, o no hacerlo, porque la desagregación de pre-fill y decodificación no es barata para todos los tipos de casos de uso.
00:08:41Analicemos otro flujo de peticiones aquí. Veamos qué pasa si se trata de un cliente dedicado.
00:08:48Un cliente dedicado nuevamente pasará por las pasarelas que se han configurado para ellos con el aislamiento adecuado.
00:08:55La facturación no se basa en tokens, la facturación se basa en el uso por GPU por hora.
00:09:03Es una pasarela privada para que no haya problemas de vecinos ruidosos y nadie más pueda entrar.
00:09:09Se utiliza la misma lógica de enrutador aquí para que, si hay peticiones muy similares, acierten en la caché la mayor parte del tiempo.
00:09:18Y dependiendo del despliegue que el cliente realice allí en sus GPU dedicadas,
00:09:24pueden decidir si desean realizar una desagregación de pre-fill y decodificación o no. Pueden decidir qué
00:09:29motor utilizar: vLLM, SGLang o TensorRT-LLM. Y dada la gran capacidad que el cliente
00:09:35ha reservado, pueden decidir si quieren tener un solo despliegue con la capacidad de escalar
00:09:42a través de todo el clúster o si prefieren tener múltiples modelos diferentes y varios despliegues.
00:09:47Algo que quiero mencionar sobre el enrutador aquí es el hecho de que
00:09:54la capacidad heterogénea entre diferentes zonas y regiones
00:09:59es compatible. Es un problema bastante complejo de balancear de carga.
00:10:04Por lo tanto, el orden de prioridad que solemos adoptar es primero la localidad de la caché KV y luego recurrir al menos cargado como alternativa.
00:10:16Eso es todo. Otro flujo de peticiones que quiero repasar aquí y que
00:10:21quizás sea un poco difícil de ver en el diagrama es el flujo de trabajo por lotes.
00:10:25Para el flujo de trabajo por lotes, lo que haríamos en realidad es tomar la capacidad subyacente que tiene el cliente;
00:10:31digamos, el mismo cliente de inferencia dedicado, que durante el día en EE. UU. ejecuta sus cargas de trabajo
00:10:37en tiempo real y desde el atardecer hasta la noche quiere ejecutar cargas de trabajo por lotes; esa misma capacidad puede programarse
00:10:43para ejecutar cargas de trabajo por lotes más tarde. Por lo tanto, proporcionamos la capacidad en la API para indicar cuándo escalar vertical u horizontalmente y
00:10:51cuándo reducir la capacidad según un horario; si nos indican que podemos reducirla,
00:10:56la reduciremos y la abriremos para el procesamiento por lotes durante la noche.
00:11:05Creo que he hablado bastante sobre las optimizaciones en el lado de la caché KV, pero quiero repetirlo un poco
00:11:10porque este es uno de los aspectos más interesantes. Si podemos aprovechar más la caché, se puede
00:11:19evitarás el costo del prellenado, que es la parte más costosa de todas.
00:11:26Reutilizar la caché KV en varios turnos distintos de tus cargas de trabajo con agentes; entre turnos también
00:11:31se genera una gran cantidad de prellenado similar en la longitud de la secuencia de entrada.
00:11:38Piensa en las cargas de trabajo de chat, donde la descarga de la caché KV también se vuelve sumamente importante,
00:11:43porque en ellas tenemos mucha latencia entre los diferentes turnos múltiples
00:11:49que nosotros como usuarios realizamos. Pero si eliminamos por completo lo que teníamos en nuestra conversación en cuestión,
00:11:57la próxima vez que hagamos una pregunta en el mismo chat, tardará un poco más.
00:12:02Así que, en lugar de eliminarlo por completo y volver a hacer el prellenado, las técnicas
00:12:08que se están usando tal vez empleen... nosotros usamos las nuestras, pero externamente conocemos LM cache y Mooncakes.
00:12:17Lo que hacemos es descargar la caché KV a un almacenamiento de gran ancho de banda
00:12:21para poder almacenar una gran parte de estos prellenados, de modo que cada vez que llegue la solicitud correspondiente
00:12:28para esa conversación en particular, se pueda cargar de inmediato en la HPM.
00:12:37Sobre las palancas de rendimiento, yo... solo quiero mencionar algunas palancas de rendimiento que hemos
00:12:41analizado: la PD DSAG es una de ellas, pero la cuantización y la decodificación especulativa son otras, y cómo
00:12:48elegir cuidadosamente los grados y las estrategias de paralelización es en realidad muy importante.
00:12:54Dos de las mayores palancas con las que hemos estado trabajando son la cuantización a NVFE4 y la decodificación especulativa.
00:13:01Ofrecemos la capacidad de que, si el cliente tiene su conjunto de datos y quiere que entrenemos modelos especulativos
00:13:07para sus conjuntos de datos a fin de lograr mejores longitudes de aceptación, lo que en última instancia hará que el rendimiento
00:13:12de salida sea significativamente mayor, también contamos con ello. Pero eso ocurre de forma asíncrona. Recibimos
00:13:20los datos de forma asíncrona, entrenamos los modelos especulativos de forma asíncrona y luego los implementamos en los entornos del cliente
00:13:26si es lo que deseaban. Aquí pueden ver tres capturas de pantalla. Las he publicado a partir de
00:13:32el trabajo de este último mes que algunos de los miembros de mi equipo han realizado. Pueden ver que llegamos
00:13:39rápidamente a la cima de la tabla de clasificación en Kimi 2.6, 2.7, y esos provienen de artificial analysis;
00:13:46y volviendo a la sesión anterior, ¿podemos confiar en eso? Por eso, para GLM, tengo los resultados
00:13:52de open router. Así que artificial analysis, cuando ejecuta pruebas comparativas, utiliza cargas de trabajo muy específicas.
00:13:58Open router corresponde a tráfico real de usuarios y pueden ver en el lado de open router, weights and biases. Así que
00:14:05la marca es diferente, pero weights and biases es básicamente curvy. Compramos weights and biases
00:14:09hace aproximadamente un año. Pueden ver aquí que la velocidad que obtenemos de nuestra implementación está bastante cerca
00:14:16de lo que ofrece Fireworks como Fireworks fast, ¿verdad? Pero las técnicas subyacentes que estamos utilizando son
00:14:21lo que más quiero destacar aquí en cuanto a la optimización del rendimiento. Eso se vuelve fundamental porque
00:14:27al final lo que queremos ofrecer al cliente, lo que queremos brindarle, es un beneficio de relación precio-rendimiento.
00:14:36Breve resumen: una plataforma única es lo que he estado intentando destacar y mostrar.
00:14:44Dos modelos de consumo diferentes, serverless y dedicado para los clientes, y dentro de serverless,
00:14:49también describí dos modelos de consumo distintos: pago por uso y rendimiento provisto si te importa
00:14:53ese aspecto, y en última instancia, potenciar las ganancias mediante optimizaciones de rendimiento en la pila.
00:15:01Eso es todo. Muchas gracias a todos.

핵심 요약

La plataforma de inferencia de CoreWeave optimiza la relación precio-rendimiento combinando arquitecturas serverless y dedicadas con un enrutamiento inteligente basado en la localidad de la caché KV y técnicas avanzadas de cuantización a NVFP4.

하이라이트

  • CoreWeave ofrece dos modelos de consumo principales: serverless (pago por token) e inferencia dedicada (pago por GPU por hora).

  • El rendimiento aprovisionado en la opción serverless evita el problema del vecino ruidoso al reservar capacidad específica para el perfil de tráfico del cliente.

  • Entre el 80% y el 90% de la longitud de la secuencia de entrada en cargas de trabajo de agentes es idéntica entre distintas peticiones.

  • El enrutador de CoreWeave prioriza la localidad de la caché KV para evitar el alto coste de cómputo de la fase de prellenado (pre-fill).

  • Las optimizaciones con cuantización a NVFP4 y decodificación especulativa incrementan sustancialmente el rendimiento de salida de los modelos.

타임라인

Modelos de consumo: Serverless y Dedicado

  • El servicio serverless opera mediante cobro por token sin necesidad de gestionar la infraestructura subyacente.
  • El servicio dedicado asigna hardware específico con cobro por uso por hora de GPU.
  • El rendimiento aprovisionado elimina la latencia por vecinos ruidosos en entornos serverless.

La plataforma abarca dos enfoques principales según el control que requiera el cliente. En la modalidad serverless, los usuarios acceden a una API sin gestionar clústeres ni orquestación. Para evitar variaciones de latencia generadas por la saturación de otros usuarios en modelos compartidos, existe el rendimiento aprovisionado, el cual reserva capacidad manteniendo el esquema de cobro por token. Por otro lado, la inferencia dedicada otorga acceso a hardware específico donde el despliegue y la optimización del rendimiento quedan bajo el control directo del cliente.

Características y demandas de las cargas de trabajo

  • Las cargas de trabajo de agentes y chat requieren alta longitud de secuencia de entrada y baja longitud de salida.
  • La voz y el vídeo en tiempo real demandan respuestas hiperestrictas en términos de latencia.
  • Las tareas por lotes (batch) operan con acuerdos de nivel de servicio (SLA) flexibles de horas.

Las arquitecturas de inferencia deben adaptarse a patrones de tráfico contrastantes. Los entornos de agentes y chat exigen baja latencia en múltiples turnos conversacionales, dependiendo críticamente de la gestión de la caché KV. A diferencia del chat, las transmisiones de voz y vídeo no admiten demoras de procesamiento. Por su parte, el procesamiento por lotes permite ejecutar cargas masivas en ventanas de tiempo flexibles, como durante periodos nocturnos, optimizando el uso de la infraestructura existente.

Arquitectura de la plataforma y enrutamiento con caché KV

  • El enrutador prioriza la localidad de la caché KV para minimizar el cómputo de prellenado.
  • La plataforma admite la desagregación opcional entre las fases de prellenado y decodificación.
  • La infraestructura permite la reprogramación de GPU dedicadas para cargas por lotes fuera de horas pico.

El plano de control gestiona autenticación, límites de tasa, observabilidad y políticas de retención cero de datos (ZDR). El enrutador es la pieza central para la eficiencia: al detectar que la mayoría de los tokens de entrada en tareas de agentes son idénticos, reutiliza la caché KV para no rehacer la costosa fase de prellenado. La arquitectura soporta balanceo de carga en clústeres heterogéneos priorizando la proximidad de los datos almacenados en caché. Además, las GPU asignadas a clientes dedicados se pueden escalar o reasignar dinámicamente a tareas por lotes cuando baja la demanda en tiempo real.

Técnicas de optimización de memoria y rendimiento

  • La descarga de la caché KV a almacenamiento de gran ancho de banda conserva el contexto en pausados de chat.
  • La cuantización a NVFP4 reduce sustancialmente el impacto de memoria de los modelos.
  • El entrenamiento asíncrono de modelos especulativos eleva la tasa de aceptación de tokens.

Para evitar volver a procesar el contexto en chats con pausas entre mensajes, la caché KV se descarga a un almacenamiento de alto ancho de banda y se recarga instantáneamente en la memoria HBM del GPU al recibir una nueva petición. En cuanto al rendimiento directo, las palancas principales son la cuantización al formato NVFP4 y la decodificación especulativa. CoreWeave entrena de forma asíncrona modelos especulativos personalizados con los datos del cliente para maximizar los tokens generados por paso, alcanzando métricas competitivas en las tablas de clasificación de velocidad.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기