[bug]内置 nvidia provider 模型列表过时，请求返回 HTTP 410 Gone

[veryspicy]

问题描述

当用户使用 DSH 内置的 nvidia provider（不显式配置 models 列表）时，模型列表来自 pi-ai 的静态 catalog，其中的模型条目已过时（pre-DeepSeek / pre-Gemma-4 时代）。调用这些模型会触发 NVIDIA API 返回 HTTP 410 Gone，错误码被模糊地归类为 PI_AI_ERROR。

相比之下，用户自定义的 nvidia-nim provider（不在 pi-ai catalog 中）会走动态 GET /models 路径，能获取最新列表，正常工作。

复现步骤

在 settings.yaml 中配置：
yaml
复制
llm-pi-ai:
providers:
nvidia:
apiKeyEnv: NVIDIA_API_KEY
不显式声明 models 列表
尝试使用内置 nvidia provider 的任意模型（如 meta/llama-3.1-70b-instruct）
观察错误：PI_AI_ERROR / 410 status code (no body)
期望行为

内置 nvidia provider 应像自定义 provider 一样，动态从 NVIDIA API 拉取最新可用模型列表，或在 catalog 层面自动替换已过时的模型。

实际行为

返回 HTTP 410 Gone，错误码为不透明的 PI_AI_ERROR。

根因分析

packages/llm/llm-pi-ai/src/discovery.ts 第 199-211 行：

typescript
复制
// catalog 路由直接短路返回静态列表，从不调 API
if (request.provider !== undefined) {
const installed = catalogModels(request.provider)
if (installed.size > 0) {
return [...installed.values()] // ← 永远不走网络
}
}
而 nvidia-nim 等自定义 provider 因为不在 pi-ai catalog 中，会走到第 232 行的 fetch(url) 动态获取逻辑。

建议修复方向

discovery.ts：对 nvidia provider 跳过静态 catalog 短路，改为动态探测
catalog.ts：新增 NVIDIA_CATALOG_PATCH 常量，在 resolveRouteModels 中自动替换过时模型
stream.ts：classifyPiAiError 增加 410 分类（返回 GONE），错误信息更明确

[veryspicy]

使用默认列表里的淘汰的模型报错
官方提供方列出的模型列表
自定义提供方获取的最新模型列表

[argszero]

Your root-cause analysis is accurate, and this is a clean two-part bug. I read the alpha.2 source (0a53fb55be) and confirmed both halves — plus found the classification gap highlights a real retry-loop risk.

Part 1 — static catalog short-circuit (confirmed).

packages/llm/llm-pi-ai/src/discovery.ts (the "fetch available models" action) short-circuits to the installed pi-ai catalog whenever the provider has catalog entries:

if (request.provider !== undefined) {
  const installed = catalogModels(request.provider)
  if (installed.size > 0) {
    return [...installed.values()].map(model => ({ id: model.id, ... }))  // ← never hits network
  }
}

The nvidia provider ships in the catalog, so every model listing comes from that frozen static list. A custom nvidia-nim provider is absent from the catalog, so it falls through to the fetch(url) dynamic path and stays current. Exactly as you describe. The stale catalog entries are the root of the 410s.

Part 2 — 410 not classified (confirmed, and this is the higher-risk half).

stream.ts classifyPiAiError has branches for 401/403→AUTH, quota→QUOTA_EXCEEDED, 429→RATE_LIMIT, 413/400→INVALID_REQUEST, 5xx→SERVER, timeout→TIMEOUT, stream-truncation/network→TRANSPORT — but no 410 branch, so a 410 falls through to the opaque PI_AI_ERROR.

The risk is the retry classification. PI_AI_ERROR (in some configurations) is treated as retryable. A 410 Gone means the model itself no longer exists — resending the identical request can never succeed, so the model should be treated as invalid/non-retryable, not as a generic provider error. Without a 410 branch, a user picking a retired catalog model gets a sticky loop of identical failing requests (and the error message is opaque).

Proposed fix directions (highest-to-lowest blast radius):

1. discovery.ts — skip the static catalog for nvidia and let it use the dynamic GET /models path (your option 1). This fixes the listing — a user picking an entry from the refreshed list won't get a 410. Cleanest for the affected provider, and testable: assert a catalogModels('nvidia').size > 0 provider still routes to network when a "dynamic" flag is set.
2. stream.ts — add a 410 branch to classifyPiAiError returning a distinct GONE / MODEL_NOT_FOUND non-retryable code. This fixes the classification so an already-broken selection degrades clearly instead of looping. High value even independent of part 1, and it's the sibling of the missing-402 classification I'd flag in the same error mapper.
3. catalog.ts — a NVIDIA_CATALOG_PATCH to refresh just the stale entries without changing the route logic. Lower return than option 1 for a provider whose whole model set goes stale, but cheap.

For the test suite, a good pairing is: (a) a discovery test that a catalog provider marked "dynamic" calls network rather than returning the static list; (b) a classifyPiAiError('... 410 ...') test asserting it returns a non-retryable code, so the no-410 gap stays closed.

This is the same error-classification class as the missing-402 handling in d8e4b7c2 — the pattern is "one exit code family missing from classifyPiAiError → opaque PI_AI_ERROR → potential sticky retry". Worth handling both while the mapper is open.

[Kynmmarshall]

Nice interesting mate