mfabric.

Peers

Download the signed Windows installer or the manual zip on each helper device, verify the SHA-256 hash, run the installer or peer launcher, choose Helper / peer, paste the join link, and approve the peer on the host.

Windows PowerShell

Get-FileHash -Algorithm SHA256 .\mfabric_peer_setup_0.1.0.exe
Get-FileHash -Algorithm SHA256 .\mfabric_public_beta_peer_current.zip

Good manual-zip extract locations

~/mfabric_public_beta
~/Downloads/mfabric_public_beta
%USERPROFILE%\Downloads\mfabric_public_beta

Avoid

If you use the manual zip, do not run from inside a compressed-zip viewer. Do not extract into system folders such as /usr, /System, C:\Windows, or C:\Program Files.

macOS / Linux

python3 -m pip install -r requirements-agent.txt
python3 mfabric_peer_bootstrap.py --join-url PASTE_HOST_JOIN_LINK --detach

Cellular

Put the host gateway behind a private mesh tunnel or authenticated HTTPS endpoint. Start the gateway with exact-origin CORS and bearer-token auth, then enter that URL in the phone client.

Verified adapter row

The host package may show a model-specific verified row when that adapter has passed its own validation. Treat each model family separately.

Advanced host controls

If a private host build exposes an experimental path, it should document that path separately from this public manual.

Revoke

Use the host control panel when a device should no longer be trusted. Open the credentials table, find the peer, and choose Revoke.

Memory-sharing availability

Memory-sharing keeps your older context alive instead of silently dropping it. When local memory fills up, stale context you are not actively using moves into pooled memory on approved helpers, so your context is maintained without losing the old one. Because the pool holds stale context, this is a continuity feature, not a speed feature. It is an opt-in preview in this build.

1. Open the host console and go to the Experiments section.
2. Click Check availability next to the memory-sharing option.
3. The console returns a status message. If it says “not available in this build”, the serving path for this experiment is not active yet.
4. The capacity planner in the same section shows how much peer memory your current helper pool has.
5. This capability is being hardened; check the release notes for when it becomes a default option.

2Big2Fit (split model) availability

2Big2Fit lets you run a model too big for one machine by splitting it across your devices: the host distributes the model across multiple trusted machines for capacity experiments when no single machine has enough memory.

1. Open the host console and go to the Experiments section.
2. Click Check availability next to the 2Big2Fit (split model) option.
3. The console returns a status message. If it says “not available in this build”, the serving path is still a preview and not active by default.
4. The capacity planner can tell you whether your current pool is large enough for the model you want to run.
5. This capability requires approved helpers with compatible hardware and is being hardened; treat it as an experiment, not a production path.

Peer does not show up

• Confirm the peer window is still open.
• Confirm the join request was approved on the host.
• Check local firewall prompts for Python.
• Re-copy the join link and run the peer launcher again.

Peer shows up but does not work

• Some peers are storage-only.
• A peer may be low battery, active, offline, or not eligible for compute.
• The workload may require a specific host-side adapter.
• If fallback events appear, the host is recovering from a peer miss or unavailable worker/path.
• Keep the workload on the standard safe default unless the host operator explicitly enables an experimental path.

Transfer rate is zero

That is normal when no workload is moving data. Run a workload or block-transfer test to see activity.

Pooled memory looks small

MFabric displays the storage budget allocated to the fabric, not every byte of physical RAM on every peer. The context estimate is a planning tier, not a promise that every model can use that much context.

Using the native runtime route for dense models

The native runtime route is a faster local execution path for dense Qwen2 and Qwen3 models with a hidden size up to 2048 (roughly 3B parameters and below). Models above that size use the standard path automatically.

This route ships with the GitHub / pip source distribution only: if you installed from the helper zip bundle or the Windows installer, the native runtime files are not included and every model uses the standard path (you will see runtime_route: hf_generate).

1. Scan your local models using the Load a local model panel.
2. Select a dense Qwen2 or Qwen3 model and press Load.
3. Send a chat prompt. When the model answers, the response details line shows a runtime_route field such as qwen2 or qwen3 for the native path, or hf_generate for the standard path.
4. You do not need to configure anything. The console picks the native path automatically when the model qualifies, unless you set MFABRIC_PUBLIC_DISABLE_NATIVE_RUNTIME=1 to force the standard path.
5. Larger models (hidden size above 2048, such as 7B+ dense Qwen) use the standard path automatically; the response details will show hf_generate for those.

Checking memory-sharing availability

Memory-sharing keeps your older context alive instead of silently dropping it: stale context moves into pooled memory on approved helpers, so your context is maintained without losing the old one. Continuity, not speed. It is an opt-in preview in this build. Full steps are in the Experiments section above.

1. Open the host console and go to the Experiments section.
2. Click Check availability next to the memory-sharing option.
3. The console will return a status message. If it says “not available in this build”, the serving path for this experiment is not active yet.
4. The capacity planner in the same section shows how much peer memory your current helper pool has.
5. This capability is being hardened; check the release notes for when it becomes a default option.

Checking 2Big2Fit (split model) availability

2Big2Fit (split model) experiments run a model too big for one machine by splitting it across trusted devices when no single machine has enough memory. Full steps are in the Experiments section above.

1. Open the host console and go to the Experiments section.
2. Click Check availability next to the 2Big2Fit (split model) option.
3. The console returns a status message. If it says “not available in this build”, the serving path is still a preview and not active by default.
4. The capacity planner can tell you whether your current pool is large enough for the model you want to run.
5. This capability requires approved helpers with compatible hardware; treat it as an experiment, not a production path.

Understanding the streaming indicator and TTFT

The chat panel can stream tokens as they arrive rather than waiting for the whole answer. This makes responses feel faster even when total generation time is the same.

1. Send a prompt in the chat panel.
2. Look for the indicator next to the response header: streaming means tokens are arriving in real time; buffered fallback means the full answer arrived at once (normal for some model and peer configurations).
3. The TTFT readout (time to first token, in milliseconds) shows how long the console waited before the first token appeared. A lower number means faster response start.
4. Buffered fallback is not an error. It can happen when the peer or model does not support token-level streaming, or when the connection is very fast and the full answer arrives before the first render cycle.
5. Both modes produce the same answer. The streaming mode only changes when characters appear on screen.

Checking live device telemetry

The telemetry panel shows real-time GPU memory, CPU load, and health for every approved device in your fabric.

1. Open the host console in your browser.
2. Scroll to the Telemetry section (or click its link in the capabilities panel).
3. Each device card shows GPU memory used, CPU percent, and whether the device is currently online.
4. The small sparkline graph shows recent GPU memory use over time.
5. If no telemetry appears, the device may be offline or not yet approved.

Running a batch of prompts

The batch panel runs several prompts at once and returns one result list.

1. Open the host console and go to the Agent swarm or batch panel.
2. Type or paste your tasks, one per line, into the task input box.
3. Press Run. Each task is sent in parallel and tracked as a separate row.
4. When all tasks finish, each row shows the answer, the tier it used, and how long it took.
5. Press Clear to reset the list before the next batch.

Checking for a newer version

MFabric does not check for updates automatically. Use this step to check manually whenever you want.

1. Open the host console.
2. Click Check for updates in the header bar, or open the Check for a newer version capability panel and press Check for update.
3. The console fetches the public update manifest. No device info, model list, or local paths are sent.
4. If a newer build is available, the status line shows the version number and where to download it.
5. If you are already on the latest build, the status line confirms that.

Five steps to your first chat

1. Check the environment: mfab doctor
2. Start the host: mfab host start --detach
3. List local models: mfab models list
4. Load a model: mfab models load <model-ref>
5. Send a prompt: mfab chat "What does MFabric do?"

Stream tokens

mfab chat --stream "Summarize what a private fabric does"

Tokens appear as they arrive instead of waiting for the full answer.

Check for updates

mfab update

Fetches the public release manifest. No device info, model list, or local paths are sent.