colibri

KO | EN

Minimalist Open Source Repository Search Engine

gitlite — search

#typescript #ai-agents #deepseek-harness #dsh-plugin #open-source #ai #cli #claude-code #windows #codex #developer-tools #dsh

★ 25,206 Open GitHub ↗

이미 보유하고 있는 하드웨어에서 최첨단 MoE 모델을 실행하세요 — 순수 C언어, 제로 의존성, 디스크에서 스트리밍되는 전문가 모델. 작은 엔진, 거대한 모델. 🐦

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

![colibrì — tiny engine, immense model](assets/colibri-logo.svg)

[![Website](https://img.shields.io/badge/website-justvugg.github.io%2Fcolibri-1f6feb)](https://justvugg.github.io/colibri)
[![Latest release](https://img.shields.io/github/v/release/JustVugg/colibri?color=2ea043)](https://github.com/JustVugg/colibri/releases)

[**Website**](https://justvugg.github.io/colibri) ·
[**Discord**](https://discord.gg/MAaKtQRc) ·
English · [简体中文](README.zh-CN.md) · [繁體中文](README.zh-TW.md) · [Italiano](README.it.md)

\*\*작은 엔진, 거대한 모델.\*\* 스토리지, RAM, VRAM을 단일 인퍼런스 계층(AI 메모리 멀티티어링)으로 통합하여 종속성 없는 순수 C 언어로 구현됨으로써, 소비자용 하드웨어 및 이기종 하드웨어에서 \*\*최첨단 MoE 모델(744B ~ 2.8T 파라미터)\*\*을 실행할 수 있습니다.
현재 5개 패밀리가 지원됩니다: \*\*GLM-5.2\*\* (744B), \*\*Inkling\*\* (975B), \*\*Kimi K3\*\* (2.8T), \*\*DeepSeek V4 Flash\*\* (284B), \*\*OLMoE\*\* (7B) — 각각 하나의 C 파일로 구성되며, 동일한 `coli chat` / `coli serve` / `coli web` 프론트엔드를 사용합니다.
[전체 목록 보기 ↓](#other-supported-models)
> \*\*Colibrì는 지금 바로 실행할 수 있는 인퍼런스 엔진이자 오픈 연구 플랫폼입니다.\*\* 주요 목표는 모델 형식, 메모리 계층, 스토리지 I/O, 배치, 스케줄링, 커널, 추측(speculation), CPU/GPU 오버랩 등 소프트웨어와 하드웨어의 경계 전반에 걸쳐 인퍼런스 성능을 추구하는 것이며, 이를 통해 대규모 모델이 부족한 하드웨어에 대한 의존도를 낮추고 실행 비용을 절감하는 것입니다.
Colibrì는 VRAM, RAM, 스토리지 계층을 단일 멀티티어 계층으로 취급하며, 과감한 시스템 아이디어를 테스트하기 위한 공간을 의도적으로 지향합니다. 따라서 \*\*속도에 대한 SLA는 없으며 의미론(semantics)에 대해서는 강력한 보장을 제공합니다\*\*: 실험은 재현 가능한 엔드투엔드 측정을 통해 그 가치를 입증해야 하며, 기본 정책은 \*\*모델 정밀도나 라우터 의미론을 임의로 변경하지 않습니다\*\*. 빠른 메모리가 부족할 경우 속도가 느려질 수는 있으나, 모델을 임의로 재정의해서는 안 됩니다.
```
$ ./coli chat
🐦 colibri v1.4.0 — GLM-5.2 · 744B MoE · int4 · streaming CPU
✓ ready in 32s · resident 9.9 GB
› ciao!
◆ Ciao! 😊 Come posso aiutarti oggi?
```
## 실행 화면 보기

![colibrì web dashboard — live metrics, hardware panel, expert tiers](docs/media/colibri-dashboard.png)

*웹 대시보드 (`./coli web`): 6개의 RTX 5090에서 모든 전문가(expert)가 상주하는 상태로 **4 tok/s, TTFT 1.6 s, 디스크 0**의 성능을 보여주는 744B 모델 — 실시간 토큰 지표, 턴별 소요 시간 분석, VRAM/RAM/디스크 티어 바, 구석의 실시간 미니 브레인.*

![the Brain page — 19,456 experts as a live cortex](docs/media/colibri-brain.png)

*실행 중인 **Brain** 페이지: 19,456개의 전문가가 살아있는 피질처럼 표현됨 — 색상은 스토리지 티어를 나타내고, 밝기는 라우팅 부하를 나타내며, 턴에서 라우팅된 모든 전문가는 흰색으로 깜빡입니다. 마우스를 올리면 전문가의 [측정된 주제 친화도](https://github.com/JustVugg/colibri/issues/175)가 표시됩니다.*

![the Atlas page — the measured expert atlas as a 3-D galaxy](docs/media/colibri-atlas.png)

*실행 중인 **Atlas** 페이지: 3차원 은하계 형태의 [측정된 전문가 아틀라스](https://github.com/JustVugg/colibri/issues/175) — 특성이 분석된 13,260개의 전문가, 주제별로 군집을 이루는 1,041개의 복제된 전문가(시, 법률, 중국어, SQL 등…). 위치는 학습된 임베딩이 아니라 측정된 라우팅 친화도입니다. 드래그하여 회전할 수 있습니다.*

## 연구 미션
Colibrì를 통해 프라이빗 프론티어 모델에 대한 접근성은 하이퍼스케일러급 하드웨어의 가용성에 제한되지 않습니다.
Colibrì는 다중 계층(multitiering) 기능을 통해 \*\*독점적 하드웨어 종속성을 제거하고 기능적 추론 엔진 파이프라인을 공격적으로 최적화\*\*합니다.
당사의 운영 미션에는 가중치가 표현되고 이동하는 방식 변경, VRAM, RAM 또는 스토리지에 상주할 데이터 결정, 이기종 연산 중첩, 시작 및 동기화 오버헤드 감소, 희소성(sparsity) 및 재사용 활용, 그리고 새로운 디코딩 알고리즘 테스트가 포함됩니다. 단지 관습적이라는 이유로 보호되는 것은 없으며, 단순히 마이크로 벤치마크가 빠르다는 이유로 채택되는 것도 없습니다. 결정적인 결과는 처리량, 지연 시간, 메모리, 비용과 함께 정확성과 품질을 측정하여 실제 장비에서 수행하는 엔드투엔드 추론입니다.
실질적인 결과는 \*\*접근성\*\*입니다. 이미 보유한 하드웨어에서 744B 파라미터 모델을 실행하고, 모든 전문가(expert)가 실시간으로 작동하는 것을 지켜보며, 이를 수행하는 코드를 변경할 수 있습니다. API 뒤에서 지능을 빌리는 것이 아니라, \*\*소유\*\*하는 것입니다: 탐색하고, 측정하고, 개선합니다. 이 엔진은 측정하고자 하는 누구나 다음 유용한 최적화를 도출해낼 수 있을 만큼 의도적으로 작게 설계되었습니다.

## 핵심 기술 및 측정된 결과
- \*\*계층 용량에 구애받지 않는 단일 계층 구조.\*\* VRAM, RAM, NVMe는 동일한 가중치를 위한 배치 계층이며, 제한된 고속 메모리는 모델의 의미론이 아니라 속도를 변경합니다.
- \*\*가중치를 위한 JIT.\*\* 측정된 라우팅 히트(heat)는 모든 전문가를 로드하는 대신 레이어별 LRU, 학습된 고정(pinned) 핫 스토어, 그리고 한 레이어 앞선 프리페치(prefetch)를 구동합니다. 이는 반복 가능한 워크로드에서 유효하지만, 기록은 과적합될 수 있고 룩아헤드(lookahead)는 일부 호스트에서 손해를 볼 수 있으므로, 두 가지 모두 약속이라기보다는 측정 가능한 정책으로 남겨둡니다.
- \*\*I/O는 엔진의 일부입니다.\*\* 배치 처리된 전문가 유니언, 중첩된 읽기 및 연산, `O\_DIRECT`, 가중치가 적용된 듀얼 SSD 스트라이핑은 스토리지 지연 시간이 무료인 것처럼 가장하는 대신 스트리밍 경로를 공략합니다. `O\_DIRECT`는 드라이브에 따라 다르며, 듀얼 SSD는 여전히 광범위한 엔드투엔드 커뮤니티 A/B 테스트가 필요합니다.
- \*\*이기종 실행.\*\* CPU, CUDA, Metal, NUMA 메모리, 그리고 부분 또는 전체 전문가 상주가 하나의 런타임을 공유하며 기기에 맞게 결합될 수 있습니다. 유리한 조합은 연산, 대역폭, 상주 여부, 워크로드에 따라 달라집니다.
- \*\*다른 모델이 필요 없는 압축 상태.\*\* 토큰 단위로 정확한 순방향 검증, 57배 더 작은 MLA KV 상태, 지속적인 웜 대화, 충실한 DSA는 최적화가 정확성과 결합되도록 유지합니다. 이는 일괄적인 처리량 주장이 아니라 메모리, 지연 시간, 정확성 속성입니다.
- \*\*가치 입증이 필요한 추측(Speculation).\*\* 네이티브 MTP와 문법 강제 초안(grammar-forced drafts)은 엔드투엔드로 측정되며, 채택(acceptance)이 검증 비용을 회수하지 못할 때는 비활성화할 수 있습니다.

## 열린 가설, 실험, 그리고 기여 방법
Colibrì는 제어된 엔드투엔드 A/B 테스트를 통해 결과가 입증될 때까지 최적화를 가설로 다룹니다. 현재의 주요 질문은 다음과 같습니다.

| 가설 | 지금까지의 입증 증거 | 추가로 필요한 실험 |
|---|---|---|
| 라우팅 기록은 단순 LRU보다 전문가를 더 잘 배치할 수 있습니다 | 학습된 핀(pin)은 반복되는 워크로드에서 성능을 향상시키지만 프롬프트에 과적합될 수 있습니다 | 코딩, 챗, 다국어, 롱컨텍스트 워크로드 전반에 걸친 홀드아웃(held-out), 크로스 세션 A/B 테스트 |
| 여러 개의 SSD는 독립적인 대역폭을 디코딩 속도로 전환할 수 있습니다 | 가중치 미러/스플릿 라우팅이 구현 및 검증되었으며, 대역폭 모델은 타당합니다 | 실제 독립 컨트롤러 환경에서의 콜드 캐시 단일 드라이브 대 듀얼 드라이브 GLM-5.2 실행 |
| 하드웨어 인식 플래너는 각 기기의 최적 구성을 자동으로 도출할 수 있습니다 | RAM/VRAM 예산과 여러 백엔드가 현재 감지됩니다 | 생성된 계획을 노트북, 워크스테이션, NUMA 호스트, 멀티 GPU 시스템 전반의 제어된 파라미터 스윕과 비교 |
| 무손실 또는 품질 제한 표현은 중요할 만큼 가중치 이동을 줄일 수 있습니다 | 정확성/품질 게이트와 함께 포맷 및 양자화 어블레이션(ablation)이 존재합니다 | 유용한 토큰당 품질, 이동한 바이트, 지연 시간, 비용을 함께 재현 — 단순 병행이 아님 |

mpression ratio alone |
| Routing-aware speculation can pay before near-full residency | MTP and grammar drafts work, but MTP has also measured a 32% loss around 85% expert hit | map the break-even surface across acceptance, expert hit rate, batch union, and draft depth |
| CPU/GPU overlap can hide transfer and synchronization rather than merely move the bottleneck | CUDA and Metal wins exist, but fast CPUs and low residency can erase them | per-stage profiles and one-variable A/Bs across PCIe, unified-memory, and full-resident machines |
기여하고 싶으신가요? 행 하나를 골라 부정적인 결과도 함께 공개하세요. 하드웨어, 커밋, 모델/컨테이너, 정확한 명령어, 프롬프트, 캐시 상태, 처리량, TTFT, Expert 적중률, 읽은 바이트 수, 품질 검증을 기록하고, 변수 하나를 변경하여 실행을 반복한 뒤 원본 로그를 첨부하세요. [CONTRIBUTING.md](CONTRIBUTING.md)부터 시작하여 [벤치마크 프로토콜](docs/benchmarks.md)과 비교한 뒤, [실험 이슈를 생성](https://github.com/JustVugg/colibri/issues/new)하세요.
여기서는 잘 통제된 실패가 원인을 알 수 없는 빠른 수치보다 더 가치 있습니다.

## 아이디어
744B Mixture-of-Experts 모델은 토큰당 약 40B 파라미터만 활성화하며, 그중 토큰마다 변경되는 것은 (라우팅되는 전문가들) 약 11 GB에 불과합니다:

![only ~5.4% of parameters are active per token](docs/media/sparse.png)

따라서 모델 전체가 고속 메모리에 *들어갈* 필요는 없습니다. 대신 \*\*배치(placed)\*\*되어야 합니다:
- \*\*밀집 부품(dense part)\*\* (attention, shared experts, embeddings — 약 17B 파라미터)은
int4 형식으로 \*\*RAM에 상주\*\*하며 (~9.9 GB);
- \*\*19,456개의 라우팅드 전문가(routed experts)\*\* (75개의 MoE 레이어 × 256 + MTP 헤드, int4 기준
각각 약 19 MB)는 \*\*디스크에 위치\*\*하고 (~370 GB) 레이어별 LRU 캐시, 학습된 핀드 핫 스토어(pinned hot-store), 그리고 선택적 VRAM 티어와 함께 \*\*요청에 따라 스트리밍\*\*됩니다.
핵심 알고리즘을 \*\*가중치를 위한 JIT(Just-In-Time)\*\*로 생각하시면 됩니다. 컴파일러 JIT은 프로그램 전체를 컴파일하지 않고, 실제로 실행되는 것을 지켜보며 핫 패스(hot path)를 적시에 컴파일합니다. colibrì는 744B 파라미터 공간에 대해 정확히 같은 접근을 취합니다. 즉, 파라미터는 보유해야 할 상주 상태가 아니라, 라우터가 필요하다고 증명하는 바로 그 순간에 이종 스토리지 계층(VRAM / RAM / NVMe) 간에 \*\*스테이징(staged)될 데이터\*\*입니다. 측정된 라우팅 히트(routing heat)가 어떤 전문가가 어떤 티어를 차지할지 결정하고, 라우터가 한 레이어 앞서 실행되어 프리페치(prefetch)가 스테이징 지연을 숨기며, JIT처럼 엔진이 사용자의 워크로드를 학습합니다. 즉, 더 많이 실행할수록 올바른 전문가들이 더욱 뜨거워집니다(hotter). 라우팅에는 측정 가능한 구조가 존재하고([expert atlas](https://github.com/JustVugg/colibri/issues/175) 참조) 구조는 캐시 가능하기 때문에 이 방식이 작동합니다.
이 엔진은 단일 C 파일(`c/glm.c`)과 소수의 헤더로 이루어져 있습니다. BLAS도 없고, 런타임 시 Python도 필요 없으며, GPU도 필수가 아닙니다.

## 작동 방식 (How it works)
### 토큰별 경로 (The per-token path)

![route → union → place → overlap → learn](docs/media/token-path.png)

모든 토큰의 모든 레이어는 동일한 다섯 단계를 거칩니다. 설계 목표는 \*\*배치가 오직 속도에만 영향을 미치도록 하는 것\*\*입니다. 즉, 전문가가 VRAM에서 응답하든 디스크에서 응답하든 라우터의 결정과 가중치의 정밀도는 동일합니다.

### 단일 메모리 요구사항 대신 단일 메모리 계층 구조

![VRAM / RAM / NVMe three-tier expert residency](docs/media/tiers.png)

### Dual-SSD: 모델 복사본 2개, 2배의 읽기 대역폭
대부분의 머신에서 디코딩은 디스크 병목(disk-bound) 현상을 겪고 전문가(expert) 읽기는 읽기 전용입니다. 따라서 \*\*두 번째 SSD\*\*가 있다면 그곳에 모델의 전체 복사본을 두고 엔진이 두 드라이브에서 동시에 스트리밍하도록 설정할 수 있습니다.
```bash
COLI\_MODEL=/fast/glm52\_i4 COLI\_MODEL\_MIRROR=/second/glm52\_i4 ./coli chat
COLI\_DISK\_WEIGHTS=9,3 ... # 선택 사항: 주 드라이브와 미러 드라이브의 대역폭 비율 (지정하지 않으면 시작 시 측정됨)
```
각 전문가는 두 드라이브의 측정된(또는 선언된) 대역폭을 가중치로 사용하는 결정론적 해시에 의해 하나의 드라이브로 라우팅됩니다. 따라서 미리 읽기(readahead)/PILOT 프리페치와 온디맨드 읽기는 항상 동일한 드라이브를 타격하며 어떤 것도 두 번 캐시되지 않습니다. 총 대역폭은 두 드라이브의 합입니다. 9 GB/s와 3 GB/s 드라이브 쌍은 빠른 드라이브 단독 사용보다 전문가를 약 33% 더 빠르게 읽어오며, OMP 병렬 핀(pin)/워밍업 로드도 양쪽에서 스트리밍됩니다. 알아두면 좋은 세부 정보:
- 미러는 \*\*시작 시 검증됩니다\*\* (파일별 크기 + safetensors 헤더가 주 드라이브와 바이트 단위로 동일해야 함). 일치하지 않거나 누락된 파일은 조용히 주 드라이브에 유지되므로 \*\*부분 미러도 괜찮습니다\*\*. 일부 샤드(shard)만 담고 있는 더 작은 두 번째 SSD도 여전히 도움이 됩니다.
- 미러는 \*\*절대 쓰여지지 않습니다\*\*: `.coli\_usage`, `.coli\_kv` 및 모든 사이드카(sidecar) 파일은 주 드라이브에 유지됩니다.
- 미러에서 읽기 오류가 발생하면 주 드라이브로 폴백됩니다(경고 1회 발생, 크래시 없음). 따라서 실행 중에 두 번째 드라이브를 뽑아도 서버가 죽는 대신 성능만 저하됩니다.
- 라우팅은 토큰을 절대 변경하지 않습니다. 두 복사본은 바이트 단위로 동일하며, 실행별 `MIRROR:` 통계 라인에 드라이브당 제공된 GB가 표시됩니다.
동일한 엔진이 전 영역을 아우릅니다. 25 GB 노트북에서는 모든 것이 디스크에서 스트리밍되고(느리지만 정확함), 대형 호스트에서는 전체 전문가 세트가 상주하게 되어(`CUDA\_EXPERT\_GB=auto PIN\_GB=all`) 디코딩 경로에서 디스크가 완전히 사라집니다. 계층 사이에는 \*\*학습 캐시(learning cache)\*\*가 위치합니다. 엔진은 사용자의 워크로드 가 라우팅되는 전문가를 기록하고(`.coli\_usage`, 매 턴마다 업데이트됨) 가장 자주 사용되는(hottest) 전문가들을 자동으로 고정(pin)합니다. 즉, colibrì는 사용할수록 말 그대로 더 빨라집니다. 멀티 소켓 호스트에서는 `COLI\_NUMA=1`을 통해 상주 가중치를 메모리 컨트롤러에 걸쳐 인터리빙할 수 있습니다 ([#82](https://github.com/JustVugg/colibri/issues/82)).
모델 전체를 담을 수 없는 두 번째 드라이브의 경우, Colibri는 이미 학습된 전문가 기록을 바탕으로 부분 미러의 순위를 매길 수 있습니다. 먼저 대표적인 프롬프트 몇 개를 실행하여 `.coli\_usage`에 워크로드가 반영되도록 한 다음, 미러를 계획, 스테이징 및 검증합니다.
```bash
./c/coli mirror plan --model /fast/glm52\_i4 --mirror /second/glm52\_i4 \
--budget-gib 200 --reserve-gib 20
./c/coli mirror stage --model /fast/glm52\_i4 --mirror /second/glm52\_i4 \
--budget-gib 200 --reserve-gib 20
./c/coli mirror verify --model /fast/glm52\_i4 --mirror /second/glm52\_i4
```
플래너는 safetensors 헤더를 직접 읽고, `COLI\_MODEL\_DIRS`에서 분할 모델 디렉토리를 추적하며, 가장 빈번하게 라우팅되는 전문가를 서브할 수 있는 샤드에 우선순위를 둡니다. 스테이징은 주 모델을 절대 변경하지 않습니다. 임시 파일을 통해 복사하고, 요청된 여유 공간 예비(reserve-space)를 유지하며, SHA-256으로 모든 샤드를 검증하고, 기존 미러 샤드를 절대 삭제하지 않으며, 선택한 미러가 준비된 후에만 영수증(receipt)을 원자적으로(atomically) 게시합니다.
### 디스크를 두 번 기다리지 마세요
미스(miss)는 비용이 많이 들므로 엔진은 이를 방지하고 겹치게(overlap) 처리하는 데 대부분의 기교를 발휘합니다. 각 전문가의 세 개 행렬은 인접하게 저장되어 하나의 `pread`로 읽히고, 제한된 비동기 I/O 풀(`PIPE=1`, 기본값)이 상주 전문가들이 계산하는 동안 누락된 전문가를 로드하며, 일괄 처리된 위치(batched positions)는 각 고유 전문가를 한 번씩 읽고(\*\*배치 유니온(batch-union)\*\*), 라우터 미리보기(lookahead) 스레드(`PILOT=1`)가 다음 레이어의 전문가를 미리 가져옵니다. 라우팅은 한 레이어 앞을 측정 가능하게도 \*\*71.6% 예측\*\*할 수 있습니다.
GPU에서는 상주 파이프라인(`COLI\_CUDA\_PIPE=2`)이 레이어 전반에 걸쳐 잔류 스트림(residual stream)을 온디바이스에 유지하여 CPU 전문가 루프가 중단 없이 실행되도록 합니다. Apple Silicon에서는 실험적인 [Metal 백엔드](docs/metal.md)가 통합 메모리(unified-memory) GPU에서 배치 전문가 연산을 수행하며, [Vulkan 백엔드](docs/vulk

an.md)은 Vulkan 1.2 드라이버를 지원하는 모든 GPU(Mesa/RADV를 통한 AMD 카드 - 공급업체 스택에서 더 이상 지원하지 않는 RX 580 같은 카드용의 유일한 백엔드이자 RDNA4에서는 ROCm과 경쟁력 있는 성능을 보여줌 — [벤치마킹 노트](docs/vulkan.md) 참조)에 전문가 수준의 밀집 투영(dense projections)과 MLA 어텐션 코어를 제공합니다.
> \*\*실제 NVMe에서는 `DIRECT=1`을 측정하세요.\*\* O_DIRECT는 페이지 캐시를 우회하며, DRAM 캐시와 대역폭 여유가 있는 드라이브에서 큰 성능 향상을 가져오는 경우가 많습니다(Blackwell/Windows 박스에서 `PIPE=1`로 측정 시 디코딩 +34% 향상; GB10의 iobench에서 4.25→9.69 GB/s). 하지만 이는 드라이브에 따라 다릅니다. QLC/DRAM-less 또는 가상화된 디스크에서는 성능이 비슷하거나 오히려 저하될 수 있습니다. 먼저 테스트해 보고 하드웨어에 가장 유리한 방식을 유지하세요.
### 충실한 모델, 압축된 상태
포워드 패스(forward pass)는 `transformers` 오라클을 기준으로 검증되었습니다(교사 강제(teacher-forcing)는 일반적으로 30-32/32이며, 두 개의 작은 오라클 위치는 부동 소수점 근사 동등 상태이며 툴체인에 따라 다름). MLA 어텐션은 압축된 KV 상태를 저장하며(32,768개 대신 토큰당 576개 부동 소수점 — \*\*57배 더 작음\*\*), 이를 재시작 시점에도 유지합니다(`.coli_kv`). 따라서 재프리필(re-prefill) 없이 대화가 바로 재개되며, 중단되지 않은 세션과 바이트 단위까지 완벽하게 동일합니다. DSA 희소 어텐션(GLM-5.2의 라이트닝 인덱서)이 충실하게 구현되어 있으며, 밀집 어텐션을 정확히 재현하도록 전체 키 선택을 강제하여 검증되었습니다.
### 정직한 추론 디코딩 (Speculative decoding)
GLM-5.2의 네이티브 MTP 헤드는 메인 모델이 단일 배치 포워드로 검증하는 토큰을 초안(draft)으로 생성하며, 효과가 있을 때 포워드당 2.2–2.8개의 토큰을 처리합니다. 어렵게 얻은 두 가지 규칙이 기본값으로 적용됩니다. MTP 헤드는 반드시 \*\*int8\*\*이어야 하고(int4 헤드는 수용률이 0–4%로 폭락함, [#8](https://github.com/JustVugg/colibri/issues/8)), 초안 생성과 검증은 \*\*동일한 함수\*\*를 연산해야 합니다 (`SPEC_PIN=1`은 둘 모두를 하나의 커널 패밀리로 고정합니다 — [#163](https://github.com/JustVugg/colibri/issues/163)에 전체 포렌식 내역이 있습니다). 문법이 강제된 초안([`GRAMMAR=file.gbnf`](docs/grammar-draft.md))은 제한된 JSON 출력에서 비용 부담 없이 수용률을 높여줍니다. 추론 디코딩이 실제로 이득이 되는지는 캐시 온도에 따라 다릅니다. 직접 측정해 보고 효과가 없을 때는 `DRAFT=0`을 사용하세요.
## 달성하는 것들

![measured decode speed by hardware class](docs/media/ladder.png)

동일한 엔진, 동일한 int4 컨테이너 — 하드웨어는 단지 전문가(expert)가 상주하는 위치만 바꿉니다. [전체 벤치마크 표](docs/benchmarks.md)의 주요 내용:
- \*\*6× RTX 5090, 전체 상주:\*\* 5.8–6.8 tok/s 디코드, TTFT ~13초
([실험 로그](docs/experiments/glm52-6x5090-2026-07-12.md));
- \*\*128 GB CPU 전용 데스크톱:\*\* ~1.8 tok/s 웜([#200](https://github.com/JustVugg/colibri/issues/200));
- \*\*단일 RTX 5070 Ti 노트북 클래스 장치:\*\* GPU 상주 파이프라인을 통해 1.07 tok/s
([#273](https://github.com/JustVugg/colibri/issues/273));
- \*\*25 GB 개발용 장치:\*\* 0.05–0.1 tok/s 콜드 — 이 프로젝트가 시작된 입증된 하한선이자 여전히 신뢰할 수 있는 기준선입니다.
품질은 추정하는 것이 아니라 측정됩니다. int4 컨테이너의 양자화 비용과 스케일-세분성/회전 어블레이션(ablation)은 [docs/benchmarks.md](docs/benchmarks.md#quality-benchmark) 및 [#108](https://github.com/JustVugg/colibri/issues/108)/[#81](https://github.com/JustVugg/colibri/issues/81)에서 확인할 수 있습니다.
## 시작하기
두 가지가 필요합니다: \*\*프로그램\*\* (수백 KB)과 \*\*모델\*\* (372 GB). 모든 플랫폼을 위한 단계별 안내는 [빠른 시작 가이드](docs/quickstart.md)에 있습니다.
### 1. colibri 가져오기
\*\*사전 빌드된 릴리스 다운로드\*\* — Linux, macOS, Windows를 지원하며 컴파일러가 필요 없습니다.
[Releases](https://github.com/JustVugg/colibri/releases)에서 사용 중인 플랫폼에 맞는 아카이브를 받아 압축을 해제하세요:
```bash
mkdir colibri && tar xzf colibri-v1.1.0-linux-x86\_64.tar.gz -C colibri && cd colibri
python3 coli info # engine ready ✓
```
내부에는 엔진(`colibri`, Windows의 경우 `colibri.exe`), `coli` 런처 및 파이썬 헬퍼가 포함되어 있습니다. 이름을 바꾸거나 설정할 필요가 없습니다. `coli`가 바로 옆에 있는 엔진을 찾아냅니다. [Python 3](https://www.python.org/downloads/)만 설치되어 있으면 됩니다. 런처와 API 게이트웨이는 파이썬 스크립트이고, 엔진 자체는 의존성이 전혀 없는 순수 C로 작성되었습니다.
\*\*또는 소스에서 빌드\*\* — OpenMP가 포함된 `gcc`(또는 clang)가 필요합니다:
```bash
git clone https://github.com/JustVugg/colibri && cd colibri/c
./setup.sh # checks gcc/OpenMP, builds, self-tests
```
PATH에 `coli`를 등록하고 싶으신가요? 체크아웃 디렉토리에서 `pip install -e .`를 실행하면 등록됩니다(엔진은 여전히 `c/`에 남아 있으며, 휠이 아닌 클론으로부터의 편집 가능한(editable) 설치입니다).
### 2. 모델 가져오기
사전 변환된 \*\*GLM-5.2 int4\*\* 컨테이너가 Hugging Face에 있습니다. \*\*int8 MTP 헤드\*\*가 포함된 \*\*그룹 스케일(gs64)\*\* 빌드를 사용하세요. 용량이 약 \*\*372 GB\*\*이므로 충분한 공간이 있는 디스크(가급적 빠른 디스크)에 저장하세요:
\*\*https://huggingface.co/mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp\*\*
> ⚠️ 이전의 행별(per-row) int4 미러(`mateogrgic/…`, `jlnsrk/…`) 대신 위의 \*\*gs64\*\* 컨테이너를 사용하세요. 해당 미러들은 품질이 ~9pp 떨어지며 [#455](https://github.com/JustVugg/colibri/issues/455)에서 발생한 원본 생각 모드(think-mode) 루프 및 무한 생성 문제의 근본 원인입니다. gs64 컨테이너는 그러한 제어된 행별 A/B 테스트 문제를 해결했지만, 일반적인 반복 또는 EOS 고갈 방지 가드는 아닙니다. 또한 MTP 헤드는 int4가 아니라 \*\*반드시 int8이어야 합니다\*\*
> (int4 사용 시 드래프트 수락률 0%, [#8](https://github.com/JustVugg/colibri/issues/8)):
> `ls -l /out-mtp-\*` — int8(정상)의 크기는 `3527131672 / 5366238584 / 1065950496`입니다.
또는 FP8 소스에서 직접 변환하세요. 디스크에 한 번에 전체 756 GB가 필요 없는, 중단 지점 이어서 하기가 가능한 단일 명령어입니다:
```bash
./coli convert --model /nvme/glm52\_i4 # download+convert shard by shard (python, one-time)
```
#### 지원되는 기타 모델
GLM-5.2가 기준 모델이지만, 동일한 스트리밍 접근 방식으로 세 가지 패밀리가 더 지원됩니다. 각각은 \*\*시블링 엔진(sibling engine)\*\*으로, 하나의 C 파일과 고유한 아키텍처를 가지며 동일한 `coli chat` / `coli serve` / `coli web` 프런트엔드를 공유합니다(런처는 모델의 `config.json`에서 바이너리를 선택합니다):
> \*\*각 모델이 필요로 하는 것.\*\* 이 모델들은 서로 많이 다르며, 두 모델의 요구사항을 함께 읽은 일부 사람들은 요구사항이 서로 상충한다고 오해했습니다
> ([#191](https://github.com/JustVugg/colibri/issues/191)). 상충하지 않습니다. 서로 다른 모델일 뿐입니다. \*\*어떤 모델도 GPU가 필요하지 않습니다.\*\*
>

| Model | Disk for the weights | RAM | GPU |
> |---|---|---|---|
> | \*\*OLMoE\*\* | ~4 GB | 8 GB | not needed |
> | \*\*GLM-5.2\*\* | ~372 GB | 16 GB min, 24 GB comfortable | not needed |
> | \*\*Inkling\*\* | ~469 GB | 25 GB with the int4 dense container, ~120 GB without | not needed |
> | \*\*Kimi K3\*\* | ~1.6 TB | 32 GB+ | not needed |
> | \*\*DeepSeek V4 Flash\*\* | ~167 GB | 16 GB min, 22 GB comfortable | not needed |
>
> GPU는 속도를 빠르게 만들어 줄 뿐입니다. 전문가(expert)들이 디스크에서 스트리밍 방식으로 로드되기 때문에 속도는 디스크 성능에 따라 결정됩니다. 느린 드라이브에서는 초당 0.부 토큰의 속도가 나오며, 캐시가 워밍업된 빠른 드라이브에서는 초당 수 개의 토큰이 처리됩니다.
| Family | Total / active | Weights | Build | Docs |
|---|---|---|---|---|
| \*\*GLM-5.2\*\* | 744B / 40B | [`mastouri/…-int4-g64-with-int8-mtp`](https://huggingface.co/mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp) (372 GB) | `make -C c glm` | this page |
| \*\*Inkling\*\* (Thinking Machines) | 975B / 41B | [`nbeerbower/Inkling-colibri-int4`](https://huggingface.co/nbeerbower/Inkling-colibri-int4) (469 GB) | `make -C c inkling` | [inkling.md](docs/inkling.md) |
| \*\*Kimi K3\*\* (Moonshot) | 2.8T / 104B | [`moonshotai/Kimi-K3`](https://huggingface.co/moonshotai/Kimi-K3) — original checkpoint, routed experts stay \*\*native MXFP4\*\* | `make -C c kimi\_k3` | [kimi\_k3.md](docs/kimi\_k3.md) |
| \*\*DeepSeek V4 Flash\*\* | 284B / 13B | official sharded checkpoint — routed experts stay \*\*native fp4\*\*, dense stays fp8-e4m3 | `make -C c deepseek-v4` | [deepseek-v4.md](docs/deepseek-v4.md) |
| \*\*OLMoE\*\* (AI2) | 7B / 1B | converted with `c/tools/convert\_olmoe\_merged.py` | `make -C c olmoe` | — |
Kimi K3는 변환이 필요 없습니다. QAT로 학습된 MXFP4 전문가들이 원본 Hugging Face 샤드에서 직접 스트리밍되며, bf16 밀집(dense) 세트는 로드 시점에 양자화됩니다.
Inkling은 int4 전문가들과 함께 \*\*bf16 밀집 가중치\*\*를 제공합니다(상주 용량 49.4 GB). 해당 용량을 수용할 수 없는 호스트의 경우, [inkling.md](docs/inkling.md)에 밀집 세트를 15.3 GB로 줄여 975B 모델을 25 GB 장비에서 실행할 수 있게 해주는 원패스(one-pass) 도구가 마련되어 있습니다(명시된 트레이드오프가 존재합니다).
### 3. 실행하기
```bash
COLI\_MODEL=/nvme/glm52\_i4 ./coli chat # RAM 예산, 캐시 및 MTP 자동 감지
COLI\_MODEL=/nvme/glm52\_i4 ./coli plan # 계획된 VRAM/RAM/디스크 배치 검사
COLI\_MODEL=/nvme/glm52\_i4 ./coli doctor # 읽기 전용 준비 상태 확인
COLI\_MODEL=/nvme/glm52\_i4 ./coli doctor --deep # 엄격한 텐서/샤드/인덱스/미러 사전 검사
COLI\_MODEL=/nvme/glm52\_i4 ./coli tune # 이 머신에 가장 빠른 안전 실행 프로필 측정 및 저장
./coli web --model /nvme/glm52\_i4 # API + 대시보드 및 브라우저 열기
./coli serve --model /nvme/glm52\_i4 # API + 대시보드, 브라우저 없음 (헤드리스)
```
Windows에서는 `python coli chat --model D:\glm52\_i4` 명령어로 동일하게 실행할 수 있습니다.
런타임 엔진은 순수 C로 구현되어 있으며, 파이썬은 일회성 변환기와 선택적 API 게이트웨이에만 사용됩니다.
#### 동일한 명령어로 모든 모델을 실행할 수 있습니다
`coli`는 모델의 `config.json`을 읽고, 일치하는 엔진 바이너리를 선택한 뒤, 해당 패밀리의 챗 템플릿을 렌더링합니다. 따라서 \*\*모델에 따라 명령줄이 변경되는 부분이 전혀 없습니다\*\*. 원하는 엔진을 한 번 빌드한 후, `COLI\_MODEL`을 올바른 디렉터리로 지정하기만 하면 됩니다.
```bash
make -C c glm # GLM-5.2
make -C c inkling # Inkling
make -C c kimi\_k3 # Kimi K3
COLI\_MODEL=/nvme/glm52\_i4 ./coli chat # TUI
COLI\_MODEL=/nvme/inkling\_i4 ./coli chat
COLI\_MODEL=/nvme/kimi\_k3 ./coli chat
./coli web --model /nvme/inkling\_i4 # API + 대시보드, 브라우저 열기
./coli web --model /nvme/kimi\_k3
./coli serve --model /nvme/inkling\_i4 # API + 대시보드, 브라우저 없음
```
GLM이 아닌 엔진의 경우, `coli chat`은 로컬에서 게이트웨이를 시작하고 TUI를 여기에 연결하므로 TUI, API, 대시보드 모두 동일한 아키텍처 인식 챗 템플릿을 거치게 됩니다. 사용자가 직접 템플릿을 전달할 필요가 없습니다.
모델마다 다른 두 가지 사항이 있으며, 두 사항 모두 모델별 페이지에 문서화되어 있습니다.
- \*\*RAM이 부족한 호스트에서의 Inkling\*\*은 int4 밀집 컨테이너가 필요합니다.

그리고 작은 expert 캐시: `./coli chat --model /nvme/inkling\_i4 --cap 2`
([inkling.md](docs/inkling.md) 참조 — 기본값인 `--cap 8`은 상주 세트 외에 약 14 GB의 캐시가 필요합니다).
- **Kimi K3**는 원본 체크포인트에서 MXFP4 expert를 스트리밍하므로 변환할 필요가 없지만, 스냅샷 용량이 약 1.6 TB입니다
([kimi\_k3.md](docs/kimi\_k3.md) 참조).

### 4. 심층 학습
| topic | doc |
|---|---|
| 벤치마크, 커뮤니티 데이터포인트, 품질 측정 | [docs/benchmarks.md](docs/benchmarks.md) |
| 튜닝 노브, 정책, 학습 캐시, 프리페치 | [docs/tuning.md](docs/tuning.md) |
| Windows 11 네이티브 빌드 (+ CUDA DLL) | [docs/windows.md](docs/windows.md) |
| CUDA 백엔드, VRAM expert 계층, 전체 상주 | [docs/cuda.md](docs/cuda.md) |
| Vulkan 백엔드 (모든 GPU: RADV를 사용하는 AMD, ROCm 지원이 중단된 카드 포함) | [docs/vulkan.md](docs/vulkan.md) |
| Apple Silicon Metal 백엔드 | [docs/metal.md](docs/metal.md) |
| OpenAI 호환 API, KV 슬롯, 웹 대시보드 | [docs/api.md](docs/api.md) |
| 문법 강제 초안 (구조화된 출력) | [docs/grammar-draft.md](docs/grammar-draft.md) |
| 환경 변수 목록 | [docs/ENVIRONMENT.md](docs/ENVIRONMENT.md) |

## DeepSeek V4
**DeepSeek V4 Flash**는 변환 없이 공식 체크포인트를 스트리밍합니다. 라우팅된 expert는 **native fp4**로 유지되고, 덴스 세트는 UE8M0 블록 스케일이 적용된 **fp8-e4m3**로 유지됩니다. MLA + DSA 스파스 어텐션, 43개 레이어, 256개의 라우팅된 expert와 1개의 공유 expert, top-6 구조입니다. x86-64/aarch64 Linux 및 Windows/MSYS2에서 지원됩니다.

```bash
cd c
make deepseek-v4
python ./coli chat --model /path/to/DeepSeek-V4-Flash --ram 22
# 또한 지원: coli run / coli serve / coli web
```

그리디 디코드, 하나의 KV 슬롯; 도구와 문법은 아직 연동되지 않았습니다.

**RAM을 할당하세요.** 43 × 256개의 라우팅된 expert는 디스크상에서 약 137 GiB이며, 토큰 하나당 이 중 301개를 참조하므로 tok/s를 결정하는 것은 expert 캐시 적중률입니다. `--ram`은 가장 유용한 단일 노브이며, 출력 결과는 전혀 변경하지 않고 오직 속도만 변경합니다.

**추론형 초안 생성(Speculative drafting) 기능이 존재하며 기본적으로 꺼져 있습니다.** DSpark의 마르코프 초안 생성기와 전체 MTP가 모두 구현 및 검증되었습니다. 초안은 순방향 패스를 절약할 수 있지만 승인된 모든 토큰은 여전히 타겟 자신의 argmax이므로 토큰을 변경할 수는 없습니다. 실제 멀티턴 챗에서 측정한 결과 15개 중 1개, 24개 중 1개가 승인되었으나, 이 엔진의 순환 어텐션 상태에서 거부된 접미사(rejected-suffix)를 재생하는 비용이 초안이 절약한 비용보다 컸습니다. 14토큰 답변 하나에 495초가 걸렸습니다. 따라서 `V4\_DRAFT`와 `V4\_MTP`는 기본값이 `0`으로 설정되어 있으며, 더 빠른 스토리지에서 이 기능을 다시 시도해 볼 사람들을 위해 코드와 그 옆의 수치들은 그대로 유지됩니다.

체크포인트 검증, 생성된 초소형 독립 오라클, 전체 노브 목록은 [docs/deepseek-v4.md](docs/deepseek-v4.md)를 참조하세요.

## 다음 계획
- **추론 시스템 연구가 곧 제품입니다.** 현재 계층 구조는 LRU + 학습된 고정(pin) 세트로 구성되어 있습니다. 진행 중인 작업은 모델 포맷, 압축, 배치, 스케줄링, I/O, CPU/GPU 커널, 이종 오버랩, KV 상태, 라우팅 인식 추론(routing-aware speculation)에 걸쳐 있습니다. 목표는 하드웨어 요구 사항을 낮추고 유용한 토큰당 비용을 줄이는 것입니다. 모든 기능은 이 프로젝트가 작동하는 방식 그대로 엔드투엔드로 측정되고, 리뷰되며, 오픈 소스로 개발됩니다.
- **더 많은 오픈 모델.** 계층화 알고리즘은 모델에 구애받지 않습니다. 라우팅된 expert가 있는 모든 MoE는 동일한 방식으로 스테이징할 수 있습니다. GLM-5.2와 OLMoE는 지금도 실행되며, **Kimi K2** (Moonshot AI), **Qwen3 MoE** (Alibaba), **MiniMax**를 비롯한 더 많은 오픈 웨이트 패밀리에 대한 지원이 로드맵에 있습니다.

## 프로젝트 지원하기
colibrì는 25 GB RAM이 탑재된 12코어 노트북에서 1인 프로젝트로 시작되었습니다. 오늘날 그 수치는 실제 머신들로 구성된 커뮤니티에서 비롯됩니다. 이 프로젝트가 도움이 되었다면:
- ⭐ 저장소에 스타를 누르고 공유해 주세요;
- 🐛 하드웨어의 벤치마크 수치와 함께 이슈를 열어주세요. 데이터포인트가 이 프로젝트를 움직이는 가장 큰 원동력입니다;
- 💬 실험, 하드웨어 결과, 연구 방향에 대해 논의하려면 [Discord 커뮤니티](https://discord.gg/MAaKtQRc)에 참여하세요;
- 💬 개발 후원이나 하드웨어 기부는 GitHub 이슈를 통해 문의해 주세요.

## 저장소 구조
```
Makefile root build/chec

k entry point
c/
├── colibri.c GLM-5.2 engine (make glm)
├── inkling.c Inkling engine (make inkling)
├── kimi\_k3.c Kimi K3 engine (make kimi\_k3)
├── deepseek\_v4.c DeepSeek V4 Flash engine (make deepseek-v4)
├── olmoe.c OLMoE engine (make olmoe)
│
├── st.h safetensors 인덱스 및 범위 읽기
├── quant.h 정규 컨테이너 디코더
├── tok.h, json.h 토크나이저 및 JSON 파서
├── compat.h Windows/macOS 심 (POSIX 이름, 단일 위치)
├── expert\_store.h 스트리밍 익스퍼트 캐시
├── route\_trace.h 라우팅 텔레메트리 및 .coli\_usage, 엔진 비종속적
├── kv\_prefix.h 턴 간 KV 프리픽스 재사용
│
├── backend\_cuda.\* 선택적 CUDA 계층 (CUDA=1)
├── backend\_metal.\* 선택적 Metal 계층 (METAL=1)
├── backend\_vulkan.\* 선택적 Vulkan 계층 (VULKAN=1)
│
├── Makefile 빌드 및 로컬 검사
├── coli 사용자 대면 CLI
├── openai\_server.py OpenAI 호환 HTTP 게이트웨이
├── resource\_plan.py `coli plan` 및 `coli doctor` 뒤의 RAM/VRAM 플래너
├── tools/ 오프라인 변환, 픽스처 및 벤치마크
├── scripts/ 장기 실행 변환 도우미
└── tests/ 종속성 없는 C 및 Python 테스트
web/ 브라우저 UI (순수 OpenAI-API 클라이언트)
desktop/ 웹 UI를 래핑하는 Tauri v2 데스크톱 셸
docker/ 컨테이너 이미지
docs/ 레퍼런스 문서, 실험, 미디어
```
\*\*모델 가족당 하나의 `.c` 파일, 공유 단일 헤더 사용.\*\* 엔진은 자신의
아키텍처만 관리하며 다른 것은 관리하지 않습니다. 두 엔진이 모두 필요로 하는 기능(safetensors 리더, 컨테이너 디코더, 토크나이저, 익스퍼트 캐시)은 두 엔진이 모두 인클루드하는 헤더에 위치하므로, 수정 사항이 모든 엔진에 한 번에 적용됩니다. 이 규칙은 장식용이 아닙니다. 여기서 반복해서 발생하는 결함들은 메커니즘이 하나의 엔진에만 도입되고 그 형제 엔진들에는 적용되지 않았던 경우들입니다.
저장소 루트에서 `make`, `make check` 및 `make clean`은 엔진 Makefile에 위임됩니다.
## 왜 "colibrì"인가
벌새는 몇 그람밖에 나가지 않고, 제자리에 호버링하며, 하루에 천 송이의 꽃을 방문합니다. 이 엔진은 벌새의 식량으로 7,440억 개의 파라미터를 가진 거대 모델을 유지합니다: 25GB의 RAM, 12개의 CPU 코어, 그리고 디스크에 대한 상당한 인내심이 필요합니다.
## 감사의 글
colibrì는 엔진일 뿐이며, 그것이 구동하는 지능은 선물입니다. 오픈 소스로 최첨단 가중치를 공개해 주신 팀들 — \*\*Z.ai\*\* (GLM), \*\*Moonshot AI\*\* (Kimi), \*\*Alibaba Qwen\*\*, \*\*MiniMax\*\*, \*\*Allen AI\*\* (OLMoE) — 그리고 벤치마크하고, 이분법적 탐색을 수행하고, 아틀라스 실행을 재현하거나 패치를 보내 주신 모든 기여자분께 감사드립니다. 이 프로젝트는 오픈 웨이트가 무엇을 가능하게 하는지 보여주는 증거입니다.
이 프로젝트의 익스퍼트 배치, 압축 및 라우팅 실험은 또한 다음의 오픈 연구 및 시스템 작업의 아이디어와 증거를 기반으로 구축되었습니다:
- 출력 인식 및 도메인별 익스퍼트 중요도를 위한 [REAP](https://github.com/CerebrasResearch/reap) 및 [EASY-EP](https://github.com/RUCAIBox/EASYEP).
- 유사도 기반 익스퍼트 재라우팅을 위한 [SERE](https://github.com/JL-Cheng/SERE), 그리고 캐시 지역성 인식 라우터 파인튜닝을 위한 [ReMoE](https://github.com/BUAA-OSCAR/ReMoE).
- 라우팅 유도 익스퍼트 병합 및 압축을 위한 [MC-SMoE](https://github.com/UNITES-Lab/MC-SMoE).
- 공유 익스퍼트 베이스 및 저랭크 익스퍼트 델타를 위한 [MoBE](https://github.com/inclusionAI/MoBE) 및 [D²-MoE](https://github.com/lliai/D2MoE).
- 하이브리드 CPU/GPU 익스퍼트 스케줄링을 위한 [HybriMoE](https://github.com/PKU-SEC-Lab/HybriMoE), 연산과 익스퍼트 통신을 중첩하기 위한 [ScMoE](https://arxiv.org/abs/2404.05019), 그리고 분산 온디맨드 익스퍼트 로딩을 위한 [OD-MoE](https://arxiv.org/abs/2512.03927).
- 비교를 재현 가능하게 만드는 오픈 추론 시스템 및 익스퍼트 오프로드 작업을 위한 [vLLM](https://github.com/vllm-project/vllm), [llama.cpp](https://github.com/ggml-org/llama.cpp), [kTransformers](https://github.com/kvcache-ai/ktransformers).
또한 이 엔진은 아이디어뿐만 아니라 구체적인 엔지니어링 작업에 기반을 두고 있습니다. 이 중 각각은 현재 소스 트리에 사용되거나 재구현되어 있습니다:
- [safetensors](https://github.com/huggingface/safetensors) — fp8 및 I64 데이터 타입을 포함하여 모든 엔진이 읽는 컨테이너 (`c/st.h`).
- [t

[tiktoken](https://github.com/openai/tiktoken) — `c/tok.h`는 정확히 그 `byte\_pair\_encode`를 재구현하여, 연결했을 때 가장 낮은 vocab ID를 가지는 인접 쌍을 병합합니다. 따라서 tiktoken에서 파생된 단어장은 별도의 병합(merges) 리스트가 필요 없습니다.
- [llama.cpp](https://github.com/ggml-org/llama.cpp) — `c/grammar.h`의 GBNF 문법 서브셋은 그 문법과 스택 집합 PDA를 따르며, Metal 패스는 `newBufferWithBytesNoCopy` 상주(residency) 트릭을 차용합니다.
- [vLLM](https://github.com/vllm-project/vllm) — 엔진이 위치별로(예: 최종 norm이 LM head 대비 어디에 위치하는지 등) 정확히 일치시키는 출력 의미론의 레퍼런스입니다.
- [transformers](https://github.com/huggingface/transformers) — 오라클: CI는 이에 맞춰 랜덤 초기화된 모델의 토큰을 토큰 단위로 재현합니다.
- [DietGPU](https://github.com/facebookresearch/dietgpu) — 실험적 압축  전문가 티어(`COLI\_ANS`)를 뒷받침하는 GPU ANS 코덱입니다.
- [rocWMMA](https://github.com/ROCm/rocWMMA) — HIP 백엔드가 CUDA의 `nvcuda::wmma` fragment/mma\_sync API를 이 위에 매핑하며(`c/backend\_gpu\_compat.h`), 이를 통해 하나의 .cu 소스코드로 양쪽 벤더 모두 컴파일할 수 있습니다.
## License
Apache 2.0. GLM-5.2 가중치는 Z.ai에서 MIT 라이선스로 배포합니다.

colibri

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README