구형 PC나 현장용 태블릿, TV 박스급 장비에 로컬 LLM을 넣으려 할 때 가장 먼저 나오는 질문은 대개 “몇 B 모델까지 돌아가는가”다. 그러나 서비스 의사결정에서 더 중요한 질문은 따로 있다. 이 장비에서 사용자가 기다릴 만한 시간 안에, 정해진 업무를 틀리지 않고, 운영 가능한 방식으로 답할 수 있는가다.
소형 장비에서 큰 모델을 실행한 공개 실험은 가능성의 범위를 넓혔다. 약 1GB 수준의 사용 가능 메모리를 가진 장비에서도 양자화 모델을 실행하고, 일부 MoE(Mixture-of-Experts) 모델은 필요한 전문가 가중치를 저장장치에서 읽어 오는 방식으로 구동한 사례가 있다. 다만 이 결과를 곧바로 “우리 장비에서도 16B급 모델을 서비스할 수 있다”는 결론으로 옮기면 안 된다.
그 실험은 특정 칩, 운영체제, 수정된 추론 런타임, 모델 형식, 저장장치 조건에서 측정된 값이다. 로컬 LLM 도입의 목표는 장비 한계까지 큰 모델을 넣는 일이 아니라, 업무 요구를 만족하는 가장 작은 실행 구성을 찾는 일이다.
먼저 정할 것은 모델이 아니라 처리 위치다
로컬 실행, 서버 실행, 혼합 실행은 서로 다른 장단점을 가진 기술 선택지라기보다 업무 흐름의 경계를 어떻게 나눌지에 대한 선택이다.
로컬 실행을 먼저 검토할 만한 경우는 입력과 결과가 장비 안에 머물러야 하는 요구가 분명할 때다. 예를 들어 네트워크 연결이 불안정한 현장 장비, 사용자가 입력한 내용을 외부 전송 없이 처리해야 하는 업무, 짧은 명령을 즉시 해석해야 하는 인터페이스가 여기에 해당할 수 있다. 이 경우에도 “로컬이므로 안전하다”라고 결론내릴 수는 없다. 모델 파일, 로그, 프롬프트 기록, 운영체제 권한, 장비 분실 시 데이터 노출을 각각 확인해야 한다.
서버 실행이 더 맞는 경우도 많다. 긴 문서 이해, 복잡한 추론, 빈번한 모델 교체, 중앙에서의 품질 관리가 핵심이면 장비마다 모델을 배포하고 상태를 관리하는 비용이 더 커질 수 있다. 특히 구형 장비의 저장장치 읽기 속도나 메모리 여유가 작다면, 모델을 실행할 수 있다는 사실과 사용자가 쓸 수 있는 응답 시간을 제공한다는 사실은 크게 다르다.
혼합 방식은 이 둘 사이에서 업무를 나눈다. 장비에서는 명령 분류, 정형 입력 추출, 짧은 안내처럼 작은 모델로 처리 가능한 일을 맡기고, 더 긴 생성이나 복잡한 판단은 별도 처리 경로로 보낸다. 다만 혼합 방식은 설계가 복잡해진다. 어떤 요청을 어디로 보낼지, 연결이 끊기면 무엇을 보여 줄지, 두 경로의 결과가 다를 때 어느 쪽을 채택할지를 제품 요구사항으로 먼저 정해야 한다.
“실행 가능” 판정에 토큰 속도 하나만 쓰면 안 된다
초당 생성 토큰 수는 유용한 측정값이지만, 도입 판단의 단독 기준은 아니다. 사용자 체감은 첫 응답이 나오기까지의 시간, 답변이 끝날 때까지의 시간, 입력 길이가 길어졌을 때의 변화에 따라 달라진다.
특히 메모리보다 큰 모델을 저장장치에서 읽어 오는 방식은 모델 적재를 가능하게 할 수 있다. MoE 모델은 토큰마다 일부 전문가만 활성화한다는 성질을 이용해, 필요한 전문가를 메모리에 유지하고 나머지를 필요할 때 불러오는 접근도 가능하다. 메모리 제약을 완화할 수 있는 방법이지만, 저장장치 또는 장치 간 데이터 이동 대역폭이 지연시간을 좌우할 수 있다. 메모리 부족을 해결했다고 해서 응답 지연 문제까지 해결한 것은 아니다.
따라서 PoC에서 다음 값을 따로 기록하는 편이 낫다.
- 첫 토큰이 표시될 때까지 걸린 시간
- 짧은 답변과 긴 답변에서의 생성 속도
- 대표 입력 길이에서의 결과 품질과 실패 유형
- 모델 실행 중 메모리 사용량과 다른 앱의 영향
- 저장장치에서 가중치를 읽는 구간에서 생기는 멈춤 또는 속도 변동
- 장비가 발열, 배터리, 절전 정책 때문에 성능을 유지하지 못하는 상황
여기서 중요한 것은 최고 성능이 아니라 하한선이다. 회의실의 한 대 장비에서 빠르게 작동하는 모델보다, 배포 대상 장비에서 반복 실행해도 업무 흐름을 끊지 않는 모델이 서비스 후보가 된다.
업무 정확도는 범용 벤치마크보다 실패 비용으로 평가한다
작은 모델은 큰 모델보다 덜 정확할 수 있고, 양자화나 어휘 출력 축소 같은 메모리 절감 기법은 결과 품질에 영향을 줄 수 있다. 그렇다고 모델 파라미터 수만으로 업무 적합성을 정할 수는 없다.
먼저 LLM이 맡을 일을 세 종류로 나눠 보자.
첫째, 결과가 틀려도 사용자가 쉽게 고칠 수 있는 보조 업무다. 문장 초안, 메뉴 탐색 안내, 음성 명령의 후보 제시처럼 사용자가 결과를 확인하는 흐름이라면 작은 모델부터 시험할 여지가 있다.
둘째, 형식은 정해져 있지만 입력 표현이 다양한 업무다. 현장 메모를 항목으로 정리하거나, 짧은 문의를 미리 정한 분류로 나누는 작업이 여기에 가깝다. 이 경우에는 답변이 그럴듯한지보다 필요한 항목을 빠뜨리지 않는지, 허용되지 않은 분류를 만드는지, 모호한 입력에서 보류하는지를 평가해야 한다.
셋째, 틀린 결과가 바로 실행이나 의사결정으로 이어지는 업무다. 이 범주에서는 모델 크기보다 검토 절차와 실행 권한 분리가 우선이다. 로컬 LLM이 답을 만들더라도, 그 답을 누가 확인하고 어떤 조건에서 후속 시스템이 움직이는지까지 정하지 않으면 모델 선택 실험만으로 서비스 준비 여부를 판단할 수 없다.
평가 세트도 제품 데모용 질문이 아니라 실제 입력 형태를 반영해야 한다. 짧은 명령, 오탈자, 장비가 인식하기 어려운 표현, 입력이 비어 있는 경우, 답하지 말아야 하는 요청을 함께 넣어야 모델의 경계를 볼 수 있다.
검증은 작은 모델, 실제 장비, 좁은 업무 순서로 시작한다
처음부터 메모리 한계까지 큰 모델을 올리는 방식은 기술 시연에는 적합할 수 있어도 제품 탐색에는 비효율적이다. 다음 순서가 낫다.
-
업무 하나를 고른다.
“사내 지식 검색”처럼 넓게 잡지 말고, 사용자가 장비에서 한 번에 끝내려는 행동을 정한다. 예를 들어 짧은 점검 기록을 정형 항목으로 바꾸는 일, 제한된 기능의 음성 명령을 해석하는 일처럼 결과와 실패를 확인할 수 있어야 한다. -
최소 모델로 정확도 기준을 확인한다.
먼저 작은 모델이 정한 입력과 출력 형식을 지키는지 본다. 모델이 약하면 큰 모델로 바꾸기 전에 프롬프트, 출력 제약, 입력 전처리, 사용자 확인 단계를 바꿨을 때 무엇이 개선되는지도 구분해야 한다. -
배포 대상 장비에서 측정한다.
개발용 노트북 결과로 판단하지 않는다. 실제 구형 PC, 모바일, 엣지 장비에서 메모리 여유, 첫 응답 시간, 반복 실행 시 변동을 확인한다. 장비별 칩 명령어 지원과 운영체제 제약에 따라 같은 모델 파일과 런타임이 그대로 작동하지 않을 수 있다. -
그다음에만 양자화와 오프로딩을 검토한다.
모델이 메모리에 들어가지 않을 때 양자화, 가중치 스트리밍, MoE 전문가 오프로딩을 후보로 둔다. 이들은 배포 가능한 모델 범위를 넓힐 수 있지만, 런타임 호환성, 저장장치 대역폭, 응답 지연의 변동을 함께 확인해야 한다. -
중단 기준을 정한다.
정확도가 기준에 못 미치거나, 응답 시간이 제품 흐름을 계속 끊거나, 장비별 관리 부담이 과도하면 로컬 대형 모델에 더 투자하지 않는다는 기준도 필요하다. 이때는 더 작은 로컬 모델로 역할을 축소하거나 서버 또는 혼합 방식으로 전환하는 편이 합리적일 수 있다.
큰 MoE 모델은 메모리 해법이지 자동적인 제품 해법은 아니다
MoE는 모든 파라미터를 매번 같은 방식으로 쓰지 않기 때문에, 제한된 메모리에서 모델을 다루는 방법으로 주목받는다. 필요한 전문가만 가져오는 방식과 압축은 메모리 요구량과 이동해야 할 데이터량을 줄이는 데 도움을 줄 수 있다.
그러나 전문가를 필요할 때 가져오는 구조에서는 데이터 이동이 새 병목이 된다. 메모리가 작은 장비에서 실행에 성공했더라도, 저장장치가 느리거나 접근 시간이 들쭉날쭉하면 대화형 제품에 필요한 응답성을 보장하기 어렵다. 그래서 MoE 후보를 평가할 때는 활성 전문가 수나 전체 파라미터 수보다 다음을 확인해야 한다.
- 요청마다 어떤 가중치를 얼마나 자주 읽어 와야 하는가
- 저장장치 읽기 속도와 지연 변동이 사용자 응답에 어떤 영향을 주는가
- 자주 쓰는 입력에서 같은 전문가가 반복 활성화되는가
- 모델 런타임이 해당 양자화 형식과 오프로딩 방식을 지원하는가
- 장비 재시작, 모델 업데이트, 저장공간 부족 상황에서 복구할 수 있는가
이 질문에 답하지 못한다면, 큰 MoE를 넣는 일은 제품 기능 개발보다 런타임 실험에 가까워진다.
CTO와 개발 리더가 PoC 승인 전에 합의할 질문
로컬 LLM 검증은 “이 모델을 돌려 보자”로 시작하기 쉽다. 승인 전에 아래 질문의 답을 한 장으로 합의하면 실험의 범위가 크게 흐트러지지 않는다.
- 이 기능은 연결이 끊겨도 작동해야 하는가, 아니면 외부 처리 경로가 있어도 되는가?
- 장비 밖으로 나가면 안 되는 입력과 결과는 무엇인가?
- 사용자가 기다릴 수 있는 시간은 어느 업무 단계에서 얼마나 다른가?
- 잘못된 응답은 사용자가 수정하는가, 후속 시스템이 실행하는가?
- 배포 대상 장비 중 가장 낮은 사양은 무엇이며, 그 장비에서 통과해야 하는 기준은 무엇인가?
- 모델 파일, 추론 런타임, 운영체제 업데이트를 누가 어떤 주기로 관리하는가?
- 모델을 키우지 않고도 업무를 좁히거나 출력 형식을 제한하면 목표를 달성할 수 있는가?
첫 PoC의 목표는 “최대 몇 B를 실행했는가”가 아니라, 해당 업무를 로컬에서 맡길 수 있는지와 맡길 수 없다면 어느 지점에서 서버 또는 혼합 구조로 넘겨야 하는지를 확인하는 데 두는 편이 좋다. 그 기준이 생긴 뒤에야 모델 크기와 최적화 기법이 비용 대비 의미를 갖는다.
