Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Nota
O Pesquisa de IA do Azure está disponível através do portal Azure, APIs REST e SDKs do Azure. Também sustenta o Foundry IQ, a camada de conhecimento gerida que transforma conteúdos empresariais em bases de conhecimento reutilizáveis e conscientes de permissões para agentes no portal Microsoft Foundry.
O Pesquisa de IA do Azure oferece dois modelos de preços que gerem a capacidade de forma diferente:
Dedicado: Planeie a capacidade dimensionando réplicas e partições e selecionando um nível de serviço.
- Capacidade de pré-provisionamento direto através do uso de réplicas e partições.
- Estima o armazenamento necessário (partições) e o débito necessário (réplicas).
- Escolha um nível de serviço para fornecer a capacidade necessária com base na procura máxima esperada.
- Depois de configurar a capacidade antecipadamente, paga uma tarifa horária medida por Unidades de Busca (SUs), independentemente do uso.
Serverless (Pré-visualização): O serviço gere automaticamente a capacidade com base na utilização e nos limites do serviço. Não precisa de provisionar capacidade previamente. Em vez disso, otimize a eficiência da sua carga de trabalho para gerir os custos.
- A capacidade escala automaticamente com a procura (pode escalar até zero quando está inativa).
- És faturado com base no uso real, medido pelas Unidades de Cálculo (CUs) e armazenamento.
- Em vez da infraestrutura, o planeamento foca-se nestes fatores de custo: padrões de consulta, tamanho e crescimento do índice e padrões de ingestão de dados. Consulte Otimizar os custos do modelo Serverless.
| Dimensão | Dedicado | Serverless |
|---|---|---|
| Modelo de capacidade | Aprovisionado (réplicas × partições) | Baseado no consumo |
| Scaling | Manual | Automatic |
| Controlo do utilizador | Explícito (configurar réplicas e partições) | Indireto (influenciado pelas características da carga de trabalho) |
| Billing | Tarifa horária fixa por Unidade de Pesquisa (SUs) | Pagamentos baseados no consumo para Unidades de Cálculo (CUs) e armazenamento |
| Custo inativo | Sempre incorrido (capacidade mínima provisionada) | Reduz para zero quando está inativo |
| Foco na otimização | Dimensionamento da infraestrutura | Eficiência da carga de trabalho |
| Melhor para | Cargas de trabalho previsíveis e constantes | Cargas de trabalho variáveis, intermitentes ou multicliente, incluindo cenários orientados por agentes |
| Abordagem de planeamento de capacidade | Dimensionar e escalar a infraestrutura (réplicas e partições) | Otimizar a eficiência da carga de trabalho e os padrões de utilização |
| Impacto na ineficiência | Latência e pressão de escalonamento | Aumento direto de custos |
Importante
O nível Serverless Developer está atualmente em pré-visualização. Esta pré-visualização é fornecida sem um acordo de nível de serviço e não é recomendada para cargas de trabalho em produção. Certas funcionalidades podem não ser suportadas ou podem ter capacidades limitadas. Para mais informações, consulte Termos Suplementares de Utilização para Microsoft Azure Previews.
A faturação para o escalão Serverless Developer tem início em 13 de setembro de 2026. As taxas de utilização a partir dessa data aparecem na sua fatura Azure. Não é cobrado pelo uso antes de 13 de setembro de 2026. O Serverless Developer é um nível pago assim que a faturação começa.
A camada Serverless Developer não suporta migração para ou de outras categorias de preços e algumas funcionalidades disponíveis noutros níveis não são suportadas durante a Pré-visualização Pública. Os limites de serviço, funcionalidades suportadas e detalhes de preços podem mudar antes da disponibilidade geral.
Durante a pré-visualização, o modelo de preços Serverless é suportado apenas em regiões específicas.
Para saber mais, veja como:
- Planear e gerir custos
- Escolha um modelo de preços e um nível de serviço
- Otimize custos com o modelo de preços Serverless
Capacidade planeada para o modelo Dedicado
No modelo Dedicado, fornece capacidade utilizando Unidades de Pesquisa (SU):
- Unidade de pesquisa (SU) = réplicas × partições
- Réplica: Cópias do motor de pesquisa. Oferece capacidade de processamento de consultas e alta disponibilidade.
- Partição: Unidades de armazenamento. Fornece armazenamento e taxa de indexação.
Cada serviço começa com 1 réplica × 1 partição (1 SU). Pode adicionar ou remover réplicas e partições independentemente para acomodar cargas de trabalho flutuantes. Adicionar capacidade aumenta o custo de execução de um serviço de pesquisa.
| Conceito | Definição |
|---|---|
| Unidade de pesquisa | Um único aumento da capacidade total disponível. É necessário um mínimo de uma unidade de pesquisa para executar o serviço. Dependendo do seu nível de preço, o máximo varia de uma a 36 unidades. O número de unidades de pesquisa é igual ao número de réplicas multiplicado pelo número de partições: R × P = SU. Cada serviço começa com uma réplica e uma partição, que consome uma unidade: 1 × 1 = 1. Adicionar uma segunda réplica consome duas unidades: 2 × 1 = 2. Uma unidade de pesquisa é também a unidade de faturação de um serviço de pesquisa. |
| Réplica | Instâncias do serviço de pesquisa, usadas principalmente para balanceamento de carga em operações de consulta. Cada réplica hospeda uma cópia de um índice. Se você alocar três réplicas, terá três cópias de um índice disponíveis para atender às solicitações de consulta. |
| Partição | Armazenamento físico e E/S para operações de leitura/gravação (por exemplo, ao reconstruir ou atualizar um índice). Cada partição tem uma fatia do índice total. Caso aloque três partições, o seu índice será dividido em terços. |
Analise a tabela de partições e réplicas para obter possíveis combinações que permaneçam abaixo do limite de 36 unidades.
As características físicas das réplicas e partições, como a velocidade de processamento e as entradas/saídas do disco, variam consoante o nível de serviço. Num serviço de pesquisa padrão, as réplicas e partições são mais rápidas e maiores do que as de um serviço básico.
Quando adicionar capacidade para o modelo dedicado
Considere adicionar réplicas ou partições quando:
- A latência das consultas aumenta ou os critérios do acordo de nível de serviço não são cumpridos.
- A frequência dos erros HTTP 503 (Serviço indisponível) aumenta.
- A frequência dos erros HTTP 429 (Demasiados pedidos) aumenta, indicando limitação de pedidos.
- São esperados grandes volumes de consulta.
- As tarefas de indexação estão lentas ou atrasadas.
- A taxa de transferência de armazenamento ou indexação é insuficiente.
Orientação de escalabilidade:
- Adicione réplicas para aumentar a capacidade de processamento de consultas e a disponibilidade.
- Adicione partições para aumentar o armazenamento e o desempenho de indexação.
- Cargas de trabalho com utilização intensiva de consultas normalmente requerem mais réplicas.
- Índices grandes podem exigir réplicas adicionais para manter o desempenho.
Importante
As operações de escalabilidade podem demorar tempo a concluir e aumentar os custos. Valide sempre as alterações utilizando testes de desempenho e estimativas de preços.
O nível de serviço que escolhes determina o tamanho e a velocidade da partição. Cada nível é otimizado em torno de um conjunto de características que se ajustam a vários cenários. Se você escolher uma camada mais avançada, talvez precise de menos partições do que se optar pelo S1. Uma das perguntas que você precisa responder por meio de testes autodirigidos é se uma partição maior e mais cara produz melhor desempenho do que duas partições mais baratas em um serviço provisionado em um nível mais baixo.
Um único serviço deve ter recursos suficientes para lidar com todas as cargas de trabalho (indexação e consultas). Nenhuma das cargas de trabalho é executada em segundo plano. Você pode agendar a indexação para momentos em que as solicitações de consulta são naturalmente menos frequentes, mas o serviço não prioriza uma tarefa em detrimento de outra. Além disso, uma certa quantidade de redundância suaviza o desempenho das consultas quando os serviços ou nós são atualizados internamente.
Como regra geral, as aplicações de pesquisa tendem a precisar de mais réplicas do que partições, especialmente quando as operações do serviço estão mais orientadas para cargas de trabalho de consulta. Cada réplica é uma cópia do seu índice, para que o serviço possa equilibrar os pedidos com múltiplas cópias. O Pesquisa de IA do Azure gere todo o balanceamento de carga e replicação de um índice. Pode alterar o número de réplicas atribuídas ao seu serviço a qualquer momento. Você pode alocar até 12 réplicas em um serviço de pesquisa padrão e 3 réplicas em um serviço de pesquisa Básico. Pode efetuar a alocação de réplicas a partir do portal do Azure ou de uma das opções programáticas.
Partições extras são úteis para cargas de trabalho de indexação intensivas. Partições extra espalham as operações de leitura e escrita por um maior número de recursos computacionais.
Finalmente, índices maiores levam mais tempo para consultar. Assim, poderá descobrir que cada incremento nas partições requer um aumento menor, mas proporcional, nas réplicas. A complexidade das suas consultas e o volume de consultas influenciam a rapidez com que a execução da consulta é concluída.
Para limites de serviço e intervalos de escala válidos, veja:
Nota
Adicionar mais réplicas ou partições aumenta o custo de execução do serviço e pode introduzir pequenas variações na forma como os resultados são ordenados. Certifique-se de verificar a calculadora de preços para entender as implicações de faturamento da adição de mais nós. A tabela de combinações de partições e réplicas pode ajudar a cruzar o número de unidades de pesquisa necessárias para uma configuração específica. Para obter mais informações sobre como réplicas extras afetam o processamento de consultas, consulte Ordenando resultados.
Como gerir e ajustar a capacidade
A mudança de capacidade não é instantânea. Dependendo do volume de dados e do tipo de operação, a escala pode demorar de minutos a várias horas.
Ao dimensionar um serviço de pesquisa, você pode escolher entre as seguintes ferramentas e abordagens:
Nota
Se o seu serviço de pesquisa foi criado antes de abril ou maio de 2024, poderá ser elegível para uma atualização única para infraestruturas mais recentes com divisões maiores, sem custo adicional. Esta atualização pode aumentar o armazenamento disponível por partição e reduzir o número de partições necessárias para a sua carga de trabalho. Para obter mais informações, consulte Atualizar seu serviço de pesquisa.
Para aumentar ou diminuir a capacidade do seu serviço, você tem duas opções:
Adicionar ou remover partições e réplicas
Vá ao seu serviço de pesquisa no portal Azure.
No painel esquerdo, selecione Escala de configurações>.
A captura de ecrã a seguir mostra um serviço Standard provisionado com uma réplica e uma partição. A fórmula na parte inferior indica quantas unidades de pesquisa estão a ser utilizadas (1). Se o preço unitário fosse de US $ 100 (não um preço real), o custo mensal de execução deste serviço seria de US $ 100 em média.
Use o controle deslizante para aumentar ou diminuir o número de partições e selecione Salvar.
Este exemplo adiciona uma segunda réplica e uma partição. Nota a contagem das unidades de pesquisa; agora são quatro porque a fórmula de faturação é o número de réplicas multiplicado pelo número de partições (2 x 2). A duplicação da capacidade mais do que duplica o custo de funcionamento do serviço. Se o custo unitário de pesquisa fosse de US $ 100, a nova conta mensal agora seria de US $ 400.
Para obter os custos unitários atuais de cada nível, visite a página de preços.
Verifique as notificações para confirmar que a operação foi iniciada.
Esta operação pode levar várias horas para ser concluída. Ocorre em segundo plano, pelo que o seu serviço de pesquisa permanece totalmente operacional e disponível para operações de leitura e escrita.
Não podes cancelar a operação nem monitorizar o seu progresso. No entanto, a mensagem a seguir é exibida enquanto as alterações estão em andamento.
Alterar o nível de preços
Nota
O portal Azure e Services - Update (REST API) suportam alterações entre os níveis Basic e Standard (S1, S2 e S3). Você pode fazer upgrade ou downgrade de camadas, desde que sua configuração de serviço atual não exceda os limites da camada de destino. Sua região também não pode ter restrições de capacidade na camada de destino.
O seu escalão de preços determina o máximo de armazenamento do seu serviço de pesquisa para o modelo de preços dedicado. Se precisar de mais ou menos capacidade, você pode mudar para um nível de preço diferente que atenda às suas necessidades de armazenamento. (Isto aplica-se apenas aos níveis do modelo de preços dedicados. O nível de Desenvolvedor do modelo Serverless não pode ser alterado depois de selecionado).
Além da capacidade, os níveis de preços determinam limites em índices, indexadores e outros objetos de pesquisa. Compare os limites de serviço da camada atual e da camada desejada antes de prosseguir. Geralmente, mudar para um nível mais alto aumenta o limite de armazenamento e o limite de vetores, aumenta a taxa de transferência de solicitações e diminui a latência, enquanto a mudança para um nível inferior tem o efeito oposto.
Mudar para um nível de preço mais alto também aumenta o custo de execução do seu serviço de pesquisa. Para obter mais informações, consulte a página de preços.
Para alterar o seu nível de preços:
Vá ao seu serviço de pesquisa no portal Azure.
No painel esquerdo, selecione Escala de configurações>.
No seu nível atual, selecione Alterar Nível de Preço.
Na página Selecionar Nível de Preço , escolha um nível diferente na lista.
Você pode alternar entre Basic, S1, S2 e S3, mas não pode alternar de ou para Free, S3HD, L1 ou L2. Esses níveis não são selecionáveis e aparecem atenuados.
Para iniciar a operação de escala, selecione Salvar.
Esta operação pode levar várias horas para ser concluída. Ocorre em segundo plano, pelo que o seu serviço de pesquisa permanece totalmente operacional e disponível para operações de leitura e escrita.
Não podes cancelar a operação nem monitorizar o seu progresso. No entanto, a mensagem a seguir é exibida enquanto as alterações estão em andamento.
Como os pedidos de escala são tratados para o modelo dedicado
Quando o serviço de pesquisa recebe um pedido de escala, ele:
- Verifica se a solicitação é válida.
- Inicia o backup de dados e informações do sistema.
- Verifica se o serviço já está num estado de provisionamento (atualmente a adicionar ou eliminar réplicas ou partições).
- Inicia o provisionamento.
Escalar um serviço pode demorar vários minutos a várias horas, dependendo do tamanho do serviço e do âmbito do pedido. A duração do backup também varia consoante a quantidade de dados e o número de partições e réplicas.
Os passos para processar um pedido de escalabilidade não são inteiramente sequenciais. Por exemplo, o sistema inicia o provisionamento quando pode fazê-lo com segurança, o que pode ocorrer enquanto o backup está acabando.
Erros durante o dimensionamento
A tabela a seguir lista causas e soluções para erros que podem ocorrer durante operações de dimensionamento.
| Mensagem de erro | Motivo | Solução |
|---|---|---|
| "As operações de atualização de serviço não são permitidas no momento porque estamos processando uma solicitação anterior." | Outra operação de dimensionamento está em andamento. | Consulte a página Visão Geral no portal Azure ou use a API REST de Gestão de Pesquisa API, Azure PowerShell ou CLI do Azure para obter o estado do seu serviço de pesquisa. Se o status for "Provisionamento", aguarde até que ele se torne "Êxito" ou "Falha" antes de tentar novamente. 1, 2 |
| Falha ao dimensionar o serviço de pesquisa servicename. Erro: contagem de ObjectActualCount excede o limite permitido: MaximumCount. | Sua configuração de serviço atual excede os limites da camada de preço alvo. | Verifique se o uso de armazenamento, o uso de vetores, índices, indexadores e outros objetos se encaixam dentro dos limites de serviço da camada inferior. Por exemplo, a camada Basic suporta até 15 índices, portanto, você não pode alternar de S1 para Basic se tiver 16 índices. Ajuste seus recursos antes de tentar novamente. |
1 Não há status para backups, que são operações internas que provavelmente não interromperão um exercício de dimensionamento.
2 Se o serviço de pesquisa parecer estar parado em um estado de provisionamento, verifique se há índices órfãos inutilizáveis, com zero volumes de consulta e sem atualizações de índice. Um índice inutilizável pode bloquear alterações na capacidade de serviço. Em particular, procure índices criptografados por CMK cujas chaves não são mais válidas. Exclua o índice ou restaure as chaves para colocá-lo online novamente e desbloquear a operação de escalonamento.
As combinações de partição e réplica
O gráfico a seguir se aplica à camada Standard e superior. Ele mostra todas as combinações possíveis de partições e réplicas, sujeito ao máximo de 36 unidades de pesquisa por serviço.
| 1 partição | 2 divisórias | 3 partições | 4 divisórias | 6 partições | 12 divisórias | |
|---|---|---|---|---|---|---|
| 1 réplica | 1 SU | 2 SU | 3 Sistema Único | 4 SU | 6 SU | 12 SU |
| 2 réplicas | 2 SU | 4 SU | 6 SU | 8 SU | 12 SU | 24 SU |
| 3 réplicas | 3 Sistema Único | 6 SU | 9 SU | 12 SU | 18 SU | 36 SU |
| 4 réplicas | 4 SU | 8 SU | 12 SU | 16 SU | 24 SU | N/A |
| 5 réplicas | 5 SU | 10 SU | 15 SU | 20 SU | 30 SU | N/A |
| 6 réplicas | 6 SU | 12 SU | 18 SU | 24 SU | 36 SU | N/A |
| 12 réplicas | 12 SU | 24 SU | 36 SU | N/A | N/A | N/A |
Os serviços de pesquisa básica têm contagens de unidades de pesquisa mais baixas.
Nos serviços de pesquisa criados antes de 3 de abril de 2024, os Serviços Básicos podem ter exatamente uma partição e até três réplicas para um limite máximo de três SUs. O único recurso ajustável são as réplicas. No entanto, você pode aumentar sua contagem de partições atualizando seu serviço.
Nos serviços de pesquisa criados após 3 de abril de 2024 em regiões suportadas, os serviços básicos podem ter até três partições e três réplicas. O limite máximo de SU é de nove para suportar um complemento completo de partições e réplicas.
Para garantir alta disponibilidade nas consultas de serviços de pesquisa em qualquer plano pago, independentemente da data de criação, é necessário um mínimo de duas réplicas.
Para taxas de faturação por nível e moeda, consulte a página de preços Pesquisa de IA do Azure.
Estimar a capacidade usando um modelo de preços dedicado
As tuas necessidades de armazenamento dependem do tamanho dos índices que esperas construir. Não existem heurísticas sólidas ou diretrizes gerais que ajudem nas estimativas. A única forma de determinar o tamanho de um índice é construir um. O seu tamanho depende da tokenização e dos embeddings, e se ativa sugestores, filtragem e ordenação, ou se pode tirar partido da compressão vetorial.
Estima a capacidade num nível faturável, Básico ou superior. O nível Gratuito é executado em recursos físicos compartilhados por vários clientes e está sujeito a fatores fora do seu controle. Somente os recursos dedicados de um serviço de pesquisa faturável podem acomodar maiores tempos de amostragem e processamento para estimativas mais realistas de quantidade, tamanho e volumes de consulta de índice durante o desenvolvimento.
Analise os limites de serviço em cada camada para determinar se as camadas inferiores podem suportar o número de índices de que você precisa. Considere se você precisa de várias cópias de um índice para desenvolvimento, teste e produção ativos.
Um serviço de pesquisa está sujeito a limites de objetos (número máximo de índices, indexadores, conjuntos de competências, etc.) e limites de armazenamento. Qualquer que seja o limite atingido primeiro é o limite efetivo.
Crie um serviço em um nível faturável. As camadas são otimizadas para determinadas cargas de trabalho. Por exemplo, o nível Otimizado para armazenamento tem um limite de 10 índices porque foi projetado para oferecer suporte a um número baixo de índices grandes.
Comece baixo, em Basic ou S1, se não tiver certeza sobre a carga projetada.
Comece alto, em S2 ou mesmo S3, se o teste incluir indexação em grande escala e cargas de consulta.
Comece com Armazenamento otimizado, em L1 ou L2, se você estiver indexando uma grande quantidade de dados e a carga de consulta for relativamente baixa, como em um aplicativo de negócios interno.
Crie um índice inicial para determinar como os dados de origem se traduzem em um índice. Esta é a única maneira de estimar o tamanho do índice. Os atributos nas definições de campo afetam os requisitos de armazenamento físico:
Para a pesquisa por palavra-chave, marcar campos como filtráveis e classificáveis aumenta o tamanho do índice.
Para pesquisa vetorial, você pode definir parâmetros para reduzir o tamanho do vetor.
Monitorizar o armazenamento, limites de serviço, volume de consulta e latência no portal Azure. O portal do Azure mostra consultas por segundo, consultas sujeitas a limitação e latência de pesquisa. Estes valores podem ajudá-lo a decidir se escolheu o escalão certo.
Adicione réplicas para alta disponibilidade ou para mitigar o desempenho lento das consultas.
Não há diretrizes sobre quantas réplicas são necessárias para acomodar cargas de consulta. O desempenho da consulta depende da complexidade da consulta e das cargas de trabalho concorrentes. Embora a adição de réplicas resulte claramente em melhor desempenho, o resultado não é estritamente linear: adicionar três réplicas não garante uma taxa de transferência tripla. Para orientações na estimativa de QPS para a sua solução, consulte Analisar o desempenho e Monitorizar consultas.
Para um índice invertido, o tamanho e a complexidade são determinados pelo conteúdo, não necessariamente pela quantidade de dados que você alimenta nele. Uma fonte de dados grande com alta redundância pode resultar em um índice menor do que um conjunto de dados menor que contém conteúdo altamente variável. Portanto, raramente é possível inferir o tamanho do índice com base no tamanho do conjunto de dados original.
Os requisitos de armazenamento podem ser inflacionados se incluir dados que nunca procura. Idealmente, os documentos contêm apenas os dados de que necessita para a experiência de pesquisa.
Considerações sobre o contrato de nível de serviço
Os acordos de nível de serviço (SLAs) não cobrem o nível Gratuito nem as funcionalidades de pré-visualização. Para todos os níveis faturáveis, os SLAs entram em vigor quando você provisiona redundância suficiente para seu serviço.
Duas ou mais réplicas satisfazem SLAs de consulta (leitura).
Três ou mais réplicas satisfazem os SLAs de consulta e indexação (leitura e escrita).
O número de partições não afeta os SLAs.
Otimize os custos para o modelo Serverless
No modelo de preços Serverless:
- O serviço gere automaticamente a capacidade.
- Não precisas de configurar réplicas, partições ou unidades de busca.
- A computação é dimensionada dinamicamente com base na carga de trabalho (carga de consultas e de indexação) e pode ser reduzida a zero quando está inativa.
Para saber mais sobre as limitações do modelo Serverless, veja Limites de serviço.
A faturação baseia-se em duas dimensões:
- Utilização de computação (CUs): Cobrado com base nas operações de consulta e indexação.
- Armazenamento indexado: Cobrado por GB por mês.
Como a faturação é baseada no consumo, o custo está diretamente ligado à utilização:
- Consultas complexas consomem mais computação.
- O design ineficiente de esquemas aumenta tanto os custos de indexação como de consulta.
- Padrões de consulta pobres, com índices grandes ou frequentemente atualizados, aumentam o armazenamento e o uso de computação.
Otimizar a eficiência da carga de trabalho
Como a ineficiência aparece como custo no modelo Serverless, paga-se mais pelo mesmo trabalho se não praticar um design consciente da carga de trabalho. A melhor forma de controlar o gasto em Serverless é desenhar os seus índices e consultas de forma eficiente desde o início.
Para desenhar cargas de trabalho para eficiência ao utilizar o modelo de preços Serverless, considere:
Desenho do índice
- Inclua apenas os campos usados nas consultas.
- Reduza as dimensões vetoriais sempre que possível.
- Evite atributos desnecessários que possam ser filtráveis, ordenáveis ou utilizáveis em facetas.
Padrões de consulta
- Use
$selectpara limitar campos devolvidos. - Aplique filtros cedo para reduzir os conjuntos de resultados.
- Evite a paginação profunda (
$skip). - Prefiro consultas direcionadas a consultas em texto completo amplas.
- Use a pesquisa híbrida com cuidado devido ao maior custo de computação.
Monitoring
- Monitorize o consumo de CU para identificar consultas dispendiosas.
- Acompanhe o crescimento do armazenamento e remova dados não utilizados.
No Serverless, melhorar o desempenho (consultas mais rápidas e direcionadas) normalmente reduz o custo.
Para saber mais, consulte Otimize custos com o modelo de preços Serverless em Pesquisa de IA do Azure.
Considerações de capacidade regional
A capacidade e disponibilidade podem variar consoante a região suportada. Algumas regiões podem ter restrições para fornecer novos serviços ou escalar os existentes.
Nota
Durante a pré-visualização pública, o modelo de preços Serverless está disponível apenas em regiões específicas.
Se a sua região de Pesquisa de IA do Azure preferida não estiver disponível devido a restrições de capacidade, veja Como lidar com restrições regionais de capacidade em Pesquisa de IA do Azure.