Qwen3.8-27B 출시 일주일 후: r/LocalLLaMA와 r/LocalLLM의 평가

• 원샷으로 만든 슈퍼 마리오 클론 (Q8, Framework Desktop) — 반박 의견: "어차피 학습 데이터에 있던 거 아님?"

• 갤러그 1:1 재현 테스트 (UD-Q8_K_XL, 3×3090 + Tesla P40): "3.6으로 만든 갤러그 클론은 사실상 스페이스 인베이더에 가까웠는데... Qwen 3.8은 생각을 엄청나게 하더니, 그 자잘한 디테일까지 다 챙겨서 결국 제대로 만들어냄." 다른 r/LocalLLM 사용자는 듀얼 4060 Ti에서 IQ4_XS로 플레이 가능한 갤러그 스타일 게임을 원샷으로 뽑아냈고, 또 다른 사람은 권한 서버와 셀프 플레이 테스트까지 갖춘 온라인 멀티플레이어 MOBA를 하룻밤 만에 만듦.

• BASIC으로 구현한 레이 트레이싱 구체: 3.8은 스스로 반복 수정해서 올바른 Cook-Torrance 레이 트레이서를 만들어냄. 3.6은 사람이 일일이 가르쳐줘야 했음. 댓글 반응: "이건 3.6에서 3.8로 넘어간 게 아니라 3.6에서 4.6으로 점프한 느낌임."

비전

네이티브로 작동함(F16 mmproj). 신문 이미지의 OCR 스타일 읽기도 약 1,000개의 이미지 토큰으로 처리 가능. 다만 16GB 카드에서 64k 컨텍스트 + MTP 조합으로 돌리면 VRAM이 150 MiB 정도밖에 안 남음. 16GB 쓰는 애들을 위한 팁: 텍스트 에이전트랑 비전 프로필은 따로 관리하거나, 프로젝터를 오프로드(--no-mmproj-offload)하셈.

고전하는 부분

• 긴 글 분석/문서 작업: 기본 설정인 3.6과 비교하면 "퇴보한 수준"임. 다만 법률 분야 사용자는 MCP와 케이스 액세스를 활용해서 122B 모델과 맞먹는 결과를 뽑아내기도 했으니, 결국 작업 나름임.

• 복잡한 네이티브 코딩: C 커널 작업 하나 시도했다가 말아먹음 (3회에 걸쳐 6시간 소요) [일화적 사례], 양자화 수치는 불명. 댓글러들 말로는 그 정도 작업 수준이면 최소 Q8은 써야 한다고 함.

2. 사고 수준(thinking-level) 상황 (불평하기 전에 이거부터 읽어라)

xhigh가 기본값으로 설정되어 있음. 네 컨텍스트 윈도우가 순식간에 증발하는 이유가 바로 이거임.

측정된 성능 지표 (RTX 5080 Laptop 16GB, llama.cpp 10451, UD-IQ3_XXS, Q8_0 KV + FA + MTP, pelican-SVG 작업, 시드 3개):

이게 눈대중으로 하는 작업에서 1.5점 더 얻으려고 시간은 6.4배나 더 쓰는 꼴임. 하지만 SWE 스타일의 통과/실패가 명확한 작업에서는 낮은 설정일 때 6~7/12였던 게 xhigh에서는 9/12가 나옴. 즉, 확실하게 틀린 걸 잡아낼 수 있는 작업일수록 프리미엄(비용)이 제값을 함.

설정 바꾸는 법: --chat-template-kwargs '{"reasoning_effort":"medium"}' (llama.cpp) 또는 LM Studio 커스텀 파라미터에서 동일한 설정 적용.

과도한 사고(overthinking) 논쟁, 양쪽 의견 다 정리함:

• 반대 측: "웹 검색을 8~9번씩 돌리면서 엉뚱한 데로 계속 샌다" (법률 작업). 어떤 사용자는 사소한 하위 작업 하나에 추론 토큰 4만 개 넘게 태우는 루프에 빠짐. 논문 관련 게시물 하나는 중간 토큰이 사실 추론이 아니라고 주장함 ("중간 토큰을 의인화하지 마라," 538점).

• 찬성 측: "추가적인 사고로 결과가 눈에 띄게 좋아진다면, 그게 딱 적당한 사고량이다." low/medium AA 점수(~43/44)가 "과도한 사고로만 이기는 거 아니냐"는 비판에 대한 가장 강력한 반박임. 물론 댓글러 두 명은 같은 데이터를 보고 정반대로 해석하긴 했음.

요약하자면: 채팅이나 분석은 medium, 확실하게 정답이 있는 작업은 xhigh.

• 이번 주 가장 강력한 통제된 실험 데이터는 X에서 나옴: @superalesha의 67시간, 40개 케이스 실행 결과에 따르면, xhigh는 low보다 추론 토큰을 7~11배 더 쓰면서 점수는 0~4.7점 더 얻는 데 그침. 심지어 1:1 비교에서는 low가 토큰을 1/7.5만 쓰고도 xhigh와 똑같은 결과(89.3%)를 냄. 게다가 medium은 모든 스택에서 low보다 점수가 낮았음 (HumanEval+에서 다 깎아먹음 — "그 프리셋은 짧은 코딩 작업에서 너무 오버함"). 결론: "low가 합리적인 프리셋이고, xhigh는 리더보드 스크린샷용이다." 레딧 여론보다 훨씬 매운맛 평가지만, 이번 주에 나온 데이터 중 표본이 가장 크니 둘 다 참고해라.

이번 주 추가 데이터 포인트:

• Medium vs xhigh "진짜 미쳤음" (223점): medium은 추론 토큰 수천 개 수준, xhigh는 최소 15~20k, 팩맨 빌드 하나는 40k까지 찍음. 하지만 같은 스레드에서 나온 최고의 반박: 버그 찾기 테스트에서 xhigh는 7분 걸려서 모든 버그를 잡았는데, medium은 80초 만에 끝내고 치명적인 버그만 잡음. 연구 작업에서는 xhigh가 알아서 레포 클론하고 소스 읽어서 답을 검증했는데, medium이나 3.6은 못 한 거임.

• 다양한 사고 수준 (287점): "low 프리셋조차 Qwen 3.7 plus나 Qwen3.6-27B 추론보다 낫다" — 결국 레벨 선택은 속도를 바꾸는 거지, 이전 세대를 이기냐 마냐의 문제는 아님.

• "high" 노력 단계는 없음 — low / medium / xhigh(기본값) 이렇게 세 단계고, medium과 xhigh 사이의 간극 때문에 계속 불만이 나오는 거임. 댓글러들 말로는 이게 단순히 프롬프트 차이가 아니라, Qwen이 RL 과정에서 각 레벨별 지시문을 따로 학습시켰다고 함.

• 예산(budget)이랑 노력(effort) 헷갈리지 마라 (PSA): llama.cpp의 웹 UI 추론 선택기는 사고 중간에 잘라버리는 강제 토큰 제한임. 이건 모델이 얼마나 철저하게 일할지를 결정하는 Qwen의 네이티브 노력 레벨과는 다름. 최근 빌드에서는 --reasoning-effort medium (구버전은 --chat-template-kwargs 형태)을 써라. 다른 거 쓰면 모델을 제어하는 게 아니라 그냥 조용히 캡(제한) 걸어버리는 거임.

• "well?" 꿀팁: 생각하는 도중에 끊고 well?이라고 쳐봐. 그럼 모델이 "아, 사용자 성격 급하네. 빨리 끝내야지" 하고 대답을 서둘러 마무리함. 효과는 확실한데, 다들 최후의 수단으로만 쓰라고 함. 모델이 생각하는 과정에 진짜 알짜배기가 들어있거든.

• 반대 의견도 있음: medium-vs-xhigh 게시물에서 "시간은 20분의 1인데 품질은 거의 똑같다"고 주장했다가 엄청 까임. 베스트 댓글: low/medium은 별로였고, frontier급 코딩 실력은 xhigh에서나 나온다는 거. 솔직히 말해서 잡담이나 대충 훑어보는 작업엔 medium이 공짜나 다름없지만, 정확도가 중요한 작업엔 xhigh가 제값 함.

3. 지식 퇴보 vs 3.6 — 이건 진짜고, 의도된 거임

전용 스레드: 3.8은 3.6이 잘만 맞추던 잡학 상식 문제를 모든 양자화 버전에서 다 틀림. AA의 오프라인 Omniscience 벤치마크 결과도 똑같음.

커뮤니티 분석: 3.8은 기억하는 대신 검색하게 훈련된 거임. 즉, 에이전트 성능을 위해 지식을 희생한 셈. 해결책으로 RAG/MCP(오프라인 Wikipedia ZIM)를 쓰거나, 지식 보조용으로 Gemma 4 31B를 같이 돌리라는 의견이 나옴.

반대 데이터: 다른 법률 업무 스레드에서는 MCP랑 케이스 데이터베이스를 붙이니까 Harvey 벤치마크 점수가 Qwen 3.5-122B랑 비슷하게 나옴(도구 백엔드 붙이기 전 61/75, 붙인 후 71/75). 지식이 사라진 게 아니라 툴박스로 옮겨간 것뿐임.

4. 양자화: 뭐가 살아남나

유일한 통제된 퍼플렉서티(PPL) 스윕 (16GB 램 양자화, wikitext-2, RTX 5060 Ti)

작성자 결론: Q4_K_M이 가성비 최고임. NVFP4는 진짜 실망스러웠음(IQ4_XS랑 용량은 같은데 PPL은 더 구림). 읽어볼 만한 반박: "PPL은 실제 성능보다 덜 떨어짐... 4비트 수준으로 내려가면 순위가 뒤집히기도 함."

Q4 vs Q6 전쟁 (결론 안 남)

• Q6/Q8 파: "복잡한 추론에는 q8이 q4보다 압도적으로 좋음." 한 유저는 264k-ctx Q6_K_XL 세션 돌리면서 200만 토큰당 실수 딱 2번 했다고 함.

• Q4-fine 파: "난 q4 쓰는데 대만족임... 그냥 KV 캐시만 q8 밑으로 안 내리면 됨."

• 뉘앙스: "Q4라고 다 같은 Q4가 아님. 종류만 5개는 됨." NVFP4 ≠ MXFP4 ≠ Q4_0 ≠ UD-Q4_K_XL. 다이내믹 양자화 기준으로 Q5 넘어가면 차이 구분하기 힘듦.

이번 주 최대 규모의 통제된 양자화 테스트 (X)

@superalesha가 67시간 동안 벤치마크 돌림: 5개 프로덕션 스택(FP8 vLLM, NVFP4 W4A16 vLLM, AWQ INT4 vLLM, GGUF Q4_K_M llama.cpp, NInfer — 전부 RTX 3090에서 테스트), 추론 작업 40개, 4,800개 태스크 / 10,120개 요청 / 1,450만 추론 토큰, 제한 없음. 결과:

• xhigh 설정에선 모든 양자화 버전이 pass@1 88.0~90.0% 사이를 기록함 — AWQ INT4 90.0%, NVFP4/GGUF-Q4_K_M 89.3%, FP8 베이스라인 88.7%, NInfer 88.0%. 4비트 양자화가 FP8보다 점수가 높게 나옴. McNemar 검정 결과 통계적으로 차이 없음(1등이랑 꼴등 차이가 150개 태스크 중 3개 수준). "양자화 간의 차이보다 추론 프리셋 간의 차이가 훨씬 큼."

• 제일 이상한 수치: GGUF Q4_K_M은 low 설정에서도 xhigh랑 똑같은 89.3%가 나옴. 토큰은 651k 대신 86k만 썼는데도. 모든 스택에서 xhigh는 low보다 토큰을 7~11배 더 태웠는데 점수는 0~4.7점밖에 안 올랐음.

• 통계적으로 유의미한 유일한 차이: 추론(reasoning)을 끈 NVFP4는 HumanEval+에서 박살 남(FP8이 30/30일 때 13/30, p=0.0041). 근데 low로 바꾸면 바로 90/90으로 복구됨. 추론은 절대 끄지 마라. 어디서든 8~12점씩 깎아먹음.

• 작성자의 치트 시트: 최고 품질 = AWQ INT4 xhigh; 실사용 = GGUF Q4_K_M low; 솔직한 한마디: FP8 테스트 중 3개는 본인 방법론 감사(토큰 제한 문제)에서 탈락해서 다시 돌리는 중임.

이 모델의 작업 수준 벤치마크에서는 Q4와 Q6 간의 전쟁이 사실상 이걸로 종결됐어. 하지만 위에서 언급한 PPL(Perplexity) 결과와는 좀 충돌하는 부분이 있다는 걸 알아둬. PPL은 NVFP4가 IQ4_XS보다 확실히 구리다고 하는데, 작업 성능은 둘이 비슷하거든. 둘 다 맞는 말일 수 있어. PPL은 토큰 단위의 오차를 재는 거고, 작업 성능은 실제로 에러가 걸러지는지를 보는 거니까. 그리고 커뮤니티에서 계속 나오는 Q4 추론 루프 문제도 여전해. "벤치마크 통과"랑 "200만 토큰 세션에서 루프 안 걸림"은 완전히 다른 요구사항이니까.

1-bit: 연산이 아니라 코미디

1-bit 스레드에서 Unsloth 창립자가 한 말: "에이전트나 툴 호출용으로 1-bit 쓰는 건 비추함." 토큰 32개만 지나도 BF16 대비 발산율이 92%까지 치솟거든. 일반적인 대화는 버티는데 에이전트는 못 버텨. 꼭 써야겠다면 presence_penalty = 1.5를 넣어.

KV 캐시 — 이 바닥에서 가장 말 많은 설정

• AMD 테스터 한 명에 따르면 f16이랑 q8_0은 절대 똑같지 않음 (f16은 12만 컨텍스트 넘어서도 품질 유지함).

• 근데 16GB 쓰는 애들은 q4_0/q4_1 KV로 64k~164k까지 아무 문제 없이 잘만 돌림.

• 댓글에서 나온 국룰: 어쩔 수 없는 상황 아니면 KV 양자화 하지 마. 꼭 해야겠다면 최소 q6 이상으로 가. 에이전트 루프 돌릴 거면 Q4 모델 + Q8 KV가 마지노선임.

Unsloth Dynamic v3 참고사항

UD-Q2_K_XL 미만 양자화 버전에서 MTP가 빠지고 따로 업로드됐어 (Q5_K_XL에서 아직 드래프트 로그가 보인다는 유저들이 있는데, 이건 아직 해결 안 됨). Imatrix는 릴리즈됐고, QAT는 안 썼어.

5. 성능 매트릭스 (출처 포함)

왜 "~200 tok/s"라는 수치가 너한테는 안 나오는지: 윈도우/WDDM 쓰면 리눅스 대비 10~15% 손해 봐. 헤드라인 수치는 짧은 컨텍스트 기준으로 잰 거고, MTP 수용률은 워크로드 따라 달라 (산문에서는 떨어지고, 가끔은 오히려 더 느려짐). 그리고 제일 빠른 수치들은 llama.cpp가 아니라 Blackwell에 최적화된 엔진(ninfer)에서 나온 거야.

X/Twitter 벤치마크 하이라이트

• @analogalok의 RTX 4090 풀 매트릭스: 최신 llama.cpp에서 UD-Q4_K_XL 돌린 결과. FP16 KV는 100k 컨텍스트에서 한계(40.9 t/s), q8 KV는 170k까지, q4_0 KV는 24GB에서 네이티브 컨텍스트 262k를 꽉 채워서 40.7 t/s 나옴. 네이티브 MTP는 80~130k 구간에서 59~60 t/s. 정확한 재현 플래그 포함됨.

• 후속 트윗: --parallel 1에 Q2_K DFlash2 드래프터 조합하면 4090 한 장으로 250k 컨텍스트에서 73.7 t/s (Q4 KV), 150k에서 75 t/s (Q8 KV), 90k에서 80.6 t/s (FP16 KV) 찍음 (llama.cpp PR #27342 필요).

• NVIDIA 포럼: DGX Spark 대결, SGLang+DFlash2 vs vLLM+MTP, 그리디 vs 공식 사고 샘플러 비교 결과 — DFlash2가 이김.

6. 실패 유형 및 버그 (재현 가능한 것들)

1. 툴 호출 실패는 보통 모델 문제가 아니라 네 툴 리스트 문제임. 이 바닥에서 제일 확실한 실험 결과: 설명 없는 툴 8개 → 0/6 성공; 똑같은 툴 하나만 넣으면 → 15/15 성공; 설명 있는 툴 13개를 중간에 넣으면 → 0/5, 뒤로 옮기면 → 3/3 성공. 모든 툴에 설명을 달고, 중요한 툴은 뒤에 배치하고, 설명 안에 예시 넣지 마. 프레임워크 실패 보고(Opencode/Pi/Claude Code) 올라오는 스레드 보면 똑같은 루프 반례가 항상 같이 올라옴.

2. Hermes 하네스 특이사항: vLLM에서는 툴 호출 계속 실패하는데, llama.cpp --jinja + q8_0 KV 조합으로 256k 돌리면 "완벽하고 문제없음". 이건 가중치 문제가 아니라 템플릿/파서 정렬 문제임.

3. 사고 과정 중에 사용자 지시사항 환각 발생 (기기 2대, Pi 하네스에서 재현): 모델이 성격 급한 사용자를 상상하더니, 프랑스인 반대 의견을 상상하고는 커밋을 되돌려버림. 커뮤니티 해결책: froggeric이 수정한 채팅 템플릿(섹션 7 참조) 쓰면 기본 템플릿의 툴 호출/복구 버그 싹 사라짐.

4. temp=1.0에서 쓰레기 출력: llama.cpp/vLLM, INT4부터 BF16까지 10~20k 토큰 넘어가면 사고 과정이 한 글자 스팸으로 무너짐. 원인은 양자화가 아니라 샘플러임. 해결책: temp 0.1로 낮추거나, 샘플링 분할(메인 0.8 / 사고 후 0.2) 사용. 반대 보고: temp 0으로 했더니 7만 토큰 루프 걸림. 만능 설정은 없으니 작업마다 튜닝해.

5. 디코드 성능 저하: 5090 llama.cpp에서 한 번 생성할 때 122 → 69 t/s로 떨어짐; vLLM/ninfer는 100 넘게 유지함. 업스트림에 버그 리포트 올라감.

6. 긴 문맥 품질 저하: B200에서 NVFP4+vLLM으로 평가했을 때, 가장 긴 문맥 구간인 [single report]에서 정답률이 고작 ~37%밖에 안 나왔음. 별개로, 공식 vLLM 레시피로 BF16/FP8 돌려본 어떤 유저는 2만 토큰 넘어가면 에이전트 맛탱이 가고, 2만 토큰 넘어서면 구조화된 출력 다 깨진다고 보고함 [single report]. 반론도 있음: UD-Q4_K_XL (ROCm)에서 f16-KV 쓰는 유저는 12만 토큰 넘어도 품질 멀쩡하다고 함. 설정마다 다르니까 직접 확인해봐.

7. Q8 이상 증상 보고 (Unsloth UD_Q8_K_XL 오프로드/CPU 100% 찍는 현상): 증거가 빈약하고 반박도 많음. 대부분 Q8 유저는 아무 문제 없다고 함.

8. 낮은 양자화에서의 추론 루프: Q4-with-QKV-quant에서 "angry birds" 가지고 4만 자 넘게 루프 돌고, 심지어 "나 루프에 갇혔어"라고 자아성찰까지 함. Q6에서는 절대 못 봤다는 주장들이 수두룩함.

7. 챗 템플릿 상황 (뭐든 디버깅하기 전에 이거부터 읽어)

공식 Qwen 3.8 Jinja 템플릿에 진짜 버그가 섞여서 나왔는데, 커뮤니티에서 48시간 만에 수정본 내놓음:

• 공식 템플릿 문제: enable_thinking=false 하면 뻗음; 멀티턴 기록에 빈 \\think 태그가 섞여서 오염됨; 클라이언트가 인자를 JSON 문자열(표준 OpenAI 형식)로 보낼 때 툴 호출이 뻗음; 대화 중간에 시스템 메시지가 날아가서 에이전트 루프가 꼬임.

• froggeric/Qwen-Fixed-Chat-Templates (HF, thread, 334점)가 사실상 표준 대체제임: 안전한 medium 기본값(2만 토큰 태우고 빈값 뱉는 xhigh 버그 해결), 생각 토글 복구, JSON 문자열 툴 호출 크래시 수정, <|think_low|> / <|think_medium|> / <|think_xhigh|>를 통한 인라인 노력 조절, 깔끔한 KV 프리픽스 캐싱을 위한 시간순 사고 보존까지 다 됨. 8월 21일 기준 v22.1로 활발하게 업데이트 중.

• 형식 충실도 중시형 대안: 두 번째 템플릿은 공식 프롬프트 형식을 최대한 그대로 유지함. 형식이 조금이라도 바뀌면 눈에는 괜찮아 보여도 품질이 미세하게 떨어진다는 이론 때문임. 벤치마크 돌릴 거면 이거 쓰고, 실사용할 거면 froggeric 거 써.

• 업스트림 참고: llama.cpp가 8월 14일에 reasoning_effort 전달 기능을 병합했음. 최신 빌드는 reasoning_effort를 템플릿에 제대로 넘겨줌. 이건 배관 공사지 공식 템플릿 자체 버그를 고치는 건 아님. 웬만하면 수정된 템플릿 쓰는 걸 추천함.

8. 벤치마크: 적당히 걸러 들어

• Artificial Analysis: 헤드라인 보면 3.8-27B가 DeepSeek V4랑 GPT-5.6 Luna Max랑 맞먹는다고 나옴. Low/medium 프리셋이 ~43/44점 찍는데, 이게 그냥 과하게 생각해서 점수 잘 나오는 게 아니라는 핵심 증거임. 에이전트 지수: medium = xhigh - 1점.

• 반발 ("의미 없는 벤치마크", 106점): 이 지수가 27B를 DSV4 Pro, Kimi 2.7 Code, Opus 4.6, Sonnet 5보다 높게 랭크함. "AA가 '지능'을 뭐라고 정의하든... 우리가 여기서 써야 할 정의는 절대 아님." 옹호 측: 에이전트/과학/코딩 쪽으로 치우친 종합 점수니까, 방법론 읽어보고 자기 용도에 맞는 하위 벤치마크를 골라 보라고 함. LiveBench는 매달 과제 갱신해서 그나마 인정받는 중.

• 찾아본 것 중 가장 괜찮은 독립 테스트: AIME 2026, exact-match, temp 0, pass@1 — FP8-xhigh가 29/30 (96.7%) 찍어서 게시물 표 기준으로 Opus 4.6, DeepSeek V4 Pro랑 동점임 (Qwen3.6-27B는 94.1%). 주의사항: 1회성 테스트고, 7번 문제는 두 정밀도 다 토큰 예산 다 써버림 (틀린 게 아니라 빈칸).

• 실제 프로덕션 블라인드 A/B 테스트 (수천 개 과제): 3.8이 일을 못 하는 게 아니라, 하지 말아야 할 때를 구분하는 걸 못 함 (노이즈 출력 +50%).

• 솔직한 평가: "Opus급"은 특정 과제에서, 적절한 양자화와 하네스를 썼을 때만 실화임. "Qwen 3.8은 Opus 4.6급 아님. 멍청한 소리 좀 하지 말자"는 스레드에서는 VS Code에서 Q6로 돌리다 망했다고 함. 댓글들은 에디터랑 양자화 탓이라고 했지만, 데모가 증명해야 할 몫은 여전히 남아있음.

9. 생태계: 이번 주에 나온 것들

• DFlash2 (llama.cpp PR #27342, 검토 중): 실제 코딩 프롬프트에서 2.26배~4.68배 속도 향상, VRAM 2.7GB 추가 소모. N-max 5가 권장 설정인 7보다 나음. --spec-draft-p-min은 아무런 효과가 없음. ngram-mod를 쌓는 건 오히려 성능 저하를 유발함 (3.6 버전의 DFlash1과는 정반대).

• ninfer: Blackwell/5090에 최적화된 엔진. 퀀트 모델에서 120~160 t/s, 4-way 동시 실행 시 480 t/s 찍음. 재현 불가능한 속도 스크린샷들의 출처로 추정됨.

• AutoRound INT4 / AWQ-INT4 GGUF (vLLM 서빙용).

• KVarN 4/2-bit KV (vLLM 0.27.1로 포팅됨): 262k 컨텍스트가 작은 카드에도 들어가고, needle-test 240k 통과함. 디코딩 속도는 20% 정도 느려짐.

• Uncensored/abliterated 변종들 빠르게 출시됨: Huihui-ai ablit, K_P 퀀트와 HauhauCS FastMTP(최대 3.02배 TG 주장)를 묶은 "Uncensored Aggressive" 릴리즈, 그리고 거부율이 0~6%까지 떨어진다고 보고된 FP8 abliteration. 다만 커뮤니티에서는 같은 표에서 주의 사항(caveat-rate)이 30~50%까지 떡락했다는 반론이 나옴. 품질 차이가 극심하니 바꾸기 전에 벤치마크 차이부터 확인하셈.

앞으로 나올 것들

• 35B-A3B 포착: ms-swift 커밋(8월 15일)에서 발견됨. 16GB 카드 쓰는 애들 신났음. 초기 수치 보면 덴스 27B가 빌빌거리는 하드웨어에서도 27~40 t/s 정도 나올 듯.

• 새로운 미들급 오픈 웨이트 모델 "다음 주 예정 (희망 사항)": Qwen 커뮤니티 매니저 피셜. 이번엔 얼리 액세스 없음. 다들 비전 기능 달린 80B급일 거라고 궁예질 중.

• 플래그십 Qwen3.8-2.4T-A95B는 출시와 동시에 오픈 웨이트 공개 및 day-0 vLLM 지원 확정. 근데 속도 추측 말고는 이번 주 로컬 커뮤니티 스레드에서 거의 언급 안 됨 (2.4T 오픈 웨이트로 만든 콜 오브 듀티 클론 데모가 좀 돌긴 함). 로컬 쪽은 온통 27B 얘기뿐임.

리포트 템플릿 (이거 복사해서 쓰셈)

다음 사람이 읽고 이해할 수 있게 이렇게 적어라:

런타임/버전:
하드웨어:
모델 파일 + 퀀트:
KV 캐시:
스펙큘레이티브 (MTP/DFlash2/ngram):
추론 노력(Reasoning effort):
샘플링:
컨텍스트 사이즈:
Prefill tok/s:
Decode tok/s:
사용 작업:
비교 대상:
관찰 결과:

메가스레드 작성일: 2026년 8월 22일, r/LocalLLaMA 및 r/LocalLLM (8월 15일~22일)과 공개 X 벤치마크 스레드 종합. 모든 성능 수치는 해당 결과를 낸 하드웨어/런타임 기준임. 데이터들이 서로 앞뒤가 안 맞는 경우가 태반인데, 대부분은 변수 하나만 확인해보면 왜 차이가 나는지 바로 알 수 있음.