r/LocalLLaMA가 공유한 university hospital 연구실의 1B+ tokens/day 로컬 serving 설계

r/LocalLLaMA에서 주목받은 한 self-post는 university hospital 연구실이 내부 LLM server를 어떻게 구성했는지 꽤 상세하게 공개한다. 작성자는 최근 몇 주 동안 stack을 다듬은 끝에, 이제 2x H200 위에서 GPT-OSS-120B를 serving하며 하루 1B+ tokens를 처리하고 있다고 설명했다. 처리량의 대략 3분의 2는 ingestion, 3분의 1은 decode라고 한다. 단순 자랑보다는 실제 운영에서 어떤 선택이 먹혔는지 공유하는 성격이 강하다.

하드웨어는 2개의 H200, 124GB RAM, 16-core CPU, 512GB disk다. 모델은 Qwen 3, GLM-Air, GPT-OSS를 비교한 뒤 GPT-OSS-120B를 선택했다. 이유는 single-user decode가 대체로 220~250 tok/s로 높았고, JSON adherence와 tool calling이 안정적이었으며, deployed weights와 published evals의 간극이 작다고 봤기 때문이다. 작성자는 community quant보다 mxfp4 경로가 H200에서 훨씬 잘 최적화돼 있다고 평가한다.

구성은 꽤 실전적이다. LiteLLM proxy가 앞단에서 OpenAI-compatible API, key, rate limit, routing을 처리하고, 뒤에는 GPU당 하나씩 두 개의 vLLM instance가 붙는다. 사용량과 spend는 PostgreSQL, 관측은 Prometheus와 Grafana, 문서는 MkDocs로 관리한다. tensor parallel 대신 GPU별 독립 replica를 둔 이유도 분명하다. 이 모델 크기에서는 single H200에 comfortably fit하고, NCCL communication overhead 없이 throughput을 더 잘 뽑을 수 있기 때문이다. 실제로 simple-shuffle routing 이후 6일 동안 prompt token load split이 2.10B 대 2.11B로 거의 완벽했다고 한다.

설정값도 구체적이다. quantization은 mxfp4, max model length는 128000, GPU memory utilization은 0.80, prefix caching과 chunked prefill을 켰고 instance당 max-num-seqs는 128로 잡았다. 추가로 VLLM_USE_FLASHINFER_MXFP4_MOE=1, NCCL_P2P_DISABLE=1 같은 environment variable도 적어 두었다. 작성자는 KV cache보다 decode throughput이 병목이며, logprobs 요청의 burst OOM을 피하려고 headroom을 20% 남기는 방식이 안정적이었다고 설명한다.

운영 수치는 더 흥미롭다. 약 6일 uptime 동안 총 6.57B tokens, 2.76M requests를 처리했고, 1-hour average 기준 combined throughput은 24,225 tok/s였다. 다만 남은 문제도 분명하다. LiteLLM이 한 replica를 cooldown시키면 다른 replica가 과부하를 받고 다시 cooldown되는 ping-pong 현상이 생긴다는 것이다. r/LocalLLaMA가 이 글에 반응한 이유는 단순 benchmark보다 훨씬 실전적인 운영 노하우가 담겨 있기 때문이다. 로컬 high-throughput inference를 실제 서비스처럼 굴리고 싶은 팀에게 꽤 구체적인 출발점이 된다.