whichllm이 보여준 로컬 LLM 선택의 새 기준: 파라미터 수보다 하드웨어 적합성

Local LLM · Hardware Fit · GGUF · Benchmark

로컬 LLM을 고를 때 가장 흔한 실수는 “요즘 제일 좋은 오픈 모델이 뭐지?”에서 출발하는 것이다. 하지만 실제 팀 운영에서는 질문이 조금 달라야 한다. 내 장비에서 실제로 돌아가고, 충분히 빠르고, 지금 기준으로 낡지 않았으며, 우리 작업에 맞는 모델은 무엇인가?

2026년 6월 10일 GitHub Trending에 오른 Andyyyy64/whichllm은 이 질문을 꽤 노골적으로 겨냥한다. README의 한 줄 설명도 명확하다. “Find the local LLM that actually runs and performs best on your hardware.” 즉 최고 모델을 추상적으로 추천하는 도구가 아니라, 현재 GPU·CPU·RAM·VRAM 조건에서 돌아갈 후보를 걸러내고 순위를 매기는 CLI다.

이 글의 핵심 주장은 간단하다. 로컬 LLM 도입은 더 이상 “몇 B 모델을 받을까”의 문제가 아니다. 하드웨어 탐지, 모델 후보 수집, 양자화 포맷, 토큰 속도 추정, 벤치마크 증거의 신선도, 실행 경로까지 묶은 작은 운영 시스템으로 봐야 한다. whichllm은 그 전환을 잘 보여주는 사례다.

기준 시점: 이 글은 2026-06-10에 확인한 whichllm GitHub 저장소, README/docs, GitHub API 메타데이터, Ollama API 문서, Hugging Face GGUF/Model Hub 문서를 바탕으로 썼다. 저장소 수치와 지원 모델·벤치마크 소스는 빠르게 바뀔 수 있다.

왜 지금 로컬 LLM 선택 도구가 다시 중요해졌나

로컬 LLM은 이미 익숙한 주제처럼 보인다. llama.cpp, Ollama, LM Studio, vLLM, Transformers, GGUF 파일, 4-bit quantization 같은 키워드는 낯설지 않다. 그런데 실제로 팀 안에서 “이번 프로젝트에 어떤 로컬 모델을 기본값으로 쓸 것인가”를 정하려고 하면 여전히 결정이 어렵다.

이유는 세 가지다.

첫째, 오픈 모델 공급이 너무 빨리 바뀐다. Hugging Face Model Hub에는 매일 새 모델, 새 quant, 새 finetune, 새 vision variant가 올라온다. 어떤 모델은 벤치마크가 좋지만 오래됐고, 어떤 모델은 최신이지만 검증 신호가 약하다. README만 읽고 고르면 “좋아 보이는 모델”과 “오늘 우리 장비에서 쓸 모델” 사이에 간극이 생긴다.

둘째, 하드웨어 제약이 모델 품질을 압도한다. 70B 모델이 좋다는 사실은 12GB VRAM 노트북 사용자에게 별 도움이 안 된다. 반대로 32B가 들어간다고 해서 항상 최선도 아니다. whichllm README 예시는 RTX 4090 시뮬레이션에서 32B 모델이 카드에는 맞지만 27B 후보가 더 높은 점수를 받을 수 있음을 보여준다. 크기보다 사용 가능성이 중요하다는 뜻이다.

셋째, 로컬 실행은 모델 파일 하나로 끝나지 않는다. GGUF라면 llama-cpp-python과 huggingface-hub 경로가 필요하고, AWQ/GPTQ/FP16 계열은 Transformers·Torch·Accelerate 같은 다른 런타임 경로를 탄다. Ollama 문서처럼 로컬 런타임은 모델 이름, 태그, pull, list, run, embeddings 같은 별도 운영 표면을 가진다. 결국 모델 선택은 실행 체인 선택이기도 하다.

whichllm의 포인트: 하드웨어에서 출발해 후보를 줄인다

whichllm의 기본 사용법은 단순하다.

uvx whichllm@latest

자주 쓰면 uv tool install whichllm, Homebrew, pip로 설치할 수 있고, --gpu "RTX 4090"처럼 특정 GPU를 가정해볼 수도 있다. README는 upgrade, plan, run, snippet, --json 같은 워크플로도 제시한다. 이 중에서 가장 실무적인 기능은 두 가지다.

• 현재 장비에서 실행 가능한 모델 후보를 자동으로 추천한다.
• 구매 전 GPU를 시뮬레이션해 업그레이드 후보를 비교한다.

공식 docs의 request flow를 보면 whichllm은 대략 이런 순서로 움직인다.

1. CLI 플래그를 검증한다.
2. 하드웨어를 탐지한다.
3. Hugging Face에서 모델 후보를 가져오거나 캐시를 읽는다.
4. 벤치마크 소스를 가져오거나 캐시를 읽는다.
5. 관련 모델 repo를 family로 묶는다.
6. 후보 variant를 다시 펼쳐 rankable candidate로 만든다.
7. 각 후보를 점수화한다.
8. 상위 결과의 published date를 보강한다.
9. Rich table 또는 JSON으로 출력한다.

여기서 핵심은 “모델 목록을 먼저 보고 나중에 내 장비에 맞춰보는” 방식이 아니라는 점이다. whichllm은 처음부터 하드웨어를 입력 조건으로 둔다. docs에 따르면 탐지 대상은 GPU 목록, CPU 이름, 물리 코어, AVX2/AVX-512, 총 RAM, 디스크 여유 공간, OS 정보까지 포함한다. NVIDIA는 nvidia-ml-py를 먼저 쓰고 실패하면 nvidia-smi로 fallback한다. AMD는 rocm-smi, lspci, /sys/class/drm 등을 시도한다. macOS는 system_profiler를 사용한다.

이 설계는 한국 개발팀에도 현실적이다. 사무실에는 M-series MacBook, RTX 데스크톱, 저가형 Windows PC, 개인 GPU 서버가 섞여 있는 경우가 많다. “우리 팀은 Qwen 32B를 쓴다”보다 “이 작업은 16GB VRAM 장비에서는 이 후보, 24GB 장비에서는 이 후보, CPU-only 환경에서는 이 후보”라고 나누는 쪽이 운영에 맞다.

순위표가 아니라 “실제 사용 가능한 선택지”를 점수화한다

whichllm docs의 scoring 페이지는 이 도구가 단순히 큰 모델을 고르지 않는다고 못박는다. 질문은 이것이다.

Of the models that can run here, which one is likely to be the best usable choice?

점수 입력값도 운영적이다. Hugging Face 모델 메타데이터, 탐지 또는 시뮬레이션된 하드웨어, VRAM/RAM 적합성 추정, tokens/sec 추정, quantization type, benchmark evidence, downloads/likes, source organization, model lineage/generation이 함께 들어간다.

특히 마음에 드는 부분은 벤치마크 증거를 차등 가중한다는 점이다. docs는 direct, base_model, variant, line_interp, self_reported, none 같은 evidence level을 나누고, self-reported eval을 의도적으로 약하게 취급한다고 설명한다. Hugging Face 모델 카드에 적힌 자체 평가도 참고는 할 수 있지만, 독립 벤치마크와 같은 신뢰도로 보면 안 된다는 태도다.

이건 로컬 LLM 선택에서 매우 중요하다. 오픈 모델 생태계는 좋은 의미로 활발하지만, 동시에 비교 기준이 들쭉날쭉하다. 어떤 모델 카드는 특정 벤치마크만 강조하고, 어떤 repo는 양자화 variant별 품질 저하를 충분히 설명하지 않는다. 모델 이름에 “Instruct”, “Coder”, “Reasoning”, “Vision”이 붙어 있어도 실제 작업 품질은 다를 수 있다. 그래서 추천 도구는 단순 인기순보다 증거의 출처와 신선도를 봐야 한다.

whichllm README의 data pipeline 설명도 이 방향이다. 모델 후보는 Hugging Face API에서 가져오고, text-generation·최근 업데이트·GGUF 필터·vision profile 등을 구분한다. benchmark sources는 LiveBench, Artificial Analysis Index, Aider 같은 current tier와 Open LLM Leaderboard v2, Chatbot Arena ELO 같은 frozen tier를 나눠 다룬다. 또 “lineage-aware recency demotion”으로 낡은 leaderboard가 오래된 세대 모델을 과대보상하지 않도록 한다고 설명한다.

여기서 SEO 키워드로 자주 검색되는 “로컬 LLM 추천”, “내 GPU에 맞는 LLM”, “GGUF 모델 추천”, “Ollama 모델 추천”의 답도 조금 바뀐다. 정답 모델 하나를 외우는 게 아니라, 추천 과정을 자동화해야 한다. 오늘의 1위 모델은 다음 주에 바뀔 수 있고, 같은 모델도 quantization과 런타임에 따라 체감 품질이 달라진다.

GGUF와 Ollama 생태계가 만든 새로운 병목

Hugging Face의 GGUF 문서는 GGUF가 llama.cpp 생태계에서 쓰이는 binary format이며 모델 가중치와 inference에 필요한 메타데이터를 저장한다고 설명한다. GGUF의 실무적 가치는 분명하다. 큰 모델을 더 작은 파일과 더 낮은 메모리 요구량으로 로컬에서 굴릴 수 있게 해준다. 하지만 동시에 선택지는 훨씬 많아진다.

예를 들어 같은 base model도 Q4, Q5, Q8, K_M 같은 여러 quantization variant로 존재할 수 있다. 파일 크기, VRAM fit, tokens/sec, 품질 저하가 모두 다르다. “이 모델은 좋다”가 아니라 “이 모델의 이 quant가 이 장비에서 이 속도로 충분한가”가 질문이 된다.

Ollama API 문서도 비슷한 운영 표면을 보여준다. 모델 이름은 model:tag 포맷을 따르고, pull, list local models, show model information, generate, chat, embeddings 같은 endpoint를 가진다. 로컬 LLM을 제품이나 사내 워크플로에 넣는 순간에는 모델 파일을 받는 행위와 실제 실행·조회·삭제·교체·태그 관리가 모두 운영 과제가 된다.

whichllm의 run과 snippet 기능은 이 병목을 조금 줄인다. docs에 따르면 whichllm run은 후보 모델을 고르고, 임시 Python chat script를 만들고, uv run --no-project와 필요한 dependency를 붙여 실행한 뒤 임시 스크립트를 지운다. GGUF 경로에서는 llama-cpp-python과 huggingface-hub를 사용하고, hf_hub_download로 선택된 GGUF 파일을 받아 llama_cpp.Llama로 로드한다. AWQ, GPTQ, FP16/BF16/FP8/INT8/BNB 4-bit 계열은 Transformers 경로를 탄다.

이런 기능은 “추천”과 “실행” 사이의 마찰을 줄인다. 좋은 모델을 찾았지만 실행 스크립트를 못 만들어 테스트가 지연되는 일이 줄어든다. 특히 작은 팀에서는 이 차이가 크다. 모델 리서치 담당자와 서비스 개발자가 분리되어 있지 않은 경우가 많기 때문이다.

한국 개발팀이 로컬 LLM을 고를 때의 체크리스트

whichllm 같은 도구를 그대로 도입하든 아니든, 여기서 배울 수 있는 운영 기준은 꽤 명확하다.

1) “최고 모델” 대신 “장비별 기본 모델”을 정하라

팀 문서에 “추천 모델: X”라고 하나만 적지 말고, 장비 profile별로 나누는 편이 낫다.

이렇게 나누면 “모델 선택”이 개인 취향에서 운영 정책으로 바뀐다.

2) 벤치마크는 최신성과 출처를 같이 보라

벤치마크 점수는 필요하다. 하지만 낡은 leaderboard, 자체 보고 eval, base model에서 파생된 variant 추정, 독립 벤치마크 direct match는 같은 신뢰도가 아니다. whichllm이 evidence level을 나누는 이유도 여기에 있다.

실무에서는 아래 순서로 보는 편이 안전하다.

1. 우리 작업과 가까운 독립 벤치마크가 있는가?
2. 해당 모델 variant와 quantization에 직접 연결되는 증거인가?
3. 모델이 최근에 업데이트됐는가?
4. 다운로드·likes 같은 생태계 신호가 있는가?
5. 실제 우리 프롬프트셋에서 latency와 실패율은 어떤가?

특히 한국어 작업이라면 글로벌 벤치마크만으로 부족하다. 내부 문서 요약, 한국어 고객 문의, 코드 주석, 로그 분석, 번역, 개인정보 마스킹 같은 실제 샘플을 별도로 돌려야 한다.

3) “돌아간다”와 “쓸 수 있다”를 구분하라

큰 모델을 낮은 bit로 줄이면 어떻게든 로드될 수 있다. 하지만 실제 사용성은 다른 문제다. 응답이 너무 느리거나, context가 부족하거나, quantization 손실 때문에 코드·추론 품질이 흔들리면 팀은 결국 클라우드 API로 돌아간다.

따라서 최소 기준을 숫자로 정하는 게 좋다.

• 첫 토큰 지연 시간
• 평균 tokens/sec
• 메모리 여유율
• 반복 프롬프트 20~50개에서의 실패율
• 한국어/영어 혼합 입력 품질
• 코드 블록·JSON·Markdown 형식 준수율
• 모델 다운로드와 cold start 시간

이 지표가 없으면 로컬 LLM 도입은 “좋아 보이는 데모”로 끝날 가능성이 높다.

4) GPU 구매 의사결정에 모델 추천을 붙여라

whichllm의 upgrade와 --gpu 시뮬레이션이 흥미로운 이유는 GPU 구매 논의를 모델 선택과 연결하기 때문이다. “RTX 4090이 좋다”가 아니라 “이 GPU를 사면 우리 후보 모델군이 어떻게 바뀌는가”를 볼 수 있다.

이 접근은 비용 통제에 유용하다. 로컬 LLM 도입에서 가장 비싼 실수는 필요한 것보다 큰 GPU를 사는 것도 아니고, 너무 작은 GPU를 사서 실제 업무에 못 쓰는 것도 아니다. 모델·작업·동시성 기준 없이 하드웨어를 먼저 사는 것이다. 먼저 어떤 작업을 로컬로 내릴지 정하고, 그 작업에서 필요한 모델 크기와 속도를 본 뒤 장비를 고르는 편이 맞다.

실무 해석: 로컬 LLM은 “프라이버시 기능”이 아니라 운영 옵션이다

로컬 LLM을 이야기할 때 자주 나오는 장점은 프라이버시와 비용이다. 둘 다 맞다. 하지만 그것만으로는 부족하다. 로컬 모델은 클라우드 API의 대체재라기보다, 특정 작업을 더 낮은 지연시간·더 강한 데이터 통제·더 예측 가능한 비용 구조로 처리하기 위한 운영 옵션이다.

한국 개발팀이라면 로컬 LLM을 다음 세 가지 범주로 나누는 게 현실적이다.

1. 개발자 개인 생산성

   • 코드 설명, 작은 리팩터링 초안, 로그 요약, Markdown 정리
   • latency와 편의성이 중요하다.

2. 사내 데이터 처리

   • 내부 문서 분류, 개인정보 포함 텍스트 요약, 고객 문의 triage
   • 데이터 경계와 감사 가능성이 중요하다.

3. 제품 기능의 fallback 또는 edge 실행

   • 네트워크가 불안정한 환경, 비용 제한이 강한 기능, 온디바이스 UX
   • 모델 크기, 추론 속도, 업데이트 전략이 중요하다.

각 범주마다 최적 모델이 다르다. 개발자 개인 생산성에는 빠른 7B~14B급이 더 나을 수 있고, 사내 문서 처리에는 한국어 안정성과 긴 context가 더 중요할 수 있다. 제품 fallback은 품질보다 deterministic한 출력 형식과 장애 대응이 우선일 수 있다.

whichllm이 보여주는 방향은 이 분리를 자동화하는 것이다. 하드웨어와 후보 모델을 보고 “이 장비에서는 이 선택지가 현실적”이라고 말해주는 도구가 있으면, 팀은 매번 모델 뉴스를 따라다니는 대신 자체 평가 루프에 집중할 수 있다.

바로 적용할 수 있는 운영 루프

로컬 LLM 도입을 진지하게 검토한다면 아래 루프를 추천한다.

1단계: 장비 profile을 정의한다

팀에 실제로 있는 장비를 나눈다. 예를 들어 macbook-m3-36gb, rtx-4060-8gb, rtx-4090-24gb, cpu-only-ci 같은 식이다. 각 profile마다 VRAM/RAM, OS, 런타임, 용도를 적는다.

2단계: 후보 모델을 자동으로 뽑는다

whichllm 같은 도구로 후보를 뽑고, Hugging Face/GGUF/Ollama 경로를 확인한다. 이때 모델 이름만 저장하지 말고 quantization, 파일 크기, 예상 tokens/sec, source, 업데이트 날짜를 같이 남긴다.

3단계: 팀 프롬프트셋으로 재평가한다

벤치마크 상위 모델이라도 우리 작업에 약할 수 있다. 최소 20개 이상의 실제 프롬프트를 준비하라. 한국어 문서, 코드, 로그, JSON 출력, 짧은 지시, 긴 context를 섞는다. 품질 점수만 보지 말고 실패 유형을 기록한다.

4단계: 기본값과 fallback을 정한다

각 장비 profile마다 기본 모델 1개, fallback 1개를 정한다. 그리고 “언제 클라우드 API로 넘길지” 기준도 정한다. 예를 들어 긴 reasoning, 보안 민감도가 낮고 정확도가 중요한 요청, 대형 context가 필요한 요청은 클라우드로 보내는 식이다.

5단계: 한 달마다 갱신한다

오픈 모델 생태계는 너무 빨리 움직인다. 한 번 고른 모델을 6개월 동안 그대로 두면 금방 낡는다. whichllm의 recency-aware 접근처럼 모델 freshness를 주기적으로 반영하라. 다만 매일 바꾸면 운영이 불안정해지므로, 월간 또는 격주 단위로 평가하는 편이 좋다.

결론: 로컬 LLM 경쟁력은 모델명이 아니라 선택 시스템에서 나온다

whichllm은 아직 작은 CLI 도구처럼 보일 수 있다. 하지만 이 저장소가 GitHub Trending에서 주목받은 이유는 분명하다. 개발자들이 이제 로컬 LLM을 “멋진 모델 하나 설치하기”가 아니라 내 장비와 내 작업에 맞는 모델을 계속 고르는 운영 문제로 받아들이기 시작했기 때문이다.

앞으로 로컬 LLM 도입의 승부는 누가 더 큰 모델 이름을 외우느냐가 아니다. 누가 하드웨어 profile을 정의하고, 후보 모델을 자동 수집하고, 최신 벤치마크 증거를 가중하고, 실제 업무 프롬프트로 다시 평가하고, 팀 기본값을 주기적으로 갱신하느냐에 달려 있다.

한 줄로 정리하면 이렇다.

로컬 LLM의 실무 기준은 “가장 큰 모델”이 아니라 “지금 내 하드웨어에서 반복적으로 쓸 수 있는 가장 좋은 모델”이다.

참고 자료

• Andyyyy64, whichllm GitHub Repository, 2026-06-10 확인.
• Andyyyy64, whichllm README, 2026-06-10 확인.
• Andyyyy64, whichllm How it works, 2026-06-10 확인.
• Andyyyy64, whichllm Scoring, 2026-06-10 확인.
• Andyyyy64, whichllm Hardware detection and simulation, 2026-06-10 확인.
• Andyyyy64, whichllm Run and snippet, 2026-06-10 확인.
• Hugging Face, GGUF documentation, 2026-06-10 확인.
• Ollama, API documentation, 2026-06-10 확인.