LMCache Query Worker Info 接口实战指南查询 KV Cache 集群 Worker 状态【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache导读query_worker_info是 LMCache 缓存控制器cache controller提供的一组接口用于按instance_id与worker_id查询集群中各 KV Cache 工作节点worker的注册信息与心跳状态。本文基于 LMCache 仓库中的 query_worker_info.rst 文档完整讲解该接口的请求/响应格式、示例 YAML 配置、vLLM 与 controller 的启动流程、HTTP 调用方法并结合 registration_controller.py、message.py 与 api_server/main.py 等源码深入剖析接口的底层实现原理。读完本文你将能够独立配置并启动一个带 controller 的 LMCache 实例熟练调用query_worker_info获取 Worker 的 IP、端口、注册时间、心跳时间等关键信息并理解其与GET /controller/workers内部 API 的异同。注意本文档描述的是 LMCache 的in-process 模式已弃用行为。官方建议使用功能更完善、性能更好的 LMCache MP 模式。文中的接口语义Worker 注册信息、心跳、实例管理在 MP 模式中同样成立只是入口与部署形态不同。一、接口定义与核心概念query_worker_info接口的完整签名如下query_worker_info(instance_id: str, worker_ids: List[int]) - event_id: str, worker_infos: List[WorkerInfo]该函数根据instance_id与worker_ids获取指定 worker 的信息controller 在收到请求后返回一个event_id与一组WorkerInfo对象。1.1 关键数据结构WorkerInfo从源码 message.py 可以看到WorkerInfo是一个dataclass字段含义如下字段类型含义instance_idstr所属 LMCache 实例的唯一标识worker_idint实例内的 worker 编号ipstrworker 的 IP 地址portintworker 的监听端口对应配置中的lmcache_worker_portspeer_init_urlOptional[str]P2P 初始化地址对应配置中的p2p_init_ports用于 worker 之间的点对点连接建立registration_timefloat注册时间戳Unix 时间秒last_heartbeat_timefloat最近一次心跳时间戳Unix 时间秒controller 依赖它判断 worker 是否存活1.2 请求消息 QueryWorkerInfoMsg在 controller 内部该接口被封装为QueryWorkerInfoMsg继承自OrchMsg编排类消息其定义见 message.pyclass QueryWorkerInfoMsg(OrchMsg): Query worker info message event_id: str instance_id: str worker_ids: Optional[list[int]] def describe(self) - str: return fQuery worker info of {self.instance_id} : {self.worker_ids}注意这里worker_ids是Optional[list[int]]。从实现来看当worker_ids为空或未提供时controller 会返回该实例下的全部 worker 信息见下文源码分析。二、完整实操配置、启动与调用2.1 第一步创建 LMCache 实例配置文件首先创建一个 YAML 文件example.yaml来配置 LMCache 实例。原文档给出的完整配置如下chunk_size: 256 local_cpu: True max_local_cpu_size: 5 # cache controller configurations enable_controller: True lmcache_instance_id: lmcache_default_instance controller_pull_url: localhost:9001 lmcache_worker_ports: 8001 # Peer identifiers p2p_host: localhost p2p_init_ports: 8200各配置项的作用与取值说明chunk_size: 256KV Cache 分块大小以 token 数为单位。该值决定了缓存项的最小粒度直接影响前缀复用的命中率与存储开销需要与模型实际推理时的 block 大小配合考虑。local_cpu: True启用本地 CPU 内存作为缓存层级。置为True后 KV Cache 除 GPU 外还可以缓存到本地 CPU 内存。max_local_cpu_size: 5本地 CPU 缓存的最大容量单位GB。达到上限后按缓存淘汰策略逐出旧块。enable_controller: True开启缓存控制器。只有开启后实例才会向 controller 注册自身、上报心跳query_worker_info才能查询到该实例的 worker。lmcache_instance_id: lmcache_default_instance当前实例在 controller 侧的唯一标识。query_worker_info的第一个参数即与此对应同一实例的多个 worker 共享该 ID。controller_pull_url: localhost:9001controller 的 PULL 监听地址用于接收 worker 推送的消息必须与下文启动 controller 时的--monitor-port 9001保持一致。lmcache_worker_ports: 8001worker 对外暴露的服务端口该值会登记到 controller 中并出现在WorkerInfo.port字段里。p2p_host: localhost、p2p_init_ports: 8200P2P 对等连接的 host 与初始端口用于 worker 之间建立直连如 KV 传输对应WorkerInfo.peer_init_url字段。2.2 第二步启动 vLLM / LMCache 实例在端口 8000 上启动 vLLM 服务并通过LMCACHE_CONFIG_FILE环境变量加载上面的配置CUDA_VISIBLE_DEVICES0 LMCACHE_CONFIG_FILEexample.yaml vllm serve meta-llama/Llama-3.1-8B-Instruct --max-model-len 4096 \ --gpu-memory-utilization 0.8 --port 8000 --kv-transfer-config {kv_connector:LMCacheConnectorV1, kv_role:kv_both}关键点说明LMCACHE_CONFIG_FILEexample.yamlLMCache 通过该环境变量加载自定义配置未设置时使用默认配置。--kv-transfer-config {kv_connector:LMCacheConnectorV1, kv_role:kv_both}将 vLLM 的 KV 传输层接到 LMCacheConnectorV1kv_role为kv_both同时承担 KV 生产与消费角色这是 LMCache in-process 模式的标准接入方式。模型与显存参数--max-model-len、--gpu-memory-utilization请按实际 GPU 显存调整。2.3 第三步启动 LMCache Controller在端口 9000 启动 controller 主服务、端口 9001 启动 monitor 服务lmcache_controller --host localhost --port 9000 --monitor-port 9001这里--monitor-port 9001与配置文件中的controller_pull_url: localhost:9001对应controller 在 9001 端口上接收来自 worker 的注册与心跳消息在 9000 端口上对外提供 HTTP API包括query_worker_info。2.4 第四步发送查询请求通过 curl 向 controller 发送查询请求curl -X POST http://localhost:9000/query_worker_info \ -H Content-Type: application/json \ -d { instance_id: lmcache_default_instance, worker_ids: [0] }controller 返回的响应形如{event_id: xxx, worker_infos: [{instance_id: lmcache_default_instance, worker_id: 0, ip: 127.0.0.1, port: 8001, peer_init_url: 127.0.0.1:8200, registration_time: 123456, last_heartbeat_time: 456789}]}worker_infos中包含被查询 worker 的完整信息返回的event_id可用于后续查询该操作的状态例如配合check_finish接口使用。2.5 请求参数的灵活用法从源码实现 registration_controller.py 可以看出query_worker_info对参数的处理存在几个隐含约定实战中可直接利用instance_id all查询全部实例下的所有 worker。若同时传入了worker_ids则会先取全量缓存再按worker_id过滤。对应代码如下# Handle special case: instance_id all if msg.instance_id all: worker_infos self.registry.get_all_worker_infos_cached() if msg.worker_ids is not None and len(msg.worker_ids) 0: worker_infos [ worker_info for worker_info in worker_infos if worker_info.worker_id in msg.worker_ids ] return QueryWorkerInfoRetMsg(event_idevent_id, worker_infosworker_infos)worker_ids为空None或[]返回该实例下全部worker 的信息只有显式给出worker_ids时才按 ID 过滤。实例或 worker 不存在不会报错而是记录 warninginstance ... not registered./worker ... not registered.并返回空列表worker_infos调用方需自行判断结果是否为空。三、源码级原理请求在 controller 中的处理链路3.1 HTTP 层 → 编排消息层POST /query_worker_info路由定义在 api_server/main.py。它先为请求生成唯一event_idQueryWorkerInfo str(uuid.uuid4())再构造QueryWorkerInfoMsg交给handle_orchestration_message分发最后将返回的QueryWorkerInfoRetMsg包装成 HTTP 响应app.post(/query_worker_info, response_modelQueryWorkerInfoResponse) async def query_worker_info(req: QueryWorkerInfoRequest): try: event_id QueryWorkerInfo str(uuid.uuid4()) msg QueryWorkerInfoMsg( event_idevent_id, instance_idreq.instance_id, worker_idsreq.worker_ids, ) ret_msg await lmcache_controller_manager.handle_orchestration_message(msg) ... return QueryWorkerInfoResponse( event_idret_msg.event_id, worker_infosret_msg.worker_infos )3.2 编排分发 → 注册控制器LMCacheControllerManager.handle_orchestration_message是 controller 所有编排类消息的总入口controller_manager.py。QueryWorkerInfoMsg被路由到RegistrationController.query_worker_infoelif isinstance(msg, QueryWorkerInfoMsg): return await self.reg_controller.query_worker_info(msg)3.3 注册控制器 → 注册表查询RegistrationController注册控制器负责 worker 的注册、注销、心跳与实例管理其内部维护一个registry注册表。query_worker_info本质上是对注册表的只读查询先按instance_id找到InstanceNode再遍历worker_ids取出每个WorkerNode通过to_worker_info()转换为面向外部 API 的WorkerInfo结构registration_controller.py。值得注意的是注册表的数据由 worker 的心跳持续驱动controller 的health_check线程每隔health_check_interval秒检查一次所有 worker 的last_heartbeat_time若超过lmcache_worker_timeout仍未收到心跳会主动执行deregister将该 worker 从注册表移除controller_manager.py。因此通过query_worker_info查询到的结果可以视为“当前 controller 视角下仍存活的 worker 集合”过期 worker 会在被健康检查清理后不再出现在worker_infos中。3.4 消息序列化Controller 内部的消息采用msgspec进行序列化worker 上报消息使用 MessagePack而来自外部系统如 Mooncake的请求则兼容 JSONcontroller_manager.py。QueryWorkerInfoRetMsg同样是一个OrchRetMsg见 message.py最终通过 HTTP JSON 序列化后返回给调用方。四、补充视角内部 HTTP APIGET /controller/workers除了query_worker_info仓库还提供了另一条查询 worker 信息的内部 HTTP 接口GET /controller/workers实现在 worker_info_api.py。两者对比维度POST /query_worker_infoGET /controller/workers请求方式HTTP POST JSON bodyHTTP GET Query 参数参数instance_id必填、worker_ids可选instance_id、worker_id均可选查询能力指定实例/指定 worker三种粒度全部实例全部 worker / 单实例全部 worker / 单实例单 worker返回字段WorkerInfo六个字段WorkerInfo六字段 key_count该 worker 当前持有的 KV 块数量缺失处理返回空列表返回 404实例/worker 不存在时若你关心某个 worker 当前缓存了多少 KV 块GET /controller/workers的key_count字段通过worker_node.get_kv_count()获取是更直接的选择而query_worker_info作为对外编排接口语义更偏“事件驱动 状态查询”返回的event_id便于与后续状态跟踪接口联动。五、典型应用场景集群健康巡检定期调用query_worker_info或内部接口拉取所有实例的worker_infos检查last_heartbeat_time是否接近当前时间快速定位失联的 KV Cache worker。P2P 拓扑发现peer_init_url字段暴露了 worker 的 P2P 初始化地址如127.0.0.1:8200上层调度器可根据该信息为新的推理请求规划 KV 传输路径或判断哪些 worker 适合建立直连。容量与分布审计结合registration_time注册时间与port/ip字段可还原实例的扩缩容历史配合内部接口的key_count评估各 worker 的 KV 负载分布。配合其他 controller 接口event_id可与check_finish等接口联动构成“发起操作 → 查询状态”的异步控制流适用于大规模集群下的编排场景。六、总结query_worker_info是 LMCache 缓存控制器对外提供的一个轻量、只读的 Worker 状态查询接口它把分布在集群各节点上的 KV Cache worker 的注册信息、P2P 地址与心跳状态统一收敛到 controller并以(event_id, worker_infos)的结构化形式返回。从源码链路看一次查询经历HTTP 路由 → 编排消息分发 → 注册表查询三个层次最终结果由心跳机制持续保鲜。掌握该接口是理解 LMCache 多实例部署、进行集群健康监控与 P2P 拓扑管理的基础一步更长期的方案请参考仓库文档中的 LMCache MP 模式 相关章节。参考文件索引接口定义文档docs/source/kv_cache_management/query_worker_info.rstWorkerInfo与消息定义lmcache/v1/cache_controller/message.pyquery_worker_info核心实现lmcache/v1/cache_controller/controllers/registration_controller.py编排消息分发lmcache/v1/cache_controller/controller_manager.pyHTTP 路由实现lmcache/v1/api_server/main.py内部 APIGET /controller/workerslmcache/v1/internal_api_server/controller/worker_info_api.py健康检查与心跳超时清理lmcache/v1/cache_controller/controller_manager.py【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LMCache Query Worker Info 接口实战指南：查询 KV Cache 集群 Worker 状态
LMCache Query Worker Info 接口实战指南查询 KV Cache 集群 Worker 状态【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache导读query_worker_info是 LMCache 缓存控制器cache controller提供的一组接口用于按instance_id与worker_id查询集群中各 KV Cache 工作节点worker的注册信息与心跳状态。本文基于 LMCache 仓库中的 query_worker_info.rst 文档完整讲解该接口的请求/响应格式、示例 YAML 配置、vLLM 与 controller 的启动流程、HTTP 调用方法并结合 registration_controller.py、message.py 与 api_server/main.py 等源码深入剖析接口的底层实现原理。读完本文你将能够独立配置并启动一个带 controller 的 LMCache 实例熟练调用query_worker_info获取 Worker 的 IP、端口、注册时间、心跳时间等关键信息并理解其与GET /controller/workers内部 API 的异同。注意本文档描述的是 LMCache 的in-process 模式已弃用行为。官方建议使用功能更完善、性能更好的 LMCache MP 模式。文中的接口语义Worker 注册信息、心跳、实例管理在 MP 模式中同样成立只是入口与部署形态不同。一、接口定义与核心概念query_worker_info接口的完整签名如下query_worker_info(instance_id: str, worker_ids: List[int]) - event_id: str, worker_infos: List[WorkerInfo]该函数根据instance_id与worker_ids获取指定 worker 的信息controller 在收到请求后返回一个event_id与一组WorkerInfo对象。1.1 关键数据结构WorkerInfo从源码 message.py 可以看到WorkerInfo是一个dataclass字段含义如下字段类型含义instance_idstr所属 LMCache 实例的唯一标识worker_idint实例内的 worker 编号ipstrworker 的 IP 地址portintworker 的监听端口对应配置中的lmcache_worker_portspeer_init_urlOptional[str]P2P 初始化地址对应配置中的p2p_init_ports用于 worker 之间的点对点连接建立registration_timefloat注册时间戳Unix 时间秒last_heartbeat_timefloat最近一次心跳时间戳Unix 时间秒controller 依赖它判断 worker 是否存活1.2 请求消息 QueryWorkerInfoMsg在 controller 内部该接口被封装为QueryWorkerInfoMsg继承自OrchMsg编排类消息其定义见 message.pyclass QueryWorkerInfoMsg(OrchMsg): Query worker info message event_id: str instance_id: str worker_ids: Optional[list[int]] def describe(self) - str: return fQuery worker info of {self.instance_id} : {self.worker_ids}注意这里worker_ids是Optional[list[int]]。从实现来看当worker_ids为空或未提供时controller 会返回该实例下的全部 worker 信息见下文源码分析。二、完整实操配置、启动与调用2.1 第一步创建 LMCache 实例配置文件首先创建一个 YAML 文件example.yaml来配置 LMCache 实例。原文档给出的完整配置如下chunk_size: 256 local_cpu: True max_local_cpu_size: 5 # cache controller configurations enable_controller: True lmcache_instance_id: lmcache_default_instance controller_pull_url: localhost:9001 lmcache_worker_ports: 8001 # Peer identifiers p2p_host: localhost p2p_init_ports: 8200各配置项的作用与取值说明chunk_size: 256KV Cache 分块大小以 token 数为单位。该值决定了缓存项的最小粒度直接影响前缀复用的命中率与存储开销需要与模型实际推理时的 block 大小配合考虑。local_cpu: True启用本地 CPU 内存作为缓存层级。置为True后 KV Cache 除 GPU 外还可以缓存到本地 CPU 内存。max_local_cpu_size: 5本地 CPU 缓存的最大容量单位GB。达到上限后按缓存淘汰策略逐出旧块。enable_controller: True开启缓存控制器。只有开启后实例才会向 controller 注册自身、上报心跳query_worker_info才能查询到该实例的 worker。lmcache_instance_id: lmcache_default_instance当前实例在 controller 侧的唯一标识。query_worker_info的第一个参数即与此对应同一实例的多个 worker 共享该 ID。controller_pull_url: localhost:9001controller 的 PULL 监听地址用于接收 worker 推送的消息必须与下文启动 controller 时的--monitor-port 9001保持一致。lmcache_worker_ports: 8001worker 对外暴露的服务端口该值会登记到 controller 中并出现在WorkerInfo.port字段里。p2p_host: localhost、p2p_init_ports: 8200P2P 对等连接的 host 与初始端口用于 worker 之间建立直连如 KV 传输对应WorkerInfo.peer_init_url字段。2.2 第二步启动 vLLM / LMCache 实例在端口 8000 上启动 vLLM 服务并通过LMCACHE_CONFIG_FILE环境变量加载上面的配置CUDA_VISIBLE_DEVICES0 LMCACHE_CONFIG_FILEexample.yaml vllm serve meta-llama/Llama-3.1-8B-Instruct --max-model-len 4096 \ --gpu-memory-utilization 0.8 --port 8000 --kv-transfer-config {kv_connector:LMCacheConnectorV1, kv_role:kv_both}关键点说明LMCACHE_CONFIG_FILEexample.yamlLMCache 通过该环境变量加载自定义配置未设置时使用默认配置。--kv-transfer-config {kv_connector:LMCacheConnectorV1, kv_role:kv_both}将 vLLM 的 KV 传输层接到 LMCacheConnectorV1kv_role为kv_both同时承担 KV 生产与消费角色这是 LMCache in-process 模式的标准接入方式。模型与显存参数--max-model-len、--gpu-memory-utilization请按实际 GPU 显存调整。2.3 第三步启动 LMCache Controller在端口 9000 启动 controller 主服务、端口 9001 启动 monitor 服务lmcache_controller --host localhost --port 9000 --monitor-port 9001这里--monitor-port 9001与配置文件中的controller_pull_url: localhost:9001对应controller 在 9001 端口上接收来自 worker 的注册与心跳消息在 9000 端口上对外提供 HTTP API包括query_worker_info。2.4 第四步发送查询请求通过 curl 向 controller 发送查询请求curl -X POST http://localhost:9000/query_worker_info \ -H Content-Type: application/json \ -d { instance_id: lmcache_default_instance, worker_ids: [0] }controller 返回的响应形如{event_id: xxx, worker_infos: [{instance_id: lmcache_default_instance, worker_id: 0, ip: 127.0.0.1, port: 8001, peer_init_url: 127.0.0.1:8200, registration_time: 123456, last_heartbeat_time: 456789}]}worker_infos中包含被查询 worker 的完整信息返回的event_id可用于后续查询该操作的状态例如配合check_finish接口使用。2.5 请求参数的灵活用法从源码实现 registration_controller.py 可以看出query_worker_info对参数的处理存在几个隐含约定实战中可直接利用instance_id all查询全部实例下的所有 worker。若同时传入了worker_ids则会先取全量缓存再按worker_id过滤。对应代码如下# Handle special case: instance_id all if msg.instance_id all: worker_infos self.registry.get_all_worker_infos_cached() if msg.worker_ids is not None and len(msg.worker_ids) 0: worker_infos [ worker_info for worker_info in worker_infos if worker_info.worker_id in msg.worker_ids ] return QueryWorkerInfoRetMsg(event_idevent_id, worker_infosworker_infos)worker_ids为空None或[]返回该实例下全部worker 的信息只有显式给出worker_ids时才按 ID 过滤。实例或 worker 不存在不会报错而是记录 warninginstance ... not registered./worker ... not registered.并返回空列表worker_infos调用方需自行判断结果是否为空。三、源码级原理请求在 controller 中的处理链路3.1 HTTP 层 → 编排消息层POST /query_worker_info路由定义在 api_server/main.py。它先为请求生成唯一event_idQueryWorkerInfo str(uuid.uuid4())再构造QueryWorkerInfoMsg交给handle_orchestration_message分发最后将返回的QueryWorkerInfoRetMsg包装成 HTTP 响应app.post(/query_worker_info, response_modelQueryWorkerInfoResponse) async def query_worker_info(req: QueryWorkerInfoRequest): try: event_id QueryWorkerInfo str(uuid.uuid4()) msg QueryWorkerInfoMsg( event_idevent_id, instance_idreq.instance_id, worker_idsreq.worker_ids, ) ret_msg await lmcache_controller_manager.handle_orchestration_message(msg) ... return QueryWorkerInfoResponse( event_idret_msg.event_id, worker_infosret_msg.worker_infos )3.2 编排分发 → 注册控制器LMCacheControllerManager.handle_orchestration_message是 controller 所有编排类消息的总入口controller_manager.py。QueryWorkerInfoMsg被路由到RegistrationController.query_worker_infoelif isinstance(msg, QueryWorkerInfoMsg): return await self.reg_controller.query_worker_info(msg)3.3 注册控制器 → 注册表查询RegistrationController注册控制器负责 worker 的注册、注销、心跳与实例管理其内部维护一个registry注册表。query_worker_info本质上是对注册表的只读查询先按instance_id找到InstanceNode再遍历worker_ids取出每个WorkerNode通过to_worker_info()转换为面向外部 API 的WorkerInfo结构registration_controller.py。值得注意的是注册表的数据由 worker 的心跳持续驱动controller 的health_check线程每隔health_check_interval秒检查一次所有 worker 的last_heartbeat_time若超过lmcache_worker_timeout仍未收到心跳会主动执行deregister将该 worker 从注册表移除controller_manager.py。因此通过query_worker_info查询到的结果可以视为“当前 controller 视角下仍存活的 worker 集合”过期 worker 会在被健康检查清理后不再出现在worker_infos中。3.4 消息序列化Controller 内部的消息采用msgspec进行序列化worker 上报消息使用 MessagePack而来自外部系统如 Mooncake的请求则兼容 JSONcontroller_manager.py。QueryWorkerInfoRetMsg同样是一个OrchRetMsg见 message.py最终通过 HTTP JSON 序列化后返回给调用方。四、补充视角内部 HTTP APIGET /controller/workers除了query_worker_info仓库还提供了另一条查询 worker 信息的内部 HTTP 接口GET /controller/workers实现在 worker_info_api.py。两者对比维度POST /query_worker_infoGET /controller/workers请求方式HTTP POST JSON bodyHTTP GET Query 参数参数instance_id必填、worker_ids可选instance_id、worker_id均可选查询能力指定实例/指定 worker三种粒度全部实例全部 worker / 单实例全部 worker / 单实例单 worker返回字段WorkerInfo六个字段WorkerInfo六字段 key_count该 worker 当前持有的 KV 块数量缺失处理返回空列表返回 404实例/worker 不存在时若你关心某个 worker 当前缓存了多少 KV 块GET /controller/workers的key_count字段通过worker_node.get_kv_count()获取是更直接的选择而query_worker_info作为对外编排接口语义更偏“事件驱动 状态查询”返回的event_id便于与后续状态跟踪接口联动。五、典型应用场景集群健康巡检定期调用query_worker_info或内部接口拉取所有实例的worker_infos检查last_heartbeat_time是否接近当前时间快速定位失联的 KV Cache worker。P2P 拓扑发现peer_init_url字段暴露了 worker 的 P2P 初始化地址如127.0.0.1:8200上层调度器可根据该信息为新的推理请求规划 KV 传输路径或判断哪些 worker 适合建立直连。容量与分布审计结合registration_time注册时间与port/ip字段可还原实例的扩缩容历史配合内部接口的key_count评估各 worker 的 KV 负载分布。配合其他 controller 接口event_id可与check_finish等接口联动构成“发起操作 → 查询状态”的异步控制流适用于大规模集群下的编排场景。六、总结query_worker_info是 LMCache 缓存控制器对外提供的一个轻量、只读的 Worker 状态查询接口它把分布在集群各节点上的 KV Cache worker 的注册信息、P2P 地址与心跳状态统一收敛到 controller并以(event_id, worker_infos)的结构化形式返回。从源码链路看一次查询经历HTTP 路由 → 编排消息分发 → 注册表查询三个层次最终结果由心跳机制持续保鲜。掌握该接口是理解 LMCache 多实例部署、进行集群健康监控与 P2P 拓扑管理的基础一步更长期的方案请参考仓库文档中的 LMCache MP 模式 相关章节。参考文件索引接口定义文档docs/source/kv_cache_management/query_worker_info.rstWorkerInfo与消息定义lmcache/v1/cache_controller/message.pyquery_worker_info核心实现lmcache/v1/cache_controller/controllers/registration_controller.py编排消息分发lmcache/v1/cache_controller/controller_manager.pyHTTP 路由实现lmcache/v1/api_server/main.py内部 APIGET /controller/workerslmcache/v1/internal_api_server/controller/worker_info_api.py健康检查与心跳超时清理lmcache/v1/cache_controller/controller_manager.py【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考