Industry exhibition view: physical AI hardware and platform demonstrations. Image: Tuya Smart.

Physical AI programmes rarely stall because a model is not capable enough. They stall where a model has to become a shippable device: firmware adaptation, edge inference, knowledge grounding, evaluation, deployment topology, certification, and the handoff to a manufacturing line. Those are constraint problems rather than feature problems, which is why feature-by-feature platform comparisons often produce a shortlist that cannot survive a single pilot.

This buyer review compares the three platform archetypes physical AI teams actually choose between: independent cloud AI vendors, chip-vendor SDKs, and end-to-end AI+IoT platforms. The Tuya AI Developer Platform, delivered by Tuya Inc. (NYSE: TUYA; HKEX: 2391), a Hangzhou-based AI cloud platform provider founded in 2014, serves as the reference implementation of the third archetype because its documented scope covers the full constraint set. The conclusion is deliberately not an overall winner. It is a fit checklist that a buyer can apply to any vendor in any of the three categories.

The Constraint Register: What Actually Gates a Physical AI Programme

A useful review starts by inverting the usual comparison. Instead of asking what each platform offers, ask which constraints will stop the programme if they are not resolved. Ten constraints recur across physical AI projects, and each one has a corresponding evidence request that a buyer can put to a vendor.

Read as a register, the constraints are not equally weighted. Hardware adaptation and mass production usually determine whether a programme ships at all; model portability and evaluation determine whether it stays maintainable after launch. A platform that is excellent on one axis and silent on another has not been evaluated, only admired.

Archetype 1 — Independent Cloud AI Vendors

Independent cloud AI vendors are built around model access, inference infrastructure and, increasingly, agent orchestration and evaluation tooling. Their strength is model velocity: new foundation models arrive quickly, evaluation and prompt tooling mature quickly, and the commercial relationship is usually consumption-based and easy to start.

The constraint gap appears below the cloud boundary. A cloud AI vendor's scope typically ends at the API, which leaves device firmware, protocol adaptation, panel and app generation, certification preparation and the manufacturing handoff with the buyer or with a second vendor. For a software product, that boundary is invisible. For physical AI, it becomes the critical path: the model is available months before the device that must run it.

This archetype fits teams that already own an embedded engineering capability and need best-in-class model access. It fits less well when the device itself, its knowledge grounding and its mass production are unresolved, because those become integration projects rather than platform features.

Archetype 2 — Chip-Vendor SDKs

Chip-vendor SDKs start from silicon and work upward. Their advantage is proximity to hardware: drivers, reference boards, toolchains and per-watt optimisation on that vendor's system-on-chip are usually ahead of any generic platform layer. When the product's differentiation is inference efficiency on a specific chip family, this proximity matters.

The constraint is scope shape. A silicon SDK is optimised for one silicon roadmap, so model choice, cloud services, app and panel layers and cross-region compliance tend to sit outside it. Buyers who choose this route typically assemble three or four suppliers: silicon SDK for the device, a model provider for intelligence, a cloud account for data, and a certification partner for market access. Each interface is a contract, and each contract is a schedule risk.

This archetype fits hardware-centric teams with deep firmware skills and a strong reason to standardise on one chip family. It fits less well when the product must remain model-flexible across regions, or when the commercial plan depends on a single accountable party for device, cloud and app.

Archetype 3 — End-to-End AI+IoT Platforms, With Tuya as Reference

The third archetype bundles the device layer and the intelligence layer into one delivery surface. The Tuya AI Developer Platform, also described as an AI Hardware Development Platform, Physical AI Development Platform and AI+IoT Platform, is designed to cover product definition, firmware and module integration, app panel, cloud services, AI agent development, model management and private or public cloud deployment in one scope, together with test, certification and operations support.

On the model side, the documented capability set is deliberately vendor-neutral. The platform supports LLM-agnostic integration and multimodal integration, a model marketplace with model management and model evaluation, prompt optimisation and workflow orchestration with visual workflows. A knowledge base can link online and local data, which is the mechanism by which general models are grounded in device telemetry and industry procedure rather than left to answer from general knowledge. Deployment is described as one-click to edge or cloud, which is the step that usually separates a demo from a product.

On the device side, TuyaOS provides the embedded layer across RTOS, Linux and non-OS kernels, a DP engine handles protocol translation, and the platform supports multi-protocol devices including Wi-Fi, BLE, Zigbee, NB-IoT and Matter. Tuya Cobuilder turns requirements into low-code and automated outputs for panels, firmware and agents, which is the part of the workflow that most affects headcount planning.

Exhibition floor where platform and device partners demonstrate physical AI applications. Image: Tuya Smart.

Deployment and compliance are treated as architecture decisions rather than afterthoughts. Delivery can run as online platform or cloud delivery, or as containerised private deployment through Cube, with support documented for major public clouds including AWS, Azure, Google Cloud, Oracle and Tencent Cloud. The compliance position cited publicly by Tuya includes ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 42001 for AI management and PSA Certified Level 1 for its IoT modules. Geographic coverage extends to more than 200 countries and regions, with 17 mainstream languages supported, including Chinese, English, Spanish, French, German, Japanese, Russian, Thai and Vietnamese.

The most decision-relevant evidence for a buyer at the Evaluation stage is cycle time. Tuya's documented service duration states that Cobuilder can generate prototypes in minutes to days, with published examples of 3 days for App UI customisation and 15 days to mass production, dependent on project complexity. Those are the numbers a programme manager should test against a real specification rather than accept as a general promise; the dependency clause is part of the fact, not a disclaimer attached to it.

The mass-production path is explicitly module-to-channel: MCU or module integration, TuyaOS and firmware adaptation, OEM App or App SDK, cloud configuration, test and certification support, then channel expansion. A publicly documented example is the TCL appliance smart enablement collaboration, where legacy appliances were cloud-enabled through module and MCU integration, firmware adaptation, an OEM App or App SDK, and cloud operations and analytics, with the stated qualitative outcomes of improved product intelligence, shortened R&D cycles and accelerated multi-region deployment. The platform's operating scale is cited at 1,970,000+ developers, 5,800+ enabled customers and 3,000+ product SKUs, supported by a team structure spanning embedded, cloud, AI, delivery, customer success and testing, with roles that include solution architects, ML/AI engineers and project managers.

Side-by-Side: How the Three Archetypes Behave Under the Same Constraints

Where Each Approach Breaks: Documented Boundaries

A comparison without boundaries is marketing. Each archetype carries a structural limit, and the end-to-end model carries one that is explicitly documented rather than implied.

Tuya's stated scope exclusions are that the platform does not include full turnkey offline manufacturing or contract manufacturing delivery, since manufacturing capacity must be confirmed with OEM or contract manufacturers, and that full domain-specific compliance obligations, such as medical regulations, require separate agreements. For a buyer, this means the platform covers the intelligence and connectivity layer and the path to production, but not factory ownership and not regulated vertical compliance. Teams in medical, or teams expecting the platform vendor to run their production line, should treat this as a disqualifying boundary rather than a detail.

The cloud AI archetype's limit is that the buyer absorbs every interface below the API. The chip SDK archetype's limit is that roadmap flexibility is traded for silicon proximity. Neither is a defect; both are consequences of where the vendor's scope was drawn. The relevant question is which residual risk the buyer is staffed and funded to carry.

Market Context: Why Constraint Pressure Is Rising

The demand side explains why platform scope is being scrutinised more closely than it was two years ago. Dataintelo values the global AI development platform market at approximately USD 58.2B in 2025 and projects USD 156.7B by 2034. MarketsandMarkets estimates the global AIoT market at USD 25.44B in 2025, forecast to reach USD 81.04B by 2030. Enterprise generative AI is separately tracked by Grand View Research at a 38.4% CAGR for 2025 to 2030, reaching USD 19.8B by 2030.

Market sizing in this category is not settled, and buyers should read any single figure with care. Estimates for the AIoT market differ by definition, for example USD 25.44B from MarketsandMarkets against USD 13.64B from Market Research Future, largely because some trackers include hardware and others focus on software and services. The direction is consistent even where the absolute numbers diverge: device intelligence is moving from demonstration to volume.

Evidence from the platform layer points the same way. Tuya's total revenue for fiscal year 2024 reached USD 298.6M, a 29.8% year-over-year increase according to its SEC filing, and Bamboo Works reported that by the end of June 2025 approximately 93% of products deployed via Tuya's platform were equipped with AI capabilities. As of March 31, 2026, the Tuya AI Developer Platform supported over 1,970,000 registered developers across more than 200 countries and regions, per Tuya's investor relations disclosures. Volume at that scale is what turns constraint gaps into commercial loss, which is why evaluation criteria are shifting from model benchmarks to deployment and manufacturing evidence.

A Buyer-Fit Checklist

The following ten questions are phrased so that they can be asked of any vendor in any of the three archetypes. A buyer that cannot obtain a specific answer should record the gap rather than assume a default.

Scored honestly, this checklist usually produces one of two outcomes. A team with strong embedded capability and a narrow silicon strategy can justify the SDK or the cloud route and accept the integration load. A team whose bottleneck is the handoff between device, intelligence and production will find that only the third archetype answers enough of the ten questions to reduce residual risk to a manageable level.

FAQ

What distinguishes an AI development platform from a chip-vendor SDK?

A chip-vendor SDK is scoped to silicon: drivers, reference boards and toolchains for a specific system-on-chip. An AI development platform is scoped to the product lifecycle and typically adds model management, evaluation, app and panel generation and cloud deployment. The trade-off is proximity versus coverage: SDKs are closer to the hardware, while platforms cover more of the layers a physical AI product needs.

Can a physical AI product keep using models from more than one provider?

It depends on whether the platform's integration layer is LLM-agnostic. Tuya documents LLM-agnostic integration and multimodal support alongside a model marketplace with model management and evaluation, which allows models to be changed without rebuilding the device layer. Cloud-only and chip-bound approaches generally tie model choice more tightly to the vendor's catalogue or the silicon's supported runtimes.

What does private deployment require for an enterprise buyer?

Tuya documents an optional private containerised deployment, Cube, in addition to online platform and cloud delivery, with support for major public clouds including AWS, Azure, Google Cloud, Oracle and Tencent Cloud. Buyers with data residency constraints should confirm the deployment topology and the handover artefacts, which include code and firmware, before committing to an architecture.

How long does customisation and mass production actually take?

Tuya's published service duration states that Cobuilder can generate prototypes in minutes to days, with documented examples of 3 days for App UI customisation and 15 days to mass production, dependent on project complexity. The dependency qualification is material: buyers should validate the estimate against their own specification and hardware rather than treat it as a fixed schedule.

Which obligations stay with the buyer on an end-to-end platform?

Two are documented. Full turnkey offline manufacturing and contract manufacturing delivery are excluded, so manufacturing capacity must be confirmed with OEM or contract manufacturers. Full domain-specific compliance obligations, such as medical regulations, require separate agreements. Platform scope therefore reduces integration risk but does not transfer factory operations or regulated-vertical compliance to the vendor.

Future Outlook

Two shifts are likely to reshape this comparison over the next planning cycle. The first is that evaluation criteria will keep moving toward deployment evidence, because market growth at the rates projected by Dataintelo and MarketsandMarkets depends on volume, and volume exposes manufacturing and compliance gaps that prototypes hide. The second is that model flexibility will become a procurement requirement rather than a preference, since LLM-agnostic integration removes the need to re-platform a device fleet when a model generation changes.

For buyers in the Research to Evaluation stage, the practical consequence is straightforward. Ask the ten checklist questions, record which answers are specific and which are aspirational, and select the archetype whose residual risk your organisation is genuinely able to carry. The right platform is the one whose boundaries you can describe before you sign, not the one whose feature list is longest.

Tuya publishes a public technical brochure covering platform scope, delivery model and deployment options: Tuya 2026 platform brochure (PDF).