VTJ.PRO 在线应用开发平台的LLM模型管理与配置

踩着两条虫
0 阅读3分钟

LLM 模型管理与配置

本节详细介绍了 VTJ.PRO 平台中大型语言模型（LLM）的基础设施和管理逻辑。系统支持多个提供商、专门的模型用途（如代码生成或多模态视觉），并包含一个缓存层以优化 AI 代理工作流的性能。

image.png

数据模型与实体

平台使用结构化的实体模型来定义 LLM 的能力和连接参数。

LLMModelEntity

LLMModelEntity 表示由外部服务提供的特定模型实例（例如 GPT-4、Claude-3）。它包含 API 端点、认证密钥和模型特定参数的配置。

关键字段包括：

  • name：模型的显示名称。
  • value：API 调用中使用的技术标识符（例如 gpt-4-turbo）。
  • provider：服务提供商（由 LLMProvider 枚举定义）。
  • purpose：主要使用场景（由 LLMPurpose 枚举定义）。
  • apiKey：提供商的凭证。
  • baseUrl：API 端点（用于代理服务或本地部署）。

枚举：Provider 与 Purpose

系统对模型进行分类，以确保为特定任务使用正确的工具：

  • LLMProvider：支持 OpenAI、DeepSeek、Ollama、Moonshot、Zhipu、Groq 和 Anthropic。
  • LLMPurpose：将模型分类为 Coder（针对 DSL 和代码生成优化）或 Multimodal（支持图像/视觉输入）。

实体关系图

下图说明了 LLMModelEntity 在后端服务层中如何与其操作枚举相关联。

模型实体空间

classDiagram
    class LLMModelEntity {
        +String name
        +String value
        +LLMProvider provider
        +LLMPurpose purpose
        +String apiKey
        +String baseUrl
    }
    class LLMProvider {
        <<enumeration>>
        OpenAI
        DeepSeek
        Ollama
        Anthropic
    }
    class LLMPurpose {
        <<enumeration>>
        Coder
        Multimodal
    }
    LLMModelEntity --> LLMProvider : identifies
    LLMModelEntity --> LLMPurpose : categorizes

LLMModelService 实现

LLMModelService 是检索和管理模型的主要接口。它扩展了 BaseCrudService 以提供标准的 CRUD 操作，同时实现了模型选择和缓存的专用逻辑。

缓存支持的检索

为了在频繁的 AI 代理请求期间最小化数据库开销，该服务对模型列表使用了缓存机制。

  • getModels()：检索所有启用的模型，优先使用缓存结果（如果可用）。
  • getCoderModels()：过滤模型列表，仅返回标记为 LLMPurpose.Coder 的模型。这些模型通常由 @vtj/coder 引擎用于生成 Vue 组件和 DSL。
  • getMultiModel()：返回标记为 LLMPurpose.Multimodal 的第一个可用模型，用于图像转代码或基于视觉的分析。

数据流：请求到模型选择

此图显示了针对特定模型（如 Coder 模型）的请求如何从服务层通过缓存流向数据库。

LLM 模型解析流程

sequenceDiagram
    participant AgentModule as AgentModule / AIService
    participant Service as LLMModelService
    participant Cache as CacheModule (Redis/Memory)
    participant DB as MySQL (LLMModelEntity)

    AgentModule->>Service: getCoderModels()
    Service->>Cache: get("LLM_MODELS_CACHE")
    alt Cache Hit
        Cache-->>Service: List<LLMModelEntity>
    else Cache Miss
        Service->>DB: find({ enabled: true })
        DB-->>Service: List<LLMModelEntity>
        Service->>Cache: set("LLM_MODELS_CACHE", data)
    end
    Service->>Service: filter(purpose == "Coder")
    Service-->>AgentModule: List<CoderModels>

管理界面

平台提供了一个专用的管理界面，用于管理 LLM 配置，位于 llms.vue 视图中。

配置界面

管理员可以执行以下操作：

  1. 提供商设置：定义新的 LLM 端点，包括为兼容 OpenAI 的代理设置自定义 baseUrl。
  2. 凭证管理：安全存储 apiKey 值。
  3. 用途分配：明确将模型标记为 Coder 或 Multimodal，以使其在特定工作台工作流中启用。
  4. 状态切换：启用或禁用模型，无需删除其配置。

前端集成

管理界面通过 LlmController 与后端交互，该控制器公开了由 LLMModelService 管理的 CRUD 端点。

组件文件路径角色
视图frontend/src/views/admin/llms.vue模型 CRUD 操作的管理界面
控制器backend/src/business/llm/llm.controller.tsLLM 管理的 REST API 端点
服务backend/src/business/llm/llm.service.ts业务逻辑和缓存管理

与 AI 代理工作流的集成

在此模块中配置的模型由 AIService 使用。当 AI 代理需要执行任务时：

  1. 它根据任务类型（例如聊天 vs. 代码生成）向 LLMModelService 查询合适的模型。
  2. 它从 LLMModelEntity 中检索 apiKey 和 baseUrl。
  3. 它使用这些参数初始化一个兼容 OpenAI 的客户端实例，以将响应流式传输回工作台。

参考资料

avatar
文章
阅读
粉丝