Reducir la memoria de un modelo de lenguaje: los ahorros son menores de lo que sugieren los artículos

Cuando un modelo de lenguaje lee un prompt largo, almacena una clave y un valor por cada token. Ese almacén es la caché KV. Con 32.000 tokens ocupa 2,4 GB para una consulta en el modelo que probamos. Muchos artículos proponen descartar la mayor parte y conservar solo los tokens importantes. Lo probamos en una GPU gratuita y planteamos dos preguntas que los artículos rara vez hacen juntas. ¿Sigue encontrando el modelo los datos que necesita? ¿Y realmente se recupera la memoria?

Respuesta corta: al 25 % y 12,5 % de la caché, cada método probado perdió los datos necesarios casi siempre.

El modelo fue Qwen3-4B-Instruct en un T4 gratuito de Kaggle. La tarea era sintética: varios registros de proyectos («Project X has status S and codeword C») ocultos entre documentos no relacionados, y luego una pregunta sobre uno, dos o los tres. Las respuestas se calificaron por coincidencia exacta de la palabra clave. Los prompts fueron de 8k, 16k y 32k tokens, 6 casos cada uno. La ejecución se detuvo en un límite de tiempo acordado, así que el nivel de 32k tiene 3 de 6 casos. Quedan 255 resultados registrados de 306 planificados. Cada combinación de método y presupuesto que aparece a continuación tiene 15 preguntas.

Comparamos seis formas de elegir qué conservar: sin desalojo, una ventana deslizante, tokens aleatorios, una puntuación key-norm y nuestras propias reimplementaciones de las ideas de puntuación SnapKV y H2O. Cada una se ejecutó a nivel de token y a nivel de página (bloques de 16 tokens).

Fuente: resultados registrados de la ejecución, 255 registros. El presupuesto del 12,5 % es peor: 0 o 1 correcta de 15 para cada método.

Con la caché completa el modelo respondió 15 de 15. Con una cuarta parte, los mejores métodos lograron 2 de 15. La respuesta incorrecta típica conservaba el nombre del proyecto pero inventaba los dígitos, por ejemplo «cobalt-381» en lugar de «cobalt-2609». Nuestra lectura: la puntuación conserva el significado de un token y descarta el número raro que lleva la respuesta. Es una hipótesis de estas ejecuciones, no un mecanismo probado.

Los servidores de inferencia almacenan la caché en páginas de 16 tokens. Una página solo se puede reutilizar cuando sus 16 tokens han desaparecido. Si borras tokens dispersos, liberas mucho menos de lo que crees. Simulamos esta contabilidad en las mismas ejecuciones. Los métodos alineados a páginas liberan casi todo, pero también perdieron la respuesta. Los métodos que conservaban algo de precisión liberaron mucho menos.

Fuente: contabilidad simulada de páginas en bloques de 16 sobre las ejecuciones registradas (media de 30 casos por método). No es una medición en un servidor paginado real. Cada método basado en una puntuación eliminó lógicamente unos 1962 MB por pregunta, así que 320 MB liberados son el 16 % de eso. El método de ventana deslizante eliminó lógicamente 2376 MB por pregunta, y 2373 MB de eso se convirtieron en páginas enteras (el valor graficado). Por qué elimina más que los otros métodos no se comprobó, así que compáralo con cuidado.

Un resultado más. En la caché estática de Hugging Face que usamos, la decodificación no se aceleró tras el desalojo (unos 1510 a 1640 ms por token). Eso indica que la biblioteca sigue calculando la atención sobre todo el ancho. No dice que un servidor paginado se comportaría igual.

• Un modelo abierto de 4B en un T4 gratuito. Esto no dice nada sobre los modelos frontera.
• SnapKV y H2O aquí son nuestras reimplementaciones, sin comprobación contra los números publicados.
• Las páginas liberadas son simuladas. Solo la asignación de caché se midió en la GPU.
• El nivel de 32k está a medias. Todos los casos de 32k completados también fallaron.
• Una única carga de trabajo sintética. Las tareas reales podrían ser menos sensibles a estas pérdidas.

Qué respalda esto: una pregunta que vale la pena probar en serio. Un método tendría que elegir páginas enteras y conservar números y nombres. No hemos construido uno.