# Fractal: federated training and model slicing across Android devices

> Fractal pairs a Python control plane, FractalCore, with a Kotlin edge node, FractalAndroid, so phones can train on local data and run pieces of a large model. The two are joined by a proprietary non-commercial licence, a Firestore rewards ledger and no tagged releases at all.

**Fractal-Compute-Orchestrations/FractalWorkspace** — A unified ecosystem and workspace for large-scale federated learning, bridging the gap between centralized model evolution and decentralized edge intelligence.

- Repository: https://github.com/Fractal-Compute-Orchestrations/FractalWorkspace
- Website: https://play.google.com/store/apps/details?id=org.fractal.app&hl=en
- Stars: 4,110 · Forks: 4
- Language: Python
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/fractal-compute-orchestrations-fractalworkspace

## A Python control plane paired with a Kotlin edge node

Fractal is presented as a distributed systems framework that bridges centralized model orchestration with decentralized edge intelligence. The README splits it into two systems. FractalCore is the Python-based control plane, responsible for multi-tenant isolation, dataset segment allocation, model graph compilation and slicing, deterministic federated weight aggregation with FedAvg, compute budgeting and tokenized reward distribution. FractalAndroid is the native Kotlin and Android execution engine that runs on mobile hardware, performing hardware-gated on-device training and memory-mapped inference, and pausing workloads when thermals or battery thresholds are exceeded.

The topology is a hierarchical master-worker architecture designed to isolate control signals from mathematical payloads, and the README draws the split in two planes. The control plane holds a REST gateway and auth controller, a tenant isolation manager, a task scheduler and segment dispatcher, the federated weight aggregator, a graph slicer with an INT4 quantizer and a TFLOPs budget controller. The data plane holds the Android nodes, each assigned a band of layers, and the two planes talk over a REST API with TLS for task polling and weight uploads.

This is a deliberately narrow division. The phone holds the data and does the arithmetic; the server decides what arithmetic to do and records who did it. Whether the reward accounting makes that trade worthwhile for an operator is the open question the repository does not answer.

## Federated rounds gated by battery and thermal telemetry

In the federated learning lifecycle described in the README, raw training datasets are never transferred to the central server. The server partitions data indices into segment bins, dispatches task descriptors to registered Android nodes and waits for computed checkpoint deltas in .ckpt files. The sequence is explicit about the exchange:

```mermaid
    Server->>Server: Partition Dataset into Binary Segment Bins
    Node->>Server: GET /api/task/current (Hardware Telemetry Proof)
    Server-->>Node: ActiveTask (Model URL + Data Bin URL + Hyperparams)
    Node->>Node: Evaluate Telemetry Permit (Battery >= 50%, Thermals <= 40C)
    Node->>Server: POST /api/model/upload (Checkpoint Delta .ckpt)
```

Two mechanisms are worth isolating. The node must present hardware telemetry proof when it asks for work, and it evaluates a telemetry permit locally before starting, with battery at or above 50 percent and thermals at or below 40C. That gate is a device-health rule, not a security check, but it has the effect of shrinking the active fleet whenever phones are hot or charging.

The second is the payment loop. The server credits liquid MBs to the node device ID in a Firestore registry, then performs FedAvg summation and increments the global model round. A node therefore earns data allowance by completing rounds, which is the incentive that keeps phones participating.

## Slicing a 16GB checkpoint into mapped partitions

The second paradigm handles inference rather than training, and it is the more unusual one. To run foundation models such as Llama 3 8B or TinyLlama across edge devices without triggering the Android Low Memory Killer, FractalCore slices a monolithic model into memory-bounded partitions named layer_[N].pte, each at or below 150MB. Each Android node memory-maps an assigned partition and passes quantized activation tensors across an ad-hoc local mesh.

The compiler pipeline in the README is a PyTorch path: ingestion and block isolation, then INT4 weight quantization using torchao, then an ATen dialect graph trace with torch.export, then delegation to XNNPACK for hardware execution, producing 32 mapped partitions from a 16GB FP16 checkpoint. Activation traffic between neighbouring nodes travels as an INT8 activation stream over a Wi-Fi socket, which the architecture diagram shows as node to node links running A to B, B to C and C to D.

The design consequence is worth being blunt about. The chain of activations between nodes has to travel over a local network in real time, so throughput is bounded by the Wi-Fi mesh rather than by the phone's own memory bandwidth. The README claims the approach sidesteps the memory killer; it does not describe measured latency for the inter-node hops.

## The repository topology of a parent project

The top-level entries describe a parent repository rather than a single library. FractalCore holds the server side, FractalApp/ holds the Android application, docs/ carries the assets used in the README, models/ holds model files, scripts/ holds helper tooling, and .gitmodules points at vendored submodules. There is a ruff.toml, which tells you the Python side is linted with ruff, and an .editorconfig for shared formatting. The repository is marked as a parent repo in its topics, and the organisation Fractal-Compute-Orchestrations maintains it, with the README naming Ahmad Hassan (B-Ted) as maintainer.

Two absences are informative. There are no GitHub releases, so there is no version to pin, and the licence is a custom one that GitHub cannot classify, described in the repository as Proprietary Non-Commercial v3.0 in the badge, with the LICENSE file at the root as the authoritative text. For an organisation evaluating the framework, the licence file is the first document to read, since non-commercial terms can rule out exactly the deployments a federated learning system is most often proposed for.

## What the project pages point at and what the overview omits

The README navigation links to an Overview, a design case study hosted on Behance, an Architecture section, the Core Paradigms, the Repository Topology, a Getting Started section, and a Security and Privacy section, and it carries a Platform badge for Android and Python. The project homepage given for the repository is a Google Play listing under the application identifier org.fractal.app, so the Android node is distributed as a real application rather than as a library you embed.

The overview itself does not give an install command. There is no pip line for FractalCore, no Gradle invocation for FractalApp and no listed environment variables in the overview, and the Getting Started and Security sections are linked but their content is not reproduced in the repository overview. What a reader can extract is the shape of the data flow: two REST endpoints appear throughout the described flows, namely:

```text
GET /api/task/current
POST /api/model/upload
```

Alongside them sit the Firestore ledger for tokens, rewards and nodes, and physical data silos holding bins, checkpoints and PTE slices. The pragmatic takeaway is that deployment here means standing up Firestore, a Python server and a set of enrolled phones, and that the fine print lives in the documentation rather than in the README.

## Where the design leaves an operator exposed

Three frictions stand out for anyone running this rather than reading about it.

The first is participation. A node that is below 50 percent battery or above 40C does not take work, and the telemetry permit is evaluated on the device, so a fleet's effective size changes with weather, charging habits and ambient heat. The reward system credits liquid MBs against completed rounds, so an unavailable phone is also an unpaid phone.

The second is the absence of releases. With no GitHub releases and the last push dated 2026-08-22, there is no version contract between the server and the app, and a node app installed from the Play listing may not match the code on the server side. Anyone integrating this needs to pin by commit.

The third is the licence, already mentioned, and it interacts with the first two: a non-commercial licence and a fast-moving server are a poor fit for a product launch, while a research pilot in a lab with its own hardware is exactly the case the design serves.

## Conclusion

Fractal fits research teams that need to train on data that must stay on phones, or that want to serve a large checkpoint across devices without hitting the Android low memory killer, and that can accept a control plane they host themselves. It is a poor fit for commercial redistribution, because the repository carries a proprietary non-commercial licence, and a poor fit for anyone who needs pinned releases, because the project has no GitHub releases and its last push was on 2026-08-22. Verify first that your Firestore project and Wi-Fi mesh assumptions match the documented endpoints GET /api/task/current and POST /api/model/upload, then check the licence file before any deployment.

## FAQ

### What is Fractal and what does FractalCore do?

Fractal is a distributed computing framework for federated learning and edge inference. FractalCore is its Python control plane, handling multi-tenant isolation, dataset segment allocation, graph slicing with INT4 quantization, FedAvg aggregation, compute budgeting and reward distribution.

### What conditions must an Android node meet before it takes a task?

The node must present hardware telemetry proof when polling for work and pass a local telemetry permit, which the README gives as battery at or above 50 percent and thermals at or below 40C. Workloads pause when thermal or battery thresholds are exceeded.

### How does Fractal run a large model on several phones?

FractalCore slices the checkpoint into memory-bounded partitions named layer_[N].pte of at most 150MB, quantizes weights to INT4 with torchao and traces the graph with torch.export. Each node memory-maps its partition and passes INT8 activation tensors to the next node over a Wi-Fi socket.

### Can Fractal be used commercially?

The repository badge names the licence as Proprietary Non-Commercial v3.0, a custom licence GitHub cannot classify, and the LICENSE file at the repository root holds the terms. Read that file before any deployment, since non-commercial terms can exclude commercial use.

## Sources

- [Fractal-Compute-Orchestrations/FractalWorkspace on GitHub](https://github.com/Fractal-Compute-Orchestrations/FractalWorkspace)
- [Issues](https://github.com/Fractal-Compute-Orchestrations/FractalWorkspace/issues)
- [Project website](https://play.google.com/store/apps/details?id=org.fractal.app&hl=en)
- [README](https://github.com/Fractal-Compute-Orchestrations/FractalWorkspace/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fractal-compute-orchestrations-fractalworkspace