안녕 localllama 형제들, 다들 잘 지내? 나는 오랜 시간 로컬 LLM 팬이었던 u/raydestar야. 약 10년의 경력을 가진 소프트웨어 엔지니어 (SWE)이고, 최근에는 에이전트형 AI (Agentic AI) 기술을 익히기 위해 열심히 노력하고 있어. 오픈 웨이트 (Open weights) 모델들이 좋아지면서 정말 놀라움을 금치 못하고 있지. 내가 이해하기 어려웠던 점은 "왜 이게 더 큰 이슈가 되지 않을까?"였어. 내 생각에 그 답은 접근성이 떨어지기 때문이고, 대부분의 사람들은 8B 모델이 대부분의 작업을 수행하기에는 충분히 좋지 않다고 생각하기 때문이야. 그리고 LM Studio에 모델을 넣고 실행해 보면, 그냥 좋은 모델이라는 느낌이 들지 않지. 하지만 나는 사람들이 이것들이 좋은 코드로 해결할 수 있는 엔지니어링 문제라는 점을 보지 못하고 있다고 생각해. 나의 미션은 다음을 증명하는 거야: 1) 로컬 LLM을 사용하여 80% 이상의 작업을 수행할 수 있다. (여기서 증명된 것은 아님 — 그것은 장기적인 과제이며, 이 포스트는 첫 번째 데이터 포인트임.) 2) 좋은 오케스트레이션 (Orchestration)이 있다면, 작은 LLM이라도 거대하게 느껴질 수 있다. 3) 적절한 툴링 (Tooling)이 주어진다면, 작은 모델이라도 우리가 SOTA 모델들이 해결하지 못한다고 비웃는 문제들(예: 세차장 문제)을 해결할 수 있다. 내가 선택한 무기는 LFM 1.2B였어. 주로 내 4090에서 최대 500 t/s까지 뽑아낼 수 있기 때문이지. AI의 베스트 프랙티스 (Best practices)를 파악하는 데 부끄러울 정도로 긴 시간이 걸렸기에, 여러분과 공유하고자 해. 텍스트 더미를 읽는 걸 싫어해서 이 내용들을 많이 정제해서 전달할 거야. 내 프로세스와 결과들을 공유하고 싶고, 만약 내 사고 과정과 어떻게 그 결과에 도달했는지 궁금하다면 마지막에 있는 내 블로그를 클릭해 줘. 네가 보는 모든 것은 오픈 소스이며 나는 무엇도 팔려고 하지 않아. 수치를 어떻게 읽어야 할지에 영향을 미치기 때문에 미리 명확히 해둘 점이 하나 있어: 이것은 지식 벤치마크 (Knowledge benchmark)가 아니야. 나도 처음에는 그걸 시도해 봤어. 스캐폴딩 (Scaffolding)을 통해 MMLU 점수를 높이려고 실제로 시간을 쏟아봤지만, 결과는 처참했지. 스캐폴딩은 모델의 가중치 (Weights)에 없는 사실을 모델에게 알려줄 수는 없어. 스캐폴딩이 할 수 있는 것은 모델이 실제로 작업을 완수하도록 돕는 것이야. 그래서 테스트는 검증 가능한 결과가 있는 100개의 작업이며, 하네스 (Harness)는 도구 (Tools)를 사용할 수 있도록 허용되었어.

내가 측정하고 있는 것은 회상 (Recall)이 아니라 작업 완료율 (Task completion)이야. 규칙:

• 수치상으로 입증 가능하고 반복 가능한 향상이 있어야 함
• 어떤 방식으로든 벤치마크 점수를 극대화하기 위해 속임수를 써서는 안 됨 (이 규칙을 유지하는 것이 매우 어려웠어. 특히 Opus는 계속해서 응답을 하드코딩(Hard-code)하려고 했지. 문제를 해결하는 대신 예상되는 정답과 패턴이 일치하는 함수를 작성하곤 했어. 만약 직접 이 작업을 수행한다면, 모델이 생성하는 점수만 보지 말고 모델이 작성한 코드를 직접 읽어봐.)

나의 프로세스는 대략 다음과 같이 과학적 방법론 (Scientific method)을 따랐어:

• 연구 (Research): 도구 사용 (Tooling) 및 오케스트레이션 (Orchestration)을 위한 베스트 프랙티스 (Best practices). 겸손함 (그리고 수많은 실패)은 나에게 이렇게 말해주었지. 너는 그렇게 똑똑하지 않으니, 그저 검증된 아키텍처 (Architecture)를 사용하라고.
• 벤치마크 (Benchmark): 이것은 전투장이며, 각 방법론은 생존을 위해 싸우고 있어. 지연 시간 (Latency)과 토큰 비용 (Token cost)을 폭증시키지 않으면서 100개의 작업 뱅크 (Task bank)를 통과해야 하며, 그렇지 못하면 폐기돼. (작업 뱅크는 나중에 제공할게.)
• 결과 (Results): 입증된 결과만 남긴다. 내가 시도한 [N]개의 방법 중 약 90%는 폐기되었고, 10%만이 유지되었어. 결과 게시 (다음은 요약된 것이며, 블로그에 더 많은 정보가 있음):
  LFM 1.2B(Q4): 15/100 --> 32/100
  Gemma 2 9B(Q4): 24/100 --> 48/100
  Gemma 2 27B(Q4): 23/100 --> 56/100
  Luna(low): 22/100 --> 66/100

설정 (Setup): [백엔드 (Backend) / 양자화 (Quant) / 컨텍스트 길이 (Context length) / 온도 (Temp) + 샘플러 (Sampler)].
오케스트레이션 (Orchestration) 비용: 베이스라인 (Baseline) 대비 대략 [X]배의 토큰과 [Y]배의 실제 시간 (Wall clock) 소요 -- 공짜는 아니며, 1.2B 모델에서는 이 트레이드오프 (Tradeoff)가 핵심이야. 이것들은 [단일 실행 (Single runs) / N회 실행의 평균 (Mean of N runs)] 결과야. Luna는 일관성이 없었어. 실행에 따라 약 [±Z] 정도의 편차를 보였으므로, 66을 고정된 숫자가 아닌 범위의 상단으로 취급해줘. 다른 것들은 몇 포인트 이내에서 유지되었어.

솔직히 말해서 SOTA (State-of-the-art) 모델들로 더 철저한 테스트를 진행하고 싶지만, 예산이 한정되어 있어. 그럼에도 불구하고, 처음에 테스트했던 LFM 1.2B 모델뿐만 아니라 전반적으로 성능 향상이 유지된다는 점에 매우 만족해. 작업 뱅크 (Task bank)에 대하여: 100개의 케이스는 [직접 작성함 / X에서 유도함]이며, 내가 정제했어.

이를 공개하는 것은 당연히 이를 봉인된 세트(sealed set)로 소모해 버리는 것이기에, 나는 [향후 실행을 위해 비공개 버전을 따로 보관하거나 / 이를 받아들이고 다음번에 새로 시작할] 생각이야. 오염(Contamination) 문제는 나 역시 가장 먼저 질문할 부분이야. 한 가지 더 흥미로운 점은, 테스트 점수를 개선하는 것이 프론트엔드(front end)의 반응성 또한... 엄청나게 향상시키는 것처럼 보였다는 거야. 이전보다 대화가 훨씬 더 자연스럽게 느껴지는데, 나는 이것을 매우 좋은 징조로 받아들이고 있어. 결론적으로, 검증된 완료율을 측정하는 100개의 작업 뱅크(task bank)에서 이는 매우 유망한 초기 결과를 보여주었어. 소형 모델들은 처음 그대로 사용할 때 느껴지는 것만큼 멍청하지 않아, 단지 스캐폴딩(scaffolding)이 부족할 뿐이야. 나는 로컬 LLM을 더 향상시키고 대중이 사용하기 더 쉽게 만들기 위해 이 작업을 계속 이어갈 거야. 감사합니다!! 블로그 포스트 -- https://markbhall.dev/writing/my-local-llm-scored-6-of-6/ Github -- https://github.com/raydeStar/sir-thaddeus (Apache 2) Benchmark -- https://github.com/raydeStar/local-benchmark-runner-public (Apache 2) /u/_raydeStar 제출 [링크] [댓글]