feat: 支持供应商gpustack与xinference

[jiangwel]

支持供应商gpustack与xinference

变更类型

• Bug修复 (不兼容的变更，修复某个问题)
• 新功能 (不兼容的变更，添加新功能)
• 破坏性变更 (修复或功能会导致现有功能无法按预期工作)
• 文档更新
• 代码重构
• 其他 (请说明)

[yokowu]

@MonkeyCode-AI review

[nanzhongguohai]

@MonkeyCode-AI 帮我review一下这个代码

[yokowu]

@MonkeyCode-AI 帮我review一下这个代码

[yokowu]

@MonkeyCode-AI review

[MonkeyCode-AI]

⏳ MonkeyCode-AI 正在分析，请稍等片刻...

[MonkeyCode-AI]

⏳ MonkeyCode-AI 正在分析，请稍等片刻...

[BKL5]

@MonkeyCode-AI 安装离线版所有模型需要多少容量的存储

[BKL5]

@MonkeyCode-AI m3-6Y30处理器是否可以用于安装离线版

[MonkeyCode-AI]

@MonkeyCode-AI review

[yokowu]

@MonkeyCode-AI review

[monkeycodebot]

💬 代码审查

评论: 整体来看该 PR 以依赖升级与依赖清理为主，方向合理，但存在较高的构建可复现性与回归风险，需要在合并前重点把关。当前需要明确确认 go.mod/go.sum 与依赖图一致、被移除依赖对应功能未受影响，并补齐后端与 UI 升级后的回归验证。另需尽快处理后端新增封装带来的可维护性问题（变量遮蔽）及潜在 nil 初始化风险以保证稳定性。

📊 统计

• 总问题数: 12
• 🔴 严重: 0
• 🟡 警告: 9
• 🔵 建议: 3
• ⚪ 细节: 0

🟡 警告 (9)

logrus 被标记为 indirect 可能与实际使用不一致 backend/go.mod:111

描述: 将 github.com/sirupsen/logrus 从直接依赖移到 indirect，意味着当前模块不再显式声明使用 logrus。如果项目代码仍直接 import logrus，go mod tidy 可能会把它重新提升为直接依赖；若未运行 tidy 或下游构建环境不同，可能引发依赖解析差异或审查时误判为“未使用”。

建议: 确认代码中是否仍直接使用 logrus：若是，建议保留为直接依赖（不要标 indirect），并在 PR 中运行 go mod tidy 保持一致；若已不再使用，确保相关 import/使用已移除并补充说明。

删除 go-github 与 gitlab client 可能导致编译/功能回归 backend/go.mod:8

描述: 移除了 github.com/google/go-github/v74 与 gitlab.com/gitlab-org/api/client-go 以及其间接依赖（如 go-querystring、go-cleanhttp、go-retryablehttp）。如果代码仍存在对 GitHub/GitLab API 客户端的直接引用，编译会失败；如果改为通过 ModelKit 间接使用，这些依赖变化需要在 PR 描述中说明以降低回归风险。

建议: 在 PR 中明确：是否已删除/替换所有 GitHub/GitLab API 相关代码路径；建议在 CI 中增加 go test ./...（或至少 go list ./...）以验证依赖删除不会导致编译失败。

ModelKit 升级带来潜在行为变化与回归风险 backend/go.mod:7

描述: 将 github.com/chaitin/ModelKit/v2 从 v2.0.6 升级到 v2.3.1 属于跨多个小版本升级，可能包含破坏性变更、行为变化或新引入的依赖（例如新增 testify、uber/mock 等）。如果未锁定/未验证，可能引入运行时行为差异。

建议: 补充升级说明：引用 ModelKit 的 release notes/变更点；在 PR 中提供回归测试结果（关键路径、供应商 gpustack/xinference 的调用）。必要时在 go.sum 变更中确认没有引入异常的大量依赖或不受信任源。

go.sum 变更可能与 go.mod 不一致，影响可复现构建 backend/go.sum:58-60

描述: 此次变更仅涉及 go.sum，但升级了 github.com/chaitin/ModelKit/v2 从 v2.0.6 到 v2.3.1。仅更新 go.sum 可能意味着 go.mod 也发生了（或应该发生）相应的依赖版本变更；如果 go.mod 未同步提交/审查，可能导致他人本地 go mod tidy 产生不同结果、CI 出现依赖不一致或构建不可复现。

建议: 确认本 PR 是否同时包含 backend/go.mod 的对应版本变更；若没有，请补充提交 go.mod，或解释为何仅 go.sum 变化（例如上游间接依赖变更）。建议在 CI 中固定 -mod=readonly 并确保 go mod tidy 后无差异。

大量依赖条目被移除，需确认不是误删导致的依赖漂移/回归 backend/go.sum:101-516

描述: go.sum 中移除了多项依赖校验记录（如 github.com/fatih/color、github.com/google/go-github/v74、gitlab.com/gitlab-org/api/client-go、github.com/sashabaranov/go-openai、hashicorp 若干库等）。若这些依赖仍被代码或间接依赖引用，后续在不同环境/不同 Go 版本执行构建或 go test 时可能重新拉取并导致 go.sum 再次变化；更严重时可能因为依赖图变化引入兼容性/行为差异而未被察觉。

建议: 在合并前运行并确认：go mod tidy、go test ./...、以及完整构建流程（含与 gpustack/xinference 相关的集成路径）。若确认这些依赖已不再需要，可在 PR 描述中补充说明（例如替换了供应商实现/SDK），并在 CI 增加校验避免 go.sum 漂移。

局部变量名遮蔽导入包名 `modelkit`，降低可读性且易出错 backend/internal/model/handler/http/v1/model.go:33-34

描述: 在 NewModelHandler 中使用 modelkit := modelkit.NewModelKit(logger) 会遮蔽导入包名 modelkit，虽然当前能编译（右侧解析为包、左侧为新变量），但可读性很差，后续维护中极易引发误用或重构时的编译错误。

建议: 将局部变量改名为更明确的名称（如 mk、modelKitClient），避免与包名同名。

修复代码:

modelKitClient := modelkit.NewModelKit(logger)
m := &ModelHandler{
    usecase:  usecase,
    logger:   logger.With("handler", "model"),
    modelkit: modelKitClient,
}

新增依赖字段可能未初始化，存在 nil 指针风险 backend/internal/model/handler/http/v1/model.go:16-206

描述: ModelHandler 新增 modelkit *modelkit.ModelKit 字段后，若存在其他构造路径或测试直接用 &ModelHandler{...} 初始化而未设置该字段，调用 h.modelkit.CheckModel/ModelList 将导致空指针 panic。当前 diff 仅展示 NewModelHandler，但无法确认是否还有其他初始化点。

建议: 确保所有创建 ModelHandler 的路径都通过 NewModelHandler，或在方法内对 h.modelkit == nil 做保护并返回明确错误；同时建议为构造器/handler 增加单元测试覆盖该路径。

修复代码:

if h.modelkit == nil {
    return web.Fail("modelkit 未初始化") // 按项目统一错误返回方式调整
}

依赖升级可能引入不兼容变更或 peerDependencies 冲突 ui/package.json:19

描述: 将依赖 @yokowu/modelkit-ui 从 2.0.6 升级到 2.3.1 可能引入破坏性变更（即使语义版本未升主版本号也可能存在行为变化），导致 UI 组件 API/样式/运行时行为不兼容；若该库内部对 peerDependencies（如 React/MUI）版本有要求，可能造成安装冲突或运行时报错。

建议: 在升级前后核对 @yokowu/modelkit-ui 的 release notes/CHANGELOG，确认是否有 breaking changes、迁移步骤及 peerDependencies 变更；在 PR 描述中补充“如何测试”（构建、关键页面回归、供应商 gpustack/xinference 相关 UI 流程）；如项目使用 lockfile（package-lock.json/pnpm-lock.yaml/yarn.lock），确保一并提交并在 CI 中执行干净安装验证。必要时将版本固定到精确版本（不使用 ^）以避免非预期的次版本升级带来回归。

升级 @yokowu/modelkit-ui 可能引入 UI/API 回归，需补充适配与验证 ui/pnpm-lock.yaml:36-40

描述: 本次变更将 @yokowu/modelkit-ui 从 2.0.6 升级到 2.3.1。由于是跨小版本升级，可能引入未在本 PR 中体现的破坏性变更（如组件 API、样式、主题/国际化行为变化），从而导致 UI 回归（构建失败、运行时报错、样式错乱）。当前 diff 仅显示 lockfile 变更，无法确认业务代码是否已适配。

建议: 在 PR 描述中补充升级原因与变更点；在仓库中执行并贴出至少以下验证：pnpm install --frozen-lockfile、pnpm build、pnpm test（如有）、关键页面/组件手工回归。若 modelkit-ui 有 release notes/CHANGELOG，请核对 2.0.6->2.3.1 的 breaking changes 并在需要处同步修改业务代码。

🔵 建议 (3)

新增间接依赖需核实版本与合规性 backend/go.mod:123

描述: 新增的间接依赖 github.com/stretchr/testify v1.11.1、go.uber.org/mock v0.6.0 会改变依赖树；若项目对依赖可审计/许可证有要求，需要确认合规与版本策略。同时，testify 1.11.1 版本号看起来异常（主流为 1.x，最高常见为 1.9/1.10 左右，需核实是否为拼写/解析导致的非预期版本）。

建议: 核实 testify 的版本是否符合预期（建议运行 go list -m -json github.com/stretchr/testify 验证）；如项目有依赖白名单/许可证扫描，补充相应结果或在 PR 描述说明这些依赖的来源（通常由 ModelKit 引入）。

未体现 go.sum 同步，可能影响构建可复现性 backend/go.mod:1

描述: go.mod diff 中仅展示依赖变更，但未看到 go.sum 同步信息。依赖调整后如果未提交对应 go.sum，可能导致下游构建失败或不可复现。

建议: 确保在 PR 中同时提交 go.sum 更新，并在本地执行 go mod tidy/go mod download 后再提交，保证依赖可复现。

@babel/runtime 补丁升级需确认可复现构建与运行影响 ui/pnpm-lock.yaml:3741-5795

描述: lockfile 中 @babel/runtime 由 7.28.2 提升到 7.28.4（在 @mui/utils、i18next、react-i18next 等依赖项下出现）。虽然通常是补丁版本，但仍可能影响打包产物、运行时 helper 行为或体积；若项目对依赖锁定/可复现构建要求严格，需要确认这是预期升级且不会导致运行环境不兼容。

建议: 确认 CI/构建环境可稳定复现（使用 --frozen-lockfile）；如团队有依赖升级策略，建议在 PR 描述中注明由哪个依赖升级触发以及为何接受该补丁升级。必要时跑一次产物对比/关键国际化渲染冒烟测试。

[sggdy]

@MonkeyCode-AI 这个pr主要是什么更新

[monkeycode-ai]

MonkeyCode-AI 正在分析任务...

[monkeycode-ai]

代码审查结果

将 modelkit 由包级调用改为注入到 ModelHandler 实例中方向正确，但当前实现存在 Go 命名遮蔽导致无法编译的问题，需修复后才能合入。

✨ 代码亮点

• 将对 ModelKit 的调用改为通过 handler 持有实例（h.modelkit），有利于后续测试注入与解耦，且避免了包级全局状态的扩散。

🚨 Critical	⚠️ Warning	💡 Suggestion
1	0	0

[monkeycode-ai]

Caution

🚨 局部变量名与导入包名冲突（命名遮蔽），导致无法调用 modelkit.NewModelKit 编译失败

文件中已导入 modelkit "github.com/chaitin/ModelKit/v2/usecase"，但在 NewModelHandler 内部使用了 modelkit := modelkit.NewModelKit(logger)。

在 Go 中，短变量声明左侧的 modelkit 会在该作用域内遮蔽同名导入包标识符；同时右侧表达式会在该新作用域中解析，从而使 modelkit.NewModelKit 试图在“局部变量 modelkit”上取字段/方法而不是在包上取函数，导致编译报错（典型报错形态：modelkit.NewModelKit undefined (type *modelkit.ModelKit has no field or method NewModelKit) 或 cannot refer to modelkit.NewModelKit）。

这是确定性的编译级问题，必须修复。

建议: 避免与导入包同名的局部变量；可改为 mk / modelKit 等，并在结构体初始化中对应替换。

 	modelKit := modelkit.NewModelKit(logger)
 	m := &ModelHandler{usecase: usecase, logger: logger.With("handler", "model"), modelkit: modelKit}