This checklist is for researchers getting started with OsxNode M4-16. First, connect to your dedicated Mac, check Python and MLX, then run a short generation to see how much memory is available. This model has an M4 chip, 16GB of unified memory and a 256GB SSD.
Have your order number ready before connecting, and export your results before expiry. A successful connection does not mean every model will fit in 16GB of unified memory.
Access is provisioned on the day your payment is confirmed. Your instance is ready when the node and connection details appear in the console. If payment is complete but you can’t see your credentials, check the relevant order before placing another one.
Sign in to the console with the email address used for your order. Open the instance or subscription details and check the order number, node name and expiry time. The node name should match your selection; use the connection address, username and port shown in the instance details.
Select “Open remote desktop” on the relevant node card or details page, then use the credentials provided in the console to access macOS. Make sure your browser allows the connection page to run. The public help pages are not a remote desktop entry point.
After signing in for the first time, change the account’s initial password under Users & Groups in System Settings, then save it in your password manager. Verify that the new password works before ending your current session. Never send your initial or new password in a support ticket.
Each physical Mac is assigned to one renter for the duration of the rental; it is not a virtual machine. Closing your browser ends the current viewing session, not your rental. To keep a task running, use a separate session as described below.
Run the commands below in Terminal on your remote Mac, not on your own computer. A dedicated virtual environment keeps this experiment’s Python packages separate from other tasks. Don’t install packages globally into the system Python.
uname -m
command -v brew
brew --versionThe expected architecture is arm64. The last two commands should return the Homebrew path and version. If brew isn’t installed, follow the official Homebrew installation instructions. Don’t paste installation scripts from unverified sources into Terminal.
brew install python@3.11
mkdir -p "$HOME/experiments/mlx-first"
cd "$HOME/experiments/mlx-first"
python3.11 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install mlx mlx-lm
python -c 'import platform; import mlx.core as mx; from importlib.metadata import version; print(platform.machine()); print("mlx", version("mlx")); print("mlx-lm", version("mlx-lm")); print(mx.array([1, 2, 3]) + 1)'After installation, the check should print arm64, the installed versions of both packages, and an array with the value [2, 3, 4]. Package versions vary over time, so don’t use a specific version string as the only sign of success.
python --version
python -m pip freeze > requirements.txt
python -m pip checkIf there are no dependency conflicts, the last command will usually return No broken requirements found. When you reopen Terminal, go to your experiment directory and run source .venv/bin/activate before running inference. Don’t migrate only the virtual environment directory; keep the dependency list and your scripts too.
The 16GB of unified memory is shared by the CPU, GPU and system; it is not all available to the model. Context cache, runtime processes and other apps need memory too. Even models with the same parameter count can have different peak memory usage depending on quantisation format and context length.
Check the model file size, licence and available disk space first. If you’ll reuse weights and datasets, consider storing them on an additional drive you’ve purchased. Confirm the drive’s mount path in Finder or Disk Utility.
More SSD capacity does not increase the 16GB of unified memory. Without an additional drive, use a directory on the main drive and keep the cache size under control. Don’t copy a volume name that doesn’t exist.
Open Activity Monitor → Memory and check both memory pressure and swap usage. Close GUI apps you don’t need, limit the output length and increase the context gradually. Record the model name, quantisation and command-line arguments.
If memory pressure turns yellow, stop increasing concurrency, shorten the context or switch to a smaller quantised model. If the system keeps swapping or the process is terminated, don’t rerun the same task with the same settings.
cd "$HOME/experiments/mlx-first"
source .venv/bin/activate
export HF_HOME="$HOME/model-cache"
mkdir -p "$HF_HOME"
df -h "$HF_HOME"
python -m mlx_lm.generate \
--model mlx-community/Qwen2.5-3B-Instruct-4bit \
--prompt "Explain unified memory in three sentences." \
--max-tokens 128The first run downloads the specified model. On success, it prints generated text; some versions also show generation statistics. This example makes no promises about download time or tokens per second. If you’re using an additional drive, set HF_HOME to a confirmed, writable directory on that drive and keep using the same path in later sessions.
Start by testing a 3B 4-bit model or a 7B 4-bit model with a short context. The 16GB tier offered here is not recommended for 13B or larger 8-bit models. LoRA fine-tuning also needs memory for training states and activations, so successful inference does not mean training will fit.
Use SSH to run commands, scp for a one-off copy, and rsync for repeat syncs or resuming interrupted transfers. Check in the console whether SSH is enabled and review its connection details first. Having browser desktop access does not mean SSH is already configured.
read -r -p "SSH user: " REMOTE_USER
read -r -p "SSH host: " REMOTE_HOST
read -r -p "SSH port: " SSH_PORT
ssh -p "$SSH_PORT" "$REMOTE_USER@$REMOTE_HOST" \
'mkdir -p ~/experiments/data ~/experiments/results'
scp -P "$SSH_PORT" ./dataset.jsonl \
"$REMOTE_USER@$REMOTE_HOST:~/experiments/data/"
rsync -avP -e "ssh -p $SSH_PORT" ./data/ \
"$REMOTE_USER@$REMOTE_HOST:~/experiments/data/"
rsync -avP -e "ssh -p $SSH_PORT" \
"$REMOTE_USER@$REMOTE_HOST:~/experiments/results/" ./results/These commands use Bash syntax and should be run in a local Bash shell. Enter the actual host, username and port shown in your instance details. Check the host fingerprint the first time you connect; don’t bypass a warning by disabling fingerprint checks. The rsync examples do not use a deletion option. The trailing slash on the source directory means “sync the directory contents”.
If your connection is unreliable, split a large archive into 1024MB volumes and upload them one at a time. Splitting only changes how the file is transferred; it does not compress the original or reduce the disk space needed at the destination.
shasum -a 256 dataset.tar
split -b 1024m dataset.tar dataset.part-
cat dataset.part-* > dataset-restored.tar
shasum -a 256 dataset-restored.tarSplit the archive on the source machine and reassemble it on the destination. Compare the SHA-256 values before extracting. If the archive and all its parts are stored together, allow space for both copies.
Install tmux on the remote Mac and create a session to run your inference command. Press Ctrl+B, then D to detach; you can reconnect to the session later.
brew install tmux
tmux new -s mlx
tmux attach -t mlxStart the task in a new session, then run attach after reconnecting. tmux can help with SSH disconnections, but it cannot keep a task running through instance shutdown, restart or the end of your rental.
Mac rentals are prepaid by the day, week, month or quarter. If you don’t renew, the instance shuts down automatically at expiry, with no further charges. Use the expiry time shown in the console to plan tasks and backups; don’t rely on whether the browser still displays the desktop.
Before expiry, open the relevant subscription in the console, review the available renewal options and complete payment. Then confirm the updated expiry time. The only accepted payment methods are USDT-TRC20 and Visa / Mastercard / Amex via Stripe. Payments are settled in US dollars; available payment gateways are confirmed in the console.
Before expiry, export your datasets, experiment scripts, dependency lists, logs and result files, then confirm you can open them locally. Verify checksums for important archives. Closing the remote desktop does not mean your results have synced; a file you can’t see locally is not backed up.
Service stops at expiry. After a node is reclaimed, its disks are erased and the system is reinstalled before the node is assigned to another renter. We do not guarantee that data will remain accessible for any period after shutdown, or that erased data can be recovered. If your order includes specific data handling arrangements, refer to the terms confirmed for that order and support ticket.
We do not guarantee a standard period of data retention after shutdown. If you’re unsure whether your backup is complete, confirm it through a support ticket while your rental is active. Don’t rely on renting again after expiry to recover data from the original disk.
Capacity, connection methods and billing periods are separate things. Understanding the difference can help you tell whether an issue is caused by model size, network access or your rental status.
Save the error message and the time it occurred before making changes. Don’t keep restarting in the hope that it will work; a restart may interrupt unsaved experiments and remove useful diagnostic information.
The browser connection may not have completed, the desktop session may be in an unexpected state, or the node may be unreachable. A black screen alone does not mean the machine is shut down.
Different input methods, macOS input sources and client keyboard mappings can cause symbols to appear in the wrong place. You usually don’t need a new instance.
Insufficient memory is one possible cause, but check disk space, model file integrity and dependency errors too. A single exit message is not a substitute for the full log.
df -h to check the disk containing the cache and confirm the download wasn’t interrupted by a lack of space.python -m pip check. If a smaller model fails too, include the error and environment versions in your support ticket.For issues with an active instance, submit a support ticket from the console after signing in so it can be linked to your order. For pre-sales questions or sign-in issues, see the email options on our Contact Us page. Our public support email is support@osxnode.com.
Include your order number, node name and current instance status. For renewal or payment issues, add the payment method and status. Don’t provide a full card number, sign-in password or SSH private key.
Give the time the issue started, whether it’s ongoing and your time zone. Avoid vague descriptions like “just now”. For availability requests, include the affected time period and node name.
Describe the prerequisites, steps to reproduce, expected result and actual result. For MLX issues, include the model identifier, quantisation, command and dependency versions. Remove sensitive information from paths.
List the results of checks such as reconnecting in the browser, SSH connectivity, memory pressure and disk space. Say whether any tasks are running or still need to be backed up to help avoid unnecessary interruptions.
Link the instance, time and error details in your support ticket. If you’re not sure whether a model will fit in 16GB, tell us its size and quantisation before asking for advice.