Real-time or Batch? The First Design Decision in Building Shelf Audit from Field Photos
When shelf audit from field photos needs real-time inference and when a queue-based batch is enough. A decision table for SIs, with photos and GPUs in Jakarta.
Real-time inference is only needed when a sales rep has to act on the shelf audit result before leaving the store. For everything else, such as supervisor dashboards or trade marketing reviews, an asynchronous queue is usually simpler, holds up better at peak hours, and needs fewer GPUs.
Build Log, pattern format: one design decision from a shelf audit pattern that can be built on IONext. This is not a project report.
Why does this decision come first?
Choosing between real-time and batch shapes how the app waits for results, how much GPU capacity has to stay ready, how peak load is handled, and what happens when store signal is weak. Changing it after go-live means reworking the field app flow and the service agreement with the client.
In the shelf audit and planogram compliance pattern, photo uploads tend to pile up in the late afternoon, after the last visit of the day. Processing every photo in real time means sizing GPUs for that peak and leaving most of that capacity idle the rest of the day. So the first question for the client is not about the model. It is about the user: who reads the audit result, and when is it needed?
When is real-time necessary, and when is batch enough?

Each client requirement should be mapped to its own inference pattern. Usually only one or two requirements truly need an answer while the sales rep is still in the store. The rest can wait a few minutes or a few hours without losing business value.
| Client requirement | Recommended pattern | Infrastructure impact |
|---|---|---|
| Sales reps need to retake blurry or dark photos | Real-time on the device | No server GPU needed. The quality check runs inside the app. |
| Sales reps must complete mandatory SKUs before leaving the store | Real-time on Jakarta GPUs, for priority SKUs only | GPUs must be ready during visit hours. The app needs a fallback for weak signal. |
| Supervisors track daily compliance | Asynchronous through a queue | Photos are processed in order, so the late-afternoon upload spike does not cause failed requests. |
| Trade marketing runs weekly reviews or verifies display claims | Scheduled batch in off-peak hours | GPUs can be shared with model fine-tuning jobs. |
For asynchronous and batch patterns, inference servers such as NVIDIA Triton offer dynamic batching: several requests are combined into one batch on the server side. This helps GPUs work more efficiently when the queue is long, without changing the field app. Triton can be run by the SI on its own VMs.
Checklist before choosing a pattern
- Ask the client who uses the audit result and when, for each type of user.
- Limit real-time to decisions that have to be made in the store.
- Move the photo quality check to the device so it does not consume server GPU.
- Keep photos in Jakarta object storage and send only the photo ID through the queue, so photos do not end up scattered across the message broker and its logs.
- Plan an offline fallback: photos stay stored in the app and are resent when signal returns.
- Record the chosen pattern in the design document and in the service agreement with the client.
Where does IONext fit?
IONext provides GPUs in Jakarta, namely the NVIDIA L40S 48GB and the NVIDIA RTX PRO 6000 Blackwell SE 96GB, along with object storage and VMs in the ORBIT workspace, to run either the real-time or the batch pattern. IONA reads production signals such as a stalled pipeline step or an exposed resource.
Choosing the pattern, building the field app, the detection model, and the service agreement with the client remain the SI's work. Details on data location and ISO/IEC 27001:2022 certification are on the Security and Compliance page.
Try building both patterns: sign up for the IONext Console, then explore ORBIT and IONA. System integrators who want to bring this pattern to FMCG or retail clients can start the conversation through the IONext Partner Program.
Sources
- NVIDIA Triton Inference Server, Dynamic Batcher documentation, accessed 3 November 2026
- Computer Vision for Retail and FMCG: Shelf Audits and Planogram Compliance from Field Photos
- Pattern Card: Summarizing Store Visit Reports with an LLM, Data Kept in Indonesia
IONext is sovereign AI infrastructure hosted in Indonesia, operated by PT Data Awan Nusantara in Jakarta. IONext provides GPU as a Service, managed inference through an OpenAI-compatible API, and open-weight model hosting, certified to ISO/IEC 27001:2022 by TÜV NORD.
IONext is sovereign AI infrastructure hosted in Indonesia, operated by PT Data Awan Nusantara in Jakarta. IONext provides GPU as a Service, managed inference through an OpenAI-compatible API, and open-weight model hosting, certified to ISO/IEC 27001:2022 by TÜV NORD.
