Engy is getting faster. Pareton now tunes how Engy runs its models, so replies come back sooner and each one costs less to serve. Nothing changes for the people building on Engy. Same API, same integration.

Engy is one of the fastest-growing inference networks on Bittensor and beyond. It is a large customer with serious traffic, and that is the workload Pareton was built for.

Kimi K3: the numbers so far

On October 14 we opened a campaign for Kimi K3 on Engy's workload. Three rounds in, the leading patch serves Engy's traffic about 25% faster end-to-end than the engine it started from, on the same eight B300 GPUs, inside the same latency limits.

Faster end-to-end
25%
Same hardware
8× B300
Token match vs. baseline
≥ 0.99
Kimi K3 leader: end-to-end speedup vs. baselineMedian per-prompt speedup on Engy's sampled traffic, 8× B300. Each round draws a new trace.
Kimi K3 leader: end-to-end speedup vs. baseline
RoundSpeedup vs. baseline
Round 1+20%
Round 2+25%
Round 3 (Provisional)+29%

A score only counts if the patch passes the campaign's gates first: p99 time to first token under 2 seconds, p99 time between tokens under 50 ms, and output that matches the baseline token for token at least 99% of the time. The campaign's target is a 10% cut in GPU-hours at that SLA. Round 3 ran with a waiver on the baseline-drift check, so we treat its number as provisional and quote round 2.

Every round, score and patch is public on the campaign page.

Why a real workload matters

Most inference benchmarks run on synthetic prompts at a fixed load. Production traffic does not look like that. Prompt lengths vary, requests arrive in bursts, and the latency a user tolerates depends on what they are doing. A configuration that wins on a leaderboard can lose on Monday morning traffic.

So every Pareton campaign starts from the customer's own profile: the model, the hardware, the serving stack, and a sample of real requests. That snapshot becomes the ruler every change is measured against.

How it works for Engy

  1. 01

    We freeze what Engy runs today as the baseline, along with its latency targets.

  2. 02

    Miners on Subnet 10 submit patches to the serving engine. Each one is benchmarked on the same GPUs and the same traffic.

  3. 03

    A patch is kept only if it is faster or cheaper and the latency caps still hold. It then becomes the new baseline, and the search starts again.

The gains arrive as reviewable code and configuration diffs, not a black box. Engy can see what changed and why it won before anything ships.

If you serve models at scale and want the same treatment, send us your profile.