# Retrivium — English index

> Retrivium develops GPU infrastructure for LLM inference across Europe, CIS and Asia. Our GPU pool is being integrated with OpenRouter as an inference provider.

Language: en
Updated: 2026-11-03
Canonical site: https://retrivium.ai/
Default language: English

## Project

Retrivium develops GPU infrastructure for LLM inference, with a distributed network focus across Europe, the CIS and Asia.

Retrivium grew out of several startups working with LLMs. We brought that experience together around one focus: resilient, distributed infrastructure for language-model workloads.

We operate our own compute capacity in an established data center. It is the foundation for expanding the network with additional sites and professional hardware.

Our technical expertise and collaborations have earned the trust of interested partners with substantial capital and compute resources.

Our role is to operate the GPU infrastructure and serve language models as an inference provider. OpenRouter supplies the model access and routing layer for applications.

We are currently working to connect our GPU pool to OpenRouter as an inference provider. Integration is in progress; a live provider listing has not been announced.

The infrastructure concept spans data centers, smaller office deployments and professional workstations with GPUs offering at least 16 GB of VRAM. Model fit depends on the complete configuration and operating conditions.

This is an informational website about Retrivium, its infrastructure, current OpenRouter provider integration and LLM engineering. It does not collect equipment or funding applications and has no contact forms, registration, payments or public API-key signup.

Team: Alexander Golubev — technology and infrastructure; Igor Komarov — business and partnerships.

## Main pages

- [Home](https://retrivium.ai/)
- [Infrastructure](https://retrivium.ai/infrastructure/)
- [OpenRouter integration](https://retrivium.ai/openrouter/)
- [Field notes](https://retrivium.ai/journal/)
- [AI retrospectives](https://retrivium.ai/retrospectives/)
- [Privacy](https://retrivium.ai/privacy/)
- [Terms of Service](https://retrivium.ai/terms/)
- [Sitemap](https://retrivium.ai/sitemap/)

## English articles (970)

- [How to rent out your GPU for LLM inference](https://retrivium.ai/journal/rent-gpu.md): What GPU owners need before joining an LLM inference pool: hardware specifications, hosting conditions, a technical pilot and questions to settle before operation.
- [What to do with GPU servers after a grant-funded project](https://retrivium.ai/journal/grant-hardware.md): How to assess idle grant-funded hardware: verify ownership and restrictions, protect research workloads and prepare a technical LLM inference scenario.
- [GPU inference economics: what to calculate before joining a pool](https://retrivium.ai/journal/inference-economics.md): Understand the operating costs of language-model GPUs and why token prices, server utilization and the equipment owner’s revenue are different measures.
- [What is LLM inference, and why does it need your GPU?](https://retrivium.ai/journal/what-is-inference.md): A plain-language guide for hardware owners to LLM inference: how models handle requests, what tokens are and which part of the service a GPU provides.
- [What hardware is suitable for an LLM inference pool?](https://retrivium.ai/journal/gpu-requirements.md): Five areas to assess in a GPU server: video memory, software compatibility, host resources, hosting conditions and predictable availability.
- [VRAM for LLMs: why model size is only part of the calculation](https://retrivium.ai/journal/vram-and-models.md): How to estimate video memory for a language model: weights, KV cache, working buffers, context length and headroom for concurrent GPU requests.
- [Can NVIDIA RTX cards be used for LLM inference?](https://retrivium.ai/journal/rtx-for-inference.md): What RTX workstation owners should check before offering inference capacity: memory, sustained load, site conditions and maintenance access.
- [How to prepare a GPU server for a technical pilot](https://retrivium.ai/journal/server-preparation.md): A practical preparation sequence for an LLM inference pilot: inventory, backups, agreed access, a test environment and restoration of the original setup.
- [How a GPU pool connects to OpenRouter](https://retrivium.ai/journal/openrouter-provider.md): OpenRouter’s role in selling LLM inference, the difference between a hardware owner and an API provider, and the onboarding stages and demand limitations.
- [How laboratories can assess spare GPU capacity](https://retrivium.ai/journal/lab-idle-capacity.md): A practical way to describe underused laboratory servers: workload schedules, reserves, operating costs and boundaries for external use.
- [Grant-funded equipment: a checklist before external workloads](https://retrivium.ai/journal/grant-checklist.md): Questions for equipment owners and grant coordinators before connecting GPUs to an external service: authority, approvals, access, costs and usage accounting.
- [LLM inference versus training: what GPU owners should know](https://retrivium.ai/journal/inference-vs-training.md): How language-model operations differ from training and fine-tuning: workload profiles, memory, scheduling and service requirements for GPU owners.
- [Multiple GPUs in a pool: one service or one large model?](https://retrivium.ai/journal/multi-gpu.md): Why a distributed GPU pool is not one graphics card: independent replicas, model distribution, memory limits and the role of connections between nodes.
- [GPU networking and availability: beyond internet speed](https://retrivium.ai/journal/network-and-uptime.md): How to assess an LLM inference server connection: network stability, latency, recovery after interruptions, operating schedules and responsibility boundaries.
- [Equipment security when joining a GPU pool](https://retrivium.ai/journal/hardware-security.md): Access boundaries GPU owners should discuss with operators: separate environments, permissions, data, logs, updates and revocation after a pilot.
- [Power and cooling: the overlooked conditions of GPU operation](https://retrivium.ai/journal/power-and-cooling.md): What sustained GPU server operation requires: measured whole-machine consumption, room cooling, site limitations and responsibility for maintenance.
- [GPU inference pilot: what to check before an operating agreement](https://retrivium.ai/journal/pilot-checklist.md): A technical pilot plan for GPU owners and operators: objectives, model, request profile, success criteria, expenses, recovery and the final decision.
- [Choosing an LLM for your server: start with its model and terms](https://retrivium.ai/journal/model-licenses.md): How to prepare a language-model choice for external inference: version, model card, license, compatibility, quality checks and change tracking.
- [What should a report on your GPU’s operation contain?](https://retrivium.ai/journal/capacity-reporting.md): Metrics equipment owners should agree with operators: node availability, successful requests, tokens, expenses, interruptions and payment reconciliation.
- [GPU rental or revenue sharing: which terms should you discuss?](https://retrivium.ai/journal/revenue-share.md): How fixed GPU rental, availability payments and inference revenue sharing differ, with questions about costs, demand risk, reporting and ending cooperation.
- [Mining rigs for LLMs: which components can be reused?](https://retrivium.ai/journal/mining-gpus-for-inference.md): How owners of former mining rigs can assess LLM inference: check GPUs, host hardware, cooling and a pilot scenario before buying a replacement fleet.
- [Idle render farms: assessing a second GPU workload](https://retrivium.ai/journal/render-farm-idle-gpus.md): How studios can evaluate LLM inference on underused render farms while separating schedules, resources, environments and obligations to their own projects.
- [Workstation GPUs at night: when scheduled operation makes sense](https://retrivium.ai/journal/studio-workstations-night.md): How to offer a studio workstation GPU outside working hours: assess the available window, model startup, workload shutdown and readiness for the next workday.
- [Spare game-studio GPUs: separating resources for inference](https://retrivium.ai/journal/game-dev-gpu-capacity.md): How game studios can evaluate external GPU workloads without disrupting editors, testing or builds: select machines, schedules and production-restoration criteria.
- [GPU integrators and suppliers: offering a fleet for a pilot](https://retrivium.ai/journal/gpu-reseller-partnership.md): How server suppliers and GPU integrators can start a technical partnership with an inference operator: configuration, demonstration nodes, test criteria and roles.
- [Keep your GPU on site or move it to a data center?](https://retrivium.ai/journal/colocation-vs-on-premise.md): How to compare GPU operation at your own site and in a data center: total costs, availability, maintenance, relocation and inference-service requirements.
- [Used GPUs: which checks are needed before a pilot?](https://retrivium.ai/journal/used-gpu-health-check.md): How to prepare used GPUs for inference assessment: operating history, inventory, diagnostics, reproducible testing and a clear final equipment record.
- [Mixed GPU fleets: how to offer them to an inference operator](https://retrivium.ai/journal/mixed-gpu-fleet.md): How to describe a heterogeneous GPU fleet for LLM inference: group by memory and compatibility, distinguish independent nodes and onboard equipment gradually.
- [Reserve GPU servers: useful workloads without losing the reserve](https://retrivium.ai/journal/reserve-gpu-capacity.md): How reserve GPU server owners can assess external work: define the reserve’s purpose, return time, internal-work priority and a tested switching procedure.
- [Joining a GPU pool: the decisions at each stage](https://retrivium.ai/journal/gpu-pool-onboarding.md): An equipment owner’s roadmap from first message to GPU operation: resource specifications, technical assessment, pilot, commercial terms and production onboarding.
- [GPUs free for a few months: offering temporary capacity](https://retrivium.ai/journal/seasonal-gpu-capacity.md): How owners of temporarily idle GPUs can assess a limited operating period: start and return dates, preparation, useful time, costs and extension decisions.
- [Who can reach your GPU server? Physical support for remote nodes](https://retrivium.ai/journal/remote-hands-gpu.md): How to agree on remote-site GPU maintenance: contacts, allowed actions, diagnostics, spare components, work confirmation and costs.
- [I have one GPU: how do I start an onboarding conversation?](https://retrivium.ai/journal/single-gpu-owner.md): A first-contact guide for single-GPU owners: important specifications, what can remain unknown and how to test inference without expanding your hardware.
- [Finding spare GPUs inside a company and preparing a proposal](https://retrivium.ai/journal/corporate-gpu-inventory.md): How to inventory a company GPU fleet in practice: ownership, purpose, actual availability, restrictions and selecting hardware for an inference pilot.
- [Returning your GPU to your own work after leaving a pool](https://retrivium.ai/journal/gpu-exit-plan.md): What GPU owners should agree before cooperation ends: notice, workload removal, environment restoration, access revocation, files and final reconciliation.
- [Prefill and decode: the work your GPU performs during inference](https://retrivium.ai/journal/llm-prefill-decode.md): Why long-input processing and response generation stress a server differently, and how GPU owners can choose a useful technical-pilot workload.
- [Continuous batching: why concurrent requests change GPU value](https://retrivium.ai/journal/continuous-batching.md): How to test shared LLM request execution on a server, and why equipment owners need queue, quality and latency measures alongside GPU utilization.
- [Prefix caching: when repeated context helps a GPU pool](https://retrivium.ai/journal/prefix-caching.md): How to evaluate reuse of a shared LLM request prefix, and why selecting a GPU requires separate cold-cache and warm-cache tests.
- [Long-context LLMs: testing a server for document workloads](https://retrivium.ai/journal/long-context-capacity.md): How GPU owners can assess long-document serving: input profiles, quality checks, latency, mixed traffic and the model’s practical operating limits.
- [KV cache and GPU economics: accounting for active-request memory](https://retrivium.ai/journal/kv-cache-economics.md): How request memory affects useful GPU server capacity: context profiles, resource occupancy time, constraint costs and comparisons between configurations.
- [LLM quantization: checking quality before choosing a GPU](https://retrivium.ai/journal/quantization-quality.md): How to compare original and quantized models on a specific GPU: tasks, response formats, memory, speed and criteria for a technical decision.
- [A GPU inference benchmark you can trust](https://retrivium.ai/journal/inference-benchmark-method.md): How to build a reproducible GPU test protocol: versions, request profiles, warmup, multiple load levels and reporting for owners and infrastructure partners.
- [Throughput and latency: choosing a GPU operating point](https://retrivium.ai/journal/throughput-latency-tradeoff.md): Why maximum token output may not deliver the best user experience, and how to compare GPU server configurations through throughput and latency together.
- [Validating model demand before expanding a GPU pool](https://retrivium.ai/journal/model-demand-validation.md): How to separate model popularity from confirmed service demand: choose a task, interview users, test an endpoint, define quality and decide whether to expand.
- [Routing and fallback: which role could your GPU serve?](https://retrivium.ai/journal/inference-routing-fallback.md): How future GPU pools can distribute node requests, what to test during failures and why a reserve machine differs from a continuously loaded replica.
- [GPU monitoring without excess charts: five observation levels](https://retrivium.ai/journal/gpu-monitoring-scorecard.md): Signals GPU owners and inference operators need: device condition, resources, service readiness, useful results and actions when behavior changes.
- [Reproducible inference stacks: preserving a GPU pilot’s result](https://retrivium.ai/journal/software-stack-reproducibility.md): What to record in a GPU server environment to repeat technical checks: weights, driver, engine, launch settings, test inputs and rollback procedures.
- [Planning a GPU pool: when is the next server actually needed?](https://retrivium.ai/journal/inference-capacity-planning.md): How observations can guide LLM inference expansion: workload profiles, operating capacity, reserve, site limitations and criteria for the next investment.
- [Embeddings and rerankers: other tasks for an idle GPU](https://retrivium.ai/journal/embeddings-rerankers-gpu.md): Why useful AI workloads extend beyond text generation: testing embedding and reranking models on existing GPUs and choosing the right unit of useful output.
- [Updating an LLM on a GPU: testing a new version with a small rollout](https://retrivium.ai/journal/model-update-canary.md): How to change models without changing an entire pool at once: record versions, compare quality, limit the test and establish rollback in advance.
- [Funding a GPU pool: from an idea to a defined project](https://retrivium.ai/journal/fund-gpu-pool.md): What to discuss before financing GPUs and operations: use of funds, technical pilots, equipment ownership, reporting and decisions about pool expansion.
- [Working capital for LLM inference: what happens after buying GPUs?](https://retrivium.ai/journal/working-capital-inference.md): Why GPU pools need operating funding: payment schedules, model deployment, delayed receipts and an operational reserve for an agreed period.
- [How to assess a GPU pool project before funding it](https://retrivium.ai/journal/gpu-project-due-diligence.md): Evidence to request before financing GPUs: infrastructure specifications, a reproducible pilot, budget, sales-channel status and operational responsibility.
- [Milestone GPU funding: paying for the next verifiable step](https://retrivium.ai/journal/milestone-funding.md): How to divide GPU pool funding into preparation, pilot, procurement and operation, with defined outcomes, budgets and decisions at every stage.
- [Buying or renting GPUs: what to compare before funding](https://retrivium.ai/journal/gpu-purchase-vs-rental.md): How to compare buying and renting GPUs for one inference scenario: total expenses, task duration, flexibility, acceptance and project exit conditions.
- [Inference unit economics: choosing the unit a funding partner needs](https://retrivium.ai/journal/inference-unit-economics.md): Choose a useful unit for GPU-pool economics: successful requests, a million tokens or a service workload. Define costs and compare like periods.
- [GPU-pool budgeting: allocating funds between hardware and operations](https://retrivium.ai/journal/gpu-budget-allocation.md): Build a concrete GPU-project budget covering hardware, preparation, hosting, operations, shared tasks and contingency without universal spending ratios.
- [Reporting to a GPU-pool funding partner](https://retrivium.ai/journal/gpu-funding-reporting.md): What a GPU-funding report should cover: funds, equipment status, technical results, budget variances and the basis for subsequent spending decisions.
- [Risks to discuss before funding GPU inference](https://retrivium.ai/journal/gpu-funding-risks.md): Connect GPU-project risks with decisions: uncertain demand, technical fit, launch timing, operating expense and dependence on external distribution channels.
- [Procuring GPUs for a pool: specification and acceptance before scaling](https://retrivium.ai/journal/procurement-before-scale.md): Prepare GPU procurement from pilot results, a complete specification, delivery conditions, acceptance criteria and the budget for putting hardware to work.
- [Demand before GPUs: evidence to gather before purchasing](https://retrivium.ai/journal/gpu-demand-before-capex.md): Validate a GPU pool’s commercial hypothesis before expansion: user scenarios, service requirements, pilot measurements and evidence for the next funding stage.
- [Questions to ask a GPU-pool team at the first meeting](https://retrivium.ai/journal/financial-partner-questions.md): Questions for an initial GPU-funding conversation: current stage, purpose of funds, available resources, results, expenses, responsibility and next decisions.
- [Discussing future compute demand and capacity reservations](https://retrivium.ai/journal/compute-offtake.md): Use preliminary inference-demand discussions to plan GPUs: workload, resources, timing, payment and the distinction between interest and confirmed commitments.
- [The GPU asset lifecycle: planning beyond the purchase](https://retrivium.ai/journal/gpu-asset-lifecycle.md): Plan GPU acceptance, condition monitoring, maintenance, changing workloads and the end of participation in a compute pool as parts of one asset lifecycle.
- [Growing a GPU pool when additional machines are actually needed](https://retrivium.ai/journal/responsible-pool-growth.md): What justifies GPU-pool growth: a measured constraint, defined need, operating readiness and budget. Avoid treating the card count as the result.
- [Finding an operating budget for grant-funded GPUs after a project](https://retrivium.ai/journal/grant-gpu-operating-budget.md): A server is already purchased, but keeping it working needs funding. Prepare power, support and pilot expenses a laboratory can discuss with a partner.
- [Cloud credits or owned GPUs: what can be offered to an operator?](https://retrivium.ai/journal/grant-cloud-credits.md): Cloud credits and grant-funded servers are different resources. Describe the support, check programme restrictions and identify a permitted collaboration scenario.
- [Preparing a laboratory proposal for GPU cooperation](https://retrivium.ai/journal/research-gpu-partner-proposal.md): A short GPU-partnership proposal for management and a technical partner: available resources, pilot objective, constraints, expenses and verifiable results.
- [Funding a research compute window](https://retrivium.ai/journal/research-compute-sponsorship.md): Support a defined GPU research window by specifying the task, operating budget, responsible people and results a funding partner can verify.
- [Shared GPU resources: agreeing laboratory, operator and partner roles](https://retrivium.ai/journal/research-pool-governance.md): A responsibility matrix for a joint GPU pilot: equipment, funding, configuration changes, acceptance, technical stops and decisions to continue.
- [Runpod for LLMs: when to choose Pods or Serverless](https://retrivium.ai/journal/runpod-guide.md): Compare Runpod Pods and Serverless for model serving: environment control, storage, startup, worker billing and a reproducible first pilot.
- [AWS for LLM inference: evaluating GPUs in Amazon EC2](https://retrivium.ai/journal/aws-gpu-hosting-guide.md): Evaluate GPU EC2 instances by accelerator family, region, purchase option, related resources and the distinction between cloud rental and an owned GPU pool.
- [Hetzner for LLMs: evaluating a dedicated GPU server](https://retrivium.ai/journal/hetzner-hosting-guide.md): Evaluate Hetzner GEX GPU servers by node configuration, location, setup and recurring charges, self-managed operations and a model acceptance test.
- [Vast.ai GPUs: evaluating marketplace offers](https://retrivium.ai/journal/vast-ai-guide.md): Read Vast.ai inference offers by host configuration, rental type, storage and reproducibility, while keeping GPU renter and equipment-provider roles distinct.
- [Lambda Cloud: planning a GPU virtual-machine pilot](https://retrivium.ai/journal/lambda-cloud-guide.md): Evaluate Lambda Cloud On-Demand through VM configuration, region, resource lifecycle, storage and the complete budget for a repeatable language-model test.
- [CoreWeave inference: choose the management layer first](https://retrivium.ai/journal/coreweave-guide.md): Evaluate CoreWeave infrastructure and dedicated inference through team responsibilities, purchasing units, complete costs and the selected service-level test.
- [DigitalOcean and Paperspace: distinguish the GPU products](https://retrivium.ai/journal/digitalocean-paperspace-guide.md): Distinguish DigitalOcean GPU Droplets from Paperspace Machines, Notebooks and Deployments, including their billing catalogues and a first LLM pilot.
- [Google Cloud GPU: regions and quotas before model launch](https://retrivium.ai/journal/google-cloud-gpu-guide.md): Prepare a Compute Engine GPU pilot through compatible configuration, regional availability, quotas, software and the complete resource lifecycle.
- [Azure GPUs for LLMs: selecting a compute VM series](https://retrivium.ai/journal/azure-gpu-guide.md): Evaluate Azure GPU virtual machines by compute versus graphics series, region, software environment and the connected operating expenses of a language model.
- [OVHcloud GPUs: distinguishing cloud instances from other services](https://retrivium.ai/journal/ovhcloud-gpu-guide.md): Evaluate OVHcloud Public Cloud GPU through product, configuration, region, charging model and the boundary between infrastructure and managed AI services.
- [Scaleway GPUs: from a prepared image to a repeatable pilot](https://retrivium.ai/journal/scaleway-gpu-guide.md): Evaluate Scaleway GPU Instances by configuration, image, region, resource charges and a repeatable launch of your language model.
- [Nebius AI Cloud: planning growth from a VM to a GPU pool](https://retrivium.ai/journal/nebius-gpu-guide.md): Evaluate Nebius AI Cloud through VMs, cluster interconnects, capacity purchasing, storage and the separate validation needed to expand beyond a small test.
- [Fluidstack: evaluating large-scale AI infrastructure](https://retrivium.ai/journal/fluidstack-guide.md): Assess Fluidstack through its current infrastructure focus, project scale, customer responsibilities and commercial inquiry route rather than assuming single-VM rental.
- [Vultr Cloud GPU: checking plan, region and image](https://retrivium.ai/journal/vultr-gpu-guide.md): Evaluate Vultr Cloud GPU by plan, location, system image, network route, complete expenses and repeatable model deployment before scaling a workload.
- [Oracle Cloud GPUs: VMs and bare metal for an owned model](https://retrivium.ai/journal/oracle-cloud-gpu-guide.md): Evaluate OCI GPUs through VM and bare-metal configurations, accelerator software, region, host resources and validation before expanding capacity.
- [Crusoe Cloud: infrastructure or managed inference?](https://retrivium.ai/journal/crusoe-cloud-guide.md): Distinguish Crusoe Infrastructure Cloud and Managed AI: self-managed VMs and clusters, managed deployments, payment units and model responsibilities.
- [Latitude.sh for LLMs: evaluating Metal GPU](https://retrivium.ai/journal/latitude-sh-guide.md): Evaluate Latitude.sh Metal GPU through dedicated configuration, location, management, storage and the full deployment-to-completion workflow.
- [Hyperstack: GPU VM costs begin with the resource lifecycle](https://retrivium.ai/journal/hyperstack-guide.md): Evaluate Hyperstack GPU VMs by flavour, region, disks, instance states and billing, then measure the complete cost of a language-model test.
- [TensorDock: evaluating GPU VMs across a host network](https://retrivium.ai/journal/tensor-dock-guide.md): Evaluate TensorDock by specific host, configurable VM resources, complete charges and the separate responsibilities of customers and equipment owners.
- [CUDO Compute in 2026: current services and older instructions](https://retrivium.ai/journal/cudo-compute-guide.md): Understand CUDO Compute’s public on-demand closure, current enterprise infrastructure focus and the questions needed before planning an AI project.
- [Five GPU clouds for a first pilot: building a shortlist](https://retrivium.ai/journal/top-gpu-clouds-first-pilot.md): An editorial shortlist for a bounded LLM pilot: Runpod, Lambda, DigitalOcean, Hyperstack and AWS, with selection criteria and a matched-test plan.
- [Four providers for European GPU deployment](https://retrivium.ai/journal/top-european-infrastructure-providers.md): Investigate Hetzner, OVHcloud, Scaleway and Hyperstack for European GPU placement, checking official locations, resource formats, data routes and operations.
- [Dedicated GPUs for LLMs: four different purchasing formats](https://retrivium.ai/journal/top-dedicated-servers-llm.md): Compare Hetzner, Latitude.sh, Oracle Cloud and CoreWeave dedicated resources: physical servers, bare-metal configurations and dedicated model endpoints.
- [Four serverless approaches to GPU inference](https://retrivium.ai/journal/top-serverless-gpu-providers.md): Investigate Runpod, Vast.ai, Modal and Crusoe serverless workflows: owned code, workers, managed model APIs, cold starts and different charging units.
- [Runpod or Vast.ai: compare the task, not one price](https://retrivium.ai/journal/runpod-vs-vast-ai.md): Compare Runpod and Vast.ai through instance format, serverless, specific configurations, portability and the separate GPU-equipment-owner scenario.
- [AWS, Google Cloud or Azure: comparing GPUs for LLMs](https://retrivium.ai/journal/aws-vs-google-cloud-vs-azure-gpu.md): Compare AWS, Google Cloud and Azure for an owned model using GPU families, regions, access, connected services and a matched end-to-end application test.
- [Hetzner, OVHcloud and Scaleway: comparing GPU infrastructure](https://retrivium.ai/journal/hetzner-vs-ovhcloud-vs-scaleway.md): Compare Hetzner GEX, OVHcloud Public Cloud GPU and Scaleway GPU Instances by resource format, operations, period, region and one model’s requirements.
- [Specialist GPU cloud or hyperscaler: choosing the right product](https://retrivium.ai/journal/specialist-vs-hyperscaler-gpu.md): Compare Runpod and Nebius with AWS, Google Cloud and Azure through product focus, existing dependencies, control and an end-to-end application test.
- [Five providers for small GPU teams: choose by the work involved](https://retrivium.ai/journal/top-providers-small-gpu-teams.md): Investigate Runpod, Lambda, DigitalOcean, Hyperstack and Modal for small teams by maintenance duties, cost control and repeatable model launches.
- [A GPU-provider shortlist: a method for verifiable selection](https://retrivium.ai/journal/gpu-cloud-shortlist-method.md): Build a current GPU shortlist by verifying product, resource format, starting route, restrictions, complete estimates and matched pilot results.
- [CPU or GPU hosting: which resource does your AI task need?](https://retrivium.ai/journal/cpu-vs-gpu-hosting.md): Separate CPU and GPU tasks in AI hosting: data processing, retrieval, generation and measured constraints before renting or proposing equipment.
- [Memory-optimized hosting: when more system RAM is useful](https://retrivium.ai/journal/memory-optimized-hosting.md): Choose high-RAM hosting for databases, caches and data preparation while separating memory capacity from CPU performance and GPU device memory.
- [RAM and VRAM: which memory matters for an AI server?](https://retrivium.ai/journal/ram-vs-vram.md): Distinguish host system RAM from GPU device memory and document an AI server without incorrectly combining them into one memory-capacity figure.
- [Compute-optimized hosting: when the processor is the constraint](https://retrivium.ai/journal/compute-optimized-hosting.md): Evaluate intensive CPU hosting through working sets, threads, sustained load and comparisons with higher-RAM configurations before selecting equipment.
- [Storage-optimized hosting: when disks constrain an AI system](https://retrivium.ai/journal/storage-optimized-hosting.md): Select servers for intensive data access by checking local and remote storage, model loading, indexes and recovery rather than disk capacity alone.
- [Arm and x86 inference: comparing CPU architectures](https://retrivium.ai/journal/arm-vs-x86-inference.md): Test Arm and x86 on AI workloads through software compatibility, vCPU allocation, memory and application measurements rather than processor names.
- [GPU hosting, GPU servers and model APIs: what are you renting?](https://retrivium.ai/journal/gpu-hosting-vs-gpu-server.md): Distinguish GPU-machine rental, managed environments and model API access so responsibilities, costs and equipment offers describe the complete service.
- [When to test CPU LLM inference before buying a GPU](https://retrivium.ai/journal/cpu-llm-inference-use-cases.md): Explore bounded CPU-inference scenarios: low traffic, compatibility checks, background work and matched end-to-end comparison before accelerator procurement.
- [LLM memory bandwidth: why gigabytes are not enough](https://retrivium.ai/journal/memory-bandwidth-llm.md): Evaluate CPU and GPU memory through capacity, access speed and actual workloads rather than replacing model tests with advertised hardware specifications.
- [NVMe for model serving: where a faster disk changes results](https://retrivium.ai/journal/nvme-for-model-serving.md): Evaluate local NVMe through weight loading, artifact caches, updates and recovery, distinguishing storage speed from warm-model generation performance.
- [NUMA in GPU servers: why resource placement matters](https://retrivium.ai/journal/numa-and-gpu-servers.md): Describe CPU, RAM and GPU relationships in a multi-socket inference server, then test process placement reproducibly before replacing hardware.
- [PCIe and GPU hosting: when the connection limits a model](https://retrivium.ai/journal/gpu-pcie-bandwidth.md): Assess GPU connections to the host and other devices, separating loading, data transfers, distributed execution and the actual server topology.
- [Spot or on-demand GPUs: accounting for interruptions](https://retrivium.ai/journal/spot-vs-on-demand-gpu.md): Compare interruptible and ordinary GPU rental through recovery, repeated work, replacement availability and the cost of useful completed jobs.
- [Reserved GPUs and flexible capacity: what are you committing to?](https://retrivium.ai/journal/reserved-vs-flexible-capacity.md): Separate GPU availability from financial commitments, then compare duration, change rules, idle costs and a flexible pilot before reserving capacity.
- [Serverless GPUs or an always-ready replica: choosing an inference mode](https://retrivium.ai/journal/serverless-vs-always-on-inference.md): Compare on-demand startup with an always-ready model across cold starts, idle intervals, baseline capacity and the complete user experience.
- [A hybrid CPU/GPU architecture: splitting an AI service by task](https://retrivium.ai/journal/cpu-gpu-hybrid-architecture.md): Map application stages to CPU and GPU resources, then compare a single-machine service with a split deployment and its full operating cost.
- [A high-RAM RAG server: deciding what to keep in memory](https://retrivium.ai/journal/high-ram-rag-servers.md): Separate RAG retrieval and generation, size indexes and update peaks, then evaluate memory configurations against relevance and complete-response latency.
- [Vector-database memory: choosing RAM and storage for retrieval](https://retrivium.ai/journal/vector-database-memory-hosting.md): Size vector-database memory by vectors, indexes, payload, filters and operating state, then compare RAM, storage and indexing alternatives.
- [RAM for AI data preparation: avoiding paid-for idle memory](https://retrivium.ai/journal/ram-for-data-preprocessing.md): Measure data transformations, batch size, workers, streaming and temporary storage before choosing a larger-memory preprocessing server.
- [GPUs in Kubernetes: scheduling CPU, RAM and accelerators together](https://retrivium.ai/journal/kubernetes-gpu-scheduling.md): Assess Kubernetes GPU jobs using the complete node configuration, placement constraints, model readiness and heterogeneous hardware rather than card count.
- [GPU containers or virtual machines: what to check before deployment](https://retrivium.ai/journal/gpu-containers-vs-vms.md): Compare GPU containers and VMs through compatibility, device access, responsibilities, repeatable tests, updates and recovery before choosing a deployment.
- [MIG and time-slicing: sharing a GPU without confusing guarantees](https://retrivium.ai/journal/gpu-mig-vs-time-slicing.md): Distinguish MIG from time-slicing, then test workload profiles, neighboring effects, host resources and accounting for a shared GPU.
- [Serving LoRA adapters: estimating GPU-server capacity](https://retrivium.ai/journal/lora-serving-capacity.md): Estimate LoRA serving through the base model, adapter compatibility, switching, mixed traffic, memory and task-specific quality checks.
- [GPU hosting for multimodal models: count more than text](https://retrivium.ai/journal/multimodal-gpu-hosting.md): Evaluate a specific multimodal workload through supported inputs, preparation, file transfer, memory, service limits and useful output.
- [Hosting batch inference: using GPUs on a schedule](https://retrivium.ai/journal/batch-inference-hosting.md): Plan scheduled GPU batches through work-unit checks, availability windows, batch growth, restart behavior and cost per completed dataset.
- [GPU autoscaling: a free card is not a ready replica](https://retrivium.ai/journal/autoscaling-gpu-cold-start.md): Measure GPU autoscaling from allocation through weights, preparation and useful output, including queue behavior and a failed-start retry.
- [AI service network traffic: accounting for egress before GPU placement](https://retrivium.ai/journal/cloud-egress-model-serving.md): Map weights, user inputs, storage, responses, backups and updates before comparing GPU placement and complete operating costs.
- [CPU hosting for RAG: four options for a technical comparison](https://retrivium.ai/journal/top-cpu-hosting-rag.md): An editorial comparison of AWS C8i, Google C4, Azure Falsv7 and Hetzner CCX, with CPU semantics and a reproducible RAG pilot.
- [Memory-optimized hosting: four high-RAM options to compare](https://retrivium.ai/journal/top-memory-optimized-clouds.md): Compare AWS R8i, Google M4, Azure Esv7 and Azure Epsv6 through working-set requirements, CPU compatibility and complete operating costs.
- [LLM hosting architectures: five arrangements for different tasks](https://retrivium.ai/journal/top-hosting-architectures-llm.md): Compare five AI hosting arrangements by readiness, resource roles, data boundaries, failure handling and the unit of useful output.
- [OpenRouter: model access and its role for a GPU pool](https://retrivium.ai/journal/openrouter-platform-guide.md): Understand OpenRouter from the developer and inference-operator sides, separating API access, routing, accounting and provider onboarding.
- [OpenRouter provider routing: defining permitted routes](https://retrivium.ai/journal/openrouter-provider-routing.md): Define mandatory OpenRouter route conditions before preferences, then test provider selection, model fallbacks and complete-request outcomes.
- [Requesty: a managed LLM gateway for routing and team access](https://retrivium.ai/journal/requesty-guide.md): Evaluate Requesty with one model scenario, explicit fallback policies, BYOK ownership, usage reconciliation and a clear data-flow review.
- [Portkey and Prisma AIRS AI Gateway: functions and product boundaries](https://retrivium.ai/journal/portkey-ai-gateway-guide.md): Evaluate Portkey and Prisma AIRS AI Gateway through product naming, deployment edition, routing policies, telemetry and operating responsibilities.
- [LiteLLM Proxy: when to operate your own model gateway](https://retrivium.ai/journal/litellm-proxy-guide.md): Assess LiteLLM Proxy through request boundaries, virtual-key policies, routing, usage reconciliation and the operating cost of a self-hosted gateway.
- [Vercel AI Gateway: common model access for an application](https://retrivium.ai/journal/vercel-ai-gateway-guide.md): Evaluate Vercel AI Gateway through API compatibility, provider policy, BYOK, complete usage costs and the distinction between consuming and selling inference.
- [Cloudflare AI Gateway: routes, observability and unified billing](https://retrivium.ai/journal/cloudflare-ai-gateway-guide.md): Separate Cloudflare AI Gateway, Workers AI, external providers, BYOK and unified billing, then test current interfaces and complete costs.
- [Kong AI Gateway: LLM traffic within API infrastructure](https://retrivium.ai/journal/kong-ai-gateway-guide.md): Assess Kong AI Gateway through control and data planes, team policies, identity, edition-specific functions and operational recovery.
- [Helicone AI Gateway: routing with observability](https://retrivium.ai/journal/helicone-ai-gateway-guide.md): Evaluate Helicone as a gateway and observation layer, preserving actual routes, attempt timelines, metric sources and data-retention settings.
- [Amazon Bedrock: model access within AWS infrastructure](https://retrivium.ai/journal/bedrock-model-access-guide.md): Evaluate a specific Bedrock model, endpoint, region and application role, then compare complete task costs and operating requirements.
- [Vertex AI Model Garden: reading the current Google Cloud catalog](https://retrivium.ai/journal/vertex-ai-model-garden-guide.md): Read the current Model Garden documentation through exact model cards, managed and self-deployed paths, project restrictions and complete pilot costs.
- [Azure AI Foundry and Microsoft Foundry Models: choosing execution](https://retrivium.ai/journal/azure-ai-foundry-models-guide.md): Distinguish Foundry model categories, deployment modes, project access and complete costs while preserving the familiar Azure AI Foundry search name.
- [Together AI: serverless and dedicated inference for open models](https://retrivium.ai/journal/together-ai-platform-guide.md): Compare Together AI execution modes through workload goals, serverless traffic, model capabilities, useful output and complete operating scenarios.
- [Fireworks AI: comparing serverless and deployments](https://retrivium.ai/journal/fireworks-ai-platform-guide.md): Evaluate Fireworks execution modes with representative traffic, usage reconciliation, model quality and the lifecycle of a managed inference service.
- [Hugging Face Inference Providers: models, routes and billing](https://retrivium.ai/journal/hugging-face-inference-providers-guide.md): Separate Hub weights, Inference Providers and dedicated endpoints, then verify model tasks, actual executors, billing routes and full deployment costs.
- [Five managed LLM routing platforms: choosing by task](https://retrivium.ai/journal/top-managed-llm-routing-platforms.md): Compare five managed LLM-access options by client requirements, payment paths, routing, observability and the same bounded workload.
- [Four self-hosted AI gateways: LiteLLM, Portkey, Kong and Agent Router](https://retrivium.ai/journal/top-self-hosted-ai-gateways.md): Compare four self-hosted gateway options through exact editions, data paths, policies, operating actions and complete maintenance responsibilities.
- [OpenRouter or Requesty: comparing managed LLM access](https://retrivium.ai/journal/openrouter-vs-requesty.md): Compare OpenRouter and Requesty on the same task, explicit policies, BYOK, incident evidence and the separate process of selling owned inference.
- [OpenRouter and Portkey: catalog access or AI-traffic governance](https://retrivium.ai/journal/openrouter-vs-portkey.md): Compare OpenRouter and Portkey by intended role, deployment, private endpoints, policies, operating responsibility and inference-sales boundaries.
- [OpenRouter or LiteLLM: managed access and an owned gateway](https://retrivium.ai/journal/openrouter-vs-litellm.md): Compare OpenRouter and LiteLLM Proxy through control boundaries, complete costs, layered routing, incident work and recovery.
- [Vercel and Cloudflare AI Gateway: comparing managed gateways](https://retrivium.ai/journal/vercel-vs-cloudflare-ai-gateway.md): Compare Vercel and Cloudflare with the same application contract, allowed routes, payment path, incident work and complete costs.
- [Bedrock, Vertex Model Garden and Foundry: cloud approaches compared](https://retrivium.ai/journal/bedrock-vs-vertex-vs-foundry.md): Compare cloud model platforms through an equivalent task, exact execution mode, project access, full operating period and unresolved conditions.
- [Together, Fireworks and OpenRouter: comparing inference roles](https://retrivium.ai/journal/together-vs-fireworks-vs-openrouter.md): Separate inference execution from routing when comparing Together, Fireworks and OpenRouter on model capabilities, fallbacks and complete task costs.
- [BYOK or managed billing: who pays for the model request?](https://retrivium.ai/journal/byok-vs-managed-billing.md): Trace customer and managed credentials across billing sources, account limits, fallback, reconciliation and credential ownership.
- [Model routing and provider routing: two different decisions](https://retrivium.ai/journal/model-routing-vs-provider-routing.md): Separate changing the model from changing its executor, then test quality, route constraints, fallback histories and cost independently.
- [The full cost of an LLM router: beyond token prices](https://retrivium.ai/journal/token-router-total-cost.md): Calculate routing cost per useful result across inference, gateway features, storage, retries and the actual work needed to operate the integration.
- [Reconciling tokens and billing in an LLM router](https://retrivium.ai/journal/router-billing-token-accounting.md): Trace application tasks, attempts, usage fields and final charges, including streaming, credentials, cached input and late accounting adjustments.
- [Comparing LLM-router data policies](https://retrivium.ai/journal/router-data-policy-comparison.md): Map content, telemetry, providers, retention, fallback and geography separately when checking a router data policy and its actual configuration.
- [LLM-router fallback and limits: testing resilience](https://retrivium.ai/journal/router-failover-and-rate-limits.md): Test router resilience through total deadlines, compatible backup targets, error categories, traffic bursts, interrupted streams and recovery to normal behavior.
- [Choosing a token-sales channel for an owned GPU pool](https://retrivium.ai/journal/choosing-token-sales-channel.md): Evaluate seller onboarding separately from API consumption, then verify requirements, accounting, commercial readiness and actual demand before expanding GPUs.
- [Mapping a company’s idle GPUs for a new service](https://retrivium.ai/journal/idle-gpu-resource-map.md): Create a practical GPU availability map linking each machine to ownership, operating windows, constraints, costs and a dated next check.
- [GPU-node acceptance: evidence beyond an attractive benchmark](https://retrivium.ai/journal/gpu-acceptance-evidence.md): Document GPU acceptance through received configuration, diagnostics, service tests, workload conditions, recovery and clearly scoped decisions.
- [A GPU maintenance budget: planning beyond startup](https://retrivium.ai/journal/gpu-maintenance-budget.md): Build a maintenance budget from regular work, incident scenarios, monitoring, repair responsibilities, spending authority and spare-part ownership.
- [Providing a GPU or handing over operations: what the owner retains](https://retrivium.ai/journal/gpu-owner-managed-operation.md): Separate equipment authority, site services and software operation, then agree access, changes, incident duties and return of the machine.
- [A short GPU-partner brief: equipment, task and budget](https://retrivium.ai/journal/gpu-partner-brief-template.md): Prepare a concise GPU partnership brief covering the resource, desired decision, constraints, unknowns and evidence needed for the next stage.
- [Research data and an external GPU pilot: defining the boundary](https://retrivium.ai/journal/research-data-boundaries-gpu.md): Separate laboratory data from a GPU pilot through explicit directories, permissions, test datasets, logs, incident procedures and access termination.
- [A reference GPU-node configuration for a small pool](https://retrivium.ai/journal/gpu-reference-configuration.md): Document one reproducible GPU node through hardware, software, workload, metrics and meaningful deviations before evaluating additional servers.
- [Energy per LLM request: measuring without false precision](https://retrivium.ai/journal/measuring-energy-per-inference.md): Measure energy per useful inference task with explicit device or server boundaries, time windows, power integration and repeatable workload conditions.
- [A GPU-pilot spending limit: knowing when to decide again](https://retrivium.ai/journal/gpu-pilot-spending-limit.md): Set a GPU-pilot budget with detailed cost categories, observable thresholds, delayed-accounting awareness and a tested completion procedure.
- [Funding an existing GPU or buying a new one: where to start](https://retrivium.ai/journal/existing-gpu-vs-new-purchase.md): Compare an existing GPU node and new purchase against the same task, preparation needs, operating expenses, acceptance and the next measurable decision.
- [Vast.ai Hosting Setup: Prepare a Verifiable Server Record](https://retrivium.ai/journal/vast-host-preflight-files.md): Prepare a Vast.ai host record covering hardware, existing workloads, site limits and change permissions before installing hosting software.
- [Vast.ai Host Verification: What Each Stage Actually Shows](https://retrivium.ai/journal/vast-host-verification-stages.md): Understand Vast.ai host verification by separating hardware records, self-test results and platform status without assuming approval or demand.
- [Vast.ai Offer End Date: Plan When Your Server Must Return](https://retrivium.ai/journal/vast-host-offer-end-date.md): Plan a Vast.ai offer end date around the time your server must return to its owner, including workload completion and environment checks.
- [Scheduling Maintenance for a Vast.ai Host](https://retrivium.ai/journal/vast-host-maintenance-window.md): Plan a Vast.ai host maintenance window with workload checks, UTC timestamps, a bounded change and evidence of restored readiness.
- [Test Your Own Vast.ai Host Through a Rental](https://retrivium.ai/journal/vast-host-self-rental-test.md): Test your own Vast.ai host with a bounded client workflow, distinguishing self-testing, default jobs and self-rental, then verify resource release.
- [GPU Server Electricity Costs: Reconcile an Actual Bill](https://retrivium.ai/journal/own-server-electricity-invoice.md): Calculate GPU server electricity from measured operating modes, then reconcile energy, tariffs and included hosting charges without double counting.
- [Calculate the Cost of Making Your GPU Available](https://retrivium.ai/journal/gpu-availability-cost-per-hour.md): Calculate GPU availability cost per hour using a defined period, verified available hours and consistently allocated operating expenses.
- [GPU Colocation Power Budget: Check the Site Limit](https://retrivium.ai/journal/gpu-site-power-budget.md): Assess a GPU colocation power budget using the site limit, complete system requirements and measurements from several operating modes.
- [Offer Your GPU Server Without Relocating It](https://retrivium.ai/journal/gpu-owner-no-relocation-brief.md): Describe a GPU server offered from its existing location: remote access, physical maintenance, schedule, network and responsibilities.
- [A GPU Availability Calendar Across Time Zones](https://retrivium.ai/journal/gpu-weekly-availability-calendar.md): Build a GPU availability calendar with named time zones, UTC timestamps, preparation windows, reservations and versioned exceptions.
- [Build a GPU Inventory CSV with nvidia-smi](https://retrivium.ai/journal/gpu-inventory-csv-from-nvidia-smi.md): Export a small GPU inventory CSV with nvidia-smi while preserving units, timestamp and the distinction between configuration and health evidence.
- [GPU Operator Handover: Issue and Revoke Access Keys](https://retrivium.ai/journal/gpu-operator-key-handover.md): Plan a GPU operator handover with named accounts, key fingerprints, approved permissions, expiry and verification of revoked access.
- [GPU Idle Reports: Separate Waiting, Outages and Reservations](https://retrivium.ai/journal/gpu-idle-report-state-taxonomy.md): Classify GPU time as external work, ready waiting, owner reservation, maintenance or unavailability before explaining idle time.
- [Return a GPU to Its Research Window](https://retrivium.ai/journal/gpu-research-window-handover.md): Return a shared GPU before a research window by stopping intake, completing work, checking resources and obtaining acceptance from the researcher.
- [GPU Cloud Credits Expiring Soon: Plan a Useful Pilot](https://retrivium.ai/journal/gpu-cloud-credit-expiry-plan.md): Use expiring GPU cloud credits for a bounded, eligible experiment while checking account rules, service coverage and costs outside the credit.
- [Grant Funded GPUs: Document Remote Access for Review](https://retrivium.ai/journal/gpu-grant-remote-access-appendix.md): Document remote access to grant funded GPUs with a specific purpose, action matrix, data boundary, expiry and reviewable approval record.
- [Allocate Electricity Costs for a Shared Research GPU](https://retrivium.ai/journal/gpu-grant-electricity-cost-center.md): Allocate electricity for a shared research GPU using one measurement boundary, non-overlapping project intervals and the applicable grant rules.
- [Build a Payment Calendar for a GPU Pilot](https://retrivium.ai/journal/gpu-funding-payment-calendar.md): Build a GPU pilot payment schedule that separates invoices, approved commitments, payment dates and available funds from work completion.
- [Reconcile a Hosting Invoice with GPU Telemetry](https://retrivium.ai/journal/gpu-invoice-vs-telemetry-reconciliation.md): Reconcile a GPU hosting invoice with telemetry by matching the measured object, units and time period before explaining consumption differences.
- [Record an Equipment Contribution to a GPU Pilot](https://retrivium.ai/journal/gpu-in-kind-contribution-register.md): Record an equipment contribution to a GPU pilot using configuration, availability, responsibilities and acceptance evidence without inventing a valuation.
- [GPU Server Spare Parts: Build a Justified Reserve](https://retrivium.ai/journal/gpu-spare-part-reserve-table.md): Build a GPU server spare parts reserve from compatible components, recovery procedures and lead times rather than a universal budget percentage.
- [Fixed and Variable GPU Costs: A Working Worksheet](https://retrivium.ai/journal/gpu-fixed-variable-cost-worksheet.md): Separate fixed and variable GPU costs according to the period and shutdown scenario, with a worksheet that avoids counting included charges twice.
- [Report Unspent GPU Pilot Funding and Commitments](https://retrivium.ai/journal/gpu-funding-unused-budget-report.md): Report GPU pilot funding by separating received funds, paid expenses, approved commitments and estimates before describing an unspent balance.
- [Compare Remote Hands Costs for Your GPU Server](https://retrivium.ai/journal/gpu-remote-hands-callout-cost.md): Compare GPU remote hands quotes by task, minimum billing unit, urgency, materials, site access and evidence of restored service.
- [Close a GPU Pilot with a Data Cleanup Record](https://retrivium.ai/journal/gpu-disk-cleanup-evidence.md): Close a GPU pilot with an agreed data inventory, cleanup evidence, separate access withdrawal and clear limits on what was verified.
- [Keep a Network Outage Log for a GPU Node](https://retrivium.ai/journal/gpu-owner-network-outage-log.md): Keep a GPU network outage timeline with observation points, UTC timestamps, connection recovery and separate application readiness evidence.
- [A Change Register for GPU Drivers and Server Settings](https://retrivium.ai/journal/gpu-maintenance-change-register.md): Track GPU server changes with a baseline, reason, approval, exact versions, verification result and a documented recovery path.
- [Allocate Shared Host Costs Between Two GPUs](https://retrivium.ai/journal/gpu-two-card-cost-allocation.md): Allocate shared host costs between two GPUs using direct attribution first and one consistent rule for the remaining common expenses.
- [Check Which GPU Expenses Cloud Credits Cover](https://retrivium.ai/journal/gpu-credit-service-eligibility-map.md): Map GPU cloud credit coverage by eligible product, account, status and expiry, keeping uncovered costs and transfer restrictions visible.
- [Track Vendor Quote Validity in a GPU Purchase Budget](https://retrivium.ai/journal/gpu-funding-quote-validity-register.md): Track GPU vendor quotes by version, expiry, configuration, currency and delivery scope so a purchase budget retains a verifiable basis.
- [RTX 3090 vs RTX 4090 for LLMs: Compare the Same Workload](https://retrivium.ai/journal/rtx-3090-vs-4090-llm.md): Compare RTX 3090 and RTX 4090 LLM workloads with the same 24GB memory boundary, model artifact, context, quality checks and host conditions.
- [RTX 4090 vs RTX 5090 for LLMs: Compare 24GB and 32GB](https://retrivium.ai/journal/rtx-4090-vs-5090-llm.md): Compare RTX 4090 24GB and RTX 5090 32GB for one LLM task, checking architecture support, full memory use and the measured reason to upgrade.
- [RTX 4090 48GB: Distinguish Official Hardware from Modifications](https://retrivium.ai/journal/rtx-4090-48gb-modification.md): Check an RTX 4090 48GB listing against official hardware, device count, reported memory, modification history and a separate workload acceptance test.
- [RTX 4090 Laptop vs Desktop for Local LLMs](https://retrivium.ai/journal/rtx-4090-laptop-vs-desktop.md): Distinguish RTX 4090 Laptop 16GB from desktop RTX 4090 24GB for LLMs, including memory, sustained operation and an owner-first schedule.
- [Choose a Local LLM for an RTX 3090 24GB](https://retrivium.ai/journal/rtx-3090-24gb-model-selection.md): Select a local LLM for RTX 3090 24GB by fixing the artifact, measuring memory and checking quality before expanding context or concurrency.
- [RTX 5090 LLM Tokens per Second: Define the Benchmark](https://retrivium.ai/journal/rtx-5090-tokens-per-second.md): Interpret RTX 5090 LLM token rates by model, numerical format, request lengths, concurrency, first-token delay and successful output.
- [Coding LLMs on 8GB VRAM: Start with a Bounded Task](https://retrivium.ai/journal/coding-llm-8gb-vram.md): Test coding LLMs on 8GB VRAM with a small artifact, bounded context and executable checks instead of assuming a complete repository assistant.
- [Coding LLMs on 12GB VRAM: Budget Context and Headroom](https://retrivium.ai/journal/coding-llm-12gb-vram.md): Plan coding LLMs on 12GB VRAM using exact artifacts, compatible quantisation, code tests and separate input, output and concurrency limits.
- [Local LLMs on 16GB VRAM: Narrow the Model Choice](https://retrivium.ai/journal/local-llm-16gb-vram.md): Narrow a local LLM shortlist for 16GB VRAM by exact model, numerical format, useful context, quality and the level of validation completed.
- [Local LLMs on 24GB VRAM: Test More Than the Weights](https://retrivium.ai/journal/local-llm-24gb-vram.md): Assess local LLMs on 24GB VRAM using exact 14B or 32B artifacts, weight estimates, context tests, concurrency and reproducible free-memory conditions.
- [48GB VRAM for LLMs: One GPU and Multiple GPUs Differ](https://retrivium.ai/journal/llm-models-48gb-vram.md): Interpret 48GB VRAM for LLMs by separating one large GPU, two 24GB devices, replicas and supported distributed model execution.
- [How Much VRAM Does a 70B Model Need?](https://retrivium.ai/journal/llm-70b-vram-calculation.md): Estimate 70B LLM weight memory at 16, 8 and 4 bits, then add quantisation overhead, KV cache and the requirements of multi-GPU placement.
- [Calculate Weight Memory for an 8B Model](https://retrivium.ai/journal/llm-8b-weight-memory.md): Calculate an 8B model weight estimate in decimal GB, distinguish actual tensor formats and reserve memory for the complete inference workload.
- [A 14B Model on 16GB VRAM: Understand the Bit Estimate](https://retrivium.ai/journal/llm-14b-16gb-memory.md): Assess a 14B model on 16GB VRAM with explicit weight arithmetic, supported quantisation, request headroom and a smaller-model quality comparison.
- [A 32B Model on 24GB VRAM: Why the Formula Is Not Enough](https://retrivium.ai/journal/llm-32b-24gb-memory.md): Evaluate a 32B model on 24GB VRAM by separating ideal weight size, quantised artifact support and the memory needed for requests.
- [Qwen3-8B VRAM: Thinking Mode and a First Local Test](https://retrivium.ai/journal/qwen3-8b-vram-requirements.md): Test Qwen3-8B VRAM with an exact artifact, supported runtime, explicit thinking mode and separate context, output and concurrency experiments.
- [Qwen3-Coder VRAM: Check the Exact Model Variant](https://retrivium.ai/journal/qwen3-coder-vram-requirements.md): Read Qwen3-Coder VRAM requirements from the exact model variant, total MoE weights, supported runtime and a narrow code-quality test.
- [Qwen3-VL VRAM: Test Images of Different Complexity](https://retrivium.ai/journal/qwen3-vl-vram-requirements.md): Assess Qwen3-VL VRAM using exact image inputs, preprocessing settings, model and runtime versions, accuracy checks and full-pipeline measurements.
- [gpt-oss-20b VRAM: Read the Conditions Behind the Claim](https://retrivium.ai/journal/gpt-oss-20b-vram-setup.md): Read gpt-oss-20b VRAM claims in context: total versus active parameters, MXFP4 support, actual loading format, reasoning and request memory.
- [gpt-oss-120b VRAM: Total MoE Weights and Active Parameters](https://retrivium.ai/journal/gpt-oss-120b-vram-setup.md): Plan gpt-oss-120b memory from the complete MoE artifact, MXFP4 conditions, per-device placement and a bounded reasoning workload.
- [DeepSeek-R1 vs Distill: Different Models, Different GPU Needs](https://retrivium.ai/journal/deepseek-r1-distill-vram.md): Distinguish full DeepSeek-R1 from a specific Distill model before estimating VRAM, selecting weights or reporting a GPU test.
- [DeepSeek-OCR GPU Requirements: Test Accuracy and Memory](https://retrivium.ai/journal/deepseek-ocr-gpu-requirements.md): Check DeepSeek-OCR GPU requirements with the exact model, page-processing mode, expected text, separate RAM/VRAM measurements and accuracy evidence.
- [Two 24GB GPUs vs One 48GB GPU for an LLM](https://retrivium.ai/journal/two-24gb-vs-one-48gb-gpu.md): Compare two 24GB GPUs with one 48GB GPU by task, supported model partitioning, interconnects, replica capacity and complete operating behaviour.
- [RTX 5060 Ti 16GB vs RTX 5070 12GB for Local LLMs](https://retrivium.ai/journal/rtx-5060ti-16gb-vs-5070-12gb.md): Compare RTX 5060 Ti 16GB and RTX 5070 12GB for a local LLM using exact variants, artifact memory, quality and measured request limits.
- [A100 40GB vs 80GB for LLMs: Check Memory and Form Factor](https://retrivium.ai/journal/a100-40gb-vs-80gb-llm.md): Compare A100 40GB and 80GB LLM configurations by exact form factor, server compatibility, partition profile and complete workload measurements.
- [H100 PCIe vs SXM for LLMs: Compare the Whole System](https://retrivium.ai/journal/h100-pcie-vs-sxm-llm.md): Compare H100 PCIe and SXM using exact SKUs, supported server platforms, real interconnects and a common LLM workload without conflating H100 NVL.
- [CUDA Out of Memory While Loading a Model: A Check Order](https://retrivium.ai/journal/cuda-oom-model-loading.md): Diagnose CUDA OOM during model loading by the last successful stage, weight format, other processes, temporary peaks and runtime-specific allocation.
- [CUDA Out of Memory on Long Prompts: Check the Context](https://retrivium.ai/journal/cuda-oom-long-context.md): Investigate CUDA OOM on long prompts using tokenised input, output allowance, KV cache, prefill buffers and a controlled context-growth test.
- [CUDA Out of Memory with Concurrent Requests](https://retrivium.ai/journal/cuda-oom-concurrent-requests.md): Diagnose CUDA OOM under concurrent LLM requests by separating clients, queued work and active sequences, then measuring a controlled load progression.
- [CUDA OOM Allocated vs Reserved: Read the Evidence](https://retrivium.ai/journal/cuda-oom-reserved-vs-allocated.md): Interpret allocated and reserved CUDA memory without adding overlapping figures, and distinguish live tensors, allocator cache and evidence of fragmentation.
- [First Verifiable vLLM Launch in Docker on NVIDIA GPUs](https://retrivium.ai/journal/vllm-docker-first-launch.md): Make a first local vLLM Docker launch verifiable by checking GPU access, model readiness, API identity and persistent weight storage.
- [Install vLLM: Check GPU, Driver and Package Compatibility](https://retrivium.ai/journal/vllm-install-compatibility.md): Install vLLM through a documented route after checking GPU, OS, driver, Python, package backend and model compatibility as separate layers.
- [vLLM on Windows: WSL and the Linux Environment](https://retrivium.ai/journal/vllm-windows-wsl.md): Run vLLM from Windows through a supported Linux environment such as compatible WSL, checking GPU access, files and local API boundaries in order.
- [vLLM served-model-name: Fix a Missing API Model](https://retrivium.ai/journal/vllm-served-model-name.md): Resolve a vLLM model-not-found response by matching served-model-name, the /v1/models result and the client request independently of checkpoint loading.
- [vLLM max-model-len: Set a Meaningful Context Limit](https://retrivium.ai/journal/vllm-max-model-len.md): Choose vLLM max-model-len from tokenised input, output allowance, model support and available memory rather than the largest advertised context window.
- [What vLLM gpu-memory-utilization Actually Limits](https://retrivium.ai/journal/vllm-gpu-memory-utilization.md): Understand vLLM gpu-memory-utilization as an engine memory budget, with explicit headroom and tests for competing processes, cache and workload changes.
- [vLLM tensor-parallel-size: When One Model Needs Multiple GPUs](https://retrivium.ai/journal/vllm-tensor-parallel-size.md): Use vLLM tensor-parallel-size for a supported single-model distribution, distinguishing topology and communication from independent replicas.
- [vLLM Quantization: Match the Weights, Format and GPU](https://retrivium.ai/journal/vllm-quantization-launch.md): Launch quantised weights in vLLM by matching checkpoint, method, GPU support and runtime, then measuring full memory use and task quality.
- [vLLM and GGUF: Check Compatibility Before Moving a Model](https://retrivium.ai/journal/vllm-gguf-compatibility.md): Move a GGUF model from llama.cpp to vLLM only after checking experimental plugin support, exact quantisation, tokenizer and equivalent control requests.
- [vLLM bench serve: Read a Serving Benchmark Result](https://retrivium.ai/journal/vllm-bench-serve-command.md): Run and interpret vLLM bench serve with a verified endpoint, explicit input/output lengths, request rate, warm-up state and useful latency measures.
- [vLLM is running but not ready: health checks and the first request](https://retrivium.ai/journal/vllm-health-ready.md): Check vLLM readiness in stages: process status, HTTP health, advertised model names and a small generation request after a clean restart.
- [vLLM KV cache preemption: why requests are recomputed](https://retrivium.ai/journal/vllm-kv-cache-preemption.md): Understand vLLM KV cache preemption, distinguish it from OOM and compare concurrency settings using completed requests and end-to-end latency.
- [Testing streaming responses from the vLLM API](https://retrivium.ai/journal/vllm-openai-streaming-test.md): Verify vLLM streaming with an unbuffered client, distinguish events from visible tokens and identify proxy buffering before changing GPU settings.
- [vLLM is unreachable: localhost, containers and published ports](https://retrivium.ai/journal/vllm-localhost-container-port.md): Diagnose unreachable vLLM endpoints by separating process readiness, container networking, bind addresses and the two sides of a published port.
- [vLLM or Ollama: choose a serving workflow](https://retrivium.ai/journal/vllm-vs-ollama-serving.md): Compare vLLM and Ollama by operating workflow, model artifacts, memory, concurrency and cold versus repeated requests without unsupported speed rankings.
- [vLLM or llama.cpp: serving workloads and GGUF workflows](https://retrivium.ai/journal/vllm-vs-llama-cpp.md): Compare vLLM and llama.cpp by model format, partial GPU offloading, serving controls and matched outputs instead of unsupported speed claims.
- [Ollama is not using the GPU: five separate checks](https://retrivium.ai/journal/ollama-does-not-use-gpu.md): Diagnose Ollama CPU-only execution by checking exact GPU support, drivers, process visibility, device selection and memory placement with logs.
- [Ollama on Windows: verify GPU support and workload placement](https://retrivium.ai/journal/ollama-windows-gpu-check.md): Verify native Ollama on Windows using the exact GPU, background process, logs, ollama ps and a repeatable test after restarting the application.
- [Ollama on AMD: check your exact GPU and backend](https://retrivium.ai/journal/ollama-amd-gpu-check.md): Check Ollama support for an exact AMD GPU, operating system and backend, then verify placement and memory without universal Radeon support claims.
- [Ollama context length: set and verify the actual window](https://retrivium.ai/journal/ollama-context-length-setting.md): Set Ollama context length explicitly, inspect effective placement and compare memory and latency at three useful context levels before increasing concurrency.
- [Running two Ollama models at once: memory and concurrency](https://retrivium.ai/journal/ollama-two-models-parallel.md): Test two Ollama models together by separating loaded-model limits from request concurrency, then checking memory, retention and the actual queue.
- [Ollama CPU and GPU split: interpreting mixed placement](https://retrivium.ai/journal/ollama-cpu-gpu-split.md): Interpret Ollama CPU/GPU placement, distinguish usable capacity from speed and test whether a mixed configuration meets the task’s latency needs.
- [Ollama keep_alive: retain or unload a model deliberately](https://retrivium.ai/journal/ollama-keep-alive-unload.md): Use Ollama keep_alive deliberately: compare cold and warm requests, inspect model retention, test unloading and document idle intervals.
- [Choosing a GGUF file for llama.cpp](https://retrivium.ai/journal/llama-cpp-gguf-selection.md): Choose an exact GGUF artifact for llama.cpp using provenance, quantization, runtime memory, tokenizer and chat-template checks on a small task set.
- [llama.cpp server: a local API from a GGUF model](https://retrivium.ai/journal/llama-cpp-server-launch.md): Start llama-server with a compatible GGUF, verify the local API and model identifier, then confirm backend placement and a repeatable clean launch.
- [llama.cpp GPU layers: verify partial model offloading](https://retrivium.ai/journal/llama-cpp-gpu-layers.md): Adjust llama.cpp GPU layers in a supported build, inspect real offloading and compare memory and latency without assuming layers occupy equal shares.
- [Building llama.cpp on Windows with the right backend](https://retrivium.ai/journal/llama-cpp-windows-build.md): Build or select llama.cpp on Windows with the intended backend, verify the actual executable and separate GPU discovery from model offloading.
- [SGLang in Docker: launch and verify your first model](https://retrivium.ai/journal/sglang-docker-launch.md): Launch SGLang in Docker on a compatible NVIDIA environment, retain model files and verify readiness, model identity and a repeated clean start.
- [SGLang or vLLM: compare engines on the same workload](https://retrivium.ai/journal/sglang-vs-vllm-serving.md): Compare SGLang and vLLM on matched checkpoints, quality examples, cache conditions and request rates, including startup and recovery behaviour.
- [SGLang memory fraction: diagnose GPU memory pressure](https://retrivium.ai/journal/sglang-memory-fraction.md): Diagnose SGLang memory pressure using mem-fraction-static, prefill and decode stages, cache capacity and small controlled configuration changes.
- [Runpod persistent storage: keep files after deleting a Pod](https://retrivium.ai/journal/runpod-network-volume-persistence.md): Keep Runpod files after Pod deletion by choosing an independent network volume, checking /workspace and testing recovery from a new environment.
- [Runpod storage types: container disk, volume disk and network volume](https://retrivium.ai/journal/runpod-container-volume-network-disk.md): Compare Runpod container disks, volume disks and network volumes by Stop, Terminate, mount location and the data that each resource should hold.
- [Runpod storage pricing: what remains billable after Stop](https://retrivium.ai/journal/runpod-storage-billing-after-stop.md): Understand Runpod charges after Stop by separating GPU compute from retained disks, independent volumes and the full period between working sessions.
- [Runpod SSH keys: prepare credentials and choose a connection](https://retrivium.ai/journal/runpod-ssh-public-key-setup.md): Prepare a Runpod SSH public key, use the current Connect command and distinguish basic proxied access from full TCP SSH with SCP or SFTP.
- [Runpod SSH not working: diagnose one connection layer at a time](https://retrivium.ai/journal/runpod-ssh-connection-debug.md): Diagnose Runpod SSH failures by checking current Pod state, transport mode, mapped ports, sshd and public-key authentication in a clear order.
- [Runpod SSH port forwarding for a private local service](https://retrivium.ai/journal/runpod-private-port-forward.md): Forward a local Runpod service through full SSH by separating the external SSH port, internal application port and loopback port on your computer.
- [Jupyter on Runpod: where to save notebooks and results](https://retrivium.ai/journal/runpod-jupyter-files-persistence.md): Save Runpod Jupyter notebooks and outputs on the intended disk, distinguish kernel memory from files and verify an exported project in a clean session.
- [Expose a Pod HTTP service through Runpod Proxy](https://retrivium.ai/journal/runpod-http-port-proxy.md): Publish a Runpod HTTP application using its internal port, a reachable bind address and the correct proxy URL, then verify route and authentication separately.
- [Runpod Community and Secure Cloud: storage and access boundaries](https://retrivium.ai/journal/runpod-community-vs-secure-boundaries.md): Compare Runpod Community and Secure Cloud using documented placement, network-volume support and the access requirements of a specific GPU project.
- [What to save before terminating a Runpod Pod](https://retrivium.ai/journal/runpod-terminate-pod-backup.md): Prepare for Runpod Terminate by inventorying results, exporting a secret-free environment recipe, checking recovery and deciding separately on network volumes.
- [Vast.ai Stop and Destroy: instance and data lifecycles](https://retrivium.ai/journal/vast-ai-instance-lifecycle-stop-destroy.md): Understand Vast.ai Stop, Restart and Destroy, including retained files, storage billing, GPU availability and a verified export before deletion.
- [Reading Vast.ai storage and bandwidth charges](https://retrivium.ai/journal/vast-ai-storage-network-charges.md): Estimate the full Vast.ai offer using GPU time, allocated storage, transfer directions, paused retention and the cost of moving results.
- [Reading Vast.ai host metrics before renting a GPU](https://retrivium.ai/journal/vast-ai-host-score-fields.md): Read Vast.ai reliability, verification tier, maximum rental duration and allocated resources, then validate the full workflow with a small test.
- [Vast.ai SSH and Jupyter: choose the right access template](https://retrivium.ai/journal/vast-ai-ssh-jupyter-ports.md): Choose Vast.ai SSH, Jupyter or Entrypoint launch modes, find current mapped ports and verify access before configuring notebooks or development tools.
- [Vast.ai on-demand, reserved and interruptible instances](https://retrivium.ai/journal/vast-ai-reserved-interruptible-choice.md): Compare Vast.ai rental types using priority, prepayment, instance-bound credits and restartable work rather than headline rate differences alone.
- [Moving data between Vast.ai instances](https://retrivium.ai/journal/vast-ai-copy-data-between-instances.md): Move Vast.ai data using supported transfer paths, preserve the environment recipe and verify files, permissions and a control run before deleting the source.
- [Vast.ai templates: ports, environment variables and repeatable launches](https://retrivium.ai/journal/vast-ai-template-environment-variables.md): Create a repeatable Vast.ai template with a fixed image, launch mode, startup logs, ports and explicit configuration while keeping secrets out of the recipe.
- [Hetzner GPU VPS searches and dedicated GEX servers](https://retrivium.ai/journal/hetzner-gpu-vps-vs-gex.md): Distinguish Hetzner GPU VPS searches from dedicated GEX root servers, including resource format, administration, scaling expectations and the first pilot.
- [Recovering SSH access to a Hetzner GPU server with Rescue](https://retrivium.ai/journal/hetzner-gex-root-rescue-access.md): Recover a Hetzner dedicated GPU server through Robot and Rescue System by separating panel access, OS diagnosis and a minimal reversible repair.
- [Hetzner GPU pricing: include setup fees in a short pilot](https://retrivium.ai/journal/hetzner-gpu-install-fee-short-rental.md): Include Hetzner GPU setup fees in a short pilot using a complete-period formula, an explicitly hypothetical example and a clear working calendar.
- [Hetzner GPU server auction: verify the actual listing](https://retrivium.ai/journal/hetzner-gpu-server-auction-status.md): Check a Hetzner Server Auction listing for an explicitly specified GPU, distinguish it from GEX and verify the full resource before ordering.
- [Hourly or monthly GPU rental: compare the full working period](https://retrivium.ai/journal/cloud-gpu-hourly-monthly-break-even.md): Compare hourly and monthly GPU rental with matched workloads, complete storage periods, setup costs and a clearly hypothetical break-even calculation.
- [Runpod pricing calculator: build a useful input worksheet](https://retrivium.ai/journal/cloud-gpu-budget-calculator-worksheet.md): Prepare a Runpod cost worksheet with billable Pod time, disk type and capacity, retained-data lifetime, transfer and measured preparation assumptions.
- [Google Cloud GPU quota: checks before requesting an increase](https://retrivium.ai/journal/google-cloud-gpu-quota-request.md): Prepare a Google Cloud GPU quota request by checking global and regional model limits, provisioning mode, existing usage and the exact configuration.
- [Google Cloud GPU capacity errors despite available quota](https://retrivium.ai/journal/google-cloud-gpu-zone-resource-pool-exhausted.md): Diagnose Google Cloud GPU resource-pool errors with sufficient quota by separating supported configurations, regional permission and physical zone capacity.
- [AWS GPU quotas: instance families and regional vCPU limits](https://retrivium.ai/journal/aws-gpu-vcpu-quota-workflow.md): Check AWS GPU vCPU quotas by region, P or G and VT family, purchase option and existing usage before submitting a Service Quotas increase.
- [GPU EC2 terminated: check the EBS volumes left behind](https://retrivium.ai/journal/aws-gpu-ebs-after-termination.md): Find EBS resources left after GPU EC2 termination by checking DeleteOnTermination, volume IDs, snapshots, regions and a verified restoration route.
- [Preparing a GPU workload for AWS Spot interruptions](https://retrivium.ai/journal/aws-spot-checkpoint-resume-gpu.md): Prepare AWS Spot GPU work with regular checkpoints, interruption handling, independent storage and a verified restart that handles incomplete outputs.
- [Azure GPU quota: regional totals and VM family limits](https://retrivium.ai/journal/azure-gpu-regional-family-quotas.md): Check Azure GPU deployment permission through Total Regional vCPUs, the selected VM-family quota and current subscription usage before diagnosing capacity.
- [Azure GPU VM Stopped or Deallocated: which costs remain](https://retrivium.ai/journal/azure-gpu-deallocated-cost-components.md): Distinguish Azure GPU VM Stopped from Deallocated, verify the actual power state and audit managed disks and networking after compute is released.
- [Starting a GPU project on Selectel: resource and access options](https://retrivium.ai/journal/selectel-gpu-server-access-options.md): Start a Selectel GPU project by verifying the cloud configuration, dedicated PCI device, storage, Data Science image and an initial access test.
- [JupyterLab on Selectel GPU: access and saved notebooks](https://retrivium.ai/journal/selectel-gpu-jupyter-notebook-access.md): Use Selectel’s Data Science GPU image for JupyterLab, verify the documented network path and save a notebook that works from a clean kernel.
- [Configuring a Yandex Cloud GPU VM](https://retrivium.ai/journal/yandex-gpu-platform-configuration.md): Configure a Yandex Cloud GPU VM using the supported platform, GPU count, paired CPU and RAM, compatible image and current quota scope.
- [Yandex Cloud GPU clusters: when InfiniBand matters](https://retrivium.ai/journal/yandex-gpu-cluster-connectivity.md): Choose a Yandex Cloud GPU cluster only for a suitable distributed workload, checking InfiniBand, supported eight-GPU nodes, zone and cluster permission.
- [Preparing a Yandex Cloud GPU quota request](https://retrivium.ai/journal/yandex-gpu-quota-approval.md): Prepare a Yandex Cloud GPU quota request with exact platform, zone, parallel VM count, current usage and the October 2026 quota-scope changes.
- [Yandex Cloud preemptible GPU VMs: disks and restart plans](https://retrivium.ai/journal/yandex-preemptible-gpu-disk-snapshot.md): Prepare a Yandex Cloud preemptible GPU VM with regular application progress, persistent files, deliberate snapshots and a tested restart from saved state.
- [Deploying a GPU VM on Cloud.ru Evolution](https://retrivium.ai/journal/cloud-ru-evolution-gpu-deployment.md): Deploy a Cloud.ru Evolution GPU VM by matching platform, GPU flavour, image, zone, network and SSH keys, then testing a small reproducible workload.
- [Cloud.ru Advanced or Evolution GPU: compare the actual platforms](https://retrivium.ai/journal/cloud-ru-advanced-vs-evolution-gpu.md): Compare Cloud.ru Advanced ECS with GPU and Evolution GPU VMs as separate platforms, including tools, dependencies, configurations and migration work.
- [SberCloud GPU and Cloud.ru: updating older instructions](https://retrivium.ai/journal/sbercloud-cloud-ru-gpu-name-change.md): Update older SberCloud GPU tutorials by identifying the current Cloud.ru platform, product, API, image and ordering terms before repeating technical steps.
- [VK Cloud GPU: full devices, vGPU profiles and first checks](https://retrivium.ai/journal/vk-cloud-gpu-instance-options.md): Choose VK Cloud GPU resources by distinguishing full devices from vGPU profiles, available VRAM, operating-system preparation and licensing requirements.
- [Timeweb Cloud GPU: checks before your first deployment](https://retrivium.ai/journal/timeweb-gpu-server-first-setup.md): Check Timeweb Cloud GPU format, availability, creation workflow, billing-period wording and supported cloning before a first workload is deployed.
- [Servercore GPU: server format, location and billing checks](https://retrivium.ai/journal/servercore-gpu-server-options.md): Evaluate Servercore GPU placement in Central Asia, the full server configuration and the difference between shutdown, pause and freeze in billing rules.
- [Accessing Jupyter on a cloud GPU through an SSH tunnel](https://retrivium.ai/journal/cloud-gpu-jupyter-ssh-tunnel.md): Access Jupyter on a cloud GPU through a loopback SSH tunnel while preserving notebook authentication and distinguishing local from remote ports.
- [Runpod S3 storage: a network-volume API, with specific limits](https://retrivium.ai/journal/gpu-cloud-s3-model-cache-storage.md): Use Runpod’s S3-compatible API for network-volume files, with the correct data-centre endpoint and explicit checks for unsupported Amazon S3 features.
- [GPU powered off, public IP retained: audit the network resource](https://retrivium.ai/journal/cloud-public-ip-lifetime-billing.md): Audit public IP resources after a GPU VM stops or is deleted, including AWS Elastic IP, Azure Public IP, DNS dependencies and remaining charges.
- [Resizing a cloud GPU VM without losing data](https://retrivium.ai/journal/cloud-gpu-resize-data-preservation.md): A practical GPU VM resize checklist covering supported changes, persistent data, a replacement instance, validation and a clear rollback point.
- [Moving a GPU VM to another region: what must move separately](https://retrivium.ai/journal/cloud-gpu-region-migration-plan.md): Plan a GPU VM region migration across compute, images, disks, quotas, network dependencies and access, with a tested cutover and rollback.
- [Ephemeral and persistent disks on GPU VMs: a deletion checklist](https://retrivium.ai/journal/cloud-gpu-ephemeral-vs-persistent-checklist.md): Understand GPU VM disk lifecycles before stopping or deleting an instance: ephemeral storage, persistent volumes, backups and a restore test.
- [GPU cloud team access: API keys and SSH keys have different jobs](https://retrivium.ai/journal/cloud-gpu-account-team-key-rotation.md): Separate cloud API credentials, SSH keys and application tokens for a GPU team, with scoped automation and a tested rotation procedure.
- [Ending a GPU pilot: finding resources that still incur charges](https://retrivium.ai/journal/cloud-gpu-resource-cleanup-audit.md): Close a GPU pilot with an inventory of instances, disks, snapshots, addresses and access, then reconcile any remaining charges.
- [Setting up an OpenRouter API key for an application](https://retrivium.ai/journal/openrouter-api-key-setup.md): Prepare an OpenRouter API key with clear ownership, bounded spending, server-side storage and a small test before a larger integration.
- [OpenRouter base URL: configuring a compatible client](https://retrivium.ai/journal/openrouter-base-url.md): Configure the OpenRouter base URL correctly by separating an SDK base address from a full endpoint and inspecting the final HTTP request.
- [Your first verifiable OpenRouter request in Python](https://retrivium.ai/journal/openrouter-python-request.md): Make a small OpenRouter call from Python, checking environment variables, HTTP failures, model identity and usage before adding frameworks.
- [Calling OpenRouter from Node.js without exposing the key](https://retrivium.ai/journal/openrouter-nodejs-request.md): Call OpenRouter from a Node.js server while keeping the API key out of browser code and checking cancellation, errors and application limits.
- [Reading an OpenRouter streaming response incrementally](https://retrivium.ai/journal/openrouter-streaming-client.md): Parse OpenRouter streaming responses with correct SSE boundaries, incremental UTF-8 decoding, completion handling and partial-error reporting.
- [Structured output through OpenRouter: when to use a JSON schema](https://retrivium.ai/journal/openrouter-json-schema.md): Use OpenRouter structured outputs with a supported route, a small JSON Schema and application checks for both structure and meaning.
- [Tool calling through OpenRouter: the model proposes, your app executes](https://retrivium.ai/journal/openrouter-tool-calling.md): Build an OpenRouter client-tool loop with route checks, argument validation, application authorization and explicit execution limits.
- [OpenRouter error 429: limits, queues and controlled retries](https://retrivium.ai/journal/openrouter-429-error.md): Diagnose OpenRouter 429 errors by identifying the limiting layer, respecting Retry-After and testing recovery with a bounded queue.
- [OpenRouter error 403: what to check before switching models](https://retrivium.ai/journal/openrouter-403-error.md): Investigate OpenRouter 403 errors through safe error details, permissions, scoped budgets, policy rules and recent configuration changes.
- [OpenRouter error 404: API address, model ID or route](https://retrivium.ai/journal/openrouter-404-error.md): Trace an OpenRouter 404 through the final API path, model identifier, request protocol and intermediate backend before changing infrastructure.
- [OpenRouter error 500: building a useful failure report](https://retrivium.ai/journal/openrouter-500-error.md): Build a useful OpenRouter 500 error report with a minimal request, safe diagnostics, bounded retries and a compatible fallback test.
- [OpenRouter error 401: checking credentials and the runtime](https://retrivium.ai/journal/openrouter-401-error.md): Resolve OpenRouter 401 errors by checking the Bearer header, the actual runtime credential, revoked access and a controlled replacement process.
- [OpenRouter error 402: credit balance and request limits](https://retrivium.ai/journal/openrouter-402-credits.md): Investigate OpenRouter 402 using credit balance, key limits, potential request cost and concurrent-work budgets before retrying or adding funds.
- [Free model limits on OpenRouter: planning a bounded test](https://retrivium.ai/journal/openrouter-free-model-limits.md): Plan a bounded OpenRouter free-model test with current account limits, valid free catalog entries, a finite queue and explicit fallback costs.
- [OpenRouter free model router: checking which model answered](https://retrivium.ai/journal/openrouter-free-model-router.md): Test the OpenRouter free router while recording the model that actually answered, required features, interruptions and differences from a fixed free entry.
- [Free OpenRouter API keys: what is free and what costs money](https://retrivium.ai/journal/openrouter-free-api-key.md): Separate a free OpenRouter API key from free model usage, account limits and paid fallback before building a small, verifiable experiment.
- [OpenRouter BYOK pricing: separating the parts of the bill](https://retrivium.ai/journal/openrouter-byok-pricing.md): Build an OpenRouter BYOK estimate that separates upstream inference, allowance, gateway fees, credit purchase fees and fallback usage.
- [OpenRouter BYOK not working: credentials, region and fallback](https://retrivium.ai/journal/openrouter-byok-not-working.md): Debug OpenRouter BYOK by checking one provider-model pair, upstream credentials, product and region eligibility, routing and the actual fallback used.
- [OpenRouter provider routing: the difference between only and order](https://retrivium.ai/journal/openrouter-provider-only-order.md): Understand OpenRouter provider.only, provider.order, fallbacks and required parameters, then test the boundary with a permitted negative case.
- [OpenRouter prompt caching: verifying savings in usage data](https://retrivium.ai/journal/openrouter-cache-cost.md): Verify OpenRouter prompt-caching savings using comparable requests, cached-input usage, actual charges and the provider route that processed them.
- [OpenRouter usage: reconciling tokens and request cost](https://retrivium.ai/journal/openrouter-usage-accounting.md): Reconcile OpenRouter request IDs, actual model identity, token usage, finish states and charges across streaming, retries and BYOK.
- [Fetching the OpenRouter model catalog before deployment](https://retrivium.ai/journal/openrouter-model-catalog-api.md): Fetch and version the OpenRouter model catalog so applications can verify IDs, context, parameters and route requirements before deployment.
- [Errors inside an OpenRouter stream: why HTTP 200 is insufficient](https://retrivium.ai/journal/openrouter-stream-errors.md): Handle OpenRouter errors after streaming starts by distinguishing HTTP success, event-level failure, partial output and a separately identified retry.
- [OpenRouter Zero Data Retention: restricting eligible routes](https://retrivium.ai/journal/openrouter-privacy-zdr.md): Evaluate OpenRouter Zero Data Retention across routing, provider endpoints, application logs and tools, including the announced screening-policy update.
- [OpenRouter fallback with a price cap: limiting backup routes](https://retrivium.ai/journal/openrouter-fallback-price-cap.md): Limit OpenRouter fallback with per-component price caps, compatible backup routes and separate bounds on tokens, attempts and total task spending.
- [Starting a LiteLLM gateway with Docker Compose](https://retrivium.ai/journal/litellm-docker-compose-start.md): Prepare a LiteLLM Docker Compose pilot with explicit gateway, Postgres, secret and volume responsibilities, then test persistence and accounting.
- [LiteLLM virtual keys: separate access for each application](https://retrivium.ai/journal/litellm-virtual-key-scopes.md): Give each LiteLLM application a scoped virtual key with documented models, ownership, budget rules, revocation and persistence checks.
- [LiteLLM budgets: periods, shared limits and overrun tests](https://retrivium.ai/journal/litellm-budget-reset.md): Configure LiteLLM budgets around the right entity, database-backed accounting, reset time and a controlled test of the effective spending boundary.
- [LiteLLM guardrails: choosing where to inspect requests and responses](https://retrivium.ai/journal/litellm-guardrails-boundary.md): Place LiteLLM guardrails at the right request or response boundary, then test false positives, dependency failures and streaming behavior.
- [Preparing LiteLLM UI for model and key management](https://retrivium.ai/journal/litellm-ui-setup.md): Prepare LiteLLM Admin UI with persistent state, managed access, one tested model, a scoped application key and a recovery procedure.
- [DLP at an AI gateway: reducing sensitive data exposure](https://retrivium.ai/journal/ai-gateway-dlp.md): Design AI gateway DLP around outgoing fields, a narrow policy, inspected upstream payloads and explicit behavior when the check fails.
- [A local RAG server: placing components around the GPU](https://retrivium.ai/journal/rag-server-local-architecture.md): Plan a local RAG server across document preparation, embeddings, vector search, reranking and generation, assigning resources to each stage.
- [Qdrant for RAG: deciding what belongs in RAM or on disk](https://retrivium.ai/journal/qdrant-memory-on-disk.md): Estimate Qdrant memory from vectors, graph structures, payload and replicas, then test RAM and on-disk placement against retrieval quality.
- [PostgreSQL and pgvector for RAG on an existing server](https://retrivium.ai/journal/pgvector-rag-server.md): Evaluate pgvector on an existing PostgreSQL server with exact and approximate search, post-scan filtering, resource limits and application workload checks.
- [Hosting Chroma: local persistence and server mode](https://retrivium.ai/journal/chroma-rag-hosting.md): Choose Chroma in-memory, persistent or client-server operation, then verify embedding location, collection consistency and recovery on your server.
- [FAISS server memory: an index library versus a database service](https://retrivium.ai/journal/faiss-index-memory.md): Size a FAISS index using representation, graph or partition overhead, metadata services and a retrieval-quality test on the actual corpus.
- [Batch text embeddings on your own GPU](https://retrivium.ai/journal/text-embeddings-batch.md): Run resumable batch text embeddings with a fixed model, documented query and document encoding, realistic lengths and verified index quality.
- [Embedding dimensions: calculating index memory](https://retrivium.ai/journal/embedding-dimensions-memory.md): Calculate embedding coordinate memory with N × D × B, then add index structures, payload and measured service overhead before sizing RAM.
- [Evaluating embeddings for Russian language retrieval](https://retrivium.ai/journal/embeddings-russian-retrieval.md): Evaluate Russian-language embeddings on your own terminology, mixed-language documents and labeled retrieval questions before comparing resource use.
- [Reranking in RAG: how many candidates should you rescore?](https://retrivium.ai/journal/reranker-rag-latency.md): Choose RAG reranker candidate depth by measuring query-passage pairs, text length, batch memory, end-to-end latency and ranking quality.
- [BGE rerankers on GPU: testing memory and batching](https://retrivium.ai/journal/bge-reranker-gpu.md): Test a BGE reranker on GPU using query-document pairs of realistic lengths, incremental batches and ranking checks before sizing capacity.
- [Qwen rerankers: separating relevance scoring from text generation](https://retrivium.ai/journal/qwen-reranker-serving.md): Serve a Qwen reranker with a relevance-scoring contract, stable instructions, preserved candidate IDs and a bounded GPU workload.
- [Choosing GPU memory for Whisper transcription](https://retrivium.ai/journal/whisper-gpu-requirements.md): Choose GPU memory for Whisper using the official approximate model guidance, representative audio, concurrency and stage-by-stage measurements.
- [Whisper on CPU or GPU: comparing completion time and cost](https://retrivium.ai/journal/whisper-cpu-vs-gpu.md): Compare Whisper on CPU and GPU using identical audio, model settings, real-time factor, transcript quality and total completed-file cost.
- [Running Whisper in a GPU container: a preflight checklist](https://retrivium.ai/journal/whisper-gpu-container.md): Validate a Whisper GPU container across host drivers, container access, FFmpeg decoding, model execution and persistent output directories.
- [Long audio with Whisper: segments, queues and durable results](https://retrivium.ai/journal/whisper-long-audio.md): Plan long-audio Whisper jobs with stable recording and segment IDs, timestamps, bounded retries and a verified durable transcript.
- [OCR on CPU or GPU: where acceleration changes the pipeline](https://retrivium.ai/journal/ocr-gpu-vs-cpu.md): Compare OCR on CPU and GPU across page preparation, recognition, structure reconstruction and durable output using the same labeled documents.
- [PaddleOCR on GPU: validating installation and document quality](https://retrivium.ai/journal/paddleocr-gpu-pilot.md): Validate PaddleOCR GPU installation, actual backend selection and document quality before changing pipeline components or scaling the workload.
- [Tesseract and GPU acceleration: why installing CUDA is insufficient](https://retrivium.ai/journal/tesseract-gpu-acceleration.md): Understand Tesseract GPU limits, experimental OpenCL support and CPU process tuning before deciding whether another OCR engine needs a GPU. 
- [A GPU OCR pipeline for a 1,000-page PDF workload](https://retrivium.ai/journal/pdf-ocr-gpu-pipeline.md): Estimate a 1,000-page PDF OCR job from representative page classes, complete pipeline timings, quality checks and explicit retry overhead.
- [ComfyUI GPU requirements depend on the entire workflow](https://retrivium.ai/journal/comfyui-gpu-requirements.md): Choose a GPU for ComfyUI using the complete workflow, model and node versions, resolution, batch and memory peaks across generation and decoding.
- [ComfyUI offloading: when moving data to RAM helps](https://retrivium.ai/journal/comfyui-gpu-offload.md): Evaluate ComfyUI offloading with the installed Dynamic VRAM behavior, RAM and disk observations, repeated jobs and full-workflow timing.
- [Multiple GPUs for ComfyUI: one workflow or separate queues?](https://retrivium.ai/journal/comfyui-multi-gpu.md): Compare independent ComfyUI GPU workers with supported multi-device graph placement, preserving queue, storage and per-device memory measurements.
- [ComfyUI in the cloud: keeping models, workflows and outputs](https://retrivium.ai/journal/comfyui-cloud-persistence.md): Preserve ComfyUI cloud models, node versions, workflows, inputs and outputs with an explicit storage map and a tested replacement-instance restore.
- [Stable Diffusion GPU requirements: resolution, batch and weights](https://retrivium.ai/journal/stable-diffusion-gpu-requirements.md): Estimate Stable Diffusion GPU memory from the actual pipeline, resolution, batch, precision, extra components and VAE stage, then test useful outputs.
- [Benchmarking GPUs for Stable Diffusion reproducibly](https://retrivium.ai/journal/stable-diffusion-gpu-benchmark.md): Benchmark Stable Diffusion GPUs with fixed pipeline settings, separate cold and warm timings, complete-image throughput and memory-aware comparisons.
- [LoRA and QLoRA: understanding fine-tuning memory](https://retrivium.ai/journal/lora-qlora-memory.md): Compare full fine-tuning, LoRA and QLoRA by trainable parameters, base-weight format, activations, optimizer state and complete-step memory.
- [A bounded PEFT and LoRA experiment on your GPU](https://retrivium.ai/journal/peft-lora-gpu-budget.md): Plan a small PEFT and LoRA experiment with authorized data, a held-out baseline, measured training steps and a verified saved adapter.
- [A 128 GB RAM server for LLMs: useful roles beyond VRAM](https://retrivium.ai/journal/server-128gb-ram-llm.md): Find useful roles for a 128 GB RAM server across CPU inference, supported offloading, document preparation and retrieval without confusing RAM with VRAM.
- [256 GB RAM for RAG: when the index justifies the capacity](https://retrivium.ai/journal/server-256gb-ram-rag.md): Size a 256 GB RAM RAG server from vectors, indexes, payload, replicas, updates and concurrent queries, then validate a representative collection.
- [An inference API conformance matrix for providers](https://retrivium.ai/journal/provider-api-conformance-matrix.md): Build a verifiable inference API compatibility matrix covering parameters, response modes, fixtures, versions and the limits of provider integration evidence.
- [Unsupported inference parameters: rejection, ignoring and the contract](https://retrivium.ai/journal/provider-unsupported-parameter-policy.md): Define inference API behavior for unsupported parameters through explicit rejection, documented ignoring and tests that distinguish acceptance from application.
- [Absent fields, null and empty strings in an inference API](https://retrivium.ai/journal/provider-json-absent-null-empty.md): Test absent fields, null, empty strings and empty arrays in an inference API with fixtures covering roles, validation and safe normalization boundaries.
- [finish_reason as a provider response state machine](https://retrivium.ai/journal/provider-finish-reason-state-machine.md): Model finish_reason and native_finish_reason as state transitions covering choice completion, accounting frames, failures and valid streaming sequences.
- [Streaming tool calls: assembling arguments by index and ID](https://retrivium.ai/journal/provider-streamed-tool-argument-assembly.md): Validate streamed tool calls by assembling arguments per index, preserving IDs and preventing execution of incomplete JSON while response fragments arrive.
- [The final usage frame: validating a streaming response contract](https://retrivium.ai/journal/provider-final-usage-frame-contract.md): Validate a final usage chunk without counting completion twice, accounting for choices shape, DONE ordering and differences between external and upstream APIs.
- [Why prompt_tokens differs from tokenizing the visible text](https://retrivium.ai/journal/provider-prompt-token-template-accounting.md): Explain prompt-token differences through chat templates, control tokens and tokenizer revisions, then build a reproducible reconciliation fixture.
- [Output limits and reasoning tokens: the length-termination contract](https://retrivium.ai/journal/provider-output-limit-reasoning-contract.md): Test length termination under output limits with reasoning tokens, empty visible content, distinct counters and reproducible API contract fixtures.
- [Provider content parts: validating structure before generation](https://retrivium.ai/journal/provider-message-content-parts-contract.md): Validate string content and text/image part arrays before model execution using role checks, nested-field fixtures and explicit capability boundaries.
- [Provider structured output: testing JSON and schema conformance separately](https://retrivium.ai/journal/provider-structured-output-conformance-tests.md): Test provider structured output across JSON syntax, required properties, types, extra fields and the actual support boundary of the selected backend.
- [The logprobs contract: aligning tokens and returned scores](https://retrivium.ai/journal/provider-logprobs-response-consistency.md): Check logprobs and top_logprobs in an inference API across opt-in behavior, output-position alignment, streaming and limits on interpreting scores.
- [Model aliases and revisions: provider response identity](https://retrivium.ai/journal/provider-model-alias-revision-identity.md): Connect a public model alias to its artifact revision, tokenizer and chat template through response identity checks and a verifiable release record.
- [SSE and UTF-8: a network chunk is not a JSON event](https://retrivium.ai/journal/provider-sse-utf8-chunk-boundaries.md): Understand why network reads are not SSE events and preserve UTF-8 across chunks with incremental decoding, framing, fragmentation fixtures and bounded buffers.
- [SSE completion: blank lines, DONE and unexpected EOF](https://retrivium.ai/journal/provider-sse-terminal-eof-contract.md): Distinguish SSE event completion, DONE and HTTP closure using minimal traces, unexpected EOF cases, usage checks and explicit completeness states.
- [SSE heartbeats and idle timeouts: what keeps a connection alive](https://retrivium.ai/journal/provider-sse-heartbeat-timeout-budget.md): Relate SSE comments, heartbeats and idle timeouts while measuring useful-output delays separately and testing the actual reverse-proxy configuration.
- [Slow SSE clients: backpressure and bounded memory](https://retrivium.ai/journal/provider-sse-slow-reader-backpressure.md): Test inference streams with slow readers through backpressure, bounded queues and memory, transport flow control and independently verified generation cancellation.
- [Testing SSE buffering at a reverse proxy](https://retrivium.ai/journal/provider-proxy-sse-buffering-test.md): Measure reverse-proxy SSE buffering through direct and proxied paths, proxy_buffering, X-Accel-Buffering and an event-arrival timeline.
- [HTTP response integrity: Content-Length, chunked transfer and truncation](https://retrivium.ai/journal/provider-http-message-framing-integrity.md): Distinguish HTTP body integrity from SSE completion through Content-Length, chunked transfer, premature closure and controlled local fixtures.
- [HTTP/2 GOAWAY during inference endpoint updates](https://retrivium.ai/journal/provider-http2-goaway-draining.md): Test HTTP/2 GOAWAY during inference updates through last-stream-ID, accepted requests, ambiguous POST outcomes and a bounded draining experiment.
- [SSE reconnection does not imply resuming an LLM generation](https://retrivium.ai/journal/provider-sse-reconnect-generation-resume.md): Explain why SSE reconnect and Last-Event-ID do not guarantee LLM generation resumption across EventSource, POST fetch, replay and deduplication boundaries.
- [Request cancellation: testing the full client-to-engine chain](https://retrivium.ai/journal/provider-client-disconnect-cancellation-chain.md): Verify inference cancellation across client abort, proxy behavior, engine operations, in-flight counters and resource cleanup without assuming propagation.
- [Graceful inference-server termination with active streams](https://retrivium.ai/journal/provider-graceful-termination-active-streams.md): Terminate an inference server with active SSE through admission shutdown, draining, preStop, grace periods and checks of actual per-request outcomes.
- [Request deadlines: budgeting queueing, prefill and streaming](https://retrivium.ai/journal/provider-request-deadline-stage-budget.md): Budget inference request deadlines across queueing, prefill and output while distinguishing absolute duration, idle timeout, cancellation and observable boundaries.
- [HTTP body limits and token limits: separate inference API checks](https://retrivium.ai/journal/provider-request-body-size-limits.md): Separate HTTP body limits, JSON parsing and model context budgets with staged validation, compressed-input checks, fixtures and accurate rejection classification.
- [Provider overload: Retry-After as part of the contract](https://retrivium.ai/journal/provider-overload-retry-after-contract.md): Describe inference overload before SSE commitment through rate policy, Retry-After, bounded retries and tests of the provider’s actual rejection contract.
- [Retrying generation POSTs: idempotency must be explicit](https://retrivium.ai/journal/provider-post-retry-idempotency-ledger.md): Design generation POST retries without assumed idempotency by defining ambiguous outcomes, request ledgers, deduplication scope and testable interface behavior.
- [Provider admission control: bound the queue before latency grows](https://retrivium.ai/journal/provider-admission-queue-budget.md): Bound inference admission through rate gates, in-flight limits, engine queues, controlled bursts and observable reasons for early rejection.
- [Keeping model capabilities and rollout state consistent](https://retrivium.ai/journal/provider-capability-rollout-consistency.md): Keep advertised model capabilities aligned with replica rollout through feature matrices, readiness checks, tools and schema fixtures, publication and rollback.
- [Startup, readiness and liveness for a slow-loading model server](https://retrivium.ai/journal/provider-startup-readiness-liveness-separation.md): Separate startup, readiness and liveness during long model loading through distinct criteria, thresholds, restart failure modes and a bounded validation scenario.
- [Monotonic clocks for inference API latency measurements](https://retrivium.ai/journal/provider-monotonic-latency-measurement.md): Measure inference API latency with monotonic clocks while separating in-process durations, wall-clock correlation, host boundaries and event-record semantics.
- [First byte, first chunk and first token are different latencies](https://retrivium.ai/journal/provider-first-byte-first-chunk-first-token.md): Distinguish first byte, first chunk and first token in inference APIs across comments, role deltas, reasoning, useful content and versioned latency SLIs.
- [Inter-token gaps and throughput: do not average different quantities](https://retrivium.ai/journal/provider-intertoken-gap-throughput-metrics.md): Distinguish TPOT, SSE event gaps and aggregate throughput through measurement boundaries, zero- and one-token outputs, weighting and a reproducible example.
- [Fleet p95: aggregate histograms rather than precomputed percentiles](https://retrivium.ai/journal/provider-latency-histogram-aggregation.md): Calculate p95 across inference replicas with histogram aggregation, compatible boundaries and cohort filters rather than averaging replica percentiles.
- [A successful stream for an SLO: define the event and denominator](https://retrivium.ai/journal/provider-stream-success-sli-denominator.md): Define a successful inference stream for SLOs across accepted, rejected, completed, failed and cancelled work, partial answers and explicit good-event denominators.
- [Inference SLO burn rates: multi-window alerting](https://retrivium.ai/journal/provider-error-budget-burn-rate-alerts.md): Build inference SLO burn-rate alerts using error budgets, multiple windows, low-traffic handling and rule tests against synthetic time series.
- [Provider metric cardinality: request IDs do not belong in labels](https://retrivium.ai/journal/provider-metric-cardinality-budget.md): Plan inference-provider metric cardinality through label products, model and outcome dimensions, histogram buckets and unique IDs kept in traces instead.
- [Request IDs and trace context across gateway, API and engine](https://retrivium.ai/journal/provider-request-id-trace-context.md): Separate generation IDs, internal request IDs and trace/span IDs through uniqueness scopes, propagation, safe correlation and missing-context fixtures.
- [OpenTelemetry GenAI: pin the semantic-convention version](https://retrivium.ai/journal/provider-otel-genai-semconv-versioning.md): Pin OpenTelemetry GenAI convention versions across the current official repository, Development status, instrumentation scope, metric names and exporter migration tests.
- [Inference API telemetry without default prompt capture](https://retrivium.ai/journal/provider-telemetry-content-redaction.md): Observe inference APIs without default prompt capture using metadata allowlists, nested tool arguments, error paths and exported-payload redaction tests.
- [From a slow histogram bucket to a trace through an exemplar](https://retrivium.ai/journal/provider-metric-exemplar-trace-link.md): Connect a slow histogram observation to a trace through exemplars while accounting for sampling, trace availability, metadata limits and navigation tests.
- [Terminal request records: reconcile stream, usage and logs](https://retrivium.ai/journal/provider-terminal-request-record-consistency.md): Build one terminal inference request record, reconcile stream completion and usage, and avoid duplicate outcomes when telemetry events are redelivered.
- [Golden inference API fixtures: test the contract rather than prose](https://retrivium.ai/journal/provider-golden-contract-fixtures.md): A compact versioned JSON and SSE fixture suite for inference API contracts, covering required fields, terminal states, privacy and baseline updates.
- [SSE property tests: one event stream under any byte partition](https://retrivium.ai/journal/provider-sse-fragmentation-property-tests.md): Test an SSE parser with randomized byte boundaries, stable event invariants, Unicode, CRLF cases, minimal counterexamples and bounded execution.
- [Differential API testing across two inference engines](https://retrivium.ai/journal/provider-engine-differential-api-tests.md): Differential tests for two inference engines, comparing schemas and terminal states with an explicit differences register separate from text quality.
- [Open and closed load models for an inference API](https://retrivium.ai/journal/provider-open-closed-load-tests.md): Why fixed concurrency can hide inference API overload, and how to compare open arrivals with a closed load model in a bounded experiment.
- [A bounded cancellation soak test for request and connection leaks](https://retrivium.ai/journal/provider-cancel-soak-resource-leaks.md): A bounded inference completion and cancellation test with resource baselines, recovery pauses, stop conditions and investigation of suspicious growth.
- [Local fault injection: interrupting an upstream at a known stream boundary](https://retrivium.ai/journal/provider-midstream-fault-injection-tests.md): A local fake upstream for SSE faults before headers, after headers and after content, with outcome classification, bounded retries and a replay artifact.
- [Seeds and fingerprints: testing an API reproducibility claim](https://retrivium.ai/journal/provider-seed-fingerprint-contract-tests.md): How to test seed and system_fingerprint in an inference API, distinguishing field support, fixed environment repeatability and limits across versions.
- [A token-budgeted synthetic probe for an inference endpoint](https://retrivium.ai/journal/provider-bounded-synthetic-probe-contract.md): An external inference endpoint probe with a small request, token and frequency limits, schema and completion checks, and clear boundaries from user SLOs.
- [Changing an inference API contract: deprecation and migration checks](https://retrivium.ai/journal/provider-api-contract-deprecation-migration.md): How to evolve an inference API contract using schema diffs, client compatibility checks, Deprecation semantics and tested JSON and SSE fixture migrations.
- [vLLM chat templates: fix string versus OpenAI content formats](https://retrivium.ai/journal/vllm-chat-content-format.md): Fix a content format mismatch by aligning the client message with the model's chat template.
- [Match prompt token IDs between Hugging Face and vLLM](https://retrivium.ai/journal/vllm-render-token-parity.md): Identical prompt text does not guarantee identical input tokens. To compare Hugging Face with vLLM, keep one message history, the same tokenizer revision, and the actual token IDs produced after templating.
- [Why generation_config.json changes vLLM generation defaults](https://retrivium.ai/journal/vllm-generation-config-precedence.md): vLLM responses can change after a model-repository update because of generation_config.json, even when the launch command stays identical.
- [vLLM stop strings and EOS: diagnose premature response endings](https://retrivium.ai/journal/vllm-stop-eos-contract.md): Diagnose an early vLLM response ending by identifying the stopping mechanism: a stop string, an ID in stop_token_ids, and EOS serve different purposes.
- [Migrate vLLM structured-output backends without schema regressions](https://retrivium.ai/journal/vllm-structured-backend-migration.md): Changing a vLLM structured-output backend requires fresh schema and regular-expression tests.
- [Align vLLM tool parsers, chat templates and tool-result messages](https://retrivium.ai/journal/vllm-tool-parser-template-contract.md): Reliable vLLM tool calling requires a compatible parser, chat template, and conversation history containing tool results.
- [Validate reasoning and answer boundaries in vLLM parser output](https://retrivium.ai/journal/vllm-reasoning-parser-boundaries.md): A vLLM reasoning parser separates generated text into reasoning and final-answer fields.
- [Validate a draft and target model pair for vLLM speculative decoding](https://retrivium.ai/journal/vllm-draft-target-validation.md): Validate a vLLM speculative-decoding draft and target as one configuration, rather than choosing a small model by size alone.
- [Evaluate vLLM n-gram speculation without a draft model](https://retrivium.ai/journal/vllm-ngram-speculation-evaluation.md): vLLM n-gram speculation proposes continuations from matches within the prompt without loading a separate draft model.
- [Tune vLLM chunked prefill token budgets for mixed traffic](https://retrivium.ai/journal/vllm-chunked-prefill-token-budget.md): Tune the vLLM chunked-prefill token budget against a mixture of new long prompts and requests already generating answers.
- [Bound vLLM request queues and prefill token backlogs](https://retrivium.ai/journal/vllm-admission-token-backlog.md): Bound vLLM backlog using the work accepted by the serving system: request count and pending prefill volume are different quantities.
- [Manage vLLM torch.compile caches across releases](https://retrivium.ai/journal/vllm-compile-cache-release.md): A vLLM compilation cache can shorten a compatible repeat startup, but copying its directory does not establish compatibility with a new release.
- [Detect vLLM CUDA Graph mode fallbacks after upgrades](https://retrivium.ai/journal/vllm-cuda-graph-mode-compatibility.md): After upgrading vLLM, inspect the effective CUDA Graph mode rather than only the requested setting.
- [Choose vLLM safetensors loading strategies for local disks and NFS](https://retrivium.ai/journal/vllm-safetensors-load-strategy.md): Choose a vLLM safetensors loading strategy from filesystem behavior and available RAM, not model quality.
- [Validate vLLM sleep and wake readiness transitions](https://retrivium.ai/journal/vllm-sleep-wake-readiness.md): vLLM sleep mode needs an explicit procedure for returning a model to service. A live API process does not establish that weights are restored and KV memory is allocated.
- [Validate target-specific EAGLE draft checkpoints in SGLang](https://retrivium.ai/journal/sglang-eagle-draft-contract.md): An EAGLE draft checkpoint in SGLang must match the particular target model and method implementation.
- [Diagnose tokenizer and detokenizer worker bottlenecks in SGLang](https://retrivium.ai/journal/sglang-tokenizer-worker-bottleneck.md): When SGLang accepts requests slowly while the GPU is idle, inspect tokenizer and detokenizer workers before changing GPU memory fraction.
- [Tune SGLang schedule conservativeness for output-length uncertainty](https://retrivium.ai/journal/sglang-schedule-conservativeness.md): Tune SGLang schedule conservativeness around uncertainty in future answer length, not as a substitute for the GPU memory budget.
- [Compare SGLang Radix eviction policies under hot-set churn](https://retrivium.ai/journal/sglang-radix-eviction-hotset.md): Choose a SGLang Radix-cache eviction policy from the pattern of prefix reuse. LRU, LFU, and SLRU can behave differently when a stable hot set encounters a burst of one-off inputs.
- [Diagnose KV transfer stalls in SGLang prefill-decode disaggregation](https://retrivium.ai/journal/sglang-pd-kv-transfer-diagnosis.md): With SGLang prefill-decode disaggregation, separate KV-transfer delay from computation on both stages.
- [Validate FP8 and FP4 GEMM backends against SGLang checkpoints](https://retrivium.ai/journal/sglang-quantized-gemm-backends.md): Check SGLang FP8 or FP4 compatibility across the checkpoint, scaling recipe, GPU architecture, and GEMM backend.
- [Why temperature zero is not enough for deterministic SGLang output](https://retrivium.ai/journal/sglang-deterministic-batch-invariance.md): Temperature zero in SGLang does not guarantee identical output when batch composition changes.
- [Separate multimodal encoder data parallelism from SGLang language-model TP](https://retrivium.ai/journal/sglang-multimodal-encoder-dp.md): SGLang multimodal-encoder data parallelism is different from tensor parallelism in the language-model component.
- [Correlate SGLang request latency across workers with OpenTelemetry](https://retrivium.ai/journal/sglang-opentelemetry-request-traces.md): SGLang tracing can explain one request's latency across workers when aggregate TTFT is insufficient.
- [Gate SGLang readiness on actual checkpoint-engine weights](https://retrivium.ai/journal/sglang-checkpoint-readiness-gate.md): When SGLang uses a checkpoint engine, distinguish process readiness from receiving actual weights.
- [Make llama.cpp automatic fit settings reproducible](https://retrivium.ai/journal/llama-cpp-fit-reproducible-settings.md): llama.cpp automatic fit can adjust unspecified settings to fit available device memory.
- [Reconcile llama.cpp unified KV pools and per-slot context limits](https://retrivium.ai/journal/llama-cpp-unified-kv-slot-limits.md): Account for a llama.cpp shared KV pool separately from the context of one parallel slot.
- [Manage resident models and eviction in the llama.cpp router](https://retrivium.ai/journal/llama-cpp-router-model-residency.md): Validate the llama.cpp model router through actual residency and child-process state.
- [Validate JSON Schema to GBNF conversion in llama.cpp](https://retrivium.ai/journal/llama-cpp-json-schema-gbnf-validation.md): Converting JSON Schema to GBNF for llama.cpp does not establish that every schema constraint is enforced.
- [Validate llama.cpp slot prompt-cache save and restore files](https://retrivium.ai/journal/llama-cpp-slot-cache-persistence.md): Validate llama.cpp slot prompt-cache persistence as a save-and-restore lifecycle for a specific state.
- [Tune llama.cpp CPU threads separately for prefill and decode](https://retrivium.ai/journal/llama-cpp-prefill-decode-cpu-threads.md): Tune llama.cpp CPU threads for prompt processing and token generation separately.
- [Build llama.cpp CUDA binaries for multiple GPU architectures](https://retrivium.ai/journal/llama-cpp-portable-cuda-build.md): Before moving a llama.cpp CUDA binary to another GPU, check its compiled architecture targets.
- [Verify split GGUF shards before merging a llama.cpp model](https://retrivium.ai/journal/llama-cpp-split-gguf-integrity.md): Accept a split GGUF as a complete shard set rather than one plausibly named file.
- [Validate llama.cpp language-model and mmproj projector pairs](https://retrivium.ai/journal/llama-cpp-mmproj-pair-validation.md): A llama.cpp language GGUF and mmproj must form a supported multimodal pair. A projector from a similar model is not interchangeable merely because its file size or family name resembles the intended artifact.
- [Use llama-bench to isolate prefill and generation regressions](https://retrivium.ai/journal/llama-bench-phase-regression.md): To localize a llama.cpp regression, separate prompt processing from token generation with llama-bench first.
- [Handle final completion correctly in Triton decoupled streaming](https://retrivium.ai/journal/triton-decoupled-stream-completion.md): In Triton decoupled mode, identify completion through the protocol signal rather than the last nonempty text fragment.
- [Identify which scheduler owns batching in Triton and TensorRT-LLM](https://retrivium.ai/journal/triton-llmapi-batching-boundaries.md): For Triton and TensorRT-LLM, first identify which component forms batches in the selected deployment path.
- [Define variable-length token input contracts for Triton ragged batching](https://retrivium.ai/journal/triton-ragged-token-input-contract.md): Triton ragged batching needs an agreed variable-length contract among client, model, and backend.
- [Verify Triton generation cancellation beyond a client disconnect](https://retrivium.ai/journal/triton-inference-cancellation.md): Validate Triton cancellation through a supported protocol action and terminated processing, not merely a closed client window.
- [Migrate legacy Triton TensorRT-LLM engine builds to the LLM API](https://retrivium.ai/journal/tensorrt-llm-triton-llmapi-migration.md): Start a Triton TensorRT-LLM migration by identifying the deployment path rather than automatically repeating trtllm-build.
- [Check TensorRT engine portability across GPUs and runtime versions](https://retrivium.ai/journal/tensorrt-plan-portability.md): A serialized TensorRT engine is not a universal file for every NVIDIA GPU and runtime release.
- [Coordinate Triton model reloads, control modes and version policies](https://retrivium.ai/journal/triton-model-control-version-policy.md): Validate Triton repository updates together with model-control mode and version policy.
- [Validate tokenizer, inference and postprocessing contracts in Triton ensembles](https://retrivium.ai/journal/triton-tokenizer-ensemble-contract.md): Validate a Triton ensemble as a tensor-dataflow graph connecting preprocessing, inference, and postprocessing.
- [Separate Triton queue, input, inference and output latency](https://retrivium.ai/journal/triton-latency-stage-diagnosis.md): Diagnose Triton latency through queueing, input processing, inference, and output processing.
- [Validate ModelOpt quantized checkpoint scales and export provenance](https://retrivium.ai/journal/modelopt-quantized-checkpoint-provenance.md): Accept a quantized ModelOpt checkpoint together with scales, quantization configuration, and calibration provenance.
- [Prepare a complete pinned Hugging Face snapshot for offline serving](https://retrivium.ai/journal/huggingface-pinned-offline-snapshot.md): Offline LLM startup requires a complete, consistent model snapshot rather than only downloaded weights.
- [Pin and review custom model code before enabling trust_remote_code](https://retrivium.ai/journal/huggingface-remote-code-review.md): trust_remote_code allows a loader to use Python implementation code from a custom model repository.
- [Validate safetensors weight artifacts separately from repository code](https://retrivium.ai/journal/safetensors-artifact-validation.md): Distinguish safetensors from pickle by serialization mechanism, and validate weight integrity separately.
- [Keep tokenizer vocabulary, special tokens and chat templates in one release](https://retrivium.ai/journal/tokenizer-artifact-release-manifest.md): Accept a tokenizer release as a consistent vocabulary, special-token, and chat-template package.
- [Validate vLLM automatic and explicitly pinned attention backends](https://retrivium.ai/journal/vllm-attention-backend-acceptance.md): Accept a vLLM attention backend through its effective selection and support for the model configuration.
- [Container stalls without OOM: reading memory.high and memory.events](https://retrivium.ai/journal/cgroup-v2-memory-high-events.md): Diagnose container stalls without OOM: reading memory.high and memory.events. Evidence to collect, a worked operational example and recovery checks.
- [Idle GPU, throttled CPU: diagnosing container CPU quota](https://retrivium.ai/journal/cgroup-cpu-throttling-gpu-feeder.md): Diagnose idle GPU, throttled CPU: diagnosing container CPU quota. Evidence to collect, a worked operational example and recovery checks.
- [Cannot create thread in a container: checking pids.max and pids.events](https://retrivium.ai/journal/container-pids-limit-thread-errors.md): Diagnose cannot create thread in a container: checking pids.max and pids.events. Evidence to collect, a worked operational example and recovery checks.
- [Out of /dev/shm: setting a GPU container IPC budget](https://retrivium.ai/journal/container-dev-shm-ipc-budget.md): Diagnose out of /dev/shm: setting a GPU container IPC budget. Evidence to collect, a worked operational example and recovery checks.
- [OOMKilled or Evicted: identifying why a Pod stopped](https://retrivium.ai/journal/kubernetes-oomkilled-vs-evicted.md): Diagnose oOMKilled or Evicted: identifying why a Pod stopped. Evidence to collect, a worked operational example and recovery checks.
- [High latency at moderate utilization: diagnosing Linux PSI](https://retrivium.ai/journal/linux-psi-inference-stalls.md): Diagnose high latency at moderate utilization: diagnosing Linux PSI. Evidence to collect, a worked operational example and recovery checks.
- [Too many open files in a container: finding the exhausted limit](https://retrivium.ai/journal/container-file-descriptor-exhaustion.md): Diagnose too many open files in a container: finding the exhausted limit. Evidence to collect, a worked operational example and recovery checks.
- [Container blocked on stdout: Docker log backpressure and rotation](https://retrivium.ai/journal/docker-log-rotation-application-blocking.md): Diagnose container blocked on stdout: Docker log backpressure and rotation. Evidence to collect, a worked operational example and recovery checks.
- [Why docker stop cannot stop a worker: PID 1, signals and zombies](https://retrivium.ai/journal/container-pid1-signals-zombies.md): Diagnose why docker stop cannot stop a worker: PID 1, signals and zombies. Evidence to collect, a worked operational example and recovery checks.
- [Host swap exists but the container cannot use it: checking limits](https://retrivium.ai/journal/container-swap-limit-mismatch.md): Diagnose host swap exists but the container cannot use it: checking limits. Evidence to collect, a worked operational example and recovery checks.
- [Pod restarts while loading: configuring a startup probe](https://retrivium.ai/journal/kubernetes-startup-probe-restart-loop.md): Diagnose pod restarts while loading: configuring a startup probe. Evidence to collect, a worked operational example and recovery checks.
- [preStop consumes the grace period: budgeting Pod termination](https://retrivium.ai/journal/kubernetes-prestop-termination-budget.md): Diagnose preStop consumes the grace period: budgeting Pod termination. Evidence to collect, a worked operational example and recovery checks.
- [kubectl drain blocked by a PDB: what a disruption budget protects](https://retrivium.ai/journal/kubernetes-pdb-voluntary-disruption.md): Diagnose kubectl drain blocked by a PDB: what a disruption budget protects. Evidence to collect, a worked operational example and recovery checks.
- [GPU Deployment rollout stuck: maxSurge without spare capacity](https://retrivium.ai/journal/kubernetes-gpu-rollout-surge-deadlock.md): Diagnose gPU Deployment rollout stuck: maxSurge without spare capacity. Evidence to collect, a worked operational example and recovery checks.
- [Pod is Terminating but still receives traffic: checking EndpointSlices](https://retrivium.ai/journal/kubernetes-terminating-endpoints.md): Diagnose pod is Terminating but still receives traffic: checking EndpointSlices. Evidence to collect, a worked operational example and recovery checks.
- [ImagePullBackOff before GPU startup: image names, registry and Secrets](https://retrivium.ai/journal/kubernetes-imagepullbackoff-registry-auth.md): Diagnose imagePullBackOff before GPU startup: image names, registry and Secrets. Evidence to collect, a worked operational example and recovery checks.
- [Init container downloads an artifact again: making preparation idempotent](https://retrivium.ai/journal/kubernetes-init-artifact-download.md): Diagnose init container downloads an artifact again: making preparation idempotent. Evidence to collect, a worked operational example and recovery checks.
- [Resource stuck Terminating: diagnosing a Kubernetes finalizer](https://retrivium.ai/journal/kubernetes-finalizer-stuck-deletion.md): Diagnose resource stuck Terminating: diagnosing a Kubernetes finalizer. Evidence to collect, a worked operational example and recovery checks.
- [Node NotReady but the Pod does not move: tolerations and eviction](https://retrivium.ai/journal/kubernetes-node-notready-taint-delay.md): Diagnose node NotReady but the Pod does not move: tolerations and eviction. Evidence to collect, a worked operational example and recovery checks.
- [No shell in the image: debugging a Pod with an ephemeral container](https://retrivium.ai/journal/kubernetes-ephemeral-container-debug.md): Diagnose no shell in the image: debugging a Pod with an ephemeral container. Evidence to collect, a worked operational example and recovery checks.
- [NVIDIA_VISIBLE_DEVICES vs CUDA_VISIBLE_DEVICES: why GPU indexes differ](https://retrivium.ai/journal/nvidia-visible-vs-cuda-visible-devices.md): Diagnose nVIDIA_VISIBLE_DEVICES vs CUDA_VISIBLE_DEVICES: why GPU indexes differ. Evidence to collect, a worked operational example and recovery checks.
- [CDI device not found: checking NVIDIA device names and specifications](https://retrivium.ai/journal/nvidia-cdi-device-selection.md): Diagnose cDI device not found: checking NVIDIA device names and specifications. Evidence to collect, a worked operational example and recovery checks.
- [NVML Unknown Error after daemon-reload: when a container loses its GPU](https://retrivium.ai/journal/nvidia-container-nvml-systemd-reload.md): Diagnose nVML Unknown Error after daemon-reload: when a container loses its GPU. Evidence to collect, a worked operational example and recovery checks.
- [nvidia-smi works but CUDA does not: checking compute and utility capabilities](https://retrivium.ai/journal/nvidia-driver-capabilities-compute-utility.md): Diagnose nvidia-smi works but CUDA does not: checking compute and utility capabilities. Evidence to collect, a worked operational example and recovery checks.
- [Slow DNS in a Pod: search domains and ndots](https://retrivium.ai/journal/kubernetes-dns-ndots-search-latency.md): Diagnose slow DNS in a Pod: search domains and ndots. Evidence to collect, a worked operational example and recovery checks.
- [Some DNS queries fail: why TCP and UDP port 53 both matter](https://retrivium.ai/journal/kubernetes-dns-udp-tcp-policy.md): Diagnose some DNS queries fail: why TCP and UDP port 53 both matter. Evidence to collect, a worked operational example and recovery checks.
- [Ping works but transfers stall: recognizing an MTU black hole](https://retrivium.ai/journal/network-mtu-blackhole-diagnostics.md): Diagnose ping works but transfers stall: recognizing an MTU black hole. Evidence to collect, a worked operational example and recovery checks.
- [New connections disappear: checking Linux conntrack pressure](https://retrivium.ai/journal/linux-conntrack-table-pressure.md): Diagnose new connections disappear: checking Linux conntrack pressure. Evidence to collect, a worked operational example and recovery checks.
- [Server returns the wrong certificate: SNI, SAN and the default virtual host](https://retrivium.ai/journal/tls-sni-san-wrong-certificate.md): Diagnose server returns the wrong certificate: SNI, SAN and the default virtual host. Evidence to collect, a worked operational example and recovery checks.
- [HTTPS works on the host but not in the container: CA trust and certificate chains](https://retrivium.ai/journal/container-ca-chain-validation.md): Diagnose hTTPS works on the host but not in the container: CA trust and certificate chains. Evidence to collect, a worked operational example and recovery checks.
- [Wrong time after restart: TLS errors and misleading log chronology](https://retrivium.ai/journal/clock-skew-tls-telemetry.md): Diagnose wrong time after restart: TLS errors and misleading log chronology. Evidence to collect, a worked operational example and recovery checks.
- [Prometheus relabel_configs vs metric_relabel_configs: where to filter data](https://retrivium.ai/journal/prometheus-target-vs-metric-relabeling.md): Diagnose prometheus relabel_configs vs metric_relabel_configs: where to filter data. Evidence to collect, a worked operational example and recovery checks.
- [Prometheus remote_write falls behind: WAL, queues and shards](https://retrivium.ai/journal/prometheus-remote-write-wal-backlog.md): Diagnose prometheus remote_write falls behind: WAL, queues and shards. Evidence to collect, a worked operational example and recovery checks.
- [OpenTelemetry Collector drops data during backend outages: queues and limits](https://retrivium.ai/journal/otel-collector-backpressure.md): Diagnose openTelemetry Collector drops data during backend outages: queues and limits. Evidence to collect, a worked operational example and recovery checks.
- [Telemetry never reaches the Collector: OTLP gRPC, HTTP and endpoints](https://retrivium.ai/journal/otlp-protocol-endpoint-mismatch.md): Diagnose telemetry never reaches the Collector: OTLP gRPC, HTTP and endpoints. Evidence to collect, a worked operational example and recovery checks.
- [A metric disappeared from the graph: staleness, up and zero values](https://retrivium.ai/journal/prometheus-scrape-staleness.md): Diagnose a metric disappeared from the graph: staleness, up and zero values. Evidence to collect, a worked operational example and recovery checks.
- [Head vs tail sampling: why a trace splits across Collectors](https://retrivium.ai/journal/otel-head-tail-sampling-collector-routing.md): Diagnose head vs tail sampling: why a trace splits across Collectors. Evidence to collect, a worked operational example and recovery checks.
- [Alerts keep disappearing: for, pending and keep_firing_for](https://retrivium.ai/journal/prometheus-alert-pending-flapping.md): Diagnose alerts keep disappearing: for, pending and keep_firing_for. Evidence to collect, a worked operational example and recovery checks.
- [Rate metrics jump after restart: counter resets and rate before sum](https://retrivium.ai/journal/prometheus-counter-reset-rate.md): Diagnose rate metrics jump after restart: counter resets and rate before sum. Evidence to collect, a worked operational example and recovery checks.
- [kubectl logs --previous is not enough: Pod log rotation and collection](https://retrivium.ai/journal/kubernetes-log-rotation-restarts.md): Diagnose kubectl logs --previous is not enough: Pod log rotation and collection. Evidence to collect, a worked operational example and recovery checks.
- [Deployment rollback starts the new image: the mutable tag problem](https://retrivium.ai/journal/kubernetes-rollback-mutable-image-tag.md): Diagnose deployment rollback starts the new image: the mutable tag problem. Evidence to collect, a worked operational example and recovery checks.
- [The digest matches, but whom do you trust: verifying container image signatures](https://retrivium.ai/journal/artifact-signature-verification.md): Diagnose the digest matches, but whom do you trust: verifying container image signatures. Evidence to collect, a worked operational example and recovery checks.
- [ConfigMap changed but the process sees old values: env, volumes and subPath](https://retrivium.ai/journal/kubernetes-configmap-update-reload.md): Diagnose configMap changed but the process sees old values: env, volumes and subPath. Evidence to collect, a worked operational example and recovery checks.
- [Secret updated but credentials are still old: file rotation and reloading](https://retrivium.ai/journal/kubernetes-secret-volume-rotation.md): Diagnose secret updated but credentials are still old: file rotation and reloading. Evidence to collect, a worked operational example and recovery checks.
- [ServiceAccount token expired: audiences and projected token rotation](https://retrivium.ai/journal/kubernetes-projected-serviceaccount-token.md): Diagnose serviceAccount token expired: audiences and projected token rotation. Evidence to collect, a worked operational example and recovery checks.
- [GPU works as root but not in a rootless container: runtime and device permissions](https://retrivium.ai/journal/rootless-nvidia-cdi-permissions.md): Diagnose gPU works as root but not in a rootless container: runtime and device permissions. Evidence to collect, a worked operational example and recovery checks.
- [Operation not permitted in a GPU container: checking seccomp](https://retrivium.ai/journal/container-seccomp-permission-denied.md): Diagnose operation not permitted in a GPU container: checking seccomp. Evidence to collect, a worked operational example and recovery checks.
- [Pod stays unready after deny-all: init container network dependencies](https://retrivium.ai/journal/kubernetes-egress-networkpolicy-bootstrap.md): Diagnose pod stays unready after deny-all: init container network dependencies. Evidence to collect, a worked operational example and recovery checks.
- [No matching manifest or exec format error: checking container image platforms](https://retrivium.ai/journal/container-image-platform-manifest-errors.md): Diagnose no matching manifest or exec format error: checking container image platforms. Evidence to collect, a worked operational example and recovery checks.
- [Read-only container will not start: where to allow temporary and cache writes](https://retrivium.ai/journal/read-only-container-writable-caches.md): Diagnose read-only container will not start: where to allow temporary and cache writes. Evidence to collect, a worked operational example and recovery checks.
- [GPU ECC: volatile and aggregate error counters](https://retrivium.ai/journal/gpu-ecc-volatile-aggregate.md): Read GPU ECC counters with their type, location and reset history. A practical evidence table separates new increments, historical totals and unavailable fields.
- [GPU row remapping: pending state, remapped rows and spares](https://retrivium.ai/journal/gpu-row-remapping-state.md): Interpret GPU row-remapping counts, pending state and spare information without confusing them with retired pages or a universal hardware replacement threshold.
- [GPU Xid errors: reconstructing an incident timeline](https://retrivium.ai/journal/gpu-xid-timeline.md): Build an actionable GPU Xid incident timeline from device identity, original logs and workload context, while separating observed sequence from a root-cause hypothesis.
- [Xid 79: evidence to retain when a GPU falls off the bus](https://retrivium.ai/journal/gpu-xid-79-event-record.md): Investigate Xid 79 using PCIe context, original logs and recovery history. Preserve evidence before deciding which component needs further examination.
- [GPU clock reductions: reading simultaneous event reasons](https://retrivium.ai/journal/gpu-clock-event-reasons.md): Decode simultaneous GPU clock event reasons, distinguish unsupported fields and correlate sampled constraints with the workload before changing operating limits.
- [GPU P-states and bursty inference requests](https://retrivium.ai/journal/gpu-pstate-burst-inference.md): Test bursty GPU inference with controlled idle gaps and aligned telemetry. Separate P-state observations from model startup, connection setup and engine warm-up.
- [BAR1 and VRAM: why GPU memory readings differ](https://retrivium.ai/journal/gpu-bar1-vs-framebuffer.md): Separate GPU BAR1 mappings from framebuffer allocations. Diagnose the failed operation with matching units and scope instead of adding two unrelated free-memory values.
- [GPU resets and telemetry counter epochs](https://retrivium.ai/journal/gpu-reset-counter-epochs.md): Design GPU counter epochs across driver changes, resets and missing samples. Validate rate calculations with saved fixtures rather than resetting a live device.
- [DCGM active diagnostics and passive health history](https://retrivium.ai/journal/dcgm-active-passive-evidence.md): Reconcile DCGM active diagnostic results with passive health history using watched systems, retention, test scope and workload conditions instead of a single health label.
- [DCGM diagnostic JSON: Pass, Fail, Skip and schema versions](https://retrivium.ai/journal/dcgm-diagnostic-json-status.md): Parse DCGM diagnostic JSON with pinned versions, retained raw output and separate pass, fail, skip and unknown states. Test the consumer with non-disruptive fixtures.
- [GPU PCIe links: negotiated speed, width and maximum capability](https://retrivium.ai/journal/gpu-pcie-negotiated-link.md): Compare GPU PCIe capability with negotiated generation and width during a controlled transfer, keeping slot allocation and actual application bottlenecks separate.
- [A GPU topology matrix: device proximity and actual measurements](https://retrivium.ai/journal/gpu-topology-distance-matrix.md): Read GPU topology as a device-path map, then test the relevant transfer. Preserve the legend, identities and route used instead of treating distance as bandwidth.
- [GPU peer access: checking each pair and direction](https://retrivium.ai/journal/gpu-peer-access-matrix.md): Build a directed GPU peer-access matrix, then verify the route used by transfers and the inference engine. Keep topology, capability and measured behavior distinct.
- [First touch and NUMA: locating GPU host buffers](https://retrivium.ai/journal/gpu-host-memory-first-touch.md): Measure GPU host-buffer NUMA placement with allocation timing, actual page observations and fixed transfers. CPU affinity alone does not establish where existing pages live.
- [Pinned GPU host memory: setting a page-locked buffer budget](https://retrivium.ai/journal/gpu-pinned-host-memory-budget.md): Budget pinned GPU host memory by live buffers, pinning overhead, host RAM pressure, NUMA placement and verified buffer reuse.
- [CUDA: verifying copy and compute overlap](https://retrivium.ai/journal/gpu-async-copy-overlap.md): Verify CUDA copy and compute overlap through pinned memory, streams, dependencies, a timeline and comparison with a sequential control run.
- [CUDA events and request time: different measurement boundaries](https://retrivium.ai/journal/gpu-cuda-events-wall-time.md): Why CUDA events and HTTP request duration measure different intervals, with host and device boundaries, completion checks and a comparable timing record.
- [NVLink errors: counter deltas and hardware generations](https://retrivium.ai/journal/gpu-nvlink-error-deltas.md): Interpret NVLink errors using counter scope, GPU generation, observation deltas and resets, while distinguishing cumulative counts from BER fields.
- [Resizable BAR: inventorying resources without changing BIOS](https://retrivium.ai/journal/gpu-resizable-bar-discovery.md): A read-only Resizable BAR inventory separating device capability, assigned PCIe resources and BAR1 usage without a universal BIOS prescription.
- [GPU, NVMe and NIC contention on a shared PCIe path](https://retrivium.ai/journal/gpu-shared-pcie-root-contention.md): Test GPU, NVMe and NIC PCIe contention with a path inventory, isolated and concurrent transfers, CPU controls and a bounded reproducible experiment.
- [NVMe Percentage Used: SSD endurance and the metric boundary](https://retrivium.ai/journal/nvme-percentage-used.md): What NVMe Percentage Used means, why 100 does not imply immediate failure, and how to interpret endurance estimates with an SSD history.
- [NVMe unsafe shutdowns and media errors mean different things](https://retrivium.ai/journal/nvme-errors-unsafe-shutdowns.md): Why NVMe unsafe shutdowns, media errors and error log entries need separate interpretation, with definitions, deltas, CLI versions and causal checks.
- [NVMe temperature and variable model-loading time](https://retrivium.ai/journal/nvme-thermal-model-loading.md): Investigate NVMe temperature and model load time using startup phases, cache controls, bounded read-only tests, thermal counters and causal limits.
- [Model caches and SSD endurance: downloads, host writes and NAND](https://retrivium.ai/journal/model-cache-ssd-write-amplification.md): Assess model cache writes without inventing write amplification, separating downloads, temporary files, NVMe host writes and physical NAND telemetry.
- [LLM loading: read-latency tails beyond one SSD speed](https://retrivium.ai/journal/nvme-read-latency-model-load.md): Investigate model-loading variance with declared fio read workloads, latency tails and an application timeline instead of predicting startup from sequential SSD bandwidth.
- [fio buffered and direct reads measure different paths](https://retrivium.ai/journal/fio-buffered-direct-read.md): Compare fio buffered and direct reads with explicit cache history, read-only safeguards and supported I/O settings. Keep filesystem and device boundaries visible.
- [OS page cache and cold model loading: what to record](https://retrivium.ai/journal/model-load-os-page-cache.md): Define cold and warm model-loading scenarios across artifact locality, OS page cache, process startup and device residency without clearing caches on shared production nodes.
- [RAID1 for models: disk availability and version recovery](https://retrivium.ai/journal/raid1-model-backup-boundary.md): Separate RAID1 availability from model-version backup and restoration. Build a recovery map covering pinned artifacts, verification and tested readiness steps.
- [Host RAM ECC and EDAC: separate from GPU memory errors](https://retrivium.ai/journal/host-ram-ecc-edac.md): Host-RAM ECC errors and GPU-memory errors belong to different devices and counters.
- [PCIe AER near a GPU: severity, requester and chronology](https://retrivium.ai/journal/pcie-aer-gpu-evidence.md): Read a PCIe AER report near a GPU through severity, requester identity, and reporting topology.
- [GPU, CPU and server energy: where measurement boundaries lie](https://retrivium.ai/journal/gpu-board-server-power-boundary.md): GPU power, CPU-package energy, and server AC input use different measurement boundaries.
- [GPU power bursts and sparse sampling](https://retrivium.ai/journal/gpu-power-sampling-aliasing.md): Sparse GPU-power snapshots cannot reconstruct every short workload burst. Polling frequency and a sensor's internal window are different properties.
- [GPU power caps: an energy and latency experiment](https://retrivium.ai/journal/gpu-power-cap-latency-frontier.md): Evaluate GPU power caps as an energy-and-latency experiment using approved, supported operating points.
- [Dual PSUs: accounting for A/B inputs and redundancy](https://retrivium.ai/journal/dual-psu-input-accounting.md): With dual PSUs, account for server energy through non-overlapping A and B inputs while describing redundancy separately.
- [UPS runtime for a GPU node: a recovery-time budget](https://retrivium.ai/journal/ups-runtime-recovery-budget.md): Choose UPS runtime for a GPU node from the actual protected load and required action sequence.
- [Inlet, GPU and memory temperatures: different sensors](https://retrivium.ai/journal/gpu-inlet-device-temperature.md): Inlet-air, GPU, and GPU-memory temperatures measure different locations. One universal “server temperature” threshold cannot describe all of them.
- [Server fans: why speed percentages are not watts](https://retrivium.ai/journal/server-fan-energy-boundary.md): A fan-speed percentage is not electrical power and does not determine whole-server cooling energy.
- [Aligning energy-meter readings with a GPU test window](https://retrivium.ai/journal/power-meter-time-alignment.md): Compare GPU-test energy only after aligning the workload window with meter boundaries.
- [GPU benchmarks: median, spread and trial order](https://retrivium.ai/journal/gpu-benchmark-median-dispersion.md): Diagnose gPU benchmarks: median, spread and trial order. Evidence to collect, a worked operational example and recovery checks.
- [GPU benchmark confidence intervals: what counts as an observation](https://retrivium.ai/journal/gpu-benchmark-confidence-interval.md): Diagnose gPU benchmark confidence intervals: what counts as an observation. Evidence to collect, a worked operational example and recovery checks.
- [GPU drivers: a controlled comparison of two versions](https://retrivium.ai/journal/gpu-driver-controlled-ab.md): Diagnose gPU drivers: a controlled comparison of two versions. Evidence to collect, a worked operational example and recovery checks.
- [GPU VBIOS and InfoROM: different baseline fields](https://retrivium.ai/journal/gpu-inforom-vbios-baseline.md): Diagnose gPU VBIOS and InfoROM: different baseline fields. Evidence to collect, a worked operational example and recovery checks.
- [OAM accelerator modules and their system boundary](https://retrivium.ai/journal/oam-gpu-module-system-boundary.md): Diagnose oAM accelerator modules and their system boundary. Evidence to collect, a worked operational example and recovery checks.
- [Display-attached GPUs: the VRAM baseline before model loading](https://retrivium.ai/journal/display-attached-vram-baseline.md): Diagnose display-attached GPUs: the VRAM baseline before model loading. Evidence to collect, a worked operational example and recovery checks.
- [GPU-server RAM: equal capacity and different DIMM channel layouts](https://retrivium.ai/journal/gpu-host-ram-channel-population.md): Diagnose gPU-server RAM: equal capacity and different DIMM channel layouts. Evidence to collect, a worked operational example and recovery checks.
- [GPU N+1 capacity: measuring maintenance headroom on a workload](https://retrivium.ai/journal/gpu-n-plus-one-maintenance-capacity.md): Diagnose gPU N+1 capacity: measuring maintenance headroom on a workload. Evidence to collect, a worked operational example and recovery checks.
- [NVMe Available Spare is not filesystem free space](https://retrivium.ai/journal/nvme-spare-threshold-capacity.md): Diagnose nVMe Available Spare is not filesystem free space. Evidence to collect, a worked operational example and recovery checks.
- [Heterogeneous GPUs in one report: aggregating benchmark results](https://retrivium.ai/journal/heterogeneous-gpu-benchmark-aggregation.md): Diagnose heterogeneous GPUs in one report: aggregating benchmark results. Evidence to collect, a worked operational example and recovery checks.
- [AMD SMI in a mixed GPU fleet: units and metric support](https://retrivium.ai/journal/amd-smi-cross-vendor-telemetry.md): Map AMD SMI telemetry into a mixed GPU fleet with explicit units, device scope and query status. Compare coverage before treating common labels as comparable measurements.
- [Intel xpu-smi: telemetry does not prove LLM-service readiness](https://retrivium.ai/journal/intel-xpu-telemetry-boundary.md): Separate Intel xpu-smi discovery and version-dependent telemetry from compute-runtime checks, model loading and inference API readiness in a layered acceptance record.
- [NVIDIA GeForce RTX 5090 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-5090-inference-rendering.md): RTX 5090 32 GB for LLMs and Cycles, covering reference 575 W power, Blackwell software checks and verified switching between server workloads.
- [NVIDIA GeForce RTX 5080 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-5080-inference-rendering.md): RTX 5080 16 GB for inference and server rendering, with memory limits, backend validation and queue decisions around the reference 360 W specification.
- [NVIDIA GeForce RTX 5070 Ti for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-5070-ti-inference-rendering.md): RTX 5070 Ti 16 GB: validate LLM context, rendering scenes and server admission against Blackwell support, reference 300 W and RTX 5070 differences.
- [NVIDIA GeForce RTX 5070 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-5070-inference-rendering.md): RTX 5070 12 GB for LLMs and Cycles: context boundaries, GDDR7 configuration, a server worker and a scene reload verification experiment.
- [NVIDIA GeForce RTX 5060 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-5060-inference-rendering.md): RTX 5060 8 GB for a bounded LLM service and GPU rendering, with host memory checks and a request cancellation resource-release experiment.
- [NVIDIA GeForce RTX 5050 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-5050-inference-rendering.md): Desktop RTX 5050 8 GB GDDR6 for small LLM workloads and Cycles, including neighboring-model differences and a display-attached worker check.
- [NVIDIA GeForce RTX 5060 Ti for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-5060-ti-inference-rendering.md): RTX 5060 Ti 8 and 16 GB: variant specifications, LLM and Cycles memory checks, server setup and a reproducible comparison of two actual boards.
- [NVIDIA GeForce RTX 5090 D for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-5090-d-inference-rendering.md): The original RTX 5090 D 32 GB: distinguish D v2, verified NVIDIA specifications, LLM and Cycles paths and an exact regional server inventory.
- [NVIDIA GeForce RTX 5090 D v2 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-5090-d-v2-inference-rendering.md): RTX 5090 D v2 24 GB: a distinct GDDR7 profile, original D differences, reference 575 W and verification of inference and a server render scene.
- [NVIDIA GeForce RTX 4090 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-4090-inference-rendering.md): RTX 4090 24 GB for LLMs and server Cycles: official desktop specifications, reference 450 W, explicit GPU workers and a two-queue acceptance test.
- [NVIDIA GeForce RTX 4080 SUPER for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-4080-super-inference-rendering.md): RTX 4080 SUPER 16 GB for LLM inference and Cycles, with reference 320 W and a worker upgrade check that keeps the original RTX 4080 distinct.
- [NVIDIA GeForce RTX 4080 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-4080-inference-rendering.md): The original RTX 4080 16 GB for inference and Cycles, distinct from SUPER, with cold-start tests separating file loading from GPU memory behavior.
- [NVIDIA GeForce RTX 4070 Ti SUPER for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-4070-ti-super-inference-rendering.md): RTX 4070 Ti SUPER 16 GB: LLM and Cycles memory, differences from the 12 GB Ti and a server admission test for long request histories.
- [NVIDIA GeForce RTX 4070 Ti for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-4070-ti-inference-rendering.md): RTX 4070 Ti 12 GB for inference and Cycles: the original non-SUPER profile, context memory, reference 285 W and complete job energy boundaries.
- [NVIDIA GeForce RTX 4070 SUPER for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-4070-super-inference-rendering.md): RTX 4070 SUPER 12 GB for inference and Cycles, distinct from the ordinary 4070, with a complete streaming response check on a server worker.
- [NVIDIA GeForce RTX 4060 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-4060-inference-rendering.md): RTX 4060 8 GB GDDR6 for LLMs and Cycles, with reference 115 W, container device checks and reproducible job transfer between workers.
- [NVIDIA GeForce RTX 4070 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-4070-inference-rendering.md): RTX 4070 12 GB GDDR6 and GDDR6X variants for LLMs and Cycles, including memory inventory and separate server workload phase checks.
- [NVIDIA GeForce RTX 4060 Ti for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-4060-ti-inference-rendering.md): RTX 4060 Ti 8 and 16 GB: variant table, unknown board-specific power, LLM and Cycles paths and job routing by verified memory capacity.
- [NVIDIA GeForce RTX 4090 D for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-4090-d-inference-rendering.md): RTX 4090 D 24 GB: official regional Ada specifications, 425 W board power, inference and Cycles paths and a server inventory classification check.
- [NVIDIA GeForce RTX 3090 Ti for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-3090-ti-inference-rendering.md): RTX 3090 Ti 24 GB for inference and Cycles, covering Ampere, reference 450 W, RTX 3090 differences and repeated jobs under normal cooling.
- [NVIDIA GeForce RTX 3090 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-3090-inference-rendering.md): RTX 3090 24 GB for inference and server Cycles, with reference 350 W and a reproducible workload acceptance test for an existing GPU.
- [NVIDIA GeForce RTX 3080 Ti for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-3080-ti-inference-rendering.md): RTX 3080 Ti 12 GB for inference and GPU rendering, with reference 350 W and resident data checks when changing a model or scene on a server worker.
- [NVIDIA GeForce RTX 3070 Ti for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-3070-ti-inference-rendering.md): RTX 3070 Ti 8 GB GDDR6X for LLMs and Cycles, with reference 290 W and a bounded memory-rejection test for a server queue.
- [NVIDIA GeForce RTX 3070 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-3070-inference-rendering.md): RTX 3070 8 GB GDDR6 for LLMs and Cycles, with partial GPU offload verification, reference 220 W and reproducible server workload placement.
- [NVIDIA GeForce RTX 3080 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-3080-inference-rendering.md): RTX 3080 10 and 12 GB GDDR6X variants, reference 320/350 W, LLM and Cycles paths and admission rules for different server worker classes.
- [NVIDIA GeForce RTX 3060 Ti for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-3060-ti-inference-rendering.md): RTX 3060 Ti 8 GB GDDR6 and GDDR6X for LLMs and Cycles, with board-revision power uncertainty and a reproducible server workload inventory.
- [NVIDIA GeForce RTX 3060 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-3060-inference-rendering.md): RTX 3060 8 and 12 GB GDDR6 variants, reference 170 W, LLM and Cycles paths and a capacity-based acceptance test beyond the shared model name.
- [NVIDIA GeForce RTX 3050 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-3050-inference-rendering.md): RTX 3050 6 and 8 GB including OEM, with LLM and Cycles paths, reference 70/130 W and checks that preserve board-specific unknowns.
- [NVIDIA GeForce RTX 2080 Ti for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-2080-ti-inference-rendering.md): RTX 2080 Ti 11 GB for LLMs and Cycles, with NVIDIA comparison-design power and worker checks that avoid rounding capacity up to 12 GB.
- [NVIDIA GeForce RTX 2080 SUPER for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-2080-super-inference-rendering.md): RTX 2080 SUPER 8 GB for inference and Cycles, with comparison-design 250 W and a controlled CUDA/OptiX backend change on a server scene.
- [NVIDIA GeForce RTX 2080 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-2080-inference-rendering.md): The original RTX 2080 8 GB for LLMs and Cycles, with NVIDIA design power and software compatibility checks separate from VRAM exhaustion.
- [NVIDIA GeForce RTX 2070 SUPER for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-2070-super-inference-rendering.md): RTX 2070 SUPER 8 GB for inference and Cycles, with the 215 W design specification and queue-delay checks separate from GPU execution time.
- [NVIDIA GeForce RTX 2070 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-2070-inference-rendering.md): RTX 2070 8 GB for LLMs and Cycles: the original Turing model, NVIDIA design power and checks for a workstation worker under background graphics load.
- [NVIDIA GeForce RTX 2060 SUPER for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-2060-super-inference-rendering.md): RTX 2060 SUPER 8 GB, distinct from RTX 2060 6/12 GB, with LLM and Cycles checks, the 175 W design and full-name server job routing.
- [NVIDIA GeForce RTX 2060 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-rtx-2060-inference-rendering.md): RTX 2060 6 and 12 GB Turing variants for LLMs and Cycles, reference 160/185 W and capacity checks without assuming a newer architecture.
- [NVIDIA TITAN RTX for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-titan-rtx-inference-rendering.md): TITAN RTX 24 GB for LLMs and Cycles, with 280 W, Turing software checks and NVLink validation without automatic memory-pooling claims.
- [NVIDIA TITAN V for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-titan-v-inference-rendering.md): TITAN V 12 GB HBM2 for conditional legacy inference, the vLLM CC 7.5 boundary, compatible CUDA tooling and a Cycles server worker check.
- [NVIDIA TITAN Xp for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-titan-xp-inference-rendering.md): TITAN Xp 12 GB GDDR5X for conditional Pascal inference and Cycles, with 250 W and a legacy binary check using the correct build architecture.
- [NVIDIA TITAN X Pascal for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-titan-x-pascal-inference-rendering.md): TITAN X Pascal 12 GB GDDR5X, distinct from Maxwell and Xp, with legacy inference and Cycles checks that preserve unknown board power.
- [NVIDIA GeForce GTX 1660 Ti for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-gtx-1660-ti-inference-rendering.md): GTX 1660 Ti 6 GB GDDR6: Turing without Tensor or RT cores, LLM offload, Cycles and a bounded worker test with the 120 W design specification.
- [NVIDIA GeForce GTX 1660 SUPER for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-gtx-1660-super-inference-rendering.md): GTX 1660 SUPER 6 GB GDDR6 for LLMs and Cycles without Tensor/RT cores, with 125 W and separate memory, loading and execution checks.
- [NVIDIA GeForce GTX 1660 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-gtx-1660-inference-rendering.md): GTX 1660 6 GB GDDR5: original Turing without Tensor/RT cores, bounded LLM and Cycles paths and GGUF provenance checks for a server worker.
- [NVIDIA GeForce GTX 16 4 GB family for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-gtx-16-4-gb-family-inference-rendering.md): GTX 1650, 1650 SUPER and 1630 4 GB variants, with GDDR5/GDDR6 specifications, tiny LLM and Cycles experiments and a limited worker envelope.
- [NVIDIA GeForce GTX 1080 Ti for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-gtx-1080-ti-inference-rendering.md): GTX 1080 Ti 11 GB GDDR5X for legacy LLMs and Cycles, with a 250 W board example and build compatibility checks separate from capacity.
- [NVIDIA GeForce GTX 1080 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-gtx-1080-inference-rendering.md): GTX 1080 8 GB GDDR5X, original and 11 Gbps refresh variants, with legacy LLM and Cycles checks separating data rate from capacity.
- [NVIDIA GeForce GTX 1070 Ti for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-gtx-1070-ti-inference-rendering.md): GTX 1070 Ti 8 GB GDDR5 using the MSI GAMING 180 W example, with legacy LLM and Cycles paths tied to an actual board specification.
- [NVIDIA GeForce GTX 1070 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-gtx-1070-inference-rendering.md): GTX 1070 8 GB GDDR5 using a Founders Edition 150 W example, with conditional legacy inference, Cycles and saved worker environment migration checks.
- [NVIDIA GeForce GTX 1060 for LLM inference and GPU rendering](https://retrivium.ai/journal/gpu-nvidia-gtx-1060-inference-rendering.md): GTX 1060 3, 5 and 6 GB GDDR5/GDDR5X variants, with a unified inventory, legacy LLM and Cycles checks tied to the actual AIB board.
- [NVIDIA RTX PRO 6000 Blackwell Workstation Edition: 96GB in a single tower](https://retrivium.ai/journal/rtx-pro-6000-blackwell-workstation-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX PRO 6000 Blackwell Workstation Edition, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition: 96GB at a 300W board limit](https://retrivium.ai/journal/rtx-pro-6000-blackwell-max-q-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX PRO 6000 Blackwell Server Edition: air and liquid server integration](https://retrivium.ai/journal/rtx-pro-6000-blackwell-server-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX PRO 6000 Blackwell Server Edition, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX PRO 5500 Blackwell Workstation Edition: 84GB and preliminary specifications](https://retrivium.ai/journal/rtx-pro-5500-blackwell-workstation-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX PRO 5500 Blackwell Workstation Edition, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX PRO 5000 Blackwell: 48GB and72GB are separate variants](https://retrivium.ai/journal/rtx-pro-5000-blackwell-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX PRO 5000 Blackwell, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX PRO 4500 Blackwell Workstation Edition: the 200W active workstation board](https://retrivium.ai/journal/rtx-pro-4500-blackwell-workstation-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX PRO 4500 Blackwell Workstation Edition, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX PRO 4500 Blackwell Server Edition: 32GB in a passive single-slot server card](https://retrivium.ai/journal/rtx-pro-4500-blackwell-server-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX PRO 4500 Blackwell Server Edition, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX PRO 4000 Blackwell: 24GB in a full-height single slot](https://retrivium.ai/journal/rtx-pro-4000-blackwell-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX PRO 4000 Blackwell, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX PRO 4000 Blackwell SFF Edition: 24GB for low-profile systems](https://retrivium.ai/journal/rtx-pro-4000-blackwell-sff-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX PRO 4000 Blackwell SFF Edition, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX PRO 2000 Blackwell: 16GB inference and compact rendering](https://retrivium.ai/journal/rtx-pro-2000-blackwell-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX PRO 2000 Blackwell, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX 6000 Ada Generation: 48GB without assuming Ampere A6000 equivalence](https://retrivium.ai/journal/rtx-6000-ada-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX 6000 Ada Generation, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX 5880 Ada Generation: identify the 48GB Ada SKU](https://retrivium.ai/journal/rtx-5880-ada-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX 5880 Ada Generation, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX 5000 Ada Generation: 32GB and engine compatibility](https://retrivium.ai/journal/rtx-5000-ada-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX 5000 Ada Generation, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX 4500 Ada Generation: 24GB for a mixed workstation](https://retrivium.ai/journal/rtx-4500-ada-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX 4500 Ada Generation, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX 4000 Ada Generation: 20GB in a full-height single slot](https://retrivium.ai/journal/rtx-4000-ada-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX 4000 Ada Generation, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX 4000 SFF Ada Generation: 20GB under a 70W board limit](https://retrivium.ai/journal/rtx-4000-sff-ada-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX 4000 SFF Ada Generation, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX 2000 Ada Generation: 16GB in a compact render worker](https://retrivium.ai/journal/rtx-2000-ada-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX 2000 Ada Generation, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA A800 40GB Active: inference compute and rendering caveats](https://retrivium.ai/journal/a800-40gb-active-llm-rendering.md): Specifications and qualification steps for NVIDIA A800 40GB Active, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX A6000: 48GB and explicit multi-GPU memory](https://retrivium.ai/journal/rtx-a6000-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX A6000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX A5500: 24GB without an Ada name collision](https://retrivium.ai/journal/rtx-a5500-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX A5500, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX A5000: a 24GB Ampere baseline](https://retrivium.ai/journal/rtx-a5000-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX A5000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX A4500: 20GB and bounded context](https://retrivium.ai/journal/rtx-a4500-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX A4500, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX A4000: 16GB in one full-height slot](https://retrivium.ai/journal/rtx-a4000-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX A4000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX A2000: 6GB versus12GB in one model family](https://retrivium.ai/journal/rtx-a2000-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX A2000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX A1000: 8GB in a 50W compact board](https://retrivium.ai/journal/rtx-a1000-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX A1000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA RTX A400: 4GB sets the workload boundary](https://retrivium.ai/journal/rtx-a400-llm-rendering.md): Specifications and qualification steps for NVIDIA RTX A400, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA T400, T600 and T1000: small-model inference and rendering limits](https://retrivium.ai/journal/compact-nvidia-t400-t600-t1000-llm-rendering.md): Specifications and qualification steps for NVIDIA T400, T600 and T1000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro RTX 8000: 48GB and the active board identity](https://retrivium.ai/journal/quadro-rtx-8000-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro RTX 8000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro RTX 6000: 24GB before the Ada and Blackwell names](https://retrivium.ai/journal/quadro-rtx-6000-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro RTX 6000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro RTX 5000: 16GB on the original Turing5000](https://retrivium.ai/journal/quadro-rtx-5000-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro RTX 5000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro RTX 4000: 8GB in the original single-slot RTX](https://retrivium.ai/journal/quadro-rtx-4000-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro RTX 4000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro RTX 8000 Passive PCIe Server Card: the passive250W server edition](https://retrivium.ai/journal/quadro-rtx-8000-passive-server-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro RTX 8000 Passive PCIe Server Card, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro RTX 6000 Passive PCIe Server Card: the passive250W server edition](https://retrivium.ai/journal/quadro-rtx-6000-passive-server-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro RTX 6000 Passive PCIe Server Card, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro GV100: 32GB Volta needs a pinned stack](https://retrivium.ai/journal/quadro-gv100-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro GV100, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro GP100: 16GB HBM2 without modern vLLM support](https://retrivium.ai/journal/quadro-gp100-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro GP100, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro P6000: 24GB capacity with legacy compilation](https://retrivium.ai/journal/quadro-p6000-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro P6000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro P5000: 16GB Pascal for bounded reuse](https://retrivium.ai/journal/quadro-p5000-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro P5000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro P4000: 8GB and the 105W single-slot board](https://retrivium.ai/journal/quadro-p4000-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro P4000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro P400, P600, P620, P1000, P2000 and P2200: 2GB to5GB legacy workload boundaries](https://retrivium.ai/journal/compact-quadro-pascal-2gb-5gb-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro P400, P600, P620, P1000, P2000 and P2200, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro M6000: 12GB and24GB on a retained legacy stack](https://retrivium.ai/journal/quadro-m6000-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro M6000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro M5000: 8GB with a Maxwell compatibility ceiling](https://retrivium.ai/journal/quadro-m5000-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro M5000, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Quadro M4000: 8GB in a legacy single slot](https://retrivium.ai/journal/quadro-m4000-llm-rendering.md): Specifications and qualification steps for NVIDIA Quadro M4000, covering memory variants, LLM backends, Cycles and system integration.
- [Radeon RX 9070 XT: 16 GB RDNA 4 deployment boundaries](https://retrivium.ai/journal/amd-radeon-rx-9070-xt-llm-rendering.md): Radeon RX 9070 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 9070: 16 GB capacity and a 220 W board](https://retrivium.ai/journal/amd-radeon-rx-9070-llm-rendering.md): Radeon RX 9070: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 9070 GRE: verify 12 GB before model sizing](https://retrivium.ai/journal/amd-radeon-rx-9070-gre-llm-rendering.md): Radeon RX 9070 GRE: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 9060 XT: 8 GB versus 16 GB for inference](https://retrivium.ai/journal/amd-radeon-rx-9060-xt-llm-rendering.md): Radeon RX 9060 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 9060 XT LP: the 140 W product and chassis checks](https://retrivium.ai/journal/amd-radeon-rx-9060-xt-lp-llm-rendering.md): Radeon RX 9060 XT LP: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 9060: the non-XT 8 GB deployment case](https://retrivium.ai/journal/amd-radeon-rx-9060-llm-rendering.md): Radeon RX 9060: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 9050: 4 GB and 8 GB small-model limits](https://retrivium.ai/journal/amd-radeon-rx-9050-llm-rendering.md): Radeon RX 9050: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 7900 XTX: 24 GB on one GPU](https://retrivium.ai/journal/amd-radeon-rx-7900-xtx-llm-rendering.md): Radeon RX 7900 XTX: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 7900 XT: planning around 20 GB](https://retrivium.ai/journal/amd-radeon-rx-7900-xt-llm-rendering.md): Radeon RX 7900 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 7900 GRE: a separate 16 GB GRE target](https://retrivium.ai/journal/amd-radeon-rx-7900-gre-llm-rendering.md): Radeon RX 7900 GRE: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 7800 XT: a repeatable 16 GB workstation](https://retrivium.ai/journal/amd-radeon-rx-7800-xt-llm-rendering.md): Radeon RX 7800 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 7700 XT: 12 GB and the non-XT naming trap](https://retrivium.ai/journal/amd-radeon-rx-7700-xt-llm-rendering.md): Radeon RX 7700 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 7700: identify the official 16 GB non-XT SKU](https://retrivium.ai/journal/amd-radeon-rx-7700-llm-rendering.md): Radeon RX 7700: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 7650 GRE: regional SKU and software support checks](https://retrivium.ai/journal/amd-radeon-rx-7650-gre-llm-rendering.md): Radeon RX 7650 GRE: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 7600 XT: 16 GB does not establish ROCm support](https://retrivium.ai/journal/amd-radeon-rx-7600-xt-llm-rendering.md): Radeon RX 7600 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 7600: an exact 8 GB ROCm SKU](https://retrivium.ai/journal/amd-radeon-rx-7600-llm-rendering.md): Radeon RX 7600: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 7400: an 8 GB low-board-power candidate](https://retrivium.ai/journal/amd-radeon-rx-7400-llm-rendering.md): Radeon RX 7400: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6950 XT: 16 GB with a 335 W reference envelope](https://retrivium.ai/journal/amd-radeon-rx-6950-xt-llm-rendering.md): Radeon RX 6950 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6900 XT: reuse an existing 16 GB flagship carefully](https://retrivium.ai/journal/amd-radeon-rx-6900-xt-llm-rendering.md): Radeon RX 6900 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6800 XT: consumer RX versus PRO software boundaries](https://retrivium.ai/journal/amd-radeon-rx-6800-xt-llm-rendering.md): Radeon RX 6800 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6800: 16 GB without the XT or PRO assumptions](https://retrivium.ai/journal/amd-radeon-rx-6800-llm-rendering.md): Radeon RX 6800: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6750 XT: 12 GB for a measured offload layout](https://retrivium.ai/journal/amd-radeon-rx-6750-xt-llm-rendering.md): Radeon RX 6750 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6700 XT: validate a 12 GB RDNA 2 node](https://retrivium.ai/journal/amd-radeon-rx-6700-xt-llm-rendering.md): Radeon RX 6700 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6700: the non-XT 10 GB capacity boundary](https://retrivium.ai/journal/amd-radeon-rx-6700-llm-rendering.md): Radeon RX 6700: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6650 XT: an 8 GB refresh needs its own test](https://retrivium.ai/journal/amd-radeon-rx-6650-xt-llm-rendering.md): Radeon RX 6650 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6600 XT: an 8 GB backend qualification checklist](https://retrivium.ai/journal/amd-radeon-rx-6600-xt-llm-rendering.md): Radeon RX 6600 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6600: selective offload on an 8 GB card](https://retrivium.ai/journal/amd-radeon-rx-6600-llm-rendering.md): Radeon RX 6600: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6400: 4 GB and host-transfer constraints](https://retrivium.ai/journal/amd-radeon-rx-6400-llm-rendering.md): Radeon RX 6400: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6750 GRE: 10 GB versus 12 GB official variants](https://retrivium.ai/journal/amd-radeon-rx-6750-gre-llm-rendering.md): Radeon RX 6750 GRE: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 6500 XT: 4 GB and 8 GB under tight memory budgets](https://retrivium.ai/journal/amd-radeon-rx-6500-xt-llm-rendering.md): Radeon RX 6500 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 5700: an existing 8 GB RDNA 1 workstation](https://retrivium.ai/journal/amd-radeon-rx-5700-llm-rendering.md): Radeon RX 5700: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 5600 XT: a practical 6 GB allocation test](https://retrivium.ai/journal/amd-radeon-rx-5600-xt-llm-rendering.md): Radeon RX 5600 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 5600: identify the 6 GB non-XT OEM card](https://retrivium.ai/journal/amd-radeon-rx-5600-llm-rendering.md): Radeon RX 5600: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 5500: the 4 GB OEM model is a separate SKU](https://retrivium.ai/journal/amd-radeon-rx-5500-llm-rendering.md): Radeon RX 5500: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 5300: what the 3 GB OEM boundary means](https://retrivium.ai/journal/amd-radeon-rx-5300-llm-rendering.md): Radeon RX 5300: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 5700 XT: standard and Anniversary board limits](https://retrivium.ai/journal/amd-radeon-rx-5700-xt-llm-rendering.md): Radeon RX 5700 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX 5500 XT: official 4 GB and 8 GB configurations](https://retrivium.ai/journal/amd-radeon-rx-5500-xt-llm-rendering.md): Radeon RX 5500 XT: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon VII: 16 GB HBM2 with legacy software boundaries](https://retrivium.ai/journal/amd-radeon-vii-llm-rendering.md): Radeon VII: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX Vega 64: an 8 GB legacy assessment](https://retrivium.ai/journal/amd-radeon-rx-vega-64-llm-rendering.md): Radeon RX Vega 64: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon RX Vega 56: an 8 GB legacy assessment](https://retrivium.ai/journal/amd-radeon-rx-vega-56-llm-rendering.md): Radeon RX Vega 56: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon Vega Frontier Edition: air versus liquid and real physical VRAM](https://retrivium.ai/journal/amd-radeon-vega-frontier-edition-llm-rendering.md): Radeon Vega Frontier Edition: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon AI PRO R9700: 32 GB in an active-cooled workstation](https://retrivium.ai/journal/amd-radeon-ai-pro-r9700-llm-rendering.md): Radeon AI PRO R9700: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon AI PRO R9700S: 32 GB passive cooling needs a qualified host](https://retrivium.ai/journal/amd-radeon-ai-pro-r9700s-llm-rendering.md): Radeon AI PRO R9700S: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon AI PRO R9600: 32 GB on the 150 W single-slot product](https://retrivium.ai/journal/amd-radeon-ai-pro-r9600-llm-rendering.md): Radeon AI PRO R9600: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon AI PRO R9600D: a passive 150 W host qualification](https://retrivium.ai/journal/amd-radeon-ai-pro-r9600d-llm-rendering.md): Radeon AI PRO R9600D: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO W7900: 48 GB standard versus Dual Slot](https://retrivium.ai/journal/amd-radeon-pro-w7900-llm-rendering.md): Radeon PRO W7900: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO W7800: 32 GB versus 48 GB model and scene budgets](https://retrivium.ai/journal/amd-radeon-pro-w7800-llm-rendering.md): Radeon PRO W7800: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO W7700: 16 GB with an exact workstation support entry](https://retrivium.ai/journal/amd-radeon-pro-w7700-llm-rendering.md): Radeon PRO W7700: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO W7600: professional drivers do not establish LLM support](https://retrivium.ai/journal/amd-radeon-pro-w7600-llm-rendering.md): Radeon PRO W7600: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO W7500: 8 GB on a 70 W workstation board](https://retrivium.ai/journal/amd-radeon-pro-w7500-llm-rendering.md): Radeon PRO W7500: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO W7400: verify the 8 GB 55 W product](https://retrivium.ai/journal/amd-radeon-pro-w7400-llm-rendering.md): Radeon PRO W7400: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO W6800: the specifically listed 32 GB RDNA 2 workstation](https://retrivium.ai/journal/amd-radeon-pro-w6800-llm-rendering.md): Radeon PRO W6800: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO W6600: an 8 GB workstation and its 130 W specification](https://retrivium.ai/journal/amd-radeon-pro-w6600-llm-rendering.md): Radeon PRO W6600: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO W6400: the 4 GB workstation boundary](https://retrivium.ai/journal/amd-radeon-pro-w6400-llm-rendering.md): Radeon PRO W6400: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO W5700: 8 GB on an existing RDNA workstation](https://retrivium.ai/journal/amd-radeon-pro-w5700-llm-rendering.md): Radeon PRO W5700: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO W5500: an 8 GB 125 W workstation test](https://retrivium.ai/journal/amd-radeon-pro-w5500-llm-rendering.md): Radeon PRO W5500: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO VII: PRO VII is distinct from consumer Radeon VII](https://retrivium.ai/journal/amd-radeon-pro-vii-llm-rendering.md): Radeon PRO VII: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO WX 9100: 16 GB with a versioned legacy specification](https://retrivium.ai/journal/amd-radeon-pro-wx-9100-llm-rendering.md): Radeon PRO WX 9100: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO WX 8200: 8 GB HBM2 and current backend limits](https://retrivium.ai/journal/amd-radeon-pro-wx-8200-llm-rendering.md): Radeon PRO WX 8200: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO V710: 28 GB and server or guest visibility](https://retrivium.ai/journal/amd-radeon-pro-v710-llm-rendering.md): Radeon PRO V710: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO V620: 32 GB board memory versus guest allocation](https://retrivium.ai/journal/amd-radeon-pro-v620-llm-rendering.md): Radeon PRO V620: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO V520: 8 GB HBM2 on a virtualization-oriented board](https://retrivium.ai/journal/amd-radeon-pro-v520-llm-rendering.md): Radeon PRO V520: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [Radeon PRO V340: dual-GPU board total is not unified VRAM](https://retrivium.ai/journal/amd-radeon-pro-v340-llm-rendering.md): Radeon PRO V340: official memory and board-power variants, ROCm and Blender Cycles support boundaries, and a practical workload validation scenario.
- [NVIDIA L40S: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-l40s-llm-rendering.md): Specifications and qualification steps for NVIDIA L40S, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA L40: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-l40-llm-rendering.md): Specifications and qualification steps for NVIDIA L40, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA L4: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-l4-llm-rendering.md): Specifications and qualification steps for NVIDIA L4, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA L20: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-l20-llm-rendering.md): Specifications and qualification steps for NVIDIA L20, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA A40: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-a40-llm-rendering.md): Specifications and qualification steps for NVIDIA A40, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA A10: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-a10-llm-rendering.md): Specifications and qualification steps for NVIDIA A10, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA A16: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-a16-llm-rendering.md): Specifications and qualification steps for NVIDIA A16, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA A2: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-a2-llm-rendering.md): Specifications and qualification steps for NVIDIA A2, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA A30: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-a30-llm-rendering.md): Specifications and qualification steps for NVIDIA A30, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA A100: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-a100-llm-rendering.md): NVIDIA A100: A100 is a family of PCIe and SXM accelerators with different memory budgets. Model residency, MIG allocation and renderer eligibility need separate checks.
- [NVIDIA A800: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-a800-llm-rendering.md): NVIDIA A800: A800 80 GB server configurations need their own inventory and support record. They must not be confused with the A800 40 GB Active workstation board.
- [NVIDIA H100: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-h100-llm-rendering.md): NVIDIA H100: H100 PCIe, SXM and NVL are different deployment choices. The NVL pair has 188 GB across two 94 GB GPUs, not a single 188 GB allocation.
- [NVIDIA H200: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-h200-llm-rendering.md): NVIDIA H200: H200 provides 141 GB HBM3e per GPU in published SXM and NVL configurations. That capacity is a runtime budget, not a model-size or concurrency guarantee.
- [NVIDIA H800: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-h800-llm-rendering.md): NVIDIA H800: H800 assessment needs the exact OEM configuration: PCIe and SXM 80 GB, or NVL 94 GB per GPU. Similar names do not establish identical host or interconnect requirements.
- [NVIDIA H20: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-h20-llm-rendering.md): NVIDIA H20: Official platform documentation distinguishes 96 GB and 141 GB H20 configurations. Capacity must follow the exact platform identity, not a generic H20 label.
- [NVIDIA B200: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-b200-llm-rendering.md): NVIDIA B200: The checked HGX reference architecture specifies 180 GB usable HBM3e per B200. Nominal capacity, MIG profiles and node totals must remain distinct.
- [NVIDIA B300: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-b300-llm-rendering.md): NVIDIA B300: HGX B300 publishes 288 GB HBM3e per GPU. Physical capacity, partition profiles and a multi-GPU node total describe different resource budgets.
- [NVIDIA Rubin GPU: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-rubin-gpu-llm-rendering.md): NVIDIA Rubin GPU: Rubin documentation publishes a 288 GB HBM4 platform GPU. Treat the specification as a platform-planning reference, with availability and software qualification checked separately.
- [NVIDIA Tesla V100: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-tesla-v100-llm-rendering.md): Specifications and qualification steps for NVIDIA Tesla V100, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Tesla V100S: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-tesla-v100s-llm-rendering.md): Specifications and qualification steps for NVIDIA Tesla V100S, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Tesla P100: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-tesla-p100-llm-rendering.md): Specifications and qualification steps for NVIDIA Tesla P100, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Tesla P40: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-tesla-p40-llm-rendering.md): Specifications and qualification steps for NVIDIA Tesla P40, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Tesla P4: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-tesla-p4-llm-rendering.md): Specifications and qualification steps for NVIDIA Tesla P4, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Tesla T4: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-tesla-t4-llm-rendering.md): Specifications and qualification steps for NVIDIA Tesla T4, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Tesla M40: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-tesla-m40-llm-rendering.md): Specifications and qualification steps for NVIDIA Tesla M40, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Tesla M60: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-tesla-m60-llm-rendering.md): Specifications and qualification steps for NVIDIA Tesla M60, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Tesla M10: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-tesla-m10-llm-rendering.md): Specifications and qualification steps for NVIDIA Tesla M10, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA Tesla M6 and P6: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-tesla-m6-and-p6-llm-rendering.md): Specifications and qualification steps for NVIDIA Tesla M6 and P6, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA GeForce GTX 980 Ti: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-geforce-gtx-980-ti-llm-rendering.md): Specifications and qualification steps for NVIDIA GeForce GTX 980 Ti, covering memory variants, LLM backends, Cycles and system integration.
- [NVIDIA GeForce GTX TITAN X Maxwell: LLM inference and server rendering boundaries](https://retrivium.ai/journal/nvidia-geforce-gtx-titan-x-maxwell-llm-rendering.md): Specifications and qualification steps for NVIDIA GeForce GTX TITAN X Maxwell, covering memory variants, LLM backends, Cycles and system integration.
- [AMD Instinct MI100: LLM inference and server rendering boundaries](https://retrivium.ai/journal/amd-instinct-mi100-llm-rendering.md): Specifications and qualification steps for AMD Instinct MI100, covering memory variants, LLM backends, Cycles and system integration.
- [AMD Instinct MI210: LLM inference and server rendering boundaries](https://retrivium.ai/journal/amd-instinct-mi210-llm-rendering.md): Specifications and qualification steps for AMD Instinct MI210, covering memory variants, LLM backends, Cycles and system integration.
- [AMD Instinct MI250 and MI250X: LLM inference and server rendering boundaries](https://retrivium.ai/journal/amd-instinct-mi250-and-mi250x-llm-rendering.md): Specifications and qualification steps for AMD Instinct MI250 and MI250X, covering memory variants, LLM backends, Cycles and system integration.
- [AMD Instinct MI300X: LLM inference and server rendering boundaries](https://retrivium.ai/journal/amd-instinct-mi300x-llm-rendering.md): Specifications and qualification steps for AMD Instinct MI300X, covering memory variants, LLM backends, Cycles and system integration.
- [AMD Instinct MI300A: LLM inference and server rendering boundaries](https://retrivium.ai/journal/amd-instinct-mi300a-llm-rendering.md): AMD Instinct MI300A: MI300A combines CPU and GPU in an APU platform with 128 GB shared HBM3. The shared budget is not dedicated GPU VRAM plus a separate 128 GB CPU pool.
- [AMD Instinct MI325X: LLM inference and server rendering boundaries](https://retrivium.ai/journal/amd-instinct-mi325x-llm-rendering.md): Specifications and qualification steps for AMD Instinct MI325X, covering memory variants, LLM backends, Cycles and system integration.
- [AMD Instinct MI350P: LLM inference and server rendering boundaries](https://retrivium.ai/journal/amd-instinct-mi350p-llm-rendering.md): Specifications and qualification steps for AMD Instinct MI350P, covering memory variants, LLM backends, Cycles and system integration.
- [AMD Instinct MI350X and MI355X: LLM inference and server rendering boundaries](https://retrivium.ai/journal/amd-instinct-mi350x-and-mi355x-llm-rendering.md): Specifications and qualification steps for AMD Instinct MI350X and MI355X, covering memory variants, LLM backends, Cycles and system integration.
- [AMD Instinct MI455X: LLM inference and server rendering boundaries](https://retrivium.ai/journal/amd-instinct-mi455x-llm-rendering.md): AMD Instinct MI455X: AMD publishes 432 GB HBM4 for the MI455X EAM platform accelerator. Direct liquid cooling and system qualification are part of the deployment boundary.
- [AMD Instinct MI430X: LLM inference and server rendering boundaries](https://retrivium.ai/journal/amd-instinct-mi430x-llm-rendering.md): AMD Instinct MI430X: AMD describes MI430X as planned for 2027 and publishes 432 GB HBM4. This is a roadmap profile, not a currently validated removable GPU recommendation.
- [AMD Instinct MI50 and MI60: LLM inference and server rendering boundaries](https://retrivium.ai/journal/amd-instinct-mi50-and-mi60-llm-rendering.md): Specifications and qualification steps for AMD Instinct MI50 and MI60, covering memory variants, LLM backends, Cycles and system integration.
- [GPU compatibility for LLM inference and Cycles rendering](https://retrivium.ai/journal/gpu-llm-renderer-compatibility-matrix.md): CUDA, ROCm and a renderer backend answer different compatibility questions. Check the exact GPU, software version and workload before assigning a node.
- [GPU VRAM, board totals and shared memory: how to read specifications](https://retrivium.ai/journal/gpu-vram-board-module-shared-memory.md): Per-GPU VRAM, a multi-GPU board total, module memory and unified CPU/GPU memory are different budgets. Adding the numbers can create a false model-fit claim.
- [Desktop GPU, workstation or server accelerator: qualify the host](https://retrivium.ai/journal/gpu-server-chassis-cooling-qualification.md): A compatible software backend does not prove that a GPU is suitable for a server chassis. Cooling, power, mechanics and manufacturer validation need their own assessment.
- [Legacy GPUs for LLMs and rendering: experimental versus supported](https://retrivium.ai/journal/legacy-gpu-inference-rendering-boundaries.md): Older NVIDIA and Radeon GPUs can require legacy software or conditional backend experiments. Missing current certification is different from universal inability to compute.
- [Sharing GPUs between LLM inference and server rendering](https://retrivium.ai/journal/gpu-llm-rendering-workload-scheduling.md): A GPU that passes separate LLM and render tests may still fail a mixed workload. Schedule by memory, latency and supported isolation rather than peak utilisation alone.
- [NVIDIA and AMD GPU catalogue for LLM inference and server rendering](https://retrivium.ai/journal/nvidia-amd-gpu-catalog.md): 194 model profiles and grouped variants, plus six guides: NVIDIA, Radeon and Instinct memory, software boundaries, cooling and workload qualification in English and Russian.
- [Qwen3-30B-A3B Instruct vs Thinking: choose by task](https://retrivium.ai/journal/qwen3-30b-instruct-vs-thinking-tasks.md): Compare the Qwen3-30B-A3B 2507 Instruct and Thinking checkpoints using task acceptance, answer limits and a reproducible evaluation record.
- [Qwen3-4B-Thinking-2507 for math: verify answers and failure cases](https://retrivium.ai/journal/qwen3-4b-thinking-math-verification.md): Evaluate Qwen3-4B-Thinking-2507 on math with checked final answers, valid alternative solutions, output limits and a reproducible failure record.
- [Qwen3-4B-Instruct-2507 for text classification](https://retrivium.ai/journal/qwen3-4b-instruct-text-classification.md): Test Qwen3-4B-Instruct-2507 for fixed-label classification using an explicit taxonomy, abstention cases, confusion records and stable output checks.
- [Qwen3-Coder-Next vs 30B-A3B for repository work](https://retrivium.ai/journal/qwen3-coder-next-vs-30b-repository-tasks.md): Compare Qwen3-Coder-Next and 30B-A3B on repository issue localization, cross-file edits, acceptance tests and declared evaluation budgets.
- [Qwen3-Coder 480B vs 30B: when to escalate a coding task](https://retrivium.ai/journal/qwen3-coder-480b-vs-30b-task-escalation.md): Choose when to escalate from Qwen3-Coder 30B to 480B using a documented failure, a fresh attempt budget and unchanged patch acceptance checks.
- [Qwen3-Coder-Next after a failed test: evaluate recovery](https://retrivium.ai/journal/qwen3-coder-next-failed-test-recovery.md): Evaluate Qwen3-Coder-Next after a failed test with a preserved transcript, protected acceptance checks and separate repair and regression evidence.
- [Qwen2.5-Coder FIM vs chat: choose the right checkpoint and prompt](https://retrivium.ai/journal/qwen25-coder-fim-vs-chat-completion.md): Choose Qwen2.5-Coder Base for fill-in-the-middle or Instruct for chat coding, then verify suffix preservation and the generated insertion.
- [Qwen3-Next vs Qwen3-32B for long text instructions](https://retrivium.ai/journal/qwen3-next-vs-32b-long-text-instructions.md): Compare Qwen3-Next and Qwen3-32B on distant text constraints while separating native context, length extension and actual instruction accuracy.
- [Qwen3-Next Gated DeltaNet: what changes for text inference](https://retrivium.ai/journal/qwen3-next-gated-deltanet-explained.md): Understand Qwen3-Next Gated DeltaNet, gated attention and sparse experts, then test distant requirements without inferring universal accuracy or speed.
- [Qwen3-Next Thinking vs Instruct: separate checkpoints and answer budgets](https://retrivium.ai/journal/qwen3-next-thinking-vs-instruct-checkpoints.md): Choose Qwen3-Next Thinking or Instruct by task, checkpoint identity, completed final answers and explicit reasoning and response budgets.
- [Qwen3.6 preserve_thinking for iterative code changes](https://retrivium.ai/journal/qwen36-preserve-thinking-code-iterations.md): Evaluate Qwen3.6 preserve_thinking on iterative code edits with intact historical messages, a fixed transcript and explicit final-answer checks.
- [Qwen3.6-27B vs 35B-A3B for text coding tasks](https://retrivium.ai/journal/qwen36-27b-vs-35b-a3b-coding.md): Compare Qwen3.6-27B and 35B-A3B on function repair and cross-file code requirements without equating active parameters with quality or speed.
- [Qwen3.8 reasoning_effort: test deeper reasoning on text tasks](https://retrivium.ai/journal/qwen38-reasoning-effort-text-tasks.md): Test Qwen3.8 reasoning_effort on a bounded text problem while distinguishing the open checkpoint, hosted Qwen-Max features and answer completion.
- [Qwen3.8 FP8 vs original weights: validate coding quality](https://retrivium.ai/journal/qwen38-fp8-vs-original-checkpoint-quality.md): Validate the official Qwen3.8 FP8 checkpoint against its original weights using quantization metadata, code acceptance tests and matched generation.
- [Qwen3-Coder-Next vs Qwen3.6: specialist or general model for code](https://retrivium.ai/journal/qwen3-coder-next-vs-qwen36-code-specialization.md): Compare Qwen3-Coder-Next and Qwen3.6 on code repair, requirements interpretation and final explanations using a shared text-only task.
- [DeepSeek-V3.2 vs Speciale: reasoning tasks and tool-use limits](https://retrivium.ai/journal/deepseek-v32-vs-speciale-reasoning-tools.md): Choose DeepSeek-V3.2 or Speciale by tool requirements and checked reasoning tasks while separating downloadable checkpoints from historical API offers.
- [DeepSeek-V3.2 thinking with tools: preserve the right history](https://retrivium.ai/journal/deepseek-v32-thinking-tool-history.md): Understand DeepSeek-V3.2 thinking history through its reference encoder, separating a new user turn from continuation after a tool result.
- [DeepSeek-V4 Flash vs Pro: choose by coding and reasoning task](https://retrivium.ai/journal/deepseek-v4-flash-vs-pro-task-choice.md): Compare DeepSeek-V4 Flash and Pro through code repair, constraint solving and task acceptance, keeping checkpoint identity separate from Max effort.
- [DeepSeek-V4 Max effort: compare reasoning with a fair budget](https://retrivium.ai/journal/deepseek-v4-max-effort-evaluation.md): Separate DeepSeek-V4 model variants from Max reasoning effort and compare completed answers under declared output, retry and time budgets.
- [DeepSeek-V4.1-Flash-1017: validate a coding-model upgrade](https://retrivium.ai/journal/deepseek-v41-flash-1017-coding-migration.md): Evaluate DeepSeek-V4.1-Flash-1017 as a coding upgrade with identical fixtures, prompt encoding and acceptance tests, keeping vendor benchmarks attributed.
- [DeepSeek-V4.1 prompt encoding: local text messages and effort](https://retrivium.ai/journal/deepseek-v41-prompt-encoding-reference.md): Understand DeepSeek-V4.1 text encoding, numeric reasoning effort, changed DSML tags and system-message boundaries using the published reference.
- [GLM-4.7-Flash vs Qwen3-30B-A3B for coding and tools](https://retrivium.ai/journal/glm47-flash-vs-qwen3-30b-coding.md): Compare GLM-4.7-Flash and exact Qwen3 30B checkpoints on code repair and tool tasks, accounting for mode and prompt-format differences.
- [GLM-4.7 preserved thinking and turn-level control](https://retrivium.ai/journal/glm47-preserved-turn-level-thinking.md): Separate GLM-4.7 preserved, interleaved and turn-level thinking using the documented history rules and a concrete iterative coding conversation.
- [GLM-5 vs GLM-4.7 for long-horizon engineering tasks](https://retrivium.ai/journal/glm5-vs-glm47-long-horizon-code.md): Compare GLM-5 and GLM-4.7 on a staged repository migration, checking interface continuity, milestones and full-task completion rather than one function.
- [GLM-5.2 vs GLM-5.3: what changes when the base model stays the same](https://retrivium.ai/journal/glm52-vs-glm53-post-training-choice.md): Compare GLM-5.2 and GLM-5.3 as post-training variants of the same base, using requirement adherence, patch acceptance and stopping behavior.
- [GLM-5.3 thinking controls: API policy and local checkpoint behavior](https://retrivium.ai/journal/glm53-thinking-api-vs-local-controls.md): Understand GLM-5.3 forced thinking in the documented API, separate it from local checkpoint controls and diagnose incomplete final answers.
- [GLM-5.2 long context: test repository dependency reasoning](https://retrivium.ai/journal/glm52-million-context-code-dependencies.md): Evaluate GLM-5.2 long context on distant code definitions, callers and stale notes using a self-contained repository bundle and checked changes.
- [Kimi K2 Thinking vs Instruct-0905 for text tasks](https://retrivium.ai/journal/kimi-k2-thinking-vs-instruct-0905.md): Compare Kimi K2 Thinking and Instruct-0905 by final text requirements, reasoning depth and declared output limits rather than variant names alone.
- [Kimi K2 Thinking INT4: native QAT and unpacked weights differ](https://retrivium.ai/journal/kimi-k2-native-int4-vs-unpacked-weights.md): Read Kimi K2 Thinking native INT4 QAT and compressed-tensors metadata correctly, distinguishing unpacked wider weights from an original master checkpoint.
- [Kimi K3 KDA and Attention Residuals: a text-model architecture guide](https://retrivium.ai/journal/kimi-k3-kda-attention-residuals-text.md): Understand Kimi K3 KDA, Attention Residuals and sparse experts as different architectural mechanisms, then define a bounded text reasoning check.
- [Kimi K3 vs K2 Thinking for long coding sessions](https://retrivium.ai/journal/kimi-k3-vs-k2-thinking-code-sessions.md): Compare Kimi K3 and K2 Thinking on text-only long coding sessions with retained requirements, recoverable failures and final repository acceptance.
- [MiniMax-M2.5 for code repair: judge tests and patch quality](https://retrivium.ai/journal/minimax-m25-test-driven-code-repair.md): Evaluate MiniMax-M2.5 code repair by checking its proposed specification, protected tests, patch behavior and regressions on a bounded example.
- [MiniMax-M2.5 tool errors: evaluate argument repair and stopping](https://retrivium.ai/journal/minimax-m25-tool-error-recovery.md): Test MiniMax-M2.5 recovery from a tool validation error, separating XML parsing, argument types, schema violations and repeated invalid proposals.
- [MiniMax-M2.5 vs GLM-4.7 for repository maintenance](https://retrivium.ai/journal/minimax-m25-vs-glm47-repository-maintenance.md): Compare MiniMax-M2.5 and GLM-4.7 on routine repository maintenance, including small patches, repeated changes, tool observations and collateral edits.
- [Devstral 2 vs Small 2 for multi-file code changes](https://retrivium.ai/journal/devstral2-vs-small2-multifile-code.md): Compare Devstral 2 and Devstral Small 2 on linked code edits, caller consistency and regression tests while preserving exact 2512 artifact identities.
- [Devstral 2 vs Qwen3-Coder-Next: compare patch workflows](https://retrivium.ai/journal/devstral2-vs-qwen-coder-next-patches.md): Compare dense Devstral 2 and hybrid Qwen3-Coder-Next on patch application, requirement retention and final tests without translating architecture into a ranking.
- [Devstral Small 2: a deprecated API and downloadable weights](https://retrivium.ai/journal/devstral-small2-deprecated-api-open-weights.md): Understand Devstral Small 2 API deprecation separately from its versioned open-weight artifact, local evaluation and replacement-model decisions.
- [Ministral 3 Instruct vs Reasoning for short text and math](https://retrivium.ai/journal/ministral3-instruct-vs-reasoning-text.md): Choose Ministral 3 8B Instruct or Reasoning using their distinct post-training, precision, sampling guidance and checked text-task requirements.
- [Ministral 3 3B, 8B or 14B for bounded text tasks](https://retrivium.ai/journal/ministral3-3b-8b-14b-text-selection.md): Choose among Ministral 3 3B, 8B and 14B for bounded text tasks using a fixed variant, clear labels, counterexamples and accepted outcomes.
- [Mistral Small 4 reasoning_effort: none vs high](https://retrivium.ai/journal/mistral-small4-reasoning-none-high.md): Use Mistral Small 4 reasoning_effort none and high as separate operating conditions, checking final answers, sampling settings and completion.
- [Mistral Small 4 vs Devstral 2 for mixed text and code work](https://retrivium.ai/journal/mistral-small4-vs-devstral2-code-generalist.md): Choose Mistral Small 4 or Devstral 2 for mixed text and code work by evaluating requirements interpretation, patch correctness and final explanations.
- [Mistral Small 4 NVFP4 vs original checkpoint: test task quality](https://retrivium.ai/journal/mistral-small4-nvfp4-checkpoint-choice.md): Evaluate Mistral Small 4 NVFP4 against its original checkpoint through artifact provenance, matched reasoning settings and bounded text and code checks.
- [Ministral 3 vs Gemma 4: reasoning history rules differ](https://retrivium.ai/journal/ministral3-vs-gemma4-thinking-history.md): Compare Ministral 3 and Gemma 4 reasoning-history rules, separating ordinary completed turns from tool continuations and final-answer fields.
- [Gemma 4 26B-A4B vs 31B for text coding tasks](https://retrivium.ai/journal/gemma4-26b-a4b-vs-31b-coding.md): Compare Gemma 4 26B-A4B and 31B for text coding tasks using their documented MoE and dense designs, matched thinking and independent patch checks.
- [Moving from Gemma 3 to Gemma 4: system roles and text prompts](https://retrivium.ai/journal/gemma3-to-gemma4-system-prompt-roles.md): Migrate Gemma 3 text prompts to Gemma 4 by separating structured message roles, rendered control tokens and duplicated system instructions.
- [Gemma 4 thinking mode and empty thought blocks](https://retrivium.ai/journal/gemma4-thinking-channel-empty-block.md): Explain Gemma 4 empty thought blocks and enable_thinking behavior, separating template-supplied prefixes, generated tokens and final-answer parsing.
- [Gemma 4 QAT unquantized vs GGUF: choose the right artifact](https://retrivium.ai/journal/gemma4-qat-unquantized-vs-gguf.md): Distinguish Gemma 4 unquantized QAT weights from ready-to-run GGUF Q4_0 artifacts, their intended uses and task-quality acceptance.
- [Gemma 4 vs Qwen3.6 for Russian and English text instructions](https://retrivium.ai/journal/gemma4-vs-qwen36-russian-english-text.md): Compare Gemma 4 and Qwen3.6 on matched Russian and English text instructions, terminology, negation and code explanations with independent references.
- [Granite 4.0 Hybrid vs Granite 4.2 Dense: identify the model first](https://retrivium.ai/journal/granite4-hybrid-vs-granite42-dense.md): Distinguish Granite 4.0 H-Small hybrid MoE from Granite 4.2 dense models using exact architecture metadata, model scale and task acceptance.
- [Granite 4.2 full, low-effort and non-thinking modes](https://retrivium.ai/journal/granite42-thinking-low-effort-selection.md): Use Granite 4.2 full, low-effort and non-thinking modes through their actual template controls, then check final answers and history behavior.
- [Granite 4.2 in Russian: test beyond the published language list](https://retrivium.ai/journal/granite42-russian-language-evaluation.md): Evaluate Granite 4.2 for Russian text without treating its published tested-language list as either a guarantee of accuracy or proof of impossibility.
- [Nemotron 3 Nano thinking budget: understand the actual mechanism](https://retrivium.ai/journal/nemotron3-nano-thinking-budget-mechanism.md): Understand Nemotron 3 Nano reasoning-budget control through its documented client mechanism, continuation request and remaining final-answer allowance.
- [Nemotron 3 Nano vs Qwen3-Next: different hybrid text models](https://retrivium.ai/journal/nemotron3-nano-vs-qwen3-next-hybrid.md): Compare Nemotron 3 Nano and Qwen3-Next as different hybrid text models, separating Mamba-based sequence processing, Gated DeltaNet and task outcomes.
- [Nemotron 3 Super vs Nano: choose by reasoning task](https://retrivium.ai/journal/nemotron3-super-vs-nano-task-escalation.md): Choose Nemotron 3 Super or Nano using checked reasoning tasks while separating LatentMoE design, training precision and downloaded checkpoint dtype.
- [SmolLM3 /think vs /no_think for small text tasks](https://retrivium.ai/journal/smollm3-thinking-vs-no-think-tasks.md): Evaluate SmolLM3 /think and /no_think on concise text and checked reasoning, preserving the documented system-prompt controls and language scope.
- [Best local LLM for coding in 2026: choose by the task](https://retrivium.ai/journal/best-local-llm-coding-2026-task-shortlist.md): Build a practical 2026 local coding LLM shortlist from verified Qwen, Devstral, GLM and Gemma checkpoints using task-specific acceptance criteria.
- [LFM2.5 vs LFM2 for narrow text tasks: respect the task boundary](https://retrivium.ai/journal/lfm25-vs-lfm2-narrow-text-tasks.md): Compare LFM2.5 and LFM2 on narrow text decisions while respecting the model cards' limits on programming and knowledge-intensive workloads.
- [BitNet b1.58 vs four-bit PTQ: native training and runtime matter](https://retrivium.ai/journal/bitnet-native-158-vs-post-training-quantization.md): Distinguish BitNet b1.58 native ternary training from four-bit post-training quantization, packed artifacts and runtime-specific efficiency claims.
- [Falcon-H1: evaluate a parallel attention and SSM text model](https://retrivium.ai/journal/falcon-h1-parallel-hybrid-text-evaluation.md): Understand Falcon-H1 parallel attention and SSM design, identify the exact 1.5B Instruct checkpoint and evaluate a bounded text requirement chain.
- [Olmo 3 Think vs Instruct: choose a task and a model-flow checkpoint](https://retrivium.ai/journal/olmo3-think-vs-instruct-model-flow.md): Choose Olmo 3 Think or Instruct by task while distinguishing final releases from Base, SFT, DPO and intermediate model-flow checkpoints.
- [LM Studio: start a local desktop assistant](https://retrivium.ai/journal/lm-studio-first-local-assistant.md): Set up a first LM Studio conversation, identify the local model, and separate desktop chat from optional tools and editor connections.
- [LM Studio vs Ollama: choose a local coding workflow](https://retrivium.ai/journal/lm-studio-vs-ollama-coding-workflow.md): Compare LM Studio and Ollama by model management, editor handoff, and code review workflow without unsupported speed rankings.
- [Use the LM Studio local API from an editor](https://retrivium.ai/journal/lm-studio-local-api-app-onboarding.md): Connect an editor to the LM Studio local server, verify the selected model, and test explanation before allowing file edits.
- [llmster: local AI without the LM Studio desktop window](https://retrivium.ai/journal/llmster-without-lm-studio-gui.md): Understand llmster, lms, and the desktop app, then verify a local editor workflow without keeping the graphical window open.
- [Jan vs LM Studio: choose a local desktop assistant](https://retrivium.ai/journal/jan-vs-lm-studio-local-desktop.md): Compare Jan and LM Studio for desktop conversations, project organization, local API access, and separately configured agent workflows.
- [Jan Desktop: a first local project and model source](https://retrivium.ai/journal/jan-first-local-project.md): Create a first Jan Desktop project and distinguish conversation organization from the local or remote source of generated answers.
- [Jan Agent with a local model: a first reviewed edit](https://retrivium.ai/journal/jan-agent-local-coding-workflow.md): Use Jan Agent with a verified local model endpoint for a small coding task, with explicit action scope and reviewed file changes.
- [Open WebUI with Ollama: connect an existing local runtime](https://retrivium.ai/journal/open-webui-with-ollama-local-chat.md): Connect an existing Ollama runtime to Open WebUI and verify model selection, account visibility, and a follow-up conversation.
- [Open WebUI with vLLM: backend models and workspace wrappers](https://retrivium.ai/journal/open-webui-vllm-model-workspace.md): Connect Open WebUI to an existing vLLM endpoint and distinguish backend model identity, Workspace wrappers, and user access.
- [Open WebUI vs AnythingLLM vs LibreChat for local AI](https://retrivium.ai/journal/open-webui-anythingllm-librechat-choice.md): Compare Open WebUI, AnythingLLM Desktop, and LibreChat by workspace ownership, model wrappers, reusable agents, and access requirements.
- [Open WebUI Desktop or server UI: choose the local workflow](https://retrivium.ai/journal/open-webui-native-desktop-workflow.md): Start with Open WebUI’s native desktop option and a working model connection, then verify conversations and optional Workspace wrappers.
- [LibreChat with local models: build a first reusable agent](https://retrivium.ai/journal/librechat-local-model-agent-start.md): Create a minimal LibreChat agent with a working local model, required builder fields, narrow instructions, and a repeatable trial.
- [AnythingLLM Desktop: built-in inference or a local server](https://retrivium.ai/journal/anythingllm-desktop-local-model-start.md): Configure AnythingLLM Desktop’s language model provider and verify a plain conversation before adding documents or optional agent tools.
- [AnythingLLM Desktop vs server: personal and shared workspaces](https://retrivium.ai/journal/anythingllm-desktop-vs-server-users.md): Choose AnythingLLM Desktop or its server product by personal ownership, independent accounts, invitations, and workspace access requirements.
- [Continue vs Cline vs Aider for local coding](https://retrivium.ai/journal/continue-cline-aider-coding-choice.md): Compare Continue, Cline, and Aider for local coding by IDE assistance, agent actions, Git integration, and the way changes are reviewed.
- [Continue with a local model: chat and autocomplete roles](https://retrivium.ai/journal/continue-local-vscode-chat-completion.md): Configure Continue in VS Code with a local model and separate chat and autocomplete roles, then verify each editor operation.
- [Cline with LM Studio or Ollama: a reviewed local edit](https://retrivium.ai/journal/cline-local-server-reviewed-edit.md): Make a first local Cline edit through a verified runtime, a small repository task, visible tool actions, and an inspected diff.
- [Cline Desktop vs IDE extension for local models](https://retrivium.ai/journal/cline-desktop-vs-ide-local-models.md): Compare Cline Desktop and IDE workflows by local model management, runtime selection, repository context, and review of the same small edit.
- [Aider with local models: make and review a repository edit](https://retrivium.ai/journal/aider-local-model-editing-start.md): Start Aider with a local Ollama model, an understood Git state, explicitly selected files, and a small change that can be reviewed.
- [OpenCode custom provider: local model configuration in V2](https://retrivium.ai/journal/opencode-v2-custom-local-provider.md): Configure an OpenCode V2 custom local provider with the correct package, endpoint, model entry, and explicit provider/model selection.
- [OpenHands Agent Canvas: local workspace, backend and model](https://retrivium.ai/journal/openhands-agent-canvas-local-workflow.md): Use OpenHands Agent Canvas with an existing local model, a local backend, an explicit workspace, and a small reviewed coding task.
- [Zed with a local model: start the native agent workflow](https://retrivium.ai/journal/zed-native-local-ai-start.md): Connect a local model to Zed’s native Agent, verify model discovery, and distinguish agent tools from edit prediction and external agents.
- [goose with a local model: validate a first project task](https://retrivium.ai/journal/goose-local-model-first-task.md): Configure Goose with Ollama or LM Studio for a first local task, distinguishing model generation from extension tools and their permissions.
- [Cherry Studio: local chat providers versus helper models](https://retrivium.ai/journal/cherry-studio-local-chat-model-choice.md): Choose a conversational local model in Cherry Studio through Model Provider settings and avoid confusing it with built-in auxiliary models.
- [Dify with a local LLM: connect a provider and build an app](https://retrivium.ai/journal/dify-local-llm-first-app.md): Connect a local language model to an existing Dify workspace, select it in a minimal app, and distinguish provider setup from node defaults.
- [n8n with a local LLM: a bounded chat-model workflow](https://retrivium.ai/journal/n8n-local-ai-chat-workflow.md): Build a first local AI workflow in an existing n8n instance using Ollama credentials, a chat model connection, and explicit input mapping.
- [Flowise with Ollama: build and test a local Chatflow](https://retrivium.ai/journal/flowise-local-chatflow-first-run.md): Create a first Flowise chatflow using an existing Ollama model, the ChatOllama node, and a minimal conversational path before adding agents.
- [Langflow with a local model: a first conversational flow](https://retrivium.ai/journal/langflow-local-model-first-flow.md): Build a local Langflow conversation with Model Providers, a Language Model component, explicit input/output connections, and Playground verification.
- [n8n vs Dify vs Flowise vs Langflow for local AI workflows](https://retrivium.ai/journal/n8n-dify-flowise-langflow-choice.md): Compare n8n, Dify, Flowise, and Langflow for local AI applications by workflow structure, model ownership, and the first useful output.
- [Choose a local AI stack: desktop chat, shared UI or coding agent](https://retrivium.ai/journal/local-ai-app-stack-selection.md): Choose a minimal local AI application stack by separating the model runtime, conversation interface, coding client, and optional tools.
- [Local coding assistants: first read, edit, review and test](https://retrivium.ai/journal/local-coding-app-read-edit-review-test.md): Complete a first local coding task through explicit reading, a small edit, diff review, and actual test output across coding applications.
- [LM Studio chat works but an editor cannot use the model](https://retrivium.ai/journal/lm-studio-chat-works-editor-cannot-connect.md): Diagnose an editor that cannot use LM Studio despite a working desktop chat by separating runtime state, local serving, and client model selection.
- [Jan server will not start: check the local startup model](https://retrivium.ai/journal/jan-local-server-startup-model-required.md): Fix Jan API server startup by selecting a loadable local default model, while keeping later remote-provider routing as a separate behavior.
- [Open WebUI model is visible to admin but not another user](https://retrivium.ai/journal/open-webui-model-visible-admin-only.md): Diagnose Open WebUI models visible only to an administrator by separating backend inventory, hidden entries, base access, and Workspace sharing.
- [Open WebUI Tools, Functions and Pipes: choose an extension](https://retrivium.ai/journal/open-webui-tools-functions-pipes-choice.md): Choose an Open WebUI extension by its job: callable Tool, selectable Pipe, message Filter, user-triggered Action, or existing HTTP integration.
- [LibreChat MCP connects but the agent has no tool](https://retrivium.ai/journal/librechat-agent-mcp-tool-not-visible.md): Find a missing LibreChat MCP tool by checking ordinary chat selection, Agent Builder bindings, per-user authentication, and model capabilities.
- [LibreChat Code Interpreter: execute code and retrieve files](https://retrivium.ai/journal/librechat-code-interpreter-files-workflow.md): Use LibreChat Code Interpreter on a configured instance, attach files to its code environment, inspect execution output, and retrieve generated files.
- [AnythingLLM Desktop MCP tools do not start or get called](https://retrivium.ai/journal/anythingllm-desktop-mcp-not-starting.md): Fix AnythingLLM Desktop MCP startup through Agent Skills, host command availability, configuration refresh, and supported tool capabilities.
- [Continue chat works but autocomplete does not appear](https://retrivium.ai/journal/continue-chat-works-autocomplete-missing.md): Diagnose missing Continue inline suggestions by checking the active autocomplete role, selected model, invocation behavior, and output filtering.
- [Undo Cline edits: checkpoints, Git history and side effects](https://retrivium.ai/journal/cline-checkpoints-restore-boundaries.md): Understand Cline checkpoint restore options, the shadow Git repository, conversation history, and effects that file restoration does not reverse.
- [Aider commits and undo with existing repository changes](https://retrivium.ai/journal/aider-git-dirty-tree-undo.md): Use Aider with existing repository changes by separating user work, automatic commits, diff review, and the actual boundary of undo.
- [Aider repo map versus files added for editing](https://retrivium.ai/journal/aider-repomap-editable-files.md): Distinguish Aider’s repository map from editable files, then supply the right implementation and reference context for a focused local change.
- [OpenCode V2 responds but a tool is denied](https://retrivium.ai/journal/opencode-v2-tool-permission-denied.md): Diagnose OpenCode V2 tool denials through ordered permission rules, actual action names, agent overrides, and multi-resource decisions.
- [OpenCode V1 to V2: keep a local coding workflow](https://retrivium.ai/journal/opencode-v1-v2-local-migration.md): Move an existing local OpenCode workflow from V1 to V2 by checking the executable generation, provider schema, permissions, and one small task.
- [OpenHands Canvas cannot find project files: locate the backend workspace](https://retrivium.ai/journal/openhands-canvas-workspace-file-location.md): Locate missing project files in OpenHands Agent Canvas by distinguishing the browser, execution backend, active workspace, and model endpoint.
- [Zed native or ACP agent: which settings apply?](https://retrivium.ai/journal/zed-native-vs-acp-settings-owner.md): Find the owner of Zed AI settings by distinguishing its native Agent, external ACP processes, forwarded MCP tools, and agent-native configuration.
- [Roo Code is retired: preserve a local workflow before migrating](https://retrivium.ai/journal/roo-code-retired-local-workflow-migration.md): Preserve an existing Roo Code local workflow after its official retirement by inventorying rules and model choices before evaluating a replacement.
- [goose connects to a model but a local extension is unavailable](https://retrivium.ai/journal/goose-local-extension-not-found.md): Diagnose unavailable Goose extensions through activation, process startup, command availability, tool permissions, and local model tool support.
- [LM Studio presets do not restore model load settings](https://retrivium.ai/journal/lm-studio-presets-load-defaults.md): Separate LM Studio chat presets from per-model load defaults, then save reusable instructions and model loading choices in the correct places.
- [Jan Agent fork and rewind: history versus file restoration](https://retrivium.ai/journal/jan-agent-fork-rewind-files.md): Use Jan Agent fork and rewind with clear boundaries between saved sessions, Git-based file restoration, project identity, and durable memory.
- [Jan Agent safe mode and shell sandbox are different controls](https://retrivium.ai/journal/jan-safe-mode-shell-sandbox.md): Separate Jan Agent approval prompts from shell confinement, inspect effective project settings and account for memory tools that follow their own policy.
- [Export Open WebUI chats and workspace items with the right scope](https://retrivium.ai/journal/open-webui-chat-vs-workspace-export.md): Move Open WebUI conversations and workspace definitions using separate exports, account for fresh import IDs and verify attached resources on the target instance.
- [Open WebUI prompt variables: reusable task forms](https://retrivium.ai/journal/open-webui-prompt-template-variables.md): Build Open WebUI slash-command prompts with typed inputs, distinguish system substitutions from user fields and keep prompt templates separate from model wrappers.
- [Share a LibreChat agent without assuming tools share access](https://retrivium.ai/journal/librechat-share-agent-tool-permissions.md): Share a LibreChat agent through explicit roles while keeping model access, MCP credentials and tool approval separate for each user.
- [Continue project rules and current configuration](https://retrivium.ai/journal/continue-project-rules-current-config.md): Use Continue project rules alongside current YAML model configuration, distinguish instructions from enforcement and migrate legacy examples with their scope intact.
- [Aider architect and editor roles with local models](https://retrivium.ai/journal/aider-architect-editor-local-workflow.md): Configure Aider architect and editor responsibilities for local models, distinguish discussion from editing, and review the resulting repository changes.
- [OpenHands repository skills: migrate older instruction examples](https://retrivium.ai/journal/openhands-repository-skills-current-layout.md): Migrate OpenHands repository instructions into concise AGENTS.md guidance and current Agent Skills locations while separating hooks, setup and tool permissions.
- [Zed Agent Profiles: availability is not tool approval](https://retrivium.ai/journal/zed-agent-profiles-tool-availability.md): Configure Zed native Agent Profiles separately from tool approval policy, identify the active profile and keep external ACP agent settings in their own scope.
- [goose recipes: repeat a local task with explicit inputs](https://retrivium.ai/journal/goose-recipes-local-task-reuse.md): Create reusable goose recipes with explicit parameters, compatible extensions and a verified local model, then test missing inputs before trusting repeated runs.
- [Cherry Studio backup versus archive: what is restored?](https://retrivium.ai/journal/cherry-studio-backup-archive-local-data.md): Separate Cherry Studio backups from its Archive, compare full and Lite content, and verify restore dependencies before relying on a local data recovery plan.
- [Qdrant RRF versus DBSF: choose fusion with a held-out query set](https://retrivium.ai/journal/qdrant-rrf-dbsf-fusion-selection.md): RRF and DBSF answer different fusion questions in Qdrant: one combines positions, while the other preserves information about score gaps.
- [Qdrant filtered HNSW: payload indexes are part of the search plan](https://retrivium.ai/journal/qdrant-payload-index-filtered-hnsw.md): A metadata filter changes the search problem in Qdrant, rather than merely hiding rows after retrieval.
- [ColBERT in Qdrant: preserve token vectors and MaxSim semantics](https://retrivium.ai/journal/qdrant-colbert-maxsim-multivectors.md): A ColBERT representation is a matrix of token vectors, not a longer ordinary embedding to average before searching.
- [Qdrant document grouping: stop one document from filling every result](https://retrivium.ai/journal/qdrant-document-grouping-chunk-diversity.md): Document grouping in Qdrant answers a different question from returning the nearest chunks.
- [pgvector halfvec indexing: retain full vectors for final scoring](https://retrivium.ai/journal/pgvector-halfvec-expression-index-rerank.md): A halfvec expression index can use a reduced-precision search representation without replacing the original vectors stored in the table.
- [pgvector binary quantization: Hamming candidates need full-vector reranking](https://retrivium.ai/journal/pgvector-binary-hamming-candidate-rerank.md): Binary quantization in pgvector is a candidate-generation technique, not a replacement for checking final relevance with the intended vector metric.
- [pgvector cosine and inner product: normalization and ORDER BY must agree](https://retrivium.ai/journal/pgvector-cosine-inner-product-ordering.md): Cosine distance and inner product can produce compatible rankings under particular normalization conditions, but their SQL operators do not have the same sign or meaning.
- [Milvus BM25 functions: combine server-generated sparse and dense retrieval](https://retrivium.ai/journal/milvus-bm25-function-dense-sparse-fusion.md): Milvus can generate BM25 sparse vectors from raw text through a declared function while searching a separate dense representation.
- [Milvus consistency: why a newly inserted document is not yet found](https://retrivium.ai/journal/milvus-consistency-new-document-visibility.md): An acknowledged insert and a searchable document are different observations in Milvus.
- [Milvus partition keys: tenant routing is not an authorization policy](https://retrivium.ai/journal/milvus-partition-key-tenant-query-boundary.md): A Milvus partition key helps organize and route data, but it is not an application authorization policy.
- [Weaviate hybrid fusion: alpha and score gaps change different decisions](https://retrivium.ai/journal/weaviate-hybrid-fusion-alpha-score-gaps.md): Weaviate hybrid fusion combines lexical and vector results, but changing the fusion strategy is not the same intervention as changing alpha.
- [Weaviate filtered search: compare sweeping, ACORN and PathSeer](https://retrivium.ai/journal/weaviate-filter-strategies-acorn-pathseer.md): Filtered HNSW in Weaviate has several traversal strategies, so choosing ACORN is not simply enabling a generic filter.
- [Weaviate BM25F: rank titles and body text without filtering evidence away](https://retrivium.ai/journal/weaviate-bm25f-field-weighting.md): BM25F field weights in Weaviate change how lexical evidence contributes to ranking; they do not replace the decision about which evidence is searchable.
- [Elasticsearch hybrid search: RRF versus normalized linear retrieval](https://retrivium.ai/journal/elasticsearch-rrf-linear-hybrid-retrievers.md): Elasticsearch RRF and linear retrievers combine signals through different contracts: rank positions versus normalized weighted scores.
- [OpenSearch hybrid search: normalization and score-ranker pipelines](https://retrivium.ai/journal/opensearch-hybrid-normalization-score-ranker.md): OpenSearch score normalization and reciprocal rank fusion belong to different search-pipeline configurations.
- [LanceDB phrase search: preserve positions before hybrid retrieval](https://retrivium.ai/journal/lancedb-phrase-search-hybrid-candidates.md): Phrase retrieval in LanceDB requires an index and query contract that preserves word positions.
- [RAG chunking strategies: document structure versus fixed token windows](https://retrivium.ai/journal/rag-chunking-structure-token-boundaries.md): A RAG chunking strategy defines which evidence can be retrieved together, not just how many tokens enter an embedding call.
- [Late chunking for RAG: embed context before pooling fragments](https://retrivium.ai/journal/rag-late-chunking-contextual-embeddings.md): Late chunking encodes broader document context before pooling token ranges into chunk embeddings.
- [RAG chunk overlap: measure lost boundaries and duplicated evidence](https://retrivium.ai/journal/rag-chunk-overlap-duplicate-evidence.md): Increasing chunk overlap changes both boundary coverage and repeated evidence in a RAG index.
- [Chunk tables for RAG without losing column headers and units](https://retrivium.ai/journal/rag-table-chunks-headers-units.md): A retrievable table fragment needs enough structure to explain what each value means, not merely the characters from one row.
- [EmbeddingGemma retrieval: query and document prompts must stay distinct](https://retrivium.ai/journal/embeddinggemma-query-document-prompts.md): EmbeddingGemma retrieval uses different input roles for a query and a source document, so a shared text-encoding call needs an explicit prompt contract.
- [Jina embeddings v4: dense and multi-vector outputs are different index contracts](https://retrivium.ai/journal/jina-v4-dense-multivector-task-contract.md): Jina embeddings v4 can expose dense and multi-vector representations, but those outputs are different index contracts rather than interchangeable serialization options.
- [Nemotron 3.5 Embed: evaluate text and page-image retrieval together](https://retrivium.ai/journal/nemotron-35-embed-multimodal-retrieval.md): Nemotron 3.5 Embed should be evaluated with matched text and page-image queries, because changing the document representation changes the retrieval problem.
- [ColPali document search: migrate to Sentence Transformers without changing scores](https://retrivium.ai/journal/colpali-sentence-transformers-v6-migration.md): Migrating ColPali to Sentence Transformers requires a score-parity fixture, because replacing imports alone can silently change query processing and similarity.
- [ColPali similarity maps: model focus is not an OCR citation box](https://retrivium.ai/journal/colpali-similarity-maps-source-grounding.md): ColPali similarity maps explain which image patches match query tokens, but they do not establish an OCR quotation or a verified citation box.
- [BEIR qrels: an unjudged passage is not a verified negative](https://retrivium.ai/journal/beir-qrels-unjudged-retrieval-evaluation.md): A missing BEIR relevance judgment does not establish that a passage is a verified negative.
- [MTEB and MMTEB: choose tasks before ranking embedding models](https://retrivium.ai/journal/mteb-mmteb-domain-task-selection.md): MTEB and MMTEB scores become useful only after selecting tasks and languages that match the intended retrieval workload.
- [Ragas context precision, recall and faithfulness measure different failures](https://retrivium.ai/journal/ragas-retrieval-faithfulness-metric-boundaries.md): Ragas context precision, context recall and faithfulness answer different questions about a RAG pipeline.
- [Synthetic RAG test sets: keep document leakage out of the holdout](https://retrivium.ai/journal/rag-synthetic-testset-leakage-controls.md): Synthetic RAG questions should be generated after separating source documents into development and holdout groups.
- [RAG noise sensitivity: test distractors without changing the answer target](https://retrivium.ai/journal/rag-noise-sensitivity-distractor-tests.md): RAG noise tests should change the surrounding context while keeping the question and answer target fixed.
- [RAG citations: measure support and completeness separately](https://retrivium.ai/journal/rag-citation-precision-completeness.md): Citation quality has separate dimensions: whether attached sources support a claim and whether important claims receive citations at all.
- [Matryoshka embeddings: truncate and normalize both sides consistently](https://retrivium.ai/journal/matryoshka-truncation-query-index-contract.md): Matryoshka embeddings can be shortened only under the selected model's supported representation contract, with matching treatment of queries and indexed documents.
- [Nemotron 3.5 Rerank: interpret scores before choosing a relevance threshold](https://retrivium.ai/journal/nemotron-35-rerank-score-thresholds.md): Nemotron 3.5 Rerank scores should be interpreted under the checkpoint's output contract before setting any rejection threshold.
- [PDF to Markdown for RAG: fix reading order before indexing](https://retrivium.ai/journal/pdf-to-markdown-reading-order-rag.md): PDF-to-Markdown conversion should preserve reading order before a RAG index is built, because perfectly recognized words can still form the wrong document.
- [Extract PDF tables for RAG: merged cells and repeated headers](https://retrivium.ai/journal/pdf-table-extraction-merged-cells.md): PDF tables need their header relationships and merged-cell scope preserved before they become RAG evidence.
- [Unstructured PDF parsing: fast, hi_res and ocr_only solve different inputs](https://retrivium.ai/journal/unstructured-pdf-strategy-selection.md): Unstructured PDF strategies should be selected by the document's actual content and required structure, rather than treating fast, hi_res and ocr_only as quality levels.
- [PyMuPDF text extraction: a text layer does not guarantee reading order](https://retrivium.ai/journal/pymupdf-digital-pdf-text-order.md): A selectable PDF text layer does not guarantee that extracted words follow human reading order.
- [Mixed PDF OCR: avoid duplicating an existing text layer](https://retrivium.ai/journal/pdf-ocr-overlay-duplicate-text.md): Mixed PDFs require an OCR policy that distinguishes existing digital text from text contained only in images.
- [PDF citations: keep page coordinates correct after rotation and cropping](https://retrivium.ai/journal/pdf-citation-coordinates-rotation-crop.md): PDF citation boxes must use an explicit coordinate system, especially after page rotation, cropping or rendering.
- [Documents to Markdown or JSON: preserve evidence provenance for RAG](https://retrivium.ai/journal/document-markdown-json-provenance.md): Markdown and structured JSON serve different roles in a document-to-RAG pipeline: readable text is useful for retrieval, while structured provenance is needed to reconstruct evidence.
- [Excel to RAG: formulas, cached values and merged cells need explicit rules](https://retrivium.ai/journal/excel-rag-formulas-merged-hidden-cells.md): Excel ingestion for RAG must distinguish formulas, cached values and workbook structure before turning cells into prose.
- [Web pages for RAG: remove navigation without losing source evidence](https://retrivium.ai/journal/webpage-clean-text-rag-trafilatura.md): Clean webpage text for RAG should retain the article's actual evidence while excluding navigation and unrelated page furniture.
- [Search meeting recordings: preserve speaker turns and audio evidence](https://retrivium.ai/journal/meeting-search-transcript-speaker-evidence.md): Meeting search needs evidence tied to the recording, not just a polished transcript with speaker names attached.
- [WhisperX alignment gaps: numbers and symbols may lack word timestamps](https://retrivium.ai/journal/whisperx-forced-alignment-missing-words.md): WhisperX can leave recognized words without reliable alignment when its alignment model cannot map their characters or sounds.
- [pyannote diarization: speaker turns, overlap and identity are different outputs](https://retrivium.ai/journal/pyannote-exclusive-diarization-speaker-identity.md): Pyannote exclusive diarization can simplify assigning transcript words to speakers, but it does not identify real people.
- [Silero VAD before ASR: sample rate and speech boundaries must agree](https://retrivium.ai/journal/silero-vad-resampling-speech-boundaries.md): Voice activity detection depends on correct audio sampling and timestamp mapping before it can safely remove silence.
- [faster-whisper batching: check VAD defaults before comparing transcripts](https://retrivium.ai/journal/faster-whisper-batched-vad-output-differences.md): Moving faster-whisper transcription to a batched pipeline can change the preprocessing contract, including voice activity detection defaults.
- [WER and CER for speech recognition: normalize text without hiding errors](https://retrivium.ai/journal/asr-wer-cer-normalization-russian.md): WER and CER compare transcripts only under a declared normalization policy, especially for Russian text containing numbers, punctuation and spelling variants.
- [Transcript cleanup: punctuation must not break word-time alignment](https://retrivium.ai/journal/asr-punctuation-word-timestamp-integrity.md): Punctuation restoration should change transcript presentation without silently rewriting word identity or timing provenance.
- [Speech to subtitles: validate SRT and WebVTT cue boundaries](https://retrivium.ai/journal/speech-subtitles-srt-vtt-cue-validation.md): Subtitle export needs its own validation even when the underlying transcript is correct.
- [Video retrieval timestamps: use PTS rather than frame-number arithmetic](https://retrivium.ai/journal/video-vfr-pts-frame-indexing.md): Variable-frame-rate video should be indexed with presentation timestamps and time bases rather than assuming that frame number divided by nominal frame rate gives exact time.
- [Index video keyframes: scene detection versus fixed-rate sampling](https://retrivium.ai/journal/video-keyframes-scene-detection-indexing.md): Scene detection and periodic frame sampling solve different video-indexing problems, so neither should be adopted as a universal keyframe strategy.
- [Local video search: join transcript evidence with visual keyframes](https://retrivium.ai/journal/local-video-search-transcript-keyframes.md): Local video search should join transcript spans and selected frames through source time, while preserving each modality's evidence separately.
- [Russian keyword retrieval: stemming must not destroy exact identifiers](https://retrivium.ai/journal/russian-bm25-analyzer-exact-identifiers.md): Russian BM25 search should separate linguistic matching from exact identifier matching rather than forcing both into one analyzed field.
- [Elasticsearch passage retrieval: nested kNN and supporting inner hits](https://retrivium.ai/journal/elasticsearch-nested-passage-inner-hits.md): Elasticsearch nested passage retrieval should return the passage that produced a document's match, not only the parent document.
- [Neural sparse search in OpenSearch: token weights are not ordinary BM25](https://retrivium.ai/journal/opensearch-neural-sparse-vocabulary-contract.md): Learned sparse retrieval requires matching document and query vocabularies, not merely accepting arrays of token identifiers and weights.
- [Qdrant sparse IDF: corpus changes can alter query scoring](https://retrivium.ai/journal/qdrant-sparse-idf-corpus-updates.md): Qdrant sparse IDF scores can change when the indexed corpus changes even if the query text and stored document vectors remain unchanged.
- [Milvus text matching versus BM25: filtering is not relevance ranking](https://retrivium.ai/journal/milvus-text-match-bm25-filter-ranking.md): Milvus TEXT_MATCH filters documents by analyzed terms, while a BM25 Function supplies a ranked full-text retrieval path.
- [Update RAG documents without leaving stale chunks and citations](https://retrivium.ai/journal/rag-document-updates-stale-chunk-citations.md): Version RAG documents and their chunks explicitly, remove superseded search evidence, and retain citation provenance without confusing historical and active content.
- [ColBERT PLAID: index compression and candidate pruning are separate checks](https://retrivium.ai/journal/colbert-plaid-late-interaction-index.md): Separate ColBERTv2 residual compression from PLAID candidate pruning, then evaluate index footprint, candidate recall and final late-interaction ranking independently.
- [LMCache vs vLLM prefix caching: choose the cache boundary](https://retrivium.ai/journal/lmcache-vs-vllm-prefix-caching.md): Compare engine-local prefix reuse with an external KV cache, including native vLLM offloading, cache lifetime and the cost of moving cached blocks.
- [LMCache CPU offload: size a reusable KV working set](https://retrivium.ai/journal/lmcache-cpu-kv-offload.md): Plan CPU memory for reusable KV blocks, distinguish cache offload from weight offload, and test transfer pressure alongside the inference workload.
- [Persistent KV cache invalidation: when a prefix stops being reusable](https://retrivium.ai/journal/persistent-kv-cache-invalidation.md): Define cache namespaces across weight revisions, tokenizers, layouts and tenant boundaries before reusing KV blocks after an inference deployment changes.
- [CacheBlend for RAG: reuse document chunks beyond an exact prefix](https://retrivium.ai/journal/cacheblend-rag-non-prefix-reuse.md): Understand selective recomputation in CacheBlend, why reordered retrieved chunks challenge ordinary prefix reuse, and how to evaluate answer quality.
- [FP8 KV cache: precision, calibration and long-context quality](https://retrivium.ai/journal/fp8-kv-cache-calibration-quality.md): Separate KV-cache precision from weight quantization, verify backend and scale support, and evaluate long-context accuracy before allocating more concurrency.
- [NVIDIA Dynamo vs vLLM: orchestration and inference are different layers](https://retrivium.ai/journal/nvidia-dynamo-vs-vllm-serving-layer.md): Place Dynamo routing, planning and cache movement around an inference engine, and identify when a simpler vLLM service is sufficient for the workload.
- [Dynamo KV-aware routing: balance cached context against queueing](https://retrivium.ai/journal/dynamo-kv-aware-routing-cache-queue.md): Evaluate cache-aware worker selection using prefix locality, queue delay and stale state, without confusing it with application-level model routing.
- [Dynamo KVBM: budget GPU, host and storage tiers separately](https://retrivium.ai/journal/dynamo-kvbm-memory-tiers.md): Read the KV Block Manager as a memory hierarchy, including block movement, pinned host capacity, storage latency and version-specific integration limits.
- [vLLM prefill-decode disaggregation: when separate pools help](https://retrivium.ai/journal/vllm-prefill-decode-disaggregation-architecture.md): Evaluate separate prefill and decode workers through phase interference, KV transfer, replica balance and useful completions under latency constraints.
- [NIXL vs NCCL: KV movement and collective communication](https://retrivium.ai/journal/nixl-vs-nccl-data-movement.md): Distinguish a heterogeneous data-movement layer from GPU communication primitives, and map their complementary roles in distributed LLM serving.
- [LMCache vs Mooncake: compare the component, not just the project](https://retrivium.ai/journal/lmcache-vs-mooncake-kv-cache.md): Compare LMCache integration with Mooncake transfer and storage components, including overlaps, composable paths and workload-specific evaluation criteria.
- [RoCE vs InfiniBand for LLM serving: qualify the full fabric](https://retrivium.ai/journal/roce-vs-infiniband-llm-serving.md): Compare RDMA over Ethernet with InfiniBand through adapters, switches, congestion and real inference transfers, without treating link speed as an SLO.
- [Expert parallel vs tensor parallel for MoE inference](https://retrivium.ai/journal/expert-parallel-vs-tensor-parallel-moe.md): Separate expert placement from tensor sharding, map attention and MoE groups, and test dispatch imbalance before choosing a multi-GPU topology.
- [Data parallel vs tensor parallel: replicas or a split model?](https://retrivium.ai/journal/data-parallel-vs-tensor-parallel-serving.md): Choose between independent serving replicas and tensor-sharded execution using model fit, cache locality, failure boundaries and measured communication.
- [FlashAttention vs PagedAttention: different attention problems](https://retrivium.ai/journal/flashattention-vs-pagedattention.md): Distinguish efficient attention computation from paged KV memory management, and understand why a serving backend can combine ideas from both.
- [FlashInfer vs FlashAttention: compare the actual kernel path](https://retrivium.ai/journal/flashinfer-vs-flashattention-kernel-stack.md): Place FlashInfer kernel collections and FlashAttention implementations within a serving backend, then compare supported operations rather than brand names.
- [CUDA Graphs vs torch.compile: replay and compilation can coexist](https://retrivium.ai/journal/cuda-graphs-vs-torch-compile.md): Separate kernel replay from graph compilation, compare startup and steady-state costs, and test shape diversity before selecting an inference optimization.
- [LLM goodput vs tokens per second: count requests meeting the objective](https://retrivium.ai/journal/llm-goodput-vs-tokens-per-second.md): Define useful serving capacity through completed requests meeting first-token and token-pacing limits, then keep that measure separate from raw throughput.
- [SGLang HiCache vs RadixAttention: a hierarchy around prefix reuse](https://retrivium.ai/journal/sglang-hicache-vs-radixattention.md): Separate radix-based prefix reuse from the host and storage hierarchy, then evaluate cache movement, model-state compatibility and working-set churn.
- [Gateway API Inference Extension vs ordinary load balancing](https://retrivium.ai/journal/gateway-api-inference-extension-vs-load-balancer.md): Understand InferencePool and endpoint picking for LLM workers, including compatibility, stale metrics and the boundary between routing and model execution.

## AI retrospectives (500)

Events from 3 August to 3 November 2026. Analyses published on 3 November. Each analysis answers an independent question; selection uses dated announcements, independent coverage and public discussion, not measured global popularity.

- [Collection and selection method](https://retrivium.ai/retrospectives/)
- [RSS](https://retrivium.ai/retrospectives/rss.xml)
- [How digitizing planning records prepared the way for PlanAssist](https://retrivium.ai/retrospectives/planassist-digitization-before-assistance.md): How the earlier Extract programme and planning-data digitization prepared the context for PlanAssist, with different roles for records and recommendations. (event: 2026-10-31)
- [Why PlanAssist separates assessment time from planning outcomes](https://retrivium.ai/retrospectives/planassist-assessment-time-vs-outcome.md): Why the PlanAssist pilot calls for separate measures of officer assessment time, total application duration and the quality of the final decision. (event: 2026-10-31)
- [How local policy became the scaling test for public-sector AI](https://retrivium.ai/retrospectives/planassist-local-policy-portability.md): How PlanAssist’s expansion makes local policy, record quality and qualified review the practical test of scaling an administrative AI assistant. (event: 2026-10-31)
- [Large4 weights: why the October29 checkpoint is not merely the preview download](https://retrivium.ai/retrospectives/large4-improved-weights-not-preview-snapshot.md): The Large4 weight release is significant because it publishes an improved artifact after the earlier preview, rather than merely exposing a download of the same observed service. (event: 2026-10-29)
- [Large4 open weights: the published model-as-a-service license boundary](https://retrivium.ai/retrospectives/large4-open-weight-maas-boundary.md): Mistral Large4's open-weight release uses a modified license with a model-as-a-service condition, so it should not be archived under an ordinary unrestricted MIT label. (event: 2026-10-29)
- [Mistral Large 4 (Le Chonk) is now open weight: internal use and model-as-a-service](https://retrivium.ai/retrospectives/retro-mistral-large4-weights-maas-license.md): For Mistral Large4, an internal application and a model-serving offering are different deployment descriptions, so an inventory should identify the actual relationship before interpreting release terms. (event: 2026-10-29)
- [Mistral Large 4 (Le Chonk) is now open weight: additional post-training after a preview](https://retrivium.ai/retrospectives/retro-mistral-large4-weights-checkpoint-delta.md): Mistral Large4's published weights followed additional post-training, so an earlier preview evaluation cannot be treated as direct acceptance of the later artifact. (event: 2026-10-29)
- [Carbon shortened the evaluation window after Argon GA](https://retrivium.ai/retrospectives/carbon-after-argon-evaluation-window.md): How Carbon's announcement soon after Argon GA illustrates the need for evaluation cutoffs and explicit reasons to reopen a model-selection study. (event: 2026-10-28)
- [A trusted-partner announcement is not a deployable default](https://retrivium.ai/retrospectives/carbon-trusted-access-procurement.md): Why Carbon's trusted-partner announcement belongs in conditional architecture planning rather than an unverified current deployment default. (event: 2026-10-28)
- [Carbon's cyber evidence spans different task boundaries](https://retrivium.ai/retrospectives/carbon-cyber-benchmark-boundaries.md): How to read Carbon's discovery, validation and patching evidence as different task outcomes rather than one end-to-end security guarantee. (event: 2026-10-28)
- [Persistent Carbon work needs honest blocker handling](https://retrivium.ai/retrospectives/carbon-long-horizon-avoid-shortcuts.md): Why Carbon's long-work claims should be tested through useful partial artifacts, explicit blocked dependencies and honest final limitations. (event: 2026-10-28)
- [Why input-token price stopped being the whole routing decision](https://retrivium.ai/retrospectives/retro-openrouter-effective-routing-cost.md): OpenRouter’s October routing rebuild followed earlier provider-quality work. The useful comparison is billed usage plus execution consequences, not a nominal rate alone. (event: 2026-10-28)
- [What the new OpenRouter router leaves under caller control](https://retrivium.ai/retrospectives/retro-openrouter-routing-explicit-constraints.md): The October router separates provider eligibility from provider selection. Ordered routes, explicit sorts and candidate filters have different effects. (event: 2026-10-28)
- [How routing signals change the incentive to add reliable capacity](https://retrivium.ai/retrospectives/retro-openrouter-provider-incentives.md): OpenRouter’s routing rebuild connects provider selection to observed service. Installed GPUs, usable route capacity and allocated traffic remain different quantities. (event: 2026-10-28)
- [Nemotron Transcribe and Granaryv2: a speech model plus its adaptation path](https://retrivium.ai/retrospectives/nemotron-transcribe-granary-model-data-split.md): Nemotron Transcribe and Granaryv2 form a model-and-adaptation release, not just a new transcription endpoint. (event: 2026-10-28)
- [Nemotron3.5 Transcribe and Granaryv2: held-out speakers and adaptation claims](https://retrivium.ai/retrospectives/retro-nemotron35-transcribe-speaker-holdout.md): NemotronTranscribe's adaptation workflow needs speaker-separated acceptance when the claim concerns unfamiliar voices, because familiar-speaker success can overstate generalization. (event: 2026-10-28)
- [Nemotron3.5 Transcribe and Granaryv2: prompted vocabulary and faithful transcription](https://retrivium.ai/retrospectives/retro-nemotron35-transcribe-prompted-asr.md): NemotronTranscribe's prompted vocabulary can help a recognizer consider rare terms, but it should not make supplied words count as evidence that they were actually spoken. (event: 2026-10-28)
- [Nemotron3.5 Transcribe and Granaryv2: open data workflow and reproducibility](https://retrivium.ai/retrospectives/retro-nemotron35-transcribe-data-recipe.md): Granary's open workflow and NemotronTranscribe's available model are different reproducibility artifacts, so obtaining one does not automatically reproduce the other's full training history. (event: 2026-10-28)
- [Meta Helios testing versus a six-gigawatt agreement](https://retrivium.ai/retrospectives/retro-meta-helios-testing-vs-capacity.md): Meta’s initial Helios installation and testing marks deployment progress. The February commitment, platform release and usable application capacity remain separate milestones. (event: 2026-10-27)
- [Why Meta’s AMD milestone spans ROCm, CPUs, and networking](https://retrivium.ai/retrospectives/retro-meta-amd-co-design-software.md): The AMD–Meta chronology makes co-design an interface question. A system-level result depends on qualified combinations, workload feedback and the operator’s environment. (event: 2026-10-27)
- [Day-zero support is not the end of infrastructure validation](https://retrivium.ai/retrospectives/retro-meta-day-zero-support-validation.md): Day-zero model support and rack acceptance validate different layers. The Helios chronology shows why software readiness cannot stand in for system testing. (event: 2026-10-27)
- [Installed, tested and accepted are separate Helios milestones](https://retrivium.ai/retrospectives/retro-meta-helios-acceptance-ladder.md): Helios testing makes acceptance a scoped decision about a named configuration. A useful record preserves workload, observed result, exceptions and the decision owner. (event: 2026-10-27)
- [Why a GPU cloud’s backbone matters for model and dataset movement](https://retrivium.ai/retrospectives/retro-global-ai-backbone-model-artifacts.md): CoreWeave’s backbone expands artifact-staging options across locations. Useful deployment still requires a coherent version, validated arrival and a separate activation step. (event: 2026-10-27)
- [A network point of presence is not a new GPU region](https://retrivium.ai/retrospectives/retro-network-pop-is-not-compute-region.md): CoreWeave’s network and facility announcements have different clocks. A new PoP describes connectivity; GPU service and customer allocation require separate evidence. (event: 2026-10-27)
- [Backbone encryption and the remaining trust boundaries of an AI cloud](https://retrivium.ai/retrospectives/retro-ai-backbone-encryption-boundary.md): CoreWeave’s MACsec claim concerns network-path protection. Application termination, plaintext access, retention and runtime integrity remain separate trust questions. (event: 2026-10-27)
- [Moving model artifacts and serving tokens need different network evidence](https://retrivium.ai/retrospectives/retro-ai-backbone-artifact-inference.md): CoreWeave’s backbone can affect preparation and live response through different paths. A measurement needs explicit start and end events before it can explain either benefit. (event: 2026-10-27)
- [ECS moves from whole-GPU assignment to shared scheduling](https://retrivium.ai/retrospectives/retro-ecs-gpu-granularity-mps.md): ECS GPU sharing introduces per-task budgets on a shared device. Finer allocation enables packing choices, while workload fit and useful performance still need application evidence. (event: 2026-10-27)
- [ECS MPS limits versus isolation: different questions](https://retrivium.ai/retrospectives/retro-ecs-mps-memory-compute-isolation.md): ECS GPU budgets describe allocation, while isolation requires a separate property and mechanism. The MPS announcement does not identify its daemon interface version or equate MPS with MIG. (event: 2026-10-27)
- [Why managed MPS daemon recovery changes operational ownership](https://retrivium.ai/retrospectives/retro-managed-mps-daemon-lifecycle.md): ECS sharing spans two deployment modes, but the announced daemon monitoring and automatic instance replacement are scoped to Managed Instances. Recovery ownership must preserve that distinction. (event: 2026-10-27)
- [Shared GPU service adds a daemon lifecycle to the task lifecycle](https://retrivium.ai/retrospectives/retro-ecs-mps-daemon-lifecycle.md): ECS shared-GPU recovery spans task, daemon and host lifecycles. Moving a task to healthy capacity is distinct from preserving its application and in-flight GPU state. (event: 2026-10-27)
- [An OCI TPU announcement is not an allocatable TPU region](https://retrivium.ai/retrospectives/retro-oci-tpu-announcement-availability.md): Google and Oracle planned OCI TPU capacity from 2027 with a multiyear ramp. The October announcement is a distribution milestone rather than current inventory. (event: 2026-10-27)
- [Why bringing an accelerator to the data differs from connecting two clouds](https://retrivium.ai/retrospectives/retro-oci-tpu-data-proximity.md): The OCI TPU plan proposes accelerator execution inside OCI after an earlier multicloud interconnect partnership. Data proximity remains a workload-specific question. (event: 2026-10-27)
- [TPU software portability and datacenter readiness run on different clocks](https://retrivium.ai/retrospectives/retro-oci-tpu-software-physical.md): OCI TPU software adoption and physical delivery have different dependencies. Familiar tooling can reduce porting work without making future capacity immediately usable. (event: 2026-10-27)
- [Multiple accelerators in one cloud do not eliminate workload qualification](https://retrivium.ai/retrospectives/retro-oci-tpu-architecture-choice.md): Adding TPUs to OCI would broaden architecture choice from 2027. Model support, operational fit and cost per acceptable result still require workload qualification. (event: 2026-10-27)
- [CoreWeave Denmark: Why most of 22.5 MW is not the same as all of 22.5 MW](https://retrivium.ai/retrospectives/retro-denmark-majority-online.md): CoreWeave’s Denmark update followed future regional expansion plans. Why reporting most of a planned 22.5 MW online requires preserving the commissioning fraction. (event: 2026-10-27)
- [CoreWeave Denmark: A colocation operator and a GPU cloud deliver different parts of capacity](https://retrivium.ai/retrospectives/retro-denmark-colocation-cloud-boundary.md): CoreWeave’s deployment at atNorth DEN01 followed platform and regional expansion milestones. Why colocation capacity and a GPU cloud are complementary deliverables. (event: 2026-10-27)
- [CoreWeave Denmark: A heat-reuse agreement is not a per-token energy measurement](https://retrivium.ai/retrospectives/retro-denmark-heat-reuse-boundary.md): CoreWeave’s Denmark announcement connects GPU infrastructure with district heating. Why a heat-reuse agreement is a new system boundary rather than a per-token energy result. (event: 2026-10-27)
- [CoreWeave Denmark: A local GPU site and a global backbone solve different placement problems](https://retrivium.ai/retrospectives/retro-denmark-local-global-network.md): CoreWeave announced Danish compute capacity alongside a network backbone. How earlier regional plans lead to two different placement questions: local requests and inter-site movement. (event: 2026-10-27)
- [LFM3: why one backbone produced several modality contracts](https://retrivium.ai/retrospectives/lfm3-shared-backbone-retrospective.md): The LFM3 announcement matters because a shared model backbone does not produce a shared application interface. (event: 2026-10-27)
- [LFM3 announcement versus runtime support: what shipped together](https://retrivium.ai/retrospectives/lfm3-announcement-runtime-boundary.md): LFM3's family announcement and a runtime's support record answer different availability questions, especially when several modality contracts share one backbone. (event: 2026-10-27)
- [Introducing LFM3: checkpoint publication and license identity](https://retrivium.ai/retrospectives/retro-liquid-lfm3-license-artifact.md): LFM3's shared backbone does not replace an artifact-specific license record, because technical lineage and distribution permissions describe different relationships. (event: 2026-10-27)
- [Introducing LFM3: decision outputs versus generated answers](https://retrivium.ai/retrospectives/retro-liquid-lfm3-decision-interface.md): LFM3's decision and conversational variants need different response contracts, even when a shared backbone makes them appear to be interchangeable family members. (event: 2026-10-27)
- [Why the sleep framework makes memory a lifecycle problem](https://retrivium.ai/retrospectives/sleep-framework-memory-lifecycle.md): A retrospective on the sleep framework, persistent adaptation and why useful model memory needs admission, consolidation and deletion rules. (event: 2026-10-27)
- [How forgetting became the real test of continual learning](https://retrivium.ai/retrospectives/sleep-framework-evaluation-forgetting.md): How continual learning reached a harder evaluation question: preserving old capabilities while adding new ones, beyond a fresh-task score. (event: 2026-10-27)
- [Why a learning model needs a version boundary in serving](https://retrivium.ai/retrospectives/sleep-framework-serving-version-boundaries.md): A retrospective on continual learning and inference operations: checkpoint identity, cache isolation and the boundary between learning and serving. (event: 2026-10-27)
- [How retrieval and weight updates reached different memory roles](https://retrivium.ai/retrospectives/sleep-framework-rag-weight-updates.md): How the sleep-framework discussion clarifies different jobs for retrieval, context and persistent model adaptation, with a counterfactual test. (event: 2026-10-27)
- [Terra 6.1 and the economics of repeated visual actions](https://retrivium.ai/retrospectives/terra61-visual-action-economics.md): Terra expanded efficient computer-use options, but completed visual tasks still include observation, browser execution, waiting and recovery costs. (event: 2026-10-26)
- [What the Terra factuality claim leaves for application tests](https://retrivium.ai/retrospectives/terra61-factuality-evaluation-slices.md): Terra factuality claims motivate a trial; review entity identity, values, qualifications and source revisions separately on the application corpus. (event: 2026-10-26)
- [Why better visual reasoning still needs screen-state verification](https://retrivium.ai/retrospectives/terra61-screen-state-verification.md): Terra can interpret a screenshot accurately while a stale screen still causes the wrong action; separate observation quality from state freshness. (event: 2026-10-26)
- [Clearer Terra writing changes the human review interface](https://retrivium.ai/retrospectives/terra61-writing-and-agent-reviews.md): Terra pairs clearer writing with computer use; review reports for retained outcome evidence and uncertainty rather than polish alone. (event: 2026-10-26)
- [SGLang isolation disclosure: when a rejected request still crossed a handoff](https://retrivium.ai/retrospectives/sglang-rejection-handoff-security-history.md): The SGLang isolation disclosure shows why rejecting a request must settle its resource lifecycle, rather than merely produce an error response. (event: 2026-10-26)
- [SGLang isolation disclosure: configured context is not processable capacity](https://retrivium.ai/retrospectives/retro-sglang-isolation-disclosure-admission.md): The SGLang disclosure in historical context: how longer context and distributed serving exposed a gap between configuration, admission and worker handoff. (event: 2026-10-26)
- [SGLang cache lifetime: what a transfer acknowledgment must actually prove](https://retrivium.ai/retrospectives/retro-sglang-isolation-disclosure-lifetime-acks.md): A retrospective on the SGLang isolation update, asynchronous cache ownership and why a control-plane acknowledgment is not automatically proof of safe reuse. (event: 2026-10-26)
- [Kimi K3.1 Pro: product rollout and the still-future weight promise](https://retrivium.ai/retrospectives/kimi31-pro-launch-before-weight-date.md): Kimi K3.1 Pro's rollout and its promised weight publication are separate historical facts at the review cutoff. (event: 2026-10-23)
- [BoltE4B: Gemma lineage inside the Nemotron release family](https://retrivium.ai/retrospectives/bolt-e4b-gemma-lineage-not-moe-scale.md): BoltE4B's release shows why product-family naming cannot substitute for model lineage. (event: 2026-10-23)
- [K3.1 Pro Series is live: thinking-only access and client migration](https://retrivium.ai/retrospectives/retro-kimi31-pro-thinking-only.md): Kimi K3.1Pro's thinking-only access requires a compatible client request, so rejecting an unsupported reasoning-mode option is not evidence that the model cannot perform the task. (event: 2026-10-23)
- [K3.1 Pro Series is live: future weights at the review cutoff](https://retrivium.ai/retrospectives/retro-kimi31-pro-weight-promise.md): Kimi's commitment to publish K3.1Pro weights by November 4 remained a future statement at the November 3 review cutoff, so it cannot be recorded as completed availability. (event: 2026-10-23)
- [K3.1 Pro Series is live: session transitions across model generations](https://retrivium.ai/retrospectives/retro-kimi31-pro-session-boundary.md): Kimi K3.1Pro's session-transition guidance makes migration a state decision, because carrying an old conversation into a new model changes the effective evaluation input. (event: 2026-10-23)
- [NVIDIA Nemotron3.5 Bolt E4B 4GB: memory branding and actual session state](https://retrivium.ai/retrospectives/retro-nemotron35-bolt-e4b-footprint-name.md): NemotronBoltE4B's 4GB branding describes a targeted footprint, not a guarantee that arbitrary context, concurrent sessions and every application component fit inside that total. (event: 2026-10-23)
- [NVIDIA Nemotron3.5 Bolt E4B 4GB: speech-ready output and tool arguments](https://retrivium.ai/retrospectives/retro-nemotron35-bolt-e4b-conversational-mode.md): NemotronBoltE4B's concise conversational role does not make spoken-friendly wording and machine tool arguments interchangeable outputs, even when one specialist produces both in an application. (event: 2026-10-23)
- [NVIDIA Nemotron3.5 Bolt E4B 4GB: base-model lineage and post-trained behavior](https://retrivium.ai/retrospectives/retro-nemotron35-bolt-e4b-gemma-adaptation.md): NemotronBoltE4B's Gemma lineage and Nemotron post-training describe complementary parts of its identity, not a reason to assume identical prompts and behaviour across product families. (event: 2026-10-23)
- [Why a bounded answer needed a different API](https://retrivium.ai/retrospectives/decisions-ga-bounded-answer-contract.md): Decisions GA made bounded outputs an explicit API contract; category design, application mapping and unresolved cases still require separate acceptance checks. (event: 2026-10-22)
- [Typed decisions do not establish the right rejection policy](https://retrivium.ai/retrospectives/decisions-ga-rejection-policy.md): Decisions GA narrows output syntax, while rejection and escalation still need labeled evidence, explicit unresolved cases and a versioned action policy. (event: 2026-10-22)
- [More questions per request change failure coupling](https://retrivium.ai/retrospectives/decisions-ga-batch-question-coupling.md): Decisions GA doubled the question limit; larger batches still need per-question evidence scope, result identity and an observed recovery contract. (event: 2026-10-22)
- [Decisions and GPT-Live separate dialogue from action selection](https://retrivium.ai/retrospectives/decisions-ga-voice-action-separation.md): Decisions GA joined bounded inference with GPT-Live; preserve request identity so a delayed choice cannot silently act on an outdated spoken intention. (event: 2026-10-22)
- [Google Agent Compute Engine: Why the model server and the agent’s computer need different lifecycles](https://retrivium.ai/retrospectives/retro-agent-compute-brain-hands.md): Google’s Agent Compute Engine follows inference routing and confidential-computing milestones. Why model serving and an agent’s working computer need different lifecycles. (event: 2026-10-22)
- [Google Agent Compute Engine: Pausing an agent is a state problem before it is a density claim](https://retrivium.ai/retrospectives/retro-agent-compute-pause-state.md): Google’s Agent Compute Engine announcement follows earlier routing and trust primitives. Why checkpointing an idle agent requires coherent state before it supports efficiency claims. (event: 2026-10-22)
- [Google Agent Compute Engine: Keeping secrets outside a sandbox changes the failure boundary](https://retrivium.ai/retrospectives/retro-agent-compute-egress-secrets.md): Google’s Agent Compute Engine keeps long-lived credentials outside the sandbox. How earlier confidential-computing work leads to a different boundary around authorized actions. (event: 2026-10-22)
- [Google Agent Compute Engine: Internal deployment and external preview are different release states](https://retrivium.ai/retrospectives/retro-agent-compute-internal-preview.md): Google’s Agent Compute Engine announcement describes internal use and a future external preview. How earlier infrastructure milestones explain the difference between those release states. (event: 2026-10-22)
- [How forest AI moved from counting trees to understanding land use](https://retrivium.ai/retrospectives/forest-ai-land-cover-to-land-use.md): How the path to AI forest-type maps exposed the difference between observing tree cover and interpreting the land use behind a green pixel. (event: 2026-10-22)
- [Why forest mapping needed better labels as much as finer pixels](https://retrivium.ai/retrospectives/forest-ai-labels-before-resolution.md): Why AI forest mapping requires trustworthy reference labels alongside high-resolution observations, and how to separate those contributions in evaluation. (event: 2026-10-22)
- [How changing forest maps exposed the need for temporal comparability](https://retrivium.ai/retrospectives/forest-ai-temporal-comparability.md): How AI forest maps reveal a temporal evaluation problem: distinguishing actual landscape change from changes in categories, observations and model versions. (event: 2026-10-22)
- [Duet made attention selection part of the agent product](https://retrivium.ai/retrospectives/duet-proactive-attention-policy.md): Why Claude Duet's proactive preview adds an attention-selection problem, with justified silence and notification tested separately from source access. (event: 2026-10-21)
- [A Duet preview announcement is not broad availability](https://retrivium.ai/retrospectives/duet-preview-access-vs-capability.md): How to read Claude Duet's October research preview without confusing waitlisted access, product capability and later announcement updates. (event: 2026-10-21)
- [Background Duet work needs evidence-bearing completion signals](https://retrivium.ai/retrospectives/duet-background-work-completion-signals.md): Why Duet background notifications need to distinguish discovery, preparation, attempts and supported completion through inspectable outcomes. (event: 2026-10-21)
- [Connected business actions require explicit transaction intent](https://retrivium.ai/retrospectives/duet-actions-vs-financial-intent.md): How Claude Duet's connected-business direction separates reversible preparation, a stable approved proposal and evidence of the eventual operation. (event: 2026-10-21)
- [Why AI cloud trust spans keys, support access, and runtime](https://retrivium.ai/retrospectives/retro-zero-trust-key-authority-runtime.md): CoreWeave’s framework links customer key authority, support approval and runtime verification. Their value depends on the decision path connecting protected data to authorized execution. (event: 2026-10-21)
- [Confidential compute: announced extension versus deployed coverage](https://retrivium.ai/retrospectives/retro-confidential-compute-announced-versus-deployed.md): CoreWeave’s confidential-computing extension has named hardware, intended timing and an initial deployment scope. Those dimensions must remain separate from completed workload coverage. (event: 2026-10-21)
- [How to read a zero-trust framework without turning it into a guarantee](https://retrivium.ai/retrospectives/retro-zero-trust-ai-framework-verification.md): CoreWeave’s framework groups several trust boundaries. Technical mechanisms, operating policies and future extensions need different evidence before supporting a workload-specific conclusion. (event: 2026-10-21)
- [Support access and runtime trust are separate zero-trust layers](https://retrivium.ai/retrospectives/retro-zero-trust-support-runtime-separation.md): Support approval and runtime verification govern different decisions. Maintenance authority, environment evidence and workload continuation should remain separate but connected records. (event: 2026-10-21)
- [From Confidential G4 preview to a documented GA boundary](https://retrivium.ai/retrospectives/retro-confidential-g4-preview-ga.md): Confidential G4 moved from preview to GA with a stated hardware and zone scope. Related Confidential Space integration retained a separate rollout status. (event: 2026-10-21)
- [Why attestation belongs before release of model secrets](https://retrivium.ai/retrospectives/retro-confidential-g4-attestation-release.md): Remote attestation can condition model-secret release on environment evidence. Confidential G4 GA does not remove the need for key policy or application authorization. (event: 2026-10-21)
- [Thirty-six zones are not thirty-six independent cloud regions](https://retrivium.ai/retrospectives/retro-confidential-g4-zones-regions.md): Confidential G4 GA reported 36 zones. Preserving that unit avoids exaggerating regional diversity or implying account-level capacity guarantees. (event: 2026-10-21)
- [Confidential G4 and Confidential Space had different rollout states](https://retrivium.ai/retrospectives/retro-confidential-g4-space-rollout.md): Confidential G4 reached GA while Confidential Space integration had a separate coming-weeks rollout. Component maturity and composition maturity require distinct evidence. (event: 2026-10-21)
- [A live-network AI-RAN call does not mean a nationwide deployment](https://retrivium.ai/retrospectives/retro-airan-pilot-commercial-boundary.md): The AI-RAN update reported a live-network call, field trials and future pilots with different scopes. Those milestones do not establish a nationwide deployment. (event: 2026-10-21)
- [Radio processing and edge inference share hardware but not deadlines](https://retrivium.ai/retrospectives/retro-airan-inference-radio-coexistence.md): AI-RAN combines radio and AI on shared infrastructure, but their timing and isolation needs differ. Apparent spare compute is not automatically an inference-service commitment. (event: 2026-10-21)
- [New ARC configurations complicate the meaning of network edge](https://retrivium.ai/retrospectives/retro-airan-central-edge-placement.md): New ARC configurations include centralized high-capacity sites. Network-edge claims need an actual placement and request path rather than a uniform edge label. (event: 2026-10-21)
- [Why telecom land, power and fiber are only the first AI layer](https://retrivium.ai/retrospectives/retro-airan-operator-assets-stack.md): Telecom assets enable deployment but do not themselves provide model serving. ARC adds compute and software layers whose operational readiness remains site specific. (event: 2026-10-21)
- [Nemotron3.5 retrieval launch: three stages of the evidence pipeline](https://retrivium.ai/retrospectives/nemotron35-three-evidence-stages-release.md): The Nemotron retrieval launch matters because it presents extraction, candidate retrieval and reranking as separate evidence stages. (event: 2026-10-21)
- [Granite Speech5: transcription,TurboCTC and attribution are separate release roles](https://retrivium.ai/retrospectives/granite-speech5-three-contracts.md): Granite Speech5 separates transcription, speech-language generation and attribution, so the October announcement cannot be reduced to a single recognition ranking. (event: 2026-10-21)
- [Humming: why a unified quantization format still needs a device-specific kernel](https://retrivium.ai/retrospectives/humming-format-kernel-contract-release.md): Humming unifies quantization representation, but a common representation does not remove the need for kernels specialized to devices and workloads. (event: 2026-10-21)
- [Nemotron3.5 Embed,Rerank and Parse: page-image evidence in dense retrieval](https://retrivium.ai/retrospectives/retro-nemotron35-retriever-page-images.md): Nemotron's visual dense retrieval can make page-image information searchable, but finding a relevant page is not the same as producing a coordinate-grounded citation for an answer. (event: 2026-10-21)
- [Nemotron3.5 Embed,Rerank and Parse: reranking and missing candidates](https://retrivium.ai/retrospectives/retro-nemotron35-retriever-rerank-contract.md): Nemotron's reranker can reorder the candidates it receives, but it cannot recover a relevant document that the preceding retrieval stage never supplied. (event: 2026-10-21)
- [Nemotron3.5 Embed,Rerank and Parse: document parsing before embeddings](https://retrivium.ai/retrospectives/retro-nemotron35-retriever-parser-boundary.md): Releasing a parser beside Nemotron's retrieval models makes ingestion a separate evidence boundary, because correct search cannot recover document relationships already lost before indexing. (event: 2026-10-21)
- [Granite Speech5.0: CTC decoding and speech-language generation](https://retrivium.ai/retrospectives/retro-ibm-speech5-ctc-versus-slm.md): Granite Speech5.0 contains different speech inference paths. Trace why CTC transcription and speech-language generation need distinct acceptance criteria. (event: 2026-10-21)
- [Granite Speech5.0: speaker attribution beyond word accuracy](https://retrivium.ai/retrospectives/retro-ibm-speech5-attribution.md): Granite Speech attribution addresses who spoke and when. Reconstruct why accurate words alone became insufficient for meeting and call applications. (event: 2026-10-21)
- [Granite Speech5.0: keyword biasing and unsupported terms](https://retrivium.ai/retrospectives/retro-ibm-speech5-keyword-bias.md): Granite Speech keyword biasing helps domain vocabulary, but prompts are not acoustic evidence. Trace the distinction and a practical acceptance approach. (event: 2026-10-21)
- [vLLM Humming: why shared quantization still needs specialized kernels](https://retrivium.ai/retrospectives/retro-vllm-humming-representation-jit.md): A retrospective on Humming, quantization integration and the boundary between a common tensor representation and execution tuned to a particular GPU workload. (event: 2026-10-21)
- [vLLM Humming benchmarks: from a fast kernel to a complete request](https://retrivium.ai/retrospectives/retro-vllm-humming-kernel-benchmark.md): How to read Humming performance results retrospectively: isolate kernel work, request scheduling and the conditions needed for a useful end-to-end comparison. (event: 2026-10-21)
- [Why llm-d 1.0 was an operations milestone as well as a serving release](https://retrivium.ai/retrospectives/retro-llmd-day-two-milestone.md): llm-d 1.0 emphasized stable configuration, coordinated upgrades and traffic policy. Those features make ongoing operations a distinct part of distributed inference. (event: 2026-10-20)
- [Cache locality and tenant fairness can pull a router in different directions](https://retrivium.ai/retrospectives/retro-llmd-cache-fairness.md): llm-d 1.0 combined cache-aware serving with priority and fairness controls. Reuse efficiency and allocation policy solve connected but different problems. (event: 2026-10-20)
- [Why prefill and decode upgrades need a shared lifecycle](https://retrivium.ai/retrospectives/retro-llmd-coordinated-upgrades.md): Disaggregated prefill and decode can scale separately while retaining shared compatibility requirements. llm-d 1.0 made coordinated upgrades an explicit lifecycle concern. (event: 2026-10-20)
- [TorchTPU changes the unit of TPU model porting](https://retrivium.ai/retrospectives/retro-torchtpu-porting-unit.md): TorchTPU offers native PyTorch execution on TPUs. It can reduce model-definition rewrites while moving qualification toward backend behavior and supported execution paths. (event: 2026-10-20)
- [Eager debugging and compiled serving answer different TPU questions](https://retrivium.ai/retrospectives/retro-torchtpu-eager-compile.md): TorchTPU exposes eager and compiled execution paths. Correct eager output does not establish warm compiled latency, preparation cost or coverage of every input shape. (event: 2026-10-20)
- [Why an out-of-tree TPU plugin can preserve the vLLM control plane](https://retrivium.ai/retrospectives/retro-torchtpu-vllm-plugin.md): The TorchTPU vLLM plugin separates shared serving logic from TPU-specific execution. A common interface does not establish parity for every backend feature. (event: 2026-10-20)
- [Open-source TPU support makes compatibility inspectable, not automatic](https://retrivium.ai/retrospectives/retro-torchtpu-open-source-validation.md): Open-sourcing TorchTPU makes native TPU implementation and integration boundaries inspectable. Exact model and serving combinations still need their own compatibility evidence. (event: 2026-10-20)
- [Voxtral3: a family release, not one monolithic speech model](https://retrivium.ai/retrospectives/voxtral3-four-stage-voice-release.md): The Voxtral3 launch should be read as a family and pipeline release rather than one universal speech model. (event: 2026-10-20)
- [DeepInfer release: why an open inference engine is not a complete service](https://retrivium.ai/retrospectives/deepinfer-public-engine-not-service.md): DeepInfer published an inference implementation, but the public code did not turn an offline model runner into a complete hosted service. (event: 2026-10-20)
- [vLLM TorchTPU: model-code reuse is not kernel portability](https://retrivium.ai/retrospectives/torchtpu-model-code-versus-kernel-portability.md): vLLM TorchTPU reuses model-serving code while keeping platform-specific execution explicit, so source reuse cannot be treated as automatic kernel portability. (event: 2026-10-20)
- [Voxtral 3: separate speech stages in a voice agent](https://retrivium.ai/retrospectives/retro-mistral-voxtral3-voice-stages.md): Voxtral3's voice-agent framing combines separate speech stages, so a successful conversation cannot be attributed to one model without identifying the chain that produced it. (event: 2026-10-20)
- [Voxtral 3: interruptions and end-of-turn decisions](https://retrivium.ai/retrospectives/retro-mistral-voxtral3-interruption.md): Voxtral3's conversational framing makes interruptions and turn boundaries evaluation targets, because transcription accuracy alone cannot explain when a voice agent should act or stop speaking. (event: 2026-10-20)
- [Voxtral 3: self-deployment and public weight availability](https://retrivium.ai/retrospectives/retro-mistral-voxtral3-private-deployment.md): Voxtral3's self-deployment offering and publicly downloadable weights are different access contracts, so one should not be used as evidence that every family component has the other. (event: 2026-10-20)
- [DeepInfer initial public commit: offline inference and service completeness](https://retrivium.ai/retrospectives/retro-deepinfer-public-offline-boundary.md): DeepInfer published offline inference building blocks. Trace why an open engine and a complete multi-user service remain different engineering deliverables. (event: 2026-10-20)
- [DeepInfer initial public commit: initial commit versus repository creation](https://retrivium.ai/retrospectives/retro-deepinfer-public-commit-date.md): DeepInfer’s public commit anchors code availability more precisely than repository creation. Reconstruct why different project timestamps answer different questions. (event: 2026-10-20)
- [vLLM TorchTPU startup: compilation is a different phase from serving](https://retrivium.ai/retrospectives/retro-vllm-torchtpu-compilation.md): A retrospective on TorchTPU model reuse, graph compilation and why a serving comparison must distinguish first startup, restarts and warmed requests. (event: 2026-10-20)
- [vLLM TorchTPU compatibility: a common API still needs a feature matrix](https://retrivium.ai/retrospectives/retro-vllm-torchtpu-feature-matrix.md): How TorchTPU reached a common vLLM interface, and why model families, precision choices and validated deployment combinations need separate evidence. (event: 2026-10-20)
- [The Indiana SMR announcement was a feasibility gate, not delivered power](https://retrivium.ai/retrospectives/retro-indiana-smr-feasibility-gate.md): The Indiana SMR agreement explores a site-specific project. Its reactor and power targets describe feasibility scope rather than delivered electricity or completed investment approval. (event: 2026-10-19)
- [Why a second SMR site tests a deployment model as well as a reactor](https://retrivium.ai/retrospectives/retro-indiana-smr-repeat-site.md): Indiana extends the X-energy deployment program to another site and utility. Repeated proposals test transferability without proving realized learning-curve cost savings. (event: 2026-10-19)
- [Amazon Indiana: A former coal site offers infrastructure context, not automatic nuclear approval](https://retrivium.ai/retrospectives/retro-indiana-coal-site-reuse.md): Amazon’s Indiana nuclear announcement followed reactor financing and another site plan. A retrospective on what former coal infrastructure can and cannot establish. (event: 2026-10-19)
- [Amazon Indiana: Development funding and electricity offtake play different roles](https://retrivium.ai/retrospectives/retro-indiana-offtake-development.md): How Amazon’s earlier reactor investment led to an Indiana agreement combining development support with prospective electricity purchasing, with different obligations at each stage. (event: 2026-10-19)
- [MiniMax M3.1Flash: what the SpaceBunny reveal established and what remained pending](https://retrivium.ai/retrospectives/minimax-m31-spacebunny-to-named-release.md): MiniMax M3.1Flash turned the SpaceBunny preview into a named API release, while the announcement still treated downloadable weights as a later step. (event: 2026-10-19)
- [MiniMax M3.1Flash: anonymous preview and named-model evidence](https://retrivium.ai/retrospectives/retro-minimax-m31-api-stealth-evidence.md): MiniMax identified SpaceBunny as an early M3.1Flash version. Trace what anonymous preview feedback establishes and what still needs controlled evaluation. (event: 2026-10-19)
- [MiniMax M3.1Flash: API launch before checkpoint terms](https://retrivium.ai/retrospectives/retro-minimax-m31-api-checkpoint-release.md): The M3.1Flash launch separated API availability from a later weight release. Reconstruct why interface access and self-hosting artifacts have different dates. (event: 2026-10-19)
- [Timestral: why covariates are not chat context](https://retrivium.ai/retrospectives/timestral-covariates-not-chat-context.md): Timestral's release matters because forecasting has a different evidence contract from language generation, even when both are called foundation models. (event: 2026-10-15)
- [Nemotron SuperVL: the October expansion from text execution to visual agents](https://retrivium.ai/retrospectives/super-vl-october-agent-modality-expansion.md): SuperVL expands an agent-model family into visual execution without making its members interchangeable. (event: 2026-10-15)
- [Introducing Timestral: known-future inputs and leakage](https://retrivium.ai/retrospectives/retro-mistral-timestral-future-covariates.md): Timestral's known-future covariates are inputs available at forecast time, not permission to include future outcomes that the forecasting system would not yet know. (event: 2026-10-15)
- [Introducing Timestral: probabilistic forecasts and point answers](https://retrivium.ai/retrospectives/retro-mistral-timestral-uncertainty.md): Timestral's probabilistic forecasts should be evaluated as uncertainty-bearing predictions, not reduced to fluent answers or a single point that discards the release's task contract. (event: 2026-10-15)
- [Introducing Timestral: chronological holdouts after the release](https://retrivium.ai/retrospectives/retro-mistral-timestral-forecast-splits.md): A chronological holdout for Timestral must preserve the information available at each forecast origin, because zero-shot use does not automatically make a retrospective evaluation leakage-free. (event: 2026-10-15)
- [Nemotron 3.5 SuperVL: visual documents versus video tasks](https://retrivium.ai/retrospectives/retro-nemotron35-super-vl-visual-evidence.md): NemotronSuperVL's multimodal release needs separate document and video fixtures, because identifying a still page is different from understanding an event across time. (event: 2026-10-15)
- [Nemotron 3.5 SuperVL: execution and orchestration roles](https://retrivium.ai/retrospectives/retro-nemotron35-super-vl-role-complement.md): NemotronSuperVL and the announced Bolt roles should be evaluated as different workflow choices, rather than treating a new visual model as a universal replacement for orchestration. (event: 2026-10-15)
- [Nemotron 3.5 SuperVL: customization and retained acceptance tests](https://retrivium.ai/retrospectives/retro-nemotron35-super-vl-posttraining.md): Customizing NemotronSuperVL creates a new behavioural artifact, so access to an adaptable model does not remove the need to retain acceptance tests for the behaviour that must survive. (event: 2026-10-15)
- [Grok Voice 3.0: Support-call resolution is different from fluent speech](https://retrivium.ai/retrospectives/grok-voice3-support-resolution.md): Grok Voice 3.0 emphasizes support-call outcomes. This retrospective separates successful resolution, tool-state correctness and caller satisfaction with the speech. (event: 2026-10-14)
- [Grok Voice 3.0: Low audio latency does not guarantee good turn-taking](https://retrivium.ai/retrospectives/grok-voice3-latency-vs-turn-taking.md): Why Grok Voice 3.0’s responsiveness discussion needs separate tests for first audio, complete caller intent, interruptions and recovery of the conversation. (event: 2026-10-14)
- [Grok Voice 3.0: A voice-model upgrade needs an audio regression artifact](https://retrivium.ai/retrospectives/grok-voice3-upgrade-audio-regression.md): Why a Grok Voice 3.0 migration needs a repeatable conversational fixture preserving audio, task state and tool outcomes, not only a text prompt comparison. (event: 2026-10-14)
- [Private endpoint visibility is a different boundary from retention](https://retrivium.ai/retrospectives/retro-openrouter-private-visibility-retention.md): Private Endpoints changes deployment visibility and routing exposure. It does not automatically change upstream retention; even setup tests remain real processing requests. (event: 2026-10-14)
- [Reserved inference capacity and optional public overflow](https://retrivium.ai/retrospectives/retro-openrouter-reserved-fallback.md): Private Endpoints can prioritize reserved capacity with optional constrained public overflow. The caller still chooses whether a different execution path and deployment behavior are acceptable. (event: 2026-10-14)
- [Why Private Endpoints did not become arbitrary self-hosted model ingestion](https://retrivium.ai/retrospectives/retro-openrouter-private-catalog-boundary.md): Private Endpoints reuses a catalog model’s identity through a supported BYOK provider and workspace key. Those dependencies define an Enterprise deployment feature, not arbitrary supplier admission. (event: 2026-10-14)
- [How AI writing created the verification bottleneck behind Deep Review](https://retrivium.ai/retrospectives/deep-review-verification-bottleneck.md): How the progression from Paper Assistant Tool pilots to Deep Review reflects a bottleneck in checking technical claims as AI-assisted writing grows. (event: 2026-10-14)
- [Why the claim became the right unit for document review](https://retrivium.ai/retrospectives/deep-review-claim-evidence-unit.md): Why technical-document review benefits from treating a claim and its supporting evidence as an inspectable unit, in the history leading to Deep Review. (event: 2026-10-14)
- [How author feedback and institutional peer review diverged](https://retrivium.ai/retrospectives/deep-review-author-feedback-institutions.md): How optional author-feedback pilots before Deep Review clarify the different roles of manuscript assistance, independent review and institutional decisions. (event: 2026-10-14)
- [Why technical review became an asynchronous AI workload](https://retrivium.ai/retrospectives/deep-review-asynchronous-compute.md): Why a system such as Deep Review is best understood as a long-running verification job, with different infrastructure needs from conversational chat. (event: 2026-10-14)
- [How Earth AI showed why a language model needs specialized spatial tools](https://retrivium.ai/retrospectives/earth-ai-specialized-tools.md): How the Earth AI geospatial-agent announcement follows a path from reusable spatial representations toward specialized tools coordinated by a language model. (event: 2026-10-14)
- [Why planetary data belongs in a workspace beyond the context window](https://retrivium.ai/retrospectives/earth-ai-workspace-context-window.md): Why Earth AI’s geospatial-agent architecture makes a separate data workspace important when the underlying evidence is larger than a useful prompt. (event: 2026-10-14)
- [How upfront planning became a measurable part of geospatial agents](https://retrivium.ai/retrospectives/earth-ai-planning-before-execution.md): How Earth AI’s geospatial-agent evaluation makes upfront planning a testable design choice, while separating planning quality from extra computation. (event: 2026-10-14)
- [Why geospatial agents still need a boundary for expert review](https://retrivium.ai/retrospectives/earth-ai-expert-review-boundary.md): Why experimental geospatial agents such as Earth AI need an inspectable boundary between a useful first draft and an expert-validated spatial conclusion. (event: 2026-10-14)
- [Argon GA made the continuation protocol an integration decision](https://retrivium.ai/retrospectives/argon-ga-unified-budget-continuation.md): How Argon GA turns long decoding into a client continuation contract with unified-budget interpretation and explicit output assembly checks. (event: 2026-10-13)
- [Broad access still needs a platform-by-plan matrix](https://retrivium.ai/retrospectives/argon-ga-platform-availability-matrix.md): How Argon's broad release still requires a platform-and-plan access matrix that keeps app demonstrations separate from API acceptance. (event: 2026-10-13)
- [Argon's introductory pricing created a temporary planning condition](https://retrivium.ai/retrospectives/argon-ga-introductory-economics.md): How Argon's introductory price creates a temporary planning condition that should be separated from task mix and steady-state usage scenarios. (event: 2026-10-13)
- [Public engineering artifacts make launch claims more inspectable](https://retrivium.ai/retrospectives/argon-ga-public-artifacts-evidence.md): How public Argon engineering artifacts improve causal inspection while keeping framework benchmarks separate from unmeasured downstream performance. (event: 2026-10-13)
- [LFM2.5-24B-A2B: the final LFM2.5 release and its changed reasoning contract](https://retrivium.ai/retrospectives/lfm25-24b-final-family-release.md): The final LFM2.5 release should be read as a change in the reasoning and adaptation contract, rather than as a promise that sparse activation makes the whole checkpoint small. (event: 2026-10-13)
- [LFM2.5-24B-A2B: reasoning-only responses and structured clients](https://retrivium.ai/retrospectives/retro-liquid-24b-reasoning-parser.md): LFM2.5-24B-A2B's reasoning-only contract changes what a structured client must recognize as completion, independently of any model-quality comparison. (event: 2026-10-13)
- [LFM2.5-24B-A2B: active experts and weight residency](https://retrivium.ai/retrospectives/retro-liquid-24b-resident-experts.md): LFM2.5-24B-A2B's sparse computation does not make its full weight inventory disappear, so active experts and resident artifacts need separate accounting. (event: 2026-10-13)
- [LFM2.5-24B-A2B: tokenizer expansion and migration fixtures](https://retrivium.ai/retrospectives/retro-liquid-24b-tokenizer-contract.md): LFM2.5-24B-A2B's tokenizer change makes input identity part of migration, because preserving text does not necessarily preserve token sequences or budgets. (event: 2026-10-13)
- [Active Focus still needs a stopping rule](https://retrivium.ai/retrospectives/wonder-active-focus-stopping-rule.md): Why Muse Wonder's Active Focus needs progress evidence and stopping rules that distinguish recoverable errors from genuine blockers. (event: 2026-10-12)
- [Active Memory raises the question of evidence freshness](https://retrivium.ai/retrospectives/wonder-active-memory-evidence-freshness.md): Why Muse Wonder's Active Memory needs freshness evaluation as well as relevant recall when agents revisit changing projects and records. (event: 2026-10-12)
- [Wonder and Wonder Full launched through different access paths](https://retrivium.ai/retrospectives/wonder-full-access-matrix.md): How Muse Wonder and Wonder Full's initial access routes require a variant-by-surface matrix rather than one family-wide availability claim. (event: 2026-10-12)
- [Helion and the separation of agent execution from model inference](https://retrivium.ai/retrospectives/retro-helion-cpu-agents-inference-split.md): Helion’s CPU-only option exposes a separate agent execution tier. The useful sizing unit includes tool work, model calls and the dependencies between them. (event: 2026-10-12)
- [Why Helion includes an enterprise CPU/GPU configuration](https://retrivium.ai/retrospectives/retro-helion-enterprise-mi350p-rack.md): Helion’s EPYC and MI350P option gives enterprises a system boundary to evaluate. Integration value depends on real application handoffs, not accelerator count alone. (event: 2026-10-12)
- [Helion: open specification, partner design, and availability are separate milestones](https://retrivium.ai/retrospectives/retro-helion-open-rack-availability.md): Helion’s open blueprint, partner implementation and planned availability are distinct milestones. A specification improves coordination without proving delivery or site acceptance. (event: 2026-10-12)
- [A CPU-only agent rack changes what an AI capacity count means](https://retrivium.ai/retrospectives/retro-helion-cpu-rack-accounting.md): A CPU-only Helion rack highlights three different ledgers: installed hardware, ready service capacity and completed application work. Their units cannot simply be added. (event: 2026-10-12)
- [Haiku 5.5 subagents need smaller contracts, not vague delegation](https://retrivium.ai/retrospectives/haiku55-subagent-contract-size.md): Why Haiku 5.5 subagents need bounded questions and checkable return artifacts before lower call costs can become useful task-level efficiency. (event: 2026-10-07)
- [Cheap summaries still spend an omission budget](https://retrivium.ai/retrospectives/haiku55-summary-omission-budget.md): How to evaluate Haiku 5.5 summaries for task-relevant exceptions and exact identifiers instead of treating short output as sufficient quality. (event: 2026-10-07)
- [Haiku 5.5 browser use makes action composition visible](https://retrivium.ai/retrospectives/haiku55-browser-action-composition.md): Why Haiku 5.5 browser evaluation must check target identity and changing page state across an action sequence, not just plausible clicks. (event: 2026-10-07)
- [High-volume Haiku traffic needs failure slices, not one average](https://retrivium.ai/retrospectives/haiku55-volume-evaluation-slices.md): Why high-volume Haiku 5.5 evaluation needs failure slices, consequence-aware routing and explicit uncertainty beyond a pooled average. (event: 2026-10-07)
- [A 240-MW India plan is not current GPU availability](https://retrivium.ai/retrospectives/retro-india-power-plan-not-gpu-availability.md): CoreWeave’s India campus is a phased future deployment. Its planned power describes infrastructure scale, while an application still needs a matching date and allocated execution path. (event: 2026-10-07)
- [Indonesia before India: the sequencing of CoreWeave’s Asia expansion](https://retrivium.ai/retrospectives/retro-coreweave-asia-region-sequencing.md): CoreWeave announced Indonesia before India, with separate 2028 delivery descriptions. A common cloud roadmap links the projects without making their commissioning paths identical. (event: 2026-10-07)
- [Why a future India campus was announced around Rubin-class infrastructure](https://retrivium.ai/retrospectives/retro-india-rubin-facility-planning.md): CoreWeave’s India plan names cooling mechanisms and future-generation intent. Adaptability becomes meaningful through specified building-to-rack interfaces and later qualification. (event: 2026-10-07)
- [Three planned buildings do not establish one India delivery date](https://retrivium.ai/retrospectives/retro-india-power-phase-timeline.md): CoreWeave specifies three buildings and phased India delivery. Building count does not establish the number of commissioning phases or one date for the whole campus. (event: 2026-10-07)
- [Open d1: why a decision model is a different interface from a chat model](https://retrivium.ai/retrospectives/open-d1-not-generative-chat.md): Open d1 changes the shape of the application interface: a decision model can return a bounded answer without composing a conversational response. (event: 2026-10-07)
- [Open d1: decision probabilities and application policy](https://retrivium.ai/retrospectives/retro-liquid-d1-weights-probability-policy.md): Open d1 exposes a decision interface, but the application's action threshold remains a separate policy choice with consequences that model publication cannot determine. (event: 2026-10-07)
- [Open d1: encoder and decoder decision backbones](https://retrivium.ai/retrospectives/retro-liquid-d1-weights-encoder-decoder.md): Open d1's encoder and decoder variants solve a related decision problem through different input contracts, so parameter count alone cannot select between them. (event: 2026-10-07)
- [Open d1: portable weights and browser execution](https://retrivium.ai/retrospectives/retro-liquid-d1-weights-browser-portability.md): Open d1's downloadable weights make browser experiments possible to investigate, but weight availability alone does not establish a complete browser execution path. (event: 2026-10-07)
- [How better AI-assisted work became a different question from better skills](https://retrivium.ai/retrospectives/ai-work-quality-vs-skill.md): How the AI-assisted work debate reached a separate question about independent skill, in the context of Google’s October study of professional learning. (event: 2026-10-07)
- [Why seniority changes the learning question around AI assistance](https://retrivium.ai/retrospectives/ai-work-seniority-learning.md): Why professional experience changes the learning question around AI assistance, in the history leading to Google’s October work-quality study. (event: 2026-10-07)
- [How unaided transfer tests became essential for evaluating AI tools](https://retrivium.ai/retrospectives/ai-work-transfer-testing.md): How independent transfer tasks became necessary for evaluating AI-assisted learning, separating a useful tool from a durable change in human competence. (event: 2026-10-07)
- [An uprate adds output without being a new reactor](https://retrivium.ai/retrospectives/retro-nuclear-uprate-new-reactor.md): The Constellation agreement targets uprates at operating nuclear plants. New reactors, dormant-plant restarts and uprates begin from different physical baselines. (event: 2026-10-06)
- [An AI power purchase agreement spans a longer clock than a GPU refresh](https://retrivium.ai/retrospectives/retro-nuclear-ppa-time-horizon.md): Long-term nuclear procurement and GPU deployment run on different schedules. The uprate agreement supports future supply rather than a named accelerator delivery date. (event: 2026-10-06)
- [Preserving nuclear output and adding nuclear output are different quantities](https://retrivium.ai/retrospectives/retro-nuclear-capacity-additionality.md): Nuclear agreements change different baselines: new construction, restored operation, uprates and preserved output. Capacity accounting must name the baseline before summing. (event: 2026-10-06)
- [Grid-scale nuclear supply does not describe a datacenter’s instantaneous mix](https://retrivium.ai/retrospectives/retro-nuclear-grid-datacenter-boundary.md): Nuclear procurement supports supply development. It does not establish a datacenter's instantaneous electricity mix or a service's measured inference energy footprint. (event: 2026-10-06)
- [Mistral Large4 preview: what was public on October6](https://retrivium.ai/retrospectives/mistral-large4-preview-versus-release.md): Mistral's Large4 preview created an evaluation surface before it created a downloadable deployment artifact. (event: 2026-10-06)
- [Introducing Mistral Large 4: preview access and defensive evaluation](https://retrivium.ai/retrospectives/retro-mistral-large4-preview-preview-cyber.md): Mistral Large4's preview provides a real evaluation surface, but a successful preview test does not certify a later checkpoint that undergoes additional post-training. (event: 2026-10-06)
- [Introducing Mistral Large 4: API access before deployment control](https://retrivium.ai/retrospectives/retro-mistral-large4-preview-preview-portability.md): Mistral Large4's API preview enabled task evaluation before it enabled control over a self-hosted checkpoint, so those adoption decisions must remain distinct. (event: 2026-10-06)
- [Introducing Mistral Large 4: benchmark claims before reproducible artifacts](https://retrivium.ai/retrospectives/retro-mistral-large4-preview-preview-evals.md): A benchmark claim attached to the Mistral Large4 preview and an independently reproduced result are different evidence types, even when they concern the same task name. (event: 2026-10-06)
- [How reporting delays made location embeddings useful for health research](https://retrivium.ai/retrospectives/earth-ai-health-reporting-lag.md): How reporting delays create a role for location embeddings in Earth AI health research, and why prediction-time evidence must be evaluated carefully. (event: 2026-10-06)
- [Why cross-border health modelling needs geographic transfer tests](https://retrivium.ai/retrospectives/earth-ai-health-geographic-transfer.md): Why Earth AI public-health research makes geographic transfer a separate evaluation problem, even when a model uses reusable location representations. (event: 2026-10-06)
- [How place embeddings sharpened the distinction between prediction and cause](https://retrivium.ai/retrospectives/earth-ai-health-proxy-causality.md): How Earth AI place representations make the distinction between useful prediction and a causal explanation especially important in public-health research. (event: 2026-10-06)
- [d1 vision launch: hosted decisions before open weights](https://retrivium.ai/retrospectives/d1-hosted-vision-before-open-weights.md): The hosted d1 vision announcement made policy questions over text and images an application interface before the later open-weight release. (event: 2026-10-05)
- [Introducing d1: versioning a hosted decision question](https://retrivium.ai/retrospectives/retro-liquid-d1-vision-policy-version.md): The hosted d1 launch made the decision question part of an application's behaviour, so editing that question can constitute a release without changing the model name. (event: 2026-10-05)
- [Introducing d1: visual conditions versus text-only labels](https://retrivium.ai/retrospectives/retro-liquid-d1-vision-image-condition.md): The d1 vision launch changed the evidence available to a decision, so a text-only fixture cannot establish that an image-dependent condition is being evaluated correctly. (event: 2026-10-05)
- [Introducing d1: uncertain decisions before the open-weight drop](https://retrivium.ai/retrospectives/retro-liquid-d1-vision-abstention-contract.md): The hosted d1 announcement made bounded decisions accessible before the weight publication, but it did not remove the application's responsibility for uncertain or unanswerable cases. (event: 2026-10-05)
- [How agent privacy moved from secret storage to appropriate information flow](https://retrivium.ai/retrospectives/agent-privacy-information-flow.md): How the contextual-agent privacy report reflects a shift from protecting stored secrets toward controlling which information flows are appropriate for a task. (event: 2026-10-05)
- [Why delegated agent work needs delegated authority limits](https://retrivium.ai/retrospectives/agent-privacy-delegation-authority.md): Why the progression from tool use to delegated agents makes authority boundaries part of the task contract, in the context of the October privacy report. (event: 2026-10-05)
- [How confirmation fatigue became a design problem for AI agents](https://retrivium.ai/retrospectives/agent-privacy-confirmation-fatigue.md): How agent autonomy made confirmation fatigue a privacy and interaction problem, and why useful approval boundaries need more than frequent prompts. (event: 2026-10-05)
- [Why agent observability needs its own privacy boundary](https://retrivium.ai/retrospectives/agent-privacy-security-observability.md): Why the contextual-agent privacy discussion creates a second boundary around observability: tracing actions without unnecessarily retaining private payloads. (event: 2026-10-05)
- [A smaller Spark configuration changes capacity choice before compute identity](https://retrivium.ai/retrospectives/retro-spark-64-capacity-choice.md): The 64 GB DGX Spark option changes the memory tier within the GB10 platform. Workload state and partner delivery status remain part of the configuration decision. (event: 2026-10-02)
- [Two Spark systems add distributed capacity, not one local memory bus](https://retrivium.ai/retrospectives/retro-spark-cluster-memory-locality.md): Sync Cluster Assistant can simplify multi-Spark setup. Connected systems still have distributed placement and communication boundaries rather than one local memory bus. (event: 2026-10-02)
- [Why the Spark post date and partner shipping date differ](https://retrivium.ai/retrospectives/retro-spark-announced-shipping-date.md): The Spark configuration post and its planned partner availability date describe different milestones. Announcement, shipment and workload acceptance need separate evidence. (event: 2026-10-02)
- [Local inference capacity does not make an entire agent workflow offline](https://retrivium.ai/retrospectives/retro-spark-local-agent-scope.md): Local Spark inference changes where the model executes. Agent tools, artifact downloads, stored history and external services retain their own location boundaries. (event: 2026-10-02)
- [How federated learning reached the demand for verifiable trust](https://retrivium.ai/retrospectives/federated-learning-verifiable-trust.md): How the history of secure aggregation and federated learning leads to Google’s October proposal for externally verifiable privacy guarantees. (event: 2026-10-02)
- [Why moving computation does not settle the privacy question](https://retrivium.ai/retrospectives/federated-learning-compute-placement.md): Why Google’s October federated-learning proposal makes compute placement and privacy guarantees separate architectural questions, beyond local-versus-cloud labels. (event: 2026-10-02)
- [How device participation became part of learning quality](https://retrivium.ai/retrospectives/federated-learning-device-participation.md): How federated learning’s device constraints made participation part of model quality, and why the October system announcement renews that evaluation question. (event: 2026-10-02)
- [Why privacy guarantees must survive the whole training workflow](https://retrivium.ai/retrospectives/federated-learning-guarantee-composition.md): Why the history of private federated learning leads to workflow-level guarantees, including repeated releases, verification state and operational changes. (event: 2026-10-02)
- [Argon had an announcement clock and an access clock](https://retrivium.ai/retrospectives/argon-preview-phased-release-clock.md): Why Gemini 4 Argon's September announcement must retain its restricted initial-access condition instead of backdating broader availability. (event: 2026-09-30)
- [Long output capacity does not define a completed project](https://retrivium.ai/retrospectives/argon-preview-long-output-completion.md): Why Argon's expanded output headroom still needs independent completion rules, semantic continuity and acceptance evidence for the delivered project. (event: 2026-09-30)
- [Code migration claims need semantic equivalence evidence](https://retrivium.ai/retrospectives/argon-preview-code-migration-evidence.md): Why Argon's code-migration examples need behavioral contracts and bounded equivalence evidence beyond rewrite size or performance anecdotes. (event: 2026-09-30)
- [Internal agent examples do not establish external reproducibility](https://retrivium.ai/retrospectives/argon-preview-agent-work-internal-external.md): How Argon's internal-agent examples can become portability hypotheses without assuming that external teams share the same inputs, tools and review. (event: 2026-09-30)
- [Micron: A 512 GB RDIMM sample is a server-qualification milestone](https://retrivium.ai/retrospectives/retro-micron-rdimm-sampling-capacity.md): Micron’s September 512 GB RDIMM samples followed earlier memory production and lower-capacity samples. What that sequence means for server qualification. (event: 2026-09-30)
- [Micron: Shipping an SSD for KV cache does not make storage behave like HBM](https://retrivium.ai/retrospectives/retro-micron-ssd-kv-cache-role.md): Micron’s KV-cache SSD shipment update followed Gen6 storage production. Why the useful inference role is managed state reuse rather than replacing HBM by capacity. (event: 2026-09-30)
- [Micron: Memory supply needs a ledger of samples, qualification and shipments](https://retrivium.ai/retrospectives/retro-micron-memory-product-stage-ledger.md): A retrospective through Micron’s March, June and September updates shows why AI memory samples, production and application shipments need separate product-level records. (event: 2026-09-30)
- [Micron: A growing AI memory business does not identify an application’s bottleneck](https://retrivium.ai/retrospectives/retro-micron-portfolio-inference-bottleneck.md): Micron’s AI memory growth followed concrete product milestones. Why that market signal explains industry investment but cannot diagnose an inference application’s bottleneck. (event: 2026-09-30)
- [CoreWeave Forge: Why a GPU cloud added the improvement loop above raw capacity](https://retrivium.ai/retrospectives/retro-forge-gpu-cloud-loop.md): CoreWeave Forge followed accelerator plans and agent sandboxes. How the path from running workloads to improving them made workflow continuity an infrastructure concern. (event: 2026-09-30)
- [CoreWeave Forge: Production observations are not automatically training data](https://retrivium.ai/retrospectives/retro-forge-observation-training-data.md): CoreWeave Forge connects observation with model improvement. Why earlier execution tools make curation possible without turning every recorded interaction into training data. (event: 2026-09-30)
- [CoreWeave Forge: A connected evaluation loop still needs a release decision](https://retrivium.ai/retrospectives/retro-forge-evaluation-release-gate.md): CoreWeave Forge followed sandboxes and compute plans. Why a connected evaluation workflow can shorten handoffs while leaving the release decision product-specific. (event: 2026-09-30)
- [CoreWeave Forge: Portable improvement data and portable execution are different promises](https://retrivium.ai/retrospectives/retro-forge-portability-interfaces.md): CoreWeave Forge emphasizes portable data and open interfaces. How earlier execution and compute layers explain the difference between moving an improvement dataset and moving a workload. (event: 2026-09-30)
- [How SynthID Bio moved provenance beyond a digital file](https://retrivium.ai/retrospectives/synthid-bio-provenance-boundary.md): How SynthID Bio connects the earlier history of generated-media provenance with a harder boundary: identifying the origin of scientific artifacts. (event: 2026-09-30)
- [Why generated science made database provenance urgent](https://retrivium.ai/retrospectives/synthid-bio-scientific-data-integrity.md): Why SynthID Bio reflects a wider scientific data problem: distinguishing generated artifacts from observations before their records are reused. (event: 2026-09-30)
- [How watermarking became one layer of scientific trust](https://retrivium.ai/retrospectives/synthid-bio-layered-trust.md): A retrospective on SynthID Bio and layered scientific trust: why identifying origin, validating a result and authorizing a use remain separate tasks. (event: 2026-09-30)
- [What a one-week model replacement means for evaluation cadence](https://retrivium.ai/retrospectives/sol61-weekly-migration-cadence.md): Sol changed within a week of its launch; preserve model, fixture and tool configuration so rapid release cadence does not create mixed evaluation reports. (event: 2026-09-29)
- [Why the Sol 6.1 cache discount is not a task-cost estimate](https://retrivium.ai/retrospectives/sol61-cache-price-vs-total-task-cost.md): The Sol upgrade cut a cache-read rate, but completed-task costs also depend on cache eligibility, output, retries and accepted work. (event: 2026-09-29)
- [Sol 6.1 and the new middle tier for repository work](https://retrivium.ai/retrospectives/sol61-coding-middle-tier.md): Sol moved the middle tier for repository work; judge dependency relationships, optional paths and accepted patches rather than isolated code generation. (event: 2026-09-29)
- [Sol 6.1 multi-agent beta: delegation is another execution contract](https://retrivium.ai/retrospectives/sol61-multiagent-boundary.md): Sol introduced a multi-agent beta, but useful delegation still depends on dependency ordering, bounded worker results and an explicit merge condition. (event: 2026-09-29)
- [From API tools to a browser: what changed on DevDay](https://retrivium.ai/retrospectives/agents-computer-use-from-tools-to-browser.md): The Agents API browser expansion changed interaction state; compare identity checks and transitions with direct tools while keeping the task requirement fixed. (event: 2026-09-29)
- [The application still owns the browser sign-in boundary](https://retrivium.ai/retrospectives/agents-computer-use-authentication-boundary.md): Agents API browser sign-in establishes access, while the application must still bind the user request to the specific actions permitted under that account. (event: 2026-09-29)
- [What a browser-agent replay must preserve](https://retrivium.ai/retrospectives/agents-computer-use-replay-evidence.md): A browser-agent audit needs linked observations, intended actions and confirmed outcomes; reconstructing history is different from reapplying clicks. (event: 2026-09-29)
- [When a hosted browser is justified beside direct tools](https://retrivium.ai/retrospectives/agents-computer-use-api-vs-ui-selection.md): Use the Agents API browser option to close a specific evidence gap; an alternate path must preserve target identity and the original question. (event: 2026-09-29)
- [Dots changed a task into an ongoing responsibility](https://retrivium.ai/retrospectives/dots-persistent-responsibility.md): How always-on dots change task completion into responsibility management, with explicit triggers, stale assumptions and stopping conditions. (event: 2026-09-29)
- [A dot can learn a preference without gaining authority](https://retrivium.ai/retrospectives/dots-memory-vs-authority.md): Why learned preferences in dots must remain separate from access and action authority, illustrated by a draft-first reporting workflow. (event: 2026-09-29)
- [A personal cloud computer is an operational boundary](https://retrivium.ai/retrospectives/dots-cloud-computer-operating-boundary.md): Why dots' personal cloud computer makes retained files, session lifetimes and recovery evidence part of agent evaluation beyond model quality. (event: 2026-09-29)
- [How to review work that happened between conversations](https://retrivium.ai/retrospectives/dots-reviewing-background-work.md): How to review dots' background work using evidence-bearing handoffs that preserve partial results, missing dependencies and a clear next decision. (event: 2026-09-29)
- [Business connectors make record consistency part of agent work](https://retrivium.ai/retrospectives/muse-smb-connectors-record-consistency.md): Why Muse business connectors require entity matching and observation consistency rather than assuming connected tools share one transactional state. (event: 2026-09-29)
- [A business goal needs smaller observable action units](https://retrivium.ai/retrospectives/muse-smb-goal-to-action-granularity.md): How Muse's small-business goals can become observable stages without confusing useful drafts, completed actions and unmeasured business value. (event: 2026-09-29)
- [Connected context is not automatically the business source of truth](https://retrivium.ai/retrospectives/muse-smb-source-of-truth.md): Why Muse business synthesis needs source authority and permission boundaries when newer messages conflict with approved records. (event: 2026-09-29)
- [One graphics image reduces the GPU-generation image matrix](https://retrivium.ai/retrospectives/retro-workspaces-image-matrix.md): Unified WorkSpaces graphics images reduce generation-specific packaging across supported families. Application tests and licensing remain separate dimensions. (event: 2026-09-29)
- [Cross-family UpdateFleet changes the migration unit](https://retrivium.ai/retrospectives/retro-workspaces-cross-family-fleet.md): Cross-family UpdateFleet separates supported fleet selection from generation-specific image rebuilding. Image eligibility and application acceptance remain distinct steps. (event: 2026-09-29)
- [Image portability does not certify every graphics application](https://retrivium.ai/retrospectives/retro-workspaces-image-compatibility-validation.md): Image portability in WorkSpaces Applications concerns packaging support. Application output, plugins and licensing require distinct qualification evidence. (event: 2026-09-29)
- [How image generation separated steering from retraining](https://retrivium.ai/retrospectives/diffusion-controller-control-vs-retraining.md): How the Diffusion Controller explanation fits a longer search for steering image generation without treating every new objective as a full model retraining. (event: 2026-09-29)
- [Why controllable images require more than a single reward score](https://retrivium.ai/retrospectives/diffusion-controller-reward-tradeoffs.md): Why the Diffusion Controller discussion renews the distinction between optimizing one image reward and preserving a useful balance of generation qualities. (event: 2026-09-29)
- [How diffusion control changed what an inference interface should describe](https://retrivium.ai/retrospectives/diffusion-controller-serving-interfaces.md): How steering research such as Diffusion Controller changes what an image-inference interface should identify for reproducibility and workload evaluation. (event: 2026-09-29)
- [Sonnet 5.5 split the middle-tier question between office work and code](https://retrivium.ai/retrospectives/sonnet55-middle-tier-office-code.md): Why Sonnet 5.5's everyday-work positioning needs separate acceptance evidence for repository changes, spreadsheets and presentations. (event: 2026-09-28)
- [Faster Sonnet feedback changes the iteration budget](https://retrivium.ai/retrospectives/sonnet55-faster-feedback-budget.md): How faster Sonnet 5.5 output can change feedback loops, and why generation, human review and accepted completion need separate timing. (event: 2026-09-28)
- [A new Sonnet default should not silently rewrite the baseline](https://retrivium.ai/retrospectives/sonnet55-default-model-evaluation.md): Why Sonnet 5.5 adoption needs pinned evaluation identities and stable task cohorts, separate from whatever a product interface currently defaults to. (event: 2026-09-28)
- [Effort allocation matters inside the Sonnet 5.5 tier](https://retrivium.ai/retrospectives/sonnet55-effort-allocation.md): Why Sonnet 5.5 effort should follow task uncertainty and acceptance boundaries rather than treating the middle tier as one fixed cost-quality point. (event: 2026-09-28)
- [Team Bots: Shared expertise does not mean shared private conversations](https://retrivium.ai/retrospectives/team-bots-shared-expertise-private-context.md): Team Bots combine shared expertise with separate user context. This retrospective examines why those are different state boundaries in a collaborative agent. (event: 2026-09-28)
- [Team Bots: A shared bot needs explicit credential ownership](https://retrivium.ai/retrospectives/team-bots-credential-ownership.md): Why Team Bots make credential ownership a separate question from sharing an agent, with different identities for personal and team-connected tools. (event: 2026-09-28)
- [Team Bots: A team bot's learned role needs a correction path](https://retrivium.ai/retrospectives/team-bots-role-memory-correction.md): Why a learning Team Bot needs a correction path that identifies whether a mistaken instruction, shared skill or individual memory actually caused the answer. (event: 2026-09-28)
- [World Labs and AMD: model research as a hardware-design feedback loop](https://retrivium.ai/retrospectives/retro-amd-worldlabs-hardware-feedback.md): The World Labs agreement could shorten feedback between model research and compute design. The hypothesis needs a trace from workload behavior to a validated platform change. (event: 2026-09-28)
- [From AMD investment to a proposed World Labs acquisition](https://retrivium.ai/retrospectives/retro-worldlabs-investment-to-agreement.md): World Labs’ earlier funding and AMD’s platform roadmap explain strategic continuity before the acquisition agreement, while leaving internal intent and technical outcomes unproven. (event: 2026-09-28)
- [What AMD’s World Labs agreement establishes—and what it does not](https://retrivium.ai/retrospectives/retro-worldlabs-agreement-not-closing.md): The World Labs announcement establishes an acquisition agreement. Closing, integrated software and usable operating capability each need their own later evidence. (event: 2026-09-28)
- [Physical-AI research adds a workload lens to a compute acquisition](https://retrivium.ai/retrospectives/retro-worldlabs-physical-ai-infrastructure.md): The World Labs agreement is an opportunity to examine workload-to-hardware feedback. Physical-AI capacity still needs an explicit data path, execution profile and evaluation boundary. (event: 2026-09-28)
- [An expressive avatar can conceal unfinished backend work](https://retrivium.ai/retrospectives/avatar38-presence-vs-completion.md): Why Gemini Live Avatar's continuous visual presence needs separate evidence for backend completion and accurate status communication. (event: 2026-09-24)
- [Enterprise Avatar availability is not every Live API surface](https://retrivium.ai/retrospectives/avatar38-enterprise-surface-boundary.md): Why Gemini Live Avatar enterprise GA must retain platform, modality and custom-creation access boundaries rather than imply every Live API supports them. (event: 2026-09-24)
- [Lip sync and semantic agreement are separate checks](https://retrivium.ai/retrospectives/avatar38-audio-video-sync-evidence.md): Why Gemini Live Avatar lip sync, spoken meaning and task completion need separate evidence before an end-to-end quality claim. (event: 2026-09-24)
- [A visual persona needs a state handoff during tool delays](https://retrivium.ai/retrospectives/avatar38-character-state-handoff.md): How Gemini Live Avatar should represent waiting, user corrections and resolution as meaningful state transitions during asynchronous tool work. (event: 2026-09-24)
- [Vision DSpark: why faster decoding does not remove image-processing cost](https://retrivium.ai/retrospectives/lfm25-vision-dspark-prefill-boundary.md): The visual DSpark release is significant because it accelerates one stage of a multimodal request rather than making the whole request equivalent to text generation. (event: 2026-09-24)
- [vLLM watermarking: a provenance signal is not a truth score](https://retrivium.ai/retrospectives/vllm-watermark-provenance-not-truth.md): vLLM watermarking adds a statistical provenance signal, but the detector does not determine whether a passage is true or identify its human author. (event: 2026-09-24)
- [LFM2.5-VL-DSpark: visual preprocessing and decode acceleration](https://retrivium.ai/retrospectives/retro-liquid-vl-dspark-vision-prefill.md): Vision DSpark can change decoding without removing visual preparation, so its benefit depends on where a complete request spends its work. (event: 2026-09-24)
- [LFM2.5-VL-DSpark: a visual drafter and its target contract](https://retrivium.ai/retrospectives/retro-liquid-vl-dspark-draft-target.md): Vision DSpark needs a paired target and visual input path, so the draft artifact cannot be selected independently from the model it is meant to accelerate. (event: 2026-09-24)
- [LFM2.5-VL-DSpark: visual context and draft acceptance](https://retrivium.ai/retrospectives/retro-liquid-vl-dspark-acceptance-context.md): Vision DSpark's draft acceptance is workload-dependent, so a useful result on one visual task does not establish identical benefit on every output distribution. (event: 2026-09-24)
- [vLLM watermark detection: keys, tokenizers and the generation contract](https://retrivium.ai/retrospectives/retro-vllm-watermarking-key-tokenizer.md): A retrospective on text watermarking in vLLM and why detector configuration must identify the key, tokenizer and assumptions behind the generation process. (event: 2026-09-24)
- [vLLM watermark statistics: why searching many keys changes the conclusion](https://retrivium.ai/retrospectives/retro-vllm-watermarking-multiple-testing.md): How the vLLM watermarking release brings multiple-testing questions into serving operations, and why the best-looking detector result needs its search history. (event: 2026-09-24)
- [Voice design turned a preset into a control surface](https://retrivium.ai/retrospectives/tts38-voice-design-control-surface.md): How Gemini 3.8 TTS voice design turns descriptions into production specifications with separate identity, delivery and representative-script checks. (event: 2026-09-23)
- [Line-level direction can change the meaning of dialogue](https://retrivium.ai/retrospectives/tts38-dialogue-direction-semantics.md): Why Gemini 3.8 TTS line direction must preserve negation, uncertainty and speaker intent rather than optimize expressiveness alone. (event: 2026-09-23)
- [Flash TTS and Flash-Lite need workload-specific acceptance](https://retrivium.ai/retrospectives/tts38-flash-lite-production-choice.md): How to compare Gemini Flash TTS and Flash-Lite through distinct creative and batch workloads rather than one universal voice-quality ranking. (event: 2026-09-23)
- [A reusable voice is an artifact with provenance](https://retrivium.ai/retrospectives/tts38-voice-artifact-provenance.md): Why reusable Gemini 3.8 TTS voices need lineage records for design inputs, authorized source material and revisions beyond a saved profile name. (event: 2026-09-23)
- [Why Sol and Luna changed the economics of task allocation](https://retrivium.ai/retrospectives/sol-luna-two-model-economics.md): The Sol and Luna release widened model choices; compare completed workflows, escalations and acceptance quality before assigning work by token price. (event: 2026-09-22)
- [Image input did not turn Sol and Luna into image generators](https://retrivium.ai/retrospectives/sol-luna-image-input-text-output.md): Sol and Luna accept images and return text; distinguish screenshot interpretation from artifact creation when routing requests through a shared interface. (event: 2026-09-22)
- [What cached context changed in the Sol and Luna decision](https://retrivium.ai/retrospectives/sol-luna-cache-workload-economics.md): The Sol and Luna launch connected model choice with caching; analyze stable request context separately from changing evidence and generated output. (event: 2026-09-22)
- [An escalation policy after the Sol and Luna launch](https://retrivium.ai/retrospectives/sol-luna-escalation-evidence.md): Sol and Luna widened escalation choices, but a useful gate depends on missing evidence and acceptance conditions rather than confidence alone. (event: 2026-09-22)
- [Opus 5.5 made token efficiency a task-accounting question](https://retrivium.ai/retrospectives/opus55-token-efficiency-task-accounting.md): How to evaluate Opus 5.5 token efficiency using equivalent accepted tasks, including retries, validation and changes in work scope. (event: 2026-09-22)
- [Shorter Opus reports need a different review test](https://retrivium.ai/retrospectives/opus55-shorter-reports-review-quality.md): Why Opus 5.5's clearer communication claim needs a reconstruction test that preserves evidence, qualifications and the reader's decision. (event: 2026-09-22)
- [Action screening and model safeguards are different layers](https://retrivium.ai/retrospectives/opus55-action-screening-vs-model-policy.md): How Opus 5.5's action screening, sandbox and model safeguards form separate layers with different evidence and recovery obligations. (event: 2026-09-22)
- [The conditions behind Opus 5.5 cost-per-task comparisons](https://retrivium.ai/retrospectives/opus55-benchmark-cost-conditions.md): How to interpret Opus 5.5 cost-per-task comparisons through effort settings, harnesses and acceptance rules before testing another workload. (event: 2026-09-22)
- [Batch pricing trades immediacy for scheduling flexibility](https://retrivium.ai/retrospectives/retro-openrouter-batch-capacity-flexibility.md): Batch inference buys scheduling flexibility by relaxing immediacy. It performs new work within a variable completion window, while response caching avoids repeating an identical answered request. (event: 2026-09-22)
- [Why a batch has one provider even on a multi-provider gateway](https://retrivium.ai/retrospectives/retro-openrouter-batch-single-provider.md): OpenRouter routes each accepted batch through one eligible provider. Per-request results improve outcome handling but do not make every row an independent provider-routing decision. (event: 2026-09-22)
- [Seven-minute beta medians and a 24-hour completion window](https://retrivium.ai/retrospectives/retro-openrouter-batch-deadline-median.md): The seven-minute beta median is an observed cohort statistic. The 24-hour window and the application’s deadline remain separate conditions for useful batch work. (event: 2026-09-22)
- [Qwen3.8Omni report: from understanding media to executing media tasks](https://retrivium.ai/retrospectives/qwen38-omni-agent-productivity-report.md): The Qwen3.8Omni report shifts attention from describing media to completing media tasks, but perception and successful execution remain separate claims. (event: 2026-09-22)
- [vllm-metal: why concurrent serving changed the Mac-inference question](https://retrivium.ai/retrospectives/vllm-metal-scheduler-not-just-backend.md): vllm-metal made concurrent serving a central AppleSilicon question, rather than treating successful token generation as a complete description of deployment. (event: 2026-09-22)
- [Qwen3.8-Omni: media understanding and task execution](https://retrivium.ai/retrospectives/retro-qwen38-omni-report-media-planning.md): Qwen3.8-Omni shifts attention from media perception to agent deliverables. Trace why understanding a recording and completing its requested task differ. (event: 2026-09-22)
- [Qwen3.8-Omni: what a technical report establishes about weight availability](https://retrivium.ai/retrospectives/retro-qwen38-omni-report-paper-availability.md): The Qwen3.8-Omni paper documents a research disclosure. Trace why a technical report, product interface, source framework, and checkpoint need separate evidence. (event: 2026-09-22)
- [vllm-metal unified memory: why concurrent inference needs headroom](https://retrivium.ai/retrospectives/retro-vllm-metal-unified-memory.md): The vllm-metal release in context: shared memory changes placement, while concurrent requests still require an explicit budget for model state and the host. (event: 2026-09-22)
- [vllm-metal attention: the boundary between reused layers and request state](https://retrivium.ai/retrospectives/retro-vllm-metal-attention-replacement.md): Why the vllm-metal announcement separates reusable token operations from request-aware attention, and how this follows earlier serving-memory research. (event: 2026-09-22)
- [Harness-native training raises a transfer question](https://retrivium.ai/retrospectives/grok47-harness-native-transfer.md): How Grok 4.7's harness-native training claim creates a transfer question for third-party tool semantics, state encoding and recovery behavior. (event: 2026-09-21)
- [Longer Grok work needs verification that survives retries](https://retrivium.ai/retrospectives/grok47-long-tasks-verification.md): Why Grok 4.7 self-verification needs evidence tied to the final artifact after retries, changed inputs and revised methods. (event: 2026-09-21)
- [Grok 4.7: The same token rate can buy a different amount of work](https://retrivium.ai/retrospectives/grok47-same-rate-different-work.md): Grok 4.7 retained the predecessor’s launch token rates, but longer work, tool execution and acceptance criteria can change the cost of a completed task. (event: 2026-09-21)
- [Grok 4.7: A larger base model is not a complete architecture disclosure](https://retrivium.ai/retrospectives/grok47-bigger-base-not-architecture-proof.md): What Grok 4.7’s larger-base statement establishes, and why it does not disclose parameter counts, memory requirements or the cause of every benchmark gain. (event: 2026-09-21)
- [Qwen Image2.1: transparent generation meets unified editing](https://retrivium.ai/retrospectives/qwen-image21-rgba-unification.md): Qwen Image2.1 joins creation and editing with transparent-image workflows, but preserving that capability requires more than displaying a convincing preview. (event: 2026-09-20)
- [Qwen-Image-2.1: native transparency and ordinary RGB output](https://retrivium.ai/retrospectives/retro-qwen-image21-transparent-edit.md): Qwen-Image-2.1 brings native transparent output into unified image creation. Trace the path from layered images to preserving alpha through an application. (event: 2026-09-20)
- [Qwen-Image-2.1: reference-image editing and identity](https://retrivium.ai/retrospectives/retro-qwen-image21-reference-images.md): Qwen-Image-2.1 expands reference-image editing. Reconstruct why multiple visual inputs require explicit evidence roles rather than a vague similarity check. (event: 2026-09-20)
- [Grok Transcribe 2.0: Noisy-audio gains need workload slices rather than one WER](https://retrivium.ai/retrospectives/grok-transcribe2-noisy-audio-slices.md): Grok Voice Transcribe 2.0 emphasizes noisy audio. This retrospective separates telephony, accents and spoken identifiers rather than treating one WER as universal. (event: 2026-09-18)
- [Grok Transcribe 2.0: A wrong spoken identifier can outweigh fluent transcription](https://retrivium.ai/retrospectives/grok-transcribe2-identifier-cost.md): Why Grok Transcribe 2.0’s spoken-identifier focus calls for exact-value acceptance tests alongside ordinary transcript quality and average word error. (event: 2026-09-18)
- [Grok Transcribe 2.0: An API listing and a model announcement are different clocks](https://retrivium.ai/retrospectives/grok-transcribe2-listing-vs-announcement.md): Why an observed API catalog entry and the official Grok Transcribe 2.0 announcement date support different historical claims about model availability. (event: 2026-09-18)
- [Why model-server state matters more than connection counts](https://retrivium.ai/retrospectives/retro-hyperpod-routing-gpu-state.md): HyperPod Inference Gateway brought serving-aware destination selection to a per-cluster add-on. Connection counts alone cannot describe queue and memory pressure. (event: 2026-09-18)
- [The HyperPod launch did not make global routing generally available](https://retrivium.ai/retrospectives/retro-hyperpod-global-tier-boundary.md): The HyperPod launch separated an available per-cluster gateway from a forthcoming global tier. Architecture diagrams do not override those release statuses. (event: 2026-09-18)
- [Three dates behind the HyperPod Inference Gateway announcement](https://retrivium.ai/retrospectives/retro-hyperpod-release-announcement-dates.md): September release notes, the HyperPod launch blog and a later news post date different milestones. A precise history keeps those records separate. (event: 2026-09-18)
- [Grok Build Memory: Project memory must distinguish conventions from temporary state](https://retrivium.ai/retrospectives/grok-memory-convention-vs-transient-state.md): How Grok Build memory makes the distinction between durable project conventions and temporary task state a practical engineering boundary. (event: 2026-09-16)
- [Grok Build Memory: Background memory notes need an inspectable review surface](https://retrivium.ai/retrospectives/grok-memory-note-review.md): Why Grok Build’s background-written memory notes need an inspectable review surface, and how visible storage differs from verified memory content. (event: 2026-09-16)
- [Grok Build Memory: A correct memory note can become wrong after a repository change](https://retrivium.ai/retrospectives/grok-memory-repository-revision.md): How a correct Grok Build memory note can become obsolete after a repository revision, and why project memory needs a relationship to current source evidence. (event: 2026-09-16)
- [From a Rubin roadmap to a multi-rack cluster](https://retrivium.ai/retrospectives/retro-rubin-rack-to-cluster-milestone.md): CoreWeave’s Rubin chronology moves from planned adoption to a multi-rack bring-up. The milestone advances system evidence while leaving workload qualification distinct. (event: 2026-09-16)
- [Why object-storage changes accompanied CoreWeave’s Rubin cluster](https://retrivium.ai/retrospectives/retro-rubin-storage-locality-announcement.md): CoreWeave’s storage and Rubin announcements meet at artifact delivery. Write acceleration, model materialization and archive retention improve different stages of a workload lifecycle. (event: 2026-09-16)
- [Cluster bring-up versus readiness for a specific inference workload](https://retrivium.ai/retrospectives/retro-rubin-bringup-customer-readiness.md): CoreWeave’s multi-rack milestone establishes system progress. Workload readiness still concerns a named artifact, software combination, execution shape and request mix. (event: 2026-09-16)
- [Why multi-rack Rubin bring-up makes failure boundaries a system question](https://retrivium.ai/retrospectives/retro-rubin-multirack-failure-domain.md): Multi-rack Rubin deployment creates placement choices with different failure dependencies. Recovery scope follows the application’s cooperating set and shared services, not rack count alone. (event: 2026-09-16)
- [A Blackwell desktop bundle is not a general GPU instance](https://retrivium.ai/retrospectives/retro-workspaces-g7-service-boundary.md): Graphics G7 brought Blackwell to WorkSpaces Personal and Core. Desktop bundles, application fleets and general GPU instances retain different operating boundaries. (event: 2026-09-16)
- [What 32 GB per GPU changes for a remote graphics project](https://retrivium.ai/retrospectives/retro-workspaces-g7-scene-memory.md): WorkSpaces G7 specifies 32 GB per GPU. Scene residency, temporary buffers and multi-device behavior determine whether that budget suits a graphics project. (event: 2026-09-16)
- [AlwaysOn and AutoStop belong in the workstation migration decision](https://retrivium.ai/retrospectives/retro-workspaces-g7-desktop-lifecycle.md): The G7 desktop release included AlwaysOn and AutoStop. Workstation migration therefore requires a session-lifecycle decision alongside GPU selection. (event: 2026-09-16)
- [Parallel reasoning changes what waiting sounds like](https://retrivium.ai/retrospectives/live38-parallel-reasoning-dialogue.md): How Gemini 3.8 Live parallel reasoning changes progress narration, and why useful dialogue must remain separate from supported completion. (event: 2026-09-15)
- [Live and Extended Thinking solve different latency choices](https://retrivium.ai/retrospectives/live38-variant-task-choice.md): How to choose between Gemini 3.8 Live and Extended Thinking using task depth, acknowledgement timing and supported-resolution evidence. (event: 2026-09-15)
- [A spoken correction can invalidate pending tool work](https://retrivium.ai/retrospectives/live38-tool-cancellation-intent.md): Why Gemini 3.8 Live corrections need separate handling for obsolete tool results, cancellation attempts and already committed consequences. (event: 2026-09-15)
- [Live visual grounding still has a context-age problem](https://retrivium.ai/retrospectives/live38-audio-visual-context-age.md): Why Gemini 3.8 Live visual grounding must distinguish image comprehension from the age and applicability of the scene behind a spoken instruction. (event: 2026-09-15)
- [Why NUMA topology became part of managed Slurm placement](https://retrivium.ai/retrospectives/retro-aws-pcs-numa-placement.md): AWS PCS exposed NUMA topology and GPU affinity to managed Slurm placement. The change makes locality visible without promising a universal application speedup. (event: 2026-09-11)
- [MIG partitions became scheduler resources in AWS PCS](https://retrivium.ai/retrospectives/retro-aws-pcs-mig-allocation.md): AWS PCS added independent scheduling of compatible MIG instances. Hardware support, partition profiles and application memory remain separate constraints. (event: 2026-09-11)
- [Custom GRES as an escape hatch from automatic hardware discovery](https://retrivium.ai/retrospectives/retro-aws-pcs-custom-gres-escape-hatch.md): Custom GRES lets AWS PCS administrators express resources and topology beyond automatic discovery. An explicit declaration still needs to match real hardware. (event: 2026-09-11)
- [The Agents API moved the harness into the service boundary](https://retrivium.ai/retrospectives/agents-api-managed-harness-shift.md): The Agents API beta moved orchestration into a managed service; applications still own task identity, access, artifact handling and acceptance. (event: 2026-09-10)
- [A durable agent session is more than a saved chat](https://retrivium.ai/retrospectives/agents-api-durable-session-meaning.md): Durable Agents API sessions preserve a work context, but applications must distinguish task records, turn state, artifacts and acknowledgments during recovery. (event: 2026-09-10)
- [Hosted and self-hosted environments after the Agents API beta](https://retrivium.ai/retrospectives/agents-api-environment-choice.md): The Agents API added environment choices; compare data access, dependency ownership and artifact behavior before attributing outcomes to model intelligence. (event: 2026-09-10)
- [Why agent API success still needs a task acceptance artifact](https://retrivium.ai/retrospectives/agents-api-acceptance-artifacts.md): The Agents API can report a completed run while a private task remains incomplete; preserve an artifact with coverage, source identity and acceptance criteria. (event: 2026-09-10)
- [Full duplex changed the voice-agent state machine](https://retrivium.ai/retrospectives/live-api-full-duplex-state-machine.md): Why the GPT-Live-1 API release changes voice-agent state ownership, and how concurrent speech exposes cancellation and stale-result boundaries. (event: 2026-09-10)
- [Backend delegation separates conversation from slow reasoning](https://retrivium.ai/retrospectives/live-api-backend-delegation-latency.md): How backend reasoning delegation changes a live voice workflow, with separate acknowledgement, resolution and stale-context acceptance criteria. (event: 2026-09-10)
- [Why voice minutes and backend tokens need separate budgets](https://retrivium.ai/retrospectives/live-api-audio-clock-billing.md): Why the GPT-Live-1 launch price describes a voice layer rather than total agent cost, and how to account for delegated reasoning separately. (event: 2026-09-10)
- [Interruption quality needs a conversation fixture](https://retrivium.ai/retrospectives/live-api-interruption-acceptance.md): Interruption tests for GPT-Live-1 should distinguish thinking pauses, acknowledgements, corrections and task outcomes rather than measuring latency alone. (event: 2026-09-10)
- [DeepSeek V4.1 Flash: why the September release changed more than a model name](https://retrivium.ai/retrospectives/deepseek41-asymmetric-release-boundary.md): DeepSeek V4.1 Flash changes more than the name sent to an API: its asymmetric execution and native visual path create a new model contract. (event: 2026-09-10)
- [Introducing DeepSeek-V4.1-Flash: input and output execution roles](https://retrivium.ai/retrospectives/retro-deepseek41-flash-asymmetric-work.md): DeepSeekV4.1Flash's asymmetric encoder-decoder separates input and output roles, so one generic parameter or speed label cannot explain every workload bottleneck. (event: 2026-09-10)
- [Introducing DeepSeek-V4.1-Flash: API aliases and source reproducibility](https://retrivium.ai/retrospectives/retro-deepseek41-flash-alias-lifecycle.md): DeepSeekV4.1Flash's API transition shows why a stable client-side model name is not sufficient provenance for comparing answers across a release boundary. (event: 2026-09-10)
- [Introducing DeepSeek-V4.1-Flash: native vision and historical cache comparisons](https://retrivium.ai/retrospectives/retro-deepseek41-flash-vision-cache.md): DeepSeekV4.1Flash's architectural cache claims do not describe the entire memory footprint of a multimodal request, so historical comparisons need a clearly defined allocation boundary. (event: 2026-09-10)
- [Residency starts at gateway decryption, not only at the GPU](https://retrivium.ai/retrospectives/retro-openrouter-residency-gateway-decryption.md): OpenRouter’s regional route includes gateway decryption as well as eligible inference location. Customer deployment regions and retention remain separately scoped parts of the path. (event: 2026-09-09)
- [Why regional inference can fail with an otherwise valid model](https://retrivium.ai/retrospectives/retro-openrouter-regional-fail-closed.md): A valid global model may have no eligible regional endpoint. OpenRouter’s documented regional 404 preserves the location condition instead of silently sending the request elsewhere. (event: 2026-09-09)
- [A model’s country of origin is not its inference location](https://retrivium.ai/retrospectives/retro-openrouter-model-origin-hosting.md): OpenRouter’s regional announcement separates model provenance from serving location. The creator, operator, gateway and data policy are distinct parts of a processing description. (event: 2026-09-09)
- [Why the Finland expansion combined nuclear, wind and storage](https://retrivium.ai/retrospectives/retro-finland-energy-portfolio.md): The Finland portfolio combined nuclear life extension, wind, storage and exploratory flexibility. Their different grid functions and rollout states should remain explicit. (event: 2026-09-09)
- [Keeping a nuclear plant online is different from adding a new plant](https://retrivium.ai/retrospectives/retro-finland-life-extension-accounting.md): Loviisa life extension preserves a future supply path rather than creating a new reactor. Its contribution depends on the retirement counterfactual being changed. (event: 2026-09-09)
- [A hypothetical siting model is not a realized electricity-price result](https://retrivium.ai/retrospectives/retro-finland-siting-study-boundary.md): The Finland siting argument used commissioned hypothetical modeling. Scenario results can guide planning without being reported as realized national electricity-price savings. (event: 2026-09-09)
- [Demand-response exploration does not make every inference job interruptible](https://retrivium.ai/retrospectives/retro-finland-flexibility-compute.md): Finland's demand-response work was exploratory. Movable inference demand still requires a workload policy for deadlines, state preservation, restart and side effects. (event: 2026-09-09)
- [CUDA 13.4: Functional Rubin preview is not a blanket production-support claim](https://retrivium.ai/retrospectives/retro-cuda134-rubin-preview.md): CUDA 13.4 introduces functional Rubin preview support after the platform roadmap. Why porting access and production qualification belong to different milestones. (event: 2026-09-09)
- [CUDA 13.4: MPS management controls and MIG isolation remain different mechanisms](https://retrivium.ai/retrospectives/retro-cuda134-mps-control-isolation.md): CUDA 13.4 expands MPS management after earlier GPU partition controls. How to distinguish programmable sharing policy from a MIG hardware-isolation boundary. (event: 2026-09-09)
- [CUDA 13.4: Separating driver packaging makes an implicit dependency explicit](https://retrivium.ai/retrospectives/retro-cuda134-driver-toolkit-packaging.md): CUDA 13.4 separates driver and toolkit installers. How successive hardware and software releases made installation ownership a visible compatibility question. (event: 2026-09-09)
- [CUDA 13.4: Windows on Arm adds an operating-system axis to CUDA qualification](https://retrivium.ai/retrospectives/retro-cuda134-arm-os-matrix.md): CUDA 13.4 adds Windows on Arm after earlier Linux Arm and GPU-platform work. Why a CPU architecture does not determine an application’s operating-system support. (event: 2026-09-09)
- [Images 2.5 and the problem of preserving edits across turns](https://retrivium.ai/retrospectives/images25-editing-state-continuity.md): Images 2.5 strengthened iterative editing, but continuity still requires a governing reference, protected properties and versioned acceptance after each edit. (event: 2026-09-08)
- [Flare and Sunburst need different creative acceptance checks](https://retrivium.ai/retrospectives/images25-flare-sunburst-acceptance.md): Flare and Sunburst target different image workflows; compare exploratory variation and precise corrections under separate artifact acceptance criteria. (event: 2026-09-08)
- [Image provenance is not a reliable model-selector label](https://retrivium.ai/retrospectives/images25-provenance-vs-model-selection.md): Images 2.5 offers distinct API variants; preserve request identity, artifact identity and the documented meaning of provenance labels when attributing outputs. (event: 2026-09-08)
- [Sketches and comments made image intent more explicit](https://retrivium.ai/retrospectives/images25-sketch-comments-workflow.md): How sketches and image comments changed edit review in Images 2.5, and why spatial scope still needs a reference revision and preservation criteria. (event: 2026-09-08)
- [Why Muse's dedicated computer changed the personal-agent boundary](https://retrivium.ai/retrospectives/muse-dedicated-computer-personal-agent.md): Why Muse's dedicated computer makes browser state and retained artifacts part of the personal-agent contract rather than a chat-only capability. (event: 2026-09-08)
- [A personal goal does not define every background permission](https://retrivium.ai/retrospectives/muse-goals-vs-background-authority.md): How Muse's personal-goal framing separates supported preparation, connected access and exact actions without turning a broad objective into unlimited authority. (event: 2026-09-08)
- [The gap between Spark's model capability and Muse's useful work](https://retrivium.ai/retrospectives/muse-model-to-product-gap.md): Why Muse's launch should be evaluated as an objective-to-outcome product loop rather than inferred from Spark's planning capability alone. (event: 2026-09-08)
- [CUDA Rust offers a language choice and a separate programming-model choice](https://retrivium.ai/retrospectives/retro-cuda-rust-two-models.md): NVIDIA introduced SIMT and tile-oriented CUDA Rust tracks. Language choice, programming-model responsibility and production readiness remain separate decisions. (event: 2026-09-08)
- [What Rust ownership catches at a GPU launch boundary](https://retrivium.ai/retrospectives/retro-cuda-rust-borrow-boundary.md): Rust ownership can catch a bounded class of GPU programming mistakes. It does not establish numerical correctness, complete synchronization safety or production maturity. (event: 2026-09-08)
- [Why NVIDIA called its Rust GPU tracks early-stage](https://retrivium.ai/retrospectives/retro-cuda-rust-alpha-production.md): NVIDIA explicitly labeled CUDA Rust tracks early-stage. Runnable examples establish an experimental path rather than complete APIs or production readiness. (event: 2026-09-08)
- [Tile abstraction trades explicit thread control for compiler responsibility](https://retrivium.ai/retrospectives/retro-cuda-rust-abstraction-kernel-control.md): Tile-oriented CUDA Rust shifts mapping responsibility toward the compiler. That abstraction choice is separate from language choice and does not imply a universal speed advantage. (event: 2026-09-08)
- [How AlphaGenome Atlas moved inference from request time to publication time](https://retrivium.ai/retrospectives/alphagenome-atlas-precomputed-inference.md): How AlphaGenome Atlas illustrates a shift from interactive inference to precomputed scientific reference data, and what that changes in operations. (event: 2026-09-08)
- [Why AlphaGenome Atlas needs explanations alongside rankings](https://retrivium.ai/retrospectives/alphagenome-atlas-ranking-explanation.md): A retrospective on AlphaGenome Atlas and why a useful variant ranking needs inspectable reasons, calibration and a question-specific interpretation. (event: 2026-09-08)
- [How a model became a shared scientific reference with AlphaGenome Atlas](https://retrivium.ai/retrospectives/alphagenome-atlas-accessible-science.md): How AlphaGenome Atlas follows the path from specialized predictive models to shared research resources, where accessibility and traceability change reuse. (event: 2026-09-08)
- [Why a predictive atlas must version its data with its model](https://retrivium.ai/retrospectives/alphagenome-atlas-model-data-versioning.md): Why a predictive reference such as AlphaGenome Atlas needs linked model and dataset versions, reproducible snapshots and explicit refresh semantics. (event: 2026-09-08)
- [Why Astra made the API contract part of the model upgrade](https://retrivium.ai/retrospectives/astra-responses-tool-contract.md): Astra made tool integration part of the model migration: examine request items, execution results and continuation before comparing output quality. (event: 2026-09-03)
- [Astra and the shift from answering to completing long work](https://retrivium.ai/retrospectives/astra-long-running-work-completion.md): Astra arrived after execution and compaction primitives; the useful question is whether long work leaves evidence another reviewer can recover. (event: 2026-09-03)
- [The controls Astra removed, and what a migration must preserve](https://retrivium.ai/retrospectives/astra-reasoning-control-compatibility.md): Astra removed familiar sampling controls; a migration must preserve the task intention rather than silently translate unrelated settings. (event: 2026-09-03)
- [What the Astra launch can and cannot prove about a workflow](https://retrivium.ai/retrospectives/astra-launch-evidence-vs-task-acceptance.md): Astra launch evidence can justify a local trial, but workload conditions and acceptance criteria determine what the trial can actually establish. (event: 2026-09-03)
- [An acquisition agreement and an open-platform promise answer different questions](https://retrivium.ai/retrospectives/retro-nvidia-hf-open-platform.md): The NVIDIA–Hugging Face agreement and its openness promise concern different claims. Closing status and future platform behavior each require their own evidence. (event: 2026-09-03)
- [Why model distribution became strategically adjacent to compute](https://retrivium.ai/retrospectives/retro-nvidia-hf-distribution-compute.md): Model discovery and execution are complementary functions in the NVIDIA–Hugging Face chronology. Their strategic adjacency does not establish mandatory hardware lock-in. (event: 2026-09-03)
- [What NVIDIA explicitly said about other clouds and accelerators](https://retrivium.ai/retrospectives/retro-nvidia-hf-multicloud-commitment.md): NVIDIA promised continued cloud and accelerator choice in the Hugging Face announcement. That commitment is separate from model licenses, source access and future governance. (event: 2026-09-03)
- [The documented path from a compute partnership to an acquisition agreement](https://retrivium.ai/retrospectives/retro-nvidia-hf-partnership-acquisition-sequence.md): The documented NVIDIA–Hugging Face chronology supports strategic continuity, not inevitability. Partnership, provider breadth and acquisition agreement have different evidentiary roles. (event: 2026-09-03)
- [How WeatherNext 3 made observation freshness part of model design](https://retrivium.ai/retrospectives/weathernext-3-observation-to-forecast.md): How the route from GraphCast and GenCast to WeatherNext 3 made observation freshness an architectural question rather than a final dashboard detail. (event: 2026-09-03)
- [Why sharper weather forecasts change the serving workload](https://retrivium.ai/retrospectives/weathernext-3-resolution-serving.md): Why the move toward sharper forecasts in WeatherNext 3 changes output volume, data movement and workload design beyond a model-speed comparison. (event: 2026-09-03)
- [How weather AI reached the decision problem beyond average accuracy](https://retrivium.ai/retrospectives/weathernext-3-probability-decisions.md): How the path to WeatherNext 3 clarifies the difference between an accurate weather prediction and a useful decision under uncertainty. (event: 2026-09-03)
- [Why learned weather models still need physical consistency checks](https://retrivium.ai/retrospectives/weathernext-3-physical-consistency.md): Why the progression toward WeatherNext 3 leaves physical consistency, coupled variables and out-of-distribution tests central to learned forecasting. (event: 2026-09-03)
- [Spark 1.3 and the challenge of several workflows in one thread](https://retrivium.ai/retrospectives/spark13-long-thread-workflows.md): Why Spark 1.3 long-thread evaluation needs workflow identity and dependency checks when a user steers several unfinished deliverables. (event: 2026-09-02)
- [Spark 1.3 shows how API and coding-product feedback meet](https://retrivium.ai/retrospectives/spark13-api-product-feedback-loop.md): How Spark's model, coding-product and API release sequence helps separate feedback about intelligence from feedback about harnesses and integration. (event: 2026-09-02)
- [Max reasoning in Spark 1.3 is a configuration to evaluate](https://retrivium.ai/retrospectives/spark13-max-reasoning-acceptance.md): How to evaluate Spark 1.3 max reasoning against resolvable uncertainty, missing evidence and supported task completion rather than answer length. (event: 2026-09-02)
- [Flash 3.8 shows why a diligent model may spend more tokens](https://retrivium.ai/retrospectives/flash38-extra-work-cost.md): Why Gemini 3.8 Flash's additional diligence should be evaluated as changed work quantity alongside rates, tool waiting and accepted task outcomes. (event: 2026-09-02)
- [Flash and Flash Cyber need separate deployment descriptions](https://retrivium.ai/retrospectives/flash38-cyber-deployment-separation.md): Why Gemini 3.8 Flash and Flash Cyber need separate capability, access-route and authorized-task descriptions in deployment comparisons. (event: 2026-09-02)
- [Long-horizon software work needs intermediate checkpoints](https://retrivium.ai/retrospectives/flash38-long-horizon-software-checkpoints.md): Why Gemini 3.8 Flash long-horizon coding needs source-state checkpoints and validation tied to the delivered patch rather than an earlier success. (event: 2026-09-02)
- [Introductory Flash pricing is a historical condition](https://retrivium.ai/retrospectives/flash38-introductory-price-history.md): Why Gemini 3.8 Flash introductory pricing belongs in a dated adoption record rather than a timeless claim about task economics. (event: 2026-09-02)
- [Fable 5.1 made thinking history a compatibility boundary](https://retrivium.ai/retrospectives/fable51-reasoning-history-compatibility.md): Why Fable 5.1 thinking-history constraints turn a model upgrade into state migration, with a replay matrix for edited conversations and fallback. (event: 2026-09-01)
- [Why the Fable 5.1 forced-tool change matters to orchestration](https://retrivium.ai/retrospectives/fable51-forced-tools-contract.md): How Fable 5.1's forced-tool breaking change exposes routing, clarification and execution decisions that an application still needs to own. (event: 2026-09-01)
- [What cheaper Fable cache reads changed in long agent loops](https://retrivium.ai/retrospectives/fable51-cache-reads-agent-loops.md): Why cheaper Fable 5.1 cache reads change long-run cost composition without proving cache hits, fewer iterations or lower cost per accepted task. (event: 2026-09-01)
- [One frontier release, two access surfaces](https://retrivium.ai/retrospectives/fable51-two-access-surfaces.md): Why the paired Fable 5.1 and Mythos 5.1 release needs separate capability, availability and tested-deployment claims in model-selection records. (event: 2026-09-01)
- [Agentic video replaced uniform sampling with evidence seeking](https://retrivium.ai/retrospectives/agentic-video-search-vs-sampling.md): How Gemini agentic video changes evidence acquisition, with explicit checks for inspected intervals and search-hypothesis blind spots. (event: 2026-09-01)
- [Video token savings need a retained-evidence denominator](https://retrivium.ai/retrospectives/agentic-video-token-saving-coverage.md): Why agentic-video token savings need accepted answers, required-event coverage and complete attempts as their comparison boundary. (event: 2026-09-01)
- [When the transcript and frame describe different events](https://retrivium.ai/retrospectives/agentic-video-transcript-visual-disagreement.md): Why Gemini agentic video must preserve temporal relationships when combining transcript passages, narration and visual events. (event: 2026-09-01)
- [Not finding an event is not proof it never happened](https://retrivium.ai/retrospectives/agentic-video-negative-evidence.md): Why Gemini agentic video's not-found results need coverage-aware wording before they become claims that an event never occurred. (event: 2026-09-01)
- [HUMAIN: live compute is a different milestone from a gigawatt plan](https://retrivium.ai/retrospectives/retro-humain-live-versus-gigawatt-plan.md): HUMAIN’s August update combines live Instinct systems with future expansion targets. The operating milestone, scheduled power and workload allocation need separate records. (event: 2026-08-31)
- [Why HUMAIN’s GPU-as-a-service announcement includes its network fabric](https://retrivium.ai/retrospectives/retro-humain-gpu-fabric-platform.md): HUMAIN’s update includes Cisco fabric as part of the live compute platform. A useful interpretation maps artifact, execution, client and management traffic separately. (event: 2026-08-31)
- [Sovereign AI moves from investment language to operating responsibility](https://retrivium.ai/retrospectives/retro-humain-sovereign-ai-operation.md): HUMAIN’s live-system milestone shifts attention from investment scope to operating responsibility: access, maintenance, recovery and application acceptance need accountable owners. (event: 2026-08-31)
- [Sovereign AI capacity needs an operational boundary beyond location](https://retrivium.ai/retrospectives/retro-humain-sovereign-operations-stack.md): HUMAIN’s local compute milestone invites an application-level boundary map. Requests, artifacts, diagnostics, administration and recovery can follow different paths. (event: 2026-08-31)
- [Qwen3.8Next report: the state that active-parameter counts omit](https://retrivium.ai/retrospectives/qwen38-next-report-off-accelerator-state.md): The Qwen3.8Next report makes off-accelerator state part of the inference question, so activated parameters alone cannot describe deployment requirements. (event: 2026-08-31)
- [On the Design of Qwen3.8-Next Architecture: off-accelerator n-gram tables](https://retrivium.ai/retrospectives/retro-qwen38next-paper-ngram-residency.md): The Qwen3.8-Next report places n-gram tables outside the accelerator. Trace why active parameters no longer describe the complete inference memory path. (event: 2026-08-31)
- [On the Design of Qwen3.8-Next Architecture: architecture ablations and deployment conclusions](https://retrivium.ai/retrospectives/retro-qwen38next-paper-ablation-reading.md): Qwen3.8-Next architecture ablations explain research choices. Learn why pretraining evidence cannot directly establish production serving performance. (event: 2026-08-31)
- [Scene extension turns continuity into a reviewable constraint](https://retrivium.ai/retrospectives/omni11-extension-continuity.md): Why Omni 1.1 scene extension should be reviewed for physical and narrative continuity at the seam rather than attractive extra footage alone. (event: 2026-08-27)
- [First and last frames do not specify the entire transition](https://retrivium.ai/retrospectives/omni11-endpoints-transition-path.md): Why Omni 1.1 first-and-last-frame interpolation needs path constraints that distinguish camera motion, object motion and continuity between anchors. (event: 2026-08-27)
- [A resolution option is not a native-detail guarantee](https://retrivium.ai/retrospectives/omni11-resolution-upscaling-meaning.md): Why Omni 1.1 4K upscaling should be evaluated separately from native detail, content fidelity and temporal consistency in a delivered video. (event: 2026-08-27)
- [Cheap video previews need a deliberate final-artifact handoff](https://retrivium.ai/retrospectives/omni11-prototype-final-artifact.md): How Omni 1.1 lightweight previews need a clear creative-selection record and a separate final-artifact acceptance pass. (event: 2026-08-27)
- [How hidden tests became an infrastructure problem for AI evaluation](https://retrivium.ai/retrospectives/double-blind-ai-hidden-test.md): How the double-blind AI evaluation pilot follows the history of broader benchmarks and turns hidden test integrity into a systems problem. (event: 2026-08-27)
- [Why confidential evaluation must protect both models and questions](https://retrivium.ai/retrospectives/double-blind-ai-model-sovereignty.md): Why double-blind AI evaluation has two confidentiality objectives: protecting proprietary model artifacts and the evaluator’s undisclosed questions. (event: 2026-08-27)
- [How attestation changed the evidence behind an AI benchmark](https://retrivium.ai/retrospectives/double-blind-ai-attestation.md): How the double-blind evaluation pilot makes execution attestation relevant to benchmark evidence, while keeping configuration proof distinct from scientific validity. (event: 2026-08-27)
- [Why double-blind execution cannot repair a weak benchmark](https://retrivium.ai/retrospectives/double-blind-ai-benchmark-design.md): Why a double-blind evaluation process cannot repair an unrepresentative benchmark, and how to keep execution integrity separate from task validity. (event: 2026-08-27)
- [Smart transcription changes the boundary of a quotation](https://retrivium.ai/retrospectives/transcribe35-smart-cleanup-evidence.md): Why Gemini 3.5 Transcribe cleanup should be treated as a representation choice when readable notes and exact quotations have different obligations. (event: 2026-08-26)
- [Live and recorded transcription are different contracts](https://retrivium.ai/retrospectives/transcribe35-live-recorded-contracts.md): Why Gemini 3.5 Transcribe's live and recorded paths need different completion, input-identity and downstream-use rules. (event: 2026-08-26)
- [Custom vocabulary needs an audio-backed correction test](https://retrivium.ai/retrospectives/transcribe35-vocabulary-scope.md): How to test Gemini 3.5 Transcribe vocabulary hints using contrasting audio, corrected recognition and false substitutions rather than expected spellings alone. (event: 2026-08-26)
- [Speaker labels and word times carry different uncertainty](https://retrivium.ai/retrospectives/transcribe35-speaker-timestamp-trust.md): Why Gemini 3.5 Transcribe words, speaker labels and timestamps need separate acceptance checks before they are combined into an action record. (event: 2026-08-26)
- [Moving the memory controller changes more than a memory specification](https://retrivium.ai/retrospectives/retro-nvhbm-controller-placement.md): NVHBM moves memory-controller functionality into the HBM base die. The change shifts integration responsibilities while partner qualification remains future work. (event: 2026-08-26)
- [Custom XPU choice still depends on memory qualification](https://retrivium.ai/retrospectives/retro-nvhbm-custom-xpu-qualification.md): NVHBM extends modular infrastructure for custom XPUs. Reusing memory functionality can narrow design work while final combinations still require qualification. (event: 2026-08-26)
- [HBM power is not whole-inference energy](https://retrivium.ai/retrospectives/retro-nvhbm-component-system-energy.md): NVHBM component power claims do not directly establish whole-inference energy savings. A service result needs system scope, duration and useful-output accounting. (event: 2026-08-26)
- [Why custom accelerators can share a rack architecture without becoming identical](https://retrivium.ai/retrospectives/retro-nvhbm-hyperscaler-common-rack.md): Fusion and NVHBM can share infrastructure around specialized accelerators. Architectural interoperability does not imply identical instruction sets or portable model binaries. (event: 2026-08-26)
- [Two million planned GPUs are a delivery window, not an inventory snapshot](https://retrivium.ai/retrospectives/retro-aws-two-million-delivery-window.md): The AWS–NVIDIA plan spans 2027–2028. Its additional GPU count describes a future delivery flow rather than current region-level inventory or customer allocation. (event: 2026-08-26)
- [Why AI capacity announcements cannot be added without checking overlap](https://retrivium.ai/retrospectives/retro-aws-capacity-roadmap-overlap.md): Capacity headlines need scope and timing before aggregation. The AWS expansion count cannot be added to every related roadmap without evidence about overlap. (event: 2026-08-26)
- [A heterogeneous GPU roadmap needs common infrastructure as well as chips](https://retrivium.ai/retrospectives/retro-aws-common-infrastructure-heterogeneous.md): The AWS–NVIDIA roadmap spans heterogeneous generations and surrounding infrastructure. Useful service delivery depends on networking, isolation and software as well as GPU supply. (event: 2026-08-26)
- [A hyperscaler’s deployment plan does not reserve capacity for an application](https://retrivium.ai/retrospectives/retro-aws-public-plan-customer-allocation.md): The AWS expansion is aggregate future supply. An application still needs a supported shape, location, account conditions and a usable allocation window. (event: 2026-08-26)
- [GLM5.3 Flash: why the name hides a different base architecture](https://retrivium.ai/retrospectives/glm53-flash-new-base-chronology.md): GLM5.3 Flash should be understood as a new base and serving contract, rather than a smaller numerical representation of the preceding flagship. (event: 2026-08-26)
- [GLM-5.3-Flash: hybrid attention and serving assumptions](https://retrivium.ai/retrospectives/retro-glm53-flash-hybrid-state.md): GLM5.3Flash's newly trained hybrid base changes serving assumptions, so the Flash label is not a reason to copy the larger model's state handling unchanged. (event: 2026-08-26)
- [GLM-5.3-Flash: native visual input and model lineage](https://retrivium.ai/retrospectives/retro-glm53-flash-visual-base.md): GLM5.3Flash's native visual path belongs to a newly trained multimodal base, so it should not be described as a processor attached to an unchanged earlier text checkpoint. (event: 2026-08-26)
- [GLM-5.3-Flash: anonymous feedback before a named release](https://retrivium.ai/retrospectives/retro-glm53-flash-preview-feedback.md): Anonymous feedback around a model preview can reveal useful task cases, but it cannot become a controlled GLM5.3Flash benchmark merely after the model receives a public name. (event: 2026-08-26)
- [Shared Cowork memory changed the handoff between conversation and work](https://retrivium.ai/retrospectives/cowork-memory-cross-surface-continuity.md): How shared Claude and Cowork memory reduces repeated briefing while remaining distinct from current evidence and exact task artifacts. (event: 2026-08-25)
- [Editable topics made memory an inspectable product object](https://retrivium.ai/retrospectives/cowork-memory-editable-topics.md): How editable Claude memory topics turn repeated answer corrections into inspectable changes to persistent assumptions, with clear limits on retroactivity. (event: 2026-08-25)
- [Global memory and project evidence should remain distinguishable](https://retrivium.ai/retrospectives/cowork-memory-project-boundary.md): Why shared Cowork memory should distinguish portable writing preferences from project-specific definitions and source-bound factual claims. (event: 2026-08-25)
- [Memory defaults change what a continuation can assume](https://retrivium.ai/retrospectives/cowork-memory-sensitive-topic-defaults.md): How sensitive-topic memory settings change continuation inputs, and why missing context should be handled explicitly rather than invented. (event: 2026-08-25)
- [Granite4.2: why family naming is insufficient to infer architecture](https://retrivium.ai/retrospectives/granite42-dense-reasoning-family-change.md): Granite4.2 illustrates why a model-family name is not a complete architecture specification. (event: 2026-08-25)
- [Granite4.2 brings native reasoning to enterprise agents: dense models after hybrid predecessors](https://retrivium.ai/retrospectives/retro-ibm-granite42-dense-family.md): Granite4.2's dense architecture means that a family name cannot determine serving requirements, especially when an operator's earlier Granite configuration used different internal assumptions. (event: 2026-08-25)
- [Granite4.2 brings native reasoning to enterprise agents: native reasoning and enterprise parsers](https://retrivium.ai/retrospectives/retro-ibm-granite42-native-thinking.md): Granite4.2's native reasoning makes answer interpretation an enterprise integration question, because a capable response still needs an explicit boundary before it becomes an accepted structured result. (event: 2026-08-25)
- [Granite4.2 brings native reasoning to enterprise agents: multi-stage post-training and causal attribution](https://retrivium.ai/retrospectives/retro-ibm-granite42-multistage-rl.md): Granite4.2 changed post-training alongside enterprise reasoning. Reconstruct why the release invites a causal question that a headline benchmark cannot resolve. (event: 2026-08-25)
- [Groq 3 LPX separates token-generation specialization from general compute](https://retrivium.ai/retrospectives/retro-groq-lpx-decode-specialization.md): Groq 3 LPX was announced as a specialized generation extension to Rubin. Its role is best evaluated through phase placement and the surrounding system path. (event: 2026-08-24)
- [Full production hardware is not the same milestone as a public API](https://retrivium.ai/retrospectives/retro-groq-lpx-production-api.md): Groq 3 LPX production and Nebius integration are different milestones. A hardware release does not by itself establish a generally available customer API route. (event: 2026-08-24)
- [Fast token generation does not determine the whole agent loop](https://retrivium.ai/retrospectives/retro-groq-lpx-agent-speed-boundary.md): LPX accelerates a generation stage, while agents also process inputs, call tools and wait on dependencies. Task completion requires a wider timing boundary. (event: 2026-08-24)
- [Why the LPX benchmark needs its model and context denominator](https://retrivium.ai/retrospectives/retro-groq-lpx-benchmark-denominator.md): The LPX benchmark belongs to its stated model, context and system path. A useful comparison retains timing, concurrency and acceptable-output boundaries. (event: 2026-08-24)
- [Pipette: the August shift from model scores to deployed-system measurements](https://retrivium.ai/retrospectives/pipette-system-benchmark-2026.md): Pipette's release matters because it makes the measured unit an entire deployed configuration rather than an isolated model name. (event: 2026-08-24)
- [Introducing Pipette: context-dependent edge rankings](https://retrivium.ai/retrospectives/retro-liquid-pipette-context-rankings.md): Pipette's system-oriented benchmark framing makes context part of a ranking, so a leading result under one request shape cannot establish a universal edge winner. (event: 2026-08-24)
- [Introducing Pipette: runtime revisions as benchmark variables](https://retrivium.ai/retrospectives/retro-liquid-pipette-runtime-control.md): Pipette's deployed-system perspective makes a runtime revision a benchmark variable, rather than an invisible detail behind an unchanged model name. (event: 2026-08-24)
- [Introducing Pipette: thermal state and reproducible edge tests](https://retrivium.ai/retrospectives/retro-liquid-pipette-thermal-state.md): Pipette's on-device measurement framing makes device state part of reproducibility, so repeated runs need a declared lifecycle rather than an unexplained average. (event: 2026-08-24)
- [LFM2.5 DSpark release: why the drafter is a separate deployment artifact](https://retrivium.ai/retrospectives/lfm25-dspark-separate-artifacts.md): The text DSpark release adds a paired deployment artifact rather than a new replacement for the target model. (event: 2026-08-20)
- [Agentic Search: what changed from retrieval to inspect-and-verify loops](https://retrivium.ai/retrospectives/mistral-agentic-search-evidence-loop.md): Agentic Search changes the retrieval question from finding a plausible passage to deciding which evidence needs further inspection. (event: 2026-08-20)
- [LFM2.5-DSpark: draft storage versus verification savings](https://retrivium.ai/retrospectives/retro-liquid-text-dspark-draft-memory.md): Text DSpark adds a separate draft artifact, so saved serial target work must be considered alongside the state and execution work introduced by the drafter. (event: 2026-08-20)
- [LFM2.5-DSpark: distribution preservation and integration correctness](https://retrivium.ai/retrospectives/retro-liquid-text-dspark-sampling-proof.md): DSpark's speculative execution must preserve the intended target contract, so an algorithmic property cannot be assumed to validate every runtime and sampler combination. (event: 2026-08-20)
- [LFM2.5-DSpark: target revisions and draft compatibility](https://retrivium.ai/retrospectives/retro-liquid-text-dspark-target-identity.md): A target update changes the DSpark pair's identity, so an accepted draft configuration should not silently certify every later checkpoint from the same family. (event: 2026-08-20)
- [Introducing Agentic Search: search navigation versus answer generation](https://retrivium.ai/retrospectives/retro-mistral-agentic-search-verification-loop.md): Mistral's Agentic Search changes how evidence is found and inspected, but a successful navigation loop does not automatically make the final answer supported. (event: 2026-08-20)
- [Introducing Agentic Search: document revisions in agentic navigation](https://retrivium.ai/retrospectives/retro-mistral-agentic-search-document-identity.md): Agentic Search can inspect a document repeatedly, so preserving source revision becomes essential when an answer combines evidence collected at different moments. (event: 2026-08-20)
- [Introducing Agentic Search: retrieval turns as a stopping problem](https://retrivium.ai/retrospectives/retro-mistral-agentic-search-loop-budget.md): Agentic Search makes another retrieval step possible, but deciding when to stop remains an application question about unresolved evidence rather than a universal turn budget. (event: 2026-08-20)
- [Grok Build: A generated app becomes a different object when published](https://retrivium.ai/retrospectives/grok-build-everyone-preview-to-published.md): How Grok Build’s move from an in-chat preview to published apps changes artifact identity, audience and the evidence needed to review a generated application. (event: 2026-08-19)
- [The Grok Build name does not identify one runtime](https://retrivium.ai/retrospectives/grok-build-surface-runtime-differences.md): Why Grok Build’s open terminal harness and later web/mobile Build Mode need separate runtime descriptions despite sharing a product-family name. (event: 2026-08-19)
- [Grok Build: Mobile creation needs a deliberate review handoff](https://retrivium.ai/retrospectives/grok-build-mobile-review-handoff.md): How Grok Build’s mobile availability changes review ergonomics while leaving a generated app’s functional, audience and publication checks necessary. (event: 2026-08-19)
- [How billing infrastructure met inference routing](https://retrivium.ai/retrospectives/retro-stripe-openrouter-billing-routing.md): Stripe and OpenRouter connect customer billing with upstream inference decisions. Their agreement explains strategic overlap, while delivered integration and financial outcomes require later evidence. (event: 2026-08-19)
- [What neutrality meant in OpenRouter’s acquisition announcement](https://retrivium.ai/retrospectives/retro-openrouter-neutrality-after-agreement.md): OpenRouter’s continuity statement is a company commitment. Neutrality remains an operating question about exposed choices, caller constraints, selection rules and actual execution. (event: 2026-08-19)
- [From Stripe Projects integration to an acquisition agreement](https://retrivium.ai/retrospectives/retro-openrouter-acquisition-chronology.md): The earlier Stripe Projects flow connected account, key and billing setup. The later acquisition agreement is a distinct corporate milestone, not a retroactive change to that integration. (event: 2026-08-19)
- [LFM2.5 QAD: a quantized release produced by training, not just conversion](https://retrivium.ai/retrospectives/lfm25-qad-training-versus-conversion.md): The QAD release makes training provenance part of quantized-checkpoint identity rather than treating the quantization label as a complete description. (event: 2026-08-19)
- [LFM2.5 Q4_0: trained quantization and artifact provenance](https://retrivium.ai/retrospectives/retro-liquid-qad-trained-artifact.md): LFM2.5 QAD shows why a Q4_0 label identifies a representation rather than the complete training provenance of the checkpoint inside it. (event: 2026-08-19)
- [LFM2.5 Q4_0: teacher comparisons and local acceptance](https://retrivium.ai/retrospectives/retro-liquid-qad-teacher-reference.md): A teacher-recovery result for LFM2.5 QAD answers a model-comparison question, but it cannot certify a downstream extraction workflow whose errors have different consequences. (event: 2026-08-19)
- [LFM2.5 Q4_0: quantized migration and exact identifiers](https://retrivium.ai/retrospectives/retro-liquid-qad-precision-migration.md): Replacing a converted checkpoint with trained LFM2.5 QAD should preserve exact-identifier tests, because fluent output can conceal the errors most consequential to structured clients. (event: 2026-08-19)
- [GLM5.3: a new post-training milestone on an existing base](https://retrivium.ai/retrospectives/glm53-same-base-new-posttraining.md): GLM5.3's announcement is a post-training milestone rather than evidence that every capability gain requires a larger base model. (event: 2026-08-14)
- [Qwen3.8-27B: reconstructing a release distinct from Max-class weights](https://retrivium.ai/retrospectives/qwen38-27b-separate-weight-timeline.md): Qwen3.8-27B has its own release chronology, so family naming cannot substitute for identifying the checkpoint that was actually available and tested. (event: 2026-08-14)
- [GLM-5.3: same base and changed post-training](https://retrivium.ai/retrospectives/retro-glm53-announcement-base-reuse.md): GLM5.3's same-base update makes post-training the relevant comparison axis, so an unchanged parameter count cannot establish unchanged task behaviour. (event: 2026-08-14)
- [GLM-5.3: announcement and later weight publication](https://retrivium.ai/retrospectives/retro-glm53-announcement-release-stages.md): GLM5.3's announcement, hosted rollout and downloadable artifacts need separate dates, because one model name can span several availability milestones. (event: 2026-08-14)
- [GLM-5.3: defensive capability and evaluation scope](https://retrivium.ai/retrospectives/retro-glm53-announcement-cyber-evidence.md): Controlled defensive evaluations around GLM5.3 should be read as task-distribution evidence, rather than proof that a deployed system is universally secure. (event: 2026-08-14)
- [Qwen3.8-27B reasoning budgets: when more output stops helping the task](https://retrivium.ai/retrospectives/retro-qwen38-27b-weights-thinking-budget.md): A retrospective on Qwen reasoning controls and the Qwen3.8-27B weight release, separating model capability from the output budget a task actually needs. (event: 2026-08-14)
- [Qwen3.8-27B checkpoints: keep official weights and conversions distinct](https://retrivium.ai/retrospectives/retro-qwen38-27b-weights-precision-evidence.md): The Qwen3.8-27B release as an artifact history: preserve checkpoint revision, conversion lineage and template identity when interpreting local model results. (event: 2026-08-14)
- [Flash 3.7 turned developer feedback into a short release cycle](https://retrivium.ai/retrospectives/flash37-release-cadence-feedback.md): How Gemini 3.7 Flash's rapid release cadence can turn developer feedback into regression assets while keeping compatibility and quality distinct. (event: 2026-08-13)
- [A workhorse label needs completed-task token accounting](https://retrivium.ai/retrospectives/flash37-workhorse-token-efficiency.md): How Gemini 3.7 Flash's introductory rates and diligent tool work should be evaluated through the complete cost of an equivalent accepted task. (event: 2026-08-13)
- [UI generation gains still need reference fidelity checks](https://retrivium.ai/retrospectives/flash37-web-ui-reference-fidelity.md): Why Gemini 3.7 Flash UI claims need separate checks for screenshot resemblance, design-system rules and functional interaction states. (event: 2026-08-13)
- [Better knowledge work requires more than a polished artifact](https://retrivium.ai/retrospectives/flash37-knowledge-work-evidence.md): Why Gemini 3.7 Flash knowledge-work evaluation must preserve evidence identity through extraction, cross-document joins and final presentation. (event: 2026-08-13)
- [MiniMax Music3: why the August event was a weight release,not its first API](https://retrivium.ai/retrospectives/minimax-music3-hosted-versus-weights.md): MiniMax Music3's August event published music-generation weights and inference artifacts, which is different from the first availability of its hosted product. (event: 2026-08-13)
- [MiniMax Music3: why a text prompt still needs an audio inference contract](https://retrivium.ai/retrospectives/retro-minimax-music3-weights-audio-output.md): The Music3 weight release in context: text-conditioned music research led to a serving problem defined by audio artifacts, duration and generation stages. (event: 2026-08-13)
- [MiniMax Music3 weights: separating artifact access from model terms](https://retrivium.ai/retrospectives/retro-minimax-music3-weights-weight-license.md): A retrospective on Music3 open weights: distinguish hosted access, the downloadable package and the terms attached to the exact artifact being evaluated. (event: 2026-08-13)
- [Grok 4.6 and the difference between sustained work and long chat](https://retrivium.ai/retrospectives/grok46-sustained-work-vs-long-chat.md): Why Grok 4.6 sustained-work claims should be tested through external artifacts, stable objectives and supported progress rather than conversation length. (event: 2026-08-12)
- [Interactive artifacts need behavior checks beyond screenshots](https://retrivium.ai/retrospectives/grok46-interactive-artifact-acceptance.md): Why Grok 4.6 interactive artifacts need parameter, repeated-use and reset checks beyond the appearance of their initial screenshot. (event: 2026-08-12)
- [The Grok 4.6 model and its coding harness are separate evidence](https://retrivium.ai/retrospectives/grok46-coding-harness-boundary.md): Why Grok 4.6 coding evidence belongs to the model-and-harness combination, with tool contracts and available context retained in comparisons. (event: 2026-08-12)
- [First-week model access is a dated operating condition](https://retrivium.ai/retrospectives/grok46-provisional-access-assumptions.md): Why Grok 4.6 first-week included usage should remain a dated product condition, separate from permanent capability and task efficiency. (event: 2026-08-12)
- [LFM2.5-VL-3B: what changed for edge visual document tasks in August](https://retrivium.ai/retrospectives/lfm25-vl3b-visual-edge-release.md): The LFM2.5 visual release matters because a compact text lineage acquires a separate path for image evidence. (event: 2026-08-12)
- [LFM2.5-VL-3B: visual processors as release artifacts](https://retrivium.ai/retrospectives/retro-liquid-vl3b-vision-processor.md): LFM2.5-VL-3B's visual processor is part of the effective release artifact, because the same source image can become different evidence before model execution. (event: 2026-08-12)
- [LFM2.5-VL-3B: OCR questions and visual evidence](https://retrivium.ai/retrospectives/retro-liquid-vl3b-ocr-grounding.md): An OCR-style question for LFM2.5-VL-3B needs source-grounded acceptance, because a persuasive visual explanation can differ from an accurate reading of the image. (event: 2026-08-12)
- [LFM2.5-VL-3B: text lineage and visual capability](https://retrivium.ai/retrospectives/retro-liquid-vl3b-text-visual-lineage.md): LFM2.5-VL-3B's text lineage helps explain its architecture, but visual capability still depends on a separately identified path from image evidence to model representation. (event: 2026-08-12)
- [Grok Bot moved from a workflow run to a persistent teammate](https://retrivium.ai/retrospectives/grok-bot-from-workflow-to-teammate.md): How Grok Bot's persistent-worker beta changes instruction lifetimes, routine corrections and the assumptions behind repeated work. (event: 2026-08-11)
- [A cloud computer changes what survives a user handoff](https://retrivium.ai/retrospectives/grok-bot-cloud-session-handoff.md): Why Grok Bot cloud handoffs must reconcile current intent, retained browser state and saved or committed effects separately from conversation memory. (event: 2026-08-11)
- [Approval interrupts are part of the task protocol](https://retrivium.ai/retrospectives/grok-bot-approval-interrupts.md): How Grok Bot approval handoffs should connect finished preparation, the exact remaining decision and the operation applied under existing authorization. (event: 2026-08-11)
- [Grok Bot's beta usage boundary needs a date](https://retrivium.ai/retrospectives/grok-bot-usage-boundary-history.md): Why Grok Bot beta's separate usage boundary should remain dated and distinct from task resource consumption, accepted outcomes and later plan terms. (event: 2026-08-11)
- [Lightning and Switchyard: why the August launch contains two different building blocks](https://retrivium.ai/retrospectives/lightning-switchyard-model-router-split.md): Lightning and Switchyard represent two different building blocks: a specialized executor and a routing library. (event: 2026-08-11)
- [NVIDIA Nemotron3.5 Lightning and NeMo Switchyard: routing library and specialist model](https://retrivium.ai/retrospectives/retro-nemotron35-lightning-router-library.md): NeMo Switchyard and NemotronLightning solve different layers of a specialist system, so a routing library cannot choose the correct model from one attractive benchmark score. (event: 2026-08-11)
- [NVIDIA Nemotron3.5 Lightning and NeMo Switchyard: distillation lineage and task specialization](https://retrivium.ai/retrospectives/retro-nemotron35-lightning-distillation.md): NemotronLightning's distillation lineage describes a training relationship, not universal equivalence to a larger teacher across every planning and execution task. (event: 2026-08-11)
- [NVIDIA Nemotron3.5 Lightning and NeMo Switchyard: specialists inside long-running workflows](https://retrivium.ai/retrospectives/retro-nemotron35-lightning-execution-loop.md): NemotronLightning can occupy repeated execution steps in a longer workflow, but a compact specialist does not remove the need to validate external actions and accumulated state. (event: 2026-08-11)
- [Grok Image 2.0: checking typography beyond visual quality](https://retrivium.ai/retrospectives/imagine2-typography-acceptance.md): Imagine Image 2.0 emphasizes typography and layout. This retrospective separates exact wording, visual hierarchy and placement in useful generated graphics. (event: 2026-08-07)
- [Grok Image 2.0: which reference details an edit must preserve](https://retrivium.ai/retrospectives/imagine2-edit-reference-identity.md): Why reference-preserving edits in Grok Image 2.0 need explicit invariants, so attractive changes do not erase the subject details the request required. (event: 2026-08-07)
- [Grok Image 2.0: what the Quality Mode label establishes](https://retrivium.ai/retrospectives/imagine2-quality-mode-task-meaning.md): What Grok Image 2.0’s Quality Mode label establishes, and why task-specific acceptance still needs evidence about text, references and usable output. (event: 2026-08-07)
- [SK hynix FMS: Why FMS framed AI memory as placement across tiers](https://retrivium.ai/retrospectives/retro-fms-memory-tier-placement.md): SK hynix’s FMS presentation followed a rack-scale roadmap and HBM shipment update. Why the next memory question concerns state placement across a hierarchy. (event: 2026-08-07)
- [SK hynix FMS: An HBF roadmap is not evidence of deployable HBF servers](https://retrivium.ai/retrospectives/retro-fms-hbf-roadmap-shipment.md): The HBF discussion at FMS followed established HBM shipment milestones. How to read an emerging memory roadmap without treating it as deployable server supply. (event: 2026-08-07)
- [SK hynix FMS: CXL expansion adds a placement option, not equivalent local memory](https://retrivium.ai/retrospectives/retro-fms-cxl-capacity-latency.md): How the path from HBM supply to FMS hierarchy demonstrations changed the CXL discussion from extra capacity to a workload placement decision. (event: 2026-08-07)
- [SK hynix FMS: A broad memory portfolio still needs software to manage state](https://retrivium.ai/retrospectives/retro-fms-memory-vendor-system-role.md): SK hynix’s broad FMS portfolio followed platform and shipment milestones. Why a complete component menu still leaves cache movement and lifecycle policy to software. (event: 2026-08-07)
- [Taalas and AMD’s shift toward workload-specialized inference hardware](https://retrivium.ai/retrospectives/retro-amd-taalas-specialized-inference.md): The Taalas agreement follows phase-level inference specialization and a broader AMD platform roadmap. Its useful question is where a tailored execution path fits a changing workload. (event: 2026-08-06)
- [Why the Taalas headline must be read with the closing conditions](https://retrivium.ai/retrospectives/retro-taalas-agreement-headline-body.md): The Taalas headline and release body carry different levels of precision. An event card should preserve the title while classifying the announced transaction from its operative text. (event: 2026-08-06)
- [Two different routes to specialized inference in AMD’s 2026 portfolio](https://retrivium.ai/retrospectives/retro-taalas-cerebras-inference-portfolio.md): The Cerebras and Taalas announcements suggest complementary inference paths. A useful portfolio analysis first distinguishes alternatives, phase components and platform layers. (event: 2026-08-06)
- [An inference-chip agreement still leaves an integration roadmap](https://retrivium.ai/retrospectives/retro-taalas-integration-roadmap-risk.md): The Taalas agreement begins an integration roadmap. A maintained inference path needs explicit model artifacts, runtime dispatch, version qualification and support ownership. (event: 2026-08-06)
- [CoreWeave Indonesia: Contracted Indonesian power and live GPU supply are different ledgers](https://retrivium.ai/retrospectives/retro-coreweave-indonesia-contract-live.md): CoreWeave’s Indonesia expansion followed a hardware roadmap and execution-platform releases. Why contracted power for 2028 is a different record from live GPU supply. (event: 2026-08-04)
- [CoreWeave Indonesia: A new AI region needs an operations team as well as equipment](https://retrivium.ai/retrospectives/retro-coreweave-indonesia-local-operations.md): CoreWeave’s Indonesia plan includes local operations training. How earlier compute and sandbox releases make staffing part of AI regional capacity rather than an afterthought. (event: 2026-08-04)
- [CoreWeave Indonesia: Locality benefits require a local service path, not just a facility address](https://retrivium.ai/retrospectives/retro-coreweave-indonesia-location-service.md): CoreWeave’s future Indonesian sites make locality a useful question. Why a regional facility address alone cannot establish the complete path of an AI request. (event: 2026-08-04)
- [CoreWeave Indonesia: A 2028 facility plan must remain flexible across accelerator generations](https://retrivium.ai/retrospectives/retro-coreweave-indonesia-generation-window.md): CoreWeave’s 2028 Indonesian facility plan followed a 2026 accelerator roadmap. A retrospective on why datacenter design and GPU generations run on different clocks. (event: 2026-08-04)
- [LFM2.5-2.6B: reconstructing the local-agent release from primary dates](https://retrivium.ai/retrospectives/lfm25-26b-announcement-timeline.md): The LFM2.5-2.6B announcement should be understood as a local-agent milestone with several later artifact branches, not a single date attached to every file in its ecosystem. (event: 2026-08-04)
- [Shieldstral: the August move from fixed labels to policy questions](https://retrivium.ai/retrospectives/shieldstral-policy-question-release.md): Shieldstral made policy questions part of a multimodal classifier's input, which changes how moderation behaviour must be recorded and compared. (event: 2026-08-04)
- [SpecForge: the August separation of target and trainer lifecycles](https://retrivium.ai/retrospectives/specforge-target-trainer-lifecycle-split.md): SpecForge separated target feature production from draft optimization, making their independent lifecycles an architectural concern rather than a minor release detail. (event: 2026-08-04)
- [LFM2.5-2.6B: reasoning traces in persistent local agents](https://retrivium.ai/retrospectives/retro-liquid-26b-thinking-session.md): LFM2.5-2.6B's compact weights do not imply a compact lifetime session, because persistent agents also accumulate conversations, tool results and unfinished work. (event: 2026-08-04)
- [LFM2.5-2.6B: tool completion versus fluent planning](https://retrivium.ai/retrospectives/retro-liquid-26b-tool-evidence.md): LFM2.5-2.6B's agent-oriented release makes tool use relevant, but a fluent plan is not evidence that an external action completed successfully. (event: 2026-08-04)
- [LFM2.5-2.6B: announcement dates and model-card refreshes](https://retrivium.ai/retrospectives/retro-liquid-26b-date-provenance.md): LFM2.5-2.6B's release history should follow the dated primary announcement, rather than treating later model-card changes or secondary coverage as a new launch. (event: 2026-08-04)
- [Introducing Shieldstral: policy questions as versioned inputs](https://retrivium.ai/retrospectives/retro-mistral-shieldstral-policy-question.md): Shieldstral puts policy questions in the inference input. Trace the move from fixed guardrail labels to versioned wording that applications must evaluate. (event: 2026-08-04)
- [Introducing Shieldstral: content policy versus provenance detection](https://retrivium.ai/retrospectives/retro-mistral-shieldstral-classifier-provenance.md): Shieldstral moderation and watermark detection answer different questions. Trace why content-policy classification cannot establish a text’s origin. (event: 2026-08-04)
- [SpecForge disaggregation: captured features need an ownership lifecycle](https://retrivium.ai/retrospectives/retro-specforge-disaggregation-feature-ownership.md): How SpecForge reached separate target-inference and draft-training pools, and why the resulting feature pipeline needs explicit ownership and recovery rules. (event: 2026-08-04)
- [SpecForge consistency gates: a small correctness check before a large run](https://retrivium.ai/retrospectives/retro-specforge-disaggregation-consistency-gate.md): A retrospective on the SpecForge training-serving consistency gate: why a controlled example can reject an incompatible pipeline without proving final model quality. (event: 2026-08-04)
- [Qwen3.8 Max: separate the August3 announcement from subsequent weights](https://retrivium.ai/retrospectives/qwen38-max-announcement-and-weights.md): Qwen3.8 Max's announcement created a cloud-model milestone and a future weight commitment, not one universally available artifact. (event: 2026-08-03)
- [Qwen3.8-Max: hosted vision and downloadable text weights](https://retrivium.ai/retrospectives/retro-qwen38max-announcement-weight-modality.md): Qwen3.8Max's hosted capabilities and downloadable checkpoint contract must be checked separately, because one family announcement does not make every route expose identical modalities. (event: 2026-08-03)
- [Qwen3.8-Max: active parameters and full checkpoint movement](https://retrivium.ai/retrospectives/retro-qwen38max-announcement-max-scale.md): Qwen3.8Max's selected computation should not be confused with full checkpoint movement, because loading and distributing an artifact involve state beyond the experts active for one request. (event: 2026-08-03)
- [Qwen3.8-Max: one announcement and several availability clocks](https://retrivium.ai/retrospectives/retro-qwen38max-announcement-release-clock.md): Qwen3.8Max's cloud announcement, checkpoint publication and runtime support form separate availability clocks, so one launch date cannot stand in for the complete adoption history. (event: 2026-08-03)

## Resources

- [Full text](https://retrivium.ai/llms-full.txt)
- [Markdown](https://retrivium.ai/index.md)
- [RSS](https://retrivium.ai/rss.xml)
- [XML sitemap](https://retrivium.ai/sitemap-index.xml)
- [Russian collection](https://retrivium.ai/ru/journal/)