r/LocalLLaMAが共有した university hospital 研究室の 1B+ tokens/day ローカル serving 設計

r/LocalLLaMA で強く反応されている self-post の一つが、university hospital の研究室で使っている内部 LLM server の構成をかなり具体的に公開したものだ。投稿者によれば、ここ数週間 stack を調整した結果、現在は 2x H200 上で GPT-OSS-120B を serving しながら 1 日 1B+ tokens を処理できるようになったという。処理量の内訳はおよそ 3 分の 2 が ingestion、3 分の 1 が decode で、単なる自慢ではなく、同じような環境を作りたい人向けの運用メモとして書かれている。

ハードウェアは GPU 以外では比較的控えめで、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 のずれが小さいと見ているからだ。Hopper 世代では mxfp4 の経路が特に良く最適化されているという評価も添えられている。

構成も現実的だ。前段には LiteLLM proxy を置き、OpenAI-compatible API、key、rate limit、routing、priority queue を担当させる。後段には GPU ごとに 1 つずつ、計 2 つの vLLM instance を置き、usage tracking は PostgreSQL、observability は Prometheus と Grafana、内部 documentation は MkDocs で管理する。tensor parallel を使わず GPU 単位の replica にしたのは、mxfp4 なら GPT-OSS-120B が single H200 に収まり、NCCL overhead を避けた方が throughput に有利だからだ。実際、simple-shuffle routing により 6 日間の prompt token 分配が 2.10B 対 2.11B と、ほぼ完全に均衡したという。

設定値も細かい。quantization は mxfp4、context window は 128k、GPU memory utilization は 0.80、chunked prefill と prefix caching を有効化し、instance あたりの max-num-seqs は 128 に設定している。さらに VLLM_USE_FLASHINFER_MXFP4_MOE=1 や NCCL_P2P_DISABLE=1 といった environment variable も共有している。投稿者の見立てでは、この構成での真のボトルネックは KV cache ではなく decode throughput であり、20% の VRAM headroom を残すことで logprobs 系の burst OOM を吸収しやすくなるという。

数字も十分に重い。約 6 日の uptime で総処理量は 6.57B tokens、request 数は 2.76M、1-hour average の combined throughput は 24,225 tok/s に達した。ただし未解決の課題もある。LiteLLM が一方の vLLM replica を cooldown すると、負荷がもう一方へ偏って再び cooldown が発生し、ping-pong のような failure pattern になるというのだ。r/LocalLLaMA がこの投稿を評価しているのは、大きな数字そのものより、実際に運用しているチームがそのまま参考にできそうな detail が揃っているからだろう。