A field-inspection company builds an app that runs on tablets carried by technicians into underground facilities with no cellular or Wi-Fi coverage. The app must run a small language model to summarize inspection notes entirely on the tablet, with no calls to any cloud endpoint. Which Microsoft Foundry capability should the team use to meet this requirement?
Select an answer to reveal the explanation.
Short Explanation
Think about what changes when a technician walks into a facility with zero signal: any approach that still needs to phone home to Azure is off the table, no matter how well it scales or how cheap it bills. The one approach built for this is running the model right there on the tablet's own chip, so summarizing notes never depends on a connection at all. Cloud-based serverless billing and dedicated GPU compute are both still cloud endpoints under the hood, so a dead cell signal breaks them just the same. And querying a search index to ground answers only makes the offline problem worse, since now the retrieval step also needs the network. When the requirement is genuinely zero connectivity, the model has to live on the device itself, not somewhere it has to call.
Full Explanation
The correct answer is B. Foundry Local packages a model to run directly on the device's own CPU, GPU, or NPU, so the inspection app can summarize notes with zero network dependency, exactly the underground, no-connectivity requirement in the stem. Option A is incorrect because a serverless API deployment is still a cloud endpoint reached over the internet; without connectivity the tablet cannot reach it. Option C is incorrect for the same reason: managed compute deployments run on Azure-hosted GPU instances, so the app would still need network access to send requests. Option D is incorrect because Azure AI Search grounding requires querying a cloud-hosted index over the network, which does nothing to solve the offline requirement and adds a dependency the team explicitly cannot use.