llama.cpp b10985修复RPC哈希缓存：激活值不再写入磁盘，避免一天 1.4 TB占用
ggml_backend_rpc此前对超过HASH_THRESHOLD的所有传输做哈希并交给rpc-server的文件缓存，本意只缓存权重，但调度器在两个后端间复制的激活值也走了同一条路。以Qwen3.8-Flash-Next双节点拆分为例，每个超过 10 MB的prefill ubatch都被哈希并写入worker缓存目录，一天后达到 1.4 TB。b10985只对标记为GGML_BACKEND_BUFFER_USAGE_WEIGHTS的缓冲区张量启用哈希路径，并通过SET_TENSOR载荷中的cache_flag字节控制服务端缓存写入，RPC_PROTO_MAJOR_VERSION随之升级。
AI解读：这个修复针对的是llama.cpp的RPC后端缓存行为：ggml_backend_rpc_buffer_set_tensor和ggml_backend_rpc_set_tensor_async原先会对所有超过HASH_THRESHOLD的传输做哈希，再由rpc-server -c从文件缓存中提供。设计意图是缓存权重，但ggml_backend_sched在多个后端之间复制的激活值也被一并缓存。
具体案例来自Qwen3.8-Flash-Next的双节点拆分：每个超过 10 MB的prefill ubatch都被哈希并写入worker的缓存目录，一天后缓存目录达到 1.4 TB。这意味着用RPC拆分大模型做prefill的场景，磁盘会被计算数据而非权重填满。
b10985的改动是把哈希路径限定在标记为GGML_BACKEND_BUFFER_USAGE_WEIGHTS的缓冲区张量上。同时，服务端不再写入所有超过阈值的SET_TENSOR，只保存哈希未命中后收到的那一个张量，即客户端重新发送的权重。
缓存决策现在由SET_TENSOR消息里的cache_flag字节传递，取代服务端的pending_cache状态：客户端在SET_TENSOR_HASH报告未命中时设置该标志，服务端只在标志存在时保存缓存条目。因为线上格式改变，RPC_PROTO_MAJOR_VERSION已升级。
对使用llama.cpp RPC做多节点推理的人来说，这次更新直接解决worker磁盘被激活值占满的问题；但缓存仍然只针对权重，不会缓存调度器在节点间搬运的计算数据，跨后端传输该走网络还是要走网络。
llama.cpp发布b10985，其中一项RPC修复改变了哈希缓存只对权重生效。此前ggml_backend_rpc_buffer_set_tensor和ggml_backend_rpc_set_tensor_async会对超过HASH_THRESHOLD的每一次传输做哈希，再由rpc-server -c从文件缓存提供；该缓存原本是为权重准备的，但ggml_backend_sched在两个后端之间复制的激活值也走了同一条路径。
双节点拆分Qwen3.8-Flash-Next：每个超 10 MB的prefill ubatch都被写入worker缓存，一天后 1.4 TB
提交信息给出的具体场景是Qwen3.8-Flash-Next的两节点拆分：每个超过 10 MB的prefill ubatch都会被哈希、写入worker的缓存目录，之后又从该目录提供。一天后缓存目录达到 1.4 TB。
也就是说，在这类prefill负载下，被缓存的不只是权重，还有调度器在节点间搬运的计算数据，磁盘占用随prefill量增长。
哈希路径限定为权重缓冲区，服务端只保存未命中后重发的那个张量
修复后，只有位于标记为GGML_BACKEND_BUFFER_USAGE_WEIGHTS的缓冲区中的张量才走哈希路径。
第二处改动针对服务端：即使客户端只对权重做哈希，服务端仍会把每个超过HASH_THRESHOLD的SET_TENSOR写入缓存目录。现在服务端记住上一次哈希未命中的SET_TENSOR_HASH的哈希值，只保存随后带着该哈希到来的那一个SET_TENSOR，也就是客户端重新发送的权重。
SET_TENSOR载荷新增cache_flag字节，RPC_PROTO_MAJOR_VERSION升级
服务端不再维护pending_cache状态，缓存决策改由SET_TENSOR消息中的cache_flag字节表示：当SET_TENSOR_HASH报告未命中时客户端设置该标志，服务端只在标志存在时保存缓存条目。
由于线上格式发生变化，RPC_PROTO_MAJOR_VERSION已提升。