The Second Half of AI Won't End With Just One Supermodel｜A Conversation With Kevin Ding, Pyromind Founder/CEO

👦🏻 Podcast interview: Koji

🥷 Edited by: Crossing

🧑‍🎨 Layout: Zeoooo

🚗 This week on Crossing, our guest is Kevin Ding, founder and CEO of Pyromind. Pyromind operates in what's often called RL as a Service — reinforcement learning as a service, or post-training as a service. The company recently closed an angel round with investors including Hillhouse, Baidu Venture, BlueRun Ventures, and Atypical.

But in Kevin's view, RL as a Service is just the starting point, not the destination. On the show, he said service only solves half the problem. To truly get Agents to keep improving in production environments, you need to string training, rewards, feedback, deployment, and data feedback into an automatically looping pipeline — that's AutoRL, the bet Pyromind is making.

We also talked about Pyromind's real-world use cases: industrial quality inspection, process parameter optimization, GUI Agents, Coding Agents, and those production problems inside enterprises where ROI is clear, data is rich, and the criteria for good versus bad are relatively well-defined.

At the same time, this episode tackles a very practical question: how can enterprise AI actually escape the project-based consulting trap?

Kevin was candid that on the first entry into a customer scenario, FDE work is unavoidable: understanding data formats, evaluation baselines, business processes, and reward signals. But Pyromind's goal is to make this effort gradually decrease across similar modalities and similar scenarios, turning one-off delivery into a horizontally replicable AutoRL pipeline.

Kevin shared in detail their new work, PyroDash: a large-small model collaborative architecture built from a 4B small model, a strong base model, and a collaboration engine. Behind this, Kevin argued, lies a bigger conviction: the world of needs is pluralistic, and not every problem should be collapsed into a single centralized large model.

This episode is for anyone who cares about AI Agents, post-training, enterprise intelligence, industrial AI, and AI infrastructure.

Listen on WeChat:

Listen on Xiaoyuzhou:

🎬 The video podcast is also now live on Koji's WeChat Channels, Xiaohongshu, Bilibili, YouTube, and other platforms.

Rapid Fire

👦🏻 Koji

Kevin, how old are you?

👨🏻‍💻 Kevin

Born in '94, so 32.

👦🏻 Koji

Your educational background?

👨🏻‍💻 Kevin

King's College London.

👦🏻 Koji

MBTI and zodiac sign?

👨🏻‍💻 Kevin

Test results say INTJ, though I feel like I'm somewhere between I and E. Zodiac is Capricorn.

👦🏻 Koji

One sentence to describe Pyromind.

👨🏻‍💻 Kevin

The ultimate positioning is AutoRL. It's a relatively concrete implementation path toward the RSI direction that everyone's been discussing.

👦🏻 Koji

Funding status?

👨🏻‍💻 Kevin

We did a round right after founding last year. Investors include Hillhouse, Baidu Venture, BlueRun Ventures, and Atypical.

👦🏻 Koji

Current team size?

👨🏻‍💻 Kevin

A little over 20 people.

👦🏻 Koji

Can you share revenue and profit figures?

👨🏻‍💻 Kevin

I'll skip the specific numbers for now, but what's encouraging is that we've initially cracked PMF.

👦🏻 Koji

What kind of PMF?

👨🏻‍💻 Kevin

Two directions.

First, proving that our AutoRL approach to RSI delivers value in production environments, and that the business model at least holds up.

Second, scalability. The effort required for horizontal replication across scenarios and customers is progressively decreasing.

👦🏻 Koji

Got it. What did you do before starting this company?

👨🏻‍💻 Kevin

I spent a lot of time on infrastructure previously. I was at Alibaba Cloud, working on elastic GPU instances and GPU training clusters.

Why Is the AI Endgame a Swarm of Agents?

👦🏻 Koji

What opportunity did you see that made you decide to start Pyromind?

👨🏻‍💻 Kevin

My thinking at the time was that model pretraining is far from over.

I saw a trend — by the second half of 2025, whether in the open-source community, Silicon Valley, or China's tech circles, everyone was talking about AI potentially entering its second half. Two directions emerged for what that second half might look like.

One direction: we keep going with pretraining, and ASI arrives as a single super-massive, centralized model that can solve the vast majority of scenarios well enough.

The other direction: ASI ultimately takes a service-oriented form, a swarm of Agents.

I personally lean toward the latter because it feels more practical.

The problems and scenarios in our world that need to be solved by AI are already infinite from where we stand today. And over time, new scenarios keep emerging — scenarios themselves aren't static.

In this kind of world, trying to use a model with finite parameters to generalize across infinite scenarios is still pretty challenging, at least on the Transformer architecture.

👦🏻 Koji

It's been over a year since then. Have you seen signals that make your initial bet look increasingly correct?

👨🏻‍💻 Kevin

First, theoretically, we can see that the second path must hold. I can't falsify the first path, but I can argue that the second, service-oriented route is definitely valid — because demand is right there, and it's growing.

One change I've observed this year: why is RSI being talked about now, when it wasn't as hot before? This is actually a consequence of service-orientation. As more Agents get deployed, imagine a person normally carrying dozens of Agents to get something done — there's no way they have the energy to maintain the evolution of each one.

RSI is needed because Agents are multiplying now. When we embed Agents one by one into scenarios, the ultimate measure is whether they perform as expected along a timeline.

The way to achieve that is for Agents to self-iterate, for Agents themselves to have the capacity for self-improvement.

Which Half Does RLaaS Actually Solve?

👦🏻 Koji

So when you first started Pyromind, did you already plan to use AutoRL for RSI? Or did that emerge along the way?

👨🏻‍💻 Kevin

Honestly, it emerged along the way.

We paid attention to the post-training scene partly because we were already looking in that direction, and partly because post-training itself had a big impact on us. You realize that RL, as a representative post-training technique, is about getting feedback from the environment and updating — it's a continuous process.

For our own direction-setting, our team operates the same way. At founding, we thought getting to RL as a Service, to a flat service form, would more or less meet the requirements for Agent deployment. But we later discovered it still wasn't enough. Because service ultimately still needs a Developer on the other end driving the Agent to improve.

That's when we started thinking: service only solves half the problem. To truly get RSI running, we need to solve two things: Training Infra, and rewards.

So we started mapping out how AutoRL would actually run — and by the same logic, rewards became part of our scope.

Koji

Can you walk through a concrete customer example? What's the actual difference in service between doing RL as a Service alone versus doing AutoRL?

Kevin

A good example is a customer of ours in the GUI Agent space. They have massive consumer-grade deployment downstream, so they're constantly collecting user-specific requests as well as their own product iteration needs.

Our initial RL service gave them a Studio with a fixed, general-purpose training pipeline. But they still had to keep putting their own algorithm engineers on updating the Agent itself — we only solved the training part for them.

Because to fully complete a training cycle and ship a model update, you need more than just requirements analysis, algorithm design, and training. The backend infra has to be solved too. We handled all the infra issues for them, but they still couldn't escape pouring significant manpower into this.

In phase two, after we got the GUI-specific rewards working, we realized this loop could actually run automatically. As long as the Agents deployed at their edge could keep collecting real-world user feedback, we thought: why not let it cycle on its own? So in phase two, we pitched them EchoMind.

Koji

You now have two main products: Pyromind Studio and EchoMind. Can you introduce what each of them is?

Kevin

Studio is the serverless service we provide to solve training infra. We implement a large number of logic nodes on Studio that training depends on.

I emphasize "logic nodes" because when developers configure them, they don't need to care about the physical machine implementation — they're mostly just configuring training parameters. The logic nodes scale horizontally, from single-card compute to single-machine to multi-machine, all on one logical layer. The scaling work is ours. For training developers, they just need to set the training parameters and configure things like DP size and TP size.

For EchoMind, we package the entire RSI workflow I just described behind the scenes. What the user sees is a proxy — a proxy URL. Plug this URL into any Agent, and it continuously captures the Agent's trajectories in real-world environments, forming a relatively clean dataset.

This dataset goes through the reward structure, generates a training pipeline, trains, and deploys the result back. The entire flow is wrapped up by EchoMind.

Who Is AutoRL Best For?

Koji

What's the typical customer profile for Pyromind right now?

Kevin

When we filter customers, the core question is whether they need real-world data. And this real-world data needs to first be generated in production scenarios, and second, ideally be outside the capabilities of existing models. That's where model improvement is most pronounced.

We were asking: where is real-world data most abundant? Right now we have some important customers concentrated in industrial — for example, companies upstream of NVIDIA.

They have a characteristic: after Manufacturing 1.0 and 2.0 transformations over the past few years, their internal digitization is quite solid, and long-term production has accumulated very substantial data. That's one indicator.

The second indicator is that industrial scenarios have defined standards for lean production. The collected data naturally carries relatively clear good/bad labels — the annotation problem gets solved naturally in the production process itself.

At the same time, this is a business, so we also have to measure ROI. When all three conditions are met, industrial customers in the supply chain are a good profile.

Koji

Industrial customers are one category. Any other typical customer profiles?

Kevin

Also Agents, or anything embodied-related.

We look at embodied too, but right now it's a relatively separate segment. Our goal is still to do RSI driven by post-training, and we'll definitely move faster in software-first domains for now. Because embodied still has to deal with hardware — that's a more complex problem.

Koji

In doing RL for enterprises, whether RL as a Service or AutoRL, what's the most time-consuming and expensive part?

Kevin

The most time-consuming part is actually the FDE work when first entering a scenario. Even though we do RSI, we don't reject full FDE entirely, because to get RSI to penetrate a scenario, the cold-start phase at initial entry is unavoidable.

We need to adapt their scene's data formats, evaluation benchmarks, and our own Reward Agent or Reward Model to the scenario — that takes time.

But the upside is that in these industries, while the initial cold start requires some work, scaling afterward has decreasing marginal effort. That's a good pattern I've observed. Because doing rewards ultimately still converges on modalities, and across similar modalities, a substantial portion of the work is reusable.

Koji

Last year there was a wave of companies doing RL as a Service. Have most of them, like you, gradually moved into AutoRL or calling it their own RSI?

Kevin

I think there's been divergence. Because demand for the second half is incredibly rich and broad.

For example, looking at some peer companies — a relatively well-known one like Applied Compute has already moved further ahead. They provide a very complete service infrastructure, doing Agent Serving and everything. They target maybe a few head enterprises and take on everything Agent- and AI-related inside the company. That's one path.

Another path is Trajectory, which has gotten attention recently — a very strong company founded by people from DeepMind. Their approach is relatively closer to our philosophy: they're purely doing RL. They also have some partnerships with Mercor, Clay, and Harvey.

Their definition is relatively similar to ours. What we more want to achieve is the Auto part. We want to provide stateless RSI capability as something platform-izable.

Koji

Stateless?

Kevin

Right. These two branches have different properties: the former, Applied Compute, is essentially packaging all scenarios inside an enterprise — a broader and heavier approach, scaling vertically within one company. The latter, Trajectory's direction, is doing just training well and scaling horizontally. We lean toward the latter.

Our understanding of environments is that they were originally a very typical thing in the coding domain. You provide a compiler — every new code snippet you generate, you run it through the compiler, and you get a fairly strong reward signal of whether it passes. Its characteristic is that it's decoupled from the information in your actual production environment; it can be abstracted out.

But for actual production environments, such environments are very limited. Take the GUI Agent I mentioned earlier — if you want to handle each user's specific needs well, you can't detach from their user context. If you do, it loses production value; if it's coupled with user context, it's a stateful environment.

So what we need to do is find the stateless elements that can scale horizontally across this long chain. This thing isn't simply an environment — it's an AutoRL pipeline.

You feed it data, it takes that data through Reward Agent and Reward Model to get a reward signal, and iterates one round. This AutoRL pipeline and the reward itself are stateless, decoupled from production context.

Koji

I'm a bit confused here. If it's a reward signal, shouldn't it emerge from the real production environment? How can it be abstracted out?

Kevin

In specific scenarios, it requires a layer of decoupling.

The reward signal itself is actually when the model rolls out once in the scene, and the corresponding Reward Model or Reward Agent gives an advantage, thereby finding the update direction. That's one method.

The second method is that data flowing back from production scenes contains some human judgment — that's also a form of reward.

These two pieces of information are already decoupled from their context; they're contained in the user-feedback dataset that flows back, not contained in the environment itself.

The pattern difference here is: for us to build a product that scales horizontally and can be sold to different customers, I can't package Customer A's state into my product and sell it to Customer B. That doesn't work.

Koji

In the industrial domain, what specifically have you helped them with?

Kevin

In industry, what we're focused on software-wise is mainly two scenarios: one is process-related process improvement, the second is quality inspection — both are typical multimodal problems, and sweet spots for post-training.

The nice thing about industrial domains is that whether it's process or inspection, the data richness is unimaginable, and there are clear evaluation benchmarks for whether results are good or bad.

Koji

Quality inspection is fairly intuitive. Can you give a more concrete example for process?

Kevin

Process is something like electroplating. Simply put, on the production line there's a batch of parameters that need configuring. Configure them right, and the back end of the line gets the product you want. Configure them wrong, and you don't get what you want.

Right now, this still relies on veteran technicians — it's driven entirely by personal experience. Our goal with post-training is to effectively transfer that human expertise into the model, drawing on both historical data and future incremental production data.

Models are already capable of ensuring long-term quality control stability, and of surpassing human performance as more incremental data accumulates.

Koji

How do you charge?

Kevin

We have two product tiers right now.

The first tier is what we call RL as a Service — the Service layer, or Studio. For users, this is more of a self-service offering with simple resource-based billing (similar to CPU, storage, GPU consumption).

For the upper-tier AutoRL product, we charge by scenario value using a quota system. We set quota limits on instances based on how frequently a scenario gets updated. Because with a product like EchoMind, we're embedding the reward value ourselves. So beyond just providing a solid training service, we're also using our own reward structure to give the correct update direction.

For customers, they don't need to manage anything — they just receive an updated model at the end.

Koji

So the first service tier is basically one-time revenue per model training, while the latter is more recurring?

Kevin

Actually the former is recurring too. The boundary between them is who maintains the RSI pipeline.

For Studio users, the pipeline is built and maintained by the customer themselves, including the Reward Function — we just provide stable Infra Service.

But for EchoMind, because we're embedded in the actual scenario, we internalize that into our Reward Model and maintain it ourselves.

Koji

What's a typical customer's spend with you?

Kevin

Because the RSI form factor we work with has a very broad spectrum. For large-granularity enterprises with clear ROI scenarios, single-customer spend basically falls in the RMB millions to tens of millions range.

AutoRL can improve scenarios with massive amplification effects and high ROI, but also smaller developer-oriented coding scenarios. For small scenarios, the spend granularity is much smaller.

We keep emphasizing horizontal coverage because AutoRL should seamlessly permeate all types of Agents. Whether it's large B2B customers or more B2C / pro-consumer customers, the spend depends on how much value the Agent itself creates.

Our EchoMind pricing uses a single quota metric. It's easy for us to distinguish scenarios: for high-value scenarios, the production loop accumulates large data volumes with high requirements and many training rounds, so EchoMind quota consumption becomes substantial; for narrower pro-consumer domain scenarios where you just need to hit baseline with less accumulated data, quota consumption is much lower.

Koji

When you say quota consumption, do you mean token consumption?

Kevin

It's actually a resource unit we defined to measure one round of RL that EchoMind performs with embedded reward value.

Koji

What is it tied to?

Kevin

It's tied to our internal cost accounting. For example, if one round of multimodal long-trajectory training costs X, after embedding reward value we price the quota at X plus some percentage markup.

Koji

Are your costs mainly token costs, or something else?

Kevin

It's actually training resource consumption — primarily GPU and CPU resources.

How did the false positive rate drop from 23% to 8%?

Koji

When enterprises come to you now, how do they express their needs?

Kevin

This gets to the demand side. Customers don't care about or understand implementation details — the most direct thing is results.

Why did we choose domains like quality inspection and process engineering? Because the results in these domains are obvious. For customers, they only ask one question: what do I need to put in, and what do I get out. Make that clear and you're good.

That's also why we felt RL as a Service wasn't enough. If we only provided a service to such customers and still required them to develop autonomously, that clearly wouldn't work. With EchoMind, we can explicitly tell them: after X rounds of training on historical samples, here's the metric you'll get.

In quality inspection, we can drop the false positive rate from 23% directly to 8% — and that's on roughly 10,000 samples. The customer's cost and benefit become very clear.

Koji

How do they generally understand your pricing? After all, you've created a new pricing system — what do they benchmark it against?

Kevin

Customers understand pricing mainly through the ROI of the scenario and what share of that ROI the cost represents, to judge whether it's worth doing. For us, the main consumption is really compute and electricity — in the end, the math works for both sides.

We're also selective about scenarios with good amplification effects. We don't do every scenario in an enterprise right now. For example, office-oriented Agents, invoice processing, or travel expense Agents — these are harder for us because ROI is difficult to measure, and the pricing framework doesn't hold up well in these scenarios.

Koji

Are there types of requests that keep coming to you but you decide to turn down at this stage?

Kevin

One is where ROI isn't clear.

I have three criteria for selecting scenarios:

First, ROI must be measurable, otherwise pricing doesn't work;

Second, it shouldn't deviate from our current R&D主线 — we're mainly focused on multimodal scenarios right now;

Third, the scenario's scalability within and across enterprises.

Given these three criteria, the domains that currently fit in the software space are process engineering and quality inspection. For example, electroplating processes are universal across the entire PCB industry, and visible-light / structured-light quality inspection is universal across virtually all manufacturing.

Koji

Sounds like it's fairly decoupled from other links in the chain?

Kevin

Not completely decoupled, since upstream and downstream links in the production line are all closely related.

There's an interesting case right now. Production lines are very long, and we take the PQ Phase (Process and Quality) control across the entire line and produce a more abstracted report — this is our Process and Quality control.

The advantage is that it's a unit that AI can solve well. That's how we look at this problem.

How does enterprise AI crack the impossible triangle?

Koji

You previously worked on Infra at Alibaba Cloud, and now you're going deep into individual customers' frontline business operations. What was that transition like?

Kevin

Actually I don't think the gap is that large. Doing Infra is inherently demand-driven — you can't build in a vacuum.

Working with customers now is the same: see the scenario, understand the demand, extract commonalities, find points that can scale up, then productize. This mindset was completely transferable from the Infra era.

Koji

So it's still starting from demand?

Kevin

Right, we actually worked with many commercial customers during the Alibaba Cloud phase too.

At the AI落地 stage, demand acceptance happens in layers.

The first layer is whether the thing works well and whether the results are good. Ease of use and simplicity can be achieved in many ways — user-friendly APIs, or tools like DSH (DeepSeek Harness). Results can be aligned to demand through extensive harness logic, or through post-training to improve model capability.

Going deeper to the second layer, customers consider: is the ROI reasonable for what I'm doing? I need returns — if there's no return, I won't do it.

Then, within enterprises, once demand reaches this second layer, you hit an impossible triangle: good cost, good efficiency, and can it also satisfy my privacy needs going forward?

That's why we chose to do RL and over time make it RSI, rather than focusing on harness — because we saw that long-term, RSI in AutoRL form can perfectly address both layers of demand, especially solving the impossible triangle. This is the work we recently released — PyroDash.

How does a 4B model get more accurate and more efficient?

Koji

Want to tell everyone what PyroDash actually is?

Kevin

PyroDash originated from our own needs, because Vibe Coding was just too expensive.

We built a collaborative inference engine that connects a 4B-size model with a Base Model. Because this collaborative engine拼接的是上下文, there are no requirements on the Base Model — open-source or closed-source both work, and we don't need its gradients.

What we train is the 4B model. We chose this size because it can run on-device (like on a Mac), meaning inference cost is zero. But the problem is its baseline performance isn't good enough, so it needs training.

Training has roughly three stages:

Stage one does easy/hard problem classification;

Stage two does cold start. When a request comes in, the small model takes it first and judges whether it can solve the problem itself. If yes, it resolves it on-device; if not, it routes back to the Base Model.

Stage three is a GRPO process. The reward structure we open-source is one for correctness and one cost reward with a coefficient.

After training for a while, its baseline performance improves somewhat compared to using the Base Model alone. At the same time, because the small model filters out and solves easy problems, costs definitely go down. On benchmarks, it improves by roughly 10%, and when Lambda is relatively small, it can save about 20% in costs.

The potential of this architecture isn't just about lowering costs. What we're currently building is a much stronger B-side privacy protection capability.

Enterprise problems can always be divided into public-domain and private-domain. Public-domain refers to problems where the base model already has decent baseline performance. In these cases, you can use something like PyroDash to train a Worker Model. Private-domain problems are simpler — just solve them end-to-end with a single model.

👦🏻 Koji

So you think no matter how much harness evolves, there will still be problems it can't solve?

👨🏻‍💻 Kevin

Harness is a very lightweight, very good approach. But if you want to optimize across all three dimensions — cost, speed, and privacy — you ultimately still need to dig into and modify the model's capabilities.

Pure harness can solve speed, but it can't solve privacy.

👦🏻 Koji

So harness can't solve privacy. How do you solve privacy specifically, and how do you define it?

👨🏻‍💻 Kevin

Privacy needs to be looked at separately for public-domain and private-domain problems.

On public-domain problems, when we train the Worker Model, we can construct different reward terms. The open-source PyroDash currently provides correctness rewards and cost rewards.

Another piece of work we haven't released yet is a privacy reward term. It gives the Worker Model masking capabilities for sensitive tokens — blocking sensitive information, processing it, then routing back to the Base Model. Because for enterprises, not all context can be thrown at the base model without reservation.

👦🏻 Koji

But can't harness also do simple routing? If you deploy an open-source model locally on your own servers, and route privacy-related questions to that locally deployed model?

👨🏻‍💻 Kevin

So it's an impossible triangle. If you use this approach, how do you ensure the model's output meets your deep scenario requirements?

👦🏻 Koji

Don't you have the same problem?

👨🏻‍💻 Kevin

That's why training is necessary. That's the ultimate goal of our model training work — the model's parameters themselves need to be modified.

If you use a parameter-free approach to do this, its ceiling is questionable. Because when you get into deep domains, there are many problems that if you don't solve through training, you might not be able to solve at all.

👦🏻 Koji

Can you expand on that?

👨🏻‍💻 Kevin

If we have a specific use case, and we get clear data or evaluation benchmarks from that scenario, we can translate those into a series of reward signals. We can teach the model how to complete tasks according to objectives. But for the model to actually learn this, it's impossible to do purely through harness.

Harness mostly provides process-oriented things — workflows, skills, or memory — essentially all working on context. If you don't train the model, the problems it can solve are very limited, and it also depends on the sample distribution of your deployed base model during pre-training.

For example, we have a client in the PCB EDA direction. This is a very independent domain. The vast majority of base models would never have seen such samples during pre-training. Even if you deploy a very large Base Model locally and have it solve this problem, no matter how much harness you do, it's very hard to reach an ideal state. You ultimately still need to modify the model parameters themselves.

👦🏻 Koji

Thinking Machine's Tinker versus what you guys are doing — what's the same and what's different?

👨🏻‍💻 Kevin

Actually quite different. Tinker still provides a LoRA API. We're not spending too much energy on LoRA training at this stage, because LoRA has to be bound to a specific base model, and there's work involved when migrating across base models.

👦🏻 Koji

So your PyroDash work is decoupled, completely decoupled — you can swap models anytime?

👨🏻‍💻 Kevin

Right. From a training methods perspective, the connection between Worker Model and Base Model is at the context level, so it's completely independent during training.

How Do 2 FDEs Serve a Dozen-Plus Enterprises?

👦🏻 Koji

In the process of serving clients, there's the FDE role that needs people on-site to communicate, serve, and sort things out. How do you understand this role now? Are you pursuing minimizing FDE as much as possible?

👨🏻‍💻 Kevin

I wouldn't say we necessarily need to weaken FDE. For a long time, this role will still be needed. What I'm pursuing is the breadth of the FDE role.

Currently the mainstream FDE definition is very broad — need to understand requirements, do adaptation, do delivery, and the delivery form is often Base Model plus harness.

The FDE as I define it only needs to do the first half — take in the requirements, do one round of adaptation on our AutoRL product. The second half of delivery is more about delivering an RSI pipeline that lets production data flow back and continuously improve model performance. This way the FDE's workload drops significantly.

Currently we're serving more than ten B-side clients, and ultimately two FDEs can support all of them.

👦🏻 Koji

But after taking in requirements, does the part that uses AutoRL need other colleagues to take over?

👨🏻‍💻 Kevin

When we're doing a scenario for the first time, the reward structure itself still needs one round of adaptation.

👦🏻 Koji

Isn't that also FDE in some sense?

👨🏻‍💻 Kevin

I don't think so. Our own role allocation is that the people taking in requirements play a foundational, general product role.

They mainly work on cross-domain problems. FDEs only need to purely take in requirements. It's a T-shaped structure.

👦🏻 Koji

Sounds like you're very much pursuing a business that can scale?

👨🏻‍💻 Kevin

It has to be, otherwise you become a technical consulting services company. That model needs to serve the single most head client, relying on one client to sustain the entire lifecycle.

But my judgment is that the ultimate form of ASI is an Agent swarm — it's inherently a distributed market, and you can't approach it with centralized thinking.

The path we've chosen is to use reward structures to make multimodal scenario problems general. As multimodal scenarios multiply, the rewards themselves will have certain reusability, and you can use generalization capabilities to solve new domain scenarios, thus spinning the flywheel.

Externally, we must clearly delineate our role, the client's role, and the boundaries.

We chose AutoRL because its boundaries are very clear: what passes between me and the client is nothing more than datasets, and in the end we give them back an updated model. This pipeline is stateless, and both sides can accept the outcome.

👦🏻 Koji

If models get better and better, and less and less training is needed later, do we make more or less?

👨🏻‍💻 Kevin

This splits into two layers. If it's a static scenario — client gives data, train once, give model back, done. But the vast majority of scenarios aren't static.

For example, the process and quality inspection (AVI) work we do — upstream requirements and cases change every day. Even tiny differences have big impacts on results.

👦🏻 Koji

Process or AVI, meaning quality inspection, why does it change every day? I thought this was pretty fixed work?

👨🏻‍💻 Kevin

From the assembly line perspective, yes. But in reality the specific cases are endlessly varied, constantly changing.

The order demands these clients receive are definitely not fixed, and production on a single line is mixed. You can't do coarse classification, because when it comes to deep problems like process and quality inspection, tiny differences have major impacts on results.

So as long as scenarios are changing, you need continuous learning to ensure the application model stays above a certain baseline.

👦🏻 Koji

In the process of talking to clients, who do you encounter most as bidding competitors?

👨🏻‍💻 Kevin

Currently in our domain, competition is relatively limited. Because this field has certain barriers — it's not a very open field.

What we face more are some traditional SaaS service providers. If there's no conflict with their business, we each do our own thing; if there is conflict, we can also talk cooperation.

Pure RSI bidding competitors are still relatively few in our selected domains. Of course there are many in other domains, like some Agent domains. Trajectory is a pretty successful case, cooperating in the legal domain. If we were to do something similar, we'd definitely face direct competition.

Why Can AI ToB Actually Do the Math?

👦🏻 Koji

SaaS is hard, and you're also To B. Why isn't it hard for you?

👨🏻‍💻 Kevin

When you take on everything in B-side, it is indeed hard. But the scenario slices we've filtered down are very neat.

And the core of B-side business is still doing the math — ROI is the most important thing.

👦🏻 Koji

Why can't SaaS do that math clearly, and why can you? Or do you think you might be able to do it more clearly than them.

👨🏻‍💻 Kevin

The reason is that there's a variable introduced here — the model itself.

Because today's models are still very powerful — they can solve a lot of problems. The key is teaching them correctly. What we're doing is teaching the model, training it to solve the problem, rather than providing a fixed software-style service. This creates cases with much more room for ROI, which naturally makes closing deals a lot easier.

Will Cloud Providers Swallow Pyromind?

👦🏻 Koji

How do you view the potential competitive threat from cloud providers in the future?

👨🏻‍💻 Kevin

First, if more people enter this space, I'd be very happy. It means everyone is exploring their own path on the RSI route.

Second, cloud providers have too broad a business scope and too many objectives. It's like pre-training models — when a platform has super many goals, the final form that emerges can't possibly be as agile and specialized as what we have.

👦🏻 Koji

Do you think today's base models and multimodal base models are good enough? Can new SOTA models still produce significant value improvements?

👨🏻‍💻 Kevin

I think the current state of base models is "good enough, and not good enough."

"Good enough" is the macro, intuitive perception everyone has. "Not good enough" is because once you get into production environments, there's still an enormous amount of work to do — it's not like you can just plug an API in and have it run well.

👦🏻 Koji

So this is the work you do?

👨🏻‍💻 Kevin

Yes, the work we do is a huge part of that. We're also trying to find a relatively convergent path here, because the most direct way to solve this is really just throwing people at it.

But that's not scalable. Our approach is to use a certain amount of human effort early on to build up the reward network.

👦🏻 Koji

When building this reward network, do you have any particular methodologies or tricks?

👨🏻‍💻 Kevin

Really, the most important thing is unifying the modality. Building across modalities is very challenging. Working within a unified modality, there's always transferability.

Regarding the evolution of base models — why do we want to push PyroDash as our main long-term direction? Because essentially all AI startup teams today are standing on the shoulders of giants to move forward.

The PyroDash architecture itself builds a Worker Model and RSI patch on top of the base model. So the evolution of base models is inherently a good thing under the PyroDash architecture.

The better the base model, the less pressure on the Worker Model.

👦🏻 Koji

There's also competition with base models — is it similar?

👨🏻‍💻 Kevin

Base models don't really create much competition. The problems they solve are always broad in scope.

Within the breadth that base models cover, just follow the PyroDash architecture. For things outside that breadth, build an end-to-end model.

We're demand-oriented. You get effective scenario-level rewards from the demand side.

👦🏻 Koji

Got it.

👨🏻‍💻 Kevin

Once you have scenario-level rewards, whether you train a Worker Model or a Base Model — isn't that the client's choice?

If in the future a client says they want to build a private model for a public-domain problem, that's fine, that's their choice. We're just saying from a broad perspective, very few people would choose to do that.

Maybe someday there will be a company or region that says they want to build a sovereign model and redo the coding problem from scratch — that's also possible. Demand is what drives us.

👦🏻 Koji

Let's end on something lighter — what's been the most rewarding moment or thing since you started your company?

👨🏻‍💻 Kevin

Actually it was pretty recent. When I was discussing the PyroDash architecture with my CTO friend, our views were initially different. The most rewarding thing was the moment we reached consensus.

👦🏻 Koji

Did you convince him, or did he convince you?

👨🏻‍💻 Kevin

There's no convincing — we're very open. Everyone was reasoning through it. We have a lot of internal debates, sometimes literally locking ourselves in a room to argue it out, including in embodied AI.

These debates are incredibly valuable. Everyone looks at it from different perspectives.

👦🏻 Koji

Got it, reaching consensus felt very rewarding.

👨🏻‍💻 Kevin

Yes. This is exactly why I love talking with people — everyone brings their own perspective, and each perspective comes with its own reward signal. When you distill results from multi-objective reward signals, you might get pretty close to the truth. That's what I find most rewarding.

👦🏻 Koji

Which AI products do you personally use lately?

👨🏻‍💻 Kevin

I use coding tools more. Recently, for example, PI the Coding Agent — it's a very minimal agent, and I think it's pretty good.

And DSH — DSH is really impressive. It's already comparable to one of the fastest-growing projects in history by stars.

👦🏻 Koji

Yes, didn't it get like 140-150k in three days?

👨🏻‍💻 Kevin

Yes.

Why Is There Still Big Demand for Small Models?

👦🏻 Koji

Which models do you like to use? Any preferences?

👨🏻‍💻 Kevin

I used to use Claude, recently it's been Moonshot AI. And when GLM came out I used that too.

Also, the Qwen series now — Qwen has pretty high actual runtime downloads, it's become a fairly high-usage model.

There's actually another interesting number in the Hugging Face report: for local models, downloads under 100B parameters basically dominate the download volume.

👦🏻 Koji

What does that indicate?

👨🏻‍💻 Kevin

It shows that our direction with the PyroDash architecture aligns with community perception. It shows that the world of demand is diverse — not all needs should be consolidated into one big Base Model for unified solving.

The massive download volume of small models on HuggingFace means there's huge demand that needs to be solved in a distributed form. So this timing for pushing PyroDash is also a very correct one.

👦🏻 Koji

Last question — what's the next milestone you're most looking forward to achieving?

👨🏻‍💻 Kevin

I think the next milestone is PyroDash gaining mainstream recognition from the community.

Because the benchmark for that recognition is whether it really solves specific problems in production scenarios, not just benchmark scores.

After all, this is our long-term direction. The mid-term and short-term directions, we've already validated pretty well.

👦🏻 Koji

Great, thanks Kevin.

👨🏻‍💻 Kevin

Sure, thank you, thank you.