whichllm의 추천은 다운로드 후보를 좁히는 데 쓸 수 있지만, ‘VRAM에 들어간다’와 ‘내 업무를 충분히 빠르고 정확하게 처리한다’는 서로 다른 판정입니다.
whichllm은 하드웨어 정보와 모델 메타데이터, 벤치마크를 조합해 실행 가능 모델을 순위로 제시하는 CLI로 소개됩니다. 원문에 나온 모델명, 점수 공식과 명령은 프로젝트 스냅샷의 설명이며 현재 구현을 보장하는 실행법이 아닙니다.
내 GPU에 맞는 LLM은 어떻게 고를까: whichllm 숫자 검증법
VRAM 계산에는 세 덩어리가 들어간다
첫째는 양자화된 모델 가중치, 둘째는 문맥과 동시 요청에 따라 커지는 KV 캐시, 셋째는 런타임 버퍼와 여유 공간입니다. 파일 크기만 VRAM과 비교하면 긴 문맥이나 배치에서 OOM이 날 수 있습니다. GQA 여부, KV head 수와 목표 문맥을 모델 설정에서 읽는 이유가 여기에 있습니다.
계산 결과에는 안전 여유를 남겨야 합니다. 데스크톱 화면이 같은 GPU를 쓰거나 추론 엔진이 예상보다 큰 버퍼를 잡을 수 있기 때문입니다. 추천된 양자화 파일을 실제 엔진으로 로드해 목표 문맥과 동시 요청으로 최고 메모리를 측정하기 전에는 ‘실행 가능’으로 확정하지 마세요.
MoE의 전체와 활성 파라미터를 나눈다
MoE는 토큰마다 일부 expert만 계산하므로 활성 파라미터가 속도 추정에 도움이 됩니다. 그러나 모든 expert 가중치를 접근할 수 있어야 하므로 적재 메모리는 전체 파라미터의 영향을 받습니다. 활성 수만 보고 작은 모델처럼 취급하거나 전체 수만 보고 항상 느리다고 판단하는 두 오류를 피해야 합니다.
초당 토큰은 파라미터 수뿐 아니라 메모리 대역폭, 프롬프트 처리와 추론 엔진에 좌우됩니다. 첫 토큰 시간과 생성 처리량을 따로 재고, 짧은 채팅과 긴 RAG 입력을 분리해야 사용 체감이 드러납니다.
벤치마크 순위는 업무 품질이 아니다
LiveBench나 ELO 같은 공개 점수와 최신성 가중치는 오래된 인기 모델만 고르는 일을 줄일 수 있습니다. 하지만 한국어 금융 분류, 사내 코드 리뷰와 같은 특정 업무의 정답률을 대신하지 않습니다. 양자화가 실제 후보의 품질에 주는 영향도 일반 페널티 하나로 정확히 예측하기 어렵습니다.
상위 세 모델을 고른 뒤 같은 30~50개 내부 평가를 실행해 정답률, 형식 준수, 사람이 고친 비율을 비교하세요. 공개 점수는 후보 생성에만 쓰고 최종 선택은 도메인 평가와 처리량의 최소 기준을 모두 통과한 모델로 제한하는 편이 안전합니다.
추천 도구도 실행 전에 감사한다
원문은 whichllm이 GPU, RAM, CPU와 OS를 탐지하고 외부 벤치마크를 갱신한다고 설명합니다. 이런 도구는 민감한 장비 정보와 네트워크 접근을 가질 수 있으므로 격리된 환경에서 소스와 외부 요청, 캐시 파일을 먼저 확인해야 합니다. 외부 사이트 구조가 바뀌면 데이터가 오래되거나 파싱이 깨질 수도 있습니다.
하드웨어 구매를 역산할 때도 추천 GPU 이름보다 필요한 메모리, 대역폭과 목표 처리량 같은 원시 수치를 보세요. 실제 후보 장비에서 작은 부하 시험을 한 뒤 발주해야 모델 계산식의 오차로 큰 비용을 쓰는 일을 피할 수 있습니다.
결론적으로 whichllm은 ‘무엇을 받을까’의 탐색 비용을 줄이는 계산기입니다. 추천값, 엔진 실측, 업무 정답 세 단계를 분리하면 VRAM 테트리스는 줄이면서도 순위를 맹신하는 새 함정은 피할 수 있습니다.
메모리 예산은 어떤 순서로 계산해야 하는가?
먼저 운영체제와 화면, 추론 서버가 이미 쓰는 VRAM을 뺀 가용 예산을 정합니다. 그 안에서 양자화 가중치, 목표 문맥의 KV 캐시, 런타임 작업 공간을 각각 추정합니다. 수치가 경계에 걸리면 가장 낙관적인 값 대신 여유를 크게 둔 후보를 선택하세요. 로드 직후만 보고 맞는다고 판단하면 긴 프롬프트나 두 번째 사용자가 들어오는 순간 OOM이 날 수 있습니다.
KV 캐시는 모델 구조, 데이터 형식, 문맥 길이, 배치와 동시 시퀀스 수에 따라 커집니다. 따라서 ‘최대 컨텍스트 32K 지원’과 ‘내 GPU에서 32K로 두 요청을 동시에 처리’는 다른 주장입니다. 실제 업무의 입력 토큰 분포를 먼저 측정하고, 상위 몇 퍼센트의 긴 요청을 잘라낼지 또는 CPU offload, 요약 경로로 보낼지 정해야 합니다.
통합 메모리를 쓰는 장비도 총 RAM 숫자만 비교하면 부족합니다. 운영체제와 다른 애플리케이션이 같은 자원을 경쟁하고, 메모리 압박이 생기면 실행은 되지만 지연이 급격히 늘 수 있습니다. 단일 프롬프트 성공이 아니라 10~20분 동안 반복 요청을 보내 최고 메모리, swap 발생, 오류와 처리량 변화를 관찰하세요.
같은 모델의 양자화 후보는 어떻게 비교하는가?
낮은 비트 양자화는 적재 공간을 줄이지만 업무 품질과 엔진 지원이 달라질 수 있습니다. 이름만 비슷한 파일을 섞지 말고 모델 revision, 양자화 방식, tokenizer와 채팅 템플릿을 고정합니다. 후보마다 동일한 seed와 프롬프트를 사용하고 구조화 출력 준수, 한국어 답변, 코드나 수식처럼 민감한 작업의 오류를 따로 셉니다.
속도는 prompt 처리와 token 생성으로 나눠 봐야 합니다. 긴 RAG 입력은 prompt 처리량이, 대화형 UI는 첫 토큰 시간과 생성 속도가 체감을 좌우합니다. 다음 표처럼 목표별 합격선을 먼저 정하면 숫자가 큰 하나의 benchmark에 끌려가지 않습니다.
| 사용 시나리오 | 주요 입력 | 먼저 볼 지표 | 대표 실패 조건 |
|---|---|---|---|
| 짧은 개인 채팅 | 짧은 prompt, 1 request | 첫 토큰 시간, 답변 품질 | 시작 지연이 길어 대화가 끊김 |
| 문서 RAG | 긴 prompt, 근거 요구 | prompt 처리량, 인용 정확도 | 긴 문맥에서 OOM 또는 근거 누락 |
| 여러 사용자 API | 동시 sequence | p95 지연, 총 처리량, 오류율 | queue 증가와 메모리 고갈 |
| 코드 보조 | 긴 파일, 구조화 출력 | 내부 test 성공, format 준수 | 양자화 뒤 수정 정확도 하락 |
추천 순위와 업무 평가를 어떻게 연결하는가?
whichllm에서 상위 후보 세 개를 받은 뒤 모든 모델을 같은 엔진 설정으로 비교합니다. 평가 질문에는 쉬운 예제뿐 아니라 모르는 경우 거절해야 하는 질문, 긴 입력, JSON 스키마와 도메인 용어를 포함하세요. 정답률이 같다면 사람이 고친 문자 수, 형식 재시도와 근거 없는 답변을 비교하면 운영 비용 차이가 드러납니다.
공개 벤치마크의 높은 점수는 후보가 기본 능력을 갖췄다는 단서일 뿐입니다. 평가 데이터의 언어와 업무가 다르거나, 공개 점수가 원본 정밀도 모델인데 실제 후보는 강한 양자화라면 순위가 뒤집힐 수 있습니다. 최신성 가중치도 새로운 모델을 탐색하는 데는 유용하지만, 오래된 모델이 이미 내부 시험과 운영 도구에서 안정적이라면 교체 비용까지 포함해야 합니다.
한 번의 평균값 대신 cold start와 warm run을 나눕니다. 모델 로드 시간, 첫 요청, 캐시가 찬 뒤 반복 요청을 각각 기록하고, 실패한 요청도 분모에 포함하세요. 토큰/초가 빨라도 형식 오류로 두 번 재시도하면 실제 업무 처리량은 낮습니다.
추천 결과가 빗나가는 실패 조건은 무엇인가?
외부 모델 메타데이터가 오래됐거나 파일 이름 파싱이 틀리면 가중치 크기와 구조가 잘못 입력될 수 있습니다. 하드웨어 탐지가 통합 GPU, 여러 GPU 또는 예약된 메모리를 정확히 반영하지 못할 수도 있습니다. 추천 출력에는 데이터 갱신 시각과 가정값을 함께 저장하고, 모델 설정 원문과 추론 엔진 로그로 교차 확인하세요.
엔진 차이도 큽니다. 같은 파일이라도 지원 kernel, CPU offload, flash attention과 KV cache 형식에 따라 속도와 메모리가 달라집니다. whichllm 계산에서 합격한 모델이 목표 엔진에서 로드되지 않거나 일부 연산이 CPU로 떨어질 수 있으므로, 추천을 받은 바로 그 장비와 배포 엔진에서 시험해야 합니다.
구매 결정에는 최소 합격 모델 하나만 보지 말고 다음 1년의 문맥, 동시성 증가와 대체 후보를 포함합니다. 반대로 언젠가 쓸 최대 모델을 위해 과도한 장비를 사는 것도 피해야 합니다. 현재 p95 요청, 성장 가정과 업그레이드 비용을 문서화하고 실제 후보 장비에서 부하 시험이 재현될 때 발주하세요.
함께 읽으면 이해가 이어지는 글
- vLLM PagedAttention은 KV 캐시를 어떻게 관리할까: 처리량, 지연, OOM 검증법 — vLLM의 PagedAttention이 요청마다 늘고 줄어드는 KV 캐시를 블록으로 관리하는 원리를 설명합니다. 논문의 처리량 수치를 운영 환경에 적용하기 전에 TTFT, TPOT, 메모리, 동시성을 검증하는 방법도 정리합니다.
- 로컬 LLM은 클라우드보다 쌀까: VRAM, 전력, 운영비 계산 — 로컬 LLM의 양자화, 메모리 대역폭, KV 캐시를 이해하고, 하드웨어 구매 전에 품질, 동시성, 전력, 운영비를 비교하는 방법을 정리합니다.
- 오픈소스 LLM이 GPT API보다 싸질까: vLLM, PagedAttention, TCO 계산 — 오픈소스 LLM의 무료 가중치와 실제 서빙 비용을 구분하고, KV Cache, Continuous Batching, 양자화와 GPU 이용률로 손익을 계산하는 방법을 정리합니다.
자주 묻는 질문
모델 파일이 VRAM보다 작으면 GPU에서 반드시 실행되나요?
아닙니다. 가중치 외에도 문맥 길이와 동시 요청에 따른 KV 캐시, 런타임 버퍼와 다른 프로세스의 메모리가 필요하므로 목표 부하로 최고 사용량을 재야 합니다.
MoE 모델은 활성 파라미터만 메모리에 올리면 되나요?
일반적으로 속도 추정에는 활성 파라미터가 중요하지만 적재 메모리는 전체 expert 가중치의 영향을 받습니다. 사용 엔진의 offload 방식과 실제 메모리를 확인해야 합니다.
whichllm 순위 1위 모델을 바로 선택해도 되나요?
순위는 후보를 좁히는 출발점입니다. 실제 양자화, 엔진에서 내부 업무 평가, 첫 토큰 시간, 생성 처리량과 오류율을 함께 통과한 모델을 선택해야 합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.