Depth Anything 3 small on a CPU: what runs, and how fast

Depth Anything 3 small is the CPU tier of its family, and the CPU story is now measured. The vendor's packaged phone runtime does one image in 157.8 milliseconds on a single Arm CPU core. A community int8 ONNX build does a run in 0.18 seconds on a Mac CPU. Plain PyTorch on an M1 laptop takes 0.3511 seconds per image. Nobody has published a desktop x86 figure in plain PyTorch. This page shows the searches that came back empty. The install, the code, the memory budget, the fast runtimes, and the hosted lane are below.

The small tier, in plain numbers

The official repository ships the family in four sizes. Your size pick decides your license as much as your speed. The repository's own model table, read 28 October 2026, splits it this way:

The small tier is one of the two Apache 2.0 rows in the main series. If your product ships depth and you cannot carry a non-commercial clause, that fact narrows the choice first. Speed questions come after. A separate metric model, DA3 metric large, also sits under Apache 2.0. That one exists for real-world scale. It is a different model, not a mode of this one.

The size question has three honest answers. Each is named here so you can check any figure you are quoted. The model card says 0.08B parameters. The Hub's own record for the same repository counts 34,299,463 parameters in the safetensors file. On disk, the file is 137,248,940 bytes, about 137 MB. The paper, Table 8, splits its parts into a 0.022B backbone, a 0.003B depth head, and a 0.001B camera head. A seller quoting one number without saying which form it means has not finished quoting.

The tier gives you relative depth, a confidence map per pixel, and camera poses across views. Send one view and you still get depth and confidence. What it does not give you is metric depth. The values order the scene from near to far. They do not measure meters. Every plan downstream inherits that law, on a CPU or anywhere else.

The publisher's own code picks the CPU

The model runs in plain PyTorch. Its publisher's own quick start handles the CPU case in its second line. The repository install is two commands:

pip install xformers torch>=2 torchvision
pip install -e .

Then the quick start from the model card, which is the whole API surface in one block:

import torch
from depth_anything_3.api import DepthAnything3

# picks the CPU when no CUDA device is present
device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
model = DepthAnything3.from_pretrained("depth-anything/da3-small")
model = model.to(device=device)

images = ["image1.jpg", "image2.jpg"]
prediction = model.inference(
    images,
    export_dir="output",
    export_format="glb",
)

print(prediction.depth.shape)       # [N, H, W] depth maps
print(prediction.conf.shape)        # [N, H, W] confidence
print(prediction.extrinsics.shape)  # [N, 3, 4] camera poses
print(prediction.intrinsics.shape)  # [N, 3, 3] camera intrinsics

On a machine with no CUDA device, the device line resolves to CPU and the run proceeds. Nothing in the API changes. The call resizes your images before the model sees them. On a CPU that matters more than anywhere else. The API reference sets process_res to 504 with the upper-bound resize method by default. A 1200 by 1600 frame becomes 378 by 504, about 190 thousand pixels. That fixed, small pixel count is the reason CPU runtimes can compete on this model at all. Your camera may shoot 12 megapixels. The model diets first.

The same work from a shell, using the repository CLI:

da3 auto path/to/images \
    --export-format glb \
    --export-dir output \
    --model-dir depth-anything/da3-small

The measured CPU band, source by source

Every number in this table belongs to a named source with a date. Runtimes and resolutions differ across rows, so read the runtime column before you compare any two of them.

Three readings of this band are worth taking with you.

First, the packaged phone core beats the laptop. Compare the 157.8 ms phone figure with the 0.3511 s laptop figure. That is not a hardware class gap. The phone number comes from a package built for CPU work. The laptop number is the same model in the stock Python stack. Runtime choice, not hardware class, sets most of your latency.

Second, the spread on the same phone is 2.36 times between the FP32 and FP16 builds of one package. The card reports the same quality metrics on both. The packaged run holds its tail: 168.2 ms at the 90th step, 172.6 ms at the 99th. Throughput is 6.34 images per second.

Third, the GPU anchor exists so you know what you are trading. The paper reports 160.5 images per second on an A100, on scenes of 32 images at 504 by 336. That is about 6.2 ms per image, roughly 25 times faster than the phone core. None of the CPU rows above is in that league. No honest CPU pitch will claim otherwise.

The empty row is the one many searches ask about. There is no published desktop x86 figure for the small tier in plain PyTorch. Four searches were run for it on 28 October 2026: quoted phrase "depth anything 3 small" with cpu inference speed; depth anything v3 small on cpu how long per image; depth anything 3 small cpu benchmark seconds per image; and DA3-SMALL cpu only torch inference time. All four came back without a number. Every measured figure that does exist is Arm or Apple silicon, named in the table above. If someone quotes you an x86 figure, ask for the runtime and the resolution first. Plan around nothing less.

Memory: what to reserve

The measured memory numbers, same sourcing rule:

Plan around one gigabyte of RAM per worker. That clears the worst measured row with headroom. PyTorch adds overhead beyond the packaged runtimes. A plain Python serving loop wants more than the phone package peak. The community benchmark is direct evidence of the ceiling. A MacBook Air with 8 GB ran the small tier at 0.3511 s and the large tier at 1.8033 s. It could not fit the giant tier at all, citing the memory limit. The Arm package caps its input at 4096 pixels per side and 1,440,000 pixels total. That bound caps the worst case before you send it.

The fast lane is the runtime, not the hardware

The 157.8 ms figure is not the model alone. It is the model wrapped in runtimes built for CPU work: a LiteRT core for depth, ExecuTorch stages for input and output resize, XNNPACK and KleidiAI on. The Arm card lists all four. If you want that class of number on your own Arm hardware, the package is public:

git clone https://github.com/ARM-software/ComputeFlow.git && cd ComputeFlow
uv sync && source .venv/bin/activate
compute-flow update
compute-flow model install monocular_depth_estimation:depth-anything-v3 da3-small-litert-fp16-compute
compute-flow build native

That runs on macOS with Apple Silicon or on Linux with an Arm CPU. The card names a Raspberry Pi 5 as an example. It trades scope for speed. The package is monocular relative depth only, with no multi-view geometry and no camera poses.

The int8 route shrinks the model as well as the runtime. Behind it, the community ONNX export quantizes only the MatMul weights, in dynamic mode. For the small tier, that file drops from 137 MB to 37 MB. Export it from the official repository yourself:

git clone https://github.com/ByteDance-Seed/Depth-Anything-3
PYTHONPATH=Depth-Anything-3/src python tools/export_da3.py --small out/

Expect friction on the export path. An open repository issue from November 2025 records the blocker. One resize call inside the model, cubic interpolation, is unsupported by both ONNX Runtime and CoreML. The community worked around it with constant folding and patched forks. The same thread carries a number for the separate metric large tier. A CoreML build ran 300 to 400 ms where ONNX Runtime took over 2000 ms. Same weights, five times slower, different runtime. Measure your runtime before you buy hardware.

When the CPU is the wrong answer

Real-time loops are where the CPU tier runs out. A desktop application that ships this model, Deep Desktop on Steam, recorded the state of play in November 2025 in its Steam discussion forum. Its developer noted that the model does not work with DirectML. Owners of AMD or Intel GPUs run it on the CPU, through the fallback in the CUDA build. A user in the same forum rated the model slower than the fast depth models for real-time use such as film watching. The same user called it faster than depth-pro and zoedepth at the same quality. For stills and batches that verdict is fine. For a camera-rate loop it is a warning.

The streaming story is still being built in the open. Repository issue 49, November 2025, tracks an incoming pull request for real-time streaming: a server design with a sliding window over video frames and buffer defaults of 12 frames on Apple MPS and 24 on CUDA. Until that lands and is measured, plan on the band above, not on hopes for streaming.

The decision rule falls out of all of it. Stills, batch work, and cheap edge nodes belong on the CPU tier. The license is Apache 2.0 and the electricity is yours. Anything that must answer a camera at frame rate belongs on a GPU you hold, or a lane someone else serves. That is the next section.

The zero-setup lane

The same tier runs as a hosted lane on this platform's vision route, under the da3-small model id. It has served since 6 October 2026, and it is on the public list as of 28 October 2026. The vision route page documents the whole contract. The run-vision reference carries the field-by-field shape. In short, your images go as file parts in one request. The answer carries the model's depth data plus a usage block. That block holds the billed image count and the call's cost.

A first call, whole thing:

curl -sS $IRONSTRATUM_BASE_URL/v1/vision \
  -H "Authorization: Bearer $IRONSTRATUM_API_KEY" \
  -F "model=da3-small" \
  -F "file=@frame.jpg" \
  -F "response_format=json"

Billing counts images, not requests. A request with three file parts bills three images. A request refused before it is served bills nothing. The rate for every listed row renders on the pricing page, drawn from the platform's model data:

The lane serves the same relative-depth output the local model gives you. The metric law from the top of this page travels with you. An account opened on the console covers it. The model page holds the tier's full sheet. The API pricing guide works the budget math for this lane, image by image.

What the small tier does not give you

Three limits, stated once, so they do not surprise you later.

It does not give metric depth. The main series returns relative depth. The packaged CPU runtimes print the same law in their specs: larger values are nearer, and the values are not meters. Work that needs true distances uses the metric tier, under its own license terms. Or convert on your side against a known reference in the scene.

The CPU packages drop outputs to buy speed. The Arm package is monocular only: no multi-view geometry, no camera poses. On the int8 side, the small export has no sky output at all (the card carries sky on the large export only). Plain PyTorch on the CPU keeps everything the model has, at the slower speed. You are choosing between scope and latency. Both choices are legitimate.

The figure you quote should carry its form. Card figure, Hub parameter count, or paper part split: 0.08B, 34.3M, or 0.026B. All three describe the same weights. The people who benchmark tiers against each other owe you the same named form in every row.

Frequently asked questions

Can Depth Anything 3 small run on a CPU only?

Yes. The publisher's own quick start picks the CPU when no CUDA device is present. Nothing in the API changes. The measured band on this page, 157.8 ms in a packaged phone runtime to 0.3511 s in plain PyTorch on a laptop, is what to expect. Plain PyTorch on a desktop x86 CPU has no published figure, and the searches for one are named above.

How fast is it on a CPU?

Between 157.8 and 372.8 milliseconds per image in the vendor's packaged phone runtime, FP16 compute versus FP32. That is one Arm CPU core at 504 by 378. Community numbers: 0.18 seconds for an int8 ONNX build on a Mac CPU. Plain PyTorch with the MPS backend on a MacBook Air M1 takes 0.3511 seconds. Every row names its source and date in the band table.

How much memory does it need?

The measured peak process memory is 772.1 MiB in the vendor's phone package. The FP32 build of the same package peaks at 811.5 MiB. On disk, the weights file is 137 MB and the int8 ONNX export is 37 MB. One gigabyte of budget per worker clears every measured figure. An 8 GB laptop ran this tier and the large tier, but not the giant tier.

Is it free to use?

The small tier carries the Apache 2.0 license, as does the base tier. The large and giant tiers of the main series carry CC BY-NC 4.0. That is not a commercial grant. The split is in the official repository's model table. Read the license text itself before shipping a product. This page is not legal advice.

Does it output metric depth?

No. The main series, this tier included, outputs relative depth. The map orders the scene from near to far and does not measure meters. A separate metric model in the family handles real-world scale, under Apache 2.0. This platform's lane serves the relative output.

Last verified: 2026-10-28