# Brick-SR1：多模态语义路由网关，统一处理文本、图像和音频输入

> Brick是一个多模态路由网关，通过单一虚拟模型接口统一处理文本、图像和音频输入，自动检测模态类型并路由到合适的后端模型，无需客户端做任何改动。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-04-09T10:55:27.000Z
- 最近活动: 2026-04-09T11:18:58.916Z
- 热度: 150.6
- 关键词: 多模态, 语义路由, 网关, OCR, 语音转文本, OpenAI API, Go, LLM部署
- 页面链接: https://www.zingnex.cn/forum/thread/brick-sr1
- Canonical: https://www.zingnex.cn/forum/thread/brick-sr1
- Markdown 来源: ingested_event

---

## 背景：多模态AI的碎片化问题

现代大语言模型部署面临一个日益严重的问题：不同输入模态——文本、图像和音频——需要不同的后端模型和API端点，迫使客户端自行实现模态检测和模型选择逻辑。

这种碎片化破坏了统一对话接口的承诺，并随着模态需求的演进产生持续的运维开销。当提供商改变API时，客户端代码需要相应修改，这种耦合使得系统变得脆弱。

Brick的出现正是为了解决这一痛点，它将模态处理逻辑从客户端迁移到网关层，为应用开发者提供真正统一的接口。

## Brick简介

Brick是一个多模态路由网关，暴露单一虚拟模型（model: "brick"），接受标准OpenAI对话补全格式的任意组合的文本、图像和音频输入。

Brick的核心价值在于透明性：客户端发送与任何OpenAI兼容端点相同的JSON请求，网关自动检测输入模态，在需要时并行执行OCR和语音转文本预处理，然后将请求路由到适当的后端——无论是直接转发到视觉模型处理图像+文本输入，还是通过语义路由管道处理文本派生内容。

整个过程无需任何客户端改动，响应中包含x-selected-model头部，告知客户端哪个后端被选中，便于日志记录和成本归因。

## 核心架构设计

Brick的架构设计围绕透明代理理念展开，主要包含以下组件：

**模态检测与分类**：预处理管道检查每条消息的内容部分，将请求分类为五种模态组合之一：图像+文本、仅图像、仅音频、音频+图像、仅文本。

**并发预处理**：对于包含音频和图像的混合输入，OCR和语音转文本通过Go协程并行执行，最小化延迟。

**智能路由决策**：根据模态分类结果，请求被路由到不同目的地。关键设计是图像输入的降级策略——先尝试OCR（更便宜、更快），如果OCR结果太短（表明是照片而非文档），则降级到直接转发原始图像到视觉模型。

**语义路由集成**：预处理后，文本派生内容被重写进请求体，传递给标准语义路由管道，该管道评估11种信号类型并选择最佳后端。

## 模态路由策略详解

Brick的路由表体现了对不同输入类型的精细处理：

| 输入模态 | 处理方式 | 目的地 |
|---------|---------|--------|
| 图像+文本 | 保留原始多模态请求体 | 视觉模型（直接转发） |
| 仅图像 | 通过专用OCR模型处理 | 如果文本长度≥阈值→语义管道；否则→视觉模型 |
| 仅音频 | 通过Whisper兼容STT端点转录 | 语义管道（使用转录文本） |
| 音频+图像 | 并行OCR+STT（并发协程） | 语义管道（使用组合文本） |
| 仅文本 | 无需预处理 | 语义管道 |

这种设计的关键洞察是图像输入的智能降级：OCR优先尝试，但短结果触发视觉模型回退，确保照片类图像得到正确处理。

## 技术实现细节

Brick使用Go 1.24实现，作为语义路由器的HTTP代理服务器的一部分。预处理管道在请求处理器内运行，在路由决策前完成。

**并发处理实现**：当请求同时包含音频和图像时，使用Go的sync.WaitGroup协调两个并发的goroutine分别执行转录和OCR，等待两者完成后合并结果。

**请求体重写**：预处理完成后，提取的文本内容被重写进标准OpenAI对话格式的请求体，后续处理对下游组件完全透明。

**透传模式支持**：客户端如果已确定适当的后端，可在请求头中设置x-selected-model直接指定模型名，Brick验证该模型存在后直接转发，跳过所有预处理。

## 配置与部署

Brick通过config.yaml中的brick:部分配置，所有字段在enabled: true时都是必需的：

```yaml
brick:
  enabled: true
  
  # 视觉模型配置
  vision_model: "qwen3.5-122b"
  vision_endpoint: "https://api.regolo.ai/v1/chat/completions"
  
  # OCR模型配置
  ocr_model: "deepseek-ocr-2"
  ocr_endpoint: "https://api.regolo.ai/v1/chat/completions"
  
  # 语音转文本配置
  stt_model: "faster-whisper-large-v3"
  stt_endpoint: "https://api.regolo.ai/v1/audio/transcriptions"
  
  # OCR结果最小字符数阈值
  ocr_min_text_length: 10
```

部署流程简洁：

```bash
# 1. 克隆
git clone https://github.com/massaindustries/semantic-routing.git
cd semantic-routing

# 2. 构建Docker镜像（Rust + Go多阶段，首次构建约5分钟）
docker build -t mymodel:latest .

# 3. 启动
docker compose -f deploy/docker-compose/docker-compose.yml up -d

# 4. 验证
curl http://localhost:8000/health
curl http://localhost:8000/v1/models
```

## 使用示例

发送请求到model: "brick"，在Authorization头部传入Regolo API密钥：

```bash
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <your-regolo-key>" \
  -d '{
    "model": "brick",
    "messages": [{
      "role": "user",
      "content": [
        {"type": "text", "text": "这份文档说了什么？"},
        {"type": "image_url", "image_url": {"url": "data:image/png;base64,..."}}
      ]
    }]
  }'
```

响应中的x-selected-model头部报告选中的后端模型。

## 与MyModel和vLLM语义路由的关系

Brick建立在vLLM语义路由器（Apache 2.0许可证）之上，语义路由管道、插件链（越狱检测、PII过滤、语义缓存、RAG、记忆、幻觉检测）和模型选择算法（包括RouteLLM、AutoMix、RouterDC和Router-R1）在完整的MyModel网关仓库中有详细文档。

Brick作为MyModel LLM托管网关的一部分实现，提供完整的语义路由管道、插件链和模型选择算法。

## 项目演进与特性

Brick项目持续演进，当前版本特性包括：

- 独立HTTP代理模式——无Envoy依赖，直接在8000端口运行HTTP服务器
- Brick虚拟模型——统一多模态网关，支持并发OCR+STT预处理
- Regolo API集成——云原生后端，支持${ENV_VAR}密钥解析
- OpenAI /v1/responses转换——将较新的Responses API格式映射到对话补全

## 应用场景与价值

Brick适用于多种场景：

**简化客户端开发**：应用开发者无需关心后端模型差异，统一使用OpenAI格式与Brick交互。

**成本优化**：通过智能路由将简单文本查询导向成本更低的模型，复杂多模态请求导向能力更强的模型。

**灵活后端切换**：更换或升级后端模型无需修改客户端代码，仅需调整网关配置。

**统一监控**：通过x-selected-model头部实现精确的模型使用追踪和成本归因。

## 开源与许可

Brick基于vLLM语义路由器构建，采用Apache License 2.0开源许可。项目欢迎社区贡献，代码托管在GitHub上。

对于需要统一多模态接口的LLM部署场景，Brick提供了一个生产就绪的解决方案，将复杂性封装在网关层，让应用开发回归简单。