后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载本文基于 semantic-router 仓库的 Router API 参考文档router.md系统讲解该项目的 API 体系包括基于 gRPC 的 Envoy ExtProc 集成协议、OpenAI 兼容的/v1/models与/v1/chat/completions端点、路由 Header 约定以及/health、/metrics等运维监控接口。读完本篇你可以完成与 Router 的端到端集成并建立一套覆盖分类、缓存、安全、成本与 TTFT/TPOT 延迟的可观测性监控方案。1. API 概览Router 作为 ExtProc 服务器Semantic Router 提供了一个基于 gRPC 的 API可与 Envoy 的外部处理ExtProc协议无缝集成。Router 作为一个 ExtProc 服务器运行通过 Envoy 代理处理 HTTP 请求。它不直接公开 REST endpoint 处理推理流量而是处理通过 Envoy 路由的 OpenAI 兼容 API 请求。注意除了 ExtProc 路径外该项目还在8080 端口启动了一个轻量级的 HTTP Classification API用于健康/信息和分类工具。OpenAI 兼容的/v1/models端点由该 HTTP API8080提供并可以通过路由规则在 Envoy8801上有选择地公开。1.1 端口和端点映射端口协议用途8801HTTPEnvoy 公共入口。典型的客户端入口用于 OpenAI 兼容请求如POST /v1/chat/completions。如果添加了 Envoy 路由可以将GET /v1/models代理到 Router 8080否则 8801 的/v1/models可能返回 no healthy upstream8080HTTPClassification APIGET /v1/modelsOpenAI 兼容模型列表含合成的MoM、GET /health、GET /info/models已加载的分类器模型 系统信息、GET /info/classifier分类器配置详情、POST /api/v1/classify/intent\|pii\|security\|batch直接分类工具50051gRPCEnvoy 外部处理ExtProc用于/v1/chat/completions的路径内分类/路由。注意这不是 HTTP 端口无法直接通过 curl 访问9190HTTPPrometheus 指标GET /metrics全局进程指标抓取端点这些端口在源码中得到了印证。启动引导代码 中定义了运行参数的默认值port flag.Int(port, 50051, Port to listen on for gRPC ExtProc) apiPort flag.Int(api-port, 0, Port to listen on for the router apiserver (default from config: 8080)) metricsPort flag.Int(metrics-port, 9190, Port for Prometheus metrics)即 gRPC ExtProc 默认监听50051、Prometheus 指标默认监听9190而 Classification API 的8080端口默认取自配置文件。1.2 请求流程一次完整的聊天补全请求在客户端、Envoy、Router 和后端模型之间的流转如下关键设计点Router 在请求阶段做分类与路由决策并以路由 Header 的形式返回给 Envoy由 Envoy 根据这些 Header 完成流量调度在响应阶段 Router 再次介入对响应做增强追加元数据 Header、安全标记等客户端最终拿到的是增强后的响应。2. OpenAI API 兼容性路由处理标准的 OpenAI API 请求主要包括两个端点模型列表与聊天补全。2.1 模型端点GET /v1/models列出可用模型并包含一个合成的MoMMixture of Models模型该模型使用 Router 的 intent classification 为每个请求选择最佳的基础模型。响应示例{ object: list, data: [ { id: MoM, object: model, created: 1726890000, owned_by: semantic-router }, { id: gpt-4o-mini, object: model, created: 1726890000, owned_by: upstream-endpoint }, { id: llama-3.1-8b-instruct, object: model, created: 1726890000, owned_by: upstream-endpoint } ] }注意事项具体的模型列表来源于config.yaml中配置的 vLLM 端点见vllm_endpoints[].models特殊的MoMMixture of Models模型始终存在并指示 Router 自动分类并路由到最佳后端模型。为了向后兼容模型名称auto也被接受为别名。源码印证/v1/models的处理入口在 handleOpenAIModels它根据当前生效的配置生成模型列表并通过ListBackendModels配置项默认false控制是否在列表中额外包含具体后端模型——默认情况下客户端看到的入口模型更少更干净配置开启后才能直接看到所有可指定的后端模型名。2.2 聊天补全端点POST /v1/chat/completions请求格式{ model: gpt-3.5-turbo, messages: [ { role: user, content: x^2 的导数是多少 } ], max_tokens: 150, temperature: 0.7, tools: [ { type: function, function: { name: calculator, description: 执行数学计算 } } ] }响应格式响应在标准 OpenAI 结构之外附带了routing_metadata字段用于暴露 Router 的决策信息{ id: chatcmpl-abc123, object: chat.completion, created: 1677858242, model: gpt-3.5-turbo, choices: [ { index: 0, message: { role: assistant, content: x^2 的导数是 2x。 }, finish_reason: stop } ], usage: { prompt_tokens: 12, completion_tokens: 8, total_tokens: 20 }, routing_metadata: { selected_model: mathematics, confidence: 0.96, processing_time_ms: 15, cache_hit: false, security_checks: { pii_detected: false, jailbreak_detected: false } } }routing_metadata使客户端无需解析 Header 也能获知请求被路由到了哪个类别/模型、分类置信度、处理耗时、是否命中缓存以及 PII / 越狱jailbreak安全检查的结果。3. 路由 Header路由在请求和响应中都会添加元数据 Header这是 Router 与 Envoy 之间传递路由决策的主要机制。3.1 请求 Header由路由添加Header描述示例x-vsr-destination-endpoint选定的后端端点endpoint1x-selected-model确定的模型类别mathematicsx-routing-confidence分类置信度0.956x-request-id唯一请求标识符req-abc123x-cache-status缓存命中/未命中状态miss3.2 响应 Header由路由添加Header描述示例x-processing-time总处理时间 (ms)45x-classification-time分类时间 (ms)12x-security-checks安全检查结果pii:false,jailbreak:falsex-tools-selected选定的工具数量23.3 从源码看完整的x-vsr-*Header 契约上表是文档层面的核心契约。当前源码中Header 的完整定义集中在 headers.go可以推断出实际部署中的 Header 面比早期文档更广形成了一套带版本号的响应契约v0.4。几个值得关注的要点决策追踪 Headerx-vsr-selected-category分类器选定的 MMLU 类别、x-vsr-selected-decisionDecisionEngine 最终选定的决策、x-vsr-selected-confidence0.0–1.0 的置信度、x-vsr-selected-model最终处理请求的模型名、x-vsr-routing-latency-ms路由耗时微秒精度。响应契约标记x-vsr-schema-version标注 Header 契约修订版当前为2x-vsr-response-path标明响应产生路径取值包括upstream、cache、fast_response、looper、image_generation、blocked、rate_limited、error、fallback等。这两个 Header 出现在每一次 VSR 处理的响应上客户端可据此判断这次响应到底是谁产生的。信号追踪 Headerx-vsr-matched-keywords、x-vsr-matched-embeddings、x-vsr-matched-pii、x-vsr-matched-jailbreak等暴露哪些信号规则被命中便于调试决策过程。客户端控制 Headerx-vsr-debug为单请求开启调试/回放模式 Header、x-vsr-skip-processing在global.router.skip_processing.enabled为 true 时让请求跳过所有路由处理、x-session-id客户端指定会话 ID。缓存与成本 Headerx-vsr-cache-hit、x-vsr-cost与x-vsr-cost-currency按所选模型配置的计价计算响应成本。从源码结构看Header 是调试/运维面的主要载体默认面保持精简完整诊断信息如幻觉检测 span、越狱类型与置信度放在 Router Replay 记录中可通过x-vsr-replay-id关联取回。4. 健康检查 APIRouter 提供用于监控的健康检查 endpoint端点GET http://localhost:8080/health{ status: healthy, version: 1.0.0, uptime: 3600, models: { category_classifier: loaded, pii_detector: loaded, jailbreak_guard: loaded }, cache: { status: healthy, entries: 1247, hit_rate: 0.73 }, endpoints: { endpoint1: healthy, endpoint2: healthy, endpoint3: degraded } }该健康检查聚合了四个维度进程状态与版本、各分类模型类别分类器、PII 检测器、越狱防护的加载状态、响应缓存的健康度与命中率、以及各后端端点的健康状态healthy/degraded。从源码看/health是 Classification API 中少数允许匿名访问的端点参见 route_auth_test.go 中匿名 /health 应成功的断言适合直接用于负载均衡器或编排系统的存活探针。此外还有/ready、/startup-status等就绪/启动状态端点可供使用。与文档中/info/models、/info/classifier对应的库存信息接口在当前源码中挂载于管理 API 命名空间下见 routes_catalog.goGET /api/v1/inventory/models已加载模型信息GET /api/v1/inventory/classifier分类器信息与状态无secret_view权限时密钥被脱敏GET /api/v1/inventory/embedding-models、GET /api/v1/inventory/model-runtime嵌入模型与 model_runtime 部署的进程/就绪/重启/服务模型卡信息。直接分类工具端点在当前源码中位于诊断命名空间包括POST /api/v1/diagnostics/classify/intent、/api/v1/diagnostics/classify/pii、/api/v1/diagnostics/classify/security以及POST /api/v1/classify/batch等见 api_paths.go 与 routes_catalog.go可用于在不发真实补全请求的情况下验证分类模型行为。5. 指标 APIMetrics APIRouter 提供 Prometheus 兼容指标抓取端点为GET http://localhost:9190/metrics由 main.go 中的独立 metrics HTTP server 提供可用--metrics-port覆盖默认端口 9190。5.1 关键指标# 请求指标 semantic_router_requests_total{endpointendpoint1,categorymathematics,statussuccess} 1247 semantic_router_request_duration_seconds{endpointendpoint1} 0.045 # 分类指标 semantic_router_classification_accuracy{categorymathematics} 0.94 semantic_router_classification_duration_seconds 0.012 # 缓存指标 semantic_router_cache_hit_ratio 0.73 semantic_router_cache_size 1247 # 安全指标 semantic_router_pii_detections_total{actionblock} 23 semantic_router_jailbreak_attempts_total{actionblock} 5 # 错误指标 llm_request_errors_total{modelgpt-4,reasontimeout} 12 llm_request_errors_total{modelclaude-3,reasonupstream_5xx} 3 llm_request_errors_total{modelphi4,reasonupstream_4xx} 5 llm_request_errors_total{modelphi4,reasonpii_policy_denied} 85.2 推理模式指标Reasoning Mode MetricsRouter 公开了专用的 Prometheus 计数器用于监控跨模型家族的 reasoning mode 决策和 template 使用情况。这些指标由 Router 发送可以由你的 Prometheus 服务器抓取。llm_reasoning_decisions_total{category, model, enabled, effort}描述按类别和所选模型记录的推理决策计数包括是否启用推理以及应用的努力等级effort level。标签category路由期间确定的类别名称model请求最终选择的模型enabled根据决策结果为true或falseeffort启用时的努力等级例如low|medium|highllm_reasoning_template_usage_total{family, param}描述特定模型家族模板参数应用于请求的次数统计。标签family规范化的模型家族例如qwen3, deepseek, gpt-oss, gptparam应用的模板参数名称例如enable_thinking, thinking, reasoning_effortllm_reasoning_effort_usage_total{family, effort}描述为给定模型家族设置推理努力等级的次数统计。标签family规范化的模型家族effort努力等级例如low|medium|high这三个计数器在 reasoning_metrics.go 中定义记录入口函数分别为RecordReasoningDecision、RecordReasoningTemplateUsage、RecordReasoningEffortUsage从源码看当family或param/effort为空时会归一化为unknown/none/unspecified保证标签基数可控。PromQL 示例# 按类别和模型划分的推理决策最近 5 分钟 sum by (category, model, enabled, effort) ( rate(llm_reasoning_decisions_total[5m]) ) # 按模型家族和参数划分的模板使用情况最近 5 分钟 sum by (family, param) ( rate(llm_reasoning_template_usage_total[5m]) ) # 按模型家族划分的努力等级分布最近 5 分钟 sum by (family, effort) ( rate(llm_reasoning_effort_usage_total[5m]) )5.3 成本和路由指标Router 为成本核算和路由决策公开了额外的指标。llm_model_cost_total{model, currency}描述归属于每个模型的总累计成本根据 token 使用情况和每 1M 定价计算按货币标记。标签model用于请求的模型名称、currency货币代码例如USDllm_routing_reason_codes_total{reason_code, model}描述按原因代码和所选模型划分的路由决策计数。标签reason_code发生路由决策的原因例如auto_routing, model_specified, pii_policy_alternative_selected、model最终选择的模型两个计数器均在 metrics.go 中注册ModelCost、RoutingReasonCodes。PromQL 示例# 过去一小时内按模型和货币划分的成本 sum by (model, currency) (increase(llm_model_cost_total[1h])) # 或者如果你只使用 USD常见的查询是 sum by (model) (increase(llm_model_cost_total{currencyUSD}[1h])) # 过去 15 分钟内按原因代码划分的路由决策 sum by (reason_code) (increase(llm_routing_reason_codes_total[15m]))5.4 请求错误指标Router 按模型和原因跟踪请求级失败因此你可以监控绝对错误吞吐量和失败请求的比例。llm_request_errors_total{model, reason}描述按失败原因分类的请求错误总数标签model失败请求的目标模型名称reason错误类别timeout, upstream_4xx, upstream_5xx, pii_policy_denied, jailbreak_block, parse_error, serialization_error, cancellation, classification_failed, unknown该计数器的 help 文本在 metrics.go 中明确列出了timeout, upstream_5xx, pii_policy_denied, jailbreak_block, parse_error, serialization_error, cancellation等原因extproc 层的测试extproc_test.go验证了parse_error、upstream_5xx、upstream_4xx等标签值在相应故障路径下确实会递增。PromQL 查询示例# 过去一小时内按原因划分的总错误数 sum by (reason) (increase(llm_request_errors_total[1h])) # 过去 15 分钟内按模型划分的错误吞吐量错误数/秒。 # 这对于事件响应很有帮助因为它显示了有多少失败请求正在影响用户。 sum by (model) (rate(llm_request_errors_total[15m])) # 过去 15 分钟内按模型划分的错误率失败请求的百分比。 # 使用 increase() 使分子和分母在相同的回溯窗口内对齐。 100 * sum by (model) (increase(llm_request_errors_total[15m])) / sum by (model) (increase(llm_model_requests_total[15m])) # 过去 24 小时内 PII 策略拦截的数量 sum(increase(llm_request_errors_total{reasonpii_policy_denied}[24h]))5.5 TTFT 和 TPOT 指标TTFTTime To First Token首 token 时间和 TPOTTime Per Output Token每输出 token 时间以 Prometheus histogram 的形式导出可以使用histogram_quantile在 p95 处可视化llm_model_ttft_seconds{model}直方图公开_bucket、_sum、_count描述自 Router 开始处理请求以来的 Time To First Token按模型划分的 p95 示例最近 5 分钟histogram_quantile(0.95, sum(rate(llm_model_ttft_seconds_bucket[5m])) by (le, model))llm_model_tpot_seconds{model}直方图公开_bucket、_sum、_count描述每输出 token 的秒数completion 延迟 / completion token 数按模型划分的 p95 示例最近 5 分钟histogram_quantile(0.95, sum(rate(llm_model_tpot_seconds_bucket[5m])) by (le, model))这两个 TTFT/TPOT p95 面板已包含在仓库自带的 Grafana 仪表板中TTFT (p95) by Model 与 TPOT (p95) by Model (sec/token)。在当前仓库中该仪表板以 ConfigMap 形式随部署清单一起提供见 Kubernetes 部署的仪表板第 2207 行与第 2296 行附近即对应的histogram_quantile(0.95, ...)查询以及 OpenShift 部署的仪表板。流式传输SSE注意事项对于服务器发送事件SSE响应路由测量的是第一个流式正文块即第一个 token的 TTFT而不是响应 Header无需手动更改 Envoy 配置ExtProc 处理程序会自动为 SSE 响应设置带有response_body_mode: STREAMED的ModeOverride以便第一个块立即到达 ExtProc前提条件Envoy 的ext_proc过滤器必须具有allow_mode_override: true仓库默认的本地/部署配置已经包含此项例如 deploy/local/envoy.yaml 第 78 行以及deploy/kubernetes/下多个 EnvoyFilter/网关清单在静态处理模式中保持response_body_mode: BUFFERED是可以的——路由会在运行时为 SSE 将其翻转为 STREAMED。5.6 定价配置为你的模型提供每 1M token 的 pricing以便 Router 可以计算请求成本并发出 metrics/logmodel_config: phi4: pricing: currency: USD prompt_per_1m: 0.07 completion_per_1m: 0.35 mistral-small3.1: pricing: currency: USD prompt_per_1m: 0.1 completion_per_1m: 0.3 gemma3:27b: pricing: currency: USD prompt_per_1m: 0.067 completion_per_1m: 0.267注意事项定价是可选的如果省略成本视为 0且仅发出 token 指标成本计算公式为(prompt_tokens * prompt_per_1m completion_tokens * completion_per_1m) / 1,000,000以配置的货币计算。从源码看计价结构定义在 catalog/types.go 的Pricing中除文档中的currency、prompt_per_1m、completion_per_1m外还支持cached_input_per_1m缓存输入 token 单价和cache_write_per_1m缓存写入单价。成本计算实际发生在 extproc 的响应处理阶段model_pricing.go它会先用Normalize对 usage 做归一化再计价因此响应体中的x-vsr-costHeader 与llm_model_cost_total指标使用同一套口径。6. gRPC ExtProc API用于与 Envoy 的 ExtProc 协议直接集成6.1 服务定义syntax proto3; package envoy.service.ext_proc.v3; service ExternalProcessor { rpc Process(stream ProcessingRequest) returns (stream ProcessingResponse); } message ProcessingRequest { oneof request { RequestHeaders request_headers 1; RequestBody request_body 2; ResponseHeaders response_headers 3; ResponseBody response_body 4; } } message ProcessingResponse { oneof response { RequestHeadersResponse request_headers 1; RequestBodyResponse request_body 2; ResponseHeadersResponse response_headers 3; ResponseBodyResponse response_body 4; } }Process是双向流Envoy 按请求 Header → 请求体 → 响应 Header → 响应体的顺序推送ProcessingRequestRouter 在每一阶段返回对应的ProcessingResponse继续/改写/短路。6.2 处理方法请求 Header 处理——提取请求元数据、设置请求上下文、返回 continue 响应func (r *Router) handleRequestHeaders(headers *ProcessingRequest_RequestHeaders) *ProcessingResponse { // 提取请求元数据 // 设置请求上下文 // 返回 continue 响应 }请求正文处理——这是路由决策的核心阶段func (r *Router) handleRequestBody(body *ProcessingRequest_RequestBody) *ProcessingResponse { // 解析 OpenAI 请求 // 分类查询意图 // 运行安全检查 // 选择最优模型 // 返回路由 Header }从源码结构看当前实现将这四个阶段拆分在pkg/extproc包的一组处理程序中processor_req_header.goHeader 阶段、processor_req_body.go 与 processor_req_body_routing.go请求体解析、路由决策、processor_res_header.go 与 processor_res_body.go响应阶段。pkg/extproc/testdata/parity/下保存了大量parity 语料如auto-essay-anthropic-backend.json、client-selected-model-overwritten.json、upstream-503.json等请求/响应记录用于回归验证各阶段行为是理解该协议实际报文形态的极好材料。7. 错误处理7.1 错误响应格式{ error: { message: 在请求中检测到 PII, type: security_violation, code: pii_detected, details: { entities_found: [EMAIL, PERSON], action_taken: block } } }7.2 HTTP 状态码状态码描述200成功400Bad Request格式错误的输入403Forbidden违反安全规定429Too Many Requests频率限制500Internal Server Error内部服务器错误503Service Unavailable后端掉线当请求因守卫规则被拒绝如 PII 拦截、越狱拦截时客户端除了收到错误响应外还可以从x-vsr-response-path: blocked响应 Header 中直接判断该响应是被守卫拒绝的这在自动化重试逻辑中非常有用。8. 配置 API 与运行时更新8.1 运行时配置更新v0.2 契约端点POST /admin/config/update{ classification: { confidence_threshold: 0.8 }, security: { enable_pii_detection: true }, cache: { ttl_seconds: 7200 } }该端点允许在不重启 Router 的情况下热更新分类置信度阈值、安全检测开关与缓存 TTL 等运行时参数。从源码结构看当前仓库的管理面 API 已演进到统一命名空间/api/v1下配置生命周期围绕部署→激活→回滚展开包括GET /api/v1/config、POST /api/v1/config/validate、POST /api/v1/config/plan、GET /api/v1/config/versions、POST /api/v1/config/rollback、GET /api/v1/config/hash等见 api_paths.go所有写操作还带审计记录/api/v1/observability/audit。如果你的部署基于较新主干建议以这些端点为准v0.2 文档中的/admin/config/update语义可视为其早期形态。9. WebSocket API可选用于实时流式响应端点ws://localhost:8801/v1/chat/streamconst ws new WebSocket(ws://localhost:8801/v1/chat/stream); ws.send(JSON.stringify({ model: gpt-3.5-turbo, messages: [{role: user, content: 讲个故事}], stream: true })); ws.onmessage function(event) { const chunk JSON.parse(event.data); console.log(chunk.choices[0].delta.content); };注意该端点标注为可选在标准部署中流式补全通常通过POST /v1/chat/completionsstream: true以 SSE 形式提供配合 5.5 节所述的STREAMED模式覆写WebSocket 端点用于需要双工连接的场景。10. 客户端库示例10.1 Python 客户端import requests class SemanticRouterClient: def __init__(self, base_urlhttp://localhost:8801): self.base_url base_url def chat_completion(self, messages, modelgpt-3.5-turbo, **kwargs): response requests.post( f{self.base_url}/v1/chat/completions, json{ model: model, messages: messages, **kwargs } ) return response.json() def get_health(self): response requests.get(f{self.base_url}/health) return response.json() # 使用示例 client SemanticRouterClient() result client.chat_completion([ {role: user, content: 2 2 等于多少} ])10.2 JavaScript 客户端class SemanticRouterClient { constructor(baseUrl http://localhost:8801) { this.baseUrl baseUrl; } async chatCompletion(messages, model gpt-3.5-turbo, options {}) { const response await fetch(${this.baseUrl}/v1/chat/completions, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ model, messages, ...options }) }); return response.json(); } async getHealth() { const response await fetch(${this.baseUrl}/health); return response.json(); } } // 使用示例 const client new SemanticRouterClient(); const result await client.chatCompletion([ { role: user, content: 求解 x^2 5x 6 0 } ]);由于 Router 严格保持 OpenAI 兼容的请求/响应形状任何 OpenAI SDK将base_url指向http://localhost:8801也可以直接使用只需把model字段设为MoM或别名auto即可触发自动分类路由。11. 频率限制Rate Limiting路由使用以下 Header 实施频率限制X-RateLimit-Limit: 1000 X-RateLimit-Remaining: 999 X-RateLimit-Reset: 1640995200 X-RateLimit-Retry-After: 60当触发限制时响应体遵循统一的错误结构{ error: { message: 超出频率限制, type: rate_limit_error, code: too_many_requests, details: { limit: 1000, window: 1h, retry_after: 60 } } }客户端应优先读取X-RateLimit-Remaining做主动限流并在收到 429 时按X-RateLimit-Retry-After或details.retry_after退避重试。12. 最佳实践12.1 请求优化在请求中提供充分的上下文system prompt和相关工具声明有助于分类器更准确地判定意图# 包含相关的上下文 messages [ { role: system, content: 你是一位数学导师。 }, { role: user, content: 用简单的术语解释导数 } ] # 使用合适的工具 tools [ { type: function, function: { name: calculator, description: 用于数学计算 } } ]12.2 错误处理try: response client.chat_completion(messages) if error in response: handle_router_error(response[error]) else: process_response(response) except requests.exceptions.Timeout: handle_timeout_error() except requests.exceptions.ConnectionError: handle_connection_error()12.3 监控集成import time start_time time.time() response client.chat_completion(messages) duration time.time() - start_time # 记录路由元数据 routing_info response.get(routing_metadata, {}) logger.info(f请求被路由到 {routing_info.get(selected_model)} f置信度为 {routing_info.get(confidence)} f耗时 {duration:.2f}s)将routing_metadata落入应用日志再与 9190 端口导出的llm_routing_reason_codes_total、llm_request_errors_total等指标对照可以建立单请求决策与集群级趋势两级可观测性。13. 进一步阅读Classification API 参考详细的分类端点说明快速入门指南真实世界的集成示例配置指南生产环境配置核心源码入口extproc 处理包、Header 契约定义、指标注册、Classification API 路由目录端到端验证用例e2e 测试目录 中的网关级集成测试可帮助确认各端点在真实 Envoy 栈下的行为版本提示本文以仓库中 v0.2 文档翻译版为主体并对照当前源码补充了演进信息如管理 API 迁移到/api/v1命名空间、x-vsr-*v0.4 Header 契约等。不同版本间端点路径可能存在差异实际接入时请以你所部署版本自带的 OpenAPI 规范端点/openapi.json输出为准。赞分享后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载相关推荐Semantic Router 的 Router API 参考基于 Envoy ExtProc 的 gRPC 路由接口、指标与集成实战Semantic Router 的 Router API 参考基于 Envoy ExtProc 的 gRPC 路由接口、指标与集成实战 Semantic Ro后端API网关模型推理服务AI AgentSemantic Router 协议兼容矩阵三大推理线协议的端到端翻译与 api_format 配置实战Semantic Router 协议兼容矩阵三大推理线协议的端到端翻译与 api_format 配置实战 Semantic Router 在数据平面两侧支持后端API网关模型推理服务AI AgentSemantic Router CRD API 参考vllm.ai/v1alpha1 下 IntelligentPool 与 IntelligentRoute 全字段详解Semantic Router CRD API 参考vllm.ai/v1alpha1 下 IntelligentPool 与 IntelligentRoute后端API网关模型推理服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考