Por Simon Gonzalez de Cruz (el build en público en X @KyaniteLabs_). Inversión de la noche 3, 2026-08-20. La URL sigue siendo la primera. El mapa estaba mal.
El número primero: 6/6 retrieval exacto de agujas a ~198k después de revertir llama.cpp c7d8722. Misma semilla. Códigos plantados byte-idénticos. Todas las celdas finish_reason=stop. Cero atractores. La «cuenca degenerada» que publicamos el 2026-08-19 era, en lo sustancial, un bug de host-buffer en esta iGPU, no una ley de profundidad de Qwen3.8-27B.
Par ancla, prompts token-idénticos, server prompt_tokens=198.228 las dos noches: miss pre-revert (ok) → HIT exacto post-revert. El único delta = el revert. Crudo: needle-format-2026-08-19/README.md · depth-remap-results.log.
Lo que imprimió esa primera noche (instrumento contaminado)
En una pila que el server contó en 198.227 tokens pedí un código plantado a cinco profundidades. Al 25% me devolvió el código exacto y paró limpio. Ese hit ya no lo tratamos como ventana de posición. Al 35% y al 75% escribió el arranque de un reporte de code review que nadie le pasó:
- **Risk**: Low; 67 medium/lowEl mismo arranque. Dos veces. Temperature 0. Esa noche también se murió a 98 °C en el siguiente prefill. Esos hechos siguen siendo un log del binario viejo. No son una cuenca a nivel de modelo.
Lo que de verdad corrió
Una semilla. Una clase de pila. Config campeón: Qwen3.8-27B Q4_K_XL, K+V q4_0, ventana de 262.144 tokens, en un GMKtec EVO-X2 de $1.400. Las profundidades son fracciones del conteo del server. El generador dijo 262k. El server dijo 198.227. El instrumento se etiqueta con el contador de la fuente.
| Profundidad | Pre-revert (08-18) | Remap post-revert (08-19/20) |
|---|---|---|
| 10% | fail ok | HIT, stop |
| 25% | HIT, stop | HIT, stop |
| 35% | fail, reporte Risk, length | HIT, stop |
| 50% | fail ok (ptok 198.228) | HIT, stop (mismo ptok) |
| 75% | fail, reporte Risk, length | HIT, stop |
| 90% | el sweep se murió | HIT, stop |
6/6 en el build arreglado. n=1 por celda. Trátalo como mapa, no como medición. No cito los códigos plantados.
Después la caja cortó la corriente (sigue siendo verdad)
En el siguiente prefill largo el EC saltó a las 16:45:42Z. Línea del journal: temp=98C -> fan=100%. Sin panic, sin amdgpu, sin OOM. La temperatura más alta que esta chasis ha dejado aquí. Los fans ya estaban haciendo su trabajo. El load fue el bug: prefills de media hora uno detrás del otro, como 6 °C arriba del sobre 90-92 °C que tratamos como normal. Ese corte no es la cuenca y no se echa atrás.
La arquitectura se aguanta. La historia de la cuenca no.
Qwen3.8-27B es un híbrido: 64 capas, y solo 16 hacen atención completa. Las otras 48 son Gated DeltaNet — atención lineal con un estado de tamaño fijo. Así cabe el contexto de 262k en una mini-PC de $1.400 (17,2 GB de KV de atención en f16, no ~60 GB). El cache KV solo existe en las 16 capas de atención — 4 KB por token por capa, 64 KB por token en total, 17,2 GB en f16 a ventana llena de 262k. En q4_0 queda en ~4,8 GB. En q8_0, ~9,1 GB. El flip a 4 bits ahorró ~4,3 GB de GTT. Margen de verdad. El GSM8K pareado de promoción se aguanta solo.
Pensamos que la cuenca era ese decay gate. Una pila de 50k tokens en el binario pre-revert falló al 15%, 50% y 85% — el mismo atractor ok. Por eso esta página dijo que la predicción del horizonte de decay falló. Esas celdas de 50k ahora son sospechosas: mismo serving contaminado. No hemos repetido 50k en el build arreglado. No voy a dejar «este modelo no recupera a ninguna longitud» como claim actual.
El quote de prefijo caliente se aguanta como forma de producto. En el mismo mini-PC de $1.400 cargamos un prefijo de 198k tokens una vez: 1818s en frío (~30 min). Cuatro follow-ups contra ese prefijo en cache, todos finish_reason=stop: recuperar el código plantado; citar la frase (16s); sí/no de que existe un código (9s); resumir (27s). El retrieval es selectivo. Cargar es caro; mantener es barato. Crudo: results/quote-probe-2026-08-19/quote-results.log.
En qué me equivoqué con nuestro stack
Le eché la culpa al «fork». Después a GDN. El hueco que sí pudimos nombrar fue llama.cpp c7d8722 (incoherencia de host-buffer en esta iGPU). El mismo revert que devolvió la visión devolvió los IDs a contexto profundo. Primero el issue tracker, después otro mapa. Esa es la cacería. Casi abrí un issue upstream de caps ngram; el gauntlet lo mató. --spec-draft-n-max no tapa ngram-mod. --spec-ngram-mod-n-max sí, y nunca lo pusimos. Nuestra config. Su flag.
No voy a escribir «sin pérdida de calidad a contexto clase 200k» con celdas n=1. Nos ganamos «retrieval exacto a seis profundidades en este binario arreglado, esta semilla, este formato». Eso es todo.
Esta noche
El título viejo se queda en la URL para que se encuentre la corrección. El claim en vivo es la inversión: la cuenca era un bug. Visión: ya revertimos c7d8722 en público. Esta es la mitad de texto/retrieval del mismo commit. Actualización: la inversión replica entre semillas — segunda semilla 6/6, 13/13 celdas post-revert a 198k (canon 66afc21).
Logs crudos: results/needle-format-2026-08-19 (remap) y results/deep-context-2026-08-18 (noche contaminada) en qwen38-27b-strix-halo.
Condiciones: GMKtec EVO-X2 (Ryzen AI Max+ 395, 96GB unificados), Qwen3.8-27B Q4_K_XL, llama.cpp ROCm post-revert c7d8722, ventana 262.144 tokens, K+V q4_0, temperature 0, prompt_tokens ~198.227 reportados por el server, n=1 por profundidad, seed s4419. Una curva. Un mapa. No una ley.