cat >> artigo.txt << EOF

최근 소셜 미디어에서 Bonsai 27B라는 모델이 화제가 되고 있습니다. 솔직히 말해서, 처음에는 그저 케이스를 팔기 위한 또 하나의 "압축 기록"일 뿐이라고 생각했습니다. Prism ML(Caltech의 스핀오프 팀)이라는 팀이 Qwen 3.6을 가져와서, 원래 FP16에서 약 54GB의 용량을 차지하는 270억 개 파라미터(parameters) 모델을 휴대폰에 통째로 들어갈 수 있도록 4GB 미만으로 줄이는 데 성공했습니다.

이것은 결코 작은 일이 아닙니다. 이와 같은 공격적인 압축(Compression)은 보통 노이즈가 되기 마련입니다. 모델이 더 많이 환각(hallucination)을 일으키고, 기본적인 규칙을 잊어버리며, 간단한 작업에서 막히게 됩니다. 그래서 제가 답하고 싶었던 질문은 "작동할까?"가 아니라, 정확히 어느 지점에서 무너지는가였습니다.

두 가지 버전, 두 가지 철학

Bonsai는 두 가지 버전으로 제공됩니다:

• Ternary (삼진법): 각 가중치(weight)가 세 가지 가능한 값 중 하나로 저장됩니다. 용량은 약 7.2GB입니다.
• 1-bit: 각 가중치가 말 그대로 양수 또는 음수의 신호가 됩니다. 용량은 약 3.9GB로, 원본보다 14배 작습니다.

비교가 의미 있으려면, "부모 모델"(Qwen 3.6)을 가공되지 않은 FP16 상태로 테스트해서는 안 됩니다. 아무도 집에서 54GB를 돌리지는 않으니까요. 저는 사람들이 일상적으로 사용하는 것과 동일한 Q4 양자화(quantization) 상태인 약 16.8GB로 테스트했습니다. 즉, 실험의 "대조군"조차 이미 압축된 상태였지만, 이는 전통적인 방식이었습니다. 진짜 질문은 이것이었습니다: Q4를 넘어선 압축이 더 나은 방향으로든, 나쁜 방향으로든 무언가 추가적인 가치를 제공하는가?

압축의 고통이 실제로 나타나는 지점

가장 명백한 것부터 시작했습니다: 흩어진 사실적 지식(factual knowledge). 매우 구체적인 역사적 사건이 몇 년도에 일어났는지 각각 여러 번 질문했습니다.

• 원본 모델은 100% 정확했습니다.
• Ternary 모델은 6번의 시도 중 단 한 번만 맞췄습니다.
• 1-bit 모델은 단 한 번도 맞추지 못했습니다. 심지어 시도할 때마다 매번 다른 날짜를 추측했으며, 거의 한 세기 가까운 차이가 나는 오류를 범하기도 했습니다.

이는 이론적으로 이미 예상되었던 사실을 확인시켜 줍니다. 모델을 압축하면 훈련 과정에서 적게 나타나는 정보부터 먼저 삭제된다는 점입니다. 매우 구체적인 사실(예: 역사적 사건의 정확한 날짜)은 빠르게 사라집니다. 반면, 데이터에 끊임없이 등장하는 일반적인 언어 패턴과 추론 능력은 훨씬 더 잘 살아남습니다.

실질적인 결론: 만약 당신이 일반적인 지식을 갖춘 챗봇, 즉 단편적인 질문에 답하거나 잘 모르는 주제를 요약해 줄 모델을 원한다면, 이 모델은 적합하지 않습니다. Ternary(3비트) 모델도, 1-bit 모델도 마찬가지입니다. 여기서 발생하는 성능 저하는 무시하기에는 너무나 명확합니다.

압축이 전혀 타격을 주지 않는 영역

하지만 여기서 흥미로운 부분이 등장합니다. 코딩 작업에서는 이야기가 완전히 달라집니다.

저는 실제 Race Condition(경쟁 상태)을 포함한 고전적인 버그들을 테스트했습니다. 이는 잠금(Lock) 없이 두 트랜잭션이 동일한 잔액을 건드리는 상황으로, 실행 순서가 어긋난 상태에 대해 추론해야 하기에 업계에서 까다로운 버그로 문서화하는 유형입니다. 운이 아니었음을 보장하기 위해 각 수정 사항을 세 번씩 연속으로 실행했습니다.

결과: 세 모델(Original, Ternary, 1-bit) 모두 동일하게 해결했습니다. 세 모델 모두 9번 중 9번을 맞췄습니다. 차이가 전혀 없었습니다.

가장 가능성 높은 설명은 "압축된 모델들이 천재적이다"가 아니라, 이처럼 분류된 유형의 버그는 오늘날의 어떤 현대적 훈련 데이터에도 이미 충분히 표현되어 있다는 것입니다. 인간에게 어렵다고 해서 모델이 이미 본 적 없는 데이터라는 뜻은 아닙니다.

세 모델을 진정으로 구분해 내기 위해, 저는 개방형 작업(Open task)으로 넘어가야 했습니다. 각 모델에게 특정 디자인 시스템(Design system)에 연결된 React 애니메이션 라이브러리를 사용하여 새로운 프로그래밍 방식의 시각적 구성을 생성하도록 요청했습니다. 그리고 여기서 제가 예상치 못했던 발견이 나타났습니다.

시간이 촉박할 때는 능력이 속도보다 중요하다

첫 번째 시도에서 세 모델 모두 틀렸지만, 그 방식은 매우 달랐습니다:

• 1-bit 모델은 14개의 오류를 범했지만, 모두 피상적이고 지적하기 쉬운 것들이었습니다 (지어낸 색상 이름, 잘못된 배열 구문).
• ternary (삼진법) 모델은 훨씬 더 구조적인 13개의 오류를 범했습니다 (존재하지 않는 경로의 import, 잘못된 인수로 호출된 함수).
• 압축이 전혀 없는 **original model (원본 모델)**은 첫 번째 시도에서 파일을 아예 생성하지 못했습니다. 참조를 읽는 데에만 모든 시간을 소비했습니다.

하지만 결과는 저를 가장 놀라게 했습니다. 가장 압축된 모델(1-bit)은 단 두 번의 시도 만에 오류 없이 작업을 마쳤습니다. ternary 모델은 수렴하는 데 10번의 시도가 필요했으며, 그 과정에서 서버의 그래픽 백엔드를 중단시키기도 했습니다 (실제 메모리 오류로 인해 모든 것을 처음부터 다시 시작해야 했습니다). 모든 능력이 온전한 원본 모델은 무언가를 쓰기 전에 코드를 탐색하는 데 너무 많은 시간을 소비하여 4번의 시도가 걸렸습니다.

세 모델 모두 버그 자체에 대한 추론 능력에는 문제가 없었습니다. 모두 무엇을 변경해야 하는지는 알고 있었습니다. 진짜 차이점은 각 모델이 자신의 편집 도구를 어떻게 다루느냐에 있었습니다. 마감 기한과 타임아웃(timeout)이 있는 작업에서, 우연히 가장 압축된 형태인 가장 빠른 모델만이 합리적인 시간 예산 내에 결과물을 제출했습니다. 더 많은 파라미터(parameter)를 가졌다고 해서 작업을 더 먼저 끝낸다는 의미는 아닙니다.

아무도 말해주지 않는 마찰(friction)

멋진 벤치마크(benchmark)를 논하기 전에 귀찮은 디테일이 하나 있습니다. Bonsai는 로컬 모델 실행에 가장 흔히 쓰이는 도구인 Ollama에서 실행되지 않습니다. ternary 버전은 Apple의 표준 MLX에서 실행되지만, 1-bit 버전은 Prism ML이 직접 만든 커스텀 포크(fork)와 사전 컴파일된 바이너리가 필요합니다.

게다가 하나 더 있습니다. 표준 MLX에서 ternary 모델은 결정론적(determinism) 버그를 보였습니다. 설정된 온도(temperature)와 상관없이 항상 바이트 단위로 정확히 동일한 답변만을 반환했습니다. 이 문제는 1-bit 모델과 동일한 커스텀 런타임(runtime)으로 교체함으로써 해결했습니다.

교훈은 이렇습니다: 압축이 공격적일수록 모델은 자체적인(표준이 아닌) 인프라에 더 의존하게 됩니다. 이는 "접근성 (accessibility)"이라는 단어가 암시하는 바와 정반대라는 점에서 다소 아이러니합니다. 만약 당신이 바이너리(binary)를 만지거나 서버 설정을 조정하는 데 인내심이 없다면, 첫 번째 질문을 입력하기도 전에 실질적인 마찰(friction)을 겪게 될 것입니다.

또한 기록해둘 점이 있습니다: 첫 번째 시도에서 1-bit 모델은 도구(tool)를 전혀 호출하지 않고, 단지 자신이 무엇을 할 것인지 텍스트로 설명하기만 했습니다. 이는 모델의 한계처럼 보였으나, 실제로는 설정 오류였습니다(대화 템플릿이 일반적인 것으로 바뀌었거나, 시스템 프롬프트(system prompt)를 수용하기에 컨텍스트(context)가 너무 작았던 문제). 이를 수정한 후에는 문제없이 도구를 호출하기 시작했습니다. 여기서 경고를 드립니다: 모델이 무언가를 "할 수 없다"고 결론 내리기 전에, 당신의 설정을 먼저 확인해 볼 가치가 있습니다.

그리고 에이전트적 사용(agentic use)에 대한 경고는?

Prism ML 자체에서도 이 모델이 많은 파일을 다루는 긴 에이전트적 사용에는 권장되지 않는다고 경고합니다. 바로 그 지점이 수학이나 고립된 코드보다 훨씬 더 큰 규모에서, 그들의 내부 벤치마크(benchmark) 성능이 가장 많이 떨어지는 부분이기 때문입니다.

제 테스트에서는 작업을 하나씩 실행했을 때 그러한 성능 저하를 목격하지 못했습니다. 하지만 그들이 설명하는 장기적이고 다중 파일(multi-file)로 구성된 프로젝트 유형은 제가 몇 시간 동안 테스트할 수 있었던 그 어떤 것보다 훨씬 더 큽니다. 따라서 두 가지 해석 모두 가능합니다. 즉, 실제 프로젝트의 규모에 따라 달라질 것입니다. 실질적으로 남는 조언은 다음과 같습니다: Bonsai를 에디터에 연결하여 질문에 하나씩 답하고 코드 조각을 검토하는 방식으로 사용하십시오. 터미널 하네스(harness)에 풀어놓은 자율 에이전트로서, 중간에 아무도 개입하지 않은 채 턴(turn)마다 스스로 여러 파일을 편집하기로 결정하게 만드는 방식으로는 사용하지 마십시오. 이 모델은 훌륭한 코파일럿(copilot)입니다. 오토파일럿(autopilot)이 되도록 만들어지지는 않았습니다.

판결

만약 당신이 범용 지식 어시스턴트를 원한다면: 멀리하십시오. 그 부분에서의 품질 저하는 무시하기에는 너무 크고 일관적입니다.

만약 당신이 이 모델을 눈여겨보는 이유가 유료 플랜의 토큰을 소비하지 않고, 퇴근 후 집에서 코딩(coding)을 하기 위해서라면: 두 가지 압축 모델 모두 원본 모델이 해결했던 문제들, 즉 고전적인 버그부터 전형적인 기술 면접 문제까지 정확히 해결해 냈습니다. 심지어 테스트된 유일한 개방형 실무 과제에서는 두 모델 중 가장 압축된 모델이 가장 먼저 작업을 완료했습니다.

두 자식 모델 중 저의 추천은 ternary(삼진) 모델이 아닌 1-bit 모델입니다. 더 작고 빠르며, 두 모델이 직접 경쟁했던 유일한 상황에서 인프라 중단 현상 없이 10번의 시도가 필요했던 ternary 모델에 비해 단 2번의 시도 만에 수렴했습니다. ternary 모델은 사실적 지식(factual knowledge) 측면에서 약간 더 높은 정밀도를 제공하지만, 다른 단점들을 상쇄할 만큼은 아닙니다.

또한 간과하기 쉬운 용도가 하나 더 있습니다: 기기의 작은 부분(약 5GB RAM)을 할당하여 Bonsai를 상주시키고, 더 큰 파이프라인 내에서 간헐적인 질의를 해결하기 위해 항상 로컬에서 실행하는 것입니다. 프로젝트의 메인 브레인은 아니지만, 기기를 벗어나거나 API 토큰을 소비하지 않고 간단한 질문을 해결해 주는 저렴한 부품 역할을 합니다. 실제로 독립적인 벤치마크(Benchmarks)에서도 Bonsai는 광범위한 작업 세트에서 원본 Qwen보다 8~12점 뒤처지는 것으로 나타났는데, 이는 지식 테스트 결과와 일치합니다. 즉, 성능 저하는 존재하지만 대부분의 사람들이 찾는 영역에서는 나타나지 않는 것입니다.

270억 개의 파라미터(parameters)를 가진 모델을 코딩 능력이나 도구 사용(tool use) 능력에서 측정 가능한 손실 없이 4GB 미만으로 들어오도록 14배 압축한 것은 진정으로 인상적인 엔지니어링 성과입니다. 계산은 맞습니다. 다만 그 계산 결과가 "일반 지식"보다는 훨씬 더 특정한 영역에 맞춰져 있으며, 이 점이 이 모델을 사용할 가치가 있는지에 대한 관점을 완전히 바꿔 놓습니다.

EOF