RETRIVIUM / SITE MAP
Every useful page in one place.
1478 English pages, including 970 guides and 500 retrospectives. The global XML sitemap includes both languages.
Main pages
GPU owners
- How to rent out your GPU for LLM inference↗
- What hardware is suitable for an LLM inference pool?↗
- Can NVIDIA RTX cards be used for LLM inference?↗
- How to prepare a GPU server for a technical pilot↗
- GPU networking and availability: beyond internet speed↗
- Equipment security when joining a GPU pool↗
- GPU inference pilot: what to check before an operating agreement↗
- Mining rigs for LLMs: which components can be reused?↗
- Idle render farms: assessing a second GPU workload↗
- Workstation GPUs at night: when scheduled operation makes sense↗
- Spare game-studio GPUs: separating resources for inference↗
- GPU integrators and suppliers: offering a fleet for a pilot↗
- Used GPUs: which checks are needed before a pilot?↗
- Mixed GPU fleets: how to offer them to an inference operator↗
- Reserve GPU servers: useful workloads without losing the reserve↗
- Joining a GPU pool: the decisions at each stage↗
- GPUs free for a few months: offering temporary capacity↗
- Who can reach your GPU server? Physical support for remote nodes↗
- I have one GPU: how do I start an onboarding conversation?↗
- Finding spare GPUs inside a company and preparing a proposal↗
- Returning your GPU to your own work after leaving a pool↗
- Mapping a company’s idle GPUs for a new service↗
- GPU-node acceptance: evidence beyond an attractive benchmark↗
- Providing a GPU or handing over operations: what the owner retains↗
- Vast.ai Hosting Setup: Prepare a Verifiable Server Record↗
- Vast.ai Host Verification: What Each Stage Actually Shows↗
- Vast.ai Offer End Date: Plan When Your Server Must Return↗
- Scheduling Maintenance for a Vast.ai Host↗
- Test Your Own Vast.ai Host Through a Rental↗
- GPU Colocation Power Budget: Check the Site Limit↗
- Offer Your GPU Server Without Relocating It↗
- A GPU Availability Calendar Across Time Zones↗
- Build a GPU Inventory CSV with nvidia-smi↗
- GPU Operator Handover: Issue and Revoke Access Keys↗
- Close a GPU Pilot with a Data Cleanup Record↗
- Keep a Network Outage Log for a GPU Node↗
- A Change Register for GPU Drivers and Server Settings↗
- RTX 3090 vs RTX 4090 for LLMs: Compare the Same Workload↗
- RTX 4090 vs RTX 5090 for LLMs: Compare 24GB and 32GB↗
- RTX 4090 48GB: Distinguish Official Hardware from Modifications↗
- RTX 4090 Laptop vs Desktop for Local LLMs↗
- Choose a Local LLM for an RTX 3090 24GB↗
- RTX 5090 LLM Tokens per Second: Define the Benchmark↗
- Coding LLMs on 8GB VRAM: Start with a Bounded Task↗
- Coding LLMs on 12GB VRAM: Budget Context and Headroom↗
- Local LLMs on 16GB VRAM: Narrow the Model Choice↗
- Local LLMs on 24GB VRAM: Test More Than the Weights↗
- 48GB VRAM for LLMs: One GPU and Multiple GPUs Differ↗
- How Much VRAM Does a 70B Model Need?↗
- Calculate Weight Memory for an 8B Model↗
- A 14B Model on 16GB VRAM: Understand the Bit Estimate↗
- A 32B Model on 24GB VRAM: Why the Formula Is Not Enough↗
- Qwen3-8B VRAM: Thinking Mode and a First Local Test↗
- Qwen3-Coder VRAM: Check the Exact Model Variant↗
- Qwen3-VL VRAM: Test Images of Different Complexity↗
- gpt-oss-20b VRAM: Read the Conditions Behind the Claim↗
- gpt-oss-120b VRAM: Total MoE Weights and Active Parameters↗
- DeepSeek-R1 vs Distill: Different Models, Different GPU Needs↗
- DeepSeek-OCR GPU Requirements: Test Accuracy and Memory↗
- Two 24GB GPUs vs One 48GB GPU for an LLM↗
- RTX 5060 Ti 16GB vs RTX 5070 12GB for Local LLMs↗
- A100 40GB vs 80GB for LLMs: Check Memory and Form Factor↗
- H100 PCIe vs SXM for LLMs: Compare the Whole System↗
Research and grants
- What to do with GPU servers after a grant-funded project↗
- How laboratories can assess spare GPU capacity↗
- Grant-funded equipment: a checklist before external workloads↗
- Finding an operating budget for grant-funded GPUs after a project↗
- Cloud credits or owned GPUs: what can be offered to an operator?↗
- Preparing a laboratory proposal for GPU cooperation↗
- Shared GPU resources: agreeing laboratory, operator and partner roles↗
- Research data and an external GPU pilot: defining the boundary↗
- Return a GPU to Its Research Window↗
- GPU Cloud Credits Expiring Soon: Plan a Useful Pilot↗
- Grant Funded GPUs: Document Remote Access for Review↗
- Allocate Electricity Costs for a Shared Research GPU↗
- Check Which GPU Expenses Cloud Credits Cover↗
Technology
- What is LLM inference, and why does it need your GPU?↗
- VRAM for LLMs: why model size is only part of the calculation↗
- How a GPU pool connects to OpenRouter↗
- LLM inference versus training: what GPU owners should know↗
- Multiple GPUs in a pool: one service or one large model?↗
- Choosing an LLM for your server: start with its model and terms↗
- Prefill and decode: the work your GPU performs during inference↗
- Continuous batching: why concurrent requests change GPU value↗
- Prefix caching: when repeated context helps a GPU pool↗
- Long-context LLMs: testing a server for document workloads↗
- LLM quantization: checking quality before choosing a GPU↗
- A GPU inference benchmark you can trust↗
- Throughput and latency: choosing a GPU operating point↗
- Routing and fallback: which role could your GPU serve?↗
- GPU monitoring without excess charts: five observation levels↗
- Reproducible inference stacks: preserving a GPU pilot’s result↗
- Embeddings and rerankers: other tasks for an idle GPU↗
- Updating an LLM on a GPU: testing a new version with a small rollout↗
- A reference GPU-node configuration for a small pool↗
- CUDA Out of Memory While Loading a Model: A Check Order↗
- CUDA Out of Memory on Long Prompts: Check the Context↗
- CUDA Out of Memory with Concurrent Requests↗
- CUDA OOM Allocated vs Reserved: Read the Evidence↗
- First Verifiable vLLM Launch in Docker on NVIDIA GPUs↗
- Install vLLM: Check GPU, Driver and Package Compatibility↗
- vLLM on Windows: WSL and the Linux Environment↗
- vLLM served-model-name: Fix a Missing API Model↗
- vLLM max-model-len: Set a Meaningful Context Limit↗
- What vLLM gpu-memory-utilization Actually Limits↗
- vLLM tensor-parallel-size: When One Model Needs Multiple GPUs↗
- vLLM Quantization: Match the Weights, Format and GPU↗
- vLLM and GGUF: Check Compatibility Before Moving a Model↗
- vLLM bench serve: Read a Serving Benchmark Result↗
- vLLM is running but not ready: health checks and the first request↗
- vLLM KV cache preemption: why requests are recomputed↗
- Testing streaming responses from the vLLM API↗
- vLLM is unreachable: localhost, containers and published ports↗
- vLLM or Ollama: choose a serving workflow↗
- vLLM or llama.cpp: serving workloads and GGUF workflows↗
- Ollama is not using the GPU: five separate checks↗
- Ollama on Windows: verify GPU support and workload placement↗
- Ollama on AMD: check your exact GPU and backend↗
- Ollama context length: set and verify the actual window↗
- Running two Ollama models at once: memory and concurrency↗
- Ollama CPU and GPU split: interpreting mixed placement↗
- Ollama keep_alive: retain or unload a model deliberately↗
- Choosing a GGUF file for llama.cpp↗
- llama.cpp server: a local API from a GGUF model↗
- llama.cpp GPU layers: verify partial model offloading↗
- Building llama.cpp on Windows with the right backend↗
- SGLang in Docker: launch and verify your first model↗
- SGLang or vLLM: compare engines on the same workload↗
- SGLang memory fraction: diagnose GPU memory pressure↗
- Batch text embeddings on your own GPU↗
- Evaluating embeddings for Russian language retrieval↗
- Reranking in RAG: how many candidates should you rescore?↗
- BGE rerankers on GPU: testing memory and batching↗
- Qwen rerankers: separating relevance scoring from text generation↗
- Running Whisper in a GPU container: a preflight checklist↗
- Long audio with Whisper: segments, queues and durable results↗
- PaddleOCR on GPU: validating installation and document quality↗
- Tesseract and GPU acceleration: why installing CUDA is insufficient↗
- A GPU OCR pipeline for a 1,000-page PDF workload↗
- Multiple GPUs for ComfyUI: one workflow or separate queues?↗
- Benchmarking GPUs for Stable Diffusion reproducibly↗
- A bounded PEFT and LoRA experiment on your GPU↗
- Model aliases and revisions: provider response identity↗
- SSE and UTF-8: a network chunk is not a JSON event↗
- SSE completion: blank lines, DONE and unexpected EOF↗
- SSE heartbeats and idle timeouts: what keeps a connection alive↗
- Slow SSE clients: backpressure and bounded memory↗
- Testing SSE buffering at a reverse proxy↗
- HTTP response integrity: Content-Length, chunked transfer and truncation↗
- HTTP/2 GOAWAY during inference endpoint updates↗
- SSE reconnection does not imply resuming an LLM generation↗
- Request cancellation: testing the full client-to-engine chain↗
- Graceful inference-server termination with active streams↗
- Request deadlines: budgeting queueing, prefill and streaming↗
- HTTP body limits and token limits: separate inference API checks↗
- Provider overload: Retry-After as part of the contract↗
- Retrying generation POSTs: idempotency must be explicit↗
- Provider admission control: bound the queue before latency grows↗
- Keeping model capabilities and rollout state consistent↗
- Startup, readiness and liveness for a slow-loading model server↗
- Monotonic clocks for inference API latency measurements↗
- First byte, first chunk and first token are different latencies↗
- Inter-token gaps and throughput: do not average different quantities↗
- Fleet p95: aggregate histograms rather than precomputed percentiles↗
- A successful stream for an SLO: define the event and denominator↗
- Inference SLO burn rates: multi-window alerting↗
- Provider metric cardinality: request IDs do not belong in labels↗
- Request IDs and trace context across gateway, API and engine↗
- OpenTelemetry GenAI: pin the semantic-convention version↗
- Inference API telemetry without default prompt capture↗
- From a slow histogram bucket to a trace through an exemplar↗
- Terminal request records: reconcile stream, usage and logs↗
- Golden inference API fixtures: test the contract rather than prose↗
- SSE property tests: one event stream under any byte partition↗
- Differential API testing across two inference engines↗
- Open and closed load models for an inference API↗
- A bounded cancellation soak test for request and connection leaks↗
- Local fault injection: interrupting an upstream at a known stream boundary↗
- Seeds and fingerprints: testing an API reproducibility claim↗
- A token-budgeted synthetic probe for an inference endpoint↗
- Changing an inference API contract: deprecation and migration checks↗
- vLLM chat templates: fix string versus OpenAI content formats↗
- Match prompt token IDs between Hugging Face and vLLM↗
- Why generation_config.json changes vLLM generation defaults↗
- vLLM stop strings and EOS: diagnose premature response endings↗
- Migrate vLLM structured-output backends without schema regressions↗
- Align vLLM tool parsers, chat templates and tool-result messages↗
- Validate reasoning and answer boundaries in vLLM parser output↗
- Validate a draft and target model pair for vLLM speculative decoding↗
- Evaluate vLLM n-gram speculation without a draft model↗
- Tune vLLM chunked prefill token budgets for mixed traffic↗
- Bound vLLM request queues and prefill token backlogs↗
- Manage vLLM torch.compile caches across releases↗
- Detect vLLM CUDA Graph mode fallbacks after upgrades↗
- Choose vLLM safetensors loading strategies for local disks and NFS↗
- Validate vLLM sleep and wake readiness transitions↗
- Validate target-specific EAGLE draft checkpoints in SGLang↗
- Diagnose tokenizer and detokenizer worker bottlenecks in SGLang↗
- Tune SGLang schedule conservativeness for output-length uncertainty↗
- Compare SGLang Radix eviction policies under hot-set churn↗
- Diagnose KV transfer stalls in SGLang prefill-decode disaggregation↗
- Validate FP8 and FP4 GEMM backends against SGLang checkpoints↗
- Why temperature zero is not enough for deterministic SGLang output↗
- Separate multimodal encoder data parallelism from SGLang language-model TP↗
- Correlate SGLang request latency across workers with OpenTelemetry↗
- Gate SGLang readiness on actual checkpoint-engine weights↗
- Make llama.cpp automatic fit settings reproducible↗
- Reconcile llama.cpp unified KV pools and per-slot context limits↗
- Manage resident models and eviction in the llama.cpp router↗
- Validate JSON Schema to GBNF conversion in llama.cpp↗
- Validate llama.cpp slot prompt-cache save and restore files↗
- Tune llama.cpp CPU threads separately for prefill and decode↗
- Build llama.cpp CUDA binaries for multiple GPU architectures↗
- Verify split GGUF shards before merging a llama.cpp model↗
- Validate llama.cpp language-model and mmproj projector pairs↗
- Use llama-bench to isolate prefill and generation regressions↗
- Handle final completion correctly in Triton decoupled streaming↗
- Identify which scheduler owns batching in Triton and TensorRT-LLM↗
- Define variable-length token input contracts for Triton ragged batching↗
- Verify Triton generation cancellation beyond a client disconnect↗
- Migrate legacy Triton TensorRT-LLM engine builds to the LLM API↗
- Check TensorRT engine portability across GPUs and runtime versions↗
- Coordinate Triton model reloads, control modes and version policies↗
- Validate tokenizer, inference and postprocessing contracts in Triton ensembles↗
- Separate Triton queue, input, inference and output latency↗
- Validate ModelOpt quantized checkpoint scales and export provenance↗
- Prepare a complete pinned Hugging Face snapshot for offline serving↗
- Pin and review custom model code before enabling trust_remote_code↗
- Validate safetensors weight artifacts separately from repository code↗
- Keep tokenizer vocabulary, special tokens and chat templates in one release↗
- Validate vLLM automatic and explicitly pinned attention backends↗
- Container stalls without OOM: reading memory.high and memory.events↗
- Idle GPU, throttled CPU: diagnosing container CPU quota↗
- Cannot create thread in a container: checking pids.max and pids.events↗
- Out of /dev/shm: setting a GPU container IPC budget↗
- OOMKilled or Evicted: identifying why a Pod stopped↗
- High latency at moderate utilization: diagnosing Linux PSI↗
- Too many open files in a container: finding the exhausted limit↗
- Container blocked on stdout: Docker log backpressure and rotation↗
- Why docker stop cannot stop a worker: PID 1, signals and zombies↗
- Host swap exists but the container cannot use it: checking limits↗
- Pod restarts while loading: configuring a startup probe↗
- preStop consumes the grace period: budgeting Pod termination↗
- kubectl drain blocked by a PDB: what a disruption budget protects↗
- GPU Deployment rollout stuck: maxSurge without spare capacity↗
- Pod is Terminating but still receives traffic: checking EndpointSlices↗
- ImagePullBackOff before GPU startup: image names, registry and Secrets↗
- Init container downloads an artifact again: making preparation idempotent↗
- Resource stuck Terminating: diagnosing a Kubernetes finalizer↗
- Node NotReady but the Pod does not move: tolerations and eviction↗
- No shell in the image: debugging a Pod with an ephemeral container↗
- NVIDIA_VISIBLE_DEVICES vs CUDA_VISIBLE_DEVICES: why GPU indexes differ↗
- CDI device not found: checking NVIDIA device names and specifications↗
- NVML Unknown Error after daemon-reload: when a container loses its GPU↗
- nvidia-smi works but CUDA does not: checking compute and utility capabilities↗
- Slow DNS in a Pod: search domains and ndots↗
- Some DNS queries fail: why TCP and UDP port 53 both matter↗
- Ping works but transfers stall: recognizing an MTU black hole↗
- New connections disappear: checking Linux conntrack pressure↗
- Server returns the wrong certificate: SNI, SAN and the default virtual host↗
- HTTPS works on the host but not in the container: CA trust and certificate chains↗
- Wrong time after restart: TLS errors and misleading log chronology↗
- Prometheus relabel_configs vs metric_relabel_configs: where to filter data↗
- Prometheus remote_write falls behind: WAL, queues and shards↗
- OpenTelemetry Collector drops data during backend outages: queues and limits↗
- Telemetry never reaches the Collector: OTLP gRPC, HTTP and endpoints↗
- A metric disappeared from the graph: staleness, up and zero values↗
- Head vs tail sampling: why a trace splits across Collectors↗
- Alerts keep disappearing: for, pending and keep_firing_for↗
- Rate metrics jump after restart: counter resets and rate before sum↗
- kubectl logs --previous is not enough: Pod log rotation and collection↗
- Deployment rollback starts the new image: the mutable tag problem↗
- The digest matches, but whom do you trust: verifying container image signatures↗
- ConfigMap changed but the process sees old values: env, volumes and subPath↗
- Secret updated but credentials are still old: file rotation and reloading↗
- ServiceAccount token expired: audiences and projected token rotation↗
- GPU works as root but not in a rootless container: runtime and device permissions↗
- Operation not permitted in a GPU container: checking seccomp↗
- Pod stays unready after deny-all: init container network dependencies↗
- No matching manifest or exec format error: checking container image platforms↗
- Read-only container will not start: where to allow temporary and cache writes↗
- Qwen3-30B-A3B Instruct vs Thinking: choose by task↗
- Qwen3-4B-Thinking-2507 for math: verify answers and failure cases↗
- Qwen3-4B-Instruct-2507 for text classification↗
- Qwen3-Coder-Next vs 30B-A3B for repository work↗
- Qwen3-Coder 480B vs 30B: when to escalate a coding task↗
- Qwen3-Coder-Next after a failed test: evaluate recovery↗
- Qwen2.5-Coder FIM vs chat: choose the right checkpoint and prompt↗
- Qwen3-Next vs Qwen3-32B for long text instructions↗
- Qwen3-Next Gated DeltaNet: what changes for text inference↗
- Qwen3-Next Thinking vs Instruct: separate checkpoints and answer budgets↗
- Qwen3.6 preserve_thinking for iterative code changes↗
- Qwen3.6-27B vs 35B-A3B for text coding tasks↗
- Qwen3.8 reasoning_effort: test deeper reasoning on text tasks↗
- Qwen3.8 FP8 vs original weights: validate coding quality↗
- Qwen3-Coder-Next vs Qwen3.6: specialist or general model for code↗
- DeepSeek-V3.2 vs Speciale: reasoning tasks and tool-use limits↗
- DeepSeek-V3.2 thinking with tools: preserve the right history↗
- DeepSeek-V4 Flash vs Pro: choose by coding and reasoning task↗
- DeepSeek-V4 Max effort: compare reasoning with a fair budget↗
- DeepSeek-V4.1-Flash-1017: validate a coding-model upgrade↗
- DeepSeek-V4.1 prompt encoding: local text messages and effort↗
- GLM-4.7-Flash vs Qwen3-30B-A3B for coding and tools↗
- GLM-4.7 preserved thinking and turn-level control↗
- GLM-5 vs GLM-4.7 for long-horizon engineering tasks↗
- GLM-5.2 vs GLM-5.3: what changes when the base model stays the same↗
- GLM-5.3 thinking controls: API policy and local checkpoint behavior↗
- GLM-5.2 long context: test repository dependency reasoning↗
- Kimi K2 Thinking vs Instruct-0905 for text tasks↗
- Kimi K2 Thinking INT4: native QAT and unpacked weights differ↗
- Kimi K3 KDA and Attention Residuals: a text-model architecture guide↗
- Kimi K3 vs K2 Thinking for long coding sessions↗
- MiniMax-M2.5 for code repair: judge tests and patch quality↗
- MiniMax-M2.5 tool errors: evaluate argument repair and stopping↗
- MiniMax-M2.5 vs GLM-4.7 for repository maintenance↗
- Devstral 2 vs Small 2 for multi-file code changes↗
- Devstral 2 vs Qwen3-Coder-Next: compare patch workflows↗
- Devstral Small 2: a deprecated API and downloadable weights↗
- Ministral 3 Instruct vs Reasoning for short text and math↗
- Ministral 3 3B, 8B or 14B for bounded text tasks↗
- Mistral Small 4 reasoning_effort: none vs high↗
- Mistral Small 4 vs Devstral 2 for mixed text and code work↗
- Mistral Small 4 NVFP4 vs original checkpoint: test task quality↗
- Ministral 3 vs Gemma 4: reasoning history rules differ↗
- Gemma 4 26B-A4B vs 31B for text coding tasks↗
- Moving from Gemma 3 to Gemma 4: system roles and text prompts↗
- Gemma 4 thinking mode and empty thought blocks↗
- Gemma 4 QAT unquantized vs GGUF: choose the right artifact↗
- Gemma 4 vs Qwen3.6 for Russian and English text instructions↗
- Granite 4.0 Hybrid vs Granite 4.2 Dense: identify the model first↗
- Granite 4.2 full, low-effort and non-thinking modes↗
- Granite 4.2 in Russian: test beyond the published language list↗
- Nemotron 3 Nano thinking budget: understand the actual mechanism↗
- Nemotron 3 Nano vs Qwen3-Next: different hybrid text models↗
- Nemotron 3 Super vs Nano: choose by reasoning task↗
- SmolLM3 /think vs /no_think for small text tasks↗
- Best local LLM for coding in 2026: choose by the task↗
- LFM2.5 vs LFM2 for narrow text tasks: respect the task boundary↗
- BitNet b1.58 vs four-bit PTQ: native training and runtime matter↗
- Falcon-H1: evaluate a parallel attention and SSM text model↗
- Olmo 3 Think vs Instruct: choose a task and a model-flow checkpoint↗
- LM Studio: start a local desktop assistant↗
- LM Studio vs Ollama: choose a local coding workflow↗
- Use the LM Studio local API from an editor↗
- llmster: local AI without the LM Studio desktop window↗
- Jan vs LM Studio: choose a local desktop assistant↗
- Jan Desktop: a first local project and model source↗
- Jan Agent with a local model: a first reviewed edit↗
- Open WebUI with Ollama: connect an existing local runtime↗
- Open WebUI with vLLM: backend models and workspace wrappers↗
- Open WebUI vs AnythingLLM vs LibreChat for local AI↗
- Open WebUI Desktop or server UI: choose the local workflow↗
- LibreChat with local models: build a first reusable agent↗
- AnythingLLM Desktop: built-in inference or a local server↗
- AnythingLLM Desktop vs server: personal and shared workspaces↗
- Continue vs Cline vs Aider for local coding↗
- Continue with a local model: chat and autocomplete roles↗
- Cline with LM Studio or Ollama: a reviewed local edit↗
- Cline Desktop vs IDE extension for local models↗
- Aider with local models: make and review a repository edit↗
- OpenCode custom provider: local model configuration in V2↗
- OpenHands Agent Canvas: local workspace, backend and model↗
- Zed with a local model: start the native agent workflow↗
- goose with a local model: validate a first project task↗
- Cherry Studio: local chat providers versus helper models↗
- Dify with a local LLM: connect a provider and build an app↗
- n8n with a local LLM: a bounded chat-model workflow↗
- Flowise with Ollama: build and test a local Chatflow↗
- Langflow with a local model: a first conversational flow↗
- n8n vs Dify vs Flowise vs Langflow for local AI workflows↗
- Choose a local AI stack: desktop chat, shared UI or coding agent↗
- Local coding assistants: first read, edit, review and test↗
- LM Studio chat works but an editor cannot use the model↗
- Jan server will not start: check the local startup model↗
- Open WebUI model is visible to admin but not another user↗
- Open WebUI Tools, Functions and Pipes: choose an extension↗
- LibreChat MCP connects but the agent has no tool↗
- LibreChat Code Interpreter: execute code and retrieve files↗
- AnythingLLM Desktop MCP tools do not start or get called↗
- Continue chat works but autocomplete does not appear↗
- Undo Cline edits: checkpoints, Git history and side effects↗
- Aider commits and undo with existing repository changes↗
- Aider repo map versus files added for editing↗
- OpenCode V2 responds but a tool is denied↗
- OpenCode V1 to V2: keep a local coding workflow↗
- OpenHands Canvas cannot find project files: locate the backend workspace↗
- Zed native or ACP agent: which settings apply?↗
- Roo Code is retired: preserve a local workflow before migrating↗
- goose connects to a model but a local extension is unavailable↗
- LM Studio presets do not restore model load settings↗
- Jan Agent fork and rewind: history versus file restoration↗
- Jan Agent safe mode and shell sandbox are different controls↗
- Export Open WebUI chats and workspace items with the right scope↗
- Open WebUI prompt variables: reusable task forms↗
- Share a LibreChat agent without assuming tools share access↗
- Continue project rules and current configuration↗
- Aider architect and editor roles with local models↗
- OpenHands repository skills: migrate older instruction examples↗
- Zed Agent Profiles: availability is not tool approval↗
- goose recipes: repeat a local task with explicit inputs↗
- Cherry Studio backup versus archive: what is restored?↗
- Qdrant RRF versus DBSF: choose fusion with a held-out query set↗
- Qdrant filtered HNSW: payload indexes are part of the search plan↗
- ColBERT in Qdrant: preserve token vectors and MaxSim semantics↗
- Qdrant document grouping: stop one document from filling every result↗
- pgvector halfvec indexing: retain full vectors for final scoring↗
- pgvector binary quantization: Hamming candidates need full-vector reranking↗
- pgvector cosine and inner product: normalization and ORDER BY must agree↗
- Milvus BM25 functions: combine server-generated sparse and dense retrieval↗
- Milvus consistency: why a newly inserted document is not yet found↗
- Milvus partition keys: tenant routing is not an authorization policy↗
- Weaviate hybrid fusion: alpha and score gaps change different decisions↗
- Weaviate filtered search: compare sweeping, ACORN and PathSeer↗
- Weaviate BM25F: rank titles and body text without filtering evidence away↗
- Elasticsearch hybrid search: RRF versus normalized linear retrieval↗
- OpenSearch hybrid search: normalization and score-ranker pipelines↗
- LanceDB phrase search: preserve positions before hybrid retrieval↗
- RAG chunking strategies: document structure versus fixed token windows↗
- Late chunking for RAG: embed context before pooling fragments↗
- RAG chunk overlap: measure lost boundaries and duplicated evidence↗
- Chunk tables for RAG without losing column headers and units↗
- EmbeddingGemma retrieval: query and document prompts must stay distinct↗
- Jina embeddings v4: dense and multi-vector outputs are different index contracts↗
- Nemotron 3.5 Embed: evaluate text and page-image retrieval together↗
- ColPali document search: migrate to Sentence Transformers without changing scores↗
- ColPali similarity maps: model focus is not an OCR citation box↗
- BEIR qrels: an unjudged passage is not a verified negative↗
- MTEB and MMTEB: choose tasks before ranking embedding models↗
- Ragas context precision, recall and faithfulness measure different failures↗
- Synthetic RAG test sets: keep document leakage out of the holdout↗
- RAG noise sensitivity: test distractors without changing the answer target↗
- RAG citations: measure support and completeness separately↗
- Matryoshka embeddings: truncate and normalize both sides consistently↗
- Nemotron 3.5 Rerank: interpret scores before choosing a relevance threshold↗
- PDF to Markdown for RAG: fix reading order before indexing↗
- Extract PDF tables for RAG: merged cells and repeated headers↗
- Unstructured PDF parsing: fast, hi_res and ocr_only solve different inputs↗
- PyMuPDF text extraction: a text layer does not guarantee reading order↗
- Mixed PDF OCR: avoid duplicating an existing text layer↗
- PDF citations: keep page coordinates correct after rotation and cropping↗
- Documents to Markdown or JSON: preserve evidence provenance for RAG↗
- Excel to RAG: formulas, cached values and merged cells need explicit rules↗
- Web pages for RAG: remove navigation without losing source evidence↗
- Search meeting recordings: preserve speaker turns and audio evidence↗
- WhisperX alignment gaps: numbers and symbols may lack word timestamps↗
- pyannote diarization: speaker turns, overlap and identity are different outputs↗
- Silero VAD before ASR: sample rate and speech boundaries must agree↗
- faster-whisper batching: check VAD defaults before comparing transcripts↗
- WER and CER for speech recognition: normalize text without hiding errors↗
- Transcript cleanup: punctuation must not break word-time alignment↗
- Speech to subtitles: validate SRT and WebVTT cue boundaries↗
- Video retrieval timestamps: use PTS rather than frame-number arithmetic↗
- Index video keyframes: scene detection versus fixed-rate sampling↗
- Local video search: join transcript evidence with visual keyframes↗
- Russian keyword retrieval: stemming must not destroy exact identifiers↗
- Elasticsearch passage retrieval: nested kNN and supporting inner hits↗
- Neural sparse search in OpenSearch: token weights are not ordinary BM25↗
- Qdrant sparse IDF: corpus changes can alter query scoring↗
- Milvus text matching versus BM25: filtering is not relevance ranking↗
- Update RAG documents without leaving stale chunks and citations↗
- ColBERT PLAID: index compression and candidate pruning are separate checks↗
- LMCache vs vLLM prefix caching: choose the cache boundary↗
- LMCache CPU offload: size a reusable KV working set↗
- Persistent KV cache invalidation: when a prefix stops being reusable↗
- CacheBlend for RAG: reuse document chunks beyond an exact prefix↗
- FP8 KV cache: precision, calibration and long-context quality↗
- NVIDIA Dynamo vs vLLM: orchestration and inference are different layers↗
- Dynamo KV-aware routing: balance cached context against queueing↗
- Dynamo KVBM: budget GPU, host and storage tiers separately↗
- vLLM prefill-decode disaggregation: when separate pools help↗
- NIXL vs NCCL: KV movement and collective communication↗
- LMCache vs Mooncake: compare the component, not just the project↗
- RoCE vs InfiniBand for LLM serving: qualify the full fabric↗
- Expert parallel vs tensor parallel for MoE inference↗
- Data parallel vs tensor parallel: replicas or a split model?↗
- FlashAttention vs PagedAttention: different attention problems↗
- FlashInfer vs FlashAttention: compare the actual kernel path↗
- CUDA Graphs vs torch.compile: replay and compilation can coexist↗
- LLM goodput vs tokens per second: count requests meeting the objective↗
- SGLang HiCache vs RadixAttention: a hierarchy around prefix reuse↗
- Gateway API Inference Extension vs ordinary load balancing↗
Economics
- GPU inference economics: what to calculate before joining a pool↗
- Power and cooling: the overlooked conditions of GPU operation↗
- What should a report on your GPU’s operation contain?↗
- GPU rental or revenue sharing: which terms should you discuss?↗
- Keep your GPU on site or move it to a data center?↗
- KV cache and GPU economics: accounting for active-request memory↗
- Validating model demand before expanding a GPU pool↗
- Planning a GPU pool: when is the next server actually needed?↗
- Energy per LLM request: measuring without false precision↗
- GPU Server Electricity Costs: Reconcile an Actual Bill↗
- Calculate the Cost of Making Your GPU Available↗
- GPU Idle Reports: Separate Waiting, Outages and Reservations↗
- Reconcile a Hosting Invoice with GPU Telemetry↗
- Fixed and Variable GPU Costs: A Working Worksheet↗
- Compare Remote Hands Costs for Your GPU Server↗
- Allocate Shared Host Costs Between Two GPUs↗
GPU funding
- Funding a GPU pool: from an idea to a defined project↗
- Working capital for LLM inference: what happens after buying GPUs?↗
- How to assess a GPU pool project before funding it↗
- Milestone GPU funding: paying for the next verifiable step↗
- Buying or renting GPUs: what to compare before funding↗
- Inference unit economics: choosing the unit a funding partner needs↗
- GPU-pool budgeting: allocating funds between hardware and operations↗
- Reporting to a GPU-pool funding partner↗
- Risks to discuss before funding GPU inference↗
- Procuring GPUs for a pool: specification and acceptance before scaling↗
- Demand before GPUs: evidence to gather before purchasing↗
- Questions to ask a GPU-pool team at the first meeting↗
- Discussing future compute demand and capacity reservations↗
- The GPU asset lifecycle: planning beyond the purchase↗
- Growing a GPU pool when additional machines are actually needed↗
- Funding a research compute window↗
- A GPU maintenance budget: planning beyond startup↗
- A short GPU-partner brief: equipment, task and budget↗
- A GPU-pilot spending limit: knowing when to decide again↗
- Funding an existing GPU or buying a new one: where to start↗
- Build a Payment Calendar for a GPU Pilot↗
- Record an Equipment Contribution to a GPU Pilot↗
- GPU Server Spare Parts: Build a Justified Reserve↗
- Report Unspent GPU Pilot Funding and Commitments↗
- Track Vendor Quote Validity in a GPU Purchase Budget↗
Cloud providers
- Runpod for LLMs: when to choose Pods or Serverless↗
- AWS for LLM inference: evaluating GPUs in Amazon EC2↗
- Hetzner for LLMs: evaluating a dedicated GPU server↗
- Vast.ai GPUs: evaluating marketplace offers↗
- Lambda Cloud: planning a GPU virtual-machine pilot↗
- CoreWeave inference: choose the management layer first↗
- DigitalOcean and Paperspace: distinguish the GPU products↗
- Google Cloud GPU: regions and quotas before model launch↗
- Azure GPUs for LLMs: selecting a compute VM series↗
- OVHcloud GPUs: distinguishing cloud instances from other services↗
- Scaleway GPUs: from a prepared image to a repeatable pilot↗
- Nebius AI Cloud: planning growth from a VM to a GPU pool↗
- Fluidstack: evaluating large-scale AI infrastructure↗
- Vultr Cloud GPU: checking plan, region and image↗
- Oracle Cloud GPUs: VMs and bare metal for an owned model↗
- Crusoe Cloud: infrastructure or managed inference?↗
- Latitude.sh for LLMs: evaluating Metal GPU↗
- Hyperstack: GPU VM costs begin with the resource lifecycle↗
- TensorDock: evaluating GPU VMs across a host network↗
- CUDO Compute in 2026: current services and older instructions↗
- Five GPU clouds for a first pilot: building a shortlist↗
- Four providers for European GPU deployment↗
- Dedicated GPUs for LLMs: four different purchasing formats↗
- Four serverless approaches to GPU inference↗
- Runpod or Vast.ai: compare the task, not one price↗
- AWS, Google Cloud or Azure: comparing GPUs for LLMs↗
- Hetzner, OVHcloud and Scaleway: comparing GPU infrastructure↗
- Specialist GPU cloud or hyperscaler: choosing the right product↗
- Five providers for small GPU teams: choose by the work involved↗
- A GPU-provider shortlist: a method for verifiable selection↗
- Runpod persistent storage: keep files after deleting a Pod↗
- Runpod storage types: container disk, volume disk and network volume↗
- Runpod storage pricing: what remains billable after Stop↗
- Runpod SSH keys: prepare credentials and choose a connection↗
- Runpod SSH not working: diagnose one connection layer at a time↗
- Runpod SSH port forwarding for a private local service↗
- Jupyter on Runpod: where to save notebooks and results↗
- Expose a Pod HTTP service through Runpod Proxy↗
- Runpod Community and Secure Cloud: storage and access boundaries↗
- What to save before terminating a Runpod Pod↗
- Vast.ai Stop and Destroy: instance and data lifecycles↗
- Reading Vast.ai storage and bandwidth charges↗
- Reading Vast.ai host metrics before renting a GPU↗
- Vast.ai SSH and Jupyter: choose the right access template↗
- Vast.ai on-demand, reserved and interruptible instances↗
- Moving data between Vast.ai instances↗
- Vast.ai templates: ports, environment variables and repeatable launches↗
- Hetzner GPU VPS searches and dedicated GEX servers↗
- Recovering SSH access to a Hetzner GPU server with Rescue↗
- Hetzner GPU pricing: include setup fees in a short pilot↗
- Hetzner GPU server auction: verify the actual listing↗
- Hourly or monthly GPU rental: compare the full working period↗
- Runpod pricing calculator: build a useful input worksheet↗
- Google Cloud GPU quota: checks before requesting an increase↗
- Google Cloud GPU capacity errors despite available quota↗
- AWS GPU quotas: instance families and regional vCPU limits↗
- GPU EC2 terminated: check the EBS volumes left behind↗
- Preparing a GPU workload for AWS Spot interruptions↗
- Azure GPU quota: regional totals and VM family limits↗
- Azure GPU VM Stopped or Deallocated: which costs remain↗
- Starting a GPU project on Selectel: resource and access options↗
- JupyterLab on Selectel GPU: access and saved notebooks↗
- Configuring a Yandex Cloud GPU VM↗
- Yandex Cloud GPU clusters: when InfiniBand matters↗
- Preparing a Yandex Cloud GPU quota request↗
- Yandex Cloud preemptible GPU VMs: disks and restart plans↗
- Deploying a GPU VM on Cloud.ru Evolution↗
- Cloud.ru Advanced or Evolution GPU: compare the actual platforms↗
- SberCloud GPU and Cloud.ru: updating older instructions↗
- VK Cloud GPU: full devices, vGPU profiles and first checks↗
- Timeweb Cloud GPU: checks before your first deployment↗
- Servercore GPU: server format, location and billing checks↗
- Accessing Jupyter on a cloud GPU through an SSH tunnel↗
- Runpod S3 storage: a network-volume API, with specific limits↗
- GPU powered off, public IP retained: audit the network resource↗
- Resizing a cloud GPU VM without losing data↗
- Moving a GPU VM to another region: what must move separately↗
- Ephemeral and persistent disks on GPU VMs: a deletion checklist↗
- GPU cloud team access: API keys and SSH keys have different jobs↗
- Ending a GPU pilot: finding resources that still incur charges↗
- ComfyUI in the cloud: keeping models, workflows and outputs↗
CPU, GPU and RAM
- CPU or GPU hosting: which resource does your AI task need?↗
- Memory-optimized hosting: when more system RAM is useful↗
- RAM and VRAM: which memory matters for an AI server?↗
- Compute-optimized hosting: when the processor is the constraint↗
- Storage-optimized hosting: when disks constrain an AI system↗
- Arm and x86 inference: comparing CPU architectures↗
- GPU hosting, GPU servers and model APIs: what are you renting?↗
- When to test CPU LLM inference before buying a GPU↗
- LLM memory bandwidth: why gigabytes are not enough↗
- NVMe for model serving: where a faster disk changes results↗
- NUMA in GPU servers: why resource placement matters↗
- PCIe and GPU hosting: when the connection limits a model↗
- Spot or on-demand GPUs: accounting for interruptions↗
- Reserved GPUs and flexible capacity: what are you committing to?↗
- Serverless GPUs or an always-ready replica: choosing an inference mode↗
- A hybrid CPU/GPU architecture: splitting an AI service by task↗
- A high-RAM RAG server: deciding what to keep in memory↗
- Vector-database memory: choosing RAM and storage for retrieval↗
- RAM for AI data preparation: avoiding paid-for idle memory↗
- GPUs in Kubernetes: scheduling CPU, RAM and accelerators together↗
- GPU containers or virtual machines: what to check before deployment↗
- MIG and time-slicing: sharing a GPU without confusing guarantees↗
- Serving LoRA adapters: estimating GPU-server capacity↗
- GPU hosting for multimodal models: count more than text↗
- Hosting batch inference: using GPUs on a schedule↗
- GPU autoscaling: a free card is not a ready replica↗
- AI service network traffic: accounting for egress before GPU placement↗
- CPU hosting for RAG: four options for a technical comparison↗
- Memory-optimized hosting: four high-RAM options to compare↗
- LLM hosting architectures: five arrangements for different tasks↗
- A local RAG server: placing components around the GPU↗
- Qdrant for RAG: deciding what belongs in RAM or on disk↗
- PostgreSQL and pgvector for RAG on an existing server↗
- Hosting Chroma: local persistence and server mode↗
- FAISS server memory: an index library versus a database service↗
- Embedding dimensions: calculating index memory↗
- Choosing GPU memory for Whisper transcription↗
- Whisper on CPU or GPU: comparing completion time and cost↗
- OCR on CPU or GPU: where acceleration changes the pipeline↗
- ComfyUI GPU requirements depend on the entire workflow↗
- ComfyUI offloading: when moving data to RAM helps↗
- Stable Diffusion GPU requirements: resolution, batch and weights↗
- LoRA and QLoRA: understanding fine-tuning memory↗
- A 128 GB RAM server for LLMs: useful roles beyond VRAM↗
- 256 GB RAM for RAG: when the index justifies the capacity↗
- GPU ECC: volatile and aggregate error counters↗
- GPU row remapping: pending state, remapped rows and spares↗
- GPU Xid errors: reconstructing an incident timeline↗
- Xid 79: evidence to retain when a GPU falls off the bus↗
- GPU clock reductions: reading simultaneous event reasons↗
- GPU P-states and bursty inference requests↗
- BAR1 and VRAM: why GPU memory readings differ↗
- GPU resets and telemetry counter epochs↗
- DCGM active diagnostics and passive health history↗
- DCGM diagnostic JSON: Pass, Fail, Skip and schema versions↗
- GPU PCIe links: negotiated speed, width and maximum capability↗
- A GPU topology matrix: device proximity and actual measurements↗
- GPU peer access: checking each pair and direction↗
- First touch and NUMA: locating GPU host buffers↗
- Pinned GPU host memory: setting a page-locked buffer budget↗
- CUDA: verifying copy and compute overlap↗
- CUDA events and request time: different measurement boundaries↗
- NVLink errors: counter deltas and hardware generations↗
- Resizable BAR: inventorying resources without changing BIOS↗
- GPU, NVMe and NIC contention on a shared PCIe path↗
- NVMe Percentage Used: SSD endurance and the metric boundary↗
- NVMe unsafe shutdowns and media errors mean different things↗
- NVMe temperature and variable model-loading time↗
- Model caches and SSD endurance: downloads, host writes and NAND↗
- LLM loading: read-latency tails beyond one SSD speed↗
- fio buffered and direct reads measure different paths↗
- OS page cache and cold model loading: what to record↗
- RAID1 for models: disk availability and version recovery↗
- Host RAM ECC and EDAC: separate from GPU memory errors↗
- PCIe AER near a GPU: severity, requester and chronology↗
- GPU, CPU and server energy: where measurement boundaries lie↗
- GPU power bursts and sparse sampling↗
- GPU power caps: an energy and latency experiment↗
- Dual PSUs: accounting for A/B inputs and redundancy↗
- UPS runtime for a GPU node: a recovery-time budget↗
- Inlet, GPU and memory temperatures: different sensors↗
- Server fans: why speed percentages are not watts↗
- Aligning energy-meter readings with a GPU test window↗
- GPU benchmarks: median, spread and trial order↗
- GPU benchmark confidence intervals: what counts as an observation↗
- GPU drivers: a controlled comparison of two versions↗
- GPU VBIOS and InfoROM: different baseline fields↗
- OAM accelerator modules and their system boundary↗
- Display-attached GPUs: the VRAM baseline before model loading↗
- GPU-server RAM: equal capacity and different DIMM channel layouts↗
- GPU N+1 capacity: measuring maintenance headroom on a workload↗
- NVMe Available Spare is not filesystem free space↗
- Heterogeneous GPUs in one report: aggregating benchmark results↗
- AMD SMI in a mixed GPU fleet: units and metric support↗
- Intel xpu-smi: telemetry does not prove LLM-service readiness↗
- NVIDIA GeForce RTX 5090 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 5080 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 5070 Ti for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 5070 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 5060 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 5050 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 5060 Ti for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 5090 D for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 5090 D v2 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 4090 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 4080 SUPER for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 4080 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 4070 Ti SUPER for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 4070 Ti for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 4070 SUPER for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 4060 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 4070 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 4060 Ti for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 4090 D for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 3090 Ti for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 3090 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 3080 Ti for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 3070 Ti for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 3070 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 3080 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 3060 Ti for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 3060 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 3050 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 2080 Ti for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 2080 SUPER for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 2080 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 2070 SUPER for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 2070 for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 2060 SUPER for LLM inference and GPU rendering↗
- NVIDIA GeForce RTX 2060 for LLM inference and GPU rendering↗
- NVIDIA TITAN RTX for LLM inference and GPU rendering↗
- NVIDIA TITAN V for LLM inference and GPU rendering↗
- NVIDIA TITAN Xp for LLM inference and GPU rendering↗
- NVIDIA TITAN X Pascal for LLM inference and GPU rendering↗
- NVIDIA GeForce GTX 1660 Ti for LLM inference and GPU rendering↗
- NVIDIA GeForce GTX 1660 SUPER for LLM inference and GPU rendering↗
- NVIDIA GeForce GTX 1660 for LLM inference and GPU rendering↗
- NVIDIA GeForce GTX 16 4 GB family for LLM inference and GPU rendering↗
- NVIDIA GeForce GTX 1080 Ti for LLM inference and GPU rendering↗
- NVIDIA GeForce GTX 1080 for LLM inference and GPU rendering↗
- NVIDIA GeForce GTX 1070 Ti for LLM inference and GPU rendering↗
- NVIDIA GeForce GTX 1070 for LLM inference and GPU rendering↗
- NVIDIA GeForce GTX 1060 for LLM inference and GPU rendering↗
- NVIDIA RTX PRO 6000 Blackwell Workstation Edition: 96GB in a single tower↗
- NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition: 96GB at a 300W board limit↗
- NVIDIA RTX PRO 6000 Blackwell Server Edition: air and liquid server integration↗
- NVIDIA RTX PRO 5500 Blackwell Workstation Edition: 84GB and preliminary specifications↗
- NVIDIA RTX PRO 5000 Blackwell: 48GB and72GB are separate variants↗
- NVIDIA RTX PRO 4500 Blackwell Workstation Edition: the 200W active workstation board↗
- NVIDIA RTX PRO 4500 Blackwell Server Edition: 32GB in a passive single-slot server card↗
- NVIDIA RTX PRO 4000 Blackwell: 24GB in a full-height single slot↗
- NVIDIA RTX PRO 4000 Blackwell SFF Edition: 24GB for low-profile systems↗
- NVIDIA RTX PRO 2000 Blackwell: 16GB inference and compact rendering↗
- NVIDIA RTX 6000 Ada Generation: 48GB without assuming Ampere A6000 equivalence↗
- NVIDIA RTX 5880 Ada Generation: identify the 48GB Ada SKU↗
- NVIDIA RTX 5000 Ada Generation: 32GB and engine compatibility↗
- NVIDIA RTX 4500 Ada Generation: 24GB for a mixed workstation↗
- NVIDIA RTX 4000 Ada Generation: 20GB in a full-height single slot↗
- NVIDIA RTX 4000 SFF Ada Generation: 20GB under a 70W board limit↗
- NVIDIA RTX 2000 Ada Generation: 16GB in a compact render worker↗
- NVIDIA A800 40GB Active: inference compute and rendering caveats↗
- NVIDIA RTX A6000: 48GB and explicit multi-GPU memory↗
- NVIDIA RTX A5500: 24GB without an Ada name collision↗
- NVIDIA RTX A5000: a 24GB Ampere baseline↗
- NVIDIA RTX A4500: 20GB and bounded context↗
- NVIDIA RTX A4000: 16GB in one full-height slot↗
- NVIDIA RTX A2000: 6GB versus12GB in one model family↗
- NVIDIA RTX A1000: 8GB in a 50W compact board↗
- NVIDIA RTX A400: 4GB sets the workload boundary↗
- NVIDIA T400, T600 and T1000: small-model inference and rendering limits↗
- NVIDIA Quadro RTX 8000: 48GB and the active board identity↗
- NVIDIA Quadro RTX 6000: 24GB before the Ada and Blackwell names↗
- NVIDIA Quadro RTX 5000: 16GB on the original Turing5000↗
- NVIDIA Quadro RTX 4000: 8GB in the original single-slot RTX↗
- NVIDIA Quadro RTX 8000 Passive PCIe Server Card: the passive250W server edition↗
- NVIDIA Quadro RTX 6000 Passive PCIe Server Card: the passive250W server edition↗
- NVIDIA Quadro GV100: 32GB Volta needs a pinned stack↗
- NVIDIA Quadro GP100: 16GB HBM2 without modern vLLM support↗
- NVIDIA Quadro P6000: 24GB capacity with legacy compilation↗
- NVIDIA Quadro P5000: 16GB Pascal for bounded reuse↗
- NVIDIA Quadro P4000: 8GB and the 105W single-slot board↗
- NVIDIA Quadro P400, P600, P620, P1000, P2000 and P2200: 2GB to5GB legacy workload boundaries↗
- NVIDIA Quadro M6000: 12GB and24GB on a retained legacy stack↗
- NVIDIA Quadro M5000: 8GB with a Maxwell compatibility ceiling↗
- NVIDIA Quadro M4000: 8GB in a legacy single slot↗
- Radeon RX 9070 XT: 16 GB RDNA 4 deployment boundaries↗
- Radeon RX 9070: 16 GB capacity and a 220 W board↗
- Radeon RX 9070 GRE: verify 12 GB before model sizing↗
- Radeon RX 9060 XT: 8 GB versus 16 GB for inference↗
- Radeon RX 9060 XT LP: the 140 W product and chassis checks↗
- Radeon RX 9060: the non-XT 8 GB deployment case↗
- Radeon RX 9050: 4 GB and 8 GB small-model limits↗
- Radeon RX 7900 XTX: 24 GB on one GPU↗
- Radeon RX 7900 XT: planning around 20 GB↗
- Radeon RX 7900 GRE: a separate 16 GB GRE target↗
- Radeon RX 7800 XT: a repeatable 16 GB workstation↗
- Radeon RX 7700 XT: 12 GB and the non-XT naming trap↗
- Radeon RX 7700: identify the official 16 GB non-XT SKU↗
- Radeon RX 7650 GRE: regional SKU and software support checks↗
- Radeon RX 7600 XT: 16 GB does not establish ROCm support↗
- Radeon RX 7600: an exact 8 GB ROCm SKU↗
- Radeon RX 7400: an 8 GB low-board-power candidate↗
- Radeon RX 6950 XT: 16 GB with a 335 W reference envelope↗
- Radeon RX 6900 XT: reuse an existing 16 GB flagship carefully↗
- Radeon RX 6800 XT: consumer RX versus PRO software boundaries↗
- Radeon RX 6800: 16 GB without the XT or PRO assumptions↗
- Radeon RX 6750 XT: 12 GB for a measured offload layout↗
- Radeon RX 6700 XT: validate a 12 GB RDNA 2 node↗
- Radeon RX 6700: the non-XT 10 GB capacity boundary↗
- Radeon RX 6650 XT: an 8 GB refresh needs its own test↗
- Radeon RX 6600 XT: an 8 GB backend qualification checklist↗
- Radeon RX 6600: selective offload on an 8 GB card↗
- Radeon RX 6400: 4 GB and host-transfer constraints↗
- Radeon RX 6750 GRE: 10 GB versus 12 GB official variants↗
- Radeon RX 6500 XT: 4 GB and 8 GB under tight memory budgets↗
- Radeon RX 5700: an existing 8 GB RDNA 1 workstation↗
- Radeon RX 5600 XT: a practical 6 GB allocation test↗
- Radeon RX 5600: identify the 6 GB non-XT OEM card↗
- Radeon RX 5500: the 4 GB OEM model is a separate SKU↗
- Radeon RX 5300: what the 3 GB OEM boundary means↗
- Radeon RX 5700 XT: standard and Anniversary board limits↗
- Radeon RX 5500 XT: official 4 GB and 8 GB configurations↗
- Radeon VII: 16 GB HBM2 with legacy software boundaries↗
- Radeon RX Vega 64: an 8 GB legacy assessment↗
- Radeon RX Vega 56: an 8 GB legacy assessment↗
- Radeon Vega Frontier Edition: air versus liquid and real physical VRAM↗
- Radeon AI PRO R9700: 32 GB in an active-cooled workstation↗
- Radeon AI PRO R9700S: 32 GB passive cooling needs a qualified host↗
- Radeon AI PRO R9600: 32 GB on the 150 W single-slot product↗
- Radeon AI PRO R9600D: a passive 150 W host qualification↗
- Radeon PRO W7900: 48 GB standard versus Dual Slot↗
- Radeon PRO W7800: 32 GB versus 48 GB model and scene budgets↗
- Radeon PRO W7700: 16 GB with an exact workstation support entry↗
- Radeon PRO W7600: professional drivers do not establish LLM support↗
- Radeon PRO W7500: 8 GB on a 70 W workstation board↗
- Radeon PRO W7400: verify the 8 GB 55 W product↗
- Radeon PRO W6800: the specifically listed 32 GB RDNA 2 workstation↗
- Radeon PRO W6600: an 8 GB workstation and its 130 W specification↗
- Radeon PRO W6400: the 4 GB workstation boundary↗
- Radeon PRO W5700: 8 GB on an existing RDNA workstation↗
- Radeon PRO W5500: an 8 GB 125 W workstation test↗
- Radeon PRO VII: PRO VII is distinct from consumer Radeon VII↗
- Radeon PRO WX 9100: 16 GB with a versioned legacy specification↗
- Radeon PRO WX 8200: 8 GB HBM2 and current backend limits↗
- Radeon PRO V710: 28 GB and server or guest visibility↗
- Radeon PRO V620: 32 GB board memory versus guest allocation↗
- Radeon PRO V520: 8 GB HBM2 on a virtualization-oriented board↗
- Radeon PRO V340: dual-GPU board total is not unified VRAM↗
- NVIDIA L40S: LLM inference and server rendering boundaries↗
- NVIDIA L40: LLM inference and server rendering boundaries↗
- NVIDIA L4: LLM inference and server rendering boundaries↗
- NVIDIA L20: LLM inference and server rendering boundaries↗
- NVIDIA A40: LLM inference and server rendering boundaries↗
- NVIDIA A10: LLM inference and server rendering boundaries↗
- NVIDIA A16: LLM inference and server rendering boundaries↗
- NVIDIA A2: LLM inference and server rendering boundaries↗
- NVIDIA A30: LLM inference and server rendering boundaries↗
- NVIDIA A100: LLM inference and server rendering boundaries↗
- NVIDIA A800: LLM inference and server rendering boundaries↗
- NVIDIA H100: LLM inference and server rendering boundaries↗
- NVIDIA H200: LLM inference and server rendering boundaries↗
- NVIDIA H800: LLM inference and server rendering boundaries↗
- NVIDIA H20: LLM inference and server rendering boundaries↗
- NVIDIA B200: LLM inference and server rendering boundaries↗
- NVIDIA B300: LLM inference and server rendering boundaries↗
- NVIDIA Rubin GPU: LLM inference and server rendering boundaries↗
- NVIDIA Tesla V100: LLM inference and server rendering boundaries↗
- NVIDIA Tesla V100S: LLM inference and server rendering boundaries↗
- NVIDIA Tesla P100: LLM inference and server rendering boundaries↗
- NVIDIA Tesla P40: LLM inference and server rendering boundaries↗
- NVIDIA Tesla P4: LLM inference and server rendering boundaries↗
- NVIDIA Tesla T4: LLM inference and server rendering boundaries↗
- NVIDIA Tesla M40: LLM inference and server rendering boundaries↗
- NVIDIA Tesla M60: LLM inference and server rendering boundaries↗
- NVIDIA Tesla M10: LLM inference and server rendering boundaries↗
- NVIDIA Tesla M6 and P6: LLM inference and server rendering boundaries↗
- NVIDIA GeForce GTX 980 Ti: LLM inference and server rendering boundaries↗
- NVIDIA GeForce GTX TITAN X Maxwell: LLM inference and server rendering boundaries↗
- AMD Instinct MI100: LLM inference and server rendering boundaries↗
- AMD Instinct MI210: LLM inference and server rendering boundaries↗
- AMD Instinct MI250 and MI250X: LLM inference and server rendering boundaries↗
- AMD Instinct MI300X: LLM inference and server rendering boundaries↗
- AMD Instinct MI300A: LLM inference and server rendering boundaries↗
- AMD Instinct MI325X: LLM inference and server rendering boundaries↗
- AMD Instinct MI350P: LLM inference and server rendering boundaries↗
- AMD Instinct MI350X and MI355X: LLM inference and server rendering boundaries↗
- AMD Instinct MI455X: LLM inference and server rendering boundaries↗
- AMD Instinct MI430X: LLM inference and server rendering boundaries↗
- AMD Instinct MI50 and MI60: LLM inference and server rendering boundaries↗
- GPU compatibility for LLM inference and Cycles rendering↗
- GPU VRAM, board totals and shared memory: how to read specifications↗
- Desktop GPU, workstation or server accelerator: qualify the host↗
- Legacy GPUs for LLMs and rendering: experimental versus supported↗
- Sharing GPUs between LLM inference and server rendering↗
- NVIDIA and AMD GPU catalogue for LLM inference and server rendering↗
LLM routing
- OpenRouter: model access and its role for a GPU pool↗
- OpenRouter provider routing: defining permitted routes↗
- Requesty: a managed LLM gateway for routing and team access↗
- Portkey and Prisma AIRS AI Gateway: functions and product boundaries↗
- LiteLLM Proxy: when to operate your own model gateway↗
- Vercel AI Gateway: common model access for an application↗
- Cloudflare AI Gateway: routes, observability and unified billing↗
- Kong AI Gateway: LLM traffic within API infrastructure↗
- Helicone AI Gateway: routing with observability↗
- Amazon Bedrock: model access within AWS infrastructure↗
- Vertex AI Model Garden: reading the current Google Cloud catalog↗
- Azure AI Foundry and Microsoft Foundry Models: choosing execution↗
- Together AI: serverless and dedicated inference for open models↗
- Fireworks AI: comparing serverless and deployments↗
- Hugging Face Inference Providers: models, routes and billing↗
- Five managed LLM routing platforms: choosing by task↗
- Four self-hosted AI gateways: LiteLLM, Portkey, Kong and Agent Router↗
- OpenRouter or Requesty: comparing managed LLM access↗
- OpenRouter and Portkey: catalog access or AI-traffic governance↗
- OpenRouter or LiteLLM: managed access and an owned gateway↗
- Vercel and Cloudflare AI Gateway: comparing managed gateways↗
- Bedrock, Vertex Model Garden and Foundry: cloud approaches compared↗
- Together, Fireworks and OpenRouter: comparing inference roles↗
- BYOK or managed billing: who pays for the model request?↗
- Model routing and provider routing: two different decisions↗
- The full cost of an LLM router: beyond token prices↗
- Reconciling tokens and billing in an LLM router↗
- Comparing LLM-router data policies↗
- LLM-router fallback and limits: testing resilience↗
- Choosing a token-sales channel for an owned GPU pool↗
- Setting up an OpenRouter API key for an application↗
- OpenRouter base URL: configuring a compatible client↗
- Your first verifiable OpenRouter request in Python↗
- Calling OpenRouter from Node.js without exposing the key↗
- Reading an OpenRouter streaming response incrementally↗
- Structured output through OpenRouter: when to use a JSON schema↗
- Tool calling through OpenRouter: the model proposes, your app executes↗
- OpenRouter error 429: limits, queues and controlled retries↗
- OpenRouter error 403: what to check before switching models↗
- OpenRouter error 404: API address, model ID or route↗
- OpenRouter error 500: building a useful failure report↗
- OpenRouter error 401: checking credentials and the runtime↗
- OpenRouter error 402: credit balance and request limits↗
- Free model limits on OpenRouter: planning a bounded test↗
- OpenRouter free model router: checking which model answered↗
- Free OpenRouter API keys: what is free and what costs money↗
- OpenRouter BYOK pricing: separating the parts of the bill↗
- OpenRouter BYOK not working: credentials, region and fallback↗
- OpenRouter provider routing: the difference between only and order↗
- OpenRouter prompt caching: verifying savings in usage data↗
- OpenRouter usage: reconciling tokens and request cost↗
- Fetching the OpenRouter model catalog before deployment↗
- Errors inside an OpenRouter stream: why HTTP 200 is insufficient↗
- OpenRouter Zero Data Retention: restricting eligible routes↗
- OpenRouter fallback with a price cap: limiting backup routes↗
- Starting a LiteLLM gateway with Docker Compose↗
- LiteLLM virtual keys: separate access for each application↗
- LiteLLM budgets: periods, shared limits and overrun tests↗
- LiteLLM guardrails: choosing where to inspect requests and responses↗
- Preparing LiteLLM UI for model and key management↗
- DLP at an AI gateway: reducing sensitive data exposure↗
- An inference API conformance matrix for providers↗
- Unsupported inference parameters: rejection, ignoring and the contract↗
- Absent fields, null and empty strings in an inference API↗
- finish_reason as a provider response state machine↗
- Streaming tool calls: assembling arguments by index and ID↗
- The final usage frame: validating a streaming response contract↗
- Why prompt_tokens differs from tokenizing the visible text↗
- Output limits and reasoning tokens: the length-termination contract↗
- Provider content parts: validating structure before generation↗
- Provider structured output: testing JSON and schema conformance separately↗
- The logprobs contract: aligning tokens and returned scores↗
Retrospectives: Models and modalities
- Large4 weights: why the October29 checkpoint is not merely the preview download↗
- Mistral Large 4 (Le Chonk) is now open weight: additional post-training after a preview↗
- Nemotron Transcribe and Granaryv2: a speech model plus its adaptation path↗
- Nemotron3.5 Transcribe and Granaryv2: prompted vocabulary and faithful transcription↗
- LFM3: why one backbone produced several modality contracts↗
- Introducing LFM3: decision outputs versus generated answers↗
- Terra 6.1 and the economics of repeated visual actions↗
- What the Terra factuality claim leaves for application tests↗
- Kimi K3.1 Pro: product rollout and the still-future weight promise↗
- BoltE4B: Gemma lineage inside the Nemotron release family↗
- K3.1 Pro Series is live: thinking-only access and client migration↗
- NVIDIA Nemotron3.5 Bolt E4B 4GB: base-model lineage and post-trained behavior↗
- Nemotron3.5 retrieval launch: three stages of the evidence pipeline↗
- Granite Speech5: transcription,TurboCTC and attribution are separate release roles↗
- Granite Speech5.0: CTC decoding and speech-language generation↗
- Granite Speech5.0: keyword biasing and unsupported terms↗
- Voxtral3: a family release, not one monolithic speech model↗
- MiniMax M3.1Flash: what the SpaceBunny reveal established and what remained pending↗
- Timestral: why covariates are not chat context↗
- Nemotron SuperVL: the October expansion from text execution to visual agents↗
- Nemotron 3.5 SuperVL: visual documents versus video tasks↗
- Nemotron 3.5 SuperVL: customization and retained acceptance tests↗
- Grok Voice 3.0: Support-call resolution is different from fluent speech↗
- Grok Voice 3.0: Low audio latency does not guarantee good turn-taking↗
- Argon GA made the continuation protocol an integration decision↗
- LFM2.5-24B-A2B: the final LFM2.5 release and its changed reasoning contract↗
- LFM2.5-24B-A2B: reasoning-only responses and structured clients↗
- LFM2.5-24B-A2B: tokenizer expansion and migration fixtures↗
- Wonder and Wonder Full launched through different access paths↗
- Open d1: why a decision model is a different interface from a chat model↗
- Open d1: decision probabilities and application policy↗
- Open d1: encoder and decoder decision backbones↗
- Mistral Large4 preview: what was public on October6↗
- Introducing Mistral Large 4: preview access and defensive evaluation↗
- d1 vision launch: hosted decisions before open weights↗
- Introducing d1: versioning a hosted decision question↗
- Introducing d1: visual conditions versus text-only labels↗
- Introducing d1: uncertain decisions before the open-weight drop↗
- Long output capacity does not define a completed project↗
- What a one-week model replacement means for evaluation cadence↗
- Why the Sol 6.1 cache discount is not a task-cost estimate↗
- Sol 6.1 and the new middle tier for repository work↗
- How image generation separated steering from retraining↗
- Sonnet 5.5 split the middle-tier question between office work and code↗
- A new Sonnet default should not silently rewrite the baseline↗
- Effort allocation matters inside the Sonnet 5.5 tier↗
- Vision DSpark: why faster decoding does not remove image-processing cost↗
- Voice design turned a preset into a control surface↗
- Line-level direction can change the meaning of dialogue↗
- Flash TTS and Flash-Lite need workload-specific acceptance↗
- A reusable voice is an artifact with provenance↗
- Why Sol and Luna changed the economics of task allocation↗
- Image input did not turn Sol and Luna into image generators↗
- What cached context changed in the Sol and Luna decision↗
- Harness-native training raises a transfer question↗
- Grok 4.7: The same token rate can buy a different amount of work↗
- Grok 4.7: A larger base model is not a complete architecture disclosure↗
- Qwen Image2.1: transparent generation meets unified editing↗
- Qwen-Image-2.1: native transparency and ordinary RGB output↗
- Grok Transcribe 2.0: Noisy-audio gains need workload slices rather than one WER↗
- Grok Transcribe 2.0: A wrong spoken identifier can outweigh fluent transcription↗
- Live and Extended Thinking solve different latency choices↗
- DeepSeek V4.1 Flash: why the September release changed more than a model name↗
- Images 2.5 and the problem of preserving edits across turns↗
- Flare and Sunburst need different creative acceptance checks↗
- Image provenance is not a reliable model-selector label↗
- Sketches and comments made image intent more explicit↗
- The controls Astra removed, and what a migration must preserve↗
- What the Astra launch can and cannot prove about a workflow↗
- Spark 1.3 shows how API and coding-product feedback meet↗
- Max reasoning in Spark 1.3 is a configuration to evaluate↗
- Fable 5.1 made thinking history a compatibility boundary↗
- One frontier release, two access surfaces↗
- Agentic video replaced uniform sampling with evidence seeking↗
- When the transcript and frame describe different events↗
- Qwen3.8Next report: the state that active-parameter counts omit↗
- Scene extension turns continuity into a reviewable constraint↗
- First and last frames do not specify the entire transition↗
- A resolution option is not a native-detail guarantee↗
- Cheap video previews need a deliberate final-artifact handoff↗
- Smart transcription changes the boundary of a quotation↗
- Live and recorded transcription are different contracts↗
- Custom vocabulary needs an audio-backed correction test↗
- Speaker labels and word times carry different uncertainty↗
- GLM5.3 Flash: why the name hides a different base architecture↗
- GLM-5.3-Flash: native visual input and model lineage↗
- Granite4.2: why family naming is insufficient to infer architecture↗
- Pipette: the August shift from model scores to deployed-system measurements↗
- LFM2.5 DSpark release: why the drafter is a separate deployment artifact↗
- Agentic Search: what changed from retrieval to inspect-and-verify loops↗
- LFM2.5 QAD: a quantized release produced by training, not just conversion↗
- LFM2.5 Q4_0: trained quantization and artifact provenance↗
- LFM2.5 Q4_0: teacher comparisons and local acceptance↗
- LFM2.5 Q4_0: quantized migration and exact identifiers↗
- GLM5.3: a new post-training milestone on an existing base↗
- Qwen3.8-27B: reconstructing a release distinct from Max-class weights↗
- GLM-5.3: same base and changed post-training↗
- Qwen3.8-27B reasoning budgets: when more output stops helping the task↗
- Qwen3.8-27B checkpoints: keep official weights and conversions distinct↗
- Flash 3.7 turned developer feedback into a short release cycle↗
- UI generation gains still need reference fidelity checks↗
- MiniMax Music3: why the August event was a weight release,not its first API↗
- MiniMax Music3: why a text prompt still needs an audio inference contract↗
- MiniMax Music3 weights: separating artifact access from model terms↗
- Interactive artifacts need behavior checks beyond screenshots↗
- The Grok 4.6 model and its coding harness are separate evidence↗
- LFM2.5-VL-3B: what changed for edge visual document tasks in August↗
- LFM2.5-VL-3B: visual processors as release artifacts↗
- LFM2.5-VL-3B: OCR questions and visual evidence↗
- LFM2.5-VL-3B: text lineage and visual capability↗
- Lightning and Switchyard: why the August launch contains two different building blocks↗
- Grok Image 2.0: checking typography beyond visual quality↗
- Grok Image 2.0: which reference details an edit must preserve↗
- Grok Image 2.0: what the Quality Mode label establishes↗
- LFM2.5-2.6B: reconstructing the local-agent release from primary dates↗
- Qwen3.8 Max: separate the August3 announcement from subsequent weights↗
- Qwen3.8-Max: hosted vision and downloadable text weights↗
Retrospectives: Agents and software
- Persistent Carbon work needs honest blocker handling↗
- Why better visual reasoning still needs screen-state verification↗
- Clearer Terra writing changes the human review interface↗
- K3.1 Pro Series is live: session transitions across model generations↗
- NVIDIA Nemotron3.5 Bolt E4B 4GB: speech-ready output and tool arguments↗
- Why a bounded answer needed a different API↗
- Typed decisions do not establish the right rejection policy↗
- More questions per request change failure coupling↗
- Decisions and GPT-Live separate dialogue from action selection↗
- Google Agent Compute Engine: Why the model server and the agent’s computer need different lifecycles↗
- Google Agent Compute Engine: Pausing an agent is a state problem before it is a density claim↗
- Google Agent Compute Engine: Keeping secrets outside a sandbox changes the failure boundary↗
- Duet made attention selection part of the agent product↗
- Background Duet work needs evidence-bearing completion signals↗
- Connected business actions require explicit transaction intent↗
- Granite Speech5.0: speaker attribution beyond word accuracy↗
- Voxtral 3: separate speech stages in a voice agent↗
- Voxtral 3: interruptions and end-of-turn decisions↗
- Nemotron 3.5 SuperVL: execution and orchestration roles↗
- How AI writing created the verification bottleneck behind Deep Review↗
- Why the claim became the right unit for document review↗
- How Earth AI showed why a language model needs specialized spatial tools↗
- Why planetary data belongs in a workspace beyond the context window↗
- How upfront planning became a measurable part of geospatial agents↗
- Active Focus still needs a stopping rule↗
- Active Memory raises the question of evidence freshness↗
- Haiku 5.5 subagents need smaller contracts, not vague delegation↗
- Cheap summaries still spend an omission budget↗
- Haiku 5.5 browser use makes action composition visible↗
- How agent privacy moved from secret storage to appropriate information flow↗
- Why delegated agent work needs delegated authority limits↗
- How confirmation fatigue became a design problem for AI agents↗
- Code migration claims need semantic equivalence evidence↗
- CoreWeave Forge: Why a GPU cloud added the improvement loop above raw capacity↗
- CoreWeave Forge: Production observations are not automatically training data↗
- CoreWeave Forge: A connected evaluation loop still needs a release decision↗
- CoreWeave Forge: Portable improvement data and portable execution are different promises↗
- Sol 6.1 multi-agent beta: delegation is another execution contract↗
- From API tools to a browser: what changed on DevDay↗
- The application still owns the browser sign-in boundary↗
- What a browser-agent replay must preserve↗
- When a hosted browser is justified beside direct tools↗
- Dots changed a task into an ongoing responsibility↗
- A dot can learn a preference without gaining authority↗
- A personal cloud computer is an operational boundary↗
- How to review work that happened between conversations↗
- Business connectors make record consistency part of agent work↗
- A business goal needs smaller observable action units↗
- Connected context is not automatically the business source of truth↗
- Faster Sonnet feedback changes the iteration budget↗
- Team Bots: Shared expertise does not mean shared private conversations↗
- Team Bots: A shared bot needs explicit credential ownership↗
- Team Bots: A team bot's learned role needs a correction path↗
- An expressive avatar can conceal unfinished backend work↗
- A visual persona needs a state handoff during tool delays↗
- An escalation policy after the Sol and Luna launch↗
- Shorter Opus reports need a different review test↗
- Action screening and model safeguards are different layers↗
- Qwen3.8Omni report: from understanding media to executing media tasks↗
- Qwen3.8-Omni: media understanding and task execution↗
- Longer Grok work needs verification that survives retries↗
- Qwen-Image-2.1: reference-image editing and identity↗
- Grok Build Memory: Project memory must distinguish conventions from temporary state↗
- Grok Build Memory: Background memory notes need an inspectable review surface↗
- Grok Build Memory: A correct memory note can become wrong after a repository change↗
- Parallel reasoning changes what waiting sounds like↗
- A spoken correction can invalidate pending tool work↗
- Live visual grounding still has a context-age problem↗
- The Agents API moved the harness into the service boundary↗
- A durable agent session is more than a saved chat↗
- Hosted and self-hosted environments after the Agents API beta↗
- Why agent API success still needs a task acceptance artifact↗
- Full duplex changed the voice-agent state machine↗
- Backend delegation separates conversation from slow reasoning↗
- Interruption quality needs a conversation fixture↗
- Why Muse's dedicated computer changed the personal-agent boundary↗
- A personal goal does not define every background permission↗
- The gap between Spark's model capability and Muse's useful work↗
- Why Astra made the API contract part of the model upgrade↗
- Astra and the shift from answering to completing long work↗
- Spark 1.3 and the challenge of several workflows in one thread↗
- Long-horizon software work needs intermediate checkpoints↗
- Why the Fable 5.1 forced-tool change matters to orchestration↗
- Shared Cowork memory changed the handoff between conversation and work↗
- Editable topics made memory an inspectable product object↗
- Global memory and project evidence should remain distinguishable↗
- Memory defaults change what a continuation can assume↗
- Granite4.2 brings native reasoning to enterprise agents: native reasoning and enterprise parsers↗
- Introducing Agentic Search: search navigation versus answer generation↗
- Introducing Agentic Search: document revisions in agentic navigation↗
- Introducing Agentic Search: retrieval turns as a stopping problem↗
- Grok Build: A generated app becomes a different object when published↗
- The Grok Build name does not identify one runtime↗
- Grok Build: Mobile creation needs a deliberate review handoff↗
- Grok 4.6 and the difference between sustained work and long chat↗
- Grok Bot moved from a workflow run to a persistent teammate↗
- A cloud computer changes what survives a user handoff↗
- Approval interrupts are part of the task protocol↗
- NVIDIA Nemotron3.5 Lightning and NeMo Switchyard: routing library and specialist model↗
- NVIDIA Nemotron3.5 Lightning and NeMo Switchyard: distillation lineage and task specialization↗
- NVIDIA Nemotron3.5 Lightning and NeMo Switchyard: specialists inside long-running workflows↗
- LFM2.5-2.6B: reasoning traces in persistent local agents↗
- LFM2.5-2.6B: tool completion versus fluent planning↗
- Introducing Shieldstral: policy questions as versioned inputs↗
Retrospectives: Compute and infrastructure
- Why input-token price stopped being the whole routing decision↗
- What the new OpenRouter router leaves under caller control↗
- How routing signals change the incentive to add reliable capacity↗
- Meta Helios testing versus a six-gigawatt agreement↗
- Why Meta’s AMD milestone spans ROCm, CPUs, and networking↗
- Day-zero support is not the end of infrastructure validation↗
- Installed, tested and accepted are separate Helios milestones↗
- Why a GPU cloud’s backbone matters for model and dataset movement↗
- A network point of presence is not a new GPU region↗
- Backbone encryption and the remaining trust boundaries of an AI cloud↗
- Moving model artifacts and serving tokens need different network evidence↗
- ECS moves from whole-GPU assignment to shared scheduling↗
- ECS MPS limits versus isolation: different questions↗
- Why managed MPS daemon recovery changes operational ownership↗
- Shared GPU service adds a daemon lifecycle to the task lifecycle↗
- An OCI TPU announcement is not an allocatable TPU region↗
- Why bringing an accelerator to the data differs from connecting two clouds↗
- TPU software portability and datacenter readiness run on different clocks↗
- Multiple accelerators in one cloud do not eliminate workload qualification↗
- CoreWeave Denmark: Why most of 22.5 MW is not the same as all of 22.5 MW↗
- CoreWeave Denmark: A colocation operator and a GPU cloud deliver different parts of capacity↗
- CoreWeave Denmark: A heat-reuse agreement is not a per-token energy measurement↗
- CoreWeave Denmark: A local GPU site and a global backbone solve different placement problems↗
- LFM3 announcement versus runtime support: what shipped together↗
- Why a learning model needs a version boundary in serving↗
- SGLang isolation disclosure: when a rejected request still crossed a handoff↗
- SGLang isolation disclosure: configured context is not processable capacity↗
- SGLang cache lifetime: what a transfer acknowledgment must actually prove↗
- NVIDIA Nemotron3.5 Bolt E4B 4GB: memory branding and actual session state↗
- Why AI cloud trust spans keys, support access, and runtime↗
- Confidential compute: announced extension versus deployed coverage↗
- How to read a zero-trust framework without turning it into a guarantee↗
- Support access and runtime trust are separate zero-trust layers↗
- From Confidential G4 preview to a documented GA boundary↗
- Why attestation belongs before release of model secrets↗
- Thirty-six zones are not thirty-six independent cloud regions↗
- Confidential G4 and Confidential Space had different rollout states↗
- A live-network AI-RAN call does not mean a nationwide deployment↗
- Radio processing and edge inference share hardware but not deadlines↗
- New ARC configurations complicate the meaning of network edge↗
- Why telecom land, power and fiber are only the first AI layer↗
- Humming: why a unified quantization format still needs a device-specific kernel↗
- vLLM Humming: why shared quantization still needs specialized kernels↗
- vLLM Humming benchmarks: from a fast kernel to a complete request↗
- Why llm-d 1.0 was an operations milestone as well as a serving release↗
- Cache locality and tenant fairness can pull a router in different directions↗
- Why prefill and decode upgrades need a shared lifecycle↗
- TorchTPU changes the unit of TPU model porting↗
- Eager debugging and compiled serving answer different TPU questions↗
- Why an out-of-tree TPU plugin can preserve the vLLM control plane↗
- Open-source TPU support makes compatibility inspectable, not automatic↗
- DeepInfer release: why an open inference engine is not a complete service↗
- vLLM TorchTPU: model-code reuse is not kernel portability↗
- DeepInfer initial public commit: offline inference and service completeness↗
- vLLM TorchTPU startup: compilation is a different phase from serving↗
- vLLM TorchTPU compatibility: a common API still needs a feature matrix↗
- The Indiana SMR announcement was a feasibility gate, not delivered power↗
- Why a second SMR site tests a deployment model as well as a reactor↗
- Amazon Indiana: A former coal site offers infrastructure context, not automatic nuclear approval↗
- Amazon Indiana: Development funding and electricity offtake play different roles↗
- Grok Voice 3.0: A voice-model upgrade needs an audio regression artifact↗
- Private endpoint visibility is a different boundary from retention↗
- Reserved inference capacity and optional public overflow↗
- Why Private Endpoints did not become arbitrary self-hosted model ingestion↗
- Why technical review became an asynchronous AI workload↗
- LFM2.5-24B-A2B: active experts and weight residency↗
- Helion and the separation of agent execution from model inference↗
- Why Helion includes an enterprise CPU/GPU configuration↗
- Helion: open specification, partner design, and availability are separate milestones↗
- A CPU-only agent rack changes what an AI capacity count means↗
- A 240-MW India plan is not current GPU availability↗
- Indonesia before India: the sequencing of CoreWeave’s Asia expansion↗
- Why a future India campus was announced around Rubin-class infrastructure↗
- Three planned buildings do not establish one India delivery date↗
- Open d1: portable weights and browser execution↗
- An uprate adds output without being a new reactor↗
- An AI power purchase agreement spans a longer clock than a GPU refresh↗
- Preserving nuclear output and adding nuclear output are different quantities↗
- Grid-scale nuclear supply does not describe a datacenter’s instantaneous mix↗
- Why agent observability needs its own privacy boundary↗
- A smaller Spark configuration changes capacity choice before compute identity↗
- Two Spark systems add distributed capacity, not one local memory bus↗
- Why the Spark post date and partner shipping date differ↗
- Local inference capacity does not make an entire agent workflow offline↗
- Why moving computation does not settle the privacy question↗
- Micron: A 512 GB RDIMM sample is a server-qualification milestone↗
- Micron: Shipping an SSD for KV cache does not make storage behave like HBM↗
- Micron: Memory supply needs a ledger of samples, qualification and shipments↗
- Micron: A growing AI memory business does not identify an application’s bottleneck↗
- One graphics image reduces the GPU-generation image matrix↗
- Cross-family UpdateFleet changes the migration unit↗
- Image portability does not certify every graphics application↗
- How diffusion control changed what an inference interface should describe↗
- LFM2.5-VL-DSpark: visual preprocessing and decode acceleration↗
- LFM2.5-VL-DSpark: a visual drafter and its target contract↗
- LFM2.5-VL-DSpark: visual context and draft acceptance↗
- Batch pricing trades immediacy for scheduling flexibility↗
- Why a batch has one provider even on a multi-provider gateway↗
- Seven-minute beta medians and a 24-hour completion window↗
- vllm-metal: why concurrent serving changed the Mac-inference question↗
- vllm-metal unified memory: why concurrent inference needs headroom↗
- vllm-metal attention: the boundary between reused layers and request state↗
- Why model-server state matters more than connection counts↗
- The HyperPod launch did not make global routing generally available↗
- Three dates behind the HyperPod Inference Gateway announcement↗
- From a Rubin roadmap to a multi-rack cluster↗
- Why object-storage changes accompanied CoreWeave’s Rubin cluster↗
- Cluster bring-up versus readiness for a specific inference workload↗
- Why multi-rack Rubin bring-up makes failure boundaries a system question↗
- A Blackwell desktop bundle is not a general GPU instance↗
- What 32 GB per GPU changes for a remote graphics project↗
- AlwaysOn and AutoStop belong in the workstation migration decision↗
- Why NUMA topology became part of managed Slurm placement↗
- MIG partitions became scheduler resources in AWS PCS↗
- Custom GRES as an escape hatch from automatic hardware discovery↗
- Introducing DeepSeek-V4.1-Flash: input and output execution roles↗
- Introducing DeepSeek-V4.1-Flash: native vision and historical cache comparisons↗
- Residency starts at gateway decryption, not only at the GPU↗
- Why regional inference can fail with an otherwise valid model↗
- A model’s country of origin is not its inference location↗
- Why the Finland expansion combined nuclear, wind and storage↗
- Keeping a nuclear plant online is different from adding a new plant↗
- A hypothetical siting model is not a realized electricity-price result↗
- Demand-response exploration does not make every inference job interruptible↗
- CUDA 13.4: Functional Rubin preview is not a blanket production-support claim↗
- CUDA 13.4: MPS management controls and MIG isolation remain different mechanisms↗
- CUDA 13.4: Separating driver packaging makes an implicit dependency explicit↗
- CUDA 13.4: Windows on Arm adds an operating-system axis to CUDA qualification↗
- CUDA Rust offers a language choice and a separate programming-model choice↗
- What Rust ownership catches at a GPU launch boundary↗
- Why NVIDIA called its Rust GPU tracks early-stage↗
- Tile abstraction trades explicit thread control for compiler responsibility↗
- How AlphaGenome Atlas moved inference from request time to publication time↗
- Why a predictive atlas must version its data with its model↗
- Why sharper weather forecasts change the serving workload↗
- HUMAIN: live compute is a different milestone from a gigawatt plan↗
- Why HUMAIN’s GPU-as-a-service announcement includes its network fabric↗
- Sovereign AI moves from investment language to operating responsibility↗
- Sovereign AI capacity needs an operational boundary beyond location↗
- On the Design of Qwen3.8-Next Architecture: off-accelerator n-gram tables↗
- Why confidential evaluation must protect both models and questions↗
- How attestation changed the evidence behind an AI benchmark↗
- Moving the memory controller changes more than a memory specification↗
- Custom XPU choice still depends on memory qualification↗
- HBM power is not whole-inference energy↗
- Why custom accelerators can share a rack architecture without becoming identical↗
- Two million planned GPUs are a delivery window, not an inventory snapshot↗
- Why AI capacity announcements cannot be added without checking overlap↗
- A heterogeneous GPU roadmap needs common infrastructure as well as chips↗
- A hyperscaler’s deployment plan does not reserve capacity for an application↗
- GLM-5.3-Flash: hybrid attention and serving assumptions↗
- Granite4.2 brings native reasoning to enterprise agents: dense models after hybrid predecessors↗
- Groq 3 LPX separates token-generation specialization from general compute↗
- Full production hardware is not the same milestone as a public API↗
- Fast token generation does not determine the whole agent loop↗
- Why the LPX benchmark needs its model and context denominator↗
- Introducing Pipette: context-dependent edge rankings↗
- Introducing Pipette: runtime revisions as benchmark variables↗
- Introducing Pipette: thermal state and reproducible edge tests↗
- LFM2.5-DSpark: draft storage versus verification savings↗
- LFM2.5-DSpark: distribution preservation and integration correctness↗
- LFM2.5-DSpark: target revisions and draft compatibility↗
- SK hynix FMS: Why FMS framed AI memory as placement across tiers↗
- SK hynix FMS: An HBF roadmap is not evidence of deployable HBF servers↗
- SK hynix FMS: CXL expansion adds a placement option, not equivalent local memory↗
- SK hynix FMS: A broad memory portfolio still needs software to manage state↗
- CoreWeave Indonesia: Contracted Indonesian power and live GPU supply are different ledgers↗
- CoreWeave Indonesia: A new AI region needs an operations team as well as equipment↗
- CoreWeave Indonesia: Locality benefits require a local service path, not just a facility address↗
- CoreWeave Indonesia: A 2028 facility plan must remain flexible across accelerator generations↗
- SpecForge: the August separation of target and trainer lifecycles↗
- SpecForge disaggregation: captured features need an ownership lifecycle↗
- SpecForge consistency gates: a small correctness check before a large run↗
- Qwen3.8-Max: active parameters and full checkpoint movement↗
Retrospectives: Research and science
- Carbon's cyber evidence spans different task boundaries↗
- Nemotron3.5 Transcribe and Granaryv2: held-out speakers and adaptation claims↗
- Nemotron3.5 Transcribe and Granaryv2: open data workflow and reproducibility↗
- Why the sleep framework makes memory a lifecycle problem↗
- How forgetting became the real test of continual learning↗
- How retrieval and weight updates reached different memory roles↗
- How forest AI moved from counting trees to understanding land use↗
- Why forest mapping needed better labels as much as finer pixels↗
- How changing forest maps exposed the need for temporal comparability↗
- Nemotron3.5 Embed,Rerank and Parse: page-image evidence in dense retrieval↗
- Nemotron3.5 Embed,Rerank and Parse: reranking and missing candidates↗
- Nemotron3.5 Embed,Rerank and Parse: document parsing before embeddings↗
- DeepInfer initial public commit: initial commit versus repository creation↗
- MiniMax M3.1Flash: anonymous preview and named-model evidence↗
- Introducing Timestral: known-future inputs and leakage↗
- Introducing Timestral: probabilistic forecasts and point answers↗
- Introducing Timestral: chronological holdouts after the release↗
- Why geospatial agents still need a boundary for expert review↗
- Public engineering artifacts make launch claims more inspectable↗
- High-volume Haiku traffic needs failure slices, not one average↗
- How better AI-assisted work became a different question from better skills↗
- Why seniority changes the learning question around AI assistance↗
- How unaided transfer tests became essential for evaluating AI tools↗
- Introducing Mistral Large 4: benchmark claims before reproducible artifacts↗
- How reporting delays made location embeddings useful for health research↗
- Why cross-border health modelling needs geographic transfer tests↗
- How place embeddings sharpened the distinction between prediction and cause↗
- How federated learning reached the demand for verifiable trust↗
- How device participation became part of learning quality↗
- Why privacy guarantees must survive the whole training workflow↗
- Internal agent examples do not establish external reproducibility↗
- How SynthID Bio moved provenance beyond a digital file↗
- Why generated science made database provenance urgent↗
- How watermarking became one layer of scientific trust↗
- Why controllable images require more than a single reward score↗
- Lip sync and semantic agreement are separate checks↗
- vLLM watermarking: a provenance signal is not a truth score↗
- vLLM watermark detection: keys, tokenizers and the generation contract↗
- vLLM watermark statistics: why searching many keys changes the conclusion↗
- The conditions behind Opus 5.5 cost-per-task comparisons↗
- Qwen3.8-Omni: what a technical report establishes about weight availability↗
- Why AlphaGenome Atlas needs explanations alongside rankings↗
- How a model became a shared scientific reference with AlphaGenome Atlas↗
- How WeatherNext 3 made observation freshness part of model design↗
- How weather AI reached the decision problem beyond average accuracy↗
- Why learned weather models still need physical consistency checks↗
- Not finding an event is not proof it never happened↗
- On the Design of Qwen3.8-Next Architecture: architecture ablations and deployment conclusions↗
- How hidden tests became an infrastructure problem for AI evaluation↗
- Why double-blind execution cannot repair a weak benchmark↗
- GLM-5.3-Flash: anonymous feedback before a named release↗
- Granite4.2 brings native reasoning to enterprise agents: multi-stage post-training and causal attribution↗
- GLM-5.3: defensive capability and evaluation scope↗
- Better knowledge work requires more than a polished artifact↗
- Shieldstral: the August move from fixed labels to policy questions↗
- Introducing Shieldstral: content policy versus provenance detection↗
Retrospectives: Industry and governance
- How digitizing planning records prepared the way for PlanAssist↗
- Why PlanAssist separates assessment time from planning outcomes↗
- How local policy became the scaling test for public-sector AI↗
- Large4 open weights: the published model-as-a-service license boundary↗
- Mistral Large 4 (Le Chonk) is now open weight: internal use and model-as-a-service↗
- Carbon shortened the evaluation window after Argon GA↗
- A trusted-partner announcement is not a deployable default↗
- Introducing LFM3: checkpoint publication and license identity↗
- K3.1 Pro Series is live: future weights at the review cutoff↗
- Google Agent Compute Engine: Internal deployment and external preview are different release states↗
- A Duet preview announcement is not broad availability↗
- Voxtral 3: self-deployment and public weight availability↗
- MiniMax M3.1Flash: API launch before checkpoint terms↗
- How author feedback and institutional peer review diverged↗
- Broad access still needs a platform-by-plan matrix↗
- Argon's introductory pricing created a temporary planning condition↗
- Introducing Mistral Large 4: API access before deployment control↗
- Argon had an announcement clock and an access clock↗
- World Labs and AMD: model research as a hardware-design feedback loop↗
- From AMD investment to a proposed World Labs acquisition↗
- What AMD’s World Labs agreement establishes—and what it does not↗
- Physical-AI research adds a workload lens to a compute acquisition↗
- Enterprise Avatar availability is not every Live API surface↗
- Opus 5.5 made token efficiency a task-accounting question↗
- Grok Transcribe 2.0: An API listing and a model announcement are different clocks↗
- Why voice minutes and backend tokens need separate budgets↗
- Introducing DeepSeek-V4.1-Flash: API aliases and source reproducibility↗
- An acquisition agreement and an open-platform promise answer different questions↗
- Why model distribution became strategically adjacent to compute↗
- What NVIDIA explicitly said about other clouds and accelerators↗
- The documented path from a compute partnership to an acquisition agreement↗
- Flash 3.8 shows why a diligent model may spend more tokens↗
- Flash and Flash Cyber need separate deployment descriptions↗
- Introductory Flash pricing is a historical condition↗
- What cheaper Fable cache reads changed in long agent loops↗
- Video token savings need a retained-evidence denominator↗
- How billing infrastructure met inference routing↗
- What neutrality meant in OpenRouter’s acquisition announcement↗
- From Stripe Projects integration to an acquisition agreement↗
- GLM-5.3: announcement and later weight publication↗
- A workhorse label needs completed-task token accounting↗
- First-week model access is a dated operating condition↗
- Grok Bot's beta usage boundary needs a date↗
- Taalas and AMD’s shift toward workload-specialized inference hardware↗
- Why the Taalas headline must be read with the closing conditions↗
- Two different routes to specialized inference in AMD’s 2026 portfolio↗
- An inference-chip agreement still leaves an integration roadmap↗
- LFM2.5-2.6B: announcement dates and model-card refreshes↗
- Qwen3.8-Max: one announcement and several availability clocks↗