Strands Decider 2B: el modelo open source de AWS que decide sin escribir texto

AWS publicó Strands Decider 2B, un modelo de decisión open source de 1.900 millones de parámetros que no genera texto: elige entre opciones, puntúa en una escala y devuelve una confianza calibrada en unos 115 milisegundos, en tu propia máquina. No es un LLM más pequeño. Es un tipo de modelo distinto, con una cabeza de punteros en lugar de una cabeza de lenguaje, y esa diferencia explica tanto sus números como sus límites.

Respuesta rápida

Qué es: un decision model (también llamado system one model) que sustituye la generación de texto por una decisión entre opciones prefijadas.
Tamaño: 1.900 millones de parámetros. Cabe en una GPU de consumo y también en un Mac con Apple silicon.
Latencia: mediana de 115 ms por decisión en una RTX 3090 bajo WSL2, percentil 95 de 299 ms. En un M3 Pro, mediana de 153 ms en tareas de menos de 300 tokens.
Precisión: 0,723 (167 de 231 tareas) en el conjunto público de JevBench v1.
Calibración: Brier 0,342 y error de calibración esperado de 0,052.
Confianza utilizable: en tareas cortas de clasificación que el modelo nunca había visto, las respuestas con confianza 0,9 o superior aciertan alrededor del 95% de las veces.
Licencia: Apache 2.0, con pesos, datos de entrenamiento y scripts de entrenamiento publicados.
Límite honesto: no programa, no resume y no conversa. Es peor que un modelo de razonamiento en problemas complejos, por diseño.

Qué es un decision model y por qué aparece ahora

La categoría estaba viva como curiosidad y en pocas semanas pasó a ser tendencia. AWS lo dice explícitamente en el anuncio del 1 de octubre de 2026: Strands Decider es «una de una nueva clase de modelos de decisión, o system one models, un tipo de modelo que ha ganado mucha atención desde el lanzamiento de Jev por TypeSafe AI a principios de este mes».

El intercambio es directo y conviene entenderlo antes que nada. Un LLM produce texto libre token a token y cuesta en proporción a lo que genera. Un decision model no puede escribir: solo elige entre las opciones que le das, o devuelve una puntuación. En esa restricción están su velocidad y su precio.

	LLM	Decision model
Salida	Texto libre generado token a token	Una de las opciones ofrecidas, o una puntuación
Coste por decisión	Alto, escala con la longitud generada	Bajo, una sola pasada hacia adelante
Flexibilidad	Máxima	Muy reducida, solo puede elegir entre lo que le das
Calibración	No expuesta por las APIs de inferencia	Cada decisión trae su confianza
Tareas típicas	Código, chat, resúmenes, razonamiento	Routing, triage, guardarraíles, selección de herramientas

El blog oficial resume la contrapartida sin adornos: a cambio de esa pérdida de flexibilidad, los decision models son más rápidos y más capaces para un tamaño dado, siempre devuelven una respuesta de entre las opciones ofrecidas, y pueden funcionar con latencia muy baja. El reverso es que su incapacidad de generar texto los hace inadecuados para programación, chatbots y resumen de documentos.

Esa última frase explica por qué no estás leyendo sobre un sustituto de GPT. Es una pieza distinta del sistema, y por eso el repositorio del Transformers ejecutando cuantizaciones de llama.cpp sigue siendo la ruta para correr un LLM entero en local: aquí no hay LLM que cuantizar.

La arquitectura: quitar la cabeza de lenguaje y poner una cabeza de punteros

Aquí está la idea técnica central, y es elegante por lo simple que es. Se toma un torso de LLM decodificador ya preentrenado, Qwen3.5-2B-Base, y se descarta su cabeza de modelado de lenguaje. Eso elimina la capacidad de generar texto. En su lugar se coloca una cabeza de punteros de poco más de un millón de parámetros, que puntúa cada opción comparando el estado oculto en la posición <answer> contra el estado oculto en el último token de esa misma opción.

El torso se adapta con un adaptador LoRA de rango 16 y la cabeza corre en fp32. El resultado es una sola pasada hacia adelante, sin generación y sin bucle de decodificación.

La consecuencia de diseño importante está en lo que la cabeza no tiene. Como no hay parámetros por opción, nada puede aprender que «la primera opción suele ser la correcta», nada limita cuántas opciones puede llevar una pregunta, y los conjuntos de etiquetas los define la petición, no los pesos. Ese es el punto que separa esta arquitectura de un clasificador tradicional entrenado sobre un espacio fijo.

De los tres tipos de pregunta salen del mismo masked softmax, solo que se leen de forma distinta: noul (sí o no), choice (una de N) y score (una rúbrica ordenada).

Instalar y probar

La instalación es una línea:

pip install strands-decider

Elegir entre opciones

strands-decider ask StrandsAgents/strands-decider-2B-hobson-v19 \
  --state "Help! My payouts have been failing for 3 days! " \
  --choice "Which team should handle this?=billing,sales,retail"

choice_0 -> billing (confidence 0.768)
  billing                  0.845
  retail                   0.091
  sales                    0.064

Preguntar sí o no

strands-decider ask StrandsAgents/strands-decider-2B-hobson-v19 \
  --state "Help! My payouts have been failing for 3 days! " \
  --noul "Does this convey urgency?"

Salida:

noul_0 noul = 0.828

Más cerca de 1 se inclina hacia «sí».

Puntuar en una escala

strands-decider ask StrandsAgents/strands-decider-2B-hobson-v19 \
  --state "Help! My payouts have been failing for 3 days! " \
  --score "How frustrated is the writer?=calm,frustrated,depressed"

score_0 score = 1.10 (confidence 0.518)
  0: calm                                     0.163
  1: frustrated                               0.573
  2: depressed                                0.265

Preguntar varias cosas a la vez

Puedes combinar tipos de pregunta en un solo comando, y es la vía recomendada. El motivo es económico y no es un detalle menor: el texto se lee una sola vez y cada pregunta posterior solo añade sus propios tokens. La documentación del repositorio lo resume como que preguntar muchas preguntas es casi gratis.

strands-decider ask StrandsAgents/strands-decider-2B-hobson-v19 \
  --state "Help! My payouts have been failing for 3 days! " \
  --choice "Which team should handle this?=billing,sales,retail" \
  --noul "Does this convey urgency?" \
  --score "How frustrated is the writer?=calm,frustrated,depressed"

noul_0 noul = 0.829
choice_0 -> billing (confidence 0.769)
  billing                  0.846
  retail                   0.090
  sales                    0.064
score_0 score = 1.10 (confidence 0.519)
  0: calm                                     0.163
  1: frustrated                               0.574
  2: depressed                                0.263

Servirlo como endpoint

strands-decider serve StrandsAgents/strands-decider-2B-hobson-v19 --port 8000

curl -s localhost:8000/v1/systemone \
  -H 'content-type: application/json' \
  -d '{
    "state": "Help! My payouts have been failing for 3 days!",
    "questions": {
      "is_urgent": {"type": "noul", "instructions": "Does this convey urgency?"}
    }
  }'

{
  "model": "strands-decider-2B-hobson-v19",
  "answers": { "is_urgent": { "type": "noul", "noul": 0.8277 } },
  "usage": { "input_tokens": 86, "output_tokens": 1 },
  "latency_ms": 140.03
}

Fíjate en output_tokens: 1. Esa es toda la diferencia entre esto y una llamada a un LLM.

Rendimiento: los tres números que importan

Para esta clase de modelo hay tres objetivos, y conviene mirarlos por separado porque no cuentan lo mismo.

Precisión. En el conjunto público de JevBench v1, 231 tareas, v19 obtiene 0,723, es decir 167 aciertos de 231.
Calibración. Brier de 0,342 y error de calibración esperado de 0,052. Esto segundo es lo que hace que la confianza sea accionable: en tareas cortas de clasificación no vistas previamente, las respuestas con confianza 0,9 o superior son correctas alrededor del 95% de las veces.
Latencia. Mediana de 115 ms por pregunta en RTX 3090 bajo WSL2, con percentil 95 de 299 ms. En Apple silicon, un M3 Pro da medianas de 153 ms en tareas de menos de 300 tokens y 234 ms en todas las tareas. La latencia crece aproximadamente de forma lineal con el tamaño de la tarea.

Medición	v19
JevBench v1 público, 231 tareas, precisión	0,723 (167 de 231)
Brier / error de calibración esperado	0,342 / 0,052
Niveles fácil / estándar / difícil	1,000 / 0,875 / 0,505
Latencia RTX 3090 (WSL2), mediana / p95	115 ms / 299 ms
Latencia M3 Pro, mediana en caliente	153 ms / 234 ms
Entrenamiento	~11 h en una RTX 3090; 1 h 10 min en 8×H100

Posición en el ranking. Tercero de 33 en la clase de 2B, y primero de 30 excluyendo los modelos que apenas superan los 2B, según el tablero público de Benchmark Heaven.

El desglose por niveles merece atención porque es donde se ve el perfil real del modelo: 1,000 en el nivel fácil, 0,875 en el estándar y 0,505 en el difícil. AWS lo dice sin rodeos en el blog: acierta el 100% de las tareas fáciles de JevBench. Ese es exactamente el perfil que interesa en un agente, donde la mayoría de las decisiones son mecánicas y unas pocas son difíciles.

Qué se hace con esto dentro de un agente

El repositorio incluye un ejemplo trabajado dentro de un agente Strands, en examples/strands/, y el escenario es más interesante de lo que parece.

La idea: un agente con una herramienta get_weather y un system prompt deliberadamente lanzado, de modo que si el usuario pregunta «¿Qué tiempo hace?» sin decir dónde, el agente inventa una ciudad y llama a la herramienta igualmente. Antes de que esa llamada se ejecute, Strands Decider lee la conversación y la llamada propuesta, y responde dos preguntas de sí o no:

¿Están los valores de los argumentos fundamentados en algo que el usuario dijo realmente?
¿Es prematuro llamar a esta herramienta antes de pedir aclaración?

Unas pocas líneas de Python convierten las predicciones en una decisión, y el agente vuelve a preguntar «¿a qué ciudad te referías?» en lugar de informar con confianza del tiempo en un sitio que nadie mencionó.

QUESTIONS = {
    "args_grounded": Decider.noul(
        "Are the tool's argument values grounded in facts the user actually provided?",
        {
            "true": "every argument value traces back to something the user said",
            "false": "an argument value was guessed or invented, not stated by the user",
        },
    ),
    "premature": Decider.noul(
        "Is it premature to call this tool now, before clarifying with the user?",
        {
            "true": "the assistant should ask a clarifying question before calling the tool",
            "false": "there is nothing left to clarify; calling now is appropriate",
        },
    ),
}

El patrón encaja en el sistema de intervenciones de Strands: un InterventionHandler con un método before_tool_call, que se pasa a Agent(interventions=[...]) y se ejecuta antes de que corra cualquier herramienta. Lo que devuelve es una acción tipada: Proceed, Deny, Confirm (parar y preguntar a una persona) o Guide, que devuelve el turno al modelo con feedback en lugar de bloquear la llamada.

Un matiz importante del propio equipo: el handler es una clase de Python y Strands no tiene opinión sobre qué va dentro. La misma forma sirve para llamar a su modelo de decisión, a una política Cedar o a otro agente. Las preguntas, el umbral y la política del ejemplo se eligieron a mano. Es una ilustración, no una recomendación.

La frase que resume el argumento comercial de todo el lanzamiento está en el blog: una decisión tan barata puede vivir en un camino donde una llamada a un LLM nunca podría.

El resto de casos de uso que reportan:

Model routing — elegir el LLM adecuado para cada tarea
Selección de herramienta — decidir qué herramienta debería invocar el agente a continuación
Verificación de argumentos — comprobar los argumentos de una llamada antes de que se ejecute
Triage — enrutar una petición entrante al equipo o a la cola que le corresponde
Guardarraíles — comprobaciones de fundamentación, clasificación de seguridad y de política
Evaluaciones — puntuar salidas de modelos y comprobar si una respuesta es adecuada, a bajo coste
Agentes híbridos — dejar que el LLM tome las decisiones difíciles y el decider las rutinarias, reduciendo coste y latencia

También se usan para jugar, automatizar tareas y navegar laberintos. La velocidad de innovación en este espacio, dice AWS, es asombrosa.

Las honestidades que el propio repositorio documenta

Esta es la parte que casi ningún anuncio incluye, y es la que hace el lanzamiento evaluable. El registro de investigación del repositorio es inusualmente honesto:

231 tareas son pocas. Seis reentrenamientos de la receta v17 dieron una desviación típica de 3,2 tareas. La regla práctica que da el repositorio: trata como no resuelto cualquier diferencia de menos de unos 10 tareas entre dos ejecuciones.
La receta publicada usa ventana de 4096 tokens, no los 3072 con los que se fijó el resultado de JevBench. En 4096, v19 puntúa 168 en lugar de 167. La diferencia es ruido, y el repositorio lo dice.
v20 no desplazó a v19. El experimento más reciente sacó 169 de 231 en ventana 4096 frente a 168 de v19, dentro del ruido de reentrenamiento, y además falló cuatro de sus predicciones. Sigue siendo v19 el modelo de referencia.
La primera iteración de la arquitectura fue un fracaso. Usaba una slot head que mapeaba el estado oculto final a un conjunto fijo de slots, y rendía significativamente peor. La pointer head actual es el segundo intento.
Cinco ejecuciones se promovieron igualmente. Desde v9, cada ejecución declara sus predicciones y sus condiciones de fallo antes de entrenar, y el resultado se añade después sin editar lo anterior. Por esa regla, una ejecución que no alcanza su marca no sustituye al modelo de referencia. Aun así, cinco ejecuciones fueron promovidas por decisión de los mantenedores, y el registro lo indica de forma explícita.

Ese es un estándar sano para un repositorio de investigación. Vale la pena comprobar que el modelo que adoptas ha pasado por ahí y no por debajo.

Strands Decider 2B frente a Jev

Ponerlos lado a lado ayuda a entender qué elegir:

	Strands Decider 2B	Jev (TypeSafe AI)
Acceso	Pesos, datos y scripts abiertos, Apache 2.0	Solo API
Ejecución	Local, CPU o GPU	Nube
Parámetros	1,9 B	No documentados públicamente

La diferencia decisiva es de integración, no de calidad. Jev llegó primero y AWS responde con apertura: pesos, datos de entrenamiento, scripts y licencia Apache 2.0. Si tu requisito es privacidad, cumplimiento o control de la cadena de suministro, esa diferencia no se compensa con la facilidad de consumo de una API.

Cómo decidir si te sirve

Te sirve si tienes un agente con muchísimas decisiones mecánicas: rutas de herramientas, triage de entradas, guardarraíles antes de llamadas caras, clasificación de políticas, o evaluaciones masivas donde cada euro cuenta.
Te sirve como punto de partida si quieres construir un clasificador propio y te da miedo el esfuerzo: entrenarlo y calibrarlo requiere el mismo tiempo y pericia que un LLM pequeño, pero aquí ya viene hecho.
No te sirve si necesitas generar texto: código, resúmenes, respuestas conversacionales o cualquier cosa que requiera redactar. El modelo no puede, no es cuestión de calidad.

Una advertencia práctica sobre la ventana de contexto: la receta publicada usa 4096 tokens. Es un modelo de decisión, no de comprensión larga. Si tu estado es largo, resume antes.

Preguntas frecuentes

¿Qué es Strands Decider 2B?

Un modelo de decisión open source de 1.900 millones de parámetros publicado por AWS el 1 de octubre de 2026. No genera texto: elige entre las opciones que le das, puntúa sobre una escala y devuelve una confianza calibrada. Es la primera versión de la familia y funciona en local sobre CPU o GPU.

¿En qué se diferencia de un LLM?

Un LLM genera texto libre token a token. Strands Decider sustituye la cabeza de modelado de lenguaje por una cabeza de punteros de poco más de un millón de parámetros que puntúa las opciones en una sola pasada hacia adelante, sin generación ni bucle de decodificación. A cambio pierde la flexibilidad de redacción y gana latencia, coste y una confianza calibrada que las APIs de inferencia de LLM no exponen.

¿Puede escribir código o mantener una conversación?

No. Su incapacidad de generar texto lo hace inadecuado para programación, chatbots y resumen de documentos, y el propio blog de AWS lo dice de forma explícita. Para esas tareas necesitas un LLM.

¿Qué significa que la confianza esté calibrada?

Que el número que acompaña a cada respuesta significa algo. En tareas cortas de clasificación no vistas previamente, las respuestas con confianza 0,9 o superior son correctas alrededor del 95% de las veces. Eso permite fijar umbrales con criterio: por encima de 0,9 actuar, por debajo confirmar con una persona. En JevBench v1 el modelo logra un Brier de 0,342 y un error de calibración esperado de 0,052.

¿Qué hardware necesito?

El modelo tiene 1.900 millones de parámetros y se sirve en una RTX 3090 con mediana de 115 ms por decisión, pero también funciona en un Mac con Apple silicon: un M3 Pro da medianas de 153 ms en tareas de menos de 300 tokens. Reentrenar la receta completa exige un host Linux o WSL2 con GPU NVIDIA: unas 11 horas en una RTX 3090 de 24 GiB, o 1 hora y 10 minutos en ocho H100 con FAST=1.

¿Cuál es su precisión y su latencia?

En el conjunto público de JevBench v1 (231 tareas) alcanza 0,723 de precisión, es decir 167 aciertos. Por niveles: 1,000 en fácil, 0,875 en estándar y 0,505 en difícil. La latencia mediana es de 115 ms en RTX 3090 bajo WSL2, con percentil 95 de 299 ms. Ojo con el margen: seis reentrenamientos de una versión anterior dieron una desviación de 3,2 tareas, así que el propio repositorio pide tratar como no resuelto cualquier diferencia de menos de unos 10 tareas.

¿Qué licencia tiene? ¿Puedo usarlo en producción?

Apache 2.0. Y no solo los pesos: el repositorio publica también los datos de entrenamiento, los scripts de entrenamiento y la documentación de las fuentes con sus licencias. Puedes servirlo, usarlo y reentrenarlo.

¿Cómo se integra en un agente?

El repositorio incluye un ejemplo en examples/strands/ que usa un InterventionHandler con un método before_tool_call. Antes de que se ejecute una herramienta, Strands Decider responde preguntas de sí o no sobre si los argumentos están fundamentados en lo que el usuario dijo y si es prematuro llamar a la herramienta. Las predicciones se convierten en acciones tipadas: Proceed, Deny, Confirm o Guide. En el ejemplo, el agente deja de inventar una ciudad y pregunta cuál.

¿Strands Decider 2B o Jev, cuál elijo?

Depende de dónde tengas que ejecutarlo. Jev, de TypeSafe AI, se consume como API y ofrece la experiencia más simple. Strands Decider 2B se ejecuta en tu propia máquina con licencia Apache 2.0 e incluye pesos, datos y scripts. Si tus requisitos incluyen privacidad, cumplimiento o control de la cadena de suministro, esa diferencia pesa más que la facilidad de consumo.