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. I covered RedMadRobot’s trend report on Russian GenAI on my channel, and it shows the same picture from the other side: the newest accelerators are officially unavailable, the bet is on owned capacity, and essentially one player trains from scratch.Knizhny kub · trend report on the Russian GenAI market (in Russian)01It matters not to switch the claim here: absence of publication is not evidence of absent capacity. I covered RedMadRobot’s trend report on Russian GenAI on my channel, and it shows the same picture from the other side: the newest accelerators are officially unavailable, the bet is on owned capacity, and essentially one player trains from scratch.Knizhny kub · trend report on the Russian GenAI market (in Russian)

Remove pretraining and a perfectly workable loop remains: open base → post-training → harness and tools → evals and environments → traces → and back into post-training. Four of its links are local. The fifth 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. This is my own comparison of public price lists as of July 2026, not an industry index: the median was taken over published niche-provider tariffs, and a different sample shifts the ratio. 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.020202John Schulman puts it even more bluntly on the Cafe Cursor podcast: in his view ChatGPT-3.5 could have been assembled by two or three people on a couple of accelerator boxes, because the secret was smart post-training rather than the amount of compute. I covered that episode on my channel.Knizhny kub · John Schulman on scaling RL (in Russian)02John Schulman puts it even more bluntly on the Cafe Cursor podcast: in his view ChatGPT-3.5 could have been assembled by two or three people on a couple of accelerator boxes, because the secret was smart post-training rather than the amount of compute. I covered that episode on my channel.Knizhny kub · John Schulman on scaling RL (in Russian)

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.030303I like that the constraint and the remedy happen to share a shape here: reinforcement learning structurally tolerates a poor network — updates are sparse and episodes independent. The flip side is visible in the GigaChat 3 Ultra tech report I covered on my channel: training a large sparse model runs straight into brutal inter-accelerator communication, expert load imbalance, and checkpoints north of ten terabytes.Knizhny kub · the GigaChat 3 Ultra tech report (in Russian)03I like that the constraint and the remedy happen to share a shape here: reinforcement learning structurally tolerates a poor network — updates are sparse and episodes independent. The flip side is visible in the GigaChat 3 Ultra tech report I covered on my channel: training a large sparse model runs straight into brutal inter-accelerator communication, expert load imbalance, and checkpoints north of ten terabytes.Knizhny kub · the GigaChat 3 Ultra tech report (in Russian)

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 (2.6× on Mistral-7B, 5.6× on Falcon-180B). 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 the published llm-d benchmark, exact knowledge of prefix placement reduced P90 time-to-first-token from 92.551 to 0.542 seconds versus random scheduling: requests with a shared prefix stopped being scattered across replicas and recomputing the prefill. Beyond that lies tiering the key-value cache out of fast memory into RAM and onto disk; in DeepSeek's price list a cached token costs roughly ten times less than an uncached one. That is a vendor statement about price, not a measurement of compute saved on your own fleet: it does not carry over to your serving cost.

Two techniques deserve conscious handling, because they attract the most confusion. Speculative decoding primarily reduces the latency of an individual response. When requests are sparse and the main accelerator has idle compute, a small draft model proposes several tokens at once and the larger model verifies them in a single pass, so the user sees the continuation sooner. Under high concurrency, that spare compute disappears: drafting and verification compete with ordinary decoding for the same budget, so total request throughput barely improves. The practical implication is to increase speculation depth when the queue is empty and responsiveness matters, then reduce or disable it under load when throughput matters more.040404Exactly the same shows up at single-machine scale: in a piece on local models I covered on my channel, speculative decoding sped up a dense model by roughly 1.5x on code and translation, while on a sparse model careful tensor placement opened a roughly threefold gap over a naive launch on identical hardware.Knizhny kub · getting more out of local LLMs (in Russian)04Exactly the same shows up at single-machine scale: in a piece on local models I covered on my channel, speculative decoding sped up a dense model by roughly 1.5x on code and translation, while on a sparse model careful tensor placement opened a roughly threefold gap over a naive launch on identical hardware.Knizhny kub · getting more out of local LLMs (in Russian)

Splitting prefill and decode across separate pools is likewise intended primarily for large-scale serving. The DistServe authors explicitly note that with only a few or a single GPU, the design space becomes sharply constrained and the system struggles to improve resource allocation. For a small fleet, colocation therefore remains the sensible default.

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, serving should therefore come first: it is the first layer that can realistically be run end to end on local infrastructure. Large-scale training still requires far more accelerator capacity and a much stronger interconnect.

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 pp² against 2.37 pp² from the model — a ratio of 7.8 in variance, not in score. In the separate Harness-Bench study, 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.050505An honest counterpoint: Nik Pash of Cline argues the exact opposite — model capability wins, and the clever layers built on top of it are obsolete. I covered his talk on my channel, and I think both claims hold, just at different points on the scale: at the frontier harnesses converge, below it the harness is what decides.Knizhny kub · Cline on the model beating the harness (in Russian)05An honest counterpoint: Nik Pash of Cline argues the exact opposite — model capability wins, and the clever layers built on top of it are obsolete. I covered his talk on my channel, and I think both claims hold, just at different points on the scale: at the frontier harnesses converge, below it the harness is what decides.Knizhny kub · Cline on the model beating the harness (in Russian)

One of Russia's largest vendors 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.

Which harness choices govern available capacity is shown by the TraceLab study (Zhu et al., 2026): 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.060606Worth 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. Cline-Bench, which I covered on my channel, is built exactly this way: a repository snapshot, a real user request, and checks taken from code that actually shipped to production.Knizhny kub · Cline-Bench and the RL environment factory (in Russian)06Worth 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. Cline-Bench, which I covered on my channel, is built exactly this way: a repository snapshot, a real user request, and checks taken from code that actually shipped to production.Knizhny kub · Cline-Bench and the RL environment factory (in Russian)

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.070707This is a long-standing, deliberate strategy rather than an accident. The T-lite and T-pro training report I covered on my channel spells it out: the point of continued pretraining is to adapt already-strong open models while spending orders of magnitude less than the people who built them.Knizhny kub · the T-lite and T-pro training report (in Russian)07This is a long-standing, deliberate strategy rather than an accident. The T-lite and T-pro training report I covered on my channel spells it out: the point of continued pretraining is to adapt already-strong open models while spending orders of magnitude less than the people who built them.Knizhny kub · the T-lite and T-pro training report (in Russian)

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 — for example, Qwen3 under Apache 2.0 and DeepSeek-R1 under MIT — use worldwide licences with no geographic restrictions. The reverse asymmetry does occur, though: the open weights of YandexGPT 5 Lite are released under a bespoke licence. Once usage reaches 10 million output tokens in a month, the licensee has 30 days to contact Yandex and agree on further terms. If they neither make contact nor reach an agreement within that period, the licences are revoked and the agreement terminates. Local “openness” is therefore 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. Draft law No. 1271570-8 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. A similar precedent already exists: in South Korea's Sovereign AI Foundation Model project, Naver Cloud did not advance to the second stage because the evaluation committee found that its model failed the test of technological independence — including freedom from licensing constraints and external control.

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.

When compute is scarce, a losing bet consumes capacity that could have gone to a stronger one. The programme therefore needs not only a list of priorities but an explicit list of things it will not fund — with a reason and a workable alternative.

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 classify them as edge-inference parts, but not enough for a meaningful comparison with available accelerators. There is currently no public evidence that Russian parts will be usable for training large models before the end of the decade. Strategy therefore has to be built around available hardware, not promises in roadmaps.080808What matters is that the barrier is not only silicon. A CodeFest talk on AI hardware I covered on my channel makes the point well: NVIDIA’s monopoly rests on software — the CUDA ecosystem took twenty years, Flash Attention reached AMD cards a year late, and consumer cards cannot be clustered for training efficiently, because the fast inter-card links are missing.Knizhny kub · where AI hardware is heading (in Russian)08What matters is that the barrier is not only silicon. A CodeFest talk on AI hardware I covered on my channel makes the point well: NVIDIA’s monopoly rests on software — the CUDA ecosystem took twenty years, Flash Attention reached AMD cards a year late, and consumer cards cannot be clustered for training efficiently, because the fast inter-card links are missing.Knizhny kub · where AI hardware is heading (in Russian)

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. The logic is straightforward: external evals, traces, environments, and harnesses cannot replace knowledge of your own tasks, so those layers must be built in-house. Base weights, pretraining, and serving-engine upstream are already available externally; with accelerators scarce, recreating them from scratch is uneconomic.

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 is not merely ageing; it is falling behind a moving technological baseline. Ampere and A100 arrived in 2020, Hopper and H100 in 2022, Blackwell in 2024, and Vera Rubin entered full production in 2026. The reference point for large AI systems moved three times in six years, while under current conditions the installed fleet has no ordinary warranty-replacement path.

The gap is not measured in TFLOPS alone. Hopper brought FP8 and fourth-generation NVLink, Blackwell brought FP4 and the fifth generation, and Vera Rubin brings HBM4 and the sixth. Quantization formats, kernels, memory capacity and bandwidth, and the expected topology all change with the generation — from an individual accelerator to a rack-scale system. A build optimized for Blackwell or Vera Rubin may therefore need a separate fallback path to run efficiently on Ampere or Hopper.

Planning has to be generational: which models remain on Ampere, which workloads are worth moving to Hopper, and how artifacts from the Blackwell and Vera Rubin world will be simplified for the fleet actually available. Spare-node inventory, checkpoint recovery, the tolerable share of dead accelerators, and fallback quantization formats and kernels are decisions about the company's future capability rather than an operations chore. Capability in 2029 will be determined by the migration and 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.

Russia does have a player capable of pretraining from scratch: the GigaChat team describes its model family in precisely those terms. But this is a capability at the scale of the country's largest companies, not a realistic test of end-to-end ownership for every local player. For most teams, being end-to-end means closing the loop from trace to release entirely inside their own jurisdiction — and winning where wins are not bought with accelerators: in environments, evals, tool contracts, and the speed with which a real failure becomes a safe improvement. The difference between a strategy and a slogan here is exactly one thing: whether the dependency has been named and its replacement rehearsed.