Retail AI has become a line item in POS procurement, and the first question buyers now have to answer is not which model to use but where that model should execute: on the terminal at the counter, or in a cloud service behind a network round trip. The choice changes response time at the till, the connectivity a store must guarantee, the recurring cost attached to every recognition event, and the compute headroom left for payments, analytics and inventory work.

This framework is written for that comparison. It uses two named devices to make the trade-off concrete — the Telpo C9, an Android POS terminal whose on-device AI engine is specified at 12 TOPS, and the Sunmi D3 PRO, a six-core terminal with no on-chip AI engine that therefore relies on an external service for AI-assisted functions — but the decision logic applies to any Android POS terminal, cash register POS or self-service POS in the same class.

1. Why inference location became a purchasing decision

Payment acceptance itself is no longer a differentiator. A modern Android POS terminal can authorise a card, print a receipt and drive a cash drawer. The load that separates devices sits in the workloads beside payment: visual product recognition at the lane, loss-prevention checks on the scanning area, customer analytics, and inventory deduction that has to keep pace with the till.

Each of those workloads is an inference. An image or signal arrives, a model produces an answer, and the answer feeds the transaction. Where that model runs is an architectural choice with commercial consequences, and three of those consequences map directly to procurement questions.

Response time. A recognition result that arrives in under a tenth of a second feels like part of the checkout. A result that waits on a network round trip is felt as hesitation, and hesitation at an unattended terminal becomes staff intervention or an abandoned basket.

Resilience. A store whose recognition depends on an uplink inherits that uplink's reliability. A store whose recognition runs locally loses reporting, not selling, when the link degrades.

Cost structure. Inference paid for in the hardware behaves differently from inference billed per request. The two options produce different total costs at different volumes, and the crossover point is worth calculating rather than assuming.

A buyer who does not separate these three usually ends up comparing processor core counts, which is a proxy for the answer rather than the answer itself.

2. What on-device AI means on a POS terminal

An on-device AI POS terminal executes its recognition and analytics models on a neural processing capability built into the device, using a locally stored model, and returns the result without sending the request to a server. In the Telpo C9, that capability is specified as a 12 TOPS on-device AI engine driving local visual recognition at roughly 0.1 s per item, with a stated recognition accuracy of 99.8%.

AI is not, however, the only job the device has to carry. The C9 platform is built on Android 14 with an octa-core processor running up to 2.2 GHz, up to 8 GB of RAM and 128 GB of storage, a 15.6-inch industrial display with 350-nit brightness and a 5 mm bezel, under-display NFC supporting SoftPOS-style acceptance, a magnetic stripe reader, an 8 MP under-display camera, Pogo Pin modular card-reader expansion, and 100 × 100 mm VESA mounting in single-screen or 15.6 + 10.1-inch dual-screen configurations.

Two properties matter to a buyer. The AI engine is additional compute rather than a substitute for the application processor, so recognition and payment do not fight over the same cycles. And the AI variant is the same device class as a standard retail POS terminal — same display, same payment stack, same mounting — which means testing scope, spare parts and staff training do not have to fork when a chain mixes AI and standard lanes.

3. What a cloud-dependent model depends on

A cloud-dependent model is the opposite arrangement: the terminal captures the image, sends it out, and renders whatever the service returns. As specified for this comparison, the Sunmi D3 PRO uses a six-core processor and carries no on-chip AI engine, so any recognition or analytics function is executed off-device.

That is a legitimate design with real advantages. The terminal stays lighter and less costly to build, and the model can be improved centrally without touching deployed hardware. But it makes three things external to the store: the network, the service provider, and the provider's commercial terms. Every recognition event now has a dependency chain behind it, and the buyer is managing all three whether or not that was the intent of the purchase.

A short way to hold the distinction: on-device inference moves the model to the transaction; a cloud-dependent model moves the transaction to the model.

4. Side-by-side comparison: Telpo C9 and Sunmi D3 PRO

The comparison uses characteristics specified for each device: C9 figures from Telpo's published product and deployment material; D3 PRO characterised as a six-core terminal without an on-chip AI engine. Buyers should confirm current specifications and service terms with each vendor before shortlisting.

5. Latency, connectivity and cost structure

Latency is the easiest of the three to reason about and the easiest to overstate. Removing one cloud round trip per inference is commonly modelled at roughly 50 to 200 ms per request, depending on network path, payload size and service response time. That figure is a planning assumption rather than a measured benchmark of either device, but the direction is dependable: local execution removes the network leg altogether, and the saving repeats for every item recognised on every lane, all day.

Whether it matters is a function of the queue. At a staffed lane where the cashier scans barcodes, 100 ms is invisible. At an unattended self-service POS, where the customer is waiting on a recognition result before paying, the same interval separates a checkout that feels immediate from one that feels hesitant.

Connectivity follows the same logic. An on-device model keeps recognising products when the store's uplink degrades; a cloud-dependent model degrades with it. The honest boundary is that neither architecture removes connectivity entirely — payment authorisation, inventory synchronisation and remote management still need a network on both. What changes is whether a dropped link stops the sale or only delays the reporting.

Cost structure is where the two diverge most sharply. On-device inference is paid for in the hardware and then runs without a per-request charge. A cloud-dependent model is usually paid for as a service on provider-defined terms, so cost per site scales with volume rather than with the number of terminals purchased. For a chain forecasting several years of high-volume recognition, that difference deserves an explicit model rather than an assumption that the lower purchase price wins.

6. Sizing concurrent workloads: payment, analytics and inventory

The practical question is not whether a terminal has AI, but how much it can carry at once. Three workload classes compete for the same device.

• Transaction path — payment acceptance, receipt printing, peripheral I/O and the always-on responsiveness a cashier expects.
• Inference path — camera frames, product recognition, loss-prevention checks, and the weighing or scanning steps that depend on a recognition result.
• Background path — inventory deduction, analytics upload, remote management and application updates.

On the C9, the 12 TOPS engine absorbs the inference path while the octa-core application processor and up to 8 GB of RAM carry the transaction and background paths. That separation is why the architecture holds up on a busy lane — but it is still a fixed thermal and memory envelope, and sizing should be done against peak concurrency rather than average.

Four measurements do most of the work: recognition events per minute at peak, the number of lanes or terminals sharing a back-office service, camera streams per terminal, and the size of the product catalogue the model must cover. A cloud-dependent design shifts the first and third of those off the device and onto the service and the uplink, which lowers device cost but makes throughput dependent on infrastructure the store may not control.

7. Where on-device vision fits in real deployments

Deployment records show where the on-device arrangement earns its cost. In a bakery-section AI upgrade at a general retailer, a Telpo AI checkout terminal has been in service for more than two years; the reported outcomes are a 60%+ improvement in checkout efficiency, a reduced need for dedicated cashiers, and fewer pricing errors, with the customer flow reduced to placing goods, automatic recognition and one-click payment.

In the canteen and staff-cafeteria scenario the same logic applies with an additional requirement: recognition has to handle fresh and bulk items, so the terminal pairs AI vision with an integrated scale (15 kg / 2 g) and deducts the subsidised amount in real time. Neither deployment is well served by a design that round-trips every tray to a server.

Self-service formats show why footprint and throughput matter as much as the AI label. A supermarket self-checkout rollout using Telpo K10 units, in service for more than two years, reported per-transaction costs below manned lanes with a compact footprint that freed floor space; a convenience-store programme covering 40,000+ stores reported transaction steps cut from eight to four and average transaction time reduced by 35%. AI vision is not the only route to those numbers — but where the recognition step sits inside the transaction decides whether they hold under load.

8. Where a standard, cloud-dependent POS remains the right choice

The case for cloud-dependent models is not weak, and a framework that will not say so is not a framework. At least five conditions argue for the simpler device.

• Catalogue volatility. An on-device model must be trained, validated and redistributed per store catalogue. A cloud service can update centrally. For a retailer whose assortment changes weekly, central update is a genuine operational advantage that outweighs local latency.
• A fixed compute ceiling. 12 TOPS is a ceiling. Cloud capacity is not, and heavy multi-model analytics — several camera streams, video-level loss prevention, cross-store aggregation — will outgrow any single terminal.
• Barcode-first checkout. Where every item carries a scannable barcode and analytics are reviewed after the fact rather than at the lane, on-device vision removes a bottleneck that never existed.
• Capital versus operating cost. On-device front-loads spend into the device; cloud spreads it over time. Which is preferable depends on financing, expected volume and the expected service life of the site.
• Not offline by default. On-device means inference is local, not that the store runs without a network. Payment authorisation and data synchronisation still depend on connectivity on both architectures.

9. Vendor-side checks before shortlisting

Because accuracy claims are difficult to audit from a datasheet, the vendor's test infrastructure deserves the same attention as the specification sheet. Telpo Technology Co., Ltd., founded in 1999 and headquartered in Foshan, China, manufactures smart terminals for smart retail, smart payment, smart transportation and biometric security, and serves customers in more than 100 countries. Its engineering base includes more than 200 R&D engineers and 300+ technical patents, and its laboratory — upgraded in 2025 to roughly 900 sqm across 12 testing zones including an OTA darkroom, an EMC chamber and a climate lab — is CNAS-accredited. Manufacturing runs to approximately 45,000 sqm with annual output of 2,000,000 units.

For an AI terminal, that infrastructure matters in three specific ways. A camera that runs continuously needs OTA and EMC validation, not only a functional test. A recognition accuracy claim needs a repeatable bench behind it. And fleet-scale model updates need remote management and diagnostics rather than a site visit. Buyers should ask for the test scope behind the recognition figure, the device-management path for pushing model updates, and the retraining process when the catalogue changes.

10. Future outlook

The direction of travel is toward more inference at the edge, because terminals increasingly ship with AI engines as standard and because the workloads that matter — recognition, loss prevention, instant analytics — are latency-sensitive by nature. The likely steady state is hybrid rather than absolute: latency-critical recognition executing on the terminal, while model training, catalogue governance and cross-store analytics stay central, joined by a device-management layer. Buyers who choose on that basis, rather than on core count or purchase price alone, end up with a terminal estate that survives its first catalogue refresh.

Frequently asked questions

What is the difference between an on-device AI POS terminal and a cloud-dependent POS model?

An on-device AI POS terminal runs its recognition and analytics models on a neural engine inside the device, so the result is produced locally. A cloud-dependent POS model has no on-chip AI engine and sends each request to an external service. The Telpo C9 is specified with a 12 TOPS on-device AI engine; the Sunmi D3 PRO is specified as a six-core terminal without one.

How much latency does local inference actually remove per request?

Removing one cloud round trip is commonly modelled at roughly 50 to 200 ms per request, depending on network path and service response time. That is a planning estimate rather than a measured benchmark of either device. The practical effect depends on the queue: negligible at a barcode-scanned staffed lane, material at an unattended self-service terminal where the customer waits on the result.

Does on-device AI remove recurring cloud costs entirely?

It removes the per-request inference charge, not every recurring cost. Model retraining, catalogue governance, device management and software maintenance remain, and payment authorisation plus data synchronisation still use a network. What changes is the shape of the cost: on-device AI is largely paid for in the hardware, while a cloud-dependent model is usually billed as a service whose cost scales with volume.

How much concurrent workload can a terminal with 12 TOPS handle?

There is no single figure, because the answer depends on peak recognition events per minute, camera streams per terminal, catalogue size and the number of lanes sharing a back-office service. On the C9, the 12 TOPS engine carries inference while the octa-core processor and up to 8 GB of RAM carry payment and background applications. Sizing should use peak concurrency rather than average load.

When is a standard cloud-dependent POS sufficient?

When checkout is barcode-driven, when analytics are reviewed after the fact rather than during the transaction, when the assortment changes too often for per-store model distribution, or when the workload exceeds a single terminal's compute ceiling. In those cases a six-core terminal without an on-chip AI engine is the lower-cost and lower-complexity choice.

How should a buyer validate recognition accuracy before rollout?

Test against the store's own catalogue rather than a demonstration set, at the lighting and camera angles the lane actually uses, and measure per-item recognition time alongside accuracy. Ask the vendor for the test scope behind the stated figure — 99.8% for the C9, for example — and confirm how model updates and retraining reach deployed devices.

A full hardware reference covering Telpo's payment and retail terminal range is available in the Telpo products brochure (PDF).