사내 챗봇이나 문서 검색형 RAG 서비스를 준비할 때, 팀은 흔히 두 가지 표를 나란히 놓습니다. 한쪽에는 상용 API의 토큰 가격을, 다른 쪽에는 오픈 웨이트 모델의 파라미터 수와 GPU 처리량을 적습니다. 이 비교는 출발점으로는 쓸 수 있지만, 여기서 배포 방식을 결정하면 실패할 가능성이 높습니다.
오픈 웨이트 LLM을 직접 운영할지 판단하는 질문은 “어느 모델이 가장 빠른가”가 아닙니다. 우리 업무 품질을 유지하면서, 목표 응답시간과 동시 사용량을 만족하고, 운영 인력을 포함한 비용을 감당할 수 있는가를 물어야 합니다.
상용 API를 유지할지, 특정 오픈 웨이트 모델을 특정 GPU에 올릴지는 같은 평가 체계로 비교할 수 있습니다. 다만 오픈 웨이트 모델은 모델 자체뿐 아니라 추론 엔진, 정밀도, GPU 간 연결 방식, 컨테이너 버전까지 성능과 운영 가능성에 영향을 줍니다. 이 결합 조건을 고정하지 않으면 벤치마크 숫자는 구매나 배포 결정에 거의 도움이 되지 않습니다.
실패는 모델 비교가 서비스 비교로 바뀌지 않을 때 시작된다
첫 번째 실패는 공개 리더보드나 단일 요청 TPS를 실제 서비스 성능으로 해석하는 데서 생깁니다.
공개 벤치마크는 추론, 코딩, 지식, 다국어 등 모델 능력을 비교하는 데 유용합니다. 그러나 사내 규정 질의, 계약서 요약, 코드 리뷰, 고객 응답 초안처럼 조직의 실제 업무를 그대로 대변하지는 않습니다. 같은 모델도 프롬프트 형식, 검색으로 넣는 문서 길이, 출력 형식 강제 여부, 한국어 비중에 따라 품질이 달라질 수 있습니다.
처리량도 마찬가지입니다. 단일 요청에서 빠른 모델이 동시 요청 16개나 32개에서도 가장 경제적이라는 보장은 없습니다. 반대로 서버 전체 처리량이 높아도 사용자가 첫 답변을 받기까지 오래 기다리면 대화형 서비스에는 맞지 않을 수 있습니다.
조기 신호는 비교표에 다음 항목이 빠져 있을 때 나타납니다.
- 업무별 정답 기준이나 사람 검토 기준이 없다.
- 입력 토큰 길이와 출력 길이가 정해지지 않았다.
- 평균 응답시간만 있고 P95 TTFT가 없다.
- 동시 사용자 수 대신 “부하가 많을 수 있다”는 설명만 있다.
- 모델별 성능 측정 조건이 서로 다르다.
TTFT(Time To First Token)는 요청 후 첫 토큰이 나오기까지 걸리는 시간입니다. 사용자는 답변 전체가 끝나는 시간보다 먼저, 화면에 응답이 시작되는 시간을 체감합니다. 배치 요약 작업이라면 TTFT가 길어도 감수할 수 있지만, 상담 보조나 사내 질의응답 화면에서는 P95 TTFT, 즉 느린 쪽 5% 요청의 첫 응답시간을 서비스 기준으로 삼는 편이 안전합니다.
따라서 모델 후보를 좁히기 전, CTO나 개발 리드는 업무를 최소 두 갈래로 나눠야 합니다. 사용자 대화처럼 즉시성이 중요한 흐름과, 문서 분류·요약·추출처럼 총 처리량이 중요한 흐름입니다. 두 흐름에 하나의 모델과 하나의 배포 구성이 모두 최선일 필요는 없습니다.
파라미터 수와 GPU 수로 용량을 예상하면 어긋나는 이유
두 번째 실패는 모델 크기와 GPU 개수를 성능의 대리 지표로 쓰는 경우입니다.
Dense 모델은 대부분의 파라미터가 토큰 처리에 참여합니다. 반면 MoE(Mixture of Experts, 전문가 혼합) 모델은 전체 파라미터 중 일부 전문가를 선택해 계산합니다. 그래서 전체 파라미터 수가 더 큰 MoE 모델이 특정 환경에서는 더 높은 생성 속도를 보일 수 있습니다. 하지만 활성 파라미터가 적다고 해서 모델 전체 가중치를 저장할 메모리 요구량까지 작아지는 것은 아닙니다.
실행 정밀도도 결과를 바꿉니다. BF16과 FP8처럼 가중치와 연산에 쓰는 형식이 달라지면 GPU 메모리 사용량, 메모리 대역폭 부담, 지원 하드웨어에서의 처리량이 함께 달라집니다. 특정 환경에서 FP8이 BF16보다 높은 처리량을 보였다는 관찰이 있더라도, 이를 다른 모델이나 GPU에 그대로 적용할 수는 없습니다. 양자화 방식, 모델 품질 변화, 추론 엔진 지원 범위를 같이 확인해야 합니다.
GPU를 늘릴 때도 같은 원리가 적용됩니다. 하나의 모델을 여러 GPU에 나누는 텐서 병렬화는 모델 적재 문제를 풀 수 있지만, GPU 사이에서 결과를 주고받고 동기화해야 합니다. PCIe 중심 연결에서는 GPU 수를 늘린 뒤 통신 비용이 계산 이득을 상쇄할 수 있습니다. 모델이 GPU 한 장에 들어간다면, 여러 GPU에 한 모델을 쪼개는 방식보다 GPU마다 모델 복제본을 두고 요청을 분산하는 편이 나을 가능성도 있습니다.
여기서 확인할 질문은 “GPU를 네 장 사면 얼마나 빨라지는가”가 아닙니다.
- 후보 모델은 목표 문맥 길이와 동시성에서 GPU 한 장에 안정적으로 올라가는가
- 여러 GPU를 쓴다면 TP(Tensor Parallelism) 1, 2, 4에서 처리량과 P95 TTFT가 어떻게 달라지는가
- 서버의 GPU 간 연결은 NVLink나 NVSwitch인지, PCIe 경로인지
- 모델 분산과 모델 복제 중 어느 방식이 서비스 요구량에 더 맞는가
이 질문에 답하지 않은 GPU 증설은 용량 계획이 아니라 추측에 가깝습니다.
비용 계산은 토큰당 가격보다 늦게 시작해야 한다
세 번째 실패는 품질과 서비스 수준을 통과하지 못한 모델의 비용 효율을 먼저 비교하는 일입니다. 출력 TPS가 높으면 시간당 서버 비용을 기준으로 달러당 출력 토큰 수를 계산할 수 있습니다.
Tokens/$ = 출력 TPS × 3,600 ÷ 시간당 서버 비용
이 지표는 같은 조건의 후보를 비교하는 데 유용합니다. 다만 GPU 비용만 넣은 계산은 자체 운영의 총비용이 아닙니다. 모델 파일 저장, 이미지 관리, 모니터링, 접근 통제, 장애 대응, 업데이트 검증, 온콜 부담이 남습니다. GPU 한 장의 처리량에 GPU 네 장 서버 전체 가격을 적용했는지, 남은 GPU에 복제본을 추가로 운영할 수 있는지도 계산의 전제를 바꿉니다.
API형 LLM의 비용도 입력·출력 토큰 단가만으로 판단하기 어렵습니다. 사용량 변동이 크고, 빠른 시작과 모델 교체가 중요하며, GPU 운영 인력이 제한된 팀이라면 API의 운영 단순성이 비용 이상의 가치가 될 수 있습니다. 반대로 외부 전송이 어려운 데이터가 많거나 인터넷과 분리된 환경에서 운영해야 한다면, 오픈 웨이트 모델은 절감 수단 이전에 필요한 배포 방식일 수 있습니다.
비용 비교는 다음 순서를 지키는 편이 낫습니다.
- 업무 품질 하한선을 넘는 후보만 남긴다.
- 각 후보가 목표 P95 TTFT와 동시성 조건을 만족하는지 확인한다.
- 그 조건을 만족하는 구성끼리 GPU, API, 운영 인력 비용을 비교한다.
- 수요 변동이 큰 서비스는 평균 사용량뿐 아니라 유휴 GPU 시간과 피크 시간의 대기열도 검토한다.
호환성 문제는 PoC의 부수 작업이 아니라 탈락 기준이다
모델 가중치가 GPU 메모리에 들어간다고 해서 서비스에 배포할 수 있는 것은 아닙니다. 모델 아키텍처를 추론 엔진이 인식하지 못하거나, Transformers 업데이트가 다른 모델 실행 환경을 깨뜨리거나, 특정 양자화 형식이 현재 GPU와 엔진 조합에서 지원되지 않을 수 있습니다.
이 문제는 종종 성능 테스트 뒤에 발견됩니다. 그러면 이미 GPU 인스턴스 비용과 엔지니어링 시간이 들어간 뒤입니다. 큰 체크포인트는 내려받기 전에 파일 크기, 데이터 형식, 예상 GPU 메모리, 목표 컨텍스트 길이에서의 KV 캐시 여유를 먼저 검토하는 편이 낫습니다. 체크포인트 파일 크기와 실제 추론 메모리는 같지 않지만, 현재 서버에서 실행 가능성이 낮은 후보를 일찍 제외하는 데는 도움이 됩니다.
벤더 선정이나 내부 플랫폼 구축 단계에서는 모델별로 다음 산출물을 요구할 수 있습니다.
- CUDA, 드라이버, 추론 엔진, Transformers, 모델 코드의 검증 버전 목록
- 모델별 고정 컨테이너 이미지와 재현 가능한 배포 절차
- 목표 입력 길이, 출력 길이, 동시성에서의 메모리 사용량
- 장애 시 재시작, 모델 교체, 롤백 방법
- 모델 업데이트 때 품질·지연시간 회귀를 확인하는 테스트 계획
“지원한다”는 답만으로는 부족합니다. 우리 환경의 정확한 버전 조합에서 설치, 기동, 요청 처리, 재배포까지 반복 가능한지를 확인해야 합니다.
API 유지와 자체 배포를 가르는 검증 순서
의사결정 회의에서 먼저 확정할 것은 모델 이름이 아니라 서비스 경계입니다. 어떤 데이터가 외부 전송 불가인지, 어떤 요청은 고성능 상용 모델을 허용하는지, 어떤 요청은 내부 모델로 충분한지를 구분합니다. 이 경계가 정해지면 API와 자체 배포를 경쟁 관계로만 보지 않아도 됩니다.
그다음 대표 업무를 선정해 고정된 평가 묶음을 만듭니다. 일반 질의, 한국어 업무 문서, 코딩, 추론, 요약, 긴 문맥 RAG처럼 서비스에 실제로 들어올 유형을 포함하되, 각 유형의 합격 기준은 조직이 정해야 합니다. 품질 평가는 정답 일치만 보지 말고 근거 누락, 형식 위반, 검색 문서와 무관한 답변, 위험한 자동 실행 가능성처럼 업무 실패 방식도 기록해야 합니다.
성능 시험에서는 후보별로 같은 입력 길이, 출력 제한, 프롬프트, 동시성 단계를 적용합니다. 평균 TPS 하나가 아니라 전체 처리량, P95 TTFT, 오류율, 메모리 여유, 장시간 실행 안정성을 함께 남깁니다. 이후에야 GPU 수, 정밀도, 텐서 병렬화, 복제본 수를 바꿔 비용 최적화를 검토할 수 있습니다.
첫 PoC의 목표는 가장 빠른 모델을 찾는 일이 아닙니다. 서비스 조건을 충족하지 못하는 조합을 빠르게 제외하고, 남은 후보가 운영 가능한 상태인지 확인하는 일입니다. 그 결과 API를 유지하는 결정이 나와도 실패가 아닙니다. 자체 운영이 필요한 요청 범위와, 제공사 관리형 서비스에 맡기는 요청 범위를 분리할 근거가 생긴 것이기 때문입니다.
