Fronteira

Apple silicon e unified memory

Unified memory remove a fronteira de capacidade do PCIe; dividir 800 GB/s pelo artefato fixado de 17,1 GB dá uma heurística perto de 47 tok/s, não um limite rígido de decode.

Atualizada em

01 · Conceito

Conceito

A lição 7.12 deixou uma ponta solta. Ela dimensionou um build de 4 bits do Qwen3.8-27B em 17,1 GB e observou que máquinas de unified memory “jogam acima da classe aparente” — mas não disse por quê, nem até onde. Isso é esta lição, e a resposta se divide limpo em duas perguntas que iniciantes rotineiramente fundem numa só: o modelo carrega, e quão rápido ele roda.

A pergunta do carregamento é arquitetural. Numa workstation convencional o arquivo do modelo é lido para a RAM do host, depois copiado através de uma fronteira PCIe para a VRAM própria da GPU discreta, e é essa VRAM — não a memória da máquina — que precisa comportar os pesos residentes. Uma máquina com 128 GB de RAM e uma placa de 24 GB é, para este fim, uma máquina de 24 GB. O Apple silicon remove a fronteira: a CPU, a GPU e o neural engine endereçam um único pool físico, e um tensor produzido por um é visível aos outros sem cópia. A Apple documenta isso como a arquitetura de unified memory subjacente ao Metal, e o MLX é construído diretamente sobre essa propriedade — arrays vivem em memória compartilhada, e uma operação é despachada para um dispositivo em vez de um buffer ser enviado a um. Então um artefato de 17,1 GB numa máquina com 64 GB de unified memory é simplesmente residente. Nada é transferido, nada é duplicado, e o KV cache da lição 7.2 se serve do mesmo pool em vez de competir por um pool privado menor.

A pergunta da velocidade é o roofline da lição 9.1, inalterado. O decode em batch um é limitado por memória: produzir um token transmite os tensors ativos do modelo de linguagem, então um roofline rígido é a bandwidth dividida pelos bytes ativos reais por token. A Apple informa uma memory bandwidth de aproximadamente 800 GB/s para suas peças de desktop classe Ultra. Tome esse número do fabricante e o tamanho do artefato fixado como proxy de planejamento:

800 GB/s17.1 GB de artefato46.8 tokens por segundo.\frac{800\ \text{GB/s}}{17.1\ \text{GB de artefato}} \approx 46.8\ \text{tokens por segundo}.

Cerca de 47 tokens por segundo como heurística pelo tamanho do artefato. Ela supõe que cada byte do arquivo seja tráfego ativo de pesos e uso perfeito da bandwidth; porém o GGUF também contém metadados e tensors mistos, enquanto cache, estado, kernels e temperatura acrescentam outro tráfego. Como esses efeitos movem em direções opostas, o quociente não é um limite superior rígido; meça bytes ativos e throughput.

Aqui está o desvio errado clássico, e ele tem o tamanho de uma compra. Um comprador lê que uma máquina classe Ultra pode ser configurada com 192 GB de unified memory, nota que a lição 7.12 pôs os pesos em bf16 em 54 GB e conclui: excelente, vou pular a quantização inteira e rodar o modelo em precisão plena na minha mesa. A alegação de capacidade está correta — 54 GB cabem em 192 GB com espaço para um contexto longo. A conclusão sobre velocidade não segue, mas o quociente pelo tamanho do checkpoint é apenas uma comparação de planejamento:

800 GB/s54 GB por token14.8 tokens por segundo.\frac{800\ \text{GB/s}}{54\ \text{GB por token}} \approx 14.8\ \text{tokens por segundo}.

Cerca de 14,8 tok/s como heurística pelo tamanho do checkpoint. A capacidade comprou a possibilidade de carregar bf16; não estabeleceu velocidade. Quantization pode reduzir bytes ativos, mas o ganho depende da representação real do runtime em vez de escalar mecanicamente com o tamanho do arquivo.

Dois efeitos de segunda ordem merecem ser nomeados. Primeiro, o cache não está livre do mesmo pool: aos 64 KiB por token da lição 7.2, uma conversa de 32.768 tokens acrescenta 2 GiB de estado de KV residente, e cada byte dele também é lido durante o decode, então contextos longos corroem o teto além da capacidade. Segundo, os aproximadamente 144 MiB de estado recorrente float32 de referência do Gated DeltaNet são constantes no comprimento da sequência, o que torna a arquitetura híbrida excepcionalmente adequada a um orçamento de memória de tamanho fixo — o cache ainda cresce linearmente com o contexto — de 8.000 para 32.000 tokens ele ainda quadruplica —, mas cresce a partir de uma base quatro vezes menor que a de um modelo puro de attention do mesmo porte, porque apenas 16 das 64 camadas fazem cache, e o estado recorrente ao lado nunca cresce.

O ponto durável é que o Apple silicon não revogou a barreira de bandwidth da lição 9.1; ele removeu uma barreira diferente. A fronteira de transferência PCIe que faz da capacidade de uma GPU discreta um penhasco rígido não existe mais, então a pergunta “cabe?” recebe uma resposta generosa em hardware de consumo. A pergunta “quão rápido?” é respondida exatamente pela mesma divisão que em todo outro chip desta track, e a lição 9.10 vai transformar as duas respostas numa conta mensal.

02 · Analogia

Analogia

Um restaurante com depósito separado manda um corredor buscar cada caixa, e o corredor entre depósito e cozinha dita o ritmo por mais rápidos que sejam os chefs. Um restaurante construído com a despensa dentro da cozinha não tem corredor nenhum — os cozinheiros simplesmente esticam o braço. Unified memory é o segundo prédio: os pesos do modelo não são copiados para o acelerador, eles já estão onde o acelerador lê. Mas a despensa ainda tem prateleiras de profundidade finita, e cada cozinheiro ainda só carrega tanto por viagem, e é por isso que capacidade e velocidade de alcance seguem sendo duas perguntas separadas.

03 · Explique de volta

Explique de volta

Explique o que a unified memory remove, depois use o tamanho fixado do artefato e a bandwidth do fabricante para calcular uma heurística de planejamento de decode em fluxo único, e explique por que um roofline rígido ainda exige bytes ativos exatos.

Mínimo: 80 caracteres e 15 palavras. Seu texto fica somente neste navegador.

Aguardando sua explicação.

Comparar com uma resposta-modelo

Numa GPU discreta, a capacidade utilizável do acelerador é a VRAM atrás do PCIe; o Apple silicon expõe um pool físico único para CPU e GPU. O artefato de texto Q4_K_M fixado tem 17,1 GB (15,93 GiB), então pode residir num pool unificado de 64 GB. Dividir um número de fabricante classe Ultra de 800 GB/s por 17,1 GB dá cerca de 46,8 tok/s, mas isso é apenas uma heurística pelo tamanho do artefato: o arquivo inclui metadados e tensors que não necessariamente são lidos em cada passo textual, enquanto cache, estado, kernels, comportamento térmico e bandwidth não atingida acrescentam custo. Um roofline rígido exige bytes ativos reais por token.

04 · Teste seu entendimento

Teste seu entendimento

01Aplicando o raciocínio de roofline da lição 9.1, o que uma grande capacidade de unified memory por si só garante sobre a velocidade de geração?
Resposta e explicação

Nada — a capacidade decide se o modelo carrega, a bandwidth dividida pelos bytes lidos por token decide o teto de velocidade — A lição 9.1 separou os dois eixos: bytes movidos por token dividindo a bandwidth dão o teto em batch 1, e a capacidade instalada não aparece em lugar nenhum nesse quociente.

02Por que uma máquina Apple silicon de 64 GB comporta um modelo que uma GPU discreta de 24 GB não comporta, mesmo quando ambas as máquinas têm 64 GB de RAM instalados?
Resposta e explicação

O pool utilizável da GPU é a VRAM dela, atrás de uma fronteira PCIe; na unified memory a GPU endereça o mesmo pool físico que a CPU — A restrição na placa discreta não é a RAM da máquina, e sim a memória ligada ao acelerador; a unified memory apaga essa distinção, que é o ponto arquitetural inteiro desta lição.

Conclua o teach-back e acerte o quiz para finalizar a aula.

◎ · Marcador de evidência

Fontes

  1. Apple Inc. (2026). Metal — Apple Developer.
  2. Apple Machine Learning Research (2026). MLX Documentation.
  3. Qwen Team (2026). Qwen3.8-27B Model Card.