O QUE VOCÊ DEVE TER EM MÃOS
- Um link de convite do cluster enviado a você pelo administrador do cluster. Ele torna você o proprietário de uma organização totalmente nova.
- Este guia, com tudo o que você precisa para ir desse link a uma integração funcional.
Boas-vindas ao MKA1
MKA1 é uma plataforma para criar aplicações de IA. Ela fornece à sua equipe um gateway para modelos de linguagem grandes, além dos componentes de nível superior necessários para produtos reais: agentes, conversas armazenadas, memória de longo prazo, recuperação de documentos (RAG), ferramentas e servidores MCP, prompts, skills, guardrails, fala e avaliações. Você trabalha com o MKA1 por meio de duas interfaces que compartilham as mesmas contas, equipes e recursos:- O Console - um painel web para criar e inspecionar tudo manualmente: executar prompts no Playground, salvar agentes, indexar arquivos, criar chaves de API e gerenciar sua organização e equipes. O console fica no endereço do seu cluster (por exemplo, platform.mka1.com).
- A API e os SDKs - os mesmos recursos por HTTPS, chamados pelo seu próprio código usando o SDK TypeScript, Python ou C#, a CLI
mka1ou curl simples. É assim que sua aplicação se comunica com o MKA1 em produção.
Antes de começar
Você só precisa de duas coisas para começar, e já tem ambas:- Um link de convite do cluster. Seu administrador criou um convite no cluster e enviou o link. Abri-lo torna você o proprietário de uma nova organização nesse cluster.
- Este guia. Ele leva você do convite a uma integração de SDK funcional.
Configuração de 15 minutos
- Etapa 1 Aceite o convite do cluster e crie sua organização.
- Etapa 2 Oriente-se no console.
- Etapa 3 Convide colegas de equipe e crie uma equipe (as chaves de API pertencem às equipes).
- Etapa 4 Crie uma chave de API.
- Etapa 5 Instale um SDK.
- Etapa 6 Autentique suas solicitações.
- Etapa 7 Faça sua primeira solicitação.
Etapa 1 · Aceite o convite do cluster
Abra o link de convite do cluster que seu administrador enviou. Ele contém um token de uso único e leva você à página Configure sua organização. Um convite do cluster é um convite de proprietário - aceitá-lo cria uma nova organização e define você como proprietário.Faça isto
- Abra o link de convite. A página valida o token e mostra um selo de Convite de proprietário (e uma data de expiração, se tiver sido definida). Se disser que o convite está indisponível, o token do convite expirou ou foi revogado. Peça ao administrador um novo link.
- Dê um nome à sua organização. Digite um nome como Acme Inc. Um slug de URL do espaço de trabalho será gerado para você (por exemplo, acme-inc); expanda Personalizar se quiser editá-lo. Apenas letras minúsculas, números e hífens.
- Escolha como entrar. Crie uma conta com e-mail e senha ou continue com o Google. Se o convite foi vinculado ao seu endereço de e-mail, esse endereço será preenchido e bloqueado.
- Verifique seu e-mail. Se você se cadastrou com uma senha, o MKA1 envia um e-mail de verificação. Clique no link para confirmar; em seguida, você será levado diretamente à sua nova organização.
- Você entrou. Você chega ao console como proprietário da sua organização, pronto para convidar colegas e criar chaves.
Agora você é o proprietário da organizaçãoO proprietário tem controle total: uso, membros, equipes e configurações. Todas as outras pessoas adicionadas serão administradores ou membros (abordado na Etapa 3). Se você já estava conectado ao MKA1 com um e-mail diferente daquele do convite, saia primeiro: os convites são vinculados a um endereço específico.
Etapa 2 · Conheça o console
Reserve um minuto para se orientar. A barra lateral esquerda agrupa todas as interfaces em Acesso, LLM, Agentes e Administração. Veja para que serve cada seção. Você usará várias delas nas próximas etapas.
Acesso
LLM
Agentes
Administração
Etapa 3 · Convide sua equipe e organize o acesso

A organização e seu proprietário
Quando você aceita o convite do cluster, torna-se o proprietário da organização. O proprietário tem controle total: métricas de uso, membros, equipes e configurações. Todas as outras pessoas adicionadas serão administradores ou membros:Equipes
Dentro de uma organização, você cria equipes, e os membros pertencem a uma ou mais delas. As equipes são onde o trabalho e o acesso realmente existem: chaves de API, agentes e outros recursos são vinculados a uma única equipe. Uma chave criada em uma equipe concede acesso somente aos recursos dessa equipe. Remover alguém (ou uma conta de serviço) de uma equipe revoga o acesso obtido com ela, e as chaves vinculadas a essa equipe deixam de funcionar. Isso torna as equipes o limite natural para separar projetos, ambientes ou unidades de negócios. Gerencie-as em Acesso → Equipes, onde é possível criar uma equipe e gerenciar sua lista simples de membros.Como convidar colegas

- Ainda não tem uma conta (este é o cenário mais provável) - ela se cadastra (e-mail/senha ou Google) usando o e-mail convidado, verifica-o e volta ao convite para concluir a entrada.
- Já está conectada com o e-mail convidado - um clique em Aceitar e entrar adiciona a pessoa à organização.
- Está conectada como outro e-mail - será solicitado que mude primeiro para a conta convidada, pois os convites são vinculados a um endereço específico.
Contas de serviço para produção
Para sistemas de produção, executores de CI, serviços de backend e trabalhos agendados, use uma conta de serviço em vez das credenciais de uma pessoa. Uma conta de serviço é uma identidade de máquina não humana que você anexa a uma ou mais equipes e para a qual cria chaves de API. Você pode criar uma navegando até Acesso → Contas de serviço e clicando em Nova conta de serviço no canto superior direito. Como as chaves herdam o escopo da equipe, desvincular uma conta de serviço de uma equipe (ou excluí-la) interrompe imediatamente todas as chaves criadas para ela nessa equipe, fornecendo um mecanismo de desativação claro para credenciais de produção.Etapa 4 · Crie uma chave de API

1 · Identidade
Dê um nome à chave (por exemplo, Gateway de produção) e escolha a identidade em nome da qual ela atua: Meu usuário (usa sua função na organização e a equipe selecionada) ou uma Conta de serviço (uma identidade não humana dedicada. Contas de serviço são recomendadas para casos de uso de produção).2 · Vínculo de escopo
Escolha a organização e a equipe às quais a chave pertence. Uma chave só pode ver recursos dentro dessa equipe e dessa organização — portanto, escolha a equipe cujos modelos, arquivos e agentes essa chave deve acessar. (Se você ainda não tem uma equipe, crie uma em Acesso → Equipes; as chaves precisam estar vinculadas a uma equipe.)3 · Permissões (escopos)
Escolha quais recursos a chave pode ler e gravar. Os escopos são verificados em cada solicitação. Use uma predefinição para acelerar e depois ajuste:- Padrão - os escopos cotidianos de leitura/gravação para criar aplicativos (respostas, conversas, arquivos, armazenamentos vetoriais, prompts, agentes e mais).
- Somente leitura - todos os escopos
read:e nada mais. - Todos - todos os escopos, incluindo os exclusivos de administrador. Disponível somente para proprietários e administradores da organização.
4 · Limitação de taxa (opcional)
Opcionalmente, limite a chave a um número máximo de solicitações por minuto, hora ou dia. O gateway aplica o limite e retorna429 Too Many Requests antes que a solicitação alcance um modelo, portanto as chamadas acima do limite não custam nada.
Etapa 5 · Instale um SDK
O MKA1 fornece SDKs para TypeScript, Python e C#, além de uma CLImka1 independente. Todos os clientes são autenticados com sua chave de API como token Bearer e apontam para o gateway da API. O gateway hospedado padrão é https://apigw.mka1.com.
Clusters privadosEm uma implantação privada, substitua
https://apigw.mka1.com pelo host de gateway do seu próprio cluster em todos os exemplos abaixo. Passe-o como a opção serverURL / server_url / serverUrl do SDK ou defina-o uma vez para a CLI. Seu administrador pode informar a URL do gateway (ela é a contraparte de API do endereço do seu console).TypeScript - @meetkai/mka1
O SDK TypeScript é instalado pelo registro de pacotes npm:Python - meetkai-mka1
Requer Python 3.10 ou mais recente:C# - MeetKai.MKA1
CLI - mka1
Binários pré-compilados são fornecidos em downloads.mka1.com. No macOS (Apple silicon):Etapa 6 · Autentique suas solicitações
Cada solicitação transporta sua chave de API como token bearer no cabeçalhoAuthorization. Para aplicativos de servidor multiusuário, você também envia X-On-Behalf-Of para identificar para qual usuário final seu uma solicitação é feita.
Quando enviar X-On-Behalf-Of
DefinaX-On-Behalf-Of como um identificador estável do seu próprio sistema (por exemplo, user_123) sempre que seu servidor estiver agindo para um usuário final específico. Isso mantém as solicitações, arquivos, memória e uso desse usuário corretamente atribuídos. Use um ID que não mude. Nunca use um e-mail ou nome de exibição.
- Somente Authorization - seu próprio fluxo de trabalho de backend, não vinculado a nenhum usuário final.
- Authorization + X-On-Behalf-Of - seu servidor agindo para um dos seus usuários finais; o uso e os recursos permanecem associados a ele.
Emita tokens de curta duração (opcional)
Quando um serviço downstream ou cliente de navegador precisar chamar o MKA1 sem manter sua chave de API, troque a chave por um JWT de curta duração viaPOST /api/v1/authentication/api-keys/exchange-token, depois use esse JWT como token bearer. Consulte o guia de autenticação e a análise detalhada.
Etapa 7 · Faça sua primeira solicitação
Com uma chave em mãos, gere sua primeira resposta. Usarmodel: 'auto' permite que o gateway escolha o modelo adequado para a solicitação.

Crie com a plataforma
Tudo abaixo pode ser chamado com a chave de API que você acabou de criar. Cada seção é fundamentada nos guias oficiais em docs.mka1.com. Siga os links em linha para a referência completa.Gere respostas (a chamada principal)

input para um prompt de turno único; o resultado inclui o texto gerado em output_text. Use auto_routing: true para permitir que o gateway escolha o modelo certo para você.
Chamada básica
X-On-Behalf-Of quando estiver agindo para um usuário final; caso contrário, omita-o.
O que auto_routing faz
auto_routing é um sinalizador de solicitação opcional, separado do alias de modelo auto. Quando você define auto_routing: true, o gateway avalia a complexidade da solicitação e a encaminha para o melhor modelo irmão quantizado, MoE ou denso dentro da família de modelos solicitada. Ele nunca troca para um modelo não relacionado e recorre ao modelo solicitado se essa família não tiver um irmão correspondente.
A pontuação é aditiva. Ela aumenta com o comprimento do prompt, muitas ferramentas ou ferramentas de alta autonomia (por exemplo, code_interpreter, mcp), tool_choice: 'required', saída estruturada, um max_output_tokens grande, contexto de vários turnos e indícios de raciocínio complexo no texto (debug, refactor, plan, incident, code); diminui para prompts curtos e tarefas simples reconhecidas (translate, summarize, classify, extract). O total escolhe a camada. Pontuações maiores são encaminhadas para dense, intermediárias para moe e baixas para quantized. Um reasoning.effort correspondente é definido (de minimal até xhigh), a menos que você mesmo já tenha definido o esforço. Assim, um prompt curto como “resuma isto” é encaminhado para quantized com esforço minimal, enquanto um relatório longo de incidente é encaminhado para dense com esforço high (ou xhigh).
Sempre que o roteamento é executado, os metadados da resposta registram routed_model - a variante realmente usada. Adicione auto_routing_debug: true para também obter um campo de metadados auto_routing_debug: uma string JSON compacta com o modelo solicitado e roteado, a camada escolhida, o esforço de raciocínio, a pontuação e os motivos da decisão. Ele é registrado mesmo quando nenhuma variante irmã está disponível, sendo útil para validar o comportamento da implantação. Deixe esse campo desativado para o tráfego normal de produção.
Transmita texto enquanto ele é gerado
Definastream: true para receber eventos enviados pelo servidor em vez de esperar pela resposta completa. Use-o para renderizar saída parcial à medida que ela chega.
Entrada multimodal (imagem + texto)
A API Responses aceita texto, imagens, áudio e arquivos em uma solicitação. Use uma matriz estruturadainput de itens de mensagem, em que content é uma matriz que combina input_text e input_image (imagem por URL, URI de dados base64 ou um file_id carregado).
Respostas em segundo plano
Para trabalhos de longa duração, definabackground: true (com stream: false) para obter uma resposta enfileirada imediatamente; depois recupere o resultado consultando mka1.llm.responses.get(...) ou por streaming. Consulte o guia de respostas em segundo plano.
Webhooks em vez de consulta
Em vez de consultar, passewebhook_url (e opcionalmente webhook_secret) ao criar uma resposta em segundo plano. O gateway envia por POST cada mudança de status ao seu endpoint — response.queued, response.in_progress, response.completed, response.failed, response.incomplete, response.cancelled — como { event, resource_id, created_at, data }, onde data é o objeto completo do evento.
Com um segredo definido, cada entrega inclui X-Webhook-Signature: sha256=<hex>, um HMAC-SHA256 do corpo JSON bruto — verifique-o antes de confiar na carga útil. A entrega nunca bloqueia a resposta: três tentativas com espera exponencial e um tempo limite de 10 segundos. O endpoint precisa estar publicamente acessível — endereços privados e localhost são rejeitados. O gateway exige que webhook_secret tenha pelo menos 16 caracteres.
Conversas e memória

Conversas com estado
Uma conversa é um contêiner no servidor que o gateway usa para manter o estado entre solicitações Responses, para que você nunca reenvie todo o histórico. Crie uma e passe seu ID em cada resposta subsequente.conversation em cada solicitação; o gateway mantém a sequência para você. Use uma conversa quando quiser um contêiner reutilizável e inspecionável para muitos turnos e a capacidade de listar, buscar ou excluir itens posteriormente. Use previous_response_id quando precisar apenas ramificar de uma única resposta anterior.
Armazenamento de memória de longo prazo
A ferramenta de histórico fornece ao modelo memória que persiste entre sessões. Adicione{ type: 'history' } a tools e defina store: true; cada par solicitação/resposta é indexado em segundo plano e pesquisado semanticamente (embeddings vetoriais) quando o modelo decide que precisa se lembrar de algo. A memória é isolada por usuário final por meio do cabeçalho X-On-Behalf-Of.
Arquivos, armazenamentos vetoriais e recuperação (RAG)

1. Carregue um arquivo
Carregue o documento uma vez. A resposta retorna um objeto de arquivo cujoid é semelhante a file_1783478060914_iemq10dh5h — passe-o aos armazenamentos vetoriais na próxima etapa.
2. Crie um armazenamento vetorial e anexe arquivos
Crie um armazenamento vetorial, passando um ou mais IDs de arquivos enviados emfileIds. O armazenamento retorna um ID como vs_1783478061269_mptf5b93t0q. Os arquivos anexados são indexados automaticamente.
createFile:
status: "in_progress" enquanto a indexação é executada; portanto, aguarde a conclusão do processamento antes de confiar nos resultados da pesquisa.
3. Pesquise trechos relevantes no armazenamento
Execute uma pesquisa semântica para recuperar os trechos mais relevantes para uma pergunta do usuário. A resposta retorna correspondências classificadas comfile_id, filename, dados de pontuação e conteúdo do trecho. Alimente esse texto na lógica da sua própria aplicação ou em uma solicitação Responses.
Bônus: extração estruturada
Quando precisar obter JSON tipado de um documento em vez de trechos de texto livre, use o recurso Extract. Para trabalho pontual, chameextract com um JSON Schema em linha — passado como uma string JSON — e o arquivo a ser lido. Para trabalhos repetidos, salve o esquema uma vez com createSchema (aqui o esquema é um objeto simples) e execute-o em muitos arquivos com extractWithSchema, referenciando o id do esquema retornado em data.id. Nomeie um modelo explicitamente em cada chamada de extração. Uma resposta bem-sucedida retorna success, um objeto data com os campos extraídos e metadata sobre a execução.
Agentes, ferramentas e MCP

tools, tool_choice, parallel_tool_calls, max_tool_calls, text, reasoning). Ao executá-lo, o serviço combina sua entrada por execução com a configuração salva e a encaminha à API Responses por meio do mkllm-gateway. Cada execução persiste a entrada e o resultado Responses upstream, portanto você também obtém o histórico de execuções automaticamente. Os agentes recebem um id estável como agt_....
Crie um agente
Crie um agente uma vez usando os SDKs MKA1 Python, TypeScript ou C#, incluindo uma ferramenta integradaweb_search para que as execuções possam buscar informações externas atuais:
tools (conforme enviada por HTTPS) configura a ferramenta integrada:
Execute um agente
Execute enviando apenas a entrada por execução. A execução persistestatus, o gateway_response armazenado e gateway_response_id da chamada upstream. Se a execução usou web_search, o gateway_response persistido incluirá as entradas de chamada da ferramenta.
sdk.agents.list_agents(...) / sdk.agent_runs.list_agent_runs(agent_id=...) para inspecionar agentes salvos e execuções anteriores.
Histórico de versões e reversão
Cada alteração confirmada em um agente salvo — criar, atualizar, reverter — adiciona uma versão imutável, para que o histórico de configuração de um agente seja sempre inspecionável. Reverter não reescreve o histórico: acrescenta uma nova versão restaurada a partir do destino.Anexe um servidor de ferramentas MCP
Além das ferramentas integradas, você pode permitir que o modelo chame ferramentas de um servidor MCP externo adicionando uma entradamcp a tools. Defina require_approval como "never" para executar imediatamente ou "always" para pausar aguardando aprovação do usuário final. Limite as ferramentas chamáveis com allowed_tools; passe credenciais upstream em headers (elas são mascaradas nas respostas armazenadas).
require_approval: "always", crie a resposta em modo de segundo plano, consulte-a e processe o item mcp_approval_request enviando de volta um mcp_approval_response.
Prompts, skills e guardrails

Repositório de prompts
A API Prompts armazena, versiona e renderiza centralmente modelos de prompt. Cada alteração de modelo cria uma versão imutável, para que você tenha um histórico completo de alterações e possa reverter para qualquer versão anterior a qualquer momento. Uma reversão não é destrutiva e apenas alterna a versão ativa. Os modelos usam espaços reservados{{variable}} que são renderizados no servidor quando você recupera um prompt, permitindo reutilizar um único modelo em diferentes contextos. Os prompts são isolados por chave de API.
Skills
Skills são pacotes reutilizáveis e versionados de capacidades que você carrega para o gateway. Cada skill empacota o comportamento de ferramentas por trás de um manifesto SKILL.md. O nome e a descrição da skill são lidos diretamente desse manifesto. Você pode enviar um único conjunto de arquivos ou um pacote completo, gerenciar versões (cada skill acompanha uma versão padrão e a mais recente) e revisar cada arquivo antes de criá-la. Gerencie skills no painel em Skills ou pela API Skills.Guardrails, limitação de taxa e auditoria de uso
Estes três recursos de governança mantêm o tráfego delegado e multiusuário controlado e responsável:- Limitação de taxa - Cada chave de API pode ter uma cota em uma janela configurável — por minuto, hora ou dia. Quando uma chave excede seu limite, o gateway retorna
429 Too Many Requestsantes que a solicitação alcance o modelo; portanto, nenhum token é consumido e nenhum uso é cobrado. Trate respostas 429 com novas tentativas de espera exponencial. - Auditoria de uso - Revise o uso de tokens, solicitações e armazenamento por organização e equipe em Administração → Uso, filtrável por usuário (membros da organização). Para relatórios por usuário final, consulte a API de uso com o filtro
external_user_ids— a identidadeX-On-Behalf-Of. Cada resposta também retorna umX-Request-IDque você pode armazenar como chave de correlação. - Guardrails - As decisões de política são registradas no mesmo fluxo de auditoria: resultados como
policy_violationouthrottlede valores depolicy_actiondewarn,blockouescalatefluem para a página Guardrails, fornecendo um caminho consistente de um relatório de uso à ação exata que foi permitida, avisada, bloqueada ou escalada.
Fala e voz

llm.speech do SDK. Use speak para texto para fala e transcribe para fala para texto. Para conversas bidirecionais em tempo real, use o modo de voz avançado. O modo de voz avançado é abordado separadamente.
Texto para fala
speak retorna um arquivo WAV completo. O corpo da resposta é áudio binário e os cabeçalhos da resposta incluem X-Language-Code.
speakStreaming e escolha mp3 (menor) ou pcm (não compactado):
Fala para texto
transcribe aceita um arquivo de áudio (FLAC, MP3, MP4, M4A, OGG, WAV, WebM, PCM e outros) e retorna a transcrição, além do idioma e confiança detectados:
includeSpeakerData: true (requer áudio WAV ou PCM). A resposta inclui então uma matriz speakers com segmentos rotulados e tempos offset_ms / duration_ms.
Arquivos-fonte: fala, saída multimodal.
Avalie e observe
Quando algo funcionar, o MKA1 ajuda você a medi-lo e monitorá-lo em produção.
- Avaliações - Crie uma suíte de avaliação a partir de conjuntos de dados, prompts e avaliadores; depois inicie execuções duráveis em um ou mais modelos. Acompanhe a precisão e as pontuações por amostra, e compare modelos em uma classificação. Use isso para escolher um modelo e detectar regressões antes da entrega.
- Execuções - Inspecione a entrada armazenada de cada execução de agente, a resposta do gateway, a transcrição (mensagens, raciocínio e chamadas de ferramentas) e o JSON bruto. Eventos brutos são transmitidos somente enquanto a execução está ativa.
- Uso e auditoria - Revise o uso de tokens, solicitações e armazenamento por organização e equipe em Administração → Uso, e filtre por usuário final quando enviar
X-On-Behalf-Of. Cada resposta também retorna umX-Request-IDque você pode armazenar como chave de correlação.
Auditoria

X-Request-ID — retornado em cada resposta de API — para ir à solicitação exata. Sinalize entradas para revisão, agrupe solicitações relacionadas em casos e exporte dados de resposta para análise offline.
Alertas

response.failed (uma solicitação de resposta falhou no provedor do modelo) e gateway.request.failed (qualquer solicitação do gateway retornou um 5xx) — ou deixe a inscrição vazia para receber todos. Filtros opcionais restringem a entrega a chaves de API, códigos de erro ou modelos específicos.
Cada endpoint tem uma página de detalhes que mostra sua configuração, seu segredo de assinatura (revelar, copiar ou rotacionar) e entregas recentes com cargas úteis e status de sucesso / falha / pendência. A partir dela, você pode reenviar uma entrega, disparar um alerta de teste durante a integração e editar, desativar ou excluir o endpoint — editar nunca altera o segredo de assinatura.
Preços, orçamentos e uso
Cada solicitação passa por um pipeline de faturamento: o uso registra os volumes, a tabela de preços de modelos os transforma em custos e os orçamentos aplicam limites ao resultado. Esta seção cobre os três.Preços

- Moeda do cluster - A moeda na qual todos os preços e orçamentos são denominados.
- Preços dos modelos - A tabela de taxas padrão do cluster, um preço por modelo. As dimensões de taxa acompanham a modalidade do modelo: tokens de entrada, saída, entrada em cache e raciocínio para LLMs; áudio e caracteres para fala; taxas por imagem com níveis opcionais por tamanho; pesquisa na web.
- Substituições da organização - Preços por organização para quando uma organização é faturada de forma diferente do padrão do cluster.
- Taxas efetivas - Uma visualização de resolução que mostra qual preço — padrão do cluster, substituição da organização ou sem preço — cada modelo resolve para uma determinada organização. Modelos sem preço são cobrados a 0.
- Administração → Uso - Gasto total precificado conforme a tabela de preços, detalhado por organização, equipe, chave de API e modelo — junto com os volumes subjacentes (consulte Uso abaixo).
- A API - Consulte gastos em qualquer intervalo de tempo, agrupados por modelo, chave de API, equipe, organização ou usuário final (a identidade
X-On-Behalf-Of). Este é o feed para sistemas de faturamento; os Orçamentos (abaixo) aplicam limites aos mesmos gastos.
Orçamentos

- Período e limite - Diário, semanal ou mensal, com um limite na moeda do cluster. As janelas de gasto são redefinidas nos limites de calendário UTC.
- Limites - Porcentagens exclusivas do limite, cada uma combinada com uma ação:
alert(notificar) oublock(rejeitar solicitações posteriores). Um orçamento que ultrapassou um limite de bloqueio mostra Bloqueado nas colunas em tempo real Gasto e Status. - Webhook de alerta (opcional) - Uma URL e segredo de assinatura HMAC que recebe notificações de limite.
read:budgets / write:budgets) no assistente de chave da Etapa 4.
Uso

- No console - Administração → Uso mostra um gráfico de tokens ao longo do tempo (24h / 7d / 30d), detalhamentos por categoria (Responses, Completions, Embeddings, Classify, Extract) com tokens de entrada/saída e contagens de solicitações por modelo, linhas por usuário final, armazenamento de arquivos e vetores e operações de sandbox — tudo exportável como CSV. A seção de gastos precifica esses volumes conforme a tabela de preços de modelos (consulte Preços acima).
- Pela API - Endpoints por categoria (
llm.usage.responses,completions,conversations,embeddings,extract,classify,vectorStores,files) retornam séries agrupadas por intervalos de tempo. Escolha umbucket_width, filtre pormodels,user_idsouexternal_user_ids(a identidadeX-On-Behalf-Of) e agrupe pormodel,api_key_id,user_id,org_idoubackgroundpara relatórios por dimensão.
Servimento
O Servimento transforma os aceleradores do seu cluster — GPU, NPU ou TPU — em endpoints de inferência com escalonamento automático para os modelos que você escolher. Ele fica em sua própria seção Servimento na barra lateral (administradores da organização e do cluster), e sua organização precisa ser provisionada para servimento pelo operador do cluster antes do primeiro uso. Seis componentes:- Implantações - Um modelo servido atrás de um endpoint de inferência em aceleradores dedicados, suportado por vLLM ou SGLang. Alterações de configuração criam uma nova revisão — reverta para qualquer revisão anterior a qualquer momento — enquanto alterações de escalonamento são aplicadas no local. A URL do endpoint é atribuída assim que a implantação estiver pronta, e a autenticação do endpoint exige que os chamadores apresentem uma chave de API válida. Cada implantação expõe status, réplicas, revisões, logs e métricas.
- Modelos - Registre um modelo servível por nome e origem, opcionalmente fixando uma revisão de branch, tag ou commit para implantações reproduzíveis.
- Imagens - Crie imagens de contêiner personalizadas (imagem OCI base, pacotes apt, comandos de compilação) para mecanismos de servimento e trabalhos de ajuste fino; as implantações usam por padrão a imagem padrão do mecanismo.
- Trabalhos de ajuste fino - Treine em aceleradores do cluster: um modelo base, um conjunto de dados, uma estratégia (LoRA por padrão ou ajuste fino completo) e hiperparâmetros de forma livre. Acompanhe logs e a linha do tempo de eventos, colete checkpoints e cancele a qualquer momento.
- Aceleradores - Os tipos de aceleradores disponíveis para sua organização (por exemplo, A100, H100) e seus limites por tipo.
- Volumes e segredos - Volumes persistentes (de tamanho fixo ou elásticos, crescendo sob demanda) e segredos como um hf-token, injetados nas implantações como variáveis de ambiente.
Juntando tudo: crie um agente de ponta a ponta
Os componentes se compõem. Este é o fluxo principal de ponta a ponta: indexe conhecimento, conecte ferramentas, empacote uma skill, monte um agente, execute-o e rastreie o resultado.
- Indexe o conhecimento. Carregue seus documentos como Arquivos e anexe-os a um Armazenamento vetorial para que o agente possa fundamentar as respostas no seu conteúdo (consulte Arquivos, armazenamentos vetoriais e recuperação).
- Conecte ferramentas. Registre um servidor MCP (ou use ferramentas integradas como
web_search) para que o agente possa realizar ações e buscar dados atualizados (consulte Agentes, ferramentas e MCP). - Empacote uma skill. Agrupe comportamento reutilizável por trás de um SKILL.md e carregue-o em Skills, depois anexe-o.
- Monte o agente. Crie um agente salvo com um modelo, instruções e esse conjunto de ferramentas. Você configura o agente uma vez, para não recriar a solicitação a cada chamada.
- Execute-o. Execute o agente com entrada nova pelo console ou
POST /api/v1/agents/{id}/runs. Cada execução persiste sua entrada e a resposta do gateway. - Rastreie a execução. Abra Execuções para revisar a transcrição armazenada e confirmar que o agente chamou as ferramentas certas.
Referência e suporte
Mantenha estes recursos por perto enquanto desenvolve:Resumo rápido
- Aceite o convite do cluster → você será proprietário de uma nova organização.
- Crie uma equipe e convide colegas.
- Crie uma chave de API nessa equipe (copie o segredo uma vez).
- Instale um SDK e autentique-se com
Authorization: Bearer. - Chame
responses.create— depois componha conversas, memória, RAG, agentes, ferramentas e fala no seu aplicativo.