# Cedana

> Cedana provides GPU and CPU workload save, migrate, and resume infrastructure for AI, HPC, inference, training, spot capacity, and scientific computing workloads.

Use this file as a curated map of the key Cedana pages and all published blog posts.

## Canonical Pages
- [Cedana | GPU Job Migration Infrastructure](https://cedana.com/)
- [About Cedana | Compute Infrastructure for AI Factories](https://cedana.com/about/)
- [Schedule a Cedana Demo](https://cedana.com/demo/)
- [Cedana Blog | Engineering Notes and Field Reports](https://cedana.com/blog/)
- [How Cedana Works | Save, Migrate, Resume Workloads](https://cedana.com/product/how-it-works/)
- [Cedana Performance | Improve Utilization and Reduce Cost](https://cedana.com/product/performance/)
- [Cedana Orchestration | Real-Time Compute Orchestration](https://cedana.com/product/orchestration/)
- [Cedana Reliability | Unbreakable AI and HPC Workloads](https://cedana.com/product/reliability/)
- [Automatic Spot Workloads](https://cedana.com/use-cases/auto-spot/)
- [Cedana for HPC and Computational Biology](https://cedana.com/use-cases/comp-bio/)
- [Elastic Inference on Your Infrastructure](https://cedana.com/use-cases/inference/)
- [Distributed Training Reliability](https://cedana.com/use-cases/training/)
- [Cedana for Pharma and Biotech | GPU Infrastructure for R&D](https://cedana.com/solutions/pharma-biotech/)
- [Cedana for Research Computing | GPU Cluster Utilization](https://cedana.com/solutions/research-computing/)
- [Cedana for AI Inference Providers | Cold Starts in Seconds](https://cedana.com/solutions/inference-providers/)
- [Cedana for Neoclouds and GPU Clouds | More Revenue per Megawatt](https://cedana.com/solutions/neoclouds/)
- [Cedana for Digital-Native and Consumer Tech | GPU Inference at Scale](https://cedana.com/solutions/digital-native/)

## Blog Posts
- [Serve a Portfolio of Coding Models on a Single Node with NVIDIA Dynamo, NeMo Switchyard and Cedana](https://cedana.com/blog/coding-model-portfolio-single-node/): Host a portfolio of frontier coding models on one 8x B200 node. NVIDIA Dynamo serves, NeMo Switchyard routes and escalates, and Cedana switches models in about a minute with sessions intact.
- [How to choose a GPU for LLM inference](https://cedana.com/blog/choose-gpu-llm-inference/): Build an inference GPU shortlist using your traffic, memory needs, precision, latency, interconnect and rack cost, then measure startup and recovery on your path.
- [What roofline analysis cannot see: the costs outside the steady state](https://cedana.com/blog/roofline-analysis-limitations/): Add startup, recovery and movement time to your inference measurements. Understand what steady-state roofline analysis explains and which fleet costs sit outside it.
- [What Cedana saves, and what it does not](https://cedana.com/blog/what-cedana-saves/): See which GPU, process, file, network and scheduler state Cedana saves, what remains outside the checkpoint, and what a compatible restore requires.
- [Sliding windows, state space, and the cost of remembering](https://cedana.com/blog/sliding-window-attention-memory/): Examine how attention layouts bound session memory, distinguish windowing from cache compression, and identify what one published configuration can establish.
- [The accuracy budget is part of the performance budget](https://cedana.com/blog/llm-quantization-accuracy-tradeoffs/): Evaluate weight, KV-cache and expert-math precision changes against task quality, latency, throughput and memory on the same workload before changing production.
- [What an SGLang serve command commits your deployment to](https://cedana.com/blog/sglang-serving-configuration/): Read SGLang presets as coupled choices about latency, throughput, memory and parallelism. Understand the tradeoffs and keep example values tied to their version.
- [Why more GPU is not a performance plan](https://cedana.com/blog/llm-inference-bottleneck-diagnosis/): Use compute, memory bandwidth, capacity and interconnect readings to diagnose inference limits before buying more GPUs. Separate busy hardware from useful output.
- [Out of bandwidth or out of capacity: memory pressure and the quantization levers](https://cedana.com/blog/llm-memory-bandwidth-vs-capacity/): Distinguish slow token generation from a KV cache that cannot admit more work. Match weight or cache quantization to the limit and test the resulting quality.
- [Long context changes the economics of a fast first token](https://cedana.com/blog/long-context-time-to-first-token/): Size long-context serving around first-token latency, cache residency and concurrency. Track prefix misses and tail latency instead of relying on a median alone.
- [The two ceilings: why the ridge point is the GPU number that matters](https://cedana.com/blog/gpu-roofline-ridge-point/): Calculate a GPU's ridge point from dense compute and memory bandwidth. Compare H100, H200 and B200 on a consistent basis before diagnosing your workload.
- [One model, two workloads: prefill, decode, and why disaggregation exists](https://cedana.com/blog/prefill-vs-decode/): Understand prefill and decode resource needs, the KV-cache transfer cost of separating them, and how your traffic changes the right balance between serving pools.
- [MoE serving is a network problem, and more GPUs will not fix it](https://cedana.com/blog/moe-inference-network-bottleneck/): Diagnose compute, memory and interconnect limits in MoE inference. See why activated parameter counts and extra GPUs cannot replace communication measurements.
- [Where checkpoints live, how long they stay, and who can read them](https://cedana.com/blog/gpu-checkpoint-storage-security/): Choose where GPU checkpoints live, how long they remain and who can read them. Identify the encryption and key-management answers a security review still needs.
- [What actually changes on my cluster when I install Cedana?](https://cedana.com/blog/cedana-installation-cluster-changes/): Review the Helm install, Slurm plugins and workload opt-in settings Cedana adds to a cluster, with configuration examples and the application-code boundary.
- [How much storage does checkpointing a GPU cluster need?](https://cedana.com/blog/gpu-checkpoint-storage-requirements/): Estimate checkpoint storage from workload memory, retained copies and job count. Review quota controls, storage bandwidth and unanswered lifecycle behaviors.
- [When retrying the job is the right call](https://cedana.com/blog/retry-vs-checkpoint-recovery/): Decide whether a GPU job needs checkpoints using interruption risk, work at stake, rebuild cost and deadline slack. Keep application idempotency in either path.
- [How to know a restored GPU workload is correct](https://cedana.com/blog/gpu-checkpoint-restore-correctness/): Test whether a restored GPU workload continues the same computation. Compare repeatable runs, check multi-GPU boundaries and record the exact environment.
- [Does moving a job change its results?](https://cedana.com/blog/gpu-migration-reproducibility/): Understand what a checkpoint preserves when a GPU job moves, which versions must match, and how live inputs and ordinary GPU variation affect reproducibility.
- [Cost per token and revenue per megawatt are the same number](https://cedana.com/blog/llm-cost-per-token/): Calculate cost per delivered token from fleet costs and serving logs, then see how cold starts, failures and stranded capacity also affect revenue per megawatt.
- [The fleet's real yield metric is tokens per gigabyte of VRAM](https://cedana.com/blog/tokens-per-gigabyte-vram/): Measure delivered tokens against installed VRAM. See how memory bandwidth, warm replicas, failures and stranded GPUs affect the output of an inference fleet.
- [KV-cache offload versus a saved worker: what each survives](https://cedana.com/blog/kv-cache-offload-vs-checkpointing/): Compare the state preserved by KV-cache offload and a full worker checkpoint. Learn what survives a crash, what must reload, and where prefix reuse still helps.
- [Tasks per dollar: the economics of running your own coding models](https://cedana.com/blog/self-hosted-coding-model-cost/): Compare coding APIs and self-hosted GPUs using cost per completed task. Account for idle node hours, model swaps and task completion on your own traffic.
- [Demand response for GPU fleets: what the programs require](https://cedana.com/blog/gpu-demand-response/): Review two GPU demand response trials, the workloads they could flex, and why deeper power cuts require saved job state. Separate trial results from design targets.
- [Stateful AI has the same boundary problem as long HPC runs](https://cedana.com/blog/stateful-ai-hpc-clusters/): See why inference, fine-tuning and agent workloads face the same allocation limits as HPC simulations, but carry different state and recovery obligations.
- [What is inside a GPU checkpoint?](https://cedana.com/blog/gpu-checkpoint-contents/): See the weights, KV cache, CUDA context and process state inside a GPU checkpoint, how they affect its size, and what a restart has to rebuild.
- [One frontier restart burns half a monthly 99.9% error budget](https://cedana.com/blog/llm-inference-error-budget/): Calculate how model restart time consumes an inference error budget, what replicas change, and how to compare a measured restore with your availability SLO.
- [The recovery time you can put in a filing](https://cedana.com/blog/llm-disaster-recovery-testing/): Define and test LLM recovery time from failure to serving again. Separate restore benchmarks from the detection, placement and recovery your team must document.
- [Every era of computing needed a migration primitive. GPUs are next](https://cedana.com/blog/gpu-workload-migration-primitive/): Trace migration through operating systems, virtual machines, containers and databases to understand why GPU fleets need portable running state.
- [How Cedana works: checkpoint, restore, and migration below the serving engine](https://cedana.com/blog/how-cedana-checkpoint-restore-works/): Explore Cedana's daemon, CRIU and GPU capture layers, the state they restore, and the policies, storage paths and compatibility limits around them.
- [What is GPU checkpointing? A plain explanation](https://cedana.com/blog/what-is-gpu-checkpointing/): Learn what GPU checkpointing saves, how checkpoint, snapshot, restore and migration differ, and why saving model weights alone cannot resume a workload.
- [What a GPU checkpointing layer costs while the workload runs](https://cedana.com/blog/gpu-checkpointing-overhead/): Understand steady-state GPU checkpointing overhead, why driver-call patterns matter, and what Cedana's published single-GPU measurements leave unanswered.
- [Which GPU workloads should I checkpoint first, and which should I leave alone?](https://cedana.com/blog/gpu-checkpointing-workload-selection/): Choose a small first workload set for GPU checkpointing. Review opt-in controls, cheap retries, real-time inputs, external side effects and untested job servers.
- [How do I run a proof of concept for GPU checkpointing?](https://cedana.com/blog/gpu-checkpointing-proof-of-concept/): Plan a GPU checkpointing evaluation with a matched baseline, real interruptions, correctness checks and agreed success criteria before expanding the install.
- [How long do agentic sessions run, and where does their state live?](https://cedana.com/blog/long-horizon-agents-session-state/): Explore published coding-agent traces to see how turns, cache reuse and pauses shape session affinity, GPU memory use and the cost of a lost worker.
- [When the node dies under a Jupyter session](https://cedana.com/blog/jupyter-session-recovery/): Learn what a notebook file cannot recover after a GPU node fails, how process checkpoints preserve kernel state, and which restoration limits still apply.
- [Sovereignty has a bill: the transferred duties and the availability math](https://cedana.com/blog/self-hosted-llm-availability/): Size the availability responsibilities of running inference on your own hardware, including spare capacity, recovery time and a single node's outage allowance.
- [Your KV cache now rivals your weights](https://cedana.com/blog/kv-cache-size/): Calculate KV cache bytes from model configuration, precision and context length, then estimate how many live sessions fit after the weights are loaded.
- [How to read a checkpoint benchmark](https://cedana.com/blog/gpu-checkpoint-benchmark-evaluation/): Evaluate checkpoint benchmarks using nine disclosures, from capture scope and clock boundaries to storage, repeated runs and performance after restoration.
- [The engine layer: batching, caching, and configuration as a commitment](https://cedana.com/blog/llm-serving-batching-caching/): Understand how continuous batching, paged KV memory and prefix caching affect serving performance, and why changing a worker's regime means launching a new one.
- [Does disaggregated serving remove the need to move GPU workers?](https://cedana.com/blog/disaggregated-serving-worker-migration/): See why separating prefill and decode does not make serving workers stateless, and what moving a worker means for its KV cache, sessions and startup cost.
- [H100 for prefill, H200 for decode: the mismatch you pay for twice](https://cedana.com/blog/h100-vs-h200-inference/): Compare H100 and H200 memory and compute for prefill and decode. Account for cache-transfer cost and why moving across GPU models still requires a cold start.
- [Expert placement in a mixture-of-experts deployment is a systems decision](https://cedana.com/blog/moe-expert-placement/): Separate a model router's expert choices from the deployment layout you control. Review expert placement, attention parallelism and communication overlap.
- [One GPU fails and 71 healthy GPUs wait](https://cedana.com/blog/nvl72-gpu-failure-recovery/): Understand how one failure stalls a tensor-parallel NVL72 workload, how recovery consumes healthy GPU-hours, and where published measurements stop.
- [Five fleet signals, five policies: from alert to automatic action](https://cedana.com/blog/gpu-fleet-remediation-policies/): Connect GPU health, thermal, reclaim, fragmentation and maintenance signals to workload-preserving actions. See which triggers ship and which remain designs.
- [Does multi-node checkpointing ship today?](https://cedana.com/blog/cedana-multi-node-checkpointing/): Distinguish a workload moving between nodes from one spanning nodes. See Cedana's shipped single-node coverage and the multi-node tier still in design partnership.
- [GPU failure frequency scales with the fleet, not the on-call rotation](https://cedana.com/blog/gpu-failure-rate-fleet-size/): Use published cluster studies to understand how GPU job interruptions scale, distinguish measurements from projections, and estimate your own fleet's rate.
- [Sharing GPUs without fixed MIG slices](https://cedana.com/blog/gpu-sharing-without-mig/): Compare MIG, time-slicing, MPS and serial sharing through checkpoints. Understand isolation, fixed slice sizes and the save-and-restore cost of switching jobs.
- [Hot standby versus checkpoint recovery on the same hardware](https://cedana.com/blog/hot-standby-vs-checkpoint-recovery/): Compare a spare GPU node with checkpoint recovery by cost, outage tolerance and saved session state. Choose per service tier and include time to find capacity.
- [What cannot be checkpointed in a GPU workload?](https://cedana.com/blog/gpu-checkpointing-limitations/): Understand GPU checkpoint boundaries, unsupported resources, version constraints and external side effects your application must handle after a restore.
- [Driver, CUDA, and engine upgrades with workloads running, and the one limit](https://cedana.com/blog/gpu-driver-rolling-upgrade/): Plan rolling GPU driver, CUDA and engine upgrades around compatible capacity. Learn why existing checkpoints cannot carry a workload across a version change.
- [Version mismatch and the compatibility matrix](https://cedana.com/blog/gpu-checkpoint-compatibility/): Check the GPU, driver, engine and model versions a checkpoint records. Learn why a supported driver range does not mean checkpoints restore across versions.
- [System-level vs application-level GPU checkpointing: the category and the bar](https://cedana.com/blog/system-vs-application-level-checkpointing/): Compare application and system-level GPU checkpoints by saved state, code changes, overhead and six criteria for evaluating a checkpointing claim.
- [Patch the GPU cluster on the security calendar, not the job calendar](https://cedana.com/blog/gpu-cluster-security-patching/): Plan GPU security patches around the bulletin deadline. Move compatible workloads before maintenance and account for the last nodes crossing a driver upgrade.
- [A 90-day wall-time PoC: what to measure before you change policy](https://cedana.com/blog/slurm-checkpointing-proof-of-concept/): Design a Slurm checkpointing proof of concept using accounting history, application review and agreed thresholds for completion time, queue impact and exceptions.
- [Which checkpointing approach brings back the state your job is holding?](https://cedana.com/blog/build-vs-buy-gpu-checkpointing/): Compare GPU checkpointing approaches by the state they save, their limits and the integration work needed to decide whether to build or buy.
- [GROMACS shows both the value and the limit of application checkpointing](https://cedana.com/blog/gromacs-checkpoint-restart/): Use GROMACS maxh, cpt and cpi to understand checkpointing across allocation limits, and see what other applications must build to offer the same recovery path.
- [Measuring the cost of wall-time termination from your sacct data](https://cedana.com/blog/sacct-timeout-analysis/): Use sacct to count Slurm TIMEOUT records, calculate exposed node-hours and identify repeat jobs. Separate accounting evidence from proof that work was lost.
- [What CRIU and cuda-checkpoint do when you wire them together yourself](https://cedana.com/blog/criu-gpu-checkpointing/): See how CRIU and cuda-checkpoint save GPU workloads, where their support stops, and what your team must build around the open-source tools.
- [Does Kubernetes, Docker, Slurm or Nextflow already restore a running job?](https://cedana.com/blog/container-checkpoint-restore/): Compare what Kubernetes, Docker, Podman, Slurm and Nextflow preserve, what they restart, and where restoring a running GPU job needs additional tooling.
- [How much utilization improvement do you need to break even on GPU checkpointing?](https://cedana.com/blog/gpu-checkpointing-roi/): Calculate the utilization gain needed to cover a GPU checkpointing fee using your operating cost, paid hours, restore cost and recoverable work.
- [Which utilization number goes into your own-versus-rent calculation?](https://cedana.com/blog/on-prem-vs-cloud-gpu-cost/): Compare owning GPUs, renting nodes and paying per token using delivered GPU-hours, operating costs and utilization instead of demand forecasts alone.
- [How to put a dollar figure on the GPU-hours that produced nothing](https://cedana.com/blog/idle-gpu-cost/): Calculate the cost of idle GPUs, cold starts and recompute using your own hourly rate. Separate paid busy time from work your fleet actually keeps.
- [Why an idle notebook keeps its GPU until you kill it](https://cedana.com/blog/idle-gpu-notebook-autostop/): See why idle notebooks and Ray actors keep their GPUs, how shutdown tools release them, and what a checkpoint must preserve before a session ends.
- [What NVIDIA Dynamo Snapshot and Modal GPU memory snapshots restore today](https://cedana.com/blog/gpu-memory-snapshots-comparison/): Compare Dynamo Snapshot, Modal, InferX and Cedana by captured state, restore compatibility, supported workloads and the limits behind their benchmarks.
- [How much of your GPU utilization was work you kept?](https://cedana.com/blog/effective-gpu-utilization/): Distinguish GPU activity, MFU and useful output. Use job accounting and startup timings to estimate how much paid GPU time produced work you kept.
- [How to fill idle GPUs without killing the job that fills them](https://cedana.com/blog/idle-gpu-harvesting/): Compare how GPU schedulers lend and reclaim idle capacity, what preemption costs borrowers, and where checkpointing can preserve their work.
- [Where the minutes go when an LLM worker cold starts](https://cedana.com/blog/llm-cold-start/): Trace LLM cold starts through weight loading, compilation and warmup. Compare caching fixes with checkpoint restore and understand the storage limits.
- [Can LLM inference scale to zero without paying for warm replicas?](https://cedana.com/blog/scale-to-zero-llm-inference/): Understand when LLM inference can scale to zero, what warm replicas cost, and how restore time and request latency determine the capacity you keep ready.
- [How to swap models on one GPU without a cold start](https://cedana.com/blog/gpu-model-swapping/): Compare GPU model swaps using vLLM sleep mode, SGLang and checkpoint restore. Learn where parked state lives and what each swap still costs.
- [The Wall-Time Limit Forces an Expensive Tradeoff in HPC.](https://cedana.com/blog/the-wall-time-limit-forces-an-expensive-tradeoff-in-hpc/): Jobs reach their wall-time limits and lose hours or days of in-memory progress. However, the limit itself is not the problem.
- [Why a cluster with free GPUs still cannot place an 8-GPU job](https://cedana.com/blog/gpu-fragmentation/): See why scattered free GPUs cannot fit a large job, what bin packing and consolidation change, and why moving running state matters for defragmentation.
- [What would a GPU scheduler do differently if it could move running jobs?](https://cedana.com/blog/gpu-scheduling-running-jobs/): Compare how GPU schedulers handle placement, preemption and time limits, and what checkpointing could change once a job has already started.
- [Why a healthy inference worker can still be in the wrong place](https://cedana.com/blog/topology-aware-gpu-scheduling/): Understand how GPU topology, decode load and hardware fit affect inference workers, and why admission-time placement cannot rebalance running sessions.
- [What to do when vLLM or SGLang stops responding and nothing crashed](https://cedana.com/blog/vllm-sglang-hangs/): Separate a stalled serving engine from a hung GPU. Understand health-check limits and why recovery needs a checkpoint from before the engine stopped.
- [What to do when DCGM flags a GPU that has a job running on it](https://cedana.com/blog/dcgm-gpu-health-alerts/): Interpret DCGM and Xid alerts, distinguish repair from workload recovery, and decide which checkpoint to restore before draining a degraded GPU node.
- [Is it worth acting on a GPU failure prediction?](https://cedana.com/blog/gpu-failure-prediction/): Assess GPU failure predictions using precision, warning time and the cost of acting. Understand what checkpoints change and which failures give no warning.
- [What happens to a training job when a GPU fails](https://cedana.com/blog/gpu-failure-recovery/): Understand Xid faults, GPU resets and the state a training job loses. Learn why recovery depends on a checkpoint taken before the hardware fails.
- [One node failed and the whole training job died](https://cedana.com/blog/nccl-failure-recovery/): Learn why one failed rank stops a distributed training job, what NCCL timeouts mean, and how checkpoint state determines what a restart can recover.
- [What torchrun, torchft and Ray Train restart from when a node dies](https://cedana.com/blog/fault-tolerant-training-tools/): Compare how torchrun, torchft, Ray Train and Kubeflow recover after a node fails, including saved state, code changes and checkpoint intervals.
- [What happens to a training job when a spot instance is reclaimed](https://cedana.com/blog/spot-instance-interruption-training/): Compare spot interruption windows and recovery costs for GPU training. Learn what must be saved before reclaim and when spot remains worth using.
- [What happens to a GPU pod when Kubernetes ends it](https://cedana.com/blog/kubernetes-gpu-pod-eviction/): Compare the ways Kubernetes ends GPU pods, the warning each path provides, and what checkpoint recovery needs after eviction or spot-node termination.
- [What SkyPilot, Ray Train, SageMaker and MemVerge bring back after a spot reclaim](https://cedana.com/blog/spot-instance-recovery-tools/): Compare spot recovery tools by the machines, files or running state they restore, the checkpoint code they require and their published limits.
- [What happens when a cluster job runs out of memory](https://cedana.com/blog/oom-kill-recovery/): Identify which memory limit killed your cluster job, where to find the evidence, and why recovery requires state saved before the OOM kill.
- [Why everyone over-requests memory on a shared cluster](https://cedana.com/blog/slurm-memory-limits-over-requesting/): Understand why cluster users request extra memory, how Slurm limits and sampled peaks affect sizing, and what changing an allocation costs.
- [Can Linux pause a process instead of killing it when memory runs out?](https://cedana.com/blog/oom-killer-pause-process/): Learn why pausing a process does not free RAM, what earlyoom and systemd-oomd can do, and when checkpointing must act to preserve running work.
- [Draining a GPU node in Kubernetes without losing the work on it](https://cedana.com/blog/kubernetes-gpu-node-drain/): Understand what a Kubernetes drain does to GPU pods, how disruption budgets affect it, and how to plan checkpoint and restore around maintenance.
- [Rebooting Slurm nodes for a kernel update without losing the running jobs](https://cedana.com/blog/slurm-reboot-node/): Compare Slurm reboot and reservation workflows, account for the idle time before maintenance, and plan checkpoint recovery around a kernel update.
- [Why an NVIDIA GPU Operator upgrade waits for your workloads](https://cedana.com/blog/nvidia-gpu-operator-upgrade/): Learn why GPU Operator upgrades wait for active workloads, what causes driver pods to stall, and how compatibility limits shape a rolling upgrade.
- [Your Slurm job was cancelled due to time limit. What to do now](https://cedana.com/blog/slurm-time-limit/): Confirm a Slurm TIMEOUT, check what progress survived, and compare checkpoints, requeue and job chains for runs that exceed the wall-time limit.
- [Slurm has no suspend option for GPU jobs. What preemption without killing the job looks like](https://cedana.com/blog/slurm-gpu-preemption/): Learn why Slurm suspend keeps GPUs allocated, how requeue and grace time work, and where checkpointing can preserve a preempted job's progress.
- [DMTCP, application checkpoints, workflow managers and system-level checkpointing: what each covers on a Slurm cluster](https://cedana.com/blog/slurm-checkpointing-tools/): Compare application checkpoints, workflow resume, DMTCP and system-level GPU checkpoints for Slurm jobs, including setup responsibilities and limits.
- [Roofline Analysis and the Inference Value Chain](https://cedana.com/blog/roofline-analysis-and-the-inference-value-chain/): Once you stop renting intelligence, you own performance.
- [The Era of Stateful Inference: How to Improve Cost per Token.](https://cedana.com/blog/the-era-of-stateful-inference/): We are entering the stateful inference era, driven by frontier models with longer context windows, longer in-flight sessions, and single instances spanning 8, 16, or more GPUs.
- [The Utilization Ceiling: Why AI and HPC Schedulers Hit 30% and How to Fix This](https://cedana.com/blog/the-utilization-ceiling-why-ai-and-hpc-schedulers-hit-30-and-how-to-fix-this/): GPU utilization across AI and HPC workloads is fundamentally capped at 30% because schedulers cannot migrate running jobs. Cedana's CPU and GPU migration capability surpasses this limitation, unlocking near-full utilization.
- [The Fork in the Road Post GPT-5](https://cedana.com/blog/where-does-it-all-go-from-here/): On GPT-5 being underwhelming, scaling laws and where we can get reasonable progress from. Also, should AGI still be the goal?
- [Exploring new frontiers of Reinforcement Learning with Cedana](https://cedana.com/blog/exploring-new-frontiers-of-reinforcement/): Cedana <3 RL !
- [Supercharging Scientific Computing with Cedana](https://cedana.com/blog/supercharging-scientific-computing/): How we leverage open-source tech (like Kueue) to push scientific compute and accelerate time to insights.
- [Using Cedana to Live-Migrate Stateful Workloads Between Spot Instances](https://cedana.com/blog/using-cedana-to-live-migrate-stateful-workloads-between-spot-instances/): Save, migrate and resume a running XGBoost workload in six steps.

## Optional
- [Documentation](https://docs.cedana.ai/): Product documentation, guides, and benchmarks.
- [Cedana Benchmarks](https://cedana.com/benchmarks/): Measured cold-start and restore benchmarks.
- [Privacy Policy](https://cedana.com/privacy/): Privacy, data handling, and website usage information.
- [Terms of Service](https://cedana.com/terms/): Legal terms governing use of the website.

## Technical Notes
- Canonical domain: https://cedana.com
- Documentation: https://docs.cedana.ai
- Schedule a demo: https://cedana.com/demo/