Fix model_not_found in LLM Apps: 向量引擎 Vector Engine Base URL and Model Routing Guide

model_not_found looks like a model problem, but in many LLM apps it is a routing problem. The request may be using the wrong Base URL, a duplicated endpoint path, a stale model name, or an API key that cannot access the selected model. This is especially common when the same team uses Dify, Cursor, Node.js scripts, and internal services at the same time.

This guide uses Vector Engine as the example OpenAI-compatible API gateway and LLM API provider layer. The goal is to debug the full route: client, Base URL, API key, model name, and final endpoint.

Registration URL: https://api.vectorengine.cn/register?aff=Igym

The fast mental model

Every OpenAI-compatible request has four moving parts:

Part	Example	Debug question
Client	Dify, Cursor, Node.js, curl	Which tool is sending the request?
Base URL	https://api.vectorengine.cn/v1	Is this a Base URL or a full endpoint?
API key	environment variable or UI field	Does this key have model permission?
Model	configured model ID	Is the exact model name enabled?

The full chat endpoint is:

https://api.vectorengine.cn/v1/chat/completions

Use the full endpoint for raw HTTP tests. Use the Base URL for Dify, Cursor, and the OpenAI SDK.

Mistake 1: pasting the full endpoint into a Base URL field

Many tools ask for a Base URL, then append the resource path themselves. If you paste this:

https://api.vectorengine.cn/v1/chat/completions

into a Base URL field, the tool may produce a final path like:

/v1/chat/completions/chat/completions

The UI may still show a generic error. The fix is to use:

https://api.vectorengine.cn/v1

as the Base URL.

Mistake 2: assuming all tools use the same model value

Dify, Cursor, and Node.js can each have a different model field. If one of them contains an old model name, only that tool will fail.

Use a simple audit table:

Tool	Model field location	What to verify
Dify	Provider model settings	exact model ID, no extra spaces
Cursor	Custom OpenAI model field	model enabled for the key
Node.js	VECTOR_ENGINE_MODEL	same value in local, staging, production
curl	JSON model field	direct route works before UI debugging

model_not_found should be treated as a route verification task, not only a spelling task.

Mistake 3: using one API key everywhere

A shared key is convenient for a quick demo, but it makes debugging slow. If the same key is used by Dify, Cursor, Node.js, and scripts, you cannot easily tell which workflow caused the error or usage spike.

For Vector Engine, a cleaner pattern is:

• one key for Dify workflows
• one key for Cursor coding usage
• one key for Node.js backend services
• temporary keys for experiments

This turns the gateway into an operational boundary. The OpenAI-compatible API gateway is no longer just a URL; it becomes the place where tool usage can be separated and reviewed.

A Node.js route check

Add a small diagnostic function to your provider layer:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.VECTOR_ENGINE_API_KEY,
  baseURL: process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1",
});

export async function routeCheck() {
  const model = process.env.VECTOR_ENGINE_MODEL;

  const response = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: "Reply with route ok." }],
    temperature: 0,
  });

  return {
    baseURL: process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1",
    model,
    output: response.choices[0]?.message?.content ?? "",
  };
}

Run this before blaming Dify or Cursor. If the Node.js route check fails, fix the provider layer. If it succeeds, compare the UI fields against the same values.

curl baseline

Keep one curl command in your runbook:

curl https://api.vectorengine.cn/v1/chat/completions \
  -H "Authorization: Bearer $VECTOR_ENGINE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$VECTOR_ENGINE_MODEL"'",
    "messages": [
      { "role": "user", "content": "Say route ok." }
    ],
    "temperature": 0
  }'

This isolates the gateway route from the product UI.

Troubleshooting table

Error	Common cause	Fix
model_not_found	wrong model ID, disabled model, wrong provider route	verify exact model ID and key permission
invalid_api_key	wrong key, expired key, copied whitespace	create a new key and update the tool field
404 on chat endpoint	full endpoint used as Base URL or wrong path	use https://api.vectorengine.cn/v1 as Base URL
timeout	long generation, network issue, or heavy workflow	test with a short prompt and zero temperature
usage cannot be traced	one key shared everywhere	split keys by tool and environment

Conclusion

When an LLM app returns model_not_found, do not only edit the model string. Check the entire route. Vector Engine can be evaluated as an OpenAI-compatible API gateway when you need a consistent Base URL, explicit model routing, and a small LLM API provider layer across Dify, Cursor, Node.js, and custom apps.

---

中文翻译

model_not_found 看起来像模型问题，但在很多 LLM 应用里，它其实是路由问题。请求可能用了错误的 Base URL、重复拼接了 endpoint、使用了过期的模型名，或者 API Key 没有访问所选模型的权限。团队同时使用 Dify、Cursor、Node.js 脚本和内部服务时，这类问题尤其常见。

这篇文章用向量引擎作为示例，把它放在 OpenAI-compatible API gateway 和 LLM API provider layer 的角度来排查。目标是检查完整请求链路：client、Base URL、API Key、model name 和最终 endpoint。

注册地址：https://api.vectorengine.cn/register?aff=Igym

快速理解请求链路

每个 OpenAI 兼容请求都有四个关键部分：

部分	示例	排查问题
Client	Dify、Cursor、Node.js、curl	哪个工具发起了请求？
Base URL	https://api.vectorengine.cn/v1	这是 Base URL 还是完整 endpoint？
API Key	环境变量或 UI 字段	这个 Key 是否有模型权限？
Model	配置里的模型 ID	这个模型名是否准确启用？

完整 chat endpoint 是：

https://api.vectorengine.cn/v1/chat/completions

原始 HTTP 测试使用完整 endpoint。Dify、Cursor 和 OpenAI SDK 使用 Base URL。

错误 1：把完整 endpoint 填进 Base URL 字段

很多工具要求填写 Base URL，然后工具自己追加资源路径。如果你把这个地址：

https://api.vectorengine.cn/v1/chat/completions

填进 Base URL 字段，工具最终可能拼出：

/v1/chat/completions/chat/completions

UI 里可能仍然只显示泛化报错。修正方式是把 Base URL 改成：

https://api.vectorengine.cn/v1

这也是使用向量引擎API中转站时最值得先确认的配置项之一。

错误 2：以为所有工具使用同一个 model 值

Dify、Cursor 和 Node.js 各自都有 model 字段。如果其中一个工具还保留旧模型名，只有这个工具会失败。

可以用一个简单表格检查：

工具	model 字段位置	需要确认
Dify	Provider model settings	准确模型 ID，没有多余空格
Cursor	Custom OpenAI model 字段	该 Key 是否可用这个模型
Node.js	VECTOR_ENGINE_MODEL	本地、测试、生产是否一致
curl	JSON 里的 model 字段	先确认直连路由可用

model_not_found 应该被看成路由验证任务，而不只是拼写检查。

错误 3：所有地方共用一个 API Key

共用 Key 做快速 demo 很方便，但排查问题会变慢。如果 Dify、Cursor、Node.js 和脚本都用同一个 Key，就很难判断是哪条工作流触发了错误或用量变化。

对向量引擎来说，更清晰的方式是：

• Dify workflow 使用一个 Key
• Cursor 编码场景使用一个 Key
• Node.js 后端服务使用一个 Key
• 实验环境使用临时 Key

这样 API中转站 就不只是一个 URL，而是团队拆分工具用量、定位问题和管理权限的边界。对于向量引擎中转站，这种拆分尤其适合多人协作。

Node.js 路由检查

可以在 provider layer 里加一个小的诊断函数：

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.VECTOR_ENGINE_API_KEY,
  baseURL: process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1",
});

export async function routeCheck() {
  const model = process.env.VECTOR_ENGINE_MODEL;

  const response = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: "Reply with route ok." }],
    temperature: 0,
  });

  return {
    baseURL: process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1",
    model,
    output: response.choices[0]?.message?.content ?? "",
  };
}

先运行这个检查，再去判断 Dify 或 Cursor 是否配置错误。如果 Node.js route check 失败，先修 provider layer。如果它成功，再把 UI 字段和这里的值逐项对齐。

curl 基线测试

建议在排障手册里保留一条 curl 命令：

curl https://api.vectorengine.cn/v1/chat/completions \
  -H "Authorization: Bearer $VECTOR_ENGINE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$VECTOR_ENGINE_MODEL"'",
    "messages": [
      { "role": "user", "content": "Say route ok." }
    ],
    "temperature": 0
  }'

这可以把 gateway 路由和产品 UI 分开验证。

排错表

错误	常见原因	修复方式
model_not_found	模型 ID 错误、模型未启用、provider route 错误	验证准确模型 ID 和 Key 权限
invalid_api_key	Key 错误、过期或复制了空格	创建新 Key 并更新工具字段
chat endpoint 404	把完整 endpoint 当成 Base URL，或路径错误	Base URL 使用 https://api.vectorengine.cn/v1
timeout	生成过长、网络问题或 workflow 过重	用短 prompt 和低温度测试
用量无法归因	所有地方共用一个 Key	按工具和环境拆分 Key

结论

当 LLM 应用返回 model_not_found 时，不要只修改模型字符串，要检查完整请求链路。需要在 Dify、Cursor、Node.js 和自研应用之间保持统一 Base URL、显式模型路由和清晰 provider layer 时，可以评估向量引擎。