01
Un AI privat pentru echipa unui birou, pe plăcile video pe care le avea deja
- Problema
- Echipa voia un asistent AI pentru chat și programare, dar codul și documentele firmei nu aveau ce căuta într-un serviciu public. Nicio stație nu avea destulă memorie GPU pentru un model de 27B cu context lung.
- Ce am făcut
- Am împărțit un model de 27 de miliarde de parametri pe patru stații GPU existente, trei NVIDIA și una AMD, cu llama.cpp RPC, compilat din sursă pentru CUDA, ROCm/HIP și Vulkan. Oamenii îl folosesc din Open WebUI pentru chat și printr-un API compatibil OpenAI direct din tool-urile de programare. Deployment-ul merge pe Bash și systemd, cu verificări de sănătate și rollback. Portul RPC e protejat de firewall, serviciul are contul lui, iar API-ul cere cheie.
- Rezultat
- Test de încărcare cu 10–16 oameni simultan: 0 erori, cam 22 de tokeni pe secundă fiecare, context de 262K tokeni.
- Tehnologii
llama.cpp RPC · CUDA · ROCm/HIP · Vulkan · Open WebUI · Linux · systemd · Bash
Diagramă: utilizatorii se conectează la Open WebUI sau la API, care trimit cererile către llama-server. llama-server împarte modelul pe patru workeri GPU prin llama.cpp RPC: trei NVIDIA și unul AMD. Răspunsurile se întorc în flux.
↑ răspunsurile se întorc în flux
llama-server
llama-server încarcă modelul de 27B și pune câte o parte din el în memoria GPU a fiecărui worker. Pentru fiecare token coordonează workerii prin rețea. Rulează sub un cont de serviciu dedicat.
Aici un singur model e împărțit pe patru calculatoare; nu e load balancing. Fiecare cerere folosește toate cele patru GPU-uri, pentru că fiecare ține o parte din același model.
La ce se folosește
Cele mai multe întrebări sunt despre cod. Pentru că modelul rulează în clădire, oamenii pot lipi cod intern fără ca acesta să iasă din rețea.
Programator
Scriptul ăsta de deploy repornește serverul de inferență, dar nu verifică niciodată dacă a pornit din nou. Cum aștept să fie funcțional, cu o limită de timp?
systemctl restart llama-server
echo "deploy finished"Model local · 27B
Interoghează endpoint-ul /health al llama-server după repornire. Ieși imediat ce răspunde și termină cu cod de eroare dacă tot nu răspunde după 60 de secunde, ca deployment-ul să poată face rollback:
systemctl restart llama-server
for attempt in $(seq 1 30); do
if curl -fsS http://127.0.0.1:8080/health > /dev/null; then
echo "llama-server is healthy"
exit 0
fi
sleep 2
done
echo "llama-server not healthy after 60 s" >&2
exit 1Măsurat în testul de încărcare
- 4
- 27B
- 262K
- 10–16
- 0
- ≈22