缘起：大规模场景下的 GIL 瓶颈
我们从事生产级模型服务多年。最初构建 Shepherd Model Gateway (SMG) 时，目标非常简单：弄清楚缓存感知负载均衡（cache-aware load balancing）能否改善跨推理副本的路由。
答案是肯定的。但随着深入研究，我们发现了一个更严重的问题。
在 SGLang 和 vLLM 中，Tokenization（分词）和 Detokenization（反分词）已成为性能瓶颈。这并非理论推测，而是在真实生产流量下的实际表现。其根源在于架构设计：尽管这两个引擎底层都使用了 Rust 或 C++ 的分词库，但调用过程必须经过 Python。这意味着全局解释器锁（GIL）的存在，导致位于服务路径上的 CPU 密集型工作被限制在单线程内。
在小规模部署下，这无关紧要。但在大规模“预填充-解码（prefill-decode）”解耦服务以及 GPU 集群间的大规模专家并行计算中，问题就变得极其严重。这些配置使 GPU 运行速度极快，快到 CPU 侧的流水线反而成了制约因素。GIL 限制下的分词每耗费一微秒，就意味着价值数十万美元的 GPU 在空转等待输入。
这便是整个旅程的起点。不是始于构建网关的愿景，而是始于生产中的实际问题。我们能否将所有的 CPU 工作负载从 GPU 路径中剥离出来，并在 Rust 中运行？不是“Python 调用 Rust”，而是纯粹的 Rust。没有 GIL，没有单线程上限，没有 Python 进程边界。
答案是肯定的，而证明这一点的项目最终成为了 Shepherd Model Gateway。
SMG 架构：客户端 → 网关 → 路由器 → 工作节点
SMG 的架构建立在一个原则之上：GPU 应专注于张量计算，其余一切任务均属于专用的服务层。
我们审查了模型服务栈，识别出了所有与 GPU 推理交织在一起的 CPU 密集型负载：分词、反分词、推理输出解析、函数调用提取、MCP 工具编排、多模态预处理、聊天历史管理、结构化输出验证、停止序列检测。每一项都是 CPU 任务，当它们与 GPU 进程共同位于 Python GIL 之后时，就会对机架中最昂贵的硬件产生反压。
SMG 将所有这些任务移至一个 Rust 网关层，该层通过 gRPC 与推理引擎通信。协议极其精简且以 GPU 为中心：发送预处理后的 Token，流式传输生成的 Token。其余一切皆由网关负责。
这不是分布式推理领域大多数项目采取的路线。NVIDIA Dynamo 和 llm-d 等项目在优化推理引擎层及相关编排方面做了出色的工作，我们认为这些工作是互补的。但 SMG 的策略不同：与其让引擎更聪明，不如让网关更聪明。将所有无需 GPU 的任务卸载到专门构建的 Rust 层中，使其能够独立扩展、独立演进，且运行过程不存在任何 GIL 竞争。
gRPC 重构：将愿景变为现实
gRPC 流水线：在交付给引擎前的网关侧处理
SMG 历史上最大的技术投入是围绕原生的 Rust gRPC 数据平面重建了整个服务流水线。这是解耦命题的架构性证明。
分词与反分词 移至网关。SMG 在 Rust 中原生运行分词器，并采用两级缓存——用于重复提示词的 L0 精确匹配，以及用于特殊 Token 边界的 L1 前缀感知。推理引擎接收的是预分词后的输入，无需触碰任何分词逻辑。没有 Python，没有 GIL。
推理与工具调用解析 在网关的流式流水线中运行。当 Token 通过 gRPC 到达时，SMG 的解析器（包括 Cohere Command, DeepSeek, Llama, Nemotron, Kimi-K2, GLM-4 和 Qwen Coder 等）会实时提取推理块、函数调用和结构化输出。引擎侧无需任何后处理步骤。
多模态处理 是最具雄心的部分。我们将 Hugging Face transformers 图像处理器的大部分组件从 Python 重写为 Rust —— 在完全不同的语言和运行时中重新实现了视觉预处理流水线、张量运算和模型特定的转换。其结果是：SMG 通过 gRPC 将预处理后的张量直接传输给引擎，实现了零 Python 开销。支持 Llama 4 Vision, Qwen VL 及所有主流视觉语言模型，并针对 SGLang, vLLM 和 TensorRT-LLM 提供了后端特定的优化。据我们所知，这是行业首创。
MCP 工具编排 完全在网关中运行，具备感知身份验证的连接池、并发批处理执行、审批工作流、自动重连和 HTTP 头部转发功能。推理引擎无需了解 MCP。我们还构建了一个完整的内置工具路由基础设施，将任何 MCP 服务器转化为原生功能（如文件搜索、网页搜索、代码解释器），适用于任何模型。部署 Llama 或 Qwen 时，可拥有与 GPT-4 相同的内置工具。
聊天历史管理 具备可插拔存储（PostgreSQL, OracleDB, Redis 和内存存储）、基于 Flyway 的架构版本控制、可自定义的表/列名，以及用于预/后持久化回调的存储钩子。所有这些都在网关中完成，使引擎保持无状态。
WASM 中间件 提供了无需重构代码库的可编程扩展能力。自定义认证、合规日志、PII 脱敏、成本跟踪、压缩等——皆可通过具有沙箱隔离的 WebAssembly 插件实现。这也是一项行业首创。
gRPC 协议本身（以 smg-grpc-proto 之名发布在 PyPI 上）定义了网关与引擎之间的窄合约。这种设计意味着你可以升级网关（增加解析器、协议、工具），而无需触碰推理引擎；也可以升级引擎（采用新的 GPU 内核、量化方案），而无需触碰网关。由于接口简洁，两者可以独立演进。
SMG 的当前能力
SMG 由 LightSeek Foundation 的 Simo Lin 和 Chang Su 创建。在大约六个月的时间里，我们发布了十三个版本。在此不逐一回顾，仅总结该项目目前所提供的功能及其背后的依据。
多模型推理网关
单一 SMG 进程即可统筹整个集群——支持多模型、多引擎、单一入口点。可同时在 SGLang, vLLM, TensorRT-LLM 和 MLX 后端之间路由请求。支持将 OpenAI、Anthropic、Google Gemini、AWS Bedrock 和 Azure OpenAI 作为外部提供商添加。一个网关，对接所有引擎与供应商。
五大原生 Agent API
SMG 原生支持 Chat Completions (OpenAI), Responses API (OpenAI), Messages API (Anthropic), Interactions API (Gemini) 和 Realtime API (WebSocket/WebRTC)。它们并非翻译层，而是每一项都是一级实现。Messages API 通过 ThinkingConfig、thinking_delta 流式事件以及交错的推理+文本+工具使用内容块，完整保留了思考过程。Responses API 将 OpenAI 的对话管理功能带到了 Llama, DeepSeek, Qwen 及所有开源模型上——SMG 是目前唯一支持此功能的开源网关。让为 Claude 设计的智能体工作流在 Llama 4, Qwen 3, DeepSeek 或 Kimi 上以完全相同的协议保真度运行。
原生 Rust gRPC 数据平面
两级分词器缓存：L0 精确匹配，L1 前缀感知
架构核心：网关与引擎之间原生的 Rust gRPC 流水线。合约极其精简——预处理后的 Token 输入，生成的 Token 输出。其余一切皆由网关负责。分词逻辑在 Rust 中运行，具备两级缓存（L0 精确匹配，L1 前缀感知）。推理和工具调用解析在 Token 到达时于流式流水线中完成——支持包括 DeepSeek-R1, Qwen3, GLM-4, Kimi, Llama-4, Cohere Command 等在内的 15 个模型系列。没有 Python，没有 GIL。gRPC 协议已发布为 PyPI 上的 smg-grpc-proto，vLLM（PR #36169）和 NVIDIA TensorRT-LLM（五个已合并 PR）均已在上游采纳该协议。
智能路由
缓存感知路由流
八种负载均衡策略：缓存感知、轮询、随机、两轮选择法（P2C）、一致性哈希、前缀哈希、手动（粘性会话）以及基于桶的策略。缓存感知路由经过完全重写——速度提升 10–12 倍（每秒 216,000 次插入），内存占用降低 99%（每个节点从 180 KB 降至 1.4 KB，缓存 10,000 个前缀：从 1.8 GB 降至 14 MB）。事件驱动的 KV 缓存路由通过 SubscribeKvEvents RPC 从所有后端流式传输实时缓存状态，并自动学习块大小。在 8 个 Llama 副本上的生产结果显示：首字延迟（TTFT）平均下降 23%，p99 下降 28%。预填充-解码解耦将这两个阶段路由至不同的工作节点池并应用独立策略——在 PD 设置下 TTFT 提升了 20–30%。
Rust 语言下的多模态处理
我们将 Hugging Face 图像处理器的大部分组件从 Python 重写为 Rust —— 重新实现了视觉预处理流水线、张量运算和模型特定的转换。支持八大视觉模型系列：Kimi K2.5, Llama-4 Vision, LLaVA, Phi-3/Phi-4 Vision, Pixtral, Qwen-VL, Qwen2-VL 和 Qwen3-VL。预处理后的张量通过 gRPC 直接流向引擎，实现了零 Python 开销。据我们所知，这是行业首创。
MCP 工具编排与内置工具
MCP 架构：网关中的工具编排
MCP 完全在网关中运行，具备感知身份验证的连接池、并发批处理执行、审批工作流、自动重连以及四种传输协议（STDIO, HTTP, SSE, Streamable）。通用 MCP 内置工具可将任何 MCP 服务器转化为任何模型的原生功能（如文件搜索、网页搜索、代码解释器）。部署 Llama 或 Qwen 时，可拥有与 GPT-4 相同的内置工具。提供租户级隔离、基于策略的信任级别以及标准的执行指标统计。
WASM 中间件
WASM 插件流水线
通过具有沙箱隔离的 WebAssembly 插件实现可编程扩展——这是又一项行业首创。自定义认证、合规日志、PII 脱敏、成本跟踪、压缩等——所有这些均无需修改代码库即可实现。基于 Wasmtime 构建，支持组件模型与异步特性。存储钩子可拦截聊天历史记录操作，进行自定义的预/后处理。
企业级安全与可观测性
TLS/mTLS 架构
支持 JWT/OIDC 认证及 JWKS 发现、基于角色的访问控制（RBAC）、API Key 认证及多租户速率限制。客户端与节点间通信均支持 TLS 和 mTLS。六层指标系统包含 40 多个 Prometheus 指标，涵盖 HTTP、路由器、工作节点、推理、发现、MCP、数据库和网格层。支持完整的 OpenTelemetry 分布式追踪。提供带有请求关联 ID 的结构化 JSON 日志记录。
可靠性与高可用性
熔断器状态机
支持工作节点级熔断器（关闭/打开/半开）、带有指数退避和抖动的自动重试、定期健康检查、并发请求速率限制、请求超时以及可配置的优雅停机。采用基于 SWIM 协议的 Gossip 网格，支持跨多节点部署的基于 CRDT 的状态同步。支持跨集群节点的分布式速率限制。架构设计上天然具备分区容错能力。
数据持久化与服务发现
服务发现：Kubernetes, DNS, 手动
聊天历史管理支持可插拔存储（PostgreSQL, OracleDB, Redis 或内存存储），具备架构版本控制和可自定义的表/列名。支持基于 Kubernetes 标签的 Pod 发现、DNS 发现或手动指定工作节点 URL。模型 ID 可来自 Pod 命名空间、标签或注解。支持引导端口注解，以便在 PD 设置中自动发现预填充端口。
全平台通用支持
Linux, Windows, macOS, x86, ARM——只需一个 Python Wheel 包（pip install smg）。支持 Python 3.8–3.14。提供 Python, Rust, Java 和 Go 语言的生产级客户端 SDK。提供引擎特定的 Docker 镜像。代码完全模块化为独立 Crates：smg-auth, smg-mesh, smg-mcp, smg-wasm, smg-grpc-client, smg-kv-index, llm-tokenizer, llm-multimodal, openai-protocol 等。
命题证明：gRPC 网关基准测试
解耦命题预测，将 CPU 工作负载从 GPU 路径中剥离应当能带来显著的性能收益——特别是在生产环境下。我们对此进行了系统性测试。
方法论
所有基准测试均在 NVIDIA H100 GPU 上运行，使用 GitHub Actions 中的 SMG 每夜构建基准测试套件，并通过 NVIDIA GenAI-Perf (genai-perf) 执行。测试涵盖 8 种模型（GPT-OSS-20B, Llama-3.1-8B, Llama-3.3-70B, Llama-3.3-70B-FP8, Llama-4-Maverick, Llama-4-Scout, Qwen2.5-7B, Qwen3-30B-MoE）、2 种运行时（SGLang, vLLM）、5 种流量场景及 9 级并发（1–256）。总计产生 1,082 个 gRPC 与 HTTP 对比数据点。
扩展性表现：优势随并发增加而增长
在 1 并发下，gRPC 和 HTTP 的性能差距在误差范围内。但在 256 并发下，gRPC 的吞吐量提高了约 8%。网关的二进制序列化和 HTTP/2 多路复用在负载增加时优势显著——恰恰是在最关键的时刻。
长上下文：gRPC 彻底改变性能
HTTP/JSON 的序列化成本随提示词长度线性增长。而 gRPC/protobuf 使用紧凑的二进制编码，规避了这一代价。在 7800 个输入 Token 时，序列化成本非常巨大。D(7800,200) 场景显示，在所有模型中，吞吐量提升了 12.2%。
最显著的结果：在 7800 Token 输入的 Llama-3.3-70B-FP8 模型中。该模型在 H100 上运行 FP8 量化时速度极快，以至于 HTTP 序列化成为了主要瓶颈。gRPC 实现了高达 3.5 倍的输出吞吐量提升：从 327 tok/s 提升至 1,150 tok/s。
高并发下的模型分解
在生产并发级别（32–256）下，gRPC 的优势因模型架构而异。Llama-3.3-70B-FP8 的增益最大（端到端 p99 提升 15.8%，输出吞吐量提升 44.6%）。较小的密集型模型（Llama-3.1-8B, Qwen2.5-7B）增益适中。规律很明确：GPU 越快，gRPC 的优势就越大，因为 CPU 开销在总延迟中所占的比例变得更高。
生态现状
我们并非唯一致力于大模型基础设施的团队。
NVIDIA Dynamo 带来了深度的硬件集成和优化的推理编排。llm-d 则通过 Kubernetes 原生方式处理分布式推理调度。两者都在引擎和集群层做了重要的工作。
SMG 在另一个边界运行：服务与协议层。我们拥有客户端与 GPU 之间的所有环节——分词、智能体协议转换、工具编排、缓存感知路由、多模态预处理、可靠性管理。统一的一层，零外部依赖，纯粹的 Rust。
核心洞察在于：这些方案是可组合的。你可以在由 llm-d 管理的 vLLM 之前运行 SMG，或者在由 Dynamo 处理 GPU 编排的 TensorRT-LLM 之前运行它。边界清晰，因为职责明确。
生产采用情况
SMG 为以下生产部署提供支持：
- Google Cloud Platform — 多租户 AI 基础设施
- Oracle Cloud Infrastructure — 企业级生成式 AI 服务
- Alibaba Cloud — 云原生 AI 工作负载
- TogetherAI — 分布式推理基础设施
从初创公司到超大规模云服务商。
未来展望
- 批处理 API 调度——采用作业调度器（Job Scheduler）和容量管理器（Capacity Governor）的二级架构，服务于离线工作负载。
- 语义路由——基于内容的轻量级分类分发，而非静态规则。
- 供应商混合方案（Mixture of Vendors, MoV）——在多个提供商之间路由同一模型，用于 A/B 测试、成本优化和质量对比。
- MCP 语义搜索——在注册了数百个工具的服务器之间实现高效的工具发现。
- 自定义指标负载均衡——通过 CEL 表达式基于任意指标进行路由，延迟在亚毫秒级。
GitHub: github.com/lightseekorg/smg
安装: pip install smg –upgrade
文档: lightseekorg.github.io/smg
致谢
SMG 的开发得益于与行业内工程团队和开源社区的紧密合作。感谢以下伙伴的贡献、反馈与合作：
- Oracle Generative AI Service — Jun Qian, Jingqiao Zhang, Wei Gao, Keyang Ru, Xinyue Zhang, Yifeng Liu, Ziwen Zhao, Daisy Zhou, Khoa Tran.
- TogetherAI — Yineng Zhang, Wei Gong, Chandra Mourya, Connor Li.
- Thinking Machines Lab — Eric Zhang, Rajat Goel, Jeff Hanson.
同时也感谢 SGLang、vLLM 和 TensorRT-LLM 社区在上游协作和协议采纳方面的支持，以及 radixArk 和 Inferact 团队的合作伙伴关系与反馈。
正是他们的生产部署、代码贡献和技术见解，塑造了今天的 SMG。