É possível montar um servidor LLM self-hosted para 300 usuários?

• Resumo de perguntas e respostas publicadas no subreddit Reddit /r/ollama
• Como administrador de sistemas de um escritório de advocacia com cerca de 300 pessoas, a ideia é oferecer a todos os funcionários uma ferramenta de redação e revisão de documentos com IA, semelhante ao ChatGPT
• Para proteger informações sensíveis, como PII, a proposta é hospedar o LLM diretamente em um servidor interno, em vez de usar serviços externos, com controle de acesso via login, 2FA, VPN etc.
• Perguntas principais
  • Um servidor LLM próprio conseguiria de fato atender mais de 300 usuários?
  • A expectativa era de que alguns PCs + GPUs seriam suficientes, mas isso foi subestimado?
  • Criação/gestão de usuários pode se tornar uma grande carga operacional?
  • Há algum ponto importante que ficou de fora dessa avaliação?
• Como a pessoa não é especialista em LLM, busca conselhos realistas sobre escalabilidade, carga operacional e viabilidade prática

Resumo das principais respostas

1. Limites de hardware, desempenho e custo

• Se a expectativa for algo no nível de modelos comerciais (ex.: ChatGPT), será necessário um cluster de GPUs caro, potencialmente na faixa de centenas de milhares de dólares (estimativa de $200,000~$1,000,000+)
• Ao reduzir a escala para modelos open source (30B~70B parâmetros), é preciso aceitar perda de desempenho (latência e qualidade das respostas). Mesmo 10 a 40 usuários simultâneos já podem ser um limite
• Recomenda-se assumir menos de 10 usuários simultâneos inicialmente e expandir aos poucos com adição de servidores
• Em vez de ambiente local, alugar GPU em nuvem pode ser mais econômico e flexível

2. Recomendação de PoC (piloto) e abordagem gradual

• Recomenda-se montar uma PoC (piloto) com 1 servidor + 1 GPU e, depois de medir cenários reais de trabalho e carga, ampliar gradualmente
• Em caso de muitas requisições simultâneas, um sistema de filas é essencial; na prática, a simultaneidade real pode ser de 10 a 30 usuários, e não 300
• No curto prazo, já dá para experimentar com modelos menores (3B~13B parâmetros) combinados com uma workstation

3. Nuvem, híbrido e opções alternativas

• Foi sugerida uma arquitetura híbrida que conecta LLMs em nuvem (API, VPS, Azure, AWS Bedrock etc.) com infraestrutura própria, de acordo com os requisitos de segurança
• No self-hosting, o peso de segurança, desempenho e custo é alto; na prática, soluções comerciais como ChatGPT Enterprise/Teams e Microsoft Copilot Studio podem ser mais eficientes
• É indispensável revisar os requisitos de segurança para tratamento de dados jurídicos e PII

4. Outros pontos operacionais, de gestão e técnicos

• Gestão de usuários/autenticação: pode ser simplificada com integração AD, OAuth ou autenticação própria
• Escolha e ajuste de modelo: recomenda-se testar modelos open source pequenos e médios adequados ao uso real (revisão de documentos etc.), como LLama, Deepseek, Gemma, Qwen
• Vale avaliar a adoção de soluções adicionais como RAG, caching e balanceamento de carga
• É necessário definir cenários reais de uso e validar orçamento/ROI por meio de uma PoC

Resumo de respostas representativas

ithkuil

• Em comparação com modelos comerciais, modelos open source têm uma diferença grande de desempenho e, para uma escala de 300 pessoas, pode ser necessário hardware de custo muito alto
• Ainda assim, vale considerar a evolução de hardware e modelos abertos nos próximos 2 anos

SlimeQ

• Recomenda começar pequeno com instância única + fila e expandir gradualmente conforme o uso aumentar
• Não é viável assumir que as 300 pessoas usarão ao mesmo tempo; a decisão de ampliar deve vir após medir o uso real

Ok-Internal9317

• Na prática, pode haver menos de 10 usuários simultâneos, e talvez 4 a 5 GPUs já sejam suficientes
• No longo prazo, o custo de API pode acabar sendo mais econômico do que hardware próprio

dyoh777

• Dá para fazer uma demo simples com Ollama+WebUI, mas a qualidade do modelo é o fator mais importante

careful-monkey

• Um Mac Studio + muita RAM pode rodar modelos menores, com velocidade em torno de 20 token/sec

tshawkins

• Recomenda soluções SaaS como Microsoft Copilot Studio, com integração ao Power Platform

roman_fyseek, Cergorach, Space__Whiskey

• Limite de VRAM do modelo: 1 sessão = 1 GPU; para 300 usuários simultâneos, seriam necessárias 300 GPUs
• Na prática, seriam necessários limites de conexões simultâneas, caching e arquitetura híbrida

Siderox, SandboChang, unrulywind

• Recomendam testar com um servidor pequeno via PoC (ex.: 1 a 2 pessoas/modelo, verificando aderência ao trabalho real) e expandir gradualmente
• Após definir o cenário real e fazer benchmarking, deve-se validar orçamento e ROI

Little_Marzipan_2087, morosis1982, Daemonero

• Aluguel de GPU em nuvem tende a ser mais barato e escalável, sendo uma solução bastante usada
• Considerando a carga de operação e manutenção, a nuvem é recomendada em vez de investir pesado em hardware

CtiPath, alew3, faldore, Wheynelau

• Foram recomendados frameworks open source de alto desempenho para servidores LLM, como vLLM, OpenWebUI, TGI, sglang
• Também foi recomendada uma arquitetura com fila + load balancer

Outros

• Questões de segurança e jurídicas: mesmo na nuvem, é preciso revisar com rigor localização dos dados, criptografia e conformidade regulatória
• Foram citadas várias opções de hardware, como Mac Studio, RTX 6000 Pro, 4090
• Caching, RAG, limites de contexto e offload podem ajudar a reduzir a carga

Resumo da conclusão

• Um servidor LLM self-hosted é mais viável se começar por um piloto pequeno (PoC) e validar por etapas número real de usuários, requisitos, desempenho e custo
• Atender 300 usuários simultâneos traz uma carga significativa de hardware e operação; dependendo do caso de uso e do orçamento, nuvem, arquitetura híbrida ou soluções comerciais podem ser mais adequadas
• No fim, é preciso considerar em conjunto fatores como segurança, custo, experiência do usuário e manutenção

[xodnrdl201]

Acho que você definiu de forma ampla demais o nível de capacidade de raciocínio necessário para as tarefas desses 300 usuários. Se a ideia for cobrir desde conhecimento comum realmente básico até artigos acadêmicos e temas avançados, essa abordagem faz sentido; mas, pensando no nível real das tarefas que precisam ser processadas, na maioria dos casos algo em torno de 30b com RAG acoplado já deve dar conta. Não será que a escala acabou ficando grande demais por vocês terem tentado elevar todos os pesos do open source de base e depender de capacidades e funções de raciocínio muito altas?

Além disso, me parece correto separar como funções distintas o que pode ser processado imediatamente e o que envolve busca e navegação em documentos.
A faixa de tokens alvo do KV cache para atender 300 usuários simultaneamente também talvez tenha sido estimada de forma excessiva; algo como 20.000 tokens por usuário, com valores quantizados, provavelmente já daria para usar com bastante folga... ??
Se esses 300 usuários não forem, de fato, doutores produzindo artigos acadêmicos, talvez dê para assumir um nível de raciocínio equivalente ao de um estudante do ensino médio (14~30b) e estruturar o processo para explorar diversos documentos internos com uma lógica de RAG e um CoT adequado. Nesse caso, imagino que daria para transformar isso em um projeto piloto com custo razoável.

[tsboard]

Eu também, por necessidade, estou montando uma solução de RAG usando nada menos que 4 GPUs H100 tão cobiçadas, mas considerando não só o investimento direto em hardware como também os custos de energia, resfriamento e afins, continuo achando que simplesmente chamar uma API é muito melhor.

No começo, eu também comecei os testes com Ollama e, depois de ver que ele não conseguia cobrir direito nem 3 usuários simultâneos, passei imediatamente para o vLLM e, de um jeito ou de outro, montei a solução de RAG. Só que, para isso, assumindo 10 usuários simultâneos, já preciso usar quase por completo 2 GPUs H100. Também deixo as tarefas de embedding e busca rodando no vLLM, então mesmo 4 H100 ficam realmente apertadas. E isso com cerca de 90 GB de VRAM por placa.

Claro, eu não entendo muito de IA e estou simplesmente tentando fazer funcionar à força enquanto adapto as coisas às necessidades do departamento e às regras internas de segurança... então fico me perguntando se esse é mesmo o caminho certo. Era o ChatGPT Enterprise? Honestamente, acho que tem um custo-benefício absurdo.

[chinnotching]

Com uma máquina absurdamente barata, talvez dê? Um escritório de advocacia absurdamente grande provavelmente compraria. Mas aí seria tipo deixar máquina de fábrica rodando 24 horas por dia kkk

[neinomu]

Uma pessoa que só pensa no preço de um Porsche e não considera nem um pouco os custos de manutenção, combustível, seguro etc.

[beepp]

Em serviços como chatbots que precisam oferecer streaming, quando há processamento simultâneo, o trabalho de prefill acaba afetando até o decode, então mesmo com VRAM de sobra, do ponto de vista do usuário parece que o desempenho cai bastante.

Também testei opções relacionadas a chunk prefill e o recurso experimental de Disaggregated Prefilling oferecido no vLLM, mas ainda acontece de, quando entra uma nova requisição, as respostas que já estão sendo geradas começarem a travar e picotar, então, do ponto de vista de um desenvolvedor iniciante, fico curioso se existe uma forma mais eficiente além de aumentar o número de GPUs ou de nós.

[iolothebard]

Tudo depende do caso!