300~600파운드로 Q4 Flash Next 구동 👀 - 스냅드래곤 미니 PC 결과 업데이트 - A3b 315/43 Tok/s, Flash Next 46/20 Tok/s (읽기/생성) 💥

Qwen3.6 35B A3B

읽기 / 쓰기 / 쓰기 + MTP: 산문 벤치마크 (~580토큰 입력, 128토큰 출력). 코딩 채팅: 코드 페이로드 (62 입력, 550-970 출력). Qwen3.6 35B A3B (읽기 / 쓰기 / MTP 포함 쓰기, 그 다음 코딩 채팅 일반 / MTP, 마지막으로 테스트):

llama.cpp, 1 box: 133.8 / 25.8 / 20.6. Coding 27.7 / 39.3. Tests 4/5, checks 6/6

llama.cpp RPC, 2 boxes: 107.1 / 24.9 / n/a. Coding 26.9. Tests 4/5, checks 6/6

Janas, 1 box: 169.5 / n/a* / 36.2. Coding 42.9 (MTP). Tests 5/5, checks 6/6

ToRc, 1 box: 228.0 / 43.4 / 49.5. Coding 42.6 / 53.3. Tests 5/5, checks 5/6

ToRc, 2 boxes: 315 / 43.3 / 43.3. Coding 42.6 / 59.6. Tests 5/5, checks 6/6

- *Janas (내 업데이트 4 빌드)는 `--no-mtp` 옵션을 써도 35B 파일에 내장된 MTP 레이어를 그대로 써버려서 딱 잘라 말할 수 있는 수치가 없음. "MTP" 수치는 그냥 지금까지 돌린 거 평균 낸 거임 (벤치 33.7-37.8, 코딩 41.3-45.4).

- 엔진 내부 (ToRc 자체 벤치, 서버 안 거침): 박스 두 개로 읽으면 **600 토큰 프롬프트에서 343.6 tok/s**, 512 토큰에선 349.4 나옴. 제목이랑 표에 적힌 315는 다른 엔진들처럼 클라이언트에서 시간 잰 거라 HTTP 요청이랑 첫 토큰까지 다 포함된 수치임.

- 박스 두 개 쓸 때 ToRc는 프롬프트 처리할 땐 둘 다 쓰다가, 상태값 다시 가져와서 박스 1에서만 답변을 씀. 케이블 타고 데이터 왔다 갔다 하는 게 토큰당 왕복 시간이 걸려서, 박스 하나 더 쓰는 이득보다 손해가 더 큼. 그래서 그냥 글 쓰는 건 박스 하나나 두 개나 똑같음 (코딩 챗에서 42.6, 답변 내용도 바이트 단위로 똑같음). MTP 켰을 땐 두 번 돌린 결과가 서로 달랐음 (626 토큰 vs 968 토큰). 그러니까 53.3이랑 59.6 차이는 박스 때문이 아니라 텍스트 차이임.

- MTP는 텍스트를 타는 게 있음. 앨리스 산문 벤치에서 llama.cpp의 MTP는 그냥 돌리는 것보다 느렸음 (25.8 -> 20.6, 초안 대부분이 거절됨). ToRc는 박스 하나일 때 14% 이득 봤고 (43.4 -> 49.5), 박스 두 개일 땐 이득 없었음. 코딩 쪽은 다들 이득 봄: llama 27.7 -> 39.3, ToRc 42.6 -> 53.3 (박스 하나), 42.6 -> 59.6 (박스 두 개, 둘 다 답변 내용은 같음).

- 테스트 관련: 엔진마다 모델은 똑같은 거 쓰는데, 아주 미세한 숫자 차이 때문에 그리디(greedy) 답변이 바뀌어서 엔진마다 결과 코드가 다름. llama.cpp가 테스트 하나 틀린 건 모델 자체 산수 문제임 (P3DT4H12M5S를 300725초라고 하는데 실제론 274325초임). 기능 자체는 정상임. ToRc가 5/6인 건 주 단위(P1W, 유효한 ISO 8601)를 못 알아먹어서 그럼.

자 이제 대망의 주인공! Flash Next!

아쉽게도 Flash Next는 Janas에서 안 돌아가서, 내가 (조만간 공개할) 엔진인 ToRc를 만들기 시작한 거임.

Flash Next IQ4_NL은 95GB임. 박스 하나에 램 32GB, 두 개 합쳐도 64GB라 절대 안 들어감. 그래서 전문가(expert) 모델들을 필요할 때마다 NVMe에서 스트리밍해서 씀. 여기서 엔진들 성능이 갈리는 거임.

읽기/쓰기: 산문 벤치 (입력 약 580 토큰, 출력 128 토큰; ToRc는 박스 두 개에 파이프라인 MTP 적용, 나머지는 그냥 돌림). 코딩 챗: 코드 페이로드 (입력 62, 출력 약 750).

Flash Next (읽기/쓰기, 그 다음 코딩 챗, 마지막으로 테스트):

llama.cpp IQ4_NL, 1 box: 7.3 / 4.2. Coding 3.2. Tests 5/5, checks 5/6

llama.cpp RPC IQ4_NL, 2 boxes: 10.9 / 5.8. Coding 5.0. Tests 5/5, checks 5/6

ToRc IQ4_NL, 1 box: 10.7 / 6.6. Coding 4.6. Tests 5/5, checks 6/6

ToRc IQ4_NL, 2 boxes: 46.2 / 20.3. Coding 19.2. Tests 작성 안 함, checks 6/6

ToRc UD-Q4_K_XL, 2 boxes: 34.3 / 18.3. Coding 16.4. Tests 5/5, checks 5/6

- llama.cpp는 여기서 `--no-repack` 옵션이 필요함. ARM에선 IQ4_NL 가중치를 램으로 리팩하는데 95GB가 안 들어가서, 이거 안 쓰면 모델 로딩 자체가 안 됨. RPC 서버는 자기 몫 가중치를 램에 들고 있어야 해서 (디스크 스트리밍 불가), 박스 2가 레이어 48개 중 12개 가져가고 박스 1은 나머지를 NVMe에서 매핑함.

- 박스 두 개 쓰는 ToRc는 둘 다 써서 생성함: 박스 2가 현재 토큰 끝내는 동안 박스 1이 MTP 헤드로 다음 토큰 초안을 짜니까, 케이블 대기 시간이 거의 상쇄됨. 박스 하나만 쓸 땐 MTP 헤드 없이 돌림: SSD에서 전문가 모델 불러오는 상황에선 MTP가 별 도움 안 됨.

- Q4_K_XL은 더 크고 좋은 양자화 모델임 (3800 토큰 델파이 코드 테스트에서 IQ4_NL보다 퍼플렉서티 낮음). 대신 속도는 10% 정도 손해 봄.

- IQ4_NL 투 박스 코딩 답변은 함수는 제대로 짰는데 테스트 코드가 없어서 "작성 안 됨"으로 처리했어. 함수 자체는 참조 체크 6개 다 통과함.

전력 및 비용:

여기엔 GPU 같은 거 안 들어감. 미니 PC 두 대 합쳐서 600파운드 들었음. 100GB짜리 모델을 GPU VRAM에 올리려면 전기세는 둘째치고 장비값만 몇 배는 더 깨짐. 당연히 속도로는 GPU 못 이기지. 근데 가성비랑 속도 생각하면... 개인적으로 꽤 흥미로운 프로젝트였음 🙏. 100GB급 모델을 챗 속도로 돌리는데, 작고 조용한 박스 두 대가 풀로드 시 각각 35W 정도밖에 안 먹음 (정확한 측정값은 나중에 올릴게).

어쨌든 일주일 동안 재밌게 작업했다. 스냅드래곤 써본 것도 처음인데 LLM까지 돌려볼 줄이야... ToRc는 아직 공개 안 함. 좀 더 깔끔하게 다듬고 테스트 제대로 거친 다음에 풀 생각임. 다음 계획은 이거임:

- 박스 두 대에서 35B 모델을 위한 파이프라인 추론 (지금은 두 번째 박스가 읽기 작업만 도와주는 수준인데, Flash Next는 이미 돌아감).

- 박스 한 대에서 Flash Next 돌릴 때 CPU가 아니라 SSD가 병목임. 전문가 모델 복사본을 담은 NVMe를 하나 더 달아서 읽기 작업을 두 드라이브로 분산시키면 좀 나아질 듯.

- 같은 방식으로 다른 모델들도 더 테스트해 볼 생각인데, 내 용도에는 아마 이 두 개면 충분할 듯 👍

궁금한 거 있으면 물어봐. 시간 나면 테스트도 해줄게...

의견이나 피드백 환영함 🙃👍

• ToRc 두 박스, IQ4_NL: 12.5초
• ToRc 두 박스, UD-Q4_K_XL: 16.9초
• ToRc 한 박스: 54초 (모든 전문가 모델을 SSD에서 읽어와야 해서)
• (llama.cpp: RPC로 53초, 한 박스에서 80초)

짧은 채팅 메시지는 훨씬 빨라, 프롬프트 길이에 따라 달라지거든. 전부 예열된 상태야: 처음에 예열 실행을 한 번 하고, ToRc가 가장 많이 쓰이는 전문가 모델을 준비 상태가 되기 전에 RAM에 미리 로드해둬. 로드 직후의 차가운 상태에서는 Flash Next의 첫 응답이 눈에 띄게 느려(캐시가 채워지기 전까지는 17-18이 아니라 대략 11-12 tok/s 정도). 나중에 제대로 된 콜드 TTFT 수치를 측정해볼게 👍

내 사용 사례는 특정 작업을 위한 하위 에이전트야. 메인 프롬프트가 올라오면, 다른 에이전트로부터 특정 목적을 위한 작업을 받아 처리하지.

프리필은 이 CPU들에서 연산 병목이 발생해서, 그걸 피할 방법은 없지만 NPU와 두 박스 간의 균형을 맞추면 여전히 약간의 여유는 있어(현재 수치보다 몇 배나 더 빨라지진 않겠지만). 👍

맞아, 인정해. 46 t/s면 8k 프롬프트 처리하는 데 첫 토큰 나오기까지 3분 정도 걸려. 하지만 실제로는 서버가 프롬프트를 캐싱하니까 채팅에서는 새로운 턴만 처리하면 돼(즉, 첫 메시지만 고통스러운 거지 - 오케스트레이터의 특정 작업을 처리하는 하위 에이전트에게는 충분히 받아들일 만한 수준이야). 그리고 35B 모델은 315+ t/s로 완전히 다른 이야기지(8k를 약 26초 만에 처리).