자신의 컴퓨터에서 모델을 돌린다면 직접 설치했든 그 위에 만든 앱을 쓰든 밑에서 일하는 것은 llama.cpp일 가능성이 큽니다. 이 프로젝트가 라이브러리 버전 1.0.0을 내놓고 시맨틱 버저닝을 따르겠다고 약속했습니다. 행정적인 일처럼 들리지만, 그 위에서 개발하는 모든 사람에게는 언제 호환성이 깨질지에 대한 약속입니다.
규칙은 간단하며 발표에 나와 있습니다. 공개 C API, 즉 include 폴더의 헤더에 호환되지 않는 변경이 있으면 메이저 버전을 올립니다. 이전 버전과 호환되는 기능, 백엔드 업데이트, 새 모델 지원, API 추가는 마이너 버전을 올립니다. API 변경이 없는 버그 수정은 패치 번호를 올립니다. 같은 규칙이 그 아래의 머신러닝 엔진 ggml과 다른 ggml-org 프로젝트에도 적용되며, 팀은 API와 ABI 모두에서 비호환성을 더 엄격하게 표시하겠다고 밝혔습니다.
이유는 규모입니다. 시작한 지 3년 반 만에 llama.cpp에 의존하는 프로젝트가 길게 늘어났고, 글에 따르면 현재 150개가 넘는 아키텍처 변형과 주요 추측 디코딩 방식을 모두 지원합니다. 배포 경로도 넓어지고 있어 Docker, Debian, Homebrew, conda-forge, MacPorts, Winget, 그리고 Apple 플랫폼용 XCFramework가 제시되어 있습니다. 테스트는 Hugging Face 인프라에서 돌아가며 NVIDIA, AMD, Qualcomm, Arm, IBM, Intel이 지원하는 자체 장비도 씁니다.
우리가 리뷰하는 도구에게 이는 조용하지만 중요한 변화입니다. Ollama와 LM Studio 모두 llama.cpp와 ggml을 바탕으로 하며, 작은 데스크톱 앱도 많이 그렇습니다. 지금까지 상류 프로젝트를 따라가려면 인터페이스 변경을 찾기 위해 변경 기록을 꼼꼼히 읽어야 했습니다. 호환성이 깨질 때 알려 주는 버전 번호가 있으면 이런 프로젝트가 더 적은 위험으로 더 자주 업데이트할 수 있고, 새 모델 지원도 사용자에게 더 빨리 닿을 것입니다. Hugging Face 팀은 macOS와 Windows용 자체 Llama 데스크톱 앱도 내놓고 있습니다.
한계도 짚어 둘 만합니다. 시맨틱 버저닝은 약속이지 보장이 아니며, C API를 다룰 뿐 품질이나 속도의 모든 동작 변화를 다루지는 않습니다. 많은 사람이 직접 쓰는 명령줄 도구나 서버 옵션에 대해서도 말하지 않습니다. 한 댓글 작성자는 매우 긴 프롬프트 처리가 여전히 바라는 만큼 빠르지 않다고 지적했고, 버전 1.0.0은 이를 해결한다고 주장하지 않습니다.