La adopción de inteligencia artificial en las empresas creció más rápido que la capacidad de los equipos de infraestructura para calcular cuánta GPU necesitan de verdad. NVIDIA publicó una guía práctica que ordena ese cálculo alrededor del comportamiento real de la carga de trabajo, y no de la intuición, con el costo total de propiedad (TCO, por su sigla en inglés) como criterio de cierre.
El punto de partida del documento es que el panorama actual de inferencia ya no se explica con las especificaciones del hardware ni con la métrica de "tokens por segundo". Los equipos enfrentan una lista creciente de decisiones previas al despliegue: qué latencia importa de verdad, si el tiempo hasta el primer token (TTFT), el percentil 99 o la latencia entre tokens; cómo los patrones de tokens del caso de uso presionan la memoria y el cómputo; y qué proporción conviene entre capacidad propia y elasticidad contratada en la nube.
¿Por dónde empieza el dimensionamiento?
Según NVIDIA, todo arranca con una pregunta engañosamente simple: qué problema se está resolviendo. Casos de uso distintos se traducen en infraestructuras radicalmente distintas. La guía agrupa la mayoría de las cargas de inferencia en cuatro categorías: asistentes conversacionales y copilotos, agentes de investigación y razonamiento, generación de contenido y aplicaciones de traducción.
Definido el caso de uso, el plan de dimensionamiento se construye sobre estas dimensiones:
- Selección del modelo: más grande no siempre es mejor. La guía sugiere evaluar modelos de uso masivo o incluso un modelo pequeño afinado que calce con los datos y la latencia requerida.
- Usuarios activos diarios y concurrencia: la concurrencia exige más memoria y castiga más la latencia que el número bruto de usuarios.
- ISL/OSL: la longitud de entrada y salida en tokens. Cadenas más largas implican más memoria y más cómputo.
- Tasa de aciertos de caché: la proporción de tokens de entrada que se repiten entre solicitudes y pueden servirse desde la caché de claves y valores en lugar de recalcularse. Una tasa alta se salta la fase de precarga para esos tokens, baja el TTFT y el costo por solicitud, y reduce la capacidad de GPU necesaria para el mismo tráfico.
- Duración del contrato: un tráfico estable y predecible justifica contratos largos o infraestructura propia. Las cargas volátiles o experimentales se benefician de capacidad flexible bajo demanda.
Núcleo y flexibilidad, el modelo para no sobreprovisionar
La recomendación central para controlar el gasto es lo que NVIDIA llama estrategia de núcleo y flexibilidad. El núcleo es una base de GPU propias o reservadas en la nube para la carga de régimen permanente, que reduce la exposición a la volatilidad de precios y asegura un servicio confiable para el grueso de los usuarios. La flexibilidad agrega elasticidad de nube pública, por demanda o en instancias interrumpibles, para absorber peaks, lanzamientos y experimentos.
El equilibrio busca que la empresa no sobreprovisione capital ni ahogue el crecimiento. En el mismo sentido, la guía advierte que elegir mal la GPU tiene un costo simétrico: cuando la capacidad va por delante de lo que la carga necesita, la utilización cae y el costo por token sube; cuando va por detrás de la memoria o el cómputo que exige, se limitan el rendimiento y la latencia.
Cuatro escenarios y la memoria que pide cada uno
La guía desarrolla cuatro escenarios de empresa a modo de demostración. Reordenados en una tabla, dejan ver cómo la longitud de contexto manda sobre el requisito de memoria más que el tamaño de la compañía:
| Escenario | Tokens entrada / salida | TTFT objetivo | Concurrencia | Memoria por GPU |
|---|---|---|---|---|
| Copiloto financiero | 5.000 / 500 | Bajo 1 segundo | 10 a 50 sesiones | 24 GB (modelo 7-8B), 48 GB (13B) |
| Agente de investigación biomédica | 20.000 / 2.000 | Bajo 2 segundos | 20 a 30 usuarios | Sobre 80 GB |
| Generador de contenido publicitario | 500 / 2.000 | Bajo 1 segundo | 50 a 100+ en peak | 16 a 24 GB |
| Plataforma de traducción masiva | 1.000 / 1.000 | Muy bajo 1 segundo | Cientos de solicitudes | 8 a 16 GB |
El contraste más útil está entre la primera y la segunda fila: un copiloto financiero que procesa correos largos de clientes se acomoda en 24 GB, mientras que un agente que ingiere artículos científicos completos con 20.000 tokens de contexto se va sobre los 80 GB por unidad. Es un salto de más de tres veces en memoria impulsado casi por completo por el contexto, no por la cantidad de usuarios, que en el segundo caso incluso es menor.
La guía también fija criterios de precisión numérica por escenario. Para tareas intensivas en conocimiento y críticas en cumplimiento normativo recomienda inferencia en FP16 o BF16; para traducción de lenguaje y código, en cambio, sostiene que FP16 o INT8 entregan fidelidad suficiente con mayor rendimiento y ahorro.
¿Cuánto ahorra realmente la cuantización?
Optimizar el TCO, según el documento, casi siempre pasa por reducir la huella de memoria del modelo, la palanca de mayor apalancamiento disponible. Una huella menor permite servir en GPU más compactas o baratas y, en muchos casos, bajar un escalón completo de hardware. NVIDIA ordena tres técnicas según el esfuerzo de ingeniería que exigen:
- Cuantización: reducir la precisión numérica de FP16 a FP8 o INT8, lo que recorta entre 25% y 50% de la memoria sin necesidad de reentrenar.
- Poda: eliminar capas o neuronas menos críticas para achicar el número de parámetros y el cómputo.
- Destilación de conocimiento: transferir la capacidad de un modelo grande a uno más pequeño y rápido.
La cuantización es la ganancia rápida porque no exige reentrenamiento. Los modelos suelen distribuirse en punto flotante de 16 bits, es decir dos bytes por parámetro; reexpresar los pesos, y opcionalmente las activaciones y la caché, en un formato de 8 bits deja un byte por parámetro y aproximadamente reduce a la mitad la memoria de pesos. Esa memoria liberada permite bajar a una GPU menor, o bien acomodar un lote mayor o una caché más larga en la misma GPU para subir el rendimiento y bajar el costo por token.
La cuantización posterior al entrenamiento convierte un modelo ya entrenado en su lugar, usando solo un conjunto pequeño de indicaciones representativas para una pasada de calibración que fija los factores de escala por capa.
Qué mirar desde un equipo en Chile
Para un equipo pequeño en Chile o la región, la lectura más accionable de la guía no son los escenarios de gran empresa sino los umbrales de memoria. Un copiloto interno sobre un modelo de 7 a 8 mil millones de parámetros cabe en 24 GB, un rango que hoy cubren tarjetas de estación de trabajo y no exige un centro de datos. El salto de costo aparece recién cuando el caso de uso exige contexto muy largo, y ahí la pregunta correcta es si ese contexto se puede acortar antes de comprar hardware.
El segundo punto es que la tasa de aciertos de caché es la variable más subestimada del cálculo. En aplicaciones con instrucciones de sistema largas y repetidas, que es el patrón habitual de un asistente corporativo, esa repetición se sirve desde caché y baja directamente la capacidad necesaria. NVIDIA insiste en que ninguna de estas optimizaciones es un ejercicio de una sola vez: hay que revisarlas a medida que evolucionan los modelos y las cargas.
