orbitkv

O OrbitKV é uma camada de cache de chave-valor externa para motores de inferência de LLM. Estende o cache KV do vLLM e do SGLang para além da memória da GPU: os prefixos reutilizáveis são mantidos em DRAM e SSD e depois restaurados quando chega um pedido correspondente. Os casos de uso indicados são cargas de trabalho com documentos repetidos, prompts de sistema partilhados e conversas longas cujos prefixos já não cabem no cache de GPU do motor. Modelo de implementação Um Cache Manager independente é executado por host, e os motores nesse host ligam-se ao seu cache partilhado. Os motores mantêm a propriedade da memória da GPU e do agendamento; o OrbitKV gere réplicas externas e transferências. O caminho de nó único é descrito como testado em GPU no vLLM 0.29.0 e no SGLang 0.5.20. A partilha de cache multi-nó está classificada como experimental, e as interfaces podem mudar antes da versão 1.0. Capacidades principais - Cache em DRAM e SSD: os prefixos podem ser reutilizados após a remoção da GPU ou o reinício do motor enquanto o Cache Manager permanecer ativo. - Políticas de reutilização opcionais: um componente Rust pode proteger páginas reutilizadas dentro de um limite de bytes e admitir escritas em SSD de forma seletiva; a documentação observa um compromisso de reutilização a frio. - Transferências diretas para GPU: ambos os motores registam buffers de GPU através de CUDA IPC; os adaptadores isolam o fluxo CUDA produtor, e o Rust trata das consultas ao cache, das leituras e da conclusão das transferências. - Recuperação ciente do modelo: a identidade do cache inclui artefactos do modelo, definições de computação e disposição de armazenamento. As regras de recuperação compiladas selecionam páginas de atenção, janelas deslizantes e pontos de verificação recorrentes/convolucionais, incluindo disposições que combinam os três. - Utilização de recursos limitada: os orçamentos de bytes cobrem leituras pendentes, páginas prontas e transferências de GPU ativas; o cancelamento retém a E/S submetida até à conclusão. - Observabilidade: métricas Prometheus e linhas temporais de pedidos opcionais, com comandos de reprodução para as medições publicadas. - Cache partilhado experimental: fragmentos de catálogo incorporados localizam réplicas pares, o Mooncake Transfer Engine move bytes, e o etcd acompanha a pertença ao cluster. Esboço de início rápido É construída e instalada uma wheel por runtime de Python e CUDA, com ambientes separados para vLLM e SGLang. A wheel inclui o Cache Manager e as bibliotecas Mooncake; o Manager também requer um PyTorch compatível. A primeira versão Python é descrita como estando a ser preparada, pelo que o estado de publicação do pacote deve ser verificado na documentação de lançamento. Um Cache Manager é iniciado com um comando como `orbitkv-cache-manager --addr 127.0.0.1:50055 --http-addr 127.0.0.1:9091 --pool-size 8gb`. O vLLM é depois iniciado com a cache de prefixos ativada e uma configuração de transferência KV que nomeia o módulo conector OrbitKV; o SGLang é iniciado com uma variável de ambiente de endpoint OrbitKV, um tamanho de página e as opções de backend de linker externo e radix cache. A cache SSD é ativada adicionando `--ssd-cache-path` e `--ssd-cache-capacity` ao comando do Manager; a cache SSD é recriada quando o Manager reinicia. O backend SSD predefinido tenta o cuFile nativo em montagens suportadas e recorre ao io_uring. Uma substituição `--ssd-read-path uring|cufile` seleciona a rota de restauração a pedido independentemente da representação armazenada. As opções de codificação de armazenamento incluem compressão sem perdas nvCOMP ANS, FP8 e TurboQuant de 3/4 bits, selecionadas com `--storage-codec`; a predefinição é armazenamento exato, e os modos com perdas requerem qualificação da qualidade do modelo. Um aumento na métrica `orbitkv_load_bytes_total` é dado como confirmação de uma restauração externa. Arquitetura e estado O adaptador do motor identifica o estado em falta e fornece destinos de GPU; o OrbitKV seleciona intervalos em cache compatíveis, lê-os dos níveis configurados e retém a propriedade das páginas até a cópia para a GPU terminar. O KV recém-calculado é publicado para reutilização posterior. A mesma API de adaptador serve DRAM, SSD e obtenções remotas experimentais, com colocação física dentro do Cache Manager. O projeto documenta um plano de implementação que mapeia mecanismos fixados do LMCache, FlexKV e Mooncake para trabalho de implementação e validação. Observações de custo limitado em Rust, previsões sombra de cópia bruta e rotas de leitura SSD independentes são descritas como implementadas; a seleção dinâmica de custo permanece planeada, e as observações estão desativadas por predefinição. A conversão de bytes entre motores, a HA do catálogo em produção e o encaminhamento de pedidos ciente do KV estão listados como trabalho planeado. Documentação de desempenho O desempenho depende, segundo é indicado, da reutilização de prefixos, da capacidade da cache, do armazenamento e do agendamento do motor. Os relatórios cobrem comparações de nó único (HBM nativa, caches de CPU do motor, OrbitKV, LMCache, FlexKV), recuperação SSD, recuperação comum com leituras do host Qwen3-8B e transferências de GPU, preparação de pedidos e qualificação de cache partilhada. A preparação de pedidos está desativada por predefinição: os controlos documentados do Qwen3-8B melhoram o débito em ambos os motores, mas a latência P95 do SGLang regride, e as medições num único H20 não são apresentadas como uma vantagem universal sobre outras caches. O código de benchmark e os resumos estão no diretório `benches/`. Licenciamento e contribuição O OrbitKV está licenciado sob Apache-2.0. A documentação cobre instalação, configuração do adaptador, opções do Manager, métricas, qualificação de falhas, padrões de implementação, um guia para contribuidores, detalhes do pacote Python, portas de teste e lançamentos. Espera-se que as contribuições incluam verificações relevantes e alterações à documentação.