在 vLLM Semantic Router 的设计中，Embedding 推理是驱动语义路由的核心信号之一。

官方教程已经演示了如何使用远程 Embedding 推理提供商（Remote Embedding Providers）替代本地 Embedding 推理服务：

👉 https://vllm-sr.ai/docs/tutorials/global/remote-embeddings/

然而，在实际生产环境中，一个更为关键的问题随之而来：

如何使用企业级、可扩展的 Embedding 推理服务来支持语义路由？

本文基于官方教程中的场景，并结合 Microsoft Foundry Embedding 模型，演示如何构建一个具备以下特性的智能路由系统：

• 无需 GPU
• 无需在本地部署 Embedding 模型
• 生产就绪

2. 回顾：远程 Embedding 推理提供商

在 vLLM Semantic Router 中，路由器运行在 CPU 上，不依赖 GPU 推理能力。

通过远程 Embedding 推理提供商：

路由器 → 远程 Embedding 推理 API → 向量

我们可以：

• 将嵌入计算完全卸载到云服务
• 统一多模型的语义能力
• 解耦路由与推理

3. 教程场景（沿用官方测试场景）

在官方教程中，核心流程如下：

第 1 步：定义语义路由

routing:
  decisions:
    - name: math
      when:
        semantic_similarity:
          text: "math question"
          threshold: 0.8

    - name: general

第 2 步：发送请求

curl http://localhost:8888/v1/chat/completions \
  -d '{
    "model": "MoM",
    "messages": [{"role": "user", "content": "What is 1+1?"}]
  }'

路由器将执行以下操作：

1. 生成嵌入向量
2. 执行语义匹配
3. 选择目标模型

4. 第 0 步：在 Microsoft Foundry 中创建 Embedding 模型

在与 vLLM Semantic Router 集成之前，我们首先需要在 Microsoft Foundry 中部署一个 Embedding 模型。

4.1 创建 Foundry 项目

1. 前往 Microsoft Foundry 门户
2. 创建新项目（或选择现有项目）
3. 确保该项目已关联 Azure 订阅

4.2 部署嵌入模型

在模型目录中：

1. 搜索 Embedding 模型
2. 选择受支持的模型（例如 text-embedding-3-small）
3. 单击 Deploy（部署）

部署完成后，你将获得：

• Endpoint URL
• API Key
• Model Name

示例：

Endpoint: https://<your-foundry-resource>.inference.ai.azure.com
Model: text-embedding-3-small
API Key: ******

4.3 验证 Embedding 推理 API

你可以直接测试该终结点：

curl https://<your-foundry-endpoint>/v1/embeddings \
  -H "api-key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "input": "Hello world"
  }'

如果调用成功，你将收到包含向量的响应。

5. 升级：使用 Microsoft Foundry 替代本地 Embedding 模型

现在，我们将教程中的 Embedding 推理提供商替换为：

✅ Microsoft Foundry Embedding 模型

6. 为什么选择 Microsoft Foundry Embedding 模型

Microsoft Foundry 提供：

• 高质量 Embedding 模型（更强的语义理解能力）
• 托管 API（无需自行部署）
• 全球可用性与企业级 SLA
• 与 Azure AI 生态系统无缝集成

更重要的是：

它可以直接充当 Semantic Router 的“语义大脑”

7. 集成：将 Microsoft Foundry 用作远程 Embedding 推理提供商

7.1 配置 Embedding 推理提供商

providers:
  embedding:
    type: remote
    provider: openai-compatible
    base_url: https://<your-foundry-endpoint>
    api_key: <your-api-key>
    model: text-embedding-3-small

说明：

• Foundry 提供兼容 OpenAI 的 API
• 可以直接复用 Semantic Router 的远程 Embedding 推理提供商
• 无需额外适配

7.2 路由器工作流

用户请求
   ↓
Semantic Router
   ↓
Microsoft Foundry Embedding 推理 API
   ↓
向量相似度计算
   ↓
路由决策
   ↓
目标模型（vLLM / API）

8. 相比官方教程的主要改进

9. 实际价值

🚀 1. 真正的“无 GPU 架构”

路由器本身运行在 CPU 上。

Embedding 模型与推理能力完全外部化：

• Foundry → Embedding 模型
• vLLM / API → 推理

🧠 2. 更准确的语义路由

在教程场景中：

"What is 1+1?" → math 路由
"Tell me a joke" → general 路由

使用 Foundry 嵌入后，可以获得：

• 更稳定的语义理解
• 更好的多语言支持
• 对边界场景更准确的判断

🌐 3. 统一的多模型入口

结合 Semantic Router：

• Microsoft Foundry（Embedding 模型）
• vLLM（自托管推理）
• OpenAI / 其他 API

从而实现真正的：

多提供商智能路由

10. 架构洞察

此次升级的本质是：

升级前：
路由器 = 基础设施 + 智能

升级后：
路由器 = 智能
Foundry = AI 能力

由此形成清晰的分层架构：

[ AI 能力层 ] → Microsoft Foundry
[ 路由层    ] → Semantic Router
[ 推理层    ] → vLLM / APIs

11. 总结

通过将 Microsoft Foundry 与官方远程 Embedding 模型教程相结合，我们实现了一套生产就绪的架构：

• 无需本地 Embedding 模型
• 无需 GPU
• 高质量的语义能力
• 企业级可靠性

这不仅是一次功能增强，更是 Semantic Router 的一次关键演进：

从“本地工具”演进为“云原生 AI 路由层”

如何在不显式指定模型 ID 的情况下，让系统自动选择最合适的模型？

本文介绍一种工程可落地的方案：

通过 Embedding 模型计算用户意图 → 在网关层进行语义匹配 → 动态路由到最合适的上游模型服务

我们将基于：

• Embedding 模型：Azure OpenAI text-embedding-3-small
• 网关：Envoy
• 核心机制：向量相似度打分 + 策略路由

问题背景与动机

在真实生产环境中，大模型调用通常面临几个挑战：

1. 成本与性能权衡

不同请求应该走不同模型，而不是“一刀切”。

2. 传统做法的局限

常见策略：

• 手动指定 model_id ❌（不智能）
• 基于规则（if/else）❌（不可扩展）
• 基于关键词匹配 ❌（语义不鲁棒）

3. 理想目标

我们希望：

用户只输入 prompt，系统自动理解“意图”，并选择最优模型

这正是 Embedding 可以发挥作用的地方。

核心原理：Embedding 驱动的语义路由

1. Embedding 本质

Embedding 模型（如 text-embedding-3-small）可以将文本映射为高维向量：

"写一段 Python 排序代码"
→ [0.012, -0.98, ..., 0.33]  (1536维向量)

语义相似的文本，其向量距离更近。

2. 路由思路

核心逻辑可以抽象为：

用户请求 → Embedding → 与“意图模板库”计算相似度 → 选择最佳匹配 → 路由模型

3. 意图模板（Intent Prototypes）

我们预先定义一组“意图向量”：

这些文本会提前计算 embedding 并缓存。

4. 相似度计算

常用方法：

• Cosine Similarity（推荐）

similarity = cosine(query_embedding, intent_embedding)

选择最高分：

argmax(similarity_i)

系统架构设计

整体架构如下：

                ┌──────────────┐
                │   Client     │
                └──────┬───────┘
                       │
               ┌───────▼────────┐
               │    Envoy 网关   │
               │   (智能路由层)   │
               └───────┬────────┘
                       │
        ┌──────────────┼──────────────┐
        │              │              │
 ┌──────▼─────┐ ┌──────▼─────┐ ┌──────▼─────┐
 │ GPT-4      │ │ GPT-4o-mini│ │ 专用模型    │
 └────────────┘ └────────────┘ └────────────┘

实现逻辑拆解

1. 请求流程

Step 1：获取用户请求

{
  "input": "帮我写一段 Go 的 HTTP server 示例"
}

Step 2：调用 Embedding API

使用 Azure OpenAI：

POST https://{endpoint}/openai/deployments/text-embedding-3-small/embeddings?api-version=2024-02-15-preview

请求体：

{
  "input": "帮我写一段 Go 的 HTTP server 示例"
}

Step 3：计算相似度

伪代码：

def route(query_embedding):
    best_score = -1
    best_model = None

    for intent in intents:
        score = cosine_similarity(query_embedding, intent.embedding)
        if score > best_score:
            best_score = score
            best_model = intent.model

    return best_model

Step 4：Envoy 动态路由

将结果写入 Header：

x-llm-route: gpt-4

Envoy 根据 Header 路由：

routes:
- match:
    prefix: "/v1/chat"
    headers:
      - name: x-llm-route
        exact_match: gpt-4
  route:
    cluster: gpt4_service

Envoy 网关实现方式

Envoy 本身不直接支持向量计算，因此需要扩展：

方案 1：External Processing（推荐）

Envoy 调用外部服务（ext_proc）：

Envoy → ext_proc 服务 → 返回路由决策 → Envoy 转发

ext_proc 负责：

• 调用 embedding
• 计算相似度
• 返回 header

方案 2：WASM 插件

在 Envoy 内嵌逻辑：

• 优点：低延迟
• 缺点：开发复杂（Rust/CPP）

方案 3：Sidecar Router（简单）

Client → Router Service → Envoy → Model

Router 服务负责所有智能逻辑。

优化策略

1. 向量缓存

避免重复调用 embedding：

cache[input_hash] = embedding

2. 意图分层

避免单层分类过粗：

一级：代码 / 问答 / 写作
二级：语言 / 长度 / 难度

3. 阈值控制

if best_score < threshold:
    fallback_model = "gpt-4"

防止误判。

4. 多模型融合（Ensemble）

可扩展为：

• Top-K 模型候选
• A/B 测试
• 加权路由

5. 成本感知路由

结合：

• token 预算
• 用户等级
• SLA

做策略增强：

if user == "free":
    prefer_small_model()

优势分析

相比规则路由

相比手动指定模型

• 用户体验更好（无需关心模型）
• 自动最优成本
• 支持动态策略

落地建议

1. 初始阶段

• 5~10 个意图模板即可
• 手动标注 + 调优

2. 数据驱动优化

记录：

• 用户请求
• 路由结果
• 用户反馈

持续优化 intent embedding。

3. 与 LLM Router 结合

未来可以升级为：

用小模型 + embedding 混合决策（Hybrid Router）

总结

本文方案的本质是：

用 Embedding 替代规则，用向量相似度驱动模型选择

关键收益：

• 降低成本（智能选择轻量模型）
• 提升效果（复杂任务走强模型）
• 架构解耦（路由逻辑与模型解耦）

在多模型时代，这种“语义驱动的网关”会成为标准架构组件。