온프레미스 LLM(on-prem LLM)을 운영한다는 것은 오픈 웨이트 모델이나 사설 배포용으로 라이선스를 받은 벤더 모델을 조직이 소유하거나 단독으로 임차한 하드웨어에서 서빙한다는 뜻입니다. 팀은 GPU 용량, 서빙 스택, 모델 업데이트를 맡고, 새 버전이 이전 버전보다 나은지 판단하는 평가도 직접 수행합니다.
조직이 이 방식을 택하는 이유는 대체로 다음과 같습니다.
- 특정 기록을 특정 관할권이나 사내에 두도록 하는 데이터 레지던시 규정
- 고객 데이터를 외부 제공자에게 보내지 못하게 하는 계약
- 지연 시간이나 처리량 때문에 토큰당 API 요금이 비싸지는 워크로드
- 외부로 나가는 연결이 전혀 없는 환경. 자세한 내용은 국방 분야의 에어갭 배포에서 다룹니다
트레이드오프는 잘 알려져 있습니다. 내부에서 실행할 수 있는 모델은 대개 가장 강력한 호스팅 모델보다 한 세대 뒤처지고, 운영 부담은 팀이 지게 됩니다.
모델을 어디서 실행하느냐로 질문 하나는 정리되지만, 두 가지 질문은 남습니다. 정리되는 질문은 프롬프트와 출력이 어디로 이동하는가입니다. 모델이 받는 데이터가 업무에 맞는지는 정리되지 않으며, 이는 여전히 업무에 필요한 결과를 기준으로 데이터를 준비하고 확인하는 일에 달려 있습니다. 까다로운 업무를 여전히 외부 모델로 보내야 할 때 어떻게 할지도 정리되지 않습니다. 내부에서 모델을 운영하는 조직에서도 흔히 생기는 일입니다.
두 번째 경우에는 컨텍스트 보존 데이터 레이어가 민감한 값을 모델에게 의미가 유지되는 대체값으로 바꾸고, 응답에서 원래 값을 복원합니다. 그러면 온프레미스 LLM과 외부 LLM 사이의 선택을 조직 전체에서 한 번에 정하지 않고 업무별로 내릴 수 있습니다. CUBIG의 LLM Capsule은 두 방식 모두와 함께 작동하며, Syntitan은 모델이 어디서 실행되든 업무에 맞게 데이터를 준비하고 검증합니다. LLM Capsule vs AI DLP에서는 일부 워크로드가 환경 밖으로 나갈 때 무엇이 달라지는지 다룹니다.
온프레미스 LLM은 컨텍스트 보존 데이터 레이어와 어떻게 다른가요?
두 방식 모두 민감한 데이터를 조직 안에 두지만, 경로가 다릅니다. 온프레미스 LLM은 모델을 데이터가 있는 곳으로 옮기므로, 모든 프롬프트와 출력이 팀이 통제하는 하드웨어에 머뭅니다. 컨텍스트 보존 데이터 레이어는 모델을 그대로 두고 밖으로 나가는 내용을 바꿉니다. 민감한 값을 의미가 유지되는 대체값으로 바꾸고, 매핑은 내부에 남기며, 응답에서 원래 값을 복원합니다.
- 온프레미스 LLM: 데이터 이동 경로를 가장 강하게 통제할 수 있으며, 서빙, 업데이트, 평가는 팀이 맡습니다.
- 컨텍스트 보존 데이터 레이어: 까다로운 업무에 가장 강력한 호스팅 모델을 쓸 수 있으며, 원래 값과 매핑은 고객 환경 안에 둡니다.
- 함께 쓰는 경우: 같은 데이터 규칙 아래에서 업무마다 맞는 모델로 보냅니다.
AI 업무에서 온프레미스 LLM은 어디서 문제가 되나요?
흔한 실패는 위치를 준비 상태로 착각하는 것입니다. 한 팀이 방화벽 안에서 모델을 서빙하고 사내 문서 저장소에 연결한 뒤 출시합니다. 몇 달 뒤 답변에 봄에 교체된 구매 정책이 인용됩니다. 어떤 문서가 최신인지 아무도 확인하지 않았고, 그 업무에서 올바른 답이 무엇인지도 정의하지 않았기 때문입니다.
모델이 어디서 실행되는지만으로는 데이터가 업무에 맞는지 알 수 없습니다. 온프레미스 LLM에 의존하기 전에 업무 기준으로 데이터를 확인하고(Syntitan의 Ready for Raw Data), 준비 전후 결과를 같은 평가 세트에서 비교하며(Ready for Model), 어떤 업무를 여전히 외부 모델로 보낼지와 그 규칙을 정해야 합니다.