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

> 一个专注于推理原语而非编排的LLM网关，通过进程隔离和OpenTelemetry原生支持，为生产环境提供稳定、可观测的多Provider统一接口。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-04-28T19:12:49.000Z
- 最近活动: 2026-04-28T19:22:04.603Z
- 热度: 150.8
- 关键词: LLM, gateway, OpenTelemetry, multi-provider, self-hosted, inference, rust, observability
- 页面链接: https://www.zingnex.cn/forum/thread/mohdel-provider-llm
- Canonical: https://www.zingnex.cn/forum/thread/mohdel-provider-llm
- Markdown 来源: ingested_event

---

## 背景：为什么需要另一个LLM网关？

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

## 项目定位：推理原语层

mohdel的核心设计哲学可以概括为"scope-capping"（范围限定）。它明确不做以下事情：

- **不做编排器**：没有链式调用、没有Agent逻辑、没有记忆管理、没有Prompt模板、没有检索增强。这些留给LangChain、LangGraph或你自己的实现。

- **不做重试/降级引擎**：错误会被分类（可重试、严重程度、类型），但mohdel不会自动重试或静默切换模型。调用方拥有重试预算和降级选择的决策权。

- **不做响应缓存**：虽然支持provider端的prompt缓存（如Anthropic、OpenAI），但mohdel本身不做结果缓存——这需要调用方根据业务不变量来决定。

- **不做上下文窗口管理**：没有预调用token计数，没有预估成本保护。调用方决定prompt内容，是token计数的唯一权威来源。

- **不做SaaS代理**：完全自托管，你的API key、你的基础设施，不经过第三方路由。

## 架构设计：三平面隔离

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

1. **JS Client**：通过Unix Socket与后端通信，支持任何语言的HTTP调用者
2. **Rust Thin-Gate**：作为调度器和状态所有者，负责会话管理和配额控制
3. **JS Session**：实际的Provider执行器，每个会话独立运行

这种设计允许以子进程方式运行thin-gate，实现故障隔离、跨进程配额管理；同时也支持在单进程服务中使用Node factory进行内联调用。

## OpenTelemetry原生支持

每个调用都会自动产生：

- **OpenTelemetry Span**：在调用方的traceparent下创建`mohdel.session.answer` span，包含GenAI语义约定属性（模型、系统、token用量）以及mohdel特有属性（状态、成本、思考token、首token延迟、冷却时间）

- **Trace-linked Logs**：每条stderr日志都携带`{traceId, spanId, callId, authId, provider, model}`，可与 traces 自动关联

- **Gate-side OTLP Metrics**：会话存活数、调用统计、延迟分布、配额拒绝率等

只需设置`OTEL_EXPORTER_OTLP_ENDPOINT`，span和metrics就会通过gRPC自动上报。未设置时零开销。

## 支持的Provider与模型格式

目前支持11个Provider：Anthropic、OpenAI、Gemini、Mistral、Groq、xAI、Cerebras、Fireworks、DeepSeek、OpenRouter、Novita。

模型ID采用统一的`<provider>/<model>`格式：
```
gemini/gemini-3-flash-preview
anthropic/claude-sonnet-4-6
openai/gpt-5.4-mini
groq/llama-4-scout-17b-16e-instruct
```

## CLI工具与使用方式

安装后可通过`mo`命令进行交互式配置和调用：

```bash
mo ask anthropic/claude-sonnet-4-6 "explain monads"
cat article.txt | mo ask openai/gpt-5.4 "summarize in 3 bullets"
mo ask anthropic/claude-sonnet-4-6 --stream "write a haiku"
mo ask anthropic/claude-opus-4-6 --effort high "prove P != NP"
```

支持的功能包括：流式输出、思考努力度控制、模型目录浏览、基准测试、速率限制管理等。

## 集成路径：Client vs Factory

**Client方式**（推荐，跨进程）：
```javascript
import { call } from 'mohdel/client'
for await (const ev of call(envelope, { socketPath: '/tmp/mohdel-data.sock' })) {
  if (ev.type === 'delta') process.stdout.write(ev.delta.delta)
}
```

**Factory方式**（单进程快捷）：
```javascript
import mohdel from 'mohdel'
const mo = await mohdel()
const result = await mo.use('anthropic/claude-sonnet-4-6').answer('Hello')
```

## 实践意义与适用场景

mohdel适合以下场景：

- 需要统一多Provider接口，但不想引入重量级编排框架
- 对可观测性有严格要求，需要完整的分布式追踪
- 希望保持架构简洁，明确区分"谁负责什么"
- 需要进程级故障隔离的生产环境

## 总结

mohdel代表了一种克制的设计哲学：在LLM基础设施层，有时候"少即是多"。通过明确划定能力边界，它让调用方保持控制权，同时提供生产级的可观测性和稳定性。对于已经使用LangChain等框架的团队，mohdel可以作为其底层的推理原语；对于希望自建编排逻辑的团队，它提供了干净的基础层。