Chip Huyen: cómo recortar el coste de inferencia sin comprar hardware nuevo
La autora de AI Engineering resume en tres palancas —modelo, servicio y nada de hardware— cómo bajar la factura de servir un LLM, y las métricas que conviene medir antes de tocar nada.
Entrenar un modelo frontera es un pago único. La inferencia es ese mismo pago repetido una y otra vez, y a lo largo de la vida útil de un modelo la proporción de cómputo entre entrenamiento e inferencia acaba en algún punto entre 1:10 y 1:100. Chip Huyen, autora de AI Engineering, lo planteó así en la conferencia P99 y dedicó media hora a la pregunta que de verdad le importa a quien despliega: cómo bajar esa factura sin comprar hardware nuevo. La respuesta cabe en dos familias de técnicas —tocar el modelo o tocar el servicio que lo sirve— y en un puñado de métricas que conviene mirar antes de decidir. Huyen vuelve al P99 CONF 2026 en unas semanas.
Lo que hay que medir
El tiempo hasta el primer token (TTFT), el tiempo por token de salida (TPOT, la latencia entre tokens consecutivos) y la latencia de extremo a extremo, que es el TTFT más el TPOT multiplicado por el número de tokens de salida menos uno. Con modelos de razonamiento hay una trampa: el primer token generado puede no ser el primero que ve el usuario, porque el modelo piensa un rato antes de enseñar nada. Algunos equipos miden aparte ese tiempo hasta publicar.
A esas métricas Huyen añade el goodput frente al throughput. El throughput cuenta peticiones procesadas en una ventana; el goodput, las que cumplieron el objetivo. Su ejemplo: una aplicación que se marca 200 ms de TTFT y 100 ms de TPOT, procesa diez peticiones por minuto y solo tres cumplen ambas condiciones.
Cuantización, destilación y batching
El hardware queda fuera de la charla a propósito. Huyen trabajó en Nvidia y su argumento es que la mayoría no puede cambiar los chips aunque quiera. También pasa de largo por añadir réplicas: es caro y se complica en cuanto conviven máquinas de 80, 48 y 24 GB con modelos de tamaños distintos. Quedan el modelo y el servicio.
Si tienes los pesos, entrenas o haces ajuste fino, la vía es el modelo. La cuantización baja la precisión con la que se guardan pesos y activaciones, de cuatro bytes por parámetro en 32 bits a uno solo en 8 bits. No solo reduce la memoria necesaria: si cada peso ocupa 32 bits hay que encadenar 32 sumas, y con 8 bits bastan ocho. El precio es un golpe pequeño en la calidad, y según Huyen es una técnica que generaliza bien entre arquitecturas y tamaños. "Casi no veo ya empresas que ejecuten un modelo a precisión completa", dijo.
La destilación va por otro camino: se recoge un conjunto grande de prompts, se pasan por un modelo mayor y se entrena al pequeño con esas respuestas. El aviso es de licencias, no de ingeniería: muchos proveedores prohíben usar sus salidas para entrenar modelos que les compitan.
Si lo que quieres es tomar un modelo tal cual y servirlo mejor, la vía es el servicio, donde no se tocan los pesos. El batching agrupa varias peticiones en una sola pasada por el modelo. El estático espera a llenar el lote: exprime el cómputo pero castiga la latencia de las primeras peticiones. El dinámico funciona con temporizador, por ejemplo agrupando cada 15 ms: menos eficiente en cómputo, mejor en latencia. Después está el batching continuo, que es hacia donde ha ido el ecosistema.
La inferencia es la línea de coste que no baja sola, y por eso estas decisiones acaban pesando más que el propio entrenamiento en la factura de quien opera el servicio. Lo que no hay en la charla es una demo sobre hardware propio: la receta asume que se trabaja con lo que ya hay montado.
