Model profiles describe what a machine can install and serve. For hosted inference, your gateway key reaches eligible machines on your own account. An installed model still needs a healthy runtime and route, and the request must pass account and key policy.

Engine follows hardware

Choose the runtime from the machine, the workload shape, and the serving model. llama.cpp and any OpenAI-compatible endpoint you run yourself land on the portable_local tier; vLLM lands on network_beta. Ollama profiles use local_convenience. These labels describe serving classes; they do not establish current availability for your key.

B3IQ runtime ready brand asset

Runtime ready Runtime probes must show the serving backend is reachable before route-ready status.

B3IQ GPU inventory brand asset

GPU inventory GPU count, memory, driver posture, runtime kind, and benchmarks shape model classes.

B3IQ CPU cores brand asset

CPU and edge capacity Match the model and runtime to the machine's memory and workload.

Research and machine state

The model guides help you compare model requirements. For installed profiles and serving state, sign in to your machines and open the machine's Models tab. A research listing does not establish that a model is installed or routable.

Dispatch checklist

Use the OpenAI SDK quickstart to list models with the same gateway key your application will use, then make a small request. Discovery reflects current eligibility; a route can become unavailable before the request arrives.

Owner inference gates
Fresh node heartbeat

The node must be online with recent signed control-plane state.

Managed route ready

The runtime and managed tunnel must be reachable, with the supported authentication mode and valid route configuration.

Onboarded and claimed

The machine was onboarded to the fleet by B3IQ and is linked to an owner account. There is no separate admin approval step beyond onboarding.

Model and request match

The profile status is installed, and its model, modality and capabilities match the request. A hardware qualification fault can still stop serving.

Account and key permit the request

The machine belongs to your account and is within the key's machine scope. Earn-mode machines are excluded. The key's model restrictions, incident controls, and any requested privacy requirements still apply.

Owner use and retained promotion fields

Owner-scoped inference does not require the marketplace promotion flags network_eligible, benchmark_verified, or paid_route_eligible, or an observed benchmark. The current owner path also skips the profile's economic route-tier and queue-health gates. An installed Ollama model can therefore serve its owner when the requirements above pass.

This does not bypass machine health, connectivity, installed-model matching, or the key's machine and model scope. Gateway route-tier filters affect model discovery; they are not an access boundary for owner chat requests. Use machine and model scopes to restrict a key, and verify a request as well as discovery. A runtime can still fail a live request. Use Route readiness to investigate the reported blockers; do not reinstall a working model solely to change a promotion flag.

The fields below remain in model profiles and diagnostics for other routing policies and operational history. They are not proof of paid capacity, earnings, or a public shared inference pool.

Key fields

FieldMeaning
statusLocal install and readiness state such as installed, ready_to_install, runtime_missing, or hardware_unsupported
runtime_kindRuntime family such as llama-cpp, ollama, localai, openai, xinference, or vllm
route_tierServing-policy class such as local_convenience, consumer_edge, portable_local, network_beta, datacenter_optimized, or fleet_orchestrated
network_eligibleRetained network promotion flag; not required for owner-scoped inference
benchmark_verifiedHost/profile benchmark claim; not required for owner-scoped inference
observed_benchmarkControl-plane-observed benchmark evidence; informative for owner use, required only by policies that enforce that gate
paid_route_eligibleRetained paid-route promotion flag; does not establish owner serving state or earnings
queue_healthReported runtime queue posture; inspect runtime health and request results even where the profile gate is skipped

Route tiers

Route tierServing class
local_convenienceOllama-class serving; can serve owner requests when live readiness and key policy permit
consumer_edgeConsumer and edge profiles; the tier alone does not establish availability
portable_localllama.cpp and self-hosted OpenAI-compatible endpoints
network_betavLLM and Xinference profiles
datacenter_optimizedDatacenter-class serving profiles
fleet_orchestratedOrchestrated fleet profiles
unknownUnrecognized tier metadata; inspect the profile and runtime before using it

Common blockers

Install the approved model profile and publish a fresh heartbeat after the runtime reports it is available.

Missing benchmark evidence alone does not block owner-scoped inference. Check discovery with your own gateway key and inspect the machine's current health. Benchmark and paid-route promotion state belong to separate policy checks; a static profile flag is not observed performance evidence.

Check whether the finding comes from model discovery, a promotion policy, or an incident control. Discovery applies gateway route-tier filters. Owner chat skips the economic promotion gate, including Ollama's local_convenience classification; key machine/model scope and incident controls still apply.

Clear queue state, runtime overload, or backend health issues, then publish a fresh heartbeat.

The key's model allowlist or denylist can reject a request. Discovery also applies gateway model and route-tier filters. Check the same key and model your application uses.

Public claims

Browser GPU preflight, static model fit, and installed model counts are not dispatch proof. Public UI should only claim route readiness when the live model profile and the router gates agree.

Ask a question... ⌘I