Hacker News

Launch HN: Magnitude (YC S25) – Self-optimizing inference engine for agents

Launch HN: Magnitude — 에이전트용 자동 최적화 추론 엔진

Magnitude는 사용 중인 하드웨어에서 커널을 컴파일하고 튜닝해 오픈 모델을 실행하는 추론 엔진입니다. 개발사는 llama.cpp보다 최대 2배 빠른 디코딩과 에이전트당 KV 캐시 메모리 27% 절감을 내세우며, 토론에서는 벤치마크 조건과 실제 기기별 성능, 멀티 GPU 지원 문제가 제기됐습니다.

AI 요약

Magnitude는 Apple Silicon, NVIDIA·AMD GPU, CPU에서 오픈 모델을 실행하는 에이전트용 추론 엔진입니다. 데스크톱 앱에서 모델을 내려받고 Pi, OpenCode, Hermes, Codex 등과 연결합니다. OpenAI 호환 API도 지원하며, 모델을 받은 뒤에는 인터넷 연결 없이 쓸 수 있다고 안내합니다. 프로젝트는 Apache 2.0 라이선스로 공개됐습니다.

기기별 커널 튜닝과 성능 주장

Magnitude는 폭넓은 하드웨어용으로 미리 컴파일한 커널을 제공하는 데 그치지 않고, 새 모델을 내려받을 때 실제 기기에서 커널 매개변수를 튜닝합니다. 개발사 설명에 따르면 이 작업은 보통 1분 정도 걸립니다. 인기 오픈 웨이트 모델 계열에는 직접 최적화한 커널을 적용합니다.

개발사는 llama.cpp보다 최대 2배 빠르다고 소개하며, 측정 사례로 Metal에서 디코딩 속도 92% 향상, CUDA에서 19% 향상을 제시합니다. 에이전트당 메모리는 27% 줄이고, 여러 세션이 접두부 캐시(prefix cache)를 공유해 동시 실행 시 속도 저하를 막는다고 설명합니다. KV 캐시는 TurboQuant에서 영감을 받은 방식으로 키를 8비트, 값을 4비트로 양자화합니다. 개발사는 이 방식으로 KV 메모리를 절반 넘게 줄이고 디코딩 속도도 높였으며, 자체 장문 검색 평가에서 검색 성능이나 문맥 일관성 저하를 발견하지 못했다고 밝혔습니다.

측정 조건과 지원 범위

개발사가 댓글에서 공개한 llama.cpp 비교는 Moby Dick 본문을 최대 64K 문맥으로 입력한 뒤 마지막 부분을 반복하게 하는 작업입니다. 비교 조건을 맞추려 speculative decoding은 끄고, 기본 prefill 배치 크기와 flash attention을 사용했습니다. llama.cpp에서 8비트 키·4비트 값 KV 캐시를 시험했지만 디코딩 속도가 크게 떨어져 16비트 KV를 기준으로 삼았다고 설명했습니다. 벤치마크 코드는 저장소에 공개했다고 합니다. MLX 엔진과도 초기 비교를 했으며, 더 자세한 결과를 공개할 계획이라고 밝혔습니다.

현재 여러 GPU를 함께 쓰는 구성은 지원하지 않습니다. AMD 기기에는 Vulkan 백엔드를 사용하며, ROCm보다 성능이 부족한지 확인한 뒤 백엔드 추가를 검토하겠다고 답했습니다. 장기적으로는 한 컴퓨터 안의 CPU·메모리·여러 GPU에 작업을 나누고, 여러 컴퓨터를 연결하는 방향도 계획하고 있습니다. MoE 모델의 미사용 expert를 RAM이나 디스크에 두고 필요할 때 불러오는 expert streaming도 로드맵에 포함했습니다.

Hacker News 반응

  • @nateb2022 — 이미지 외에 벤치마크 출처나 방법론이 있나요? llama.cpp 성능은 설정에 따라 크게 달라집니다. MLX와 비교한 결과도 보고 싶습니다.
    • @anerli — Moby Dick을 최대 64K 문맥으로 입력하고 마지막 부분을 반복하게 했습니다. 가능한 한 설정을 비슷하게 맞췄고, speculative decoding은 끄고 기본 prefill 배치 크기와 flash attention을 사용했습니다. llama.cpp에서 8비트 키·4비트 값 KV 캐시도 시험했지만 디코딩 속도가 크게 떨어져 16비트 KV로 비교했습니다. 벤치마크 코드는 공개했습니다.
  • @kenzic — 예를 들어 M3 MacBook Pro에서는 튜닝에 얼마나 걸리나요?
    • @anerli — 새 모델을 내려받을 때 한 번 진행하며, 보통 1분 정도 걸립니다. 하드웨어에 따라 조금 달라질 수 있습니다.
  • @kmike84 — llama.cpp를 이기는 건 낮은 기준입니다. 특히 Mac에는 더 빠르거나 메모리를 덜 쓰는 엔진이 있습니다. 긴 문맥에서 속도가 떨어지는 문제와 KV 캐시 사용량도 살펴봐야 합니다.
    • @anerli — speculative decoding에는 모델별 drafter를 배정하고 DFlash, DSpark, DFlash2를 지원합니다. KV 캐시는 8비트 키·4비트 값으로 양자화해 메모리 사용량을 절반 넘게 줄입니다. 에이전트 추론에서 긴 문맥이 흔하므로 장문 요청에 맞춰 최적화한다고 답했습니다.
    • @skohan — 캐시 양자화가 품질에 미치는 영향을 평가한 자료가 있나요?
    • @anerli — RULER 기반 검색 평가로 전체 문맥을 모델이 계속 파악하는지 확인하고 있습니다. 평가 코드는 공개했습니다.
  • @herf — NVIDIA GPU 두 장을 쓰는데 Magnitude가 네 장으로 표시합니다. 대부분의 모델이 너무 크다고 나오고 한 장에서만 실행됩니다. 제 5070 Ti에서는 llama.cpp가 디코딩 기준으로 20~30% 빠릅니다.
    • @anerli — 현재 멀티 GPU는 지원하지 않으며 가까운 시일 내 로드맵에 있습니다. 모델 크기 안내는 버그일 수 있으니 설정을 이슈로 남겨 달라고 했습니다. 모델과 백엔드에 따라 성능 차이가 있을 수 있으며 개선 중이라고 답했습니다.
  • @cedricd — 모델 평가 단계가 오래 걸려 다운로드를 시작하지 못합니다. 모델을 고를 때 평가하거나 백그라운드에서 진행하면 안 되나요?
    • @anerli — 평가가 1분 넘게 걸려서는 안 됩니다. 메모리에 맞지 않는 모델을 걸러내고 속도를 예상하는 단계라고 설명하며, 하드웨어와 운영체제 정보를 요청했습니다.
  • @happybox2016 — llama.cpp가 이미 메모리 대역폭을 꽉 쓰는데, 어떤 하드웨어에서 2배 빠르다는 건가요? 실제 에이전트 사용에서는 여러 긴 문맥의 KV 캐시가 병목일 수 있습니다.
    • @anerli — 주로 M4 Pro와 Max를 포함한 여러 Mac에서 디코딩 속도가 2배에 가까운 결과를 얻었다고 답했습니다. 단일 스트림에서도 llama.cpp가 메모리 대역폭을 다 쓰지는 않으며, 장문 문맥과 배치 처리에서는 양자화 KV 캐시가 필요한 대역폭을 줄인다고 설명했습니다.

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