Magnitude, 하드웨어에 맞춰 스스로 최적화하는 에이전트 추론 엔진 공개
Launch HN: Magnitude (YC S25) – Self-optimizing inference engine for agents
Magnitude는 에이전트용 오픈소스 추론 엔진으로, 사용자의 기기에서 커널을 컴파일하고 튜닝해 llama.cpp보다 최대 2배 빠른 속도를 낸다. Metal에서 디코드 92%, CUDA에서 19% 향상됐고, 에이전트당 메모리 사용량은 27% 줄었다. Apple Silicon, NVIDIA, AMD는 물론 CPU만으로도 동작하며, Pi, OpenCode, Codex 등 기존 에이전트를 클릭 한 번으로 연결한다. Apache 2.0 라이선스로 무료 제공되고 모든 데이터는 로컬에 남는다.
Magnitude는 사용자의 실제 기기에서 모델이 실행되기 전에 커널을 컴파일하고 튜닝하므로, 정확한 칩에 맞춰 최적화된다.
HN 토론
56- kmike84
UI의 속도 추정치는 얼마나 정확한가요? Qwen 3.8 (Q8)의 경우 UI에 나온 속도 수치가 꽤 형편없어 보여서 묻습니다:
당신의 머신에서 추정된 속도
컨텍스트 토큰 초당 토큰 수
25 000 17
50 000 16
75 000 16
262 144 12
262K 수치는 괜찮지만, 더 낮은 컨텍스트 크기(<128K)에서는 실제 mtplx 세션에서 qwen3.8 q8 (mac m5 max)로 얻는 수치보다 약 2배 느립니다.
최적화 부족인가요, 아니면 잘못된 숫자인가요, 아니면 벤치마크 아티팩트인가요(예: 일반적인 에이전트 세션보다 spec decoding에 더 어려운 무언가)?
- happybox2016
M3 Max에서 "2x llama.cpp"라니? llama.cpp의 metal 커널은 이미 메모리 대역폭을 포화시키고 있습니다. 실제 에이전트 병목은 단일 스트림 tok/s가 아니라 24GB VRAM에서 5개 이상의 동시 128k 컨텍스트를 위한 KV 캐시입니다. 실제로 로컬에서 멀티 에이전트를 돌리는 사람이 누가 있나요? A) 단일 세션만 B) 2-3개 에이전트 C) 5개 이상 에이전트 D) 포기함,
- lxe
내 로컬 추론 박스에는 llama.cpp 체크아웃에서 항상 열려 있는 codex 스레드가 있는데, 주기적으로 현재 대기 중인 llama.cpp PR들을 살펴보고, 최신 MTP, Dflash 및 기타 예측 또는 어텐션 최적화에 대해 조사하고, 최신 모델 퀀트와 파인튜닝을 조사하고, localLlama Reddit 스레드를 살펴보며 본질적으로 최전선을 훑습니다.
그런 다음 최신 llama.cpp를 다시 빌드하고, 테스트할 관련 있다고 판단한 PR들을 가져와서 벤치마크를 수행하고 업그레이드를 마무리하며, 어떤 모델, 변형, 심지어 별도의 파인튜닝을 실행해야 하는지 검증합니다.
때때로 자체 최적화를 수행하고 커밋하는데, 이는 나중에 PR과 병합된 코드로 대체되어 모델 자체의 최적화 방향성을 본질적으로 검증합니다.
- kmike84
좋은 아이디어인 것 같습니다. 하지만 속도에서 llama.cpp를 이기는 건 낮은 기준이죠 :)
좋은 베이스라인이라고 생각하지만, 적어도 Mac에서는 항상 훨씬 더 빠르거나 메모리 요구 사항이 더 나은 무언가가 있었습니다 - 말씀하신 대로 ds4, omlx, mtplx 등등. 로컬 LLM을 실제로 사용한다면 더 최적화된 엔진 중 하나를 사용하지 않을 이유가 거의 없는 것 같습니다.
엔진에서 관찰한 3가지 주요 실패 모드:
* 최적의 spec decoding을 사용하지 않음
* KV 캐시에 너무 많은 VRAM 사용 (예: ds4에서는 KV 캐시가 거의 아무것도 차지하지 않았지만, deepseek 모델의 경우 unsloth/llama.cpp에서 엄청난 VRAM을 사용함)
* 큰 컨텍스트 크기에서 성능 저하 - 4K 또는 32K에서의 벤치마크는 훌륭하지만, 현실적인 100-200K에서는 일부 멍청한 베이스라인보다 느림
- singh_abinashi
이것의 평가가 실제 에이전트 워크로드와 합성 벤치마크에서 어떻게 작동하는지 궁금합니다. 제 경험상 도구 사용 루프가 포함되면 에이전트 비용과 지연 프로필이 크게 변하는데, 토큰 분포가 단일 프롬프트보다 훨씬 더 버스트해지기 때문입니다. 다단계 도구 호출 트레이스에서 평가하셨나요, 아니면 주로 단일 턴에서 하셨나요?