¿Es posible construir un servidor LLM autoalojado para 300 usuarios?

• Resumen de una pregunta y respuestas publicadas en el subreddit Reddit /r/ollama
• Como administrador de sistemas de un despacho jurídico de unas 300 personas, se busca ofrecer a todo el personal una herramienta de redacción y corrección de documentos basada en IA, similar a ChatGPT
• Para proteger información sensible como PII, se está considerando alojar directamente un LLM en servidores internos en lugar de usar servicios externos, aplicando controles de acceso como inicio de sesión, 2FA y VPN
• Preguntas principales
  • ¿Un servidor LLM construido internamente podría realmente dar soporte a más de 300 usuarios?
  • Se pensaba que bastaría con unas cuantas PCs con GPU, pero ¿se está subestimando la complejidad real?
  • ¿La creación y administración de usuarios puede convertirse en una carga importante?
  • ¿Hay consideraciones importantes que se estén pasando por alto?
• Como no se es especialista en LLM, se piden consejos realistas sobre escalabilidad, carga operativa y viabilidad

Resumen de las respuestas principales

1. Límites de hardware, rendimiento y costo

• Si se espera un nivel similar al de modelos comerciales (por ejemplo, ChatGPT), haría falta un clúster de GPU muy costoso, del orden de cientos de miles de dólares (estimación: $200,000~$1,000,000+)
• Si se reduce la escala usando modelos open source (de 30B~70B parámetros), hay que asumir una caída en el rendimiento (latencia y calidad de resultados). Incluso manejar 10~40 usuarios simultáneos puede ser el límite
• Se recomienda asumir menos de 10 usuarios concurrentes e ir ampliando de forma gradual mediante expansión progresiva de servidores
• En lugar de un entorno local, alquilar GPU en la nube puede ser más económico y flexible

2. Recomendación de PoC (piloto) y enfoque gradual

• Se recomienda construir primero una PoC (piloto) con 1 servidor + 1 GPU, medir escenarios reales de trabajo y carga, y luego ampliar
• Si hay muchas solicitudes simultáneas, un sistema de colas es indispensable; la concurrencia real podría no ser de 300, sino de 10~30 usuarios
• A corto plazo, es posible experimentar con modelos pequeños (3B~13B parámetros) junto con una workstation

3. Opciones de nube, híbridas y alternativas

• Se propone una arquitectura híbrida que conecte LLM basados en la nube (API, VPS, Azure, AWS Bedrock, etc.) con infraestructura propia, según los requisitos de seguridad
• En autoalojamiento, la carga de seguridad, rendimiento y costo es alta; en la práctica, soluciones comerciales como ChatGPT Enterprise/Teams o Microsoft Copilot Studio pueden ser más eficientes
• Es indispensable revisar los requisitos de seguridad para datos legales y procesamiento de PII

4. Otros temas operativos, de gestión y técnicos

• Gestión de usuarios/autenticación: puede simplificarse con integración a AD, OAuth o autenticación propia
• Selección y ajuste del modelo: se recomienda probar modelos open source medianos o pequeños adecuados al caso de uso real (corrección de documentos, etc.), como LLama, Deepseek, Gemma, Qwen
• Conviene evaluar la posible adopción de soluciones adicionales como RAG, caché y balanceo de carga
• Es necesario definir los escenarios reales de uso y validar presupuesto/ROI mediante una PoC

Resumen de respuestas destacadas

ithkuil

• Frente a modelos comerciales, los modelos open source muestran una gran diferencia de rendimiento, y para una escala de 300 personas podría hacer falta hardware de cientos de miles de dólares
• Vale la pena esperar avances de hardware y modelos abiertos en los próximos 2 años

SlimeQ

• Recomienda empezar en pequeño con una sola instancia + cola, y escalar gradualmente conforme aumente el uso
• No es posible que las 300 personas lo usen al mismo tiempo; la decisión de expansión debe basarse en la medición del uso real

Ok-Internal9317

• Los usuarios simultáneos reales podrían ser menos de 10, y 4~5 GPU podrían bastar
• A largo plazo, el costo de una API podría resultar más económico que el hardware propio

dyoh777

• Es fácil hacer una demo con Ollama+WebUI, pero la calidad del modelo es lo más importante

careful-monkey

• Es posible ejecutar modelos pequeños con Mac Studio + mucha RAM, a velocidades de alrededor de 20 token/sec

tshawkins

• Recomienda soluciones SaaS como Microsoft Copilot Studio, integradas dentro de Power Platform

roman_fyseek, Cergorach, Space__Whiskey

• Límite de VRAM del modelo: 1 sesión = 1 GPU; procesar 300 usuarios simultáneos requeriría 300 GPU
• En la práctica se necesitan límites de concurrencia, caché y una arquitectura híbrida

Siderox, SandboChang, unrulywind

• Recomiendan experimentar primero con un servidor pequeño en una PoC (ej. 1~2 usuarios/modelo, validando su utilidad en trabajo real) y luego escalar gradualmente
• Tras definir escenarios reales y hacer benchmarking, hay que validar presupuesto y ROI

Little_Marzipan_2087, morosis1982, Daemonero

• Alquilar GPU en la nube es barato y escalable, y es una solución usada con frecuencia
• Considerando la carga de operación y mantenimiento, recomiendan la nube antes que invertir en hardware

CtiPath, alew3, faldore, Wheynelau

• Recomiendan frameworks open source de alto rendimiento para servidores LLM como vLLM, OpenWebUI, TGI, sglang
• También sugieren una arquitectura con cola + balanceador de carga

Otros

• Seguridad/aspectos legales: incluso al usar la nube, hay que revisar cuidadosamente ubicación de los datos, cifrado y cumplimiento normativo
• Se mencionan varias opciones de hardware como Mac Studio, RTX 6000 Pro, 4090
• Caché, RAG, límites de contexto y offload podrían ayudar a reducir la carga

Resumen de la conclusión

• Un servidor LLM autoalojado es más realista si se empieza con un piloto pequeño (PoC) y se validan por etapas el tamaño real de los usuarios, requisitos, rendimiento y costos
• Atender a 300 usuarios concurrentes implica una carga importante de hardware y costos operativos, y según el caso de uso y el presupuesto, podrían encajar mejor soluciones de nube, híbridas o comerciales
• En última instancia, hay que considerar de forma integral factores como seguridad, costo, experiencia de usuario y mantenimiento

[xodnrdl201]

Creo que definiste de forma demasiado amplia el nivel de capacidad de razonamiento requerido para las tareas de esos 300 usuarios. Si de verdad quieres cubrir desde sentido común muy general hasta artículos académicos o temas avanzados, entonces este enfoque tiene sentido, pero si piensas en el nivel real de las tareas que necesitan procesarse, con algo como un 30b más RAG probablemente se podría resolver la mayoría. Al depender de capacidades de razonamiento altas elevando todos los pesos de un modelo base open source, ¿no terminó creciendo demasiado la escala del sistema?

Y también creo que lo correcto sería separar como funciones distintas lo que puede procesarse directamente y la búsqueda/exploración de documentos.

En cuanto al rango de tokens objetivo para el KV cache al atender a 300 usuarios concurrentes, si se considera algo como 20,000 tokens cuantizados por cada uno, también parecería que esa parte podría estar sobredimensionada... ??

A menos que esas 300 personas sean doctores redactando artículos académicos, quizá bastaría con fijar el nivel de razonamiento en algo equivalente al de un estudiante de preparatoria (14~30b) y configurar el proceso para explorar diversos documentos internos con una lógica RAG y un CoT adecuado; así podría convertirse en un proyecto piloto operable con un presupuesto razonable.

[tsboard]

Yo también, por necesidad, estoy armando una solución RAG usando nada menos que 4 GPU H100, de esas tan difíciles de conseguir, pero considerando no solo la inversión directa en hardware sino también la factura de electricidad, los costos de refrigeración y demás, no dejaba de pensar que simplemente llamar a una API sería mucho mejor.

Yo también empecé probando con Ollama al principio, y en cuanto confirmé que ni siquiera podía cubrir bien 3 usuarios concurrentes, pasé enseguida a vLLM y, entre una cosa y otra, armé una solución RAG, pero (asumiendo 10 usuarios concurrentes) solo para esto ya casi tengo que usar 2 GPU H100 prácticamente al máximo. También levanto en vLLM las tareas de embeddings y de búsqueda, así que 4 H100 realmente quedan muy justas. Y eso que cada tarjeta tiene alrededor de 90 GB de VRAM.

Claro, yo en realidad no sé mucho de AI, y como fui ajustando lo necesario para el departamento junto con las políticas internas de seguridad, simplemente lo he estado intentando a la fuerza... pero me pregunto si esto realmente tiene sentido. ¿Era ChatGPT Enterprise? Realmente me parece que tiene un precio increíblemente conveniente.

[chinnotching]

Con una sola máquina increíble a un precio increíble debería bastar, ¿no? Un bufete increíble seguramente la compraría. Pero sería como hacer funcionar maquinaria de fábrica las 24 horas, jajaja.

[neinomu]

Una persona que solo piensa en el precio de un Porsche y no considera para nada los costos de mantenimiento, gasolina, seguro, etc.

[beepp]

En servicios como los chatbots que necesitan ofrecer funcionalidad de streaming, cuando hay procesamiento simultáneo, el trabajo de prefill termina afectando incluso al decode, así que aunque haya VRAM de sobra, desde la perspectiva del usuario parece que el rendimiento baja muchísimo.

Probé opciones relacionadas con chunked prefill y también la función experimental de Disaggregated Prefilling que ofrece vLLM, pero aun así, cuando entra una nueva solicitud, sigue pasando que las respuestas que ya se estaban generando se cortan a cada rato. Como desarrollador principiante, me pregunto si existe un método más eficiente, aparte de aumentar la cantidad de GPU o de nodos.

[iolothebard]

Todo depende del caso.