프로파일링 베이스라인을 조용히 초기화하는 패리티 수정

llama.cpp b9437: llama-bench에 -fa auto 추가, -ngl 기본값이 -1로 전환. 무엇이 바뀌고 누가 영향받는지.

프로파일링 베이스라인을 조용히 초기화하는 패리티 수정
Share

llama-bench로 모델을 프로파일링한다면, 2026년 5월의 작은 빌드 하나가 기본값 두 개를 조용히 바꿨다는 점을 알아야 합니다 — 예전 수치와 새 수치가 더 이상 맞아떨어지지 않을 만큼이요.

b9437의 정체와 변경 내용

b9437은 ggml-org/llama.cpp의 단일 PR 증분 태그로, 2026년 5월 30일에 공개되었습니다 — 마일스톤 릴리스가 아닙니다. llama.cpp는 선별된 시맨틱 버전을 따로 제공하지 않습니다. master에 머지되는 거의 모든 커밋마다 새 태그 빌드를 생성해, 하루에 약 1~3개의 태그가 만들어집니다 . 따라서 b9437의 실질적인 변경 내역은 해당 PR 제목 하나로 요약됩니다.

핵심 정리: b9437은 2026년 5월 30일의 per-commit llama.cpp 태그로, PR #23714 "Support -fa auto in llama-bench" 하나만 포함합니다. 벤치마크 하니스의 기본값 두 가지 — Flash Attention과 GPU 레이어 오프로드 — 를 변경하며, 파일 두 개(108줄 추가, 51줄 삭제)만 수정됩니다. 추론 런타임, 모델 형식, API에는 영향이 없습니다.

전체 변경 사항은 PR #23714, "Support -fa auto in llama-bench,"로, gaugarg-nv가 작성하고 두 번의 승인과 27개의 통과 검사를 거쳐 머지되었습니다 . tools/llama-bench 하위 파일 두 개 — llama-bench.cppREADME.md — 만 수정되어 108줄이 추가되고 51줄이 삭제되었습니다 .

실질적인 효과는 llama-bench 하니스 내부 규칙 두 가지의 변경입니다: Flash Attention 기본값 변경과 GPU 레이어 오프로드 기본값 재해석. 추론 런타임, 모델 형식, 양자화, API에는 어떤 영향도 없습니다. 발행 주기도 눈여겨볼 만합니다. 조사 시점에 인덱스에는 b9611(2026년 6월 12일)이 Latest로 표시되어 있었으며 , b9437은 이미 한참 뒤처진 과거 시점으로 보는 편이 적절합니다.

불리언에서 열거형으로: -fa 파라미터 리팩터

The parity fix that quietly resets your profiling baseline

b9437의 핵심은 llama-bench-fa/--flash-attn 플래그가 이진(boolean) 상태에서 벗어나, on·off·auto 세 가지 값을 받는 설정으로 바뀐 것입니다 — 기본값은 이제 auto입니다 . 이전에는 Flash Attention을 켜거나 끄는 것만 가능했지만, llama-serverllama-cli는 이미 모델과 백엔드에 따라 런타임에서 활성화 여부를 결정하는 auto 모드를 지원하고 있었습니다. PR #23714는 이 간극을 메웁니다.

내부적으로는 flash_attn 파라미터 타입이 일반 bool에서 llama_flash_attn_type 열거형으로 변경되었습니다. b9437에서 이 열거형은 세 개의 명명된 값을 갖습니다: LLAMA_FLASH_ATTN_TYPE_AUTO = -1, LLAMA_FLASH_ATTN_TYPE_DISABLED = 0, LLAMA_FLASH_ATTN_TYPE_ENABLED = 1 . auto를 전달하면, 명시적으로 비활성화되지 않는 한 Flash Attention을 활성화하고 auto_fa를 true로 설정해 컨텍스트 파라미터에 매핑됩니다. 실제 결정은 하드 플래그가 아닌 런타임의 자동 선택 경로에 위임됩니다 .

동기는 이론보다 실용에 있었습니다. PR 작성자에 따르면, 회귀 테스트용으로 llama-bench를 운영하는 자동화 팀의 요청에서 비롯되었습니다:

"자동화 팀은 이미 auto 모드를 지원하던 llama-cli, llama-server와 동일하게 하니스가 동작하길 원했습니다." — gaugarg-nv, PR #23714 작성자 (source: ggml-org/llama.cpp PR #23714)

덕분에 서버나 CLI가 프로덕션에서 적용하는 것과 동일한 Flash Attention 결정 로직으로 모델을 벤치마킹할 수 있게 되어, 측정값과 실제 실행 환경 사이의 불일치가 해소됩니다. diff 자체는 작았습니다 — PR은 두 파일(README.mdllama-bench.cpp)에서 약 108줄 추가, 51줄 삭제에 그쳤습니다 .

항목b9437 이전b9437 이후
허용 -faon, offon, off, auto
내부 타입boolllama_flash_attn_type 열거형
기본값off/on 불리언auto (-1)
런타임 매핑강제 활성화/비활성화auto → 비활성화되지 않으면 활성화, auto_fa 설정, 런타임 선택에 위임

하니스를 스크립트로 다루는 분이라면 타입 변경을 주목해야 합니다. 과거에는 불리언으로 읽히던 필드가 이제 정수형 열거값을 반환합니다. 이 점은 다음 섹션에서 내보내기 출력을 통해 살펴봅니다.

레이어 수 vs. 레이어 관례: -ngl 재해석

-fa 리팩토링은 단독으로 오지 않았습니다. PR #23714는 GPU로 오프로드되는 모델 레이어 수를 지정하는 -ngl/--n-gpu-layers의 기본값을 99에서 -1로 변경하고, 옵션 파서가 음수 정수를 허용하도록 업데이트했습니다 . 겉보기엔 단순한 미적 수정처럼 보입니다. 그러나 실제로는 임의의 숫자 상한선에서 llama.cpp가 어디서나 사용하는 관례로 전환한 것이며, 일부 기록된 실행 결과의 보고 방식에도 영향을 미칩니다.

이유는 공개 헤더에 있습니다. llama.h에서 음수 n_gpu_layers는 레이어 수를 그대로 나타내는 것이 아니라 "모든 레이어를 VRAM에 저장"을 의미하는 센티넬 값입니다 . 기존 기본값 99는 실제로 거의 모든 모델을 오프로드할 만큼 충분히 큰 정수였지만, 그래도 "전체"를 대신하는 고정 숫자에 불과했습니다. 기본값을 -1로 설정하면 llama-benchllama-serverllama-cli에서 이미 따르는 "모두 오프로드" 의미론과 일치하게 되어, 이제 하니스는 추측에 의한 상한선이 아닌 의도를 표현합니다 .

대부분의 모델에서 런타임에는 동일하게 해석됩니다 — 99와 -1 모두 전체 네트워크를 오프로드하므로 처리량 수치에는 변화가 없습니다 . 차이는 성능이 아닌 비교 가능성에 있습니다. 오프로드 가능한 레이어가 99개를 초과하는 모델의 경우, 이전 기본값은 일부 레이어를 CPU에 남겨두었겠지만 -1은 모두를 오프로드합니다. 그리고 출력되는 ngl 컬럼은 이제 99 대신 -1을 표시하므로, 해당 필드를 파싱하거나 이전 실행 결과와 비교하는 스크립트가 깨집니다.

마이그레이션 경로는 간단합니다:

  • b9437 이전 메타데이터 그대로 재현: -ngl 99를 명시적으로 전달하면 기록된 값과 오프로드 동작이 보관된 실행 결과와 일치합니다.
  • 미래 지향적 스크립트: -ngl -1을 사용하거나 플래그를 생략하세요. 이것이 이제 올바른 최신 형식이며 런타임의 "모든 레이어" 관례와 일치합니다.

회귀 도구가 원시 llama-bench 출력을 저장한다면, 기본값에 의존하지 말고 이전 실행과 새 실행 모두에서 플래그를 명시적으로 고정하세요 — 이렇게 하면 어느 빌드가 해당 행을 생성했든 상관없이 b9437 경계에 걸쳐 ngl 컬럼이 안정적으로 유지됩니다.

기존 내보내기 스크립트에 지금 보이는 것

The parity fix that quietly resets your profiling baseline

llama-bench 출력을 파서로 파이프하는 경우, b9437은 두 컬럼의 형태를 변경합니다. flash_attn 필드는 더 이상 이진값이 아닙니다: 이전에 true 또는 false를 읽던 행이 이제는 정수 열거형 -1(auto), 0(off), 1(on)을 가집니다 . flash_attn == true를 검사하거나 불리언 리터럴을 매칭하는 스크립트는 조용히 오작동합니다 — 오류가 발생하지 않고 그냥 잘못된 값을 읽습니다.

b9437 README 예제가 이를 구체적으로 보여줍니다: 기본 실행은 CSV 및 JSON 행에서 flash_attn: -1과 디바이스 레이블 auto를 기록합니다. auto가 이제 기본 모드이기 때문입니다 . ngl 컬럼에도 동일하게 적용됩니다: 명시적인 -ngl 플래그 없이 실행하면 이제 99 대신 -1을 출력합니다 . 99를 "완전히 오프로드됨" 센티넬로 하드코딩한 대시보드는 새로운 모든 실행을 잘못 표시합니다.

컬럼b9437 이전b9437부터 (기본 실행)마이그레이션 참고
flash_attntrue / false (불리언)-1 auto · 0 off · 1 on (열거형)불리언 검사를 교체하세요; -1→auto, 1→on, 0→off로 매핑하세요.
ngl플래그 생략 시 99플래그 생략 시 -199를 "모든 레이어"로 취급하지 마세요; -1이 새로운 센티넬입니다.

가장 안전한 마이그레이션은 리터럴 비교를 완전히 중단하는 것입니다. 두 필드 모두 수집 시 정규화하세요 — flash_attn 열거형을 레이블로 변환하고 음수 ngl을 "모든 레이어"로 처리합니다 — 이렇게 하면 단일 파서가 b9437 경계 양쪽의 빌드 출력을 처리할 수 있습니다. 장기 회귀 데이터의 경우, 함께 차트를 그리기 전에 이전 불리언 및 99 값이 새로운 열거형 및 -1 관례와 일치하도록 이전 행을 재키잉하거나 백필하세요.

영향 범위는 좁습니다: 앱 소비자가 아닌, 프로파일링 사용자에게만

b9437의 영향 범위는 좁고 단 하나의 도구에 국한됩니다. 조치가 필요한 사람은 llama.cpp를 컴파일하거나 다운로드하여 llama-bench를 실행하면서 모델·양자화·백엔드 조합별로 토큰 처리량, 프롬프트 처리 속도, Flash Attention 동작을 프로파일링하는 개발자뿐입니다. PR #23714는 tools/llama-bench 하위의 정확히 두 파일 — README.mdllama-bench.cpp — 만 수정했으며, 총 108줄 추가와 51줄 삭제로 이루어졌습니다 . 해당 하네스 외부에서 변경된 것은 없습니다.

간접적으로 영향을 받는 두 번째 그룹도 있습니다: llama-bench의 구조화된 출력을 파싱하거나, 명시적인 -fa-ngl 플래그를 고정하지 않은 채 실행 결과를 비교하는 CI 작업 또는 회귀 스크립트입니다. 이러한 파이프라인에서는 flash_attn 필드가 불리언에서 열거형으로 변경되어(auto-1로 출력), -ngl 기본값도 99에서 -1로 바뀐 것을 확인하게 됩니다 . 스크립트에서 두 플래그를 이미 고정하고 있다면 기본값은 적용되지 않으며, 경계를 넘어도 수치는 안정적으로 유지됩니다.

그 외 모든 것은 그대로입니다. llama-server, llama-cli, llama-cpp-python 바인딩, GGUF 형식, 모델 가중치, 그리고 런타임의 모든 애플리케이션 수준 소비자에게는 아무런 변화가 없습니다. API 표면 수정도, 모델 형식 개정도, 이 태그로 인해 동작이 달라지는 추론 경로도 없습니다 .

b9437이 아닌 것이 무엇인지 정확히 짚어둘 필요가 있습니다. 이 릴리스는 새로운 모델 아키텍처도, 새로운 양자화 형식도, 추론 품질 변경도 도입하지 않습니다 . 이것은 llama-clillama-server가 이미 사용하던 자동 선택 로직에 llama-bench를 맞추는 도구 계층 동등성 수정이며, 런타임 변경이 아닙니다. llama.cpp를 직접 벤치마크하기보다 그 위에 제품을 올려 제공한다면, 이 태그는 완전히 건너뛰고 현재 헤드를 추적해도 됩니다 .

배포 아티팩트: 23개 플랫폼, 일부 비활성 슬롯

The parity fix that quietly resets your profiling baseline

b9437 릴리스 페이지에는 데스크톱, 모바일, 서버 대상을 포괄하는 약 23개의 사전 빌드 아티팩트가 제공되므로 대부분의 사용자는 소스를 컴파일하지 않고 바이너리를 다운로드할 수 있습니다 . 범위는 Apple, Linux, Android, Windows를 아우르지만, 커밋별 CI 매트릭스가 모든 태그에서 모든 가속기 슬롯을 실행하지는 않습니다 — 특정 GPU 스택용 빌드를 고정하기 전에 확인해야 할 일상적인 간극입니다.

이 태그에 명시된 대상은 다음과 같습니다:

  • Apple: macOS Apple Silicon(arm64), macOS Intel(x64), iOS XCFramework .
  • Linux: Ubuntu x64/arm64/s390x CPU, Ubuntu x64/arm64 Vulkan, Ubuntu x64 ROCm 7.2, Ubuntu x64 OpenVINO, openEuler 빌드 .
  • Android: arm64 CPU .
  • Windows: x64/arm64 CPU, Vulkan, HIP, 두 가지 CUDA 바이너리 — x64 CUDA 12(CUDA 12.4 DLL 포함)와 x64 CUDA 13(CUDA 13.3 DLL 포함) .

Windows CUDA 사용자는 두 빌드가 상호 교환 불가능하다는 점에 유의해야 합니다: CUDA 12.4 또는 CUDA 13.3 아티팩트를 선택하기 전에 설치된 드라이버와 툴킷 버전을 확인하세요. 한편, 이 태그에서는 macOS Apple Silicon KleidiAI 및 SYCL 변형을 포함한 일부 선택적 빌드가 비활성으로 표시되었습니다 . 이는 지속적 태깅 파이프라인에서 예상되는 동작이며, 회귀가 아닙니다. 실질적인 교훈: 특정 가속기 빌드에 의존하는 워크플로가 있다면, 원하는 태그에서 해당 슬롯이 실제로 활성화되었는지 반드시 확인하세요 — 특정 빌드 번호에서 전체 커버리지를 당연하게 여기지 마세요 .

맥락으로 보는 b9437: 지속적 태깅 주기

b9437은 날마다 성장하는 릴리스 스트림의 데이터 포인트 하나일 뿐, 기대치를 고정해야 할 마일스톤이 아닙니다. llama.cpp는 master에 병합된 커밋마다 사실상 새로운 태그 빌드를 생성하여, 하루에 약 1~3개(때로는 그 이상)의 태그 릴리스를 만들어냅니다 . 그 주기로 보면 b9437은 9,000개가 넘는 태그 중 하나이며, 각 태그는 일반적으로 단일 풀 리퀘스트를 담고 있습니다 — 여기서는 PR #23714의 llama-bench-fa auto 동등성 작업입니다 .

이 태그는 이미 프로젝트 헤드보다 한참 뒤처져 있습니다. 2026년 6월 12일 기준, 릴리스 인덱스에는 b9611(6월 12일 14:03)이 Latest로 등록되어 있어, b9437은 약 174개 태그 뒤에 위치합니다 . 이 프로젝트는 시맨틱 버전 관리를 따르지 않으며, 별도의 "안정" 대 "베타" 트랙도 없습니다 — 헤드가 항상 가장 기능이 완전한 버전이며, 되돌아갈 큐레이션된 릴리스 브랜치도 없습니다 .

이것이 b9437 같은 번호를 어떻게 활용해야 하는지를 결정합니다. 회귀 고정 목적으로는 이 태그가 유효한 안정적 앵커입니다: 정확한 커밋(aa46bda)과 고정된 아티팩트 세트를 식별하므로 벤치마크 스크립트가 재현 가능한 실행을 위해 참조할 수 있습니다 . 그 외 — 새 기능, 수정, 현재 가속기 커버리지 — 를 위해서는 b9437을 역사적 경유지로 취급하고 llama.cpp 릴리스 페이지의 Latest 항목을 추적하세요. 어제의 결과를 내일도 재현해야 할 때는 번호를 고정하고, 오늘의 기능이 필요할 때는 헤드를 따르세요.

자주 묻는 질문

llama.cpp b9437은 고정해서 써도 될 만큼 안정적인 릴리스인가요?

아닙니다. llama.cpp는 시맨틱 버저닝을 사용하지 않으며, 병합된 커밋마다 새 태그 빌드를 생성해 하루에 대략 1~3개의 태그 릴리스가 만들어집니다 . b9437은 2026년 5월 30일에 커밋 aa46bda로부터 만들어진 단일 PR 증분 태그로, 정식 마일스톤이 아닙니다. 안정성이 필요하다면 검증된 태그 하나를 고정해 재사용하고, 최신 기능이 필요하다면 릴리스 페이지에서 매일 갱신되는 Latest를 추적하세요.

b9437로 업그레이드하면 llama-bench 결과가 달라지나요?

기본 플래그에 의존하고 있다면 달라집니다. b9437에서 -fa/--flash-attn의 기본값이 off에서 auto로, -ngl/--n-gpu-layers의 기본값이 99에서 -1(모든 레이어를 VRAM에 올림)로 변경됐습니다. b9437 이전과 동일한 출력을 재현하려면 -fa off -ngl 99를 명시적으로 전달하세요. -ngl 변경은 오프로드 가능한 레이어가 99개를 초과하는 모델의 비교 가능성에 주로 영향을 미칩니다 .

구조화된 출력에서 flash_attn이 true/false에서 -1/0/1로 바뀐 이유는 무엇인가요?

내부 flash_attn 파라미터 타입이 불리언에서 llama_flash_attn_type 열거형으로 변경돼 두 가지가 아닌 세 가지 상태를 표현할 수 있게 됐습니다: LLAMA_FLASH_ATTN_TYPE_AUTO = -1, LLAMA_FLASH_ATTN_TYPE_DISABLED = 0, LLAMA_FLASH_ATTN_TYPE_ENABLED = 1 . CSV 및 JSON 행에는 이제 기존 불리언 대신 정수 열거형 값이 출력됩니다 — README 예시에서 flash_attn은 디바이스 레이블 auto와 함께 -1로 표시됩니다.

b9437이 llama-server, llama-cli, llama-cpp-python에도 영향을 미치나요?

아닙니다. PR #23714는 tools/llama-bench 하위의 두 파일(README.mdllama-bench.cpp)만 수정했으며, 108줄 추가 및 51줄 삭제에 그쳤습니다 . 추론 런타임, GGUF 모델 포맷, 양자화 포맷, llama-cpp-python을 비롯한 모든 언어 바인딩은 변경되지 않았으며, b9437은 API나 모델 포맷 변경을 일절 포함하지 않습니다 .

b9437이 이미 구버전이라면 llama.cpp의 현재 최신 버전은 무엇인가요?

2026년 6월 12일 기준, b9611(6월 12일 14:03 빌드)이 Latest로 등록돼 있으며 b9437보다 훨씬 앞서 있습니다 . llama.cpp는 병합된 커밋마다 빌드를 태깅하므로 Latest 항목은 매일 바뀝니다 — 특정 빌드 번호가 최신이라고 단정하기 전에 릴리스 인덱스에서 현재 최신 버전을 확인하세요.