카카오톡 AI 에이전트를 위한 온디바이스 모델 최적화 및 적용

kakao tech·if(kakao)25 2025·10개월 전·

#ios#model-optimization#llm#quantization#on-device-ai#mlx#core-ml

AI 요약

카카오톡 AI 에이전트용 3B 미만 Kanana 모델을 iPhone에서 직접 돌리려는 목표에서 출발한다. 서버용으로 양자화된 모델을 온디바이스로 옮기는 변환 비용 문제를 MLX·Core ML 비교와 자체 tensor 조립 파이프라인으로 풀어가는 과정을 따라간다.

핵심 포인트

개인 데이터를 네트워크로 보내지 않고 연결 상태에 의존하지 않으려 온디바이스 실행을 택하되, 배터리·발열·공유 메모리 제약과 학습/실행 환경 차이를 양자화 전략으로 대응
llama.cpp·ExecuTorch·MLX를 비교해 Apple Silicon에 최적화된 MLX를 선택하고 Swift Transformers·MLX-LM으로 초기 경로를 단순화했지만, 서버용 최신 양자화 조합 실험엔 별도 변환 계층이 필요
기존 GPTQ→MLX 변환이 계산한 scale·zero point를 버리고 FP로 되돌린 뒤 재양자화하던 문제를, SafeTensors header·binary를 직접 읽고 framework별 tensor 이름·transpose·zero point 표현을 변환해 재양자화 없이 layer별 mixed precision까지 실험
Core ML·ANEMLL로 Apple Neural Engine에서 실행하고 ML State로 KV cache 앱 왕복을 줄였지만 약 1B 모델 생성 속도는 MLX GPU가 약 2배 빨라, 단발·저지연은 MLX, CPU·GPU를 비워야 하는 지속 반복은 Core ML로 선택

왜 읽나LLM을 iOS 온디바이스로 올리려는 ML 엔지니어에게 프레임워크 선택 기준, 재양자화를 없앤 tensor 변환, ANE의 KV cache 병목까지 구체적 수치와 함께 정리한 실전 최적화기.

챕터별 상세

010:10 – 3:00

서버 LLM을 iPhone 안으로 옮기는 이유

서버 호출 방식은 개인 데이터를 네트워크로 보내야 하고 연결 상태에도 의존하지만, 모바일 성능 향상으로 작은 언어모델을 기기 안에서 직접 실행할 가능성이 커졌다. 배터리·발열·공유 메모리 제약과 학습 환경과 실행 환경이 다른 변환 비용을 고려해, 3B 미만 Kanana 모델을 적절히 양자화하는 전략을 세웠다.

llama.cpp, ExecuTorch, MLX 등 여러 실행기를 비교한 결과 Apple Silicon에 최적화된 MLX가 llama.cpp보다 빠르고 사용성도 좋았다. Swift Transformers와 함께 Hugging Face 형식을 다루고 MLX-LM으로 변환·양자화할 수 있어 초기 적용 경로가 단순했다. 다만 서버용 최신 양자화 조합까지 실험하려면 별도 변환 계층이 필요했다.

기존 GPTQ→MLX 변환은 계산한 scale과 zero point를 버리고 FP로 되돌린 뒤 다시 양자화해 품질과 실험 유연성을 잃었다. SafeTensors의 단순한 header·binary 구조를 직접 읽고, framework마다 다른 tensor 이름·transpose·zero point/bias 표현을 변환한다. Tensor를 분해·가공·재조립해 layer별 bit와 양자화 방식이 다른 mixed precision 조합까지 시험했다.

Core ML과 ANEMLL을 이용해 Apple Neural Engine에서 LLM을 실행하고 ML State로 KV cache의 앱 왕복 복사를 줄였다. 그래도 약 1B 모델의 생성 속도는 MLX GPU가 Core ML보다 약 두 배 빨랐고 최초 compile 비용도 있었다. 단발·저지연 작업은 MLX, CPU·GPU를 비워야 하는 지속 반복 작업은 Core ML을 고려하는 식으로 workload에 따라 선택한다.