O seu fornecedor de IA aplica rate limits ao seu melhor dia.

Imagine o dia em que finalmente funciona. O lançamento corre bem, a notícia sai, a campanha pega. O tráfego é o triplo do plano e a subir, e algures no produto, as funcionalidades de IA começam a devolver 429. Não no mês passado, quando tinha margem de sobra. Agora, precisamente agora, porque o melhor dia do seu produto é também a hora mais movimentada da plataforma, e a plataforma tem de escolher quem espera.

A maioria das equipas arquiva isto como azar e escreve mais lógica de retry. Não é sorte. É a arquitetura a fazer exatamente o que tem de fazer.

O racionamento é o produto a funcionar como foi desenhado

Não há vilão aqui, e é isso que o torna duradouro. Uma plataforma de inferência partilhada vende as mesmas GPU a milhares de clientes. A procura de pico tem de ser racionada ou a plataforma colapsa para toda a gente, por isso as ferramentas de racionamento existem: rate limits por escalão de conta, prioridade de fila para quem gasta mais, erros de capacidade quando a reserva seca. Tudo razoável. Tudo invisível na demonstração. Tudo decisivo no dia em que o seu tráfego finalmente aparece. A partilha tem um mapa de lugares, e não controla o seu lugar.

A parte que as equipas descobrem tarde é que o limite é um objeto de política. Varia por escalão de conta. Move-se com o planeamento de capacidade do próprio fornecedor. Aumentá-lo é um pedido, às vezes uma conversa comercial, e nada nele é física contratual. Se o roadmap diz o triplo da utilização até ao Q4 e o plano para isso é «vamos pedir que aumentem o limite», o roadmap tem uma dependência que ninguém assinou.

“O seu rate limit não é uma lei da natureza. É uma política, definida por outra pessoa, revisível sem o seu voto.”

O que uma máquina reservada muda realmente

Single-tenant significa que o lançamento de nenhum outro cliente pode consumir a sua capacidade: não há mais ninguém na máquina. Determinístico por conceção significa que o seu perfil de latência é definido pelo seu modelo, pela sua placa e pela sua afinação, não pelo tráfego de um estranho. O teto continua a existir. É o throughput que dimensionou, e dimensioná-lo é aritmética (a versão honesta dessas contas). Mas é o seu teto: conhecido de antemão, testado sob carga na sua carga de trabalho antes do lançamento, e movido por uma decisão de hardware que toma, não por uma política a que faz um pedido.

As mesmas contas castigam o trabalho batch constante, não só os lançamentos. Enriquecimento, classificação, processamento de documentos sobre um grande conjunto de dados privado: numa plataforma partilhada com throttling, o racionamento do throughput transforma um trabalho de fim de semana numa semana, e o contador corre o tempo todo. Numa máquina reservada o batch corre ao ritmo da máquina, constante, sem ansiedade de contador. Saber se o seu volume justifica uma máquina reservada exige uma comparação da sua despesa atual, da utilização sustentada e dos requisitos operacionais. Comece pelo pedido de dimensionamento GPU para solicitar uma configuração para essa comparação.

Quem deve ignorar este artigo

Se a sua carga de trabalho é pequena e genuinamente intermitente, uma demonstração, uma experiência, uma tarde de carga, a elasticidade da plataforma partilhada é o melhor negócio e os seus rate limits provavelmente nunca lhe tocarão. Essa é a resposta honesta e damo-la livremente, porque uma máquina reservada que usa quatro horas por mês é uma má compra e preferíamos não lha vender. Este artigo é para a outra equipa: aquela cuja utilização é constante, crescente, ou com picos exatamente quando importa, onde o mapa de lugares já começou a custar lançamentos reais e dinheiro real. Para essa equipa, a questão não é se a API é boa. É em que folha de cálculo vive o seu teto.