. 안녕하세요, 저는 세 가지 Apple silicon 엔진(mlx-lm, llama.cpp, Kapitsa)에서 Nanbeige4.3-33B (dense, 4-bit)의 성능을 측정했습니다. 이 비교는 프롬프트 길이 512부터 32K 토큰까지의 범위에서 prefill, decode, 첫 토큰 생성 시간(time to first token), 후속 지연 시간(follow-up latency) 및 메모리를 다룹니다. 이는 새로운 모델이며, nanbeige 측에서 이 수치를 주장했습니다. https://preview.redd.it/328gzbcvvvxh1.png?width=2800&format=png&auto=webp&s=d296f9e03f66c98ab4f5da70e31d5a5be8c3c336 언급할 사항: 저는 Apple Silicon 추론 엔진인 Kapitsa를 개발하고 있으며, 이는 open source이며 apache2 라이선스이므로 이 점을 염두에 두고 수치를 다루어 주십시오. 원본 출력 및 스크립트는 하단에 연결되어 있어 누구나 확인할 수 있거나 재실행할 수 있습니다. 설정 머신: MacBook Pro M5 Max, 128 GB, macOS 26.4, AC 전원, High Power 모드. 가중치(Weights): mlx-lm 0.32.2 및 Kapitsa 0.2.19는 동일한 4-bit MLX AWQ 패키지(그룹 64)를 읽습니다. 현재 버전인 0.2.20은 긴 컨텍스트에 대한 두 가지 KFlash 수정 사항을 추가했지만, 여기의 수치 중 어느 것도 변경하지 않았습니다. llama.cpp b11871은 Q4_K_M을 읽습니다. 방법: 각 엔진은 동일한 조건에서 순차적으로 실행되었습니다. 요약하자면(TL;DR) 이 모델은 느리고 매우 비효율적이며, 모든 레이어에 완전한 어텐션(full attention)을 사용하는 것은 최적이 아닌 것 같습니다. muse glimmer는 128k 토큰당 1.6gb이지만 nanbeige는 26gb입니다 lol. 수정: 코딩 자체는 상당히 좋지만, 저는 여전히 35B/27B Qwen 모델에 머무르고 qwen 4 출시를 기다릴 것이라고 생각합니다. 1. Prefill 속도 prefill 컨텍스트 mlx-lm llama.cpp Kapitsa 512 757 691 693 1K 829 669 721 2K 840 639 731 4K 773 556 692 8K 663 496 616 16K 618 437 540 32K 546 349 520 프롬프트 토큰/초, 각 엔진의 자체 벤치마크 도구에서 측정되었습니다. 2. Context 길이 대비 Decode 속도 컨텍스트 mlx-lm llama.cpp Kapitsa with KFlash 512 28.8 27.3 34.9 1K 28.4 26.9 32.6 2K 27.9 26.4 31.0 4K 27.5 24.6 30.3 8K 25.8 23.2 26.1 16K 24.3 20.4 25.6 32K 20.8 16.7 22.8 https://preview.redd.it/783i1abbxvxh1.png?width=1760&format=png&auto=webp&s=d60f9f66adc92a0e0f04b4394845ac617f5033c8 3.
Time to first token, 콜드 프롬프트 ttft 콜드 프롬프트 토큰 mlx-lm llama.cpp Kapitsa 532 0.90 s 1.20 s 1.18 s 995 1.75 s 1.94 s 1.94 s 2K 3.36 s 4.28 s 4.07 s 4.1K 6.44 s 8.71 s 8.08 s 8.1K 12.9 s 17.9 s 15.1 s 16.1K 28.0 s 40.7 s 33.2 s 29.5K 59.4 s 89.7 s 69.4 s
이 수치는 각 엔진의 OpenAI 호환 서버로 전송된 실제 채팅 요청이며, 사고 과정(thinking)은 비활성화되어 있어 시간 측정에는 채팅 템플릿과 서버 자체 오버헤드가 포함됩니다. 순서는 프리필 결과를 따릅니다. https://preview.redd.it/053ey6ihxvxh1.png?width=1760&format=png&auto=webp&s=8003339f13619c909071dc6ac9efe1205098f6a0
-
후속 턴(follow-up turn)에서의 첫 토큰 시간 ttft 후속 대화 지금까지의 대화 mlx-lm llama.cpp Kapitsa 532 290 ms 220 ms 140 ms 995 310 ms 220 ms 150 ms 2K 340 ms 220 ms 160 ms 4.1K 370 ms 240 ms 150 ms 8.1K 460 ms 270 ms 190 ms 16.1K 580 ms 320 ms 230 ms 29.5K 880 ms 410 ms 300 ms
지금까지의 대화 내용은 이미 캐시되어 있으며, 새로운 사용자 턴이 추가됩니다. 이는 다중 턴 채팅 및 에이전트 루프에서 체감하는 지연 시간(latency)입니다. 세 엔진 모두 여기서 캐시를 재사용하며, 각 턴당 비용이 얼마나 드는지가 다릅니다. https://preview.redd.it/04ilir5fxvxh1.png?width=1760&format=png&auto=webp&s=1002135edfc3817bbb4f70cb4b38a0c2f8cc3d48
-
컨텍스트가 증가함에 따른 최대 메모리 사용량 memory 컨텍스트 도달 mlx-lm llama.cpp Kapitsa 532 21.9 GB 28.0 GB 22.6 GB 2K 22.3 GB 28.6 GB 22.6 GB 4.1K 24.9 GB 29.1 GB 22.8 GB 8.1K 31.6 GB 30.2 GB 24.4 GB 16.1K 36.7 GB 32.0 GB 25.4 GB 29.5K 52.1 GB 35.5 GB 28.1 GB https://preview.redd.it/4eozm8faxvxh1.png?width=1760&format=png&auto=webp&s=421e6612178ee93e86e75db87b5279f383422c29
컨텍스트가 증가함에 따라 메모리 사용량이 늘어나는 것을 확인하십시오.
How Kflash works
Kflash - 추측 디코딩(speculative decoding)이지만 트리 구조를 가집니다. 작은 드래프터 모델이 다음 7개의 토큰을 추측하고, 27b는 이 모든 토큰을 한 번의 패스로 확인합니다. 대부분의 엔진은 이러한 추측들을 체인으로 확인하기 때문에, 첫 번째 잘못된 추측만으로도 그 이후의 모든 내용은 무효화됩니다.
kflash(저희 버전)는 대신 트리를 확인합니다. 작성자(drafter)가 확신하지 못할 때, 두 번째 추측이 같은 패스에 나타나며, 우리는 27b가 동의하는 가장 긴 브랜치를 유지합니다. 양쪽 방식 모두 하나의 패스를 보여줍니다: https://preview.redd.it/7ajhl1d2vvxh1.png?width=880&format=png&auto=webp&s=9305f1bb5e32e226272fa11d33073206300fc2a3 한 사이클 동안 동일한 8개 행을 사용하는 두 가지 방법 (예시). 상단: 작성자의 체인. 타겟은 key를 수락한 후, not을 작성하고 나머지 체인은 폐기됩니다. 하단: 동일 후보들의 최적 우선 트리(best-first tree). 행은 빌더가 가져가는 순서대로 번호가 매겨지며, 각 노드의 경로 확률을 포함합니다. 타겟은 key, not 및 in을 수락한 후, self를 작성합니다. 위치는 마지막으로 작성된 토큰인 P부터 계산됩니다. Kapitsa 측을 재현하려면: brew install nace-ai/tap/kapitsa kapitsa pull nanbeige kapitsa serve --model nanbeige (제공자: /u/DotaMate) [링크] [댓글]