Informe técnico 3: Operar IA local en una GPU de 16 GB

Código: ITL-IT-04 · Banco IT Lab, edición 1

Resumen

Este informe describe qué se puede esperar de una tarjeta gráfica de 16 GiB al operar modelos de IA local con trabajo real, a partir de las mediciones del Banco IT Lab. Aborda cinco asuntos: la memoria realmente utilizable, el efecto de la configuración del motor de inferencia, el comportamiento con contexto real largo, el coste de activar el razonamiento y los límites de lo que se midió.

En el banco, el mismo modelo pasó de 30,3 a 54,6 tok/s según la configuración del motor, y la configuración más rápida fue también la de menor memoria (13,3 GB). Con documentos reales de gran tamaño, la lectura cayó 13 veces cerca de 50.000 tokens, y la generación bajó de 36-43 tok/s con contexto corto a 7,5-14 tok/s con 80K-110K tokens ocupados. Activar el razonamiento convirtió dos reprobaciones en aprobaciones en un diagnóstico, a cambio de un aumento considerable de tokens y de tiempo. A juicio de IT Lab, una tarjeta de 16 GiB sirve para modelos cuantizados de 12B a 35B atendiendo a una persona o un proceso a la vez, y no basta para prometer contexto muy largo a buena velocidad ni uso simultáneo por varios usuarios, que no se midió.

1. Introducción y pregunta

Una organización pequeña que decide operar IA local con sus propios documentos suele partir de la ficha del hardware: la cantidad de memoria de la tarjeta y el tamaño de contexto que anuncia el modelo. Ninguno de los dos datos responde la pregunta operativa. Lo que interesa es qué modelos caben, a qué velocidad trabajan con documentos reales y qué ocurre cuando la ventana de contexto se llena.

Este informe responde tres preguntas de dimensionamiento con mediciones del banco:

1. Cuánta de la memoria nominal de una tarjeta de 16 GiB queda realmente disponible para el modelo.
2. Cuánto cambian la velocidad y la memoria con la configuración del motor de inferencia, para un mismo modelo.
3. Cómo se comporta la velocidad cuando el contexto es real y largo, y qué costo tiene pedirle al modelo que razone.

El informe de método, Informe técnico 4: Metodología del Banco IT Lab, describe el protocolo general. Los artículos Configurar un modelo local pesa tanto como elegirlo y Hardware de pyme para IA local con 16 GB presentan una versión breve de los hallazgos de configuración y de hardware que este informe documenta con detalle.

2. Método

Equipo y medición

Las mediciones se realizaron en un equipo que IT Lab definió y armó específicamente para pruebas: procesador Ryzen 7 5700X, 31 GiB de RAM y una tarjeta gráfica AMD Radeon RX 9070 XT de 16 GiB, con Linux. La tarjeta se eligió por ser hoy la opción más asequible con buena relación costo-beneficio que una empresa pequeña puede comprar. Los modelos evaluados cuentan con versiones optimizadas para tarjetas NVIDIA, por lo que se espera que el patrón general sea comparable en ese hardware; las cifras publicadas corresponden a este equipo.

La velocidad y la memoria se informan tal como las registra el servidor de inferencia, no como estimaciones. La velocidad de generación se expresa en tokens por segundo (tok/s); la velocidad de lectura es el procesamiento del texto de entrada antes de generar. La memoria se informa como pico de la tarjeta durante la corrida.

Familias de medición

El informe usa tres tipos de medición, todas con el mismo modelo o familia de modelos y sin cambiar el instrumento de evaluación entre configuraciones:

• Benchmark de configuración del motor. Un caso real de código, contexto de 65.536 tokens y una longitud fija de salida, repetido sobre configuraciones distintas del motor para un mismo modelo. Mide velocidad de generación, velocidad de lectura y memoria pico.
• Contexto real prearmado. Documentos reales completos, armados de una sola pieza con conteo de tokens (79.964, 109.874, 198.270, 227.733 y 247.581 tokens), en lugar de llenar el contexto por tramos. Mide lectura y generación con la ventana ocupada.
• Diagnóstico de razonamiento. Una repetición de un examen de trabajo agéntico con el razonamiento desactivado y activado, para medir cuánto corrige y cuánto cuesta en tokens y tiempo.

Juez, criterio de aprobación y mejor oportunidad

Cuando una medición incluye aprobación, la decide un juez automático, fijo y determinista, sin un modelo que evalúe a otro, con el criterio de aprobación fijado antes de la corrida. El protocolo exige además dar a cada modelo su mejor configuración, de modo que las diferencias de velocidad y de aprobación no se atribuyan al modelo cuando provienen de un montaje deficiente. Las configuraciones se documentan por modelo y no se publican sus valores finos.

Controles de calidad relevantes para este informe

• Control de memoria de la GPU. El margen de memoria se calibra contra el estado real del equipo: se exigen al menos 100 MB libres sobre el estado normal del sistema, en lugar de un límite fijo de 15,5 GiB. Un límite fijo mal calibrado puede descartar configuraciones viables sin avisar.
• Contexto real prearmado de una sola pieza. Evita que el llenado artificial por tramos oculte el comportamiento de la ventana completa.
• Medición del contexto máximo que cabe en memoria. Si un modelo no cabe en el tope de la tarjeta, se sondea el contexto máximo que admite y se documenta; no se lo excluye. En una batería de trabajo agéntico, dos modelos quedaron en 131.072 y 200.704 tokens bajo un tope de 15,4 GiB.
• Velocidad con decodificación especulativa. La decodificación especulativa usa un borrador de tokens que el modelo luego confirma. El contenido repetido puede inflar su velocidad, por lo que el banco la mide con una tarea nueva y declara la tasa de aceptación del borrador.
• Separación de evidencia. La pasada oficial se informa aparte de las sondas y los diagnósticos, en secciones rotuladas.

3. Resultados

Memoria utilizable

De los 15,922 GiB nominales de la tarjeta, el presupuesto de memoria del banco descuenta 1,28 GiB reservados para el sistema y 0,4 GiB de margen, lo que deja 14,242 GiB utilizables. El descuento es una reserva del sistema y del margen de seguridad, no el uso de otras aplicaciones durante las pruebas.

A juicio de IT Lab, ese número, y no la cifra de la ficha, es el que debe usarse para dimensionar. Con esa memoria, el banco cargó modelos de 12B a 35B en cuantización de 3 o 4 bits con contexto de trabajo de 64K a 131K tokens. El techo de contexto que admite la memoria varía por modelo, desde 32.768 hasta 262.144 tokens, y es un techo de carga, no una medida de rendimiento ni de comprensión de la ventana completa.

Con el contexto de texto completo, la visión supera el tope de memoria de 15,5 GiB; para incorporar imágenes hay que reducir el contexto.

Configuración del motor: pasada de referencia (misma tarea, mismo modelo)

La tabla compara cinco configuraciones del motor de inferencia con el mismo modelo, Qwen3.8-27B-GSQ-RCO, cuantizado a 3 bits, en el mismo caso real de código y con contexto de 65.536 tokens. Una corrida por condición. La temperatura de muestreo no está declarada en la fuente de estas filas, por lo que sus cifras no se comparan con las de otras tablas de este informe. Banco IT Lab, edición 1.

Para la configuración alternativa sin decodificación especulativa, la fuente registra además una segunda corrida de 30,1 tok/s. Para la configuración con decodificación especulativa sin caché cuantizada, la segunda corrida registra 40,1 tok/s. En la configuración optimizada, la lectura fue de 841 tok/s y la tasa de aceptación del borrador de 0,67. Una variante intermedia de borrador especulativo funcionó entre 52 y 57 tok/s, pero no cerró resultado por el límite de memoria y no se informa con cifra.

Tres lecturas de IT Lab. Primero, la configuración de referencia no era la más rápida de la serie. Segundo, la alternativa sin decodificación especulativa rindió menos y ocupó más memoria que la referencia. Tercero, la configuración optimizada fue la más rápida y la que menos memoria usó, con 3,6 GB menos que la de mayor consumo de la serie. La ganancia proviene de combinar una caché de atención cuantizada con decodificación especulativa; con la caché en precisión completa y decodificación especulativa a 64K, el pico llegó a 16,9 GB.

En una batería de cinco casos de programación, la configuración optimizada aprobó los cinco con velocidades de 50,7 a 57,8 tok/s y memoria de 14,2 a 14,4 GB, en una sola pasada.

Decodificación especulativa: velocidad y tasa de aceptación

La decodificación especulativa se midió con el borrador del propio modelo realmente cargado, sobre un caso nuevo de código, con Swift Flash-Next cuantizado a 3 bits y con el razonamiento activado y desactivado. Una corrida por condición. Bajo esas condiciones, la generación fue de 59,7 a 72,5 tok/s y la tasa de aceptación del borrador de 66,9 % a 87,3 %. Los tiempos totales por caso variaron entre 19,5 s y 2 min 06,9 s, y los tokens generados entre 1.137 y 7.337.

Dos conclusiones se sostienen. Un borrador más largo no implica más velocidad: dentro de cada modo, el mejor resultado no estuvo en el extremo. Y la tasa de aceptación cambia con el modo de razonamiento y con el muestreo. Como las salidas de las seis corridas tuvieron longitudes muy distintas, IT Lab no declara una configuración de borrador óptima universal; el valor de la cifra está en su rango y en que se midió con tarea nueva. Por ese motivo, el banco no mezcla en una misma tabla velocidades obtenidas con muestreos distintos.

En la configuración optimizada de la tabla de configuración del motor la tasa de aceptación fue de 0,67, y en otras corridas de producción del banco se registraron tasas de entre 0,57 y 0,67.

Triaje de tamaños y cuantizaciones (sonda)

Esta sonda se informa aparte de la pasada de referencia. Es una medición de dos casos con contexto de 32.768 tokens y caché cuantizada, y la temperatura de muestreo no quedó registrada: la velocidad de cada fila es fiable como medida, pero la comparación entre filas no es controlada.

Las velocidades de contexto corto del banco, entre campañas, fueron de 40 a 172 tok/s según el modelo, y los perfiles de código sostuvieron entre 51 y 58 tok/s, con 56 tok/s ponderados a 64K.

Contexto real: caída de lectura

Con contextos reales prearmados, la lectura va rápida hasta cerca de 50.000 tokens y luego cae 13 veces, de unos 665 tok/s a 54 tok/s, sin recuperarse a medida que se llena la ventana. Llenar un contexto de 110K tokens tomó cerca de 34 minutos. Una medición separada de la anterior, con cinco cuantizaciones del mismo modelo base y los mismos parámetros confirmados en el registro del servidor, mostró la misma forma: la lectura se mantuvo entre 508 y 571 tok/s hasta cerca del token 54.510 y descendió a unos 52 tok/s.

La causa de esta caída es probable, no confirmada: a juicio de IT Lab, lo más verosímil es que se agota lo que cabe en la memoria de la tarjeta y el resto de la caché de atención se lee desde la memoria del sistema. El banco no aisló ese mecanismo, y la forma de la caída es un hecho medido mientras que su explicación es una hipótesis.

La caída no es una constante del tamaño de la ventana. En un perfil distinto del mismo banco, con Swift Flash-Next cuantizado a 3 bits, una sesión de 80.124 tokens reales se leyó a 881,32 tok/s en 1 min 30,9 s, con generación a 50,4 tok/s y un pico de 15,33 GiB. Las dos mediciones no son comparables entre sí, pero muestran que la velocidad con contexto largo depende de cómo se configura la memoria, y que debe medirse con el perfil con el que se va a operar.

Generación con contexto lleno

La generación también se degrada con la ventana ocupada. En el mismo modelo, la velocidad pasó de 36-43 tok/s con contexto corto a 7,5-14 tok/s con 80K-110K tokens ocupados, con un pico de memoria de unos 15,46 GB. El efecto de dimensionamiento es directo: un modelo que "soporta 128K" y un modelo que trabaja a buena velocidad con 128K ocupados son afirmaciones distintas, y solo la segunda importa para leer documentos largos sin sacarlos de la organización.

Sondeo del contexto máximo que cabe

Cuando un modelo no cabe con su contexto nominal, el banco no lo excluye: busca por bisección el contexto máximo que admite bajo el tope de memoria y lo documenta. Con la memoria utilizable descrita arriba, el techo de carga de Qwen3.8-27B-GSQ-RCO y de Qwopus3.6-35B es de 262.144 tokens. Es una medida de capacidad de carga. La comprensión efectiva de esa ventana completa no se midió y no debe inferirse de ella.

Coste de razonar (diagnóstico)

Este apartado es un diagnóstico, no una pasada oficial. Repite un examen de trabajo agéntico con el razonamiento desactivado y activado en nivel medio. Una pasada por condición. El tope de salida debe elevarse al activar el razonamiento; de lo contrario el razonamiento consume el contenido y la respuesta llega vacía.

En los dos modelos Gemma, la activación del razonamiento corrigió un mismo episodio de aritmética que en la configuración desactivada valía 30 de 100 puntos, y con ello pasaron de no superar a superar el criterio. En los otros dos modelos, el resultado ya superaba el criterio sin razonar y el razonamiento solo aumentó tokens y tiempo. El modelo más pequeño de la tabla llevó su tiempo de 17,6 s a 688,6 s para ese cambio.

El diagnóstico dejó además tres observaciones sobre cómo se comparan estos niveles:

• Pedir razonamiento desactivado no garantiza que el servidor deje de razonar. Dos modelos devolvieron cero tokens de razonamiento, un tercero devolvió el mismo bloque de razonamiento con el interruptor apagado y encendido, y un modelo de pago sin control de nivel gastó 4.910 tokens de razonamiento en la corrida oficial desactivada. Por eso "razonamiento desactivado" no es homogéneo entre familias y no se compara entre ellas.
• Los niveles no existen de forma pareja: un modelo admite varios niveles y rechaza el más alto sin generar un solo token; otros dos solo distinguen encendido y apagado, y sus salidas en niveles superiores son idénticas byte a byte.
• Más nivel no implica un gasto proporcional: en un modelo, el nivel máximo usó menos razonamiento que el medio (300 contra 393 tokens).

En código, el mismo eje mostró un patrón similar. Con una variante de Qwen3.8 y contexto de 64K, el razonamiento desactivado aprobó 1 de 3 casos, el bajo 2 de 3 en 10 min 34 s y el medio 3 de 3 en 9 min 53 s. Esa comparación no aísla una sola variable, porque las pasadas de 24K y de 64K usaron configuraciones de memoria y de muestreo distintas.

Concurrencia: no medida

Todas las mediciones se hicieron en serie, con un modelo cargado a la vez. El banco no midió cuántas consultas por hora soporta el equipo con varios usuarios simultáneos, ni la latencia bajo carga, ni la interferencia entre solicitudes. No existe, por lo tanto, un dato de concurrencia en este informe, y ninguna cifra debe interpretarse como capacidad de servicio para un equipo de trabajo.

4. Discusión

Señal. Tres resultados superan lo que cabría atribuir al ruido de una sola pasada. El primero es la diferencia de velocidad entre configuraciones del motor para un mismo modelo, de 30,3 a 54,6 tok/s, acompañada de una diferencia de memoria de 3,6 GB. El segundo es la forma de la caída de lectura cerca de 50.000 tokens, medida en dos series distintas con la misma forma. El tercero es la magnitud del coste de razonar en tokens y tiempo, que en el caso del modelo más pequeño llevó el tiempo de 17,6 s a 688,6 s.

Ruido. Las diferencias entre configuraciones de borrador de un mismo modelo, con salidas de longitudes muy distintas, no permiten declarar una configuración óptima. Tampoco las comparaciones de la sonda de triaje, cuyo muestreo no se registró, ni las de los exámenes de código con configuraciones de contexto distintas. Un 3 de 3 de una campaña no es comparable con un 3 de 3 de otra, porque los jueces y los contratos cambiaron entre campañas.

Interpretación. A juicio de IT Lab, la configuración del motor es parte del resultado y no un detalle de instalación: una configuración genérica habría atribuido al modelo una lentitud que correspondía al montaje, y en la serie de configuraciones del motor el mismo archivo de modelo rindió entre 30,3 y 54,6 tok/s según la configuración. Del mismo modo, el contexto anunciado por un modelo no equivale a rendimiento con ese contexto, y la afirmación que importa a una organización es la segunda.

Qué no se concluye. El informe no concluye que una configuración de borrador sea la mejor en general, ni que el razonamiento deba activarse siempre, ni que la caída de lectura se deba a un mecanismo concreto. Tampoco compara el rendimiento de esta tarjeta con el de otras.

5. Implicancias para organizaciones con recursos acotados

Las siguientes recomendaciones son criterio de dimensionamiento de IT Lab, basado en sus mediciones. No son una recomendación de compra.

1. Dimensionar sobre la memoria utilizable. En una tarjeta de 16 GiB, planificar sobre 14,242 GiB y reservar el margen del sistema. Una configuración cuyo pico queda sobre ese presupuesto puede no cargar o inestabilizar el equipo.
2. Elegir el modelo en el rango de 12B a 35B cuantizados. Es el rango que el banco pudo cargar con contexto de trabajo de 64K a 131K tokens, con velocidades útiles en contexto corto.
3. Configurar el motor por modelo. Mantener una configuración documentada por modelo y comparar velocidades solo entre corridas con la misma tarea, el mismo muestreo y la misma carga. Cuando se use decodificación especulativa, medir con una tarea nueva y registrar la tasa de aceptación; una velocidad medida sobre contenido repetido sobrestima el rendimiento real.
4. Probar con el contexto real del trabajo. Antes de comprometer un flujo con documentos largos, medir lectura y generación con documentos del tamaño real. Cerca de 50.000 tokens la lectura cayó 13 veces en el banco, y con 80K-110K tokens ocupados la generación bajó de 36-43 a 7,5-14 tok/s. Los flujos que exijan contexto muy largo a buena velocidad no deben prometerse con esta clase de tarjeta sin una medición propia.
5. Fragmentar el trabajo cuando sea posible. Para tareas sobre documentos largos, a juicio de IT Lab conviene diseñarlas para operar con contextos más cortos antes que depender de la ventana completa.
6. Activar el razonamiento solo donde corrige. El razonamiento corrigió aritmética concreta en dos modelos, pero en otros dos solo aumentó el costo. Decidirlo por tarea y por modelo, y elevar el tope de salida cuando se active.
7. Un modelo a la vez. Dimensionar para atender a una persona o un proceso por vez. El uso simultáneo por varios usuarios no se midió, y no debe prometerse un acuerdo de nivel de servicio ni capacidad para toda la empresa.
8. Medir el medidor. Exigir a cualquier cifra de velocidad que indique la configuración del motor, el muestreo, la memoria disponible y el tamaño de contexto con que se obtuvo.

Preguntas frecuentes

¿Qué memoria de una tarjeta de 16 GiB se puede usar? De 15,922 GiB nominales, 14,242 GiB resultaron utilizables una vez reservado el margen para el sistema.

¿Qué pasa con documentos muy largos? Con documentos reales de gran tamaño, la lectura cayó 13 veces cerca de 50.000 tokens, y la generación bajó de 36-43 tok/s a 7,5-14 tok/s con 80K-110K tokens ocupados.

¿Importa la configuración del motor de inferencia? Sí: el mismo modelo pasó de 30,3 a 54,6 tok/s según la configuración, y la más rápida fue también la de menor memoria (13,3 GB).

¿Cuánto cuesta una IA local? El banco no mide costos. Operar IA local implica costos reales (energía, inversión inicial en hardware, mantención y tiempo) y a juicio de IT Lab, los precios actuales de los servicios de pago pueden no reflejar su costo real.

6. Limitaciones y alcance

• Una sola pasada por condición y caso, salvo que se indique otro número. Las diferencias pequeñas son ruido.
• La pasada de referencia se separa de las sondas y los diagnósticos: el triaje de tamaños es una sonda y el coste de razonar es un diagnóstico.
• La temperatura de muestreo de varias corridas de configuración del motor no quedó declarada en la fuente. Las velocidades de muestreos distintos no se mezclan.
• Tope de memoria de la configuración citada: 14,242 GiB utilizables de 15,922 GiB, con un tope de vigilancia de 15,5 GiB.
• "Razonamiento desactivado" no es homogéneo entre familias de modelos; esos niveles no se comparan entre familias.
• La causa de la caída de lectura es probable, no confirmada.
• La configuración con borrador especulativo más largo no cargó, y una variante intermedia no cerró resultado.
• La concurrencia no se midió.
• El banco no mide costos. Operar IA local implica costos reales (energía, inversión inicial en hardware, mantención y tiempo) y a juicio de IT Lab, los precios actuales de los servicios de pago pueden no reflejar su costo real.
• Medición de IT Lab sobre un único equipo; no es una recomendación de compra ni una certificación.

7. Conclusiones

1. A juicio de IT Lab, la memoria utilizable de una tarjeta de 16 GiB es de 14,242 GiB, y es la cifra con la que debe dimensionarse.
2. En el banco, la configuración del motor cambió la velocidad de un mismo modelo de 30,3 a 54,6 tok/s, y la configuración más rápida fue también la de menor memoria, con 13,3 GB.
3. La lectura con contexto real cayó 13 veces cerca de 50.000 tokens, y la generación bajó de 36-43 a 7,5-14 tok/s con 80K-110K tokens ocupados; la causa es probable, no confirmada.
4. En el diagnóstico, activar el razonamiento hizo que dos modelos pasaran de no superar a superar el criterio, con un aumento de tokens y de tiempo que en el modelo más pequeño llevó la corrida de 17,6 s a 688,6 s.
5. La concurrencia no se midió. El dimensionamiento que propone IT Lab para esta clase de tarjeta es de un modelo a la vez, con contexto de trabajo medido en la tarea real.

Ficha de medición

• Equipo: las mediciones se realizaron en un equipo que IT Lab definió y armó específicamente para pruebas: procesador Ryzen 7 5700X, 31 GiB de RAM y una tarjeta gráfica AMD Radeon RX 9070 XT de 16 GiB, con Linux. La tarjeta se eligió por ser hoy la opción más asequible con buena relación costo-beneficio que una empresa pequeña puede comprar. Los modelos evaluados cuentan con versiones optimizadas para tarjetas NVIDIA, por lo que se espera que el patrón general sea comparable en ese hardware; las cifras publicadas corresponden a este equipo.
• Cuantización: de 3 o 4 bits, según el modelo.
• Contexto: 65.536 tokens en el benchmark de configuración; contextos reales de 79.964 a 247.581 tokens en las pruebas de contexto largo.
• Tope de memoria de GPU: 14,242 GiB utilizables de 15,922 GiB nominales; tope de vigilancia de 15,5 GiB.
• Pasadas: una por condición, salvo que se indique otro número.
• Banco IT Lab, edición 1.

Cómo citar

IT Lab, Informe técnico ITL-IT-04, Banco IT Lab, edición 1.

Contacto: IT Lab evalúa modelos de IA local para organizaciones chilenas con sus propios documentos y datos. Conversemos

El Banco IT Lab es un instrumento vivo, en perfeccionamiento continuo. Parte de las mediciones proviene de versiones previas del instrumento y de modelos de generaciones anteriores, y algunas cifras pueden contener imprecisiones que se corrigen en cada nueva edición. Las conclusiones expresan el criterio de IT Lab a partir de sus propias mediciones.