LLM locales.
Bien dimensionados.
Del modelo adecuado al servicio de IA gestionado: DAXS planifica infraestructura LLM local, comprueba el hardware con carga real e integra la solución en su informática.
Un servidor de IA empieza por su perfil de carga.
Un modelo de lenguaje local puede preparar textos internos, ayudar con borradores de código o formar parte de una búsqueda de conocimiento. La calidad del modelo, los recorridos de datos permitidos y el uso previsto deben encajar. DAXS registra los requisitos, planifica la infraestructura y asume instalación, integración y operación acordada, junto con su departamento IT o como servicio delimitado.
Tarea y calidad
¿Qué preguntas, idiomas, documentos o tareas de código debe resolver? Un chat breve y el análisis de documentos largos requieren modelos y contextos diferentes.
Uso y espera
¿Cuántas consultas llegan a la vez? ¿Cuándo debe empezar la respuesta y cuánto puede tardar en completarse? Las consultas ocasionales y un servicio continuo para equipos necesitan reservas diferentes.
Datos y operación
¿Qué fuentes y funciones están autorizadas? ¿Dónde pueden alojarse modelo, índice, registros y copias? ¿Quién atiende actualizaciones y fallos y qué recuperación se necesita?
Conectar adecuadamente aplicación, inferencia y operación.
La interfaz de usuario es solo una parte. Antes están los controles de identidad y acceso; detrás, el servicio de inferencia, el almacén de modelos y, cuando procede, la búsqueda de conocimiento o las interfaces empresariales. Supervisión, actualizaciones y recuperación forman parte del mismo plan.
El esquema presenta una posible arquitectura. Un proxy inverso puede proteger TLS y el punto de entrada. La aplicación debe aplicar también los permisos de usuario. Las API del modelo se limitan a las redes y funciones necesarias; el servicio empresarial requiere completar esa integración.
Más que el tamaño del archivo del modelo.
Valoramos pesos, recursos de ejecución, contexto, concurrencia y todo el recorrido de datos. Una GPU puede tener memoria suficiente y aun así no ofrecer la respuesta deseada. Un modelo más pequeño y bien elegido puede resolver la tarea de forma más económica.
| Componente | Qué comprobamos | Por qué importa |
|---|---|---|
| GPU y VRAM | Arquitectura, controladores, backend de inferencia, formatos de cálculo compatibles, capacidad y ancho de banda de memoria. | Los pesos y la caché KV necesitan espacio. El cálculo y las transferencias de memoria afectan a fases diferentes; el valor TOPS anunciado debe contrastarse con la aplicación. |
| Una o varias GPU | Reparto del modelo, interconexión de GPU, conexión PCIe, energía y refrigeración. | La VRAM de varias GPU requiere que el stack admita su reparto y sincronización para utilizarse conjuntamente. Añadir GPU también puede introducir cuellos de botella. |
| CPU y RAM del sistema | Ejecución, tokenización, preparación de datos, procesos paralelos y, cuando procede, inferencia en CPU u offloading. | La descarga a otra memoria puede permitir ejecutar el modelo, pero cambia el rendimiento. Las transferencias entre RAM y GPU pueden ralentizar la respuesta. Un servidor GPU también necesita reservas adecuadas de CPU y RAM. |
| NVMe y almacenamiento | Versiones de modelos, carga, índice de búsqueda, importaciones, registros, capacidad libre y copias. | Las SSD NVMe rápidas ayudan a cargar modelos y realizar determinadas operaciones de datos. Si el modelo reside completamente en la GPU, la generación de tokens depende principalmente del cálculo, la memoria y la ejecución. |
| Red y alimentación | Conectividad, recorridos permitidos, espacio, consumo, calor y acceso de mantenimiento. | El servicio debe sostener la carga real en refrigeración, organización y acceso a datos, además de contar con buenos componentes de cálculo. |
Una ayuda de cálculo para orientar la revisión.
El límite inferior de memoria para los pesos puede estimarse aproximadamente con número de parámetros × bits por peso ÷ 8 Para un modelo hipotético de ocho mil millones de parámetros y cuatro bits por peso, el resultado es cuatro gigabytes, unos 3,73 GiB.
Se añaden metadatos de cuantización, posibles partes de mayor precisión, caché KV, áreas de trabajo y ejecución. Por ello, el valor no determina la VRAM suficiente para su aplicación. En arquitecturas de expertos deben distinguirse también los parámetros activos en cálculo y todos los pesos que deben mantenerse disponibles.
Una respuesta breve y un servicio de equipo requieren pruebas distintas.
La ventana de contexto abarca la información que el modelo puede considerar para una consulta: instrucciones, historial, fragmentos recuperados y salida prevista, según la aplicación. El máximo nominal debe contrastarse con el hardware y el aprovechamiento real de la información.
Caché KV
La caché clave-valor conserva estados intermedios de atención. Su consumo depende de la arquitectura, el tipo de datos, el contexto realmente ocupado y las secuencias activas. Más contexto y concurrencia suelen aumentar considerablemente la memoria necesaria.
Prefill y decode
En prefill se procesa el contexto de entrada; en decode se generan nuevos tokens. Ambas fases cargan el hardware de forma diferente. Los documentos largos pueden retrasar el primer token aunque la salida posterior parezca fluida.
Procesamiento por lotes y cola
Procesar consultas conjuntamente puede aumentar el rendimiento total, pero también la espera individual. Por ello se planifican capacidad reservada, colas, límites y concurrencia.
Medimos el caso de uso real.
El piloto incluye consultas cortas, largas y simultáneas. Medimos el tiempo hasta el primer token, el tiempo total, la velocidad de salida, la cola, los errores y la memoria. Los tokens por segundo solo son comparables junto con la versión, la cuantización, el contexto, la carga y las condiciones de medición.
El stack se adapta al modelo y al uso.
Ollama, llama.cpp y vLLM son posibles componentes. Se eligen y configuran según modelos compatibles, hardware, concurrencia, operación e integración. Comprobamos las versiones concretas y diseñamos la arquitectura productiva completa.
Ollama
Una posible entrada para gestionar y publicar modelos localmente. Almacén, modelos autorizados, contexto, concurrencia y protección deben encajar en el entorno.
llama.cpp
Un componente flexible para modelos adecuados en distintos backends CPU/GPU, con formatos cuantizados y funcionamiento como servidor. Se prueban hardware, reparto y funciones API necesarias.
vLLM
Una opción para perfiles adecuados de inferencia y carga de servidor. Se coordinan planificación, caché KV, lotes y posibles GPU múltiples. El rendimiento total y la espera individual se evalúan por separado.
¿Contenedor, máquina virtual o host propio?
Los contenedores pueden reunir versiones de software de forma reproducible. Una máquina virtual puede aportar aislamiento técnico y organizativo adicional. La elección depende del acceso directo a dispositivos, los controladores, el mantenimiento y los procedimientos existentes. Una API compatible facilita la conexión y debe probarse con su aplicación.
¿Cuándo encaja Proxmox con passthrough de GPU?
El passthrough asigna una GPU física adecuada a una máquina virtual. Deben encajar plataforma, firmware, grupos IOMMU, controladores de host e invitado y reinicio del dispositivo, entre otros aspectos. Comprobamos la combinación concreta antes de comprometernos.
Compartir una GPU asignada entre varias máquinas requiere un mecanismo compatible. vGPU y passthrough directo son conceptos distintos, con requisitos y posibles licencias propios. El mantenimiento, las copias y un cambio de host necesitan procedimientos adecuados; la migración en vivo se comprueba para la configuración concreta.
Infraestructura y virtualización · Valorar una migración Proxmox
El modelo adecuado debe superar la tarea.
Comparamos modelos con ejemplos autorizados del uso futuro: preguntas técnicas en alemán, fragmentos de documentos, consultas multilingües o una tarea de scripting. Los modelos de código y embeddings cumplen funciones distintas. En una búsqueda de conocimiento deben encajar búsqueda, embeddings y modelo de respuesta.
La cuantización suele reducir la memoria necesaria. Se comprueba su efecto en calidad, llamadas a herramientas y velocidad para el formato elegido. El tamaño del modelo y el contexto máximo se valoran junto con la calidad real y la viabilidad económica.
- Licencia: comprobar concretamente los pesos elegidos, el uso comercial, la distribución y los avisos necesarios, además de obtener los archivos.
- Versión: registrar de forma trazable modelo, cuantización, tokenizador y entorno de ejecución.
- Aceptación: comprobar idoneidad funcional, respuestas no permitidas, calidad lingüística y fallos con un conjunto reproducible de preguntas.
- Cambios: probar primero las nuevas versiones, conservar una reversión útil y regenerar adecuadamente los índices cuando cambien los embeddings.
Local, externo o una combinación adecuada.
El hardware propio puede encajar con una utilización adecuada, requisitos claros de datos y una operación disponible. Un servicio externo puede convenir para uso variable, capacidades específicas o menor capacidad operativa propia. Un modelo híbrido combina tareas y recorridos delimitados.
La comparación incluye compra o consumo, energía y refrigeración, licencias, integración, actualizaciones, asistencia, reservas y consecuencias de fallos. El procesamiento local también requiere revisar seguridad y RGPD: modelos, embeddings, telemetría, actualizaciones, herramientas externas y registros deben encajar en el plan de datos.
Primero planificamos un piloto manejable con requisitos medibles. Su resultado permite decidir entre ampliar, ajustar o elegir una alternativa más sencilla. Encontrará más fundamentos en Cloud y SaaS.
Un servicio gestionado necesita responsables claros.
DAXS puede planificar e instalar hardware y software, conectarlos con identidades y aplicaciones existentes y asumir la operación acordada. Incluye supervisión de disponibilidad y recursos, versiones, errores y documentación. Se acuerdan concretamente la disponibilidad necesaria y los canales de respuesta.
Definimos qué configuraciones, componentes, índices y posibles modelos adaptados deben copiarse. Los pesos que pueden volver a descargarse y los datos empresariales protegidos tienen requisitos distintos. Una prueba de recuperación forma parte del modelo operativo adecuado.
Recogida de requisitos, propuesta de arquitectura, prueba de modelo y carga, recorridos documentados de datos y una recomendación trazable de hardware, operación y siguientes integraciones.
Lo aclaramos en una conversación.
¿Cuánta VRAM necesita un LLM local?
Depende del modelo, la cuantización, la ejecución, el contexto y las consultas simultáneas. Probamos la tarea completa, incluidas consultas largas y picos, antes de recomendar un equipo concreto.
¿Una segunda GPU es automáticamente más rápida?
No. El stack debe admitir el reparto. La interconexión, la sincronización y la arquitectura influyen en el resultado. Más memoria puede permitir ejecutar el modelo sin acelerar cada respuesta.
¿Se puede utilizar un servidor Proxmox existente?
Puede encajar si son adecuados el hardware, los grupos IOMMU, los controladores y el passthrough. También deben existir reservas para otros servicios y procedimientos de mantenimiento, copia y recuperación. Revisamos la plataforma concreta.
¿Se entrena el modelo con los documentos internos?
A menudo no es necesario para buscar conocimiento. RAG recupera fragmentos pertinentes y autorizados y los aporta como contexto. Modificar los pesos del modelo es otra medida que se justifica por separado.
¿Cuándo resulta más económico un servicio externo?
Puede encajar mejor con uso escaso o muy variable, necesidades específicas de modelo o falta de capacidad operativa. Comparamos costes, recorridos de datos, calidad y operación durante el periodo previsto.
Observar conjuntamente modelos, carga y costes.
Además de la utilización de GPU y la respuesta, valoramos el coste por tarea útil. Antes de actualizar un modelo se compara con las pruebas autorizadas. Los errores, colas, límites de memoria y fallos necesitan responsables y recuperación. Solo se contempla un servicio externo alternativo si lo permiten la clase de datos y la autorización.
Hablemos de su caso de uso.
¿Qué debe ser más sencillo, qué datos intervienen y qué sistemas existen? A partir de ello definimos un inicio útil y un siguiente paso manejable.