Redazione RHC : 18 julio 2025 08:22
En los últimos años, los modelos de lenguaje grandes (LLM, Large Language Models) como GPT, Claude o LLaMA han demostrado capacidades extraordinarias para comprender y generar lenguaje natural. Sin embargo, entre bastidores, gestionar un LLM no es tarea fácil: requiere una infraestructura computacional considerable, una inversión financiera considerable y decisiones arquitectónicas precisas. Intentemos entender por qué.
Un LLM de 70 mil millones de parámetros, como el LLaMA 3.3 70B de Meta, contiene 70 mil millones de «pesos», números de punto flotante (generalmente FP16 o BF16, es decir, 2 bytes por parámetro) que representan las habilidades aprendidas durante el entrenamiento. Solo para cargar este modelo en memoria, se necesita aproximadamente:
Agregue entre 20 y 30 GB adicionales de VRAM para gestionar las operaciones dinámicas durante la inferencia: caché de tokens (caché KV), incrustación de indicaciones, activaciones temporales y sobrecarga del sistema. En total, un LLM de 70 mil millones de parámetros requiere aproximadamente 160-180 GB de memoria GPU para funcionar eficientemente.
Mucha gente se pregunta: «¿Por qué no ejecutar el modelo en una CPU?». La respuesta es simple: latencia y paralelismo.
Las Unidades de Procesamiento Gráfico (GPU) están diseñadas para ejecutar millones de operaciones en paralelo, lo que las hace ideales para el cálculo tensorial que requieren los LLM. Las CPU, por otro lado, están optimizadas para un número limitado de operaciones secuenciales de alta complejidad. Un modelo como el LLaMA 3.3 70B puede generar una palabra cada 5-10 segundos en una CPU, mientras que en una GPU dedicada puede responder en menos de un segundo. En un contexto de producción, esta diferencia es inaceptable.
Además, la VRAM de las GPU de gama alta (p. ej., NVIDIA A100, H100) permite que el modelo se mantenga residente en memoria y aprovechar la aceleración de hardware para la multiplicación de matrices, el núcleo de la inferencia LLM.
Imaginemos que queremos ofrecer un servicio similar a ChatGPT solo para la generación de texto, basado en un modelo LLM de 70 mil millones de parámetros, con 100 usuarios activos simultáneamente. Supongamos que cada usuario envía mensajes con entre 300 y 500 tokens y espera respuestas rápidas, con una latencia inferior a un segundo.
Un modelo de este tamaño requiere aproximadamente 140 GB de memoria de GPU solo para los pesos de FP16, además de otros 20 a 40 GB para la caché de tokens (caché KV), las activaciones temporales y la sobrecarga del sistema. Una sola GPU, incluso una de gama alta, no tiene suficiente memoria para ejecutar el modelo completo, por lo que debe distribuirse entre varias GPU mediante técnicas de paralelismo tensorial.
Una configuración típica implica distribuir el modelo en un clúster de ocho GPU A100 de 80 GB, suficiente para cargar el modelo en FP16 y administrar la memoria necesaria para la inferencia en tiempo real. Sin embargo, para atender a 100 usuarios simultáneos manteniendo una latencia inferior a un segundo para un LLM de este tamaño, una sola instancia de 8 GPU A100 (80 GB) suele ser insuficiente.
Para alcanzar el objetivo de 100 usuarios simultáneos con una latencia inferior a un segundo, se requiere una combinación de:
Para una mayor escalabilidad, estas instancias se pueden replicar en múltiples POD de GPU, lo que permite la gestión asincrónica y con equilibrio de tráfico de miles de usuarios en total, en función del tráfico entrante. Por supuesto, más allá de la simple inferencia, es esencial proporcionar recursos adicionales para:
La implementación local requiere una inversión inicial de cientos de miles de euros, además de los costes anuales de gestión, energía y personal. Como alternativa, los principales proveedores de la nube ofrecen recursos equivalentes a un coste mensual mucho más asequible y flexible. Sin embargo, es importante tener en cuenta que, incluso en la nube, una configuración de hardware capaz de gestionar tal carga en tiempo real puede generar costes mensuales que fácilmente superan las decenas de miles de euros, o incluso más, según el uso.
En ambos casos, es evidente que el uso de LLM a gran escala representa no solo un reto algorítmico, sino también infraestructural y económico, lo que hace cada vez más importante la búsqueda de modelos más eficientes y ligeros.
Una alternativa sencilla para muchas empresas es utilizar las API de proveedores externos como OpenAI, Anthropic o Google. Sin embargo, cuando entran en juego la confidencialidad y la criticidad de los datos, el enfoque cambia radicalmente. Si los datos que se van a procesar incluyen información sensible o personal (p. ej., historiales médicos, planes de negocios o documentos judiciales), enviarlos a servicios externos en la nube puede entrar en conflicto con los requisitos del RGPD, en particular con respecto a las transferencias transfronterizas de datos y el principio de minimización de datos.
Muchas políticas corporativas basadas en estándares de seguridad como la ISO/IEC 27001 también exigen el procesamiento de datos críticos en entornos controlados, auditables y localizados.
Además, con la entrada en vigor del Reglamento Europeo sobre Inteligencia Artificial (Ley de IA), los proveedores y usuarios de sistemas de inteligencia artificial (IA) deben garantizar la trazabilidad, la transparencia y la seguridad. y supervisión humana, especialmente si el modelo se utiliza en contextos de alto riesgo (finanzas, salud, educación, justicia). El uso de LLM a través de API en la nube puede imposibilitar el cumplimiento de estas obligaciones, ya que la inferencia y la gestión de datos se producen fuera del control directo de la organización.
En estos casos, la única opción que realmente cumple con los estándares regulatorios y de seguridad es adoptar una infraestructura local o una nube privada dedicada, donde:
Este enfoque permite preservar la soberanía digital y cumplir con el RGPD, la norma ISO 27001 y la Ley de IA, a la vez que requiere un esfuerzo técnico y financiero significativo.
La puesta en marcha de un LLM no se trata solo de un desafío algorítmico, sino sobre todo de una tarea de infraestructura que implica hardware especializado, optimizaciones complejas, altos costes energéticos y latencia. Restricciones. Los modelos de vanguardia requieren clústeres de docenas de GPU, con inversiones que oscilan entre cientos de miles y millones de euros al año para garantizar un servicio escalable, rápido y fiable.
Una consideración final, pero fundamental, se refiere al impacto ambiental de estos sistemas. Los modelos grandes consumen enormes cantidades de electricidad, tanto durante el entrenamiento como durante la inferencia. A medida que aumenta la adopción de LLM, se hace urgente desarrollar modelos más pequeños, ligeros y eficientes que puedan ofrecer un rendimiento comparable con un consumo computacional (y energético) significativamente menor.
Como ocurre con toda evolución tecnológica, desde los ordenadores personales hasta los teléfonos móviles, la eficiencia es clave para la madurez: no siempre necesitamos modelos más grandes, sino modelos más inteligentes, adaptables y sostenibles.
RedazioneEn el marco de las investigaciones llevadas a cabo por la Fiscalía de Roma y coordinadas por la Dirección Nacional Antimafia y Antiterrorista, la Policía Postal ha completado importante...
Las vulnerabilidades de día cero son uno de los mayores riesgos de ciberseguridad para las organizaciones. Se trata de vulnerabilidades desconocidas y sin parchear que los atacantes explotan para...
Las amenazas persistentes avanzadas (APT) son actores maliciosos que operan en la sombra de internet, llevando a cabo ataques altamente sofisticados y dirigidos. Estos grupos, a menudo asociados con e...
Los ataques de denegación de servicio distribuido (DDoS) son una de las amenazas más comunes para sitios web, servidores y otras infraestructuras en línea. En concreto, este tipo de ata...
Por Centro de Defensa Cibernética Maticmind (Andrea Mariucci, Riccardo Michetti, Federico Savastano, Ada Spinelli) El actor de amenazas Scattered Spider, UNC9344, apareció en 2022 con dos at...
Para más información: [email protected]
