September 2026 Summaries

A reproducible benchmark of 50 million members inserted into a single sorted set compared six Redis releases and five Valkey releases on the same Graviton4 host using pipelined ZADD operations. Older releases of both projects used about 4.83 GB, or roughly 97 bytes per member, while Redis reduced usage to 3.73 GB and improved insertion throughput beginning with version 8.6; Valkey reached a similar 3.77 GB in version 8.1 and further reduced consumption to 3.34 GB, about 67 bytes per member, in version 9.1.2, which also produced the highest measured insertion rate at roughly 647,000 operations per second. The memory improvements are attributed to Valkey changes that eliminated duplicate sorted-set mappings and later embedded member strings in skiplist nodes, with Redis 8.6 adapting the first of these designs while retaining its own dictionary implementation. The comparison is limited to one large skiplist-encoded sorted set with short members, integer scores, allocator-level memory accounting, and one pipelined client, so results may differ for other workloads.

At IBC 2026, the author argues that industry attention to ubiquitous AI features and dramatic latency reductions overshadowed the operational infrastructure required to deliver major live events reliably. While AI demonstrations largely focused on captioning, metadata, reframing, and synthetic talent, and low-latency streaming showed promise in controlled settings, real deployments remain constrained by advertising, content protection, last-mile delivery, synchronization, authentication, failover, caching, and real-time monitoring. Looking toward 2027, the author expects “AI-powered” to lose value as a marketing label while media consolidation reduces the number of major buyers and increases the stakes for vendors and content owners. The resulting challenge will be deciding what to build internally versus outsource, particularly as AI-generated software may increase technical debt and token-related operating costs, making scalable infrastructure a central competitive concern.

A benchmark of remote versus local KV-cache storage for LLM inference tested vLLM and LMCache across two NVIDIA L4 GPU nodes and a Valkey server connected by 10 Gbps networking, using repeated 10,000-token legal and medical prompts to measure time to first token. For a workload exceeding available host memory, remote Valkey achieved a median cached TTFT of 557 ms, nearly six times faster than cold prefill and substantially faster than local NVMe at 1,521 ms, while DRAM cache misses occurred because the configured 8 GB tier could not hold the roughly 16 GB working set. The analysis attributes Valkey’s performance to parallel network reads reaching approximately 1.2 GB/s, whereas the local disk path achieved about 400 MB/s despite NVMe’s higher theoretical capability. In a two-node test, locally stored NVMe cache provided no reuse when requests reached the other GPU, while Valkey retained essentially identical performance and reused all cache entries across nodes. The findings suggest that DRAM is preferable when the KV working set fits in memory, but a shared remote cache can offer greater capacity, cross-node reuse, and, in this configuration, faster retrieval than local NVMe, although it added roughly 110–150 ms to cache-fill latency. The benchmark materials are publicly available, and the author notes that consistent cross-node cache keys require configuring LMCache with a stable hash algorithm rather than Python’s process-randomized default hash.