로컬 LLM은 “다운로드가 된다”와 “업무에 쓸 만하다”가 다릅니다. 모델 파일이 메모리에 들어가도 긴 문맥에서 KV 캐시가 커지거나 다른 앱이 메모리를 점유하면 속도가 급격히 떨어질 수 있습니다. 그래서 모델 이름보다 먼저 하드웨어 탐지값, 목표 컨텍스트, 메모리 여유, 실제 추론 결과를 차례로 확인해야 합니다. 아래 절차는 구매 추천이 아니라 후보를 탈락시키기 위한 검증표입니다. 민감한 도구 기능과 명령은 2026년 8월 31일 공식 문서 기준입니다.
두 도구가 답하는 질문은 다릅니다
| 단계 | 확인할 질문 | whichllm | llmfit | 통과 기준 |
|---|---|---|---|---|
| 하드웨어 | GPU·VRAM·RAM이 제대로 잡혔나 | 상세 탐지 | 시스템 요약·진단 | 실제 사양과 일치 |
| 적합성 | 목표 컨텍스트에서 어떤 방식으로 구동되나 | full GPU·부분 오프로딩·CPU 구분 | 모델별 계획과 메모리 추정 | 여유를 남긴 후보만 유지 |
| 성능 | 추정치가 실제 환경에서도 나오는가 | 근거·신뢰도 범위 | 실행 중인 공급자에 3회 추론 | 반복 결과가 업무 기준 충족 |
Apple Silicon은 CPU와 GPU가 통합 메모리를 공유합니다. whichllm 하드웨어 문서는 이를 GPU가 사용할 수 있는 메모리로 취급하고, llmfit의 하드웨어 재정의에서도 RAM 변경이 VRAM 계산에 함께 반영됩니다. 다만 통합 메모리 전부를 모델에 배정하면 운영체제와 브라우저가 쓸 공간이 줄어듭니다. “딱 맞음”보다 헤드룸을 남긴 결과를 선택하는 이유입니다.
20분 검증 절차
- 탐지값부터 대조합니다.
llmfit system과llmfit doctor로 시스템과 공급자 상태를 확인하고, whichllm의 GPU·VRAM·RAM·CPU 정보를 운영체제 정보와 맞춥니다. 값이 다르면 추천 결과도 무효입니다. - 업무 조건을 먼저 고정합니다. 짧은 채팅인지, 8K 이상 코드 문맥인지 정하고 같은 컨텍스트 길이로 비교합니다. llmfit은
plan의 컨텍스트 옵션을, whichllm은--context-length를 사용합니다. - 보수적인 예산을 둡니다. whichllm의 VRAM 헤드룸과 RAM 예산을 설정합니다. 경계선 모델은 우선 제외하고, full GPU 후보와 부분 오프로딩 후보를 분리합니다.
- 실제 공급자를 띄워 측정합니다. llmfit 벤치마크는 실행 중인 공급자와 모델에 실제 요청을 세 번 보내 토큰 처리량과 첫 토큰 시간을 기록합니다. 추정치만 보고 결정하지 않습니다.
- 같은 프롬프트로 반복합니다. 짧은 질의, 긴 문서 요약, 코드 수정처럼 실제 작업 세 가지를 같은 조건에서 실행하고 최저값을 봅니다. 평균이 좋아도 한 작업이 계속 실패하면 해당 용도에서는 탈락입니다.
즉시 중단해야 하는 실패 조건
- 탐지된 VRAM·RAM 또는 GPU 종류가 실제 사양과 다릅니다.
- 비교 후보마다 컨텍스트 길이와 양자화 방식이 달라 결과를 나란히 볼 수 없습니다.
- 모델이 메모리 한계에 붙어 있고 헤드룸을 주면 CPU 전용으로 바뀝니다.
- 벤치마크 공급자가 실행되지 않았거나 실제 모델과 다른 이름으로 연결됐습니다.
- 한 번의 최고 속도만 있고 첫 토큰 지연, 반복 범위, 실패 기록이 없습니다.
최종 선택 기준
대화가 목적이면 첫 토큰이 빠르고 반복 결과가 안정적인 후보가 우선입니다. 긴 문서·코딩이면 목표 컨텍스트에서 메모리 여유를 유지하는지가 더 중요합니다. 데이터가 민감하면 외부 전송 경로와 공급자 설정도 별도로 확인해야 합니다. 가장 큰 모델이 아니라 내 작업 세 가지를 같은 조건에서 끝내고, 여유 메모리를 남기며, 반복 최저값도 허용 범위인 모델을 선택하면 됩니다.