Trabalho comparável. Premissas explícitas.

1. Um contrato de comparação versionado

O modelo e a revisão exata, a precisão, a quantização, o runtime e sua versão, o protocolo de benchmark e sua versão e a meta de qualidade precisam corresponder. A inferência também fixa os comprimentos de entrada/saída, o tamanho do lote, a concorrência, o cache, a base de tokens e a restrição de latência. O treinamento fixa o conjunto de dados/revisão, a definição do trabalho e o critério de conclusão.

Modelo de GPU, quantidade de GPUs, hardware, interconexão e paralelismo podem variar entre resultados dentro desse contrato, mas cada resultado precisa manter sua configuração medida. A vinculação de preço da V1 suporta apenas um único nó. Nenhum escalonamento de desempenho de hardware é inferido.

2. Uma fórmula, unidades explícitas

Para o custo horário do sistema inteiro C e a vazão agregada compatível T em tokens/segundo:

USD por 1M tokens = C × 1,000,000 / (T × 3,600)

Um preço horário por GPU é multiplicado uma única vez pela quantidade de GPUs medida. Um preço horário por instância inteira já é um preço de sistema. A vazão por GPU é multiplicada uma única vez pela quantidade de GPUs medida; a vazão agregada é usada diretamente. O contrato de comparação identifica tokens de entrada, de saída ou totais.

Para treinamento: custo por execução definida = custo horário do sistema × horas de execução medidas. As GPU-hours por execução são divididas pela quantidade de GPUs medida para estimar as horas decorridas, explicitamente identificadas como uma estimativa contábil. Cenários de execuções repetidas pressupõem execuções idênticas e sequenciais.

3. Compatibilidade de preço e custos

Um fundador precisa atestar que a observação pública de preço cobre exatamente a configuração medida e a cobrança de capacidade computacional anunciada. As unidades originais em USD de GPU/hora e instance-hour são suportadas. Outras moedas e unidades continuam indisponíveis. Um fixing agregado público do KCI não pode substituir um preço de sistema que possa ser comprado.

Somente a cobrança de capacidade computacional anunciada é incluída. Configuração inicial, CPU/RAM cobradas à parte, armazenamento, rede/egress, impostos e suporte são excluídos. Os snapshots de base não modelam compromissos mínimos, incrementos de faturamento, perdas de utilização nem disponibilidade; o gasto realizado pode ser maior. Estes não são preços de tokens de API nem estimativas de custo total.

4. Atualidade, revisão e revisões

As observações de benchmark mantêm o teto de atualidade de desempenho existente de 180 dias. O Economics v1 aplica um teto de preço de 30 dias para não apresentar observações antigas de preço de tabela como custos atuais. São janelas de elegibilidade, não pontuações de confiança. As classes de fonte são declarada pelo provedor, independente ou interna.

A importação ou captura cria um rascunho; uma revisão explícita o aprova. A retirada e a substituição aprovada bloqueiam novos cálculos. Snapshots imutáveis preservam as entradas originais, as datas de medição, as datas de aquisição, as revisões de benchmark, as versões de grupo, a versão da fórmula e o horário do cálculo. A despublicação de uma fonte pode remover o acesso público sem apagar o registro interno mantido.

5. Histórico e ferramentas de decisão

O histórico de economia é um registro informativo. Não é um nível de índice e não é inserido automaticamente no histórico de fixings do KCI. As correções fazem referência a snapshots anteriores. Mudanças de configuração, versão do contrato, revisão de benchmark ou fórmula estabelecem segmentos separados. Nenhum preenchimento histórico retroativo é gerado.

Os cenários de volume do usuário preservam as condições da carga de trabalho selecionada. O tempo é estimado a partir da vazão medida sustentada ou de execuções de treinamento idênticas repetidas. Siga o link da oferta para analisar os detalhes comerciais ou abra o Workload Economics para planejar com premissas adicionais. Nenhuma reserva ou ação de compra é realizada.

Cenários de custo e prazo

O espaço de trabalho de decisão compara dois snapshots selecionados explicitamente sob o mesmo contrato, fórmula, unidades e cobertura de custos. Condições comerciais e classes de fonte diferentes são informadas. Entradas expiradas, retiradas ou corrigidas não podem sustentar uma nova comparação.

Horas produtivas = horas do snapshot por unidade de métrica × unidades solicitadas
Horas decorridas = horas produtivas / (percentual de utilização / 100)
Horas faturadas = máx(horas decorridas, mínimo de horas faturadas do usuário)
Subtotal de capacidade computacional = horas faturadas × cobrança horária do sistema em USD
Total modelado = subtotal de capacidade computacional + custos adicionais em USD inseridos explicitamente

Cada cenário usa um sistema medido e pressupõe que ele é faturado durante o tempo ocioso. O piso de faturamento altera o custo, não o tempo de conclusão. Custos adicionais deixados em branco continuam desconhecidos; nenhum total modelado é exibido. Uma estimativa de prazo exclui filas, atrasos de inicialização e restrições de capacidade. Obrigações contratuais completas, cobranças não inseridas e a disponibilidade do provedor continuam não verificadas. O resultado não é um TCO completo nem uma cotação.

O JSON do cenário para download mantém os snapshots exatos das evidências, os carimbos de data e hora das fontes e as premissas do usuário. É um relatório de um momento específico, não uma garantia de validade atual. Atualize as evidências antes de uma decisão. Os cenários não são salvos em uma conta.

6. Acesso a dados somente leitura

GET /api/index/economics?limit=50&format=json GET /api/index/economics?group=GROUP_UUID&format=csv

Limites: 1–100 snapshots; padrão 50. Parâmetros desconhecidos, duplicados ou malformados são rejeitados. As respostas incluem entradas originais, unidades, fontes, carimbos de data e hora, revisões, status atual e códigos de motivo. As leituras aplicam a visibilidade pública, excluem os atores e as notas de revisão e não expõem o registro interno de execuções. Respostas limitadas sinalizam explicitamente o truncamento.

Horários de observação e de cálculo

O campo effective_at da API registra o horário da observação do preço original. calculated_at registra quando as entradas revisadas foram combinadas. Um benchmark posterior não estabelece a economia em uma data de preço anterior; este registro não preenche retroativamente o desempenho histórico.