레딧발 60tps
https://www.reddit.com/r/LocalLLM/comments/1vvtquz/dgx_spark_qwen_38_27b_nvfp4_at_60toks_generation/
제가쓰는 버전은 이겁니다
https://forums.developer.nvidia.com/t/qwen3-8-27b-nvfp4-on-single-dual-dgx-spark-sglang-dflash2-fully-openai-compatible/380732
작업량(단일 스트림) | 1x 스파크 | 2x 스파크 (TP=2) |
|---|
코드 생성 | 52~61건/초 | 87건/초 |
산문/에세이 | 26건/초 | 41건/초 |
생각의 대화 | 초당 34~49건 | 49건/초 |
코드, ("없음")에 대해 생각하기 | 52건/초 | 초당 약 80건 |
TTFT, 짧은 프롬프트 | 약 0.16초 | 비슷한 |
TTFT, 16K 접두사 반복 | 0.44초 | 0.74초 |
컨텍스트 창 | 262,144 | 262,144 |
제가 좀 보수적인 셋팅을 써서 (퀀트용, 임베딩용, 8B모델 같이 사용 등) 실측 36~46 tps가 나오네요
Flash 2+ Slang은 정말 .. 엄청 빠르네요. 기술의 발전이란.
오늘의 팁 : Qwen38은 compact 버그가 있네요
DeepSeek Harness에서 Qwen3.8 27B로 150K 토큰 세션을 압축할 때 auto compact가 끝나지 않는 거의 동일한 문제가 보고됐습니다.
원인: 압축기가 원래 대화의 reasoning 설정을 상속해 출력 예산을 사고 과정에 소모
해결: 요약 요청만 reasoningEffort: off
오래된 reasoning 제거, 이미지 제거, 대형 도구 결과 축약
이 방식으로 128K·150K·256K 세션 압축을 안정화했다고 보고했습니다.
DeepSeek Harness Qwen3.8 compaction 사례
Qwen Code에서도 제목·요약·recap 같은 보조 요청이 메인 모델 설정을 상속해 불필요하게 thinking하는 문제가 보고됐습니다. 해결 방향은 “각 보조 요청이 자체 모델·리즈닝·extra body 설정을 가져야 한다”입니다.
Qwen Code side-query 설정 상속 문제
또 다른 Qwen Code 이슈에서는 일반 OpenAI 요청 구조에 Qwen 전용 enable_thinking이 포함되지 않아, OFF 설정이 실제 서버에 전달되지 않는 문제가 확인됐습니다. 즉 UI에서 OFF라고 표시하는 것만으로는 부족하고 provider adapter가 요청 본문에 명시적으로 넣어야 합니다.
Qwen Code enable_thinking 전달 결함
아래를 Vector Build에 추가해서 해결했습니다
{
"chat_template_kwargs": {
"enable_thinking": false,
"preserve_thinking": false
}
}
