llm-d/llm-d-router

llm-d Router 是 LLM 推理服务链路中的智能入口。它由代理（通常是 Envoy）和 Endpoint Picker（EPP）组成，后者根据 KV-cache 局部性、当前负载和请求优先级决定由哪个模型服务器副本处理请求。它适合已经在 Kubernetes 上运行推理服务、希望获得比轮询更精细调度能力的团队。

工作方式的变化

与把每个请求交给下一个可用副本不同，EPP 会结合 InferencePool 的当前状态评估每个请求，并通过 ext-proc 协议把实时信号注入数据面。两个请求管理 API 用于调节这一行为：InferenceObjective 为特定请求设定优先级和性能目标等调度目标，InferenceModelRewrite 则改写模型名称，用于 A/B 测试和灰度发布。此外还有 Disaggregation Sidecar，负责在 worker 之间协调 KV-cache 与 embedding 传输，支持 Prefill/Decode 和 Encode/Prefill/Decode 等多阶段推理流程（README）。

两条部署路径

Standalone 模式使用自管理的 Envoy 代理，不依赖 Gateway API 基础设施。默认的 sidecar 拓扑把代理放在 EPP Pod 内，README 称其适合测试和本地评估；service 模式则把代理作为独立、可水平扩展的 Deployment，通过 EPP Service 访问。Standalone Helm chart 覆盖这两种拓扑（README）。

Gateway 模式是推荐的生产路径。EPP 作为 InferencePool 的后端，由共享 Gateway 上的 HTTPRoute 引用，从而支持高级流量管理、多集群负载均衡，以及推理与传统工作负载共享基础设施（架构文档）。

前提条件与限制

• 需要 Kubernetes；Gateway 模式还需要 Gateway API。InferencePool API 位于独立的 Gateway API Inference Extension 项目中，Endpoint Picker Protocol 也在那里定义（README）。
• 如果不使用项目提供的自动化工具、而是自行安装或配置 Envoy，则唯一支持的 request_body_mode 与 response_body_mode 是 FULL_DUPLEX_STREAMED（README）。
• EPP 容器规格指南和 TLS 文档是独立文件；重负载或长上下文场景在规划资源前应参考规格指南（README）。

README 没有给出基准测试结果，也没有说明故障、升级或回滚行为，这些需要在自有环境中验证。项目采用 Apache-2.0 许可证，已发布的容器镜像带有签名的来源证明和 SBOM，并提供了验证方法（README）。