Merge pull request #442 from windsonsea/fixaks

update kvcache-wins-you-can-see.md

Author: windsonsea

docs/zh/docs/blogs/2025/kvcache-wins-you-can-see.md

@@ -53,7 +53,7 @@ OpenAI 的 [API 定价](http://openai.com/api/pricing/)页面上也能看到同
 
     已经了解 vLLM 如何使用 KV 缓存（Key-Value Cache）和前缀缓存优化推理？可以直接跳到[扩展的挑战](#_3)。
 
-在每个 Transformer 模型的核心是**自注意力机制** ：模型通过计算每对 Token
+在每个 Transformer 模型的核心是 **自注意力机制** ：模型通过计算每对 Token
 之间的注意力分数来理解上下文。这种两两比较随输入长度呈平方级增长，使得初始的
 **Prefill** 计算成为生成中最昂贵的部分。
 
@@ -77,8 +77,8 @@ vLLM 的缓存能力并非理论，它直接映射到最常见和最有价值的
 
 #### 对话式 AI
 
-在任何多轮对话中，从客服机器人到长文本助手，整个聊天历史和系统提示共同构成了庞大的**前缀** 。
-而每条新用户消息则是一个很小的**后缀** 。高效缓存意味着只需 Prefill 最新的对话轮次，
+在任何多轮对话中，从客服机器人到长文本助手，整个聊天历史和系统提示共同构成了庞大的 **前缀** 。
+而每条新用户消息则是一个很小的 **后缀** 。高效缓存意味着只需 Prefill 最新的对话轮次，
 从而保持对话流畅，避免随着对话长度增加而导致的延迟累积。
 
 ![对话式 AI 前缀缓存图](./images/image1.png)
@@ -96,8 +96,6 @@ AI 智能体是前缀占主导的极端场景。这些系统在推理循环中
 
 <small>图 2：智能体循环示意图，展示了庞大且静态的上下文（工具、历史步骤）作为缓存前缀，而新观察/动作是小后缀。</small>
 
-<br/><br/>
-
 在每次迭代中重用庞大的上下文，对复杂智能体的计算可行性和成本效益至关重要。
 
 !!! tip "RAG 怎么办？"
@@ -107,7 +105,7 @@ AI 智能体是前缀占主导的极端场景。这些系统在推理循环中
 
 ## 横向扩展的挑战
 
-当我们从单实例环境转移到分布式生产集群时，会发生什么？曾经统一的 KV 缓存变得**解耦** 。
+当我们从单实例环境转移到分布式生产集群时，会发生什么？曾经统一的 KV 缓存变得 **解耦** 。
 每个 vLLM Pod 都在完全隔离的情况下管理自己的缓存。
 标准的负载均衡器会天真地使用对缓存一无所知的指标来平均分配流量，把相关请求分散到不同的
 Pod 上，从而破坏缓存局部性。
@@ -118,8 +116,6 @@ Pod 上，从而破坏缓存局部性。
 
 <small>图 3：令人心碎的 KV 缓存未命中场景。</small>
 
-<br/><br/>
-
 这个单一的路由决策触发了一连串的失败：
 
 * **缓存未命中:** Pod A 上的热缓存优势完全丧失  
@@ -137,7 +133,7 @@ Pod 上，从而破坏缓存局部性。
 从而导致代价高昂的缓存未命中。解决方案就是弥合这种解耦。为了恢复前缀缓存的优势，
 调度器需要一种新的能力：洞察分布式缓存的实时状态。
 
-这正是 llm-d 提供的功能（双关语有意为之）。它创建了一个**全局视图** ，让集群的
+这正是 llm-d 提供的功能（双关语有意为之）。它创建了一个 **全局视图** ，让集群的
 KV 缓存可以被视为单一的、可管理的内存池，从而实现精确的请求路由。
 
 ### 工作原理：通过 `KVEvents` 构建全局缓存视图
@@ -190,7 +186,7 @@ KV 缓存亲和度得分会与分布式、负载感知得分结合，形成一
 每个客户有 **6,000-Token 的上下文** ，并且每个客户有 **5 个并发用户** 提交
 **1,200-Token 的查询** ，在 **3-60 QPS** 的持续负载下运行。
 
-该工作负载产生的 KV 缓存总需求是**集群容量的 73%** ，是单个 Pod 能处理的
+该工作负载产生的 KV 缓存总需求是 **集群容量的 73%** ，是单个 Pod 能处理的
 **6 倍** ，这迫使系统必须在集群内分配前缀 —— 正是智能调度至关重要的场景。
 
 !!! info "基准测试细节"
@@ -207,7 +203,7 @@ KV 缓存亲和度得分会与分布式、负载感知得分结合，形成一
 * `precise-scheduling`: 本文所描述的高级路径。
 
 因此，此基准测试检验调度器高效管理解耦 KV 缓存的能力。在生产环境中，如果总缓存需求超过集群容量，
-自动扩缩容系统将负责增加副本以维持 SLO。而这里，我们专注于**最大化现有硬件的性能** 。
+自动扩缩容系统将负责增加副本以维持 SLO。而这里，我们专注于 **最大化现有硬件的性能** 。
 
 ### 结果：性能飞跃
 
@@ -249,7 +245,7 @@ P90 TTFT。相比之下，近似调度器超过 **31 秒** ，缓存盲调度器
 
 #### “为什么”：从节省工作到系统吞吐量
 
-基准测试中的显著性能提升直接来源于**系统效率** ，这一差异在 **实时 Grafana 指标** 中立刻可见。
+基准测试中的显著性能提升直接来源于 **系统效率** ，这一差异在 **实时 Grafana 指标** 中立刻可见。
 
 以下图表是在基准运行期间捕获的。调度器依次展示：`precise-scheduling` *(左)*，`approximate-scheduling` *(中)*，`random-scheduling` *(右)*。
 
@@ -262,8 +258,6 @@ GPU **避免** 的计算工作。数值高意味着系统持续节省了大量
 
 <small>图 6：在整个基准测试过程中，KV 缓存为集群节省的计算工作总量。</small>
 
-<br/><br/>
-
 图表清楚显示，`precise-scheduling` 通过有效命中前缀，维持了巨大且稳定的节省吞吐量。中间的 `approximate-scheduling` 效率尚可但较低，而右侧的 `random-scheduling` 几乎没有节省任何工作。
 
 ##### 2. 系统状态：效率的结果
@@ -284,7 +278,7 @@ GPU **避免** 的计算工作。数值高意味着系统持续节省了大量
 不断增长的等待队列扼杀了系统，阻止工作被高效完成。
 
 这种不稳定是由 **缓存抖动** 引起的。缓存盲调度器不断在不同 Pod 上 **重复和驱逐** 相同前缀，浪费 GPU 周期在
-**冗余 Prefill ** 上。`precise-scheduling` 完全避免了这一点。它对前缀位置有精确认知，
+**冗余 Prefill** 上。`precise-scheduling` 完全避免了这一点。它对前缀位置有精确认知，
 并持续路由请求以实现缓存命中 —— 只要负载允许 —— 结果就是更少的工作、几乎没有队列以及一个健康的系统。
 
 !!! info "会话级调度"

docs/zh/docs/en/blogs/2025/kvcache-wins-you-can-see.md

@@ -70,8 +70,6 @@ AI agents represent the most extreme case of prefix dominance. These systems ope
 
 <small>*__FIGURE 2__: A visual of an agent loop, showing the massive, static context (tools, step-history) as the cached prefix and the new observation/action as the small suffix.*</small>
 
-<br/><br/>
-
 Reusing this massive context on each turn is essential for complex agents to be computationally viable and cost-effective.
 
 !!! tip "What about RAG?"
@@ -88,8 +86,6 @@ Let's revisit our agentic workflow example to see the direct impact of being bli
 
 <small>*__FIGURE 3__: A heartbreaking KV-cache miss scenario.*</small>
 
-<br/><br/>
-
 This single routing decision triggers a cascade of failures:
 
 * **Cache Miss:** The warm cache benefit on Pod A is completely lost  
@@ -120,8 +116,6 @@ This two-layered architecture provides a continuously updated, scalable view of
 
 <small>*__FIGURE 4__: Simplified architecture diagram. (1) - (3) show the read path, while (A) - (B) show the write pipeline.*</small>
 
-<br/><br/>
-
 **What about the overhead?** The memory overhead for this global index is negligible - see **Appendix A.3** for the scaling analysis showing a **1,000,000:1** data-to-metadata ratio.
 
 !!! info "High availability support"
@@ -192,8 +186,6 @@ This allows you to handle significantly more traffic on the exact same hardware,
 
 <small>*__FIGURE 5__: A tri-panel of TTFT, TPoT and Throughput measured through progressively rising QPS rates.*</small>
 
-<br/><br/>
-
 The charts above clearly illustrate these wins. The blue line (`precise-scheduling`) maintains the lowest Mean TTFT and achieves the highest Total Throughput as the request rate increases.
 
 #### The "Why": From Saved Work to System Throughput
@@ -210,8 +202,6 @@ First, we measure the **Effective Cache Throughput** - the number of prompt **to
 
 <small>*__FIGURE 6__: The total computational work **saved** by the KV-cache across the cluster, over the course of the benchmarks.*</small>
 
-<br/><br/>
-
 The chart clearly shows that `precise-scheduling` sustains a massive and stable throughput of saved work by hitting the prefixes effectively. In the middle, we see `approximate-scheduling` with good but lower efficiency, and on the right, `random-scheduling` saving almost no work.
 
 ##### 2. System State: The Consequence of Efficiency