Large Model Valuations: Revenue and Business Model Risks

Generative AI is moving from text understanding and code generation toward complex engineering collaboration, and expectations for large models are rising quickly. A widely discussed case is a technical report from a frontier laboratory in which a model received a natural-language requirement and completed design solutions for three electronic devices: a home voice assistant, a conference audio terminal, and a handheld electronic pet. The model selected electronic components, designed the circuit board and enclosure, and wrote control software. After manufacturing partners produced the devices, they operated without circuit modifications.

The attention around this case comes not from a single feature demonstration, but from the implication of a new R&D paradigm: AI is moving from an assistant to an engineering collaborator, and may take end-to-end delivery roles in some parts of the process.

At the same time, capital markets are raising valuations for frontier model companies. High valuations often rest on three assumptions:

1. Model capabilities will continue to expand into more industries.
2. Usage demand will shift from demonstration applications to production-scale workloads.
3. Business models will extend from project-based work or tool subscriptions to platform-level revenue.

However, stronger technical capability does not automatically mean a more stable commercial model. In high-complexity scenarios such as hardware R&D, industrial software, and embedded systems, revenue quality, delivery cost, responsibility boundaries, and repeat purchase rates become critical to whether a business model can hold. Understanding the logic of high large-model valuations therefore requires looking beyond technical breakthroughs to whether they can become replicable, auditable, and sustainable revenue structures.

1. Capability Leap: From Language Generation to a Complex Engineering Closed Loop

In the early stage, large models mainly served tasks such as text question answering, content generation, and code completion. Their commercial value was often expressed as efficiency improvement, such as reducing repetitive writing, accelerating code draft generation, or helping organize documentation. But when a model can understand a natural-language requirement and break it down into electronic components, circuit structures, enclosure forms, control logic, and test plans, its capability boundary expands from “assisted generation” to “engineering decision-making.”

This shift involves several technical layers.

1. Requirement parsing and solution decomposition

A user input may be only one sentence, such as “design a low-power desktop device.” The model needs to understand functional goals, usage scenarios, cost constraints, power limitations, interface requirements, dimensional boundaries, and manufacturing conditions, then convert them into executable engineering tasks.

2. Component selection and parameter constraints

Hardware design is not a simple assembly of components. The model needs to understand the function, package, electrical characteristics, power consumption, supply cycle, cost range, and compatibility of different components. A single parameter error can cause a circuit to fail, a structure to be unassemblable, or a project to exceed cost controls.

3. Coordination among circuit, structure, and firmware

Circuit boards, enclosures, and control software are not independent modules. Layout affects thermal performance, structure affects assembly, firmware affects peripheral drivers, and power design affects battery options. To complete end-to-end design, a model must have cross-domain coordination capability.

4. Simulation, verification, and iterative correction

Software output can be corrected quickly through compilation and testing. Hardware design, however, often involves simulation, prototyping, manufacturing, and physical testing. If a model does not establish reliable verification mechanisms, so-called “completed design” may remain only at the drawing level and may be difficult to move into real delivery.

Therefore, what is truly valuable is not merely “generating a solution,” but building a verifiable, traceable, and iterative engineering closed loop. This is the key for large models to evolve from content tools into R&D infrastructure.

2. Revenue Models: Usage Volume and Delivery Outcomes Follow Different Paths

Revenue sources for large-model companies often include API calls, subscription services, industry solutions, customized projects, model licensing, and joint R&D revenue sharing. Different revenue models correspond to very different growth qualities.

1. Usage-based revenue: elastic, but dependent on real business demand

If a model is mainly called as a general capability, revenue growth often depends on whether customers use it frequently in real business processes. Call volume may be high during demonstration stages, but once customers move into production, they pay more attention to stability, cost, latency, and accuracy. If usage cannot form a continuous business loop, call-volume growth may be difficult to convert into long-term revenue.

2. Subscription revenue: stable, but requires a clear value anchor

Subscription models are suitable for tool-type scenarios, such as R&D assistants, code assistance, and document generation. The advantage is predictable revenue, but the challenge is that customers must have a clear reason to renew. If a model only improves local efficiency without changing core processes, customers may reduce willingness to pay when budgets tighten.

3. Project-based revenue: visible in the short term, but difficult to scale

Complex hardware design and industry solutions often require deep customization. Project-based work can bring higher average contract values and is also useful for creating reference cases. However, its problems are heavy delivery, low reuse, and unstable gross margins. Every new scenario may involve new requirement understanding, knowledge-base construction, verification processes, and responsibility allocation.

4. Result-based revenue: attractive, but complex to measure

If a model can participate in product revenue sharing, for example by charging based on cost reduction, shortened delivery cycles, or sales increments generated by design outcomes, this model can be closer to business value. However, it requires both sides to agree on data definitions, attribution methods, and audit mechanisms. Without clear boundaries, such arrangements can easily lead to commercial disputes.

High valuations often imply expectations of high-frequency, replicable, and platform-based revenue. But if actual revenue mainly comes from low-frequency custom projects, or depends heavily on a small number of large customers, the valuation model will be challenged. For evaluators, the key question is not whether revenue is growing, but whether revenue has room for repeat purchase, expansion, and gross-margin improvement.

3. Cost Structure: Inference Cost Is Only the Surface; Engineering Validation Is Critical

When people discuss large-model costs, they often think first of inference compute. In reality, in complex engineering scenarios, the real cost is not only incurred during model calls.

1. Inference cost

A model may need to perform requirement understanding, solution design, code generation, multi-round correction, and report output. The more complex the task, the longer the input context and the more generation steps, the higher the cost per task. If a task requires multiple interactions and repeated validation, costs rise further.

2. Knowledge governance cost

For a large model to produce reliable engineering output, it depends on high-quality knowledge bases. Component manuals, design rules, historical cases, process constraints, test standards, and failure records all need to be cleaned, structured, updated, and maintained. This cost is often hidden in back-end R&D work, but it has a long-term impact on model accuracy.

3. Simulation and verification cost

Verification costs for hardware and embedded systems are much higher than for pure text tasks. Circuit simulation, structural simulation, firmware compilation, log analysis, and regression testing can consume substantial compute resources. If verification capability is insufficient, the probability of the model generating incorrect solutions rises, and later rework costs can increase significantly.

4. Platform operating cost

Stable model services require containerized deployment, asynchronous task scheduling, object storage, message queues, logging services, monitoring and alerting, and permission management. For enterprise customers, system availability, data isolation, audit traceability, and cost control are all necessary investments.

Therefore, when evaluating large-model commercialization, it is not enough to look only at “model call unit price.” The end-to-end task cost matters. A successful delivery may include knowledge retrieval, solution generation, simulation verification, human review, version management, and test report generation. Only when the cost per task is lower than traditional R&D costs and quality is stable and controllable does the business model have a foundation for scale expansion.

4. Business Model Risks: Technology Demonstrations Are Not the Same as Continuous Revenue

Large models have significant potential in hardware R&D scenarios, but commercialization risks are also significant. The main reasons include the following.

1. There is a gap between demonstration effects and engineering reliability

Generating a runnable device from a natural-language requirement is a powerful demonstration. However, real commercial scenarios have higher requirements: the device must operate stably over time and meet multiple constraints such as power consumption, thermal management, electromagnetic compatibility, safety certification, cost control, and supply-chain consistency. Demonstration success does not equal successful batch delivery.

2. Long-tail scenarios make revenue difficult to standardize

Software requirements can be complex, but they can still be corrected through version iteration, automated testing, and cloud updates. Hardware scenarios are different. Materials, processes, structures, supply systems, and test conditions all affect outcomes. Because customers differ in industry, usage environment, and compliance requirements, solution reuse can be difficult. If every project requires rebuilding knowledge bases and verification processes, scale expansion will be limited.

3. Raised customer expectations create delivery pressure

When customers see that a model can complete end-to-end design, they often expect higher automation, shorter delivery cycles, and lower costs. If actual delivery requires extensive involvement from engineers, customer satisfaction may decline. If the business model relies too heavily on an “AI fully automated” narrative, while actual delivery remains a hybrid model of AI plus expert teams, an expectation gap may arise.

4. Responsibility boundaries are complex

If a hardware product fails, the consequences may involve safety, equipment damage, production stoppage, or even personal risk. A model can provide design suggestions, but responsibility allocation must be clear. Who reviews the solution? Who bears certification responsibility? Who is accountable for manufacturing deviations? Without resolving these questions, commercialization contracts are difficult to standardize.

5. The data flywheel may not form naturally

High valuations often depend on a data flywheel: the more the system is used, the stronger the model becomes; the stronger the model, the more customers it attracts. However, in industrial and hardware domains, data is often distributed, sensitive, complex in format, and difficult for customers to share. Without compliant data governance and privacy protection mechanisms, accumulated data may not form a real competitive barrier.

5. Enterprise Adoption Advice: Start with Verifiable Scenarios and Build Human-Machine Collaboration Processes

For enterprises that want to use large models to improve R&D efficiency, it is not advisable to immediately pursue “fully automated design of complex products.” Instead, they should start with scenarios that are verifiable, measurable, and risk-controllable.

1. Prioritize low-risk scenarios

At the initial stage, suitable applications include internal test fixtures, prototype validation, modular terminals, and non-safety-critical devices. These scenarios allow fast trial and error, relatively controllable failure costs, and easier standardization of processes.

2. Build human-machine collaborative review mechanisms

Models are suitable for generating candidate solutions, checking design rules, summarizing requirements, and generating test cases. However, final decisions should still be confirmed by engineers. Enterprises can set up multiple review checkpoints, including requirement review, component review, circuit review, structural review, firmware review, and test review. This can improve efficiency while controlling risk.

3. Move verification capability forward

If a model only generates designs without participating in verification, its value is limited. Enterprises should bring simulation, compilation, rule checking, BOM validation, and log analysis into the same platform, allowing the model to iterate within a closed loop rather than output static results once.

4. Build a unified engineering data foundation

R&D data often includes requirement documents, design drawings, version records, component information, test reports, fault logs, and change records. If these data are scattered across different systems, models will find it difficult to form reliable judgments. Enterprises can use object storage on general cloud platforms to preserve version materials, use message queues to handle asynchronous tasks, use container platforms to run compilation and simulation services, and use logging services and monitoring alerts to observe system status.

5. Establish measurable indicators

It is not enough to evaluate AI R&D capability only by “generation speed.” More reasonable indicators include:

• Requirement conversion rate
• Solution feasibility rate
• First-prototype pass rate
• Average delivery cycle
• Inference cost per task
• Rework rate
• Defect density
• Customer repeat purchase rate
• Gross-margin changes

Only when these indicators continue to improve does technical capability truly turn into business value.

6. Valuation Perspective: High Expectations Require High Execution Capability

High valuation is not necessarily wrong, but it requires matching execution capability. For frontier model companies, the market usually focuses on several points.

First, does the model have cross-scenario generalization capability? If it performs well only in a few demonstration tasks and struggles to enter real business processes, the valuation foundation is unstable.

Second, is revenue shifting from one-time projects to continuous services? Continuous subscriptions, platform usage, industry solution replication, and long-term operations and maintenance revenue are more supportive of valuation than a single reference project.

Third, does gross margin improve with scale? If complex delivery relies heavily on expert labor, costs may rise at the same time as scale expands, making it difficult to form software-style scale effects.

Fourth, does the company own accumulable assets? These may include engineering knowledge bases, domain data, validation toolchains, entry points into customer workflows, and industry certifications. If every project starts from zero, the company will struggle to build long-term barriers.

Fifth, are risks controllable? Hardware and industrial scenarios involve safety, compliance, and responsibility issues. If a company cannot clearly define the boundaries of AI output, commercial expansion will be constrained by legal requirements and customer trust.

From an investment perspective, the value of large models in R&D is real, but the path to commercial realization is not easy. The more complex the technical capability, the more rigorous the engineering, productization, and commercialization design must be. High valuation can reflect future potential, but it cannot replace current operating quality.

7. Conclusion: Technical Capability Sets the Ceiling; the Business Model Sets the Floor

The movement of large models from text generation to hardware collaborative design indicates that AI applications are entering more complex engineering domains. This brings both an efficiency revolution and new commercial risks.

For enterprise users, the key is not to blindly chase the concept of “fully automated generation,” but to assess whether the model can reduce error rates, shorten cycles, improve reuse rates, and produce measurable returns in real processes.

For model service providers, the key is not whether a single demonstration is impressive, but whether they can establish stable knowledge governance, verification loops, cost control, and responsibility boundaries.

Applications with long-term value in the future will not be tools that only “generate solutions.” They will be infrastructure that can deeply enter R&D processes, understand engineering constraints, continuously accumulate knowledge, and help customers achieve measurable benefits. Only when technical capability, delivery capability, and business models form a closed loop can high valuations become sustainable growth rather than remain at the level of expectations.