12°
Portada del artículo: Strands Decider 2B como juez de mis planos: 37 ms, y una regla de palabras lo empata
IABenchmarksInferencia local

Strands Decider 2B como juez de mis planos: 37 ms, y una regla de palabras lo empata

Medí Strands Decider 2B como juez sobre 75 planos: con choice llega a AUC 0,91 en 34 ms por juicio, contra 0,99 de Claude Opus; una regla simple llegó a 0,90. Con su primitivo por defecto, noul, no atrapó ni uno de los 31 planos genéricos; el checkpoint v21 no lo mejora, y la repetición entre planos, que era mi falla real, la detectan todos. Datos, etiquetas y scripts publicados.

Efrain Garay 7 de octubre de 2026

Reproduciendo el resumen

Mi pipeline de videos cortos tiene un paso que escribe la lista de planos antes de renderizarlos. Cuando ese paso lo hace un modelo local chico, falla de una forma concreta: pega la misma escena en los diez planos, o devuelve solo el prefijo de estilo sin escena. El resultado es un video de una sola imagen. Quería una compuerta que lo detectara antes de gastar la tarjeta en renderizar.

La respuesta habitual es poner un LLM de juez. Funciona, pero cada juicio cuesta y tarda. Así que probé otra categoría: los decision models, modelos que no escriben texto y devuelven directamente una probabilidad. El candidato fue Strands Decider 2B, 2.000 millones de parámetros, licencia Apache-2.0.

Con narración: tres bots juzgan los mismos planos. El de 2B responde en 37 ms pero deja pasar todos los genéricos con su umbral; el LLM tarda un segundo y medio y separa casi perfecto; una regla de palabras empata con el de 2B. Todas las cifras son las medidas.Verlo en el visualizador de reels →

Mi primera prueba no servía, y una regex lo demostró

La primera versión de este artículo usaba ocho descripciones de planos escritas a mano, cuatro fuertes y cuatro genéricas. El decision model acertó las ocho en 33 ms; Opus siete, Haiku seis y MiniMax cuatro. Parecía un resultado limpio.

Una auditoría externa lo desarmó con tres líneas de código. Los ocho negativos decían, literalmente, “genérico”, “intercambiable” o “sin sujeto”. Una expresión regular que busca esas palabras también acierta ocho de ocho. El banco medía si el texto se declaraba genérico, no si el plano lo era.

Qué es un decision model y cómo lo puse a juzgar

Un decision model recibe un estado y una pregunta, y en vez de escribir una respuesta devuelve números: la probabilidad de un sí (noul), una elección entre opciones con su probabilidad (choice) o un puntaje. No hay texto que parsear, y por eso responde en milisegundos. Ya había medido otro de la misma categoría, Intern-Decision prediciendo la lluvia sin entrenarlo.

Lo puse frente a dos tipos de rivales: LLM que se usan de juez y reglas que no usan ningún modelo.

Un plano, tres jueces de la misma familia de bots: una regla de palabras, el decision model de 2B local y un LLM en la nube, cada uno con su latencia, AUC y límite medidos▦planoreglasin modelo¿dice close-up, wide, tercio…?0 ms · AUC 0,90 · no ve el sujetoDecider 2Blocal{ "noul": 0,79 }37 ms · AUC 0,82 · su umbral 0,5 atrapa 0 de 31LLMnubetexto → parsear1,5 s · AUC 0,99 · ~1 centavo por llamadarepetición entre planos: la atrapan todos, y también un embedding gratis

El banco

75 descripciones de planos, en inglés porque así le llegan al generador de imágenes.

  • 22 de producción. Escenas que mi pipeline generó con el modelo grande en corridas reales, sacadas del checkpoint de Postgres donde queda el estado de cada corrida.
  • 41 de un modelo débil. Corrí el nodo real que escribe los planos con qwen2.5 14B y con gemma3 4B, con el prompt original sin mejorar, sobre ocho perfiles. Ahí aparecieron las tres fallas reales: la misma escena pegada diez veces, el prefijo de estilo sin escena, y sujetos de relleno como “un personaje” o “una figura misteriosa”. También aparecieron planos buenos: el modelo débil no se equivoca siempre.
  • 12 adversariales escritos a mano. Seis planos fuertes que contienen palabras trampa como same, typical o generic, y seis genéricos disfrazados de jerga de cámara sin sujeto ni acción.

La rúbrica. Anoté cada plano con tres rasgos: si nombra un sujeto concreto, si describe una acción o estado visible, y si fija una decisión de cámara (tamaño de plano, ángulo, posición en el cuadro o movimiento). Un plano es fuerte si tiene los tres. Quedaron 44 fuertes y 31 genéricos.

Los jueces. Strands Decider 2B con dos primitivos (noul y choice), qwen2.5 14B local, Claude Opus, Claude Haiku y MiniMax M3, más dos líneas base: el largo del texto y una regla que solo busca palabras de encuadre como close-up, wide shot o third. Todos reciben el mismo plano y la misma pregunta.

Tres tropiezos antes de los números

El CLI contaminaba al juez. Los LLM los llamé por línea de comandos, y por defecto la herramienta carga mi propio archivo de instrucciones: unos 22.000 tokens de contexto ajeno a la tarea. Con eso puesto, Haiku ni siquiera devolvió el JSON; respondió que necesitaba más contexto. Lo corrí en un modo limpio, sin configuración de usuario, con un prompt de sistema mínimo y una sola herramienta. El costo por juicio de Opus bajó de unos 15 centavos de dólar a 1,1.

Los 404 segundos de carga eran la descarga. En la primera prueba el modelo tardó 404 s en cargar y lo reporté como arranque en frío. Era la primera descarga de los pesos. Desde el disco carga en 10,7 s.

El modelo corrió con los kernels lentos. Al cargar, la librería avisa que faltan causal_conv1d y flash-linear-attention y que usa la implementación de referencia. No los instalé, así que los 37 ms son una cota conservadora.

Los números

JuezAUCGenéricos atrapadosBuenos rechazadosLatencia mediana
Claude Opus0,98830/312/441,52 s (API)
Claude Haiku0,94116/310/445,50 s (API)
MiniMax M30,93826/314/442,56 s (API)
Decider 2B v19 · choice0,90516/314/4434 ms (local)
Regla de encuadre0,90325/310/44~0
Decider 2B v21 · choice0,8817/310/4441 ms (local)
qwen2.5 14B local0,84913/312/44291 ms (local)
Decider 2B v19 · noul0,8190/310/4437 ms (local)
Decider 2B v21 · noul0,7500/310/4440 ms (local)
Largo del texto0,727no aplicano aplica0

El AUC mide qué tan bien ordena cada juez los planos fuertes por encima de los genéricos, sin depender del umbral; 1 es perfecto y 0,5 es azar. “Genéricos atrapados” y “buenos rechazados” usan el umbral 0,5, que es lo que haría una compuerta sin calibrar. Los intervalos de confianza del 95 %, de 2.000 remuestreos, están en el banco de abajo.

AUC sobre los mismos 75 planosAUC · más es mejor
  1. Claude Opus0,988IC 95 %: 0,962 a 1,000 · atrapa 30/31 · rechaza 2/44
  2. Claude Haiku0,941IC 95 %: 0,863 a 0,994 · atrapa 16/31 · rechaza 0/44
  3. MiniMax M30,938IC 95 %: 0,877 a 0,980 · atrapa 26/31 · rechaza 4/44
  4. Decider 2B v19 · choice0,905IC 95 %: 0,831 a 0,963 · atrapa 16/31 · rechaza 4/44
  5. Regla de encuadre0,903IC 95 %: 0,833 a 0,969 · atrapa 25/31 · rechaza 0/44
  6. Decider 2B v21 · choice0,881IC 95 %: 0,800 a 0,946 · atrapa 7/31 · rechaza 0/44
  7. qwen2.5 14B local0,849IC 95 %: 0,757 a 0,929 · atrapa 13/31 · rechaza 2/44
  8. Decider 2B v19 · noul0,819IC 95 %: 0,707 a 0,912 · atrapa 0/31 · rechaza 0/44
  9. Decider 2B v21 · noul0,750IC 95 %: 0,633 a 0,854 · atrapa 0/31 · rechaza 0/44
  10. Largo del texto0,727IC 95 %: 0,597 a 0,852 · sesgo del banco, no un juez

75 planos (63 capturados del pipeline, 12 adversariales), rasgos anotados antes de correr los jueces. Locales en una RTX 4070 Ti SUPER; LLM por su API en modo limpio.

Opus ordena casi perfecto y, con el umbral 0,5, atrapa 30 de los 31 genéricos rechazando solo 2 de los 44 buenos. Como todos los jueces juzgaron los mismos 75 planos, la comparación justa es por pares, remuestreando los planos juntos: Opus le saca 0,083 de AUC al 2B con choice (intervalo del 95 % entre 0,022 y 0,154), 0,084 a la regla (0,023 a 0,158) y 0,139 a qwen (0,054 a 0,233). Es el mejor juez del banco y la diferencia no es ruido.

El umbral que no viaja

El resultado que más me sorprendió es la fila de noul. Ordena de forma aceptable, AUC 0,82, pero con el umbral 0,5 no atrapa ningún plano genérico. Todas sus probabilidades quedaron entre 0,54 y 0,84: los genéricos entre 0,58 y 0,82, los fuertes con mediana 0,80. Todo cae a la derecha del umbral, y el genérico mejor puntuado queda por encima de la mitad de los fuertes.

Dónde deja cada juez los 75 planosCada punto es un plano; rojo = genérico, teal = fuerte según la rúbrica. La posición es la probabilidad de "fuerte" que le dio el juez.
0,00,250,50,751,0umbral 0,5Claude OpusAUC 0,99atrapa 30/31 · rechaza 2/44MiniMax M3AUC 0,94atrapa 26/31 · rechaza 4/44Claude HaikuAUC 0,94atrapa 16/31 · rechaza 0/44qwen2.5 14B localAUC 0,85atrapa 13/31 · rechaza 2/44Decider 2B · choiceAUC 0,91atrapa 16/31 · rechaza 4/44Decider 2B · noulAUC 0,82atrapa 0/31 · rechaza 0/44regla de encuadreAUC 0,90atrapa 25/31 · rechaza 0/44

genérico fuerte

En mi primera prueba, las mismas probabilidades separaban limpio, 0,71 a 0,74 contra 0,21 a 0,36. Esa separación era una propiedad de ocho frases fáciles en español, no del modelo. La propia ficha lo advierte: la calibración se ajustó sobre clasificación corta, “noul y score transfieren mal a rúbricas”, y hay que medir sobre el tráfico propio antes de confiar en un umbral.

Con choice, el primitivo sobre el que está ajustada su calibración, el modelo mejora: AUC 0,91 y atrapa 16 de 31 en 0,5. Si además se ajusta el umbral con ejemplos etiquetados, dejando cada plano fuera mientras se elige el corte con los otros 74, llega a 0,84 de exactitud balanceada. Sirve, pero exige etiquetar antes de usarlo.

Una regla de palabras lo empata

La regla de encuadre no usa ningún modelo: marca como fuerte cualquier plano que diga close-up, wide shot, third, centered o un movimiento de cámara. Llega a AUC 0,90, atrapa 25 de 31 genéricos y no rechaza ningún plano bueno.

La razón está en la rúbrica: un plano sin decisión de cámara nunca es fuerte, y esa parte la detecta un buscador de palabras. Lo que la regla no puede ver es el sujeto. Los 6 genéricos que se le escapan son prompts de solo estilo que mencionan “vertical framing” o “rule of thirds” sin decir qué hay en el cuadro. El largo del texto también predice algo, AUC 0,73, porque los planos buenos son más largos: es un sesgo del banco que conviene tener a la vista.

La repetición, que era mi falla real

La compuerta que motivó todo esto no era sobre planos sueltos sino sobre listas: el modelo débil que pega la misma escena diez veces. Un juez que recibe un plano a la vez no puede ver eso, porque cada plano por separado puede estar bien.

Armé 13 listas de cinco planos: 6 con escenas distintas de una misma corrida de producción, 6 con una escena repetida (copias exactas o paráfrasis leves) y la lista real que emitió qwen, “un héroe en pose dramática” cinco veces. A cada juez le pregunté si la lista repite la misma escena.

El decision model de 2B acertó las 13, igual que Opus y Haiku; MiniMax 12 y qwen 10. Un embedding de 300 millones de parámetros (embeddinggemma), comparando los planos entre sí, separó perfecto: todas las listas repetidas quedaron más parecidas por dentro que todas las distintas, sin ningún juez. La comprobación léxica que ya usa mi pipeline, contar escenas distintas por su texto, falló una de las paráfrasis.

Esta prueba fue fácil: las paráfrasis cambiaban pocas palabras. Lo que sí deja claro es que para la repetición no hace falta un LLM.

Velocidad, arranque y costo

Milisegundos por juicio, medianaLocales: misma GPU, mismo proceso, mismo cronómetro alrededor de la llamada, modelo ya cargado. LLM: latencia que reporta su API.
Decider 2B · choice34 ms
Decider 2B · noul37 ms
qwen2.5 14B291 ms

El 2B es 8 veces más rápido que el 14B en la misma tarjeta.

Claude Opus1520 ms
MiniMax M32561 ms
Claude Haiku5497 ms

Medido desde mi red; incluye ida y vuelta. Haiku salió más lento que Opus en las dos corridas.

Escala de animación distinta por escenario; las cifras impresas son las medidas.

El 2B responde en 37 ms y ocupa 3,7 GB de VRAM. qwen2.5 14B, en la misma tarjeta y con el mismo cronómetro, tarda 291 ms. Opus tarda 1,5 s de mediana por su API. Como el 2B carga en 10,7 s, se paga frente a Opus después de unos 7 juicios: tiene sentido como servicio que queda cargado, no como proceso que arranca para juzgar un plano y se apaga.

En costo, un juicio de Opus en modo limpio sale 1,1 centavos de dólar, de MiniMax 0,7 y de Haiku 0,6. Mil juicios con Opus son unos 11 dólares. En el 2B, la tarjeta consumió unos 200 W mientras inferían los modelos locales: 37 ms son unos 7 joules por juicio. Un millón de juicios gasta unos 2 kWh, del orden de 40 centavos de dólar a 0,20 dólares el kWh.

Lo que esta medición no dice

  • Las anotaciones las hice yo, con una rúbrica y antes de correr los jueces; la regla que las convierte en etiqueta la corregí después, como cuento arriba. Ocho planos quedaron marcados como casos frontera. Otro anotador podría mover algunos; las anotaciones están publicadas ítem por ítem.
  • 75 planos es un banco chico. Por eso todas las comparaciones del artículo son pareadas. El 2B con choice y la regla quedan a +0,001 de AUC (intervalo del 95 % entre −0,097 y 0,099): con estos datos no se distinguen, y tampoco el 2B con choice de qwen (+0,056, entre −0,029 y 0,147).
  • Una sola pregunta. Otra redacción podría mover a todos los jueces, en especial al 2B, cuya ficha dice que lee las preguntas con menos atención que los documentos.
  • Las latencias de los LLM no son comparables con las locales. Unas son de API con red incluida y las otras de una llamada local. Por eso la comparación limpia es la del 2B contra el 14B en la misma GPU.
  • La prueba de repetición fue fácil. Faltan listas con planos distintos pero parecidos, que es donde un juez de verdad se gana el sueldo.

Cuándo usaría cada uno

Para la repetición entre planos, una métrica y no un juez. El embedding o incluso la comparación de textos la detectan gratis y en milisegundos. El 2B también acierta si le paso la lista completa.

Para juzgar la calidad de cada plano con poco volumen, un LLM. Opus separó casi perfecto, y a un centavo por juicio un video de veinte planos cuesta veinte centavos.

Para mucho volumen o latencia crítica, una regla primero y el 2B después, calibrado. La regla de encuadre filtra lo evidente sin costo. El decision model solo aporta si uso choice y ajusto su umbral con planos etiquetados de mi propio pipeline; con su umbral de fábrica deja pasar todo.

El decision model es rápido, liviano y se instala con un pip install. Lo que no trae de fábrica es el criterio de mi rúbrica, y eso no lo compensa la velocidad.


Medido entre el 6 y el 7 de octubre de 2026. Locales en una RTX 4070 Ti SUPER de 16 GB con torch 2.14.1+cu130, strands-decider 0.1.0 (checkpoint StrandsAgents/strands-decider-2B-hobson-v19) y qwen2.5 14B por ollama. LLM por su API en modo limpio: claude-opus-5-5, claude-haiku-4-5-20251001 y MiniMax-M3, los identificadores que devolvió cada API. La primera prueba de ocho frases corrió antes en una RTX 2080 Ti alquilada con torch 2.7.1. El checkpoint hobson-v21 lo medí después, el mismo 7 de octubre, con el mismo harness y la misma GPU.

Preguntas frecuentes

¿Qué es Strands Decider 2B?

Un decision model: un adaptador LoRA sobre Qwen3.5-2B-Base, con licencia Apache-2.0, que no genera texto sino probabilidades tipadas. Le das un estado y una pregunta, y responde con un número (noul), una elección entre opciones (choice) o un puntaje (score). La ficha de hobson-v19, el checkpoint que medí, reporta 0,723 de exactitud en JevBench público (167 de 231 tareas); la de hobson-v21, publicado después, 0,762 (176 de 231).

¿Sirve como juez de calidad en lugar de un LLM?

En mi banco de 75 planos, no como reemplazo directo. Ordenó los planos con un AUC de 0,82 usando noul y 0,91 usando choice; Claude Opus llegó a 0,99, Claude Haiku a 0,94 y MiniMax M3 a 0,94. Una regla que solo busca palabras de encuadre llegó a 0,90. Es mucho más rápido y casi gratis, pero no juzga mejor.

¿Por qué no atrapó ningún plano genérico?

Porque con noul todas sus probabilidades quedaron entre 0,54 y 0,84, así que el umbral 0,5 acepta todo. La propia ficha advierte que noul y score transfieren mal a rúbricas y que hay que medir sobre el tráfico propio antes de confiar en un umbral. Con choice y un umbral ajustado sobre ejemplos etiquetados llegó a 0,84 de exactitud balanceada.

¿El checkpoint v21 cambia el resultado?

No. hobson-v21 sube en JevBench público de 167 a 176 de 231, pero sobre mis 75 planos ordena peor con noul (AUC 0,750 contra 0,819; diferencia pareada −0,069, con un intervalo del 95 % entre −0,137 y −0,010) y queda igual con choice (0,881 contra 0,905, sin diferencia significativa). Con su umbral por defecto y noul sigue sin atrapar ningún plano genérico.

¿Qué tan rápido es?

37 ms por juicio de mediana en una RTX 4070 Ti SUPER, con el modelo ya cargado. qwen2.5 14B en la misma GPU y con el mismo cronómetro tardó 291 ms. Claude Opus, por su API, 1,5 s de mediana. El 2B carga en 10,7 s desde el disco y ocupa 3,7 GB de VRAM.

¿Necesito una GPU para correrlo?

No necesariamente. Según su ficha corre en cuda, en mps (Apple Silicon) y en cpu. Yo solo lo medí en CUDA, así que las latencias publicadas son de GPU; en CPU serán mayores.

¿Puedo reproducir los números?

Sí. Los 75 planos, la rúbrica, las anotaciones ítem por ítem, las dos variantes de etiqueta, los scripts y las salidas crudas de los jueces están publicados; los datos también como dataset descargable con licencia CC-BY-4.0 en efraingaray.com/datasets/juez-decision-75/. Anoté los tres rasgos de cada plano antes de correr ningún juez; después descubrí que mi primera forma de convertir esos rasgos en fuerte o genérico no coincidía con la pregunta y la corregí. Publico las dos variantes y el orden de los jueces no cambia.

Fuentes

Comentarios

Todavía no hay comentarios. El primero es tuyo.

Se revisa antes de publicarse. El correo no se guarda ni aparece en ninguna parte.