프로젝션 모델이 별도 파일로 나뉘게 된 건 아쉽고, 나도 단일 파일 안에 들어가는 편을 원했음
왜 그렇게 됐는지는 정확히 모르겠지만, GGUF를 설계할 때 염두에 둔 단일 파일 철학과는 꽤 어긋남
둘을 합치는 일을 누군가 이끌어주길 바라며, 이번에는 내가 흐름에서 너무 벗어나 있는 것 같음 :-)
지금 MTP 지원이 개발 중인 걸 보면, 그 논의 중에 Mmproj처럼 MTP 모델을 메인 GGUF에서 분리하자는 아이디어가 오간 듯했지만 거부됐음
그 결정은 마음에 듦. 그렇다면 Mmproj 파일도 GGUF 안에 포함하는 데 열려 있을 가능성이 있다고 보는 게 무리도 아니라고 생각함
떠오르는 유일한 문제는 어떤 형식을 넣을지임. BF16, F16 등 선택지가 있음
GGML과 GGUF는 오픈소스 머신러닝/AI 생태계에 매우 중요했음
llama.cpp, whisper.cpp, stable-diffusion.cpp 같은 프로젝트는 다양한 플랫폼과 하드웨어 백엔드에서 대체로 바로 잘 동작함
llama.cpp는 Meta 쪽 산물이긴 하고 Meta는 정말 싫어하지만, 다른 것들에 비해 가장 쉽다는 건 인정함
컴파일하고 모델을 넣고 실행하면 됨. 그러면 웹 UI와 API까지 얻을 수 있음
> <|turn>user Hi there!<|turn>model Hi there, how can I help you today
세상에, XML보다도 가독성이 낮은 형식을 만들어냈음
사람이 읽으라고 만든 형식이 아님. 실제로 들여다볼 일도 거의 없음
이 형식은 실제 내용과 혼동되지 않도록 설계됐고, 그 내용은 인터넷에서 온 아무 텍스트나 될 수 있음
그러려면 어디에서도 쓰이지 않는 형식을 써야 함
맞음. 메모리 사용 효율 측면에서는 최적이 아닌 형식처럼 보임
현재 가장 크게 빠진 것은 모델 아키텍처를 현재 빌드에 하드코딩하지 않고 정의하는 방법이라고 봄
완전히 지원되는 모델과 1:1 성능 동등성을 가질 필요는 없음
출시 첫날부터 벤더가 검증한 제대로 된 지원이 있느냐가 모델을 훌륭하다고 느끼게 하느냐 끔찍하다고 느끼게 하느냐를 가름함. 최근 Gemma와 Qwen 출시가 그 예임
해결책은 잘 모르겠지만, 모델 그래프를 설명하는 DSL을 작성해 GGUF에 넣는 방식이 있을 수 있음
다른 대안은 공식 모델 릴리스의 PyTorch 모듈을 읽어서 어떻게든 GGML 연산으로 변환하는 것임
GGUF 명세에 계산 그래프를 포함할 공간을 일부러 남겨뒀고, 누군가 이어받길 바랐음
첫 버전에 넣고 싶었지만, 당시에는 최소 기능 명세를 내고 구현되게 하는 쪽을 우선했음
지금도 보고 싶지만, 현재 GGML IR 상태를 아주 잘 아는 추진자가 필요함
계산 그래프를 ONNX처럼 가중치 파일 안에 임베드할 수 있을 것 같음
그런 다음 공통 매개변수를 받는 공통 인터페이스를 노출하고, 추가 커스텀 매개변수는 Wayland처럼 확장으로 둘 수 있음
그러면 LLaMa 같은 트랜스포머 계열뿐 아니라 RWKV 같은 순환 신경망 계열, 멀티모달 모델 등도 지원할 수 있음
실제 구현은 잘 모르겠지만 멋진 아이디어로 들림. 다만 계산 그래프가 모델 파일에 박혀 있으면, 가중치를 바꿀 필요 없는 아키텍처 개선이나 최적화가 기존 파일에는 변환 없이는 적용되지 않을까 걱정됨
> GGUF의 정말 깔끔한 점은 파일 하나라는 것이다. Hugging Face의 일반적인 safetensors 저장소와 비교하면, 필요한 JSON 파일들이 여기저기 흩어져 있다 [...]
흥미롭게도 내게 AI 모델은 “항상” 단일 파일이었음. 로컬 이미지 생성 쪽에서는 그게 표준이었기 때문임
safetensors 파일도 내부에 온갖 것을 넣을 수 있어서, 이를 위해 꼭 GGUF가 필요한 건 아님
다만 현대 모델의 텍스트 인코더는 그 자체로 수 기가바이트짜리 언어 모델이라, 누구도 모든 체크포인트에 중복 복사본을 넣지는 않음
단일 파일 배포는 내가 의도적으로 세운 설계 목표였음
대부분의 이미지 모델은 단일 파일이었거나 지금도 그렇지만, LLM의 safetensors는 적어도 당시에는 그렇지 않았고, 구조적 수준에서 이를 강제하고 싶었음
또한 실행기, 예를 들어 llama.cpp에 JSON 리더를 요구하고 싶지 않았는데, ST 방식은 그게 필요했을 것임
더 큰 문제는 기억이 맞다면 당시 ST가 GGML의 새 양자화 형식을 지원할 수 없었고, 자체 파일 형식이 있으면 ST로는 얻기 어려운 유연성을 확보할 수 있었다는 점임
“로컬 이미지 생성 쪽에서는 AI 모델이 항상 단일 파일이었다”는 말은 그 영역에서도 말이 안 됨
아키텍처를 가중치로 실제 실행하려면 단일 가중치 파일만 쓰는 게 아니라 여러 인코더와 디코더 등이 필요함
쓰는 도구가 그걸 숨겨줄 수는 있지만, 표면 아래에는 여전히 존재함
libllama API에 노출된, 몇 가지 채팅 형식을 C++에 직접 하드코딩한 다소 이상한 llama_chat_apply_template 말인데, 데스크톱 기반 추론 앱을 FLTK[0]로 만지작거리는 입장에서는 이게 llama.cpp가 쓰는 실제 Jinja2 템플릿 파서를 사용했으면 좋겠음
아니면 그런 일을 해주는 다른 C 함수가 있었으면 함. 제대로 파싱하려면, 예를 들어 도구 호출 여부를 템플릿이 알 수 있도록 여러 데이터를 넘길 수 있어야 하는 것 같음
지금은 이 임시스러운 함수를 쓰고 있지만, 결국 Jinja2 인터프리터를 직접 쓰거나 llama.cpp 코드에서 가져와 붙이게 될 것 같음
그래도 GGUF의 올인원 접근은 매우 편리함. 프로젝션 모델이 별도 파일인 건 이상하게 느껴진다는 데 동의함
비전 지원 모델을 처음 받았을 때 적당해 보이는 GGUF만 내려받았는데, llama.cpp가 모델을 처리할 수 없다고 해서 한참 뒤에 추가 파일이 필요하다는 걸 깨달았음
그때 든 생각이 말 그대로 “GGUF는 전부 담는 형식 아니었나?”였음 :-P
[0] https://i.imgur.com/GiTBE1j.png
나는 항상 Hugging Face 저장소와 비슷한 safetensors + 메타데이터 파일 형식을 써왔음
큰 불편은 전혀 아니지만, GGUF가 더 조밀한 형식과 좋은 지원을 갖춘 건 괜찮아 보임
GGUF에 아직 없는 것들을 보면서 오히려 GGUF를 더 배웠음 도구 호출 형식은 정말 자연스럽고, LLM에서 에이전트로 넘어가는 이정표가 될 것 같음
최근 TheBloke의 7B Mistral을 받아서 시험해보려 했고, 4070을 가지고 있음
Mistral을 좋아하지만 그 모델은 최고는 아님
Gemma 4 e4b를 한번 써보는 게 좋겠음. Mistral 7B와 비슷한 크기이고 4070에서 잘 돌아갈 것임
“E4B”라는 이름은 살짝 오해를 부를 수 있음
7B Mistral은 꽤 오래됐음
12GB 4070에서는 Qwen 3.5 9B q4km나 Qwen 3.6 35B를 돌릴 수 있음. 후자가 훨씬 똑똑하지만 메모리 오프로딩 때문에 훨씬 느림
둘 다 LM Studio에서 써보면, 정말 놀랄 만큼 능력이 좋음
2070에서도 정말 빠르게 잘 동작하는 걸 확인했음
TheBloke를 좋아해서, 아직도 모델을 만들어줬으면 좋겠음
Hacker News 의견들
프로젝션 모델이 별도 파일로 나뉘게 된 건 아쉽고, 나도 단일 파일 안에 들어가는 편을 원했음
왜 그렇게 됐는지는 정확히 모르겠지만, GGUF를 설계할 때 염두에 둔 단일 파일 철학과는 꽤 어긋남
둘을 합치는 일을 누군가 이끌어주길 바라며, 이번에는 내가 흐름에서 너무 벗어나 있는 것 같음 :-)
그 결정은 마음에 듦. 그렇다면 Mmproj 파일도 GGUF 안에 포함하는 데 열려 있을 가능성이 있다고 보는 게 무리도 아니라고 생각함
떠오르는 유일한 문제는 어떤 형식을 넣을지임. BF16, F16 등 선택지가 있음
GGML과 GGUF는 오픈소스 머신러닝/AI 생태계에 매우 중요했음
llama.cpp, whisper.cpp, stable-diffusion.cpp 같은 프로젝트는 다양한 플랫폼과 하드웨어 백엔드에서 대체로 바로 잘 동작함
컴파일하고 모델을 넣고 실행하면 됨. 그러면 웹 UI와 API까지 얻을 수 있음
> <|turn>user Hi there!<|turn>model Hi there, how can I help you today세상에, XML보다도 가독성이 낮은 형식을 만들어냈음
이 형식은 실제 내용과 혼동되지 않도록 설계됐고, 그 내용은 인터넷에서 온 아무 텍스트나 될 수 있음
그러려면 어디에서도 쓰이지 않는 형식을 써야 함
현재 가장 크게 빠진 것은 모델 아키텍처를 현재 빌드에 하드코딩하지 않고 정의하는 방법이라고 봄
완전히 지원되는 모델과 1:1 성능 동등성을 가질 필요는 없음
출시 첫날부터 벤더가 검증한 제대로 된 지원이 있느냐가 모델을 훌륭하다고 느끼게 하느냐 끔찍하다고 느끼게 하느냐를 가름함. 최근 Gemma와 Qwen 출시가 그 예임
해결책은 잘 모르겠지만, 모델 그래프를 설명하는 DSL을 작성해 GGUF에 넣는 방식이 있을 수 있음
다른 대안은 공식 모델 릴리스의 PyTorch 모듈을 읽어서 어떻게든 GGML 연산으로 변환하는 것임
첫 버전에 넣고 싶었지만, 당시에는 최소 기능 명세를 내고 구현되게 하는 쪽을 우선했음
지금도 보고 싶지만, 현재 GGML IR 상태를 아주 잘 아는 추진자가 필요함
그런 다음 공통 매개변수를 받는 공통 인터페이스를 노출하고, 추가 커스텀 매개변수는 Wayland처럼 확장으로 둘 수 있음
그러면 LLaMa 같은 트랜스포머 계열뿐 아니라 RWKV 같은 순환 신경망 계열, 멀티모달 모델 등도 지원할 수 있음
실제 구현은 잘 모르겠지만 멋진 아이디어로 들림. 다만 계산 그래프가 모델 파일에 박혀 있으면, 가중치를 바꿀 필요 없는 아키텍처 개선이나 최적화가 기존 파일에는 변환 없이는 적용되지 않을까 걱정됨
> GGUF의 정말 깔끔한 점은 파일 하나라는 것이다. Hugging Face의 일반적인 safetensors 저장소와 비교하면, 필요한 JSON 파일들이 여기저기 흩어져 있다 [...]흥미롭게도 내게 AI 모델은 “항상” 단일 파일이었음. 로컬 이미지 생성 쪽에서는 그게 표준이었기 때문임
safetensors 파일도 내부에 온갖 것을 넣을 수 있어서, 이를 위해 꼭 GGUF가 필요한 건 아님
다만 현대 모델의 텍스트 인코더는 그 자체로 수 기가바이트짜리 언어 모델이라, 누구도 모든 체크포인트에 중복 복사본을 넣지는 않음
대부분의 이미지 모델은 단일 파일이었거나 지금도 그렇지만, LLM의 safetensors는 적어도 당시에는 그렇지 않았고, 구조적 수준에서 이를 강제하고 싶었음
또한 실행기, 예를 들어 llama.cpp에 JSON 리더를 요구하고 싶지 않았는데, ST 방식은 그게 필요했을 것임
더 큰 문제는 기억이 맞다면 당시 ST가 GGML의 새 양자화 형식을 지원할 수 없었고, 자체 파일 형식이 있으면 ST로는 얻기 어려운 유연성을 확보할 수 있었다는 점임
아키텍처를 가중치로 실제 실행하려면 단일 가중치 파일만 쓰는 게 아니라 여러 인코더와 디코더 등이 필요함
쓰는 도구가 그걸 숨겨줄 수는 있지만, 표면 아래에는 여전히 존재함
libllamaAPI에 노출된, 몇 가지 채팅 형식을 C++에 직접 하드코딩한 다소 이상한llama_chat_apply_template말인데, 데스크톱 기반 추론 앱을 FLTK[0]로 만지작거리는 입장에서는 이게 llama.cpp가 쓰는 실제 Jinja2 템플릿 파서를 사용했으면 좋겠음아니면 그런 일을 해주는 다른 C 함수가 있었으면 함. 제대로 파싱하려면, 예를 들어 도구 호출 여부를 템플릿이 알 수 있도록 여러 데이터를 넘길 수 있어야 하는 것 같음
지금은 이 임시스러운 함수를 쓰고 있지만, 결국 Jinja2 인터프리터를 직접 쓰거나 llama.cpp 코드에서 가져와 붙이게 될 것 같음
그래도 GGUF의 올인원 접근은 매우 편리함. 프로젝션 모델이 별도 파일인 건 이상하게 느껴진다는 데 동의함
비전 지원 모델을 처음 받았을 때 적당해 보이는 GGUF만 내려받았는데, llama.cpp가 모델을 처리할 수 없다고 해서 한참 뒤에 추가 파일이 필요하다는 걸 깨달았음
그때 든 생각이 말 그대로 “GGUF는 전부 담는 형식 아니었나?”였음 :-P
[0] https://i.imgur.com/GiTBE1j.png
나는 항상 Hugging Face 저장소와 비슷한 safetensors + 메타데이터 파일 형식을 써왔음
큰 불편은 전혀 아니지만, GGUF가 더 조밀한 형식과 좋은 지원을 갖춘 건 괜찮아 보임
GGUF에 아직 없는 것들을 보면서 오히려 GGUF를 더 배웠음
도구 호출 형식은 정말 자연스럽고, LLM에서 에이전트로 넘어가는 이정표가 될 것 같음
최근 TheBloke의 7B Mistral을 받아서 시험해보려 했고, 4070을 가지고 있음
Gemma 4 e4b를 한번 써보는 게 좋겠음. Mistral 7B와 비슷한 크기이고 4070에서 잘 돌아갈 것임
“E4B”라는 이름은 살짝 오해를 부를 수 있음
12GB 4070에서는 Qwen 3.5 9B q4km나 Qwen 3.6 35B를 돌릴 수 있음. 후자가 훨씬 똑똑하지만 메모리 오프로딩 때문에 훨씬 느림
둘 다 LM Studio에서 써보면, 정말 놀랄 만큼 능력이 좋음
TheBloke를 좋아해서, 아직도 모델을 만들어줬으면 좋겠음