Dimensionamento do KV cache e orçamentos de memória

01 · Conceito

Conceito

Você tem um acelerador de 80 GB e quer servir o Qwen3.8-27B com janelas de 8.192 tokens. Alguém subtrai 54 dos pesos de 80, divide o restante pelos 64 KiB por token da lição 7.2 e reporta 48 usuários. O resultado calculado é 36: a estimativa ingênua fica um terço acima, e o modo de falha é um crash por falta de memória sob carga. Esta lição faz o orçamento linha a linha porque tudo o que vem depois é precificado contra ele.

Comece pela capacidade utilizável, e não pela capacidade de folheto. Uma peça vendida como 80 GB carrega HBM da classe 80 GiB e reporta aproximadamente 79,6 GiB ao runtime depois que ECC e regiões reservadas de firmware são descontadas, então o número que você consegue de fato alocar é menor que o número na caixa. Fazer o orçamento inteiro numa única família de unidades é a única defesa, então converta tudo para gibibytes e permaneça ali. Os pesos em bf16, cerca de 54 GB pelo número canônico, são 50,3 GiB. Em seguida vem uma linha que a subtração ingênua omite por completo: a reserva de runtime. O contexto do driver, buffers de ativação para o maior batch que você pretende rodar, workspace temporário para os kernels de attention e de feed-forward, e a fragmentação do alocador consomem juntos vários gibibytes antes que exista um único token de cache. Seis gibibytes é um número ilustrativo e nada generoso; frameworks de serving codificam a mesma ideia como uma fração de utilização, retendo por padrão cerca de um décimo do dispositivo. O restante é o pool:

Agora precifique uma sequência, e precifique-a por completo. A lição 7.2 derivou o cache em 4 KiB por token por camada que faz cache, 64 KiB por token através das 16 camadas de full attention, e essa derivação não se repete aqui. Uma conversa de 8.192 tokens, portanto, guarda

de keys e values. Mas as 48 camadas de Gated DeltaNet também não são de graça. Na referência do Transformers, cada uma mantém um estado matricial de 3 MiB em float32, totalizando 144 MiB sem o pequeno estado de convolução. Esse estado pertence à sequência, não ao modelo. Cada conversa carrega uma cópia. O custo real é 512 mais 144, ou 656 MiB, e o pool comporta

Trinta e seis, não quarenta e oito. As três correções são a conversão de unidades, a reserva de runtime e o estado recorrente constante.

Empurre o mesmo pool ao outro extremo. Uma sequência de 262.144 tokens guarda 16.384 MiB de K/V mais 144 MiB de estado matricial, então o pool comporta uma. Em 32.768 tokens, cada sequência custa 2.048 mais 144, ou 2.192 MiB, e a placa serve dez. A concorrência é função do comprimento de contexto prometido.

Refaça o orçamento com pesos em FP8 e cache em FP8. Os pesos caem para cerca de 27 GB, ou 25,15 GiB, e o cache para 32 KiB por token. O pool passa a 49.613 MiB. Cada sequência de 8.192 tokens custa 256 MiB de cache mais os 144 MiB inalterados do estado da referência, 400 MiB no total, então a placa serve

e cinco conversas em contexto nativo completo. Isso é um ganho de aproximadamente 3,4 vezes nessa mudança combinada de precisão.

Omitir o estado DeltaNet prevê 46 sequências em bf16 em vez de 36, cerca de 28 por cento a mais, e 193 em FP8 em vez de 124, cerca de 56 por cento a mais. O estado é constante, então seu peso relativo cresce quando os termos variáveis encolhem; muitas cópias de 144 MiB viram uma linha relevante do orçamento.

Leve dois hábitos desta lição. Orce numa única família de unidades, e precifique uma sequência por completo em vez de precificar apenas o cache dela. A lição 9.4 muda a linha de capacidade mudando o silício, e a lição 9.10 transforma esses números de ocupação em custo por token.