llama.cpp Bonsai 2 27B 런타임 병합: Q2_0 정확성 확인, 포크 안내는 유지

가중치 형식만으로는 부족한 이유

모델 카드에 따르면 Bonsai 2는 블록 단위 Hadamard 회전을 가중치에 접어 넣어 저장한다. 그래서 추론 때 활성값에도 대응하는 변환이 들어가야 결과가 맞다.

PTQ1_0과 PQ2_0 파일은 별도 패킹 형식을 쓴다. GGUF 확장자는 컨테이너일 뿐, 런타임이 내부 기능을 모두 구현했다는 보장이 아니다.

주의할 점: 병합과 문서 사이의 불일치

10월 13일 확인한 Prism 모델 카드는 여전히 자체 포크를 안내한다. stock llama.cpp는 PQ2_0와 PTQ1_0을 알 수 없는 형식으로 거부하고, Q2_0는 경고 없이 읽은 뒤 쓸모없는 출력을 낸다고 설명한다.

백엔드 문서도 업스트림 통합을 대기 중으로 적고 모든 Bonsai 2 GGUF에 포크를 쓰라고 한다. 새 업스트림 빌드와 공개된 각 팩의 조합이 어디까지 완성됐는지는 확인되지 않는다.

PTQ1_0 형식은 별도 PR 29672로 이어졌다. 병합 하나가 포괄적인 호환성 발표는 아니다.

백엔드 문서가 나누는 두 가지 지원 표

백엔드 문서는 파일 형식 표와 Hadamard 변환 표를 따로 둔다. 부호 반전과 모델 그래프 변환도 필요하며, 형식 디코딩이나 변환 커널 하나만으로는 부족하다고 명시한다.

이 표는 특정 포크 릴리스 기준의 소스 구현 상태다. 예를 들어 SYCL 경로에서는 PTQ1_0이 PQ2_0 크기 배치로 풀리므로, 파일이 작아도 GPU 메모리가 작다는 보장이 없다.

실행 조합을 하나의 단위로 기록하는 방법

모델 파일명과 리비전, 런타임 커밋이나 패키지 버전, 선택한 기기·백엔드, 실제 실행 인자를 한 조합으로 기록한다. 속도 결과에도 그 조합을 붙인다.

그래야 앱이 내장 런타임을 바꾸거나 모델 저장소가 권장 패킹을 바꾼 뒤에도 성공한 시험을 재현할 수 있다.

로드가 아닌 출력으로 하는 첫 확인

실패가 오류가 아니라 잘못된 텍스트로 나타날 수 있어, 파일 로드나 토큰 출력만으로는 검증이 약하다. 답을 아는 짧은 프롬프트로 시작해 대표 작업으로 넓히는 편이 확실하다.

모델 카드는 기본 추론 강도가 xhigh이고 low는 지원하지 않아 xhigh에 가깝게 동작한다고 설명한다. 출력 예산이 작아 사고 과정이 잘린 것을 백엔드 고장으로 오해하기 쉽다.

병합 이후에 남은 확인 항목

이번 병합으로 하위 앱이 반영할 구체적인 변경이 생겼다. 앱이 관련 런타임과 형식 지원을 문서화하기 전까지는 프로젝트의 버전 고정 안내를 따르고, 속도보다 정확성을 먼저 확인한다.

이 기사에서는 하드웨어나 모델을 실행하지 않았다.

업스트림 병합은 출발점이고, 어떤 파일이 어떤 빌드와 백엔드에서 맞게 도는지는 여전히 조합별로 확인할 일이다.