首页
/ Nuxt Kit Builder 工具详解:扩展 Vite / webpack 配置与构建输出的完整指南

Nuxt Kit Builder 工具详解:扩展 Vite / webpack 配置与构建输出的完整指南

2026-09-07 09:51:44作者:魏侃纯Zoe

导读

Nuxt 的构建系统建立在 Vite 与 webpack(以及 Rspack)之上,为了让模块作者能够无侵入地介入各类打包器的配置装配过程,Nuxt Kit 提供了一组围绕“构建器(Builder)”的高层工具函数。本文围绕 docs/4.api/5.kit/15.builder.md 展开,系统讲解 extendViteConfigextendWebpackConfigaddVitePluginaddWebpackPluginaddBuildPluginsetBuildOutput 六个 API 的用法、参数语义与底层实现机制。读完本文,你将掌握在 Nuxt 模块中追加 Vite/webpack 插件、修改两类打包器配置、以及注册构建产物(build output)供 Nitro 服务端运行时消费的完整套路,并理解 Nuxt 5+ 中 Vite Environment API 引入的配置作用域变化。

Nuxt 的构建器与 Kit 工具定位

Nuxt 生态中存在三种官方或官方相关构建器:Vite(见 packages/vite)、webpack(见 packages/webpack),以及社区与 Rspack 相关的构建链路。它们各自的完整实现位于 packages 目录,而 Nuxt Kit 的构建工具函数则集中在 packages/kit/src/build.ts,并在 packages/kit/src/index.ts 中统一导出:

export { addBuildPlugin, addVitePlugin, addRspackPlugin, addWebpackPlugin, extendViteConfig, extendRspackConfig, extendWebpackConfig, setBuildOutput } from './build.ts'
export type { ExtendConfigOptions, ExtendViteConfigOptions, ExtendWebpackConfigOptions } from './build.ts'

从用途上可以把这些 API 分为两类:

  1. 配置扩展类extendViteConfig / extendWebpackConfig 允许模块读取并原地修改传给对应构建器的配置对象;
  2. 插件注册类addVitePlugin / addWebpackPlugin / addBuildPlugin 允许模块把插件实例“挂”进最终配置的 plugins 数组;
  3. 构建产物注册类setBuildOutput 让构建器(或参与构建的模块)把产物的“提供者”写入 nuxt.buildOutputs,供 Nitro 服务端运行时以稳定的 nuxt/* 子路径导入消费。

所有函数都必须在模块的 setup() 阶段调用(此时 Nuxt 上下文可用),它们内部依赖 useNuxt() 获取当前 Nuxt 实例。

extendViteConfig:扩展 Vite 配置

extendViteConfig 用于扩展传给 Vite 的配置对象。其回调可能被调用多次——当同一份配置同时作用于客户端与服务端构建时(准确地说,取决于你传递的 options)。

基本用法

在模块 setup 中为 optimizeDeps.include 追加依赖项:

import { defineNuxtModule, extendViteConfig } from '@nuxt/kit'

export default defineNuxtModule({
  setup () {
    extendViteConfig((config) => {
      config.optimizeDeps ||= {}
      config.optimizeDeps.include ||= []
      config.optimizeDeps.include.push('cross-fetch')
    })
  },
})

类型签名

import type { UserConfig as ViteConfig } from 'vite'
import type { ExtendViteConfigOptions } from '@nuxt/kit'

function extendViteConfig (callback: ((config: ViteConfig) => void), options?: ExtendViteConfigOptions): void

参数说明

Property Type Required Description
dev boolean false 若设为 true,开发模式下构建时会调用回调函数。默认来自源码 ExtendConfigOptions 中的 @default true,即默认在开发与生产构建都会生效;显式传 false 会在开发模式下跳过。
build boolean false 若设为 true,生产构建时会调用回调函数;传 false 则在生产构建时跳过。
server boolean false 若设为 true,构建服务端 bundle 时调用回调。Nuxt 5+ 已弃用,改用 addVitePlugin() 配合 applyToEnvironment()
client boolean false 若设为 true,构建客户端 bundle 时调用回调。Nuxt 5+ 已弃用,改用 addVitePlugin() 配合 applyToEnvironment()
prepend boolean false 若设为 true,回调以 unshift() 方式前置追加到数组中,而非默认的 push() 追加(该选项实际作用于插件数组的插入顺序)。

关于 dev/build 的默认语义:结合 packages/kit/src/build.tsExtendConfigOptions 源码可知,devbuildserverclient 四个布尔开关的默认值均为 true(即默认在所有模式、所有端生效)。dev: false / build: false 会让函数在对应模式下提前返回、跳过注册。

弃用警告:文档明确提示 extendViteConfig 已经弃用,官方推荐改用 Vite 插件(plugin)形态并实现 config 钩子;如果需要按环境(environment)做差异化配置,则使用 applyToEnvironment 钩子(详见下文 addVitePlugin 一节)。

Nuxt 5+ 的推荐替代写法

针对 Nuxt 5+ 的环境级配置,官方推荐直接改用 addVitePlugin()

import { addVitePlugin, defineNuxtModule } from '@nuxt/kit'

export default defineNuxtModule({
  setup () {
    // 全局配置(影响所有环境)
    addVitePlugin(() => ({
      name: 'my-global-plugin',
      config (config) {
        // 该钩子在环境装配之前运行,修改的是全局配置
        config.optimizeDeps ||= {}
        config.optimizeDeps.include ||= []
        config.optimizeDeps.include.push('cross-fetch')
      },
    }))

    // 按环境做差异化配置
    addVitePlugin(() => ({
      name: 'my-client-plugin',
      applyToEnvironment (environment) {
        return environment.name === 'client'
      },
      configEnvironment (name, config) {
        // 仅影响 client 环境
        config.optimizeDeps ||= {}
        config.optimizeDeps.include ||= []
        config.optimizeDeps.include.push('client-only-package')
      },
    }))
  },
})

执行顺序要点config 钩子先于 applyToEnvironment 运行,且修改的是全局配置;需要环境级差异时请用 configEnvironment。这是 Nuxt 5+ 采用 Vite Environment API 之后的关键变化。

底层实现原理

从源码看,extendViteConfig 的实现非常轻量(packages/kit/src/build.ts):

export function extendViteConfig (fn, options = {}) {
  const nuxt = useNuxt()
  if (options.dev === false && nuxt.options.dev) { return }
  if (options.build === false && nuxt.options.build) { return }
  // 若显式只针对 server/client,会向调用者打印弃用警告
  // ...
  // fn() 只被调用一次
  return nuxt.hook('vite:extend', ({ config }) => fn(config))
}

关键事实:

  • 回调挂在 vite:extend 钩子上。该钩子由 Vite 构建器的 packages/vite/src/vite.ts 在完整 ViteConfig 装配完成后触发一次(await nuxt.callHook('vite:extend', ctx))。
  • 从源码注释(Call fn() only once)可以看出,Vite 分支不再像 webpack 那样为 client/server 各调一次——因为 Nuxt 5+ 的 Vite Environment API 让 clientssr 环境共享同一份基础配置,环境级差异交给插件钩子处理。因此文档中“回调可能被调用多次”的描述主要针对旧版行为与 webpack 场景。
  • 当你显式传入 server: falseclient: false 时,Kit 会通过 getUserCaller() 找到调用点并打印形如 [@nuxt/kit] calling extendViteConfig with only server/client environment is deprecated... 的弃用警告,提示改用 Vite 插件方案。

extendWebpackConfig:扩展 webpack 配置

extendWebpackConfig 用于扩展 webpack 配置。与 Vite 分支不同,webpack 的 client 与 server 是两份独立命名配置,因此回调默认会被调用多次(分别针对 server 与 client 构建)。

基本用法

为 webpack 追加一条 raw-loader 规则,用于导入 .txt 文件:

import { defineNuxtModule, extendWebpackConfig } from '@nuxt/kit'

export default defineNuxtModule({
  setup () {
    extendWebpackConfig((config) => {
      config.module!.rules!.push({
        test: /\.txt$/,
        use: 'raw-loader',
      })
    })
  },
})

类型签名

import type { Configuration as WebpackConfig } from 'webpack'
import type { ExtendWebpackConfigOptions } from '@nuxt/kit'

function extendWebpackConfig (callback: ((config: WebpackConfig) => void), options?: ExtendWebpackConfigOptions): void

参数说明

Property Type Required Description
dev boolean false 若设为 true,开发模式构建时调用回调;false 则在开发模式跳过。
build boolean false 若设为 true,生产构建时调用回调;false 则在生产构建跳过。
server boolean false 若设为 true,构建 server bundle 时调用回调。
client boolean false 若设为 true,构建 client bundle 时调用回调。
prepend boolean false 若设为 true,回调以 unshift() 方式前置追加,而非默认 push()

底层实现原理

extendWebpackConfigextendRspackConfig 实际共享同一个工厂函数 extendWebpackCompatibleConfigpackages/kit/src/build.ts):

const extendWebpackCompatibleConfig = (builder: 'rspack' | 'webpack') => (fn, options = {}) => {
  const nuxt = useNuxt()
  if (options.dev === false && nuxt.options.dev) { return }
  if (options.build === false && nuxt.options.build) { return }
  nuxt.hook(`${builder}:config`, async (configs) => {
    if (options.server !== false) {
      const config = configs.find(i => i.name === 'server')
      if (config) { await fn(config) }
    }
    if (options.client !== false) {
      const config = configs.find(i => i.name === 'client')
      if (config) { await fn(config) }
    }
  })
}

由此可确认的实现事实:

  • 回调注册在 webpack:config(或 rspack:config)钩子上。Nuxt 服务端运行时在 packages/nitro-server/src/index.ts 处统一回调 webpack:configrspack:config 钩子,钩子类型定义见 packages/schema/src/types/hooks.ts
  • 回调并非对整份配置数组调用一次,而是从 configs 数组中按 name === 'server' / name === 'client' 查找命名配置并分别调用。默认情况下(serverclient 均未显式关闭)同一个回调会被执行两次,这正是文档“callback function can be called multiple times”的来源。如果你只需要修改某一端,务必传入 { server: false }{ client: false }
  • webpack 配置对象可能是 Promise 形式的结果,回调函数支持 asyncawait fn(config)),因此返回值为 Thenable<void> 也是允许的。

addVitePlugin:追加 Vite 插件

addVitePlugin 把插件实例追加进 Vite 配置。它是 Nuxt 5+ 环境中做配置扩展的首选入口。

基本用法

模块化地接入 SVG 图标插件:

import { addVitePlugin, defineNuxtModule } from '@nuxt/kit'
import { svg4VuePlugin } from 'vite-plugin-svg4vue'

export default defineNuxtModule({
  meta: {
    name: 'nuxt-svg-icons',
    configKey: 'nuxtSvgIcons',
  },
  defaults: {
    svg4vue: {
      assetsDirName: 'assets/icons',
    },
  },
  setup (options) {
    addVitePlugin(svg4VuePlugin(options.svg4vue))

    // 或者:只把插件加到某一个环境
    addVitePlugin(() => ({
      name: 'my-client-plugin',
      applyToEnvironment (environment) {
        return environment.name === 'client'
      },
      // ... 其余仅客户端生效的插件逻辑
    }))
  },
})

类型签名

pluginOrGetter 同时接受插件实例、插件实例数组,或返回这两者的(可异步)函数:

import type { Plugin as VitePlugin } from 'vite'
import type { ExtendViteConfigOptions } from '@nuxt/kit'

function addVitePlugin (pluginOrGetter: VitePlugin | VitePlugin[] | (() => VitePlugin | VitePlugin[]), options?: ExtendViteConfigOptions): void

参数说明

pluginOrGetter:Vite 插件实例,或插件实例数组。若传入函数,则该函数必须返回插件实例或插件实例数组;函数也可以是 async 的(返回 Promise)——这一点对“懒加载”插件特别有用:只有真正执行构建时才会 import 插件模块,避免模块加载阶段不必要的开销与副作用:

import { addVitePlugin, defineNuxtModule } from '@nuxt/kit'

export default defineNuxtModule({
  setup () {
    // 懒加载插件——只在构建真正执行时才 import
    addVitePlugin(() => import('my-vite-plugin').then(r => r.default()))
  },
})

options:与 extendViteConfig 相同的 ExtendViteConfigOptions

Property Type Required Description
dev boolean false true 表示开发模式构建时安装插件。
build boolean false true 表示生产构建时安装插件。
server boolean false true 表示在 server bundle 安装插件。Nuxt 5+ 弃用,改用 applyToEnvironment()
client boolean false true 表示在 client bundle 安装插件。Nuxt 5+ 弃用,改用 applyToEnvironment()
prepend boolean false true 表示用 unshift() 前置插入插件数组,而非默认 push() 追加。

底层实现与 Nuxt 5+ 环境 API

源码实现(packages/kit/src/build.ts)展示了 Nuxt 5+ 的两个关键分支:

  1. 判断是否为“同构”插件const isIsomorphic = options.server !== false && options.client !== false。未显式关闭任何一端时,插件被视为同构插件,直接以顶层插件追加进 config.plugins
  2. 环境 API 感知:若 Vite 配置尚未使用 Environment API(不存在 config.environments?.ssrconfig.environments.client),则非同构插件被标记为 needsEnvInjection,改由每个环境逐个触发的 vite:extendConfig 钩子注入(该钩子在 packages/vite/src/vite.ts 中按 client/ssr 循环触发);若已启用 Environment API,则通过 scopeToEnvironments 包装插件:
    • 为插件补上 applyToEnvironment(environment):当 isAllowed 判定环境不属于该插件作用域时返回 false,否则调用插件自身的 applyToEnvironment(若存在);
    • 为插件推导默认 enforce:同构插件仅在 prepend 时取 'pre',否则保持不指定;按端区分的插件在 prepend 时取 'pre',否则取 'post'
    • 包装插件仍然作为顶层插件返回,而不是嵌套在包装器内,这样 Vite 仍会正常执行 apply、按 enforce 排序、调用 configureServer 等服务器级钩子,并暴露插件声明的其它属性(如 api)。

这意味着:在 Nuxt 5+,用 server: falseclient: false 注册的插件,其 config / configResolved 钩子不会再被调用;如需按环境生效,应使用 applyToEnvironment() 方法编写插件。

addWebpackPlugin:追加 webpack 插件

addWebpackPlugin 把插件实例追加到 webpack 配置的 plugins 数组中,通常配合构建时 lint、代码分析等场景使用。

基本用法

一个把 eslint-webpack-plugin 接入 Nuxt 的模块示例(客户端构建生效、生产/开发默认均启用):

import EslintWebpackPlugin from 'eslint-webpack-plugin'
import { addWebpackPlugin, defineNuxtModule } from '@nuxt/kit'

export default defineNuxtModule({
  meta: {
    name: 'nuxt-eslint',
    configKey: 'eslint',
  },
  defaults: nuxt => ({
    include: [`${nuxt.options.srcDir}/**/*.{js,jsx,ts,tsx,vue}`],
    lintOnStart: true,
  }),
  setup (options, nuxt) {
    const webpackOptions = {
      ...options,
      context: nuxt.options.srcDir,
      files: options.include,
      lintDirtyModulesOnly: !options.lintOnStart,
    }
    addWebpackPlugin(new EslintWebpackPlugin(webpackOptions), { server: false })
  },
})

类型签名

import type { WebpackPluginInstance } from 'webpack'
import type { ExtendWebpackConfigOptions } from '@nuxt/kit'

function addWebpackPlugin (pluginOrGetter: WebpackPluginInstance | WebpackPluginInstance[] | (() => WebpackPluginInstance | WebpackPluginInstance[]), options?: ExtendWebpackConfigOptions): void

参数说明

pluginOrGetter:webpack 插件实例或实例数组;也可传函数,函数须返回插件实例或数组,且可以是 async(返回 Promise),从而支持插件的懒加载。

options:完整的 ExtendWebpackConfigOptions(webpack 分支的 server/client 未弃用):

Property Type Required Description
dev boolean false true 表示开发模式构建时安装插件。
build boolean false true 表示生产构建时安装插件。
server boolean false true 表示在 server bundle 安装插件。
client boolean false true 表示在 client bundle 安装插件。
prepend boolean false true 表示用 unshift() 前置插入插件数组,而非默认 push() 追加。

底层实现原理

源码(packages/kit/src/build.ts)内部即是对 extendWebpackConfig 的封装:

export function addWebpackPlugin (pluginOrGetter, options) {
  extendWebpackConfig(async (config) => {
    const method = options?.prepend ? 'unshift' : 'push'
    const plugin = typeof pluginOrGetter === 'function' ? await pluginOrGetter() : pluginOrGetter
    config.plugins ||= []
    config.pluginsmethod)
  }, options)
}

要点:函数形态的 pluginOrGetter 会被 await,实现懒求值;得到的插件通过 toArray 归一为数组后一次性展开追加/前置。因底层复用 extendWebpackConfig,插件同样默认会被同时安装到 server 与 client 两份配置中,如示例所示通常需要显式传 { server: false } 来限定作用端。

addBuildPlugin:构建器无关的插件注册

addBuildPluginaddVitePluginaddWebpackPlugin(以及 Rspack 链路)的构建器无关版本:向它传入一个工厂,它会自动把对应构建器的插件分发给当前存在的 Vite / webpack / Rspack 配置——前提是这些构建器确实被启用。

类型签名

import type { ExtendConfigOptions } from '@nuxt/kit'
import type { Plugin as VitePlugin } from 'vite'
import type { WebpackPluginInstance } from 'webpack'
import type { RspackPluginInstance } from '@rspack/core'

interface AddBuildPluginFactory {
  vite?: () => VitePlugin | VitePlugin[]
  webpack?: () => WebpackPluginInstance | WebpackPluginInstance[]
  rspack?: () => RspackPluginInstance | RspackPluginInstance[]
}

function addBuildPlugin (pluginFactory: AddBuildPluginFactory, options?: ExtendConfigOptions): void

参数说明

pluginFactory:一个返回对象工厂,对象的 vite 与/或 webpack(及 rspack)属性必须是函数,各自返回对应构建器的插件实例或实例数组。

optionsExtendConfigOptions

Property Type Required Description
dev boolean false true 表示开发模式构建时安装。
build boolean false true 表示生产构建时安装。
server boolean false true 表示在 server bundle 安装。
client boolean false true 表示在 client bundle 安装。
prepend boolean false true 表示用 unshift() 前置插入插件数组。

底层实现原理

源码(packages/kit/src/build.ts)极为直白——工厂里声明了哪个构建器,就分发给哪个构建器:

export function addBuildPlugin (pluginFactory, options) {
  if (pluginFactory.vite) { addVitePlugin(pluginFactory.vite, options) }
  if (pluginFactory.webpack) { addWebpackPlugin(pluginFactory.webpack, options) }
  if (pluginFactory.rspack) { addRspackPlugin(pluginFactory.rspack, options) }
}

它的价值在于:如果你的模块希望同时兼容使用 Vite、webpack 或 Rspack 的 Nuxt 项目,只需写一次注册逻辑,Kit 会按实际启用的构建器自动分发。注意 addVitePlugin 收到的 options 语义受上一节所述的环境 API 行为约束。

setBuildOutput:注册构建产物

setBuildOutput 为给定 key 设置一个“构建产物提供者”。构建产物是构建器(Vite、webpack、Rspack 或自定义构建器)与 Nitro 服务端运行时之间的契约:每个 key 对应一个 nuxt/* 子路径导入,服务端运行时在构建期解析它。它通常由构建器内部调用,或由参与构建过程的模块调用。关于这套契约的完整机制,参见 docs/3.guide/6.going-further/8.builders.md(原文以 /docs/4.x/guide/going-further/builders 链接指向的“build output contract”小节)。

类型签名

import type { NuxtBuildOutputs } from '@nuxt/schema'

function setBuildOutput<K extends keyof NuxtBuildOutputs> (key: K, provider: NuxtBuildOutputs[K]): void

参数说明

key:构建产物键,取值于 NuxtBuildOutputs 的键集合:serverEntryclientManifestclientPrecomputedssrStylesentryChunkNameentryIds 之一。

provider:对应 key 的值——一个(可异步的)函数,返回模块内容(string),在服务端构建解析对应的 nuxt/* 导入时被惰性读取(lazily read)。

完整示例

import { setBuildOutput } from '@nuxt/kit'

// 通过绝对 specifier 重新导出构建好的 SSR entry
setBuildOutput('serverEntry', () => `export { default } from ${JSON.stringify(serverEntryURL)}`)

// 提供序列化后的 client manifest
setBuildOutput('clientManifest', () => `export default ${serializedManifest}`)

// 重新导出按组件生成的样式映射,供 `nuxt/styles` 使用
setBuildOutput('ssrStyles', () => `export { default } from ${JSON.stringify(pathToFileURL(resolve(serverDir, 'styles.mjs')).href)}`)

底层实现与契约细节

packages/schema/src/types/nuxt.ts 可以看到 NuxtBuildOutputs 的完整定义,其中每个 key 都被注释说明了消费方:

  • serverEntry:模块体重新导出 SSR app 入口,服务端运行时经 nuxt/entry 子路径拿到 createRenderer 所需的 SSR app factory;
  • ssrStyles:按组件划分的 SSR 内联样式映射模块体,并含 inlinedCSS 具名导出——把渲染时可能被丢弃 <link> 的每个已输出 CSS 文件映射到“内联了其内容的模块 ID 分组”,默认两者均为空映射;运行时经 nuxt/styles 解析;
  • clientManifest:供 vue-bundle-renderer 使用的序列化客户端 manifest;
  • clientPrecomputed:供 vue-bundle-renderer 使用的序列化预计算客户端依赖数据;
  • entryChunkName:导出“带 hash 的入口 chunk 文件名”的模块体,用于 import maps;
  • entryIds:导出入口模块 ID 的模块体,用于内联样式提取。

setBuildOutput 的源码实现(packages/kit/src/build.ts)非常简洁,就是把 provider 写入当前 Nuxt 实例的 nuxt.buildOutputs[key]

export function setBuildOutput<K extends keyof NuxtBuildOutputs> (key: K, provider: NuxtBuildOutputs[K], nuxt: Nuxt = useNuxt()): void {
  nuxt.buildOutputs[key] = provider
}

在消费侧,Nitro 服务端运行时会把 nuxt.buildOutputs 作为 nuxt/* 虚拟模块的来源。例如 packages/nitro-server/src/index.ts 里保留了默认的构建产物并提供给 nuxt/entry-chunknuxt/entry-ids 等,同文件第 571 行则用 nitroConfig.virtual![specifier] = () => nuxt.buildOutputs[key]() 把用户构建器注册的产物注入虚拟模块。由于 provider 是惰性函数,产物内容(例如 SSR entry 的路径、manifest 数据)只在实际构建解析 nuxt/* 导入时才被读取,这为构建器提供了在构建流程中“随时”填充产物的灵活性。

不常用到的 key 不必全部提供:例如 SSR 被禁用时 serverEntry 的默认值就是 no-op app,其它多数输出也不会被消费;只提供你的构建器真实产出的 key 即可。这与构建输出契约文档中“defaults are sensible… provide only what your build produces”的指导一致。

小结与选型建议

API 用途 作用构建器 Nuxt 5+ 注意事项
extendViteConfig 原地修改 Vite 配置对象 Vite 已弃用;推荐改用 Vite 插件的 config 钩子
extendWebpackConfig 原地修改 webpack 配置对象(server/client 各调一次) webpack 无环境 API 问题,server/client 选项仍有效
addVitePlugin 追加 Vite 插件(支持懒加载) Vite server:false/client:falseconfig 钩子不再触发;按环境请用 applyToEnvironment
addWebpackPlugin 追加 webpack 插件(支持懒加载) webpack 注意默认会同时作用于 server 与 client
addBuildPlugin 同时向 Vite/webpack/Rspack 分发插件 多构建器 是编写跨构建器模块的首选入口
setBuildOutput 注册 nuxt/* 构建产物 provider 全部(含自定义构建器) 是构建器与 Nitro 服务端运行时之间契约的核心

实际编写模块时的两条核心经验:

  1. 新代码优先走插件化路线:在 Nuxt 5+,凡是想修改 Vite 配置的地方,优先用 addVitePlugin 配合插件的 config / configEnvironment / applyToEnvironment 钩子,而不是直接调用 extendViteConfig——后者面向旧版共享配置模型的 server/client 区分已经弃用并会打印警告。
  2. 跨构建器模块用 addBuildPlugin:如果你无法预知使用方项目用的是 Vite 还是 webpack/Rspack,写一份 AddBuildPluginFactory 即可覆盖三种构建器;再配合 setBuildOutput 参与到构建产物契约中,模块就能与 Nuxt 的构建管线深度集成。

所有 API 的类型与导出声明可在 packages/kit/src/index.tspackages/kit/src/build.ts 中直接查阅,模块开发的基础流程可参考 docs/3.guide/4.modules/1.getting-started.md

登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
33
18
ops-transformerops-transformer
本项目是CANN提供的transformer类大模型算子库,实现网络在NPU上加速计算。
C++
1.14 K
2.74 K
pytorchpytorch
作为 Ascend for PyTorch 社区的核心组件,TorchNPU 是昇腾专为 PyTorch 打造的深度学习适配插件,使 PyTorch 框架能够直接调用昇腾 NPU,为开发者提供昇腾 AI 处理器的超强算力。
Python
857
1.35 K
docsdocs
暂无描述
Markdown
897
5.81 K
kernelkernel
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
531
595
ops-nnops-nn
本项目是CANN提供的神经网络类计算算子库,实现网络在NPU上加速计算。
C++
920
1.84 K
jiuwenswarmjiuwenswarm
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent,它能够将大语言模型的强大能力,通过你日常使用的各类通讯应用,直接延伸至你的指尖。
Python
3.63 K
1.02 K
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
1.36 K
1.46 K
cann-learning-hubcann-learning-hub
CANN 学习中心仓,支持在线互动运行、边学边练,提供教程、示例与优化方案,一站式助力昇腾开发者快速上手。
Jupyter Notebook
1.02 K
518
AscendNPU-IRAscendNPU-IR
AscendNPU-IR是基于MLIR(Multi-Level Intermediate Representation)构建的,面向昇腾亲和算子编译时使用的中间表示,提供昇腾完备表达能力,通过编译优化提升昇腾AI处理器计算效率,支持通过生态框架使能昇腾AI处理器与深度调优
C++
547
389