Teste com DeepSeek H200 questiona a alegação de ser '80x mais barato
DeepSeek enfrentou um teste prático de custo depois que a The Call Center Doctors alugou quatro GPUs Nvidia H200 para examinar a alegação de que o modelo seria “80x mais barato”.
A consultoria tentou oferecer o DeepSeek V4.1 Flash aos seus agentes de codificação em vez de usar Claude Opus 5.5 por meio do Claude Code. Seu teste original constatou que pesos de modelo baratos não resultavam em um sistema funcional barato.
O teste com DeepSeek H200 expôs uma diferença entre a precificação por tokens e o custo de concluir trabalho real de software. O servidor alugado lidou rapidamente com cargas sintéticas, mas sua economia piorou quando a equipe reproduziu seu tráfego real de codificação.
Na tarifa normal de aluguel sob demanda, o servidor custava aproximadamente o dobro de enviar a mesma carga de trabalho para a própria API do DeepSeek. A consultoria também concluiu que suas assinaturas existentes do Claude Code continuavam competitivas ao medir alterações de código concluídas, em vez dos preços por token.
Essas conclusões vêm da carga de trabalho, configuração e medições internas de uma única empresa. Não constituem uma referência universal para nenhum dos modelos. O DeepSeek nunca recebeu permissão para escrever código de produção durante o teste, o que limita qualquer comparação direta de trabalho concluído.
Ainda assim, o experimento é relevante porque utilizou tráfego de agentes de codificação implantados, em vez de um benchmark isolado. Ele mediu contexto repetido, concorrência, latência, trabalho operacional e a fronteira de segurança em torno da execução autônoma de código.
A inversão central é simples. As baixas tarifas da API do DeepSeek continuaram atraentes, enquanto hospedar o mesmo modelo em GPUs premium gerou uma economia pior para essa carga de trabalho específica.
O resultado pressiona compradores a definir o que “mais barato” significa antes de trocar de fornecedor. Uma baixa tarifa por token de saída pode ser relevante, mas não descreve capacidade de processamento, confiabilidade, esforço de engenharia ou entrega bem-sucedida.
O teste com DeepSeek H200 substituiu uma alegação de preço por um teste de carga de trabalho
A consultoria testou um sistema completo de inferência, não apenas o número exibido ao lado de um milhão de tokens.
A The Call Center Doctors constrói e opera ambientes de call center para outras empresas. Ela também usa agentes de codificação para manter o software que sustenta esse trabalho.
Em 27 de setembro, a empresa alugou um servidor com quatro aceleradores Nvidia H200. Ela baixou o DeepSeek V4.1 Flash e configurou o modelo como backend para agentes normalmente conectados ao Claude Code.
O teste visava duas alegações comuns sobre modelos de pesos abertos. A primeira diz que tarifas menores por token se traduzem diretamente em custos operacionais menores. A segunda diz que organizações podem evitar as margens dos provedores ao alugar GPUs e servir o modelo por conta própria.
O DeepSeek oferece aos compradores motivos para investigar essas alegações. Seu lançamento do modelo descreve o V4.1 Flash como um modelo de mistura de especialistas projetado para inferência mais rápida e maior capacidade de processamento.
Um modelo de mistura de especialistas ativa apenas parte de sua rede para cada token. Esse design pode reduzir a computação em comparação com executar todos os parâmetros para cada solicitação.
O DeepSeek afirma que sua arquitetura ativa menos parâmetros durante o processamento de entrada e saída. Também afirma que o modelo precisa de menos memória de alta largura de banda para seu cache de chave-valor do que a geração anterior.
Um cache de chave-valor armazena dados intermediários de atenção de tokens anteriores. Reutilizar esses dados torna o contexto repetido mais barato do que processar toda a sequência como nova entrada.
A consultoria, portanto, escolheu hardware adequado para inferência intensiva em memória. Cada H200 inclui 141GB de memória de alta largura de banda, segundo as especificações do H200 da Nvidia.
Em quatro GPUs, essa capacidade foi suficiente para carregar e servir o modelo após várias mudanças de configuração. No entanto, alcançar um serviço estável exigiu cinco inicializações.
Cada reinicialização exigiu outro período de carregamento do modelo. Uma otimização consumiu memória inesperada, outra execução travou, e uma configuração posterior falhou sob maior concorrência.
A quinta tentativa se estabilizou com um limite menor de concorrência e a maior parte da memória disponível comprometida. Essa sequência operacional tornou-se parte do resultado econômico.
Uma API hospedada oculta downloads do modelo, alocação de memória, software de serving, planejamento de capacidade e inicializações malsucedidas. Uma máquina alugada expõe cada tarefa ao cliente.
Quando estabilizado, o servidor apresentou bom desempenho em testes isolados de um minuto. Processou entradas em cache particularmente rápido e gerou milhares de tokens por segundo em toda a máquina.
Esse resultado inicialmente sustentou o argumento a favor da auto-hospedagem. Quatro H200s tinham capacidade bruta substancial, e o design orientado a cache do DeepSeek se comportou como esperado.
O problema apareceu quando a equipe deixou de testar uma categoria de token por vez. Seus agentes de codificação não enviavam uma sequência equilibrada de nova entrada, entrada em cache e saída.
Eles forneciam repetidamente conversas longas, resultados de ferramentas, contexto de arquivos e raciocínios anteriores. A maior parte de cada solicitação consistia em texto que o modelo já tinha visto.
Essa carga de trabalho afastou o teste da velocidade teórica de saída. Ela forçou a máquina a gastar quase todo o tempo processando o contexto necessário antes de gerar a próxima resposta.
Portanto, o evento não foi uma corrida convencional entre modelos. Foi um teste para verificar se taxas atraentes de inferência resistiam ao contato com o tráfego real de um sistema de agentes.
Por que o contexto dos agentes consumiu as quatro H200s
Agentes de codificação frequentemente gastam muito mais computação lendo seu histórico do que escrevendo o próximo token útil.
Os registros de setembro da consultoria continham 388,5 bilhões de tokens lidos e 393 milhões de tokens escritos. Das entradas, 374,2 bilhões de tokens eram releituras em cache.
Isso significa que mais de 96 por cento da entrada registrada repetia contexto anterior. Para cada token de saída, os agentes forneciam cerca de 41,6 novos tokens de entrada e 1.042 tokens em cache.
Uma solicitação média relia aproximadamente 196.000 tokens. Esse padrão importa porque a entrada em cache é barata por token, mas nunca é computacionalmente gratuita.
O servidor alugado processava cada token em cache mais rapidamente do que cada novo token. No entanto, os agentes forneciam tantos tokens em cache que esses pequenos custos se acumularam e se tornaram a carga dominante.
A empresa mediu aproximadamente 1,9 microssegundo de tempo de servidor para um token em cache. Um novo token de entrada exigia cerca de 60 microssegundos, enquanto um token de saída exigia cerca de 189 microssegundos.
Aplicar essas medições ao mix de tráfego de produção gerou um teto combinado próximo de 213 tokens de saída por segundo. Esse foi o resultado agregado para todos os agentes compartilhando as quatro GPUs.
A fórmula correspondeu ao teste ao vivo com uma margem de três por cento, segundo a consultoria. Essa concordância reforçou o modelo de carga de trabalho, embora uma parte independente não o tenha replicado.
A empresa estimou que a máquina poderia processar aproximadamente 20 bilhões de tokens totais por dia sob esse mix. Seu dia mais movimentado de setembro atingiu 51 bilhões de tokens.
A capacidade, portanto, tornou-se uma segunda restrição. Um servidor não conseguiria absorver o pico registrado, mesmo que sua economia normal de aluguel tivesse sido favorável.
O contraste entre testes isolados e mistos explica por que a capacidade de processamento anunciada pode enganar. A máquina gerou mais de 5.000 tokens por segundo quando a saída foi medida isoladamente.
Agentes reais não podem operar apenas com saída. Eles precisam fornecer continuamente instruções, código, arquivos, logs, respostas de ferramentas e mensagens anteriores.
Agentes de longa duração amplificam esse desequilíbrio porque as conversas crescem com o tempo. Cada chamada subsequente pode conter grande parte do mesmo histórico, além de uma pequena quantidade de novas informações.
Descontos de cache reduzem a cobrança por esses tokens repetidos. Eles não eliminam largura de banda de memória, atrasos de agendamento nem o custo de oportunidade de ocupar um servidor.
Essa distinção também complica comparações entre modelos. Um modelo mais capaz pode concluir uma tarefa com menos tentativas, prompts mais curtos ou menos revisão.
Um modelo mais barato ainda pode vencer se usar contexto semelhante e alcançar resultados comparáveis. Pode perder se exigir mais tentativas, explicações mais longas ou a verificação de outro modelo.
O teste com DeepSeek H200 não respondeu plenamente a essa questão de qualidade porque o DeepSeek serviu principalmente como um revisor somente para leitura. Mas mostrou por que tarifas apenas por tokens de saída não podem respondê-la.
A métrica relevante depende do trabalho. Um sistema de sumarização em lote pode priorizar capacidade total de processamento, enquanto um agente interativo também precisa de baixa latência e uso confiável de ferramentas.
Uma operação de codificação se preocupa com alterações concluídas, tempo de revisão, regressões, segurança e espera dos desenvolvedores. A eficiência por token é apenas uma entrada para esse resultado.
Os registros da consultoria ofereceram um alerta útil para outros compradores. Antes de selecionar hardware, equipes precisam traçar o perfil da proporção entre nova entrada, contexto em cache e saída gerada.
Sem essa proporção, um benchmark pode otimizar a menor parte da carga de trabalho. Um teste de geração rápida pode dizer pouco sobre um agente que passa a maior parte do tempo lendo.
A auto-hospedagem do DeepSeek perdeu para a API do DeepSeek
O resultado mais claro não foi DeepSeek versus Claude, mas infraestrutura DeepSeek alugada versus o serviço gerenciado do DeepSeek.
A tarifa normal do servidor sob demanda gerou um custo diário aproximadamente 2 a 2,4 vezes maior que o valor do mesmo tráfego pela API do DeepSeek. Esse cálculo pressupunha utilização contínua.
O aluguel spot usado durante o experimento era muito mais barato. Nessa tarifa temporária, o servidor apenas se aproximava da paridade com o serviço gerenciado do DeepSeek ao operar com carga total.
A capacidade spot traz uma contrapartida de disponibilidade. Os provedores podem retomá-la quando a demanda muda, o que dificulta tratá-la como infraestrutura de produção confiável.
Isso aconteceu quase imediatamente após o experimento. O provedor retomou a máquina poucos minutos depois do teste final.
A alternativa sob demanda evitava esse risco de interrupção, mas piorava a economia. Ela também cobrava enquanto o modelo carregava, reiniciava, aguardava tráfego ou permanecia abaixo da utilização máxima.
A API gerenciada do DeepSeek distribui esses períodos ociosos entre muitos clientes. O provedor pode agrupar solicitações, compartilhar hardware e operar sua própria pilha de serving em maior escala.
Sua tabela de tarifas da API também distingue entrada em cache, nova entrada e saída. O tráfego fora do pico recebe tarifas menores do que o tráfego no pico durante dias úteis.
Esse cronograma oferece aos compradores outra via de otimização. Cargas de trabalho em lote flexíveis podem ser deslocadas para fora dos períodos de pico sem exigir uma máquina dedicada.
O servidor alugado não tinha ajuste de demanda correspondente. Seu medidor por hora continuava funcionando, independentemente de os agentes produzirem trabalho útil.
A comparação não estabelece que a auto-hospedagem é sempre antieconômica. Organizações podem possuir hardware já depreciado, negociar tarifas menores de capacidade ou manter utilização estável em várias cargas de trabalho.
Implantações de grande escala também podem otimizar kernels, quantização, roteamento e agendamento de lotes além do que um experimento curto alcançou. O próprio DeepSeek convida organizações que planejam implantações muito grandes a discutir opções adicionais.
A privacidade pode justificar a operação local mesmo quando a inferência hospedada é mais barata. Cargas de trabalho reguladas podem exigir controles de dados que superem os custos diretos de computação.
A capacidade previsível também pode importar. Uma empresa com demanda sustentada pode preferir infraestrutura que controla, especialmente quando uma API externa impõe limites ou riscos de disponibilidade.
No entanto, essas vantagens exigem uma máquina estável, operadores experientes, monitoramento, failover e controles de segurança. Nada disso vem automaticamente com pesos abertos.
O teste também revelou um custo de expertise. Os engenheiros tiveram de diagnosticar consumo de memória, falhas de inicialização, limites de concorrência e comportamento de serving antes de executar a carga de trabalho útil.
Esse trabalho não foi incluído na simples comparação entre máquinas. Incluí-lo tornaria o curto experimento de auto-hospedagem menos favorável.
Essa é a principal lição para empresas que consideram uma implantação auto-hospedada do DeepSeek. A comparação relevante é entre um serviço completo e outro serviço completo.
Os pesos do modelo são um componente. Aluguel de hardware, capacidade ociosa, orquestração, observabilidade, resposta a incidentes, energia, armazenamento e tempo da equipe completam o sistema.
A API do DeepSeek se beneficia da mesma eficiência arquitetural do modelo disponível para download. Também se beneficia de uma infraestrutura que o DeepSeek pode operar para muitos clientes.
A auto-hospedagem precisa superar ambas as vantagens. Evitar a margem de uma API é insuficiente quando o provedor da API tem melhor utilização e experiência em serving.
Para essa carga de trabalho, ela não as superou. A opção de pesos abertos ofereceu controle, mas a nuvem do DeepSeek proporcionou a experiência DeepSeek mais barata.
A Alegação de “80x Mais Barato” Comparou Modelos de Compra Diferentes
A comparação principal perdeu força porque colocou tarifas públicas de API ao lado de acesso por assinatura com uso intenso.
A alegação de “80x mais barato” compara tarifas por token sob determinadas premissas. Ela não descreve automaticamente o valor pago por todos os usuários do Claude Code.
A consultoria acessou o Claude por meio de assinaturas, e não da API medida da Anthropic. A Anthropic confirma que os planos elegíveis fornecem acesso por assinatura ao Claude Code, sujeito a limites compartilhados de uso.
Uma assinatura e uma API atendem a padrões de compra diferentes. A assinatura agrupa o acesso dentro de limites definidos, enquanto uma API cobra de acordo com o consumo medido.
A consultoria afirmou que o uso por assinatura equivalia a receber um grande desconto sobre as tarifas públicas de API. Essa diferença absorveu a maior parte da lacuna teórica de 80x.
Com base no tráfego de setembro, a empresa calculou que a API do DeepSeek poderia variar de um pouco mais barata a mais cara do que suas assinaturas do Claude. O horário determinava onde o uso se situava entre as tarifas de pico e fora de pico.
Os resultados reportados também estimaram que a tarifa pública da API do Claude teria gerado uma conta muito maior. No entanto, esse não era o produto que a empresa havia adquirido.
Essa distinção é fácil de ignorar quando as comparações reduzem todos os produtos a uma tarifa nominal por token. O mesmo modelo pode ser vendido por assinaturas, contratos empresariais, plataformas de nuvem ou APIs diretas.
Cada canal tem limites e incentivos econômicos diferentes. Uma assinatura pode favorecer uso individual consistente, enquanto uma API oferece escala programável e contabilidade detalhada de uso.
Um contrato empresarial pode adicionar capacidade negociada, compromissos de serviço ou controles. A auto-hospedagem substitui a margem de serviço do fornecedor por infraestrutura e responsabilidade operacional.
Nenhuma tarifa única captura os quatro arranjos. Os compradores devem comparar a modalidade que de fato conseguem adquirir e operar.
A consultoria também calculou o custo de uma alteração de código integrada. Seus agentes Claude concluíram 5.610 alterações integradas no período medido, com cinco posteriormente revertidas.
Ela estimou que o DeepSeek exigiria tokens adicionais, novas tentativas e verificações baseadas no Claude. Sob essas premissas, cada alteração aceita custaria mais por meio do DeepSeek.
Essa estimativa merece cautela. O DeepSeek não executou a mesma tarefa com permissão de escrita, portanto o estudo não pôde observar sua taxa real de sucesso ou o uso total de tokens.
As premissas podem ser rigorosas demais se prompts melhores, software de serving ou o design dos agentes melhorarem a saída do DeepSeek. Podem ser otimistas demais se a revisão revelar mais defeitos.
Ainda assim, o custo por alteração aceita é uma métrica mais útil do que o custo por token de saída. Ele conecta o gasto com inferência ao software que sobrevive à revisão.
A melhor unidade depende do fluxo de trabalho. Equipes de atendimento ao cliente podem medir casos resolvidos, enquanto pesquisadores podem medir descobertas verificadas.
Uma tarifa baixa por token continua valiosa quando os modelos exigem trabalho semelhante para chegar a esses resultados. Ela se torna menos decisiva quando capacidade, latência ou carga de revisão diferem.
A cifra de “80x”, portanto, descreve uma comparação restrita, e não uma economia universal. A Call Center Doctors não refutou a tarifa publicada do DeepSeek.
Em vez disso, demonstrou que a aritmética das tabelas de preços pode ruir quando produtos, cargas de trabalho e qualidade dos resultados diferem.
A Segurança Impediu o DeepSeek de Escrever Código de Produção
A limitação mais forte do experimento também foi seu alerta operacional mais importante: o DeepSeek nunca concluiu a tarefa de programação pretendida.
A empresa planejava usar o DeepSeek para agentes de escrita de código. Seus revisores então encontraram possíveis caminhos para que código gerado escapasse do sandbox pretendido.
Um sandbox é um ambiente de execução isolado que restringe o que código não confiável pode acessar. Ele deve impedir que um agente alcance arquivos sensíveis, credenciais, redes ou privilégios administrativos.
Uma fragilidade relatada envolvia um arquivo de configurações em um diretório temporário compartilhado. A empresa acreditava que conteúdo manipulado ali poderia permitir que código gerado fosse executado com permissões elevadas.
Por isso, a consultoria manteve os agentes de construção offline. O DeepSeek operou apenas por meio de 48 a 64 agentes revisores somente leitura.
Esses revisores examinaram 2.377 pastas de código e produziram 32 relatórios de bugs. Essa atividade demonstrou uma taxa de processamento útil, mas não testou implementação autônoma.
A questão de segurança não foi apresentada como uma falha nos pesos do modelo DeepSeek. Ela dizia respeito ao ambiente de agentes e aos controles de execução da própria consultoria.
Essa distinção importa. Qualquer modelo capaz de gerar comandos pode expor fragilidades em uma cadeia de ferramentas mal isolada.
Claude, DeepSeek ou outro modelo podem produzir ações inseguras quando agentes recebem acesso ao sistema de arquivos e ao shell. A fronteira de segurança deve presumir que a saída do modelo não é confiável.
Consequentemente, o teste misturou duas questões separadas. Uma dizia respeito à economia da inferência do DeepSeek. A outra dizia respeito a se o sandbox de agentes da empresa estava pronto para automação com permissão de escrita.
Apenas a primeira questão recebeu medições diretas da carga de trabalho. A segunda interrompeu o teste de programação comparativo pretendido.
Isso impede uma afirmação forte de que o Claude produziu código melhor no mesmo experimento. O trabalho concluído pelo Claude em setembro era dado histórico de produção, enquanto o trabalho do DeepSeek foi um teste restrito.
Também impede uma medição justa do custo do DeepSeek por alteração integrada. O modelo nunca teve a oportunidade de gerar alterações para revisão e implantação.
A empresa citou benchmarks públicos de programação para argumentar que o Opus mantinha uma vantagem de capacidade. Benchmarks podem oferecer contexto, mas não substituem um conjunto idêntico de tarefas internas.
Um acompanhamento rigoroso daria aos dois modelos os mesmos repositórios, ferramentas, restrições de segurança, prompts e testes de aceitação. Os revisores permaneceriam sem saber a identidade do modelo.
O estudo registraria alterações bem-sucedidas, regressões, novas tentativas, latência, uso de tokens, tempo de revisão humana e violações de segurança. Só então poderia comparar diretamente os custos totais de entrega.
Apesar dessa limitação, a implantação abortada traz uma lição prática. O custo de infraestrutura tem pouco significado quando a camada de execução não consegue expor com segurança as ferramentas pretendidas do modelo.
Sistemas de agentes ampliam a superfície de ataque porque conectam saídas probabilísticas do modelo a ações determinísticas. Um único caminho inseguro pode importar mais do que milhares de tokens baratos.
Portanto, as empresas devem testar a contenção antes de calcular economias provenientes de trabalho autônomo. Análise somente leitura e agentes com permissão de escrita pertencem a categorias de risco muito diferentes.
A segurança também afeta a economia. Um isolamento mais forte pode exigir ambientes descartáveis, credenciais restritas, controles de rede, registros e pontos de aprovação.
Esses controles consomem tempo de engenharia e aumentam a latência. Também podem reduzir a concorrência ou exigir infraestrutura separada.
O modelo com a menor tarifa de inferência pode não produzir o menor custo de entrega segura. O sistema relevante inclui todo controle necessário para confiar em sua saída.
O Que o Teste do DeepSeek com H200 Significa para Compradores de IA
A próxima comparação deve se concentrar em trabalho aceito, utilização sustentada e execução segura, em vez de um único preço por token.
O primeiro sinal a observar é uma nova execução controlada com permissão de escrita. O DeepSeek precisa receber as mesmas ferramentas, repositórios, prompts e critérios de aceitação usados anteriormente com o Claude.
Se concluir alterações comparáveis com revisão limitada, a conclusão negativa da consultoria perderá força. Se novas tentativas e correções permanecerem altas, o argumento de custo baseado em resultados se fortalecerá.
O segundo sinal é a utilização sustentada ao longo de várias semanas. Um servidor auto-hospedado torna-se mais atraente quando a demanda útil permanece próxima da capacidade durante todo o dia.
A Call Center Doctors mediu um pico que excedia a capacidade de uma máquina. Ainda assim, o tráfego variável pode deixar períodos ociosos caros fora desses picos.
Um teste mais longo deve informar a utilização por hora, a profundidade da fila, a latência até o primeiro token, interrupções e a fração do tempo gasta carregando ou recuperando.
Ele também deve separar entrada em cache, nova entrada e saída. Essas categorias interagem de maneiras diferentes com largura de banda de memória e batching.
O terceiro sinal é o DeepSeek V4.1-Pro. O DeepSeek afirma que sua atual arquitetura Flash se estenderá a modelos maiores, mas não forneceu uma data firme de lançamento.
Um modelo mais forte poderia mudar a economia se concluísse mais tarefas com menos novas tentativas. Também poderia exigir mais memória ou oferecer menor throughput.
Os compradores devem acompanhar tanto a capacidade quanto os requisitos de serving. Uma melhoria em benchmark não garante menor custo de produção.
A conquista atual do DeepSeek continua significativa. Suas tarifas oficiais tornam acessível a experimentação em alto volume, e seus pesos disponíveis para download oferecem flexibilidade de implantação.
O teste não eliminou essas vantagens. Ele restringiu as condições em que elas se traduzem em economia.
Para demanda intermitente ou incerta, a API gerenciada do DeepSeek parece mais racional do que alugar um servidor dedicado com quatro GPUs. Ela preserva tarifas baixas por token sem transferir as operações de infraestrutura ao cliente.
Para dados sensíveis, demanda previsível e sustentada ou otimização especializada, a auto-hospedagem ainda pode merecer avaliação. O caso de negócio deve incluir equipe, confiabilidade, segurança e capacidade não utilizada.
O Claude Code apresenta uma proposta diferente. Ele reúne acesso ao modelo, uma interface de programação e infraestrutura operada pelo fornecedor sob limites de assinatura.
Esse pacote pode superar comparações baseadas em tokens para uso individual intenso. Também pode se tornar restritivo quando organizações precisam de capacidade programável ou controle centralizado.
A pressão, portanto, recai sobre equipes de compras e líderes de engenharia. Eles devem deixar de tratar “API”, “assinatura” e “auto-hospedado” como unidades de compra intercambiáveis.
Devem começar com rastros de produção, em vez de exemplos de fornecedores. O rastro mais útil registra tamanho de contexto, acertos de cache, saídas, latência, falhas e resultados aceitos.
As equipes podem então reproduzir cargas de trabalho representativas em sistemas concorrentes. O teste deve incluir as condições operacionais que importam após uma demonstração bem-sucedida.
Essas condições incluem concorrência, variação de tráfego, reinicializações, filas, atualizações de modelos, monitoramento e recuperação. Os testes de segurança devem ocorrer antes que os agentes recebam acesso de escrita.
As métricas de resultado devem corresponder ao objetivo da organização. Para agentes de programação, elas incluem alterações incorporadas, defeitos, reversões, tempo de revisão e tempo até a conclusão.
Para agentes de suporte, medidas úteis incluem casos resolvidos, escalonamentos, satisfação do cliente e violações de política. Para agentes de pesquisa, descobertas verificadas importam mais do que páginas geradas.
O teste do DeepSeek H200 é valioso porque avançou nessa direção. Ele substituiu uma comparação abstrata de tarifas por uma distribuição real de contexto e infraestrutura real.
Suas limitações são igualmente instrutivas. O curto período de execução, uma única organização, o trabalho de segurança inacabado e o acesso desigual à produção impedem um veredito universal.
A conclusão adequada é mais restrita. Quatro H200 alugadas não superaram a API da DeepSeek para essa carga de trabalho de agentes, e a API não ofereceu uma vantagem evidente de 80x em relação às assinaturas.
Isso basta para questionar alegações simplistas. Não basta para descartar a DeepSeek, pesos abertos ou inferência auto-hospedada.
Antes de mudar uma stack de IA, colete uma semana de tráfego representativo e calcule o custo por resultado aceito. Em seguida, repita a comparação com controles de segurança ativados.
Pergunte se o modelo conclui o mesmo trabalho, e não se seu token mais barato parece impressionante. O próximo teste do DeepSeek H200 deve responder a essa pergunta mais difícil.
