Experiencias de la práctica

IA local en la empresa: ¿qué se necesita como mínimo?

CPU o GPU, 32 o 64 GB de RAM: diferencias entre una primera prueba, un puesto de uso habitual y un servicio de IA compartido.

InfraestructuraDetalles técnicosEstrategia y práctica de TI
Una usuaria maneja el ratón y el teclado de un puesto HP y observa el chat de la IA local.

Una primera prueba de IA local no exige comprar inmediatamente un servidor nuevo. Un ordenador existente puede mostrar si un modelo de lenguaje más pequeño ofrece resultados útiles para la tarea prevista. Para el trabajo diario también cuentan después los tiempos de espera, la capacidad disponible y una operación fiable.

La pregunta principal es, por tanto: ¿qué debe hacer el modelo? Una breve revisión de texto tiene requisitos distintos del análisis de documentos largos, un trabajo de programación extenso o el uso simultáneo por varias personas. «El modelo arranca» es una primera constatación técnica. Todavía no demuestra que exista un puesto adecuado o un servicio empresarial apropiado.

Qué se puede hacer sin una tarjeta gráfica especial

Los modelos de lenguaje pueden ejecutarse en una CPU compatible. El entorno de ejecución llama.cpp admite distintas plataformas de procesadores y el reparto del trabajo entre CPU y GPU. Una GPU no es, por tanto, un requisito general para todas las pruebas, aunque puede acelerar considerablemente el procesamiento. La diferencia real se mide con la tarea elegida. llama.cpp: hardware compatible y ejecución (enlace externo).

Una prueba con CPU puede servir, por ejemplo, para redactar un borrador a partir de notas no sensibles, estructurar una nota breve o valorar un pequeño ejemplo de código. El modelo debe ser adecuado tanto para el idioma como para la materia. Una entrada larga, una respuesta exigente o una segunda solicitud simultánea pueden cambiar mucho el resultado inicialmente útil de una prueba individual.

32 o 64 GB de RAM: escenarios de planificación, no un mínimo universal

Los siguientes niveles se presentan expresamente como ejemplos. No sustituyen ni la revisión del archivo concreto del modelo ni una prueba de carga. Los modelos pequeños pueden necesitar menos memoria; los grandes, los contextos largos o varios servicios pueden requerir bastante más.

Orientación para un piloto acotado, no una configuración mínima general.
Nivel de ampliación Base de ejemplo Qué debe aclarar la prueba
Evaluar el ordenador existente CPU compatible, por ejemplo 32 GB de RAM y suficiente espacio libre en SSD; inicialmente sin GPU adicional. ¿Un modelo más pequeño es adecuado para la materia? ¿Es aceptable la espera para tareas cortas individuales?
Puesto de uso habitual Por ejemplo, 32–64 GB de RAM, SSD NVMe y una GPU seleccionada según el modelo y el contexto. ¿Sigue siendo fluido el trabajo cuando hay otras aplicaciones en paralelo y las entradas son más largas?
Servicio compartido Recursos dedicados; por ejemplo, 64 GB de RAM del sistema como punto de partida de la planificación, aceleración adecuada y operación organizada. ¿Qué simultaneidad, calidad de respuesta y disponibilidad se alcanzan con una carga real?

64 GB de RAM del sistema no sustituyen una memoria gráfica suficientemente grande. Del mismo modo, que un archivo de modelo quepa en el SSD no demuestra que el modelo completo, con el contexto deseado, quepa en la GPU. En los sistemas con memoria compartida debe evaluarse todo el reparto de la memoria.

Por qué no basta con el tamaño del modelo

Un cálculo sencillo ilustra el orden de magnitud: ocho mil millones de parámetros con cuatro bits teóricos por parámetro dan 8.000.000.000 × 4 ÷ 8 = 4.000.000.000 bytes, es decir, unos 4 GB o 3,73 GiB solo para los pesos. No es el requisito completo de memoria de un modelo ejecutable.

Se añaden, entre otros elementos, información de cuantización, partes almacenadas en otros formatos, búferes del entorno de ejecución y memoria para el contexto. El archivo real y el entorno elegido son determinantes. GGUF, por ejemplo, contiene metadatos además de los tensores y admite distintos formatos de cuantización. Hugging Face: GGUF y cuantización (enlace externo).

Una ventana de contexto mayor requiere memoria adicional. Por eso se documenta expresamente la longitud de entrada deseada en la prueba. Una conversación corta con una entrada pequeña dice poco sobre el trabajo posterior con documentos largos. Ollama: longitud del contexto y memoria necesaria (enlace externo).

Una GPU debe encajar en todo el entorno

En la selección cuentan la memoria gráfica utilizable, los controladores y el entorno de ejecución compatibles, el consumo, la refrigeración y las condiciones de instalación. Dos tarjetas con nombres comerciales parecidos pueden tener cantidades de memoria distintas. Que el sistema operativo reconozca una tarjeta tampoco significa que el entorno del modelo la utilice correctamente.

Antes de comprar se comprueban, por tanto, el modelo exacto de tarjeta, el sistema operativo y la versión del controlador frente a la compatibilidad actual del entorno de ejecución. Ollama documenta distintas vías para NVIDIA, AMD, Apple Metal y otros backends. Esto no implica que todas las tarjetas de una marca sean compatibles. Ollama: compatibilidad actual del hardware (enlace externo).

Qué aportan NVMe y Linux

Un SSD NVMe es una opción razonable al planificar los archivos de modelos locales, las actualizaciones y los datos de trabajo. Se reserva espacio libre para los modelos utilizados realmente y las versiones adicionales. Una unidad mayor no sustituye la RAM ni la memoria gráfica; tampoco un SSD rápido permite usar interactivamente, por sí solo, un modelo demasiado grande.

Linux puede ser adecuado para un servicio de funcionamiento continuo si los controladores, el mantenimiento y las responsabilidades encajan en la empresa. Ollama describe, entre otras opciones, su ejecución como servicio del sistema independiente. El sistema operativo se elige según el entorno existente; no tiene que implantarse de nuevo en todos los puestos. Ollama: operación en Linux y mantenimiento de versiones (enlace externo).

Un piloto breve produce una lista de compra más útil

  1. Definir una tarea: por ejemplo, preparar un borrador a partir de notas aprobadas antes de conectar todo el repositorio de conocimientos.
  2. Anotar las condiciones de prueba: versión del modelo, cuantización, contexto, hardware y otras aplicaciones en ejecución.
  3. Evaluar los resultados: corrección del contenido, cambios necesarios y trabajo realmente ahorrado.
  4. Medir los tiempos de espera: entradas habituales y más largas, junto con el uso simultáneo previsto.
  5. Comprobar también la operación: rutas de datos, autorizaciones, actualizaciones, copias de seguridad y recuperación del servicio.

El procedimiento de evaluación detallado se describe en el artículo Probar la IA local: un piloto con una carga representativa. Para pasar a un servicio compartido, Ollama y Open WebUI en la red de la empresa explica la separación entre acceso, interfaz y modelo.

Aprovechar lo existente y ampliarlo de forma selectiva

Un ordenador existente puede bastar para empezar. Si el piloto demuestra una utilidad sólida, se realiza después una ampliación selectiva o se planifica un servicio propio. Para tareas poco frecuentes o especialmente exigentes también puede ser rentable una API en la nube aprobada o un modelo híbrido. Los datos, la calidad, el uso y el esfuerzo operativo son decisivos.

DAXS ayuda en esta evaluación y en la integración con la TI existente. Como punto de partida están LLM locales e infraestructura y la solicitud de asesoramiento sobre IA y automatización.

Fuentes: los valores de memoria son escenarios de planificación expresamente descritos o un cálculo teórico de los pesos. No constituyen una prueba de rendimiento, una oferta económica ni una demostración de capacidad para un número concreto de usuarios. La licencia del modelo concreto y la compatibilidad del sistema se comprueban antes de utilizarlo.