Noticias Generales de la Industria de la IAVigilancia de pila de inferencia

La apuesta de Infinity para destronar a CUDA: una capa universal de inferencia para cualquier chip de IA

Infinity está construyendo una pila de inferencia alternativa a CUDA que genera y ajusta automáticamente kernels de bajo nivel en diversos aceleradores, con el objetivo de hacer que el despliegue de modelos sea portátil y más económico. Con nueva financiación y socios tempranos de chips, apunta al foso de software de Nvidia y al problema de costo y capacidad que enfrentan los desarrolladores de IA.

NexusAI Editorial21 jul 20261.7K vistas9 min de lectura

La apuesta de Infinity para destronar a CUDA: una capa universal de inferencia para cualquier chip de IA

Resumen de IA

Infinity persigue una capa universal de inferencia que escribe y optimiza automáticamente kernels para que el mismo modelo pueda funcionar eficientemente en chips heterogéneos. Si funciona a escala, esto debilita la dependencia de CUDA de Nvidia al trasladar los costos de cambio del tiempo del desarrollador a la automatización de software. La ventaja estratégica: proveedores de chips y operadores de nube pueden desbloquear capacidad ociosa, y las empresas ganan apalancamiento en precio/rendimiento sin reescribir modelos. La perspectiva práctica es tokens por segundo y latencia por dólar en cargas de trabajo objetivo, no microbenchmarks. Se esperan victorias tempranas en operadores y formas de modelo específicas, con una hoja de ruta hacia mayor cobertura de operadores y determinismo. La adquisición debe tratar esto como un servicio de optimización con beneficios medibles, no como una plataforma basada en licencias.

Infinity apunta a una de las ventajas más duraderas de Nvidia: la atracción de desarrolladores de CUDA. En lugar de perseguir el silicio bruto, está construyendo una capa de software que escribe y ajusta los kernels de bajo nivel que la inferencia necesita, permitiendo que los modelos funcionen eficientemente en GPUs, aceleradores especializados y NPUs de borde. Con una nueva ronda de financiación y socios tempranos de chips, la compañía posiciona su pila como un motor de portabilidad que comprime meses de optimización manual en horas o días. La promesa no es elegancia teórica; es convertir hardware heterogéneo en capacidad práctica, reduciendo costos, latencia y dependencia de proveedores para equipos que no pueden permitirse ingeniería de kernels a medida.

Técnicamente, el enfoque de Infinity se centra en un ciclo agente que genera, prueba y mejora iterativamente variantes de kernels para operadores objetivo y grafos de modelos. Mide el rendimiento (tokens por segundo), latencia p99 y uso de memoria, luego reescribe automáticamente rutas de código para explotar la planificación, jerarquía de memoria y conjunto de instrucciones de cada chip. El producto final se asemeja a una biblioteca universal de inferencia: un registro de operadores portátiles, plantillas de kernels y heurísticas aprendidas que generalizan a través de arquitecturas. Crucialmente, el sistema apunta a la auto-optimización, adaptándose a medida que aparecen nuevos modelos, esquemas de cuantización y aceleradores, de modo que la mejora de rendimiento se acumula con el tiempo en lugar de estancarse tras las primeras victorias.

Para los compradores, la implicación es apalancamiento. Hoy, la mayoría de las pilas de inferencia predeterminan Nvidia porque las canalizaciones de PyTorch y TensorFlow están centradas en CUDA y el costo de portar es alto. Una capa creíble entre chips cambia el cálculo: los proveedores de chips pueden exponer su silicio sin forzar a los clientes a reescribir código, los proveedores de nube pueden mezclar flotas para equilibrar precio/rendimiento, y las empresas pueden probar alternativas durante crisis de capacidad. Se espera tracción temprana donde los conjuntos de operadores son más estrechos y predecibles: servicio de LLM en producción con familias de modelos estables, perfiles de cuantización y formas de lote, antes de que la paridad general con la vasta biblioteca de CUDA sea factible.

El riesgo de ejecución sigue siendo real. La portabilidad solo es valiosa cuando preserva la precisión y ofrece ganancias repetibles en tráfico de producción. Los equipos deben tratar a Infinity como un socio de optimización con SLA claros vinculados a KPIs a nivel de carga de trabajo: tokens/segundo objetivo a latencia p99 y costo por millón de tokens en hardware específico. Un piloto robusto incluye auditorías de cobertura de operadores, verificaciones de corrección con conjuntos dorados, canarios A/B y rutas de reversión. Si la mejora a nivel de modelo es significativa, la tarifa basada en ingresos ligada a la mejora de rendimiento puede ser atractiva frente a licencias fijas. Si no, CUDA sigue siendo el predeterminado. El éxito aquí se decidirá por benchmarking disciplinado, telemetría transparente y cierre rápido de la hoja de ruta de operadores.

Conclusiones clave

La portabilidad puede desbloquear capacidad

Una capa de inferencia entre chips reduce los costos de cambio, permitiendo a los equipos usar capacidad no Nvidia sin reescribir modelos, valioso durante escasez de GPU y picos de costo.

Medir de extremo a extremo, no microbenchmarks

Evaluar con tráfico similar a producción usando tokens/segundo, latencia p99 y umbrales de deriva de precisión. Las victorias de operadores solo importan si se traducen en ganancias a nivel SLA.

Adquirir por resultados

Vincular contratos a KPIs de carga de trabajo y SLA de regresión. La tarifa basada en ingresos por mejoras verificadas de rendimiento/costo puede superar licencias fijas cuando la mejora es incierta.

Cómo funciona la capa universal de inferencia

La canalización de Infinity ingiere un grafo de modelo, identifica operadores calientes y explora candidatos a kernels ajustados al hardware objetivo. Aprende estrategias de planificación (división en bloques, vectorización, coalescencia de memoria), compila variantes y las evalúa bajo tamaños de lote y longitudes de secuencia realistas. Los kernels ganadores se almacenan en una biblioteca portátil de operadores. En tiempo de ejecución, un despachador selecciona kernels óptimos según el perfil de hardware y la telemetría en vivo. Con el tiempo, la biblioteca se expande para cubrir más operaciones (atención, multiplicaciones de matrices, normalizaciones de capa, activaciones fusionadas) y modos de cuantización (INT8, FP8, precisión mixta). El resultado es un camino repetible desde el código del modelo hasta kernels eficientes para el chip sin implementaciones específicas escritas a mano por el proveedor.

Por qué esto importa ahora

La inferencia está superando al entrenamiento como el centro de costos dominante para muchos productos de IA, y la capacidad sigue siendo desigual entre nubes y centros de datos. Las empresas quieren aprovechar aceleradores alternativos, pero carecen de la experiencia en kernels para alcanzar un rendimiento cercano al del silicio. La madurez de CUDA mantiene las cargas de trabajo atadas a Nvidia incluso cuando existen opciones más baratas o con capacidad más cercana. Una capa de inferencia entre chips reduce los costos de cambio, desbloquea flotas inactivas y presiona a los proveedores en rendimiento por dólar en lugar de solo en la atención del desarrollador. Para líderes financieros y operativos, esto crea un camino más claro hacia la gobernanza presupuestaria, comparando el rendimiento total en objetivos de confiabilidad a través de hardware diverso, no solo precios de etiqueta o microbenchmarks.

Quién se beneficia y cómo pilotar

Las startups de chips ganan una vía de software hacia cargas de trabajo reales; las nubes pueden adaptarse a flotas heterogéneas; las empresas pueden diversificar proveedores sin refactorizar modelos. Un piloto pragmático: elegir dos modelos relevantes para producción (por ejemplo, un LLM sensible a la latencia y un reranker por lotes de alto rendimiento), definir criterios de aceptación (tokens/segundo a p99, costo/millón de tokens, deriva de precisión <0.1%) y probar en dos objetivos no Nvidia más una línea base CUDA. Requerir ganchos de observabilidad para atribución por operador, ejecutar corridas deterministas para verificaciones de regresión y tráfico canario durante una semana antes de escalar. El éxito se mide en puntos finales SLA, no en kernels sintéticos.

Riesgos, brechas y qué vigilar

Tres riesgos merecen escrutinio: cobertura de operadores, corrección y velocidad de mantenimiento. El ecosistema de CUDA tiene cobertura de una década y kernels altamente optimizados; igualar su amplitud tomará tiempo. La corrección debe mantenerse bajo cuantización, atención de contexto largo y operaciones fusionadas; usar conjuntos de datos dorados y tráfico sombra para detectar deriva. El mantenimiento requiere seguir arquitecturas de modelos y hojas de ruta de silicio que cambian rápidamente. La adquisición debe aclarar términos de propiedad intelectual para kernels generados, gobernanza de datos para telemetría usada en ajustes y cláusulas de salida si el rendimiento retrocede. Tratar con escepticismo las afirmaciones de “paridad con CUDA” sin evidencia de carga de trabajo de extremo a extremo en su perfil exacto de tráfico.

Recomendaciones de flujo de trabajo y métricas que importan

Adoptar un marco estándar de evaluación: unificar tokenización, agrupamiento y almacenamiento en caché entre backends; fijar precisión; y capturar telemetría por operador. Rastrear tokens/segundo, latencias p50/p95/p99, bloqueos en cola, margen de memoria y costo/millón de tokens. Usar un registro reproducible de auditoría de kernels para comparar variantes y asegurar reversión. Para velocidad de ingeniería, preferir pilas que exporten manifiestos de cobertura de operadores y soporten formatos comunes de modelos (ONNX, exportación PyTorch). Construir una RFP alrededor de cobertura mínima de operadores, garantías de determinismo, SLA de regresión y cadencia de hoja de ruta. Priorizar chips donde los kernels tempranos entreguen ganancias desproporcionadas, luego expandir cobertura una vez probada la confiabilidad y automatización.

Preguntas frecuentes

¿Cómo deberíamos evaluar Infinity frente a una línea base CUDA?

Seleccionar dos modelos relevantes para producción, fijar precisión y formas de lote, y ejecutar pruebas A/B/C entre CUDA y dos objetivos no Nvidia. Requerir manifiestos de cobertura de operadores, verificaciones de corrección con conjuntos dorados y una semana de tráfico canario. Decidir según tokens/segundo a p99 y costo/millón de tokens, no microbenchmarks de kernels.

¿Qué términos contractuales reducen el riesgo si el rendimiento retrocede?

Usar precios basados en resultados vinculados a KPIs verificados de carga de trabajo, incluir derechos de reversión, requerir registros de auditoría de kernels y garantías de determinismo, y establecer SLA de regresión con créditos. Asegurar claridad en propiedad intelectual para kernels generados y manejo de datos de telemetría de rendimiento.

¿Esto puede ayudar en el borde con CPUs o NPUs?

Sí, si la cobertura de operadores y kernels conscientes de memoria coinciden con las limitaciones de su dispositivo. Pilotar con su esquema exacto de cuantización y longitudes de secuencia, verificar estabilidad térmica bajo carga y establecer objetivos de latencia por clase de dispositivo antes de comprometerse con despliegues grandes.