llama.cpp에 GLM-5.3-Flash(GLM5-Next) 지원 추가

AI 요약

이 PR은 GLM-5.3-Flash를 llama.cpp에서 실행하도록 GLM5-Next 아키텍처 지원을 추가합니다. 모델을 읽고 추론하는 기능만 넣는 데 그치지 않고, 멀티스트림 프리필의 잘못된 메모리 접근과 공유 KV 캐시 정리 문제를 고칩니다. 모델 이름과 텐서 구성 차이 때문에 기존 GGUF 양자화 파일을 그대로 쓸 수 있는지도 PR 논의에서 다뤄집니다.

멀티스트림 프리필의 주소 계산 수정

GLM5-Next는 rope 부분을 쿼리에 이어 붙이지 않는 nope-only 구조입니다. 따라서 순열을 적용한 q_absorbed 텐서는 연속 메모리 배치가 아니며, q->nb[3]/n_stream으로 스트림 간격을 구하면 실제 토큰 차원 간격과 달라집니다. 연속 텐서라면 두 값이 같지만, GLM5-Next에서는 계산된 간격이 헤드 수만큼 커져 두 번째 스트림부터 다른 헤드의 쿼리를 읽었습니다.

이 문제는 unified KV를 쓰지 않는 Split-KV 프리필, 즉 -np N 설정에서 스트림이 여러 개일 때 발생합니다. unified KV와 디코딩은 스트림 수가 1이거나 gather 경로를 사용하므로 영향을 받지 않습니다. rope를 이어 붙이는 다른 MLA 모델은 q가 연속 배치라 기존 계산값이 그대로 유효합니다. 수정안은 스트림 간격을 토큰 차원에서 계산합니다. 연속 배치의 q에서도 같은 값이 나옵니다.

공유 셀 정리와 테스트 보완

KV 캐시에서 공유 셀이 있는 상태로 시퀀스를 제거할 때, 살아남은 시퀀스까지 stale 처리해 공유 상태를 다시 계산하는 로직이 필요합니다. 이 처리는 seq_rm에는 있었지만 state_read와 state_drop에는 빠져 있었습니다. 두 경로에도 같은 재계산을 적용하고, 공유가 편집이나 seq_rm을 통해서만 끝난다고 적힌 주석도 바로잡았습니다.

PR을 최신 master와 맞추면서 GLM5-Next 전용 rollback 테스트 호출은 제거했습니다. 공통 테스트가 생성된 모든 모델을 대상으로 실행되며, GLM5-Next도 recurrent 모델로 포함되기 때문입니다. 새 아키텍처에는 Metal fusion 기준 데이터도 필요합니다. M5 Max에서 test-fusion --record로 GLM5-Next 항목 6개를 추가한 뒤, --check가 270개 테스트 모두 통과했다는 후속 내용이 있습니다. 별도로 CPU 전용 빌드와 thread sanitizer를 켠 상태에서 더미 GLM5 모델의 데이터 레이스가 보고돼 조사 과제로 언급됐습니다.

GGUF 호환성과 실행 사례

토론에서는 모델 아키텍처 이름이 glm5next와 glm5-next로 달라 기존 양자화 파일이 메인라인 빌드에서 로드되지 않는 문제가 나왔습니다. 단순 별칭만 추가하면 이 PR로 만든 양자화 파일이 깨질 수 있다는 지적도 있습니다. 텐서 이름과 양자화 보호 설정 변경에 따라 파일을 다시 변환하거나 shard를 고쳐야 할 수 있으며, 비전 projector 이름도 glm4v와 glm5next 사이에서 달라 재생성이 필요하다는 논의가 이어졌습니다.

한 사용자는 128GB DDR5와 RTX 4090 24GB 시스템에서 IQ3_S 모델을 시험했습니다. 컨텍스트 256K, 배치 크기 2048 설정에서 프리필은 초당 약 300토큰이었고, 생성 속도는 처음 약 9토큰에서 컨텍스트가 128K에 이르자 약 6토큰으로 떨어졌다고 보고했습니다. 모델 응답은 일관적이었다고 했지만, perplexity와 KL 수치는 아직 산출하지 않았습니다. 체크포인트 크기가 컨텍스트 증가에 따라 빠르게 커져 90K 부근에서 약 1.6GB에 이르는 현상도 관찰했습니다.

Reddit 반응

• @u/Elouakili_Flexy — 3주 동안 조용하다가 pwilkin이 마무리했습니다. 결국 릴리스 주기는 메인테이너 한 명에게 한가한 주가 있느냐에 달렸네요.
  • @u/3000LettersOfMarque — 오픈소스에 오신 걸 환영합니다.
• @u/SnooPaintings8639 — 새 모델을 학습하고 출시하는 데 두 달, llama.cpp가 지원하는 데 한 달이 걸립니다. 팀이 더 커져 모델 지원과 최적화가 빨라졌으면 합니다. 새 실험 아키텍처가 빠르게, 많이 나오는데 따라잡을 수 있을지 모르겠습니다.
  • @u/am17an — 앞서 Reddit 글에서도 말했듯 이건 우리 잘못이 아닙니다. PR이 3주 동안 갱신되지 않았고, pwilkin이 나서서 마무리했습니다.
  • @u/arbv — 팀이 커진다고 빨라지는 건 아닙니다. 오히려 반대인 경우도 많습니다. 아키텍처를 잡는 단계에서는 한 명이 맡는 편이 보통 낫습니다.
  • @u/jacek2023 — 기능이 꼭 필요하면 병합 전에 PR을 빌드해도 됩니다.
  • @u/SnooPaintings8639 — 한 달 전부터 Flash Next 최적화를 위해 서로 다른 PR의 커밋 약 5개를 체리픽해 사용하고 있습니다. 모델 하나 때문에 업스트림이 갱신될 때마다 병합하고 충돌을 푸는 작업이 필요합니다.
• @u/geon2k2 — 안타깝게도 Unsloth PR은 메인라인 PR과 호환되지 않습니다. 한쪽은 glm5next, 다른 쪽은 glm5-next라서 이제 메인라인 llama는 Unsloth 양자화 파일을 읽지 못합니다.
  • @u/segmond — 보통 메인라인에서 지원하면 다시 양자화합니다.
  • @u/Best-Echidna-5883 — 공식 llama.cpp 버전에서는 avar6/GLM-5.3-Flash-BF16-gguf를 써야 합니다. 커스텀 버전을 쓰려는 게 아니라면 Unsloth 파일은 피하세요.
  • @u/silenceimpaired — 당장은요.
• @u/florinandrei — 이제 집 컴퓨터에서 GLM-5.3-Flash를 쓸 수 있겠네요. 제 집 컴퓨터 성능을 지나치게 낙관하시는 것 같지만, llama.cpp에 들어온 건 반갑습니다.
• @u/Constant_Art_20 — llama.cpp에 GLM 5.3 Flash 지원이 없었던 건가요?
  • @u/Spectrum1523 — 공식 지원은 없었습니다. Unsloth가 자체 포크에서 먼저 실행되게 했습니다.
• @u/120decibel — Unsloth 커스텀 빌드로 전부터 가능했던 것 아닌가요?
  • @u/Spectrum1523 — 차이는 포크가 아니라 메인라인 지원입니다.
• @u/Impressive_Chain6039 — 이 PR에서 Vulkan도 최적화했나요?
• @u/madbrain1976 — 128GB RAM과 5060 Ti 16GB 네 장 구성에서 Blackwell로 GLM 5.3 Flash를 실행한 분 있나요? 첫 요청에서 SOFT_MAX 실패와 GPU 0의 CUDA invalid argument 오류가 납니다.

원문: GitHub PR / 번역·요약: Trawling