로컬 LLM 성능은 모델보다 양자화·채팅 템플릿·샘플러 설정에서 먼저 흔들림

맥북 프로에서 Qwen 3.8 27B MLX를 돌려봤는데, 생각보다 전혀 멍청하지 않아서 놀랐음.

M4 Pro에서 돌리면 발열이 너무 심한데, 다른 사람도 같은지 궁금함.

M5 48GB 맥북 프로에서 검열을 푼 Qwen 3.8을 돌리는 중임. 로컬에서 제약 없이 실험하기 좋더라.

8GB VRAM 게임용 PC에서 Qwen 3.8 27B가 4 tok/s로 느렸지만 pi.dev용 웹 검색·수집 스킬을 한 번에 만들었음. 예전 모델은 에이전트 작업에서 전부 실패했는데, Gemma 4 12B QAT 4비트는 32k 컨텍스트에서 80 to 120 tok/s가 나와서 개인용으로 쓸 만했음.

48GB M4 Pro에서 LM Studio와 pi로 기존 코드베이스 문제를 맡겼더니 20분 동안 헛돌다가 죽었음. 내가 pi를 잘못 쓰는 건지도 모르겠지만 결과가 정반대였음.

H100에서 로컬 GPT-OSS 80GB를 돌려봤는데도 너무 멍청해서 놀랐음.

로컬 모델이 멍청해지는 가장 흔한 이유는 양자화보다 채팅 템플릿임. GGUF 배포본이 메타데이터의 템플릿을 빼버리면 런타임이 ChatML로 조용히 대체하고, 말은 되는데 성능이 눈에 띄게 떨어짐. 그다음은 공급자 권장값 대신 UI 기본값으로 샘플링하는 경우임.

TextGen과 llama.cpp를 LocalAI로 옮기며 API 동작을 비교 중인데, 기본값과 Jinja를 맞춰도 예상 밖 차이가 나더라. 익숙한 도구라도 저장소 구현을 직접 읽어야겠다는 생각이 들었음.

Ollama는 설치와 관리가 쉬워서 쓰는데 추론 품질 자체에 문제가 있는지 궁금함. vLLM은 동시 요청 배치가 장점이라고만 알았고, 윈도우에서는 쓰기 불편함.

Ollama 사용자는 자기가 어떤 양자화를 쓰는지 모르는 경우가 많음. Qwen 3.8 27B를 써봤다고 해도 Ollama의 Q4 결과라면 BF16 가중치 성능을 말하는 게 아니며, llama.cpp를 직접 쓰면 가중치도 스스로 관리하게 됨.

Ollama 바이너리 대신 GPU와 CPU 옵션을 맞춰 컴파일한 llama.cpp를 쓰니 같은 모델이 두 배 빨라졌음. 왜 그랬는지는 다시 확인 안 했지만, 하드웨어와 작업량에 맞춰 조절할 수 있는 옵션 때문에 llama.cpp를 계속 씀.

4090에서 검열 해제 Qwen 3.8 Q4_K_P로 2026 CrackMe CTF를 반복 실행 중임. Codex는 CTF 파일을 읽자마자 중단했지만, 로컬 모델에는 그런 제약이 없었음.

클라우드 모델로 코드베이스의 보안 문제를 먼저 찾고 보고서를 만들고, 로컬 모델에는 그 내용을 넣어 테스트를 작성하거나 취약점이 실제인지 검증하게 함.

WSL의 Ubuntu 26.04에서 5090과 sglang으로 Qwen3.8 27B NVFP4를 96k 컨텍스트, medium reasoning으로 돌리니 150 tok/s 이상 나왔음. opencode로 고전 세로형 슈팅 게임도 문제 없이 만들었음.

나는 KV 캐시를 양자화하지 않고, 모델 양자화도 가능한 한 Q8보다 낮추지 않는 편임. 느려도 출력 정확도에 더 신뢰가 감.

내부 테스트에서는 Qwen3.8 27B의 4비트 양자화도 Gemini 3.7 Flash와 구별하기 어려웠음. RTX 5090과 ninfer에서는 동시성 8일 때 약 800 TPS, 단일 스트림은 약 140 tok/s가 나왔음.

Anthropic이 어느 날 서비스 품질을 낮추는 것보다 로컬 모델은 내가 품질을 통제할 수 있다는 점이 좋음.

시스템 프롬프트와 컨텍스트 창 관리 설명에는 동의함. 인기 실행기의 기본 양자화가 FP16보다 논리 성능을 얼마나 떨어뜨리는지, 특히 긴 컨텍스트 추론에서 KV 캐시 압축 영향도 측정했는지 궁금함.