Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA em português / Inferência em GPU lenta desmascarada: fallback para CPU, conflitos de versão CUDA/TensorRT e erros de contêiner (Dublagem IA)

Transcript

Inferência em GPU lenta desmascarada: fallback para CPU, conflitos de versão CUDA/TensorRT e erros de contêiner (Dublagem IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA em português

0:00
Começou com um aviso, depois do silêncio.
0:02
A conta da GPU subiu como se o acelerador nunca dormisse, mas as saídas se arrastavam como se as luzes estivessem apagadas.
0:07
Os painéis estavam verdes, os clientes não.
0:10
Anomalia não fazia sentido.
0:12
Utilização de GPU próxima de zero enquanto a latência disparava.
0:15
Nenhum alerta foi disparado, nenhuma linha vermelha, apenas tempo evaporando.
0:18
As evidências sugerem uma patologia única disfarçada de normalidade.
0:22
Aqui está a promessa.
0:23
Vamos rastrear os artefatos, nomear o culpado e corrigir a patologia.
0:26
Examinaremos três modos de falha, fallback para a CPU, incompatibilidade de diversão entre CUDA e o ANX Tenso RT,
0:32
configuração incorreta de container, provaremos isso com latência, taxa de transferência e utilização de GPU antes e depois.
0:39
Configuração do caso, o ambiente e o perfil da vítima.
0:41
Toda a configuração conta uma história, e esta começa com um cliente comum sob pressão.
0:46
A carga de trabalho e difusão de texto para imagem.
0:49
Variantes de stable diffusion rodando em 512 por 512 e escalando para 1024 por 1024.
0:54
Tráfego intermitente.
0:55
A concorrência pressiona entre 8 e 32 solicitações.
0:58
Os tamanhos de lote variam de 1 a 8.
1:00
Os níveis de serviço são rigorosos quanto à latência de cauda.
1:02
Violações de P95 se traduzem diretamente em créditos e penalidades.
1:05
Os modelos não são exóticos, mas suas escolhas importam.
1:08
Pipelines de stable diffusion exportados em ONX 6,
1:11
otimizações de atenção cruzada como Xformers ou Scale.Product Attention,
1:14
e seleções de agendador que trocam passos por qualidade.
1:17
O ecossistema deveria acelerar quando a estrutura é bem feita.
1:21
O hardware parece respeitável no papel.
1:22
Placas, CNVID, RTX e Série A na nuvem, 16 a 32 GB de verão.
1:27
O PCI fica entre o host e o dispositivo como um pedágio.
1:30
Rápido o suficiente quando configurado, punitivo quando os limites de erro recorrem a transferência de paginares.
1:34
Neste ambiente, nada é acidental.
1:36
A cadeia de ferramentas se organiza em camadas familiares.
1:38
O PyTorch é usado para exportação, então ONIX Runtime ou Tenso RT assume a inferência.
1:42
Os drives e escudas sustentam tudo.
1:44
Os kernels de atenção prometem velocidade se as versões estiverem alinhadas.
1:47
A implantação é estritamente containerizada.
1:50
Imagens imutáveis, lançamentos controlados por CI e Blue Green por política.
1:54
Essa restrição deveria criar segurança.
1:56
Também pode congelar defeitos no tempo.
1:57
Os riscos comerciais não são mistratos.
1:59
O custo por solicitação define a margem.
2:01
Reservas de GPU precificadas por hora que aos kernels rodem ou não.
2:05
Quando a latência se estende de segundos para meio minuto, a taxa de transferência é colar.
2:08
Uma configuração incorreta transforma um acelerador em um aquecedor.
2:11
Caro, silencioso e ocupado sem fazer nada que ajude a fila.
2:13
Após um exame mais detalhado, o perfil da vítima se estreita.
2:17
Concorrência em 16 lotes em 2 para ficar abaixo dos limites de verã em 512, subindo para 1.024 por qualidade.
2:24
O cliente espera um P95 consistente.
2:27
Em vez disso, os rastreamentos mostram latências erráticas grandes deltas entre P50 e P95
2:32
e ciclos de trabalho da GPU oscilando de 5% a 40% e uma razão óbvia.
2:37
Os gráficos da CPU revelam uma verdade feira.
2:39
Núcleos em carga máxima sem que o pré-processamento justifique.
2:41
As evidências sugerem 3 caminhos.
2:43
Primeiro, fallback para a CPU.
2:45
Quando o provedor de execução CUDA ou TensoRT falha ao carregar, o motor seleciona silenciosamente o gráfico da CPU.
2:50
O modelo funciona, mas com 10 a 30 vezes mais atento.
2:53
Segundo, incompatibilidade de versões.
2:55
ONQs Front Time compilado com CUDA.
2:57
Nós rodando outro, motores TensoRT invalidados e reconstruídos com kernels genéricos.
3:02
A utilização aparece, mas os caminhos rápidos desapareceram.
3:04
Terceiro, erro de configuração de contêiner, imagens pesadas, montagem de GPU ausentes, configurações erradas do kit de ferramentas NVIDIA e alocações de memória que amplificam a latência sob carga.
3:14
E, no fim das contas, isso não é um mistério sobre o modelo.
3:17
Um caso sobre a veracidade da infraestrutura.
3:19
Rastrearemos os artefatos, a ordem dos provedores, os logs de capacidade e as montagens de dispositivos, que relacionaremos a três métricas mutáveis.
3:26
Latência, throughput e utilização da GPU.
3:30
Arquivo de evidência A, fallback da CPU.
3:33
O sabotador, silencioso.
3:36
Começou com uma requisição que deveria levar segundos e não levou.
3:38
O medidor da GPU estava quieto, quieto e mais.
3:41
O gráfico da CPU, enquanto isso, disparou com um alarme de incêndio.
3:44
Após um exame mais atento, o motor tinha feito uma escolha.
3:46
Executou um trabalho de custo de GPU na CPU.
3:48
Nem o alerta foi disparado.
3:49
A saída foi retornada eventualmente.
3:51
Este é o sabotador silencioso, o fallback da CPU.
3:54
Por que isso importa é simples.
3:55
Stable diffusion na CPU é uma perda de tempo.
3:58
O modelo funciona, mas a latência se multiplica, 10 a 30 vezes mais lenta, e o throughput colapsa.
4:03
Em um ambiente que vem de milissegundos, essa diferença é fatal.
4:06
A conta continua cobrando tempo de GPU, mas o dispositivo não faz o trabalho.
4:09
A linha do tempo revelou o padrão.
4:10
Containers que rodavam localmente com CUDA voavam.
4:13
Implantados em um node cluster com uma pilha de drivers ligeiramente diferente, os mesmos containers iniciavam.
4:17
Respondiam a sondagem de saúde, então degradavam.
4:20
O endpoint de saúde apenas verificava o servidor citativo.
4:22
Portanto, nunca verificava se o GPU está realmente executando.
4:25
Neste ambiente, nada é acidental.
4:27
O silêncio é um artefato.
4:29
O artefato principal é a ordem do provedor de execução no NNX Runtime.
4:33
O motor aceita uma lista.
4:35
Tente ter seu RT, depois CUDA, depois CPU.
4:36
Se o CUDA falha ao inicializar, driver errado, bibliotecas ausentes, dispositivo não montado,
4:42
o RT vinculará silenciosamente o provedor de execução da CPU.
4:45
Sem exceção, sem travamento, apenas uma linha nos logs, frequentemente escondida.
4:48
Provedor de execução CUDA não disponível.
4:50
Recorrendo à CPU.
4:52
Essa linha é a confissão que a maioria das equipes nunca lê.
4:54
Aqui está a parte estranha.
4:55
Os gráficos de utilização parecem enganosamente normais à primeira vista.
4:58
As requisições ainda são concluídas.
5:00
O mapa de serviço mostra verde, mas o ciclo de trabalho da GPU para em 5%
5:03
e quanto o tempo de CPU do usuário dispara e estabiliza.
5:06
A latência P50 quadruplica e a P95 se descontrola.
5:09
Profil adjajada de apiação.
5:11
Filas se acumulam e o escalonamento automático adiciona mais réplicas que a AirDom.
5:14
Pense nisso como uma equipe de revezamento, onde o velocista nunca aparece,
5:17
então o bibliotecário corre a etapa.
5:19
O bastão se move, mas não na velocidade da corrida.
5:21
Em outras palavras, o sistema entrega a correção à custa de todo o orçamento de SLO.
5:25
Os artefatos se acumulam rapidamente quando você rastreia a sequência de desação.
5:28
Os logs de carga do provedor mostram tentativas de inicialização do CUDA
5:31
com verificações de versão do drive.
5:32
Se o container foi criado para CUDA 2.2, mas o nosso Atena 12.0, a inicialização falha.
5:39
Se o kit e ferramentas de container da NVIDIA não estiver configurado,
5:42
a montagem do dispositivo nunca aparece dentro do container.
5:44
Sem drive-by-Vidia, não há IBCU.
5:46
Portanto, se a especificação do pod não solicitar GPUs explicitamente,
5:50
o agendador nunca atribui o dispositivo.
5:52
Qualquer um desses pontos dispara o downgrade silencioso.
5:55
A reprodução é direta.
5:56
Em um nó mal configurado, uma inferência simples exibe provedores de execução de CPU,
6:01
onde você esperava provedores tenso RT ou CUDA ou CUDA.
6:07
Envie um único prompt e a GPU permanece ociosa.
6:11
As threads da CPU disparam e a imagem retorna em 20 a 40 segundos em vez de 2 a 6.
6:15
Repita em um nó com drivers e montagens corretos.
6:17
O mesmo prompt termina em uma fração do tempo
6:19
e o ciclo de trabalho da GPU pula para uma faixa sustentada.
6:22
As evidências sugerem que as proteções atuais são teatrais.
6:25
As sondas de saúde retornam no 200 porque o servidor responde.
6:28
Não há afirmação na inicialização de que o caminho da GPU esteja ativo.
6:31
Sondas de desempenho não existem,
6:32
então a orquestração acredita que as réplicas estão saudáveis.
6:34
O sistema não consegue distinguir entre aceleração e emulação.
6:38
A contramedida é deliberada mediária.
6:40
Falha crítica se o provedor de execução da GPU estiver ausente ou degradado.
6:44
Recuse-se iniciar com o CPU em produção.
6:46
No lançamento do processo, enumere os provedores.
6:49
Confirme se o tenso RT ao CUDA carregou
6:51
e se a contagem de dispositivos corresponde às expectativas.
6:54
Registre o conjunto de capacidades CUDA-NN,
6:56
núcleo de tensor disponíveis, limite de memória
6:58
e saia com código diferente de zero se algo estiver faltando.
7:01
Troque disponibilidade por integridade.
7:03
Deixe os orquestradores reagendarem em um nó saudável.
7:05
Para garantir isso, imponha a verificação de vinculação de ava.
7:08
Vincule entradas e saídas à memória do dispositivo
7:10
e valide uma inferência trivial na inicialização.
7:13
Uma execução de aquecimento que exercite o kernel de atenção fundida.
7:15
Se o tempo exceder um limite de latência,
7:18
assuma um caminho degradado e falha o POD.
7:20
Adicione um conjunto de prompts de teste que não é coincidência.
7:23
Compare a latência com a janela de referência.
7:26
Se o desvio exceder sua tolerância,
7:27
alerte a equipe de produção e interrompe o rolado.
7:29
Isso pode parecer rigoroso, mas a alternativa é pior.
7:32
Um cluster que funciona enquanto?
7:34
Drena tempo e orçamento.
7:35
Trave a ordem do provedor, rejeite o fallback do CPU
7:37
e faça o sistema provar que é rápido antes de considerá-lo ativo.
7:40
Só então o verde significa acelerado.
7:44
Evidência e arquivo B.
7:45
Incompatibilidade de versão.
7:46
Cuda Onyx, Tenso RT, incompatíveis.
7:49
Se a GPU não foi usada,
7:50
a próxima pergunta é se ela conseguiria operar em velocidade máxima mesmo estando presente.
7:54
A evidência sugere uma falha mais sutil.
7:56
As versões alinham-se o suficiente para rodar,
7:58
mas não o bastante para liberar o caminho rápido.
8:00
O sistema parece acelerado até você observar os relógios.
8:03
Porque isso importa é simples.
8:05
Pipelines de difusão dependem inteiramente do desempenho de atenção.
8:07
Quando o Onyx Runtime e o Tenso RT não conseguem carregar kernels fundidos que esperam,
8:11
devido a versões divergentes de CUDA com o DNN ou Tenso RT,
8:14
eles se redirecionam silenciosamente para implementações genéricas.
8:17
O modelo funciona.
8:19
A utilização oscila entre 30% e a latência ultrapassa o orçamento.
8:24
O build parece o mesmo, trabalha mais lento.
8:26
Em uma análise mais detalhada, os artefatos são precisos.
8:29
Os logs de carga do provedor declaram sucesso uma pista.
8:32
Retornando para kernels padrão ou com o XFarmers desabilitado,
8:35
você verá a falha na deserialização do plano Tenso RT com a reconstrução do engine incompatível
8:40
que aciona uma compilação no nó.
8:42
Engines criados em uma versão secundária do Tenso RT não deserializam em outra.
8:46
A reconstrução termina, mas o plano resultante pode omitir a tensão fundida,
8:49
otimizações FP16.
8:51
A corrida termina.
8:53
Sem picos, os ciclos de trabalho e os tensor cores permanecem baixo.
8:56
Aqui está a parte contra intuitiva.
8:57
As equipes interpretam que se roda e está otimizado.
9:00
Neste ambiente, nada é acidental.
9:03
Se a tensão Scale.Product não está ativa, se o XFarmers está desligado,
9:06
se o QDNN reporta espaço de trabalho ilimitado, o desempenho colapsa educadamente.
9:10
A versão simples é que binários incompatíveis forçam kernels que usam mais movimentação de memória
9:14
e menos densidade matemática.
9:16
O PCI torna-se visível nos rastreamentos.
9:18
As latências de cauda oscilam à medida que a concorrência aumenta.
9:20
Pense na pilha como um conjunto de fechador.
9:22
Driver, Toolkit, CUDA, CUDA-NN, flag de compilação do NNX Runtime e tensor RT.
9:28
No dente fora do lugar, a chave gira apenas pela metade.
9:31
O ART anuncia um gráfico de capacidade para o provedor de execução.
9:34
Se o ART compilado espera CUDA 12.2, mas o driver dos nós põe 12.1,
9:39
o CUDA carrega com recursos restritos, nem carrega.
9:42
Se o tensor RT é 8.6 no nó, mas os planos foram gerados com 8.4,
9:46
a deserialização falha e regenera com táticas conservadoras.
9:50
O sistema prefere a correção à velocidade silenciosamente.
9:53
Benchmarks comprovam a perda em termos práticos.
9:55
Com X-Formers ou SDP ativos, a tensão de difusão reduz o tempo de processamento de forma mensurada.
10:00
Pesquisas mostram consistentemente acelerações de 2x acima x no caminho de tensão,
10:03
dependendo da resolução e do tamanho do lote.
10:06
Desabilite-se por diversão e você perderá esses multiplicadores.
10:09
A fusão de tokens, Tomy A, acumula-se com esses ganhos.
10:12
Sem os cânions fundidos, benefício é limitado pela largura de banda da memória e layouts não otimizados.
10:17
A lacuna aumenta em resoluções de 1024x1024, concorrência maior.
10:21
Para rastrear os artefatos, comece pela numeração de capacidades.
10:24
Na inicialização, imprima a lista exata de provedores e seus recursos reportados.
10:28
Versão do tensor RT, disponibilidade de FP16 e NT8, espaço de trabalho máximo,
10:33
heurística de convolução com o DNN, presença de NC-SERI para multi-GPU.
10:38
Para o runtime ONNX, despeje as prioridades de EP.
10:41
Tenso RT, CUDA, depois CPU.
10:43
Verifique o que realmente se vincula aos nós do seu gráfico.
10:46
Registre se os nós de atenção são atribuídos ao tensor RT com kernels fundidos ou a kernels CUDA genéricos.
10:52
Em seguida, interrogue o ambiente.
10:54
Consulte o driver.
10:55
O NVDSME mostra o módulo do kernel e a compatibilidade com CUDA.
10:58
Leia as versões das bibliotecas.
10:59
Se a imagem contém bibliotecas CUDA 12.3, mas o driver host suporta até 12.2.
11:08
O modo de compatibilidade de runtime pode carregar com restrições.
11:11
Se a imagem espera cabeçalhos do tensor RT 8.6, mas o plugin do nó entrega 8.4,
11:15
as chamadas de API degradarão ou anularão certas otimizações.
11:18
A solução é uma matriz de compilação, não um desejo.
11:21
Fiche versões exatas e uma única fonte da verdade.
11:23
Imagem básica, compatibilidade de driver CUDA menor, CUDA NN,
11:27
hash de compilação URT e versão do tensor RT e versão do tensor RT.
11:30
Gere imagens de inferência contra essa matriz e rejeite nós que não correspondam via rótulos de nó e verificações de admissão.
11:36
Precompile e armazena em caixa os mecanismos do tensor RT para cada variante de modelo resolução na versão exata do tensor RT que você implanta.
11:41
Trate os arquivos de plano como artefatos vinculados à matriz.
11:44
Nunca dependa da compilação de mecanismos no nó em produção.
11:47
Isso mascara a deriva e infla as inicializações afetadas.
11:49
Para consolidar, adicione testes de fumaça em si equivalirem às capacidades do kernel.
11:54
Execute o container em um ambiente isolado com o driver-alvo e verifique se o tensor RT carrega kernels FP16 usados,
12:00
nós de atenção fundidos, vinculação de IO ativo X-Formers ou SDP reconhecidos.
12:05
Execute um conjunto de prompts determinísticos e fale a compilação se a latência se der janela base
12:09
ou se os logs contiverem qualquer linguagem de retrocesso.
12:13
Armazene instantâneo de capacidade junto com o digest da imagem
12:16
para que reversões recuperem tanto o código quanto as características de desempenho.
12:20
No final, as evidências dizem que a deriva de versão não é um bug, entende?
12:22
Ou uma velocidade que você paga.
12:24
O sistema irá rodar.
12:25
Os cronômetros irão testemunhar.
12:27
Arquivo de evidência C, container.
12:30
Erosão de eficiência por má configuração ou por design.
12:33
Mesmo quando as versões se alinham, o container pode sabotar a eficiência por dentro.
12:36
As evidências sugerem um sangramento lento, imagem inchada,
12:40
falta de conexão de GPU e comportamento do alocador que distorce a latência subcarga.
12:44
Nada trava.
12:44
Tudo degrada.
12:47
O motivo de se botar é simples.
12:49
Containers moldam a realidade do runtime.
12:51
Se a imagem é obesa e as inicializações a frio são lentas,
12:54
as réplicas chegam atrasadas ao incidente.
12:56
Se os dispositivos de GPU não estiverem montados
12:58
ou o runtime carece das flags corretas,
13:00
os provedores de execução agem de forma inadequada.
13:02
Se os arenas de memória acumulam alocações,
13:03
a rotatividade de randes para paginação e picos de latência.
13:06
O modelo parece bom.
13:08
Container taxa silenciosamente cada requisição.
13:10
Em uma análise mais detalhada,
13:11
artefatos se acumulam no momento da compilação.
13:13
Imagens excedem 2 GB carregadas com compiladores,
13:16
headers e ativos de teste por falta de builds multi-estágio.
13:19
Docker ignora ausente a tie notebooks,
13:21
caches e pesos experimentais para as camadas de produção.
13:24
Cada implantação puxa gigabytes pela rede.
13:27
Escale isso entre o pulso de nós e o code start vira regra.
13:30
Não exceção.
13:32
As evidências não são misteriosas.
13:33
O histórico do Docker conta a história em camadas.
13:35
O tempo de execução revela o segundo nível de erosão.
13:38
Sem flags de GPU explícitas no Docker
13:40
ou configuração de plugin de dispositivo no Kubernetes,
13:43
o processo não vê dispositivos dev NVIDIA.
13:47
Má configurações no kit de ferramentas de contêiner NVIDIA
13:49
ocultam a libicuda.
13:51
Portanto, o provedor de execução carrega com restrições
13:53
ou nem encarrega.
13:55
O MIG não é aplicado,
13:56
então as cargas de trabalho brigam por fatias de memória
13:58
e criam um desperdício que os agendadores não entendem.
14:00
Os logs permanecem educados enquanto o desmaias vai.
14:02
O comportamento de memória é o terceiro nível.
14:04
Por padrão, a arena de memória acuda do NNX Runtime
14:06
cacheia locações agressivamente.
14:08
Sob concorrência, isso parece estabilidade.
14:10
Até que a arena reserve demais e prive novas requisições.
14:14
Memória pinada não está definida,
14:15
então transferências host-dispositivo
14:17
ocorrem via buffers pagináveis,
14:18
tornando o PCI um gargalo.
14:20
A E barra Cs não está vinculada ao dispositivo,
14:22
então tensores saltam entre CPU e GPU,
14:24
criando taxas de latência invisíveis.
14:26
O comportamento da cauda piora primeiro,
14:27
depois é o mesmo caminho.
14:28
É assim que o conjunto sintoma se parece na prática.
14:31
O throughput efetivo atrasa,
14:32
apesar de uma utilização moderada da GPU.
14:34
A latência sob carga leve é aceitável,
14:36
mas o P9 V5 oscila sob concorrência
14:37
e depois dispara imprevisivelmente.
14:40
O MQs ocasionais resetam réplicas no pico de tráfego,
14:42
criando um efeito manada.
14:44
Inicializações em cascata,
14:45
autoscares instáveis e filas acumuladas.
14:47
Operadores perseguem a causa errada,
14:48
acreditando que o modelo é pesado,
14:50
enquanto as políticas dos containers causam colapso.
14:51
Pense na higiene com o containers
14:53
como uma manipulação de videnda.
14:54
Builds multi-estágio removem impressões digitais.
14:56
Compiladores e ferramentas de desenvolvimento
14:57
nunca entram no tempo de execução.
14:59
Uma imagem em base de Strolless ou Slim
15:00
reduz a superfície e diminui o tempo de pulo.
15:03
Auditorias com Docker Slim ou Dive
15:04
confirmam que sobreviveu ao build.
15:06
Um Docker ignora e evita volume acidental.
15:09
O resultado é uma limpeza forense.
15:10
O que roda é apenas o que deveria rodar.
15:13
A infraestrutura de GPU precisa de declarações explícitas.
15:15
No Docker, declare GPUs como
15:17
All ou a fatia exata do MIG.
15:19
No Kubernetes, solicite recursos de GPU.
15:21
O NVID garanta que o plugin de dispositivo
15:23
corresponda à sua versão de driver.
15:25
Na inicialização, verifique a presença do dispositivo
15:27
e a compatibilidade do NVID.
15:28
NVID, SME e configuração de LD
15:30
não são decorativos, são verificações de admissão.
15:32
Se algo estiver faltando ou incompatível,
15:33
registre como violação e encerre.
15:35
Então ajuste o NX Runtime e o TensoRT com propósito.
15:38
Bloqueie a ordem do provedor de execução
15:39
apenas para caminhos de GPU em produção.
15:42
Considere desativar ou reajustar
15:43
a arena de memória acuda
15:44
quando ela acumular além do seu conjunto de trabalho.
15:47
Limite o crescimento.
15:48
Defina a pré-alocação para limites previsíveis.
15:49
Habilite o FP16 por padrão
15:52
quando as diretrizes de precisão permitirem.
15:54
Condicione o NT8 a um teste de precisão.
15:57
Vincule a E barra S a memória do dispositivo
15:59
para que os inputs cheguem onde reside o processamento
16:01
e escolhe streams deliberadamente
16:02
para evitar o bloqueio de cabeça de fila.
16:04
Garanta consistência com dois filtros,
16:05
integridade e desempenho.
16:10
Provedores carregados,
16:11
kernels fundidos presentes,
16:12
núcleos de tensores reconhecidos,
16:14
e barra S vinculado.
16:14
Desempenhe um conjunto base de prompts
16:17
que roda pré-aquecido na inicialização
16:18
com uma janela de latência e um piso de utilização.
16:21
Se o container não atinge ambos,
16:22
ele não é admitido no serviço.
16:24
Anexe orçamentos de tamanho de pool a CI
16:26
para que imagens que cedam os limites falhem no build.
16:28
Mantenha um diff do conteúdo das imagens por digest
16:30
para que rollbacks restaurem o código e a higiene.
16:33
As evidências sugerem que containers
16:35
não apenas implantam softwares
16:36
que codificam o comportamento sob estresse.
16:38
Quando são ruidosos, pesados ou vagos
16:40
sobre a GPU,
16:41
transformam a aceleração em cerimônia.
16:42
Quando são enxutos, espícios e assertivos
16:44
preservam o caminho rápido pelo qual você pagou.
16:46
Neste ambiente, nada é acidental.
16:48
Container ou ajuda a GPU a realizar seu trabalho ou atrapalha.
16:52
Laboratório forense, métricas que condenam.
16:54
Latência, vazão, utilização.
16:56
Evidências superam opiniões.
16:57
Então fixamos o conjunto de prompts,
16:59
travamos as sítios, executamos o pré-aquecido.
17:01
Mesmos schedulers,
17:02
mesmos passos,
17:03
20 para 512,
17:04
expandidos para 50,
17:06
para 1024,
17:07
para 1024,
17:07
para expor a tensão.
17:10
A concorrência é mantida em 16
17:11
com uma varredura TD2.
17:13
A mãe do lote começa aumentando cuidadosamente
17:15
até que os limites da verança se manifestem.
17:16
Sem extrapolação,
17:17
sem desculpas,
17:18
apenas relógios e contadores.
17:19
A latência testemunha primeiro.
17:21
No estado degradado,
17:22
o fallback de CPU,
17:23
o caminho de atenção genérico P50,
17:25
em 512 por 512,
17:26
estica para dois dígitos.
17:28
P95,
17:29
conta beida da história.
17:30
Ele varia de 20 a 40 segundos
17:32
de forma imprevisível,
17:33
porque filas compõem
17:33
pequenas ineficiências.
17:36
Em 1024 por 1024,
17:37
com 50 passos,
17:38
o P95 se torna
17:39
uma violação logo na chegada.
17:41
Após a remediação,
17:41
com o GPU EP travado,
17:43
a tensão fundida ativa
17:44
e a RSS vinculada ao dispositivo,
17:46
o P50 retorna um dígito baixo
17:47
e o P95 comprime-se
17:49
dentro do orçamento.
17:51
O intervalo encolhe,
17:51
o sistema se torna previsível.
17:53
A vazão corrobora.
17:55
Com concorrência 16,
17:56
o caminho degradado
17:56
resulta em gotejamento.
17:57
Imagens por minuto mal
17:59
aumentam com réplicas,
18:00
pois cada instância
18:01
trava a si mesmo.
18:02
Escalar para 32
18:03
multiplica com tensão.
18:04
Não a saída.
18:05
Pós-correção,
18:06
a relação se estabiliza.
18:07
Imagens por minuto
18:08
sobem de forma quase linear
18:09
até que o ciclo de trabalho
18:10
dos núcleos tensores
18:11
Satur ou Averan
18:11
limite o lote.
18:13
A diferença na inclinação
18:14
é a condenação.
18:15
O trabalho realmente cruza
18:16
a linha de chegada
18:16
mais rápida,
18:17
não apenas mais alta.
18:18
A utilização encerra o caso.
18:19
Antes,
18:20
o ciclo de trabalho da GPU
18:21
oscilava entre 0% e 50%,
18:22
com longos vales planos.
18:24
Os contadores PCE
18:25
mostram ruído.
18:26
Vindo de transferências
18:27
pagináveis.
18:29
Depois,
18:30
os ciclos de trabalho
18:31
estabilizam uma faixa
18:32
alta e consistente
18:33
com engajamento visível
18:34
dos núcleos de tensores.
18:36
A CPU retorna
18:37
para a orquestração
18:37
e pré-processamento leve.
18:39
Os picos de PCI
18:40
diminuem
18:40
porque a memória é fixada
18:41
e a vinculação de EBR-CS
18:42
eliminaram o tráfego desnecessário.
18:44
Nada mais explica
18:45
essa mudança
18:45
a não ser uma aceleração real.
18:47
Adicionamos uma
18:47
verificação distracial.
18:48
Em 512 por 512 com 20 passos,
18:50
o caminho otimizado
18:51
sustenta a concorrência
18:52
16 sem picos residuais.
18:54
Ao forçar para 32,
18:55
o sistema degrada
18:55
de forma gradual.
18:56
O P95 expõe
18:57
de forma previsível,
18:58
não calótica.
19:00
Em 1024 por 1024
19:01
com 50 passos,
19:02
a diferença é amplificada.
19:04
O caminho não otimizado
19:05
cede com tempos limites.
19:07
O caminho endurecido
19:07
mantém um P50 utilizável
19:09
e um P95 aceitável
19:10
com lote 1-2
19:11
até atingir os limites
19:12
da verã.
19:13
É aqui que arenas
19:13
e fluxos importam.
19:15
Após o ajuste,
19:15
o bloqueio de início
19:16
de fila recua.
19:17
O ângulo de custo
19:18
é aritmética simples.
19:19
Solicitações por hora
19:20
de GPU
19:20
sobem de 2 a 5 vezes
19:21
quando a tensão fundida
19:22
é FP-16
19:23
e a vinculação
19:23
de FP-16
19:24
são verificadas.
19:26
O custo efetivo
19:26
por mil imagens
19:27
cai consequentemente.
19:29
As penalidades de inicialização
19:30
a frio diminuem
19:30
porque as imagens são leves
19:31
e os motores são pré-compilados.
19:33
Nós paramos de pagar
19:33
o custo de compilação
19:34
no primeiro toque.
19:35
O registro concorda
19:36
com os logs.
19:37
A verificação evita
19:38
execuções por sólidas.
19:39
Em um segundo pool de nós
19:40
com uma versão menor
19:40
de driver diferente,
19:42
a imagem endurecida
19:43
se recusa a iniciar
19:44
em uma incompatível
19:44
por design.
19:46
Assim, os resultados
19:47
são comparáveis,
19:48
não confundidos.
19:49
Verifique cruzadamente
19:50
o snapshot de capacidade.
19:51
Mesma ordem de provedores,
19:52
mesmo tenso RT,
19:53
mesmo as assertões de care.
19:55
Execute novamente
19:55
o conjunto de promptos
19:56
e recaptura as distribuições.
19:58
Quando os histogramas
19:58
se sobrepõem,
19:59
a confiança aumenta.
20:00
Quando não há diferença
20:01
de capacidade,
20:02
explica o porquê.
20:03
No final,
20:03
os números no argumento,
20:04
eles condenam.
20:05
A latência comprime,
20:06
o rendimento escala,
20:07
a utilização estabiliza.
20:09
A patologia não é hipotética.
20:10
É mensurável
20:11
e depois deixa impressões digitais
20:13
em cada gráfico.
20:13
O protocolo de correção.
20:16
Uma lista de verificação
20:17
de endurecimento repetível.
20:18
Controle de admissão
20:19
vem primeiro.
20:19
Recuse iniciar
20:21
se os provedores de execução
20:22
tenso RT ou CUDA
20:23
não estiverem presentes.
20:24
Enumere provedores,
20:25
verifique a contagem
20:26
de dispositivos,
20:27
imprime o snapshot
20:27
de capacidade,
20:28
QDN,
20:28
FP16,
20:29
espaço de trabalho
20:30
NT8.
20:31
Se algo estiver faltando,
20:32
sai com o código diferente.
20:33
A disponibilidade
20:34
segue a integridade.
20:35
A fixação de versões
20:36
é espiandosa.
20:37
Mantenha uma única matriz,
20:38
ramificação do driver,
20:39
CUDA menor para CUDA,
20:40
DNN,
20:40
hash build do Anishka's runtime
20:41
e tenso RT.
20:42
Construa imagens de inferência
20:44
com dessa matriz.
20:45
Oture os nós
20:45
para corresponder.
20:46
Condicione a admissão
20:47
e igualdade.
20:49
Motores tenso RT
20:49
pré-construídos
20:50
por modelo e resolução.
20:51
Planos são artefatos,
20:52
não suposições
20:53
em tempo de execução.
20:54
A higiene de containers
20:55
preserva a verdade.
20:56
Use construções
20:56
de múltiplos estágios.
20:58
Mantenha um runtime
20:58
de showless ou leve.
21:00
Inclua um docker
21:00
e ignore rigoroso.
21:01
Verifique um histórico
21:02
do docker
21:03
e uma auditoria de julgamento.
21:04
Defina orçamento
21:05
de tamanho de pulmuciei.
21:06
Fale imagens que incham.
21:07
Assine imagens
21:08
e compare conteúdos
21:09
por digest.
21:10
Configure a GPU primeiro,
21:11
trave a ordem IP
21:12
para a tenso RT CUDA
21:13
e desative o provedor
21:14
de CPU em produção.
21:14
Verifique a presença
21:17
de dev NVIDIA
21:17
e a versão do NVIDIA
21:18
contene a Toolkit.
21:20
Solicite a GPU
21:21
em NVIDIA.com
21:21
explicitamente
21:22
ou misture licenças
21:23
e verifique na inicialização.
21:24
Ajuste o runtime.
21:25
Habilite a FP16
21:26
por padrão.
21:28
Limite NT8
21:28
com verificações de precisão.
21:30
Vincule a I.O.
21:31
diretamente
21:32
à memória do dispositivo.
21:33
Habilite a memória paginada
21:34
e escolhe streams
21:35
para evitar bloqueio
21:35
head offline.
21:37
Reajuste ou desative
21:38
a área na RT CUDA
21:39
quando ela parar
21:40
além do conjunto de trabalho.
21:41
Define a celiose
21:42
de desempenho
21:43
como código
21:43
autoteste
21:44
de inicialização
21:44
com janela de latência
21:45
de prontos determinísticos
21:46
e piso de utilização.
21:47
Fale em backlogs crescentes.
21:49
Adicione observabilidade,
21:50
métricas de GPU
21:51
por requisição,
21:52
alertas de caminho degradado,
21:53
prompt scannery,
21:54
baselines comparáveis.
21:56
Implemente blue bar green
21:57
com gates de desempenho
21:58
e reversão automática
21:59
em caso de violação.
22:00
Com protocolo aplicado,
22:02
aceleração é comprovável,
22:03
não presumido.
22:03
Alisson é clean.
22:06
Fallback silencioso de CPU,
22:08
desvio de versão
22:08
e inchaço de container
22:09
não são bugs.
22:10
São padrões de falha
22:11
previsíveis que você pode bloquear.
22:12
Execute o protocolo,
22:13
instrumente a utilização da GPU,
22:15
recuse caminhos degradados,
22:16
fiche versões
22:16
e trait engines
22:17
como artefatos.
22:18
Se você quer um mergulho
22:19
mais profundo
22:19
no comportamento de memória
22:20
doar em ex-run time
22:21
e tenso RT
22:22
e quando desativar arenas,
22:23
assista ao próximo caso
22:24
desta série
22:25
e inscreva-se
22:25
para as notas de laboratório.
22:26
e inscreva-se