같은 모델인데 왜 내 PC에서만 바보가 될까: 로컬 LLM이 실력을 못 내는 진짜 이유

주말에 큰맘 먹고 그래픽카드를 지른 다음, 화제의 오픈웨이트 모델을 내려받아 돌려봤는데 결과가 처참했던 경험 있으신가요. 분명 벤치마크에서는 상용 API를 따라잡았다고 하는데, 내 컴퓨터에서는 세 번째 질문쯤부터 앞 얘기를 까먹고 헛소리를 시작합니다. 근데 모델 탓이 아닐 공산이 큽니다. 로컬 LLM 커뮤니티에서 몇 년째 반복되는 이야기인데, 대부분의 “우리 집 모델이 멍청한 문제"는 모델 파일이 아니라 그 파일을 돌리는 설정에서 나옵니다.

미리 밝혀두면, 이번 주제는 최근 30일 커뮤니티 데이터가 거의 잡히지 않았습니다. 그래서 특정 스레드의 추천수나 댓글 수를 인용하는 대신, 로컬 LLM 판에서 몇 번이고 검증된 기술적 쟁점 위주로 정리했습니다.

첫 번째 범인: 양자화, 용량을 줄인 만큼 뇌도 줄었습니다

로컬에서 모델을 돌린다는 건 사실상 양자화된 모델을 돌린다는 뜻입니다. 원본 모델은 파라미터 하나를 16비트로 저장하는데, 이걸 4비트나 5비트로 압축해서 용량을 3분의 1 이하로 줄인 게 우리가 받는 GGUF 파일입니다. 이 압축이 무손실이 아니라는 게 문제죠.

경험적으로 Q4 근처가 용량 대비 품질의 손익분기점으로 통합니다. 여기까지는 체감 성능 저하가 크지 않습니다. 그런데 VRAM이 모자라서 Q3, Q2까지 내려가면 이야기가 달라집니다. 문장은 여전히 매끄럽게 나옵니다. 대신 코드에서 변수명을 슬쩍 틀리고 계산에서 자릿수를 놓칩니다. 긴 추론이면 중간 단계를 통째로 건너뛰기도 하고요. 티가 안 나게 망가지는 게 저비트 양자화의 가장 고약한 점입니다.

여기서 흔한 오해가 하나 있습니다. “큰 모델을 심하게 압축하는 게, 작은 모델을 덜 압축하는 것보다 낫다"는 통념인데요. 대체로는 맞는데 3비트 아래로 내려가면 자주 뒤집힙니다. 70B를 Q2로 욱여넣느니 32B를 Q4로 쓰는 편이 실전에서 더 똑똑합니다. 게다가 요즘은 같은 4비트라도 중요한 레이어에 비트를 더 얹는 방식이 흔해졌습니다. 파일명에 붙은 숫자만 보고 고르면 손해를 봅니다.

두 번째 범인은 샘플러 기본값, 창의성이라는 이름으로 정확도를 깎습니다

이게 가장 억울한 케이스입니다. 모델은 멀쩡한데 설정 하나가 답을 망칩니다.

LLM은 다음 단어를 확률로 뽑습니다. 이때 얼마나 과감하게 뽑을지를 정하는 게 temperature, top_p, top_k 같은 샘플러 설정입니다. 여러 로컬 실행 도구는 기본 temperature를 0.7에서 0.8 사이로 잡아둡니다. 소설 쓰기에는 적당한 값이지만 코딩이나 수학, 사실 확인에는 재앙에 가깝습니다. 정답 토큰의 확률이 90%여도 나머지 10%를 굴려서 틀린 길로 빠질 여지를 매번 열어주는 셈이니까요.

더 골치 아픈 건 제작사가 권장하는 값이 모델마다 다르다는 겁니다. 추론 특화 모델은 temperature 0.6에 top_p 0.95를 권하고 어떤 코딩 모델은 아예 0에 가깝게 쓰라고 못 박습니다. 실행 도구는 이 권장값을 자동으로 읽어오지 않는 일이 많습니다. 모델 카드에 적힌 설정을 사람이 손으로 옮겨 넣어야 하죠. 안 그러면 제작사가 맞춰둔 최적점 대신 도구 만든 사람이 정한 범용 기본값으로 돌아갑니다.

repeat penalty도 비슷합니다. 같은 말 반복을 막으려고 넣은 장치인데, 값을 1.1 이상으로 올리면 코드에서 반복해서 나와야 하는 괄호나 들여쓰기, 변수명까지 억제해버립니다. 갑자기 코드 블록이 이상하게 끝난다면 이쪽을 의심해볼 만합니다.

세 번째 범인은 채팅 템플릿입니다. 한 글자 틀리면 다른 모델이 됩니다

파인튜닝된 모델은 정해진 형식으로 대화를 받도록 훈련됐습니다. 어디까지가 시스템 프롬프트고 어디부터가 사용자 발화인지를 특수 토큰으로 구분합니다. 이 형식이 어긋나면 모델은 학습 때 본 적 없는 입력을 받습니다.

증상은 꽤 특징적입니다. 답을 하다가 혼자 다음 질문까지 지어냅니다. 응답 끝에 이상한 태그가 튀어나오기도 하고, 시스템 프롬프트로 준 지시를 대놓고 무시하기도 합니다. 이걸 보고 “이 모델은 지시 따르기가 약하네"라고 결론 내리기 쉬운데, 실은 템플릿이 어긋나 있을 뿐입니다.

요즘 배포 도구는 모델 파일에 박힌 템플릿을 알아서 읽어옵니다. 그런데도 사고는 두 군데서 납니다. 커뮤니티에서 재양자화한 파일에 템플릿 메타데이터가 잘못 들어가 있거나, 사용자가 프런트엔드에서 프롬프트 형식을 손으로 지정해놓고 잊어버렸거나. 특히 추론 모델의 사고 과정 태그를 어떻게 처리하는지는 실행 도구마다 제각각입니다. 같은 모델이라도 어디서 돌리느냐에 따라 결과가 갈립니다.

네 번째 범인: 컨텍스트 창, 128K 모델이 실제로는 4K로 돌아갑니다

체감상 이게 제일 충격적입니다. 모델 카드에는 128K 토큰을 지원한다고 적혀 있는데 실행 도구의 기본 컨텍스트 설정은 여전히 2048이나 4096에 머물러 있기 일쑤입니다. 메모리 부족으로 뻗는 걸 막으려는 안전장치인데, 사용자한테 경고를 안 해주는 게 문제죠.

이 상태에서 긴 문서를 붙여넣으면 앞부분이 조용히 잘려나갑니다. 에러도 안 납니다. 모델은 남은 절반만 보고 성실하게 답합니다. 사용자 입장에서는 “문서를 다 줬는데 왜 절반만 요약하지” 싶어집니다. 대화가 길어질 때 갑자기 초반 맥락을 잊는 현상도 대개 여기서 나옵니다.

하나 덧붙이면, 컨텍스트를 최대로 열어놓는 게 늘 정답은 아닙니다. KV 캐시가 VRAM을 잡아먹어서 정작 모델 레이어가 GPU에 다 못 올라가고 일부가 시스템 메모리로 밀려나면 속도가 몇 배로 느려집니다. 실제 쓰는 길이보다 조금 넉넉한 정도로 잡는 게 낫습니다.

그래서 뭘 확인해야 할까요

순서대로 훑으면 대부분 잡힙니다. 컨텍스트 길이가 실제로 얼마로 잡혀 있는지부터 확인하세요. 그다음은 모델 카드에 적힌 권장 샘플러 값을 그대로 옮겨 넣는 일입니다. 코딩이나 사실 확인 용도라면 temperature를 0.2 이하로 낮춰보시고요. 같은 프롬프트를 다른 실행 도구에서 돌렸을 때 결과가 크게 다르면 템플릿 문제일 확률이 높습니다. Q3 이하를 쓰고 있다면 한 단계 작은 모델의 Q4 버전과 직접 비교해보세요.

로컬 LLM은 “모델을 받으면 끝"인 물건이 아닙니다. 파일과 사용자 사이에 설정 레이어가 최소 네 겹 있고, 그 기본값은 안전이나 범용성에 맞춰져 있지 내 작업에 맞춰져 있지 않습니다. 상용 API를 쓸 때는 제공사가 이 조율을 대신 해줬을 뿐입니다. 지금 쓰는 로컬 모델이 기대에 못 미친다면 모델을 갈아치우기 전에 설정 화면부터 열어보세요. 거기 묶여 있는 성능이 생각보다 많습니다.