로컬 AI의 저비용 운용 방법에 대하여

로컬 LLM(Large Language Model)을 구동하려고 할 때, AWS에서 운용할 기회가 있다.

AWS의 경우 GPU 인스턴스를 사용했을 때의 요금이 비싸다. 반면 GPU를 사용하지 않으면 LLM의 추론(Inference)이나 프리필(Prefill)이 느려진다.

이번에는 그 딜레마를 어떻게 개선할 것인가라는 관점에서 글을 쓴다.

로컬 LLM이란 말 그대로 로컬 환경에서 구동할 수 있는 AI이다. 일반적인 ChatGPT나 Claude Code 등과 비교하여, 외부에 정보를 두지 않고 구동할 수 있다는 장점이 있다. 하지만 일반적으로 클라우드형 유명 모델보다 성능이 떨어지거나, 구동을 위한 환경 구축이 힘들다는 단점도 알려져 있다.

그럼에도 불구하고 최근의 모델 진보 덕분에, 2026년에 등장할 AI는 상당히 고성능이 될 것이다. 예를 들어 Qwen3.6의 오픈 웨이트(Open-weight) 모델은 Claude Sonnet 4.5 상당의 성능이 있다고 알려져 있다. Claude Sonnet 4.5는 2025년 9월 30일에 발표된 클라우드형 모델이다. 조금 전 Claude code의 표준 모델 상당의 성능이 현재는 로컬에서 구동 가능한 상태이다.

이는 바꿔 말하면, 로컬 AI의 과제였던 성능 면의 격차가 메워지고 있음을 나타낸다. 실제로 나도 반년 전에 로컬 AI를 구동해 본 적이 있지만, 현재의 모델과 비교하면 명백히 도구 호출(Tool calling)의 정밀도가 떨어지는 등 실용적인 면에서 과제가 있었다. 지금은 그러한 초보적인 결함이 로컬에서도 상당히 진정되었고, 안정적으로 동작하는 모델이 늘어나고 있다.

그렇기 때문에 로컬 LLM을 도입할 가치가 점차 나오고 있는 단계가 되었다. 이번에는 로컬 LLM을 운용할 때의 PC 선정 및 모델 선택 방법을 중심으로 해설한다.

로컬 LLM 모델은 다수 존재하며, 어떤 것을 결정해야 할지 판단할 필요가 있다. 기본적으로는 최신 모델을 선택하는 것이 철칙이지만, 이번에는 보다 상세하게 해설을 진행하겠다.

기본적으로 LLM이 어느 정도의 성능을 필요로 하는지를 결정하고, 그 다음에 모델 사이즈와 대응하는 도구 호출 기능을 결정함으로써 채택 모델을 결정한다.

최근의 로컬 LLM은 ChatBOT과 같은 대화형 운용의 경우, 대체로 어떤 모델이든 돌아갈 정도로 성숙해 있다.

반면, AI 코딩과 같은 에이전트(Agent) 운용을 생각하면 적성과 부적성이 여전히 명확하게 갈린다.

예를 들어, AI에게 파일을 읽고 쓰게 할 때, AI가 생성하는 JSON 포맷이 올바르지 않아 앱 측에서 에러를 발생시키는 빈도가 높은 모델이 존재한다. 또한, 순수하게 코딩을 시킬 때라 하더라도 올바르게 코드를 생성하지 못하는 등의 과제가 있다.

LLM의 성능을 조사할 때는 벤치마크(Benchmark) 결과를 비교하는 것이 일반적이라고 알려져 있다. 하지만 일부 AI 모델에서는 벤치마크에 최적화하는 방식으로 모델이 우수하다고 어필하는 케이스가 산견된다. 이 케이스의 경우, 벤치마크 성능이 실제 운용에서 발휘되지 않을 수 있다. 이 때문에 AI 모델을 구동할 경우, 실제로 직접 만져보며 구동을 확인하는 것이 중요하다.

AI 모델의 동작 확인이라면, Ollama나 LMStudio 등의 간단한 방법으로 모델을 띄워 구동하면 된다. 현재는 GUI 상에서 최신 모델을 간단히 테스트할 수 있다. 따라서 우선은 직접 구동해 보는 것을 추천한다.

똑똑한 AI일수록 모델 사이즈가 커지는 경향이 있다. 실제로 로컬 LLM의 상위 모델을 확인하면, 100B(1,000억) 파라미터 이상의 모델이 많다. 일반적으로 10B당 무압축 시 약 20GB의 파라미터를 가진다. 즉, 100B 모델을 무압축으로 구동할 경우 약 200GB의 메모리가 필요하다. 시판되는 PC에서는 이 정도 사이즈의 메모리를 탑재하는 것이 쉽지 않다. 따라서 모델 사이즈의 상한을 사전에 파악하는 것이 중요하다.

또한, 양자화(Quantization) 기술을 활용하는 것도 중요하다. 일반적으로 추론의 경우, 4비트 양자화를 해도 오리지널과 비교하여 추론 정밀도에 차이가 거의 나지 않는다고 알려져 있다. 4비트 양자화에서는 무압축(16비트)과 비교하여 1/41/3 정도의 사이즈가 된다. 즉, 10B당 6GB7GB 정도로 작게 만들 수 있다. 나아가 일부 GPU에서는 4비트나 8비트 정밀도로 직접 계산할 수 있는 것도 있어, 대응하는 것을 사용함으로써 양자화 모델의 계산 속도를 빠르게 할 수 있다.

또한, 액티브 파라미터(Active Parameter)가 전체의 일부가 되는 케이스도 있다. 모델이 크면 추론이 느려지기 때문에, 파라미터의 일부만을 적절히 활성화하며 구동하는 MoE(Mixture of Experts) 아키텍처를 채택하는 모델이 있다. 이 모델의 경우, 모델 사이즈가 커도 어느 정도 고속으로 동작하며, 액티브 파라미터의 사이즈에 따라 CPU 추론도 가능해진다.

AI에 따라 이미지를 읽어오는 기능이나 도구 호출 (Tool Calling) 등 특정 기능을 갖춘 경우가 있다. 따라서 "사전에 어떤 기능을 사용할 것인가"라는 관점에서 모델을 필터링하는 것이 중요하다. 최근 트렌드에서 중요한 기능을 아래에 나타낸다.

에이전트 (Agent) 기능을 사용할 때 필수적이다. 도구 호출 (Tool Calling) 기능에 대응하면, Cline 등의 에이전트 소프트웨어를 통해 자율적으로 PC 내부를 조작할 수 있게 된다. 예를 들어 파일의 생성 및 읽기, 커맨드 실행, 대응하는 경우 브라우저 표시 등도 가능하다. 최근 모델들은 도구 호출에 대응하는 경우가 많지만, 드물게 대응하지 않는 경우가 있으므로 주의해야 한다.

이미지나 음성에 대해 AI를 구동할 때 필요하다. 예를 들어 휴머노이드 로봇을 만드는 경우에는 음성 인식이나 카메라 이미지로 정보를 입력하여 대화를 나누는 용도로 이 기능을 사용한다. 모델에 따라 음성 혹은 이미지만에 대응하는 경우도 있다. 웹 개발 등에서 UI 스크린샷을 LLM에 전달하여 외관 개선에 사용하는 등의 용도로도 쓸 수 있다. 대응 여부는 모델에 달려 있다. 이러한 기능들을 생략하고 코딩 등 특정 성능에 주력하는 모델도 있으므로, 필요에 따라 취사선택하는 것도 필요하다.

LLM을 구동하기 위한 PC 패턴으로는 다음과 같은 후보가 있다.

노트북 (개발 단말기 상에서 완결)

서버 (자체적으로 기반을 보유)

EC2 인스턴스 (인프라 관리가 편하지만 GPU 인스턴스는 고가)

여기서 중요해지는 것은 모델 사이즈이다. 간단한 작업이라면 현재 7B 등의 소형 모델로 구동하는 것이 가능하다. 반면 어느 정도 사이즈가 되면 서버나 EC2 인스턴스 상에서 구동하게 된다. 극단적으로 말해 H100 등의 고성능 GPU가 여러 개 있다면 큰 모델도 구동할 수 있다. 하지만 상당히 고가이다. 예로, EC2 인스턴스에서는 1 GPU 인스턴스를 한 달 동안 구동하는 것만으로 10만 엔 이상이 된다. 게다가 온디맨드 (On-demand)로 구동할 수 없을 정도로 인기 있는 GPU 인스턴스도 많아, 손쉽게 시도하기 어렵다.

따라서 용도나 모델에 따라 CPU 추론 (CPU Inference)도 검토하는 것을 추천한다. 앞서 기술한 MoE 아키텍처에서 액티브 파라미터가 수 B 정도라면, CPU 추론으로도 어느 정도 속도를 낼 수 있다.

다만 CPU 추론의 경우, "프롬프트 $\rightarrow$ 토큰 변환 (Prefill)"에서 과제가 있다.

LLM의 처리에는 Prefill과 디코드 (Decode, 토큰 $\rightarrow$ 출력 워드 변환)라는 두 가지 프로세스가 있는데, 일반적으로 Prefill이 Decode보다 병렬도가 높은 계산이다. 채팅이라면 입력한 문장을 Prefill 하기만 하면 되지만, 에이전트의 경우 에이전트 동작을 위한 프롬프트가 채팅 문장에 더해져 포함되어 있다. 그 결과, Prefill에 소요되는 토큰 수가 많아진다. 예를 들어 입력은 수만 토큰이고 출력은 수백 토큰의 텍스트가 되는 경우가 있다. GPU를 사용함으로써 이 Prefill을 가속화할 수 있지만, CPU에서는 프롬프트를 넣은 후 Prefill에 시간이 걸리기 때문에 명확한 응답 저하를 느낄 수 있다.

그 결과로, GPU가 없으면 에이전트 운용에 관해서는 현재 어려운 상태이다.

토큰 생성은 토크나이저 (Tokenizer)에 의해 결정된다. 토큰을 생성할 때는 가급적 효율적으로 문자를 토큰으로 만드는 설계로 한다. 이때 자주 사용되는 언어로는 영어와 중국어를 들 수 있다. 따라서 많은 모델에서는 영어와 중국어 같은 언어에서 토큰 생성을 최소한으로 억제하도록 토크나이저를 설계한다.

하지만 많은 일본인은 일본어를 사용하기 때문에, 실제 상황에서는 일본어의 토큰 효율이 중요해진다. 토크나이저는 사전형 부호화 (Dictionary Coding) 등과 마찬가지로, 1토큰에 자주 나오는 문자열을 할당하는 방식이다. 예를 들어 "you", "because"와 같이 자주 나오는 문자를 여러 문자로 1토큰으로서 취급할 수 있다. 다만 어휘 사전 크기가 고정되어 있기 때문에 모든 단어를 할당할 수는 없다. 따라서 영어와 일본어 모두의 효율을 동시에 높이는 것은 어렵다.

결과적으로 일본어는 세계적으로 보면 마이너한 언어이기 때문에 부호 효율이 나빠지는 경향이 있다. 부호화 효율을 좋게 하기 위해, 일본어에 최적화된 토크나이저를 사용하는 모델을 채택하면 앱의 실행 효율이 좋아지는 경우가 있다.

구체적인 예로, 일반적인 토크나이저를 가진 Gemma4와 일본어에 최적화된 토크나이저를 가진 LLM-JP4의 토큰 생성 수를 비교했다.

토크나이저의 일본어 효율에 대해서는, 같은 문장을 실제 토크나이저로 분해하게 함으로써 비교할 수 있다. 토큰이 적을수록 효율이 좋다.

결과적으로는 LLM-JP4가 Gemma4보다 더 좋은 결과를 나타냈다. 활성 파라미터 (Active Parameters)의 차이도 있지만, 토큰 생성 효율이 좋기 때문에 결과적인 일본어 생성 속도는 토크나이저 (Tokenizer)의 최적화에 따라 변화한다는 것을 알 수 있다.

이 때문에 일본어 토큰 생성 효율에 대해서는 LLM-JP4가 더 높으며, 동일한 일본어를 더 적은 토큰으로 표현할 수 있다.

다만, 일본어 특화형 LLM은 현재 발전 단계에 있으며, 다른 모델보다 순수한 실행 능력이 떨어지는 경우가 많다. 예를 들어 JP-LLM4는 GPT-4 세대 상당의 성능이지만, Gemma4라면 GPT-5 세대의 성능이 된다.

이러한 점을 고려하면, 현시점에서는 아직 일본어 특화 LLM에 대해 성능이 부족하다는 느낌을 부정할 수 없으나, 토큰 생성 효율 또한 향후 모델 선정에 영향을 미칠 것으로 생각된다.

최근 등장한 Qwen3.6이나 Gemma4라면 에이전트 (Agent) 성능이 상당히 개선되어, 로컬 LLM으로는 코딩이 어렵다는 상황이 바뀌기 시작했다.

1년 전의 모델로는 예를 들어 Llama4가 있었다. 이 모델은 100B 클래스의 크기로 실행 환경에 대한 요구 사항도 높았다. 하지만 실제로 코딩을 시키려고 하면, 파일 읽기/쓰기 명령을 올바르게 출력하지 못하고 에러를 내는 등 에이전트 성능이 부족하여 실용적이지 않았다.

그 후 GPT-OSS가 등장하여 코딩 작업을 자동으로 수행할 수 있는 에이전트 성능을 가진 모델이 나왔으나, 120B의 파라미터 규모였기 때문에 일반적인 로컬 환경에서 구동하기 어려운 상태가 지속되었다.

GPT-OSS 등장 이후 반년 이상 이 상태가 지속되었으나, Gemma4와 Qwen3.6의 등장으로 이 상황이 크게 바뀌었다. 양자의 큰 특징은 에이전트 성능에 중요한 JSON 오브젝트 (JSON Object)의 정확한 생성 정밀도가 높다는 점이다. 포맷 에러 (Format Error)나 명령 실행 형식 에러의 빈도가 격감했다. 또한, 기존 로컬 모델에서 자주 보이던 사고 루프 (Thinking Loop, 사고 토큰을 무제한으로 소비하며 영원히 답이 나오지 않는 현상)도 거의 보이지 않는다. 이 때문에 최근에는 로컬 환경에서 코딩 작업이 현실적으로 가능해지기 시작했다고 할 수 있다.

이번에는 로컬 LLM을 구동할 때 필요한 모델 선정 및 머신 스펙 (Machine Spec)에 대한 사고방식을 정리했다. 단적으로 표현하면 다음과 같이 요약할 수 있다.

・새로운 모델일수록 똑똑한 경향이 있다

・LLM의 벤치마크 (Benchmark)는 결과 수치가 잘 나오도록 최적화되는 경우가 많으므로, 실제 사용감을 확인하는 것이 중요하다

・에이전트로 운용할 경우, 도구 호출 (Tool Call)과 GPU 탑재 머신이 필수적이다

・챗봇 (Chatbot)이라면 CPU 인스턴스 (Instance)로도 어느 정도 사용 가능하다

・용도에 따라서는 일본어 특화 토크나이저를 탑재한 모델이 유효하다

・최신 LLM 모델이라면 고가의 머신이 아니더라도 에이전트 운용이 어느 정도 가능하다

앞으로도 새로운 모델의 등장에 따라 로컬에서 할 수 있는 일은 늘어날 전망이다. 이 지식을 참고하여 향후 로컬 AI 도입에 도움이 되기를 바란다.