DEV Community: 김민식/학생

¿Puede una NPU solo-inferencia preentrenar un LLM? 325M de parámetros desde cero, con la misma calidad que una B200

김민식/학생 — Mon, 26 Oct 2026 05:53:36 +0000

Resumen

Sí, siempre que exista una pila de entrenamiento hecha para ello. En VIDRAFT preentrenamos VKORE-325M-NPU-Base (325,6 millones de parámetros) desde una inicialización aleatoria en la Rebellions ATOM-Max, una NPU comercial coreana lanzada en 2025 y diseñada para inferencia. Entrenamos el mismo modelo en una GPU B200 como referencia. En 1.024 ventanas de texto que ningún modelo vio durante el entrenamiento, la NPU obtiene una pérdida de 0,7993 y la GPU 0,7994. Los pesos de ambos y el script de evaluación son públicos.

¿Por qué se asume que una NPU de inferencia no puede entrenar?

El compilador y el entorno de ejecución de un acelerador de inferencia están hechos para ejecutar la pasada hacia adelante de un modelo entrenado en otro lugar. Preentrenar exige mucho más: retropropagación por todas las capas, estado del optimizador y actualizaciones estables durante decenas de miles de pasos. Nada de eso viene incluido.

La pregunta tiene consecuencias económicas. Las NPU de inferencia cuestan menos y consumen menos energía que las GPU de entrenamiento, y muchas organizaciones ya las tienen. Si también pueden entrenar, un solo tipo de chip cubre los dos trabajos.

¿Qué entrenamos exactamente?

Elemento	Valor
Modelo	VKORE-325M-NPU-Base, Transformer solo decodificador
Parámetros	325,6M (20 capas, ancho 1024, FFN 3584, GQA 8 consultas / 2 KV)
Vocabulario	256, a nivel de byte
Datos	5.000 millones de tokens de byte de FineWeb-Edu
Entrenamiento	76.292 pasos, unos cuatro días, inicialización aleatoria
Pesos preentrenados usados	ninguno
Hardware	NPU Rebellions ATOM-Max (2025)

¿Cómo se demuestra la "calidad de GPU"?

Con una referencia que solo cambie el hardware. Entrenamos el mismo modelo dos veces con la misma inicialización, los mismos datos, el mismo lote y el mismo calendario de tasa de aprendizaje: una vez en la NPU y otra en una sola GPU B200.

¿Coinciden las curvas de entrenamiento?

Se superponen durante todo el entrenamiento, de unos 5,8 a unos 0,80.

¿Y en texto que el modelo nunca vio?

El corpus de entrenamiento se construyó solo con los dos primeros fragmentos de FineWeb-Edu sample/10BT. Evaluamos ambos modelos publicados en 1.024 ventanas del fragmento 013, que nunca formó parte del entrenamiento.

Modelo	Pérdida, texto no visto	Bits por byte
NPU Rebellions ATOM-Max	0,7993	1,1531
GPU B200 de referencia	0,7994	1,1533

Comparando ventana por ventana, la diferencia media es -0,0001 (NPU menos GPU) con un error estándar de 0,0007, y la NPU es mejor en el 50,1 % de las ventanas. A esta resolución no se pueden distinguir.

¿Qué cambió respecto a VKORE-46M?

Lo difícil no fue la retropropagación, sino mantener estable un entrenamiento largo hasta el final. Esa técnica de estabilidad es propia y está en proceso de patente, por eso no la describimos.

¿Basta con comprar la NPU para entrenar?

No. La ATOM-Max y su software estándar están diseñados para inferencia. Entrenar en ella depende de nuestra propia pila de entrenamiento y de nuestra técnica de estabilidad. Comprar el chip no permite entrenar por sí solo.

¿Cómo reproducirlo?

from transformers import AutoModelForCausalLM

npu = AutoModelForCausalLM.from_pretrained("FINAL-Bench/VKORE-325M-NPU-Base")
gpu = AutoModelForCausalLM.from_pretrained("FINAL-Bench/VKORE-325M-NPU-Base", subfolder="b200_reference")

El script evaluate_unseen.py del repositorio descarga el fragmento 013, toma las mismas 1.024 ventanas y muestra ambas pérdidas y la diferencia emparejada.

Preguntas frecuentes

¿Qué NPU se usó? La Rebellions ATOM-Max, una NPU comercial de inferencia lanzada en 2025.

¿El modelo de la NPU es tan bueno como el de la GPU? En texto no visto, sí: 0,7993 frente a 0,7994, con una diferencia emparejada de -0,0001 y error estándar de 0,0007.

¿Es un modelo de chat? No. Es un modelo base de 325M entrenado con 5.000 millones de tokens, publicado como resultado de hardware de entrenamiento.

¿Es abierto el método? Los pesos, la receta de datos y la evaluación son abiertos. La pila de entrenamiento y la técnica de estabilidad son propias y están en proceso de patente.

Lecturas recomendadas

Informe técnico completo (inglés): Pretraining a 325M Language Model from Zero on an Inference-Only NPU
Modelos: FINAL-Bench/VKORE-325M-NPU-Base
Preentrenamiento desde cero en una NPU solo-inferencia: VKORE-46M-NPU
When attacks automate, defense has to automate too

When attacks automate, defense has to automate too

김민식/학생 — Fri, 23 Oct 2026 09:23:17 +0000

In autumn 2026, seven financial institutions in Korea were breached by a single open-source AI penetration tool, and roughly 65,000 customer records were taken. The attack path was not exotic: injection in a peripheral web app, authentication bypass, and bulk harvesting through sequential access. What changed was speed and autonomy.

Once an attack runs itself, the defense has to run itself too. That is the premise behind Chitos.

What autonomy looks like here

Chitos forms its own audit hypotheses from reconnaissance, and when one path is blocked it researches another and keeps going, widening coverage without a human spelling out each step. Then an AI verification layer re-reads every first-pass finding and filters false positives, so what you get is reproducible evidence, not a pile of maybes.

The numbers

On the OWASP Benchmark, the base scanner scores 52.8 Youden. With the AI verification layer, Chitos reaches 77.8 on-prem (Darwin-180B-RSI) and 77.2 online (Claude Opus 5.5), removing more than 60 percent of false positives while missing no real vulnerabilities. Publicly reported commercial tools sit in the mid-70s and above, and these self-measured figures land in that range.

Security should speak in evidence, not promises. We are stacking that evidence as numbers, with official cross-validation in progress.

More: https://vidraft.net

Antes de enviar una molécula: cómo comprobar los límites del Open Discovery Challenge con RDKit

김민식/학생 — Thu, 22 Oct 2026 14:33:22 +0000

TL;DR

El Open Discovery Challenge (ODC) de FINAL-Bench, organizado por VIDRAFT, pide una sola cosa: una molécula escrita como SMILES. Un verificador automático que no puedes ver la puntúa y la coloca en un ranking público. Antes de que tu envío llegue a ese verificador hay una puerta barata y totalmente pública: los límites de entrada (peso molecular máximo y átomos pesados máximos), que cambian por temporada. Un envío fuera de límites se rechaza con el motivo a la vista. En este artículo leo los límites desde la API en vivo de hoy (22 de octubre de 2026), escribo un validador de 30 líneas con RDKit y lo pruebo con cinco fármacos reales. Resultado concreto: la bedaquilina pesa 555,5 Da, solo 5,5 por encima del límite de 550 de la temporada 2, y la rifampicina se rechaza en todas las temporadas abiertas. La temporada 2 (tuberculosis, premio de USD 2.000) cierra el 31 de octubre de 2026.

Una aclaración de entrada: VIDRAFT organiza el reto, y esta cuenta es de VIDRAFT. Todo lo que sigue sale de la documentación pública del reto y de mediciones mías que puedes repetir. Las puntuaciones del ODC son predicciones computacionales, no mediciones de laboratorio.

¿Qué pide exactamente el Open Discovery Challenge?

Cada temporada es una enfermedad distinta con una proteína diana distinta. Además de la diana, el verificador puntúa una contradiana: una proteína humana parecida. Una molécula que se une igual de fuerte a la proteína humana que a la del patógeno no gana solo por potencia.

Estos son los valores que devuelve hoy el endpoint /api/seasons del Space (los leí en vivo, no copiados de un README):

Temporada	Enfermedad	Diana	Contradiana	Cierre	Premio	Acepta envíos
1	Malaria	PfDHODH	DHODH humana	2026-09-30	USD 1.000	no (cerrada)
2	Tuberculosis	InhA	FASN humana (dominio ER)	2026-10-31	USD 2.000	sí
3	Enfermedad de Chagas	CYP51 de T. cruzi	CYP51A1 humana	2026-11-30	USD 1.000	sí
4	Analgesia no opioide	Nav1.7 (VSD4)	hERG (tetrámero del poro)	2027-01-31	USD 1.000	sí

La contradiana de la temporada 4 tiene una razón clínica clara: un fármaco contra un canal de sodio que además bloquea hERG es un riesgo cardíaco.

¿Cómo se reparte la puntuación entre los seis ejes?

El verificador usa seis ejes que suman 100 puntos: actividad, unión (binding), selectividad, ADMET, novedad y síntesis. Los pesos cambian por temporada porque la biología cambia.

Lo que enseña el gráfico: de la temporada 1 a la 4, la actividad cae de 30 a 10 puntos, mientras la unión y la selectividad suben a 30 puntos cada una. Es decir, a partir de la temporada 3, 60 de los 100 puntos dependen de cómo se une tu molécula a la diana frente a la contradiana. ADMET (15), novedad (10) y síntesis (5) son idénticos en las cuatro.

La unión y la selectividad salen de predicción de estructura contra la diana y la contradiana. Cada molécula se acopla varias veces y la dispersión se publica junto a la nota, para que una sola pose afortunada no decida un puesto. Si algún eje no se puede calcular, no se escribe ningún resultado: un eje ausente es un estado, no un cero.

¿Qué límites de entrada son públicos?

Aquí está el punto de este artículo. Los límites de entrada son el único filtro duro que el organizador publica con números exactos:

Temporada	Peso molecular máximo	Átomos pesados máximos
1	550	45
2	550	45
3	750	55
4	600	45

Un envío fuera de estos límites se rechaza al momento de enviarlo, con el motivo visible. Lo que no es público, y con razón: el código de puntuación, los umbrales de las puertas más allá de estos límites y los conjuntos de referencia de novedad. Publicarlos permitiría moldear una entrada contra el evaluador en lugar de contra la biología.

Si vas a automatizar envíos, por ejemplo con un agente que genera candidatos en bucle, conviene filtrar localmente antes de gastar un envío.

¿Cómo escribo un validador de límites con RDKit?

Treinta líneas bastan. La idea: leer los límites de la API (así no se quedan viejos si el organizador los cambia), parsear el SMILES, y devolver un veredicto por temporada.

import json, urllib.request
from rdkit import Chem
from rdkit.Chem import Descriptors

API = "https://final-bench-open-discovery-challenge.hf.space/api/seasons"
seasons = json.load(urllib.request.urlopen(API, timeout=30))["seasons"]
limits = {s["number"]: (s["limits"]["mw_max"], s["limits"]["heavy_max"], s["accepting"])
          for s in seasons}

def preflight(smiles):
    m = Chem.MolFromSmiles(smiles)
    if m is None:
        return None                      # SMILES invalido: ni llega al verificador
    mw = Descriptors.MolWt(m)
    ha = m.GetNumHeavyAtoms()
    out = {"mw": round(mw, 1), "heavy": ha}
    for n, (mw_max, ha_max, accepting) in sorted(limits.items()):
        if not accepting:
            out[f"T{n}"] = "cerrada"
        else:
            out[f"T{n}"] = "ok" if (mw <= mw_max and ha <= ha_max) else "RECHAZO"
    return out

Dos decisiones de diseño que importan. Primera, el campo accepting es distinto de open: la temporada 1 devuelve open: true pero accepting: false, porque la temporada existe y sus resultados son visibles, pero ya no admite envíos. Si filtras por open enviarás a una temporada cerrada. Segunda, los límites vienen de la API y no de constantes en tu código, de modo que si el organizador ajusta un tope, tu validador lo sigue sin cambios.

¿Qué pasa con cinco fármacos reales?

Ejecuté preflight con cinco moléculas conocidas más una cadena que no es un SMILES. Aclaro el propósito: son pruebas de tamaño. No son candidatos propuestos, no son nuevas (el eje de novedad existe justamente para eso) y varias ni siquiera actúan sobre InhA. La isoniazida es un profármaco que, activado por KatG, forma un aducto con NAD que inhibe InhA. El triclosán es un inhibidor conocido de InhA. El etambutol actúa sobre otra enzima de la pared celular, la bedaquilina sobre la ATP sintasa y la rifampicina sobre la ARN polimerasa.

Molécula	Peso molecular (Da)	Átomos pesados	T2	T3	T4
Isoniazida	137,1	10	ok	ok	ok
Etambutol	204,3	14	ok	ok	ok
Triclosán	289,5	17	ok	ok	ok
Bedaquilina	555,5	37	RECHAZO	ok	ok
Rifampicina	823,0	59	RECHAZO	RECHAZO	RECHAZO
`C1CC(`	(no parsea)		None	None	None

La temporada 1 aparece como cerrada para todas. Medido con RDKit 2026.03.1 el 22 de octubre de 2026.

La bedaquilina es el caso instructivo. Pasa el límite de átomos pesados con holgura (37 de 45), pero su peso molecular de 555,5 Da supera por 5,5 el tope de 550 de la temporada 2. Dos topes distintos, y el que muerde no es el que uno miraría primero. La misma molécula entra sin problema en la temporada 3 (tope 750) y en la 4 (tope 600).

La rifampicina, con 59 átomos pesados, sobrepasa incluso el límite de 55 de la temporada 3, el más generoso. Es un recordatorio útil para quien piense en macrociclos grandes: el reto está pensado para moléculas del tamaño de un candidato oral, no de un antibiótico macrocíclico.

¿Cuánto confío en mi validador local?

Con límites. Mi validador usa Descriptors.MolWt y GetNumHeavyAtoms de RDKit sobre el SMILES tal como lo escribo. El servidor del organizador aplica sus propias reglas de normalización, por ejemplo con sales o fragmentos múltiples, que no están publicadas. Trata mi filtro como una criba previa que descarta lo obvio, no como una garantía de aceptación. El criterio final lo da el servidor, y lo da con un motivo de rechazo visible.

Un caso borde que vale la pena probar antes de automatizar: una molécula con contraión (por ejemplo una sal clorhidrato). MolWt suma todos los fragmentos. Si el servidor cuenta solo el fragmento mayor, tu filtro será más estricto que el suyo; si cuenta todo, coincidirá. No lo sé, y no voy a inventarlo: pruébalo con un envío de bajo valor en una temporada abierta si te importa.

¿Y los otros retos abiertos del mismo organizador?

FINAL-Bench mantiene otros cuatro retos con la misma filosofía: un verificador que guarda la respuesta en privado. Todos los Spaces estaban en estado RUNNING cuando los consulté hoy.

Reto	Qué envías	Cierre
Open Materials Challenge	Una estructura cristalina con litio (electrolito sólido)	2026-11-30
Open Superconductor Challenge	Una estimación de emparejamiento d-wave por material 2D	2026-12-31
Open Quantum Challenge	Energías de Fermi-Hubbard o un decodificador de código de superficie	2027-02-28 y 2027-03-31
LEADBOARD	Predicciones de propiedades para moléculas retenidas	tableros abiertos

El Open Materials Challenge admite un validador análogo con pymatgen. Sus límites públicos (leídos de /api/season) son: máximo 60 átomos, energía sobre el casco convexo de hasta 0,10 eV/átomo, banda prohibida mínima de 1,0 eV y presencia obligatoria de litio. Dos de esas comprobaciones, la energía sobre el casco y la banda prohibida, necesitan un cálculo previo que no cabe en un validador de 30 líneas. Las otras dos sí:

from pymatgen.core import Structure, Lattice

s = Structure.from_spacegroup("Fm-3m", Lattice.cubic(5.14), ["Li", "Cl"],
                              [[0, 0, 0], [0.5, 0.5, 0.5]])
s2 = s.copy(); s2.make_supercell([2, 2, 2])
for name, st in [("LiCl celda convencional", s), ("LiCl supercelda 2x2x2", s2)]:
    els = {e.symbol for e in st.composition.elements}
    print(name, "atomos", len(st), "tiene_Li", "Li" in els, "atomos<=60", len(st) <= 60)

Salida medida: la celda convencional de LiCl tiene 8 átomos y pasa; la supercelda 2x2x2 tiene 64 átomos y deja de cumplir el tope de 60. Es un ejemplo ilustrativo de un error muy común, enviar una supercelda en lugar de la celda primitiva.

¿Por qué un verificador privado y no un benchmark público?

Si el evaluador es público, una entrada se puede moldear contra el evaluador. Es la razón por la que estos retos publican reglas, pesos y límites, pero no la implementación de la puntuación ni la clave de respuestas.

El tablero LEADBOARD del mismo organizador da una cifra que ilustra el problema de preguntar lo equivocado. Según su documentación, con los mismos datos y el mismo modelo, el AUROC en el tablero de cardiotoxicidad hERG fue de 0,818 con una partición aleatoria y de 0,606 con una partición temporal. Mismas moléculas, mismo código: solo cambió la pregunta. Un modelo se usa para ordenar compuestos que nadie ha medido todavía, así que la prueba honesta es entrenar con lo conocido hasta un año de corte y predecir lo que vino después. Es una cifra del organizador, medida por él; yo la cito, no la he reproducido.

¿Pueden participar agentes de IA?

El reto de superconductores lo dice de forma explícita: investigadores, estudiantes y agentes de código pueden participar. El ODC exige iniciar sesión en Hugging Face para enviar. Un agente con herramienta de código puede leer las reglas, consultar /api/seasons, filtrar candidatos con un validador como el de arriba y preparar el envío. Lo que no debería hacer, ni un agente ni una persona, es tratar la nota como evidencia biológica: una nota alta es una hipótesis que merece probarse en un laboratorio, nada más.

Preguntas frecuentes

¿Cómo envío una molécula al Open Discovery Challenge?
Abre el Space FINAL-Bench/open-discovery-challenge en Hugging Face, inicia sesión, elige una temporada que acepte envíos y pega tu SMILES. Se rechaza al momento si excede los límites de peso molecular o átomos pesados, con el motivo visible.

¿Qué temporadas aceptan envíos hoy?
Según /api/seasons el 22 de octubre de 2026: la 2 (tuberculosis, cierra el 31 de octubre), la 3 (Chagas, cierra el 30 de noviembre) y la 4 (analgesia no opioide, cierra el 31 de enero de 2027). La 1 (malaria) ya no admite envíos.

¿Por qué mi molécula pasa en la temporada 3 pero no en la 2?
Porque los límites difieren. La temporada 3 permite hasta 750 Da y 55 átomos pesados, la 2 solo 550 Da y 45 átomos pesados. La bedaquilina (555,5 Da) es un ejemplo medido de ese caso.

¿La nota del ODC demuestra que una molécula funciona?
No. Son predicciones computacionales de unión, selectividad, ADMET, novedad y síntesis. Una nota alta es una hipótesis para validar en laboratorio, no evidencia de actividad en células ni en animales.

¿Qué hace el verificador si no puede calcular un eje?
No escribe ningún resultado. Un eje ausente es un estado, no una puntuación de cero. Una entrada sin nota todavía no se ha evaluado, y una que falla repetidamente por causas del entorno, como una GPU llena, se mantiene en cola en lugar de descartarse.

¿Puedo ver el código de puntuación?
No. El código de puntuación, los umbrales de las puertas más allá de los límites publicados y los conjuntos de referencia de novedad son privados, a propósito, para que nadie moldee una entrada contra el evaluador.

Reproducibilidad

Los scripts de este artículo (es_preflight.py, es_omc.py) usan solo RDKit, pymatgen y la API pública del Space. Los límites se leen en vivo, así que si el organizador los modifica después del 22 de octubre de 2026, tus resultados serán los vigentes y los números de las tablas de arriba serán los de ese día. Los repositorios públicos del reto están en github.com/final-bench/open-discovery-challenge y github.com/final-bench/open-materials-challenge.

Preentrenamiento desde cero en una NPU solo-inferencia: VKORE-46M-NPU

김민식/학생 — Thu, 15 Oct 2026 01:32:49 +0000

TL;DR: VIDRAFT preentreno un modelo de lenguaje desde cero (from scratch), con retropropagacion real, en una NPU disenada solo para inferencia, sin ninguna GPU. El resultado, VKORE-46M-NPU, esta publicado en Hugging Face con pesos, tarjeta de modelo y datos de comparacion. Entrenado en condiciones identicas sobre una GPU, las trayectorias de perdida correlacionan a 0,99.

Por que entrenar en una NPU solo-inferencia es dificil

Las NPU de inferencia se construyen para el camino hacia adelante: grafos compilados de forma estatica, baja precision y pesos tratados como constantes. El entrenamiento necesita lo contrario: un grafo hacia atras con activaciones guardadas, estado del optimizador, estabilidad numerica para gradientes pequenos y sincronizacion de gradientes entre chips. Por eso se asumia que "las NPU no pueden hacer retropropagacion". Este trabajo la ejecuta directamente y entrena sin pesos previos.

La evidencia: mismo modelo, dos tipos de hardware

Se entreno el mismo modelo en condiciones identicas (inicializacion, datos y planificacion) en una NPU de 32 chips y en una GPU de referencia.

Las trayectorias de perdida correlacionan a 0,99.
El rendimiento (tokens por segundo) convergio a un nivel comparable.

Una curva de perdida que baja no prueba nada por si sola. Una correlacion de 0,99 con la referencia en GPU indica que la retropropagacion y las actualizaciones del optimizador hacen el mismo trabajo numerico.

Una sola NPU para todo el ciclo

Preentrenamiento desde cero, ajuste LoRA, aceleracion de inferencia (3,8x por usuario, 4,1x de rendimiento de servidor) y ejecucion de modelos cuantizados. VIDRAFT reune esto en una capa de software llamada VKORE: "CUDA para NPU", una capa de aceleracion independiente del hardware que reduce la dependencia de una GPU concreta y su ecosistema.

Por que importa

Los servidores GPU de gama alta son caros, tienen largas esperas y consumen mucha energia. Una NPU barata y de bajo consumo que ademas entrena permite a una empresa desarrollar su propio modelo en sus instalaciones, sin esperar GPU y sin enviar datos sensibles fuera.

El modelo publicado (46M, nivel de caracteres, TinyStories) es una prueba del camino de entrenamiento, no una afirmacion de calidad. Escalar a modelos grandes y datos reales es el siguiente paso. La tecnica central esta en tramite de patente y el codigo de entrenamiento se mantiene privado.

FAQ

Retropropagacion real en una NPU solo-inferencia?
Si, preentrenamiento desde cero en un chip disenado solo para inferencia.

Que significa 0,99?
La curva de perdida de la NPU casi coincide con una referencia en GPU entrenada en condiciones identicas.

Modelo: https://huggingface.co/FINAL-Bench/VKORE-46M-NPU

Demostrar con tablas de clasificacion publicas: importa mas quien corrige

김민식/학생 — Mon, 12 Oct 2026 10:35:05 +0000

Resumen

Las afirmaciones de rendimiento en IA sobran. Lo que importa no es el tamano del numero, sino quien corrige y con que problemas. Este articulo explica como leer resultados de tablas de clasificacion publicas, cual es la trampa de autoevaluarse, y por que los resultados de VIDRAFT en tablas publicas operadas por terceros si tienen peso.

Por que la autoevaluacion es dificil de creer

Si yo creo el examen, lo resuelvo y me corrijo, puedo subir la nota cuando quiera. Basta con filtrar el conjunto de prueba hacia el entrenamiento, elegir la mejor de muchas ejecuciones, o dejar que una ruta de respaldo invente una respuesta. El numero sube y nada real cambia.

Por eso una metrica confiable cumple tres condiciones.

Corrige un tercero. El examen y la correccion los tiene una entidad externa.
El problema resiste la memorizacion. Preguntas de nivel posgrado que no se resuelven buscando.
Se sostiene en varias tablas. Una nota alta puede ser suerte, pero el primer puesto en varias tablas independientes es dificil de fingir.

Los resultados publicos, tal cual

Estos valores vienen de evaluaciones publicas operadas por terceros.

AIME 2026 y HMMT de febrero 2026: puntuacion perfecta en los conjuntos de matematica de competencia.
GPQA Diamond: 93.43% en la categoria por debajo de 500B, preguntas de ciencia de nivel posgrado disenadas para resistir la busqueda.
Amplitud: primeros puestos en once categorias de tablas publicas y dieciseis categorias en la tabla Polaris de prediccion de farmacos.

La clave no es el tamano del numero. Es que el examen lo tenia otro, que resiste la memorizacion, y que el mismo metodo funciono en dominios muy distintos.

Lista de verificacion al leer una tabla

Entrenamiento y prueba no se solapan. Si un item se filtra, la subida es una ilusion.
Si hay puntuacion perfecta, primero sospecha que el examen es demasiado facil.
Una diferencia positiva no es una victoria. Una subida dentro del ruido no es una subida.
Si activaste un truco de aceleracion, sospecha primero del medidor.

Estos son los mismos principios que aplicamos a nuestros resultados antes de publicarlos.

Por que demostrar en publico

Una demo privada se ve bien en condiciones controladas. Una tabla publica traslada ese control afuera. Con el mismo examen y la misma correccion, cualquiera puede intentar reproducir. De ahi viene el peso de la prueba.

Preguntas frecuentes

Puntuacion perfecta es lo mejor? No necesariamente. Puede indicar que el examen perdio capacidad de discriminar.

Basta un primer puesto? Una tabla puede ser suerte. La confianza sube con varias tablas independientes.

De donde vienen los numeros? De evaluaciones publicas operadas por terceros.

La autoevaluacion no sirve? Sirve durante el desarrollo, pero no reemplaza la correccion externa.

Cierre

Una buena afirmacion no es "nuestro numero es alto", sino "en un examen que tenia otro, con problemas que resisten la memorizacion, a traves de varios dominios". Mira primero las condiciones, luego el numero.

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: 김민식/학생

¿Puede una NPU solo-inferencia preentrenar un LLM? 325M de parámetros desde cero, con la misma calidad que una B200

Resumen

¿Por qué se asume que una NPU de inferencia no puede entrenar?

¿Qué entrenamos exactamente?

¿Cómo se demuestra la "calidad de GPU"?

¿Coinciden las curvas de entrenamiento?

¿Y en texto que el modelo nunca vio?

¿Qué cambió respecto a VKORE-46M?

¿Basta con comprar la NPU para entrenar?

¿Cómo reproducirlo?

Preguntas frecuentes

Lecturas recomendadas

When attacks automate, defense has to automate too

What autonomy looks like here

The numbers

Antes de enviar una molécula: cómo comprobar los límites del Open Discovery Challenge con RDKit

TL;DR

¿Qué pide exactamente el Open Discovery Challenge?

¿Cómo se reparte la puntuación entre los seis ejes?

¿Qué límites de entrada son públicos?

¿Cómo escribo un validador de límites con RDKit?

¿Qué pasa con cinco fármacos reales?

¿Cuánto confío en mi validador local?

¿Y los otros retos abiertos del mismo organizador?

¿Por qué un verificador privado y no un benchmark público?

¿Pueden participar agentes de IA?

Preguntas frecuentes

Reproducibilidad

Further reading

Preentrenamiento desde cero en una NPU solo-inferencia: VKORE-46M-NPU

Por que entrenar en una NPU solo-inferencia es dificil

La evidencia: mismo modelo, dos tipos de hardware

Una sola NPU para todo el ciclo

Por que importa

FAQ

Demostrar con tablas de clasificacion publicas: importa mas quien corrige

Resumen

Por que la autoevaluacion es dificil de creer

Los resultados publicos, tal cual

Lista de verificacion al leer una tabla

Por que demostrar en publico

Preguntas frecuentes

Cierre

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