Skip to content
←

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

✨ Learn with Quiz
|

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

이 글은 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이라는 비율은 그 비용을 재배치한 결과이고, 대가는 먼 과거를 정확히 되짚는 능력의 일부입니다.

원문과 관련 글

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

The Hybrid Attention in Qwen3.8-27B — Only 16 of 64 Layers Grow a KV Cache

This post is based on items I read directly from the Hacker News API and the GeekNews feed on 2026-08-15. Scores and rankings keep moving.

What was up there

An item read from the Hacker News API. The title is Qwen 3.8 27B, the item number is 49299605, and as of 2026-08-15 it stood at 793 points with 519 comments. The link points to the Hugging Face model card for Qwen/Qwen3.8-27B-FP8. The same item appeared in the GeekNews feed that day. The score and comment count moved even while I was checking.

What is interesting in that model card is not the benchmark table. It is the layer layout.

Why 27B parameters can carry 262K tokens

The card lists 27 billion parameters, 64 layers, and a hidden dimension of 5,120. The context is 262,144 tokens natively, and it says that with positional interpolation this can be pushed to 1,000,000 tokens.

Stop there for a moment. In an ordinary transformer, 262K tokens is a burden all by itself, regardless of parameter count, because the KV cache grows in proportion to the token count multiplied by the layer count. With 64 layers you would be holding 64 copies of a 262K-token cache, and at that point the cache easily exceeds the 27B of weights.

The card writes the layer layout like this: 16 x (3 x (Gated DeltaNet -> FFN) -> 1 x (Gated Attention -> FFN)). Read out loud: a group of four repeats sixteen times, and within each group the first three are Gated DeltaNet while only the last is ordinary attention.

So 48 of the 64 layers are linear attention and only 16 are ordinary attention. And only those 16 layers grow a KV cache. The other 48 hold a single fixed-size state no matter how long the sequence gets.

Grouped-query attention multiplies on top of that

The configuration of the 16 cache-holding layers is in the card too: 24 query heads, 4 key/value heads, head dimension 256. Since the ratio of queries to key/values is six to one, the cache those layers hold is one sixth of what it would be if every head carried its own key and value.

The two savings multiply. A quarter of the layers hold a cache, and within those layers it is a sixth again. That is the point at which 262K tokens becomes plausible on consumer hardware. On the Gated DeltaNet side the card lists 48 value heads, 16 query/key heads, and head dimension 128.

What is given up

It is not free. A linear attention state is fixed in size, so it holds the entire past by compressing it, and compression is lossy.

Ordinary attention can reach back and retrieve an exact string that appeared 200,000 tokens earlier, because it takes a direct dot product between the query and the key at that position. A fixed-size state does not retain that individual entry. This is why pure linear attention models are weak at exact quotation or identifier matching over long documents.

That is exactly why this architecture is hybrid. The ordinary attention layer that appears once every four layers is the channel responsible for exact lookup. The linear layers carry summary and flow cheaply, and the periodic attention layers look at the source directly when it matters. The three-to-one ratio is the result of trading those two against each other, not a value proven optimal.

What this means in practice: when you use this model over a long context and summarization and reasoning go well but pinpointing a specific value goes wrong unusually often, that is not a prompting problem. It is the failure the structure predicts.

Where FP8 actually applies

This repository is the FP8 variant. The card says it used fine-grained FP8 quantization with a block size of 128, and that performance is nearly identical to the original.

The block size is the point. If you use one scale across all the weights, a single outlier eats the resolution of everything else. Group them 128 at a time with a separate scale per group and the damage from an outlier is confined to that group.

Watch out for this: FP8 shrinks the weights, not the KV cache. The cache savings above come from the layer layout and are independent of FP8. If memory blows up on a long context, tightening weight quantization further will not fix it. What you should look at then is cache quantization or the number of concurrent requests.

The condition attached to the 1M context

The card says positional interpolation extends the context to a million tokens, and it also states the limit: the implementation is static, so the scaling factor stays fixed regardless of input length.

That is not a sentence to skim past. If you turn the million-token setting on, the same factor applies to a 2,000-token request as well. It means short-input quality can degrade.

So from a deployment standpoint, taking both long and short requests through a single endpoint is risky. If long-context traffic is only a slice of the whole, it is better to split instances with the extension on from instances with it off. For reference, the output allocation the card gives at the million-token setting is 262,144 tokens for reasoning and 131,072 for the final response.

Benchmarks and how it is run

Some of the figures listed on the card: SWE-bench Pro 61.7%, Terminal Bench 2.1 73.0%, IFBench 79.5%, LiveCodeBench v6 90.3%. On the vision side, OSWorld-Verified 84.3%, AndroidWorld 81.9%, OmniDocBench 1.5 at 91.1%, and MathVision at 94.6% with chain of thought enabled.

SGLang, vLLM, and TokenSpeed are named as inference frameworks, and the license is Apache 2.0.

# Example: the minimal launch form given on the model card
vllm serve "Qwen/Qwen3.8-27B-FP8"

It matters that the sampling values differ per mode. Thinking mode is temperature 1.0, top_p 0.95, top_k 20, presence_penalty 0.0; instruct mode is temperature 0.7, top_p 0.80, top_k 20, presence_penalty 1.5. The card states that thinking mode is the default.

Where the comments split

What came up repeatedly in the comments was not the benchmarks but token usage. One commenter wrote that it did solve their private problem but took five times as many tokens; another said a competing model of similar size reaches the same conclusion with a tenth of the thinking tokens, and that it is therefore hard to find a reason to use this one.

That objection matters because the benchmark table does not show this axis at all. An accuracy of 61.7% carries no information about how many tokens it took to get there. In local execution that converts directly into perceived waiting time. Several comments also reported that the chat templates are off. When tool calling does not behave, suspect the template before the model.

How to apply this

If you are evaluating local or in-house inference, three things are worth taking away.

First, stop comparing models by parameter count alone. The number 27B tells you about weight memory only. If your workload handles long contexts, what sets the real ceiling is KV memory, and that comes from the layer layout. Pulling layer count, the proportion of attention layers, and key/value head count out of each candidate's config file into one table is far more useful than comparing parameter counts.

Second, put token count into your evaluation metrics. If you measure accuracy only, the model that spends more thinking tokens always wins. Put average output tokens per task and 95th-percentile latency into the same table and the choice often changes.

Third, do not turn the long-context setting on for all traffic, because of the static scaling factor above.

Who this does not apply to

If you use managed APIs only and plan to keep doing so, most of this is background. The layer layout does not appear on your invoice. In that case, price per token and response time are enough.

The same goes for workloads whose context mostly stays under 8,000 tokens. At that length the KV cache is not the bottleneck, so you can end up carrying the compression loss without the hybrid structure's benefit ever showing. Pipelines where exact quotation is a contractual condition — pulling clauses verbatim out of legal documents, for instance — should also be validated carefully before adoption.

Summary

What this model card really tells you is not that a new model shipped, but that the cost of a long context is decided by which layers grow a cache, not by parameter count. The 48-to-16 ratio is a redistribution of that cost, and the price is part of the ability to reach back precisely into the distant past.

Sources and related reading

The structural explanation and the application advice above are my own, built on the figures written in the model card.