요약 (TL;DR)

모든 모델은 Qwen3.6입니다.

27B-MTP vs Base 27B (15k 단일 턴): 전반적으로 더 빠름

• 총 소요 시간 (wall): 87.44s → 77.39s (10.05s 더 빠름 / -11.50%)
• 생성 (Generation): 7.63 → 16.15 t/s (+111.77% 속도 향상)
• 프롬프트 처리 (Prompt Processing): 279.75 → 244.90 t/s (-12.46% 속도 저하)

35B-MTP vs Base 35B (15k 단일 턴): 전반적으로 더 느림

• 총 소요 시간 (wall): 20.83s → 23.16s (2.33s 더 느림 / +11.17%)
• 생성 (Generation): 48.18 → 56.12 t/s (+16.47% 속도 향상)
• 프롬프트 처리 (Prompt Processing): 972.18 → 811.90 t/s (-16.49% 속도 저하)

27B-MTP vs Base 27B (5턴 채팅, 약 28.5k 컨텍스트): 대폭적인 시간 절약

• 총 소요 시간 (wall): 258.65s → 200.55s (58.10s 더 빠름 / -22.46%)
• 2~5턴 (wall): 211.37s → 155.33s (56.04s 더 빠름 / -26.51%)
• 평균 생성 (Avg Generation): 7.61 → 17.98 t/s (+136.41% 속도 향상)
• 평균 프롬프트 처리 (Avg Prompt Processing): 254.20 → 207.87 t/s (-18.23% 속도 저하)

35B-MTP vs Base 35B (5턴 채팅, 약 28.5k 컨텍스트): 거의 비슷하거나 약간 더 느림

• 총 소요 시간 (wall): 58.86s → 60.24s (1.38s 더 느림 / +2.34%)
• 2~5턴 (wall): 47.96s → 49.21s (1.25s 더 느림 / +2.62%)
• 평균 생성 (Avg Generation): 46.66 → 58.23 t/s (+24.80% 속도 향상)
• 평균 프롬프트 처리 (Avg Prompt Processing): 826.47 → 703.45 t/s (-14.89% 속도 저하)

용어 설명:

• wall = 요청을 보낸 시점부터 전체 응답을 받을 때까지의 실제 종료 간 경과 시간 (end-to-end elapsed time).
• pp = 프롬프트 처리 처리량 (prompt processing throughput, tokens/sec).
• gen t/s = 생성 처리량 (generation throughput, tokens/sec).

---

하드웨어 / 소프트웨어

• CPU: AMD RYZEN AI MAX+ 395 (16C/32T)
• iGPU: Radeon 8060S (RADV GFX1151)
• RAM: 30 GiB
• OS: Ubuntu 24.04, kernel 6.17
• llama.cpp / llama-server: 9187 (0253fb21f)
• Vulkan Instance: 1.4.313
• GPU API: 1.4.305
• Mesa RADV: 25.0.7

---

테스트된 모델 (모두 Unsloth)

• Qwen3.6-27B-Q8_0.gguf
• Qwen3.6-27B-Q8_0-MTP.gguf
• Qwen3.6-35B-A3B-Q8_0.gguf
• Qwen3.6-35B-A3B-Q8_0-MTP.gguf

---

사용된 런타임 설정 (Runtime Config Used)

• --ctx-size 128000
• -b 2048
• --ubatch-size 1024
• --flash-attn on
• --threads 16
• --threads-batch 16

MTP 모델 전용:

• --spec-type draft-mtp
• --spec-draft-n-max 3
• --spec-draft-p-min 0.75

---

방법론 (Methodology)

15k 단일 턴 비캐시 (15k single-turn uncached)

• 약 15k 프롬프트 토큰(prompt tokens)에 맞춰 조정된 합성 에이전트 프롬프트 (Synthetic agentic prompt).
• max_tokens=256, temperature=0.
• 매 실행 시 프롬프트를 무작위화(RUN_TAG)하여 cache_n=0 (진정한 비캐시 프리필, true uncached prefill) 상태로 유지.
• 모델당 2회 실행.

5턴 연속 턴 테스트 (5-turn subsequent-turn test)

• 각 모델에 대해 동일한 스크립트 기반의 5턴 대화 수행.
• 각 턴마다 약 3,900단어의 사용자 페이로드 (user payload).
• 5번째 턴에 도달하면 컨텍스트가 약 28.5k 프롬프트 토큰으로 증가.
• max_tokens=220, temperature=0.
• 5턴 전체 합계와 2~5턴만 별도로 보고 (subsequent turn 동작을 격리하기 위함).

---

안정성 (Stability)

• 장시간 실행 중 발생하는 일시적인 502/503/504 오류에 대한 재시도 로직 적용.
• 서버 추론 시간 (server infer timing)과 클라이언트 관찰 시간 (client-observed wall time)을 모두 보고.

---

전체 결과 (지연 시간 중심) (Full Results (Latency-Focused))

15k 단일 턴 (15k single-turn)

5턴 전체 (~5턴 시점 28.5k) (5-turn total (~28.5k by turn 5))

연속 턴만 (2~5턴) (Subsequent turns only (turns 2-5))

---

시사점 (Takeaways)

• MTP는 일관되게 pp (prefill)를 낮추고 생성 t/s (tokens per second)를 높입니다.

• 워크로드 형태가 전체적인 승자를 결정합니다:

• 디코딩 (decode)이 지배적이라면, MTP가 압도적으로 유리할 수 있습니다 (여기서 27B 모델의 사례).

• 프리필 (prefill)이 충분히 지배적이라면, MTP가 전체적으로 약간 불리할 수 있습니다 (여기서 35B 모델의 사례).

• 이 Strix Halo 설정에서는:

• 27B-MTP는 긴 컨텍스트 (long-context) 채팅 워크플로우를 위한 강력하고 실용적인 업그레이드입니다.

• 35B-MTP는 결과가 엇갈립니다: 토큰 생성 (token generation)은 더 빠르지만, 이러한 특정 긴 컨텍스트 테스트에서는 엔드 투 엔드 (end-to-end) 성능이 약간 더 느립니다.