Define the job before comparing hosts
A host choice only has meaning against a defined job. “Run an LLM” leaves out whether a person waits on each response, a batch can run overnight, several callers arrive together, or a retrieval service shares the machine. Write down the acceptable behavior before shopping. Do not substitute an advertised core count or accelerator name for the workload description.
Workload fields
Complete one record per materially different workload. Identify the exact model artifact source and revision, file format, quantization or tensor metadata, shards, and any projector or adapter. Name the selected runtime, version, build/backend, operating system, and serving interface. These fields determine what compatibility question to ask; they do not establish how much memory a host will need. Keep file bytes, host RAM, device VRAM, runtime allocation, activations, KV cache, and temporary download/build space separate. Use the Article 4 memory worksheet for those quantities.
| Field to decide | Record explicitly | Why it affects this comparison |
|---|---|---|
| Task and artifact | Chat, generation, embedding, reranking, or bounded batch; repository, revision, file(s), format and sidecars | Different artifacts and runtime paths have different compatibility requirements. |
| Serving behavior | Context setting, expected request size, concurrency range, peak window and response/latency objective | A hardware label cannot show whether your chosen service goal is met. Values remain workload assumptions until observed. |
| Caller and availability | Who calls it, from where, when it must be available, and what happens during a delay or outage | Network placement, operating window and recovery can change the architecture choice. |
| Resident neighbors | Other selected processes, their peak periods, storage and resource needs | Capacity is shared; do not plan as if inference owns every host resource. |
| Owner and acceptance | Named operator, observation window, acceptable failure mode and decision date | Someone must verify fit and own the next action. No measured value exists until the operator records it. |
For an interactive service, write a response goal in the terms users care about and define the observation window and load to be used later. For a batch job, record the completion window and whether a retry is acceptable. Keep the acceptance value blank until the workload owner supplies it. This article offers no token-rate threshold, “real-time” definition, or presumed capacity.
Required controls
Record whether the service may be reachable only from the same host, from a private network, or from a specifically authorized public caller. Public reachability is a security design choice, not a performance requirement. Note the data residency or location constraint, backup/recovery objective, retention period, and deletion owner. Separately ask whether the runtime needs device access, elevated host privileges, a container device mapping, or a provider-controlled driver. Do not approve broader privileges merely to make a GPU visible.
Set an acceptance gate for each control: source document or provider response, access date, exact product/release, responsible person, and the condition that would pause the purchase. Terms apply at more than one layer: host use policy, service terms, model and dataset licenses, and rights to input or output material are separate questions. This checklist records them; it does not provide a legal interpretation. For a concrete candidate, carry forward the user’s intended use and verify the applicable policy text.
CPU candidate checklist
A CPU candidate is worth evaluating when the chosen runtime has a documented CPU path for the candidate’s actual architecture and the job can tolerate the result you later observe. That is a conditional procurement position, not a claim that CPU is adequate for a particular model. Basic CPU support means the software path exists under stated conditions; it does not imply a target response time, model fit, or equivalence to a GPU.
Architecture and OS
Ask the provider for the machine architecture actually presented to the guest, operating-system image, kernel constraints if relevant, and whether the offered compute is a virtualized allocation or a more dedicated arrangement. Record only disclosed facts. Where the selected software names instruction-set requirements, verify them against the guest CPU exposure and exact build. A generic “x86” label may not establish every required instruction or extension. ARM64 and other architectures require their own runtime and package support check.
Capture the exact OS release and relevant kernel/virtualization boundary from the candidate specification or an authorized, read-only inspection after provisioning. If the provider does not state a field, write not disclosed; do not infer an ISA from a plan name or physical host generation. Match the candidate against documentation for the selected runtime version, not a general statement about another release.
Runtime and model path
Check the runtime’s current installation and backend guidance for the selected platform, architecture, artifact format and build method. The captured vLLM CPU documentation describes basic CPU installation and serving/inferencing on specified platforms; it does not establish CPU/GPU speed equality or capacity for your model. Its supported platforms and build instructions can change, so verify the current page and release when choosing. For Ollama, hardware support documentation is relevant to GPU backends; it should not be read as a general CPU capacity guarantee. For llama.cpp, the captured build documentation is tied to commit 6c01da6278ab6c69ed67d9124806b50d2b299ba7, not proof that every released build has the same backend behavior.
Record runtime version, build provenance, backend enabled, artifact support statement, and any required compilation or runtime dependency. GGUF is a container format that can include mixed tensor encodings; a filename or size label alone does not prove runtime compatibility or the resources needed. If the supported model path is absent or ambiguous, ask the runtime maintainer or choose a documented path before comparing hardware.
Host limits and contention
Record the provider’s allocated vCPU count, host RAM, included disk, storage type if stated, limits and billing unit. Do not turn vCPU count into a throughput estimate. Add co-resident services and their peak resource windows to the plan, including OS, runtime, retrieval or monitoring services only when selected. The artifact’s disk size is not a RAM multiplier; the memory worksheet keeps system memory, process allocations, KV, and other caches apart.
Write down whether CPU and memory are reserved, shared, capped, or otherwise qualified, using the product’s actual wording. If allocation or contention behavior is unknown, keep it open. The practical next step is a separately planned, authorized observation with the exact artifact, runtime, workload and acceptance criteria—not an assumed result derived from the package description. Do not call this article’s examples tested capacity.
GPU candidate checklist
Only open a GPU candidate when a required runtime feature or a future workload observation justifies evaluating one. A marketing category, “AI-ready” label, generic GPU reference, or apparent memory number is not enough to identify what a customer receives. The device must be disclosed and usable by the selected operating system, driver, toolkit and runtime path. If these links cannot be confirmed, mark the candidate pending rather than filling gaps with a likely device or generic compatibility statement.
Device and passthrough
Request the exact accelerator model or an explicit product identifier, availability for the required region, quantity, architecture/generation, and usable VRAM per assigned device. Ask whether assignment is exclusive, partitioned, shared, or otherwise limited, and what guest-visible device access is provided. A provider’s statement about the host GPU does not by itself prove what the guest or container can see. Record whether device passthrough or a supported virtualization mechanism is used if disclosed.
Document who owns the driver lifecycle: customer or provider; whether the customer has permission to install or update it; and whether host maintenance can alter device visibility. A stated VRAM quantity is one field, not total model capacity. Runtime allocation, weights, activations, KV cache and other processes compete for resources according to their own configuration and workload. Do not infer a GPU field when the provider has not published it. Request written clarification or stop the comparison.
Software compatibility
Build a version tuple: guest OS and kernel; device architecture; driver; toolkit or backend library; runtime release and build; model format and quantization; and the intended tensor placement. Verify the tuple against the selected runtime’s support matrix and installation requirements. For example, the captured Ollama GPU page gives version-scoped NVIDIA compute-capability and driver requirements, with a different driver floor for some older capability levels, and describes distinct AMD ROCm and other paths. Those requirements do not prove that an unnamed hosted device is exposed or available.
The captured vLLM GPU installation and quantization pages tie supported devices, builds and quantized formats to their documented versions and combinations. A format appearing in a matrix is not a performance or quality guarantee, and it does not establish that a candidate host exposes the needed device. The llama.cpp build instructions likewise describe backend-specific build dependencies at the cited commit. Confirm the exact current documentation for the versions you will deploy. If the provider supplies a prebuilt image, ask who updates and supports its driver/toolkit stack and whether the image includes the runtime version you need.
Security and service boundaries
Make privilege and isolation part of the quote decision. Identify whether device access requires host-level capabilities, privileged containers, host filesystem access, provider intervention, or a particular service account. State the least access your chosen setup needs and who can grant and audit it. Do not copy a broad privilege workaround from a software guide without assessing the exact host and container boundary.
Map the serving endpoint separately: process bind, container publication, host firewall, provider firewall/network policy, authentication, and authorized caller. A listener on all container interfaces is not automatically internet permission, but a published port can create reachability that must be checked at each layer. Keep the endpoint private by design unless a reviewed public access pattern is an explicit requirement. Specify driver update responsibility, outage behavior during maintenance, backup/restore plan, and the owner for each control. If the support boundary leaves a security or recovery responsibility unowned, pause.
Compare candidates without a score
Use one row for each CPU or GPU product actually under consideration. Attach the source and date to every populated cell. “Not disclosed,” “not checked,” “not applicable,” and “not selected” mean different things. Preserve those distinctions; a blank must never turn into an implied feature or a zero-cost line.
| Requirement | CPU candidate evidence | GPU candidate evidence | Source and date | Missing field | Operational consequence | Next verification |
|---|---|---|---|---|---|---|
| Product and location | Exact product/plan and region: ______ | Exact product, accelerator, quantity and region: ______ | Provider page or written response: ______ | Availability / device identity: ______ | Cannot establish what is being bought. | Confirm current SKU and allocation in writing. |
| Guest architecture | CPU architecture, exposed instructions, OS: ______ | Host CPU architecture and guest device visibility: ______ | Specification or authorized inspection: ______ | ISA / passthrough details: ______ | Selected build may not be usable. | Match exact environment to runtime docs. |
| Memory and storage | Host RAM, disk and limits: ______ | Host RAM, usable VRAM per device, disk: ______ | Provider specification and Article 4 record: ______ | Allocation or limit: ______ | Capacity cannot be judged from a label. | Complete separate memory and disk ledger. |
| Runtime path | Runtime/version/build/backend/artifact: ______ | Runtime/version/build/device backend/artifact: ______ | Exact version documentation: ______ | Driver/toolkit/build compatibility: ______ | Compatibility remains unresolved. | Confirm supported version tuple before order. |
| Access and operations | Privileges, caller path, maintenance owner: ______ | Device privilege, isolation, update and caller path: ______ | Provider and runtime docs: ______ | Security/recovery owner: ______ | Unowned access or recovery risk. | Obtain a bounded written answer; pause if absent. |
| Terms and billables | Billing unit, disk, traffic and use terms: ______ | Accelerator unit, minimum, residuals, terms: ______ | Current product and policy text: ______ | Rate / terms / stop behavior: ______ | Cannot calculate or approve the candidate. | Send verified inputs to Article 2. |
Then take one of four branches. Proceed to price when required architecture, runtime support, controls, terms and acceptance criteria have evidence. Request provider clarification when a specific product field is missing but the candidate may still qualify. Use another supported architecture when the selected runtime path does not match the available candidate and another documented path serves the same job. Pause when a core compatibility, security, policy or recovery condition remains unknown.
Do not compare vendors with a numeric score that hides missing evidence. Do not predict tokens per second or claim one architecture always wins. If later testing is authorized, keep the test plan outside this procurement table and record its environment, artifact, runtime, workload, concurrency, observation window and result. A result from one configuration does not automatically transfer to a different host or release.
Convert choice into cost and memory handoffs
Before requesting a quote or approving a purchase, preserve both the selected path and the rejected alternative. Mark an alternative “not selected” when it was available but not chosen; mark it “unavailable” only when the provider or evidence establishes that. Record the reason in one sentence tied to an input: unsupported architecture, missing device disclosure, unowned driver maintenance, policy uncertainty, unacceptable operating requirement, or verified budget constraint.
Memory and artifact handoff
Send Article 4 the exact artifact identity and separate file bytes, system RAM, VRAM, process placement, context/KV assumptions, runtime caches, and co-resident processes. Keep unknown quantities open. Do not use a model-family name as a universal memory estimate.
Cost and runtime handoff
Send Article 2 the chosen CPU or GPU product, region, billing unit, accelerator line and minimum, disk, traffic, backup, residual charges and source dates. Include only the chosen architecture in the total; keep alternatives as separate scenarios. Article 5 owns detailed runtime comparisons and release-specific behavior.
Build the Article 2 price roll-up · Check runtime support in Article 5
A missing price is unknown, not zero. Do not assume a GPU charge stops when an instance is powered off, that a retained disk or address is free, or that a traffic allowance is unlimited. Billing and use terms vary by product and time. The captured Contabo terms, content guidance, and traffic-limit page are bounded examples of questions to verify, not a universal approval or permanent product promise. The captured Vultr acceptable-use excerpt is another policy source; read the applicable current text and exact product context before deciding. Hosting permission does not replace model, dataset, software, or user-content rights review.
Use this handoff record for every candidate: decision owner ______; selected path ______; exact product/release ______; evidence links and access dates ______; unresolved fields ______; acceptance criteria ______; next verification and owner ______; reconsideration date or trigger ______. Procurement is ready only when the required evidence is attached and someone owns each remaining check.
Evidence and update gate
Source captures checked 2026-11-06. They establish the documentation statements and historical policy wording cited here, not that a candidate VPS is available, exposes a device, meets a workload, or has a current price. Recheck the selected runtime release, supported architecture, driver/toolkit combination, model format, provider SKU and region, billing unit, terms and support boundary at drafting and again before purchase. Save the exact URL, access date and relevant version alongside the decision record.
- Ollama hardware support — captured runtime hardware and driver/backend requirements; support varies by device family and software stack.
- Ollama Linux installation and Ollama Docker guidance — runtime installation and device-path context, not a provider guarantee.
- vLLM CPU installation — a basic CPU serving/inferencing path under documented platform requirements; not a speed comparison.
- vLLM GPU installation, quantization support, and optimization guidance — version-sensitive device, build, format and configuration details.
- llama.cpp documentation at the captured commit and its build guide — commit-scoped reference, not release-wide proof.
- Contabo terms, content restrictions guidance, and traffic guidance — provider-specific captured terms and statements; confirm current applicability.
- Vultr Acceptable Use Policy — provider-specific policy reference; current language and product scope require review.
For a candidate already defined, return to the Local AI selection hub, send the selected product fields to Article 2, and verify the exact runtime path in Article 5. This page is a procurement worksheet, not a record of deployment, benchmark, provider support confirmation, or security test. Use the methodology page for the site’s evidence approach.