로컬 LLM을 계속 쓰는 이유

요즘 클라우드 모델이 워낙 잘한다.

코드를 길게 읽히거나 복잡한 작업을 맡기면 로컬 모델보다 결과가 좋은 경우가 많다. 그냥 편하게 쓰려면 API를 호출하는 쪽이 훨씬 낫다.

그런데도 집에서는 계속 로컬 모델을 굴리고 있다.

처음에는 비용 때문이었다. 많이 쓰면 API 비용이 아깝고, 이미 장비가 있으니 직접 띄우면 되겠다고 생각했다.

계속 쓰다 보니 이유가 조금 바뀌었다.

모델보다 주변이 더 문제였다

처음에는 어떤 모델이 더 좋은지가 제일 중요해 보였다.

실제로 써보면 모델 선택보다 먼저 걸리는 게 많다.

• 요청이 너무 길면 어떻게 할지
• 모델이 내려가 있으면 어디로 보낼지
• 첫 토큰이 너무 늦으면 얼마나 기다릴지
• 동시에 여러 요청이 오면 몇 개까지 받을지
• 실패한 요청을 다시 보낼지 말지
• 어떤 모델이 어떤 작업에서 자주 실패하는지

모델을 하나 띄웠을 뿐인데 결국 서버 운영 문제로 돌아왔다.

컨텍스트를 크게 잡으면 메모리를 더 먹고, 동시 요청을 늘리면 응답이 느려진다. 작은 모델은 빠르지만 어려운 작업에서 헤매고, 큰 모델은 잘하지만 항상 켜두기 부담스럽다.

이런 건 벤치마크 표만 봐서는 잘 안 보였다.

모든 요청에 제일 좋은 모델이 필요하지 않았다

한동안은 가장 성능 좋은 모델 하나를 기본으로 두려고 했다.

지금은 반대로 생각한다.

단순 분류나 짧은 정리는 작은 모델로도 충분하다. 코드베이스를 길게 읽고 판단해야 하는 작업은 더 좋은 모델을 쓰는 게 낫다. 애매하면 그냥 클라우드 모델로 넘기면 된다.

대충 이런 식이다.

짧고 반복적인 작업
  -> 로컬 모델

코드 분석이나 긴 문맥
  -> 더 큰 로컬 모델 또는 클라우드

실패하거나 확신이 없는 작업
  -> fallback

거창한 라우터가 필요한 건 아니다.

처음에는 요청 종류 몇 개만 나눠도 꽤 차이가 난다.

오히려 라우팅을 너무 똑똑하게 만들려고 하면 그 라우터 자체가 또 하나의 문제가 된다. 예전에 이것저것 붙여보다가 결국 많이 걷어낸 적도 있다.

비용도 조금 다르게 보게 됐다

로컬 모델이 공짜인 건 아니다.

장비값이 들고 전기도 먹고, 업데이트하거나 모델을 바꿀 때 손이 간다. 장애가 나면 내가 봐야 한다.

그래도 좋은 점은 사용량이 늘어날 때 비용이 바로 토큰 단위로 올라가지는 않는다는 것이다.

반대로 클라우드는 관리할 게 거의 없고 필요할 때 강한 모델을 바로 쓸 수 있다.

그래서 둘 중 하나를 고르기보다 같이 쓰는 쪽이 지금은 더 편하다.

로컬은 자주 반복되는 작업을 맡기고, 비싼 모델은 정말 필요한 순간에 쓴다.

직접 굴려봐서 알게 된 것

로컬 LLM을 쓴다고 해서 AI를 더 잘 안다고 생각하지는 않는다.

다만 직접 서버에 올리고 계속 요청을 보내다 보니 모델 바깥의 문제를 자주 보게 됐다.

GPU 메모리가 부족한 날도 있고, 컨텍스트 설정 하나 때문에 요청이 터지기도 하고, fallback 모델의 최대 토큰이 더 작아서 두 번째 실패가 나는 경우도 있다.

이런 문제를 몇 번 겪고 나면 어떤 모델이 몇 점이다보다 이런 질문을 더 하게 된다.

이 요청은 꼭 이 모델이 해야 하나?

실패했을 때 클라이언트는 뭘 받아야 하나?

이 모델을 계속 켜둘 만큼 자주 쓰나?

요즘 내가 관심 있는 건 이쪽에 더 가깝다.

그래서 계속 쓴다

클라우드 모델을 안 쓰겠다는 건 아니다.

오히려 복잡한 코딩 작업이나 긴 문맥은 클라우드 모델을 자주 쓴다. 회사 업무에서도 필요하면 상용 모델을 쓴다.

로컬 모델은 그걸 대체하려고 돌리는 게 아니다.

내가 직접 통제할 수 있는 작은 실행 환경을 하나 가지고 있고, 거기서 모델이 실제 서비스 안에 들어갔을 때 생기는 문제를 계속 보는 게 재미있어서 쓴다.

좋은 모델이 새로 나오면 올려보고, 느리면 내리고, 역할을 바꿔본다.

아마 당분간은 계속 이럴 것 같다.