Inferencia de LLM — pasado, presente y futuro: ¿hacia dónde se mueve el valor?
Durante los últimos dos años, la inferencia de LLM ha sido una de las capas más disputadas en la infraestructura de IA. Decenas de proveedores de inferencia, nubes de GPU, proyectos de código abierto y fabricantes de chips han perseguido el mismo objetivo: servir un modelo entrenado más rápido y más barato que la competencia.
El atractivo se basaba en una idea plausible. La inferencia parecía un problema de software con un foso de software. Mejores kernels, un planificador más inteligente o una decodificación especulativa más potente podían justificar precios premium o mejores márgenes al mismo precio. Durante un tiempo, un motor propio fue un arma competitiva real, y los benchmarks ganaban contratos.
Ese período está terminando. La inferencia importa más que nunca y el mercado sigue creciendo, pero el valor defendible se ha alejado del motor. La capa del motor se está mercantilizando rápidamente. El valor se está desplazando primero hacia las operaciones y plataformas de servicio, luego hacia el capital, la capacidad de GPU y, finalmente, hacia los propios centros de datos.
El rendimiento del software todavía cuenta. Un motor lento o poco fiable puede descalificar a un proveedor. Sin embargo, el buen rendimiento se ha generalizado, lo que dificulta que una sola empresa cobre por ello. La pregunta ya no es si el motor crea valor, sino quién captura ese valor una vez que el motor se convierte en infraestructura común.
Tres generaciones de hardware hacen visible el cambio. El mismo patrón explica la competencia entre los actuales proveedores de inferencia y hacia dónde es probable que se dirija después.
Parte I: El pasado — cuando el motor era el foso
Tres generaciones, tres listas de verificación
Cada generación de hardware de NVIDIA venía con una lista de verificación para un motor propio. Lo que cambiaba era la rapidez con la que la lista se convertía en conocimiento público y lo poco que quedaba de ventaja una vez que todos la habían completado.
La era Ampere (A100). El listón inicial era concreto. Un motor que soportara CUDA Graphs para eliminar la sobrecarga de lanzamiento, implementara decodificación especulativa como EAGLE-1 o Medusa, y ofreciera una cuantización INT8 W8A8 sólida, se situaba por delante de la mayor parte del campo. La ingeniería era difícil pero acotada, y completar esa breve lista colocaba a un proveedor en el nivel superior. Esas funciones ganaban contratos.
La era Hopper (H100/H200). La lista creció y se dividió en dos. Para un despliegue único, ya fuera una réplica, un nodo o unos pocos, los diferenciadores eran FlashAttention-3, la atención FP8, la decodificación especulativa EAGLE-3 y la cuantización FP8 W8A8. Las implementaciones sólidas producían resultados destacados en un solo nodo.
Hopper también abrió un segundo frente en el despliegue disgregado. El soporte para la disgregación prefill-decode (PD), el paralelismo de expertos (EP) para las arquitecturas MoE cada vez más dominantes y la descarga de la caché KV en la jerarquía de memoria importaban a escala de clúster, donde estaban los contratos más grandes. Este nivel exigía ingeniería de sistemas además de trabajo de kernels. Durante un tiempo, separó a los proveedores más fuertes del resto.
Los dos niveles recompensaban capacidades diferentes. Los equipos de kernels aún podían ganar un benchmark en un despliegue contenido, mientras que las cargas de trabajo de producción más grandes exigían coordinación entre máquinas, grupos de memoria y dominios de fallo. Ese segundo nivel tardó más en copiarse y dio a los proveedores una ventana más amplia para convertir el trabajo de ingeniería en ingresos.
La era Blackwell (B200/B300/GB200/GB300). Aquí la lista de verificación se ha reducido a un elemento principal: la optimización NVFP4. La ruta líder ya no es una implementación independiente. Los equipos integran los cubins trtllm-gen que NVIDIA envía o construyen directamente sobre TensorRT-LLM. La decodificación especulativa, las rutas FP8 y FP4, el soporte de disgregación y el paralelismo MoE ya están en la pila de referencia.
Blackwell cambia la decisión de construir o comprar. Construir la pila una vez demostraba profundidad técnica; ahora puede equivaler a recrear el trabajo del proveedor mientras los competidores emplean a los mismos ingenieros en otra parte. Una implementación propia puede seguir siendo adecuada para un modelo o un despliegue inusual, pero ya no es el camino predeterminado hacia el rendimiento líder.
La inferencia no tiene secretos. Cada técnica importante tiene un artículo, una implementación de código abierto o un binario del proveedor. El conocimiento que una vez circuló entre un puñado de equipos de rendimiento está empaquetado en código que cualquier grupo competente puede inspeccionar o integrar. La lista de verificación todavía califica a un motor, pero ya no lo distingue.
Por qué TRT-LLM se convirtió en la base de Blackwell
La posición de TensorRT-LLM en la era Blackwell se deriva de los incentivos en ambos lados del mercado.
NVIDIA necesita que TRT-LLM rinda bien. El software sustenta sus benchmarks de hardware nuevo, incluidas las presentaciones de InferenceX, las afirmaciones del día de lanzamiento y los resultados de las keynotes. Por lo tanto, las optimizaciones para un chip nuevo llegan a TRT-LLM el primer día, respaldadas por una gran organización de ingeniería de kernels y un runtime capaz.
Los motores independientes no pueden reproducir esa ventaja solo con esfuerzo. NVIDIA ve la hoja de ruta del hardware, controla las capas de software más bajas y tiene una razón comercial directa para que cada generación parezca fuerte en el lanzamiento. TRT-LLM es donde convergen esos incentivos.
Al mismo tiempo, un puñado de familias de modelos abiertos de frontera representan ahora la abrumadora mayoría del tráfico serio de producción. Los proveedores tienen menos necesidad de soportar cientos de arquitecturas. Dado ese conjunto de modelos más reducido y el hardware Blackwell, TRT-LLM ofrece el techo de rendimiento más alto disponible. La amplitud del soporte de modelos, el argumento tradicional para un motor de propósito general, importa menos cuando la demanda misma se ha reducido.
La producción ahora recompensa la especialización. Un motor que maneja correctamente una larga cola de modelos es útil, pero un proveedor obtiene la mayor parte de sus ingresos de los modelos que los clientes realmente solicitan. En una pequeña matriz de modelos populares y hardware NVIDIA actual, el rendimiento máximo pesa más que la amplitud arquitectónica.
Desde mediados de 2025, más equipos de inferencia han dejado de mantener motores totalmente independientes y han pasado a un desarrollo secundario sobre TRT-LLM. Su debilidad persistente es la usabilidad. La experiencia del desarrollador es difícil, pero un equipo pagado para extraer el último 20 por ciento de un parque de GPU tolerará un conjunto de herramientas complicado. La usabilidad desempata; TRT-LLM en Blackwell no tiene rivales con los que desempatar.
Esos equipos no han dejado de hacer ingeniería. Siguen ajustando modelos, parcheando el comportamiento del runtime y construyendo los sistemas de producción alrededor del motor. Lo que ha cambiado es la capa en la que comienzan. Partir de la base de NVIDIA dirige más esfuerzo hacia su carga de trabajo y menos hacia reproducir maquinaria general.
El acelerante: los agentes de codificación
La convergencia del código abierto y el empuje vertical de NVIDIA ya estaban acortando la vida de las ventajas propietarias. En los últimos seis meses, los agentes de codificación la han acortado aún más al reducir el coste de la ingeniería de inferencia.
El trabajo de kernels, los cambios en el runtime y la infraestructura de servicio pueden completarse más rápido con asistencia de IA. Intent Lab tardó aproximadamente una semana, trabajando con asistencia de agentes sobre TRT-LLM, en implementar optimizaciones que produjeron mejoras muy grandes de extremo a extremo. Antes, un trabajo de ese alcance podría haber ocupado a un ingeniero dedicado durante un trimestre.
La economía del trabajo de motores propietarios cambia con esa velocidad. Una técnica que requería seis meses-ingeniero y compraba nueve meses de exclusividad podía justificar la inversión. Si lleva dos semanas construirla y los competidores la reproducen en tres, el resultado no es un foso; es una cinta de correr. El trabajo sigue siendo técnicamente difícil, pero la vida útil de la ventaja se acerca a cero.
Lo que importa económicamente es cuánto dura la ventaja. Una optimización difícil puede seguir siendo comercialmente débil si se difunde antes de que la empresa recupere el coste de construirla. Los agentes de codificación no hacen que la ingeniería sea trivial; hacen que la exclusividad caduque más rápido.
Lo que queda para los motores abiertos: comunidad, usabilidad y muy poca lealtad
vLLM, SGLang y otros motores de código abierto atienden el mercado que deja abierto la difícil experiencia de desarrollador de TRT-LLM. Muchos usuarios fuera de los proveedores con equipos de inferencia dedicados son investigadores o ejecutan generación offline: cargas de trabajo por lotes orientadas al rendimiento más que servicio en línea sensible a la latencia. En esos entornos, la brecha de rendimiento con TRT-LLM es modesta, a menudo despreciable.
Esos usuarios optimizan para un flujo de trabajo diferente. Necesitan poner en marcha un modelo rápidamente, cambiar de arquitectura sin reescribir la pila y encontrar respuestas cuando algo se rompe. Unos pocos puntos porcentuales de rendimiento rara vez justifican días luchando contra un runtime, especialmente cuando la carga de trabajo no tiene un objetivo de latencia interactiva.
La adopción depende en cambio de la facilidad de uso, la documentación y la comunidad. Instala el paquete, apúntalo a un repositorio de Hugging Face y expón un endpoint compatible con OpenAI. Para un investigador o un pipeline de generación por lotes, esa es toda la decisión de compra.
La adopción no es lealtad. La estandarización en la API compatible con OpenAI reduce un cambio de motor, en el caso más simple, a un cambio en base_url. Un equipo puede ejecutar vLLM hoy, probar SGLang mañana y comparar ambos a finales de semana. Los motores abiertos deben seguir compitiendo por cargas de trabajo que ya han ganado.
Los usuarios se benefician de esa portabilidad; los proyectos que buscan un control duradero, no. El tamaño de la comunidad puede atraer una carga de trabajo, y la documentación puede retenerla durante un tiempo, pero ninguna de las dos impide que un equipo repita la comparación cuando un competidor publica una versión más rápida.
Los verdaderos costes de cambio aparecen en la producción en línea. Provienen del monitoreo y las alertas, los pipelines de despliegue, la recuperación ante desastres, la recuperación automatizada de fallos, las correcciones de errores acumuladas y la larga cola de casos límite de producción. Solo el parseo de llamadas a herramientas proporciona muchos de ellos. Esta capa operativa crea bloqueo, pero es fricción de migración, no un foso de capacidades. Un equipo competente puede reproducirla alrededor de otro motor en semanas. Más importante aún, ese conocimiento pertenece a la organización de SRE del usuario, por lo que el proyecto del motor no captura nada de él.
Comercialmente, el conocimiento operativo hace que un despliegue sea difícil de abandonar sin dar al proveedor del motor poder de fijación de precios. El usuario asume el coste de la migración y es dueño de la mayoría de los sistemas circundantes. Incluso cuando reemplazarlo es molesto, el motor en sí no ha asegurado la cuenta.
El código abierto como bien público
Los principales motores de código abierto han aceptado en gran medida este papel. vLLM y SGLang devuelven casi todo su trabajo a la comunidad. Su objetivo estratégico es la adopción; el resultado es una base libre cada vez mejor en funciones, rendimiento y estabilidad. En la práctica, el ecosistema está subvencionando la inferencia de vanguardia para todos.
Hay un coste para los propios proyectos. Cada mejora de la base reduce el espacio para la diferenciación, incluidos los motores internos y los motores abiertos que hicieron posible la mejora. Al elevar el suelo, estos proyectos también comprimen el valor de su propia capa.
La señal reveladora: las empresas de motores están subiendo en la pila
El comportamiento de los autores de motores ofrece la evidencia más clara de que un motor por sí solo no puede capturar mucho valor.
Las empresas detrás de los dos principales motores de código abierto han comenzado a asumir trabajo de servicio de producción y, según se informa, han firmado contratos de inferencia con importantes laboratorios de modelos y plataformas de consumo. Su razón declarada tiene sentido: ejecutar producción es la forma más rápida de exponer los fallos que un motor debe manejar. El dogfooding a escala encuentra los casos límite.
También pone a esas empresas en competencia con proveedores que una vez fueron sus usuarios y defensores más importantes. El proyecto impulsa la adopción, mientras que los contratos de servicio producen ingresos. Esos roles son difíciles de conciliar cuando los usuarios del proyecto venden el mismo servicio.
Las empresas de motores son comprensiblemente cuidadosas con la etiqueta de proveedor. Su ecosistema depende de empresas que quieren un proyecto upstream neutral, no un competidor subvencionado. Sin embargo, una vez que la empresa de motores opera producción para clientes, la superposición es real independientemente de cómo se describa el trabajo.
Moverse hacia el servicio dice más que la explicación que lo acompaña. Los autores de motores no esperan que la capa del motor sostenga un negocio por sí sola. La pregunta es si el servicio es más defendible.
Parte II: El presente — qué distingue realmente a los proveedores
Las ventajas reales de los incumbentes no tienen nada que ver con los kernels
Las ventajas duraderas de los principales proveedores de inferencia como Together AI, Fireworks y Baseten no aparecen en un benchmark de motores.
Ventaja del pionero y marca. Cuando un laboratorio de modelos necesita un socio de lanzamiento o una startup nativa de IA necesita inferencia de producción, estas empresas encabezan la primera lista corta. El mindshare suena blando hasta que decide contrato tras contrato. Ser la opción predeterminada en un mercado rápido vale más que una ventaja estrecha en un benchmark.
La plataforma. Años de trabajo se han acumulado en herramientas de despliegue, observabilidad, controles empresariales y cumplimiento. Un nuevo entrante debe reconstruir esa superficie pieza por pieza mientras los incumbentes continúan ampliándola.
Ninguna de estas características gana un ranking público de velocidad, pero juntas deciden si un cliente puede mover una carga de trabajo a producción. También se acumulan. Cada despliegue expone otro control faltante o modo de fallo, y la corrección se convierte en parte de la plataforma ofrecida al siguiente cliente.
Capacidad de GPU y su cadena de suministro. Esta es la ventaja más difícil y la menos discutida. Los proveedores deben asegurar asignaciones a través de generaciones de hardware, negociar con nubes y neoclouds, gestionar flotas heterogéneas y planificar la capacidad frente a una demanda desigual. Los incumbentes han aprendido a hacerlo bajo carga. Cuando llega un gran contrato, la pregunta decisiva a menudo no es qué motor es más rápido, sino quién puede poner en línea miles de GPUs el próximo mes.
Los nuevos entrantes están respondiendo a esas economías. Modal ha lanzado un servicio de inferencia. Nebius adquirió Eigen AI para añadir servicio a su nube. La inferencia tiene mejores márgenes que las horas de GPU brutas, por lo que las nubes de GPU están subiendo mientras las empresas de motores se mueven hacia el servicio desde abajo. Proveedores, nubes y empresas de motores están convergiendo en la misma capa porque ahí es donde se acumula actualmente el valor.
Cada grupo comienza con una ventaja diferente. Las empresas de motores aportan experiencia en software, las nubes de GPU aportan capacidad, y los proveedores establecidos aportan clientes y experiencia operativa. Su movimiento hacia el mismo producto hace que las diferencias restantes sean más fáciles de ver: distribución, capital y la capacidad de ejecutar un servicio fiable a escala.
Por qué las clasificaciones de TPS en lotes pequeños se desvanecerán
La clasificación de velocidad de salida con poca concurrencia en Artificial Analysis todavía atrae atención, y durante años fue un buen indicador de la calidad de la ingeniería. Dice menos con cada ciclo de hardware. Las pruebas estándar de API usan una solicitud o diez solicitudes paralelas. Con esa carga, un proveedor puede combinar hardware más nuevo con decodificación especulativa sensible a la carga como DSpark, gastar más capacidad de lote en cada solicitud mientras la máquina está inactiva, y publicar un TPS por usuario extraordinario. El número es real pero estrecho: muestra cuán rápido un endpoint con poca carga puede emitir los tokens de un usuario, no con qué eficiencia una flota sirve a un negocio.
La producción tiene un objetivo diferente. Primero, mantener el TPS por usuario por encima del nivel que la aplicación requiere. Luego maximizar los tokens totales por minuto por GPU (TPM/GPU) sin caer por debajo de ese suelo. Una vez que la experiencia del usuario es lo suficientemente rápida, otro incremento de TPS con poca carga puede valer mucho menos que servir a más usuarios simultáneos en la misma GPU. El coste por token entregado importa más que el puesto en el ranking.
La decodificación especulativa agudiza la distinción. El trabajo de verificación que es barato con lotes pequeños puede consumir capacidad de lote valiosa bajo concurrencia, por lo que una configuración optimizada para el TPS más alto con poca carga no tiene por qué estar en la mejor curva de coste de producción. El resultado útil es una frontera de Pareto: el TPS por usuario en un eje y el TPM/GPU en el otro, con el suelo de velocidad de la aplicación seleccionando el punto de operación y el coste por token derivándose de él.
El TPS de lotes pequeños no es inútil. Establece un suelo de interactividad y expone endpoints que son claramente demasiado lentos. Las pruebas de concurrencia incremental de Artificial Analysis apuntan en la dirección más útil, midiendo lo que el sistema en su conjunto puede sostener. Lo que se desvanecerá es la lectura de "el ganador se lo lleva todo" de la clasificación de lotes pequeños. A los compradores de producción les importará menos quién publica el TPS más alto y más cuánto tráfico de pago lleva cada GPU mientras el TPS por usuario permanezca por encima del suelo requerido. Es el patrón del ensayo en miniatura: el número más visible deja de predecir hacia dónde va el dinero.
Soporte Day-0: el foso relacional se estrecha
Un cambio en 2026 ha fortalecido aún más a los incumbentes: los desarrolladores de modelos se asocian cada vez más directamente con los proveedores de inferencia.
El soporte Day-0 una vez pasaba por los motores de código abierto. Antes de un lanzamiento, un laboratorio coordinaba con vLLM o SGLang; el motor fusionaba el soporte; los proveedores posteriores lo recogían. Esto daba a los motores abiertos un lugar
Incorporar software a una base de activos es mucho más rápido que incorporar una base de activos a una empresa de software. La mercantilización de los motores ayudó a los proveedores a crecer, pero también equipa a su retador más peligroso.
El rival más grande al que se enfrentan Together AI, Fireworks y Baseten no es otro proveedor. Es Nebius, seguido de cualquier neocloud dispuesto a subir en la pila tecnológica.
Dónde van ahora las horas de ingeniería
La ingeniería de inferencia seguirá siendo importante dentro de los proveedores, pero su asignación cambiará. Los motores de código abierto hacen posible esa reasignación.
A medida que mejora la base de motores gratuitos, los proveedores pueden sacar tiempo de ingeniería costoso de los kernels y runtimes. Las horas se destinan a la fiabilidad de la infraestructura, que da sustancia al SLA; a la experiencia de plataforma, que respalda las renovaciones; y cada vez más al RL. Los despliegues de aprendizaje por refuerzo son intensivos en inferencia, por lo que la experiencia en servicio de inferencia se transfiere directamente a la infraestructura de RL para el creciente mercado de post-entrenamiento.
Los proveedores no se están retirando del trabajo técnico. La fiabilidad en una flota heterogénea, la recuperación rápida bajo carga y los despliegues eficientes de RL son problemas de sistemas difíciles. Sus soluciones se mantienen más cerca de los clientes y las operaciones del proveedor, lo que las hace más útiles como fuentes de diferenciación.
El valor en la capa de motores no ha desaparecido. El código abierto lo ha integrado en una base gratuita, lo que permite que el valor de la ingeniería migre hacia los sistemas construidos sobre ella. La pregunta estratégica para la mayoría de las empresas ya no es si construir un motor, sino en qué gastar el tiempo que un motor gratuito ahorra. Los beneficiarios del trabajo de bienes públicos de código abierto aparecen en las hojas de ruta de otras empresas.
La historia no ha terminado
El final de la partida sigue sin resolverse. Vera Rubin, MI455, LPU y otro hardware orientado a la inferencia restablecerán la lista de verificación, como ha hecho cada transición de hardware anterior. Cada restablecimiento reabre brevemente espacio para la diferenciación de motores mediante nuevos formatos numéricos, jerarquías de memoria y compensaciones de paralelismo. Luego las técnicas se difunden y la ventana se cierra.
Las nuevas arquitecturas de modelos y cargas de trabajo crearán aperturas similares. Los agentes con grandes contextos reutilizables y el RL a escala de producción imponen nuevas restricciones. La mercantilización de los motores es un ciclo recurrente. El intervalo entre la invención y la difusión se está reduciendo, pero no ha desaparecido.
Durante cada apertura, un equipo rápido aún puede ganar negocio significativo. Las ventajas temporales importan cuando llegan junto con una gran transición de hardware o de modelos, porque los ingresos y las relaciones con los clientes pueden persistir después de que los competidores se pongan al día. Lo que ha cambiado es el tiempo disponible para reconocer y aprovechar la apertura.
Los motores y los proveedores aún enfrentan dos pruebas. La primera es la velocidad de reacción: ¿pueden detectar una transición mientras la ventaja sigue disponible? Cada generación ha dejado atrás a empresas bien gestionadas que llegaron un ciclo de hardware tarde. Los equipos que se movieron pronto en la desagregación o en la economía NVFP4 de Blackwell obtuvieron ganancias temporales pero compuestas.
La segunda prueba es financiera: ¿pueden preservar el margen mientras crece el ARR? Un proveedor puede registrar más ingresos y perder más dinero comprando crecimiento con capacidad infravalorada. A medida que la competencia se intensifica y los márgenes brutos se acercan a la economía de infraestructura, la disciplina operativa se convierte en una condición de supervivencia. La utilización de la flota, los costos de energía, la previsión de demanda, la planificación de capacidad y el equilibrio entre ingresos comprometidos y spot decidirán el próximo grupo de ganadores. Recaudar miles de millones es solo el comienzo; gastar bien esos miles de millones es el oficio.
El valor en este mercado sigue moviéndose: de los modelos a los motores, de los motores al servicio de inferencia, y del servicio de inferencia hacia la capacidad y la energía. Deja capas donde no queda ningún foso duradero. Los próximos ganadores reconocerán el cambio antes de que la lista de verificación se convierta en conocimiento común.
