The "Revenue Illusion" of Large Model Companies

A large customer contract worth 5 million yuan looks great in the financing materials.

The customers are real, the scenarios are real, and the contracts are also real. During roadshows, such cases are usually very useful: a leading financial institution, a large manufacturing enterprise, or a local state-owned enterprise has started using the company's large model products.

It sounds like the commercialization has been successful.

However, when investors really dig into the accounts, the problems become much more unpleasant.

Out of the 5 million yuan, how much is the model call fee? How much is the standard product subscription? How much is the private deployment? How much is for interface development, data cleaning, and model fine-tuning? And how much is actually for on-site implementation, subsequent operation and maintenance, manual optimization, and project management?

The contract is real, and the revenue is also real. The question is, should this money be valued as large model product revenue or as project delivery revenue?

This is the embarrassment that many large model companies will face in the future. They have passed the stage of just talking about visions and parameters. Without revenue, it's difficult to negotiate the next round of financing; without customers, the commercialization story can't go on. But when the revenue increases, another problem arises: Is this money brought about by the model's capabilities or piled up by the delivery capabilities?

Two types of customer cases, not the same type of revenue

In the past two years, large model companies have loved to talk about customer cases. This is normal. Large models are too abstract. Only when they enter real scenarios will customers be willing to believe they are valuable. A large customer is more useful than ten pages of model introductions.

However, there are two types of customer cases.

Product - type case: The customer buys a clear product. The deployment path is relatively standard, the functional boundaries are stable, and the next customer can reuse most of the core capabilities. It can be sold to a bank today, an insurance company tomorrow, and a securities firm the day after tomorrow. The core capabilities and delivery processes can be extended.

Project - type case: The customer buys a result. To achieve this result, the company can modify processes, connect systems, adjust models, clean data, and send people on - site to finally deliver the project. The customer is satisfied, and the case looks good. But when the next customer comes, it may have to be redone.

The key to distinguishing these two types of cases lies not in the customer's name, but in which part of the delivery can be reused for the next customer.

Both types of cases can be written as "large model implementation" in the financing materials. But they are not the same type of revenue. The former proves that the product is starting to take shape, and the latter proves that the team is good at delivery.

A benchmark customer proves that someone is willing to try. Large - scale application proves that this thing can continue to operate beyond a single project. This is the difference. The capital market will not always price the two according to the same logic.

Take a look at a 5 - million - yuan contract

To understand where the "revenue illusion" comes from, it's advisable to really break down a 5 - million - yuan contract.

The first layer is the part closest to product revenue: model call and inference capabilities. It corresponds to the call volume, inference services, and model base capabilities. It has the highest reusability and is closest to replicable revenue.

The second layer is standardized private deployment. It includes basic deployment, permission configuration, and industry - common modules. The reusability depends on whether the deployment process can be standardized. If each customer needs to be re - adapted, this part will quickly become a heavy burden.

The third layer is data cleaning and annotation. It includes customer data processing, knowledge base organization, and annotation verification. It highly depends on customer data and has relatively low reusability.

The fourth layer is interface development and system integration. It needs to connect with the customer's business system, permission system, and workflow. It is often affected by the customer's IT environment and is difficult to directly replicate to the next customer.

The fifth layer is on - site implementation and project management. It includes requirement communication, acceptance promotion, and manual coordination. It is closer to manpower delivery.

The sixth layer is subsequent operation and maintenance and optimization. It includes version maintenance, effect optimization, and manual review. It easily consumes manpower continuously.

From the perspective of "replicable revenue", only a small part at the front may be truly close to product revenue. The contract amount seems to be 5 million yuan, but what can be reused by the next customer may not necessarily be 5 million yuan.

It's certainly correct to write this single - order revenue as "large model commercialization". But if the majority of the revenue comes from deployment, implementation, customization, and operation and maintenance, it is closer to project delivery revenue rather than model service revenue.

The more revenue, the less like a model company

The most difficult part for large model companies is that they must prove two mutually conflicting things at the same time.

They need to prove that they have revenue, so they can't easily reject customers. They also need to prove that they are product companies, so they can't accept every demand. In reality, the former often outweighs the latter.

It's hard to reject a large customer's request for private deployment. It's hard to reject a customer in an industry's request for in - depth customization. It's also hard to reject a financial customer's request for security review, permission modification, log retention, and manual review. There are reasons to accept each order. The cash flow needs it, the financing materials need it, and the team morale also needs it.

So the company quickly generates revenue. However, not all of this revenue can support the valuation of a "large model company".

For large model companies, the most troublesome thing is not the lack of revenue, but the fact that as the revenue increases, the company becomes less and less like a model company.

For example, every time the team signs a new customer, it has to hold a new requirement meeting; every time it enters a new industry, it has to rebuild the knowledge base, interfaces, processes, and permissions; every time it completes a project, it accumulates some experience, but it's difficult to directly turn it into a standard product. At this time, the company may have an illusion that more customers mean more market recognition.

But from the perspective of valuation, the problem may be the opposite. More customers mean a larger delivery team; more contracts mean more customization; more cases mean the product roadmap is more led by the customers. The busier the company is, the less like a replicable large model product company it becomes.

Project revenue can grow the company, but it can also damage the valuation criteria. Because the more project revenue there is, the more commercialized the company seems. But if each order is highly customized and each customer needs to be redelivered, the revenue growth will actually expose a problem: The company is not selling a replicable product, but a solution - providing ability with a large model label.

The fifth set of standards brings these problems forward

On June 17th, the Shanghai Stock Exchange issued the review guidelines for the fifth set of listing standards on the Science and Technology Innovation Board applicable to large artificial intelligence model enterprises. The thing that the market is most likely to remember is the "estimated market value of 4 billion yuan". But this figure is still far from most mid - tier companies. What really stings them are the other two words: product launch and large - scale application.

In other words, in the future, the capital market will distinguish earlier whether a company is selling a product that can be repeatedly delivered or doing a project that needs to be redone every time.

These two words will break down a lot of the previously vague "large model commercialization revenue" into more specific categories.

These problems were not supposed to be encountered only before listing. A serious late - stage investor, industrial capital, or acquirer will all ask similar questions. It's just that in the past, many problems could be temporarily covered up by "the large model is still in its early stage", "commercialization has just begun", and "first focus on benchmark customers". After the fifth set of standards came out, this cover will become thinner.

It has the greatest impact on mid - tier companies that have completed several rounds of financing, have a relatively high valuation, have many customers, and are starting to see revenue growth. In their next round of financing, they can't just say "we have large customers", but also need to clarify what exactly has been precipitated from these large customers.

Has a product been precipitated, or project experience?

Has a replicable deployment process been precipitated, or a larger delivery team?

Has stable call and renewal been precipitated, or more one - time contracts?

Has large - scale application been precipitated, or a few expensive benchmark cases?

This is the real pressure brought by the fifth set of standards - not whether the company can go public today, but whether every single revenue today can be understood as the revenue of a large model company in the future.

Large model revenue is being stratified

In the past, "large model revenue" was a very useful catch - all term. API calls could be included, subscription products could be included, and so could private deployment, industry solutions, project delivery, data governance, model fine - tuning, and operation and maintenance services.

In the early stage of the industry, this vagueness was useful. It helped the company prove that customers were willing to pay, and it also helped investors understand that commercialization was starting to happen. But this vagueness won't be useful forever.

In the next stage, large model revenue will be stratified:

The purest is API calls and standard subscriptions. They correspond to pay - per - use and SaaS subscriptions. The boundaries are clear, the reusability is the strongest, and it's easiest for capital to understand them as product revenue.

Next is standardized private deployment. It corresponds to reusable industry modules. It is still relatively heavy, but if the deployment process and module capabilities can be reused, there is a chance to transform from project revenue to a lighter form.

The third category is in - depth customization and one - time industry solutions. They can contribute to cash flow and prove that customers are willing to pay, but it's difficult to naturally prove large - scale capabilities.

The most in need of explanation are on - site implementation, data cleaning, and operation and maintenance. They are closer to service revenue. They can make money, but they can't support the software valuation multiple of a large model company in the long run.

This doesn't mean that project revenue is bad. System integration, consulting delivery, private deployment, and industry solutions can all be good businesses. But they shouldn't enjoy the same valuation as standardized model services, API calls, and subscription products.

The most dangerous thing is not that the company does projects, but that the company grows relying on project revenue but still raises funds as a product company.

Three simple questions

Financing PPTs usually put all these revenues into the same "large model commercialization" story. But what really distinguishes a model company from a delivery company are often three simpler questions:

First, when the next customer in the same industry comes, how many person - days does the delivery team need to reinvest?

Second, how much of the money the customer pays is generated by call volume or subscription renewal, rather than settled according to project milestones?

Third, after removing this project, what does the company have left? A product that can be installed and reused, or a group of people who have worked on this project?

Once the answers to these three questions are clear, how to stratify the four words "large model revenue" will also be clear.

The real change brought by the fifth set of standards is not to open an easier path for large model companies to go public, but to let the market see earlier that some large model revenues are not so attractive after a detailed breakdown.

The next round of differentiation will not only occur in model capabilities but also in the income statement. Those whose customer cases can be transformed into large - scale applications, whose project revenues can be precipitated into products, and whose contract amounts can be converted into replicable revenues are more like large model companies that can be recognized by the public market in the future.

The remaining companies may still be able to make money. But they have to first admit that the money they make may not be the same as that of a large model company.

This article is from the WeChat official account "Path and Boundary", author: Yan Jun. It is published by 36Kr with authorization.