Skip to main content
O QUE VOCÊ DEVE TER EM MÃOS
  1. 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.
  2. Este guia, com tudo o que você precisa para ir desse link a uma integração funcional.
Links rápidos

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 mka1 ou curl simples. É assim que sua aplicação se comunica com o MKA1 em produção.
Este guia percorre todo o caminho em ordem. As etapas 1–7 levam você do link de convite à sua primeira solicitação bem-sucedida; as seções seguintes apresentam cada componente com exemplos para copiar e colar.

Antes de começar

Você só precisa de duas coisas para começar, e já tem ambas:
  1. 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.
  2. Este guia. Ele leva você do convite a uma integração de SDK funcional.
Nada para instalar antecipadamente. O console é executado no seu navegador, e você só instala um SDK quando estiver pronto para escrever código. O caminho abaixo leva cerca de 15 minutos:
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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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. Configurações de organizações no console MKA1

Acesso

LLM

Agentes

Administração

Etapa 3 · Convide sua equipe e organize o acesso

Página de detalhes da equipe em Acesso → Equipes O acesso no MKA1 é organizado como uma hierarquia simples: organização → equipes → membros, com funções controlando o que cada pessoa pode fazer e contas de serviço representando chamadores não humanos.

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

Diálogo de convite de pessoas com seleção de função e equipe Para adicionar uma pessoa, envie-lhe por e-mail um convite para a organização. Faça isso navegando até Acesso → Organizações e clicando em Convidar pessoas no canto superior direito. Compartilhe o link gerado, que abre a página Aceitar convite, mostrando a organização, quem a convidou, a função que receberá e quando o convite expira. O que a pessoa deve fazer para aceitar depende de seu estado:
  • 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.
Os convites podem expirar ou ser revogados; portanto, envie um novo link se alguém informar que o anterior não funciona.

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

Formulário de nova chave de API com etapas de identidade, vínculo de escopo e permissões Uma chave de API é a credencial que seu código envia em cada solicitação. No console, abra Acesso → Chaves de API e clique em Criar chave de API. O formulário possui quatro etapas.

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.
Alguns escopos são exclusivos de administrador (ajuste fino, registro de modelos, guardrails, pesquisa, lotes, sandbox, autorização granular) e só aparecem se você for proprietário ou administrador. Conceda o conjunto mais restrito de que a chave realmente precisa.

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 retorna 429 Too Many Requests antes que a solicitação alcance um modelo, portanto as chamadas acima do limite não custam nada.
Copie o segredo agora — ele é exibido somente uma vezAo clicar em Criar chave, o segredo completo é revelado uma única vez. Copie-o imediatamente e armazene-o em local seguro (um gerenciador de segredos ou seu .env). Se o perder, não poderá vê-lo novamente. Regenere a chave para obter um novo segredo. Trate-o como uma senha: nunca faça commit dele no controle de código-fonte nem o exponha em código do navegador.

Etapa 5 · Instale um SDK

O MKA1 fornece SDKs para TypeScript, Python e C#, além de uma CLI mka1 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):
Substitua arm64 por x86_64 em processadores Intel; pacotes .deb/.rpm e um .zip para Windows estão vinculados no guia da CLI. Em seguida, defina sua chave e execute qualquer comando:
Para uma configuração persistente que armazena segredos no chaveiro do sistema operacional, consulte autenticar a CLI.

Etapa 6 · Autentique suas solicitações

Cada solicitação transporta sua chave de API como token bearer no cabeçalho Authorization. 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

Defina X-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 via POST /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. Usar model: 'auto' permite que o gateway escolha o modelo adequado para a solicitação. Uma resposta concluída no console com entrada, raciocínio e saída
Esse é o caminho completo desde o início. Você tem uma organização, uma equipe, uma chave de API, um SDK e uma solicitação funcional. O restante deste guia apresenta os componentes que você reunirá em aplicações reais.

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)

Playground com o painel de configurações avançadas aberto O recurso Responses é como você gera texto com o MKA1. Passe uma string simples em 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

Passe 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

Defina stream: 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 estruturada input 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, defina background: 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, passe webhook_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.
Para o lado receptor:

Conversas e memória

Detalhes da conversa com itens e metadados O MKA1 oferece duas formas complementares de manter contexto entre turnos: conversas com estado (histórico mantido para uma sessão, no servidor) e o armazenamento de memória de longo prazo (a ferramenta de histórico, persistente entre sessões e vinculada por usuário final).

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.
Passe 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.
Regra prática: conversas mantêm uma sessão coerente; a ferramenta de histórico leva preferências, decisões e contexto adiante entre muitas sessões do mesmo usuário.

Arquivos, armazenamentos vetoriais e recuperação (RAG)

Um armazenamento vetorial com arquivos anexados sendo indexados O MKA1 divide a recuperação em dois recursos: Arquivos armazenam seus documentos enviados, e Armazenamentos vetoriais indexam esses arquivos para que você possa executar pesquisas semânticas nos trechos resultantes. Este é o padrão comum para assistentes baseados em documentos e respostas fundamentadas. A indexação é automática. Você envia, anexa e pesquisa; o MKA1 processa a divisão em trechos e os embeddings. Todos os exemplos abaixo usam o SDK MKA1 TypeScript ou Python. Inicialize o cliente uma vez:

1. Carregue um arquivo

Carregue o documento uma vez. A resposta retorna um objeto de arquivo cujo id é 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 em fileIds. O armazenamento retorna um ID como vs_1783478061269_mptf5b93t0q. Os arquivos anexados são indexados automaticamente.
Para adicionar mais arquivos posteriormente sem recriar o armazenamento, use createFile:
Um arquivo de armazenamento vetorial pode informar 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 com file_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, chame extract 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

Execução de um agente salvo pelo console Um agente salvo é um objeto de agente reutilizável que armazena seu próprio comportamento para que você não recrie uma solicitação Responses todas as vezes. Cada agente persiste um modelo, instruções e uma configuração de ferramentas (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 integrada web_search para que as execuções possam buscar informações externas atuais:
A matriz completa tools (conforme enviada por HTTPS) configura a ferramenta integrada:

Execute um agente

Execute enviando apenas a entrada por execução. A execução persiste status, 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.
Use 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 entrada mcp 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).
O modelo chama a ferramenta MCP permitida e retorna a mensagem final em uma solicitação. Com 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

Um modelo de prompt versionado no repositório de prompts O MKA1 separa o o quê de uma chamada LLM (seus prompts), as capacidades que você agrupa para ela (skills) e a governança que mantém o uso seguro e responsável (guardrails, limitação de taxa e auditoria).

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 Requests antes 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 identidade X-On-Behalf-Of. Cada resposta também retorna um X-Request-ID que 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_violation ou throttled e valores de policy_action de warn, block ou escalate fluem 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.
Fontes: repositórios de prompts, limitação de taxa, auditoria de uso e skills.

Fala e voz

Detalhes da geração de texto para fala com saída de áudio O MKA1 expõe fala baseada em arquivo pelo recurso 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.
Para reprodução de baixa latência que começa antes de o arquivo completo estar pronto, use 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:
Para separação de vários falantes, defina 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. Uma suíte de avaliação com conjunto de dados, avaliador e versões
  • 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 um X-Request-ID que você pode armazenar como chave de correlação.

Auditoria

A visualização Auditoria do tráfego do gateway em Administração → Auditoria Auditoria (Administração → Auditoria) é a interface de revisão para o tráfego que passou pelo gateway. Administradores do cluster veem solicitações em todas as organizações e equipes; administradores da organização veem a atividade da própria organização. Pesquise por rota, caminho ou usuário; filtre por serviço, método, status, modelo ou estado de revisão; ou cole um 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

Endpoints de webhook de alerta em Administração → Alertas Os alertas transformam falhas em webhooks. Em Administração → Alertas, registre uma URL de endpoint e escolha seu escopo: todo o cluster (administradores do cluster), sua organização (proprietários e administradores da organização) ou uma única equipe — administradores da organização podem direcionar qualquer equipe, e membros da equipe podem gerenciar webhooks da própria equipe ativa. Inscreva o endpoint em um ou ambos os tipos de evento — 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

Formulário de adição de preço de modelo na tabela de preços em Administração → Preços Cada solicitação é medida e precificada conforme a tabela de preços de modelos do seu cluster. Administradores do cluster mantêm a tabela de preços em Administração → 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.
Os preços são datados: salvar adiciona uma nova versão e nunca reformula custos anteriores. Os gastos aparecem então em dois lugares:
  • 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

Formulário de novo orçamento da organização em Administração → Orçamentos Os orçamentos limitam o gasto total por período em uma organização ou uma chave de API. Crie e gerencie-os em Administração → Orçamentos — administradores da organização gerenciam os orçamentos da organização, enquanto os orçamentos de chave de API são hoje gerenciados pelo administrador do cluster. Um orçamento tem três partes:
  • 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) ou block (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.
Cada linha de orçamento mostra gastos em tempo real contra seu limite; abra o histórico de um orçamento para revisar os eventos de limite do período e edite ou exclua orçamentos conforme as necessidades mudarem. Os orçamentos têm duas propriedades: orçamentos do cluster são tetos operacionais (somente leitura para administradores da organização), enquanto orçamentos da organização são autoimpostos. A aplicação é de melhor esforço e falha aberta, portanto defina limites com margem. As mesmas operações estão disponíveis pela API — conceda à chave os escopos exclusivos de administrador de Orçamentos (read:budgets / write:budgets) no assistente de chave da Etapa 4.

Uso

O painel de Uso com tokens ao longo do tempo e detalhamentos por modelo em Administração → Uso Uso é o livro-razão de volume por trás de preços e orçamentos — os tokens, contagens de solicitações e armazenamento de cada solicitação são medidos por organização, equipe, chave de API e usuário final. Ele existe em dois lugares:
  • 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 um bucket_width, filtre por models, user_ids ou external_user_ids (a identidade X-On-Behalf-Of) e agrupe por model, api_key_id, user_id, org_id ou background para 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.
O escalonamento automático é por implantação: réplicas mínimas e máximas, réplicas de reserva mantidas prontas para absorver picos, um limite de solicitações simultâneas encaminhadas a uma réplica antes de escalar e uma janela de inatividade (2–1200 segundos) antes de reduzir a escala.

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. Formulário de criação de agente com ferramentas integradas
  1. 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).
  2. 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).
  3. Empacote uma skill. Agrupe comportamento reutilizável por trás de um SKILL.md e carregue-o em Skills, depois anexe-o.
  4. 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.
  5. 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.
  6. 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
  1. Aceite o convite do cluster → você será proprietário de uma nova organização.
  2. Crie uma equipe e convide colegas.
  3. Crie uma chave de API nessa equipe (copie o segredo uma vez).
  4. Instale um SDK e autentique-se com Authorization: Bearer.
  5. Chame responses.create — depois componha conversas, memória, RAG, agentes, ferramentas e fala no seu aplicativo.
Boas-vindas. Agora vá criar algo.