Entrenar un modelo borrador a medida para recortar la factura de inferencia

El coste de servir un modelo de lenguaje no está en el cálculo, sino en mover pesos. Un LLM de 70.000 millones de parámetros tiene que leer sus 140 GB de pesos desde la memoria de la GPU por cada token que genera, y en una NVIDIA H100 eso deja las unidades de cómputo paradas más del 95% del tiempo. El límite es el ancho de banda de memoria, no la capacidad de cómputo. La decodificación especulativa lleva desde 2022 atacando ese desequilibrio, y Red Hat ha detallado cómo aplicarla a modelos afinados propios desplegados en OpenShift AI con Kubeflow.

Las cifras que maneja la compañía sitúan entre el 70% y el 80% del gasto empresarial en IA en inferencia, no en entrenamiento, con la H100 costando entre 2 y 5 dólares por hora. Según Red Hat, la adopción de IA generativa en empresas ha pasado del 37% en 2023 a más del 90% en 2026, y el mercado de modelos afinados de dominio crece a más del 38% anual compuesto desde 2023. Son datos suyos, no de un tercero independiente, pero apuntan a lo mismo: con modelos ya entrenados y en producción, la eficiencia al responder es la palanca grande de la factura.

Un borrador que adivina y un verificador que comprueba

El mecanismo es sencillo de describir. Un modelo pequeño, el borrador, propone varios tokens candidatos de golpe. El modelo grande, el verificador, los valida en una sola pasada forward, que es la operación cara porque implica leer todos los pesos. Los aciertos se aceptan y, en el primer fallo, se usa el token del propio verificador y el ciclo arranca de nuevo. El truco que garantiza que la salida no cambia es el rejection sampling: solo se acepta un token del borrador si el verificador lo habría emitido con al menos la misma probabilidad. La distribución final es idéntica a la de servir el modelo solo.

El paper de EAGLE3 reporta entre 4x y 6x de aceleración con temperatura 0, y despliegues reales sobre vLLM se quedan en reducciones de 2,5x a 3,5x de latencia entre tokens según modelo y carga. El peor caso es no ganar nada: si el borrador falla siempre, el verificador sigue produciendo un token por pasada, igual que sin la técnica. Es decir, no puede empeorar el resultado correcto, solo el tiempo.

El borrador genérico no sirve

Si funciona tan bien, ¿por qué no está en todas partes? Porque cada borrador está acoplado a un verificador concreto. Uno entrenado sobre la distribución de tokens de un modelo no acierta con otro, así que cada afinado o cambio de modelo base obliga a reentrenar el borrador. La métrica que decide si esto ayuda o estorba es la tasa de aceptación: con un borrador mal emparejado cae por debajo del umbral de equilibrio y el overhead de ejecutar dos modelos hace que la inferencia vaya más lenta que el verificador a secas.

Ahí entra el speculator training, que construye el borrador a partir de las representaciones internas del verificador afinado. La técnica es EAGLE3, presentada en NeurIPS 2025 y mantenida dentro de la librería Speculators del proyecto vLLM. vLLM ya soporta decodificación especulativa en serving, con documentación propia, y hay borradores preentrenados en el espacio RedHatAI de HuggingFace.

Lo que queda por ver es cuánto tarda esto en ser un paso más del pipeline. Hoy la pieza que falta no es el runtime, que ya está, sino entrenar el borrador cada vez que se toca el modelo servido. Mientras eso siga siendo un trabajo manual por despliegue, la ganancia de 2x a 3x estará al alcance de quien se moleste en hacerlo, y no de serie.