Hook
Eighty billion parameters. That's the only hard number Yandex gave us, and it's the only one that matters. In FP16 the weights alone occupy roughly 160 gigabytes of VRAM. Quantize to INT8 and you need 80. Push to INT4 and you're at 40 — just under a single A100 80GB, or a pair of consumer cards if you're patient enough to babysit the offload. The "A3B" suffix, if it follows the convention every MoE shop has adopted since Mixtral, means roughly 3 billion parameters activate per token. That's the whole pitch: big capacity, small compute. And that single design choice is what the decentralized-inference crowd will spend the next six months getting wrong.
I've watched this movie. In 2022 I stood up a node to stress-test a Layer 1 that promised to "solve the trilemma," simulated a 15% validator dropout, and watched finality stall for forty minutes. The marketing never survives the harness. So before anyone wires this model into an on-chain agent, let's do the arithmetic nobody in the press release did.
Context
What Yandex actually shipped, per the available reporting, is a foundation model called AliceAI-Foundation 80B-A3B under an open-source license. That's it. No model card, no benchmark table, no full license text, no context length, no training-data disclosure. The reporting is a headline and a verb. Everything past that point is inference — mine and yours.
For readers who live in smart contracts rather than tensors, the mechanical summary is short. A Mixture-of-Experts model is a chassis, not an engine. Instead of running every parameter for every token, it routes each token through a small subset of specialist sub-networks. You get the representational capacity of an 80B dense model with the per-token FLOPs of something far smaller. That's the trade, and it is a real trade, not a marketing one — MoE is why the current generation of open models can be served economically at all.
Here's why this belongs in a blockchain publication and not just an ML feed. The entire thesis of decentralized inference — the networks that rent idle GPUs and pay them to serve model outputs — rests on a specific economic assumption: that a capable model can be split across heterogeneous, untrusted hardware. MoE breaks that assumption in a way dense models do not. Keep that in your pocket. I'll come back with the receipts.
Core
Start with memory, because memory is the wall, not compute. FP16 puts the weight set at 160 GB. INT8 brings it to 80. INT4 to 40. Add the KV cache. Add router overhead. Add activation buffers. A single 24 GB consumer card cannot hold the INT4 weights, let alone the runtime state. You are not running this on a laptop. You are running it on a cluster or a rented slice of one. The A3B activation figure narrows the compute cost of each forward pass, but it does not shrink the resident weight set — every expert has to be addressable, because the router decides at runtime which experts fire.
That asymmetry is the entire engineering problem. Compute scales with activated parameters. Memory scales with total parameters. You cannot quantize your way around a residency requirement.
For a centralized operator — Yandex Cloud, say — that's fine. You amortize 40 to 160 gigabytes of weights across thousands of concurrent requests and the marginal cost per token collapses into noise. That's the actual business model hiding under the word "open."
For a decentralized inference network, it's a knife. Now the routing has to happen somewhere. In a dense model you can pipeline layers across machines and the communication pattern is predictable. In an MoE, every token's route is data-dependent. Expert parallelism means All-to-All communication: tokens scatter to the experts that own them, results come back, then scatter again at the next layer. Inside a single NVLink domain this is fast. Across the public internet, between untrusted heterogeneous nodes, it is a latency and synchronization nightmare. The All-to-All exchange is the consensus protocol of MoE serving — and it is exactly where decentralized inference has no answer. Vulnerabilities aren't confined to the smart contract. They live in the topology.
Here's the second thing the headline buries. "Base model." Not instruct. Not aligned. Base means pre-training weights: raw next-token prediction, no supervised fine-tuning, no RLHF, no safety layer that refuses a harmful request. It knows how language is shaped. It has no opinion about what it should refuse.
That distinction is a rounding error to a researcher and a catastrophe to an on-chain agent. In 2026 I integrated an LLM-based agent framework against a privacy-preserving zk-rollup and found a prompt-injection vector in the oracle feed. A malicious agent could shape the natural-language data the model consumed and steer the transaction output. Two million dollars in a dry run. The cryptography held. The model didn't. The attack didn't touch a single opcode — it touched the boundary where unstructured input entered the decision loop.
A base model sharpens that edge. An aligned instruct model at least carries a trained prior toward refusing manipulative inputs. A base model carries none. Ship open weights with no alignment, wrap them in an agent that signs transactions, and you have built an extremely articulate device for converting prompt injection into irreversible settlement. On EVM chains, "irreversible" is not a figure of speech. There is no chargeback, no support ticket, no freeze.
Now the part that should worry the crypto-native reader even more than the safety angle: verification. The romantic version of decentralized AI is "don't trust, verify." You accept a model's output because you can recompute it or prove it. That works when the model is small enough to run redundantly and cheaply. It does not work here. Nobody is going to re-run 80 billion parameters of a data-dependent MoE on a second node to check a third node's honesty. The redundant-computation schemes that make sense for a 7B dense model collapse under the memory and routing costs of this thing. Cryptographic inference proofs are nowhere near the scale of a sparse 80B model in production.
So the honest summary is this: an open-weight 80B MoE gives you auditability of the weights and essentially nothing else. You can inspect what was trained. You cannot practically verify what was served. The word "open" is doing enormous load-bearing work, and most of the load is wishful.
That should sound familiar. It's the same move USDC pulls: a compliance-first chain of custody that markets itself as a decentralized rail. Circle can freeze any address within a day. That's not a critique of Circle's engineering — it's a critique of the vocabulary. On-chain, we stopped calling permissioned systems trustless a long time ago, mostly because people got burned. Off-chain, we're about to relearn the same lesson with "open" models. Open weights aren't open inference. Verified weights aren't verified outputs. Those are two different claims wearing one word.
Contrarian
Everyone focused on the param count. The paragraph that didn't appear is the one to watch. The reporting says "open-source license." Apache 2.0? MIT? A custom, restricted, region-gated, non-commercial-with-conditions text? We don't know. And that is not a small gap. The license is the entire commercial strategy. "Open-source license" on a press summary is a claim, not a contract. If the terms bar commercial use, gate distribution by jurisdiction, or claw back the weights through a custom clause, then the model functions as a demand-generation funnel for Yandex Cloud and nothing more — which, to be fair, is a legitimate strategy.
But read the licensing silence the way you'd read a contract with an unpinned dependency. The pattern is telling. A base model release, rather than an instruct version, suggests alignment hasn't been finished. A base model shipping in early 2026 without a published model card, a safety evaluation, or an acceptable-use clause is three things missing at once. The absence of that apparatus is itself a data point.
The geopolitical story is obvious: constrained silicon access, MoE as the only architecture that lets you keep a big-parameter footprint on a compute budget, open weights as the cheapest way to recruit external fine-tuners and gather evaluation signal without a salesforce. That's not idealism. That's procurement. And the community is already doing the free labor — spinning up inference replicas, publishing quantizations, filing bug reports — under the belief that they're receiving an open model. The question is whether they get one.
There's a second-order effect nobody is modeling yet. If models like this do get served through decentralized networks, the friction doesn't land on verification. It lands on metering. And every on-chain AI payment rail has the same hard constraint: you cannot put per-token inference cost inside a gas-metered transaction. The gas isn't the model's problem. The gas is the friction of settling thousands of sub-cent inference calls on a chain that charges by the opcode. The narrative that "blob space will absorb it" is the same narrative that said rollup data would stay cheap forever. Blob demand is already chasing the cap. Within two years the cheap-data assumption rolls off a cliff and inference metering inherits the bill.
The irony is sharp. The architecture everyone praised for making on-chain AI affordable — cheap blob data, L2 compression — is the same one that will make on-chain AI settlement expensive just as the agent economy arrives.
Takeaway
So where does this leave us? The 80B-A3B release might be a genuinely good model. It might be the best open Russian-language base model on earth. I can't tell you, and neither can anyone writing about it from a press summary. That's the entire point.
Here's the forward bet. Open-weight models will keep shipping with "open" in the headline, but the defining constraint won't be the parameter count. It'll be whether the weights are actually safe to plug into anything that moves money. Right now, this one isn't — not because of a judgement about Yandex specifically, but because you don't know. Not until someone answers the questions. What's the alignment gap? What's the license? Who can serve it, and can any node prove it did?
Until those answers exist, the only safe deployment for a model like this is behind an airgap, with a human in the loop, and nothing signing transactions. Code that doesn't announce its own limitations is code that gets trusted right up until it fails. The interesting question isn't whether Yandex shipped something. It's whether the rest of us are patient enough to read the model card before we wire it to a wallet. Because if you can't answer what a model refuses, you don't know what it will do — and on-chain, what it will do settles in about twelve seconds.