Los pesos son tuyos para adaptarlos
Clef-Flash se publica como pesos abiertos bajo la licencia Apache 2.0. Es una licencia permisiva: puedes descargar el modelo, ejecutarlo en tu propio hardware, modificarlo y usarlo con fines comerciales sin pedir permiso ni pagar regalías, siempre que conserves el aviso de licencia. Para un modelo de decisión, la consecuencia práctica es que no estás tomando prestado un clasificador que controla otra persona. Puedes poseer y adaptar el modelo exacto que puntúa tus opciones.
Cloudflare publica Clef-Flash como un modelo de latencia de 9B, entrenado a partir de Qwen3.5-9B, y Clef como un modelo de precisión de 27B. Ambos tienen una ventana de contexto de 64k tokens y un codificador de visión integrado, y ambos se distribuyen a través de Workers AI, Ollama, Hugging Face y OpenRouter. La página de Hugging Face es donde viven los pesos, y tener los pesos es lo que hace posible la adaptación local.
Qué permite realmente Apache 2.0
Apache 2.0 concede un amplio conjunto de derechos sobre los pesos del modelo: uso, reproducción, modificación, distribución y sublicencia, incluso dentro de productos comerciales. Puedes ajustar los pesos, integrarlos en un sistema interno o distribuirlos como parte de un servicio de pago, siempre que preserves los avisos de atribución y licencia y declares los cambios significativos que hayas hecho.
La licencia también incluye una concesión de patentes por parte de los contribuyentes, algo que importa cuando un modelo se integra profundamente en una cadena comercial, y es compatible con la mayoría de las políticas corporativas de código abierto. No te concede los nombres Clef ni Clef-Flash, y no incluye garantía alguna. La licencia te da los bloques de construcción, no un contrato de soporte.
Para los equipos con restricciones de residencia de datos o de cumplimiento normativo, este suele ser el punto decisivo. Los pesos pueden vivir dentro de tu propio perímetro, y un derivado ajustado puede quedarse ahí también, lo que convierte una dependencia alojada en un activo interno.
La ruta de aprendizaje por refuerzo publicada
Clef-Flash no se entrenó solo con predicción supervisada del siguiente token. Según lo que publicó Cloudflare, se postentrenó a partir de Qwen3.5-9B mediante aprendizaje por refuerzo, es decir, el modelo se optimiza contra una señal de recompensa en lugar de limitarse a imitar un corpus de respuestas correctas.
Esa distinción importa muchísimo en un modelo de decisión, porque el objetivo no es una prosa fluida. El objetivo es una distribución de probabilidad bien calibrada sobre un espacio de respuestas fijo. Un bucle de refuerzo puede premiar exactamente eso: ¿puso el modelo la mayor parte de su masa en la opción que resultó ser correcta, y cuán seguro estaba cuando se equivocó?
No necesitas reproducir la receta exacta. Cloudflare publicó una ruta, no una hoja de hiperparámetros, e inventar cifras que nunca se publicaron no ayudaría a nadie. Lo que heredas es un modelo que ya trata las decisiones como opciones puntuadas, lo que da a tu propio ajuste un punto de partida mucho mejor que el de un modelo de chat general.
Por qué el objetivo son probabilidades, no prosa
Cuando ajustas un modelo de chat, el éxito suele juzgarse por lo bien que se ve el texto. Cuando ajustas un modelo de decisión, el éxito se juzga por si las probabilidades son útiles. Una respuesta incorrecta con mucha seguridad y una respuesta correcta con dudas son modos de fallo distintos, y tu evaluación debería tratarlos de forma distinta.
La calibración es la propiedad que hace fiable una probabilidad: cuando el modelo dice 0,8, el suceso debería ocurrir aproximadamente el ochenta por ciento de las veces. El ajuste es tu oportunidad de llevar la calibración hacia tu dominio en lugar de dejarla en una media genérica aprendida de una distribución de tareas mucho más amplia.
Como cada opción se puntúa en una sola pasada y el espacio de respuestas está tipado, puedes medirlo de forma directa. Comparas la distribución predicha con los resultados observados y sigues ajustando hasta que los números se comporten como esperan tus umbrales.
Qué puede cambiar realmente el ajuste
El ajuste es más útil para tres cosas: el vocabulario del dominio, los conjuntos de opciones que aparecen en tu esquema y la calibración de las probabilidades sobre las que tu aplicación aplica umbrales. Esas tres cubren casi toda la distancia entre un modelo de decisión general y uno que encaja con un negocio concreto.
El vocabulario del dominio abarca las palabras y abreviaturas que usa tu organización y que un modelo general nunca ha visto en contexto: etiquetas internas, nombres en clave de productos, categorías regulatorias, taxonomías de tickets. Adaptarse a ese lenguaje reduce la ambigüedad que el modelo debe resolver en inferencia y le permite dedicar su capacidad a la decisión en lugar de a descifrar jerga.
Los conjuntos de opciones y la calibración son más sutiles. El esquema sigue siendo flexible y se define en el momento de la petición, pero el ajuste empuja al modelo hacia los patrones de razonamiento que hay detrás de tus decisiones concretas y hacia los niveles de confianza en los que tu equipo ha aprendido a confiar.
Datos: cómo reunir ejemplos de decisiones
Ajustar un modelo de decisión requiere ejemplos de decisiones, no ensayos. Cada ejemplo es un estado, el esquema de preguntas tipadas que enviarías y la respuesta correcta para cada pregunta. La fuente más limpia es tu propio historial: tickets que se clasificaron, contenido que se moderó, llamadas que se enrutaron, solicitudes que se revisaron.
El truco consiste en capturar el estado exactamente como lo verá el modelo en inferencia y en registrar el resultado que se confirmó después, no solo la primera suposición que hicieron una persona o un sistema. Los resultados verificados valen mucho más que los ambiguos, y un conjunto más pequeño de etiquetas limpias suele superar a uno grande de etiquetas ruidosas.
Donde las etiquetas históricas escasean, una pasada cuidadosa de revisión humana puede cubrir el hueco, pero la coherencia entre revisores importa más que el volumen bruto. Un modelo de decisión aprende el patrón de tu esquema; las etiquetas contradictorias solo le enseñan ruido, y el ruido es caro de desaprender.
Evaluación y calibración
Reserva una parte de tus ejemplos y no entrenes nunca con ellos. Después mide algo más que la exactitud: observa la distribución completa que devuelve el modelo y compárala con lo que ocurrió realmente. La precisión y la exhaustividad sobre la opción principal son un comienzo, pero ocultan la información de confianza que hace valioso a un modelo de decisión.
Las curvas de calibración, en las que agrupas las predicciones por confianza y compruebas la tasa observada dentro de cada grupo, muestran si el modelo es demasiado confiado o demasiado inseguro en tu dominio. Si lo es, es una señal para seguir ajustando o para revisar tus umbrales en lugar de confiar ciegamente en el número.
Informa de las métricas que conectan con tu aplicación: con qué frecuencia acierta la opción principal, con qué frecuencia se escala a una persona una respuesta de baja confianza y cuánto coincide el modelo con tus revisores. Esos son los números que justifican publicar un ajuste y los que vigilarás después del despliegue.
Ejecutar el modelo adaptado en local
Clef-Flash necesita unos 41 GB de VRAM para ejecutarse en local, y Clef necesita unos 85 GB. Eso pone un único Clef-Flash ajustado al alcance de una estación de trabajo o de un nodo de inferencia modesto, que es lo que hace práctica la vía autoalojada para un equipo pequeño y no solo para grandes grupos de infraestructura.
Puedes descargar el modelo base a través de Ollama, tomar los pesos de Hugging Face, incluidos formatos cuantizados como MLX 4-bit, y alojarlo en tu propia infraestructura. El mismo modelo también está disponible a través de Workers AI si prefieres no gestionar hardware, lo que mantiene la opción abierta mientras experimentas.
Después del ajuste, el consumo en ejecución cambia solo de forma modesta, porque estás adaptando un modelo de 9B existente en lugar de hacerlo crecer. El coste principal es la propia ejecución de entrenamiento, no un clúster de servicio permanentemente más grande, y eso es lo que hace económicamente razonable ajustar de forma iterativa.
Mantener la compatibilidad con el esquema compartido
Una de las razones más sólidas para ajustar en lugar de reemplazar es la compatibilidad. Clef y Clef-Flash comparten interfaz, y el esquema se define en el momento de la petición en lugar de quedar fijado en los pesos. Un Clef-Flash ajustado puede seguir respondiendo a las mismas preguntas tipadas que el modelo base, lo que significa que el código de tu aplicación no cambia cuando intercambias los pesos que hay debajo.
Mantén estables los conjuntos de opciones y los tipos de pregunta entre el entrenamiento y el servicio. Si enseñas al modelo una etiqueta nueva, añádela al esquema que envías y asegúrate de que tu evaluación la cubre. La compatibilidad es lo que te permite mover una misma decisión entre Clef-Flash, un ajuste y el modelo Clef más grande sin reescribir el sistema que los rodea.
Alojado o autoalojado: la decisión
La inferencia alojada a través de Workers AI es la forma más rápida de empezar. No hay hardware que aprovisionar ni modelo que mantener, y puedes posponer la cuestión del ajuste hasta tener pruebas de que tu esquema y tus datos merecen la pena.
El autoalojamiento resulta atractivo cuando tienes requisitos estrictos de residencia de datos, un volumen alto y estable que encarece el precio por token, o una necesidad real de un modelo ajustado a un lenguaje que ningún endpoint alojado ha visto. La licencia Apache 2.0 es lo que convierte esa opción en algo real y no teórico.
Las dos vías no son excluyentes. Muchos equipos hacen prototipos en el endpoint alojado, reúnen ejemplos de decisiones de tráfico real de producción y solo entonces entrenan y despliegan un ajuste local detrás exactamente del mismo esquema que ya usaban.