DEV Community: 김민식/학생

ZTC (Zero-Token Confidence): juzgar una acción de IA leyendo el estado interno del modelo, con cero tokens extra

김민식/학생 — Tue, 06 Oct 2026 19:10:27 +0000

TL;DR

Cuando un agente de IA realiza una accion, alguien tiene que decidir si esa accion es confiable. La via habitual es preguntarle a otro modelo de lenguaje (un juez LLM), lo que cuesta tokens, latencia y a veces enviar datos fuera de tu red. ZTC (Zero-Token Confidence) toma otro camino: lee el estado interno del propio modelo que ya hizo la inferencia y, a partir de esas senales, estima la confianza de la accion sin generar un solo token extra.

En nuestras mediciones, ZTC alcanza un AUC de 0.7289, practicamente a la par del juez LLM de referencia (JEV, AUC 0.7350), pero resuelve cada decision en 0.06 s frente a 0.59 s del juez. Es casi un orden de magnitud mas rapido, con cero tokens de generacion adicional, y corre on premise / en red cerrada porque no necesita llamar a ningun servicio externo.

Esta es una nota de ingenieria sobre que es ZTC, por que leer el estado interno funciona, y cuando conviene usarlo frente a un juez LLM.

Que problema resuelve ZTC?

En cualquier sistema agentico serio hay un segundo bucle de control: el modelo propone una accion (una respuesta, una llamada a herramienta, una consulta) y un componente de verificacion decide si esa accion se ejecuta, se bloquea o se escala a un humano. Ese componente es el que convierte un demo en un producto.

El patron dominante hoy es el juez LLM: se toma la salida del modelo y se envia a otro modelo con un prompt del estilo "evalua si esta respuesta es correcta y segura". Funciona, pero tiene tres costos que se acumulan a escala:

Tokens. Cada juicio es otra inferencia completa. Si tu agente realiza miles de acciones por minuto, estas pagando dos modelos en lugar de uno.
Latencia. El juez agrega cientos de milisegundos a cada accion, justo en la ruta critica del usuario.
Superficie de datos. Si el juez es una API externa, cada decision implica sacar el contenido de tu red. En banca, salud o defensa eso suele ser inaceptable.

ZTC ataca los tres a la vez. En lugar de pedir una segunda opinion, aprovecha algo que el modelo ya produjo gratis durante la inferencia original.

Que es exactamente ZTC (Zero-Token Confidence)?

ZTC es un estimador de confianza que no genera texto. La idea central es simple de enunciar: cuando un modelo esta a punto de equivocarse, su estado interno se ve distinto a cuando esta seguro. Esa diferencia es medible.

Durante una inferencia normal, el modelo expone una enorme cantidad de senal que casi siempre se descarta: las distribuciones de probabilidad sobre el vocabulario en cada paso, la geometria de las representaciones internas, y los patrones de atencion. ZTC lee esas senales que ya existen y las convierte en un unico numero: la probabilidad de que la accion sea correcta.

El nombre lo dice todo. Cero tokens porque no hay generacion nueva: no se corre un segundo modelo, no se escribe un prompt de evaluacion, no se produce una sola palabra adicional. La parte de confianza es un clasificador ligero sobre esas senales internas, entrenado para separar acciones buenas de malas.

El contraste con el juez LLM es directo:

Dimension	Juez LLM (JEV)	ZTC
Como decide	Genera una evaluacion con otro modelo	Lee el estado interno del modelo original
Tokens extra	Una inferencia completa por decision	Cero
Latencia por decision	0.59 s	0.06 s
AUC	0.7350	0.7289
Red cerrada / on premise	Depende de donde este el juez	Si, por diseno

Que tan bueno es ZTC frente a un juez LLM?

La pregunta correcta no es "cual tiene mas AUC", sino "cuanta calidad cedo por cuanta velocidad gano". Los numeros:

AUC: ZTC 0.7289 contra JEV 0.7350. La diferencia es de 0.0061, menos de un punto porcentual. En la practica, las dos curvas se solapan.
Latencia: 0.06 s contra 0.59 s. ZTC es cercano a 10x mas rapido por decision.
Costo de tokens: cero contra una inferencia completa. A escala, esto es la mitad del gasto de computo del sistema de verificacion.

Dicho de otra forma: pagas una perdida de calidad despreciable y a cambio recuperas latencia, presupuesto de tokens y soberania de datos. Para la mayoria de los bucles de control en produccion, ese intercambio es claramente favorable.

# Esquema conceptual (ilustrativo) del bucle de verificacion.
# El juez LLM corre una segunda inferencia; ZTC reutiliza lo que ya existe.

# --- Via tradicional: juez LLM ---
salida = modelo.generar(prompt)              # inferencia 1
veredicto = juez_llm.generar(               # inferencia 2: tokens + latencia + datos fuera
    f"Evalua si esto es correcto: {salida}"
)
confianza = parsear(veredicto)

# --- Via ZTC: leer el estado interno ---
salida, estado = modelo.generar(prompt, exponer_estado=True)  # misma inferencia
confianza = ztc.puntuar(estado)              # clasificador ligero, 0 tokens generados

La clave del segundo bloque es exponer_estado=True: la senal que ZTC necesita se produce igualmente durante la inferencia. Solo hay que no tirarla.

Por que leer el estado interno funciona en absoluto?

Es razonable sospechar que un numero sin generar texto no puede competir con un modelo que razona en voz alta. La intuicion que lo explica es que el razonamiento del juez ya esta contenido, de forma comprimida, en la dinamica interna del modelo original.

Cuando el modelo esta seguro, concentra masa de probabilidad en pocos tokens y sus representaciones son estables. Cuando titubea, la distribucion se aplana, las representaciones se vuelven ambiguas y la senal se dispersa. Un juez LLM, en el fondo, vuelve a leer la misma salida para inferir esa incertidumbre. ZTC se salta el intermediario y mide la incertidumbre en la fuente.

Por eso el AUC queda tan cerca: ambos metodos miran la misma realidad subyacente. El juez la reconstruye con una segunda pasada cara; ZTC la observa directamente.

Cuando conviene ZTC y cuando un juez LLM?

ZTC no reemplaza todo. Es una herramienta con un perfil claro.

Usa ZTC cuando:

La verificacion esta en la ruta critica y la latencia importa.
El volumen de decisiones hace que duplicar inferencias sea caro.
Operas en red cerrada o on premise y no puedes sacar datos a un juez externo.
Necesitas un primer filtro barato que decida que acciones pasan y cuales se escalan.

Prefiere o combina con un juez LLM cuando:

Necesitas una explicacion legible de por que una accion se rechazo.
El dominio exige razonamiento multi paso sobre politicas complejas.
Estas en el borde de decision y quieres una segunda opinion cara solo para los casos dudosos.

El patron mas potente es en cascada: ZTC filtra barato y rapido la gran mayoria de acciones, y solo los casos cerca del umbral pasan a un juez LLM. Asi obtienes la velocidad de ZTC en el caso comun y la profundidad del juez donde de verdad hace falta.

Que significa que corra en red cerrada?

Significa que todo el bucle de verificacion vive donde ya vive tu modelo. ZTC no hace llamadas de red, no depende de una API de terceros y no envia contenido fuera de tu infraestructura. Para sectores regulados esto no es un detalle de rendimiento, es la condicion que determina si puedes desplegar el sistema o no. Un juez LLM alojado por un proveedor externo convierte cada decision en una transferencia de datos; ZTC la mantiene dentro de tus paredes.

FAQ

Que significa "cero tokens" exactamente?
Que ZTC no genera texto nuevo para decidir. No corre una segunda inferencia ni escribe un prompt de evaluacion. Reutiliza las senales que la inferencia original ya produjo, asi que el costo marginal en tokens de generacion es cero.

ZTC es menos preciso que un juez LLM?
Marginalmente. AUC 0.7289 frente a 0.7350, una diferencia de 0.0061. En casi cualquier bucle de control esa brecha se compensa de sobra con 10x menos latencia y cero tokens extra.

Necesito reentrenar mi modelo base para usar ZTC?
No. El modelo base no cambia. ZTC es un clasificador ligero que se entrena sobre las senales internas que el modelo ya expone durante la inferencia.

Funciona con cualquier modelo?
Funciona con modelos cuyo estado interno sea accesible en tu despliegue, que es el caso tipico cuando sirves pesos abiertos on premise. Con una API cerrada que solo devuelve texto, no tienes acceso a esas senales y ZTC no aplica.

Puedo usar ZTC y un juez LLM juntos?
Si, y suele ser lo ideal. ZTC como primer filtro rapido y barato, y un juez LLM reservado para los casos cerca del umbral de decision. Obtienes velocidad en el caso comun y profundidad donde importa.

Por que no usar simplemente la probabilidad del token de salida?
Porque es solo una de las senales disponibles y por si sola es ruidosa. ZTC combina varias senales del estado interno en un unico estimador calibrado, lo que explica que se acerque tanto al juez LLM.

Cómo correr un modelo de 180B sin GPU: POCKET-Darwin-180B en GGUF con llama.cpp

김민식/학생 — Tue, 06 Oct 2026 13:12:02 +0000

TL;DR

POCKET-Darwin-180B-GGUF es la versión cuantizada del modelo abierto Darwin-180B-RSI, pensada para correr sin GPU. Puntos clave para quien va a desplegarlo:

Pesa 111 GB en GGUF (el original en BF16 ocupa 360 GB) y se ejecuta con llama.cpp.
Hasta 21 tokens por segundo solo en CPU (1 socket, 16 hilos, 78.8 GB de RAM usada). En un portátil con RTX 5060 de 8 GB y 32 GB de RAM: 4.17 tok/s.
Misma precisión que el original: en MMLU-Pro (2,000 preguntas) ambos miden 87.65%, aunque el modelo esté en 4 bits.
Arquitectura MoE: 180B de parámetros totales, pero solo unos 3B activos por token (10 de 512 expertos).
Se descargan 4 archivos y arranca con una sola línea de comando.

Este artículo explica por qué funciona y cómo ponerlo en marcha.

¿Por qué un modelo de 180B cabe en un portátil?

La respuesta corta: la mayor parte del modelo no se usa en cada paso.

Darwin-180B-RSI es un modelo de mezcla de expertos (Mixture of Experts, MoE). Tiene 512 redes "expertas", pero para generar cada token un enrutador selecciona solo 10. De los 180,000 millones de parámetros, apenas unos 3,000 millones intervienen en el cálculo de cada token.

Esto cambia por completo las cuentas de despliegue. En un modelo denso de 180B tendrías que mover los 180B de parámetros por la memoria en cada token. Con MoE, el trabajo aritmético por token se parece más al de un modelo de 3B, aunque la capacidad total siga siendo la de un modelo enorme. El cuello de botella deja de ser el cómputo y pasa a ser dónde guardas los pesos y a qué velocidad los lees.

Ahí entra la cuantización. El original en BF16 ocupa 360 GB. La versión POCKET se construye sobre una cuantización de 4 bits ya validada por la comunidad, y solo la parte que el entrenamiento de autosuperación de VIDRAFT realmente modificó (alrededor del 3% del volumen total) se mantiene en alta precisión. El resultado: 111 GB en disco, repartidos en 4 archivos GGUF.

Con 111 GB tienes dos caminos:

Mini PC con 128 GB de RAM: el modelo entero entra en memoria y corre sin GPU.
Portátil con 32 GB de RAM: no cabe entero, así que llama.cpp lee desde SSD mediante mapeo de memoria (mmap) los expertos que hace falta en cada momento. Más lento, pero funciona.

¿Cómo lo ejecuto con llama.cpp? (paso a paso)

GGUF es el formato que usa llama.cpp, el motor de inferencia de código abierto. No necesitas cuenta en la nube ni servidor con GPU. Necesitas una build reciente de llama.cpp (b11048 o posterior) y espacio en disco para los 111 GB.

Primero, descarga los archivos del repositorio en Hugging Face:

# Instala el cliente de Hugging Face
pip install -U "huggingface_hub[cli]"

# Descarga los 4 archivos GGUF (111 GB en total)
hf download FINAL-Bench/POCKET-Darwin-180B-GGUF \
  --local-dir ./pocket-darwin-180b \
  --include "*.gguf"

Luego compila llama.cpp (si aún no la tienes) y lanza la inferencia:

# Compilar llama.cpp (build b11048 o superior)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp && cmake -B build && cmake --build build --config Release

# Ejecutar solo en CPU
./build/bin/llama-cli \
  --model ../pocket-darwin-180b/pocket-darwin-180b-Q4.gguf \
  --threads 16 \
  --ctx-size 8192 \
  --prompt "Explica en tres frases qué es una arquitectura MoE."

Notas prácticas de ingeniería:

--threads: ajusta al número de hilos físicos de tu CPU. En el servidor de prueba (16 hilos) se obtuvieron de 18.4 a 21.0 tok/s.
mmap: llama.cpp mapea el archivo por defecto, así que en máquinas con poca RAM los pesos se leen desde SSD bajo demanda. Un SSD NVMe rápido ayuda mucho aquí.
Servidor HTTP: usa llama-server en lugar de llama-cli si quieres exponer un endpoint compatible con la API de chat.

Un apunte importante: este modelo se distribuye como GGUF para llama.cpp. Verifica la compatibilidad de la versión del motor antes de integrarlo en otras herramientas de escritorio.

¿Pierde precisión al comprimir a 4 bits?

Esta es la pregunta que todo ingeniero hace antes de confiar en una versión cuantizada. La respuesta medida: no, al menos en el banco de pruebas principal.

En MMLU-Pro, un examen de conocimiento general de 2,000 preguntas, comparando pregunta por pregunta:

Versión	MMLU-Pro
Original (BF16)	87.65%
POCKET (4 bits)	87.65%

Idéntico. La cuantización agresiva no degradó la tasa de acierto en ese conjunto.

Además, hay una señal interesante sobre el efecto de la autosuperación (RSI). En SuperGPQA, un conjunto de 1,000 preguntas de ciencia de nivel de posgrado que no se usó en el entrenamiento, se comparó solo la parte modificada por RSI contra la misma versión de 4 bits del modelo base:

Modelo base (4 bits): 59.10%
POCKET (4 bits): 61.55%

Una mejora de 2.45 puntos, estadísticamente significativa. Y lo hizo usando alrededor de 13% menos tokens por pregunta: razona de forma más concisa y deja de reverificar la respuesta una vez que ya la tiene. Un desarrollador externo verificó este resultado archivo por archivo en una discusión pública.

¿Para qué casos sirve un modelo de alto nivel sin conexión?

El caso de uso que ordena todo lo anterior es claro: entornos donde los datos no pueden salir a la nube. Defensa, finanzas y sector público tienen reglas que prohíben enviar datos a servidores externos. POCKET-Darwin-180B corre dentro de un servidor local o un mini PC, sin conexión a internet, sin que ningún dato cruce la frontera de la organización.

La comparación de coste también pesa. Un servidor con 8 GPU H100 ronda cifras de cientos de miles de dólares. Un portátil gamer de gama media con 8 GB de memoria gráfica y 32 GB de RAM cuesta una fracción mínima de eso. No es la misma velocidad, pero para cargas de trabajo por lotes o inferencia local, la ecuación cambia por completo.

Preguntas frecuentes (FAQ)

¿Qué hardware mínimo necesito?
Para correr el modelo completo en memoria, un mini PC con 128 GB de RAM sin GPU. Con 32 GB de RAM funciona vía mmap desde SSD, a menor velocidad (4.17 tok/s medidos en un portátil con RTX 5060 de 8 GB). Un SSD NVMe rápido es muy recomendable.

¿Cuánto espacio en disco ocupa?
Son 4 archivos GGUF que suman 111 GB. Deja margen adicional para la caché del sistema operativo.

¿Por qué 180B de parámetros corren tan rápido en CPU?
Por la arquitectura MoE: solo 10 de 512 expertos se activan por token, lo que equivale a unos 3B de parámetros activos. El cómputo por token es bajo; el reto real es la lectura de pesos desde disco o RAM.

¿Puedo usarlo con Ollama o LM Studio?
El modelo está publicado y probado para llama.cpp (build b11048 o superior). Antes de usarlo con otras herramientas, confirma que su versión del motor soporta esta arquitectura y cuantización.

¿La cuantización de 4 bits lo vuelve menos fiable?
En MMLU-Pro, la tasa de acierto es idéntica a la del original (87.65% en ambos). La parte modificada por el entrenamiento de autosuperación se conserva en alta precisión, lo que ayuda a preservar la calidad.

¿Dónde lo descargo?
En Hugging Face (huggingface.co/FINAL-Bench/POCKET-Darwin-180B-GGUF) y en ModelScope (modelscope.cn/models/FINAL-Bench/POCKET-Darwin-180B-GGUF). El modelo original está en huggingface.co/FINAL-Bench/Darwin-180B-RSI.

Cierre

Lo interesante de POCKET-Darwin-180B no es solo que un modelo de 180B corra sin GPU, sino el conjunto de decisiones de ingeniería que lo hacen posible: MoE para reducir el cómputo por token, cuantización de 4 bits que preserva la precisión, y GGUF más llama.cpp para desplegar con una sola línea de comando. La combinación acerca un modelo de nivel puntero al hardware que ya tienes sobre la mesa.

De los exámenes al trabajo real: un modelo abierto de 180B lidera 10 clasificaciones oficiales de Hugging Face

김민식/학생 — Tue, 06 Oct 2026 00:43:23 +0000

TL;DR

Un modelo de código abierto, Darwin-180B-RSI, ocupa ahora el puesto #1 en 10 de los 48 benchmarks oficiales de Hugging Face, el mayor número entre las 95 organizaciones que compiten. La segunda posición es Z.ai, con 4.
El décimo primer puesto es MDPBench (parsing de documentos multilingües, 83.65). Se suma a los dos anteriores orientados al trabajo real: IFStruct (salida estructurada, 98.95%) y ExtractBench (extracción de documentos, 90.29).
El modelo mejora solo con RSI a nivel de modelo (auto mejora recursiva): resuelve problemas verificables, se queda únicamente con sus propias soluciones confirmadas como correctas y vuelve a entrenar con ellas.
Al mismo tiempo, Gate Arcade, una app para juzgar acciones de agentes, fue elegida Spaces of the Week de Hugging Face. Dentro va ZTC, una técnica que juzga leyendo el estado interno del modelo sin generar ni una sola letra.

Este post está pensado para que lo pueda leer alguien de ingeniería: qué miden los benchmarks, cómo se logró y por qué ZTC es relevante para agentes en producción.

¿Qué significa liderar 10 benchmarks oficiales de Hugging Face?

Hugging Face mantiene un conjunto de benchmarks oficiales sobre los que cualquier organización puede registrar resultados medidos con el arnés de evaluación oficial de cada prueba. Hoy son 48 benchmarks y 95 organizaciones participantes. Que una misma familia de modelos encabece 10 de ellos no es un promedio alto: es haber ganado la prueba, una por una, en dominios muy distintos.

Lo interesante no es solo la cantidad, sino el reparto. Hasta hace poco, los primeros puestos estaban en pruebas tipo examen: ciencia de posgrado, olimpiadas de matemáticas, preguntas de estilo jurídico. Los tres añadidos recientes miden otra cosa: la capacidad de hacer el trabajo que una empresa realmente le encarga a un modelo.

Área	Benchmark	Puntuación
Ciencia y conocimiento	GPQA Diamond	94.44
Ciencia y conocimiento	MMLU-Pro	88.12
Matemáticas	AIME 2026	100
Matemáticas	HMMT 2026	100
Razonamiento visual	MMMU-Pro	79.48
Jurídico	LEXam	68.94
Jurídico	LEXam-hard	45.72
Trabajo de empresa	ExtractBench	90.29
Trabajo de empresa	IFStruct	98.95
Parsing de documentos	MDPBench	83.65

Conviene subrayar un detalle: en MMLU-Pro (141 modelos registrados) y GPQA (111 modelos), los dos benchmarks con más competidores, el modelo sigue en primer lugar. Ganar donde hay más gente mirando es distinto a ganar en una prueba de nicho.

¿Qué miden MDPBench, IFStruct y ExtractBench?

MDPBench evalúa el parsing de documentos multilingües: tomar un documento real, con sus tablas, encabezados y estructura, y convertirlo en una representación limpia y utilizable. Es el paso previo invisible de casi cualquier sistema RAG o de automatización documental. Si el parsing se equivoca, todo lo que viene después hereda el error. Aquí el modelo marcó 83.65.

IFStruct, de Liquid AI, comprueba si el modelo devuelve JSON o YAML válido que respeta un esquema pedido. La corrección es aprobado o suspenso por prompt, y es estricta:

número exacto de elementos (o rango), clave envoltorio, JSON frente a YAML
bloque de código requerido o prohibido, sin comentarios cuando se pide
cada tipo de campo, enum, límite numérico y longitud de lista anidada
cualquier campo que el esquema no pidió hace fallar la respuesta

No se usa decodificación restringida, así que solo se mide la disciplina propia del modelo. Darwin aprobó 1.979 de 2.000 prompts con los valores por defecto del arnés oficial (temperatura 0, 16K tokens, razonamiento activado), para un 98.95%. Un prompt agotó el tiempo de lectura de 120 segundos del arnés y se contó como fallo, así que la cifra es conservadora.

Modelo	IFStruct
Darwin-180B-RSI	98.95
Agents-A1	93.25
gpt-oss-20b	91.95
Nemotron-3-Nano-30B	86.80
Granite 4.1 8B	68.45

ExtractBench, de LlamaIndex, pide extraer campos estructurados de 370 documentos PDF, desde formularios cortos hasta archivos cercanos a 200 páginas. La segunda ronda de auto mejora, Darwin-180B-RSI-R3, obtuvo 90.29, por delante de su propio modelo base Qwen3.8-Flash-Next (89.88).

Por qué importan los tres juntos: en una tubería de agentes, la salida del modelo la lee código, no una persona. Un tipo de dato mal puesto, una clave inventada o una tabla mal parseada, y el proceso se detiene. Estas pruebas miden exactamente la parte que decide si un piloto llega a producción.

¿Cómo mejora el modelo sin datos etiquetados por humanos?

Darwin-180B-RSI parte del modelo abierto Qwen3.8-Flash-Next de Alibaba y sube su rendimiento con la técnica propia de RSI a nivel de modelo (Model-level RSI, auto mejora recursiva). La idea, en una frase: el modelo aprende de sus propios aciertos verificados.

El bucle, sin recetas internas ni hiperparámetros:

El modelo resuelve problemas cuya respuesta se puede verificar de forma automática.
Se conservan solo las soluciones confirmadas como correctas.
Se vuelve a entrenar con ese conjunto depurado.
Se repite.

Como nunca aprende de soluciones sin verificar, los errores no se refuerzan. Un detalle llamativo: nadie le enseñó explícitamente derecho ni extracción documental, y aun así encabeza esas áreas. La lectura del equipo es que el hábito de razonar con cuidado, adquirido al resolver problemas verificables, se transfiere a dominios nuevos.

¿Qué es ZTC y por qué es Spaces of the Week?

Mientras los agentes de IA empiezan a enviar correos, pagar y ejecutar código en nuestro nombre, el nuevo terreno de disputa es el juicio (decision): filtrar la acción equivocada antes de ejecutarla. La API JEV de Typesafe fijó un formato de referencia, y en la clasificación abierta Decision Index ya hay más de 70 modelos. El 30 de septiembre, Cloudflare publicó un modelo juez compatible con ese formato, y equipos de Stanford y NVIDIA presentaron modelos de la misma familia.

ZTC (Zero-Token Confidence, confianza sin tokens) propone otra dirección. En lugar de preguntar a otra IA "¿esta respuesta es correcta?" y recibir texto de vuelta, lee una vez el estado interno del modelo que ya produjo la respuesta y calcula la probabilidad de que sea correcta. Los tokens adicionales generados son cero.

Misma precisión, 10 veces más rápido. La precisión de juicio (AUC) es ZTC 0.7289 frente a la API externa (JEV) 0.7350, estadísticamente equivalentes. El tiempo por juicio es ZTC 0.06 s frente a JEV 0.59 s. En los mismos 300 segundos, ZTC procesó 177 casos y JEV 135; en un duelo de 2.000 rondas, ZTC ganó el 73.7%.
Los datos no salen. ZTC corre en la misma GPU junto al modelo, sin ida y vuelta a una API externa. Funciona en redes aisladas, lo que encaja con defensa, banca y sector público.
Coste adicional casi nulo. Solo lee el interior de un modelo que ya generó su respuesta. Con este método, Darwin-397B-ZTC subió la precisión al juzgar sus propias respuestas de 0.76 a 0.88.

Spaces of the Week es la curación con la que Hugging Face destaca 8 apps por semana entre cerca de 1,5 millones. Gate Arcade, que muestra como un juego cuándo una acción de agente se ejecuta o se retiene, fue seleccionada en la semana del 28 de septiembre. Suma la acción correcta (+1), penaliza la equivocada (−1) y deja en 0 la retención, y enfrenta tres estrategias: ejecutar todo sin juzgar, preguntar a una API externa (JEV) y ZTC.

	Plano	JEV (API externa)	ZTC
Precisión de juicio (AUC)	sin dato	0.7350	0.7289
Tiempo por juicio	0 s	0.591 s	0.0615 s
Casos en 300 s	no aplica	135	177

Preguntas frecuentes

¿El modelo es realmente de código abierto?
Darwin-180B-RSI parte de Qwen3.8-Flash-Next de Alibaba y está publicado en Hugging Face como FINAL-Bench/Darwin-180B-RSI. La variante usada en ExtractBench es FINAL-Bench/Darwin-180B-RSI-R3.

¿Quién mide y registra las puntuaciones?
Cada organización mide con la herramienta de evaluación oficial de cada benchmark y registra el valor. Los resultados aquí citados corresponden a ese registro oficial en Hugging Face a octubre de 2026.

¿Por qué un 98.95% y no un 100% en IFStruct?
De 2.000 prompts, uno agotó el límite de lectura de 120 segundos del arnés y se contabilizó como fallo. La cifra es, por tanto, conservadora. Con el razonamiento desactivado, el mismo modelo baja a 89.7%: la fase de razonamiento es la que cierra las últimas violaciones de restricciones.

¿ZTC sustituye a las APIs de juicio como JEV?
No necesariamente. ZTC alcanza una precisión equivalente a JEV con unas 10 veces menos de latencia y sin enviar datos fuera, lo que lo hace idóneo en redes aisladas y cargas de alto volumen. JEV sigue siendo útil cuando se prefiere un juez externo e independiente del modelo.

¿Esto sirve para mi tubería de agentes?
Si su salida la consume código (JSON, YAML, extracción de PDF), IFStruct, ExtractBench y MDPBench miden justo esa fiabilidad. Y si necesita decidir si una acción se ejecuta o se retiene con baja latencia, ese es el caso de uso de ZTC.

Darwin-180B-RSI: el modelo de lenguaje de código abierto #1 en 9 clasificaciones oficiales de Hugging Face

김민식/학생 — Mon, 05 Oct 2026 08:58:49 +0000

TL;DR

La familia Darwin-180B-RSI de VIDRAFT ocupa el primer lugar en 9 de los 48 benchmarks oficiales de Hugging Face. Ninguna de las 95 organizaciones participantes tiene más; detrás vienen Moonshot AI y Zhipu AI (Z.ai) con 4 cada una.
Los dos primeros puestos más recientes son de trabajo real, no de examen: IFStruct 98.95 % (salida estructurada, 1.979 de 2.000 prompts) y ExtractBench 90.29 (extracción de datos de 370 PDF, versión R3).
La receta se llama auto-mejora recursiva a nivel de modelo (Model-level RSI): el modelo resuelve problemas verificables, se queda solo con sus propias soluciones comprobadas como correctas y vuelve a entrenarse con ellas. Sin respuestas escritas por humanos.
El mismo equipo desarrolló ZTC, un juez que decide sin generar un solo token: misma precisión que consultar una API externa (AUC 0.7289 frente a 0.7350) y unas 10 veces más rápido (0.0615 s frente a 0.591 s).
Abajo tienes código Python para consultar la clasificación tú mismo, cómo servir el modelo con vLLM o Transformers, y un FAQ. Todas las cifras se volvieron a comprobar contra la API de Hugging Face el 5 de octubre de 2026.

¿Qué son exactamente los 9 primeros puestos en la clasificación de Hugging Face?

Hugging Face marca ciertos datasets como benchmarks oficiales (benchmark:official) y les añade una tabla de clasificación. Cada laboratorio publica sus resultados en su propio repositorio con archivos .eval_results/*.yaml, y Hugging Face los agrega en un ranking. Hoy hay 48 tableros oficiales y 95 organizaciones compitiendo.

Estos son los 9 tableros donde lidera Darwin-180B-RSI, con su perseguidor inmediato, según la API el 5 de octubre de 2026:

Área	Benchmark (ID del dataset)	Darwin	2.º lugar	Puntaje
Ciencia	GPQA Diamond (`Idavidrein/gpqa`)	94.44	moonshotai/Kimi-K3	93.5
Conocimiento	MMLU-Pro (`TIGER-Lab/MMLU-Pro`)	88.12	MiniMaxAI/MiniMax-M2.1	88.0
Matemáticas	AIME 2026 (`MathArena/aime_2026`)	100	thinkingmachines/Inkling	97.1
Matemáticas	HMMT Feb 2026 (`MathArena/hmmt_feb_2026`)	100	moonshotai/Kimi-K2.6	92.7
Visión	MMMU-Pro (`MMMU/MMMU_Pro`)	79.48	moonshotai/Kimi-K2.6	79.4
Derecho	LEXam (`LEXam-Benchmark/LEXam`)	68.94	deepseek-ai/DeepSeek-R1	52.41
Derecho	LEXam-hard (`joelniklaus/LEXam-hard`)	45.72	thinkingmachines/Inkling	40.82
Trabajo real	ExtractBench (`llamaindex/ExtractBench`)	90.29 (R3)	Qwen/Qwen3.8-Flash-Next	89.88
Trabajo real	IFStruct (`LiquidAI/ifstruct-v1.0`)	98.95	InternScience/Agents-A1	93.25

MMLU-Pro (unas 141 entradas) y GPQA (unas 111) son los tableros más concurridos, y ambos los encabeza este modelo. Lo interesante para quien desarrolla es la combinación: los rankings más disputados y, a la vez, las tareas que de verdad aparecen en producción.

Una aclaración honesta: todos estos puntajes son autorreportados, medidos por cada laboratorio con la herramienta oficial de evaluación, que es como funciona este sistema para todos. Los resultados por voto mayoritario (por ejemplo AIME maj@16) están etiquetados como tales en la ficha del modelo. Antes de comparar, revisa la configuración.

¿Cómo puedo verificar la clasificación con código?

No tienes que creerle a ningún artículo. La API pública de Hugging Face lo responde en segundos y no necesita token:

import requests
from collections import Counter

API = "https://huggingface.co/api"

# 1) Lista de benchmarks oficiales
boards = requests.get(f"{API}/datasets",
                      params={"filter": "benchmark:official", "limit": 200}).json()
print("Benchmarks oficiales:", len(boards))

# 2) Quién va primero en cada tablero
firsts = Counter()
for b in boards:
    rows = requests.get(f"{API}/datasets/{b['id']}/leaderboard").json()
    if not isinstance(rows, list) or not rows:
        continue
    top = rows[0]                      # rank 1
    firsts[top["modelId"].split("/")[0]] += 1
    if top["modelId"].startswith("FINAL-Bench/"):
        r2 = rows[1] if len(rows) > 1 else {}
        print(b["id"], top["value"], top["modelId"],
              "| 2.º", r2.get("modelId"), r2.get("value"))

print(firsts.most_common(5))
# Resultado el 2026-10-05: FINAL-Bench 9, moonshotai 4, zai-org 4, XiaomiMiMo 3, deepseek-ai 3

Cada fila trae campos como rank, value, modelId, source (enlace a la ficha del modelo) y verified. Con esto puedes montar un panel interno para elegir modelos o una alerta que te avise cuando cambia el líder de un benchmark que te importa.

¿Por qué importa a un desarrollador el 98.95 % en IFStruct?

IFStruct, creado por Liquid AI, mide si un modelo devuelve JSON o YAML válido que respete un esquema pedido, con los requisitos redactados de las mil maneras en que los escriben los usuarios reales. Cada prompt se aprueba o se reprueba, y el criterio es estricto:

cantidad exacta de elementos (o rango), clave contenedora, JSON frente a YAML
bloque de código obligatorio o prohibido, nada de comentarios si así se pide
tipo de cada campo, enums, límites numéricos y largo de listas anidadas
cualquier campo que el esquema no pidió hace fallar la respuesta

No se usa decodificación restringida (constrained decoding), así que se mide solo la disciplina del propio modelo. Darwin-180B-RSI aprobó 1.979 de 2.000 prompts con los valores por defecto del harness oficial (temperatura 0, 16.000 tokens máximos, razonamiento activado). Un prompt superó el timeout de lectura de 120 segundos del harness y contó como fallo, así que la cifra es conservadora. Con el razonamiento apagado, el mismo modelo baja a 89.7 %: la fase de razonamiento es la que atrapa las últimas violaciones de formato.

En un pipeline de agentes o en un backoffice automatizado, la salida del modelo no la lee una persona: la parsea tu código. Un tipo equivocado o una clave inventada y json.loads o tu validador de esquema revientan. Pasar de 93.25 % a 98.95 % se traduce en menos reintentos, menos lógica de reparación y menos alertas a las tres de la mañana.

¿Cómo se logró el 90.29 en ExtractBench?

ExtractBench, de LlamaIndex, pide extraer campos estructurados de 370 documentos PDF, desde formularios cortos hasta archivos de casi 200 páginas. La segunda ronda de auto-mejora, Darwin-180B-RSI-R3, obtuvo 90.29 y superó a su propio modelo base, Qwen3.8-Flash-Next de Alibaba (89.88), y a Qwen3.8-27B (89.75). Esta corrida usó el harness oficial con el razonamiento desactivado, y así quedó declarado en la entrega.

Que la siguiente generación de un mismo linaje supere al modelo del que partió es la evidencia más directa de que el ciclo de auto-mejora funciona.

¿Cómo funciona la auto-mejora recursiva (Model-level RSI)?

Darwin-180B-RSI parte del modelo abierto Qwen3.8-Flash-Next de Alibaba y mejora mediante la auto-mejora recursiva a nivel de modelo de VIDRAFT. La idea cabe en tres pasos:

El modelo resuelve por su cuenta problemas verificables.
Se conservan solo sus propias soluciones comprobadas como correctas.
El modelo se reentrena con ellas, y el ciclo se repite.

No se usan soluciones ni cadenas de razonamiento escritas por personas. Como lo no verificado nunca entra al entrenamiento, el modelo no refuerza sus propios errores. R3 es simplemente una vuelta más del ciclo.

Lo llamativo es que nunca se entrenó con textos jurídicos ni con extracción de documentos, y aun así lidera LEXam, LEXam-hard y ExtractBench. La lectura de la empresa: los hábitos de razonamiento cuidadoso y paso a paso que se aprenden resolviendo problemas verificables se transfieren a otros dominios.

¿Por qué "a nivel de modelo"? Para distinguirlo de los enfoques que mejoran el arnés (prompts, herramientas, flujos) alrededor de un modelo fijo. Aquí lo que cambia no es el manual, sino los pesos: el cerebro mismo.

¿Cómo ejecuto Darwin-180B-RSI en mi infraestructura?

El código siguiente viene tal cual de la sección Quickstart de la ficha del modelo. Primero, las especificaciones:

Mixture-of-Experts con atención híbrida (36 capas de atención lineal + 12 de atención completa)
512 expertos enrutados, 10 activos por token, más un experto compartido
Contexto de 262.144 tokens; entrada de imagen y texto, salida de texto
Unos 336 GB en bf16

Servir con vLLM (8 × B200 o equivalente)

vllm serve FINAL-Bench/Darwin-180B-RSI \
  --tensor-parallel-size 8 --enable-expert-parallel \
  --max-model-len 135168 --trust-remote-code

Llamarlo con la API compatible con OpenAI

from openai import OpenAI
c = OpenAI(base_url="http://localhost:8000/v1", api_key="-")
r = c.chat.completions.create(model="FINAL-Bench/Darwin-180B-RSI",
    messages=[{"role": "user", "content": "Explica en dos frases por qué el cielo es azul."}],
    temperature=1.0, top_p=0.95, extra_body={"top_k": 20})
print(r.choices[0].message.content)

Cargarlo con Transformers

from transformers import AutoProcessor, AutoModelForImageTextToText
model_id = "FINAL-Bench/Darwin-180B-RSI"
processor = AutoProcessor.from_pretrained(model_id)
model = AutoModelForImageTextToText.from_pretrained(model_id, torch_dtype="auto", device_map="auto")

Dos consejos prácticos. Primero, es un modelo de razonamiento (thinking): para problemas difíciles la ficha recomienda un presupuesto de 32K a 131K tokens; si lo recortas, pierdes precisión. Segundo, la configuración de evaluación de la ficha es temperatura 1.0, top_p 0.95, top_k 20, aunque para tareas de formato estricto como IFStruct el harness oficial usó temperatura 0.

¿Qué es ZTC y en qué se diferencia de JEV?

Ahora que los agentes envían correos, hacen pagos y ejecutan código, filtrar una acción equivocada antes de ejecutarla se volvió un tema central. La API de decisión JEV, de Typesafe, definió el formato estándar del sector, y el ranking público Decision Index ya reúne más de 70 modelos. El 30 de septiembre Cloudflare publicó Clef, un modelo de decisión compatible con JEV.

ZTC (Zero-Token Confidence) de VIDRAFT toma otro camino. En lugar de preguntarle a otra IA "¿esta respuesta es correcta?" y esperar texto de vuelta, lee una sola vez el estado interno del modelo que generó la respuesta y calcula la probabilidad de que sea correcta. Tokens adicionales generados: cero.

Para verlo en acción está Gate Arcade, elegida como "Space of the Week" de Hugging Face la semana del 28 de septiembre. Un agente propone una acción y la compuerta decide ejecutar o retener: +1 por ejecutar una acción correcta, -1 por ejecutar una incorrecta, 0 por retener. Mediciones del 24 de septiembre de 2026, en despliegue aislado de internet:

	Sin compuerta	JEV (API externa)	ZTC (VIDRAFT)
Precisión de decisión (AUC)	n/a	0.7350	0.7289
Tiempo por decisión	0 s	0.591 s	0.0615 s
Decisiones en 300 s	n/a	135	177

La precisión es estadísticamente equivalente y la velocidad es unas 10 veces mayor. En 2.000 partidas cara a cara, ZTC ganó el 73.7 %. Como no envía datos a ningún servicio externo, funciona en redes aisladas, algo clave para banca, defensa o sector público. Con el mismo enfoque, Darwin-397B-ZTC elevó de 0.76 a 0.88 la precisión con la que juzga si sus propias respuestas son correctas.

Los límites también son claros: hay que leer el interior del modelo, así que no sirve para modelos cerrados que solo se usan por API, y cada modelo necesita su propio lector calibrado. Lo sensato es usarlo como primer filtro rápido y barato, no como juez final. Además, el lector ZTC incluido en el repositorio de Darwin-180B-RSI está marcado en la ficha como "early release"; léela antes de usarlo en acciones de alto riesgo.

Preguntas frecuentes (FAQ)

1. ¿Dónde veo la clasificación de Hugging Face con los 9 primeros puestos?
En la pestaña de leaderboard de cada dataset (por ejemplo huggingface.co/datasets/LiquidAI/ifstruct-v1.0) o llamando a https://huggingface.co/api/datasets/{id}/leaderboard, como en el script de arriba.

2. ¿Quién midió los puntajes? ¿Están verificados?
Los tableros oficiales de Hugging Face funcionan con resultados que cada laboratorio mide con la herramienta oficial y publica vía .eval_results. Los de Darwin también son autorreportados, y la ficha del modelo documenta muestras por pregunta y presupuesto de razonamiento.

3. ¿De verdad la auto-mejora recursiva no usa respuestas humanas?
Así es. El modelo resuelve problemas verificables, conserva solo sus soluciones comprobadas y se reentrena con ellas. No se usan soluciones ni razonamientos escritos por personas.

4. ¿Puedo usar este modelo de lenguaje de código abierto ya mismo? ¿Qué hardware necesito?
Los pesos están publicados en Hugging Face. Ocupan unos 336 GB en bf16, por eso la ficha recomienda 8 × B200 (o equivalente) con vLLM, paralelismo tensorial 8 y paralelismo de expertos.

5. ¿Por qué elegirlo para generar JSON en producción?
Logró 98.95 % en IFStruct sin decodificación restringida, 5.7 puntos por encima del segundo (93.25 %). Eso significa menos reintentos y menos código de reparación.

6. ¿Cómo integro ZTC en mi servicio?
Necesitas un modelo de pesos abiertos cuyo estado interno puedas leer. Prueba primero Gate Arcade para entender el flujo y revisa los ejemplos de la carpeta ztc/ en la ficha del modelo.

Enlaces

VIDRAFT: https://vidraft.net
Modelo: https://huggingface.co/FINAL-Bench/Darwin-180B-RSI
R3 (#1 en ExtractBench): https://huggingface.co/FINAL-Bench/Darwin-180B-RSI-R3
Gate Arcade (Space of the Week): https://huggingface.co/spaces/FINAL-Bench/gate-tetris

De un modelo que aprueba exámenes a uno que trabaja respetando el formato que le pides, más una compuerta que detecta en 0.06 segundos cuándo no está seguro antes de actuar. Pruébalo y cuéntanos en los comentarios qué tal te fue.

DEV Community: 김민식/학생

ZTC (Zero-Token Confidence): juzgar una acción de IA leyendo el estado interno del modelo, con cero tokens extra

TL;DR

Que problema resuelve ZTC?

Que es exactamente ZTC (Zero-Token Confidence)?

Que tan bueno es ZTC frente a un juez LLM?

Por que leer el estado interno funciona en absoluto?

Cuando conviene ZTC y cuando un juez LLM?

Que significa que corra en red cerrada?

FAQ

Further reading

Cómo correr un modelo de 180B sin GPU: POCKET-Darwin-180B en GGUF con llama.cpp

TL;DR

¿Por qué un modelo de 180B cabe en un portátil?

¿Cómo lo ejecuto con llama.cpp? (paso a paso)

¿Pierde precisión al comprimir a 4 bits?

¿Para qué casos sirve un modelo de alto nivel sin conexión?

Preguntas frecuentes (FAQ)

Cierre

De los exámenes al trabajo real: un modelo abierto de 180B lidera 10 clasificaciones oficiales de Hugging Face

TL;DR

¿Qué significa liderar 10 benchmarks oficiales de Hugging Face?

¿Qué miden MDPBench, IFStruct y ExtractBench?

¿Cómo mejora el modelo sin datos etiquetados por humanos?

¿Qué es ZTC y por qué es Spaces of the Week?

Preguntas frecuentes

Further reading

Darwin-180B-RSI: el modelo de lenguaje de código abierto #1 en 9 clasificaciones oficiales de Hugging Face

TL;DR

¿Qué son exactamente los 9 primeros puestos en la clasificación de Hugging Face?

¿Cómo puedo verificar la clasificación con código?

¿Por qué importa a un desarrollador el 98.95 % en IFStruct?

¿Cómo se logró el 90.29 en ExtractBench?

¿Cómo funciona la auto-mejora recursiva (Model-level RSI)?

¿Cómo ejecuto Darwin-180B-RSI en mi infraestructura?

Servir con vLLM (8 × B200 o equivalente)

Llamarlo con la API compatible con OpenAI

Cargarlo con Transformers

¿Qué es ZTC y en qué se diferencia de JEV?

Preguntas frecuentes (FAQ)

Enlaces