Euclyd: como a startup quer quebrar o monopólio CUDA da Nvidia

Toda vez que alguém me pergunta “qual GPU comprar pra rodar IA?”, eu já sei que a conversa vai terminar em CUDA, cuDNN e algum driver da Nvidia travando na madrugada. O monopólio da Nvidia em chips de IA não é só sobre hardware — é sobre um ecossistema de software que custa bilhões para ser replicado. A notícia de que a Samsung liderou uma rodada de US$ 231 milhões na Euclyd, startup holandesa que quer mudar a arquitetura dos chips de IA, segundo o Olhar Digital, me fez parar e analisar o que isso significa de verdade pra quem escreve código. Porque a parte mais interessante dessa história não é o dinheiro — é a rachadura que está se formando na fortaleza CUDA.

Por que a Nvidia domina — e por que isso está mudando

Trabalhei com inferência de modelos grandes em produção desde 2022 e posso te dizer: a Nvidia venceu não por causa da GPU em si, mas por causa de três camadas que se reforçam:

• CUDA — toolkit maduro, com mais de 17 anos de evolução e documentação obscura que devs seniores já aprenderam a traduzir na marra.
• cuDNN / TensorRT — bibliotecas otimizadas que tornam transformadores rápidos sem o dev entender o que está acontecendo por baixo.
• O lock-in do framework — PyTorch e TensorFlow foram escritos assumindo CUDA. Portar pra outra arquitetura dá trabalho de verdade.

Quando uma startup como a Euclyd aparece prometendo uma arquitetura alternativa, a pergunta técnica que eu faço é simples: como ela lida com as três camadas acima?. Se a resposta for “vamos reescrever tudo do zero”, a probabilidade de tração comercial em larga escala é baixa. Se for “vamos licenciar IP e casar com frameworks existentes”, aí a conversa muda.

E é exatamente isso que a Euclyd propõe, segundo o CEO Bernardo Kastrup: duas frentes — venda de racks de hardware pra inferência on-premise e licenciamento de IP pra quem quer fabricar chip próprio. É o modelo da ARM, aplicado a IA. Inteligente, se a arquitetura for realmente boa.

O que a Euclyd está propondo (e o que ainda não sabemos)

A fonte original é cuidadosa em um ponto importante: os sistemas da Euclyd ainda não foram comprovados em implantações comerciais em larga escala. Isso muda tudo. Na minha experiência avaliando vendors de infraestrutura, promessa sem benchmark público é promessa de marketing.

O que sabemos até agora:

• É silício desenhado especificamente pra modelos fundamentais (foundation models) — não é uma GPU genérica adaptada.
• O foco declarado é em eficiência energética e custo de data center, não em performance bruta.
• A Samsung é co-líder da rodada, junto com Somerset Capital, EQT e Innovation Industries.
• O valor de US$ 231 milhões é robusto pra uma Série A, mas modesto comparado com o que a Nvidia gasta em P&D por trimestre.

O que não sabemos — e isso é o que mais me incomoda como dev:

• Qual o ISA (Instruction Set Architecture)? É algo tipo TPU do Google, ou algo exótico como wafer-scale da Cerebras?
• Qual o ecossistema de software? Tem compilador pra PyTorch? Tem suporte nativo?
• Qual a densidade de memória? Modelos de 70B+ parâmetros precisam de HBM ou algo equivalente.

Sem respostas pra essas perguntas, “alternativa à Nvidia” é só narrativa. Mas a narrativa importa — porque é ela que move capital, e capital é o que faz chips saírem do papel.

Na Prática: como devs podem se preparar para um mundo (possivelmente) menos CUDA

Mesmo que a Euclyd não vingue, a tendência é clara: arquiteturas heterogêneas vão dominar os próximos 5 anos. O Google já tem TPUs em produção massiva, a Apple tem o Neural Engine, a AWS tem Trainium e Inferentia, a Groq está crescendo, e agora a Euclyd entra no jogo.

O erro que vejo devs juniores cometerem é hardcodar tudo no CUDA. Vou te mostrar como escrever código de inferência agnóstico ao backend — algo que eu uso em produção há dois anos:

import os
# Variável de ambiente define o backend antes do import
# ACCELERATOR=cuda | tpu | cpu | custom
os.environ.setdefault("ACCELERATOR", "cuda")

from abc import ABC, abstractmethod
from dataclasses import dataclass
from typing import List

@dataclass
class InferenceResult:
    text: str
    tokens_generated: int
    accelerator: str
    latency_ms: float

class InferenceBackend(ABC):
    @abstractmethod
    def load(self, model_path: str) -> None: ...
    
    @abstractmethod
    def generate(self, prompt: str, max_tokens: int = 256) -> InferenceResult: ...

class CudaBackend(InferenceBackend):
    """Wrapper para vLLM ou HuggingFace TGI rodando em CUDA"""
    def __init__(self):
        self.accelerator = "cuda"
    # ... implementação real aqui

class TpuBackend(InferenceBackend):
    """Wrapper para JAX/Pax em Google TPU"""
    def __init__(self):
        self.accelerator = "tpu"
    # ... implementação real aqui

class CustomSiliconBackend(InferenceBackend):
    """Backend futuro para arquiteturas como Euclyd, Groq, etc."""
    def __init__(self, ip_license_key: str):
        # Aqui entraria a SDK específica do fabricante
        if not ip_license_key:
            raise ValueError("IP license required for custom silicon")
        self.accelerator = "custom-silicon"
    # ... implementação real aqui

def get_backend() -> InferenceBackend:
    accel = os.environ.get("ACCELERATOR", "cuda").lower()
    if accel == "cuda":
        return CudaBackend()
    elif accel == "tpu":
        return TpuBackend()
    elif accel == "custom":
        return CustomSiliconBackend(ip_license_key=os.environ["IP_KEY"])
    else:
        # CPU fallback — lento, mas funciona
        raise NotImplementedError(f"Backend {accel} ainda não implementado")

# Uso: trocar uma única variável de ambiente muda o hardware
backend = get_backend()
backend.load("./models/llama-3-70b")
result = backend.generate("Explique atenção multi-cabeça em 3 frases")
print(f"[{result.accelerator}] {result.text}")

Esse padrão de strategy + factory é o que evita refatoração de seis meses quando o CTO decide migrar de Nvidia pra outra coisa da noite pro dia. Já vi acontecer três vezes. Não é questão de se, é de quando.

Comparativo: alternativas à Nvidia no horizonte 2026

Repare no padrão: todo mundo está fugindo da GPU genérica e indo pra ASIC focado. É o mesmo movimento que aconteceu com mining de cripto (CPUs → GPUs → ASICs). A diferença é que, no caso de IA, o “algoritmo” muda a cada 6 meses, o que torna ASICs muito mais arriscados.

Erros comuns que devs cometem ao pensar em hardware de IA

Depois de anos quebrando cabeça com infra, esses são os erros que mais vejo:

1. Escolher hardware pelo FLOPS de pico. FLOPS teórico raramente reflete performance real em inference. Memória bandwidth e latência de HBM importam mais que TFLOPs.
2. Ignorar o custo total de propriedade (TCO). Uma H100 parece cara, mas o custo por token inferido pode ser menor que em alternativas mais baratas e menos otimizadas.
3. Acoplar código demais ao backend. Se seu código só roda em CUDA, você vira refém de preço. Escreva abstrações como mostrei acima.
4. Subestimar o custo de portabilidade. “Ah, é só trocar torch.cuda() por torch.xla()” — não, não é. Em produção real, a portabilidade custa 2 a 6 meses de engenharia.
5. Confundir treino com inferência. Hardware ótimo pra treino (MuP, alta VRAM) frequentemente é overkill pra inferência (latência, throughput por watt).
6. Não testar com modelos reais do seu domínio. Benchmark sintético em MLPerf é bonito, mas não diz nada sobre como o chip lida com seu modelo de 13B com fine-tuning LoRA.

Se eu fosse você, antes de apostar em qualquer chip novo — inclusive um da Euclyd quando aparecer — eu pediria acesso a uma sandbox e rodaria meu workload real por pelo menos 14 dias. Qualquer vendor sério oferece isso.

FAQ

A Euclyd realmente vai substituir a Nvidia?

Improvável num horizonte de 5 anos. A Nvidia tem vantagem ecossistêmica massiva (CUDA, cuDNN, NCCL, Triton, TensorRT). Mas a Euclyd não precisa substituir — só precisa capturar uma fatia significativa, especialmente em inferência on-premise onde custo de energia é diferencial.

Como dev, preciso me preocupar com isso agora?

Se você trabalha com deploy de modelos em produção, sim. Se você só faz fine-tuning no Colab, não. Mas se seu código de produção tem qualquer dependência hardcoded em CUDA, comece a refatorar pra abstrações. Eu já vi três migrações forçadas em dois anos — a próxima é questão de tempo.

Qual a diferença entre TPU da Google e o que a Euclyd está fazendo?

TPUs são ASICs projetados pra ops de matriz densa e têm ecossistema maduro (JAX, XLA). O que a Euclyd parece propor — pelo que dá pra inferir da reportagem — é silício dedicado especificamente a foundation models, com modelo de licenciamento de IP tipo ARM. É uma proposta de mercado diferente, não necessariamente uma arquitetura revolucionária.

Vale a pena esperar a Euclyd antes de comprar hardware de IA?

Não. Se você precisa de capacidade agora, compre Nvidia. A Euclyd ainda não tem produto comercial comprovado em larga escala, segundo a própria reportagem. Esperar hardware não-lançado pra deploy de produção é como esperar carro autônomo pra ir ao trabalho — funciona na teoria, te deixa a pé na prática.

Como avaliar se uma alternativa à Nvidia é boa de verdade?

Três perguntas que eu faço a qualquer vendor: (1) Tem suporte nativo a PyTorch ou só roda com SDK proprietário? (2) Posso rodar meu modelo real em sandbox por 14 dias? (3) Qual o custo por milhão de tokens comparado a uma H100? Se qualquer resposta for evasiva, passa pra próxima.

A corrida pra desafiar a Nvidia vai ser longa e sangrenta. A Samsung apostando na Euclyd mostra que o Vale do Silício (o original, não o californiano) também quer uma fatia. Pra quem programa, o recado é claro: pare de escrever código que só funciona em um fabricante. O próximo checkpoint de CUDA pode estar mais perto do que você imagina.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.