¿Cuántos bits necesita una IA?

Decides descargar un modelo de IA de ocho mil millones de parámetros.

Tienes un ordenador, algunas tareas en mente y la creencia optimista de que descargar algo es una actividad con principio y fin.

Entonces llegas a la página del modelo.

Hay una versión FP16. Una de ocho bits. Una de seis. Una de cinco. Varias de cuatro. Y algo llamado Q4_K_M, que parece el código de un repuesto que convendría fotografiar antes de ir a la ferretería.

Todas son versiones del mismo modelo entrenado. Contienen, en esencia, el mismo conjunto de parámetros aprendidos. Sin embargo, sus necesidades de memoria son muy distintas.

Tu primer impulso es comprensible: elegir la más grande. Seguro que contiene más de eso que hace útil al modelo.

Tu tarjeta gráfica, con sus ocho gigabytes de VRAM, también querría participar en la decisión.

La diferencia entre estas versiones se debe en gran parte a la cuantización de pesos: representar los pesos numéricos aprendidos por el modelo con menos bits, mediante aproximaciones cuidadosamente elegidas.

Reducir la precisión de esos números puede disminuir enormemente la memoria que ocupan.

Parece una ganga, seguida de inmediato por un motivo para desconfiar.

¿Qué se ha perdido? ¿Seguirá entendiendo tus documentos? ¿Podrá ayudarte con código? ¿Sabe un modelo de cuatro bits que Boston está en Massachusetts, o eliminaron la geografía para hacer sitio a la gramática?

No existe un departamento que decida qué ciudades sobreviven a la compresión.

Lo que cambia es la fidelidad con la que se conservan los números aprendidos. Esos números influyen en los cálculos, de modo que modificarlos puede afectar a cómo utiliza el modelo lo que aprendió.

Pero conservar cada bit disponible tiene un coste. Y para el trabajo que realmente quieres hacer, la precisión adicional puede justificar más memoria de vídeo, o quizá no.

Esa es la pregunta que se esconde tras todo el menú de descargas:

¿Cuánta precisión numérica del modelo original necesito, y qué puedo hacer con la VRAM que ahorro?

El modelo ya ha ido a la escuela

Antes de comparar cuatro bits con dieciséis, conviene separar aprender de almacenar lo aprendido.

Durante el entrenamiento, un modelo ajusta enormes conjuntos de valores numéricos llamados pesos. En conjunto, influyen en cómo reconoce patrones, sigue instrucciones y elabora respuestas.

Cuando descargas un modelo preentrenado corriente, ese entrenamiento ya ha sucedido.

La versión de cuatro bits no ha estudiado cuatro años mientras la de dieciséis estudiaba dieciséis. Son representaciones numéricas distintas del mismo modelo entrenado.

Primero vino la educación. La cuantización cambia cómo se conservan sus resultados.

Imagina que el entrenamiento produjo este peso:

Para entender la precisión numérica, compara estas representaciones:

Describen aproximadamente el mismo valor, pero conservan distinta cantidad de detalle.

La primera mantiene todas las cifras de nuestro ejemplo. La segunda redondea el valor a dos decimales. La tercera es una aproximación más gruesa.

Esa es la idea cotidiana de la precisión numérica: hasta qué punto el número almacenado conserva el valor que queríamos guardar.

Al representar los mismos pesos con menos bits, generalmente aceptamos aproximaciones más gruesas a cambio de consumir menos memoria.

El ejemplo decimal es ilustrativo. Los ordenadores usan formatos binarios, así que cuatro bits no significa cuatro decimales. Los formatos distribuyen sus bits de maneras distintas, y la cuantización real es más sofisticada que cortar cifras al final.

Pero el intercambio de fondo es real.

Más bits dan más margen para conservar fielmente los números aprendidos. Menos bits ahorran memoria, pero descartan parte del detalle numérico.

Como las capacidades del modelo dependen de esos números, perder detalle puede afectar a cómo utiliza lo aprendido.

A veces cuesta notar la diferencia. A veces importa.

La tarea consiste en averiguar qué caso corresponde a tu trabajo.

Tu tarjeta gráfica tiene un apartamento más pequeño

En tu SSD quizá quepan varias versiones de un modelo. Un disco de dos terabytes permite reunir una colección considerable.

Tu tarjeta gráfica es una casera menos generosa.

En los siguientes ejemplos, supongamos que quieres ejecutar el modelo íntegramente en una GPU dedicada. Sus pesos deben caber en la memoria de vídeo, o VRAM, de esa tarjeta, dejando espacio adicional para procesar tus peticiones.

Ese es el presupuesto de memoria que nos interesa aquí.

Un bit tiene dos estados posibles: cero o uno. Varios bits juntos pueden formar más combinaciones:

Cuatro bits ofrecen dieciséis combinaciones. Seis ofrecen sesenta y cuatro. Ocho ofrecen 256.

Un formato numérico utiliza esas combinaciones para representar valores. Más posibilidades de representación cuestan más memoria real.

Ocho bits forman un byte. Dieciséis bits forman dos bytes.

Considera un modelo simplificado con exactamente ocho mil millones de pesos. Con dieciséis bits por peso, sus datos de pesos sin añadidos requieren aproximadamente:

Es decir, unos 16 GB de datos de pesos que hay que alojar en VRAM, antes de añadir memoria de trabajo.

Una tarjeta gráfica de 8 GB no puede proporcionar ese espacio. No se vuelve más flexible cuando le explicas que el modelo tiene excelentes reseñas.

Con cuatro bits por peso, el cálculo idealizado queda así:

Los formatos reales añaden información auxiliar y pueden conservar algunos componentes con mayor precisión. Pero la diferencia básica es considerable.

El mismo conjunto de pesos aprendidos puede ocupar mucha menos VRAM.

Estas ecuaciones usan gigabytes decimales. El software puede mostrar GiB, una unidad ligeramente mayor. Más importante aún: describen solo los datos de los pesos, no toda la memoria necesaria para ejecutar el modelo.

Por tanto, cuatro bits no significa «necesita una tarjeta gráfica de cuatro gigabytes».

La relación útil es que, para un mismo modelo, menos bits por peso suelen dejar más memoria de vídeo disponible para todo lo demás.

Los ocho mil millones de parámetros siguen presentes. Les han revisado la ayuda para vivienda.

Qué almacenan realmente cuatro bits

Volvamos a nuestro peso imaginario:

¿Cómo puede un código de cuatro bits representar un número así?

Un código de cuatro bits puede identificar dieciséis posibilidades. En un ejemplo deliberadamente sencillo, podríamos hacer que esos códigos representaran dieciséis valores separados por pasos de 0.1:

Nuestro valor original no figura en la lista. El más cercano disponible es 0.4.

El sistema puede guardar el código compacto 4, junto con información compartida que indique que cada paso representa 0.1:

El tamaño del paso se llama escala.

La diferencia entre el peso original y su aproximación es:

Esa diferencia es el error de cuantización.

Este es un ejemplo didáctico, no la receta literal de Q4_K_M. Los pesos reales pueden ser negativos y los métodos prácticos eligen sus representaciones con más cuidado.

Muchos métodos dividen los pesos en grupos, cada uno con una escala adecuada u otra información de interpretación. Por eso, un mismo código de cuatro bits puede representar valores aproximados distintos en grupos diferentes. El modelo completo no está limitado a una única lista universal de dieciséis números. La guía de cuantización de Hugging Face explica estas correspondencias.

Piensa en una regla cuyas marcas pudieran espaciarse según las medidas que tienes delante.

Un grupo de valores muy próximos se beneficia de marcas juntas. Otro repartido por un intervalo más amplio necesita una distribución diferente.

Sigues teniendo un número limitado de marcas. Puedes colocarlas inteligentemente, pero no crear otras a fuerza de entusiasmo.

Los ordenadores siguen siendo decepcionantemente inmunes al entusiasmo.

Cómo llega el redondeo a la respuesta

Nuestro peso original era 0.3726. Su aproximación es 0.4.

Supongamos que el valor numérico de entrada es 2. Con el peso original obtenemos:

Con la aproximación obtenemos:

La operación es la misma. El resultado ha variado.

Un modelo realiza enormes cantidades de cálculos con sus pesos. Los resultados alimentan cálculos posteriores a través de sus capas.

Cuando preguntas por Boston, tu texto se divide en tokens —palabras o fragmentos de palabras— y se convierte en representaciones numéricas. Estas cambian a medida que recorren el modelo.

Esos valores numéricos cambiantes se llaman activaciones. Los pesos aprendidos ayudan a determinar cómo se transforman.

Una operación habitual puede escribirse de forma compacta:

Aquí, $X$ contiene la información numérica de entrada, $W$ los pesos aprendidos y $Y$ el resultado transformado.

Detrás de esa pequeña ecuación puede haber una enorme cantidad de multiplicaciones y sumas. Mientras el modelo parece hablar tranquilamente de la arquitectura de Boston, el hardware hace aritmética con una intensidad que preocuparía a un contable humano.

Cambiar los pesos puede cambiar, por tanto, los cálculos y, finalmente, la respuesta.

Pero los efectos no se reducen a sumar todos los errores de redondeo. Algunas diferencias se compensan. Otras tienen poca importancia práctica. Otras afectan a partes más relevantes del cálculo.

Los buenos métodos de cuantización intentan conservar un comportamiento útil pese a las aproximaciones.

Los investigadores también estudian cómo se usan realmente los pesos. AWQ, o Activation-aware Weight Quantization, utiliza información sobre las activaciones para proteger canales importantes mediante cambios de escala. La investigación sobre AWQ describe este enfoque.

La precisión no importa por igual en todas partes.

Al parecer, incluso dentro de una red neuronal, algunos números han negociado mejores contratos.

Boston sobrevive. El itinerario necesita más atención.

Supongamos que preguntas a varias versiones del mismo modelo competente:

¿Está Boston en Massachusetts?

Todas podrían responder correctamente.

Boston sobrevive a la cuantización de cuatro bits. Massachusetts sigue donde lo dejamos. Nadie ha trasladado el río Charles a Ohio.

Prueba ahora con una petición más exigente:

Me alojo cerca de Back Bay. Organiza un día con un museo, una librería independiente, una cena de marisco y dos horas libres por la tarde. No tengo coche, quiero evitar caminatas largas y necesito llegar a South Station antes de mi tren de la noche.

El modelo debe coordinar varios requisitos. También necesita información fiable sobre horarios y transporte.

Hay más oportunidades de que se manifiesten sus debilidades.

Una buena versión de cuatro bits puede resolver la tarea muy bien. Una versión de mayor precisión puede conservar mejor la capacidad del modelo original para coordinar esos requisitos. Ninguno de los resultados se deduce automáticamente del número de bits.

Lo mismo puede ocurrir al comparar propuestas con exclusiones complicadas, modificar código sin romper funciones relacionadas o resolver un problema con varios pasos dependientes.

Esas tareas nos dan motivos para cuidar el comportamiento aprendido del modelo.

Pero precisión numérica y exactitud de los hechos son cosas distintas.

Un modelo puede conservar sus pesos con mucha precisión y aun así carecer de la información necesaria para responder. Más bits no aportan un horario actualizado que nunca ha recibido.

Dieciséis bits no convencen a un restaurante cerrado de que vuelva a abrir.

Y una respuesta más detallada no es necesariamente más correcta. Un modelo puede equivocarse brevemente o presentar una explicación admirablemente organizada de su equivocación.

La seguridad en uno mismo, por desgracia, ocupa muy poco espacio.

Entonces, ¿para qué conservar la versión de dieciséis bits?

Si una versión de cuatro bits puede responder bien, ¿por qué usar la más grande?

Porque «funciona igual de bien en esta tarea» no equivale a «conserva todo el comportamiento del modelo original en todas las tareas».

Un checkpoint de dieciséis bits suele servir como versión de alta precisión a partir de la cual se crean variantes más pequeñas. Conservarlo evita la aproximación adicional que introduce la cuantización a pocos bits.

Eso importa cuando preservar el comportamiento original pesa más que reducir las necesidades de memoria.

Quizá tu trabajo revela una debilidad de la versión cuantizada. Quizá evalúas el modelo con un conjunto amplio de tareas. Quizá tienes suficiente VRAM para los pesos de alta precisión, el contexto y el espacio de trabajo, y no hay mucho motivo para aceptar más pérdida numérica.

Una precisión mayor no garantiza una respuesta correcta. Elimina una fuente adicional de cambios.

La versión original también es valiosa como punto de partida para otros trabajos: crear nuevas cuantizaciones, comparar métodos o preparar el modelo para entrenamiento adicional.

Una vez descartado el detalle numérico, convertir la representación pequeña de nuevo a un formato mayor no lo recupera.

Escribir 0.400000 en vez de 0.4 no devuelve 0.3726. Le pone a la aproximación un traje más largo.

El entrenamiento adicional merece una distinción aparte. Instalar un modelo de dieciséis bits no hace que siga aprendiendo automáticamente durante una conversación normal. El entrenamiento exige un proceso que actualice parámetros.

Las representaciones de mayor precisión son útiles para ese trabajo, aunque también existen enfoques de pocos bits. QLoRA, por ejemplo, mantiene congelado un modelo base de cuatro bits mientras entrena componentes adicionales llamados adaptadores. El artículo de QLoRA explica el método.

Así pues, los modelos de dieciséis bits tienen usos prácticos. Conservan un punto de partida más fiel y pueden ayudar a evitar degradaciones relevantes para una tarea concreta.

Lo que no ofrecen es una mejora automática de «conoce Boston» a «ha hecho un doctorado sobre Massachusetts».

Y por qué quizá no necesites dieciséis bits

La mayoría de quienes descargan un modelo local quieren hacer algo.

Quieren ordenar notas, entender un documento, redactar un correo, comparar productos, trabajar con código o explorar un tema.

Normalmente no intentan conservar cada detalle numérico porque sí.

Si una buena versión de cuatro, cinco o seis bits resuelve bien sus tareas, la memoria adicional de una versión más precisa puede aportar poca mejora práctica para ese uso concreto.

Esta es la diferencia entre una diferencia medible y una diferencia que cambia tu experiencia.

Ambas importan, pero responden a preguntas distintas.

Supongamos que dos versiones hacen resúmenes igual de útiles de los documentos que realmente lees. Una ocupa mucha más VRAM. La otra deja espacio para documentos más largos y más historial de conversación.

Elegir la representación pequeña puede ser una decisión técnica sensata.

No tienes que reservar una suite presidencial para cada decimal.

Al mismo tiempo, no existe una regla universal según la cual cuantizar a cuatro bits pierda solo un dos por ciento de calidad, o conserve un porcentaje fijo de inteligencia.

Una diferencia publicada corresponde a un modelo, método de cuantización, evaluación y configuración concretos. Otra carga de trabajo puede mostrar una diferencia menor, mayor o prácticamente irrelevante.

Investigaciones como GPTQ han demostrado cuantización de tres y cuatro bits con pérdidas pequeñas en las evaluaciones publicadas, incluso en modelos muy grandes. Eso demuestra que el intercambio puede funcionar extraordinariamente bien. No es una garantía para cualquier modelo y tarea. El artículo de GPTQ describe los resultados.

La pregunta útil es, por tanto, personal y comprobable:

¿Sigue haciendo esta versión pequeña mi trabajo lo bastante bien, y vale más para mí la VRAM ahorrada que la diferencia restante?

Para muchas tareas cotidianas, la respuesta puede ser sí.

En algunas tareas exigentes, una precisión mayor puede ganarse su sitio.

Ninguna decisión exige afiliarse a un bando en internet.

Cuatro bits y un MacBook

La idea de reducir la precisión de las redes neuronales existía mucho antes de que los modelos de lenguaje locales se hicieran populares.

Lo que cambió fue la escala de la oportunidad.

Al crecer los modelos hasta miles de millones de parámetros, reducir los bits por peso podía transformar una necesidad de memoria impracticable en algo que un ordenador personal podía alojar.

En marzo de 2023, esa posibilidad adquirió una forma especialmente tangible con llama.cpp, de Georgi Gerganov.

El 11 de marzo, el desarrollador Simon Willison documentó la ejecución del modelo LLaMA de siete mil millones de parámetros en su MacBook Pro M2. Su ordenador tenía 64 GB de memoria; el archivo del modelo ocupaba unos 4 GB tras la cuantización a cuatro bits. Su relato de primera mano sigue disponible.

Un modelo de lenguaje entrenado respondía preguntas localmente en un portátil.

Para quienes estaban acostumbrados a oír hablar de centros de datos y enormes presupuestos de entrenamiento, aquello cambiaba la perspectiva. Podías experimentar con un modelo competente en un ordenador personal sin comprar también refrigeración industrial y contratar al responsable de mantenimiento del edificio.

La cuantización no hizo gratuito el entrenamiento original. Ayudó a que el resultado entrenado fuera práctico de utilizar.

Los modelos costaban mucho de educar y resultaron sorprendentemente tolerantes con el estado de sus apuntes.

Y una vez demostrada la utilidad de una precisión muy baja, los investigadores siguieron explorando hasta dónde podían llegar.

Los programadores a veces llegan a la filosofía restando uno repetidamente.

Q4_K_M y otras formas de letra pequeña

Vuelves a la lista de descargas.

Ahora entiendes los cuatro bits. Por desgracia, Q4_K_M parece contener varias opiniones adicionales.

La etiqueta identifica una receta concreta de cuantización. El cuatro apunta a su representación de pesos de pocos bits, pero los formatos reales necesitan más que los códigos compactos.

También pueden guardar escalas, otra información de interpretación y algunos componentes del modelo con mayor precisión.

Por eso, un formato «de cuatro bits» puede tener un promedio de más de cuatro bits efectivos por peso.

Dos archivos etiquetados como de cuatro bits pueden diferir en tamaño y comportamiento. Importa la receta, no solo la cifra del titular.

Un modelo de cuatro bits se parece a una instalación de software «de cinco minutos» en un aspecto limitado: la cifra es útil, pero conviene mantener buenas relaciones con las notas al pie.

También puedes ver GGUF, que designa el formato del archivo que contiene el modelo y sus metadatos. Es una etiqueta de otra clase que Q4_K_M, que describe una receta de cuantización.

Y FP16 y BF16 son ambos formatos de coma flotante de dieciséis bits, pero reparten esos bits de manera distinta entre rango numérico y precisión.

Puedes entender la elección práctica sin memorizar cada distribución interna.

Lo importante es que el número de bits no identifica por completo el formato, y tu entorno de ejecución —el software que ejecuta el modelo— debe admitir la versión elegida.

Las abreviaturas pueden quedarse en conocidas. No tienes que adoptarlas como familia.

Los pesos pequeños también tienen que desplazarse

Surge una pregunta razonable: si los pesos se guardan como códigos compactos, ¿tiene el ordenador que expandir todo el modelo a una enorme copia de alta precisión antes de usarlo?

Una implementación adecuada no necesita conservar permanentemente esa copia expandida.

Las rutinas optimizadas pueden leer bloques compactos de pesos e interpretar sus valores aproximados durante el cálculo. Parte de la aritmética puede seguir usando mayor precisión.

Eso no recupera la información perdida en la cuantización. Multiplicar 0.4 con mucha precisión no revela que el peso original era 0.3726.

Mantener compactos los pesos también reduce la cantidad de datos de pesos que debe circular por el sistema de memoria.

Ese movimiento lleva tiempo. El ancho de banda de memoria describe la velocidad a la que se transfieren datos. Cuando moverlos es un cuello de botella importante, las representaciones pequeñas pueden reducir las esperas del procesador.

Pero descodificar representaciones compactas puede exigir trabajo adicional. El rendimiento depende del hardware, el entorno de ejecución, el formato y la tarea.

Un formato que acelera la generación de respuestas puede comportarse de otra manera al procesar una petición larga.

Por eso, «cuatro bits siempre es más rápido» no es una regla fiable. Tampoco «la descarga más pequeña dará la respuesta más rápida».

El archivo pequeño normalmente se descargará antes en las mismas condiciones. Reconforta que al menos una parte de la conversación se comporte bien.

Para la velocidad real de inferencia, sigue siendo útil medir en la configuración prevista.

Los pesos caben. Ahora el modelo quiere trabajar.

Aquí es donde la VRAM ahorrada resulta especialmente útil.

Los pesos son solo una parte de la memoria necesaria para ejecutar un modelo. También necesita espacio para cálculos temporales y búferes del entorno de ejecución.

Muchos modelos mantienen una caché KV, que guarda información intermedia asociada a tokens ya procesados. Reutilizarla evita repetir parte de los mismos cálculos al generar el token siguiente. Hugging Face explica cómo funciona esta caché.

Tus instrucciones, los documentos aportados, el historial de conversación y la respuesta en curso forman parte del contexto del modelo.

Un contexto más largo suele necesitar más memoria de caché, aunque la relación exacta depende de la arquitectura y del entorno de ejecución. Algunos diseños limitan o cambian ese crecimiento.

Los pesos no crecen porque pegues otro capítulo. La demanda adicional procede de manejar un contexto más largo.

Hay otra distinción fácil de pasar por alto: pesos de cuatro bits no implican automáticamente una caché KV de cuatro bits. La precisión de pesos y la de caché se eligen por separado.

Para un plan sencillo de memoria GPU, podemos pensar así:

El margen de trabajo cubre, por ejemplo, búferes de cálculo y espacio reservado para otros usos de la GPU.

Pongamos números a la idea.

La documentación de llama.cpp indica un archivo Q4_K_M para Llama 3.1 8B de aproximadamente 4.58 GiB, y uno Q8_0 de unos 7.95 GiB. Esos tamaños publicados de archivos de pesos sirven como punto de partida para una estimación; no son mediciones de toda la VRAM utilizada en ejecución. Fuente: comparación de cuantizaciones de llama.cpp.

Supongamos que, para este ejemplo de planificación, usamos esas cifras para los pesos y reservamos 1 GiB para la caché de conversación y otro 1 GiB para espacio de trabajo y otros usos.

Con la representación pequeña de los pesos:

Con la mayor:

En una tarjeta con un presupuesto de VRAM de 8 GiB, son situaciones muy diferentes.

Los márgenes de un gigabyte son supuestos de este ejemplo. Los requisitos reales dependen del entorno de ejecución y la carga de trabajo.

Pero ahora se ve por qué importa el cálculo completo.

La representación mayor de los pesos casi cabe por sí sola. La carga de trabajo prevista no.

La representación pequeña deja espacio para trabajar.

Por eso, la representación más fiel no es automáticamente la configuración más útil en un ordenador concreto.

Un modelo que consume casi toda la VRAM disponible se parece a un sofá magnífico que ocupa casi todo el salón. El sofá cabe. Ahora cenas de pie.

La cuantización puede hacer sitio para el resto de la velada.

¿Puede ayudar la RAM del sistema?

Sí, cuando el modelo y el entorno de ejecución admiten esa distribución.

Un modelo puede ejecutarse en la CPU usando RAM del sistema. Puede ejecutarse en una GPU usando VRAM. O el entorno de ejecución puede repartir el trabajo: una parte del modelo usa RAM y otra utiliza la GPU. Proyectos como llama.cpp admiten ejecución en CPU y funcionamiento mixto CPU–GPU.

En sistemas de memoria unificada, el procesador y el hardware gráfico comparten un conjunto de memoria, lo que vuelve a cambiar la distribución.

Estos enfoques permiten utilizar modelos que no cabrían enteros en la VRAM de una tarjeta dedicada. El rendimiento depende de cómo se organice.

Sin embargo, 8 GB de VRAM dedicada más 32 GB de RAM del sistema no se convierten en 40 GB de memoria GPU igual de rápida.

El entorno de ejecución debe distribuir adecuadamente datos y cálculos. Mover datos y realizar parte del trabajo en la CPU puede afectar a la velocidad.

Tu sistema operativo y las otras aplicaciones también necesitan RAM. No han aceptado mudarse simplemente porque te haya dado por la inteligencia artificial.

Del mismo modo, toda la base de datos de un agente no pasa automáticamente a la VRAM. La base de datos funciona en su propio entorno; los fragmentos recuperados y enviados al modelo pasan a formar parte del contexto.

Los cálculos GPU anteriores suponen que todos los pesos están en la tarjeta gráfica. Cambiar esa distribución modifica el plan de memoria.

De vuelta al botón de descarga

A estas alturas, la lista de archivos debería parecerse menos a un examen de admisión.

La versión de dieciséis bits conserva una representación de alta precisión de los pesos entrenados. La cuantización de ocho bits suele aproximarlos de manera menos agresiva que las alternativas de menos bits. Los formatos de cinco y seis ofrecen compromisos intermedios. Los de cuatro pueden hacer práctico un modelo competente con mucha menos VRAM.

En todas esas opciones, la pregunta de fondo es la misma: ¿cuánta fidelidad numérica beneficia a tu tarea?

Para clasificaciones breves, pueden bastar un contexto modesto y una buena versión de pocos bits. Para un asistente de programación que examina varios archivos, o un agente que lleva instrucciones e historial de tareas, la memoria de trabajo puede ser una parte considerable de los requisitos.

Algunas tareas muestran una ventaja útil de la precisión mayor. Otras producen resultados igual de satisfactorios con menos.

Un modelo que cabe con un saludo breve puede tener dificultades con el documento que querías darle. Un modelo de alta precisión que no puede alojarlo ha conservado sus números de maravilla, pero ha perdido de vista el encargo.

Por eso las pruebas deben parecerse a tu trabajo.

Si quieres comparar pedidos de imprenta, dale pedidos representativos con respuestas conocidas. Si buscas ayuda con código, usa código que puedas evaluar. Si quieres un itinerario por Boston, comprueba que respete los límites de caminata y que los horarios procedan de una fuente fiable.

Situar correctamente Boston en Massachusetts es un comienzo prometedor. No acredita al modelo para organizarte todo el fin de semana.

Al comparar cuantizaciones, mantén el modelo de origen y la tarea lo más constantes posible. Así resulta más fácil juzgar el efecto del cambio de representación.

Ese es también el propósito de explorar presupuestos de memoria en Green Zone: ver cómo podrían encajar los pesos elegidos, el contexto, la distribución de memoria y la capacidad disponible.

Una estimación ayuda a elegir una configuración plausible. Probarla con tareas representativas te dice si te resulta útil.

Quizá descubras que cuatro bits conservan suficientes capacidades para todo lo que necesitas. Quizá prefieras cinco o seis. O quizá tu trabajo se beneficie de más precisión y dispongas de VRAM suficiente para utilizarla con comodidad.

No hay premio por dedicar cada byte disponible únicamente a los pesos.

Tampoco hay obligación de descartar precisión cuando aporta un beneficio útil.

El modelo ya ha aprendido. Tu decisión es con qué fidelidad conservar ese aprendizaje mientras le dejas espacio suficiente para trabajar en tu ordenador.

Vuelves a la página de descargas. Las etiquetas no han cambiado, pero ahora sabes leerlas.

Eliges una versión adecuada para tu entorno de ejecución, tu memoria de trabajo disponible y la tarea que realmente tienes en mente.

Boston sigue en Massachusetts. Tu ordenador tiene espacio para trabajar. Por fin puedes cerrar el hilo de comparaciones.

Alguien acaba de publicar un argumento detallado sobre la cuantización de dos bits.

No tienes por qué abrirlo.