YC S25 Magnitude, llama.cpp 능가 주장하는 에이전트용 자기 최적화 추론 엔진 공개

비즈니스 모델이 뭐임?

나중에 하이브리드 워크로드용 추론 클라우드를 만들 거고 토큰당 과금할 계획임. 로컬이랑 클라우드 모델을 같은 작업에서도 프리픽스 캐시 안 깨고 오갈 수 있게 하는 게 목표고, 지금은 엔진 자체에 집중하고 있음.

벤치마크 방법론 소스가 이미지 말고 따로 있음? llama.cpp는 설정에 따라 편차가 엄청 커서. MLX랑 비교한 것도 보고 싶음.

Moby Dick을 64k 문맥까지 넣고 마지막 구절을 반복시키는 과제임. llama.cpp는 투기적 디코딩 끄고 기본 프리필 배치에 flash attention 켠 설정으로 맞췄고, KV를 8비트 키 4비트 값으로 양자화해봤더니 llama.cpp는 디코드가 박살나서 16비트로 비교했음.

MLX 기반 엔진들이랑 대충 돌려봤는데 지금까지 비교한 것 중에선 다 앞서고 있음. 자세한 벤치마크는 곧 공개할 예정임.

이거 Wafer.ai 같은 거임? 코딩 에이전트가 커널을 계속 최적화해주는 방식?

Wafer랑 공통점은 에이전트 워크로드용 추론 성능을 잡는 거임. 기기에서 도는 코딩 에이전트가 커널을 고치는 게 아니라, 튜닝 가능한 파라미터가 있는 커널 구조를 짜두면 실제 하드웨어에 맞춰 피팅하는 시스템임.

M3 맥북프로에서 튜닝이 얼마나 걸림?

새 모델 받을 때 한 번, 1분 정도임. 그보다 오래 돌려도 수렴해서 이득이 없음. 하드웨어에 따라 조금 다름.

이거 덕분에 예전엔 못 돌리던 큰 모델이 돌아감?

KV 메모리를 덜 써서 긴 세션에서 모델 가중치 자리가 더 남음. 안 쓰는 전문가를 램이나 디스크로 내리고 필요할 때만 올리는 expert streaming이 로드맵에 있어서 GPU 메모리에 안 들어가던 MoE 모델도 돌릴 수 있게 됨.

llama.cpp 이기는 건 낮은 기준 아님? 맥에서는 ds4, omlx, mtplx 같은 게 훨씬 빨랐음. 엔진들이 자주 실패하는 지점이 최적 투기적 디코딩 안 씀, KV 캐시에 VRAM 너무 많이 씀, 100-200K 큰 문맥에서 성능 붕괴임.

셋 다 직접 잡는 부분임. 카탈로그 모델마다 최적 드래프터를 붙여서 DFlash, DSpark, DFlash2를 지원하고, KV는 TurboQuant에서 착안한 8비트 키 4비트 값 양자화로 메모리를 절반 이하로 줄이면서 디코드도 빨라짐. 긴 문맥에 최적화를 집중하는 것도 에이전트 추론이 대부분 그렇게 생겨서임.

로컬 박스에서 codex 스레드 계속 돌려서 llama.cpp PR이랑 MTP, DFlash 최적화 훑고 벤치 돌리는 식으로 씀. 저쪽도 커널 최적화에 코딩 에이전트를 많이 쓴다니 반갑네.

에이전트가 자잘한 마이크로 최적화에 갇히기 쉬워서 논문을 참고하게 하거나 구조를 크게 바꾸라고 밀어줘야 함.

vLLM이나 llama.cpp 드롭인 대체를 노리는 거임, 아니면 몇 개 아키텍처만 집중함?

같은 계열 모델은 아키텍처를 공유해서 한 번만 최적화하면 새 모델도 같은 커널을 씀. 파레토 프론티어 근처 아키텍처는 다 지원할 계획이고, 오래됐거나 마이너한 계열은 우선순위에서 뺌.

16GB GPU 두 장인데 4장으로 인식하고 8GB 넘는 모델은 다 크다고 나옴. 5070ti 한 장에서만 도는데 같은 조건의 llama.cpp가 디코드 20-30% 더 빠름.