¿Cómo elegimos la ventana de contexto adecuada para la IA empresarial?

Parte de la necesidad del producto, no de la ficha técnica del modelo. Para la mayoría de los asistentes empresariales, 8k-16k es suficiente si tu pipeline RAG es eficaz. Aumenta el contexto solo para flujos de trabajo con documentos largos, como contratos o grandes especificaciones técnicas. Ten en cuenta que los contextos más largos aumentan el uso de VRAM (caché KV) y reducen el rendimiento.

¿Qué es lo que más afecta a la VRAM en la inferencia de LLM?

Los tres factores principales son los pesos del modelo, la ventana de contexto (caché KV) y el batching/concurrencia. Los equipos suelen subestimar el impacto de la caché KV: duplicar el tamaño del contexto puede aumentar significativamente las necesidades de VRAM, especialmente con niveles de concurrencia más altos.

¿Por qué no usar un modelo muy grande como Kimi k2.5?

Más allá de cierta escala, añadir parámetros produce rendimientos decrecientes en calidad. Modelos como Qwen 3.6 son suficientes para tareas agénticas complejas sin depender de modelos open source de frontera como Deepseek V4. La diferencia de rendimiento rara vez justifica el coste; un modelo más pequeño y bien configurado es más rápido y a menudo suficiente.

¿Cuánto costará la electricidad para ejecutar un sistema de IA autogestionada?

Los costes de electricidad son insignificantes en comparación con los costes iniciales de hardware o los costes de los proveedores de API. Para un uso intensivo (por ejemplo, el 20% del tiempo al 100% de capacidad con 4 GPU de consumo), la factura mensual ronda los 100€. El mismo uso en proveedores de IA costaría entre 3.000€ y 6.000€ al mes.

¿Cómo elegir la placa base adecuada y qué pasa con PCIe para hardware de IA?

Elige según tus necesidades. Se recomiendan placas base profesionales como la Gigabyte MZ32-AR0 para cargar/descargar modelos rápidamente mediante carriles PCIe 4 16x. Para configuraciones de uno o dos modelos, placas de consumo como la B550 Eagle son rentables. La velocidad de los carriles PCIe (incluso PCIe 3 x1) no afecta a la velocidad de inferencia, solo al tiempo de carga de los modelos.

¿Qué CPU debería combinar con GPU de gama alta para cargas de trabajo de IA?

Prioriza los carriles PCIe y el ancho de banda de memoria. Las CPU de estación de trabajo o servidor como Threadripper, EPYC o Xeon suelen ser mejores que las CPU de consumo cuando se ejecutan 2-4+ GPU. Esto ayuda a evitar cuellos de botella de CPU para el streaming de tokens y los pipelines RAG.

¿Es el hardware de GPU de consumo lo bastante fiable para la IA en producción?

En la mayoría de los casos, sí. Sin embargo, si sirves a clientes y no puedes aceptar un mayor riesgo operativo (por la falta de VRAM con ECC y temperaturas menos predecibles), prefiere GPU de datacenter, chasis validados y soporte empresarial.

¿Necesitamos red de alta velocidad (10/25GbE) para la inferencia de IA?

En realidad no. El tráfico de IA es mayoritariamente texto, que es ligero, por lo que la velocidad de red rara vez es el cuello de botella para la inferencia.

¿Puedo usar GPU AMD o Intel para IA autogestionada?

Técnicamente sí, pero a menudo no merece la pena debido a las lagunas de soporte del ecosistema en ROCm e Intel oneAPI en comparación con CUDA. Puedes tener problemas de compatibilidad, y algunos modelos o funciones pueden no funcionar, anulando el ahorro inicial de costes.

IA autogestionada de nivel empresarial

Q: ¿Qué rendimiento se puede esperar de una configuración de LLM autoalojada?

Por ejemplo, 4x RTX 3090 ejecutando Qwen 3.6 35b con una ventana de contexto de 256k en llama.cpp entregan 120 tokens/seg para un solo usuario y 70 tokens/seg para 3 solicitudes concurrentes. Este rendimiento supera a muchas alternativas basadas en API como Claude 4.6, sin límites de uso.

Q: ¿Cómo elegimos la cuantización adecuada (FP16 vs 8-bit vs 4-bit)?

Evita FP16, salvo para modelos pequeños o generación de imágenes. 8-bit es ideal para tareas sensibles a la precisión con un buen ahorro de memoria. 4-bit suele ser la mejor relación coste/rendimiento para chat y RAG, aunque se recomienda validar con tu propio conjunto de evaluación. En Saphes, la cuantización Q5 ofrece el equilibrio perfecto sin degradación observada en la calidad de salida.

Q: ¿Necesitamos un reranker para RAG?

Si tus documentos tienen ruido o son largos, o si la calidad de recuperación es crítica (por ejemplo, contenido legal/técnico), un reranker suele mejorar la precisión más que aumentar el tamaño del contexto. Para corpus pequeños y limpios, puedes prescindir de él.

Q: ¿Debería usar varios modelos o un único modelo insignia?

Recomendamos un modelo insignia siempre cargado en tus GPU para la mayoría de las tareas. Mantén algo de VRAM disponible para modelos más pequeños especializados, como especialistas en traducción o autocompletado de código. Estos ocupan poca VRAM, son muy rápidos y ayudan a descargar solicitudes concurrentes del modelo insignia.

En este artículo compartimos cómo Saphes IT Systems ha abordado la IA autogestionada de nivel empresarial desde el primer día. Emprendimos este camino por dos razones: necesitábamos cumplir estrictos requisitos de conformidad y queríamos mantener el control total en lugar de depender de un único proveedor.

Nuestro trabajo está estrechamente ligado a la propiedad intelectual y a datos sensibles de clientes. Enviar conocimiento propio y activos a un proveedor de IA externo sin garantías ni control claros plantea una pregunta sencilla: ¿y si acabamos regalando nuestra PI a cambio de nada?

Tras más de dos años de experimentación práctica en condiciones de producción, hemos adquirido una profunda experiencia en el diseño y la operación de un stack de IA autogestionada competitivo. Hoy, esa experiencia se traduce en una plataforma que no solo es conforme y controlable, sino también más rápida y significativamente más rentable que muchas alternativas.

En las siguientes secciones, repasamos los bloques clave de una configuración de IA autogestionada para empresas:

Hardware y dimensionamiento (planificación basada en capacidad y SLO)
Estrategia de modelos (qué ejecutar para cada tarea y cómo gestionar el ciclo de vida)
Stack de software (inferencia, orquestación, RAG, observabilidad)

Hardware y dimensionamiento

El dimensionamiento parte de unos pocos objetivos prácticos: número de usuarios previsto, concurrencia máxima, latencia aceptable (tiempo hasta el primer token y tokens/seg) y mezcla de cargas de trabajo (chat, RAG, trabajos por lotes, embeddings). A partir de ahí, puedes elegir:

Cómputo: CPU frente a GPU, clase de GPU (consumo o datacenter) y necesidades de VRAM determinadas por el tamaño del modelo + longitud del contexto + tamaño del lote. Consulta los benchmarks de GPU de PassMark para comparativas entre tarjetas de consumo y Pro.
Memoria y almacenamiento: suficiente RAM para los servicios de apoyo, además de almacenamiento local rápido para los pesos de los modelos y las cachés; planifica el crecimiento a medida que aumentan los modelos y las ventanas de contexto.
Red: red de baja latencia entre la inferencia y los servicios de apoyo (base de datos vectorial, almacenamiento, observabilidad), y suficiente capacidad de salida si varias aplicaciones llaman al modelo.

Para los equipos que ya gestionan servidores, esto se parece a la planificación de capacidad de cualquier otra plataforma interna: definir SLO, medir y luego escalar.

Observaciones

Estas observaciones pueden no coincidir con tus requisitos exactos. Recomendamos encarecidamente analizar tu uso futuro con un experto en lugar de adivinar. Los ejemplos siguientes son observaciones del mundo real, pero no son lo bastante precisos para elegir la configuración adecuada por sí solos.

Tamaño de empresa	Tipos de uso	Opciones de hardware	Coste inicial
Equipo pequeño (2-20 usuarios), uso bajo	Chat interno, Q&A puntual, baja concurrencia	CPU-first (Apple M3 Ultra) o 1× GPU Pro 48GB VRAM (por ejemplo RTX PRO 5000) con 64GB RAM y NVMe rápido	~2k-5k€
Equipo pequeño de ingenieros (2-10 usuarios), uso alto	Chat interno, Q&A puntual, alta concurrencia, RAG, generación de código, autocompletado de código	2× GPU Pro 96GB VRAM (RTX PRO 5000) o 4× GPU de consumo premium y rentables (RTX 3090) con 128GB RAM y NVMe rápido	~5k-15k€
Empresa mediana (50-200 usuarios), uso mixto	Asistente interno + RAG por departamento (RRHH, Ventas, Soporte), concurrencia moderada, algunos trabajos por lotes	2× GPU de datacenter 80GB (A100 / H100) o 2× GPU Pro 96GB RTX 6000, 256-512GB RAM, 2-4× NVMe (RAID); considera un nodo separado para la base de datos vectorial/ETL	~20k€-50k€

Preguntas frecuentes

¿Cuánto costará la electricidad para ejecutar el sistema?

Es insignificante en comparación con el coste inicial o con los costes por token de los proveedores de IA. Supongamos que usas el 20% del tiempo el 100% de tu capacidad con 4 GPU de consumo (un uso intensivo). Tendrás una factura de unos 100€/mes. Con el mismo uso intensivo, en proveedores de IA estarías en torno a 3k-6k€ al mes.

¿Cómo elegir la placa base adecuada y qué pasa con PCIe?

Depende de tus necesidades. Se recomiendan algunas placas base profesionales como la MZ32-AR0, sobre todo si quieres usar varios modelos y cargarlos/descargarlos rápidamente (versión y carriles PCIe por ranura, aquí PCIe 4 16x). Si dependes de uno o dos modelos, puedes mantenerlos cargados y usar una placa base de consumo como una B550 Eagle, que es muy rentable. De hecho, la velocidad de los carriles, incluso en PCIe 3 x1, es suficiente y no hay diferencia en la velocidad de inferencia; solo la carga de modelos se vuelve mucho más larga.

¿Cómo alimentar 4 GPU? ¿Puedo usar varias fuentes de alimentación?

Sí. Recomendamos usar varias fuentes de alimentación si no encuentras una que cumpla tus requisitos. Una fuente de alimentación puede activarse sin necesidad de conectarla a la estación de trabajo.

¿Qué CPU debería combinar con GPU de gama alta?

Prioriza los carriles PCIe y el ancho de banda de memoria: las CPU de estación de trabajo/servidor (Threadripper/EPYC/Xeon) suelen encajar mejor que las CPU de consumo cuando ejecutas 2-4+ GPU. Evita cuellos de botella de CPU para el streaming de tokens y los pipelines RAG.

¿Qué configuración de almacenamiento funciona mejor para los pesos de los modelos y RAG?

Usa NVMe rápido para los pesos de los modelos y las cachés activas. Volúmenes separados (o nodos separados) para la base de datos vectorial y los logs. RAID1/10 ayuda a la disponibilidad; planifica también copias de seguridad para índices y documentos.

¿Es el hardware de GPU de consumo lo bastante fiable para producción?

En la mayoría de los casos, sí. Sin embargo, si sirves a clientes y no aceptas un mayor riesgo operativo (sin VRAM con ECC, temperaturas menos predecibles), prefiere GPU de datacenter, chasis validados y soporte empresarial.

¿Cómo gestionamos la refrigeración, el ruido y los límites de potencia?

Planifica primero el flujo de aire (de delante hacia atrás, ventiladores de alta presión estática), dimensiona las fuentes de alimentación con margen y establece límites de potencia de GPU para estabilizar el rendimiento/vatio. En oficinas, considera la ubicación remota en rack o configuraciones de estación de trabajo más silenciosas (evita los sistemas de turbina).

¿Necesitamos red de alta velocidad (10/25GbE)?

En realidad no. El tráfico de IA es mayoritariamente texto, y el texto es ligero, por lo que rara vez es el cuello de botella.

¿Puedo usar GPU AMD o Intel?

La respuesta corta es sí, pero en la práctica a menudo no merece la pena. El problema es el soporte del ecosistema (ROCm e Intel oneAPI) en comparación con CUDA. Aunque ahorres algo en el coste inicial, probablemente tendrás más dificultades, y a veces simplemente no podrás usar un modelo o una función determinados.

Selección de modelos

Las configuraciones empresariales se benefician de una política de modelos deliberada en lugar de "un modelo para todo". En la práctica, recomendamos definir una pequeña "cartera de modelos":

Modelo asistente principal (la mejor calidad que puedas ejecutar dentro de tus restricciones de latencia/SLO)
Modelo rentable para tareas de alto volumen (clasificación, extracción, enrutamiento, borradores)
Modelo de embeddings para RAG (y opcionalmente un reranker si la calidad de recuperación importa)

Criterios de selección que usamos:

Ajuste a las tareas: chat frente a traducciones frente a extracción estructurada frente a código; no gastes de más en un modelo grande para una clasificación sencilla.
Eficiencia de servicio: el tamaño de la caché KV crece con la ventana de contexto; el contexto suele ser el verdadero cuello de botella de VRAM.
Licencias y gobernanza: valida la compatibilidad de licencias (uso interno, uso de cara al cliente, redistribución) y documenta los modelos aprobados. Consulta las licencias de modelos de Hugging Face antes del despliegue.

Nuestras recomendaciones de base

La tabla siguiente pretende ser un punto de partida (la VRAM exacta depende del backend, el tamaño del lote, el contexto y si mantienes varios modelos cargados).

Modelo	Cuantización	Ventana de contexto	Tamaño VRAM	Uso
Qwen3.6 35b (a3b)	Q5_K_M	256k	50GB	Código, tareas agénticas, tareas generales
Qwen3.6 27b	Q5_K_M	256k	50GB	Igual que el 35b, más preciso en benchmarks, pero más lento
GLM 4.7 flash	Q5_K_M	198k	50GB	Código, tareas agénticas, tareas generales
TranslateGemma	Q5_K_M	128k	35GB	Traducciones
Qwen2.5 Coder 14b (base)	Q5_K_M	8k (hasta 32k)	25GB	Autocompletado de código
Nomic Embed 0.3b	FP16	2k	1GB	Modelo de embeddings ligero, fiable y portátil
Qwen3 Embedding 4b	Q8_0	40k	20GB	Modelo de embeddings muy preciso, pero pesado, útil si necesitas una gran ventana de contexto
Flux 2 Klein 9b	FP8	/	10GB	Bueno para resultados fotorrealistas
GLM Image	FP8/FP16	/	20GB	Bueno para imágenes comunes, incluido texto

Preguntas frecuentes

¿Qué rendimiento se puede esperar?

Cada uno de nuestros ejemplos es muy práctico. Por ejemplo, una 4× RTX 3090 ejecutando Qwen 3.6 35B con una ventana de contexto de 256k en llama.cpp entrega 120 tokens/seg para un solo usuario y 70 tokens/seg para 3 solicitudes concurrentes, lo que es mejor que, por ejemplo, la API de Claude 4.6, sin ninguna limitación de uso.

¿Cómo elegimos la ventana de contexto adecuada?

Parte de la necesidad del producto, no de la ficha técnica del modelo. Para la mayoría de los asistentes empresariales, 8k-16k es suficiente si tu pipeline RAG es bueno (recupera menos, recupera mejor). Aumenta el contexto solo cuando tengas flujos de trabajo reales con documentos largos (contratos, grandes especificaciones técnicas, revisiones de código de varios archivos). Recuerda: un contexto más largo aumenta el uso de VRAM (caché KV) y a menudo reduce el rendimiento.

¿Cómo elegimos la cuantización adecuada (FP16 vs 8-bit vs 4-bit)?

Nunca uses FP16, salvo para modelos muy pequeños o generación de imágenes; no merece la pena. 8-bit es muy bueno para tareas sensibles a la precisión con un mejor ahorro de memoria. 4-bit suele ser la mejor relación coste/rendimiento para chat y RAG en producción, pero valida con tu propio conjunto de evaluación (algunas tareas como la extracción estricta o los matices multilingües pueden degradarse). En Saphes recomendamos la cuantización Q5; el equilibrio es perfecto para nuestro uso, y nunca hemos identificado una salida degradada con esta cuantización.

¿Qué es lo que más afecta a la VRAM?

Tres factores principales: (1) los pesos del modelo, (2) la ventana de contexto (caché KV) y (3) el batching/concurrencia. Muchos equipos subestiman la caché KV: duplicar el contexto puede aumentar significativamente las necesidades de VRAM, especialmente con mayor concurrencia.

¿Deberíamos ejecutar un modelo grande o varios más pequeños?

Prefiere varios modelos cuando tengas una separación clara de tareas: un asistente potente para solicitudes "difíciles" y un modelo más económico para enrutamiento, resumen, extracción o borradores. Esto reduce el coste y mejora la latencia bajo carga.

¿Necesitamos un reranker para RAG?

Si tus documentos tienen ruido o son largos y la calidad de recuperación importa (bases de conocimiento de soporte, contenido legal/técnico), un reranker suele mejorar la precisión más que aumentar el tamaño del contexto. Si tu corpus es pequeño y limpio, puedes prescindir de él.

¿Por qué no un modelo grande como Kimi k2.5?

Una vez alcanzas cierta escala, añadir parámetros tiene cada vez menos impacto en la calidad. Un modelo como Qwen 3.6 es más que suficiente para tareas agénticas complejas hoy en día; no tienes que depender de modelos open source "de frontera" como Deepseek V4. La diferencia de rendimiento no merece la pena: un modelo más pequeño y bien configurado es más que suficiente, y mucho más rápido.

¿Debería usar varios modelos o un único modelo insignia?

Recomendamos tener un modelo insignia, siempre cargado en tus GPU, usado para la mayoría de las tareas. Mantén algo de VRAM disponible para modelos más pequeños útiles, como un especialista en traducción y autocompletado de código; estos no ocupan mucha VRAM y son muy rápidos en lo que hacen. Esto también ayuda a descargar solicitudes concurrentes de tu modelo insignia.

Stack de software / tooling

Un stack autogestionado típico es modular y puede empezar siendo pequeño:

Inferencia

Para la inferencia, actualmente hay tres verdaderos contendientes. Cada uno expone una API compatible con OpenAI, y cada uno tiene fortalezas y compromisos:

Solución	Ventajas	Inconvenientes
Ollama	Rápido de configurar, fácil de usar: unos pocos comandos y tu modelo está funcionando.	Más lento que las otras soluciones; carga/descarga modelos con frecuencia si una solicitud no coincide con lo que ya está cargado.
Llama server (llama.cpp)	Muy rápido y sólido para la concurrencia; alto nivel de personalización; amplia elección de modelos y soporte de formatos.	Carga un modelo a la vez; más largo de configurar que Ollama.
vLLM	Excelente para la concurrencia; la elección adecuada para un modelo insignia a escala; permite un alto nivel de personalización.	Más lento que llama.cpp para solicitudes individuales; más largo de configurar que Ollama; menos formatos soportados que llama.cpp.

UI / Gateway

Hay una opción destacada: Open WebUI. Open WebUI actúa como gateway y ofrece control de acceso granular. También incluye muchas funciones, como hacer de proxy de Ollama (si lo usas) así como de otras API compatibles con OpenAI conectadas.

Open WebUI puede combinarse con ComfyUI para la generación de imágenes; ambos interactúan bien, creando una experiencia de generación de imágenes similar a GPT.

RAG

Un sistema RAG (Retrieval-Augmented Generation) es crucial para muchos casos de uso, y cuantos más documentos tenga tu empresa, más importante se vuelve. RAG te permite almacenar fragmentos de tus documentos y, en lugar de inyectar 300 páginas en la ventana de contexto para cada pregunta, recuperar solo las partes relevantes junto con metadatos (nombre del documento, referencia de página, etc.). Aprende más sobre la arquitectura RAG y las buenas prácticas.

Para fines de desarrollo, RAG suele ser menos útil (por ejemplo, volver a embeber todo un código base para cada rama no es realista). En cambio, embeber documentación estructurada de un framework o lenguaje puede ser muy útil.

Antes de configurar un sistema RAG (que es sencillo de empezar), la parte más importante es definir qué debe estar en tu base de datos y qué metadatos necesitas. La arquitectura importa: determina si tu sistema RAG será utilizable en la práctica.

Puedes ejecutar ChromaDB o Qdrant en tu servidor. Ambos son buenos; recomendamos Qdrant porque es rápido y está bien diseñado (esta recomendación es subjetiva).

Editores de código

Para un desarrollo local-first asistido por IA, recomendamos la siguiente configuración:

Zed: nuestra recomendación por defecto. Integra la IA de forma nativa, soporta ACP y otras herramientas modernas, y es extremadamente rápido y ágil. Consulta la documentación de IA de Zed para detalles de configuración.

VS Code o JetBrains:

Continue para autocompletado de código y respuestas rápidas tipo chat.
Cline para flujos de trabajo más agénticos (tareas de varios pasos, cambios en todo el repositorio, orquestación de herramientas).

MCP

Hay muchos MCP en el mercado. Los correctos son simplemente los que necesitas. Lo que más importa es el despliegue: los MCP pueden ejecutarse de varias maneras y soportar distintos tipos de conexión. Recomendamos conexiones HTTP en streaming para los MCP que deben conectarse a tu servidor, y ejecutarlos directamente en el servidor.

Un conjunto sólido de MCP, o construir los que necesitas, puede ser un cambio radical. Los MCP están limitados sobre todo por la imaginación: puedes desarrollar un MCP para hablar con tu plataforma de comercio electrónico, CMS, crear y obtener contenido, crear productos y mucho más. Aprende más sobre la especificación del Model Context Protocol y explora el MCP Registry para integraciones creadas por la comunidad.

Reflexiones finales

Hoy, integrar IA autogestionada en una empresa ya no es un proyecto imposible: es concreto y alcanzable. Los modelos son ahora lo bastante inteligentes y rápidos para manejar tareas complejas, un sistema RAG bien configurado puede superar a la mayoría de las soluciones RAG automatizadas del mercado, las herramientas de UI se han vuelto fáciles de usar, y el ROI suele alcanzarse rápidamente, normalmente entre 6 y 24 meses según la complejidad de tus sistemas.

Dicho esto, hay consideraciones importantes. La configuración inicial puede ser complicada: problemas de drivers, conectar herramientas, configurar el sistema RAG y seleccionar los modelos adecuados. Para nosotros, el mayor coste no es el hardware, sino la configuración que consume tiempo, mientras que el mantenimiento continuo suele ser mucho más sencillo.