많은 사람들이 내가 Gufo를 사용해야 한다고 주장해 왔는데, 그것은 오픈 소스이고 '똑같거나 더 좋다'는 이유 때문이었습니다. 그들의 GitHub (GitHub.com/gufo-org/gufo)를 확인하자마자... Strix Halo 장치에서 Qwen 27B Q4: 단일 사용자 기준 70.56 tok/s, 8명 사용자 기준 123 tok/s라는 수치를 보게 되었습니다. 정말 좋네요... 그래서 오늘 직접 테스트해 봤습니다... 설정은 그들의 podman 이미지에서 가져온 gufo 0.4.0과 Unsloth의 Qwen3.8 27B UD-Q4_K_XL, 그리고 DFlash2 Q4_K_M 초안 모델을 사용했으며, 그들이 제공하는 자체 벤치마크 스크립트와 설정(greedy, thinking off, 출력 토큰 128개, 프롬프트 캐시 비활성화)을 이용했습니다. 간단히 요약하자면... 네, 저는 70.22 tok/s를 얻었습니다. 그러니 이 수치는 실제입니다. 하지만 이 속도를 만들어낸 프롬프트는 '단어 red를 정확히 1000번 쓰시오'였습니다. 하지만 이것 역시 실제 상황은 아닙니다. 그 그래프의 모든 속도는 추측 디코딩(speculative decoding)에서 나옵니다. 초안 모델이 7 토큰을 미리 추측하면, 27B 모델이 이를 한 번에 확인하고 일치하는 것만 유지합니다. 출력물이 계속 같은 단어일 때는 초안 모델이 항상 맞습니다. 하지만 실제 프롬프트에서는 절반 정도만 맞는 경우가 많습니다. 그들의 벤치마크에는 아홉 가지 일반적인 프롬프트 세트(C++ 코드, 수학 문제, 요약, 이탈리아어, 중국어, JSON, 소설 일부, 디버깅 체크리스트)가 있습니다. 이에 대한 결과는 다음과 같습니다: | | 단어 반복 프롬프트 | 일반 프롬프트 | |---|---|---| | 1 사용자 | 70.2 tok/s | 39.4 tok/s (중앙값), 프롬프트에 따라 22~52 사이 | | 8명 사용자, 그들의 '집계' 수치 | 122.6 | 82.4 | | 8명 사용자, 실제로 초당 전달되는 토큰 수 | 82 | 52 | 마지막 행에 대해 설명드리자면.
최적의 케이스는 리포지토리 설명과 README 상단에서만 나옵니다. APU에서 Q4로 구동되는 27B 모델이 39 tok/s를 기록한 것도 정말 좋은 수치입니다. 초안(draft) 모델을 사용하지 않을 경우, 그들의 문서에는 약 12 tok/s 정도라고 나와 있습니다. 제가 알고 싶었던 또 다른 점은 평소에 사용하는 halogen (peonist-ai/halogen-flash-server)과 비교하는 것이었습니다. 둘 다 Qwen3.8 Flash-Next를 서비스할 수 있기 때문에, 이 모델을 두 서버 모두에 적용하고 동일한 프롬프트를 전송했습니다. 박스는 두 개였고, 하드웨어와 OS 이미지는 같았습니다. Greedy, thinking off, 256 토큰으로 설정했습니다. | | halogen 0.13.8 | gufo 0.4.0 | |---|---|---| | nine normal prompts, average decode (일반 프롬프트 9개, 평균 디코드) | 43.9 tok/s | 38.2 tok/s | | 4 users at once, end to end (동시 사용자 4명, 엔드 투 엔드) | 76.6 tok/s | 63.1 tok/s | | cold prompt processing, ~9.7k tokens (콜드 프롬프트 처리, 약 9.7k 토큰) | 1288 tok/s | 1495 tok/s | | the "red" prompt ("빨간색" 프롬프트) | 56.9 tok/s | 87.4 tok/s | 따라서 일상적인 생성(everyday generation)에서는 halogen이 사용자 한 명당 약 13% 더 빠르고, 네 명일 때는 약 18% 더 빨랐습니다. gufo는 긴 프롬프트를 처리할 때 16% 더 빨랐고, 반복적인 프롬프트에서는 훨씬 더 빨랐습니다. 혹시라도 누군가 댓글에서 질문하거나 언급할까 봐 이 내용을 추가합니다. 가중치(weights)가 같지 않다는 것을 알고 있습니다. halogen은 자체 4비트 포맷을 사용하고, gufo는 Unsloth GGUF를 사용합니다. 저는 오직 속도만 측정했습니다. 출력 품질은 전혀 비교하지 않았습니다. - 두 기계였지만 하드웨어와 소프트웨어는 동일했고, 다른 벤치마크에서는 제 박스들이 1% 이내로 일치했지만, 여전히 두 대의 기계입니다. - 헤드 투 헤드(head to head) 테스트는 각각 한 번씩 수행되었습니다. 그들의 수치를 재현하기 위해 3회 반복했습니다. - gufo가 지난 4일 동안 네 개의 버전을 출시했기 때문에, 이 모든 것이 다음 주에는 구식이 될 수도 있습니다. 성능과 관련 없는 부분에서도 제가 gufo에 대해 마음에 들었던 점이 많았습니다. 일반 GGUF를 사용하고, MIT 라이선스이며, 27B 모델을 약 3초 만에 로드합니다 (Flash-Next는 13초). 요청당 로그 라인에서 초안 수용(draft acceptance)과 캐시 적중률(cache hits)을 알려주며, 8개의 배치 세션(batched sessions)을 처리할 수 있습니다. 또한 제가 아직 건드려보지 않은 ASR, TTS 및 이미지 모델도 갖추고 있습니다.
그들의 벤치마크는 드래프트 모델 유무에 따라 출력을 해시하며, 매번 동일했습니다. 따라서 추측 경로(speculative path)가 모델의 출력 내용을 변경하지 않습니다. 만약 직접 사용해 보신다면 염두에 두실 점은 세션당 메모리를 미리 예약한다는 것입니다. 64k 컨텍스트로 4개 세션을 처리하는 Flash-Next는 94GB를 사용했습니다. 그러니 이것이 단순히 보여주기식(smoke and mirrors)은 아닙니다. 제가 확인한 모든 것이 재현되었습니다. 다만, 70 tps라는 수치는 워크로드가 믿을 수 없을 만큼 예측 가능한 텍스트일 때만 도달할 수 있는 최대치이며, 일반적인 작업에서는 27B 모델 기준으로 30대 초반을 염두에 두시는 것이 좋습니다. 저는 앞으로 며칠 동안 실제 출력 품질을 가지고 이것들을 모두 설정해 두고 만져볼 예정입니다. 혹시 특정 것을 보고 싶으신 분이 있다면 다른 프롬프트를 실행하거나 다른 설정으로 시도할 의향이 있습니다. /u/brainchillzZ가 제출했습니다 [링크] [댓글]