mohdel：自托管多Provider LLM网关的设计哲学与实践

mohdel是一个专注于推理原语而非编排的自托管多Provider LLM网关，通过进程隔离和OpenTelemetry原生支持，为生产环境提供稳定、可观测的多Provider统一接口。其核心设计哲学为"scope-capping"（范围限定），明确不做编排、重试降级、缓存等功能，让调用方保留完整控制权。

当前LLM生态中，开发者面临两难选择：直接使用各Provider的SDK需承担多供应商管理复杂性；采用LangChain等编排框架则引入超出需求的抽象层级。mohdel选择中间道路——只做推理原语，不做编排，保留调用方控制权。

mohdel的核心设计哲学是"scope-capping"，明确不做以下事情：

• 不做编排器：无链式调用、Agent逻辑、记忆管理等（留给LangChain等实现）；
• 不做重试/降级引擎：错误分类但不自动重试或切换模型；
• 不做响应缓存：仅支持provider端缓存；
• 不做上下文窗口管理：调用方决定prompt内容；
• 不做SaaS代理：完全自托管，API key和基础设施由用户掌控。

mohdel采用三平面架构实现进程隔离：

1. JS Client：通过Unix Socket与后端通信，支持任意语言HTTP调用者；
2. Rust Thin-Gate：调度器和状态所有者，负责会话管理和配额控制；
3. JS Session：实际Provider执行器，每个会话独立运行。 此设计支持子进程运行thin-gate实现故障隔离，也可单进程内联调用。

mohdel每个调用自动生成：

• OpenTelemetry Span：创建mohdel.session.answer span，包含GenAI语义属性（模型、token用量等）及mohdel特有属性；
• Trace-linked Logs：stderr日志携带traceId、spanId等关联信息；
• Gate-side OTLP Metrics：会话存活数、调用统计、延迟分布等。 设置OTEL_EXPORTER_OTLP_ENDPOINT即可自动上报span和metrics，未设置时零开销。

支持的Provider：目前支持Anthropic、OpenAI、Gemini等11个Provider，模型ID采用<provider>/<model>格式（如gemini/gemini-3-flash-preview）。 CLI工具：安装后通过mo命令交互调用，如mo ask anthropic/claude-sonnet-4-6 "explain monads"，cat article.txt | mo ask openai/gpt-5.4 "summarize in 3 bullets"，支持流式输出、努力度控制等。 集成路径：

• Client方式（推荐跨进程）：通过Unix Socket通信；
• Factory方式（单进程快捷）：内联调用。

适用场景：

• 需要统一多Provider接口但不想用重量级编排框架；
• 对可观测性有严格要求；
• 希望保持架构简洁，明确责任划分；
• 生产环境需进程级故障隔离。 总结：mohdel体现"少即是多"的设计哲学，通过明确能力边界让调用方保持控制权，同时提供生产级可观测性和稳定性。可作为LangChain等框架的底层推理原语，或为自建编排逻辑提供基础层。