약 일주일 전 u/lkarlslund의 게시물에서 Ninfer6000(Ninfer를 포크하여 6000 blackwell 및 Qwen3.8-Flash-Next에 맞춰 조정됨)에 대한 내용을 보았습니다. 그래서 '내가 바보라서 저걸 사서 주로 이 모델을 사용해 봐야겠다'고 생각했습니다. 제 작은 사이트에 관련 블로그 게시물이 있지만, 요약하자면 다음과 같습니다: tl;dr: Decode는 incredible하며 Prefill은 vLLM보다 떨어지지만 전반적으로 승리입니다. 포스트에서 본 거의 400tok/s에는 미치지 못했지만, 이상적인 조건의 작은 테스트에서는 근접했습니다. 그래서 제 테스트가 다르게 진행된 것 같습니다. 정확도 벤치마크는 기본적으로 동일합니다. 실제 사용 환경에서는 주요 도구 호출(tool calling) 형식 문제들이 보입니다.
모델/엔진:
| Engine | Model |
|---|
| vLLM | nvidia/Qwen3.8-Flash-Next-NVFP4 |
| Ninfer6000 | swift_1_5_qwen3_8_flash_next_nvfp4_fp8ple_fp8proj.ninfer |
| llama.cpp | unsloth/Qwen3.8-Flash-Next-GGUF/UD-Q4_K_XL |
| Hardware: Rtx Pro 6000 Blackwell @ 600w, 96gb ddr4 @ 3000mhz, Ryzen 5 5600x | |
Decode tps: visual Prompt | Ninfer6000 | vLLM nvfp4 | llama.cpp Q4_K_XL | N vs vLLM N vs llama.cpp |
---|---|
~1k | 232 | 159 | 138 | 1.46x | 1.68x |
7.2k | 241 | 148 | 129 | 1.63x | 1.87x |
28.6k | 227 | 150 | 112 | 1.51x | 2.02x |
57.1k | 249 | 149 | 93 | 1.68x | 2.67x |
114.1k | 240 | 144 | 65 | 1.66x | 3.70x |
mean | 238 | 150 | 108 | 1.59x | 2.21x |
Prefill tps & TTFT: visual Prompt | Ninfer6000 prefill | vLLM prefill | llama.cpp prefill | Ninfer TTFT | vLLM TTFT | llama.cpp TTFT |
---|---|
~1k | 4,315 | 6,944 | 1,823 | 0.23 s | 0.17 s | 0.56 s |
7.2k | 7,996 | 16,484 | 2,960 | 0.90 s | 0.44 s | 2.44 s |
28.6k | 9,521 | 16,798 | 3,320 | 3.00 s | 1.70 s | 8.61 s |
57.1k | 9,914 | 16,700 | 3,277 | 5.76 s | 3.42 s | 17.42 s |
114.1k | 10,037 | 16,229 | 3,108 | 11.37 s | 7.03 s | 36.70 s |
The speed gains are real. Substantial decode gain over vLLM, but a prefill loss. Colossal decode and prefill gain over llama.cpp.
벤치마크: 시각 벤치마크 샘플 Ninfer6000 vLLM nvfp4 llama.cpp Q4_K_XL Spread 도구 호출 (BFCL v4) 300 76.67 ± 5.21 74.56 ± 0.96 73.00 ± 2.96 지침 따르기 (IFEval, prompt-strict) 250 82.80 ± 1.06 84.93 ± 0.61 84.93 ± 0.61 2.1 지식 (MMLU-Pro) 420 84.13 ± 0.77 83.65 ± 0.73 84.92 ± 0.69 1.3 코드 (HumanEval+) 164 93.29 ± 0.61 94.92 ± 0.35 93.90 ± 1.22 1.6 코드 (MBPP+) 378 94.80 ± 0.31 95.15 ± 1.07 95.59 ± 0.76 0.8 장문(Arena-Hard) 75 81.48 76.07 77.42 5.41 긴 컨텍스트 (RULER, 4k ~ 257k) 290 98.28 99.14 98.97 0.9 닐링 인 어 헤이스틱 (RULER): 시각 헤이스틱 실제 프롬프트 토큰 Ninfer6000 vLLM nvfp4 llama.cpp Q4_K_XL Spread 항목 4,096 4,820 98.89 100.00 98.89 1.11 45 16,384 18,910 98.89 100.00 98.89 1.11 45 32,768 37,754 98.75 100.00 100.00 1.25 40 65,536 75,294 98.75 98.75 98.75 0.00 40 131,072 150,371 97.50 98.75 98.75 1.25 40 180,000 206,418 97.50 97.50 98.75 1.25 40 224,000 256,827 97.50 98.75 98.75 1.25 40 모든 항목 290 - 98.28 99.14 98.97 0.86 290 세 가지 모델 모두 긴 컨텍스트에서 문제는 없었습니다. 한 가지 큰 문제가 있었습니다: 벤치마크 외적으로 저는 이 세 모델을 인하우스 테스트에 대비하여 설정했고, Ninfer6000에서 심각한 도구 호출 문제를 발견했습니다. 일관되게 도구 호출 형식을 잘못 만들고 실제로 도구를 호출하는 대신 텍스트를 출력합니다. 예시 이것은 고립된 문제도 아니었습니다. 지난주 동안 저는 Ninfer6000을 일일 드라이버로 사용하려고 노력했고, 제가 사용했던 Open-WebUI와 Cline 모두에서 이 동작이 끊임없이 반복됩니다. 저는 llama.cpp나 vLLM에서는 이러한 문제가 없습니다. 저와 제 설정에 문제가 있는지, 아니면 엔진 자체에 문제가 있는지 확실하지 않습니다. 이것을 알아낼 때까지는 vLLM을 계속 사용해야 할 것 같습니다. 하지만 Swift1.5 튜닝으로 인한 추론 효율성 향상은 환상적이라고 생각하며, 제대로 적용할 수만 있다면 그 자체로 가치가 있습니다.
이모 Ninfer6000은 초기 도구 호출에 실패하고 제가 '야 너 또 도구 호출 망쳤다, 다시 시도해 봐'라고 말해야 했음에도 불구하고 최고의 펠리컨을 가졌습니다. /u/dboybaker 제출 [링크] [댓글]