人工智能大模型模型推理服务后端【免费下载链接】MooncakeMooncake is the serving platform for Kimi, a leading LLM service provided by Moonshot AI.项目地址https://gitcode.com/gh_mirrors/mo/Mooncake点击查看免费下载本文以 Mooncake 仓库中的 Conductor 设计文档架构设计、KV 事件发布者设计、KV 事件订阅者指南为主体结合 mooncake-conductor 的 C 源码实现与 Indexer HTTP API 参考系统讲解 Mooncake Conductor 的架构、数据模型、事件流/查询流、动态注册与配置以及 KV 事件在发布者与订阅者两侧的完整协议与故障恢复策略。读完本文你将能理解缓存感知路由器如何回答该请求前缀在哪个实例、哪个缓存层级上有最佳可复用 KV 缓存这一调度问题并掌握 Conductor 的部署、注册、查询与 KV 事件订阅的完整实战方法。Conductor 是什么定位与设计目标Mooncake Conductor 是 Mooncake 平台中供缓存感知路由器cache-aware router使用的KV 缓存索引器KV-cache indexer。它订阅来自推理引擎或存储后端的 KV 缓存事件将这些事件归一化维护一张全局前缀缓存表并通过 HTTP API 暴露动态服务注册与缓存命中查询能力。其核心设计目标非常聚焦让路由器回答一个简单的调度问题——对于当前请求前缀哪个已注册实例拥有最好的可复用 KV 缓存局部性该前缀又存在于哪些缓存层级cache tier上Conductor 自身不参与推理、不存储 KV 数据它只维护哪些前缀在哪些实例的哪些介质上可用这一元数据视图供路由器做出缓存感知的转发决策。在 Mooncake 的典型部署中Conductor 作为独立进程运行mooncake_conductor位于网关/路由器与推理/存储服务之间消费 vLLM、SGLang、Mooncake Store master 等发布者产出的 KV 事件流。相关设计文档入口见 Conductor 索引页。总体架构与核心组件架构图设计文档给出了如下组件关系图组件职责组件职责EventManager拥有 Conductor 生命周期、HTTP 服务器、动态注册、活跃服务映射active service map以及租户到实例映射tenant-to-instance map。ZMQClient连接发布者端点消费事件帧解码事件批次追踪序列号并在重连后请求回放replay。KVEventHandler将解码后的引擎事件适配为带注册元数据的 Conductor store/remove 事件。PrefixCacheTable维护按模型上下文ModelContext划分的前缀映射、引擎哈希到 Conductor 哈希的映射、medium 元数据、DP-rank 元数据以及查询时的命中计算。源码级佐证C 实现与组件一一对应设计文档描述的组件在 mooncake-conductor 的 C 实现中可逐一对应进程入口src/main.cpp初始化 glog、解析日志级别随后调用ParseConfig读取静态配置构造EventManager依次启动 HTTP 服务器与 RPC 服务器并注册SIGINT/SIGTERM信号处理完成优雅退出。EventManagerinclude/conductor/kvevent/event_manager.h 中声明的EventManager内部持有subscribers_instance_idtenant_iddp_rank→ZMQClient、handlers_→KVEventHandler、active_endpoints_、active_configs_以及prefixindex::PrefixCacheTable indexer_与设计文档中每个(instance_id, tenant_id, dp_rank)服务键创建一个 ZMQClient的描述一致MakeServiceKey在 event_manager.h。KVEventHandler同一头文件 event_manager.h 中定义实现了zmq::EventHandler接口并针对 vLLM、SGLang、Mooncake 三种发布者分别提供HandleVllm*、HandleSglang*、HandleMooncake*系列处理方法OnSourceStale在无法恢复到无间隙序列时整体作废该来源贡献的索引条目等待全量重新同步。PrefixCacheTableinclude/conductor/prefixindex/prefix_indexer.h 中提供Register/Unregister/StoreEngine/RemoveEngine/ClearEngine/StoreShared/RemoveShared/ClearShared/Query等完整索引接口。数据模型ModelContext 与三层索引前缀索引的作用域前缀索引以ModelContext为作用域(tenant_id, model_name, lora_name, block_size, additional_salt, instance_id)也就是说同一个前缀在不同模型、不同 LoRA、不同 block_size、不同租户、不同 salt 命名空间下是完全隔离的互不干扰。每个上下文内维护的数据在每个上下文内部Conductor 存储三类数据引擎块哈希 → Conductor 前缀哈希的映射engine-provided block hash 到 Conductor prefix hash前缀哈希映射记录副本数量replica count、medium 集合、DP-rank 集合以及每个实例的访问元数据per-instance access metadataDP-rank 集合用于汇报 rank 级别的命中信息。从源码看ContextStateprefix_indexer.h内部持有blocksProjectedPrefix→BlockPresence、按写入顺序维护的write_order列表用于容量驱逐、max_blocks上限与累计驱逐计数evicted_by_capacity。其中BlockPresenceprefix_indexer.h细分为四类 ownernpu_owners、cpu_local_owners、cpu_share_owners、disk_owners——对应 Indexer API 中的 G1 Device PoolGPU/NPU、G2 Host PoolCPU 本地与共享注册内存、G3 Disk Pool 三级逻辑介质。默认每个上下文最多追踪kDefaultMaxBlocks 200000个前缀prefix_indexer.h容量达到阈值时按kEvictTargetRatio 0.9的目标占用率做批量容量驱逐。vLLM 与 SGLang 的哈希策略差异设计文档特别强调了两类引擎在前缀哈希上的关键差异vLLM 策略只对完整块计算前缀哈希/query时忽略末尾不完整的部分块SGLang 策略把末尾不完整的部分块也纳入哈希因此命中延伸到部分块时报告的是请求实际携带的 token 数而永远不是整块数。这一差异直接影响路由器的命中语义解读命中长度单位是 token 数而不是块数。仓库测试 compute_hash_test.cpp 与hash_strategy相关实现即围绕这两类哈希策略展开测试夹具fixtures中还包含verify_fixture_against_vllm.py等脚本用于与 vLLM 侧的哈希结果做交叉校验。事件流与查询流事件流Event flow服务通过conductor_config.json静态注册或通过POST /register动态注册EventManager为每个(instance_id, tenant_id, dp_rank)服务键创建一个ZMQClientZMQClient订阅发布者端点按[topic, sequence, payload]三帧形式消费事件payload 被解码为一批引擎事件。当前实现的解析器支持 vLLM 的BlockStored与BlockRemovedmsgpack 事件对应测试见 msg_decoder_test.cpp 与 zmq_client_test.cppKVEventHandler用注册元数据模型、LoRA、租户、实例、block size、additional salt丰富事件内容PrefixCacheTable对 store/remove 的块更新前缀映射若重连时发现序列号出现缺口可借助replay endpoint请求补发错过的历史事件。查询流Query flow路由器获取提示词 token ID通常来自引擎的 tokenizer 端点路由器调用POST /query携带model、token_ids、block_size可选tenant_id、instance_id、lora_name、cache_saltConductor 为请求计算完整块的前缀哈希按顺序扫描前缀表遇到第一个 miss 立即终止扫描从而保证前缀连续性prefix continuity不被破坏Conductor 返回每个实例的longest_matched、各 medium 命中数与 DP-rank 命中数路由器据此选出最优目标实例并转发请求。查询的返回值结构在源码CacheHitResultprefix_indexer.h中有完整定义longest_match_tokens、按 DP rank 聚合的dp映射、按 rank 细分的rank_matches以及npu/cpu_local/cpu_share/disk四类介质各自的命中 token 数。动态注册与静态配置动态注册POST /registerConductor 支持运行时注册路由或控制平面无需重启进程即可增删 KV 事件发布者。注册请求体如下{ endpoint: tcp://127.0.0.1:5557, replay_endpoint: tcp://127.0.0.1:5558, type: vLLM, modelname: qwen2.5, lora_name: , tenant_id: default, instance_id: vllm-prefill-node1, block_size: 128, dp_rank: 0, additionalsalt: }静态配置kvevent_instance静态配置使用相同字段但位于kvevent_instance之下键名即实例 ID{ http_server_port: 13333, kvevent_instance: { vllm-prefill-node1: { endpoint: tcp://127.0.0.1:5557, replay_endpoint: tcp://127.0.0.1:5558, type: vLLM, modelname: qwen2.5, lora_name: , tenant_id: default, instance_id: vllm-prefill-node1, block_size: 128, dp_rank: 0, additionalsalt: } } }源码级解析细节配置解析实现在 src/kvevent/config.cpp几个容易踩坑的细节值得注意配置文件缺失不退出文件打不开时仅打 WARNING 并以空服务列表继续运行但JSON 解析失败会exit(1)未知服务类型跳过type无法识别时记录 ERROR 并跳过该条目tenant_id缺省为defaultinstance_id缺省取配置对象的键名即上面的vllm-prefill-node1block_size、dp_rank必须为合法整数dp_rank需在[0, INT_MAX]范围内否则该条目不生效除设计文档列出的字段外解析器还支持cache_group目前仅接受值为0或 null与hash_profile必含strategy、algorithm、index_projection三个字符串字段SGLang 策略下python_hash_seed可选其余策略下必填字段白名单之外的键会被拒绝。hash_profile在静态配置解析阶段即完成配方根哈希的解析ResolveHashProfile保证任何服务在订阅前都已绑定经过校验的哈希方案无法以未解析/伪造的根参与索引。环境变量与端口设计文档给出的环境变量如下变量默认值说明CONDUCTOR_LOG_LEVELINFO日志级别DEBUG、INFO、WARN或ERROR。CONDUCTOR_CONFIG_PATH~/.mooncake/conductor_config.json静态配置文件路径。CONDUCTOR_SEED随机用于哈希计算实验的遗留种子选项。端口方面从 src/main.cpp 可以看到实现细节HTTP 服务器端口默认 13333可由配置文件的http_server_port覆盖注意配置中缺省该字段时端口会被置为 0行为与文档示例中的显式配置不同RPC 服务器端口默认 13334coro_rpc 通道配置文件可覆盖显式设置为0则关闭 RPC 通道StartRPCServer在rpc_server_port0时是空操作。构建与运行设计文档给出的构建流程Go 版如下cd mooncake-conductor/conductor-ctrl go mod tidy go build -o mooncake_conductor .运行export CONDUCTOR_CONFIG_PATH../example/conductor_config.json export CONDUCTOR_LOG_LEVELINFO ./mooncake_conductor需要说明的是设计文档中的conductor-ctrl/目录结构属于早期 Go 实现的组织方式当前仓库 mooncake-conductor 中的实际实现为 C入口为 src/main.cpp目录组织与文档中的模块划分保持一致mooncake-conductor/ -- include/conductor/ | -- client/ # conductor client 与类型定义 | -- common/ # 共享类型、工具 | -- kvevent/ # EventManager、KVEventHandler、ConductorService、config | -- prefixindex/ # 前缀缓存表与命中计算hash_strategy、prefix_indexer | -- zmq/ # ZMQ client、事件解码、事件类型 -- src/ # 与 include 对应的实现以及 main.cpp 进程入口 -- tests/ # e2e、单元测试与哈希 golden 向量夹具 -- CMakeLists.txt设计文档中的 Indexer API 文档进一步给出了 HTTP API 与 KV Events 线上格式的完整规范。发布者视角Mooncake Store KV Event Publisherpublisher-design.md 描述了Mooncake Store master 侧的 KV 事件发布器设计。发布者的目标是对外发布逻辑缓存可用性而把物理副本管理保留在内部实现沿用既有 RFC #1527 map 协议支持stored、removed、cleared三类事件本身不包含索引器、回放服务或 Conductor这些属于消费者侧的组件。传输协议master 绑定一个 ZeroMQPUBsocket。每条 multipart 消息为一个空 topic 帧一个8 字节无符号 64 位大端传输序列号一个 msgpack payload[timestamp_ms, [event_maps], dp_rank]。发布是异步的。一个有界的进程内队列在满时丢弃最旧事件并保留这些事件本应占用的序列号缺口让订阅者能够检测到丢失。相关 master 配置项enable_kv_eventskv_events_bind_endpointkv_events_backend_idkv_events_model_namekv_events_block_sizekv_events_additional_saltkv_events_lora_namekv_events_dp_rankkv_events_emit_object_keykv_events_emit_legacy_compatkv_events_queue_capacity该特性仅在ENABLE_KV_EVENTSON时编译在无 ZMQ 的构建中公开客户端 API 仍可用但事件元数据相关调用退化为 no-op。对象与介质状态模型事件身份由backend_id、tenant_id、object_key三元组标识medium是单个字符串cpu或disk。若对象同时存在于两个层级发布者按层级各发一条事件副本类型被折叠到两个逻辑层级内存副本映射为cpu所有非内存副本类型disk、local disk、NOF SSD、DFS映射为disk。订阅者按存储类别看到一条记录无需感知 Mooncake 内部可增长的副本分类体系副本分类演进不需要改协议。副本拓扑被归一化为介质可用性某介质上第一个完成副本 → 发stored某介质上最后一个完成副本被移除 → 发removed可用介质内部副本数量/位置变化 →不发事件一次成功的 Put/Upsert 提交 → 对当前每个介质都发stored。无状态设计与before 集合责任发布者不持有任何按对象的状态。每个增量都由单次调用的参数计算得出变更后的介质集合 调用者在变更前捕获的集合。master 在变更元数据前本来就会对集合做快照因此发布者再保留一份副本属于重复而按对象维护 map 则会遮蔽 master 的整个键空间。这使得before 集合的责任落在调用方先改元数据再发布、却没有快照的路径无法产生正确的增量这正是整个 master 中快照与发布调用必须位于同一函数内的原因。重复 removed 的处理发布者不抑制重复的removed事件。当同一移除可能被到达两次时例如驱逐掉最后一个副本、随后擦除已失效对象master 只选择一个发布点而非两个驱逐路径在对象不再有效时提前返回把宣告留给擦除路径。订阅者侧同时将removed视为幂等因此重复是无害的而不是需要负载承担的问题。事件载荷字段发布者是刻意**键无关key-agnostic**的Store 从不解析、拆分或解释对象键因此没有任何键格式被特权化也没有任何连接器需要 Mooncake 专属的键约定。原始 Store 键原样透传为object_key所有需要解释该键的字段保持为空seq_hashes与遗留字段block_hashes发空数组stored上token_ids与parent_hash为 nilbase_block_idx在stored与removed上均为 nilgroup_id携带 Store 组身份而非连接器组字段。cleared事件是仅含信封的它完全省略object_key、group_id、seq_hashes、block_hashes、base_block_idx字段而不是以 nil 发出。其余信封字段来自 master 配置因为一个发布者服务于一个固定的模型、块大小、LoRA、additional-salt 与数据并行上下文model_name、block_size、additional_salt、lora_name、dp_rank。block_size0编码为 nil空 salt 与空 LoRA 名同理。配置的dp_rank同时出现在每个事件信封与批次尾部。按对象的tenant_id来自 Store 操作本身而非全局租户配置。设置kv_events_emit_object_keyfalse会整体抑制stored与removed没有键就没有订阅者可行动的标识被抑制的事件计入skipped_keyless_eventscleared不受影响因为它按租户作用域不需要对象身份。设置kv_events_emit_legacy_compattrue默认值时每个事件还携带一个遗留type别名与event_type并存BlockStored、BlockRemoved、AllBlocksCleared遗留模式还追加block_hashes数组以及stored上的 nilparent_block_hash。这让按 RFC 之前字段名编写的订阅者可以不加修改地消费同一数据流。需要块级或分片级语义的订阅者必须从键本身并结合产出该键的连接器约定与自身注册的拓扑来推导发布者不知道是哪个连接器写了某个键、一个块跨越多少层/分片或某个块在前缀链中处于多深。发布点一览操作事件行为Put/BatchPut 提交对所有已完成介质发stored对已存在对象的 Upsert旧值不可读时发removed提交时对所有已完成介质发storedCopy/Move 完成介质可用性增量Offload/promotion 完成目标介质首次出现时发stored副本清除或驱逐介质上最后一个副本消失时发removed过期句柄/客户端清理介质可用性增量Remove/BatchRemove/正则 remove对每个可用介质发removedRemoveAll逐对象发removed所有对象均被移除后发租户级cleared失败的未提交新 Put不发事件cleared使用mediumnil清除指定backend_id tenant_id的全部介质。它只在租户确实持有对象且没有任何对象被跳过时发出从未存在过的租户不产生clearedRemoveAll留下仍被 lease 的对象时也不产生cleared。HA oplog 场景下元数据擦除延后到持久化回调中执行因此该判定基于移除循环实际接受的结果而非元数据 map 是否看起来为空。每个跳过都计入包括不那么明显的副本未全部完成的对象、有挂起复制任务的对象、oplog 槽位预留失败、oplog append 失败等。发布者局限发布器是PUB-only它不回放错过的历史事件、不发布启动快照、不持久化其紧凑上下文缓存。订阅者必须自行检测传输序列缺口并通过自己的对账路径恢复。由于紧凑上下文是进程内的且不持久化master 重启会重置它此前已知对象的首条事件是全新的stored而非增量。发布者启动前已恢复的对象只能用租户、backend、固定的发布者上下文与对象键来描述。订阅者视角KV Event Subscriber Guidesubscriber-guide.md 面向需要消费 Mooncake Store KV 事件流的开发者是接入侧的核心操作手册。传输与消息格式事件通过 ZMQPUBsocket 到达为三帧 multipart 消息帧内容0Topic。恒为空但恒存在。1无符号 64 位大端序列号8 字节。2MessagePack payload。payload 是 3 元素数组[timestamp_ms, [event_map, ...], dp_rank]。一条消息最多携带 64 个事件因此订阅者必须遍历中间元素而不能假设一消息一事件。事件信封每个事件 map 包含以下字段字段类型event_idu64按发布者进程单调递增timestampi64毫秒event_typestored、removed或clearedmodel_namestring 或 nilblock_sizeu32配置为 0 时为 niladditional_saltstring 或 nillora_namestring 或 niltenant_idstringbackend_idstringmediumstring 或 nildp_ranku32stored与removed额外携带group_id、object_key除非kv_events_emit_object_keyfalse、seq_hashes、base_block_idxstored还额外携带parent_hash与token_ids。键不被解释与发布者设计一致Store 从不解析/拆分/解释对象键原始 Store 键原样透传为object_key需要解释键的字段恒为空或 nilseq_hashes与遗留block_hashes恒为空数组stored的token_ids、parent_hash恒为 nilbase_block_idx恒为 nil。需要块级身份的订阅者必须依据生产者应用的约定从object_key自行推导不要指望 Mooncake 提供块哈希、token ID 或块深度。介质语义medium归一化为恰好两个逻辑层级cpu表示内存副本disk表示所有非内存类别本地盘、NVMe-oF、DFS。一条事件只命名一个介质。三类事件的正确消费语义stored宣告对象在该事件的介质上可读。把同一对象/backend/介质上的重复stored视为幂等不要从事件数量推断物理副本数。对已存在对象的 Upsert 会先对旧值发removed、再对新值发stored按此顺序没有单独的 update 事件。removed只收回该事件介质上的可用性。同一对象的其他介质可能仍然有效因此只有所有介质都不再存在时才应整体删除对象。重复removed视为幂等发布者不去重收回因此按介质做引用计数而非存集合的订阅者可能减到负数——建议存集合。cleared仅信封省略object_key、group_id、seq_hashes、block_hashes、base_block_idx不是 nil并携带mediumnil。它表示事件backend_id tenant_id下的所有对象都已消失。Mooncake 仅在RemoveAll真正清空租户时发出对从未持有对象的租户不发有任何对象被跳过例如无force的仍被 lease 对象也不发。遗留兼容kv_events_emit_legacy_compattrue默认时每个事件还带type字段event_type遗留typestoredBlockStoredremovedBlockRemovedclearedAllBlocksCleared按对象的事件还额外携带空block_hashes数组stored携带 nilparent_block_hash。将该标志设为false则只发出 RFC #1527 字段名。排序、丢失与恢复发布者运行期间序列号严格单调且无间隙。用帧 1 做传输层排序用event_id做事件流内排序。序列缺口意味着事件被丢弃发布者异步队列满时丢弃最旧事件并保留它们本应使用的序列号因此缺口总是可见的而不是静默的。看到缺口后订阅者要么作废受影响的backend_id tenant_id状态要么与 master 对账master 是键放置的权威来源。没有回放端点、没有启动快照对象已存储后才加入的订阅者收不到任何历史。发布者状态是进程内的且不持久化因此master 重启会把序列计数器重置为 1且不发出重置信号依赖单调序列过滤的订阅者必须准备好计数器回退应对 master 对账而不是丢弃新事件。可观测性master admin 端口的GET /kv_events/status上报字段含义enabled发布者是否存活published_batches已发送的 ZMQ 消息数published_events这些消息内的总事件数dropped_events满队列丢弃的事件数每个丢弃都会留下一个序列缺口skipped_keyless_events因无object_key而被抑制的按对象事件数当kv_events_emit_object_keyfalse时出现非零的skipped_keyless_events是预期行为该标志抑制全部stored与removed只留cleared。索引器 HTTP API 速览conductor-indexer.md 是 Conductor 的线上契约规范与设计文档配套使用核心接口包括POST /register注册 KV 事件发布者并开始消费endpoint、type、modelname、instance_id、block_size、dp_rank必填replay_endpoint、lora_name、tenant_id、additionalsalt可选POST /unregister按(instance_id, tenant_id, dp_rank)停止消费POST /query按 token IDs 查询缓存命中返回按实例的longest_matched、各介质GPU/CPU/DISK与DPrank 命中数POST /query_by_hash按预计算的滚动序列哈希查询longest_matched block_size * matched_hash_count避免在网络上传输长 token 列表。标准化的哈希方案为XXH3-64本地块哈希为XXH3(token_bytes_le, S)滚动序列哈希为seq_hash[i] XXH3(seq_hash[i-1]_le || local_block_hash[i]_le, S)所有 KV Events API 使用的都是滚动序列哈希相等的前缀直到第一个不同块为止产生相等的哈希。在解耦部署推理 worker Mooncake 主机/磁盘池中全局索引器需要合并三个事实来源SGLang引擎 ZMQ 事件GPU/HiCache 层、token、parent_hash、seq_hashes、lora、Mooncake master的可选 RFC #1527 发布器主机/磁盘池mediumcpu|disk、POST /registerinstance_id、model、block_size。注意instance_id与backend_id语义不同前者是路由器面向的调度目标Indexer API后者是事件流中的缓存所有者KV Events API。测试与验证仓库 mooncake-conductor/tests 为上述机制提供了可运行的验证用例适合作为接入开发时的参考与回归保障e2eclient_server_e2e_test.cpp 覆盖客户端到 Conductor 服务端的完整链路哈希compute_hash_test.cpp 结合 fixtures/hash_golden_vectors.json 与 verify_fixture_against_vllm.py 对哈希向量做 golden 校验索引与查询prefix_indexer_test.cpp、model_context_test.cpp事件与 ZMQevent_manager_test.cpp、msg_decoder_test.cpp、zmq_client_test.cpp。总结Mooncake Conductor 是缓存感知路由体系中承上启下的索引层向下它以 ZMQ SUB/DEALER 订阅 vLLM、SGLang、Mooncake Store master 等发布者的 KV 事件通过KVEventHandler归一化并富化元数据向上它以ModelContext为作用域维护全局前缀缓存表通过/query等 HTTP API 回答路由器该前缀在哪个实例、哪些介质上可用。本文系统梳理了其架构组件、数据模型、事件/查询双流程、静态与动态注册、发布者与订阅者的完整协议与故障恢复语义并结合 mooncake-conductor 的 C 源码给出了实现级佐证。进一步的细节请参阅仓库内原文Conductor 架构设计、KV 事件发布者设计、KV 事件订阅者指南以及 Conductor Indexer API 参考。赞分享人工智能大模型模型推理服务后端【免费下载链接】MooncakeMooncake is the serving platform for Kimi, a leading LLM service provided by Moonshot AI.项目地址https://gitcode.com/gh_mirrors/mo/Mooncake点击查看免费下载相关推荐Mooncake Conductor Indexer API 指南KV Cache 感知调度的注册、事件与查询协议Mooncake Conductor Indexer API 指南KV Cache 感知调度的注册、事件与查询协议 Mooncake Conductor 是人工智能大模型模型推理服务后端LMCache KV Cache Events 实战指南为 KV 缓存感知路由打通 vLLM 与 SGLang 事件通道LMCache KV Cache Events 实战指南为 KV 缓存感知路由打通 vLLM 与 SGLang 事件通道 KV Cache Events 是人工智能大模型缓存抽象模型推理服务AIBrix 前缀缓存感知路由Prefix Cache Aware Routing全解析原理、配置与 KV 事件同步实战AIBrix 前缀缓存感知路由Prefix Cache Aware Routing全解析原理、配置与 KV 事件同步实战 Prefix Cache Awa人工智能大模型云原生模型推理服务LLM 网关API网关弹性伸缩上一篇Stremio Addons List 开源项目教程下一篇XposedWechatHelper 开源项目教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考