같은 로컬 LLM도 실행 환경에 따라 답이 달라져요

같은 로컬 LLM도 실행 환경에 따라 답이 달라져요

AI 뉴스 썸네일

같은 모델 파일을 내려받았는데 공식 서비스나 다른 사용자의 결과보다 답이 둔하게 느껴질 때가 있어요. 원인은 모델 가중치만이 아닐 수 있어요. GPU, 추론 엔진, 어텐션 백엔드, 양자화와 KV 캐시 정밀도가 달라지면 다음 토큰의 계산 결과도 달라져요. 긴 문맥과 도구 호출에서는 작은 수치 차이가 실제 작업 성공 여부까지 바꿀 수 있어요. 1

핵심 요약

구분	내용
실행 환경	같은 가중치라도 GPU 명령어, CUDA 커널, 추론 엔진에 따라 출력 분포가 달라질 수 있어요.
어텐션	약 10만 토큰 문맥에서 백엔드만 바꿔도 후반부의 최상위 토큰 선택이 달라졌어요.
KV 캐시	가중치를 BF16으로 유지해도 KV 캐시를 INT8·INT4로 낮추면 도구 호출 결과가 달라졌어요.
가중치 양자화	비트 수만으로 품질 순서를 정하기 어려워요. 양자화 방식과 실행 커널까지 함께 봐야 해요.
평가 방법	짧은 질문 몇 개보다 실제 문맥, 도구 호출, 도메인 작업으로 실행 환경 전체를 확인해야 해요.

1. 모델 파일보다 넓은 범위에서 성능을 봐야 해요

로컬 LLM의 출력은 가중치 하나로 정해지지 않아요. 추론 엔진은 GPU 명령어와 CUDA 커널을 거쳐 로짓을 계산하고, 샘플러가 다음 토큰을 고른 뒤 텍스트로 바꿔요. 이 과정에서 하드웨어 세대나 커널 구현이 달라지면 같은 입력과 가중치에서도 확률분포에 작은 차이가 생길 수 있어요. 2

작은 차이가 매번 눈에 띄는 것은 아니에요. 하지만 생성한 토큰이 다음 입력에 다시 포함되는 생성 과정에서는 한 번의 선택 차이가 이후 경로를 바꿔요. 자연어 답변에서는 표현 차이로 끝날 수 있지만, JSON 형식이나 도구 이름과 인수를 맞춰야 하는 작업에서는 오류로 이어질 수 있어요.

728x90

어텐션 백엔드만 바꿔도 다음 토큰이 달라졌어요

원문 작성자는 Qwen3.6-27B의 공식 BF16 체크포인트와 RTX PRO 6000 Blackwell GPU를 사용했어요. 약 10만 토큰 길이의 실제 작업 문맥을 재생하면서 FlashAttention 2, Flash Inference, Triton Attention을 비교했어요. 하드웨어와 나머지 소프트웨어 조건은 고정하고, 전체 어텐션을 처리하는 백엔드만 바꿨어요.

세 백엔드는 문맥 초반에 거의 같은 결과를 냈어요. 뒤로 갈수록 최상위 로짓을 가진 토큰이 달라지는 지점이 늘었어요. 차이는 문맥 길이에 비례해 고르게 커지지 않았어요. 특정 내용이 나온 구간에 몰렸기 때문에 몇 토큰을 넘으면 모델이 갑자기 무너진다고 해석하기는 어려워요. 같은 백엔드를 같은 조건에서 반복한 대조 실험은 비트 단위로 같은 결과를 냈어요. 관찰된 차이가 단순한 무작위 실행 때문은 아니라는 뜻이에요. 2

KV 캐시 정밀도도 실제 작업에 영향을 줘요

KV 캐시는 이전 토큰의 어텐션 계산 결과를 저장해 긴 문맥을 빠르게 처리해요. 문맥이 길어질수록 메모리를 많이 쓰기 때문에 INT8이나 INT4로 압축하는 설정을 자주 사용해요. 이 설정은 모델 가중치를 건드리지 않지만 출력에는 영향을 줄 수 있어요.

실험에서는 BF16 가중치를 유지한 채 KV 캐시 정밀도만 바꿨어요. 실제 도구 호출 구간에서 BF16은 정상 처리했어요. INT8은 한 차례 오류를 낸 뒤 스스로 복구했어요. INT4는 같은 오류에서 회복하지 못했어요. 한 사례만으로 모든 모델과 작업에 같은 순서를 적용할 수는 없어요. 그래도 메모리 절약 설정이 응답의 말투만 바꾸는 것이 아니라 작업 완료 여부에도 영향을 줄 수 있다는 점은 확인할 수 있어요. 2

8비트와 4비트라는 숫자만 비교하면 놓치는 부분이 있어요

가중치 양자화 비교에서도 단순한 비트 수가 품질을 충분히 설명하지 못했어요. BF16을 기준으로 FP8, INT8 W8A16, NVIDIA NVFP4, AWQ W4A16을 비교했는데, INT8 W8A16이 공식 FP8과 NVFP4보다 기준 출력에 가까웠어요. NVFP4는 88k 문맥의 측정 위치 가운데 약 절반에서 최상위 토큰이 달랐어요.

양자화는 가중치와 활성값 가운데 무엇을 낮추는지, 레이어별로 어떤 방식을 쓰는지, 어떤 커널로 계산하는지에 따라 결과가 달라져요. 같은 4비트 파일이라도 포맷과 보정 데이터, 런타임이 다르면 체감 품질을 같은 범주로 묶기 어려워요. 메모리 사용량과 처리 속도를 비교할 때도 모델 이름과 파일 크기만 적기보다 양자화 방식, KV 캐시 정밀도, 추론 엔진 버전을 함께 기록하는 편이 좋아요.

KLD가 낮다고 더 똑똑한 모델은 아니에요

KL Divergence(KLD)는 한 출력 확률분포가 기준 분포에서 얼마나 달라졌는지 재는 값이에요. 낮을수록 선택한 기준에 가깝다는 뜻이에요. 작업 정확도나 추론 능력을 바로 뜻하지는 않아요.

모델 카드의 KLD 수치를 비교하려면 기준 체크포인트와 전체 런타임, 평가 텍스트, 보정 데이터, 문맥 길이, 측정 위치를 알아야 해요. KL 계산 방향과 토큰 집계 방식도 필요해요. 조건이 빠진 숫자 하나로 서로 다른 양자화 모델의 품질을 순위 매기면 실제 사용 결과와 어긋날 수 있어요. 2

로컬 환경에서는 실제 작업을 그대로 재현해 보는 편이 좋아요

짧은 제로샷 질문이나 temperature 0 설정만으로는 긴 작업의 실패 지점을 찾기 어려워요. 로컬 LLM을 코딩, 문서 처리, 네트워크 운영에 쓴다면 평소와 비슷한 길이의 입력과 도구 호출을 포함한 평가가 필요해요. JSON 스키마 준수율, 도구 호출 성공률, 오류 후 복구 여부처럼 작업 단위의 결과를 기록하면 설정 차이를 비교하기 쉬워요.

비교할 때는 한 번에 하나의 조건만 바꾸는 편이 좋아요. 먼저 공식 권장 채팅 템플릿과 샘플러 설정을 맞춰요. 그다음 추론 엔진과 어텐션 백엔드, 가중치 양자화, KV 캐시 정밀도를 차례로 바꾸면 품질 저하가 생긴 지점을 좁힐 수 있어요. 속도와 메모리만 기록하지 말고 실제 작업의 성공 여부도 함께 남겨야 해요.

왜 중요한가요

로컬 LLM은 모델을 직접 보유하고 실행 환경을 통제할 수 있다는 장점이 있어요. 그만큼 품질 책임도 모델 제작사와 로컬 런타임 사이에 나뉘어요. 같은 모델 이름을 쓴다는 이유만으로 공식 벤치마크나 다른 하드웨어의 결과가 그대로 재현된다고 기대하기는 어려워요. 2

팀에서 로컬 모델을 운영한다면 배포 사양에 가중치 파일만 적어 두기에는 부족해요. GPU 종류, 드라이버와 CUDA 버전, 추론 엔진 빌드, 어텐션 백엔드, 샘플러, 채팅 템플릿, KV 캐시 정밀도까지 실행 사양으로 관리해야 해요. 이 정보를 고정하면 성능 회귀가 모델 교체 때문인지 런타임 변경 때문인지 찾기 쉬워져요.

양자화 설정은 비용과 품질 사이의 선택이에요. 더 작은 파일이 무조건 나쁜 것도 아니고, 더 높은 비트가 모든 작업에서 가장 좋은 것도 아니에요. 실제 업무 문맥에서 필요한 정확도와 도구 호출 성공률을 유지하는 가장 작은 설정을 찾는 방식이 현실적이에요. 이번 결과는 한 모델과 제한된 실행 환경에서 나온 실험이므로 다른 모델과 GPU에서도 직접 재현해 봐야 해요.

참고 자료

1. 로컬 LLM이 실제 성능보다 더 멍청하게 느껴지는 이유 — GeekNews
2. Why your local LLM feels dumber than it is — Level1Techs Forums