Por Simon Gonzalez de Cruz (sigue la construcción en público en X @KyaniteLabs_), asistido por GLM-5.3. 2026-08-25. Cada número fue re-leído de archivos de resultados crudos en esta máquina antes de escribir.
Operamos un pequeño laboratorio de IA en hardware que cabe bajo un televisor: una mini-PC AMD Strix Halo con 64GB de memoria compartida. Un Qwen3.8-27B ha sido nuestro modelo principal y motor diario desde mediados de agosto. Esta semana hicimos una pregunta más difícil: ¿puede esta misma máquina correr también Ornith-1.5-35B, un modelo abierto más grande, al mismo tiempo, y es realmente bueno cuando lo mides con justicia?
La respuesta es sí, con tres advertencias. Aquí está todo, incluido lo que falló. Un número abajo fue medido mal primero por nuestra propia herramienta. La historia, al final.
La configuración
Una máquina. Dos modelos, residentes al mismo tiempo, sin intercambio:
- Qwen3.8-27B (nuestro "campeón", sirviendo el producto): contexto de 262k, visión adjunta.
- Ornith-1.5-35B-A3B (el recién llegado, carril de razonamiento): una construcción Mixture-of-Experts que solo activa ~3B parámetros por token. Corremos una cuantización APEX-Compact de 17.4GB. Juntos, los dos modelos usan 43.4 de 64GB, con unos 20GB de margen.
Ese margen importa: esto solo cabe gracias a un truco de memoria que verificamos (ver abajo). La cuantización de fábrica de ~22GB también cabe, pero con menos holgura.
El marcador, cada número emparejado, mismos problemas, misma máquina
Nunca comparamos dos números que vienen de lugares distintos. Ambos modelos corrieron los mismos conjuntos fijos de problemas, uno tras otro, en la misma máquina:
| Prueba | Campeón 27B | Ornith 35B | Lectura |
|---|---|---|---|
| Mate de primaria (GSM8K, calificación estricta, 2×2 emparejado, mismos 60 problemas, n=60/celda) | 96.7% sin razonamiento; 96.7% con razonamiento (resultados idénticos, McNemar p=1.0) | 90.0% sin razonamiento; 98.3% con razonamiento (p=0.0625, marginal con n=60) | En la mejor configuración de cada modelo: empate a un problema (p=1.0). El razonamiento le cuesta al campeón 2.4× tiempo para cero ganancia; Ornith lo necesita |
| Código, problemas limpios (HumanEval, mismos 30 congelados) | 28/30 | 26/30 | Empate dentro del ruido |
| Código, mundo real (LiveCodeBench, mismos 30) | 20/30 | 17/30 | Ventaja ligera del campeón, no decisiva con n=30 |
| Visión, mismas 6 capturas reales | 6/6 | 5/6 | Ornith malleyó un correo en un formulario (dominio con error) |
Si solo recuerdas una fila: un modelo de razonamiento de 35B ya corre a la par de nuestro motor diario en esta clase de hardware. Hasta mediciones emparejadas como esta, eso era una discusión de foro.
Las tres advertencias
- Razonar es un dial, no una brecha de modelo. Medido emparejado (2×2, mismos problemas, mismo protocolo): el campeón obtiene 96.7% con razonamiento apagado Y encendido (resultados idénticos, p=1.0), así que su interruptor no compra nada aquí a 2.4× el tiempo. Ornith obtiene 90.0% sin razonamiento y 98.3% con él. En las mejores configuraciones, los dos modelos empatan dentro de un problema (p=1.0). Números anteriores que comparaban Qwen sin razonamiento contra Ornith con razonamiento tenían regímenes mezclados; esta tabla emparejada es la verdad y los reemplaza.
- Código es un empate, no una victoria. 26/30 contra 28/30 en problemas idénticos está dentro del ruido. No reclamaremos un campeón de código con estos datos.
- Visión tiene un fallo. En una captura real de un formulario de registro, Ornith devolvió un correo con el dominio mal leído. Es una respuesta incorrecta, no un casi. Nuestro campeón obtuvo los 6. Muestra pequeña, etiquetada: 5/6.
Lo que NO funcionó (la parte que pocos publican)
Probamos la decodificación especulativa de dos maneras, porque prometía velocidad gratis:
- La cabeza de borrador entrenada que viene en las builds APEX: aceptó solo ~33% de los tokens de borrador, y hizo la generación ~9% más lenta de punta a punta. Muerta en este hardware, medido, dos veces.
- Un borrador improvisado: misma clase de ~33%. Mismo veredicto.
La decodificación especulativa es un truco de ancho de banda de memoria, y el ancho de banda de esta máquina se va en los dos modelos residentes. La configuración correcta es APAGADA, y cualquiera con una máquina similar debería empezar ahí en vez de pagar nuestro costo de descubrimiento.
El truco de memoria que lo hizo caber
La build APEX-Compact empaqueta el 35B en 17.4GB (contra ~22GB de fábrica en el mismo nivel de calidad Q4). No pudimos medir un costo de calidad con estos tamaños de muestra: mate de primaria 95.0% contra 96.7% de fábrica con n=60, y resultados idénticos en un conjunto de 15 problemas de razonamiento de código. Esos ~4.3GB de ahorro son la diferencia entre "un modelo a la vez" y "dos modelos siempre encendidos", que es todo el punto de la máquina.
Velocidad, etiquetada
- Escribir una respuesta larga: ~55 tokens/segundo sostenidos. Una respuesta de 200 palabras llega en 6-7 segundos. Una corrida completa de razonamiento en un problema difícil: minutos.
- Leer documentos largos (prefill): ingresamos 130,715 tokens, un libro entero, en 359 segundos (~364 tokens/segundo), con el chip a 72°C todo el camino. El trabajo de contexto largo es donde esta build MoE se gana su lugar.
Nuestra tarjeta de configuración (si tienes la misma máquina)
Decodificación greedy (temperatura 0), caché KV q4_0, decodificación especulativa APAGADA, pesos APEX-Compact Q4, presupuesto de mate 2048 tokens, presupuesto de código difícil 8192 (2/30 problemas aún toparon el tope, etiquetado, no oculto). Nada aquí es exótico; todo fue medido contra al menos una alternativa en esta máquina antes de conservarlo.
Por qué publicar todo
La mayoría de los posts de "corrí un modelo grande localmente" muestran una captura y un número de tokens por segundo. Pensamos que el artefacto valioso es la tabla emparejada con fixture fijo y los fracasos incluidos, incluyendo la corrida donde nuestra propia herramienta de calificación truncó la salida del modelo y brevemente nos dijo que era malo en mate (0.467). No lo era; nuestro instrumento estaba equivocado. Esa diferencia es visible en las dos configuraciones guardadas. Mismos problemas: 0.967. Ambos JSON citados abajo, porque el instrumento debería ser sospechado tan seguido como el modelo.
Fuentes (archivos de resultados crudos, rutas en la máquina): GSM8K 2×2 emparejado ~/exp/2x2-gsm8k/summary.json (campeón 58/60 en ambas celdas; orn 54/60 sin, 59/60 con; McNemar p=1.0/0.0625/1.0; medianas 28.3/68.5/11.4/23.3s; corrida 2026-08-24T19:42Z, puertas vivas, auto-prueba leída antes de calificar). GSM8K Ornith de fábrica corregido ~/exp/w1-35b/gsm-full-b/Ornith35B/results_2026-08-22T01-26-41.json (estricto 0.9667); el falso arranque results_2026-08-22T01-00-27.json (estricto 0.4667, truncamiento de instrumento). APEX-Compact ~/exp/w4-35b/gsm-run.log (0.9500). HumanEval-30 Ornith ~/exp/w1-35b/bench-results-default.log (26/30); campeón 28/30 (~/exp/bench-results-default.log, verificado 2026-08-24). LiveCodeBench-30 Ornith ~/exp/w3b-35b/verdict.txt (17/30, truncados 2/30); campeón 20/30 (registrado en el diseño de comparación, LEÍDO; bytes de resultado aún no localizados, etiquetado). LCB-15 paridad ~/exp/w4-35b/lcb15-run.log (7/15, idéntico a fábrica). Visión UI real: Ornith ~/exp/vision35b-results.log (5/6); campeón ~/exp/vision-real-results.log (6/6). Velocidad de decodificación ~/exp/w4-fire.log (sin espec 55.9 tok/s; espec más lento 50.4 contra 55.2, emparejado, mismo binario). Prefill ~/exp/ornith-window-results.log (359s, 130,715 tokens, 72°C). Aceptación especulativa ~0.33: comparadores window-4. Memoria: pesos APEX-Compact 17.4GB; doble residente 43.4/64GB GTT (lectura viva 2026-08-23). Nota de régimen: lecturas anteriores del campeón GSM8K de 70% estricto y 98% son anteriores al protocolo emparejado y quedan reemplazadas por el 2×2 para esta pieza.