Destilación de modelos LLM: qué es y cuándo ahorra 51 veces

En mayo me pasaron la factura de OpenAI de una empresa de soporte. 1.600 $ al mes.

Fui a ver en qué se gastaba. No era un agente sofisticado: era un clasificador de tickets. Llega un mensaje, el modelo decide si es facturación, bug, acceso o feature, le pone prioridad y marca si necesita un humano.

Doscientos mil tickets al mes por el modelo más caro que tenían en producción. Acertaba el 96 %, pero pagaban precio de razonamiento frontera por una tarea de cinco respuestas.

Llevaban seis meses regalando el mejor argumento a favor de la destilación de modelos: el modelo caro ya había resuelto ese problema doscientas mil veces, y esas respuestas se borraban cada noche.

En corto: la destilación de modelos consiste en usar las salidas de un modelo grande (teacher) como datos de entrenamiento para uno pequeño (student). El pequeño reproduce su comportamiento en una tarea concreta a una fracción del coste. Gana cuando la tarea es estrecha, repetitiva y de alto volumen; pierde en cuanto la tarea cambia o necesita generalizar fuera de lo que viste al construir el dataset.

¿Qué es la destilación de modelos?

La destilación de modelos (model distillation) es entrenar un modelo pequeño —el student— para que imite el comportamiento de uno grande —el teacher— en una tarea específica, usando como dataset las respuestas que el grande ya ha generado.

La idea tiene once años y viene de Hinton, Vinyals y Dean (2015), que la propusieron para comprimir el conocimiento de un ensemble de redes en un único modelo desplegable. Lo que ha cambiado no es la técnica. Es que ahora el profesor cobra por token.

El caso más visible son los DeepSeek-R1 distilled: cogieron 800.000 muestras curadas con R1 y con ellas hicieron fine-tuning supervisado de modelos base Qwen2.5 (1.5B a 32B) y Llama (8B y 70B). Sin refuerzo, solo SFT sobre las salidas del grande. El de 32B reporta 72,6 en AIME 2024 y 94,3 en MATH-500.

Un modelo de 32B razonando cerca de uno de cientos de miles de millones de parámetros. Ese es el truco entero.

Destilación no es fine-tuning, ni RAG, ni cuantización

Destilación y fine-tuning clásico comparten mecanismo y se diferencian en quién pone las etiquetas: un modelo en la destilación, una persona en el fine-tuning. RAG no toca los pesos y la cuantización no cambia el comportamiento.

Aquí es donde casi todo el mundo se lía, y es lo que decide si tu proyecto funciona. Las cinco técnicas suenan parecidas porque todas prometen "mejor o más barato", pero cada una toca una pieza distinta:

Enfoque	Qué modifica	Coste real	Cuándo gana	Limitación / riesgo
Prompt engineering	El texto que envías	Cero	Siempre es el primer intento	Pagas el prompt largo en cada llamada, para siempre
RAG	Lo que el modelo sabe al consultar	Índice + tokens extra	El conocimiento cambia a diario	No enseña comportamiento, solo aporta datos; infla el contexto
Fine-tuning clásico	Los pesos, con etiquetas humanas	El etiquetado humano	Ya tienes histórico etiquetado fiable	Casi nadie tiene esas etiquetas; producirlas cuesta meses
Destilación	Los pesos, con etiquetas de otro modelo	Inferencia del teacher + entrenamiento	Tarea estrecha, alto volumen, el grande acierta	Heredas los errores del teacher; los ToS pueden prohibirlo
Cuantización	La precisión numérica de los pesos	Minutos de CPU	Quieres el mismo modelo en menos VRAM	No mejora la tarea; pierde algo de calidad

La distinción que importa: destilación y fine-tuning clásico son el mismo mecanismo con distinta procedencia de las etiquetas. Destilar es fine-tuning donde el etiquetador es una máquina que ya sabe hacerlo. Eso es lo que lo vuelve viable, porque el cuello de botella del fine-tuning nunca fue el entrenamiento: era conseguir diez mil ejemplos etiquetados de forma consistente.

Y la que más confunde: la cuantización no es destilación. Cuantizar es coger ese mismo modelo y guardar sus pesos con menos bits. No hay profesor, ni alumno, ni dataset. Es compresión, no transferencia. Si lo que quieres es correr un modelo en tu máquina sin tocar su comportamiento, eso es cuantización, y va por la guía de modelos para correr en local.

Escribí hace tiempo sobre cuándo usar RAG, fine-tuning o simplemente más contexto. La destilación es la cuarta opción de ese mismo debate, y la que menos gente considera, porque suena a paper. No lo es: OpenAI y AWS tienen botones para hacerlo.

¿Cuánto cuesta destilar un modelo y cuánto ahorra?

Destilar un clasificador que hace 200.000 llamadas al mes cuesta unos 112 $ una sola vez y baja la factura mensual de 1.600 $ a 31,20 $. Se amortiza en poco más de dos días.

Volvamos a los tickets. Doscientas mil clasificaciones al mes, unos 700 tokens de entrada y 20 de salida cada una: 140 millones de tokens de entrada y 4 millones de salida.

Con los precios públicos de la API de OpenAI a septiembre de 2026:

Modelo	Entrada / salida (por 1M tokens)	Coste mensual
GPT-6 Astra (el teacher)	10 $ / 50 $ (contexto estándar)	1.600 $
GPT-4.1-mini base	0,40 $ / 1,60 $	62,40 $
GPT-4.1-mini destilado	0,80 $ / 3,20 $	124,80 $
GPT-4.1-nano base	0,10 $ / 0,40 $	15,60 $
GPT-4.1-nano destilado	0,20 $ / 0,80 $	31,20 $

Fíjate en un detalle que casi nadie anticipa: un modelo destilado cuesta exactamente el doble que su versión base. OpenAI cobra 0,20 $ de entrada por el nano ajustado frente a 0,10 $ del nano de catálogo. Es la prima por servir tus pesos. Si en tu presupuesto pusiste el precio base, tu presupuesto está a la mitad de la realidad.

Y fíjate en lo que dice esa tabla si la lees entera: el nano de catálogo sale por 15,60 $, la mitad que el destilado. La destilación no es lo que compras para ahorrar; es lo que compras cuando el nano de catálogo no pasa tus evals y la alternativa era seguir pagando 1.600 $.

Aun así, el salto de 1.600 $ a 31,20 $ son 51 veces. Eso no lo consigue ningún prompt.

Y es una cota baja: la tabla carga los mismos 700 tokens de entrada a todas las filas, también al destilado, que en realidad va con un prompt mucho más corto. Ahora vemos por qué.

¿Y cuánto cuesta destilar? La parte facturable es ridícula:

Generar 10.000 ejemplos con Astra: 7M de entrada a 10 $ más 0,2M de salida a 50 $ = 80 $.
Entrenar el nano: 7,2M de tokens de entrenamiento a 1,50 $ el millón ≈ 11 $ por época, unos 32 $ con tres épocas.

112 $ para ahorrar 1.569 $ al mes. Se amortiza en poco más de dos días.

Esto es el mismo razonamiento que aplico en coste por tarea en lugar de precio por token, llevado al caso extremo: una tarea tan estrecha que cabe entera en los pesos de un nano.

Y si trabajas en español, el tokenizador cobra alrededor de un 26 % más por el mismo texto en castellano: un argumento más a favor de destilar, porque ese sobrecoste lo pagas en cada llamada mientras sigas con el grande. El desglose del precio por tarea del frontera está en el análisis de GPT-6 Astra.

Cómo se construye el dataset para destilar un modelo

El dataset se construye filtrando las salidas del teacher contra un esquema y descartando las que no validan, nunca corrigiéndolas a mano. La destilación no falla en el entrenamiento: falla porque el dataset está sucio.

Aquí la teoría se estrella contra el suelo.

El teacher acierta el 96 %, sí. Pero también devuelve JSON malformado, inventa categorías que no están en tu enum y se contradice en casos límite. Si esos ejemplos entran al entrenamiento, no estás destilando conocimiento: estás enseñando a tu modelo pequeño a equivocarse con seguridad.

La regla es simple: valida la salida del teacher contra un esquema antes de que entre al dataset, y descarta lo que no pase. No lo arregles a mano. Descártalo.

import { z } from &#39;zod&#39;
import OpenAI from &#39;openai&#39;

const openai = new OpenAI()

// El contrato de salida. Si el teacher no lo cumple, el ejemplo no entra.
const TicketLabel = z.object({
  category: z.enum([&#39;facturacion&#39;, &#39;bug&#39;, &#39;acceso&#39;, &#39;feature&#39;, &#39;otro&#39;]),
  priority: z.enum([&#39;baja&#39;, &#39;media&#39;, &#39;alta&#39;]),
  needsHuman: z.boolean(),
})

type TicketLabel = z.infer<typeof TicketLabel>

async function labelWithTeacher(ticket: string): Promise<TicketLabel | null> {
  const response = await openai.responses.create({
    model: &#39;gpt-6-astra&#39;,
    input: [
      { role: &#39;system&#39;, content: LONG_PROMPT }, // el prompt largo, con reglas y casos límite
      { role: &#39;user&#39;, content: ticket },
    ],
    text: { format: { type: &#39;json_object&#39; } },
  })

  let raw: unknown
  try {
    raw = JSON.parse(response.output_text)
  } catch {
    return null // JSON malformado: fuera del dataset
  }

  const parsed = TicketLabel.safeParse(raw)
  return parsed.success ? parsed.data : null
}

Podrías forzar el esquema en la API con json_schema, pero entonces no verías lo que el teacher hace mal. Aquí lo que interesa es medir cuánto descartas.

Y ahora el detalle del JSONL que decide tu factura:

import { appendFile } from &#39;node:fs/promises&#39;

for (const ticket of tickets) {
  const label = await labelWithTeacher(ticket.body)
  if (!label) continue // ejemplo sucio: fuera

  await appendFile(&#39;dataset.jsonl&#39;, JSON.stringify({
    messages: [
      { role: &#39;system&#39;, content: SHORT_PROMPT }, // el prompt CORTO, no el largo
      { role: &#39;user&#39;, content: ticket.body },
      { role: &#39;assistant&#39;, content: JSON.stringify(label) },
    ],
  }) + &#39;\n&#39;)
}

Ese SHORT_PROMPT puede partir por la mitad la factura del student, y se explica en una frase: el teacher necesita el prompt largo con todas las reglas; el student se las aprende en los pesos. Si entrenas con el prompt largo, condenas al modelo pequeño a reenviarlo en cada llamada para siempre y tiras por la ventana buena parte de la reducción de tokens.

Tratar los esquemas como contrato —y no como validación decorativa— es lo que enseño en el curso de Zod. En destilación deja de ser higiene y pasa a ser el filtro que decide la calidad de tu modelo.

OpenAI te ahorra parte de este trabajo: la Responses API guarda las respuestas 30 días por defecto, así que puedes filtrar tus salidas reales de producción en vez de generarlas de cero.

Amazon Bedrock Model Distillation hace lo mismo con los invocation logs de CloudWatch y automatiza el ciclo entero. Si activas sus técnicas de síntesis de datos, amplía tu dataset hasta un máximo de 15.000 pares prompt-respuesta, y te factura aparte esas llamadas extra al teacher.

Qué dicen los que ya han destilado un modelo en producción

En el hilo de Hacker News Distillation makes AI models smaller and cheaper hay dos comentarios que valen más que la mitad de los artículos sobre el tema.

El primero, de NitpickLawyer, sobre cuántos ejemplos hacen falta de verdad: "you can use as few as 1-2k traces to reach similar results. Much cheaper." Mil o dos mil trazas, no cien mil. Encaja con lo que recomienda OpenAI, que sugiere arrancar el fine-tuning con 50 demostraciones bien hechas y medir antes de escalar.

El segundo, de v3ss0n, resume el riesgo en cuatro palabras: "Sometimes better, sometimes dumber."

Esa es la frase honesta. El student no hereda el 100 % del teacher: hereda su comportamiento en la distribución de datos que le enseñaste. A veces mejora, porque se especializa. A veces se vuelve tonto justo en el caso raro que no estaba en tus 10.000 ejemplos.

Por eso el orden correcto es: primero las evals, después destilar. Sin forma automática de comparar student contra teacher sobre casos difíciles, no sabrás cuál de las dos te ha tocado. Lo conté en evals deterministas para agentes de IA: mide el dato que sale, no el texto que lo envuelve. En clasificación es trivial, y es justo lo que hace que destilar sea seguro aquí y peligroso en tareas abiertas.

Cuándo NO destilar un modelo

Cinco situaciones en las que esto se te vuelve en contra. Las he visto todas.

1. La tarea cambia cada mes. Un modelo destilado es una foto del comportamiento del teacher el día que generaste el dataset. Si añades dos categorías de ticket en octubre, el student no las conoce y no hay prompt que lo arregle: toca regenerar dataset y reentrenar. Con un modelo de catálogo eso son diez minutos editando texto.

2. No tienes volumen. Los 112 $ se amortizan en dos días con 200.000 llamadas al mes. Con 2.000 llamadas no se amortizan nunca. Por debajo de unas decenas de miles de llamadas mensuales, quédate en el modelo pequeño de catálogo con un buen prompt.

3. Los términos de servicio de tu proveedor. Destilar gpt-6-astra en gpt-4.1-nano dentro de OpenAI es una función que ellos te venden. Sacar las salidas para entrenar un Qwen que corres tú es otra conversación, y merece leerse los Business Terms con alguien de legal delante.

4. El proveedor puede quitarte el botón. No es teórico. La documentación de Bedrock dice hoy, textualmente, que "Distillation is not currently available for Anthropic models on Amazon Bedrock", sin plazo de restauración. Si montas tu arquitectura de costes sobre destilar Claude en Bedrock, ese pilar ahora mismo no existe. Y ojo al despliegue: con los modelos de Llama el job corre en US West (Oregón), y servir el destilado pasa por comprar provisioned throughput —coste fijo mensual, no precio por token— o copiarlo a otra región y comprarlo allí.

5. Necesitas que generalice. Si tu caso de uso es "un asistente que responde de todo", destilar es exactamente lo contrario de lo que quieres. La destilación compra rendimiento en una distribución estrecha pagando con generalidad. Para un clasificador es el negocio del siglo. Para un copiloto de propósito general es amputarse una pierna para correr más rápido.

Cómo empezar a destilar: los tres pasos de esta semana

No empieces destilando. Empieza midiendo.

Coge tu tarea más repetitiva —la que llama al modelo miles de veces al día con el mismo prompt— y haz tres cosas esta semana, en este orden:

Monta 50 casos de eval con la respuesta correcta conocida, incluyendo los diez casos raros que te preocupan.
Pasa esos 50 casos por el modelo pequeño de catálogo con tu prompt actual. Si aguanta, has terminado: cambia el modelo y ahórrate el proyecto entero. Este paso se lo salta demasiada gente, porque destilar suena más interesante que probar el nano.
Solo si el pequeño falla, genera 1.000 ejemplos con el teacher, valídalos contra un esquema, entrena y vuelve a pasar los mismos 50 casos.

La decisión no la toma tu intuición sobre lo difícil que es la tarea. La toma esa tabla de 50 filas.

Si quieres montar el sistema completo alrededor de esto —el harness, los contratos de salida y las evals que hacen que un flujo con IA sea fiable y no solo demostrable— es lo que trabajamos en Construye con IA.

Y en Dominicode Labs está el pipeline de destilación con el validador de dataset y el script de evals que usamos en producción.

Preguntas frecuentes

¿Qué diferencia hay entre destilación y fine-tuning?

Son el mismo mecanismo con distinta procedencia de las etiquetas. En el fine-tuning clásico las etiquetas las produce una persona; en la destilación las produce otro modelo, el teacher. Eso cambia el cuello de botella entero: conseguir diez mil ejemplos etiquetados por humanos de forma consistente cuesta meses, y generarlos con un modelo frontera cuesta 80 $ y una tarde.

¿Qué son el modelo teacher y el modelo student?

El teacher es el modelo grande y caro cuyo comportamiento quieres reproducir; el student es el modelo pequeño que se entrena con sus salidas. En una destilación dentro de la plataforma de OpenAI, un par típico es GPT-6 Astra como teacher y GPT-4.1-nano como student. En Amazon Bedrock, Amazon Nova Pro como teacher y Nova Micro o Nova Lite como student.

¿Cuántos ejemplos necesito para destilar un modelo?

Menos de los que crees. OpenAI recomienda empezar el fine-tuning con 50 demostraciones bien construidas y medir antes de escalar, y los rangos que reportan los profesionales van de 1.000 a 2.000 trazas para clasificación o extracción. Para razonamiento la cifra sube mucho: los DeepSeek-R1 distilled se entrenaron con 800.000 muestras curadas. El número de ejemplos escala con la variedad de la tarea, no con su dificultad.

¿Cuál es la diferencia entre destilación de modelos y cuantización?

Son operaciones distintas que solo comparten el objetivo de abaratar. La cuantización coge un modelo y guarda sus pesos con menos bits —de 16 a 4, por ejemplo— para que ocupe menos memoria: es el mismo modelo comprimido, sin entrenamiento ni datos nuevos. La destilación entrena un modelo diferente y más pequeño usando las salidas del grande como dataset, y el resultado es otro modelo con otros pesos. Puedes hacer las dos cosas: destilar un Qwen de 7B y después cuantizarlo a 4 bits para que quepa en tu portátil.

¿Puedo destilar GPT o Claude en un modelo open source?

Técnicamente sí, y mucha gente lo hace. Legalmente depende del contrato que hayas firmado. Los Business Terms de OpenAI, en su redacción de mayo de 2025, prohíben usar el Output para desarrollar modelos de IA que compitan con sus productos y servicios, salvo excepción permitida, y otros proveedores tienen cláusulas equivalentes. Destilar dentro de la plataforma del proveedor (Astra a nano en OpenAI, Nova Pro a Nova Micro en Bedrock) es una función que te venden ellos y no tiene discusión. Sacar las salidas para entrenar un modelo que corres tú conviene revisarlo con alguien de legal, no con un post de blog.

¿La destilación sustituye a RAG?

No, resuelven problemas distintos y a menudo conviven. RAG inyecta conocimiento que cambia —documentación, catálogo, tickets recientes— en el contexto de la consulta. La destilación graba comportamiento en los pesos: cómo clasificar, qué formato devolver, qué criterio aplicar. Si el modelo no sabe el precio actual de un producto, destilar no ayuda en nada y RAG sí. Si el modelo pequeño no sigue tu criterio de prioridad, RAG no ayuda y destilar sí. En un clasificador sobre documentación viva querrás las dos.

¿Cómo sé si el modelo destilado aguanta en producción?

Con evals deterministas sobre un conjunto fijo de casos, ejecutadas antes y después. En clasificación o extracción es directo, porque la salida es estructurada y comparas el campo, no el texto. Lo mínimo viable es un set de 50 a 100 casos con la respuesta correcta conocida, sesgado a propósito hacia los casos límite. Si el student pierde más de lo que tu negocio tolera en los casos raros, la conclusión no siempre es descartar la destilación: a veces es enrutar, mandar el 95 % fácil al student y el 5 % dudoso al teacher. Esa arquitectura híbrida suele dar la mejor relación coste-precisión.

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.