Skip to content
Published on

Qwen3.8-27B의 하이브리드 어텐션 — 64개 층 중 16개만 KV 캐시를 쌓는 구조

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드✨Start Quiz
공유하기
Authors

이 글은 2026-08-15에 Hacker News API와 GeekNews 피드에서 직접 확인한 항목을 바탕으로 합니다. 점수와 순위는 계속 바뀝니다.

무엇이 올라와 있었나

Hacker News API로 확인한 항목입니다. 제목은 Qwen 3.8 27B, 아이템 번호는 49299605이고 2026-08-15 기준 793점에 댓글 519개입니다. 링크는 Hugging Face의 Qwen/Qwen3.8-27B-FP8 모델 카드입니다. 같은 날 GeekNews 피드에도 같은 항목이 올라와 있었습니다. 점수와 댓글 수는 제가 확인하는 동안에도 움직였습니다.

모델 카드에서 눈길이 가는 것은 벤치마크 숫자가 아닙니다. 층 구성입니다.

27B인데 26만 토큰이 되는 이유

모델 카드에 적힌 파라미터는 270억 개, 층은 64개, 히든 차원은 5,120입니다. 컨텍스트는 262,144 토큰이 기본이고 위치 보간을 쓰면 1,000,000 토큰까지 늘릴 수 있다고 적혀 있습니다.

여기서 한 번 멈춰야 합니다. 일반적인 트랜스포머에서 26만 토큰은 파라미터 수와 무관하게 그 자체로 부담입니다. KV 캐시가 토큰 수와 층 수의 곱에 비례해서 자라기 때문입니다. 층이 64개면 26만 토큰짜리 캐시를 64벌 들고 있어야 하고, 그 시점에서 캐시는 27B 가중치보다 쉽게 커집니다.

모델 카드는 층 구성을 이렇게 적어 두었습니다. 16 x (3 x (Gated DeltaNet -> FFN) -> 1 x (Gated Attention -> FFN)). 읽으면 이렇습니다. 네 개짜리 묶음이 16번 반복되고, 묶음 안에서 앞의 셋은 Gated DeltaNet이고 마지막 하나만 일반 어텐션입니다.

즉 64개 층 중 48개는 선형 어텐션이고 16개만 일반 어텐션입니다. 그리고 KV 캐시가 자라는 층은 그 16개뿐입니다. 나머지 48개 층은 시퀀스가 아무리 길어져도 고정 크기 상태 하나만 유지합니다.

여기에 그룹 쿼리 어텐션이 한 번 더 곱해집니다

캐시를 쌓는 16개 층의 설정도 모델 카드에 있습니다. 쿼리 헤드 24개, 키/값 헤드 4개, 헤드 차원 256입니다. 쿼리와 키/값의 비율이 6대 1이므로, 이 층들이 들고 있는 캐시는 모든 헤드가 자기 키/값을 갖는 구성 대비 6분의 1입니다.

두 절약이 곱해집니다. 캐시를 쌓는 층이 4분의 1이고, 그 층 안에서 다시 6분의 1입니다. 26만 토큰이 소비자 장비에서 말이 되는 지점이 여기입니다. Gated DeltaNet 쪽은 값 헤드 48개, 쿼리/키 헤드 16개, 헤드 차원 128로 적혀 있습니다.

무엇을 잃는가

공짜는 아닙니다. 선형 어텐션의 상태는 크기가 고정되어 있으므로, 과거 전체를 그 안에 압축해서 담습니다. 압축은 손실이 있습니다.

일반 어텐션은 20만 토큰 앞에 나온 특정 문자열을 정확히 되짚을 수 있습니다. 쿼리와 그 위치의 키를 직접 내적하기 때문입니다. 고정 상태에는 그 개별 항목이 남아 있지 않습니다. 그래서 순수 선형 어텐션 모델은 긴 문서에서 정확한 인용이나 식별자 대조 같은 작업에 약합니다.

이 구조가 하이브리드인 이유가 그것입니다. 네 층마다 한 번씩 들어가는 일반 어텐션 층이 정확한 조회를 담당하는 통로입니다. 선형 층들이 요약과 흐름을 싸게 나르고, 주기적으로 등장하는 어텐션 층이 필요한 순간에 원문을 직접 봅니다. 3대 1이라는 비율은 그 두 가지를 맞바꾼 결과이지 최적해로 증명된 값이 아닙니다.

실무적으로 의미하는 바는 이렇습니다. 긴 컨텍스트에서 이 모델을 쓸 때 요약과 추론은 잘 되는데 특정 값을 정확히 집어내는 작업에서 유독 어긋난다면 그것은 프롬프트 문제가 아니라 구조에서 예상되는 실패입니다.

FP8은 어디에 걸리는가

이 저장소는 FP8 변형입니다. 모델 카드는 블록 크기 128의 세밀한 FP8 양자화를 썼고 성능이 원본과 거의 같다고 적고 있습니다.

블록 크기가 핵심입니다. 가중치 전체에 스케일 하나를 쓰면 이상치 하나가 나머지 전부의 해상도를 깎아 먹습니다. 128개씩 묶고 묶음마다 스케일을 따로 두면 이상치의 피해가 그 묶음 안에 갇힙니다.

주의할 점은 FP8이 가중치를 줄이지 KV 캐시를 줄이지는 않는다는 것입니다. 위에서 본 캐시 절약은 층 구성에서 온 것이고 FP8과는 별개입니다. 긴 컨텍스트에서 메모리가 터진다면 가중치 양자화를 더 조여도 해결되지 않습니다. 그때 봐야 할 것은 캐시 양자화나 동시 요청 수입니다.

1M 컨텍스트에 붙은 조건

모델 카드는 위치 보간으로 백만 토큰까지 늘릴 수 있다고 하면서 한계도 같이 적어 두었습니다. 구현이 정적이어서 배율이 입력 길이와 무관하게 고정된다는 점입니다.

이 문장은 그냥 넘어갈 문장이 아닙니다. 백만 토큰 설정을 켜 두면 2천 토큰짜리 요청에도 같은 배율이 걸립니다. 짧은 입력의 품질이 내려갈 수 있다는 뜻입니다.

그래서 배포 관점에서는 하나의 엔드포인트로 긴 요청과 짧은 요청을 모두 받는 구성이 위험합니다. 긴 컨텍스트가 필요한 트래픽이 일부라면 확장 설정을 켠 인스턴스와 끈 인스턴스를 나누는 편이 낫습니다. 참고로 모델 카드가 제시한 백만 토큰 기준 출력 배분은 추론 262,144 토큰, 최종 응답 131,072 토큰입니다.

벤치마크와 실행 설정

모델 카드에 적힌 수치 중 일부입니다. SWE-bench Pro 61.7%, Terminal Bench 2.1 73.0%, IFBench 79.5%, LiveCodeBench v6 90.3%입니다. 비전 쪽은 OSWorld-Verified 84.3%, AndroidWorld 81.9%, OmniDocBench 1.5가 91.1%이고 MathVision은 사고 사슬을 켠 조건에서 94.6%입니다.

추론 프레임워크로는 SGLang, vLLM, TokenSpeed가 언급되어 있고 라이선스는 Apache 2.0입니다.

# 예시: 모델 카드에 적힌 최소 실행 형태
vllm serve "Qwen/Qwen3.8-27B-FP8"

샘플링 값이 모드별로 다르게 제시되어 있다는 점이 중요합니다. 사고 모드는 temperature 1.0, top_p 0.95, top_k 20, presence_penalty 0.0이고, 지시 모드는 temperature 0.7, top_p 0.80, top_k 20, presence_penalty 1.5입니다. 기본값이 사고 모드라고 적혀 있습니다.

댓글에서 갈린 지점

댓글에서 반복적으로 지적된 것은 벤치마크가 아니라 토큰 사용량이었습니다. 한 댓글은 자신의 비공개 문제를 풀긴 했지만 다섯 배의 토큰이 들었다고 적었고, 다른 댓글은 비슷한 크기의 경쟁 모델이 10분의 1의 사고 토큰으로 같은 결론에 도달한다며 그렇다면 쓸 이유를 찾기 어렵다고 했습니다.

이 지적이 중요한 이유는 벤치마크 표가 이 축을 보여 주지 않기 때문입니다. 정확도 61.7%는 그 답을 내는 데 몇 토큰이 들었는지를 담고 있지 않습니다. 로컬 실행에서 이것은 곧바로 체감 대기 시간이 됩니다. 채팅 템플릿이 어긋난다는 지적도 여러 번 나왔습니다. 도구 호출이 의도대로 안 될 때 모델보다 템플릿을 먼저 의심하라는 이야기입니다.

어떻게 적용하나

로컬 또는 사내 추론을 검토 중이라면 이 항목에서 실제로 가져갈 것은 다음 세 가지입니다.

첫째, 모델을 파라미터 수로만 비교하는 습관을 멈추는 것입니다. 27B라는 숫자는 가중치 메모리만 알려 줍니다. 여러분의 워크로드가 긴 컨텍스트를 다룬다면 실제 한계를 정하는 것은 KV 메모리이고, 그것은 층 구성에서 나옵니다. 후보 모델들의 설정 파일에서 층 수, 어텐션 층의 비율, 키/값 헤드 수를 뽑아 표로 만드는 것이 파라미터 수를 비교하는 것보다 훨씬 유용합니다.

둘째, 평가 지표에 토큰 수를 넣는 것입니다. 정확도만 재면 사고 토큰을 많이 쓰는 모델이 항상 이깁니다. 과제당 평균 출력 토큰과 95분위 지연 시간을 같은 표에 올려 두면 선택이 달라지는 경우가 많습니다.

셋째, 긴 컨텍스트 설정을 트래픽 전체에 켜지 않는 것입니다. 위에서 본 정적 배율 문제 때문입니다.

누구에게는 해당 없는가

관리형 API만 쓰고 앞으로도 그럴 계획이라면 이 글의 대부분은 배경지식입니다. 층 구성이 여러분의 청구서에 나타나지 않기 때문입니다. 그 경우에는 토큰당 단가와 응답 시간만 보면 충분합니다.

컨텍스트가 대체로 8천 토큰 아래에 머무는 워크로드도 마찬가지입니다. 그 길이에서는 KV 캐시가 병목이 아니어서 하이브리드 구조의 이점이 드러나지 않는 채로 압축 손실만 떠안을 수 있습니다. 법률 문서에서 조항을 원문 그대로 뽑아야 하는 파이프라인처럼 정확한 인용이 계약 조건인 작업도 신중하게 검증한 뒤에 도입해야 합니다.

정리

이 모델 카드가 알려 주는 진짜 내용은 새 모델이 나왔다는 사실이 아니라, 긴 컨텍스트의 비용이 파라미터가 아니라 어느 층이 캐시를 쌓느냐에서 결정된다는 점입니다. 48대 16이라는 비율은 그 비용을 재배치한 결과이고, 대가는 먼 과거를 정확히 되짚는 능력의 일부입니다.

원문과 관련 글

본문의 구조 설명과 적용 방법은 모델 카드에 적힌 수치를 바탕으로 제가 정리한 것입니다.

Discuss on Twitter • View on GitHub