Vector Index Quota Exhaustion - Support Inquiry

Rocio Zarate 0 Puntos de reputación
2026-06-25T17:16:58.5533333+00:00

Requerimos asesoría técnica para confirmar si existen alternativas de optimización (como cuantización o reestructuración) para recuperar espacio, o si el escalado de infraestructura es la única vía obligatoria para continuar operando.

  1. Verification of Constraints: Could you confirm if, given our current configuration, the only viable path to support additional vector data is to increase the partition count or upgrade the pricing tier?
  2. Advanced Optimization Options: Are there specific features or configurations (such as vector quantization, HNSW parameter tuning, or index reconstruction best practices) that we should exhaust to recover or reclaim vector index space without requiring an infrastructure upgrade?
  3. Storage Misalignment: We observe that general storage is significantly underutilized (e.g., index-semantic-srch-3 at 24.8% total storage). Is there any architectural way to redistribute or rebalance this allocation?
Microsoft Foundry
Microsoft Foundry

Una plataforma unificada de Azure para crear y administrar modelos, agentes y aplicaciones de IA con seguridad, supervisión y gobernanza empresariales integradas


2 respuestas

Ordenar por: Lo más útil
  1. Rocio Zarate 0 Puntos de reputación
    2026-07-07T15:34:50.29+00:00

    existe posibilidad que tengamos una sesion para verificar las solucion que me indicas, actualmente nuestra suscripcion de soporte es developer.

    ¿Le resultó útil esta respuesta?

    0 comentarios No hay comentarios

  2. Karnam Venkata Rajeswari 5,340 Puntos de reputación Personal externo de Microsoft Moderador
    2026-07-02T14:01:06.3266667+00:00

    La siguiente respuesta fue escrita primero en inglés y luego traducida.

    Hola @Rocio Zarate

    Tras revisar el escenario, el comportamiento parece estar relacionado con los límites de capacidad vectorial de Azure AI Search y no con un agotamiento del almacenamiento general. En Azure AI Search, la cuota de almacenamiento y la cuota de tamaño del índice vectorial se administran por separado. La cuota de almacenamiento representa el espacio en disco utilizado por todos los índices, mientras que la cuota del índice vectorial depende de factores como las dimensiones de los vectores, la cantidad de documentos, el número de campos vectoriales, los tipos de datos y la memoria requerida por algoritmos de búsqueda vectorial como HNSW. Por esta razón, es posible observar una utilización baja del almacenamiento mientras la cuota vectorial ya se encuentra completamente consumida.

    El primer paso consiste en confirmar si la limitación real corresponde a la cuota de almacenamiento o a la cuota del índice vectorial.

    sta información puede validarse desde Azure AI Search > Overview > Usage, donde están disponibles las siguientes métricas:

    1. Almacenamiento utilizado / Cuota de almacenamiento
    2. Tamaño del índice vectorial utilizado / Cuota vectorial
    3. Nivel (tier) actual y configuración de particiones

    Estas métricas permitirán determinar si la limitación está relacionada con el consumo de memoria de los vectores o con la capacidad general del servicio.

    Aumentar el número de particiones o migrar a un nivel de mayor capacidad podría ser necesario en última instancia, pero primero se recomienda evaluar varias oportunidades de optimización.

    1. Reducir la huella vectorial La optimización con mayor impacto suele ser la reducción de la cantidad de datos vectoriales almacenados en el índice. Áreas recomendadas para revisar:
      1. Habilitar Scalar Quantization o Binary Quantization
      2. Revisar el uso de tipos de datos vectoriales más compactos cuando sea apropiado
      3. Eliminar almacenamiento vectorial innecesario cuando sea posible
    2. Revisar las dimensiones de embeddings El almacenamiento vectorial crece proporcionalmente a las dimensiones de los embeddings. Ejemplos como 3072 → 1536 o 1536 → 768 pueden reducir significativamente el consumo del índice vectorial cuando los requisitos de la carga de trabajo lo permiten.
    3. Revisar la estrategia de segmentación (chunking) Una estrategia de segmentación demasiado agresiva suele generar una gran cantidad de vectores que incrementan innecesariamente el tamaño del índice. Validaciones recomendadas:
      • Revisar el tamaño promedio de los fragmentos
      • Reducir la fragmentación excesiva
      • Mantener fragmentos con significado semántico cuando sea posible
    4. Revisar el diseño de los campos vectoriales Cada campo vectorial contribuye a un consumo adicional del índice vectorial. Considerar:
      • Eliminar campos vectoriales redundantes
      • Consolidar representaciones vectoriales duplicadas cuando sea posible
    5. Evaluar la reconstrucción del índice Cuando se han producido numerosas actualizaciones o eliminaciones de documentos, reconstruir el índice utilizando un esquema optimizado puede ayudar a mejorar la eficiencia y eliminar contenido obsoleto.

    Revisión de la configuración HNSW

    Si el índice utiliza HNSW, vale la pena revisar los siguientes parámetros:

    • m – Valores más altos suelen mejorar la recuperación de resultados, pero incrementan el consumo de memoria.
    • efConstruction – Influye en la calidad de indexación y en el rendimiento de la construcción del índice.
    • efSearch – Afecta principalmente el rendimiento y la latencia de las consultas.

    Aunque los ajustes de HNSW pueden aportar mejoras, las técnicas de compresión y reducción de vectores suelen proporcionar beneficios significativamente mayores.

    Evaluación de Exhaustive KNN

    Para algunas cargas de trabajo, Exhaustive KNN puede considerarse como una alternativa.

    1. No mantiene un grafo HNSW en memoria
    2. No consume la cuota del índice vectorial de la misma forma que HNSW
    3. Continúa consumiendo almacenamiento
    4. Puede introducir compromisos de rendimiento dependiendo de las características de la carga de trabajo

    Aclaración sobre la utilización del almacenamiento

    Una utilización de almacenamiento observada de aproximadamente 24,8 % no significa que exista capacidad vectorial adicional disponible.

    Azure AI Search considera:

    • La cuota de almacenamiento (capacidad basada en disco)
    • La cuota del índice vectorial (capacidad basada en memoria)

    como recursos independientes.

    Por este motivo, el almacenamiento no utilizado no puede reasignarse ni convertirse en cuota de índice vectorial.

    Revisión de la capacidad del servicio

    Los límites vectoriales varían en función de:

    • El nivel del servicio (tier)
    • La región
    • El número de particiones
    • La fecha de creación del servicio

    Los servicios creados después de las actualizaciones de capacidad de abril de 2024 suelen beneficiarse de límites vectoriales significativamente más altos. Por lo tanto, se recomienda revisar la fecha de creación del servicio antes de realizar migraciones o cambios importantes en la arquitectura.

    Cuándo es necesario escalar

    Si los esfuerzos de optimización no proporcionan suficiente capacidad, las opciones de escalado admitidas son:

    1. Aumentar el número de particiones para ampliar la cuota vectorial disponible.
    2. Migrar a un nivel de Azure AI Search con mayor capacidad.
    3. Evaluar una migración a una configuración de servicio más reciente si las limitaciones actuales están relacionadas con la antigüedad del servicio o restricciones regionales.

    Las siguientes referencias podrían ser útiles; por favor revísalas.

    Por favor, háganos saber si la respuesta fue útil.

    Gracias.

    ¿Le resultó útil esta respuesta?

    0 comentarios No hay comentarios

Su respuesta

Las respuestas pueden ser marcadas como Respuestas aceptadas por el autor de la pregunta, lo que indica a los usuarios que la respuesta resolvió su problema.