Qwen 27B 1비트 로컬 모델은 실무에 쓸 만한가: 속도와 품질을 가르는 조건

Qwen 27B를 1비트로 줄여 로컬에서 돌렸다는 경험은 흥미롭다. 하지만 모델이 실행된다는 사실만으로 작업을 맡길 수 있는지는 알 수 없다. 로컬 모델은 실무 도구인가, 아니면 구동 자체가 더 재미있는 실험인가?

‘Qwen 27B 1비트’라는 말부터 구분해야 한다

클코단에서는 Qwen 27B의 초저비트 버전을 구동해봤다는 이야기가 나왔다. 직접 돌려보는 재미에 공감하는 의견과 프론티어 모델을 대신하기에는 부족하다는 의견이 갈렸다. 다만 대화에 정확한 모델 세대와 양자화 파일명은 없다. 특정 제품의 성능 평가로 확대할 근거는 없는 셈이다.

양자화는 모델의 가중치를 더 적은 비트로 저장해 메모리 부담을 줄이는 방식이다. 여기서 ‘1비트’는 파일을 확인하기 전까지 정확한 사양이 아니다. llama.cpp의 양자화 목록만 봐도 Q1_0은 가중치당 1.125비트, IQ1_S는 1.56비트로 표기된다. 같은 1비트 계열이라는 소개만으로 두 파일의 크기와 품질을 같다고 취급할 수 없다. (github.com)

처음부터 저비트 구조로 학습한 모델과 학습을 마친 Qwen을 나중에 압축한 모델도 다르다. 마이크로소프트의 BitNet 자료는 자사 모델을 처음부터 저비트 방식으로 학습했다고 명시한다. Qwen 27B의 양자화 파일을 BitNet과 동일한 방식으로 만들어진 ‘네이티브 1비트 모델’이라고 부르면 안 되는 이유다. (github.com)

모델이 들어가는 것과 문맥이 들어가는 것은 다르다

압축한 가중치가 메모리에 들어가도 작업은 끝나지 않는다. 대화와 입력 내용을 처리하는 캐시, 실행 프로그램, 운영체제에도 공간이 필요하다. 특히 긴 문서를 넣거나 도구를 여러 차례 호출하면 처음의 짧은 질문과는 메모리 조건이 달라진다. 개인 개발자가 모델 파일 크기만 보고 장비 적합성을 판단하기 어려운 이유다.

Qwen이 공개한 Qwen3.8-27B의 기본 문맥 길이는 26만 2144토큰이다. 이 수치는 로컬 컴퓨터에서 언제나 그 길이를 쾌적하게 처리한다는 보증이 아니다. 참고로 Ollama가 제공하는 Qwen3.5 27B 항목은 다운로드 크기를 약 17~20GB로 표시한다. 세대와 배포 형식이 다른 수치이므로 방에서 언급된 1비트 파일의 실제 크기를 대신하지는 않는다. (huggingface.co)

실행을 재현하려면 모델 이름보다 파일과 설정을 먼저 기록해야 한다. GGUF 파일을 쓴다면 배포 저장소에서 양자화 종류를 고르고 llama.cpp의 llama-server에 파일 경로와 문맥 길이를 지정할 수 있다. 같은 질문을 각 설정에 입력한 뒤 답변뿐 아니라 첫 응답까지의 시간, 메모리 사용량, 작업 완료 여부를 남긴다. llama.cpp 문서는 GGUF 모델 실행과 서버의 문맥 길이 설정을 안내한다. (github.com)

빠른 출력이 곧 빠른 작업 완료는 아니다

로컬 모델의 인상은 추론 서버에 따라서도 바뀐다. Apple Silicon용 oMLX는 모델을 제공하는 서버로, 반복해서 등장하는 입력 앞부분을 KV 캐시에 보관한다. 프로젝트 지침처럼 같은 내용이 다시 들어오면 앞부분을 재계산하는 부담을 줄일 수 있다. 여러 요청을 함께 처리하는 기능과 토큰 생성·입력 처리 속도를 따로 측정하는 화면도 제공한다. (github.com)

그렇다고 캐싱이 모델의 추론 능력을 높여주지는 않는다. 반복 입력에서 얻는 시간 절약과 처음 보는 문제를 정확히 푸는 능력은 서로 다른 항목이다. 제공된 사용 사례에는 oMLX에서 빠른 출력 속도를 관찰했다는 경험도 담겨 있다. 해당 수치를 다른 컴퓨터나 모델에서도 얻는 성능으로 일반화할 수는 없다.

실사용에서도 평가는 엇갈린다. 써본 사람들 사이에는 작은 작업은 맡길 만하지만 긴 코딩 과정에서는 응답 지연과 반복적인 추론이 부담스럽다는 반응이 있다. 반대로 도구 연결과 작업 범위를 조정하니 유용해졌다는 의견도 나온다. 어느 쪽도 모든 Qwen 27B 양자화 파일에 적용되는 판정은 아니다.

프론티어 모델과 비교할 때 빠뜨리기 쉬운 조건

클코단의 회의론은 한 번 생성한 문장의 품질보다 작업 전반의 신뢰도를 묻는 의견에 가깝다. 코드 작업이라면 지시를 이해하고 필요한 파일을 고른 뒤 도구를 호출해 오류를 수정해야 한다. 처음 답이 그럴듯해도 뒤의 단계에서 막히면 사람의 확인 시간이 늘어난다.

한편 로컬 모델 전체를 ‘장난감’으로 묶기도 어렵다. Qwen이 공개한 Qwen3.8-27B의 평가표는 Terminal Bench 2.1에서 73.0점, 비교 대상으로 제시한 Opus 4.6 Max에서 78.2점을 기록했다. 같은 표의 다른 코딩 시험에서는 순서가 달라진다. 다만 이 결과는 Qwen의 평가 조건에서 얻은 점수다. 방에서 사용한 미확인 1비트 파일의 점수도, 개별 개발자의 프로젝트 완료율도 아니다. (huggingface.co)

공정한 비교에는 같은 입력과 성공 기준이 필요하다. 예를 들어 이미 테스트가 있는 저장소에서 함수 하나를 고치게 하고 양쪽 모델에 동일한 지침과 파일 접근 범위를 준다. 이어 테스트 통과, 잘못 바꾼 파일, 재시도 횟수, 사람이 수정한 시간을 함께 비교한다. 출력 토큰 속도만 재면 클라우드 모델의 대기 시간은 보이지만 실패를 복구하는 데 든 시간은 빠진다.

개인 개발자의 선택은 작업 단위에서 갈린다

로컬 실행의 이점은 모델 선택과 실행 환경을 직접 통제할 수 있다는 점이다. 반복 입력이 많은 작업에는 캐싱도 도움이 될 수 있다. 반면 기기의 메모리가 부족하거나 긴 문맥이 꼭 필요하다면 더 강한 압축은 품질 손실을 감수하게 만들 수 있다. 1비트 구동 성공을 실무 도입의 최종 근거로 삼기 어려운 까닭이다.

작은 팀이라면 같은 Qwen 27B에서 양자화 수준만 바꿔 비교하는 편이 질문에 더 정확히 답한다. 1비트 계열, 메모리에 여유를 둔 상위 비트 파일, 기존에 쓰던 클라우드 모델에 같은 일을 시켜본다. 한 번의 멋진 결과보다 열 번의 수정 요청에서 몇 번을 끝냈는지가 유용하다.

로컬 모델이 장난감인지 묻는 질문에는 모델 이름 하나로 답할 수 없다. 방의 구동 경험은 실행 가능성을 보여주지만 품질 평가는 남겨둔다. 그 간극을 메우는 값은 초당 토큰 수가 아니라 정해둔 작업을 사람의 추가 수정 없이 마친 비율이다.