Como trabalhamos

Produto e uso ilimitado

A assinatura dá acesso ao modelo selecionado por 3, 7 ou 30 dias, sem cota total de tokens de entrada ou saída. Cada assinatura inclui quatro solicitações simultâneas. As chaves da conta usam um pool compartilhado de slots do modelo correspondente. O slot é liberado quando a operação termina.

A Rate Cloud gerencia a localização dos pesos, os mecanismos de execução, os perfis de precisão e a distribuição de solicitações. Os equipamentos são alugados de proprietários empresariais. A capacidade disponível dos clusters complementa a reserva estável. O uso ilimitado se refere aos tokens durante o período; contexto, tempo de operação, simultaneidade e limites de proteção continuam finitos.

Servidores e computação

A arquitetura usa plataformas Huawei Atlas e aceleradores Ascend: Atlas 800I A2 e A3 para modelos grandes, Atlas 900 A2 PoD e A3 SuperPoD para grupos distribuídos. Atlas 500 e 500 A2 destinam-se a pequenas tarefas de serviço; Atlas 800 com Atlas 300I Duo é uma classe de compatibilidade separada.

O Atlas 800I A2 contém 8 NPU de 64 GB cada. O Atlas 800I A3 contém 8 NPU físicas de 128 GB, representadas como 16 dispositivos lógicos. São duas representações da mesma memória e não devem ser somadas. O suporte é verificado separadamente para cada modelo. Solicitações inteiras são transferidas entre locais; cálculos fortemente acoplados em uma réplica usam uma rede local compatível.

Modelos e quantização

O mesmo modelo é preparado em várias variantes de quantização. Por exemplo, o GLM 5.3 pode atender diferentes solicitações em um perfil de qualidade, equilibrado ou econômico. O sistema inteligente avalia a tarefa e escolhe uma variante adequada desse mesmo modelo. O usuário só precisa escolher o modelo; não precisa mudar manualmente a quantidade de bits.

O perfil de qualidade usa formato original verificado, W8A8 ou outra configuração aprovada. O perfil equilibrado combina a precisão dos componentes, por exemplo 4 e 8 bits com média efetiva de cerca de 6 bits. Isso não é uma promessa de INT6 universal. O perfil econômico usa W4A16, W4A8 ou MXFP4 verificados do mesmo modelo. A disponibilidade depende do equipamento e da verificação de qualidade.

Imagine os números do modelo como valores escritos com precisões diferentes. Uma representação compacta ocupa menos memória, mas pode afetar o resultado. Assim, uma busca simples pode usar uma variante compacta verificada, enquanto código complexo, matemática e ferramentas podem usar um perfil de qualidade. Em caso de dúvida, o sistema escolhe qualidade. Flash e Pro continuam sendo modelos distintos e não substituem um ao outro.

Verificação de qualidade

Cada perfil é verificado em relação à versão original exata com tarefas públicas, sintéticas e preparadas especialmente: código, matemática, contexto longo, ferramentas e JSON estrito. Conversas de usuários não são usadas para treinamento ou calibração.

A verificação abrange qualidade do resultado, memória, velocidade e funcionamento correto da API. Baixa largura de bits só é permitida para tarefas adequadas. Aumentar a largura de bits de pesos de poucos bits já publicados não recupera informações perdidas. Alterar reasoning_effort é uma configuração independente e não é apresentado como efeito da quantização.

Percurso da solicitação

Conexão segura → verificar chave, assinatura e slot livre → determinar requisitos → escolher o perfil do modelo selecionado → atribuir uma réplica pronta → transmitir a resposta → liberar o slot e limpar o conteúdo temporário.

Uma operação lógica tem um request_id; cada tentativa de computação tem um attempt_id. Antes do início da saída, é permitida nova tentativa em uma réplica compatível dentro do prazo total. Depois que o fluxo começa, o início de uma resposta não é unido à continuação de uma nova geração. O cliente deve considerar incompleto um fluxo interrompido.

Distribuição inteligente

O roteador considera contexto, imagens, ferramentas, formato da resposta, complexidade da tarefa, memória disponível, fila, saúde da réplica e prazo de alocação de recursos. Código, matemática, esquemas estritos, ferramentas e tarefas incertas recebem prioridade de qualidade. Uma pergunta curta não é necessariamente simples.

O custo é considerado apenas entre rotas adequadas. A versão dos pesos e as funções permitidas ficam fixas durante a operação. Servidores incompatíveis são excluídos antes da atribuição. Se não houver capacidade adequada, pode haver espera dentro do orçamento interno ou erro explícito de indisponibilidade temporária; outro modelo nunca é substituído sem aviso.

Resiliência e recuperação

Grupos estáveis sustentam a operação principal e a recuperação. Grupos interrompíveis adicionais aumentam a capacidade. Ao receber aviso de revogação, o servidor para de aceitar novas operações, enquanto tarefas inacabadas continuam dentro do prazo original. A perda de um acelerador crítico exclui toda a réplica dependente.

Uma réplica preparada passa pelo carregamento dos pesos, aquecimento e verificações de prontidão. Grupos de falha independentes reduzem o impacto de uma interrupção. Repetir a computação pode aumentar a latência. A arquitetura de recuperação não garante disponibilidade 24/7 de cada modelo.

Segurança da infraestrutura

As transferências externas são protegidas por TLS. As conexões entre serviços usam verificação de identidade e mTLS. Os direitos de acesso são concedidos conforme a necessidade de trabalho. Chaves, contas, projetos e áreas de cache são isolados. Segredos de API e corpos de solicitações não devem aparecer em registros nem backups.

A segurança da conexão é diferente da proteção dos dados durante a computação. Equipamentos alugados têm seu próprio limite de confiança: não é possível prometer execução protegida por hardware em todo acelerador. Se o controle for perdido, o nó é excluído e sua autoridade revogada; o retorno exige análise e limpeza.

Exclusão de solicitações e cache temporário

A Rate Cloud não cria um histórico permanente do texto de solicitações e respostas nem treina modelos com dados de usuários. O conteúdo é processado em memória temporária. A meta de limpeza dos buffers de aplicação gerenciados e disponíveis é de até 5 segundos após a entrega bem-sucedida e até 30 segundos após um erro final, cancelamento ou perda de conexão.

O cache KV de computação isolado tem prazo próprio: até 5 minutos sem reutilização e até 15 minutos de idade absoluta. Após o prazo, o bloco deixa de ser usado em novas correspondências; uma operação que já o utiliza pode terminar dentro do próprio prazo. A memória é limpa após a liberação da última referência. O cache não é gravado em disco persistente nem incluído em snapshots.

A chave de compatibilidade inclui conta, modelo, revisão dos pesos, quantização, tokenizador, modelo de conversa e instruções do sistema. O índice é protegido por HMAC. O usuário não pode selecionar a área de cache de outra pessoa. A política de processamento do projeto define o perfil sem cache entre solicitações. O histórico em um aplicativo cliente é controlado pelo próprio aplicativo.

Metadados técnicos incluem identificadores, modelo, perfil, horário, duração, usage, estado dos slots e códigos de erro. Registros detalhados são excluídos após 30 dias. Não incluem prompts, respostas, argumentos de ferramentas, arquivos nem tokens de autorização. Dados da conta, pagamentos e solicitações voluntárias de suporte têm finalidades e prazos de retenção separados.

Disponibilidade e compensação

A disponibilidade dos modelos 24 horas por dia, 7 dias por semana não é garantida. Se todo o sistema ficar completamente indisponível por mais de 4 horas seguidas e as solicitações retornarem HTTP 503, as assinaturas pagas são prorrogadas: um prazo de 3 dias recebe 12 horas, um de 7 dias recebe 1 dia e um de 30 dias recebe 3 dias.

Esta regra se aplica apenas à interrupção total do sistema com HTTP 503. Erros de um modelo específico, resposta lenta, limites de simultaneidade e outros códigos não se qualificam. Para verificar o incidente, contate o suporte com o horário e os IDs das operações, sem enviar segredo de API ou conteúdo das solicitações. Os direitos obrigatórios do usuário continuam válidos.

Versões e critérios de implementação

A aceitação verifica a preservação do modelo selecionado, a prioridade da qualidade, a recuperação dentro do prazo original, o isolamento do cache, a exclusão do conteúdo, a proteção das conexões e a ausência de textos na análise. Alterações nos contratos de API, cache e perfis devem estar alinhadas entre documentação, painel e condições.