当Coding Agent需要跨十几个文件修复bug时，它必须反复读取代码、检索资料、运行测试。前几轮交互或许顺畅，但随着任务持续推进，系统需要处理的历史信息不断累积。当成千上万个Agent同时工作时，运营方会遭遇一个棘手问题：服务器仍在运行，可承接的并发量却越来越吃紧，部分请求连输出第一个Token都要等待许久。

问题的根源在于大模型的记忆机制。模型每生成一个新Token，都需要继续使用前文信息。为避免重复计算，推理系统会把已算好的中间结果缓存起来，这就是KV Cache。会话越长，这份记忆越厚。一旦显存装不下、部分缓存被清走，Agent下一轮又需要这些历史信息时，就可能重新执行Prefill，让GPU把已经算过的内容再算一遍。

以Qwen3-8B为例，按照公开模型配置，在KV Cache采用BF16或FP16、每个数值占2字节的条件下，每个Token对应的KV数据约为147KB。若假设需要缓存100万个Token，对应KV数据约147GB。需要说明的是，1M仅为测算假设，Qwen3-8B官方说明为原生32768 Token，采用YaRN可扩展至131072 Token。

若将请求规模放大，假设一个服务有300万日活用户，每人每天发出10个请求，且每个请求均按1M上下文计算，一天就是3000万个请求，对应日累计KV数据规模约为4410PB。若日活增至3亿，相同假设下该数字将放大100倍，达到约441EB。不过，一天的请求累计涉及多少KV数据，与数据中心同时需要存下多少KV数据并非同一概念，实际缓存池配置还需考虑高峰并发、缓存保留时长、前缀共享及压缩淘汰策略等因素。