온프레미스 LLM 서비스 구축 예시
온프레미스 LLM 서비스 구축 예시
온프레미스 LLM은 모델 가중치와 추론 서버를 조직이 통제하는 인프라에 배치하고, 사내 서비스가 내부 네트워크를 통해 이용하도록 구성하는 방식입니다. 단순히 외부 LLM API 앞에 프록시를 두는 것과 달리 GPU 자원, 모델 파일, 추론 엔진, 보안 정책과 운영 체계를 직접 관리합니다.
이 방식은 데이터 경계를 명확히 하고 외부 API 의존도를 줄이는 데 도움이 될 수 있습니다. 반면 GPU 조달과 용량 계획, 전력과 냉각, 드라이버 호환성, 모델 라이선스, 보안 업데이트와 장애 대응까지 책임져야 합니다. 따라서 온프레미스가 언제나 더 저렴하거나 안전하다고 가정하기보다, 데이터 등급과 품질 목표, 예상 트래픽을 기준으로 적합성을 먼저 검증해야 합니다.
이 문서는 특정 기업의 실제 환경이나 확정 견적이 아닌 공개용 구축 예시입니다. 장비 수량과 모델, 일정은 벤치마크와 요구사항 확정 후 결정합니다.
1. 구축 목표
- 사내 서비스가 사용할 수 있는 OpenAI 호환 추론 API 제공
- 모델과 프롬프트가 승인되지 않은 외부 경로로 전송되지 않도록 네트워크 경계 설정
- 서비스 계정별 인증, 모델 허용 목록, 호출량과 동시 요청 수 통제
- 모델 버전과 컨테이너 이미지를 고정해 재현 가능한 배포와 롤백 지원
- 지연 시간, 처리량, 대기열, GPU와 KV 캐시 사용량을 관측할 수 있는 운영 기반 마련
- 단일 GPU 검증 환경에서 다중 노드 운영 환경으로 확장 가능한 구조 준비
2. 권장 아키텍처
사내 업무 서비스 / 사내 사용자 화면
|
내부 인증 및 TLS
|
API Gateway 또는 LiteLLM
- 서비스 계정과 API 키
- 모델 허용 목록
- 호출량과 동시 요청 제한
- 감사 로그와 사용량 집계
|
로드 밸런서
|
vLLM 추론 서버 복제본
|
GPU 노드
|
내부 모델 저장소 / 이미지 레지스트리
관측 계층: Prometheus, Grafana, 로그 수집기
선택 계층: 문서 수집, 임베딩, 벡터 데이터베이스, 권한 필터를 포함한 RAG
구성은 제어 영역과 추론 영역으로 나누는 편이 좋습니다.
- 제어 영역: 사용자와 서비스 인증, 모델 등록, 배포 승인, 정책 변경, 사용량 집계와 감사 기록을 담당합니다.
- 추론 영역: GPU에서 모델을 적재하고 실제 생성 요청을 처리합니다. 추론 서버는 외부에 직접 공개하지 않고 게이트웨이를 통해서만 접근하게 합니다.
3. 주요 구성 요소
| 영역 | 구성 요소 | 역할과 확인 사항 |
|---|---|---|
| 연산 | GPU 서버 또는 GPU 클러스터 | 후보 모델의 정밀도, 컨텍스트 길이, 동시 요청 수를 기준으로 메모리와 처리량을 산정합니다. |
| 실행 환경 | Linux, GPU 드라이버, 컨테이너 런타임 | 가속기, 드라이버, CUDA 또는 해당 런타임, 추론 엔진의 지원 조합을 확인합니다. NVIDIA 환경에서는 Container Toolkit이나 Kubernetes GPU Operator를 검토할 수 있습니다. |
| 추론 엔진 | vLLM | OpenAI 호환 API와 스트리밍을 제공하고 모델 병렬화, 배치 처리와 메트릭 노출을 담당합니다. 사용할 모델의 채팅 템플릿과 지원 기능은 별도로 확인합니다. |
| API 제어 | LiteLLM 또는 기존 API Gateway | 서비스 계정 인증, 모델 별칭, 허용 모델, 호출량과 동시 요청 제한, 비용 또는 내부 사용량 배분을 담당합니다. |
| 모델 관리 | 내부 모델 저장소 또는 오브젝트 스토리지 | 승인한 모델 리비전, 라이선스, 모델 카드, 체크섬과 반입 이력을 보관합니다. |
| 배포 | Docker Compose 또는 Kubernetes | 검증 환경은 단일 서버로 시작할 수 있고, 운영 환경은 다중 노드 배치, 상태 확인과 순차 배포가 필요합니다. |
| 관측 | Prometheus, Grafana, 로그 수집기 | 첫 토큰 지연 시간, 토큰 간 지연 시간, 전체 응답 시간, 처리량, 대기 요청, 오류, GPU와 KV 캐시 사용량을 확인합니다. |
| 보안 | 비밀 관리, IAM, 방화벽, 인증서 | 최소 권한, 내부 전용 접근, 비밀 교체, 송수신 암호화, 로그 보존과 민감정보 마스킹 정책을 적용합니다. |
4. 배포 형태별 구축 예시
4.1 단일 GPU 검증 환경
한 대의 GPU 서버에 컨테이너 런타임, vLLM과 게이트웨이를 배치합니다. 후보 모델의 품질과 실제 업무 요청의 지연 시간을 측정하고 API 연동 방식을 확정하는 단계에 적합합니다.
- 모델과 컨테이너 이미지 버전을 고정합니다.
- 추론 서버의 상태 확인과 메트릭 엔드포인트를 연결합니다.
- 게이트웨이에 서비스 계정과 허용 모델을 등록합니다.
- 대표 입력과 기대 결과로 구성한 평가 세트를 실행합니다.
- 장애 조치나 무중단 배포를 보장하지 않는 검증 환경임을 명확히 합니다.
4.2 다중 GPU 또는 다중 노드 운영 환경
운영 환경은 로드 밸런서와 여러 추론 복제본을 두고, Kubernetes와 GPU Operator, KServe 또는 Ray Serve 같은 구성 요소를 선택할 수 있습니다. 모델이 한 장의 GPU 메모리에 들어가지 않으면 텐서 병렬화나 파이프라인 병렬화 지원 범위를 검토합니다.
- 노드와 가속기 장애 시 요청을 정상 복제본으로 전환합니다.
- 준비 상태를 통과한 복제본에만 트래픽을 전달합니다.
- 새 모델은 일부 트래픽이나 별도 검증 엔드포인트에서 확인한 뒤 승격합니다.
- 모델 적재 시간과 GPU 자원 부족을 고려해 배포와 복구 절차를 설계합니다.
- 고가용성 수준과 복구 목표는 서비스 중요도에 맞춰 별도로 확정합니다.
4.3 외부망이 차단된 환경
망 분리 또는 폐쇄망에서는 모델 파일만 복사하면 끝나는 것이 아닙니다. 승인된 반입 경로와 내부 저장소를 운영 절차로 만들어야 합니다.
- 외부 구간에서 모델 리비전, 라이선스, 체크섬과 악성 파일 검사 결과를 확인합니다.
- 승인된 모델 스냅샷, 컨테이너 이미지와 패키지를 내부 레지스트리 또는 미러로 반입합니다.
- 실행 환경은 오프라인 모드와 로컬 파일만 사용하도록 설정합니다.
- 보안 패치와 모델 업데이트도 같은 승인 절차로 반복할 수 있게 문서화합니다.
- 방화벽 차단 여부와 실제 외부 통신 시도를 함께 시험합니다.
5. 모델 선정과 라이선스 검토
모델 이름이나 파라미터 수만으로 운영 모델을 정하면 안 됩니다. 실제 업무 입력으로 품질과 성능을 함께 비교합니다.
- 한국어 이해와 생성 품질
- 요약, 분류, 질의응답, 코드 생성 등 핵심 업무 적합성
- 필요한 컨텍스트 길이와 최대 출력 길이
- 도구 호출, 구조화 출력, 멀티모달 등 필수 기능 지원 여부
- 양자화 적용 전후의 품질과 처리량 변화
- 상업적 이용, 내부 서비스 제공, 수정과 재배포에 관한 라이선스 조건
- 접근 승인이 필요한 게이트 모델의 사용 조건과 계정 관리 방식
운영에 반입할 때는 모델 저장소의 최신 상태를 그대로 참조하지 않고 정확한 리비전이나 커밋을 고정합니다. 모델 카드, 라이선스 사본, 체크섬, 승인자와 반입 일자를 함께 보관하면 업데이트와 롤백 근거를 남길 수 있습니다.
6. 용량 산정과 벤치마크
필요한 GPU 수는 모델 크기 하나로 확정할 수 없습니다. 모델 가중치 외에도 KV 캐시와 실행 메모리가 필요하고, 긴 컨텍스트와 높은 동시 요청 수는 메모리 사용량과 지연 시간을 크게 바꿉니다.
다음 값을 실제 요청 분포에 맞춰 측정합니다.
- 입력 토큰과 출력 토큰의 평균, 상위 구간과 최대값
- 동시 요청 수와 초당 또는 분당 요청량
- 첫 토큰 지연 시간(TTFT)
- 토큰 간 지연 시간(TPOT 또는 inter-token latency)
- 전체 응답 시간과 생성 처리량
- 대기열 길이, 요청 실패율과 제한 발생 횟수
- GPU 메모리와 연산 사용률, KV 캐시 사용률
양자화는 메모리 사용량을 줄일 수 있지만 모델별 품질과 성능 변화가 다릅니다. 후보 모델, 정밀도, 컨텍스트 길이와 동시 요청 수의 조합을 대표 평가 세트로 비교한 뒤 장비 수량을 결정합니다. 제조사 사양이나 공개 벤치마크만으로 납품 성능을 약속하지 않습니다.
7. API 게이트웨이와 보안 정책
vLLM은 OpenAI 호환 HTTP 서버를 제공하지만 조직 전체의 인증과 사용 정책을 대신하는 관리 계층은 아닙니다. LiteLLM이나 기존 API Gateway를 앞에 두고 다음 정책을 적용합니다.
- 사람 계정과 서비스 계정을 분리하고 최소 권한을 부여합니다.
- 서비스별로 사용할 수 있는 모델과 최대 컨텍스트, 출력 길이를 제한합니다.
- 분당 호출량뿐 아니라 동시 요청 수와 대기열 상한을 설정합니다.
- 추론 서버는 내부 네트워크에서 게이트웨이를 통해서만 접근하게 합니다.
- TLS를 적용하고 보안 수준에 따라 서비스 간 상호 TLS를 검토합니다.
- 프롬프트와 응답은 기본적으로 민감 데이터로 취급합니다.
- 원문 로그 저장 여부, 마스킹 대상, 보존 기간과 열람 권한을 사전에 정합니다.
- 비밀값은 이미지나 설정 파일에 넣지 않고 전용 비밀 관리 수단으로 주입합니다.
- 모델 파일과 컨테이너 이미지의 출처, 취약점 검사, 업데이트와 롤백 이력을 관리합니다.
폐쇄망도 그 자체로 안전을 보장하지 않습니다. 반입 파일, 관리자 계정, 내부자 접근, 로그와 백업까지 포함한 운영 통제가 필요합니다.
8. RAG와 파인튜닝의 범위
사내 문서를 검색해 답변하는 RAG는 기본 추론 서버와 별도의 데이터 파이프라인입니다. 다음 항목이 추가됩니다.
- 문서 원본 연결, 형식 변환, 분할과 임베딩 생성
- 벡터 데이터베이스와 메타데이터 저장소
- 사용자와 문서 권한을 반영하는 검색 단계의 접근 제어
- 답변 근거와 출처 표시
- 원본 변경과 삭제를 반영하는 재색인 절차
- 검색 품질, 답변 충실도와 권한 누출 시험
RAG를 적용해도 답변의 정확성이 자동으로 보장되지는 않습니다. 특히 문서 권한은 모델에게 지시하는 방식이 아니라 검색 단계에서 강제해야 합니다.
파인튜닝과 추가 학습도 별도 범위로 분리합니다. 학습 데이터 수집과 정제, 개인정보와 저작권 검토, 학습용 GPU, 평가와 모델 등록 절차가 추가되기 때문입니다. 초기에는 기본 모델과 프롬프트, RAG만으로 목표 품질을 달성할 수 있는지 먼저 확인하는 편이 일반적입니다.
9. 착수 전에 확정할 항목
| 구분 | 확정할 내용 | 결정이 필요한 이유 |
|---|---|---|
| 업무 범위 | 요약, 검색, 문서 작성, 코드 보조 등 우선 사용 사례 | 평가 데이터와 필요한 모델 기능이 달라집니다. |
| 데이터 등급 | 입력 가능한 정보, 개인정보와 기밀정보 범위 | 네트워크, 로그와 접근 통제 수준을 결정합니다. |
| 모델 | 후보 모델, 리비전, 라이선스와 사용 승인 | 품질, 메모리, 운영 조건과 법적 의무가 달라집니다. |
| 성능 목표 | TTFT, 전체 응답 시간, 처리량, 동시 요청 수 | GPU 수량과 확장 방식을 정하는 기준입니다. |
| 요청 한도 | 최대 입력, 출력과 컨텍스트 길이 | 메모리 사용량과 사용자 경험에 직접 영향을 줍니다. |
| 가속기 | 기존 장비 활용 또는 신규 조달, 지원 런타임 | 드라이버와 추론 엔진 호환성, 일정에 영향을 줍니다. |
| 배포 구조 | 단일 서버, 다중 노드, Kubernetes 사용 여부 | 고가용성, 운영 복잡도와 산출물이 달라집니다. |
| 네트워크 | 내부망, 망 분리, 외부 통신 허용 목록 | 모델과 이미지 반입, 업데이트 방식을 결정합니다. |
| 인증 | 사내 SSO, 서비스 계정, API 키 또는 인증서 | 발급, 회수와 감사 방식을 확정해야 합니다. |
| 로그 | 원문 저장 여부, 마스킹, 보존 기간과 열람자 | 개인정보 보호와 장애 분석 요구를 함께 맞춰야 합니다. |
| 복구 | 가용성 수준, 백업 범위, 복구 목표와 롤백 기준 | 노드 장애와 잘못된 모델 배포에 대응하는 기준입니다. |
| 확장 기능 | RAG, 파인튜닝, 멀티모달, 외부 API 대체 경로 | 기본 추론 구축과 별도 일정, 인프라가 필요할 수 있습니다. |
10. 단계별 구축 절차
1단계: 요구사항과 데이터 경계 정의
사용 사례, 호출 주체, 데이터 등급, 네트워크 경계와 성공 기준을 확정합니다. 운영 서비스와 검증 환경의 책임자를 구분합니다.
2단계: 후보 모델 평가
실제 업무를 대표하는 평가 세트를 만들고 후보 모델의 품질, 기능, 라이선스와 안전성을 비교합니다. 정답이 하나가 아닌 생성 업무는 평가 기준과 사람 검토 절차를 함께 정합니다.
3단계: 성능 시험과 장비 산정
후보 장비에서 모델 정밀도, 양자화, 컨텍스트 길이와 동시 요청 수를 바꿔 측정합니다. 결과를 근거로 GPU와 저장소, 네트워크 용량을 산정합니다.
4단계: 기반 인프라 구축
서버 운영체제, 드라이버, 컨테이너 런타임, 내부 레지스트리, 인증서와 방화벽을 구성합니다. 지원 조합과 버전을 문서로 고정합니다.
5단계: 모델 반입과 추론 서버 배포
승인한 모델 스냅샷을 내부 저장소에 등록하고 vLLM을 배포합니다. 상태 확인, 준비 상태, 모델 적재 실패와 메트릭 수집을 점검합니다.
6단계: 게이트웨이와 정책 적용
내부 엔드포인트를 만들고 서비스 계정, 모델 별칭, 허용 목록, 요청과 동시성 제한을 설정합니다. 비밀 발급과 회수 절차도 함께 작성합니다.
7단계: 관측과 장애 대응 구성
대시보드와 경보를 만들고 GPU 부족, 대기열 증가, 모델 적재 실패, 노드 장애와 비정상 응답에 대한 대응 절차를 작성합니다.
8단계: 통합 시험과 단계적 전환
부하, 보안, 장애와 롤백 시험을 수행합니다. 일부 내부 사용자부터 적용하고 품질과 자원 사용량을 확인한 뒤 이용 범위를 넓힙니다.
정확한 일정은 장비 확보 여부, 후보 모델 수, 폐쇄망 반입 절차와 RAG 포함 여부에 따라 달라집니다. 모델 평가와 장비 조달이 완료되지 않은 상태에서 고정된 오픈 일정을 먼저 약속하지 않는 것이 안전합니다.
11. 인수 시험 예시
- 승인된 모델 리비전이 지정된 노드에서 정상 적재되고 상태 확인을 통과합니다.
- 허용된 서비스 계정의 요청은 성공하고, 만료되거나 권한이 없는 요청은 차단됩니다.
- 필요한 채팅, 스트리밍, 도구 호출 또는 구조화 출력 기능이 연동 시험을 통과합니다.
- 합의한 입력과 출력 길이, 동시 요청 조건에서 지연 시간과 처리량 목표를 충족합니다.
- TTFT, 토큰 간 지연 시간, 전체 응답 시간, 대기열, 오류, GPU와 KV 캐시 지표를 확인할 수 있습니다.
- 프로세스와 노드 재시작, 모델 배포 실패와 이전 버전 롤백 절차가 검증됩니다.
- 원문 로그 저장을 끈 경우 프롬프트와 응답이 일반 로그에 남지 않습니다.
- 모델 라이선스, 리비전, 체크섬과 반입 이력을 확인할 수 있습니다.
- 설정, 모델 목록과 운영 데이터의 백업 및 복구 절차를 시험합니다.
- 폐쇄망 요구가 있다면 승인되지 않은 외부 통신이 발생하지 않음을 확인합니다.
- RAG가 포함되면 권한이 없는 문서가 검색 결과와 답변에 포함되지 않음을 시험합니다.
12. 권장 산출물
- 인프라, 네트워크와 요청 흐름을 포함한 아키텍처 구성도
- 후보 모델 비교표, 평가 세트와 품질 평가 결과
- 장비 산정 근거와 부하 시험 보고서
- 버전이 고정된 컨테이너와 오케스트레이션 설정 파일
- 승인된 모델 목록, 리비전, 라이선스와 반입 절차
- vLLM과 API Gateway 또는 LiteLLM 설정
- 서비스 계정과 비밀 발급, 교체, 회수 절차
- 모니터링 대시보드, 경보 기준과 로그 정책
- 배포, 업데이트, 롤백, 백업, 복구와 장애 대응 운영서
- API 연동 예제 또는 Postman 컬렉션
- 인수 시험 결과와 관리자 인수인계 문서
13. 제외 범위를 명확히 해야 하는 항목
다음 항목은 기본 추론 서비스에 자동으로 포함되는 것으로 보지 않고 별도 범위와 비용을 정하는 편이 좋습니다.
- GPU 서버 구매, 데이터센터 상면, 전력과 냉각 공사
- 모델 학습과 파인튜닝용 데이터 구축
- 사내 문서 수집, 권한 연동과 RAG 구축
- 사용자용 채팅 화면이나 업무 시스템 UI 신규 개발
- 모델 공급자의 라이선스 비용과 상업 이용 협의
- 연중무휴 관제, 현장 하드웨어 교체와 장기 운영 대행
- 특정 모델이 모든 업무에서 정답을 생성한다는 품질 보증
14. 공식 참고 자료
- vLLM Online Serving
- vLLM Metrics
- vLLM GPU Installation
- NVIDIA Container Toolkit
- NVIDIA GPU Operator
- Hugging Face 모델 다운로드와 리비전 고정
- Hugging Face 오프라인 모드
- Hugging Face 게이트 모델
- KServe 생성형 추론 개요