Los modelos pequeños de ScaleDown para tareas rutinarias dentro de la aplicación: clasificar, extraer, resumir

El 13 de octubre de 2026, ScaleDown desveló tres pequeños modelos específicos de tareas que vende como una sola idea: Classify, Extract y Summarize, cada uno diseñado para el trabajo repetitivo que rodea a una llamada a un LLM en producción más que para la conversación. Los tres aceptan una entrada de 1M tokens, los tres aceptan texto o imágenes, y se puede acceder a los tres a través de la propia API de ScaleDown — y aquí es donde la cuestión de los precios se vuelve interesante, porque los tres tienen formas de coste completamente distintas. El cuarto modelo de la familia, ScaleDown Compress, figura en la documentación del proveedor como una herramienta de recorte de contexto, más que como uno de los tres nuevos. Lo que sigue es lo que documenta el proveedor, mantenido aparte de lo que nadie ha reproducido todavía.

¿Qué se lanzó realmente el 13 de octubre?

ScaleDown lleva algún tiempo operando un endpoint de Decisions — una interfaz de puntuación estructurada que toma un objeto de estado más un mapa de preguntas tipadas y devuelve probabilidades calibradas. El anuncio del 13 de octubre es el punto en el que la empresa empezó a vender los modelos subyacentes como productos por derecho propio en lugar de como un único endpoint, y en el que comenzó a describirlos como componentes de propósito general para trabajo dentro de la aplicación.

Los tres modelos y sus contratos, tal como los documenta el proveedor:

• ScaleDown Classify — asigna texto a un conjunto de etiquetas que proporciona el llamador. Cada etiqueta lleva un nombre y una rúbrica, que la documentación denomina "una pregunta de sí/no que el modelo utiliza para puntuar la etiqueta", y que la documentación describe como la parte más importante de la solicitud. El modo de etiqueta única devuelve una distribución softmax que suma 1.0 más una etiqueta principal; el modo multietiqueta puntúa cada etiqueta de forma independiente contra un umbral establecido por el llamador.

• ScaleDown Extract — extrae campos estructurados de texto no estructurado. En la documentación de la familia, este es el modelo que convierte un documento en un registro que tu código puede indexar.

• ScaleDown Summarize — resúmenes abstractivos breves de entradas largas, que es la tarea a la que más obviamente apunta la ventana de 1M de tokens.

El contrato compartido entre los tres es la parte que vale la pena dejar por escrito. Un millón de tokens de entrada por solicitud está aproximadamente un orden de magnitud por encima de lo que aceptan las API medianas convencionales, y es la cifra que hace que Summarize y Extract sean plausibles para trabajar con documentos completos sin una capa de fragmentación. La entrada de texto o imagen importa para Extract en concreto: entra una factura escaneada o una captura de pantalla de un formulario, salen campos, y no hay ningún paso de OCR entre ellos. Los tres se sirven desde la propia API de ScaleDown, cuya documentación indica que la URL base es span>api.scaledown.xyz/span> y deja claro que span>api.scaledown.ai/span> no es un host de API.

El único número que no es como los demás

El precio es donde estos tres dejan de ser intercambiables. Classify figura a $0,05 por millón de tokens de entrada y $0 por millón de tokens de salida, y el listado del modelo en catálogos de terceros muestra esa misma tarifa con un descuento promocional aplicado en ocasiones; el descuento no es un compromiso de ScaleDown y no debería tenerse en cuenta para la planificación. El precio cero de salida no es un truco de marketing: un clasificador puntuado mediante rúbrica emite etiquetas y probabilidades, no texto generado, así que no hay nada que facturar. Extract y Summarize sí generan salida, por lo que sus estructuras de costos no son comparables con las de Classify y deberían cotizarse directamente con el proveedor en lugar de inferirse a partir de la tarifa del clasificador.

El detalle de facturación de Classify es más difícil de razonar que la tarifa anunciada. En el modo de etiqueta única, cada etiqueta y su rúbrica entran en una sola llamada al modelo, por lo que cada etiqueta que añades incrementa los tokens de entrada facturados; pedir una explicación de una frase sobre la elección los vuelve a enviar al doble, y la documentación dice claramente que la explicación se genera después de que se fija la etiqueta principal, por lo que justifica la respuesta en lugar de cuestionarla. En el modo multietiqueta, cada etiqueta es una llamada al modelo separada, y cada fragmento se puntúa por separado. Una taxonomía de sesenta etiquetas con razonamiento activado, por lo tanto, no es una operación de $0,05 por millón de tokens en el sentido que asume un lector; es esa tarifa multiplicada por el conjunto de etiquetas y, después, duplicada si el razonamiento está activado. Los límites máximos documentados —20 etiquetas por solicitud, 16 en modo multietiqueta, 50 fragmentos por lote— son las restricciones prácticas que hay que considerar al diseñar.

Hay un comportamiento documentado adicional que importa más que cualquiera de estos límites. El clasificador «siempre devuelve un ganador», incluso cuando no encaja ninguna etiqueta. El filtrado por confianza se deja por completo a quien realiza la llamada. En una solicitud con 10 etiquetas, una puntuación máxima de 0.4 aún puede ser la respuesta correcta, porque las puntuaciones son relativas dentro del conjunto de etiquetas en lugar de absolutas. Todo uso en producción de este modelo necesita su propia política de umbral, y una etiqueta comodín — la documentación sugiere nombrar una span>other/span> — no es opcional en la práctica.

Por qué una ventana de 1M de tokens en un clasificador es la parte interesante

Los modelos clasificadores convencionalmente toman entradas cortas. La razón es mecánica: un clasificador puntuado por rúbricas tiene que sopesar toda la entrada frente a la pregunta de sí/no de cada etiqueta, y el coste de puntuar un documento de cien mil tokens contra veinte rúbricas es veinte pasadas completas sobre ese documento. La respuesta de ScaleDown es la ventana de 1M más la capa de batching —hasta 50 fragmentos puntuados contra un perfil compartido en una sola solicitud—, y la afirmación del proveedor es que la calibración por fragmento es la misma tanto si envías un fragmento como cincuenta, con la única diferencia de que el perfil compartido se factura una vez por solicitud.

Esa afirmación es la que hay que probar antes de construir sobre ella. También es la afirmación que hace que el modelo sea interesante: la razón principal para clasificar dentro de la aplicación en lugar de en el borde es que la decisión puede ver el contexto completo —todo el hilo de soporte, el contrato completo, el documento recuperado completo— en lugar de una ventana truncada. Si la ventana de 1M se sostiene con tus tamaños de entrada, la pregunta de arquitectura («¿necesito un esquema de fragmentación y votación?») desaparece en gran medida. Si no, tienes un clasificador de entradas cortas muy barato y un segundo problema que resolver.

Las afirmaciones que necesitan una segunda opinión

El marketing de ScaleDown sostiene que los modelos de lenguaje pequeños específicos para tareas superan a los modelos de frontera en costo, velocidad y precisión para trabajo repetitivo de alto volumen, y cita cifras que incluyen un modelo de aproximadamente medio billón de parámetros que alcanza el 91,7 % en una tarea de clasificación simple frente al 88,6 % de un modelo de 72 mil millones de parámetros. Esas son las cifras del propio proveedor y no han sido reproducidas de forma independiente: ScaleDown Classify actualmente figura sin puntuación en las tablas de clasificación públicas, sin filas de referencia de terceros publicadas. Trata el argumento de la precisión como una hipótesis con un mecanismo plausible —la brecha de eficiencia de muestreo entre un modelo pequeño entrenado para un propósito específico y uno grande de propósito general en una taxonomía estrecha es real y está bien documentada—, no como un resultado establecido.

La cifra de entrada de 1 millón de tokens también está declarada por el proveedor. Los listados de catálogos de terceros para el modelo muestran la longitud de contexto como no aplicable en lugar de repetir el número de un millón de tokens, lo cual es una limitación del catálogo más que una contradicción, pero sí significa que la ventana no ha sido corroborada fuera de la documentación de ScaleDown.

Dónde encaja esto si ya tienes un pipeline en funcionamiento

El patrón al que apuntan estos tres modelos es un bucle, no una sola llamada: recuperar un documento, clasificarlo, extraer campos, resumirlo y luego entregar el resumen a un modelo generativo que escribe la respuesta. El cuarto paso es el costoso por token, y es el paso que cubre OrcaRouter: más de 200 modelos detrás de una sola clave compatible con OpenAI a precio de lista del proveedor traspasado con 0% de margen, con conmutación por error automática cuando se degrada una ruta de servicio. No alojamos ScaleDown Classify, Extract ni Summarize; no están en nuestro catálogo y no son un destino de chat-completions, y la capa de enrutamiento aquí es la mitad de generación del patrón, no la mitad de puntuación.

Esa división merece decirse sin rodeos porque la comparación de costos a la que la gente recurrirá es engañosa. Un clasificador puntuado con rúbrica a unos pocos centavos por millón de tokens de entrada y un modelo generativo a unos pocos dólares por millón no son competidores; son partidas distintas, y la razón para poner un modelo pequeño en el paso de clasificación es que te permite costear un modelo mejor en el paso que realmente escribe algo.

¿Qué cambiaría esta evaluación?

Tres cosas, en orden de cuánto cambiarían el panorama. Una evaluación independiente de la tarea de clasificación evaluada con rúbrica en un benchmark público convertiría el argumento de precisión de una afirmación del proveedor en un dato. Una cifra de latencia publicada —el proveedor documenta los factores de costo pero no la latencia de servicio— resolvería si la ventana de 1M es utilizable en rendimiento o solo en lote. Y una reproducción por terceros de la afirmación de calibración por fragmento decidiría si un lote de cincuenta fragmentos es una optimización de costos o un modelo diferente. Hasta que al menos uno de esos se materialice, el resumen honesto es que ScaleDown ha lanzado tres modelos con contratos inusualmente claros y límites de entrada inusualmente grandes, a precios que hacen que una etapa de clasificación basada en umbrales sea lo suficientemente barata como para considerarla, y que las cifras que los respaldan son del propio proveedor.

La versión corta

Si tienes una etapa de clasificación o extracción de gran volumen con una taxonomía estable y entrada de texto o imágenes, los tres modelos de ScaleDown merecen una evaluación comparativa con tus propios datos esta semana, porque el contrato es simple y el límite de entrada es generoso. Presupuesta la multiplicación de etiquetas y el recargo por razonamiento 2x antes de comprometerte con una taxonomía, y espera tener que definir tu propio umbral de confianza. Si tu tarea es generación abierta, nada de esto está pensado para ti.

La elección de modelos también es una cuestión de lo que ha salido mal antes: los incidentes de IA documentados y los fallos de agentes que hay detrás de los modelos de esta clase se recopilan en el OrcaRouter AI Incident Archive, donde cada entrada lleva sus propias fuentes, gravedad, grado de confianza e indicador de disputa.