Hedge Fund Day 2

Hedge Fund Day 2: 共绩科技

I visited Gongji expecting to see a compute marketplace.

That was the wrong frame.

The better question is not whether the company can find cheap GPUs and resell them at a higher price. That version of the story is too thin. The more interesting question is whether scattered compute can be made to feel like a product.

It is trying to turn scattered, idle, and uneven compute resources into something customers can actually use.

That sounds simple until you ask what “usable” means.

The Problem Is Not Supply

The lazy version of the AI infrastructure story is that demand for compute keeps going up, so anyone with access to GPUs should do well.

That is directionally true and still not very useful.

Compute demand is not smooth. It spikes, fragments, shifts by model, changes by customer, and behaves differently across training, inference, batch jobs, and experimental workloads. Supply is not clean either. Some resources are centralized and stable. Some are only available at certain times. Some are attached to local government projects, IDCs, cloud vendors, or enterprise clusters. Some are technically available but commercially awkward. Some are cheap because they are imperfect.

So the real problem is not “is there compute somewhere?”

The real problem is:

Can imperfect compute be matched to the right kind of workload without making the customer feel the imperfection?

That is the part I had underestimated.

Idle Compute Has Shape

The word “idle” makes compute sound like loose inventory. It is not.

Idle compute has shape. It has location, network quality, owner constraints, failure probability, setup cost, model compatibility, data sensitivity, and time windows. A GPU that is useful for one customer may be useless for another. A resource that works for offline batch jobs may be dangerous for latency-sensitive inference. A cluster that looks attractive on paper may require too much engineering work to absorb.

This is why I think the marketplace analogy is incomplete.

A marketplace can match supply and demand. A product has to absorb the ugly parts of the match.

For Gongji, the hard work seems to sit in that absorption layer: checking environments, moving images, preparing models, managing caches, routing traffic, handling isolation, recovering from failure, and deciding what kind of task belongs on what kind of resource.

None of that is glamorous. Most of it is the kind of work that disappears when it is done well.

That is usually where infrastructure companies are built.

Elasticity Is A Promise, Not A Feature

“Elastic compute” is easy to say. Customers do not buy the word elastic. They buy a promise.

Sometimes the promise is speed: I need capacity quickly.

Sometimes the promise is cost: I can accept lower priority if the price is meaningfully better.

Sometimes the promise is reliability: I do not care how messy the backend is, just do not make it my problem.

These are different products wearing the same label.

That distinction matters because fragmented compute is only valuable when paired with the right customer expectation. If the customer expects cloud-like smoothness, the platform needs redundancy, monitoring, recovery, and a clear SLA boundary. If the customer wants cheap batch capacity, interruption may be acceptable. If the customer wants a model service, the compute layer is only one piece of the experience.

The interesting question is not whether fragmented resources exist. They do.

The interesting question is which promises Gongji can make repeatedly.

This Is More Operational Than It Looks

From the outside, this kind of company can look like software. You imagine a dashboard, a scheduler, a pricing layer, and some APIs.

The closer view is more physical.

There are machines in different places. There are owners who care about their own workloads first. There are customers who only care about the outcome. There are local policies, procurement habits, data-center economics, bandwidth constraints, and hardware differences. There are models that do not behave the same way on every stack. There are failures that are not theoretical.

This makes the company harder to evaluate, but also more interesting.

If Gongji only works when resources are clean and centralized, then it is closer to a normal rental or cloud-resale business.

If it can digest messy resources and still give customers a usable service, then it is doing something more differentiated.

That difference is the whole story.

The Product Boundary Is Still Moving

The company does not look like a clean single-product software company yet.

It sits somewhere between platform, operator, systems integrator, and technical delivery team. That sounds messy because it is messy. But early infrastructure markets often start this way. Customers do not always know exactly what they need. Hardware changes. Model workloads change. The market is still discovering which layer has the durable margin.

The risk is obvious: too much custom work, too many one-off deployments, too many customer-specific exceptions.

The opportunity is also obvious: if the messy work turns into reusable tooling, the company learns faster than a cleaner but more distant competitor.

That is the distinction I would keep watching.

Not “did they solve one hard deployment?”

But:

Did the last hard deployment make the next one easier?

That is how services become products.

The Government Layer

The government angle is more central than I expected.

That does not automatically make the business better or worse. It makes the business more complex.

Local governments and state-owned players may have compute resources, data-center ambitions, policy goals, or regional platform mandates. What they may not have is the operating capability to turn those assets into actual demand-side usage. A company like Gongji can become useful if it helps convert idle or underused resources into something commercially legible.

But this is also where language can get slippery.

A “platform” can mean policy infrastructure, a procurement channel, an operating system, a dashboard, a business entity, or a slide in a government plan. A “resource” can mean potential, signed, connected, online, dispatchable, or revenue-generating. These are not the same.

So I would not ask whether the company has government projects.

I would ask:

Who owns the resource, who owns the customer, who carries the SLA, who books the revenue, and who gets the profit?

That question is less exciting than the headline. It is also more important.

The Numbers Need Translation

I would be careful with any fast-growing infrastructure company whose business lines are still forming.

Revenue can hide very different things:

• recurring platform usage
• project delivery
• resource resale
• model service
• hardware or software adaptation
• token-related volume
• government or operator-side work

Those categories can all be real, but they should not be valued the same way.

The important question is not just how much money flows through the company. It is where the margin comes from. Is the company earning because it temporarily found cheaper supply? Because it controls customer demand? Because it has reusable software? Because it can operate resources others cannot? Because it does painful integration work nobody else wants to do?

Those are different businesses.

They can coexist for a while, but eventually the market will care which one is the core.

A Sketch Of The Cycle

The most memorable moment was a simple sketch about capital, compute centers, and the AI industry.

I do not read the drawing as a forecast. It is more useful as a worldview.

Capital, compute-center construction, and AI demand do not move at the same rhythm. Capital can rush in early. Physical infrastructure can arrive later. Real usage can develop on a different curve again. The result is a market that can be overbuilt in one place and under-served in another.

That is where a scheduling company wants to live.

If the world were perfectly planned, there would be less need for this business. Every unit of compute would be in the right place, at the right time, owned by the right person, attached to the right workload, priced correctly, and connected cleanly.

The world is not like that.

The opportunity exists because capital, electricity, data centers, models, customers, and policy all move at different speeds.

That does not mean Gongji wins. It means the problem is real.

What I Like

I like businesses that attack mismatch.

This one has a real mismatch: uneven AI demand meeting uneven compute supply.

I also like that the boring layers matter. Image movement, cache design, network behavior, container isolation, model adaptation, monitoring, and recovery are not decorative technical details. They are the business. If those layers work, the customer sees a product. If they fail, the customer sees a pile of unreliable resources.

The third thing I like is that the company may have more than one wedge into the market: commercial elastic compute, model service, resource-side operation, regional compute networks, and domestic hardware adaptation. That gives the company more ways to learn.

It also creates the biggest danger.

Multiple wedges can be strategy. They can also be a lack of focus wearing a better name.

What I Worry About

The first risk is standardization.

If every resource pool, customer, model, and hardware type requires special handling, growth can look impressive while the company quietly becomes a project organization.

The second risk is revenue quality.

Platform usage, resale, integration work, and government projects can all produce revenue. They do not produce the same kind of company.

The third risk is responsibility.

When a company sells reliability on top of resources it does not fully own, the boundary matters. If something breaks, who is responsible to the customer? The resource owner? The platform? The customer? The answer cannot stay fuzzy forever.

The fourth risk is strategic temptation.

AI infrastructure companies sit close to models, customers, hardware, and capital. It is very easy to want to do everything. The discipline is knowing which layer you can actually own.

What I Would Track

If I keep following Gongji, I would track a few boring metrics:

• resources that are truly dispatchable, not just theoretically available
• recurring customers, not just urgent one-off demand
• gross profit by business line
• customer expansion after the first use case
• failure rates, complaints, and recovery time
• speed from resource access to usable delivery
• percentage of work that still requires custom engineering
• cash conversion, especially around public-sector projects
• whether hardware adaptation becomes tooling or labor

None of these are as exciting as the phrase “AI compute network.”

That is why they matter.

My Current Take

Before the visit, I thought Gongji would be easier to describe.

After the visit, I think it is more ambitious and harder to prove.

The weak version of the company is a broker with engineering.

The strong version is an operating layer for fragmented compute.

The difference between those two versions will not be decided by storytelling. It will be decided by whether Gongji can repeatedly make messy resources feel reliable, priced well, and easy enough for customers to use.

That is a real question.

It is also a much better question than “how many GPUs do they have?”