Sana da NVIDIA: imagem de 1024 px em 0,4 segundo? Eu testei

Autoria: Prompt Engineer 48 · 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: NVIDIA’s Sana: 1024px Image in 0.4 Seconds? I Tested It · Canal: Prompt Engineer 48 · 08:08 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Ferramentas de desenvolvimento com IA, Geração de conteúdo com IA, Infraestrutura e hardware de IA, Modelos locais e open source

Resumo

O vídeo testa o Sana, modelo de geração de imagens da NVIDIA, comparando o desempenho em um laptop com 8 GB de VRAM e em uma GPU A40 alugada. Na A40, o Sana Sprint gerou uma imagem de 1024 × 1024 em 0,38 segundo; no laptop, o modelo levou cerca de 21 segundos com CPU offload. O apresentador também compara a qualidade das imagens e observa que a renderização de texto continua sendo um ponto fraco. Por fim, apresenta outras versões e ferramentas compatíveis e recomenda opções conforme a quantidade de VRAM disponível.

Pontos-chave

O Sana Sprint 0.6B gerou imagens de 1024 × 1024 em 0,38 segundo na A40, usando dois passos.
No laptop com RTX 4060 e 8 GB de VRAM, o modelo 0.6B levou cerca de 21 a 26 segundos.
Executar o modelo inteiro na GPU do laptop foi mais lento porque o uso de memória excedeu os 8 GB disponíveis.
O Sana 1.6B com 20 passos levou 2,52 segundos na A40 e usou até 10,9 GB de VRAM.
O Sana 1.6B produziu as imagens mais limpas no teste, mas o Sprint foi visualmente parecido em imagens sem texto.
A renderização de texto é uma limitação: o modelo pode errar até mesmo uma palavra curta.
O vídeo menciona versões de 2K, 4K, quantização de 4 bits e ControlNet, mas o apresentador não testou essas opções.
Para placas com 8 GB de VRAM, o apresentador recomenda experimentar a versão de 4 bits, ressalvando que não a testou.

Capítulos

Início	Capítulo	Resumo
00:02	O que o repositório promete e como o Sana funciona	O vídeo apresenta as alegações de velocidade do repositório e explica as técnicas de compressão, atenção linear e destilação usadas pelo Sana.
02:11	Testes no laptop e em uma GPU alugada	O apresentador mede o desempenho no laptop e na A40, comparando tempos de geração, consumo de memória e diferentes tamanhos de modelo.
04:54	Qualidade das imagens e recursos adicionais	A comparação visual destaca os erros na renderização de texto e apresenta versões, recursos e ferramentas compatíveis que não foram todos testados.
07:03	Como repetir o teste e veredito	O vídeo mostra as configurações usadas, recomenda opções conforme a VRAM disponível e conclui com os resultados do benchmark.

Citações

Esta imagem levou 0,38 segundo para ser criada. — 00:02

No Sana Sprint 0.6B, com dois passos, o tempo foi de 0,38 segundo. — 03:51

A diferença não está no modelo; está na memória. — 04:22

Para imagens sem texto, é difícil distinguir o modelo Sprint do modelo de 20 passos só de olhar. — 05:25

O Sana Sprint gera uma imagem de 1024 em menos de meio segundo em uma placa como a A40. — 07:34

Conceitos e entidades

Sana (modelo): Modelo de geração de imagens da NVIDIA testado no vídeo em diferentes tamanhos e configurações.
Sana Sprint (modelo): Versão destilada do Sana que gera imagens em um a quatro passos, em vez dos 20 passos dos modelos regulares.
NVlabs/Sana (repo): Repositório apresentado como fonte do código, da documentação e das versões do Sana.
NVIDIA (empresa): Empresa associada ao desenvolvimento do Sana.
DCAE (conceito): Autoencoder usado pelo Sana para comprimir a imagem em mais intensidade antes da difusão.
Gemma (modelo): Modelo de linguagem usado como encoder de texto no Sana, em vez do T5.
Diffusers (ferramenta): Biblioteca usada no vídeo para carregar e executar as versões do Sana.
RunPod (ferramenta): Serviço usado para alugar uma GPU e executar os testes do Sana.
A40 (ferramenta): GPU alugada para medir o desempenho dos modelos, com 48 GB de VRAM.
ComfyUI (ferramenta): Interface citada como outra opção para executar o Sana, por meio de um nó de modelos adicionais.
Nunchaku (ferramenta): Engine mencionada junto à quantização SVD como opção para executar o modelo com menos de 8 GB de VRAM.
ControlNet (modelo): Versão mencionada que permite guiar a geração de imagens com um esboço ou mapa de bordas.

Tradução completa (pt-BR)

00:02 Esta imagem levou 0,38 segundo para ser gerada. Ela tem 1024 por 1024 pixels, e a placa diz Saana, mais ou menos. Agora, o mesmo modelo, no mesmo tamanho, no meu notebook gamer com 8 GB: cerca de 21 segundos. Então, quem está certo? O repo que diz 0,1 segundo ou o meu notebook? Vale lembrar que tudo o que foi lento neste vídeo rodou no meu próprio sistema, e tudo o que foi rápido rodou em uma GPU alugada que me custou 59 centavos por hora. Vamos testar isso. Este é o repo NVlabs/saana.

00:33 Dá para ver cerca de 9,3 mil estrelas, 745 forks, e a licença à direita é Apache 2.0, então você pode usar o modelo comercialmente. Ele vem da Nvidia e do MIT, e a descrição diz: síntese eficiente de imagens em alta resolução com um transformer de difusão linear. Agora, se você olhar o readme, a alegação aparece logo no topo: geração de texto para imagem de até 4K, 20 vezes menor e 100 vezes mais rápido que Flux 12B. E a versão Sprint diz 0,1 segundo por imagem de 1024 pixels em uma H100. Uma coisa que quero dizer, sinceramente, é que, se você olhar a seção de notícias

01:05 a maior parte do trabalho recente é com vídeo e modelos de mundo: Saana video 2.0, Saana WM, Saana streaming. O modelo de imagem que estou testando hoje é a parte mais antiga do repo, de 2024 e do início de 2025, mas é a parte que a maioria de nós consegue realmente executar. A página de documentação lista as principais técnicas, e há três que importam para a velocidade. Primeiro, o autoencoder. Modelos de imagem normais comprimem uma imagem oito vezes antes de o modelo de difusão processá-la. Saana usa DCAE, que comprime 32 vezes, então uma imagem de 1024 pixels vira 32 por 32 tokens, e não

01:39 128 por 128. Isso significa 16 vezes menos tokens. Segundo, atenção linear. Em um transformer comum, dobrar a quantidade de tokens aumenta aproximadamente quatro vezes o custo da atenção. Saana substitui isso por atenção linear, então o custo cresce em linha reta, e a diferença aumenta quanto maior for a resolução. É por isso que eles podem falar em 4K. Terceiro, o codificador de texto: em vez de T5, eles usam um modelo de linguagem pequeno, somente decodificador, o Gemma, como codificador de texto. É isso que permite que ele siga prompts mais longos. E, depois, o Sprint. O Sprint é destilado. Então, em vez de 20

02:11 etapas, ele gera a imagem em 1 a 4 etapas. No meu teste, usei duas. Aqui estão os modelos no Hugging Face. Vou usar as versões do Diffusers, assim não preciso compilar o repo inteiro. Meu sistema é um notebook com uma RTX 4060, 8 GB de VRAM e 16 GB de RAM. Instalei o Diffusers, carreguei o Stable Diffusion 0.6b, e o primeiro download levou 319 segundos. Ou seja, 5 minutos só para baixar os pesos. Agora, na primeira execução, com o descarregamento para a CPU ativado, ele gerou imagens em 20,6 segundos e 25,9 segundos, e o pico de VRAM foi de 5,3 GB. Então, funciona, mas está longe

02:46 de chegar perto de 0,1 segundo. Talvez o problema seja o descarregamento, pensei. Então, coloquei o modelo inteiro na GPU, e ficou mais lento: de 37 a 41 segundos por imagem. O motivo aparece na tela: o pico de memória foi de 8,8 GB, e minha placa tem oito. Então, o Windows transfere o restante para a memória compartilhada. Esse é o primeiro número realista: o modelo de 0.6b não cabe em uma placa de 8 GB sem ajuda. Depois, tentei o maior, o Stable Diffusion 1.6b, e ele nem chegou a carregar. Recebi um erro de memória ao carregar o transformer porque eu tinha cerca de 2 GB de RAM livres. Vou deixar isso no vídeo porque, se

03:21 você tiver um notebook com 16 GB, isso também pode acontecer com você. Então, aluguei uma GPU no RunPod. A primeira que escolhi, uma RTX 4090, iniciou, mas a GPU não inicializava. O CUDA deu um erro desconhecido, então apaguei a instância e segui em frente. A segunda escolha foi uma A40 com 48 GB de VRAM por 59 centavos a hora. Executei cada modelo uma vez para aquecimento e depois seis vezes, e estes são os resultados. Stable Diffusion Sprint 0.6b, duas etapas: 0,38 segundo. Todas as

03:51 seis execuções ficaram dentro de um centésimo de segundo. Stable Diffusion 1.6B: 0,47 segundo. Os modelos normais, com 20 etapas: SANA 0.6B leva 1,57 segundo, e SANA 1.6B leva 2,52 segundos. O pico de VRAM para o 1.6B é de 10,9 GB. Então, a alegação de 0,1 segundo era com uma H100. Nesta A40, medi 0,38. Isso é cerca de quatro vezes mais lento que o número da H100, o que é razoável para uma A40, e é um resultado real.

04:22 E compare isso com o notebook: de 21 a 26 segundos contra 0,38. É mais de 50 vezes mais lento. E a diferença não está no modelo, mas na memória. Agora, cometi um erro que quero mostrar: minha primeira execução do modelo 1.6B com 20 etapas ficou assim. Aquilo não era SANA. Eu tinha carregado a variante errada do checkpoint: os pesos FP16 em um pipeline BF16. Quando usei o repo BF16 com a variante BF16, que é o que diz o model card, o mesmo prompt gerou isto. A placa diz SANA, e está escrito certo.

04:54 A velocidade é só metade da questão. Então, vamos olhar as imagens. Os mesmos três prompts: um gato cyberpunk com uma placa de neon, uma cafeteria ao nascer do sol e uma raposa vermelha na neve. O 1.6B com 20 etapas é o mais nítido. Dá para ver os bigodes, o reflexo na rua molhada, e a placa está escrita corretamente. A imagem do Sprint 1.6B é parecida, mas a placa diz SANA com um S a mais. E, no meu notebook, o Sprint 0.6B escreveu SANA com um A a mais. Então, a renderização de texto é o ponto fraco. Para uma única

05:25 palavra, funciona na maioria das vezes, mas eu não confiaria nele para uma frase inteira. Para imagens sem texto, é sinceramente difícil distinguir, de relance, o modelo Sprint a 0,4 segundo do modelo de 20 etapas. Antes do veredito, deixe-me mostrar o que mais você recebe, porque o repo é maior do que um único modelo. Tudo isso vem da lista de notícias do readme. Há um modelo de 2K que, segundo o readme, gera uma imagem em cerca de 4 segundos, e um modelo de 4K que gera uma imagem de 4096 por 4096 pixels em cerca de 20 segundos. Esses são os números deles, não os meus, e eu não testei 4K, então considere

05:58 isso apenas uma alegação. Há uma versão de 4 bits. A seção de notícias diz que você pode executar o Stable Diffusion com 8 GB de VRAM usando quantização SVD e o mecanismo Nunchaku. De novo, não testei, mas, se você tem uma placa de 8 GB, é a primeira coisa que eu tentaria. Há o Stable Diffusion 1.5, que trata de escalabilidade. Eles treinam um modelo maior com mais eficiência e adicionam escalabilidade de inference, para que você possa usar mais poder computacional na hora da geração e obter uma imagem melhor. E há uma versão ControlNet, para que você possa orientar uma imagem com um esboço ou um

06:28 mapa de bordas. Para fine-tuning, o Diffusers oferece suporte ao treinamento de Stable Diffusion LoRA, e o readme tem um link para um guia do DreamBooth. E, para executá-lo, você pode usar Diffusers, ComfyUI por meio do nó de modelos extras ou SG Lang, se quiser um servidor de API. Então, você não fica preso a um único script. Seja qual for a ferramenta que você já usa, provavelmente há um jeito de fazer isso. Se quiser repetir meu teste, este é o código, direto do model card. Você carrega o pipeline do Stable Diffusion pelo Diffusers, aponta para o repo BF16, define a variante como BF16 e o torch dtype como bfloat16. Foi nessa linha da variante que errei da primeira vez. Depois,

07:03 você também define o VAE e o codificador de texto como bfloat16. Envie o pipeline para CUDA e chame-o com um prompt, altura e largura de 1024 e guidance scale de 4.5. Usei 20 etapas neste teste. E, se você tiver menos de cerca de 11 GB de VRAM livre, ative o descarregamento do modelo para a CPU e espere que fique mais lento. No meu notebook, com o descarregamento ativado, o modelo Stable Diffusion 0.6b levou cerca de 21 segundos por imagem, contra 0,38 na A40, e parte dessa diferença se deve ao descarregamento. Coloquei meus

07:34 scripts de benchmark e todos os tempos na descrição, para que você possa comparar sua placa com a minha. Então, aqui vai meu veredito, com números. Se você tem uma placa de 8 GB, use a versão de 4 bits. O readme diz que ela funciona com menos de 8 GB, mas não testei essa versão, então não posso garantir a velocidade. Se você tem de 12 a 24 GB, o Sprint da Sana gera uma imagem de 1024 em menos de meio segundo em uma placa como a A40, e o 1.6B com 20 etapas leva cerca de 2 segundos e meio. E, se você não tem o hardware, alugar custa cerca de um dólar por uma hora e meia de testes como este. Gastei cerca de 10 centavos neste benchmark inteiro. O

08:08 A versão mais recente é a 2.0.0, Sanas video e Sanas video e Sanas WM. Então, uma análise em vídeo disso vem a seguir. Se você está procurando GPUs baratas e confiáveis, eu uso o RunPod, e o link está na descrição. Neste vídeo, vimos que o Sanas Sprint gera uma imagem de 1024 pixels em 0,38 segundo em uma A40, mas leva mais de 20 segundos no meu laptop com 8 GB. Vá em frente e experimente no seu próprio sistema e me conte nos comentários quanto tempo levou. Até a próxima.

Transcrição original

[00:02] This image took 0.38 seconds to make. It’s 1024 by 1024 and the sign says Saana more or less. Now, the same model, the same size on my 8 GB gaming laptop, about 21 seconds. So, who is right? The repo that says 0.1 seconds or my laptop? Mind you, everything slow in this video ran on my own system and everything fast ran on a rented GPU that cost me 59 cents an hour. Let’s go ahead and test this out. This is the repo NVlabs/saana.

[00:33] You can see about 9.3 thousand stars, 745 forks and the license on the right is Apache 2.0, so you can use it commercially. It comes from Nvidia and MIT and the description says efficient high-resolution image synthesis with a linear diffusion transformer. Now, if you look at the readme, the claim is right at the top, text-to-image up to 4K, 20 times smaller and 100 times faster than Flux 12B and the sprint version says 0.1 seconds per 1024 pixel image on an H100. One thing I want to say, honestly, if you look at the news

[01:05] section, most of the recent work is video and world models, Saana video 2.0, Saana WM, Saana streaming. The image model I’m testing today is the older part of the repo from 2024 and early 2025, but it is the part that most of us can actually run. The docs page list the key techniques and there are three that matter for speed. First, the autoencoder. Normal image models compress an image eight times before the diffusion model touches it. Saana uses DCAE, which compresses 32 times, so a 1024 image becomes 32 by 32 tokens, not

[01:39] 128 by 128. That is 16 times fewer tokens. Second, linear tension. In a regular transformer, doubling the tokens roughly quadruples the attention cost. Saana swaps that for linear tension, so the cost grows in a straight line and the gap gets bigger the higher the resolution goes. That’s why they can talk about 4K. Third, the text encoder, instead of T5, they use a small decoder-only language model, Gemma, as the text encoder. That is what lets it follow longer prompts. And then Sprint. Sprint is distilled. So, instead of 20

[02:11] steps, it makes the image in 1 to 4 steps. In my test, I used two. Here are the models on Hugging Face. I’m going to use the Diffusers versions, so I don’t have to build the whole repo. My system is a laptop with an RTX 4060 and 8 GB of VRAM and 16 GB of RAM. I installed Diffusers, loaded Stable Diffusion 0.6b, and the first download took 319 seconds. So, that’s 5 minutes just for weights. Now, the first run with CPU offload turned on, it generated in 20.6 seconds and 25.9 seconds, and peak VRAM was 5.3 GB. So, that works, but it’s nowhere

[02:46] near 0.1 seconds. Maybe offload is the problem, I thought. So, I put the whole model on the GPU, and it got slower, 37 to 41 seconds per image. The reason is on screen, peak memory was 8.8 GB, and my card has eight. So, Windows spills the rest into shared memory. That is the first honest number, the 0.6b model does not fit on an 8 GB card without help. Then, I tried the bigger one, Stable Diffusion 1.6b, and it didn’t even load. I got a memory error while loading the transformer because I had about 2 GB of RAM free. I’m leaving that in because if

[03:21] you have a 16 GB laptop, this might happen to you, too. So, I rented a GPU on RunPod. The first one I picked, an RTX 4090, started, but the GPU wouldn’t initialize. CUDA gave an unknown error, so I deleted it and moved on. Second pick was an A40 with 48 GB of VRAM at 59 cents an hour. I ran each model with one warm-up and then six times runs, and here are the results. Stable Diffusion Sprint 0.6b, two steps, 0.38 seconds. Every one of

[03:51] the six runs was within a hundredth of a second. Stable Diffusion 1.6B 0.47 seconds. The regular models with 20 steps, SANA 0.6B takes 1.57 seconds and SANA 1.6B takes 2.52 seconds. Peak VRAM for the 1.6B is 10.9 GB. So, the claim of 0.1 seconds was on an H100. On this A40, I measured 0.38. That’s about four times slower than the H100 number, which is reasonable for an A40 and it’s real.

[04:22] And compare that with the laptop, 21 to 26 seconds against 0.38. That’s more than 50 times slower. And the difference is not the model, it’s the memory. Now, one mistake of mine because I want to show it, my first 20-step run of the 1.6B model came out as this. That wasn’t SANA. I had loaded the wrong checkpoint variant, the FP16 weights in a BF16 pipeline. When I used the BF16 repo with the BF16 variant, which is what the model card says, the same prompt gave this. The sign says SANA and it’s spelled right.

[04:54] Speed is only half of it. So, let’s look at the images. Same three prompts, a cyberpunk cat with a neon sign, a coffee shop at sunrise, and a red fox in snow. The 1.6B at 20 steps is the cleanest. You can see the whiskers, the wet street reflection, and the sign is spelled correctly. The Sprint 1.6B image is close, but the sign says SANA with an extra S. And on my laptop, Sprint 0.6B wrote SANA with an extra A. So, text rendering is the weak spot. For a single

[05:25] word, it mostly works, but I wouldn’t trust it with a full sentence. For pictures without text, the Sprint model at 0.4 seconds is honestly hard to tell from the 20-step model at a glance. Before the verdict, let me show you what else you get because the repo is bigger than one model. All of this is from the readme news list. There’s a 2K model that the readme says makes an image in about 4 seconds and a 4K model that makes a 4096 by 4096 image in about 20 seconds. Those are their numbers, not mine, and I did not run 4K, so treat

[05:58] that as a claim. There’s a 4-bit version. The news section says you can run Stable Diffusion inside 8 GB of VRAM using SVD quant and the Nunchaku engine. Again, I haven’t tested it, but if you own an 8 GB card, that is the first thing I would try. There’s Stable Diffusion 1.5, which is about scaling. They train a bigger model more efficiently, and they add inference scaling, so you can spend more compute at generation time for a better image. And there’s a ControlNet version, so you can guide an image with a sketch or an

[06:28] edge map. For fine-tuning, Diffusers supports Stable Diffusion LoRA training, and the readme links a DreamBooth guide. And for running it, you can use Diffusers, ComfyUI through the extra models node, or SG Lang if you want an API server. So, you’re not locked into one script. Whatever tool you already use, there is probably a path. If you want to repeat my test, this is the code, and it’s straight from the model card. You load Stable Diffusion pipeline from Diffusers, point it at the BF16 repo, and set variant to BF16, and torch dtype to bfloat16. That variant line is the one I got wrong the first time. Then

[07:03] you move the VAE and the text encoder to bfloat16 as well. Send the pipeline to CUDA, and call it with a prompt height and width of 1024, and guidance scale 4.5. I used 20 steps for this one. And if you have less than about 11 GB of free VRAM, turn on model CPU offload, and expect it to be slower. On my laptop with offload on, the Stable Diffusion 0.6b model took about 21 seconds per image against 0.38 on the A40, and part of that gap is the offload. I put my

[07:34] benchmark scripts and every timing in the description, so you can compare your own card with mine. So, here’s my verdict with numbers. If you have an 8-GB card, use the 4-bit version. The readme says it runs under 8 GB, but I did not test that one, so I can’t promise the speed. If you have 12 to 24 GB, Sanas Sprint gives you a 1024 image in under half a second on a card like an A40, and the 1.6B at 20 steps is about 2 and 1/2 seconds. And if you don’t have the hardware, renting costs about a dollar for an hour and a half of testing like this. I spent about 10 cents on this whole benchmark. The

[08:08] latest release is version 2.0.0 Sanas video and Sanas video and Sanas WM. So, a video review of that is next. If you’re looking for cheap and reliable GPUs, I use RunPod, and the link is in the description. So, in this video, we have seen that Sanas Sprint makes a 1024 image in 0.38 seconds on an A40, but takes more than 20 seconds on my 8-GB laptop. Go ahead and try this on your own system, and let me know your timing in the comments. I’ll see you in another one.