AesCode 8B: como calcular o custo de uma tarefa de geração de código estético

Por que o custo por token não basta

O custo de gerar uma página com o AesCode 8B não se limita necessariamente aos tokens de entrada e saída. O modelo produz artefatos visuais estruturados em HTML e CSS, e o fluxo descrito pelo projeto inclui renderizar o resultado em um navegador e verificar propriedades do código e da página. Se um resultado não atender aos critérios definidos, a equipe também pode decidir corrigi-lo ou gerar uma nova versão.

Por isso, convém distinguir os custos de inferência, verificação e iterações. Em uma implantação local, esses componentes podem corresponder a recursos diferentes: a inferência pode consumir GPU, enquanto a renderização e alguns controles podem usar CPU, memória e navegador. O custo financeiro depende de como esses recursos são alocados e da política de novas tentativas.

A documentação do AesCode descreve o método e os verificadores, mas não publica tarifas, latências por verificação nem uma taxa universal de sucesso na primeira tentativa. Os números apresentados aqui são variáveis para um cálculo próprio, não medições do AesCode 8B. A avaliação agregada do projeto também não equivale à probabilidade de uma tarefa específica passar por todos os critérios de um produto.

Componentes do custo

Uma estimativa útil separa as etapas do fluxo, em vez de atribuir um custo único a cada geração. A inferência abrange o processamento do prompt e a produção de HTML e CSS. Sua duração depende, entre outros fatores, do hardware, da configuração do modelo, do tamanho da entrada e da quantidade de tokens gerados.

A verificação descrita pelo projeto renderiza o HTML em um navegador Playwright e executa verificações determinísticas. Entre as propriedades examinadas estão execução, texto, limites dos elementos, dados de tabelas e gráficos, layout semântico e espaços em branco. O repositório documenta o funcionamento desses controles, mas não seu consumo de recursos nem a latência por tarefa.

A iteração acontece quando o fluxo exige outra geração ou uma correção após detectar uma falha. Nem todas as equipes repetem o processo da mesma forma: algumas estabelecem um número máximo de tentativas, outras corrigem apenas o código, e outras incluem revisão humana. O custo médio depende dessa política, dos recursos usados em cada etapa e dos resultados observados em tarefas representativas.

Modelo de cálculo e hipóteses

Para estimar o custo de inferência por tentativa, divida a quantidade de tokens gerados pela velocidade efetiva de geração. O resultado é um tempo aproximado. Se o custo da GPU for expresso por hora, converta o tempo para essa unidade e multiplique-o pela tarifa ou pelo custo interno correspondente. Essa aproximação, por si só, não representa toda a utilização do sistema, especialmente quando há solicitações simultâneas ou recursos compartilhados.

A verificação deve ser calculada conforme os recursos que realmente utiliza. Se Playwright e os verificadores consumirem CPU, aplicar diretamente a tarifa horária de GPU a essas etapas não refletirá necessariamente o custo. Para uma estimativa mais fiel, meça e avalie cada tipo de recurso separadamente. O exemplo de código usa uma tarifa comum apenas para ilustrar a estrutura do cálculo.

O fator 1/p pode estimar o número médio de tentativas somente sob hipóteses específicas: tentativas independentes, probabilidade de sucesso constante e repetição até o sucesso, sem limite de novas tentativas. Nessas condições, calcula-se primeiro o custo conjunto de inferência e verificação por tentativa e aplica-se o fator esperado uma única vez. A taxa de sucesso na primeira tentativa, por si só, não demonstra que essas hipóteses sejam válidas. Se as tentativas posteriores mudarem de estratégia, custo ou probabilidade, ou se houver um número máximo de tentativas, o modelo precisa ser adaptado.

def calcular_tco(tokens_saida, tok_por_seg, custo_gpu_hora, t_verif_seg, taxa_sucesso):
    if tok_por_seg <= 0 or custo_gpu_hora < 0 or t_verif_seg < 0:
        raise ValueError("Os tempos e custos devem ser válidos")
    if not 0 < taxa_sucesso <= 1:
        raise ValueError("taxa_sucesso deve estar entre 0 e 1")

    t_inferencia = tokens_saida / tok_por_seg
    custo_inferencia = (t_inferencia / 3600) * custo_gpu_hora
    custo_verificacao = (t_verif_seg / 3600) * custo_gpu_hora
    fator_iteracao = 1 / taxa_sucesso

    return (custo_inferencia + custo_verificacao) * fator_iteracao

Exemplo hipotético: 100 apresentações

Suponha, apenas para ilustrar o cálculo, uma saída média de 5.000 tokens gerada a 50 tokens por segundo, uma verificação de 10 segundos por tentativa e um custo de US$ 2 por hora. O exemplo aplica a mesma tarifa à inferência e à verificação para simplificar; isso não significa que a verificação consuma GPU nem que esses valores correspondam a uma instalação real do AesCode 8B.

Com essas hipóteses, a inferência dura 100 segundos e a verificação, outros 10 segundos por tentativa. O custo conjunto é 110/3.600 × 2 = US$ 0,061111 por tentativa. Se também presumirmos uma taxa de sucesso de 80%, tentativas independentes, probabilidade constante e repetição ilimitada até a aceitação, o fator médio é 1/0,8 = 1,25. Portanto, o custo estimado por tarefa aceita é 0,061111 × 1,25 = aproximadamente US$ 0,076389. Para 100 tarefas, a estimativa é US$ 7,64.

O exemplo não é uma tarifa nem um resultado medido. Alterar a velocidade, o tempo de verificação, o custo dos recursos, a taxa de sucesso ou a política de novas tentativas muda o resultado. Sob essas hipóteses, a relação entre o custo esperado e a probabilidade de sucesso é inversa, não exponencial.

Como obter uma estimativa própria

Uma estimativa operacional deve se basear no mesmo hardware, configuração e fluxo previstos para a implantação. Antes de medir, defina o que significa uma tarefa ser aceita: por exemplo, quais requisitos de conteúdo precisam ser atendidos e quais defeitos visuais justificam a rejeição. Sem critérios estáveis, a taxa de sucesso não permite comparar configurações de forma consistente.

Registre separadamente a inferência, a renderização e cada verificação. Para cada tarefa, anote os tokens de entrada e saída, a duração e os recursos usados em cada tentativa, as falhas detectadas e o número de novas tentativas. Se o fluxo limitar as tentativas, permitir correções parciais ou exigir revisão humana, inclua essas regras no cálculo em vez de presumir que o mesmo processo se repete até o sucesso.

Um conjunto de testes deve representar os prompts, as imagens de referência e os tipos de página esperados na aplicação. Um teste pequeno pode servir como primeira aproximação, mas a taxa de sucesso obtida não é uma garantia para outras tarefas. Diferenças de complexidade, carga simultânea, configuração do navegador e hardware podem alterar tanto o tempo quanto o custo.

Alcance dos resultados e limites da estimativa

A avaliação publicada pelo projeto informa resultados agregados para 300 amostras de infográficos, com três gerações por prompt e sem seleção entre elas. Essas métricas descrevem o desempenho no benchmark e suas dimensões de avaliação; não constituem uma taxa geral de sucesso na primeira tentativa para qualquer aplicação, prompt ou critério de aceitação. Também não demonstram que uma página aprovada em verificações determinísticas esteja pronta para entrega sem revisão visual.

O repositório descreve a renderização com Playwright e seis verificadores determinísticos, além de canais de avaliação visual. Não publica o custo ou a duração de cada verificação, o consumo de CPU ou GPU por tarefa nem uma taxa universal de sucesso inicial. A configuração usada em uma avaliação tampouco permite deduzir, por si só, a memória necessária ou o desempenho em outro hardware.

Portanto, o resultado do cálculo deve ser entendido como uma estimativa condicionada pelas medições e hipóteses escolhidas. Separar os custos de GPU e CPU, explicitar a política de novas tentativas e usar critérios de aceitação reproduzíveis ajuda a comparar implantações, mas não garante que o custo ou a qualidade permaneçam iguais quando mudarem o hardware, a carga ou os prompts.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.