Por qué ejecutar Clef-Flash en local
Clef-Flash es un modelo de decisión de 9B, y ese tamaño es lo que hace práctica la implementación local. El requisito de VRAM publicado ronda los 41 GB, que caben en un único acelerador de gran memoria en lugar de en una flota de tarjetas.
Ejecutarlo en local mantiene cada estado en tu propia máquina, algo que importa cuando las entradas son tickets de clientes, notas médicas o documentos internos que preferirías no enviar a un endpoint alojado.
También elimina la red del cálculo de latencia. La mediana publicada de unos 39 ms describe al modelo en sí, y una ejecución local te deja ver esa cifra sin la variación del transporte encima.
Lo que necesitas antes de empezar
Necesitas una máquina con suficiente memoria de acelerador —unos 41 GB para Clef-Flash— y una instalación reciente de Ollama. Se recomienda firmemente una GPU compatible con CUDA o Metal, porque un modelo de decisión en CPU será muchísimo más lento que las cifras publicadas.
No necesitas un framework, un entorno de Python ni una tubería de entrenamiento. El modelo llega cuantizado y listo para servirse, y el resto del trabajo es escribir un esquema y llamar al endpoint local.
Si tu hardware se queda corto, puedes seguir el artículo con la API alojada o con el playground del navegador, que devuelven la misma decisión estructurada.
- Ollama instalado y en ejecución.
- Unos 41 GB de memoria de acelerador para Clef-Flash.
- Algo de espacio en disco para los pesos del modelo.
- Un estado y un esquema de preguntas tipadas para probar.
Descargar el modelo
El modelo se distribuye a través de la biblioteca de Ollama, y Clef-Flash se descarga con el nombre clef-flash. El modelo de precisión mayor, de 27B, está disponible como clef en la misma biblioteca, así que puedes tener ambos a la vez.
La primera descarga baja los pesos y puede tardar un rato según tu conexión. Las ejecuciones siguientes parten de la caché local, así que la descarga es un coste único y no por sesión.
Cuando termina la descarga, el modelo queda disponible para cualquier herramienta que hable con el endpoint local de Ollama, incluida la línea de comandos y la API HTTP.
Tomar tu primera decisión
Una petición de decisión tiene dos entradas: el estado y el esquema. El estado es la situación —un ticket, un mensaje, un documento o una imagen—. El esquema enumera las preguntas tipadas que quieres responder y las opciones permitidas para cada una.
A diferencia de una finalización de chat, no pides un párrafo. Pides al modelo que puntúe cada opción permitida, así que la respuesta que recibes es una probabilidad por opción, lista para umbralizar o registrar directamente.
Empieza con algo pequeño. Una sola pregunta de enumeración con tres o cuatro opciones basta para confirmar que el modelo responde y que tu cliente lee bien la estructura.
Escribir un esquema que funcione
Un buen esquema nombra cada pregunta con claridad y enumera solo las opciones que aceptarías de verdad. Las preguntas de enumeración cubren elecciones categóricas, las booleanas cubren divisiones binarias y las de número acotado cubren valores dentro de un rango.
Mantén las preguntas independientes en lo posible. Si dos preguntas se solapan, el modelo puede devolver probabilidades sensatas por separado pero inconsistentes en conjunto, y perderás tiempo reconciliándolas después.
Las opciones deben ser mutuamente excluyentes y exhaustivas. Si una respuesta real pudiera quedar fuera de tu lista, añade una opción para ella en lugar de forzar al modelo a elegir la etiqueta menos incorrecta.
Ajustar la latencia
La mayor palanca sobre la latencia local es la longitud del estado. Recorta el estado a lo que la decisión necesita de verdad; un preámbulo largo que no cambia la respuesta cuesta tiempo en cada llamada.
La segunda palanca es el tamaño del esquema. Cada pregunta adicional y cada opción adicional añaden trabajo de puntuación, así que un esquema ajustado es un esquema rápido. Haz solo las preguntas cuyas respuestas vayas a usar.
Después de eso se aplican las prácticas habituales de inferencia local: mantén el modelo residente en lugar de recargarlo, evita el intercambio de memoria y mide tu propio p95 en lugar de fiarte de una sola medición.
Ejecutar Clef junto a Clef-Flash
Ambos modelos viven en la misma biblioteca, así que puedes descargar también clef y compararlos con el mismo esquema. Como la interfaz es idéntica, el único cambio en tu petición es el nombre del modelo.
El modelo Clef de 27B necesita unos 85 GB de VRAM, así que puede que no quepa en la misma máquina que Clef-Flash. Ejecutarlo en un equipo más potente y apuntar tu cliente a ese endpoint mantiene honesta la comparación.
Un patrón habitual es enviar las decisiones fáciles a Clef-Flash y reservar Clef para los casos en que una pequeña diferencia de probabilidad cambia el resultado. Ambos devuelven la misma forma de respuesta, así que la lógica de enrutado sigue siendo sencilla.
Usar la API alojada en su lugar
Si no hay hardware local disponible, la API alojada expone el mismo contrato de decisión sin el requisito de memoria. Es la forma más rápida de poner en marcha una integración antes de invertir en una máquina.
La API es también la opción práctica para tráfico a ráfagas, ya que pagas por llamada y no por tiempo de acelerador inactivo. El precio de entrada reportado ronda los 0,09 dólares por millón de tokens, lo que hace barato un prototipo alojado.
Puedes moverte entre local y alojado sin cambiar el esquema, porque las formas de la petición y de la respuesta son las mismas. Prototipar en uno y desplegar en el otro es un camino admitido.
Resolver los problemas habituales
Si el modelo se niega a cargar, la causa habitual es memoria de acelerador insuficiente. Comprueba el requisito publicado de Clef-Flash —unos 41 GB— y confirma que nada más está ocupando el dispositivo.
Si las respuestas se sienten más lentas que la mediana publicada, mira primero la longitud del estado y el tamaño del esquema, y después si el modelo se está recargando entre llamadas. Arreglar solo la recarga puede transformar los tiempos.
Si las respuestas parecen incorrectas más que lentas, el problema suele ser el esquema. Relaja una opción, divide una pregunta solapada o añade una categoría general, y las probabilidades tienden a volverse mucho más fáciles de interpretar.
Adónde ir después
Cuando una decisión local funcione, el siguiente paso es medirla sobre una muestra realista. Reúne unos cientos de estados reales, pásalos por el mismo esquema y observa cómo se distribuyen las probabilidades entre las opciones.
A partir de ahí, elige tus umbrales, decide si Clef-Flash es lo bastante preciso para la tarea e integra la llamada en tu aplicación. La decisión es solo la mitad de la tubería; la lógica que la rodea es lo que convierte una probabilidad en una acción.
El playground, la documentación de la API y las páginas de modelos describen el mismo contrato, así que todo lo que aprendas en uno se traslada directamente a los demás.