폐쇄망 AI 코딩 에이전트, GPU가 몇 장 필요한가요 — H100 기준 사이징 노트

폐쇄망에서 AI 에이전트를 검토하는 기관과 미팅을 하면 질문이 결국 한 곳으로 수렴한다. "그래서 GPU 가 몇 장 필요한가요?" 인원 100명이 넘으면 어떻게 되냐, 최소로 시작하면 얼마냐, 클라우드 모델을 못 쓰는데 뭘 올리냐. 전부 같은 질문의 변형이다. 미팅 때마다 화이트보드에 그리던 걸 한 번 정리해 둔다.

동시 사용자 수 기준으로 GPU는 몇 장인가?

기준선은 이렇다. 32B 급 코딩 모델 기준으로 80GB GPU(A100/H100) 1장이 동시 에이전트 세션 5~10개를 감당한다. 그래서 동시 10명 수준의 중규모 구성이면 H100 80GB 1장이 출발점이고, 운영 여유와 장애 대비까지 잡으면 2장 구성을 권한다. 수십 명이 동시에 쓰는 대형 기관은 2장 이상, 여기서부터는 산수가 단순해진다.

필요 GPU 노드 ≈ 동시 에이전트 실행 수 ÷ (80GB 1장당 5~10 세션)

주의할 건 "인원 수"가 아니라 "동시 실행 수"라는 점이다. 재직자 100명이 전부 같은 시각에 에이전트를 돌리는 조직은 없다. 그런데 반대로, 에이전트는 사람과 달리 한 명이 세션 여러 개를 병렬로 띄울 수 있다. 그래서 100명 조직에서 에이전트 사용이 성숙하면 동시 실행 수가 수십을 넘기 시작하고, 그때 "H100 수십 장" 이야기가 과장이 아니게 된다. 인원이 아니라 사용 패턴이 사이징을 결정한다.

VRAM 쪽 산수도 적어두면, 모델이 차지하는 메모리는 대략 파라미터 수 × 파라미터당 바이트(FP16 이면 2, INT8 이면 1, INT4 면 0.5)이고, 여기에 KV 캐시로 20~40% 를 얹는다. 32B 모델을 INT8 로 돌리면 32GB + 캐시로 80GB 1장에 여유 있게 들어가고, INT4 로 낮추면 48GB 급(L40S) 1장에서도 돈다. 이게 PoC 최소 구성이다.

클라우드 모델을 못 쓰는데, 뭘 올리나?

폐쇄망에 올릴 수 있는 건 오픈 웨이트 모델이고, 현재 우리 기준 sweet spot 은 Qwen2.5-Coder-32B(Apache 2.0)다. 코딩 성능, tool-calling 안정성, 라이선스, GPU 비용의 균형점이 여기다. 그 아래로 7B 급 경량 모델은 보조 용도로는 쓸 만한데 구조화된 출력이 자주 깨져서 에이전트 본체로는 권하지 않는다. 위로는 70B급, 그리고 80B MoE 계열이 있는데 GPU 가 2장 이상으로 늘어난다. 100B 를 넘는 대형 MoE 는 8×GPU 노드가 필요해서, 솔직히 대부분의 기관에는 과투자라고 미팅에서도 말린다. 국산 모델이 요건인 조직에는 LG EXAONE 계열이 옵션인데, 상업 이용 라이선스 계약이 별도로 필요하다는 점은 미리 확인해야 한다.

여기서 정직해야 할 부분. 폐쇄망 오픈 모델은 클라우드 프런티어 모델과 동급이 아니다. Claude 급 모델은 온프렘에 들어오지 않는다. 우리가 실측으로 보는 위치는, 32B 오픈 모델에 컨텍스트 주입과 실행 레이어를 제대로 붙였을 때 한두 세대 전 프런티어급 코딩 능력에 접근하는 정도다. 이걸 부풀려 말하는 벤더를 조심하면 된다. 대신 온프렘만의 이점이 하나 있는데, 하드웨어는 그대로 두고 모델 파일만 교체하면 성능이 올라간다는 것. 오픈 모델 생태계가 반년 단위로 좋아지고 있어서, 오늘 산 GPU 의 가치가 시간이 지날수록 커지는 드문 구조다. 운영 디테일은 폐쇄망 Llama/Qwen 9개월 노트에 있다.

왜 에이전트는 토큰을 그렇게 많이 쓰나?

에이전트의 토큰 소비가 챗봇의 수십 배인 건 구조적인 문제다. 챗봇은 질문 하나에 답 하나를 만들고 끝난다. 코딩 에이전트는 다르다. 파일을 읽고, 계획을 세우고, 수정하고, 빌드를 돌리고, 실패 로그를 다시 읽고, 또 수정한다. 루프 한 바퀴마다 이전 컨텍스트가 다시 입력으로 들어간다. 한 번의 "작업"이 내부적으로는 수십 번의 모델 호출이고, 호출마다 컨텍스트가 쌓인다.

이게 사이징에 주는 함의는 명확하다. GPU 사이징에서 병목은 사용자 수가 아니라 토큰 처리량이고, 토큰 처리량은 에이전트 사용 강도에 비례한다. 그래서 우리는 에이전트별 토큰 예산과 세션 길이 제한을 플랫폼 차원에서 건다. 무제한으로 열어두면 잘 쓰는 조직일수록 GPU 가 먼저 마른다. 클라우드 환경에서 같은 문제를 비용으로 겪은 기록은 LLM 비용 통제 6가지 패턴에 있는데, 온프렘에서는 그 청구서가 GPU 대기열로 모습만 바꿔 돌아온다.

그런데 이게 폐쇄망에서 정말 되나?

된다. 우리는 폐쇄망을 예외 상황이 아니라 1급 시나리오로 설계했다. 모델 패키지가 오프라인 설치 번들에 포함되고, 라이선스 활성화도 서명 검증 기반 오프라인으로 처리되고, 추론은 전부 내부 GPU 에서 돈다. 외부로 나가는 트래픽이 0 임을 보안 담당자가 직접 검증할 수 있어야 한다는 걸 요건으로 놓고 만들었다. 폐쇄망 에이전트가 어려운 진짜 이유는 모델이 아니라 실행 권한과 감사라는 얘기는 별도 글에서 다뤘다.

GPU 도입을 검토 중인 기관에 우리가 실제로 하는 조언은 싱겁다. 동시 실행 수를 먼저 추정하고, 80GB 1장으로 시작해서 대기열 지표를 보고 늘리라는 것. GPU 는 나중에 더 살 수 있지만, 반대로 처음부터 수십 장을 사 놓고 사용률 10% 로 노는 장비만큼 감사에서 아픈 항목도 없다.