Capítulo 3: Pesos, KV cache, estado recurrente y visión. En este capítulo aprenderás a separar cuatro componentes que suelen confundirse al hablar de memoria.

Cuando alguien dice que un modelo “cabe en la GPU”, puede estar hablando sólo del archivo de pesos. El servidor necesita más. Hay buffers del runtime, activaciones temporales, estructuras de ejecución y memorias que crecen con la secuencia. En Ornith, además, la arquitectura híbrida obliga a distinguir el cache KV del estado recurrente. Si todo se resume en una sola cifra, se pierde la causa real de un límite o de un ahorro.

Los pesos son los parámetros aprendidos. La cuantización Q4_K_L reduce su tamaño respecto del checkpoint BF16 y conserva ciertas partes con más precisión. Ese formato determina cuánto ocupa el artefacto principal y qué kernels puede usar llama.cpp. Cambiar los pesos puede alterar memoria, velocidad y calidad. No dice, por sí solo, cuánto contexto cabe ni cuántas solicitudes pueden ejecutarse al mismo tiempo.

El KV cache guarda claves y valores producidos durante la atención. Crece con los tokens procesados y con la concurrencia. Cuantizarlo a Q4 reduce su huella frente a tipos de mayor precisión, aunque añade costos y posibles efectos de calidad que deben medirse. En el perfil activo, la combinación es Q4_K_L para pesos y Q4 para KV. Son dos decisiones separadas, aunque ambas incluyan la etiqueta Q4.

Los tres slots del servidor representan espacios para secuencias. Si cada secuencia es corta, los tres pueden ser prácticos. Si todas se acercan al contexto máximo, el consumo cambia de escala. Por eso “tres slots configurados” no equivale a “tres contextos largos validados”. La prueba correcta debe fijar longitudes, concurrencia, prompts, memoria disponible y criterio de éxito, además de observar errores de memoria y corrupción de respuestas.

El estado recurrente pertenece a las capas de atención lineal de la arquitectura Qwen3.5 heredada por Ornith. No es el mismo objeto que el KV cache de las capas de atención completa. Su forma, persistencia y manejo dependen del runtime. Reducir el KV no implica que el estado recurrente disminuya en la misma proporción. Tampoco se puede calcular la capacidad total usando una fórmula de Transformer convencional y olvidando la ruta recurrente.

Fuente A separa claramente pesos y KV, y documenta el servicio local con Q4_K_L y KV Q4. También describe la arquitectura híbrida y advierte que el rendimiento no tiene trazabilidad cerrada. Fuente B aporta más detalle sobre perfiles de KV y estimaciones del estado recurrente, pero esos detalles siguen siendo Fuente B cuando no existe corroboración equivalente. Consenso cubre la necesidad de tratar pesos, KV y estado recurrente como capas distintas de memoria; no convierte una estimación en medición.

La visión agrega otra confusión. El checkpoint original de Ornith incluye una torre visual y un contrato multimodal. En GGUF, llama.cpp suele manejar la ruta visual mediante un mmproj externo. El servicio actual no carga ese proyector. Esto confirma un perfil textual y evita el consumo del componente externo. No confirma que el GGUF principal haya sido podado ni que se hayan eliminado todos los tensores relacionados con visión.

Para afirmar un ahorro visual exacto hay que identificar el mmproj, su tamaño, su hash y su condición de carga. Para afirmar que el modelo principal es físicamente text-only hay que inspeccionar el artefacto y comprobar que configuración, índice y tensores son coherentes. Omitir un componente en runtime es reversible. Borrar o exportar pesos produce otro artefacto y exige pruebas de equivalencia. Son operaciones distintas.

La calidad visual tampoco se hereda de la arquitectura. Que existan una torre, tokens especiales y una interfaz para imagen o video demuestra capacidad estructural. No demuestra que el postentrenamiento de Ornith conserve buena precisión visual. En este Atlas, visión debe quedar como arquitectura presente y operación local no validada, porque el servidor activo no usa mmproj externo.

MTP toca otra zona del mapa. La configuración oficial declara una capa MTP, pero el perfil local no tiene una evaluación funcional de sus pesos, aceptación, memoria o utilidad. DFlash es un archivo auxiliar separado y sigue apagado. Ninguno debe sumarse al cálculo del baseline como si ya participara en cada generación.

La forma más limpia de medir memoria es construir perfiles. Primero, pesos fijos y KV fijo con una sola secuencia. Después, misma cuantización de pesos con otros tipos de KV. Luego, concurrencia escalonada. En cada corrida se registra memoria al cargar, durante prefilling y durante generación. Sólo después se prueba MTP o DFlash en perfiles aparte. Así, si cambia el resultado, sabemos qué variable lo produjo.

Confirmado hoy… El sistema activo combina pesos Q4_K_L, KV Q4, tres slots y ejecución textual sin mmproj externo. Pesos, KV, estado recurrente y visión son componentes distintos.

Falta demostrar… La huella medida de cada componente, el comportamiento con varias secuencias largas, el contenido visual exacto del GGUF y el costo o beneficio funcional de MTP.

Siguiente capítulo… Compararemos rutas de cuantización, qué modifica cada una y cuáles son las mediciones mínimas para hablar de calidad, memoria y rendimiento.