O imposto DevOps: o custo real do self-hosting de IA não é a GPU.
A rubrica que ninguém orçamenta é o tempo de engenharia: lutas com drivers, versões de CUDA, afinação do serving stack, Kubernetes. Porque o preço por hora da GPU nunca foi o número que importava.
Neste artigo 2 secções
- O maior custo escondido na IA self-hosted é o tempo de engenharia, não o preço por hora da GPU.
- Compatibilidade de drivers e CUDA, escolhas de quantização, afinação do serving stack e Kubernetes consomem semanas antes de o primeiro token ser servido.
- Uma GPU cloud em bruto entrega-lhe computação e uma fatura; a ligação de tudo é, silenciosamente, a sua folha de salários.
- A alternativa managed: a sua equipa chama um endpoint, os nossos engenheiros mantêm-no a funcionar. Não contrata um engenheiro de MLOps, fica com o nosso.
Peça o preço de um GPU server e recebe um número limpo. Peça o preço do que é preciso para transformar esse servidor num endpoint de inferência de produção e o número amolece: uma versão de driver que discorda do CUDA toolkit, um serving framework que quer um kernel diferente, uma quantização que afinal precisa de mais VRAM do que o artigo dizia, uma camada de Kubernetes de que a carga de trabalho não precisava. Nada disto aparece na fatura. Tudo isto aparece na sua folha de salários.
O imposto, linha a linha
Eis o que fica entre uma placa num rack e um endpoint em que a sua aplicação pode confiar, pela ordem em que chega. Cada linha é tempo de engenharia, e cada linha repete-se: uma stack que funcionava no dia em que foi instalada tem de continuar a funcionar através de todas as atualizações que se seguem.
Burn-in.
Prove que a placa e o host estão saudáveis antes de algo depender deles: carga sustentada, temperaturas, memória, alimentação. Uma placa que faz throttle no seu primeiro batch real é um problema que quer encontrar no primeiro dia, não no dia do lançamento.
Alinhamento de driver e toolkit.
Kernel, driver, CUDA toolkit, container runtime e serving framework têm todos de concordar entre si. Concordam no dia em que os fixa. Cada atualização a qualquer um deles reabre a questão.
Empacotamento do modelo.
Pesos, tokenizer, quantização e o orçamento de VRAM que deles decorre. A escolha da quantização decide se o modelo cabe, a que velocidade responde e quanta qualidade sacrifica, e os números publicados são um ponto de partida, não uma garantia para o seu hardware.
Afinação do serving stack.
Batching, comprimento de contexto, dimensionamento da KV cache e concorrência, afinados para o seu alvo de latência e não para as predefinições do framework. É aqui que vive a maior parte do throughput, e é trabalho que ninguém vê quando é bem feito.
Infraestrutura do endpoint.
TLS, autenticação, um caminho de rede privado até à aplicação que o chama, e a decisão sobre o que é alcançável a partir de onde. Um endpoint de inferência alcançável a partir da internet pública é uma responsabilidade antes de ser uma funcionalidade.
Observabilidade.
Saúde da placa, pressão de VRAM, profundidade da fila e percentis de latência, com alguém a vigiá-los de facto. Uma GPU que corre silenciosamente a metade da velocidade parece exatamente saudável num dashboard que só verifica se o processo está em cima.
Atualizações, com caminho de regresso.
Atualizações de modelo, driver e stack aplicadas de forma agendada, testadas antes de aterrarem, com um rollback que já foi exercitado. Saltar atualizações compra sossego por algum tempo e depois uma semana muito barulhenta.
Teste de carga.
Prove que o endpoint aguenta a sua concorrência no seu alvo de latência antes de algo depender dele. A primeira vez que o endpoint vê tráfego real não deve ser a primeira vez que alguém o mediu.
Prevenção.
Quando avaria às 3 da manhã, alguém tem de assumir. Não numa escala numa folha de cálculo: um engenheiro que conhece a stack, acordado, com acesso.
Que linhas desaparecem quando as pessoas que instalaram a placa no rack também fazem o deployment da stack
Todas menos duas. Continua a escolher o modelo, e continua a escrever a aplicação que o chama. Burn-in, fixação de versões, afinação do serving stack, o endpoint privado, a monitorização, as atualizações, o teste de carga e a prevenção ficam com as pessoas que são donas do hardware e que já os carregam para todas as outras máquinas na sala. Corremos inferência nas nossas próprias GPU, pelo que a lista vem da prática.
Não uma placa à hora. Um endpoint privado que responde na latência acordada, numa máquina single-tenant, mantido atualizado por engenheiros que conhecem a stack porque a construíram. O preço por hora é o número mais pequeno da página.
Respostas diretas
Não podemos simplesmente usar o guia de instalação do fabricante?+
Os guias assumem uma placa, um driver, uma versão de framework, congelados no tempo. Produção significa que a combinação continua a funcionar através de atualizações, sob carga, no seu alvo de latência. Essa manutenção é o imposto; a instalação nunca foi a parte difícil.
Managed significa que perdemos o root?+
Não. A máquina é single-tenant e sua; quanto da stack carregamos é acordado por cliente: alguns ficam com as chaves e correm tudo, outros entregam-nos a camada de serving e ficam com a sua aplicação.
O que é que a vossa equipa faz realmente em contínuo?+
Fixa versões de drivers e CUDA, instala e afina o serving stack, monitoriza a placa e o endpoint 24/7, e aplica atualizações de modelo e de stack num calendário que a sua empresa aprova. Quando avaria, nós reparamos, a qualquer hora.
Traga-nos o modelo que quer correr
Dimensionamos a GPU, fazemos o deployment da stack, e entregamos-lhe um endpoint privado. O imposto DevOps fica connosco.
Ver os GPU serversChegou ao fim.
Ponha a leitura em prática
O que executa?
Fale-nos da carga de trabalho, do tráfego e dos requisitos de recuperação. Comece pelo configurador de servidores ou discuta os detalhes com um engenheiro.
Escrito pelos engenheiros que constroem e operam a infraestrutura que descreve.Fale com um engenheiro