로컬 AI 에이전트 런타임, 어떤 걸 골라야 하나

로컬에서 AI 에이전트를 돌릴 때 런타임은 사실상 세 갈래로 정리된다. 혼자 빠르게 실험하려면 Ollama, 기기에 깊게 심으려면 llama.cpp, 여러 에이전트를 동시에 굴리는 프로덕션이라면 vLLM이 기본값이고, 나머지 고민은 대부분 이 세 갈래 위에서 갈린다.

한 줄 요약: 런타임은 지연시간·메모리·도구 호출 방식 세 축으로 갈린다. 개인 실험은 Ollama, 엣지·온디바이스는 llama.cpp, 프로덕션 멀티에이전트는 vLLM.

먼저 '런타임'이라는 말부터 풀고 가자. 런타임은 모델을 실제로 실행해 주는 프로그램이다. 모델 파일(가중치)은 그 자체로는 그냥 숫자 덩어리라서, 입력을 받아 토큰을 뱉게 만들려면 이 가중치를 메모리에 올리고 계산을 돌려 줄 엔진이 필요하다. 자동차로 치면 모델은 '설계도', 런타임은 그 설계도로 실제 굴러가는 '엔진'이다. 같은 모델이라도 어떤 엔진에 얹느냐에 따라 속도, 메모리 사용량, 동시에 처리할 수 있는 요청 수가 크게 달라진다.

우리 ai-server에서 로컬 LLM은 얼마나 빠른가?#

Hax 자체 ai-server(qwen3.6-35b-a3b 로컬 서빙)에서 직접 측정한 생성 속도입니다(measured, 2026-07-04, 3회 중앙값).

왜 굳이 로컬에서 돌리나?#

클라우드 API를 부르면 편하지만, 에이전트는 한 번 답하고 끝나는 게 아니라 도구를 부르고 그 결과를 다시 모델에 넣는 왕복을 한 작업에서 수십 번 반복한다. 이 왕복마다 네트워크 지연이 붙으면 체감 속도가 크게 느려진다. 로컬은 이 왕복이 기기 안에서 끝나기 때문에 도구 호출 지연이 짧고, 민감한 컨텍스트(사내 문서, 개인정보)가 기기를 떠나지 않으며, 토큰 비용이 사실상 0에 수렴한다.

대신 공짜는 아니다. 클라우드가 대신 짊어지던 모델 크기와 VRAM 제약이 그대로 내 몫이 된다. 예를 들어 7~8B 모델은 4bit로 양자화하면 대략 5~6GB VRAM이 필요하고, 파라미터가 커질수록 이 요구량은 거의 선형으로 늘어난다. "그럼 큰 모델은 못 돌리나?" 싶겠지만, 양자화와 CPU 오프로딩으로 어느 정도는 밀어 넣을 수 있다. 다만 그만큼 속도를 내주는 트레이드오프가 생긴다. 이 균형점이 런타임 선택의 밑바탕이다.

그래서 뭘 골라야 하나?#

결정은 "무엇을 하려는가"에서 출발한다. 아래 흐름이 세 갈래를 한눈에 정리해 준다.

• Ollama — 설치 즉시 사용. ollama run 한 줄이면 모델을 내려받아 바로 대화한다. 모델 교체와 관리가 가장 쉽다. 대신 동시 요청 처리(동시성)와 세밀한 튜닝에는 한계가 있어, 여러 에이전트를 무겁게 굴리면 병목이 온다. 혼자 빠르게 만져 볼 때 최적.
• llama.cpp — 경량하고 유연. C/C++로 짜여 CPU만으로도 돌고, GPU 일부 오프로딩도 유연하다. 라즈베리파이나 노트북 같은 기기에 깊게 박아 넣기 좋다. 대신 서버와 도구 호출을 직접 배선해야 해서 손이 조금 더 간다. 엣지·온디바이스에 최적.
• vLLM — 높은 처리량. PagedAttention과 연속 배칭(continuous batching)으로 여러 요청을 한 번에 밀어 처리량이 크다. 대신 VRAM 요구가 크고 셋업이 무겁다. 여러 에이전트를 동시에 굴리는 프로덕션에 최적.

지연시간은 실제로 얼마나 줄어드나?#

숫자로 감을 잡아 보자. 클라우드 왕복은 도구 호출 한 번에 흔히 200~800ms의 네트워크 지연이 붙는다. 에이전트가 한 작업에서 도구를 10번 부르면 그것만으로 2~8초가 순수 대기 시간으로 날아간다. 로컬은 이 네트워크 구간이 사라져 왕복이 수 ms 수준으로 떨어진다.

물론 로컬이 무조건 빠른 것은 아니다. 로컬은 모델 추론 자체(토큰 생성)가 하드웨어에 따라 느릴 수 있다. 그래서 "지연이 준다"는 말은 네트워크 왕복 비용에 한정한 이야기다. 흔한 오해가 여기서 갈린다. 로컬은 무조건 빠른 게 아니라, 도구 호출 왕복이 잦은 에이전트 워크로드에서 특히 유리하다.

벤치마크는 어디까지 믿어야 하나?#

런타임 비교 글이나 트윗의 숫자는 측정 조건이 제각각이라 그대로 믿기 어렵다. 의미 있는 비교의 최소 조건은 같은 입력, 같은 시드, 같은 측정 지점이다. 특히 네 가지를 맞춰야 한다. (1) 프롬프트와 컨텍스트 길이, (2) 양자화 방식(같은 4bit라도 방법마다 결과가 다르다), (3) 배치 크기, (4) 측정 대상이 첫 토큰 지연(TTFT)인지 초당 토큰 처리량(throughput)인지. 이 네 가지가 다르면 "vLLM이 3배 빠르다" 같은 수치는 사실 서로 다른 실험을 비교한 것에 불과하다.

5분 안에 시작하기#

1. 혼자 실험: Ollama 설치 후 ollama run llama3.1:8b로 바로 대화.
2. 기기에 심기: llama.cpp를 빌드하고 llama-server로 OpenAI 호환 엔드포인트 띄우기.
3. 프로덕션 다중 에이전트: vLLM을 python -m vllm.entrypoints.openai.api_server로 서버 기동.

세 경우 모두 OpenAI 호환 API를 노출하므로, 에이전트 코드는 base URL만 바꿔 그대로 붙는다. 즉 지금 Ollama로 시작해도 나중에 vLLM으로 옮길 때 애플리케이션 코드를 다시 쓸 필요가 없다.

핵심 한 문장: 워크로드가 커질수록 Ollama에서 llama.cpp, vLLM 순으로 옮겨 가되, 벤치마크는 반드시 같은 조건에서 재현해 확인하라.

참고: 이 글은 2026년 7월 기준 각 런타임의 안정 버전을 기준으로 한다. vLLM과 llama.cpp는 릴리스가 잦아 성능 수치가 자주 바뀌므로, 약 6개월 주기로 수치를 갱신한다.