Skip to main content

Why HiCache Matters

SGLang HiCache extends the traditional RadixAttention with a three-tier hierarchical KV caching system that dramatically improves performance for long-context and multi-turn conversation scenarios. By intelligently managing KV caches across GPU memory, host memory, and external storage backends, HiCache addresses the fundamental capacity bottleneck that limits cache hit rates in conventional systems.

Configuration Guidelines

Core HiCache Parameters

Command
Notes:
  • Besides configuring --hicache-storage-backend at startup, SGLang also supports runtime attach/detach of the HiCache storage backend (no restart required) via HTTP admin endpoints. See Runtime Attach/Detach HiCache Storage Backend.

Key Configurations with Storage Backends Enabled

Memory Layout Optimization

Command
Layout Compatibility:
  • page_first: Only compatible with kernel I/O backend, automatically switches to layer_first with direct backend
  • page_first_direct: Specifically designed for direct I/O backend with optimized memory organization

Heterogeneous TP Support (GQA/MHA models)

HiCache storage supports cross-cluster KV reuse when different deployments use different TP sizes (for example, tp=4 and tp=8) and share the same storage backend namespace. Use tp_lcm_size in --hicache-storage-backend-extra-config:
Command
Guidelines:
  • Set tp_lcm_size to the least common multiple (LCM) of all TP sizes that will share the same HiCache storage.
  • For MHA models with Mooncake and page_head layout, HiCache will split head shards based on tp_lcm_size to make keys reusable across heterogeneous TP deployments.
  • If all clusters use the same TP size, this option is not needed.

Prefetch Policies

Command

Integration with PD Disaggregation

HiCache works seamlessly with PD Disaggregation. You can choose between two configurations:
  1. Prefill-only HiCache: Enable HiCache only on Prefill nodes, allowing KV cache sharing among Prefill instances
  2. Full HiCache with async offloading: Enable HiCache on Prefill nodes and async KV cache offloading on Decode nodes, allowing Prefill nodes to reuse KV caches from Decode nodes in multi-turn dialogue scenarios
Command

Deployment with HF3FS

Here is an example of deploying DeepSeek-R1 with HiCache-HF3FS. For more details, see the HF3FS Documentation.
Command

Deployment with Mooncake

Here is an example of deploying Qwen3-235B-A22B-Instruct-2507 with Mooncake. For more details, see the Mooncake Documentation.
Command

Custom Storage Backend Integration

To integrate a new storage backend:
  1. Implement three core methods:
    • get(key): Retrieve value by key
    • exists(key): Check key existence
    • set(key, value): Store key-value pair
  2. Register your backend: Add your storage backend to the HiCache BackendFactory
The HiCache controller handles all scheduling and synchronization automatically.

Dynamic Backend Loading

Alternatively, you can use dynamic loading to avoid hard-coding your backend in the repository:
Command
Configuration Parameters:
  • --hicache-storage-backend: Set to dynamic
  • --hicache-storage-backend-extra-config: JSON configuration with:
    • backend_name: Custom backend identifier
    • module_path: Python module path to your implementation
    • class_name: Your HiCache implementation class name
    • interface_v1: 0 (disable) or 1 (enable) to control usage of batch_get_v1 and batch_set_v1 methods

Community and Support

  • GitHub Issues: Report bugs and feature requests
  • Slack Channel: Join community discussions in #sgl-kv-cache-store
  • Documentation: Refer to storage backend-specific guides

This document will be continuously updated based on community feedback and new features. Contributions and suggestions are welcome!