Alauda AI
简体中文

发版日志

目录

AI 1.3.3

修复的问题

  • 用共享模型的模板发布其推理服务时，偶尔会出现模型拉取失败的问题
  • 推理服务列表中的 GPU 加速一列，未能正确的展示扩展资源的使用情况，当推理服务使用扩展资源时，此列错误的展示成‘未使用’了

已知问题

  • 在 Gitlab 中通过直接编辑 readme 文件，来修改 library_name，在页面中无法同步显示出其模型类型变化。
    临时方案：使用 UI 操作修改，避免直接操作 Gitlab 修改。

AI 1.3.2

修复的问题

  • 推理服务（Inference Service）问题：服务卡在“待处理（Pending）”状态
    在部署推理服务时，该服务长时间处于待处理状态，无法进入运行状态。
    检查容器平台计算组件（Deployment）内的实时事件后，观察到以下警告信息：
    “创建失败：禁止创建 Pod“xxx-predictor-xxx”：配额不足：默认配额要求必须为以下资源指定限制值：队列代理（queue-proxy）的 limits.cpu；队列代理（queue-proxy）的 limits.memory；队列代理（queue-proxy）的 requests.memory”
    此错误表明，由于违反资源配额限制，部署操作无法创建 Pod。该问题的根本原因是：由 Knative 注入的队列代理（queue-proxy）容器未配置默认资源限制。因此，队列代理缺少容器平台默认配额强制要求的 CPU 和内存资源规格（limits.cpu、limits.memory、requests.memory）。

已知问题

  • 用共享模型的模板发布其推理服务时，偶尔会出现模型拉取失败的问题
  • 在 Gitlab 中通过直接编辑 readme 文件，来修改 library_name，在页面中无法同步显示出其模型类型变化。
    临时方案：使用 UI 操作修改，避免直接操作 Gitlab 修改。

AI 1.3.1

新增与优化功能

产品更名为 "Alauda AI"

产品名称由 "Alauda Machine Learning" 更改为 "Alauda AI"。

修复的问题

此次发版无相关问题。

已知问题

  • 用共享模型的模板发布其推理服务时，偶尔会出现模型拉取失败的问题
  • 推理服务（Inference Service）问题：服务卡在“待处理（Pending）”状态
    在部署推理服务时，该服务长时间处于待处理状态，无法进入运行状态。
    检查容器平台计算组件（Deployment）内的实时事件后，观察到以下警告信息：
    “创建失败：禁止创建 Pod“xxx-predictor-xxx”：配额不足：默认配额要求必须为以下资源指定限制值：队列代理（queue-proxy）的 limits.cpu；队列代理（queue-proxy）的 limits.memory；队列代理（queue-proxy）的 requests.memory”
    此错误表明，由于违反资源配额限制，部署操作无法创建 Pod。该问题的根本原因是：由 Knative 注入的队列代理（queue-proxy）容器未配置默认资源限制。因此，队列代理缺少容器平台默认配额强制要求的 CPU 和内存资源规格（limits.cpu、limits.memory、requests.memory）。
  • 在 Gitlab 中通过直接编辑 readme 文件，来修改 library_name，在页面中无法同步显示出其模型类型变化。
    临时方案：使用 UI 操作修改，避免直接操作 Gitlab 修改。

AI 1.3.0

新增与优化功能

共享模型权限限制

模型仓库目前支持两种模型类型：共享模型 和 私有模型。在原设计中，用户可以对共享模型执行部分管理操作，存在潜在权限风险。
本次发布中，私有模型的功能和权限保持不变，支持完整的管理操作。共享模型的权限进行了限制和优化，具体如下：

  • 权限限制：所有用户仅能使用共享模型，不再支持创建、编辑或删除共享模型。
  • 创建流程调整：“创建模型”流程中移除可见性参数，所有新建模型默认为 私有模型。
  • 功能移除：
    • 共享模型移除以下功能：
      • 编辑标签按钮
      • 编辑描述按钮
      • 创建标签按钮
      • 删除按钮
      • 文件管理标签页
      • 版本管理标签页

推理服务新增模板发布功能

之前创建推理服务需要手动配置大量相互依赖的参数，复杂度高且易出错，导致成功率降低，影响用户体验。
本次发布引入了模板发布功能，允许用户将验证过的配置封装为模板，基于模板快速发布推理服务。
优势包括：

  • 用户可创建自定义模板，复用验证过的最佳实践。
  • 参数配置自动填充，减少重复输入和依赖错误。
  • 降低大模型推理服务发布门槛，提高成功率和效率。

推理运行时支持单节点多GPU

之前推理服务部署在单节点时仅支持单GPU模式，受限于资源调度，限制了大模型推理场景且GPU资源利用不足。
本次升级支持单节点内多GPU调度，单个推理服务可自动分配同一机器上的多个GPU，实现更大模型推理、更优资源利用和增强服务能力。

推理服务新增“业务监控”

推理服务之前仅展示基础信息。为提升可观测性，帮助用户快速发现问题、实时监控服务健康、主动优化或调整资源，新增以下功能：
监控面板

  • 作为推理服务的新标签页，覆盖三大维度：
    • 资源监控：CPU 使用量（核）、CPU 利用率（%）、内存使用量（GiB）、内存利用率（%）
    • 计算监控：GPU 使用量（核）、GPU 利用率（%）、GPU 内存使用量（GiB）、GPU 内存利用率（%）
    • 其他指标：响应时间、流量（入/出数据量）、QPS（每秒查询数）、总调用次数、令牌吞吐量（/秒）

推理运行时扩展

为增强 AML 推理运行时支持，本版本新增以下运行时：

  • vllm-cuda-11.8
  • vllm-cpu

独立“平台管理视图”

之前平台管理功能（包括 Namespace 管理和凭证管理）与业务功能混合在同一视图，权限层级混杂导致混淆。
本次发布：

  • 平台管理功能独立为单独视图，仅管理员可见和操作。
  • 管理员可通过顶部导航自由切换 “管理视图” 和 “业务视图”。
  • 普通用户仅能访问 业务视图，无法访问平台管理功能。

Namespace 入驻自动配置 GitLab 令牌

之前入驻 Namespace 时，用户需手动配置 GitLab 令牌以授权仓库访问。
本次优化 GitLab 授权流程，实现 自动配置 GitLab 令牌：

  • 每个新入驻的 Namespace 平台自动配置 GitLab 令牌。
  • 用户无需手动操作或管理 GitLab 授权。
  • 确保所有管理的 Namespace 持续访问 GitLab。

废弃功能

α 功能降级为 S2 阶段

AML 平台迭代过程中，部分模块以 α 功能 形式发布，用于探索设计和用户需求验证。
但由于大模型开发场景快速变化及用户需求演进，部分 α 功能存在设计缺陷或适用性有限，将进行重新评估并降级为 S2 阶段以便未来规划。
降级功能包括：

  • 数据集：数据集仓库、数据标注
  • 模型优化：任务模板、模型微调、预训练
  • Agents：应用仓库、Dify
  • 高级功能：Notebook、存储卷、MLFlow、Tensorboard、工作流、工作流任务、定时任务、AutoML
  • 模型：构建推理 API 镜像

修复的问题

  • “共享”类型的模型无法被其他命名空间的用户访问，导致“推理服务体验”效果从聊天补全退变为文本补全。
  • 当模型数量超过100时，因API错误仅可获取前100条数据，导致“概览页”中“模型仓库数量的统计不准确。
  • 推理服务的日志仅可显示第一个 pod 的日志，导致无法查看多个 pod 的日志。
  • 修复推理服务调用示例中使用了固定的模型名称的问题。
  • 在驱动为cuda 12.4的节点上，使用 gpu-manager + vllm推理运行时创建推理服务时，会出现”enforce_eager=True or user '--enforce-eager' in the CLI“的错误。
    原因是，当应用根据cuda版本请求cuda函数地址时， gpu-manager每次都返回最新的函数版本，例如cumemoryalloc存在v1，v2，v3时。v1存在cuda 10版本，v2针对cuda11版本，v3针对cuda12版本，每次返回最新可能会导致推理服务异常。

已知问题

  • 用共享模型的模板发布其推理服务时，偶尔会出现模型拉取失败的问题
  • 推理服务（Inference Service）问题：服务卡在“待处理（Pending）”状态
    在部署推理服务时，该服务长时间处于待处理状态，无法进入运行状态。
    检查容器平台计算组件（Deployment）内的实时事件后，观察到以下警告信息：
    “创建失败：禁止创建 Pod“xxx-predictor-xxx”：配额不足：默认配额要求必须为以下资源指定限制值：队列代理（queue-proxy）的 limits.cpu；队列代理（queue-proxy）的 limits.memory；队列代理（queue-proxy）的 requests.memory”
    此错误表明，由于违反资源配额限制，部署操作无法创建 Pod。该问题的根本原因是：由 Knative 注入的队列代理（queue-proxy）容器未配置默认资源限制。因此，队列代理缺少容器平台默认配额强制要求的 CPU 和内存资源规格（limits.cpu、limits.memory、requests.memory）。
  • 在 Gitlab 中通过直接编辑 readme 文件，来修改 library_name，在页面中无法同步显示出其模型类型变化。
    临时方案：使用 UI 操作修改，避免直接操作 Gitlab 修改。