온디바이스 LLM 이슈: 성능·보안·배포 한계를 한눈에

온디바이스 LLM 이슈는 모델이 스마트폰과 PC에서 바로 돌아가면 생기는 성능·보안·배포 한계를 가리킵니다. 클라우드 왕복이 없어도 첫 응답은 빨라질 수 있지만 메모리와 전력이 바로 드러납니다. 짧은 컨텍스트에서는 토큰당 지연을 낮출 여지가 있습니다.

FP32 기준 70억 파라미터 LLM은 약 28GB 저장이 필요해 일반 단말 용량을 크게 초과합니다. 모바일 RAM은 OS와 공존해 고사양 기기에서도 가용 메모리가 보통 4GB 미만입니다. 이 글은 메모리 벽, 양자화 품질 저하, 온디바이스 보안, 앱·OS 배포를 순서대로 점검하고 실무 포인트를 남깁니다.

온디바이스 LLM이 주목받는 이유와 제약

클라우드 LLM은 서버에서 추론하므로 네트워크 왕복이 첫 토큰 전에 200~500ms를 더합니다. AR, 번역, 음성처럼 즉시 반응이 필요한 작업에서는 이 지연이 사용 경험을 끊습니다. 온디바이스는 짧은 컨텍스트에서 토큰당 20ms 이하가 가능하다고 정리됩니다. 다만 용량과 대역폭이 부족하면 그 이점은 단말 사양과 발열 한도에 묶입니다.

로컬 실행은 프롬프트를 서버로 보내지 않아 민감 입력을 단말 안에 둘 수 있습니다. 그런데 7B 모델을 FP32로 두면 저장만 약 28GB가 필요하고 175B급은 수백 GB에 이릅니다. 일반 단말이 감당하기 어려운 용량이라 경량화와 배포 계획 없이 주목 이유를 유지하기는 어렵습니다.

온디바이스 LLM의 핵심 이슈: 메모리·지연·전력

온디바이스 LLM의 핵심 병목은 연산량이 아니라 메모리 용량과 대역폭입니다. 서베이는 정적 용량과 동적 대역폭 한계를 온디바이스 추론의 핵심 도전으로 정리합니다. 연산 유닛이 있어도 가중치를 제때 읽지 못하면 디코드는 멈춥니다. 아래에서는 RAM과 NPU 제약, 배터리와 발열로 체감 지연이 어떻게 갈리는지를 구분해 나눕니다.

모바일 메모리 대역폭은 약 50~90GB/s 수준이고 데이터센터 GPU의 2~3TB/s보다 30~50배 낮습니다. 토큰마다 가중치 전체를 다시 읽어 연산 유닛이 대기하므로 디코드는 메모리 바운드가 됩니다. 모바일에서는 이 대기 시간이 곧 입력 지연으로 보입니다.

RAM·NPU 제약으로 생기는 추론 병목

모바일 RAM은 OS·다른 서비스와 공존해 고사양 기기에서도 가용 메모리가 보통 4GB 미만입니다. 7B를 FP32로 올리면 가중치만 약 28GB라 적재 자체가 실패합니다. NPU가 있어도 모델이 RAM에 들어오지 않으면 추론 파이프라인은 시작되지 않습니다. 공유 메모리 압박이 있으면 앱이 강제로 종료되기도 합니다.

대역폭이 50~90GB/s에 묶이면 디코드 단계에서 가중치 재적재가 반복됩니다. 연산 유닛은 대기하고 사용자는 토큰이 늦게 붙는 현상으로 병목을 체감합니다. KV 캐시까지 커지면 가용 4GB 안에서 컨텍스트를 길게 유지하기도 어렵습니다. 정적 용량이 부족하면 양자화 전에도 실패합니다.

배터리·발열과 실사용 체감 성능

폰에서 기본 온디바이스 추론 전력은 클라우드 오프로딩 대비 138%를 넘습니다. EnerInfer는 텍스트 폴리싱 시나리오에서 NPU와 메모리가 주원인이라고 보고합니다. 발열이 오르면 클록이 내려가 지연이 다시 늘어납니다. NPU 사용률이 높아도 메모리 트래픽이 크면 전력은 내려가지 않습니다.

연속 대화에서는 배터리 소모가 체감 성능을 가로챕니다. 짧은 문장은 토큰당 20ms 이하를 노릴 수 있어도 긴 생성은 전력과 열 때문에 속도가 떨어집니다. 스로틀링이 시작되면 사용자가 체감하는 품질은 벤치마크 수치와 어긋납니다. 실사용 점검은 벤치 한 방이 아니라 연속 세션에서 해야 합니다.

모델 경량화와 양자화가 만드는 품질 저하 문제

4비트 PTQ는 널리 쓰이는 타협점이지만 2비트는 급격한 성능 절벽을 유발합니다. ACL Findings 논문은 4비트를 최적 타협으로 두고 2비트를 재앙적 절벽으로 구분합니다. 단말에 넣기 위한 비트 축소는 품질 저하와 항상 같이 옵니다.

Llama3에서 앞 두 레이어만 2비트로 양자화하면 정확도가 100%에서 41.65%로 떨어집니다. 저자들은 2비트 손상이 초기 레이어에서 즉시 신호를 파괴하고 되돌리기도 어렵다고 실험했습니다. 용량을 줄여도 품질 저하가 남으면 온디바이스 LLM 이슈는 해결되지 않습니다. 경량화는 저장을 줄여도 초기 레이어 정밀도를 함부로 깎으면 안 됩니다.

프라이버시와 온디바이스 보안 리스크

로컬 실행은 입력을 서버로 보내지 않아 클라우드 대비 전송 노출은 줄어듭니다. 그렇다고 온디바이스 보안이 자동으로 확보되지는 않습니다. 모델 파일과 프롬프트, 로그가 단말에 남으면 유출 경로는 오히려 기기 쪽으로 옮겨갑니다. 클라우드 미전송만 내세우면 단말 측 위험을 놓칩니다.

앱 샌드박스 밖 백업, 루팅, 디버그 추출이 있으면 가중치와 대화 기록이 함께 복사될 수 있습니다. 온디바이스 LLM 이슈를 보안 관점에서 보면 저장 위치와 접근 권한이 핵심입니다. 전체 디스크 암호화 없이 캐시를 두면 분실 단말에서 복구가 쉬워집니다. 권한 목록과 파일 암호화 여부를 출시 체크리스트에 넣는 편이 안전합니다.

로컬 저장 모델·프롬프트 유출 경로

가중치 파일은 앱 데이터 디렉터리에 풀린 채 남는 경우가 많습니다. 프롬프트와 생성 결과는 로그, 클립보드, 크래시 리포트로도 새어 나갑니다. 업데이트 패키지에 양자화 가중치가 포함되면 배포 채널도 유출 면이 됩니다.

기기 백업과 공유 폴더를 열면 모델과 대화가 같이 이동합니다. 루팅이나 디버그 브리지가 켜져 있으면 추출은 더 단순해집니다. 온디바이스 보안은 전송을 끊는 것만으로 끝나지 않고 로컬 파일 권한과 삭제 주기, 백업 제외 설정까지 반드시 묶어서 봐야 합니다. 삭제 API가 있어도 잔여 캐시를 지우지 못하면 유출은 남습니다.

앱·OS별 배포·업데이트 운영 난제

앱 스토어와 OS 버전마다 바이너리 크기, NPU API, 백그라운드 제한이 다릅니다. 같은 양자화 모델을 iOS와 Android, Windows에 넣어도 로딩 경로와 가속 가능 여부가 갈립니다. 백그라운드 추론은 OS가 프로세스를 죽이면 중단됩니다.

델타 업데이트 없이 수 GB 가중치를 통째로 올리면 다운로드 실패와 이탈이 커집니다. 모델 버전과 토크나이저가 어긋나면 앱은 설치돼 있어도 추론이 깨집니다. 엣지 AI 배포는 스토어 심사, 롤백, GPU·NPU·최소 OS 호환 표를 운영 범위에 넣어야 합니다. A/B 채널 없이 전량 배포하면 불량 양자화 한 건이 전 사용자를 멈춥니다.

온디바이스 LLM 이슈 점검과 실무 정리

온디바이스 LLM 이슈는 용량, 대역폭, 전력, 양자화 품질, 로컬 보안, 배포가 겹친 문제입니다. 실무에서는 모델 크기만 줄이지 말고 가용 메모리와 업데이트 경로를 먼저 적습니다. 보안은 로컬 저장 암호화와 백업 제외를 기본값으로 둡니다.

7B를 FP32로 두면 약 28GB가 필요하고 고사양 폰도 가용 RAM은 보통 4GB 미만입니다. 4비트 PTQ는 타협으로 쓰이지만 앞 레이어 2비트는 정확도를 41.65%까지 떨어뜨릴 수 있습니다. 배포 전에는 전력 138% 이상 구간과 유출 경로를 점검하는 것이 안전합니다. 표의 수치를 출시 기준으로 옮기고 미달 기기에는 클라우드 폴백을 둡니다.

항목	한계 수치	실무 함의
7B FP32 저장	약 28GB	일반 단말 용량 초과
모바일 가용 RAM	보통 4GB 미만	적재 실패·강제 종료
메모리 대역폭	50~90GB/s, GPU 대비 30~50배 낮음	디코드가 메모리 바운드
양자화	4비트 타협, 2비트 절벽	Llama3 앞층 2비트 시 41.65%
추론 전력	클라우드 대비 138% 이상	NPU·메모리가 주원인