ACR Artifact Streaming shows zero pull-time improvement in Container Apps (Consumption-GPU) despite meeting all documented requirements

Question

Setup

Azure Container Apps, Consumption-GPU-NC8as-T4 workload profile
Premium Azure Container Registry, same region as the Container Apps environment (Central India)
Following the recommendation in "Using serverless GPUs in Azure Container Apps" → Improve GPU cold start, which states enabling artifact streaming can "significantly improve cold start times"

Prerequisites confirmed met

Registry SKU: Premium ✓
Customer-managed keys: disabled (not used) ✓
Image pulled by tag, not digest ✓
Platform: linux/amd64 ✓

What we tested

We created streaming artifacts for two different builds of the same ~13GB image (one with a single large layer, one restructured into several genuine layers, to rule out layer-shape as a factor):

az acr artifact-streaming create --name --image :

az acr artifact-streaming operation show --name --image :

Both conversions completed successfully well before testing:

"status": "Succeeded",

"progress": "100%"

We then compared:

A plain docker pull of the same image locally (guaranteed non-streaming baseline): 217.05s
The same image pulled by Container Apps (document-prodtest-t4warm, single-layer build): 217.54s
The multi-layer test build pulled by Container Apps (streaming_test): 219.22s

All three times are statistically identical, for a ~13GB image, well under the ~30GB threshold Microsoft's docs mention as where the benefit is "especially helpful" — but even accounting for that, we expected

some measurable difference between a guaranteed non-streaming pull and a pull that should be using the fully-converted streaming artifact, and saw none.

What we noticed in the documentation

The general Artifact Streaming overview only ever describes streaming to Azure Kubernetes Service (AKS) — no

mention of Container Apps anywhere.

The troubleshooting guide has a dedicated "Address Azure Kubernetes Service (AKS) integration issues" section

(including AKS-specific pod conditions like UpgradeIfStreamableDisabled) for verifying consumption-side behavior — again, no equivalent section or mention for Container Apps.

The only place Container Apps is mentioned at all is a single line in the GPU serverless overview doc's cold-start section, with no further detail, requirements, or troubleshooting guidance specific to ACA.

Question

Is artifact streaming actually implemented for Container Apps' image pull path today, or does the Container Apps GPU documentation describe a capability that isn't fully rolled out / doesn't apply the same way it

does for AKS? If it is supported, what are we missing that would explain identical pull times despite every documented prerequisite being met?

Answer

Hi @Rocky Sawant ,

Based on the information you've provided, your understanding of the documentation is correct. Successfully converting an image for Artifact Streaming in Azure Container Registry confirms that the streaming artifact was created, but it does not by itself confirm that Azure Container Apps actually consumed the streamed artifact during image pull.

Before concluding that this is a limitation in Azure Container Apps, I'd recommend checking the following:

1. Verify how your Container App authenticates with Azure Container Registry

If your Container App is using ACR admin credentials or registry username/password authentication, try switching to a Managed Identity with the AcrPull role and repeat the test.

2. Consider whether the image is read-heavy during startup

Artifact Streaming provides the greatest benefit for workloads that do not require most image layers immediately during startup.

Since your image is approximately 13 GB and contains GPU libraries and model files, it's possible that the application reads a large portion of the image during initialization. In that scenario, the runtime may need to fetch most of the data immediately, resulting in startup times that are very similar to a normal image pull.

3. Measure application readiness instead of total image pull time

Artifact Streaming is designed to reduce the time until the container becomes ready, rather than reducing the total amount of data downloaded.

If possible, compare the Container App system logs and measure the time from image pull to the container reaching the Running/Ready state instead of comparing overall pull duration alone.

At present, Azure Container Registry documentation describes the Artifact Streaming consumer-side enablement and verification process for Azure Kubernetes Service (AKS). Equivalent enablement or verification steps are not currently documented for Azure Container Apps.

Because of this, there is currently no documented method to verify whether a Container Apps revision actually used the streamed artifact or automatically fell back to a standard image pull.

I recommend first validating the authentication method and repeating the test with a Managed Identity if applicable. If the behavior remains unchanged, collecting the timing information from Container Apps system logs would help determine whether the startup delay is caused by image transfer or by application initialization.

Additionally, for large GPU workloads, consider storing model files on a supported storage mount instead of packaging them inside the container image. This is one of the recommended approaches for improving cold-start performance in Azure Container Apps.

Please let us know the results of the above checks, and we'll be happy to assist you further.

Answer

Hello Rocky Sawant,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your ACR Artifact Streaming shows zero pull-time improvement in Container Apps (Consumption-GPU) despite meeting all documented requirements.

The issue is not that the ACR streaming artifact failed. Based on the scenario, the ACR-side conversion appears complete, ACR Artifact Streaming was enabled at the registry/image level, but Azure Container Apps usage of that streaming artifact is not proven or customer-verifiable from the documented Container Apps surface. ACR conversion success only proves that the streaming artifact exists in ACR. It does not prove the Container Apps runtime selected it. - https://learn.microsoft.com/en-us/azure/container-registry/container-registry-artifact-streaming, https://learn.microsoft.com/en-us/azure/container-registry/troubleshoot-artifact-streaming

What to do is to use AKS if Artifact Streaming is a hard requirement, because AKS has the documented consumer-side enablement and validation path. If the workload must remain on Azure Container Apps, the next required step is an Azure Support/Product Group investigation to confirm from backend platform logs whether the Container Apps revision used the streaming artifact or fell back to a standard OCI image pull. - https://learn.microsoft.com/en-us/azure/aks/artifact-streaming, https://learn.microsoft.com/en-us/azure/container-apps/log-monitoring

In addition, for Azure Container Apps GPU cold-start reduction, the documented and reliable mitigations are to reduce the image size, keep ACR close to the Container Apps environment, move large model files or large runtime assets to storage mounts, add application startup instrumentation, and use proactive warm-up or minimum replicas where cold-start latency is business-critical. - https://learn.microsoft.com/en-us/azure/container-apps/cold-start, https://learn.microsoft.com/en-us/azure/container-apps/gpu-serverless-overview. Also, escalation might be required via priority customer support team or paid support subscription, because Container Apps-side Artifact Streaming verification command is required.

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.