El catálogo de modelos: texto, embeddings, visión, audio e imagen

El catálogo es la frontera real de Workers AI: no puedes subir tus propios pesos, así que lo que el catálogo abarca es exactamente lo que la plataforma puede hacer por ti. Leerlo bien no consiste en memorizar identificadores, sino en entender que está organizado por modalidad —qué entra y qué sale— y que dentro de cada modalidad hay una escalera de tamaños que traza la curva entre calidad, latencia y coste. Elegir modelo es, casi siempre, elegir el punto más bajo de esa escalera que todavía resuelve tu problema.

Las familias, por lo que entra y lo que sale

La forma más útil de ordenar el catálogo no es por proveedor ni por popularidad, sino por la firma de la tarea: qué tipo de dato le das y qué tipo de dato te devuelve. Esa firma determina cómo lo invocas, qué forma tiene la respuesta y con qué otras piezas de la plataforma encaja.

La distinción que más gente confunde al empezar es la de generar frente a representar. Un LLM produce texto nuevo; un modelo de embeddings no produce nada legible, produce coordenadas. Preguntarle a un embedding qué opina de algo no tiene sentido, igual que no lo tiene pedirle a un LLM el vector de un párrafo. Son dos herramientas que se usan juntas —recuperas con embeddings, respondes con un LLM— pero no son intercambiables.

Leer el identificador de un modelo

Los nombres del catálogo siguen una convención que, una vez descifrada, te ahorra buscar la documentación cada vez. Empiezan por @cf, siguen con la organización que publicó el modelo y terminan con el nombre, la versión y una cola de sufijos técnicos.

// @cf / meta / llama-3.1-8b-instruct
//  |      |         |    |     |
//  |      |         |    |     +-- afinado para seguir instrucciones
//  |      |         |    +-------- 8 mil millones de parametros
//  |      |         +------------- version de la familia
//  |      +----------------------- organizacion que lo publico
//  +------------------------------ ejecutado en la red de Cloudflare

const modelos = {
  rapido: "@cf/meta/llama-3.1-8b-instruct",
  potente: "@cf/meta/llama-3.3-70b-instruct-fp8-fast",
  embeddings: "@cf/baai/bge-m3",
  audio: "@cf/openai/whisper-large-v3-turbo",
  imagen: "@cf/black-forest-labs/flux-1-schnell",
};

Los sufijos son los que más información densa aportan. El instruct indica que el modelo fue afinado para obedecer instrucciones y conversar, frente a un modelo base que solo continúa texto: para casi todo lo que harás en un Worker, quieres la variante instruct. El fp8 o int8 señala una cuantización, es decir, pesos almacenados con menos precisión numérica: ocupan menos, se ejecutan más rápido y cuestan menos neurons, a cambio de una pérdida de calidad que en la mayoría de tareas resulta imperceptible. Y el fast o turbo marca variantes optimizadas para latencia, la elección natural cuando la respuesta va en el camino de una petición del usuario.

El número de parámetros es la señal más ruidosa de todas, porque invita a leerlo como una puntuación. No lo es. Un modelo de setenta mil millones escribe con más matiz y razona mejor en cadenas largas, pero también tarda varias veces más y consume bastante más presupuesto por invocación. Un modelo de ocho mil millones bien instruido resuelve clasificación, extracción, reformulación y resumen con una calidad indistinguible para el usuario final, en una fracción del tiempo.

Elegir: la tarea manda sobre el tamaño

El error más común al empezar es partir del modelo más grande disponible y usarlo para todo, porque parece la opción segura. Es exactamente al revés: es la opción cara y lenta que además oculta que muchas de tus tareas ni siquiera necesitaban un LLM. El criterio sano recorre el árbol en el otro sentido, empezando por la naturaleza de la tarea y bajando hasta el modelo más pequeño que la resuelva.

flowchart TD
T[Que necesito hacer] --> A{Que dato entra}
A -->|Audio| W[Modelo de transcripcion]
A -->|Imagen| V[Modelo de vision]
A -->|Texto| B{Que dato sale}
B -->|Una imagen| D[Modelo de difusion]
B -->|Un vector| E[Modelo de embeddings]
B -->|Texto| C{Es una tarea cerrada}
C -->|Si, clasificar o traducir| U[Modelo utilitario pequeno]
C -->|No, razonar o redactar| L[LLM instruct]
L --> S{Va en el camino de la peticion}
S -->|Si| P[Variante pequena o fast]
S -->|No, es diferido| G[Variante grande]
style L fill:#89b4fa,color:#11111b
style E fill:#a6e3a1,color:#11111b

Ese último nodo del árbol es el que más dinero y más milisegundos ahorra. Si la inferencia ocurre mientras un usuario espera, la latencia es un requisito de producto y debe pesar tanto como la calidad: un modelo pequeño que responde en medio segundo gana casi siempre a uno grande que tarda seis. Si la inferencia es diferida —dentro de una cola, un cron o un Workflow, donde nadie mira el reloj— el argumento se invierte y el modelo grande sale gratis en términos de experiencia.

La disciplina que cierra el criterio es medir en vez de opinar. Escribe una docena de casos representativos de tu tarea, con la salida que considerarías correcta, y pásalos por dos o tres candidatos comparando calidad, tiempo y coste. Es media hora de trabajo que decide bien una elección que, hecha por intuición, arrastrarás durante meses.

Probar antes de comprometerse

Comparar modelos no requiere un banco de pruebas sofisticado. Requiere un puñado de entradas reales de tu dominio —no ejemplos de juguete, sino los mensajes raros, largos y mal escritos que de verdad te llegan— y un bucle que los pase por cada candidato midiendo lo mismo en todos.

const candidatos = [
  "@cf/meta/llama-3.1-8b-instruct",
  "@cf/mistralai/mistral-small-3.1-24b-instruct",
  "@cf/meta/llama-3.3-70b-instruct-fp8-fast",
];

for (const modelo of candidatos) {
  for (const caso of casosReales) {
    const inicio = Date.now();
    const { response } = await env.AI.run(modelo, {
      messages: [
        { role: "system", content: instruccion },
        { role: "user", content: caso.entrada },
      ],
      max_tokens: 256,
      temperature: 0,
    });
    resultados.push({
      modelo,
      caso: caso.id,
      ms: Date.now() - inicio,
      acierto: response.trim() === caso.esperada,
      salida: response,
    });
  }
}

Tres detalles hacen que esta comparación sea honesta. La temperature a cero elimina la aleatoriedad, de modo que las diferencias que veas son del modelo y no del muestreo. El mismo max_tokens y la misma instrucción para todos evitan comparar peras con manzanas. Y guardar la salida completa, no solo el veredicto, te permite leer en qué se equivoca cada uno: muchas veces descubrirás que el modelo pequeño no falla la tarea sino el formato, y que eso se arregla con dos frases más en el mensaje de sistema en lugar de con un modelo cuatro veces más caro.