Seu vizinho na GPU consegue ouvir seu modelo — Branislav Brzak, Stealthium

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Your GPU Neighbor Can Hear Your Model — Branislav Brzak, Stealthium · Canal: AI Engineer · 13:06 · Assistir no YouTube

Tópicos: Infraestrutura e hardware de IA, Modelos locais e open source, Privacidade e proteção de dados, Segurança de IA

Resumo

Branislav Brzak, da Stealthium, apresenta ataques de canal lateral que permitem inferir informações sobre modelos de IA em servidores com GPUs compartilhadas, apenas medindo tempos de execução. Em GPUs H100 com MIG, os pesquisadores identificaram modelos, estimaram velocidade e profundidade das camadas e, em certas condições, inferiram o tipo de tarefa — sem acessar os dados ou prompts. O ataque também pode funcionar entre GPUs diferentes conectadas por NVLink, embora com menos precisão. A apresentação termina com recomendações de posicionamento, atenção às compensações de isolamento e monitoramento de workloads suspeitos.

Pontos-chave

• Um inquilino malicioso pode medir seus próprios acessos à memória e inferir atividade de outro inquilino sem permissões especiais nem acesso à memória da vítima.
• Em GPUs H100 com MIG, o ataque identificou a arquitetura e a profundidade do modelo com até 97% de precisão e estimou a velocidade de geração com até 99,3%.
• As barreiras de memória afetam as partições L2 da GPU, e o tempo de execução não fica totalmente isolado entre instâncias MIG.
• A contagem de camadas oferece uma assinatura mais precisa que a velocidade isolada e pode distinguir modelos com taxas de geração semelhantes.
• Com speculative decoding ativado, variações de tempo podem revelar categorias do texto gerado, como prosa, código, JSON ou conteúdo de recuperação.
• Em servidores com NVLink, uma GPU diferente pode observar efeitos de temporização; o método teve 79,2% de precisão no teste apresentado, mas não recuperou a assinatura de camadas.
• A equipe relata que sua ferramenta detectou o padrão por meio de lançamentos repetidos de um kernel sobre a mesma pequena região de memória.
• As recomendações incluem não colocar inquilinos não confiáveis ao lado de modelos sensíveis em MIG e monitorar workloads suspeitos na infraestrutura da GPU.

Capítulos

Início	Capítulo	Resumo
00:01	O risco de vazamento por temporização	A apresentação descreve o canal lateral em GPUs compartilhadas e explica que medições de tempo podem revelar características de um LLM sem acesso aos dados.
03:41	Inferência de velocidade e profundidade do modelo	Os testes em H100 mostram como padrões de latência permitem estimar a velocidade de geração e identificar camadas e modelos.
06:52	Identificação de modelos e tipos de tarefa	A apresentação compara modelos relacionados e mostra que, com speculative decoding ativado, o canal pode indicar categorias do conteúdo gerado.
08:58	Ataque entre GPUs via NVLink	Os pesquisadores demonstram que uma GPU diferente no mesmo servidor pode inferir informações sobre a atividade da vítima, embora sem recuperar a assinatura de camadas.
11:03	Detecção e recomendações de mitigação	A equipe relata a detecção do padrão de ataque e recomenda cautela no posicionamento de inquilinos e monitoramento ativo da infraestrutura.

Citações

Alguém ao seu lado pode descobrir coisas sobre o modelo que você está executando. — 00:01

Para o atacante, esses três microssegundos são tudo de que precisa. — 03:41

Uma relação sinal-ruído pior não significa segurança. — 11:03

Não coloque inquilinos não confiáveis em instâncias MIG ao lado de modelos sensíveis. — 12:03

Conceitos e entidades

• Branislav Brzak (pessoa): Pesquisador de segurança cibernética da Stealthium que apresenta os ataques de canal lateral contra workloads de LLM em GPUs compartilhadas.
• Stealthium (empresa): Empresa que atua na segurança e observabilidade dos ambientes em que sistemas de IA são executados.
• Multi-Instance GPU (MIG) (conceito): Recurso da NVIDIA que divide uma GPU em instâncias isoladas, embora, segundo a apresentação, não isole completamente os efeitos de temporização.
• NVLink (conceito): Interconexão entre GPUs que pode permitir observar efeitos de temporização de workloads executados em outra GPU do mesmo servidor.
• H100 (modelo): GPU da NVIDIA usada nos testes descritos na apresentação.
• Qwen (modelo): Família de modelos citada nos testes de inferência de arquitetura, profundidade e velocidade.
• Llama 3 (modelo): Família de modelos da Meta usada como exemplo de modelos com velocidades semelhantes, mas profundidades que podem ser distinguidas pelo canal lateral.
• speculative decoding (conceito): Técnica de geração cuja aceitação de tokens especulativos pode alterar os tempos de execução e expor sinais sobre o tipo de texto gerado.
• Delty (ferramenta): Produto mencionado na apresentação como capaz de monitorar lançamentos de kernels e sinalizar workloads suspeitos.

Tradução completa (pt-BR)

00:01 Olá, pessoal. Esta palestra é sobre o perigo de informações sobre seu LLM vazarem por meio de GPUs compartilhadas. Se você executa um modelo na nuvem, em uma GPU compartilhada com outros clientes, alguém ao seu lado pode descobrir coisas sobre ele. Essa pessoa pode identificar qual modelo você está executando, a velocidade com que ele responde e até o tipo de trabalho que está fazendo naquele momento. Tudo isso sem tocar nos seus dados, apenas observando os tempos. É disso que trata esta palestra: o que outros clientes no mesmo hardware podem descobrir sobre seu LLM apenas pelos tempos e o que você pode fazer a respeito. Para começar, sou Brian Sabbrzac, um pesquisador de segurança cibernética

00:32 empregado na Stealthium. Na Stealthium, somos especializados em proteger e fornecer observabilidade dos ambientes em que sistemas de IA são executados. Meu foco é pesquisa de segurança de baixo nível relacionada a GPUs. É disso que esta palestra trata. Quando você compartilha uma GPU entre clientes, espera isolamento total, mas o isolamento fornecido pode não ser suficiente. Neste ataque, o invasor nem precisa de permissões especiais, como acesso root. Também não precisa de nenhum exploit tradicional. A única coisa que faz é medir o tempo

01:05 das partes do hardware que ainda são compartilhadas entre os clientes. Este é um vídeo de demonstração de como são os painéis das vítimas e dos invasores. À esquerda, temos o modelo Qwen fazendo inferência. À direita, o invasor usa um canal lateral para o qual o Qwen vaza informações enquanto está em execução. Com isso, ele determina exatamente qual é o modelo e que tipo de texto está produzindo naquele momento. Essas são apenas as principais alegações, mas não contam toda a história. Conseguimos identificar a arquitetura e a profundidade do modelo

01:36 com 97% de precisão. Conseguimos identificar a velocidade de geração de código com 99,3% de precisão. Conseguimos identificar quando ocorrem os períodos de atividade intensa, sua duração, a contagem de tokens e o tamanho das respostas. Também conseguimos identificar o tipo de trabalho que está sendo feito: código, prosa, JSON ou recuperação. Mas não conseguimos identificar os prompts, as respostas ou o conteúdo em si, apenas os tempos. E tudo isso em H100s reais atendendo LLMs reais. Se você usa hardware Nvidia, o isolamento da GPU

02:07 é obtido usando Multi-Instance GPU, ou MIG, para abreviar. Cada fatia isolada de MIG tem suas próprias unidades físicas de computação e VRAM dedicada, que fornece isolamento de hardware para esses componentes. No nosso exemplo, o LLM que atendemos é executado em uma fatia com três unidades de computação e 40 GB de VRAM. O ataque é executado usando apenas uma unidade de computação e 10 GB de VRAM. O que fica isolado são as unidades de computação, a capacidade de memória, as cotas de largura de banda e as taxas de falha.

02:37 O cache L2 também é particionado por instância. Não há expulsão entre instâncias. Portanto, nesse sentido, ele não é compartilhado. Os vazamentos de fato vêm de barreiras de memória, ou barreiras, que abrangem toda a GPU. A barreira de uma instância ainda afeta todas as partições L2 da placa. O tempo é a única coisa que não fica isolada. Assim, quando um cliente está ocupado, os outros clientes ficam um pouco mais lentos. O ponto principal é que uma barreira de memória que abrange toda a GPU tem efeito em cada partição L2

03:09 da placa. O próximo slide constrói todo o ataque com base nesse único fato. O vetor de ataque é que o invasor só lê a própria memória. Ele mede apenas o tempo das próprias leituras. Nunca toca na memória da vítima. Há três etapas. A partir do próprio buffer pequeno, mede o tempo de carregamento e repete isso a cada cinco microssegundos. Essa primitiva e o próprio vazamento por barreira de memória do MIG não são uma descoberta nossa. O crédito vai para os pesquisadores por trás de “Behind Bars”, da Using Security. Um grande agradecimento pelo trabalho deles.

03:41 Agora tente observar a olho nu as diferenças de tempo, comparando seu cliente ocioso com quando está atendendo um LLM. Você nem conseguiria distingui-las. A latência mediana é apenas três microssegundos maior. Para o invasor, porém, esses três microssegundos são tudo de que ele precisa. Isso basta para obter todas as informações de que já falamos. O Qwen com 8 bilhões de parâmetros está sendo executado na fatia da vítima durante todo este exemplo. Todos os dados capturados foram obtidos

04:12 de um modelo em execução ao vivo. Na parte superior, está a atividade da GPU ao longo do tempo, com uma rajada por token. Abaixo, está o espectro de frequência do traço de latência do invasor. Há uma frequência fundamental de 81 Hz, que corresponde apenas aos tokens por segundo, além de harmônicos, já que cada token é uma combinação de frequências distintas, e não uma única frequência pura. Este é um traço real de um token no domínio do tempo. O token apresenta um total de 39 picos. Os picos verdes correspondem às invocações das camadas, enquanto os laranjas

04:44 são etapas adicionais de processamento entre camadas. Em um slide posterior, vamos demonstrar como determinamos a contagem exata de camadas mesmo com esses picos extras presentes. Aqui, observamos a própria velocidade de decodificação. Apenas medindo o tempo, descobrimos a taxa de tokens por segundo. Portanto, um invasor consegue recuperar a velocidade com precisão. Mas a velocidade, por si só, não é uma impressão digital inequívoca. O Qwen com 8 bilhões de parâmetros e o Llama com 38 bilhões diferem apenas 1,6% na taxa de tokens. Então,

05:15 se você se baseasse apenas na velocidade, pensaria que são o mesmo modelo. Isso restringe as possibilidades, mas não permite identificá-lo com certeza. Precisamos de algo mais preciso: a contagem de camadas. É disso que tratam os próximos slides. Usamos a mesma técnica de dobrar e calcular a média de antes. Desta vez, executamos o processo uma vez por modelo, em vez de uma vez por token. O resultado é uma contagem que fica quase exatamente em um número inteiro. A distância média até um número inteiro, em 22 traços, é de apenas 0,028. De zero a oito. Esse é o

05:46 indício. Se isso fosse apenas um artefato fixo do hardware dividido por diferentes taxas de tokens, esperaríamos frações, não números inteiros. Cada contagem corresponde à contagem de camadas do modelo mais uma a três camadas adicionais. Cada modelo mantém sua própria impressão digital do sinal, uma combinação de ritmo e estrutura harmônica. Para deixar claro, este não é um classificador de machine learning treinado. Não há conjunto de treinamento, rótulos nem configuração. São menos de 30 linhas de código. O método verifica cada

06:17 profundidade candidata, de 16 a 48. Ele mede o quanto a assinatura esperada para aquela profundidade aparece no traço real. Depois, escolhe a melhor opção. Para o Qwen com 8 bilhões de parâmetros, as 36 camadas se destacam com uma vantagem de quatro vezes sobre a próxima candidata. Como este é um teste de melhor ajuste, e não uma tabela de consulta, ele também funciona com modelos que nunca viu antes. Isso inclui modelos proprietários e ainda não lançados, já que não é preciso que o método tenha visto esses modelos antes.

06:52 E isso funciona surpreendentemente bem. O classificador de ajuste de camadas também indica o nível de confiança. Em nossos testes, apenas duas das respostas de menor confiança acabaram estando erradas. Esse mesmo método também identifica fine-tunes e destilações que compartilham o mesmo modelo-base. Isso ocorre porque a arquitetura e a contagem de camadas permanecem inalteradas. Tomemos como exemplo três modelos relacionados. O Llama 3 8B, da Meta, tem 32 camadas. O Llama 3.1 8B

07:24 — também da Meta — usa a mesma estrutura de 32 camadas, com pequenas melhorias, e o R1, que ainda é baseado no Llama 8B, da DeepSeek, traz melhorias sobre ele. A temporização por camada resulta em diferenças de latência mediana de apenas 1,6 microssegundo entre eles. O restante do sinal parece igual. Apesar disso, nosso classificador ainda consegue distingui-los. Agora fazemos uma pergunta mais profunda usando o mesmo canal. Não qual é o modelo, mas o que ele está

07:55 fazendo neste momento? Observamos quatro tipos de carga de trabalho: prosa, código, JSON e recuperação. Classificamos a carga de trabalho a cada meio segundo, com base nos últimos cinco segundos de medições de tempo. De 40 janelas de meio segundo, 31 foram classificadas corretamente, e quatro respostas completas foram identificadas corretamente por votação majoritária. Este é o mesmo classificador do vídeo anterior; os erros também estão incluídos. Vale mencionar uma condição: isso foi medido com decodificação especulativa ativada. Essa é uma opção habilitada pelo usuário no VLM, não

08:26 a configuração padrão. Este é o mecanismo: a previsibilidade do texto altera quantos tokens provisórios são aceitos em cada etapa. Isso altera o tempo da etapa, e é esse sinal que estamos detectando. Testamos 11 configurações, densas e de mistura de especialistas, em BF16 e FP8. A mesma figura apareceu todas as vezes, mas com intensidades muito diferentes. Uma diferença de 70,2% no GPT-OSS 20B, contra 0,9% no GLM 4.9B. Em 10 de 11 casos, a prosa foi a mais rápida

08:58 quando o acaso, sozinho, só daria uma chance em quatro. Portanto, suponha que o invasor já saiba qual é o modelo, como nos slides anteriores, e que a decodificação especulativa esteja ativada. Ele também consegue identificar que tipo de texto está sendo gerado. Agora, vamos retirar completamente o chip da equação. O MLG exige que o invasor esteja no mesmo chip físico. Este ataque, não. A configuração aqui é um servidor com oito H100s, conectado por uma malha de switches MV. A vítima executa dezenas de tarefas paralelas em todas as GPUs

09:30 Zero e um. O atacante só precisa de qualquer outra GPU no mesmo servidor, a GPU 2 neste caso. O acesso entre pares por NVSwitch é um recurso previsto. É assim que trabalhos com várias GPUs normalmente funcionam, não um bug sendo explorado. O paralelismo de tensores MLG também não pode coexistir no mesmo dispositivo. Então, trata-se de uma população diferente de implantações, não apenas do mesmo ataque repetido. A sondagem é executada na GPU 2. Ela aponta para a memória

10:00 que, na verdade, está na GPU 0, atravessando o NVLink pelo caminho. Uma passagem ociosa leva cerca de 890 nanossegundos. Quando a vítima começa a trabalhar, isso sobe para 300 microssegundos. Estas são três capturas de meio segundo, e dá para contar os tokens a olho. O que perdemos em comparação com MLG é que o sinal das camadas fica abaixo do ruído a essa distância. Então, pelo NVLink, as

10:32 impressões digitais que nos restam são principalmente o ritmo, não a contagem de camadas. Aqui, testamos os cinco modelos em uma configuração de serviço idêntica. Só o próprio modelo revela qual deles é. Este método alcança 79,2% de precisão. Agora, ele falha exatamente onde seria de esperar que o ritmo falhasse. Llama 3.5 8 billion e R1 ainda são ambos modelos de 8 bilhões de parâmetros, com apenas três hertz de diferença no código, então se confundem, enquanto as contagens de camadas do MIG

11:03 os separariam facilmente. A conclusão é que o NVLink é pior que o MIG, pois perde o sinal das camadas. Mas uma relação sinal-ruído pior não é o mesmo que segurança. 79% contra uma linha de base de 20% ainda são impressões digitais reais, não ruído. Primeiro, uma boa notícia. Nosso próprio produto no trabalho identificou o ataque imediatamente, sem configuração adicional. O Delty monitora cada lançamento de kernel em todas as GPUs, analisa

11:33 cargas de trabalho suspeitas e as encaminha por um pipeline completo de alertas, algo que nem todos os fornecedores conseguem fazer. Eis o que fez esse caso se destacar. Um único kernel foi relançado cerca de 3.000 vezes, acessando repetidamente exatamente os mesmos 40 kilobytes de memória, em vez de avançar para novos dados. Apenas um kilobyte de dados foi enviado de volta à CPU durante todo esse tempo, porque o próprio tempo era a carga útil, não a saída. Em termos reais, isso levou menos de 600

12:03 milissegundos do início ao fim, com menos de 50 tokens na resposta. Nós o identificamos antes que a resposta estivesse sequer escrita pela metade. Então, três conclusões. Primeiro, a localização é algo que os operadores realmente controlam. Portanto, não coloquem tenants não confiáveis ao lado de modelos sensíveis no MIG. Segundo, conheçam a contrapartida. O MIG impede a comunicação entre pares, o que significa que não há paralelismo de tensores no MIG. O particionamento pelo NVLink

12:35 revela informações apenas pelo tempo, em vez de pelas contagens de camadas. Terceiro, monitorem a própria GPU C. Garantam que a infraestrutura do host esteja verificando ativamente se não há cargas de trabalho maliciosas em execução no hardware. É exatamente isso que o Seltium faz, detectando essas sondagens diretamente pelo comportamento do Chrome. Compartilhar uma GPU significa que apenas o tempo pode revelar o modelo, a velocidade e a carga de trabalho. Isso também vale através do NVLink, sem precisar de nenhuma exploração

13:06 de vulnerabilidade. O Deltium detecta isso em tempo real. A maioria das organizações ainda não tem esse tipo de visibilidade. Agradeço novamente aos pesquisadores do Behind Bars. Esta palestra inteira se baseia no trabalho deles. Obrigado a todos por assistir.

Transcrição original

[00:01] Hello everyone. This talk is about the danger of your LLMZ information leaking through shared GPU hardware. If you’re running a model in the cloud on a GPU you share with other tenants, someone next to you can learn things about it. They can tell what model you’re running, how fast it’s responding, and even what kind of work is doing right now. All without touching your data, just by watching timing. That’s what this sock covers. What a code tenants on the same hardware can learn about your LLM from timing alone and what you can do about it. To start, I’m Brian Sabbrzac, a cyber

[00:32] security researcher employed at Stealthium. At Stealthium, we specialize in securing and providing observability into the environments AI systems run on. My area of focus is low-level GPU related security research. That’s something this talk covers. When you share a GPU between tenants, you would expect full isolation, but the isolation provided may not prove to be sufficient. In the case of this attack, the attacker doesn’t even need any special permissions like root access. It doesn’t need any traditional exploit either. The only thing it does is time

[01:05] the parts of the hardware that still shared among tenants. This is a demonstration video of what the victims and the attackers dashboards look like. On the left, we have quentry model doing. On the right, the attacker uses a side channel that quentry leaks into as it’s running. From that it determines exactly what model it is and what kind of text is producing right now. These are just the headline claims but not the whole story. We can tell which model it is architecture and depth

[01:36] within 97% accuracy. We can tell how fast is the coding within 99.3% accuracy. We can tell when and how much the busy periods token counts and the answer length. What we can tell what kind of work it’s doing, codes, J pros, JSON or retrieval. What we cannot tell though are the actual prompts, answers or contents, just timing. And all of these on real H100s serving real LLMs. If you’re using Nvidia hardware, GPU

[02:07] isolation is achieved using multi instant GPU or MIG for short. Each isolated MAG slice has its own physical compute units and dedicated VRM that provides hardware isolation on those parts. In our example, the LLM we’re serving runs on a slice with three compute units and 40 GB of VM. The attack runs on just one compute units and 10 GB of VM. What’s isolated are compute units, memory capacity, bandwidth quotas, and

[02:37] false errors. The L2 cache is partitioned per instance too. There’s no cross instance eviction. So it’s not shared in that sense. The actual leaks are memory barriers or members which are GPU wide. One instances barrier still touches every L2 partition on the card. Timing is the one thing that isn’t isolated. So when one tenant is busy, the other tenants owns get slightly slower. The key point is the a GPUwide memory barrier takes effect in every L2

[03:09] partition on the card. The next slide builds the whole attack on that one fact. The vector is that the attacker only ever reads its own memory. It only times its own reads. It never touches the victim’s memory. There are three steps. All from its own small buffer, time the load and repeat every five microsconds. This primitive and the MIG member leak itself isn’t our discovery. Credit goes to the researchers behind behind bars at using security. A big thanks for their

[03:41] work. Now try looking at the timing differences with the naked eye comparing your tenant idle versus serving an LLM. You wouldn’t even be able to discern them. The median latency is only three microsconds higher. To the attacker though, those three microsconds are all it needs. That’s enough to gather all the information we already talked about. Quentry with 8 billion parameters is running on the victim slice throughout this one. All captured data was taken

[04:12] from a live model. At the top is GPU activity over time, one burst per token. Below is the frequency spectrum of the attackers on latency trace. There is a fundamental at 81 Hz which is just tokens per second plus harmonics since each token is a mix of distinct frequencies not one clean one. This is a real trace one token in the time domain. The token shows a total of 39 bumps. The bumps with green peaks are the layer invocations while orange ones

[04:44] are additional between layer processing. In a later slide, we will demonstrate how we determine the actual layer counts even with those extra bumps are present. Here we look at the decode speed itself. Just by timing, we found the token ray completely bind. So speed alone is something an attacker can recover accurately. But speed by itself isn’t a clean fingerprints. Quentry 8 billion and llama 38 billion they quote only 1.6% apart in their token rate. So from

[05:15] speed alone, you’d think they’re the same model. It narrows things down, but it doesn’t nail it. We need something sharper. Layer counts. That’s what the next few slides get into. We use the same fold and average stick from before. This time we run it once per model instead of once per token. What comes out is a bit count that lands almost exactly on a whole number. The mean distance from an integer across 22 traces is just 0.028. 0 to8. That’s the

[05:46] tell. If this were just a fixed hardware artifact divided by different token rates, we’d expect factions, not whole numbers. Each count works out to the model’s layer count plus one to true, one to three additional picss. Every model keeps its own signal fingerprints, a mix of tempo and harmonic structure. To be clear, this is not a trained machine learning classifier. There’s no training set, no labels, no configuration. It’s under 30 lines of code. The method checks each

[06:17] candidate’s depth from 16 to 48. It measures how strongly that depth’s expected signature shows up in the real trace. Then it picks whichever of its best for quen 8 billion 36 layers wins clearly by four point times over the next candidate. Because this is a best fit test, not a lookup table. It also works to models it never seen before. That includes proprietary on unreleased ones. since there’s nothing it needs to have seen in the first place.

[06:52] And this works surprisingly well. The layer fit classifier also outputs the confidence level. Across our testing, only two least confident answers ended up being wrong ones. This same method also picks up fine tunes and distillations that that share the same base model. That’s because the architecture and layer count carry over unchanged. Take three related models as an example. Llama 38 billion from meta has 32 layers. Llama 3.18

[07:24] billion also from meta uses that same 32 layer backbone with minor upgrades and R1 is still llama 8 billion from deepseek is an improvements on top of that. The per layer timing comes out to only 1.6 600 seconds median latency shifts of each other. The rest of the signal looks the same. Regardless of this, our classifier is still able to discern between them. Now we ask a deeper question on the same channel. Not which model, but what is

[07:55] doing right now? We look at four workload types. Pros, code, JSON, and retrieval. We give a work that’s on every half second based on the last 5 seconds of timing. out of 40 half second words with 31 rights and four full responses were correctly identified by majority votes. This is the same classifier from the video earlier misses included. One condition is worth stating this was measured with speculative decoding turned on. That’s an optin in VLM, not

[08:26] the default. Here’s the mechanism. How predictable the text is changes how many drafted tokens get accepted at each step. that changes step time and that’s the signal we’re picking up. We tested 11 configurations dense and mixture of experts BF16 and FB8. The same figure page showed up every time just at very different strengths. 70.2% spread on GPT or 20 billion versus 0.9% on GLM 49 billion. 10 out of 11 round pros fastest

[08:58] when the chance alone would only give you one in four. So say the attacker already knows the model from the earlier slides and specular quality happens to be on. It can also tell what kind of text is coming out. Now we take the shade chip out of the picture entirely. MLG needs the attacker on the same physical die. This attack doesn’t. The setup here is an eight times H100 server connected over an MV switch fabric. The victim runs tens of parallel across GPU

[09:30] 0ero and one. The attacker just needs any other GPU in that same server, GPU 2 in this case. Per access over NV switch is a real intended feature. It’s how multi-GPU jobs normally work, not a bug being abused. MLG tensor parallelism also can’t coexist on the same device. So this is really a different population of deployments, not just the same attack repeated. The probe runs on GPU 2. It pointer

[10:00] traases memory that actually is on GPU0 over envelop along the way. An idle hop takes about 890 nconds. Once the victim starts working that climbs up to 300 microsconds. These are three half seconds me captures and you can actually count the tokens by eye. What we lose compared to MLG is the layer bit is below the noise at this distance. So over envelink the

[10:32] fingerprints we we’re left with is mostly tempo not layer counts. Here we test the five models on identical serving setup. Only the model itself gives away which one it is. This method gives 79.2% accuracy. Now it fails exactly where you’d expect the tempo to fail. Llama 3.5 8 billion and R1 is still are both 8 billion models that the code three hertz apart so they blur together where MIG’s

[11:03] layer counts would have separate them easily. The takeaway is that the envel worse than MG’s since it loses the layer bit. But worse signal to noise ratio isn’t the same as safety. 79% against a 20% baseline is still real fingerprints not noise. First, some good news. Our own product at work called the attack straight out of the box. Delty monitors every single kernel launch across every GPU, analyzes

[11:33] suspicious workloads, and runs them through a full alert pipeline, which is something not every vendor can do. Here is what’s made this one stand out. A single kernel relaunched about 3,000 times, hitting the exact same 40 kilobytes of memory over and over instead of moving to new data. only one kilobte of data was sent back to the CPU the entire time because the timing itself was the payload not the output. In real terms that is under 600

[12:03] milliseconds start to finish with fewer than 50 tokens of a reply. We quot it before the response was ever half typed. So three takeaways. First placement is something operators actually control. So do not put an untrusted tenants. MIG slides right next to sensitive model. Second, know the trade-off. MIG rules out peer-to-peer communication, meaning there is no tens of parallelism on MIG. Sharding over envels

[12:35] what leaks to timing alone rather than the layer counts. Third, watch the C GPU itself. Make sure the host infrastructure is actively verifying that no malicious workloads are running on the hardware. That’s exactly what Seltium does by catching these probes straight from the Chrome behavior. Sharing a GPU means timing alone can give away the model, the speed and the workload. That’s true even across envelink without needing any exploit at

[13:06] all. Deltium sees this happen in real time. Most organizations still don’t have that kind of visibility. Thanks again to the researchers of Behind Bars. This whole talk builds upon their work. Thank you all for watching.