Documentation

Fifteen documents from the source archive. They are written in Spanish, because they are transcriptions of the repository and not copy written for this site, so each one opens as a page in its own language with its original file one click away. All fifteen travel in the same download.

The formulas are not typeset. They are shown as source, exactly as they appear in the file, because typesetting them would mean shipping a maths renderer heavier than the rest of this site put together. Ten of the fifteen documents contain none.

Start with verify.md if you want to check a number on the home page: it names the two entry points and the environment variables, and every figure comes from one of them.

Architecture and ownership

  • architecture.mdwhat lives in Rust, what lives in Python, where the frontier is and what each layer guarantees
  • scm.mdwhere each crate lives, what guarantee it gives and how one is promoted into core
  • hosting.mdthe organization as the canonical owner, and what happened to the old account

Routing and growth

  • routing.mdcost-aware routing: the cost model, the shortest path and failover
  • swarm-routing.mdselection by model, load spread between copies and failover by redundancy
  • redundancy.mdcapacity score, layer assignment and head replication
  • growth-protocol.mdthe FSENNL score and the three growth actions

The model and the adapter

  • ncm.mdthe model, the residual vector quantizer and the transformer fragments
  • telomerase.mdLoRA, federated merging and the gRPC service
  • data-architecture/model-zoo.mdadapted variants and device-aware selection, over the catalog both planes read

Measuring and verifying

The three growth actions, in text

When a node arrives, the growth protocol picks one of three actions. The home page used to draw them; it does not any more, so they are written here. This is an illustration of the routing model, not a benchmark: latency and throughput are not measured on this page either.

  1. 1 old-tablet The node cannot hold a new segment, but it can hold a replica. The red segment is already on another node, so this one takes a copy: the pipeline keeps its shape and gains a second holder of that layer.
  2. 2 beast There is capacity to make the model longer. New layers are added at the end of the chain and the new node holds them, so the swarm answers questions the shorter model could not.
  3. 3 seer The node brings its own model rather than more of the same one. It joins as an expert, and the router sends it the requests its model is better at.

An edge appears when a node joins: a route continues the chain, a replica copies a segment, and an expert adds a model. The three are different actions, and the score that chooses between them is the FSENNL one, measured in growth-protocol.md.

Honest limitations

What the design does not solve, without dressing it up.

  • Growth in intelligence is gradual, not instant.

    Merging an adapter improves behaviour in the direction of the local data; it does not turn a small model into a large one. It takes many rounds and representative data.

  • Averaging can make a node worse.

    Federated averaging does not guarantee that every node improves: two nodes with opposite distributions produce a midpoint that can be worse than both ends. Fixing it needs loss weighting or adapter clustering, and neither is implemented.

  • Network latency is still the physical limit.

    Every hop adds milliseconds; over WiFi the queue explodes. Ethernet is a requirement, not a recommendation.

  • Heterogeneity demands accurate profiles.

    A misreported video memory makes the scheduler place a segment that does not fit. A profile can be faked and the system does not verify it.