An End-to-End Player Without Its Own Silicon: Building AI Development in Russia from Traces and Harnesses, Not Pretraining

Start by crossing something out. The phrase “end-to-end” usually drags along a picture of a full vertical from silicon to product, and that picture is what makes the conversation pointless. The public record is thin: in the June 2026 TOP500 list Russia has five systems totalling roughly 69 PFlop/s, all of them V100- and A100-era machines. That silence has to be read correctly: it means there is no publicly benchmarked national-scale cluster on newer accelerators, not that no such accelerators exist in the country.

The record on what is actually trained in Russia is thinner still. The only detailed hardware disclosures are 96 A100 accelerators for an 8-billion-parameter model in 2024, and four nodes of eight H100s for the SFT and DPO stages in the T-pro 2.0 recipe. Both numbers describe post-training, not pretraining. The GigaChat family is trained from scratch, but training compute is undisclosed for every version, so the compute-to-capability ratio cannot be computed.010101It matters not to switch the claim here. Absence of publication is not evidence of absent capacity. But you cannot plan someone else’s strategy on unpublished numbers — and certainly not your own.

Remove pretraining and a perfectly workable loop remains: open base → post-training → harness and tools → evals and environments → traces → and back into post-training. Five of its links are local. The sixth is someone else’s open-weight release, and that dependency gets its own section below. The hardware constraint, meanwhile, does not cap reachable quality — it taxes the number of passes: the only verified published Russian price list implies roughly triple the median of niche foreign providers and about 1.5x a large hyperscaler’s list price. An experiment costing three times more is a tax on iteration count.

An evidence class for every number

Half the public numbers in this field are marketing, so every figure below should be mentally filed into one of three columns.

The single most useful number in this field was published by DeepSeek about itself. The V3 report gives a cost table: pretraining 2,664K GPU-hours, context extension 119K, post-training 5K. Inside one model that is roughly 500 to 1. It is self-reported, it covers only the final run, and it excludes prior research and failed attempts. But the planning input is the ratio, not the sum: if you cannot fund the first column, your entire product surface is decided in the third.

Two independent results confirm this from either side. In the peer-reviewed DeepSeek-R1 paper reinforcement learning lifts AIME 2024 from 15.6% to 77.9% — on top of an existing base model and for a fraction of its cost (the base itself is not included in that figure, and this must be said out loud). And in February 2026 Cursor reported that post-training compute for Composer 1.5 exceeded the compute used to pretrain its base model. The inversion is now explicit.

Meanwhile the entry ticket keeps rising: Epoch AI estimates final-run cost growing about 2.4x per year. That curve structurally excludes any player without hyperscaler-grade capital — not because the team is worse, but because the ticket compounds faster than any plausible procurement ramp. Reinforcement learning, by contrast, has stopped being a craft: work on scaling RL compute fits sigmoidal curves and predicts the outcome of a 100,000 GPU-hour run. That turns RL into a budgetable line item.

The cheapest win, though, is not in training at all — it is in the tokenizer. In the T-pro 2.0 recipe, replacing 34,000 low-frequency non-Cyrillic tokens with Cyrillic ones at a fixed vocabulary size drops tokens per word from 3.12 to 2.38, and raises the share of Russian words fitting in two tokens from 38.2% to 60.1%. That is roughly a quarter less compute on the same Russian text, in both training and inference — a discount denominated in exactly the currency that is scarce.

priority 1 — serving · priority 2 — post-training and environments · priority 3 — tokenizer and data · pretraining from scratch only for whoever has already demonstrated a multi-trillion-token run

The canonical example of an interconnect deficit migrating into model architecture again comes from DeepSeek. In a separate paper they describe how a halved inter-accelerator bandwidth was compensated for beyond the network: latent attention that shrinks the key-value cache several-fold, routing capped at four nodes per token, FP8 training, and hand-written communication kernels occupying only 20 streaming multiprocessors. The network deficit was answered in the model, not only in the fabric.

Huawei tells a similar story. In Pangu Ultra a dense 135-billion-parameter model was trained on 8,192 Ascend accelerators with only 200 Gbps of inter-node fabric, at a claimed utilization above 52%. But the honest counterpoint is published by the same company: Pangu Ultra MoE at 718 billion parameters on 6,000 accelerators reaches only 30%. Sparsity does not always pay off — and these figures are vendor claims.

The most applicable line of work is training with infrequent synchronization. DiLoCo demonstrates about 500x less communication at comparable quality; Streaming DiLoCo cuts transmitted bits 400x and peak bandwidth 8x. The temptation to declare the problem solved is strong, so here is the counterweight immediately: per Epoch AI, decentralized runs sit roughly 300x below the frontier, and the bandwidth-reduction techniques themselves cost quality. The conclusion is narrow and therefore useful: infrequent synchronization is a way to put a fragmented fleet to work on post-training and mid-scale jobs, not a way to reach the pretraining frontier.020202I like that the constraint and the remedy happen to share a shape here. Reinforcement learning is the one large training mode that structurally tolerates a poor network: updates are sparse and episodes are independent. A fleet unfit for synchronous pretraining is perfectly fit for this.

One more hard constraint shapes practice: the quantization format is chosen by the accelerator generation, not by engineering preference. On Ampere, FP8 remains a memory-saving trick and buys no arithmetic speed-up, so the working choice there is INT8 and four-bit weights. A mixed fleet means assembling different artifacts of the same model for different generations.

When the fleet cannot grow, every throughput multiple is equivalent to a purchase that will not happen. The order of magnitude is set by two published results: paged attention gives a two-to-fourfold gain at equal latency, and splitting the prefill stage into chunks yields between 2.6x and 5.6x more served load under a tail-latency constraint. That is a floor, not a ceiling: a stack still using static request batching is losing multiples, not percentages.

The next largest lever is cache-aware routing. In measurements of one open router, accurate prefix accounting moved time-to-first-token by orders of magnitude, simply because the same prefix stopped being duplicated across replicas. Beyond that lies tiering the key-value cache out of fast memory into RAM and onto disk; in DeepSeek's own publication a cached token costs roughly ten times less than an uncached one.

Two techniques deserve conscious handling, because they attract the most confusion. Speculative decoding buys interactivity, not capacity: the gain is large at concurrency of one and nearly vanishes under high parallelism, so the correct posture is adaptive depth. And splitting prefill and decode across separate pools is, by its own authors' admission, a technique for hundreds and thousands of accelerators; for a small fleet the sensible default remains colocation.

There is a strategic asymmetry here worth remembering. When Huawei published CloudMatrix384, the numbers for serving someone else's open model on its own silicon turned out to be quite publishable — in a period when training on that same silicon went considerably worse. Serving tolerates a weak network, tolerates restarts, and scales by adding racks. Large synchronous training tolerates none of that. For a country with a constrained fleet, this means the serving layer is the first one to close.

There is one measurement worth keeping in mind during any conversation about a local stack. In a controlled three-harness by three-model grid, the outcome variance contributed by the harness was 18.48 against 2.37 from the model — a ratio of 7.8. In a separate benchmark, the gap between the best and worst harness on identical tasks and the same model pool reached 23.8 percentage points.

What matters most, though, is not the magnitude but the asymmetry inside it: both papers note that stronger models show less variance across harnesses. In other words, a weaker model is more sensitive to harness quality, not less. For a player who is knowingly not running a frontier model, that is the best possible news: the layer where the most can be won costs engineering taste and no compute at all.

The largest Russian vendor has, incidentally, already voted for this conclusion with its feet. Yandex SourceCraft CLI ships no proprietary harness — it runs OpenCode built in under an MIT licence, with the company's engineering going into integration with its own models, platform tools, and skills. That is a strong argument for adapting rather than rewriting at the harness layer.

What in the harness actually governs capacity is visible in the characterization of agentic traces: an input-to-output ratio around 294 to 1, the overwhelming majority of input tokens hitting the prefix cache, and a hit rate that drops noticeably on a new user message compared with a continuation after a tool result. Hence a concrete list of decisions, none of which requires compute: prefix stability and ordering, the shape and volume of tool results, the context-truncation policy, the cache retention horizon, and routing between models of different sizes. Naive context truncation destroys the very asset your capacity rests on.

The layer everyone forgets: the substrate

An agent that builds a project, installs dependencies, and runs tests inherits the reliability of git clone and pip install. In 2026 that stopped being a theoretical concern: per independent measurement data, the share of failed connections to the largest code host from Russian networks rose from about 4% to 16% in May, and in June the main Python package repository was unreachable for a day. The industry's answer was in-country mirrors of package registries. The design conclusion is simple: before tuning harness quality, make the dependency and container planes that tool calls hit resolve deterministically.

And a correction to the optimism straight away: in a survey of large customers, Russian development tools scored an average of 5.8 out of 10, and about 70% of respondents keep using foreign platforms in parallel. Corporate code sits neither cleanly on-premises nor cleanly in a domestic stack — it is split, and a harness designed for one clean environment will underperform its spec.

Weights can be downloaded, the serving engine taken open-source, the harness adapted. Traces from your own product, evals on your own tasks, and environments reproducing your own work can be neither bought nor rented. This is the only layer where a local player is structurally stronger than any external vendor — which is exactly why it should be built first.

An environment is a concrete thing: a repository snapshot, a task statement, a verifier withheld until scoring time, and a reward. The public scaling axis has moved precisely here — from 20,000 parallel environments at Qwen to 807,693 environments automatically constructed from real pull requests. The economics happen to suit a hardware-poor player: per Epoch AI a task costs $200–2,000 and represents labour rather than compute, while the run itself is cheap — in the open DeepSWE experiment 64 accelerators over six days reached 42.2% on SWE-bench Verified. The environment corpus is a permanent, labour-intensive asset; the run is a one-off, schedulable expense.

The Polar work deserves separate mention: an agent can be RL-trained on top of someone else's unmodified harness by intercepting the exchange at the model-API boundary. In the published measurements this lifted one agent on SWE-bench Verified from 3.8% to 26.4% without a single edit to harness code. The practical implication for a local player is large: owning the harness and owning the training can be decoupled.

The value of your own evals is rising for an external reason. In February 2026 OpenAI stopped reporting SWE-bench Verified: models reproduced the reference patch from the task identifier alone, and of 138 audited hard problems more than 60% turned out to be unsolvable as written. The public leaderboard stopped being a measuring instrument — which is exactly the argument that raises the price of a private, freshly collected set.

The Russian-language part of the picture confirms the same thing from another angle. In the open 1C benchmark tasks are compiled and executed on the real platform, and the best foreign models solve roughly half; no Russian model appears in the table at all. The domain where a local player holds the most data is the domain where every model is weakest. That divergence is the definition of an opportunity.030303Worth pausing here. Verification by compiling and executing on the real platform is the cheapest way to get an honest reward. You do not have to buy it from anyone, and it cannot be contaminated by someone else’s dataset.

The claim the industry states reluctantly has been published by the companies themselves. The Alice AI tech report says outright that training runs on top of initialization with Qwen3-235B weights, and that this was chosen deliberately over training from scratch. T-Technologies never concealed it either.

More consequential than the fact itself is that the dependency is not single. In the published T-pro 2.0 recipe, foreign open weights appear at least four times: as the base checkpoint, as the teacher used to regenerate answers in the training mix, as the initialization of the reward model, and as the draft model for speculative decoding. An end to open-weight publication would break not one thing but four.

The legal layer creates less risk than is commonly assumed — worth saying plainly, because the market usually fears the wrong thing. The leading open families ship under permissive licences with no geographic restrictions. The reverse asymmetry does occur, though: some Russian open weights are released under bespoke licences that terminate automatically once a usage threshold is exceeded. Local “openness” is sometimes stricter than foreign openness, and the text matters more than the label.

The real price of the dependency is set not by the licence but by the regulatory category. The emerging framework distinguishes a model requiring full reproducibility of the entire cycle from a model in which foreign components under open licences are permitted. The decisive definitions — whether weights count as a “component” and whether a given licence qualifies as “open” — are deferred to secondary acts that do not yet exist. The practical meaning: starting from someone else's base is not disqualifying, but a ruling on those definitions could change a model's category with no technical change whatsoever. Precedents exist: in Korea's sovereign programme one team was dropped precisely for using a foreign closed component inside its own model.

The substitution drill

What follows from all this is not rhetoric but an exercise. A base-substitution plan that has never been executed is not a plan — it is a hope.

• —the post-training recipe is written so that it does not depend on a specific checkpoint: tokenizer, data, environments, evals, and the serving stack are separated from the base;
• —a second base is kept warm in advance — not as an idea, but as a passing build;
• —specific GPU-hours and specific weeks are budgeted for the return to parity;
• —parity is measured on a Russian-language eval you own, not on a public leaderboard;
• —a legal event counts as a trigger too, not only a technical one — a ruling on licence status lands instantly and without warning.

The negative half of the programme matters more than the positive one, because a scarce resource is consumed first by unsuccessful bets.

A separate word on domestic silicon, because it carries the most expectation. What is public is the process node and the power envelopes of announced parts — not measured performance and not memory bandwidth. That is enough to establish these are edge-inference devices and not enough to rank them against anything. Nothing in the public record puts Russian silicon inside a training loop this decade, and building a strategy on announcements means substituting a roadmap for a wafer.

The division of responsibility is easier to describe by an own-or-rent call than by vendor logos. Two layers stay yours: evals, traces, and environments — and the harness together with tools and the sandbox. Three stay rented: base weights, pretraining, and the upstream of the serving engine. This split follows directly from the previous sections: the first cannot be bought, the second is pointless to reproduce.

What breaks depends on size. At fifty engineers, measurement fails first: everyone ships, nobody measures, and evals and trace plumbing get done last. At five hundred, something else fails — the sandbox permission boundary, accelerator quota politics, and the prefix-cache hit rate, which collapses as soon as routing fragments across teams. Both failures are organizational, and both are cheaper to prevent than to repair.

A minimal one-year programme

1. 01Measure rather than procure. Instrument agentic traces with in-country storage and de-identification on ingest; measure the actual prefix-cache hit rate and the share of repeated prefill.
2. 02Stand up a baseline serving loop. Continuous request batching, chunked prefill, cache-aware routing, and a fixed quantization matrix per fleet generation.
3. 03Build your own environments and evals. 20–50 tasks drawn from real failures, verification by compilation and execution, grading code withheld until scoring, a private split, and a continuously refreshed task pipeline.
4. 04Take the cheap compute wins. Tokenizer surgery for your own language mix, plus routing and a distilled small model that pulls bulk traffic off the expensive one.
5. 05Run the substitution drill. Not after the upstream release changes, but on a schedule — with budgeted GPU-hours, budgeted weeks, and a parity criterion on an eval you own.
6. 06Write the spares plan. Treat fleet degradation as part of product strategy rather than an operations chore.

This is best managed by a short set of numbers, none of which is about model quality: experiments per week, cost per accepted task, prefix-cache hit rate, the share of traffic served by the cheap model, the time from a trace appearing to a corresponding eval existing, and the time to swap the base checkpoint in a test loop.

The question nobody plans for

There is a topic absent from every public strategy I know of: the fleet ages and is not replaced. Ampere-generation accelerators are 2020 silicon, and under current conditions there is no ordinary warranty-replacement path. That makes the spare-node inventory, the checkpoint-restart design for unreliable and irreplaceable hardware, and the tolerable share of dead nodes decisions about the company's future capability rather than an operations chore. Capability in 2029 will be determined by the spares plan written now.

Adjacent to it sits a security question barely covered in public engineering literature: an agent with terminal access inside a protected perimeter. Egress policy, secret handling, the list of what the model may read, and the separate question of whether the serving loop itself becomes a significant infrastructure object. There is no ready rule here, and that is worth admitting rather than presenting as solved.