# AnchorGPU — editorial text mirror Environment: public. This file mirrors visible selected editorial content; the canonical HTML remains the reference. AnchorGPU brings together NVIDIA and AMD GPU specifications, fixed-term prices, and configuration tools. Availability must be confirmed before an order is accepted. ## AnchorGPU Facts & Catalog Reference Canonical: https://anchorgpu.com/reference Updated: 2026-09-04 Read the catalog’s scope, billing units, memory conventions and evidence boundaries. Modeled quantities do not establish service availability, which is not verified. AnchorGPU brings together NVIDIA and AMD GPU specifications, fixed-term prices, and configuration tools. Availability must be confirmed before an order is accepted. ### Product status Catalog and configuration reference; GPU provisioning is confirmed by the operator once the crypto payment is matched to the order. Evidence: Current implementation ### Catalog scope 15 GPU models and 6,300 modeled cards across 3 US regions. Evidence: Supplied catalog, not live stock ### Billing units One week = 7 days; one month = 30 days. USD-denominated fixed-term quotes. Evidence: Catalog billing rules ### Node sizes 1, 2, 4, 8 GPUs per modeled node. Aggregate VRAM is not automatically a shared memory pool. Evidence: Catalog configuration model ### Funding methods Check the asset, network, amount, and order reference before any transfer. Payment confirmation and order fulfillment are separate steps. Evidence: Service scope ### Operational evidence Legal operator, reservable inventory, monitoring, payment processor and staffed support await verification. Evidence: Not verified ### Modeled catalog Model | Memory | 7-day USD per card | 30-day USD per card | Modeled quantity B200 SXM | 180 GB HBM3e | 1090 | 3890 | 180 H200 SXM | 141 GB HBM3e | 640 | 2290 | 265 H100 SXM | 80 GB HBM3 | 475 | 1690 | 690 H100 PCIe | 80 GB HBM2e | 420 | 1490 | 510 MI300X | 192 GB HBM3 | 450 | 1590 | 430 A100 SXM | 80 GB HBM2e | 280 | 990 | 780 RTX 5090 | 32 GB GDDR7 | 155 | 540 | 595 L40S | 48 GB GDDR6 ECC | 148 | 520 | 430 RTX 6000 Ada | 48 GB GDDR6 ECC | 130 | 460 | 410 RTX 4090 | 24 GB GDDR6X | 110 | 390 | 590 RTX A6000 | 48 GB GDDR6 ECC | 82 | 290 | 405 L4 | 24 GB GDDR6 ECC | 70 | 250 | 315 A40 | 48 GB GDDR6 ECC | 68 | 240 | 265 RTX 3090 | 24 GB GDDR6X | 65 | 230 | 245 RTX A5000 | 24 GB GDDR6 ECC | 55 | 190 | 190 Catalog prices exclude options. Quantities are not live inventory. Card count does not establish shared memory or a connected GPU fabric. --- ## Sources, Methods & Editorial Policy Canonical: https://anchorgpu.com/editorial-policy Updated: 2026-09-04 How AnchorGPU separates manufacturer specifications, catalog inputs, workload guidance and measured evidence, with rules for recording revisions and corrections. ### Four different kinds of evidence Manufacturer specifications describe a named accelerator or software release. They do not establish the topology, cooling, networking or performance of an AnchorGPU allocation. Catalog inputs describe this product model: prices, node discounts, host resources and regional quantities. They are not live inventory or binding offers. Workload guidance is an interpretation to test, while measured results require a reproducible experiment. ### Sources beside the decision Technical claims are grounded in primary manufacturer or project documentation where available. Reviewed articles and comparisons list the exact source URLs, distinguish limits from recommendations and link to the next practical check. Useful comparisons hold the workload, model revision, numerical settings and quality target constant. Published bandwidth or theoretical compute specifications are not substituted for measured tokens per second, training time or reliability. ### What a benchmark would need to disclose A future measured result must identify the hardware and host topology, software and driver versions, model and data revisions, numerical format, input distribution, concurrency or batch size, warm-up policy and test duration. Results must include the metric definition, failure rate and relevant memory or utilization constraints. There are currently no AnchorGPU physical-infrastructure benchmarks, audited uptime figures or verified customer testimonials in this edition. ### Dates, authorship and corrections Article dates indicate the recorded editorial revision, not the date a server built or crawled the page. Catalog updates have a separate snapshot date. AnchorGPU is the publishing identity; this site does not invent individual expert credentials or a history of independent reviews. When a material error is confirmed, revise the explanation, update the date, and note consequential changes in the changelog. The support center describes the currently available contact routes; no externally staffed correction inbox is connected. ### Translations retain the same evidence Translations must preserve model names, numbers, currencies, units, source URLs, code examples, and operational or availability warnings. Machine output requires checks for omissions and meaning changes before publication. A translated URL becomes independently indexable only when its content and metadata are complete and reviewed. English placeholder pages are not presented as finished translations, and alternate-language links must reflect actual available versions. --- ## GPU Workload Glossary: VRAM, KV Cache & Parallelism Canonical: https://anchorgpu.com/glossary Updated: 2026-09-04 Plain-language definitions of GPU memory, KV cache, quantization, CUDA, ROCm, tensor parallelism, training and fixed-term billing. ### VRAM Memory local to an accelerator. Workload capacity includes more than model weights: activations, buffers, cached state and framework allocations can also consume it. Source: https://docs.pytorch.org/docs/stable/notes/cuda.html#cuda-memory-management ### KV cache Key and value tensors retained by autoregressive serving for live sequences. Model architecture, cache precision, token count and concurrency affect the required capacity. Source: https://docs.vllm.ai/en/latest/serving/parallelism_scaling/ ### Quantization Representing some model values with reduced numerical precision. Real memory use includes format metadata and runtime workspaces; supported kernels and output quality must be checked. Source: https://docs.vllm.ai/en/latest/features/quantization/ ### Tensor parallelism Distributing parts of model tensor operations across accelerators. It can spread a model across cards but introduces communication and requires an explicitly supported serving or training strategy. Source: https://docs.vllm.ai/en/latest/serving/parallelism_scaling/ ### DistributedDataParallel (DDP) A PyTorch training approach that runs model replicas across processes and synchronizes gradients. Replication does not combine device memories into one contiguous pool. Source: https://docs.pytorch.org/tutorials/beginner/dist_overview.html ### Fully Sharded Data Parallel (FSDP) Distributed training that shards model parameters, gradients and optimizer state. Memory savings come with communication, coordination and checkpoint requirements. Source: https://docs.pytorch.org/docs/stable/fsdp.html ### CUDA NVIDIA’s parallel-computing platform and programming model. A CUDA-dependent workload still requires compatible hardware, driver, runtime and libraries. Source: https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html ### ROCm AMD’s software stack for GPU computing. Support must be checked for the exact GPU, operating system, framework build and workload dependencies. Source: https://rocm.docs.amd.com/en/latest/ ### Training checkpoint Saved state used to resume or reproduce training. Depending on the run, this includes the model, optimizer, schedule, random state and progress through the data. Verify restoration, not just writing. Source: https://docs.pytorch.org/tutorials/beginner/saving_loading_models.html ### Variational autoencoder (VAE) In a diffusion pipeline, a component that maps between latent representations and viewable outputs. Decoding can have a separate memory peak from denoising; supported chunking or tiling requires quality checks. Source: https://huggingface.co/docs/diffusers/main/optimization/memory ### Fixed rental term In this catalog, a week is exactly 7 days and a month exactly 30 days. Stopping a modeled allocation does not pause the paid period. GPU prices and selected options form the complete quote. Source: https://anchorgpu.com/pricing ### Idempotency key An identifier that lets a supported operation recognize a repeated request, so the same action is not applied twice. Reuse it for a retry of the same operation, not a different purchase or configuration. Source: https://anchorgpu.com/docs/api-reference --- ## GPU Rental & Hardware FAQ Canonical: https://anchorgpu.com/faq/hardware Updated: 2026-09-04 Dedicated allocation, GPU choice, availability, node sizes, and provisioning. ### What does “dedicated GPU” mean? Answer link: https://anchorgpu.com/faq/hardware#q-what-does-dedicated-gpu-mean A dedicated GPU configuration means one card is reserved for one customer for the paid term rather than time-sliced. Actual allocation is confirmed only when provisioning succeeds. ### Which GPUs and regions are available? Answer link: https://anchorgpu.com/faq/hardware#q-which-gpus-and-regions-are-available The catalog covers NVIDIA and AMD models across Dallas, Ashburn, and Portland. Catalog quantities are reference values; current availability must be confirmed before an order is accepted. ### Can I rent more than one GPU? Answer link: https://anchorgpu.com/faq/hardware#q-can-i-rent-more-than-one-gpu Configurations support 1, 2, 4, or 8 cards. The catalog applies the published volume discount to 2-, 4-, and 8-GPU nodes and shows the complete 7- or 30-day price before deployment. ### How should I choose a GPU? Answer link: https://anchorgpu.com/faq/hardware#q-how-should-i-choose-a-gpu Start with required VRAM, software compatibility, latency or throughput goals, and whether the workload can use multiple cards efficiently. Multiple GPUs do not automatically behave as one shared memory pool; the application must support sharding or parallel execution. ### How long does provisioning take? Answer link: https://anchorgpu.com/faq/hardware#q-how-long-does-provisioning-take Provisioning time is not published. A deployment must remain pending until the infrastructure provider confirms a usable machine. --- ## Accounts & Access FAQ Canonical: https://anchorgpu.com/faq/accounts Updated: 2026-09-04 Pseudonymous signup, recovery codes, SSH keys, sessions, and API keys. ### Do I need an email address, phone number, or identity document? Answer link: https://anchorgpu.com/faq/accounts#q-do-i-need-an-email-address-phone-number-or-identity-document No. The intended signup flow uses a unique username and password without requesting an email address, phone number, or identity document. The Acceptable Use Policy and applicable legal obligations still apply. ### How is my account recovered without email? Answer link: https://anchorgpu.com/faq/accounts#q-how-is-my-account-recovered-without-email Recovery codes are shown once when the account is created. Store them offline and separately from the password; they are the recovery path when no email address or phone number is attached to the account. ### What happens if I lose both my password and recovery codes? Answer link: https://anchorgpu.com/faq/accounts#q-what-happens-if-i-lose-both-my-password-and-recovery-codes The account may not be recoverable because support has no verified email or phone identity to fall back on. Never assume that a wallet transaction, username, or support message alone proves account ownership. ### Which SSH keys can I add? Answer link: https://anchorgpu.com/faq/accounts#q-which-ssh-keys-can-i-add Add a supported SSH public key, such as Ed25519 or ECDSA P-256. Never paste a private key, seed phrase, recovery code, password, or API secret into the dashboard or a support request. ### How do API keys and sessions work? Answer link: https://anchorgpu.com/faq/accounts#q-how-do-api-keys-and-sessions-work API secrets should be displayed only when created and stored as hashes by the service. Revoke a key or active session if it is exposed, and use a separate key for each system so access can be withdrawn independently. --- ## Pricing & Deployment FAQ Canonical: https://anchorgpu.com/faq/pricing Updated: 2026-09-04 Fixed rental periods, complete quotes, inventory reservations, and charges. ### Are rentals billed by the hour? Answer link: https://anchorgpu.com/faq/pricing#q-are-rentals-billed-by-the-hour No. A weekly term is exactly 7 consecutive days and a monthly term is exactly 30 consecutive days. There is no hourly meter inside either fixed term. ### How is the total rental price calculated? Answer link: https://anchorgpu.com/faq/pricing#q-how-is-the-total-rental-price-calculated The total starts with the published per-card price, multiplies it by the selected card count, applies the published node discount, and adds selected options. The complete USD-denominated amount should be visible before any balance is charged. ### When is my balance charged? Answer link: https://anchorgpu.com/faq/pricing#q-when-is-my-balance-charged The billing rule debits the full fixed-term amount only after capacity is accepted for deployment. The displayed balance is derived from individual ledger entries. ### Does requesting a quote reserve inventory? Answer link: https://anchorgpu.com/faq/pricing#q-does-requesting-a-quote-reserve-inventory No. A quote describes a configuration and price for a limited period; capacity is reserved only when a deployment is accepted. Availability may change between viewing a quote and submitting the deployment. ### Can a price change during an active term? Answer link: https://anchorgpu.com/faq/pricing#q-can-a-price-change-during-an-active-term The price for an active 7- or 30-day term does not change. The applicable renewal price must be shown before the next charge. --- ## Crypto Payments FAQ Canonical: https://anchorgpu.com/faq/crypto Updated: 2026-09-04 Supported networks, confirmations, deposit quotes, ledger credits, and withdrawals. ### Can I send cryptocurrency to an address shown at checkout? Answer link: https://anchorgpu.com/faq/crypto#q-can-i-send-cryptocurrency-to-the-addresses-shown-in-this-preview Only after checkout displays a confirmed payment request linked to your order. The addresses shown can be real: verify the asset, network, address, amount, and order reference before sending. Never send funds during testing or from an unconfirmed screen. ### Which cryptocurrencies and networks are supported? Answer link: https://anchorgpu.com/faq/crypto#q-which-cryptocurrencies-and-networks-are-supported Checkout lists BTC on Bitcoin, ETH on Ethereum, USDT on TRC-20, USDC on ERC-20, XMR on Monero, SOL on Solana, and LTC on Litecoin. Availability depends on the payment integration. Sending an asset on another network may be unrecoverable. ### When is a deposit credited? Answer link: https://anchorgpu.com/faq/crypto#q-when-is-a-deposit-credited The displayed thresholds are 1 confirmation for BTC, 12 for ETH, 19 for USDT TRC-20, 12 for USDC ERC-20, 10 for XMR, 32 for SOL, and 6 for LTC. Credit must occur only after the payment integration confirms the required threshold. ### How is the crypto amount calculated, and are there deposit fees? Answer link: https://anchorgpu.com/faq/crypto#q-how-is-the-crypto-amount-calculated-and-are-there-deposit-fees Checkout shows an indicative, time-stamped conversion for a chosen USD amount. It is not a payment request or locked rate; network and withdrawal fees are excluded, and payment confirmation is handled separately. ### How do withdrawals work? Answer link: https://anchorgpu.com/faq/crypto#q-how-do-withdrawals-work Withdrawals are not enabled until limits, rate handling, network fees, review timing, asset provenance, and processing responsibilities are published. --- ## Renewals & Lifecycle FAQ Canonical: https://anchorgpu.com/faq/lifecycle Updated: 2026-09-04 Automatic renewal, grace periods, stop, release, and recovery behavior. ### How does automatic renewal work? Answer link: https://anchorgpu.com/faq/lifecycle#q-how-does-automatic-renewal-work When enabled, automatic renewal is attempted 24 hours before the current term expires. The renewal must create only one charge for that billing period, even if a scheduled job is delivered more than once. ### What happens if my balance is too low for renewal? Answer link: https://anchorgpu.com/faq/lifecycle#q-what-happens-if-my-balance-is-too-low-for-renewal The instance continues until the paid term ends, then stops. Its reservation and local data remain in a 72-hour grace period before final release; no partial renewal or negative balance should be created. ### Can I renew during the grace period? Answer link: https://anchorgpu.com/faq/lifecycle#q-can-i-renew-during-the-grace-period The intended lifecycle allows renewal while the instance remains in grace if sufficient eligible balance is available. Once release has completed, the former instance and its local data cannot be restored. ### What is the difference between stopping and releasing an instance? Answer link: https://anchorgpu.com/faq/lifecycle#q-what-is-the-difference-between-stopping-and-releasing-an-instance Stopping is reversible and does not pause or extend the paid term. Release is permanent in the account workflow; infrastructure data deletion depends on the provisioning integration and published retention policy. ### Can I disable automatic renewal or renew manually? Answer link: https://anchorgpu.com/faq/lifecycle#q-can-i-disable-automatic-renewal-or-renew-manually Yes. Automatic renewal can be disabled before the renewal attempt, and a manual renewal can be requested while the instance remains eligible. The account should always show the resulting term end and charge. --- ## Networking, Storage & Images FAQ Canonical: https://anchorgpu.com/faq/networking-storage Updated: 2026-09-04 Machine images, containers, local NVMe, public addresses, and bandwidth. ### Which machine images are offered? Answer link: https://anchorgpu.com/faq/networking-storage#q-which-machine-images-are-offered The catalog lists Ubuntu, PyTorch, vLLM, ComfyUI, Ollama, JAX, ROCm, and Debian starting points. Image availability depends on GPU vendor compatibility; for example, ROCm targets supported AMD configurations. ### Can I install my own software or use containers? Answer link: https://anchorgpu.com/faq/networking-storage#q-can-i-install-my-own-software-or-use-containers The intended dedicated-node service provides administrative access so customers can update packages, run containers, and configure their workload. Customers remain responsible for licenses, security updates, and compatibility with the selected hardware. ### What happens to local NVMe data? Answer link: https://anchorgpu.com/faq/networking-storage#q-what-happens-to-local-nvme-data The account lifecycle treats local NVMe as part of the instance. Stopping preserves its allocation during the paid term or grace period; final deletion depends on the provisioning integration and retention policy. Do not treat local NVMe as a backup. ### Can I add storage or a public IP address? Answer link: https://anchorgpu.com/faq/networking-storage#q-can-i-add-storage-or-a-public-ip-address The catalog can quote extra NVMe storage, a dedicated public IPv4 address, additional bandwidth, and a private colocation VLAN. Availability, limits, and the exact period price should be confirmed before deployment. ### Are bandwidth and backups unlimited? Answer link: https://anchorgpu.com/faq/networking-storage#q-are-bandwidth-and-backups-unlimited Do not assume either. The deployment quote and documentation must state included transfer, purchased increments, enforcement behavior, and any overage policy. Backups exist only when a specific backup or persistent-storage product is selected and documented. --- ## Security & Privacy FAQ Canonical: https://anchorgpu.com/faq/security Updated: 2026-09-04 Workload privacy, retained records, customer responsibilities, and acceptable use. ### Does AnchorGPU inspect my models, prompts, datasets, or files? Answer link: https://anchorgpu.com/faq/security#q-does-anchorgpu-inspect-my-models-prompts-datasets-or-files The intended design does not inspect workload content by default; actual isolation and operator access still need production verification. Limited host, network, account, billing, and security information may be processed when needed to operate the service, investigate authorized support, respond to an active threat, or meet a valid legal obligation. ### What operational information is retained? Answer link: https://anchorgpu.com/faq/security#q-what-operational-information-is-retained The intended records include account and session data, public SSH keys, API-key hashes, ledger and transaction records, instance configuration, support messages, and limited security telemetry. Exact retention periods and subprocessors must be stated in the production Privacy Policy. ### What security responsibilities remain mine? Answer link: https://anchorgpu.com/faq/security#q-what-security-responsibilities-remain-mine Customers are responsible for protecting passwords, recovery codes, SSH private keys and API secrets; applying software updates; limiting exposed services; and securing their own data and backups. Dedicated hardware does not make an unsafe workload secure. ### What activity is prohibited? Answer link: https://anchorgpu.com/faq/security#q-what-activity-is-prohibited The service must not be used for malware, phishing, credential theft, botnets, unsolicited messaging, denial-of-service attacks, unauthorized access, exploitation of minors, interference with other tenants, or unlawful conduct. Security testing requires authorization from the target. ### Does “no KYC” mean there are no rules or abuse controls? Answer link: https://anchorgpu.com/faq/security#q-does-no-kyc-mean-there-are-no-rules-or-abuse-controls No. It means identity documents are not requested at signup. AnchorGPU may still enforce its Acceptable Use Policy, protect customers and infrastructure, investigate credible reports, and respond to valid legal process. --- ## Refunds & Used Hardware FAQ Canonical: https://anchorgpu.com/faq/refunds-used-hardware Updated: 2026-09-04 Corrections, service credits, condition reports, delivery, warranty, and returns. ### Can I receive a prorated refund if I release a healthy instance early? Answer link: https://anchorgpu.com/faq/refunds-used-hardware#q-can-i-receive-a-prorated-refund-if-i-release-a-healthy-instance-early Normally no. A fixed term reserves dedicated capacity for all 7 or 30 days, so stopping or releasing a healthy instance early does not create an automatic prorated refund. ### What happens after a duplicate charge or failed deployment? Answer link: https://anchorgpu.com/faq/refunds-used-hardware#q-what-happens-after-a-duplicate-charge-or-failed-deployment A verified duplicate debit or deployment that never becomes usable should be corrected with a separate compensating ledger entry. Existing accounting entries should not be silently edited or deleted. ### When is a service credit available? Answer link: https://anchorgpu.com/faq/refunds-used-hardware#q-when-is-a-service-credit-available Service-credit eligibility depends on an approved SLA covering exclusions, measurement, claim windows, and the credit schedule. No uptime or credit commitment is made until that SLA is published. ### Are the used GPUs shown on the site available to purchase? Answer link: https://anchorgpu.com/faq/refunds-used-hardware#q-are-the-used-gpus-shown-in-the-preview-available-to-purchase Catalog entries are not binding offers. Before accepting an order, a listing must confirm stock, condition, test results, included items, exact price, location, and serial-specific details. ### How will used-GPU payment, shipping, warranty, and returns work? Answer link: https://anchorgpu.com/faq/refunds-used-hardware#q-how-will-used-gpu-payment-shipping-warranty-and-returns-work Used-hardware orders must not be accepted until the listing and sales terms disclose payment, delivery regions, shipping responsibility, taxes or duties, transfer of title, warranty, returns, and item condition. --- ## H200 SXM vs MI300X: memory headroom or CUDA continuity? Canonical: https://anchorgpu.com/compare/nvidia-h200-sxm-vs-amd-mi300x Updated: 2026-09-04 Compare H200 SXM and MI300X: 141 vs 192 GB memory, software requirements, fixed-term costs and workload tradeoffs. ### Quick answer H200 SXM vs MI300X: memory headroom or CUDA continuity? Prefer H200 for CUDA-dependent continuity. Evaluate MI300X when a validated ROCm path and larger single-accelerator memory reduce your application’s complexity. - Inventory custom CUDA extensions, attention kernels, quantization kernels and collective operations. - Validate model loading, a representative request or step, numerical output and checkpoint restore. - Measure the KV cache or training state alongside model weights; capacity is not just parameter count. Manufacturer specifications describe the accelerator, not verified AnchorGPU host topology. Catalog cost differences are not performance measurements. H200 offers 141 GB on the Hopper CUDA platform; MI300X offers 192 GB on AMD’s ROCm platform. More memory can simplify the model layout, while retaining an already-qualified software stack can reduce migration work. Choose H200 when the application depends on CUDA-only extensions, Hopper-validated containers or NVIDIA libraries that have not been qualified on ROCm. The larger memory capacity relative to an 80 GB card may reduce the need for sharding. Choose MI300X when 192 GB can avoid a multi-GPU split and the complete workload has passed testing on ROCm. Validate the serving or training backend, custom operations, attention kernels and quantization format, not just a successful PyTorch import. Architecture | NVIDIA Hopper | AMD CDNA 3 Memory | 141 GB HBM3e | 192 GB HBM3 Published memory bandwidth | 4.8 TB/s | 5.3 TB/s peak theoretical Primary software stack | CUDA | ROCm Reference accelerator fabric | NVLink in HGX systems | Infinity Fabric in MI300X platforms - Inventory custom CUDA extensions, attention kernels, quantization kernels and collective operations. - Validate model loading, a representative request or step, numerical output and checkpoint restore. - Measure the KV cache or training state alongside model weights; capacity is not just parameter count. - Do not interpret memory bandwidth specifications as measured tokens per second or training speed. Prefer H200 for CUDA-dependent continuity. Evaluate MI300X when a validated ROCm path and larger single-accelerator memory reduce your application’s complexity. Specifications are manufacturer data. They are not a measured AnchorGPU benchmark. ### Sources - NVIDIA H200 specifications: https://www.nvidia.com/en-us/data-center/h200/ [official-documentation] - AMD MI300X specifications: https://www.amd.com/en/products/accelerators/instinct/mi300/mi300x.html [official-documentation] - PyTorch on ROCm: https://rocm.docs.amd.com/projects/install-on-linux/en/docs-6.4.0/install/3rd-party/pytorch-install.html [official-documentation] - Modeled price inputs, not measured performance: https://anchorgpu.com/reference#catalog [catalog-model] --- ## H100 SXM vs H100 PCIe: same capacity, different system design Canonical: https://anchorgpu.com/compare/nvidia-h100-sxm-vs-nvidia-h100-pcie Updated: 2026-09-04 Compare H100 SXM and H100 PCIe: 80 vs 80 GB memory, software requirements, fixed-term costs and workload tradeoffs. ### Quick answer H100 SXM vs H100 PCIe: same capacity, different system design PCIe is the lower-cost Hopper choice for independent work. SXM is a candidate for closely coupled workloads only when the delivered topology supports the intended strategy. - Confirm which requested GPUs share the same CPU and NUMA domain. - Ask which pairs have NVLink and whether the machine contains NVSwitch, a two-card bridge or PCIe-only communication. - Verify the GPU, network adapter and local storage placement for your communication pattern. Manufacturer specifications describe the accelerator, not verified AnchorGPU host topology. Catalog cost differences are not performance measurements. Both models use Hopper and offer 80 GB, but the memory subsystem and host integration differ. The useful question is whether your workload needs a connected multi-GPU platform or can run on one card or independent replicas. Choose H100 SXM for a communication-sensitive model split across several GPUs, provided that the allocation actually exposes the expected HGX fabric. Memory-bandwidth-sensitive work is another reason to test SXM against PCIe. Choose H100 PCIe when one GPU is sufficient, workers operate independently, or a lower-priced Hopper configuration meets the measured latency and throughput requirement. Do not assume that multiple PCIe cards create an all-to-all GPU fabric. Architecture | Hopper | Hopper Memory | 80 GB HBM3 | 80 GB HBM2e Published memory bandwidth | 3.35 TB/s | 2.0 TB/s Form factor | SXM | Dual-slot PCIe Gen5 Reference system connection | HGX NVLink/NVSwitch platforms | PCIe; optional bridge to an adjacent H100 - Confirm which requested GPUs share the same CPU and NUMA domain. - Ask which pairs have NVLink and whether the machine contains NVSwitch, a two-card bridge or PCIe-only communication. - Verify the GPU, network adapter and local storage placement for your communication pattern. - Check driver, CUDA, framework and collective-library versions as one environment. PCIe is the lower-cost Hopper choice for independent work. SXM is a candidate for closely coupled workloads only when the delivered topology supports the intended strategy. Specifications are manufacturer data. They are not a measured AnchorGPU benchmark. ### Sources - NVIDIA H100 specifications: https://www.nvidia.com/en-us/data-center/h100/ [official-documentation] - NVIDIA H100 PCIe product brief: https://www.nvidia.com/content/dam/en-zz/Solutions/gtcs22/data-center/h100/PB-11133-001_v01.pdf [official-documentation] - Modeled price inputs, not measured performance: https://anchorgpu.com/reference#catalog [catalog-model] --- ## H100 SXM vs A100 SXM: is Hopper worth the premium? Canonical: https://anchorgpu.com/compare/nvidia-h100-sxm-vs-nvidia-a100-sxm Updated: 2026-09-04 Compare H100 SXM and A100 SXM: 80 vs 80 GB memory, software requirements, fixed-term costs and workload tradeoffs. ### Quick answer H100 SXM vs A100 SXM: is Hopper worth the premium? Start with A100 as the lower-cost 80 GB baseline. Choose H100 when an application-level pilot shows a useful Hopper advantage. - Switching between these models does not increase the 80 GB capacity. - FP8-capable hardware does not prove that your model, kernels or quality target can use FP8. - Multi-GPU scaling requires an explicit parallelism strategy and a verified host fabric. Manufacturer specifications describe the accelerator, not verified AnchorGPU host topology. Catalog cost differences are not performance measurements. Both accelerators offer 80 GB, so this is not primarily a memory-capacity decision. Compare the value of a Hopper-optimized software path with the lower fixed cost of an established Ampere configuration. Choose H100 SXM when your application has a validated Hopper path, such as kernels deliberately using Transformer Engine or FP8, or when profiling identifies memory movement as a bottleneck. Keep the accuracy target and software versions the same in your pilot. Choose A100 SXM when the complete workload already fits in 80 GB, the CUDA environment is proven on Ampere, and a pilot has not demonstrated enough benefit from Hopper to cover the higher rental cost. Architecture | Hopper | Ampere Memory | 80 GB HBM3 | 80 GB HBM2e Published memory bandwidth | 3.35 TB/s | 2,039 GB/s Published SXM NVLink bandwidth | 900 GB/s | 600 GB/s - Switching between these models does not increase the 80 GB capacity. - FP8-capable hardware does not prove that your model, kernels or quality target can use FP8. - Multi-GPU scaling requires an explicit parallelism strategy and a verified host fabric. - Compare peak memory, useful step throughput, communication time and validation quality with the same workload. Start with A100 as the lower-cost 80 GB baseline. Choose H100 when an application-level pilot shows a useful Hopper advantage. Specifications are manufacturer data. They are not a measured AnchorGPU benchmark. ### Sources - NVIDIA H100 specifications: https://www.nvidia.com/en-us/data-center/h100/ [official-documentation] - NVIDIA A100 specifications: https://www.nvidia.com/en-us/data-center/a100/ [official-documentation] - Modeled price inputs, not measured performance: https://anchorgpu.com/reference#catalog [catalog-model] --- ## Prepare your first node request Canonical: https://anchorgpu.com/docs/quickstart Updated: 2026-09-04 Create an account, save an SSH key, review funding requirements, and prepare your first GPU node request. ### Quick answer How do I prepare a GPU node request? Create an account, save the recovery codes, add a public SSH key, then review the GPU, region, image, term, options, and total price. Submit the configuration only after checking every field; an order is confirmed only when the connected payment and provisioning services return confirmed states. The current workflow saves configuration and lifecycle records but does not provision physical hardware or transfer funds. - Keep private keys and recovery codes out of support messages. - Review the fixed period and selected options. - A saved instance record is not a reachable physical server. AnchorGPU provides catalog and configuration reference material. Crypto payments are received on the addresses shown at checkout; provisioning and availability are confirmed by the operator for each order. ### 1. Create your account Choose a unique account identifier with 3–32 letters, digits, underscores or hyphens. Usernames are case-insensitive. Your password must contain 12–128 characters. Save the eight recovery codes shown after registration. Each code can reset your password once. There is no email recovery flow; keep the codes somewhere separate from your password. ### 2. Save an SSH public key Open SSH keys in your dashboard and paste an Ed25519 or ECDSA P-256 public key. Give it a recognizable label, such as Work laptop. The key is saved to your account and can be selected for subsequent deployments. ### 3. Review funding requirements Open Wallet to review the asset, network, requested USD value, and confirmation threshold. Creating a quote does not change the balance, and no order should be treated as paid until the connected payment workflow confirms settlement. Displayed non-production addresses must not receive cryptocurrency. Payment matching and reconciliation are not connected in this build. ### 4. Review and submit the request Choose a GPU, 1/2/4/8 cards, a region, a compatible image and a 7- or 30-day period. Select your SSH key and any options. The summary includes the node discount and option charges. Review deployment validates the configuration and total on the server. Submitting creates a configuration request; treat the order as confirmed only when the connected payment and provisioning services return confirmed states. The current instance record does not provision a physical GPU or remote SSH host. ### Sources - Product implementation notes · 1. Create your account: https://anchorgpu.com/docs/quickstart#account [product-documentation] - Product implementation notes · 2. Save an SSH public key: https://anchorgpu.com/docs/quickstart#key [product-documentation] - Product implementation notes · 3. Review funding requirements: https://anchorgpu.com/docs/quickstart#balance [product-documentation] - Product implementation notes · 4. Review and submit the request: https://anchorgpu.com/docs/quickstart#deploy [product-documentation] --- ## SSH keys & access Canonical: https://anchorgpu.com/docs/ssh-access Updated: 2026-09-04 Generate an SSH public key, compare its fingerprint and manage keys for future deployments. ### Quick answer What is required to connect to a GPU node over SSH? A real node needs your public SSH key installed and a verified reachable endpoint. Keep the private key on your own device and verify the host identity before connecting. The configuration interface saves supported public keys but does not provision a remote SSH host. - Never upload a private key. - A saved public key does not prove a machine exists. - Use the endpoint of the actual provisioned allocation. AnchorGPU provides catalog and configuration reference material. Crypto payments are received on the addresses shown at checkout; provisioning and availability are confirmed by the operator for each order. ### Generate an Ed25519 key Run the command below in a terminal with OpenSSH installed. Choose a new filename when prompted, and a passphrase to protect the private key. Do not overwrite an existing key you still use. Code example: ssh-keygen -t ed25519 -a 64 The .pub file is your public key. Its matching file without .pub is private and stays on your computer. ### Register the complete public key In Dashboard → SSH keys, enter a label and paste the entire line from the .pub file. Supported formats begin with ssh-ed25519 or ecdsa-sha2-nistp256, followed by the encoded key and an optional comment. The saved SHA256 fingerprint identifies the public key. Changing a comment does not change its fingerprint. To compare locally, run ssh-keygen -lf followed by the path to the .pub file. ### Use and revoke a key Select one saved, active key when configuring a node. Revoking a key removes it from future deployment choices; it is not a remote command to edit an existing machine. The local demo validates and stores keys but does not create a remote host. A connection command will require a real hostname, username and independently verified host fingerprint when provisioning is connected. ### Sources - Product implementation notes · Generate an Ed25519 key: https://anchorgpu.com/docs/ssh-access#generate [product-documentation] - Product implementation notes · Register the complete public key: https://anchorgpu.com/docs/ssh-access#register [product-documentation] - Product implementation notes · Use and revoke a key: https://anchorgpu.com/docs/ssh-access#access [product-documentation] --- ## Billing & your ledger Canonical: https://anchorgpu.com/docs/billing-ledger Updated: 2026-09-04 Understand fixed terms, volume discounts, option charges, renewals and the balance shown in your ledger. ### Quick answer How is the AnchorGPU balance calculated? The balance is the sum of signed ledger entries. A confirmed rental would charge the complete 7- or 30-day configuration, including options and applicable node discounts. Quote, deployment, renewal, and withdrawal mutations use replay safeguards, and corrections require new entries rather than rewriting history. Until payment reconciliation is connected, displayed records are not evidence of settled funds. - A quote alone does not credit or debit the balance. - Stopping does not pause a fixed paid term. - Displayed credits and charges are configuration records, not proof of settled customer transactions. AnchorGPU provides catalog and configuration reference material. Crypto payments are received on the addresses shown at checkout; provisioning and availability are confirmed by the operator for each order. ### Fixed terms, not hourly metering A week is seven days and a month is thirty days. The total is charged from the USD balance when the deployment is accepted. Stopping an instance does not pause the term. Releasing an instance does not automatically refund unused time. The node discount is 0% for one card, 5% for two, 8% for four and 10% for eight. The GPU subtotal is rounded to the nearest whole dollar after applying the discount. Selected options are added once per node and term, without the volume discount. ### Know what is included GPU allocation and selected options appear separately in the configuration summary. NVMe, IPv4, bandwidth and private VLAN options have their own weekly and monthly prices. The final quote is recalculated on the server before deployment. Your instance stores the accepted total, including options. Manual and automatic renewal use that stored price for the same term; a later catalog change does not silently change that instance’s renewal charge. ### Read the account ledger The balance is the sum of your ledger entries, stored as integer USD cents. A deposit is positive; deployment, renewal and withdrawal reservations are negative. The billing screen shows the latest 100 entries while the balance uses the complete history. Entries are append-only. Retrying the same confirmed demo deposit does not credit it twice. Deployment, renewal and withdrawal API requests use an Idempotency-Key so a retry can refer to the same operation. ### Sources - Product implementation notes · Fixed terms, not hourly metering: https://anchorgpu.com/docs/billing-ledger#terms [product-documentation] - Product implementation notes · Know what is included: https://anchorgpu.com/docs/billing-ledger#options [product-documentation] - Product implementation notes · Read the account ledger: https://anchorgpu.com/docs/billing-ledger#ledger [product-documentation] --- ## Deposits & withdrawals Canonical: https://anchorgpu.com/docs/crypto-funding Updated: 2026-09-04 Create a sandbox quote, credit the local wallet and understand withdrawal reservations. ### Quick answer Can I fund the local wallet with real cryptocurrency? Not yet. The checkout contains real receiving addresses, but payment matching and confirmation are not connected. Do not send funds without a confirmed payment request linked to your order. An address or conversion alone is not a payment request. - Never send funds unless an order identifies a verified production destination. - An asset and its network are one payment choice. - A repeated confirmation must not create a second credit. AnchorGPU provides catalog and configuration reference material. Crypto payments are received on the addresses shown at checkout; provisioning and availability are confirmed by the operator for each order. ### Create a deposit quote Choose a supported asset and its displayed network. Enter between $10 and $100,000. The quote records the requested USD value, the asset, the network and the confirmation threshold, and expires after ten minutes. Quotes in this build are sandbox records, not live exchange-rate offers. Their SANDBOX-prefixed addresses must not receive cryptocurrency. Code example: POST /api/v1/deposit-quotes Content-Type: application/json { "asset": "usdc", "desiredUsdCents": 50000 } ### Credit your local account Use Simulate confirmation on the quote to add the requested demo credit. This action is available only on the local development server. You must be signed in to the account that owns the quote. The confirmed event and ledger credit are saved together. Repeating a confirmation returns the existing result without adding more credit. If the quote expires before confirmation, create a new quote. ### Record a withdrawal request The minimum request is $25. The asset must have a credited deposit on this account, and the available balance must cover the amount. Enter a destination for the same network. Submitting records a requested withdrawal and reserves its amount with a negative ledger entry. The local demo does not send a blockchain transaction. The status remains requested until a payment-processing workflow is connected. ### Sources - Product implementation notes · Create a deposit quote: https://anchorgpu.com/docs/crypto-funding#quote [product-documentation] - Product implementation notes · Credit your local account: https://anchorgpu.com/docs/crypto-funding#credit [product-documentation] - Product implementation notes · Record a withdrawal request: https://anchorgpu.com/docs/crypto-funding#withdraw [product-documentation] --- ## Manage an instance Canonical: https://anchorgpu.com/docs/instance-lifecycle Updated: 2026-09-04 Understand start, stop, renewal, the grace period and release for fixed-term GPU nodes. ### Quick answer What is the difference between stopping, renewing and releasing? Stopping is reversible within an eligible allocation and does not extend its paid term. Renewal adds the next fixed period and creates a corresponding charge. Release ends the allocation permanently in the product model. The configuration workflow stores these lifecycle states but does not control physical hardware. - Review auto-renew before the next term. - A low balance can prevent renewal. - Back up required artifacts before a real allocation ends. AnchorGPU provides catalog and configuration reference material. Crypto payments are received on the addresses shown at checkout; provisioning and availability are confirmed by the operator for each order. ### From running to released Running means an active allocation in the local lifecycle. Stop changes it to stopped without altering its end date. Start is accepted only for a stopped instance whose paid term has not expired. Released is final: it returns modeled capacity to the pool, and the instance cannot be started or renewed. Release asks for confirmation in the dashboard. ### Renew manually or automatically Renew adds another full term after the current end date, or after the current time if the old term has already expired. The renewal price is displayed on the instance card before the action. Auto-renew is off by default unless you enable it. The scheduled worker looks for eligible instances during the 24 hours before expiry. It renews only when the account balance can cover the stored price. The local development server does not invoke scheduled events automatically; manual renewal is available for testing. ### Expiry and the 72-hour grace window When the lifecycle worker processes an expired instance, it enters grace. The grace deadline is 72 hours after the original expiry, not 72 hours after the worker happens to run. Starting is blocked until renewal succeeds. After the grace deadline the worker releases the allocation. An expired node cannot be brought back merely by toggling start. These are local database transitions; production power, storage and data-retention behavior still require a provisioning integration. ### Sources - Product implementation notes · From running to released: https://anchorgpu.com/docs/instance-lifecycle#states [product-documentation] - Product implementation notes · Renew manually or automatically: https://anchorgpu.com/docs/instance-lifecycle#renewal [product-documentation] - Product implementation notes · Expiry and the 72-hour grace window: https://anchorgpu.com/docs/instance-lifecycle#expiry [product-documentation] --- ## Choose a machine image Canonical: https://anchorgpu.com/docs/machine-images Updated: 2026-09-04 Choose an image compatible with your GPU vendor and workload from the current catalog. ### Quick answer Does choosing a GPU image guarantee software compatibility? No. A catalog image is a starting configuration, not proof that a particular model or extension will run. Match the GPU vendor, architecture, driver and CUDA or ROCm build, then test the complete workload. The configuration interface validates catalog choices but does not boot a container or machine. - Record exact versions and container tags. - Qualify custom operators and quantization kernels. - Do not treat a catalog label as an installed environment. AnchorGPU provides catalog and configuration reference material. Crypto payments are received on the addresses shown at checkout; provisioning and availability are confirmed by the operator for each order. ### Start with the workload Choose a general-purpose image if you intend to install your own stack, or a framework image for a specific workflow. The table below is generated from the same catalog as the deployment selector. The available image list changes with the GPU vendor. Switching to an incompatible vendor resets the selection to a compatible image. The server also validates compatibility, including requests made directly through the API. ### Images in the catalog These labels describe the configured image templates. The local demo does not boot containers or validate the installed packages of a remote machine. ### Keep workloads reproducible For a real workload, record the driver, runtime, framework version and model dependencies in your project. A template name alone is not a reproducible environment. Keep your training data and outputs backed up outside the rented node. ### Sources - Product implementation notes · Start with the workload: https://anchorgpu.com/docs/machine-images#selection [product-documentation] - Product implementation notes · Images in the catalog: https://anchorgpu.com/docs/machine-images#catalog [product-documentation] - Product implementation notes · Keep workloads reproducible: https://anchorgpu.com/docs/machine-images#reproducibility [product-documentation] --- ## API reference Canonical: https://anchorgpu.com/docs/api-reference Updated: 2026-09-04 Authenticate with a session or API key and use the implemented account, quote, instance and billing endpoints. ### Quick answer What can the local AnchorGPU API do? The API supports account sessions, saved keys, configuration quotes, and persisted lifecycle records. Use a separate API key for each client, keep secrets server-side, and use idempotency keys for supported monetary and deployment requests. Payment and provisioning adapters are not connected, so responses do not confirm settled funds or physical GPU allocation. - Private endpoints require authentication. - Never put an API secret in a public URL. - An API response from the configuration service is not proof of production availability. AnchorGPU provides catalog and configuration reference material. Crypto payments are received on the addresses shown at checkout; provisioning and availability are confirmed by the operator for each order. ### Authentication The base path is /api/v1. Browser requests use the HttpOnly session cookie created at login. Scripts can use Authorization: Bearer followed by an active API key. Keys have full account permissions and are shown once when created. The local UI uses gh_demo_ keys. Revoking a key immediately prevents new authenticated requests using it. Do not put keys in URLs or browser-side bundles. Code example: GET /api/v1/balance Authorization: Bearer 200 OK { "currency": "USD", "balanceCents": 50000, "derivedFrom": "ledger_entries" } ### Request and retry rules POST and PATCH bodies are JSON objects, with Content-Type: application/json. Send {} for actions without parameters. Bodies are limited to 32 KiB of text. Responses use Cache-Control: no-store. Deployment, manual renewal and withdrawal require an Idempotency-Key of 8–128 characters. Use a new key for a new intended operation and reuse the same key for its retry. Never reuse it with a different body. A replay response includes replayed: true. Instance quotes calculate the current catalog price without reserving capacity. Send expectedPriceCents when deploying; a mismatch returns 409 so the price can be reviewed again. Code example: POST /api/v1/instances Content-Type: application/json Idempotency-Key: Authorization: Bearer { "sku": "nvidia-rtx-4090", "gpuCount": 1, "region": "dal", "image": "pytorch", "period": "week", "options": [], "sshKeyId": "", "autoRenew": false, "expectedPriceCents": 11000 } ### Implemented endpoints All account resources are restricted to their owner. The availability endpoint is public and exposes the catalog snapshot, not a live hardware probe. ### Handle errors explicitly Errors have {error, message}: a stable code and a readable explanation. 400 indicates invalid input, 401 missing or invalid authentication, 403 a rejected origin, 404 an unknown or unowned resource, 409 a balance/state/duplicate conflict, and 415 the wrong content type. For an expired deposit quote, create another quote. For a changed instance state, reload the instance before deciding on another action. After a network interruption, reuse the operation key rather than creating a second charge. ### Sources - Product implementation notes · Authentication: https://anchorgpu.com/docs/api-reference#authentication [product-documentation] - Product implementation notes · Request and retry rules: https://anchorgpu.com/docs/api-reference#requests [product-documentation] - Product implementation notes · Implemented endpoints: https://anchorgpu.com/docs/api-reference#endpoints [product-documentation] - Product implementation notes · Handle errors explicitly: https://anchorgpu.com/docs/api-reference#errors [product-documentation] --- ## Troubleshooting Canonical: https://anchorgpu.com/docs/troubleshooting Updated: 2026-09-04 Resolve sign-in, SSH key, quote, balance and instance-state problems in the local workflow. ### Quick answer Where should I start when a deployment fails? Check the saved configuration, compatible image, available demo balance and required public SSH key. Review the specific response before retrying, and preserve the idempotency key when repeating the same operation. Real driver, network and workload troubleshooting requires access to the actual provisioned host. - Do not share passwords, keys or recovery codes in diagnostics. - Quotes can become stale before confirmation. - The local edition cannot diagnose physical GPU health. AnchorGPU provides catalog and configuration reference material. Crypto payments are received on the addresses shown at checkout; provisioning and availability are confirmed by the operator for each order. ### I cannot sign in Use the username you registered, not an email address. Usernames are case-insensitive. If you have forgotten the password, use one unused recovery code on the recovery page. The reset invalidates previous browser sessions; sign in again with the new password. A 401 response after using an API key can mean the key was revoked. Create another key from an authenticated account session. ### My deposit did not change the balance Creating a sandbox quote is not a deposit. In the local Wallet, use Simulate confirmation before it expires. If it has expired, create a new quote and confirm that one. Refresh the wallet and check Deposits and Billing. Retrying an already confirmed quote must not increase the balance again. The dashboard reads persisted account data, not a browser-only balance. ### Deployment is unavailable or rejected Check that you are signed in, have an active saved SSH key, and have enough balance for the GPU allocation plus options. A malformed-key error usually means the public key line is incomplete or a private key was pasted. If a direct API request reports an image mismatch, choose an image supporting the GPU vendor. If it reports a price change, request a fresh instance quote. A capacity conflict means the modeled allocation pool is full; try another region or configuration. ### Start or renewal fails Refresh the instance list after a state conflict. Start works only for a stopped node within its paid term. An expired node needs renewal first. A released instance cannot be restarted; configure a new node instead. There is no SSH hostname in the local demo because no remote hardware has been allocated. The running label tests the account and billing lifecycle, not a network connection. ### Sources - Product implementation notes · I cannot sign in: https://anchorgpu.com/docs/troubleshooting#signin [product-documentation] - Product implementation notes · My deposit did not change the balance: https://anchorgpu.com/docs/troubleshooting#balance [product-documentation] - Product implementation notes · Deployment is unavailable or rejected: https://anchorgpu.com/docs/troubleshooting#deployment [product-documentation] - Product implementation notes · Start or renewal fails: https://anchorgpu.com/docs/troubleshooting#lifecycle [product-documentation] --- ## Serve an LLM with vLLM Canonical: https://anchorgpu.com/docs/serve-llm-with-vllm Updated: 2026-09-04 Plan memory and concurrency, configure a vLLM endpoint and validate a representative inference workload. ### Quick answer What is the safest first vLLM serving test? Pin the model and serving stack, verify GPU support, and launch a single-GPU pilot bound to loopback with an API key. Test the real prompt lengths and concurrency before selecting parallelism. Record memory, latency and errors; exposing a production endpoint requires separate network and security configuration. - Confirm the model’s chat template. - Distinguish replicas from tensor parallelism. - The commands require real compatible hardware; the local site does not run them. AnchorGPU provides catalog and configuration reference material. Crypto payments are received on the addresses shown at checkout; provisioning and availability are confirmed by the operator for each order. ### Define the serving contract Record the model identifier and revision, weight format, quantization, maximum context length, prompt-length distribution, concurrency and latency objective. These settings are part of the workload, not optional benchmark notes. Weights share GPU memory with the KV cache and temporary workspaces. A model that loads successfully with one short prompt may still run out of memory under the intended traffic. Keep operating headroom and test the longest allowed requests. ### Start with one GPU when it fits A single GPU avoids inter-GPU communication and makes a first deployment easier to diagnose. Consider tensor parallelism when the model and required runtime state do not fit on one accelerator, or when a representative measurement justifies splitting it. Independent replicas serve separate requests; tensor parallelism splits model computation. They solve different problems. A catalog node with several cards does not, by itself, prove a particular interconnect. ### Qualify the complete environment The AnchorGPU vllm image is available for NVIDIA and AMD in the catalog. Before real execution, identify the actual driver, CUDA or ROCm runtime, PyTorch, Python and vLLM versions. Check model architecture, quantization support and any compiled attention kernels together. This local site saves configurations but does not run a remote model server. The following commands belong on a real, provisioned Linux node with the required software and model access. ### Launch a private endpoint Set the model and a private API key in the shell used to launch the server. Replace both placeholders. The key is a vLLM serving credential, not your AnchorGPU account API key. Bind to loopback while validating; remote access needs an authenticated TLS or private-network path. Code example: export MODEL_ID="your-organization/your-model" export VLLM_API_KEY="replace-with-a-private-serving-key" vllm serve "$MODEL_ID" --host 127.0.0.1 --port 8000 For a model intentionally split across four visible GPUs on the same node, add --tensor-parallel-size 4. Confirm the hardware layout and software support before making that change. ### Check the API before load testing In another shell, set the same VLLM_API_KEY and query the model list. A chat-completions request also requires a model with an appropriate chat template; a successful server launch does not guarantee every API task is supported. Code example: curl http://127.0.0.1:8000/v1/models \ -H "Authorization: Bearer $VLLM_API_KEY" Use the model identifier reported by the server in client requests. Keep authentication enabled while testing. ### Measure sustained capacity Replay sanitized requests with the intended prompt lengths, output limits and concurrency. Record time to first token, end-to-end latency, throughput, error rate, GPU memory use and the KV-cache capacity reported by the server. Measure cold model loading separately from steady-state serving. Increase concurrency gradually. If memory becomes the limit, evaluate lower context/concurrency, a suitable quantization format or more memory before assuming more compute will help. Convert completed work into cost using the fixed reservation price. A headline tokens-per-second number is not a capacity promise, and we do not claim AnchorGPU benchmark results in this guide. ### Resolve the common failure modes Chat request fails: check the model’s chat template and supported API task. Memory failure after load increases: check KV-cache pressure, context and concurrency. Multi-GPU initialization hangs: confirm visible devices, collective libraries and the validity of the tensor-parallel split. Save the model revision, container digest, launch configuration, validation results and client API contract. Copy operational artifacts away from the node before releasing it. ### Sources - vLLM GPU installation: https://docs.vllm.ai/en/stable/getting_started/installation/gpu/ [official-documentation] - vLLM parallelism and scaling: https://docs.vllm.ai/en/latest/serving/parallelism_scaling/ [official-documentation] - vLLM quickstart and authentication: https://docs.vllm.ai/en/latest/getting_started/quickstart/ [official-documentation] - vLLM online serving: https://docs.vllm.ai/en/latest/serving/online_serving/ [official-documentation] - Product implementation notes · Define the serving contract: https://anchorgpu.com/docs/serve-llm-with-vllm#contract [product-documentation] - Product implementation notes · Start with one GPU when it fits: https://anchorgpu.com/docs/serve-llm-with-vllm#layout [product-documentation] - Product implementation notes · Qualify the complete environment: https://anchorgpu.com/docs/serve-llm-with-vllm#environment [product-documentation] - Product implementation notes · Launch a private endpoint: https://anchorgpu.com/docs/serve-llm-with-vllm#launch [product-documentation] - Product implementation notes · Check the API before load testing: https://anchorgpu.com/docs/serve-llm-with-vllm#verify [product-documentation] - Product implementation notes · Measure sustained capacity: https://anchorgpu.com/docs/serve-llm-with-vllm#capacity [product-documentation] - Product implementation notes · Resolve the common failure modes: https://anchorgpu.com/docs/serve-llm-with-vllm#failure [product-documentation] --- ## Plan a reproducible PyTorch run Canonical: https://anchorgpu.com/docs/pytorch-fine-tuning Updated: 2026-09-04 Measure memory, choose a parallelism strategy, test checkpoint restore and plan a fixed-term PyTorch training run. ### Quick answer How do I qualify a PyTorch training configuration? Use the real model, data and optimizer, warm up the run, and measure a complete forward, backward and optimizer step. Compare peak tensor allocation with total device use, then test validation, checkpoint save and restore. Scale only after identifying whether memory, computation, communication or data loading is the constraint. - A forward pass is not a complete training-memory test. - DDP and FSDP solve different scaling problems. - Record framework, driver and data revisions with the result. AnchorGPU provides catalog and configuration reference material. Crypto payments are received on the addresses shown at checkout; provisioning and availability are confirmed by the operator for each order. ### Prove one complete step before scaling Lock the model and dataset revisions, dependency versions, training configuration, random seeds and container digest. Run model loading, a complete training step, evaluation, checkpoint save and checkpoint restore on one accelerator. Use the same sequence length and micro-batch settings intended for the longer run. A tiny pilot that omits optimizer state or uses shorter sequences can hide the memory problem you are trying to measure. ### Measure a representative optimization step Inside your existing training program, surround a representative step with a peak-memory measurement. The example assumes model, batch and optimizer have already been initialized on the GPU. Include the optimizer step because some state is created lazily. Code example: torch.cuda.reset_peak_memory_stats() optimizer.zero_grad(set_to_none=True) loss = model(**batch).loss loss.backward() optimizer.step() torch.cuda.synchronize() peak_gib = torch.cuda.max_memory_allocated() / 2**30 print(f"Peak tensor memory: {peak_gib:.2f} GiB") This reports peak tensor allocation, not the complete device footprint. Also inspect reserved memory, runtime overhead and the system’s device-memory report. ### Choose DDP or sharding for the right reason DistributedDataParallel keeps a model replica on each process and synchronizes gradients. It is useful when the full training state fits on each GPU and you want to process more data in parallel; it does not merge VRAM into one contiguous pool. Fully Sharded Data Parallel can distribute parameters, gradients and optimizer state. Use it when memory pressure justifies sharding, and account for extra communication and distributed-checkpoint complexity. Mixed precision and activation checkpointing are separate choices. Validate numerical behavior for lower precision; measure the compute cost of recomputing activations when checkpointing saves memory. ### Launch a single-node pilot The training script must initialize distributed execution and assign one process to each GPU using the local-rank information. Match the process count to the visible GPUs. The following is a launch example for a distributed-aware script, not a complete training implementation. Code example: torchrun --standalone --nproc-per-node=4 \ train.py --config configs/pilot.yaml Run this only on a provisioned node. The local AnchorGPU demo does not execute training or allocate remote GPUs. ### Select hardware from the pilot result Use A100 as a lower-priced 80 GB CUDA baseline, and test H100 if the workload has a useful Hopper-specific path. H200 offers a larger CUDA memory configuration. MI300X offers more per-accelerator capacity in this catalog, provided the full application is qualified on ROCm. For AMD, check custom extensions, kernels, package versions and the ROCm-tested PyTorch image as a complete set. Framework-level compatibility does not validate every optional operation. ### Test restore, not just save Record model, optimizer, scheduler, training step, configuration and mixed-precision scaler state where relevant. Save a checkpoint, terminate the process, then restore and resume before committing to the long run. Use a checkpoint method appropriate to distributed state. Test that the saved artifacts can be read independently of the original process, and that the evaluation output remains within the expected tolerance. ### Budget for the whole pipeline Include downloads, preprocessing, data loading, validation, checkpointing, export and copying outputs off the node. Measure throughput together with memory, data-loading stalls, communication time, checkpoint duration and validation quality. A 7-day term is useful for a bounded compatibility and profiling pass. Choose a 30-day reservation only after you can estimate the useful work and the operational buffer. More GPUs help only when additional computation outweighs communication and input-pipeline limits. ### Sources - PyTorch distributed overview: https://docs.pytorch.org/tutorials/beginner/dist_overview.html [official-documentation] - PyTorch peak allocated memory: https://docs.pytorch.org/docs/stable/generated/torch.cuda.max_memory_allocated.html [official-documentation] - PyTorch torchrun: https://docs.pytorch.org/docs/stable/elastic/run [official-documentation] - PyTorch activation checkpointing: https://docs.pytorch.org/docs/stable/checkpoint.html [official-documentation] - PyTorch Distributed Checkpoint: https://docs.pytorch.org/tutorials/recipes/distributed_checkpoint_recipe.html [official-documentation] - PyTorch on ROCm: https://rocm.docs.amd.com/projects/install-on-linux/en/docs-6.4.0/install/3rd-party/pytorch-install.html [official-documentation] - Product implementation notes · Prove one complete step before scaling: https://anchorgpu.com/docs/pytorch-fine-tuning#pilot [product-documentation] - Product implementation notes · Measure a representative optimization step: https://anchorgpu.com/docs/pytorch-fine-tuning#memory [product-documentation] - Product implementation notes · Choose DDP or sharding for the right reason: https://anchorgpu.com/docs/pytorch-fine-tuning#parallelism [product-documentation] - Product implementation notes · Launch a single-node pilot: https://anchorgpu.com/docs/pytorch-fine-tuning#launch [product-documentation] - Product implementation notes · Select hardware from the pilot result: https://anchorgpu.com/docs/pytorch-fine-tuning#hardware [product-documentation] - Product implementation notes · Test restore, not just save: https://anchorgpu.com/docs/pytorch-fine-tuning#checkpoint [product-documentation] - Product implementation notes · Budget for the whole pipeline: https://anchorgpu.com/docs/pytorch-fine-tuning#term [product-documentation] --- ## How much GPU VRAM do you actually need? Canonical: https://anchorgpu.com/blog/how-much-vram-do-you-need Updated: 2026-09-04 A practical memory budget for inference, fine-tuning, image generation, and video workloads—from 24 GB to 192 GB. ### Quick answer How much GPU memory does a workload actually need? Budget model weights, runtime workspaces and the workload’s peak working memory. Inference adds a KV cache; training adds gradients, optimizer state and saved activations. Measure the complete request or training step at the intended context, batch and concurrency before choosing a card. - A parameter count is not a complete memory requirement. - Multiple GPUs do not automatically create one contiguous memory pool. - Quantization, offload and sharding need workload-specific validation. Workload guidance, not an AnchorGPU benchmark or capacity guarantee. Validate the actual model, software and hardware configuration. ### VRAM is a budget, not a model label GPU memory is consumed by several independent categories: model weights, inference KV cache, temporary activations, framework workspaces, allocator cache, and—during training—gradients and optimizer state. A model fitting in one configuration does not prove that it will fit with a longer context, larger batch, different precision, or more concurrent requests. Plan from the exact model revision and runtime configuration. Labels such as 7B, 13B, or 70B describe parameter scale, not total operating memory, so they should never be mapped to a GPU universally. ### Estimate raw weights first As an explicitly hypothetical example, suppose a model has exactly 13 billion parameters and stores every parameter in a 16-bit format. Raw weight storage is 13,000,000,000 × 2 bytes = 26,000,000,000 bytes, or about 24.2 GiB. That number excludes every other allocation, so it is a lower bound rather than a GPU recommendation. Quantization can reduce weight storage, but real footprints also include scales, metadata, dequantization buffers, duplicated tensors, and runtime workspaces. Use the format produced by the actual loader rather than dividing parameter count by a nominal bit width and treating the result as final. ### Inference adds KV cache and working memory Autoregressive serving retains key and value tensors for active sequences. KV-cache demand depends on model architecture, cache precision, concurrent sequences, and the number of live tokens across those sequences. Raising maximum context or concurrency can exhaust memory even when the weights load successfully. Temporary activations, attention workspaces, compiled kernels, communication buffers, and the framework allocator consume additional memory. vLLM reports its available GPU KV-cache capacity and an estimated concurrency for the configured sequence length; treat those startup figures as planning evidence, then replay representative prompts before committing a production workload. ### Training has a different memory shape Fine-tuning adds gradients, optimizer state, saved activations, and sometimes additional full-precision copies. Their exact size depends on the optimizer, precision policy, trainable parameter set, and sharding strategy, so a single inference multiplier is misleading. DistributedDataParallel replicates the training state needed by each worker; it does not turn several GPUs into one contiguous memory pool. Fully Sharded Data Parallel can shard parameters, gradients, and optimizer states across workers, while activation checkpointing reduces saved-activation memory by recomputing selected work during backward. Both techniques exchange simplicity or compute for memory. ### Measure the configuration you will run Test model loading and a complete representative inference request or training step, including optimizer update, with the exact framework, precision, context, batch, and parallelism settings. Record peak allocated and reserved memory, then repeat with realistic concurrency or gradient accumulation. Leave operating headroom instead of targeting the last available byte. Choose a larger-memory GPU when the measured peak cannot be reduced safely. Add GPUs only when the software explicitly shards the model or workload and the delivered interconnect is known. Re-run the measurement after any model, runtime, quantization, context, or batch change. ### Sources - vLLM — parallelism and scaling: https://docs.vllm.ai/en/latest/serving/parallelism_scaling/ [official-documentation] - PyTorch — FullyShardedDataParallel: https://docs.pytorch.org/docs/stable/fsdp.html [official-documentation] - PyTorch — activation checkpointing: https://docs.pytorch.org/docs/stable/checkpoint.html [official-documentation] --- ## Best GPU for fine-tuning: A100, H100, H200, or MI300X? Canonical: https://anchorgpu.com/blog/best-gpu-for-fine-tuning Updated: 2026-09-04 Choose by memory pressure, software stack, interconnect needs, and the value of finishing sooner—not headline throughput alone. ### Quick answer Which GPU should I choose for fine-tuning? Start with the smallest tested configuration that completes the full forward, backward and optimizer step. This modeled catalog lists A100 and H100 at 80 GB, H200 at 141 GB and MI300X at 192 GB. Compare software compatibility, measured training output and complete fixed-term cost, not theoretical speed alone. - Qualify the optimizer, precision, batch and sequence length together. - Test CUDA or ROCm dependencies before reserving a term. - Prove checkpoint restore before scaling the run. Workload guidance, not an AnchorGPU benchmark or capacity guarantee. Validate the actual model, software and hardware configuration. ### Define the run before the card There is no universal best fine-tuning GPU. Record the model revision, trainable parameter count, optimizer, precision, maximum sequence length, micro-batch size and validation schedule. A LoRA adapter run and a full-parameter run on the same model have different memory requirements. Choose the smallest tested configuration that completes the full training step with useful headroom. A parameter count multiplied by weight precision is only a lower bound: gradients, optimizer state, activations, temporary buffers and the framework also consume memory. ### Start with a representative single-GPU pilot Run warm-up iterations followed by forward, backward and optimizer steps on your actual longest batches. Record peak allocated tensor memory and inspect total device use; the PyTorch allocator statistic does not include every allocation made by other libraries. Measure step-time variation, data-loading stalls, validation duration and checkpoint writes. Save the framework, driver, model and data revisions with these results. One successful forward pass does not validate a training configuration. ### A100, H100, H200 or MI300X? The catalog A100 SXM and H100 SXM both have 80 GB per accelerator. A100 is a lower catalog-cost CUDA baseline. H100 is worth testing when your actual kernels and numerical format exploit its capabilities; architecture alone is not a speed guarantee. H200 offers 141 GB and MI300X offers 192 GB per accelerator. Those larger capacities can simplify a memory-constrained workload, but the AMD choice also needs a validated ROCm build, supported operators and compatible dependencies. Confirm the exact installed accelerator and stack, not just its product name. ### Pick the right form of parallel training DistributedDataParallel replicates the model across processes and synchronizes gradients; it does not turn four cards into one large memory pool. Fully Sharded Data Parallel partitions training state and introduces communication. The right choice depends on whether you need throughput, more memory, or both. Before scaling, confirm GPU topology, process binding and the collective communication library. Compare useful throughput against the single-GPU baseline at equivalent effective batch size and quality settings. Four accelerators are not automatically four times faster. ### Checkpoint recovery is part of the benchmark A successful save is not evidence of a recoverable run. Restore into a fresh process and check the model, optimizer, schedule, random state and data position required for your experiment. Include loading, validation, checkpoint upload and export in the rental window. Local NVMe is a working disk, not an independent backup. Move the required artifacts off the machine before the allocation ends. ### Make the fixed-term decision Use the live catalog table for the selected card count and term, then add required options. Divide the complete test cost by successful training output, not by a theoretical peak throughput number. Our recommendation is a staged pilot: establish a working memory budget, test one scaling step, prove restoration and then reserve the term. AnchorGPU currently models allocation and billing locally; no performance measurement of its physical infrastructure is claimed. ### Sources - PyTorch — distributed training overview: https://docs.pytorch.org/tutorials/beginner/dist_overview.html [official-documentation] - PyTorch — peak tensor memory: https://docs.pytorch.org/docs/stable/generated/torch.cuda.max_memory_allocated.html [official-documentation] - AMD — PyTorch on ROCm: https://rocm.docs.amd.com/en/docs-6.4.0/compatibility/ml-compatibility/pytorch-compatibility.html [official-documentation] - NVIDIA — H200 memory specifications: https://www.nvidia.com/en-us/data-center/h200/ [official-documentation] - Modeled memory capacities in the catalog: https://anchorgpu.com/reference#catalog [catalog-model] --- ## Choosing a GPU for LLM inference in production Canonical: https://anchorgpu.com/blog/gpu-for-llm-inference Updated: 2026-09-04 How model size, quantization, context, batching, and latency targets change the best GPU—and the real cost per request. ### Quick answer How should I choose a GPU for LLM inference? Choose from a tested serving target: model revision, quantization, prompt length, output length, concurrency and latency. Include KV-cache memory and runtime overhead. Compare replicas with model sharding on the actual node topology, then calculate cost from successfully served output and the complete rental term. - Model loading alone is not a capacity test. - Report latency, throughput and failures together. - Idle time remains part of a fixed-term rental’s cost. Workload guidance, not an AnchorGPU benchmark or capacity guarantee. Validate the actual model, software and hardware configuration. ### Specify the serving contract Separate interactive serving from offline batch work. Define maximum prompt length, typical and maximum output length, target concurrency, time to first token, inter-token latency and error tolerance. A single short request is not a capacity test. Keep the model and tokenizer revisions, quantization format, chat template and decoding settings fixed when comparing hardware. Otherwise a faster result may come from a different workload or a quality tradeoff rather than the GPU. ### Budget more than the model weights Inference needs model weights, runtime buffers, activations and usually a KV cache for active sequences. More simultaneous sequences and longer contexts change the required memory. Quantization support and its effect on output quality need validation on the chosen runtime. A 24 GB or 48 GB card is a candidate for a model that fits, not a promise that every model in a parameter-size class will run. Test the actual model and context limit. Larger-memory accelerators are useful when they reduce partitioning or provide measured concurrency headroom. ### Replicas or a distributed model? If the model fits on one GPU, independent replicas may be a straightforward way to serve more requests. Tensor parallelism distributes parts of the model and introduces communication between accelerators. Pipeline parallelism has different placement and utilization tradeoffs. Check the current vLLM guidance and the delivered machine topology before choosing a card count. Do not assume that SXM, PCIe, four cards or an aggregate VRAM number implies a particular connected fabric. ### Qualify the software stack before timing Confirm the driver, CUDA or ROCm build, GPU architecture support and availability of the operators your model needs. Container tags should be pinned and a fresh environment should reproduce the same serving result. Bind a first test to loopback, use an API key and do not expose an unauthenticated model endpoint. Remote access, TLS, ingress controls and service monitoring require an explicit deployment configuration; they are not created by selecting a catalog image. ### Measure realistic traffic Warm the server and separate model-loading time from steady-state results. Replay a representative mixture of prompt lengths, output lengths and concurrent requests. Report accepted request throughput, p95 latency, errors and memory use together. Increase traffic until the latency or reliability target stops being met, then leave capacity margin. Keep cold-start and recovery tests separate: operational readiness includes restoring service after a process or node failure. ### Compare the cost of useful output For a measured interval, divide the complete allocation cost attributable to that interval by successfully delivered output. If reporting cost per million tokens, say whether input and output tokens are included and use the same convention for every candidate. A fixed 7- or 30-day rental is paid for the whole term, including idle time. Project utilization explicitly and include options before comparing configurations. AnchorGPU catalog prices are modeled inputs; no live serving benchmark or production availability is asserted here. ### Sources - vLLM — quickstart and serving: https://docs.vllm.ai/en/latest/getting_started/quickstart/ [official-documentation] - vLLM — distributed serving and parallelism: https://docs.vllm.ai/en/latest/serving/parallelism_scaling/ [official-documentation] - vLLM — GPU installation requirements: https://docs.vllm.ai/en/latest/getting_started/installation/gpu/ [official-documentation] --- ## Which GPU should you rent for AI video? Canonical: https://anchorgpu.com/blog/gpu-for-ai-video Updated: 2026-09-04 A workflow-first guide to VRAM, render duration, codecs, storage, and choosing between RTX, L40S, and datacenter GPUs. ### Quick answer What determines the GPU needed for AI video? The complete pipeline determines capacity: model and precision, resolution, generated frame count, conditioning inputs, denoising and VAE decoding. Measure both device memory and end-to-end time on a representative clip. Offload or chunking can reduce a memory peak but may increase time or affect output quality. - Generated frame count is different from export FPS. - The denoiser and VAE can peak at different stages. - Check codec support on the exact GPU and software version. Workload guidance, not an AnchorGPU benchmark or capacity guarantee. Validate the actual model, software and hardware configuration. ### Choose from the pipeline, not a model-name tier Start by recording the exact pipeline: text-to-video, image-to-video, or video-to-video; checkpoint and precision; target width and height; generated frame count; batch size; denoising steps; conditioning inputs; and whether the job includes upscaling or interpolation. Video memory is not determined by parameter count alone. Model weights, attention and temporal activations, latent tensors, and VAE decoding contribute at different stages. Use the pipeline’s supported dimensions and frame range as constraints. A GPU that loads the checkpoint may still fail on the intended clip, so capacity planning should reproduce the production request rather than a minimal sample. ### Frame count and resolution shape the working set Diffusers notes for Stable Video Diffusion that frames are generated together, resembling a large image batch. More frames and more pixels generally expand intermediate tensors, but the exact curve depends on the architecture and implementation. Frames per second is not a substitute for generated-frame count: export FPS controls playback timing, while num_frames controls how many frames the model creates. Profile at the real aspect ratio and duration. If a model requires windowed generation or clip stitching, evaluate temporal consistency at boundaries as well as whether the run fits. ### Offload and chunking exchange memory for time Model CPU offload keeps inactive pipeline components in host memory and moves them onto the accelerator when needed. Sequential offload works at a finer level and can save more device memory, but repeated transfers can be much slower. Forward chunking reduces the amount of feed-forward work performed at once. These are different levers, and none creates free capacity. Record peak device memory and end-to-end time with each configuration. Watch host-memory pressure and transfer behavior instead of assuming a fixed system-RAM requirement; checkpoint format, dtype, pipeline design, and offload strategy all change it. ### Separate denoising from VAE decoding The VAE turns latents into viewable frames and can create its own memory peak. In Stable Video Diffusion, decode_chunk_size controls how many frames the VAE decodes together; smaller chunks reduce peak memory, while very small chunks can affect temporal consistency. Generic Diffusers VAE slicing works across batch items, whereas VAE tiling divides large frames into overlapping spatial tiles and can introduce tile-to-tile tone variation. Check that the chosen VAE supports the optimization, then compare output quality as well as memory. Solving the decode peak does not necessarily solve the denoiser’s peak. ### Include decoding, encoding, and delivery If the workflow ingests footage or exports many variants, codec hardware matters alongside AI compute. NVIDIA documents NVENC as a dedicated encoder independent of CUDA cores, with encoding and decoding able to run alongside CUDA processing in supported workflows. Codec and feature support varies by GPU generation, driver, and SDK, so verify the exact card rather than inferring support from the brand alone. Before renting, run one representative sample and log software versions, conditioning inputs, seed, dimensions, frame count, steps, offload settings, VAE chunking, wall time, peak VRAM, and export codec. Choose the smallest configuration that completes that test with practical headroom, then scale only when repeat runs demonstrate a real throughput need. ### Sources - Hugging Face Diffusers — Stable Video Diffusion: https://huggingface.co/docs/diffusers/main/api/pipelines/stable_diffusion/svd [official-documentation] - Hugging Face Diffusers — reduce memory usage: https://huggingface.co/docs/diffusers/main/optimization/memory [official-documentation] - NVIDIA Video Codec SDK 13.1 — NVENC application note: https://docs.nvidia.com/video-technologies/video-codec-sdk/13.1/nvenc-application-note/index.html [official-documentation] --- ## GPU rental vs buying: a 30-day cost framework Canonical: https://anchorgpu.com/blog/renting-vs-buying-gpus Updated: 2026-09-04 Compare useful capacity, financing, power, cooling, downtime, and resale value—not just the card price against one month of rent. ### Quick answer When does GPU rental make more sense than buying? Compare equivalent useful capacity over the same workload horizon. Ownership includes the complete host, running costs, operator time and uncertain resale value. Rental includes the whole fixed term and selected options, including idle time. Test lower utilization and a repair scenario before choosing; neither option is always cheaper. - A bare-card price is not comparable to a complete rented node. - Use measured whole-system electricity consumption. - Cost examples in this guide are hypothetical, not binding offers. Workload guidance, not an AnchorGPU benchmark or capacity guarantee. Validate the actual model, software and hardware configuration. ### Compare equivalent useful capacity A purchase price and one month of GPU rental are not comparable on their own. Start with a configuration that meets the same memory, software, throughput and reliability requirements in both cases. Include the host CPU, RAM, storage, network and any required interconnect rather than comparing a bare accelerator with a complete rented node. Choose one analysis horizon and one workload forecast. For a temporary experiment, the relevant question may be how much cash is committed before the result is known. For a recurring service, include idle periods, maintenance and the operational work needed to keep the machine useful. ### Build the ownership cost from explicit inputs Record the complete acquisition cost, delivery and installation, expected resale proceeds, electricity, facilities, maintenance, licenses and operator time. Include financing or other overhead only where it actually applies. Label estimates and get real quotes before making a purchase decision. A simple planning allocation is (acquisition cost minus estimated resale value) divided by the number of months used, plus monthly running costs. This is a comparison model, not an accounting depreciation schedule or a prediction of resale value. Test the result with zero resale value as a downside case. ### Use measured electricity, not a board label Energy in kilowatthours is average power in kilowatts multiplied by hours. As a hypothetical example, a complete system averaging 0.8 kW over a 30-day, 720-hour period uses 576 kWh. Multiply that by your own electricity rate and include any separately measured cooling or facility overhead. Manufacturer maximum thermal design power is a board design specification, not a measured average for the entire host. NVIDIA publishes different A100 power limits by form factor; neither value includes your complete installation. Obtain representative wall-power measurements at load and idle if electricity materially affects the decision. ### Include idle time in both options A fixed-term rental is charged for the selected 7 or 30 days, even when the workload is stopped. Add the chosen storage, networking and other options to the catalog GPU total. If the job finishes early, unused time remains part of its cost. For ownership, calculate cost per useful workload hour rather than assuming continuous utilization. For example, a hypothetical $600 monthly all-in cost is $2 per useful hour at 300 hours, but $10 at 60 hours. These are arithmetic examples, not current hardware prices or an hourly AnchorGPU offer. ### Stress-test the decision before committing Recalculate with fewer useful hours, a longer run, one repair and a lower resale value. Include time spent acquiring, configuring and restoring equipment, and check whether the comparison still meets the same output-quality and delivery target. Our recommendation is to test the workload first and then compare the complete, quoted options over the intended horizon. Rental can suit uncertain or short-lived demand; ownership may suit a stable, sustained workload when facilities and operating capacity are available. The AnchorGPU used listings and rental catalog remain modeled inputs, not verified offers or a guarantee that either option is cheaper. ### Sources - EIA — kilowatts and kilowatthours: https://www.eia.gov/tools/glossary/index.php?id=Electric [official-documentation] - NVIDIA — A100 board specifications and maximum TDP: https://www.nvidia.com/en-us/data-center/a100/ [official-documentation]