The Framework That Wants Your Phone to Train Llama 3

There is a coworking space in Kingston, Ontario called Fractal Workspace. It has private offices, SnapCab phone booths, complimentary coffee, and a Google Play app built by OfficeRnD for booking meeting rooms. It has roughly 1,400 Facebook followers and a 100% recommendation rate across 21 reviews. If you go searching for “Fractal Workspace” — the GitHub organization Fractal-Compute-Orchestrations/FractalWorkspace — you will wade through a remarkable amount of Canadian real estate before you find any code. That collision is a fitting introduction to a project whose entire premise is about fragmented, overlooked compute: the phones in your drawer are a datacenter nobody is renting out.

What Fractal Actually Is

Strip away the branding and Fractal is two systems stapled together by a REST API. On one side, FractalCore, a Python control plane: a multi-tenant Flask server that handles authentication, partitions datasets, schedules work, aggregates federated weights, and — in its more ambitious mode — compiles large models into memory-bounded slices. On the other side, FractalAndroid, a native Kotlin app that turns a physical Android device into a compute node, running on-device training through TFLite and memory-mapped inference over partitioned model files.

The project is maintained by a single architect, Ahmad Hassan (B-Ted), and is explicitly labeled active development. It is not, in the conventional sense, open source at all — the license is a proprietary, source-available, non-commercial restrictive license v3.0, with commercial use prohibited without written authorization. That fact alone makes it an odd candidate for GitHub hype, and it shapes everything about the project’s likely trajectory: you can read it, study it, and run it, but you cannot build a business on it without asking permission.

The Two Paradigms

Fractal’s README describes two operational modes, and they are genuinely different problems wearing the same architecture.

The first is federated learning, the now well-established pattern where raw data never leaves the device. The server partitions dataset indices into segment bins, dispatches task descriptors, and nodes download model weights plus their assigned data bin, run local gradient descent, and upload only a checkpoint delta. The server then runs federated averaging — FedAvg, the workhorse aggregation scheme that the broader literature identifies as the standard approach for combining client updates — and increments the global model round. This is textbook cross-device horizontal federated learning, the same category as smartphones collaboratively improving voice recognition, as surveys of the field describe it. The privacy argument is the standard one: bandwidth savings, no raw data ingress, and regulatory breathing room, which the FL literature consistently frames as the technique’s core value proposition against centralized training.

The second mode is stranger and more interesting: decentralized pipeline parallelism for foundation model inference. The problem is concrete. A 16GB FP16 checkpoint — the README names Llama 3 8B and TinyLlama as targets — cannot fit in phone memory, and Android’s Low Memory Killer will summarily execute any process that tries. Fractal’s answer is to slice the model into layer partitions, each capped at 150MB, quantize the weights to INT4 via torchao, trace the graph through torch.export into the ATen dialect, and lower it to XNNPACK for mobile hardware. Each Android node then memory-maps its assigned partition — layers 0–7 on one phone, 8–15 on the next — and the phones pass activations to each other over an ad-hoc local Wi-Fi mesh.

This is pipeline parallelism in the classic sense — the same layer-splitting strategy used inside GPU clusters — but transposed onto consumer hardware where the interconnect is a Wi-Fi socket and the memory budget is whatever Android hasn’t already claimed. The engineering constraint that falls out of it is the most telling detail in the entire README: the activation contract. Each inter-node transmission is a 4096-dimension INT8 tensor plus a single float scale, hard-capped at 4,100 bytes. Exceed it and the frame is dropped and re-requested. When your network is a phone hotspot, your protocol design is dictated by frame size, and the whole system is architected around that arithmetic.

The Contracts Are the Architecture

The most distinctive thing about Fractal’s design documentation is not any single component — it’s the framing. The README presents a table of “global system contracts” with strict specifications and defined failure behaviors: the weight contract (partitions ≤ 150MB or the slicer rejects compilation), the activation contract (≤ 4,100 bytes or the frame drops), the telemetry permit (battery ≥ 50%, device charging, battery temperature ≤ 40°C, or training pauses immediately), the authentication contract (an X-Auth-Token header on all tenant and admin routes, or a 401/403), and the upload validation (checkpoint uploads must reference a live, unconsumed task_Id, or a 400).

This is a control-plane mindset applied to edge chaos. The telemetry permit in particular is the part most distributed-computing papers wave at with the word “heterogeneity.” Fractal treats the human holding the phone as a first-class constraint: the device must be plugged in, above half battery, and not overheating before it will do your gradient descent. The federated learning literature acknowledges client dropout and resource variability as core challenges — one survey notes FL’s saving grace is that training continues even when clients drop offline — but few implementations encode the device’s physical welfare as a hard execution gate. Whether the enforcement is airtight in practice is unverifiable from the README alone, but as a design philosophy, “the phone’s owner outranks the tenant” is the right call for anything that wants people to actually install it.

The reward mechanism is also worth pausing on. Nodes that complete training work are credited “Liquid MBs” — a tokenized reward tracked in a Firestore ledger, keyed to device ID. The README calls it tokenized reward distribution; the scripts directory reportedly contains reward audit tooling. There is no evidence in the available material of a liquid market, an exchange, or any economic machinery beyond ledger credits, so “tokenized” here should be read generously — it is an accounting system, not a currency. Still, the shape of the idea — paying device owners for compute in a unit the orchestrator mints — is the same premise that has animated a long line of distributed-computing ventures, most of which discovered that the economics of consumer hardware are brutal.

Where It Sits in the Field

Contextually, Fractal is operating in a crowded research neighborhood. Federated learning at the edge has been systematically surveyed for years — a 2022 survey in Sensors covers implementation, protocols, architecture, and hardware requirements, and cites Cisco’s projection of over 75 billion connected IoT devices by 2025. The smart-cities literature treats FL-plus-IoT as a maturing pairing, with applications, challenges, and solutions already catalogued. Industry writing distinguishes horizontal FL (shared feature space, different samples — Fractal’s mode) from vertical FL (different features, same entities), and notes that FedAvg, personalization, and adversarial robustness are the field’s active frontiers. None of this is unexplored territory.

What Fractal appears to bring that the survey literature does not is a working, end-to-end implementation that unifies two things usually kept separate: federated training on one hand, and partitioned inference of large models on the other, both under a single multi-tenant control plane with budgets, ledgers, and hardware gates. The surveys describe architectures; Fractal ships a Flask server, a Docker Compose stack, a Kotlin MVVM app, and a compiler pipeline that turns a monolithic checkpoint into 32 mapped partitions. That unification — training and inference, control plane and data plane, in one codebase — is the project’s genuine claim to distinctiveness, however early.

The Honest Caveats

Several things should temper enthusiasm. First, everything described here comes from the project’s own README; no independent benchmarks, third-party evaluations, or published results are available in the provided material. The claim that a Llama 3 8B model runs across four Android phones over Wi-Fi is an architectural claim, not a verified one — throughput, latency, and whether INT8 activations survive a 4,100-byte cap without quality collapse are all open questions the sources cannot answer. Second, the pipeline-parallelism mode has an inherent bottleneck that no README spin can remove: pipeline parallelism is latency-bound by its slowest stage, and a Wi-Fi mesh between phones is not a NVLink. Third, this is a single-maintainer project under active development with a proprietary license — the two facts together mean adoption, contribution, and longevity all carry real risk. Fourth, the “multi-tenant” framing invites a question the material doesn’t address: who, exactly, are the tenants of a phone-fleet compute market, and what workloads justify orchestrating consumer devices instead of renting a GPU for an hour?

And there is the matter of discoverability. The project shares its name with a Kingston coworking business whose web presence — website, Instagram, Facebook, LinkedIn, a Google Play app — thoroughly owns the search results. The GitHub project is effectively invisible to anyone who isn’t already looking for it, which may explain why there is no visible hype to analyze. This article, in a sense, is the first press it’s getting, sandwiched between SnapCab privacy pods and complimentary coffee.

Outlook

The open questions are the interesting ones. Can INT4-quantized, XNNPACK-lowered layer partitions actually deliver useful inference throughput across a phone mesh, or does the activation contract strangle the model? Does the telemetry permit hold up against real thermal behavior on real devices? Will “Liquid MBs” ever mean anything outside the Firestore ledger? And will a non-commercial license attract the kind of contributor base that a distributed system this ambitious needs?

What Fractal gets right, on paper, is the discipline. The contracts, the failure behaviors, the hard caps, the human-centric execution gates — this is systems thinking applied to a problem most people solve by renting cloud GPUs and forgetting about it. If the execution matches the specification, it will be worth watching. If it doesn’t, it will at least remain a well-documented artifact of the idea that the largest untapped compute resource on Earth is sitting in people’s pockets, charging overnight.