- A Google TPU v1 foi um ASIC desenvolvido em 15 meses, a partir do fim de 2013, para suportar o custo e a escala da inferência em serviços de deep learning, com a meta de alcançar 10x mais desempenho por custo que uma GPU
- O ponto central foi implementar o array sistólico de 1978 de H.T. Kung e Charles E. Leiserson em uma estrutura MAC 256×256, reduzindo as idas e vindas à memória dos resultados intermediários da multiplicação de matrizes
- A TPU v1 se comunica com o host via PCIe e armazena pesos em DDR3-2133, compondo o fluxo de inferência com poucas instruções como
Read_Host_Memory, Read_Weights, Matrix_Multiply / Convolve, Activate e Write_Host_Memory
- Com multiplicação inteira de 8-bit×8-bit e quantização, evitou o custo de área em silício dos cálculos em ponto flutuante, e a execução é controlada por um User Space Driver e um Kernel Driver integrados ao TensorFlow
- Intel Haswell CPU e Nvidia K80 GPU eram as referências de comparação na época; em inferência, a TPU v1 era cerca de 15~30x mais rápida e tinha desempenho/Watt incremental relativo 25~29x maior que a GPU, mas não era um dispositivo para treinamento
O ponto de partida da TPU v1 para reduzir o custo de inferência
- O objetivo do projeto TPU v1 era criar rapidamente um ASIC para inferência para reduzir o custo de hardware em larga escala exigido por serviços baseados em deep learning
- A meta era ter uma vantagem de 10x em desempenho por custo em inferência em relação à GPU
- Eram exigidos ao mesmo tempo desenvolvimento rápido, alto desempenho, aplicação em larga escala, suporte imediato a novas cargas de trabalho e eficiência de custo
- O nome TPU vem do fato de ser um dispositivo que acelera operações com tensores
- Na prática, os cálculos centrais tratados pelo hardware da TPU v1 são principalmente operações com vetores e matrizes
- As camadas ocultas e de saída de redes neurais podem ser representadas como o resultado da aplicação de uma função de ativação ao produto entre um vetor de entrada e uma matriz de pesos
- Quando entram vários dados de entrada, a forma passa a ser a aplicação da função de ativação a cada elemento do resultado da multiplicação de matrizes
Processamento de multiplicação de matrizes com array sistólico
- A TPU v1 usa o conceito de sistema sistólico apresentado no artigo de 1978 de H.T. Kung e Charles E. Leiserson, Systolic Arrays (for VLSI)
- É uma estrutura em que vários processadores calculam e transferem dados em um ritmo regular
- Cada processador executa um cálculo curto enquanto move continuamente os dados para dentro e para fora
- Em uma multiplicação simples de matrizes 2×2, se os valores de entrada forem fornecidos na ordem correta por cima e pela esquerda, o resultado surge naturalmente em um array MAC 2×2
- Cada MAC realiza multiplicação e acumulação
- As somas parciais ficam armazenadas dentro do array, e o resultado final aparece em forma de diagonal em movimento
- O exemplo 2×2 requer 4 etapas, mas na prática, assim que o MAC superior esquerdo fica livre, já é possível iniciar a próxima multiplicação de matrizes, permitindo uma nova a cada 2 ciclos
- O essencial é que, ao alimentar o array sistólico na ordem correta, o próprio fluxo de valores e resultados cria a sequência de cálculo necessária
- Não é preciso salvar resultados intermediários na memória principal e depois buscá-los novamente
- Graças à estrutura da unidade de multiplicação de matrizes e à ordem de entrada, os resultados intermediários ficam automaticamente disponíveis no momento certo
Configuração do sistema TPU v1
- A TPU v1 se comunica com o computador host por meio do barramento serial de alta velocidade PCIe e acessa diretamente sua própria DDR3 DRAM
- Os principais componentes são os seguintes
- DDR3 DRAM / Weight FIFO
- Os pesos são armazenados em chips DDR3 RAM conectados por interface DDR3-2133
- Depois de serem pré-carregados da memória do host via PCIe, são movidos para a Weight FIFO para uso pela Matrix Multiply Unit
- Matrix Multiply Unit
- É um array sistólico composto por MACs 256×256
- Recebe 256 pesos por cima e 256 entradas de dados pela esquerda
- Accumulators
- Armazenam os resultados que saem da parte inferior da unidade matricial sistólica
- Activation
- É a etapa que aplica a função de ativação da rede neural
- Unified Buffer / Systolic Data Setup
- Armazena os resultados após a aplicação da função de ativação e os prepara para serem novamente fornecidos como entrada da Matrix Multiply Unit no cálculo da próxima camada
Formato de cálculo e conjunto de instruções
- A Matrix Multiply Unit da TPU v1 executa multiplicação inteira de 8-bit×8-bit
- Com o uso de quantização, evita cálculos em ponto flutuante, que exigiriam maior área em silício
- O conjunto de instruções é um projeto CISC com cerca de 20 instruções
- As instruções não são buscadas na memória; o computador host as envia via PCIe
- A maior parte do fluxo de inferência é composta por 5 instruções principais
Read_Host_Memory
- Lê os valores de entrada da memória do host via PCIe para o Unified Buffer
Read_Weights
- Lê os pesos da memória de pesos para a Weight FIFO
Matrix_Multiply / Convolve
- Envia as entradas do Unified Buffer para os Accumulators enquanto executa multiplicação de matrizes ou convolução
- Multiplica uma entrada B×256 por pesos constantes 256×256 para gerar uma saída B×256, levando B ciclos de pipeline
Activate
- Aplica funções não lineares de neurônios artificiais, como ReLU e Sigmoid, à entrada dos Accumulators e envia o resultado ao Unified Buffer
Write_Host_Memory
- Escreve o resultado do Unified Buffer na memória do host via PCIe
- Esse fluxo pode ser visto aproximadamente na seguinte forma
Read_Host_Memory
Read_Weights
Loop_Start
Matrix_Multiply
Activate
Loop_End
Write_Host_Memory
- A unidade matricial usa execução sistólica para economizar energia reduzindo leituras e escritas no Unified Buffer
- Os dados entram pela esquerda, e os pesos são carregados por cima
- As operações MAC de 256 elementos atravessam a matriz como uma frente de onda diagonal
TensorFlow e a pilha de drivers
- Para usar o hardware da TPU v1 em serviços reais, era necessária uma pilha de software que o suportasse
- Como a Google desenvolvia e usava o TensorFlow, um passo central foi criar drivers para que o TensorFlow funcionasse com a TPU v1
- A pilha de software da TPU precisava ser compatível com as pilhas de CPU e GPU
- As aplicações precisavam poder ser portadas rapidamente para a TPU
- A parte da aplicação executada na TPU geralmente é escrita em TensorFlow e compilada para uma API que pode rodar em GPU ou TPU
- Assim como nas GPUs, a pilha da TPU também é dividida em User Space Driver e Kernel Driver
- O Kernel Driver é mantido leve, lidando apenas com gerenciamento de memória e interrupções, com foco em estabilidade de longo prazo
- O User Space Driver muda com frequência e é responsável pela configuração e pelo controle da execução da TPU, pela reformatação de dados conforme a ordem da TPU, pela conversão de chamadas de API em instruções da TPU e pela geração do binário da aplicação
Processo de 28nm e layout do die
- A TPU v1 foi fabricada no relativamente maduro processo de 28nm da TSMC
- Na época, os chips Intel Haswell CPU e Nvidia K80 GPU usados nos data centers do Google eram feitos em processos mais avançados
- Segundo o Google, a área do die da TPU v1 era menos da metade da área de die desses chips
- A ISA simples reduziu o overhead de área em silício necessário para decodificação e tarefas relacionadas
- A área
control ocupa apenas 2% da área do die
- A Matrix Multiply Unit ocupa 24%, e o Unified Buffer, 29%
Comparação de desempenho e limitações claras
- A TPU v1 é um dispositivo de inferência voltado a usar de forma mais eficiente modelos já treinados em serviços reais na escala do Google
- Não foi projetada para melhorar velocidade ou eficiência de treinamento
- Inferência e treinamento impõem desafios diferentes no desenvolvimento de hardware especializado
- Em 2013, as principais referências de comparação eram a Intel Haswell CPU e a Nvidia K80 GPU
- A TPU v1 tem 25x mais MACs que a K80 GPU
- A TPU v1 tem 3,5x mais memória on-chip que a K80 GPU
- A TPU v1 é cerca de 15~30x mais rápida em inferência do que a K80 GPU e a Haswell CPU
- O desempenho/Watt incremental relativo em relação à GPU é de 25~29x
- Graças à arquitetura personalizada, a TPU v1 alcançou desempenho de inferência superior e menor consumo de energia do que CPUs e GPUs da época
- Por ser um design de primeira geração focado em um único objetivo — inferência rápida e eficiência energética —, ficou a limitação de não ter sido projetada para treinamento
1 comentários
Comentários do Hacker News
O CEO da Groq, Jonathan Ross, contou recentemente em uma entrevista em podcast sobre a época em que criou os primeiros TPUs no Google: originalmente era um FPGA feito no tempo livre de 20%, enquanto ele se sentava perto de uma equipe que estava sofrendo com problemas de velocidade de inferência
Depois que fizeram algo funcional, Jeff Dean fez as contas e decidiram partir para um ASIC
Hoje, eu acho que o Google deveria transformar a equipe de TPU em uma empresa separada. É o único concorrente realmente confiável da Nvidia e o suporte de software fica só um nível abaixo do da Nvidia
https://open.spotify.com/episode/0V9kRgNS7Ds6zh3GjdXUAQ?si=q...
Mas cada uma dessas vantagens tem fraquezas. A capacidade nas foundries é apertada, mas a Nvidia pode sacrificar o mercado de GPUs para consumidores se puder vender chips de IA mais caros. Se um concorrente tivesse apostado pesado há alguns anos, ou se uma empresa com muita capacidade de produção, como a Intel, mudasse suas prioridades, essa vantagem desapareceria
Software proprietário é conveniente quando vira padrão da indústria, mas sua importância real depende muito do caso de uso. O design de hardware para TPU parece intrinsecamente muito mais simples que uma GPU: não precisa de ray tracing, texture samplers nem rasterização, e em grande parte basta ter multiplicação de matrizes e muita memória
Relacionamento com clientes ajuda a continuar participando das conversas, mas em um mercado que busca qualquer pequena vantagem, o fornecedor de hardware com mais FLOPS por dólar terá clientes suficientes para ocupar sua capacidade de produção. Por isso, parece que daqui a alguns anos a concorrência deve se tornar bem real rapidamente
Ainda assim, TPU é um recurso de computação relativamente escasso mesmo dentro do Google, e provavelmente eles já têm dificuldade para atender à demanda interna
Quase nunca digo que respeito uma empresa nesse nível, mas a Groq realmente merece esse respeito
O Google inventou o TPU e o Google Research até publicou artigos sobre LLMs, então não entendo por que a NVDA e as startups de IA ficaram com quase 100% do valor
No caso do Google, dá para fazer a analogia de que propor algo como o ChatGPT para grande escala poderia canibalizar o posicionamento pago no buscador e a receita de anúncios de sites que as pessoas talvez nem precisassem visitar. Então pode ter surgido a decisão de introduzir isso só quando fosse necessário por causa da concorrência, e de um jeito cuidadoso que causasse menos impacto
Na prática provavelmente não é tão simples assim, mas seria bem engraçado se esse fosse o motivo
https://www.linkedin.com/posts/eolver_googles-defense-agains...
Sou funcionário do Google e, se você não olhou os TPUs há algum tempo, recomendo conferir o v5. Agora ele suporta PyTorch/JAX, então ficou muito mais fácil de usar do que quando era só para TensorFlow
Este texto conectou muito bem várias peças que estavam dispersas em um nível abstrato, mostrando como elas de fato fluem dentro do silício
Foi especialmente bom ver instruções CISC simples correspondendo quase diretamente às etapas de inferência de LLM
Talvez seja uma pergunta boba que revela que eu não entendo bem do assunto, mas do lado do consumidor continuo ouvindo que os chips M1 a M4 são bons para algumas tarefas de IA
Hoje o que mais importa para mim são ferramentas como Photoshop e Resolve, e vi que elas rodam muito mais rápido nos novos chips proprietários da Apple do que na minha máquina antiga
Isso talvez não se conecte bem com o que este chip ou um H100 conseguem fazer, mas fico curioso se existe alguma relação, mesmo que parcial. Claro que a Apple não vende seus chips proprietários separadamente, então para transformar isso em algo prático teria que lançar algo como um servidor externo cheio de GPUs e chips de IA
Os chips M* usam memória unificada e, especialmente os modelos Pro/Max/Ultra, têm largura de banda de memória muito alta, mesmo comparados a GPUs como a 1080. A largura de banda de memória do M1 Ultra fica em algum ponto entre a 2080 e a 3090
Em tamanhos de lote pequenos, especialmente lote 1 como na maior parte do trabalho local, a inferência fica limitada mais pela largura de banda de memória do que pela capacidade de computação. É por isso que se diz que os chips M* são bons para machine learning
Mas o H100 é usado principalmente para treinamento com tamanhos de lote enormes, e treinar modelos grandes exige muitas interconexões. Nessa escala, a intensidade aritmética é muito alta, então os chips M* não seriam muito competitivos, mesmo que pudessem ser ligados em rede. É como escolher outro ponto da curva de Pareto entre energia e eficiência em comparação com chips que consomem muita energia, como o H100
O que o Google realmente deveria fazer é entrar na área de 2nm EUV e descer abaixo de 2nm
Se eles conseguissem algo assim, seja litografia eletrônica ou a tecnologia que a ASML grava nos chips, se tornariam uma força realmente perigosa. Parece que precisariam de um projeto hardcore no estilo moonshot do Google X
Ou talvez eles até tenham uns US$ 500 milhões para comprar uma máquina. Se o TPU for realmente tão bom assim, pode ser um bom negócio integrar verticalmente com tecnologia própria e até uma fab própria
Hoje, fabs de ponta dão lucro porque fabricam dispositivos de computação de uso geral para clientes e aplicações diversos, além de contarem com décadas de talentos acumulados e engenharia. Além disso, os clientes impulsionam inovação de forma independente em áreas-chave, como melhorias no rendimento de chip-on-chip HDI da Micron e o fabric de comunicação entre dies e o design de substratos multichip da Xilinx
O TPU jamais conseguiria produzir o volume necessário, nem atrair clientes suficientes para criar economias de escala lucrativas. O Google também teria de oferecer um preço atraente em relação aos concorrentes
Se houvesse um caso de negócio realmente convincente, as fabs existentes alocariam capacidade de bom grado. O TPU ainda está longe de ser tão convincente assim
Ouvi uma apresentação do Jim Keller, da TensTorrent, explicando uma abordagem diferente para construir núcleos de IA. A ideia é usar cinco núcleos RISC-V: um para carregar dados, um para enviar dados e os demais dedicados a operações matriciais
Ele também mencionou o Google TPU e disse que programá-lo parecia lidar com VLIW, e que havia cerca de 500 pessoas trabalhando no compilador
O texto original diz que o “TPU v1 era um projeto CISC com cerca de 20 instruções”, e é engraçado como CISC/RISC parece ter ido de observação afiada a programa de pesquisa, tecnologia revolucionária, modismo de marketing e, no fim, puro papo sem sentido
Dá para chamar isso de ciclo de vida de um termo
Então, mesmo que o TPU tenha poucas instruções, ele ainda pode ser CISC se cada uma delas for bem complexa. Mas faz 15 anos que cursei arquitetura de computadores na pós, então minha memória está meio nebulosa. Também passei boa parte daquele semestre trabalhando com Itanium, que hoje já não serve para muita coisa
Parece haver uma demanda enorme por capacidade de foundry, então fico curioso sobre como Microsoft ou Google vão para o topo da fila quando precisam produzir seus próprios chips
Será que eles são simples o bastante para serem fabricados em fabs “mais antigas e com menos demanda”? Sei que Apple e Nvidia já ocupam bastante capacidade de foundry
https://en.wikipedia.org/wiki/Tensor_Processing_Unit#Product...
Eles também têm presença e gasto consideráveis em áreas como HBM, e o SemiAnalysis tem textos bons sobre isso
Fico curioso para saber como o hardware mudaria se LLMs realmente se consolidarem com quantização em -1, 0, 1