AI’s Second Half Won’t Leave Just One Supermodel Standing | A Conversation with Kevin Ding, PyroMind Founder/CEO

Summary

• Kevin Ding’s core bet on AI’s second half is that ASI will not arrive solely as a single, highly centralized supermodel, but will also take “a service form—the form of Agent swarms.” His reasoning is that the problems and scenarios AI needs to solve “are infinite in number and will keep generating new scenarios,” while the scenarios themselves are not static; “using a model with finite parameters to generalize across infinite scenarios… is still extremely challenging, at least with the Transformer architecture.” He does not rule out the first path, but believes the service path “will definitely work”—demand is already there and continues to grow.
• PyroMind evolved from RL as a Service to Auto RL-powered RSI (self-improvement) after discovering that “Service only solves half the problem.” RSI is gaining attention precisely because more Agents are being deployed: “If 1 person is carrying dozens of Agents in their daily work, they can’t possibly have the bandwidth to maintain the evolution of every Agent.” Agents therefore need to iterate on their own, bringing both training and reward into the loop.
• Commercially, PyroMind has “initially achieved PMF”: a single large customer pays RMB1M–10M, 2 FDEs support 10-plus B2B customers, and the workload of horizontal replication is gradually declining. Koji described the financing as an angel round; Kevin confirmed that the company completed 1 round after incorporation, with Hillhouse, Baidu Ventures, BlueRun Ventures and Vertical among the investors. The team has 20-plus people. The strongest outcome metric is in quality inspection: based on approximately 10,000 samples, the false-positive rate fell from 23% to 8%.
• The key abstraction for scaling is “stateless”: instead of a stateful environment coupled to customer context, PyroMind builds a stateless Auto RL pipeline. “I can’t package Customer A’s state into the product and then sell it to Customer B”—the main exchange with customers is data in and an updated model out. The competitive field splits accordingly: Apply Compute scales vertically inside leading enterprises and takes care of everything, while DeepMind-linked Trajectory is closer to PyroMind’s philosophy—focusing on training and scaling horizontally.
• The verdict on the Harness route is that enterprise demand forms an impossible trinity of cost, speed and privacy: Harness can solve speed, but “privacy definitely cannot be solved,” while methods that leave model parameters untouched have a questionable ceiling. The PCB EDA case illustrates the point: a Base Model could not have encountered such samples during pretraining, so “no matter how much Harness work you do, it will struggle to reach the ideal state.”
• The new Paradigm is a collaborative inference engine pairing a 4B Worker Model with any Base Model—open or closed source, with no need for gradients—lifting benchmark performance by about 10% and cutting costs by about 20% when lambda is small. The 4B model can run on-device on a Mac, making inference costs nearly zero. Its 3-stage training process covers difficulty classification, routing and GRPO. The next step is an unreleased privacy reward: sensitive tokens will be masked before the request is routed back to the Base Model. Unlike Thinking Machines’ Tinker, whose LoRA is tied to the Base Model, Paradigm is decoupled from the Base Model and can switch models.
• PyroMind fears neither foundation models nor cloud vendors: foundation models are “good enough and not enough,” and in production “you cannot just connect a model API to the site and expect it to run by itself.” The stronger the foundation model, the less pressure on the Worker Model—PyroMind is standing on the shoulders of giants, not competing with them. Cloud vendors pursue too many objectives, so their eventual products cannot be as agile or specialized as PyroMind. Citing a Hugging Face report, Kevin noted that local models above 100B account for very few downloads, while models below 100B dominate, suggesting substantial demand that must be addressed through distributed systems.

Deep dive

1. Setting the Tone: Auto RL as a Concrete Implementation Path for RSI

• Kevin Ding was born in 1994, graduated from King’s College London and previously worked on infrastructure at Alibaba Cloud, covering elastic GPU instances and GPU training clusters. PyroMind’s one-line positioning: “It is an Auto RL system—effectively, a fairly concrete implementation path for the RSI direction everyone is discussing.” The company completed 1 round after incorporation, with Hillhouse, Baidu Ventures, BlueRun Ventures and Vertical among its investors; the team now numbers 20-plus.
• He defines “initially achieving PMF” along 2 dimensions. First, proving that Auto RL-based RSI “creates value in production” and that the commercial model at least works. Second, proving scalability: when replicating across scenarios and customers, “our workload gradually declines.”

2. The Fork in AI’s Second Half: Supermodels vs. Agent Swarms

• In the second half of 2025, Kevin observed the community, Silicon Valley and China’s technical circles converging on 2 possible paths for AI’s next phase: continue scaling pretraining toward a “massively large centralized model,” or see ASI arrive “in a service form, in the form of Agent swarms.” He clearly backs the latter: “The problems and scenarios in this world that need to be solved by AI… are infinite in number and will keep generating new scenarios,” while the scenarios themselves are not static; “using a model with finite parameters to generalize across infinite scenarios is still extremely challenging, at least with the Transformer architecture.”
• More than 1 year later, the validation signal is that he does not claim to have disproved the first path, but the service path “will definitely work.” RSI is now being discussed so frequently “because this is actually the result of service-based deployment.” As more Agents are deployed, “if 1 person is carrying dozens of Agents in their daily work, they can’t possibly have the bandwidth to maintain the evolution of every Agent.” The standard therefore becomes whether an Agent continues to perform as expected over time; the answer is to make the Agent iterate and improve itself.

3. From RL Service to Auto RL: A Pivot Driven by the Product Itself

• The self-correction is worth preserving: “When we first started the company, we thought that building RL as a Service in a flat service form would basically meet the deployment requirements of these Agents. But later we realized that still wasn’t enough.” A service still requires developers to drive Agent improvements, solving only half the problem. To make RSI work, both training and reward had to be addressed, so reward was brought into scope.
• A GUI Agent customer carried the argument through both phases. The first phase provided Studio and a fixed, general-purpose training pipeline, solving the entire infrastructure layer, but the customer “still hadn’t escaped the need to invest a lot of manpower” in updating the Agent. In the second phase, after completing the reward layer for GUI Agents, PyroMind found that if the downstream Agent could continuously feed back real-user feedback, “the loop could actually run automatically.” That led to the launch of EchoMind.

4. 2 Product Layers: Studio for Training Infrastructure, EchoMind for the Full RSI Loop

• Studio is a serverless training-infrastructure service built around “logical nodes.” Developers do not need to care about the physical-machine implementation; they configure training parameters such as DP size and TP size, while PyroMind handles horizontal scaling from 1 GPU to multiple machines.
• EchoMind packages the full RSI process behind the scenes and exposes only a Proxy—a proxy URL—to the user. Once connected to an Agent, it continuously captures the Agent’s execution trajectories and builds a relatively clean dataset. The dataset is processed through a reward structure to generate a training pipeline; after training, the model is redeployed. EchoMind encapsulates the entire workflow, and the customer receives an updated model.

5. Customer Profile: Industry Is the Sweet Spot Because Data Is Rich and Labeled

• The customer-selection logic is to look for environments with the richest real-world data: data generated in production, ideally around problems beyond the model’s existing capabilities. PyroMind’s important customers are currently concentrated in industry, including companies upstream of Nvidia. After undergoing Manufacturing 1.0 and 2.0 upgrades, these companies are relatively well digitized and have accumulated substantial data. Industrial companies also have clear definitions of lean production, so the data they collect often comes with relatively clear good-versus-bad labels, naturally solving much of the labeling problem. Add measurable ROI, and all 3 conditions are met.
• The 2 software-heavy use cases are process improvement and quality inspection, with the latter a classic multimodal problem. Electroplating is an example of process improvement: a production line requires a set of parameters, and the right parameters are needed to achieve the desired result; today, this is still handled mainly by “master craftsmen.” The post-training goal is to transfer that human expertise into the model so it can improve quality-control safeguards and manage process variation over long-term operation—and, as incremental data accumulates, “possibly do better than people.” Embodied intelligence is also on the radar, but its hardware component makes it a relatively independent and more complex segment.

6. Statelessness Is the Key to Horizontal Scaling

• The environment problem breaks down differently by domain. In coding, a compiler environment can run every piece of generated code and produce a strong reward signal; it is also separable and not coupled to production-environment information. A GUI Agent, by contrast, cannot be detached from user context if it is to meet each user’s needs; once coupled to that context, it becomes a stateful environment.
• PyroMind’s solution is to isolate the stateless component in the long chain that can scale horizontally—not merely an environment, but an Auto RL pipeline. Data is fed in; a Reward Agent or Reward Model produces a reward signal and advantage to identify the update direction, after which another iteration runs. Alternatively, human labels already present in production feedback data can serve as the reward. Both types of information sit in the feedback dataset and are decoupled from the environment context. Since a product for Customer B cannot simply package Customer A’s state, PyroMind needs a stateless pipeline.

7. The Field Is Splitting: Apply Compute Goes Heavy and Vertical, Trajectory Stays Light and Horizontal

• Companies focused on RL as a Service around the same time last year have now “diverged.” Apply Compute has gone a step further, offering a full-service infrastructure layer that also handles Agent Serving and related functions. It targets a few leading enterprises and aims to “do everything inside the company related to Agents and AI”—scaling vertically within 1 enterprise, with a broader and heavier footprint.
• Trajectory, which has recently gained visibility, was founded by people from DeepMind and is closer to PyroMind in philosophy: it focuses purely on RL and has some partnerships with companies including Mercury, Clay and Harvey, pursuing horizontal scaling. PyroMind is aiming for Auto RL and a platform for stateless RSI capabilities. Kevin believes the second-half spectrum is broad enough for multiple forms; PyroMind has chosen the path better suited to the distributed market of Agent swarms.

8. Pricing and the Ledger: Studio Charges for Resources, EchoMind Allocates Quota by Scenario Value

• Studio is self-serve and charges for resources such as GPU, CPU and storage. EchoMind charges based on scenario value, using quota as the resource unit and limiting the quota of each EchoMind instance according to the scenario’s update frequency. It is not tightly pegged to tokens: if 1 round of Auto RL on a long multimodal execution trajectory costs X, embedding the reward value adds a certain percentage on top of X to determine quota. The main cost is GPU, CPU and other training resources—what Kevin summarizes as electricity and compute. High-value scenarios generate more data and require more training rounds, naturally consuming substantial quota; a small Pro-C scenario only needs to reach baseline and consumes less.
• For large-grained customers with clear ROI, a single customer typically pays roughly RMB1M–10M. Customers assess the price against the ROI in their specific scenario and the share of that ROI represented by the cost. In a quality-inspection case based on approximately 10,000 samples, the false-positive rate fell from 23% to 8%, making both cost and benefit relatively clear.
• The 3 scenario-selection criteria are also the rejection criteria: ROI must be measurable; the use case cannot stray from the multimodal R&D roadmap; and it must be scalable both within the enterprise and across enterprises. Office, invoice and travel Agents are currently difficult to execute. Electroplating is common across the PCB industry, while visible-light and structured-light inspection are nearly universal in manufacturing—precisely the use cases that survive the filter.

9. Why Harness Is Not Enough: The Impossible Trinity and the Need to Modify Parameters

• Koji first layered implementation requirements by asking whether the product is usable and whether performance is good, then whether the enterprise can calculate ROI, and finally whether it can achieve the “impossible trinity” of cost, efficiency and privacy. Kevin agrees that Harness is a lightweight approach that “may solve the speed problem, but privacy definitely cannot be solved.”
• His more fundamental claim is that “if you use a method that does not modify parameters to do this, its ceiling is actually questionable.” Harness provides workflow, skills, memory and other process capabilities; at its core, it operates on context. For a PCB EDA customer, circuit-design diagrams represent an independent deep domain. Most Base Models could not have encountered such samples during pretraining, so even the largest locally deployed Base Model paired with Harness would struggle to reach the desired state. The model’s parameters ultimately need to be modified.
• Public- and private-domain problems need to be separated. For public-domain problems that Base Models already handle reasonably well, a Worker Model can be trained with the specific requirements without pretraining from scratch. Very deep domains require an end-to-end model. When asked about routing privacy-sensitive problems to a local open-source model, Kevin again emphasized that the model still needs to be trained and its parameters themselves need to be modified.

10. Paradigm: A 4B On-Device Model and Any Base Model for Collaborative Inference, With Cost as the Entry Point and Privacy as the Goal

• Paradigm began with PyroMind’s own need: “Web coding is too expensive.” It is a collaborative inference engine that connects a 4B model to a Base Model through a context policy. It places no restrictions on the Base Model, which can be open or closed source because Paradigm does not need the Base Model’s gradients. The 4B model was chosen because it can run on-device on a Mac, making inference costs nearly zero; the trade-off is that performance is not yet good enough and the model needs to be trained.
• Training has 3 stages: first, classify the difficulty of a problem; second, build a routing system in which the small model handles the request first, keeps it on-device if it can solve it, and routes it back to the Base Model if it cannot; third, run GRPO. The reward structure includes correctness and cost, with a coefficient attached to the cost reward. The result is an approximately 10% improvement on benchmarks, while a small lambda can still deliver roughly 20% cost savings.
• Kevin is explicit that the architecture’s potential is not limited to cost. Cost is the entry point for promoting Paradigm; the real product under construction is a privacy solution. An unreleased privacy reward will give the Worker Model the ability to mask sensitive tokens—blocking and processing sensitive information first, then routing the request back to the Base Model.
• The architecture differs from Thinking Machines’ Tinker. Tinker provides a LoRA API, and LoRA must be tied to the Base Model, so migrating across Base Models requires additional work. Paradigm’s Worker Model and Base Model are linked through context but trained independently, allowing the Base Model to be replaced.

11. FDEs, Continuous Training and “SaaS Is Hard—Why Would You Be Different?”

• The most time-consuming work is the FDE engagement when PyroMind first enters a scenario: “this stage cannot be skipped.” The team must understand the customer’s data, domain knowledge and evaluation benchmarks, then adapt the Reward Agent or Reward Model to that scenario. Rewards ultimately converge at the modality level, so some work can be reused across scenarios within the same modality; as the system scales, the workload declines. Kevin is not trying to eliminate FDEs, but to narrow their scope: FDEs mainly handle the front half of reconnecting with the customer’s requirements, while the deliverable is an RSI pipeline that lets production data flow back and continuously improve model performance, forming a T-shaped structure. At present, roughly 2 FDEs support 10-plus B2B customers.
• The need for continuous training comes from changes in specific cases. A production line may look fixed from the perspective of process and quality inspection, but order requirements are not fixed, and the same line may run mixed production. In these deep-domain problems, small differences can materially affect results, requiring continuous learning to keep the application model above a certain performance level.
• Asked why PyroMind should succeed when “SaaS is hard to sell to enterprises,” Kevin’s answer is that the variable is the model: “What we do is teach the model to solve the problem, rather than provide a fixed, software-like service.” The model can create a larger ROI opportunity. There are currently few pure- RSI competitors, but PyroMind may encounter traditional SaaS providers that have spent years building deep domain expertise. If there is no conflict, the companies can coexist; if there is conflict, they can discuss cooperation. In the Agent market, PyroMind will directly face competition from Mercury and Harvey, among others.

12. Base Models, Cloud Vendors and Community Signals: Distributed Demand Supports Paradigm

• Kevin’s view of Base Models is that they are “good enough and not enough.” At a high level, everyone sees Base Models as powerful, but “when you run them in production, you find that a lot of work still needs to be filled in”; connecting a model API to a live environment does not make it run by itself. The stronger the Base Model, the less pressure on Paradigm’s Worker Model; problems outside the Base Model’s capability breadth require an end-to-end model. Customers can choose whether to train the Worker Model or the Base Model. If a company or region wants to build a sovereign model and redo the foundation model, that is also possible—the demand is the driver. Cloud vendors are compared with pretraining platforms: with too many objectives, their end products cannot be as agile and specialized as PyroMind.
• The community-side evidence is a Hugging Face report Kevin cited: among downloads of local models, models above 100B account for very little, while models below 100B dominate. He sees this as evidence that substantial demand needs to be addressed through distributed architectures, making the timing right to launch Paradigm. Products he uses personally include the minimalist coding Agent Pi, Dify, Claude, Kimi, Gemini and the Qwen series. He specifically noted the strong reception for Qwen 3’s 8B and 27B models, and said Dify should already have approximately 140K–150K stars.
• The most rewarding moment came while discussing the Paradigm architecture with CTO Frank, when disagreement turned into consensus: “There was no one convincing the other”; the result emerged from jointly testing different perspectives. Those perspectives “carry their own reward signals,” and under a multi-objective reward structure, the distilled result “may end up being very close to the truth.” The next milestone is mainstream recognition of Paradigm by the community, measured by whether it genuinely solves fixed problems in production rather than merely improving benchmarks.