首页
/ MinIO KMS 完全指南：SSE-S3 服务端加密、自动加密与密钥管理（KES / 静态密钥）实战

MinIO KMS 完全指南：SSE-S3 服务端加密、自动加密与密钥管理（KES / 静态密钥）实战

2026-09-04 17:18:35作者：何将鹤
minio
MinIO is a high-performance, S3 compatible object store, open sourced under GNU AGPLv3 license.
项目地址：https://gitcode.com/GitHub_Trending/mi/minio

本文基于 MinIO 仓库中 KMS 指南 与 KMS IAM/Config 加密文档 编写，覆盖 MinIO 密钥管理系统（KMS）的完整落地路径：如何用 KES 或静态密钥启用 SSE-S3 服务端加密、配置自动加密、保护加密客户端私钥、加密 IAM 与配置数据，并结合 internal/kms 源码解析配置校验、密钥派生与管理 API 的底层实现。读完本文，你可以独立完成一套带 KMS 的 MinIO 部署，并理解每个环境变量的作用边界与常见失败原因。

KMS 与 SSE-S3 的基本工作原理

MinIO 使用 KMS 来支持 SSE-S3（服务端加密）：当客户端请求 SSE-S3，或开启了自动加密时，MinIO 会为每个对象生成一把唯一的对象密钥（数据密钥，DEK），这把对象密钥再由 KMS 管理的**主密钥（Master Key）**保护。数据密钥本身不经过 KMS 服务器落地，只有加密后的密文随对象元数据保存。

从源码结构看，这一流程在 internal/kms/kms.go 中体现得很清楚：

  • GenerateKey 调用 KMS 生成数据密钥，请求中携带 AssociatedData（关联上下文），解密时必须提供相同的上下文；对 KMS 服务端连接而言，生成的 DEK 固定为 32 字节（见 internal/kms/kms.go#L358-L390，其中 Length: 32）。
  • Decrypt 用主密钥还原加密的数据密钥，req.Name 为空时自动回退到 DefaultKey（由 MINIO_KMS_KES_KEY_NAME / MINIO_KMS_SSE_KEY 等环境变量指定），见 internal/kms/kms.go#L228-L248。
  • 每次加解密操作都会更新成功/失败计数与延迟直方图（10ms 到 10s 共 10 个桶），供管理 API 查询 KMS 运行指标。

因此，SSE-S3 的完整链路是：客户端 PUT 对象（带 X-Amz-Server-Side-Encryption: AES256 头）→ MinIO 调用 KMS 生成 DEK → 用 DEK 加密对象数据 → DEK 密文写入对象元数据；GET 时反向执行：先向 KMS 请求解密 DEK，再解密对象数据。

Quick Start：三步接入 KES 演示实例

MinIO 通过 KES 项目支持多种 KMS 实现，官方在 https://play.min.io:7373 运行了一个 KES 实例供快速实验。按照 docs/kms/README.md 的步骤：

1. 获取根身份（root identity）

curl -sSL --tlsv1.2 \
     -O 'https://raw.githubusercontent.com/minio/kes/master/root.key' \
     -O 'https://raw.githubusercontent.com/minio/kes/master/root.cert'

2. 设置 MinIO-KES 配置

export MINIO_KMS_KES_ENDPOINT=https://play.min.io:7373
export MINIO_KMS_KES_KEY_FILE=root.key
export MINIO_KMS_KES_CERT_FILE=root.cert
export MINIO_KMS_KES_KEY_NAME=my-minio-key

3. 启动 MinIO Server

export MINIO_ROOT_USER=minio
export MINIO_ROOT_PASSWORD=minio123
minio server ~/export

注意：https://play.min.io:7373 仅用于实验，任何人都可以访问或删除其中的主密钥。生产环境必须运行你自己的 KES 实例。

部署拓扑与 KMS 实现选型

典型的 MinIO + KMS 部署拓扑如下（引自 docs/kms/README.md）：

    ┌────────────┐
    │ ┌──────────┴─┬─────╮          ┌────────────┐
    └─┤ ┌──────────┴─┬───┴──────────┤ ┌──────────┴─┬─────────────────╮
      └─┤ ┌──────────┴─┬─────┬──────┴─┤ KES Server ├─────────────────┤
        └─┤   MinIO    ├─────╯        └────────────┘            ┌────┴────┐
          └────────────┘                                        │   KMS   │
                                                                └─────────┘

在给定部署中，存在 n 个 MinIO 实例与 m 台 KES 服务器通信，但只有 1 个中心 KMS。最简单的形态是 1 个 MinIO 服务器（或集群）经由 1 台 KES 访问 1 个 KMS。各种 MinIO-KMS 部署的主要区别只在 KMS 实现不同，文档给出的选型参考如下：

KMS 实现 适用场景
Hashicorp Vault 本地 KMS，MinIO 与 KMS 均部署在本地（推荐）
AWS-KMS + SecretsManager 云 KMS，MinIO 搭配托管式 KMS
Gemalto KeySecure / Thales CipherTrust 本地 KMS，MinIO 与 KMS 均在本地
Google Cloud Platform SecretManager 云 KMS，MinIO 搭配托管式 KMS
FS（文件系统 Keystore） 本地测试或开发（不建议用于生产）

关键在于：无论底层 KMS 实现是什么，MinIO 侧的 KES 配置方式始终一致——都通过同一组 MINIO_KMS_KES_* 环境变量完成。

从源码可以验证这种"配置收敛"：internal/kms/config.go#L44-L67 集中定义了全部 KMS 相关环境变量：

// Environment variables for MinIO KMS.
const (
	EnvKMSEndpoint   = "MINIO_KMS_SERVER"  // List of MinIO KMS endpoints, separated by ','
	EnvKMSEnclave    = "MINIO_KMS_ENCLAVE" // MinIO KMS enclave in which the key and identity exists
	EnvKMSDefaultKey = "MINIO_KMS_SSE_KEY" // Default key used for SSE-S3 or when no SSE-KMS key ID is specified
	EnvKMSAPIKey     = "MINIO_KMS_API_KEY" // Credential to access the MinIO KMS.
)

// Environment variables for MinIO KES.
const (
	EnvKESEndpoint       = "MINIO_KMS_KES_ENDPOINT"     // One or multiple KES endpoints, separated by ','
	EnvKESDefaultKey     = "MINIO_KMS_KES_KEY_NAME"     // The default key name used for IAM data and when no key ID is specified on a bucket
	EnvKESAPIKey         = "MINIO_KMS_KES_API_KEY"      // Access credential for KES - API keys and private key / certificate are mutually exclusive
	EnvKESClientKey      = "MINIO_KMS_KES_KEY_FILE"     // Path to TLS private key for authenticating to KES with mTLS
	EnvKESClientCert     = "MINIO_KMS_KES_CERT_FILE"    // Path to TLS certificate for authenticating to KES with mTLS
	EnvKESServerCA       = "MINIO_KMS_KES_CAPATH"       // Path to file/directory containing CA certificates to verify the KES server certificate
	EnvKESClientPassword = "MINIO_KMS_KES_KEY_PASSWORD" // Optional password to decrypt an encrypted TLS private key
)

// Environment variables for static KMS key.
const (
	EnvKMSSecretKey     = "MINIO_KMS_SECRET_KEY"      // Static KMS key in the form "<key-name>:<base64-32byte-key>"
	EnvKMSSecretKeyFile = "MINIO_KMS_SECRET_KEY_FILE" // Path to a file to read the static KMS key from
)

补充两个文档未展开、但源码确认的变量：

  • MINIO_KMS_REPLICATE_KEYID（默认开启）：控制跨站复制时是否随对象元数据复制 KMS 密钥 ID。若各站点使用不同的 KMS 集群与不同的密钥，复制密钥 ID 会导致请求失败，此时应设置 MINIO_KMS_REPLICATE_KEYID=off（见 internal/kms/config.go#L69-L93）。
  • MINIO_KMS_SECRET_KEY_FILE：Docker 镜像场景下从文件读取静态密钥；若相对路径不存在，会回退到 Docker 默认 secrets 目录 /run/secrets 下查找（internal/kms/config.go#L278-L297）。

连接建立与配置校验逻辑

Connect 函数（internal/kms/config.go#L112-L298）按优先级在三类实现中选择：

  1. MinIO KMS：存在 MINIO_KMS_SERVER 时建立直连 KMS 客户端连接；
  2. MinIO KES：存在 MINIO_KMS_KES_ENDPOINT 时建立 KES mTLS 客户端；
  3. 静态密钥（Builtin）：读取 MINIO_KMS_SECRET_KEY 或 MINIO_KMS_SECRET_KEY_FILE，构建进程内单密钥 KMS。

其中 KES 分支有两个值得注意的实现细节：

mTLS 认证二选一：MINIO_KMS_KES_API_KEY 与"私钥 + 证书"文件互斥。使用 API key 时，MinIO 在内存中由 key 派生客户端证书；使用文件方式时，通过 certs.NewCertificate 加载证书对，并注册了热加载：每 15 分钟检查一次文件变化，同时监听 SIGHUP 信号——这意味着更换客户端证书无需重启 MinIO（internal/kms/config.go#L196-L238）。

默认密钥缓存保活：连接建立后会启动一个后台 goroutine，每 10 秒对默认密钥执行一次 DescribeKey，将默认密钥保持在 KES 客户端缓存中，避免 MinIO 重启后首次加解密因缓存未命中而出现可用性问题（internal/kms/config.go#L252-L266）。

另外，MINIO_KMS_KES_ENDPOINT 支持逗号分隔的多端点与省略号展开（如 https://kes{1...2}.example.com:7373），由 expandEndpoints 借助 ellipses 库展开，便于 KES 集群部署（internal/kms/config.go#L420-L441）。

IsPresent（internal/kms/config.go#L303-L418）负责启动前的配置校验，常见报错都来自这里：

  • 三类配置不能同时出现：MinIO KMS / KES / 静态密钥的配置变量同时存在时直接报错（如 kms: configuration for MinIO KMS and MinIO KES is present）；
  • KES 配置必须完整：必须同时提供 MINIO_KMS_KES_ENDPOINT 与 MINIO_KMS_KES_KEY_NAME，且必须二选一提供 MINIO_KMS_KES_API_KEY 或"证书 + 私钥"；
  • 静态密钥二选一：MINIO_KMS_SECRET_KEY 与 MINIO_KMS_SECRET_KEY_FILE 不能同时设置；
  • 针对 Docker 镜像的特殊处理：若 MINIO_KMS_SECRET_KEY 为空、或 MINIO_KMS_SECRET_KEY_FILE 指向不存在的路径，会先 unset 该变量再判定，从而以"未配置 KMS"方式启动——这也解释了为什么容器化部署下"配了环境变量但没生效"时服务仍能起来。

自动加密（Auto Encryption）

当管理员希望存储到 MinIO 的所有数据都默认落盘加密时，可以启用自动加密。

方式一：mc encrypt（推荐）

在 KMS 成功配置的前提下，为每个需要加密的桶开启桶级加密配置：

mc encrypt set sse-s3 myminio/bucket/

验证桶上是否已启用 sse-s3：

mc encrypt info myminio/bucket/
Auto encryption 'sse-s3' is enabled

从源码看，桶加密配置的写入过程本身就会访问 KMS：cmd/bucket-encryption-handlers.go 中，当 GlobalKMS == nil 时直接返回"KMS 未配置"错误，否则先调用 GlobalKMS.GenerateKey 做一次密钥生成测试，确认指定密钥可用后才允许保存配置（cmd/bucket-encryption-handlers.go#L81-L88）。

方式二：环境变量（不推荐）

export MINIO_KMS_AUTO_ENCRYPTION=on

设置该变量后，KMS 配置成功时 MinIO 会自动加密所有桶上的对象。文档明确标注此方式不推荐，优先使用 mc encrypt 做桶级精细控制。

验证自动加密

注意：自动加密只影响未携带 S3 加密头的请求。如果 S3 客户端发送了例如 SSE-C 头，MinIO 会用客户端提供的密钥加密对象，而不会访问已配置的 KMS。

mc cp test.file myminio/bucket/
test.file:              5 B / 5 B  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  100.00% 337 B/s 0s

mc stat myminio/bucket/test.file
Name      : test.file
...
Encrypted :
  X-Amz-Server-Side-Encryption: AES256

mc stat 输出中的 X-Amz-Server-Side-Encryption: AES256 即确认对象走了 SSE-S3，由服务端（KMS 提供的密钥）完成加密。

加密的 KES 客户端私钥

MinIO 支持加密后的 KES 客户端私钥，因此 MINIO_KMS_KES_KEY_FILE 可以指向受密码保护的私钥文件。此时需要提供解锁密码：

export MINIO_KMS_KES_KEY_PASSWORD=<your-password>

注意：MinIO 只支持加密的私钥，不支持加密的证书——证书本身不是秘密，会在 TLS 握手时以明文发送。

源码印证：加载客户端证书对时，MinIO 会先用 pem.Decode 解析私钥，若 x509.IsEncryptedPEMBlock 判定为加密块，则使用 MINIO_KMS_KES_KEY_PASSWORD 调用 x509.DecryptPEMBlock 解密；密码错误会在启动阶段直接报 Unable to decrypt KES client private key（internal/kms/config.go#L198-L226）。

静态密钥：MINIO_KMS_SECRET_KEY 快速启用加密

不部署 KES 时，MinIO 也支持用一个静态密钥作为"最小化 KMS"。这一路径来自 docs/kms/IAM.md，它同时服务于 SSE-S3 与 IAM/配置数据加密。

MINIO_KMS_SECRET_KEY 的格式为：

MINIO_KMS_SECRET_KEY=<key-name>:<base64-value>

先生成一个 256 bit 随机密钥：

$ cat /dev/urandom | head -c 32 | base64 -
OSMM+vkKUTCvQs9YL/CVMIMt43HFhkUpqJxTmGl6rYw=

然后设置：

export MINIO_KMS_SECRET_KEY=my-minio-key:OSMM+vkKUTCvQs9YL/CVMIMt43HFhkUpqJxTmGl6rYw=
  • 密钥名可以任选，不必是 my-minio-key；
  • 丢失 MINIO_KMS_SECRET_KEY 意味着数据丢失——IAM/配置数据将无法再解密；
  • 分布式 MinIO 部署中，每个 MinIO 服务器进程必须设置相同的 MINIO_KMS_SECRET_KEY。

源码层面，ParseSecretKey 按 : 切分得到 key-id 与 base64 值，NewBuiltin 强制要求解码后恰好 32 字节，否则报 kms: invalid key length（internal/kms/secret-key.go#L41-L73）。

这个内置 KMS 的 DEK 派生算法值得了解（internal/kms/secret-key.go#L120-L161）：

  1. 生成 28 字节随机数，前 16 字节作 IV、后 12 字节作 AES-GCM nonce；
  2. 以主密钥计算 HMAC-SHA256(key, iv) 派生"封套密钥"（sealing key），用 AES-256-GCM 加密随机生成的 32 字节明文 DEK，密文尾部拼接随机数——该二进制格式与 KES/MinKMS 的输出兼容；
  3. Decrypt 同时支持 AES-GCM 与 ChaCha20Poly1305 两种算法，并能把历史版本的 JSON 格式密文透明转换为二进制格式（internal/kms/secret-key.go#L227-L248），保证了升级兼容性。

从静态密钥平滑升级到 KES

任何时候都可以从 MINIO_KMS_SECRET_KEY 切换到完整 KMS 部署：把之前生成的密钥导入 KES 即可。例如在 KES 就绪后通过 KES CLI：

kes key create my-minio-key OSMM+vkKUTCvQs9YL/CVMIMt43HFhkUpqJxTmGl6rYw=

KMS 与 IAM / 配置数据加密

MinIO 支持用 KMS 提供的密钥加密 config 与 IAM 资产。如果未启用 KMS，这些数据将以明文（经纠删编码）存放在后端磁盘上。

docs/kms/IAM.md 指出 MinIO 有两种加密 IAM 与配置数据的方式：

  1. KES + 外部 KMS（功能完整，可多密钥、可轮换，参见上文 Quick Start 与选型表）；
  2. 单个静态密钥（更简单）：仅设置 MINIO_KMS_SECRET_KEY 后启动/重启 MinIO 服务器即可，格式与生成方法见上一节。

为什么统一到 KMS？（原文 FAQ 要点）

在这项变更之前，MinIO 有两套并存的加密机制：S3 对象在存在 KMS 时用 KMS 加密，而 IAM/配置数据用 root 凭据派生的密钥加密。现在 IAM/配置数据与 S3 对象统一由 KMS（若存在）加密。统一带来的收益：

  • 密钥管理集中化：只有一条路径变更或轮换加密密钥，不再存在"对象一套、IAM 一套"的分裂机制；
  • 降低启动时间：旧方案中 IAM 加密基于 root 凭据，需要使用内存/ CPU 开销很大的 Argon2 这类 memory-hard 函数；KMS 方案可以使用比其廉价数个数量级的密钥派生函数；
  • root 凭据可随时更换：过去 root 凭据参与 IAM 数据加解密，更换时必须新旧凭据并存、两步操作并在完成后移除旧凭据；现在这一步骤完全消失。

是否需要企业级 KMS 才能安全运行 MinIO？

不需要。MinIO 不依赖任何第三方 KMS 供应商，有三种选择：

  • 不配置 KMS 运行——所有 IAM 数据以明文存储；
  • 使用单个静态密钥（MINIO_KMS_SECRET_KEY）作为最小化 KMS——IAM 数据全部加密，密钥经环境变量传入；
  • 使用 KES 搭配任意受支持的 KMS（例如 MinIO + KES + Hashicorp Vault）作为安全密钥库。

存量集群升级与兼容性

  • 能否直接升级？ 可以。MinIO 会尝试透明迁移既有 IAM 数据：无 KMS 时存明文，有 KMS 时重新用 KMS 加密；
  • 是否向后兼容？ 并非对所有部署都兼容：已废弃的原生 Hashicorp Vault 集成不再受支持，接入第三方 KMS 时 KES 成为必选组件。此外，由于配置数据改用 KMS 加密，KMS 配置本身不能再保存在 MinIO 配置文件中，必须通过环境变量提供——如果此前是用 mc admin config 类命令配置 KMS 的，需要调整部署方式；
  • 升级是否影响 SLA / 造成停机？ 升级本身不会造成停机。但首次启动会尝试迁移既有 IAM 数据，boot 过程可能略有变长（通常无感知）；迁移完成后，后续重启速度与之前相当甚至更快。

管理 API：状态检查、密钥管理与指标

MinIO 将 KMS 操作暴露为管理 API（cmd/kms-handlers.go），供 mc admin 与监控使用。所有 handler 在 GlobalKMS == nil 时返回 ErrKMSNotConfigured，并经由 IAM 策略（kms:Status、kms:CreateKey 等动作）做权限校验：

端点 功能
GET /minio/kms/v1/status KMS 类型、默认密钥 ID、各端点在线状态
GET /minio/kms/v1/metrics 请求成功/错误计数与延迟直方图
GET /minio/kms/v1/version KMS 版本
GET /minio/kms/v1/apis KMS 支持的 API 列表（静态密钥实现返回"不支持"）
POST /minio/kms/v1/key/create?key-id=<id> 创建主密钥（静态密钥实现下仅当名字与已配置 key-id 一致时返回"已存在"，不能新建第二个密钥）
GET /minio/kms/v1/key/list?pattern=<pattern> 按前缀列出密钥，且逐一把结果与调用者策略的 Resource 匹配过滤
GET /minio/kms/v1/key/status?key-id=<id> 密钥健康检查

其中 KMSKeyStatusHandler 的实现（cmd/kms-handlers.go#L266-L315）是一个很好的 KMS 健康检查范式：

  1. 用指定主密钥 GenerateKey 生成一把测试数据密钥（key-id 为空时使用默认密钥）；
  2. 用同一 AssociatedData 上下文调用 Decrypt 解密；
  3. 用 subtle.ConstantTimeCompare 恒定时间比较明文与解密结果，任一步失败都会把具体错误写入响应的 EncryptionErr / DecryptionErr 字段。

这意味着你可以定期通过管理 API 主动探测"KMS 是否真正可用"，而不仅是"网络是否可达"。静态密钥实现的对应行为见 internal/kms/secret-key.go（ListKeys 只返回单一 key-id，MAC 使用 HMAC-SHA256）。

关键实践要点

  1. 配置方式唯一且互斥：KMS（MINIO_KMS_SERVER 系列）、KES（MINIO_KMS_KES_* 系列）、静态密钥（MINIO_KMS_SECRET_KEY[_FILE]）三者只能配一组，且各自必须完整，启动时由 internal/kms/config.go 的 IsPresent 严格校验；
  2. 生产环境必须自建 KES + KMS，https://play.min.io:7373 只用于实验，其上任何人都能删除主密钥；
  3. 优先用 mc encrypt set sse-s3 做桶级自动加密，MINIO_KMS_AUTO_ENCRYPTION=on 是全局兜底手段；注意 SSE-C 客户端自带密钥的请求不会触及 KMS；
  4. 客户端私钥可以加密（MINIO_KMS_KES_KEY_PASSWORD），且证书对支持 15 分钟周期 + SIGHUP 热加载，换证书不重启；
  5. 静态密钥丢失 = 数据丢失，分布式集群所有进程必须使用同一 MINIO_KMS_SECRET_KEY；需要多密钥/轮换/审计能力时按 docs/kms/IAM.md 的方式把密钥导入 KES 完成平滑升级；
  6. 跨站点复制且各站点密钥不同（不同 KMS 集群）时，设置 MINIO_KMS_REPLICATE_KEYID=off 避免复制密钥 ID 引发请求失败。
minio
MinIO is a high-performance, S3 compatible object store, open sourced under GNU AGPLv3 license.
项目地址：https://gitcode.com/GitHub_Trending/mi/minio
登录后查看全文

相关内容推荐

1 MinIO 使用 KMS 加密 IAM 与配置数据：MINIO_KMS_SECRET_KEY 静态密钥与 KES 接入实战2 MinIO 安全策略与漏洞披露流程详解：从报告 SLA 到安全修复的完整机制3 MinIO 自动站点复制（Automatic Site Replication）：跨集群 IAM/存储桶/对象同步的原理与实战4 Parseable对象存储加密功能的技术实现解析5 Spring File Storage 项目中 MinIO 动态 Bucket 与 SSE 加密实现解析6 MinIO客户端mc加密功能路径匹配问题解析与修复7 KICS项目中的S3存储桶加密配置问题解析8 MinIO客户端mc使用SSE-C加密上传文件的技术指南9 Mountpoint for Amazon S3中KMS密钥ID格式问题的技术解析10 Mountpoint-S3 项目新增 AES256 服务器端加密支持的技术解析
热门项目推荐
相关项目推荐

热门内容推荐

1 编程实践项目探索指南：从零构建技术能力体系2 技术解构式学习：从0到1构建你的编程知识体系3 构建自己的技术世界：build-your-own-x项目的实践探索指南4 解锁编程技能的实践之旅：从零构建你的技术世界5 技术实践探索：从零开始构建核心系统的实践指南6 亲手锻造技术引擎：从0到1构建核心系统的实践指南

最新内容推荐

Playwright 页面级 Screencast 完整指南：录屏、JPEG 逐帧回调与演示叠加层（v1.59+）在 Next.js 项目中集成 ESLint：基于 with-eslint 官方示例与 next 共享配置的完整指南Puppeteer 导航控制详解：GoToOptions 接口的配置项、默认语义与底层实现Traefik etcd Provider 详解：用 etcd 作为动态配置源构建可编程路由OpenCV 模板匹配实战：matchTemplate 原理、掩码与 6 种匹配方法详解（C++ / Python / Java 完整示例）Test Table SlideAngular Signals 防抖指南：用 `debounced` 将去抖信号无缝接入 `Resource` 异步数据流Rust 编译器错误码 E0243 解析：泛型实参数量不足的诊断与现代化演进使用 Supabase 与 Next.js 构建实时 Slack 克隆：从数据库 Schema、RLS 权限到 Realtime 全栈实践Flutter Android Platform Views 全模式解析：Hybrid Composition++、Virtual Display、Hybrid Composition 与 Texture Layer Hybrid Composition

项目优选

收起
kernelkernel
deepin linux kernel
C
33
18
pytorchpytorch
作为 Ascend for PyTorch 社区的核心组件，TorchNPU 是昇腾专为 PyTorch 打造的深度学习适配插件，使 PyTorch 框架能够直接调用昇腾 NPU，为开发者提供昇腾 AI 处理器的超强算力。
Python
854
1.34 K
ops-transformerops-transformer
本项目是CANN提供的transformer类大模型算子库，实现网络在NPU上加速计算。
C++
1.12 K
2.72 K
kernelkernel
openEuler内核是openEuler操作系统的核心，既是系统性能与稳定性的基石，也是连接处理器、设备与服务的桥梁。
C
528
589
ops-nnops-nn
本项目是CANN提供的神经网络类计算算子库，实现网络在NPU上加速计算。
C++
906
1.83 K
jiuwenswarmjiuwenswarm
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent，它能够将大语言模型的强大能力，通过你日常使用的各类通讯应用，直接延伸至你的指尖。
Python
3.55 K
1.01 K
cann-learning-hubcann-learning-hub
CANN 学习中心仓，支持在线互动运行、边学边练，提供教程、示例与优化方案，一站式助力昇腾开发者快速上手。
Jupyter Notebook
991
508
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库，实现网络在NPU上加速计算。
C++
1.34 K
1.45 K
docsdocs
暂无描述
Markdown
892
5.79 K
openGauss-serveropenGauss-server
openGauss kernel ~ openGauss is an open source relational database management system
C++
213
313