Azure OpenAI Data Plane returning 404 Deployment not found for standard SKU Embeddings models

For eastus2, both text-embedding-3-large (version 1) and text-embedding-ada-002 (version 2) are valid Standard embeddings models and are listed as available in that region, so a persistent 404 DeploymentNotFound from the data plane despite provisioningState=Succeeded indicates a deployment- or endpoint-level issue rather than model unavailability.

From the available guidance, the following checks and mitigations are supported:

1. Validate the embeddings endpoint shape
   • For embeddings, the data-plane call must use the embeddings path under /openai/v1/ and the deployment name, for example:

          POST https://{endpoint}/openai/deployments/{deployment-id}/embeddings?api-version=2024-10-21
          {
            "input": ["this is a test"]
          }
     

   • A 404 is expected if either:
     • The base URL does not include /openai/v1/, or
     • The deployment-id segment does not exactly match the deployment name of the embeddings model.
   • The troubleshooting guidance for embeddings explicitly calls out this pattern: a 404 error should trigger verification that the endpoint includes /openai/v1/ and that the base URL and deployment name are correct.
2. Confirm the deployment name vs. model name
   • The model field in the deployment (for example text-embedding-3-large) is not what is sent on the wire; the REST call must use the deployment name in the URL path.
   • A mismatch such as calling .../deployments/text-embedding-3-large/embeddings when the deployment is actually named embeddings-large will produce DeploymentNotFound even if provisioningState=Succeeded and capabilities show embeddings:true.
3. Use a supported API version for embeddings
   • Embeddings are documented with a concrete example using api-version=2024-10-21 on the /openai/v1/embeddings path.
   • The new GA data-plane API version 2024-06-01 adds embeddings parameters (encoding_format, dimensions) and is the latest GA inference API. Using one of the documented embeddings-capable API versions is required; older or preview-only versions may not route correctly for some deployment types.
4. Interpret unavailable_model on /openai/v1/embeddings?api-version=preview
   • The unavailable_model response on the generic /openai/v1/embeddings path with api-version=preview indicates that the model or deployment being targeted is not recognized by that specific API version or path combination.
   • The embeddings reference shows the canonical pattern as .../deployments/{deployment-id}/embeddings?api-version=2024-10-21, not the generic /openai/v1/embeddings?api-version=preview form. Switching to the documented pattern is required for a supported scenario.
5. Region and model availability sanity check
   • The embeddings model summary confirms that in eastus2:
     • text-embedding-3-large, version 1 is available.
     • text-embedding-ada-002, version 2 is available.
   • This rules out a simple “model not in region” cause for eastus2 Standard deployments.
6. When the control plane succeeds but data plane never becomes ready
   • There is a known class of issues where a deployment shows provisioningState=Succeeded but the data plane never becomes usable; in similar cases the recommended resolution has been to delete and recreate the deployment, sometimes in a different region.
   • One documented case of a deployment failing in a region with opaque errors was resolved by switching to another region; another case of a stuck deployment was resolved by deleting and recreating it.
   • Given that chat deployments on the same resource and region work and quota is present, this points to a deployment-specific fault for the embeddings deployments.

Supported remediation steps based on the documentation and similar cases:

1. Recreate the embeddings deployments
   • Delete the existing text-embedding-3-large@1 and text-embedding-ada-002@2 Standard deployments.
   • Recreate them in eastus2 with simple, alphanumeric deployment names (for example emb3large and embada002) and then call:

          POST https://{endpoint}/openai/deployments/emb3large/embeddings?api-version=2024-10-21
     

   • If they still return DeploymentNotFound after provisioningState=Succeeded, this matches the pattern of a stuck or mis-provisioned deployment.
2. If possible, test in a second region
   • Create the same embeddings deployments in another region where these models are available (for example eastus) and call them with the same API version and pattern.
   • If the second region works while eastus2 continues to return DeploymentNotFound, this aligns with the documented scenario where region-specific deployment issues required moving or recreating the deployment.
3. Validate error-class alignment
   • For embeddings, the documented mapping is:
     • 401/403: invalid key or auth.
     • 404: incorrect base URL or missing /openai/v1/ path, or wrong deployment name.
     • 400: invalid JSON or model not set to deployment name.
   • Since authentication and base URL are already validated by a working chat deployment, focus on:
     • Exact deployment name in the URL path.
     • Use of /openai/v1/ in the embeddings URL.
     • A supported embeddings API version such as 2024-10-21 or 2024-06-01.

If, after confirming the URL pattern, deployment name, and API version, newly created embeddings deployments in eastus2 still return DeploymentNotFound while the same configuration works in another region, the behavior matches the documented pattern of a region/deployment fault that required deletion/recreation or region change, and should be escalated through Azure support with those reproduction details.

References:

• Azure OpenAI in Azure AI Foundry Models
• Azure OpenAI in Microsoft Foundry Models REST API reference
• Learn how to generate embeddings
• What's new in Azure OpenAI in Azure AI Foundry Models
• Azure Deployment Takes 70 Minutes to Fail with Obscure Error - Microsoft Q&A
• Deployed Claude and getting API deployment resource is not ready even though it has been an hour - Microsoft Q&A