shardr — 모델을 위한 Docker 같은 도구, BitTorrent 동기화, OpenAI 호환 서빙, 상위 스트림의 추론 엔진

저는 항상 똑같은 세 가지 문제에 직면했습니다. 제가 잊어버린 폴더에 존재했기 때문에 동일한 40 GB 양자화(quant) 파일을 두 번 다운로드해야 했고, 모델들이 Hugging Face에서 조용히 사라지거나, 모든 도구들이 디스크에 가중치(weights)의 자체 사본을 유지하는 문제였습니다. 그래서 저는 shardr를 만들었습니다. 이는 기계에 모델을 위한 단일 콘텐츠 주소 지정 저장소(content-addressed store)를 제공하는 작은 Go 데몬(Apache-2.0)입니다.

구체적으로 작동하는 방식은 다음과 같습니다:

• 모든 것은 SHA-256으로 저장되고 검증됩니다. 신뢰는 출처가 아니라 다이제스트(digests)에서 나옵니다.
• BitTorrent v2를 사용합니다. 피어들로부터 모델을 가져올 수 있으며, 자신이 가진 것을 스웜(swarm)에 다시 시딩(seeding)할 수 있습니다.
• 러너(runner)는 OpenAI 호환 API를 사용하여 llama-server를 시작하고 가중치를 저장소에서 직접 mmap 합니다. 즉, 디스크에 하나의 사본만 존재하며 스테이징 복사본이나 파일 이동이 없습니다.
• 런타임은 상위 스트림의 llama.cpp 릴리스 바이너리(절대 자체 컴파일하지 않음, 다이제스트 검증)를 통해 잠금 파일(lockfile)로 고정되므로, llama.cpp 업데이트는 해당 테스트 매트릭스 전체가 뒤에 있는 잠금 파일에 대한 PR만 있으면 됩니다.

이것은 pirateface.co와 함께 카탈로그 역할을 합니다: shardr catalog search qwen, shardr pull <owner/repo>를 사용하면 다운로드가 정확한 리비전의 Hugging Face 체크섬을 기준으로 고정됩니다. 마그넷(magnet) 파일이 속일 수 없습니다. 사라진 모델(HF 소스 없음)은 카탈로그에 기록된 체크섬을 기반으로 가져오지만, --trust-catalog를 명시적으로 사용해야 합니다. 다른 미러들도 동일한 인터페이스 뒤에 맞출 수 있습니다. 즉, 카탈로그는 플러그인 방식이며 기본 URL은 구성 가능합니다.

간단한 테스트:

$ make all
$ shardhive serve &
$ shardr catalog search qwen2.5-0.5b
$ shardr pull unsloth/Qwen2.5-0.5B-Instruct-GGUF --quant q4_k_m
$ shardr serve unsloth/qwen2.5-0.5b:q4_k_m --id chat
$ curl http://127.0.0.1:<port>/v1/chat/completions -d '{"model":"chat",...}'

현재 상태는 macOS arm64와 Linux amd64에서 엔드투엔드가 작동하며, 릴리스는 CI를 통해 빌드됩니다. 문서는 https://cyb3rdudu.github.io/shardr에 있습니다.

가지고 있지 않은 것: UI, Windows 지원, llama-server를 넘어서는 런타임, 그리고 솔직히 말해서 아마도 많은 미흡한 부분들.
내가 도움받고 싶은 것:

• 대규모 로컬 컬렉션을 가진 사람들이 임포트를 시도해보고 어떤 부분이 깨지는지 알려주는 것
• 신뢰 모델에 대한 피드백 — HF 기반 풀(pulls), 복구된 모델에 대한 명시적 옵트인. 분명히 허점이 있을 거예요. 찔러보세요.
• 스웜/시딩 측면을 즐기고 직접 수정하고 싶은 사람

설계 결정에 관한 것이라면 무엇이든 기꺼이 답변해 드릴게요. 문서는 위에 링크되어 있고, 사양은 어떻게 만들어졌는지 보고 싶다면 레포지토리에 있습니다.
제출자: /u/Cyb3erDudu
[링크] [댓글]