약 한 달 전, 저는 에이전트 (agents)의 세계로 뛰어들었습니다. 물론 제 LLM은 "기술적으로" 한동안 에이전트적 (agentic)이었지만, 저는 Qwen에 Google Search MCP를 연결해서 사용해 왔고 아주 만족하고 있었습니다. 하지만 이제 저는 완전히 몰입하고 있으며, 이는 밤과 낮처럼 확연히 다른 경험입니다. 만약 여러분이 로컬 LLM으로 에이전트적 (agentic) 작업을 하고 있지 않다면, 완전히 다른 차원의 경험을 놓치고 있는 것입니다. 정말로 거의 무한한 가능성의 세계처럼 느껴집니다.

이것은 저를 LM Studio로 이끌었습니다. LM Studio는 거의 2년 동안 제가 선택해 온 서버였습니다. 사람들은 한동안 저에게 llama.cpp로 옮길 것을 권장해 왔지만, 저는 이를 피해 왔습니다. 제 주의력을 99% 요구하는 너무 많은 다른 프로젝트들로 너무 바빴기 때문에, 잠재적인 버그나 문제를 일으킬 수 있는 요소를 추가하는 것은 좋은 동기 부여가 되지 않았습니다.

그렇긴 하지만, 에이전트적 (agentic) 작업을 시작하면서 제가 직접 할 필요조차 없다는 것을 깨달았습니다. 그래서 저는 에이전트에게 이 일을 맡겼고, 에이전트가 저를 대신해 이를 설치해주었으며, 저는 제대로 시도해 볼 수 있었습니다.

따라서, 제가 경험한 몇 가지 사항과 LM Studio에서 넘어올 때 여러분이 아마도 알아두어야 할 사항들을 말씀드리겠습니다. 또한, 여러분 중 해결 방법(workarounds)에 대한 제안이 있다면 저를 가르쳐 주십시오, 스승님(sensei). 저는 여전히 이 모든 것들을 배우려고 노력 중입니다.

LM Studio보다 llama.cpp가 더 빠릅니다. 사실입니다. 이것은 #2번과 몇 가지 추가적인 tok/sec (초당 토큰 수)의 조합입니다. 전체적인 경험이 훨씬 더 경쾌하게 느껴집니다.

프롬프트 처리 (Prompt Processing) 속도가 llama-server에서 훨씬 더 좋습니다. 최근 LM Studio에 무슨 일이 일어났는지는 모르겠지만, 모델의 PP (프롬프트 처리) 속도가 정말 형편없어서 더 이상 참을 수 없는 수준이었습니다. 이를 해결하기 위해 저는 미친 듯이 모델 스위칭 (model switching)을 해왔지만, 이 또한 모델 간에 KV 캐시 (kv caches)가 다시 로드되면서 추가적인 프롬프트 처리 지연을 초래했습니다. 때로는 모델을 언로드 (unloaded)했음에도 불구하고 RAM 지문 (ram fingerprint)이 여전히 남아 있어서 작업 관리자에서 프로세스를 여러 번 종료해야 할 때도 있었습니다. llama-server에서는 이것이 문제가 되지 않습니다. 이는 또 다른 논점으로 이어집니다...

프롬프트 처리 (pp) 속도의 향상 덕분에, 더 큰 양자화 (quant) 모델에서도 더 높은 컨텍스트 제한 (context limits)을 실행할 수 있습니다. 예를 들어, 제가 주로 사용하던 모델은 Qwen 2.5 Q5_K_XL이었습니다. 하지만 컨텍스트가 100K에 가까워지면 pp 속도가 매우 느려져서 모델을 교체해야만 했습니다. 이제 그것은 문제가 되지 않으며, 큰 pp 저하 없이 100K에 도달할 수 있습니다. 물론 최대 컨텍스트에 가까워지면 토큰/초 (tok/sec)가 떨어지긴 하지만, 100K 컨텍스트에서 22 tok/sec 대 30 tok/sec 정도의 차이라 충분히 실행 가능한 수준입니다. 이제 저는 더 나은 모델들로부터 더 많은 경험을 쌓고 있습니다. 이는 결코 작은 일이 아닙니다.

lama.cpp의 내장 채팅 UI인 Llama-UI는 LM Studio가 가진 거의 모든 기능을 갖추고 있으며, 프롬프트 처리 (pp) 속도를 확인할 수 있는 내장 옵션과 같은 몇 가지 추가 기능도 제공합니다:

[IMG:1]

하단의 대시보드를 통해 해당 턴에 사용된 토큰, pp 속도, tok/sec, 도구 호출 (tool call) 통계, 에이전트 (agentic) 통계 등을 확인할 수 있으며, 모두 유용한 정보들입니다. (참고: 위 예시는 100K 컨텍스트에 근접한 상태입니다)

그 외에도 언급하지 않을 수많은 장점들이 있으며, 전환해 보시면 직접 알게 될 것입니다. 이제 단점과 주의해야 할 사항들에 대해 알아보겠습니다.

첫째, 이 분야가 처음이라면 프론트엔드 (frontend)가 어떻게 작동하는지 이해하지 못할 수도 있습니다. 그래서 간단한 참고 사항을 알려드리자면, LM Studio는 프론트엔드 채팅 UI이자 서버 역할을 동시에 수행합니다. 에이전트 루프 (agentic loops), 대화 저장, MCP 도구 처리 등은 모두 서버 측이 아닌 스택 (stack) 측에서 이루어집니다. 그렇다면 llama.cpp로 전환했을 때는 무엇이 달라질까요?

LM Studio와 달리, Llama-UI는 대화 내용을 로컬에 자동으로 저장하지 않고 브라우저에 저장합니다. 따라서 세션이 끝난 후 설정 메뉴에서 수동으로 다운로드하거나 (json 형식으로 다운로드되어 매우 쉽습니다), 자동화/확장 프로그램 등을 코드로 구현해야 합니다. 만약 별도의 하네스 (harness)를 사용 중이라면, 아마 이미 이 작업을 처리할 수 있을 것입니다.

Llama-UI는 MCP 도구와 함께 작동하지만, 만약 사용 중인 MCP가 stdio 프로세스를 실행한다면 프록시 브리지 (proxy bridge)를 만들어야 할 수도 있습니다. 만약 이 말이 이해되지 않는다면, 사용 중인 에이전트에게 물어보세요. 에이전트는 알고 있을 것입니다.

토큰화 (tokenization) 오류가 발생하면 채팅이 종료됩니다.

제 말은, LM Studio에서는 에이전트가 도구 호출 (tool call)을 실수하더라도 그냥 에러가 발생하고 즉시 중단될 뿐이라는 것입니다. 하지만