站点图标 高效码农

Google LiteRT NeuroPilot：将手机NPU变为设备端大模型的“一等公民”

高效码农

在追求更快、更私密的AI体验时代，设备端运行大型语言模型（LLM）是关键的下一步。但将动辄数十亿参数的模型塞进手机，并流畅运行，一直是开发者的巨大挑战。最近，Google与MediaTek联手推出的LiteRT NeuroPilot Accelerator技术栈，正致力于将MediaTek Dimensity系列芯片的NPU（神经处理单元）变成运行设备端LLM的“首选目标”。这不仅仅是又一个技术更新，它旨在彻底改变开发者与手机专用AI硬件打交道的方式。

概述：告别碎片化，迎来统一NPU开发体验

想象一下，你开发了一个手机AI应用，需要针对市面上数十款不同型号的MediaTek芯片进行不同的优化、编译和打包——这就是过去设备端机器学习开发的常态。NPU（神经处理单元）虽强，但各家厂商的软件开发工具包（SDK）和编译链各不相同，导致开发流程复杂，适配成本极高。

LiteRT NeuroPilot Accelerator 的核心目标就是终结这种混乱。它通过深度集成Google的LiteRT运行时与MediaTek的NeuroPilot NPU软件栈，为开发者提供了一个统一的、高级别的API抽象层。现在，开发者可以像调用CPU或GPU一样，通过简单的 Accelerator.NPU 选项，将模型部署到覆盖中端到旗舰的众多Dimensity芯片上，而无需为每款芯片编写定制代码。

核心摘要：Google的LiteRT NeuroPilot Accelerator技术栈通过统一API，将MediaTek Dimensity系列芯片的NPU深度整合进设备端AI运行时。它支持Qwen3、Gemma-3系列等开源模型，在Dimensity 9500上可使Gemma 3n E2B模型实现超过1600 tokens/s的预填充速度，并通过AOT（预先编译）技术将大模型首次运行编译时间从数分钟降至零，极大简化了高性能设备端LLM的部署流程。

技术深潜：什么是LiteRT NeuroPilot Accelerator？

要理解这项技术，我们首先要厘清几个关键组件：

  • LiteRT：你可以将其视为TensorFlow Lite的进化版。它是一个高性能的设备端运行时，专为运行 .tflite 格式的模型而设计。其最大特点是拥有一个统一的硬件加速层，能够将计算任务智能地分发到CPU、GPU，现在，通过新的Accelerator，也能无缝分发到NPU。
  • NeuroPilot：这是MediaTek为其NPU打造的软件生态系统，包含编译器、驱动和运行时。
  • LiteRT NeuroPilot Accelerator：这正是连接上述两者的桥梁。它不再像过去的“TFLite NeuroPilot委托”那样，将NPU视为一个外围插件，而是实现了与NeuroPilot编译器、运行时的直接集成。这带来了一个根本性的变化：从“委托”模式升级为 “编译模型（Compiled Model）”API。

这个新的API同时支持预先编译（AOT）和设备端即时编译两种模式，并通过相同的C++和Kotlin API向开发者暴露。这意味着，无论是为了追求极致性能而预先针对特定芯片优化模型，还是希望保持模型分发灵活性在用户设备上首次运行时编译，开发者都能使用同一套代码逻辑。

支持的硬件：目前，该集成已明确支持MediaTek Dimensity 7300, 8300, 9000, 9200, 9300 和 9400系列系统级芯片（SoC）。这些芯片广泛覆盖了Android中端和旗舰手机市场，为应用提供了庞大的潜在硬件基础。

开发者为何应关注？一场工作流的革命

对于工程师而言，LiteRT NeuroPilot带来的最直接价值是一个高度简化的三步骤工作流。无论目标设备是搭载Dimensity 7300还是9400，流程完全一致：

  1. 模型准备：像往常一样转换或加载你的 .tflite 模型。
  2. 可选预先编译：使用LiteRT的Python工具进行AOT编译，生成一个或多个目标SoC绑定的“AI包”。这是部署生产级LLM的关键步骤。
  3. 部署与运行：通过Google Play的“设备端AI”服务分发AI包，在应用运行时，只需简单地选择 Accelerator.NPU。LiteRT会自行处理设备匹配、运行时加载，并在NPU不可用时自动回退至GPU或CPU。

这种设计将复杂的设备适配逻辑从应用代码中剥离，转移到了结构化的配置文件和分发渠道中。作为开发者，你的主要交互对象变成了 CompiledModel 和那个决定性的硬件加速器选项。

AOT vs. 设备端编译：一个至关重要的性能抉择

两种编译模式各有优劣，选择取决于你的模型大小和部署策略：

  • AOT预先编译：在开发端为已知型号的SoC提前编译模型。这是部署大型模型（如LLM）的推荐方式。因为它彻底消除了在用户设备上进行首次编译的耗时。数据显示，对于Gemma-3-270M这样的模型，纯设备端编译可能耗时超过1分钟，这在实际应用中是无法接受的。AOT将这部分成本提前消化，用户首次打开应用即可获得极致性能。
  • 设备端即时编译：直接分发通用的 .tflite 文件，在用户设备上首次运行时编译。这更适合小型模型，或者需要极高分发灵活性的场景，代价是用户会感受到显著的“首次运行延迟”。

实战性能：哪些模型能在MediaTek NPU上飞驰？

该技术栈并非空谈框架，而是围绕一系列具体、开源的模型构建，提供了明确的生产级支持。这些模型覆盖了从文本生成到多模态理解的多种任务：

  • Qwen3 0.6B：专为文本生成设计，特别针对中国大陆等市场需求。
  • Gemma-3-270M：一个紧凑的基础模型，易于针对情感分析、实体提取等任务进行微调。
  • Gemma-3-1B：一个多语言纯文本模型，适用于摘要和通用推理。
  • Gemma-3n E2B：一个多模态模型，能够处理文本、音频和视觉输入，可用于实时翻译、视觉问答等场景。
  • EmbeddingGemma 300M：一个文本嵌入模型，专为检索增强生成、语义搜索和分类任务优化。

量化性能表现：
在搭载最新Dimensity 9500芯片的Vivo X300 Pro设备上，运行在NPU上的Gemma 3n E2B模型展示了令人印象深刻的性能：

  • 预填充阶段：速度超过 1600 tokens/秒（在4K上下文长度下）。
  • 解码生成阶段：速度达到 28 tokens/秒（同样在4K上下文长度下）。
  • 横向对比：与运行在CPU和GPU上相比，NPU在LLM工作负载上的吞吐量实测最高可达CPU的12倍，GPU的10倍。

针对不同任务的API层级：

  • 文本生成：使用高级的 LiteRT-LM 引擎。它构建在LiteRT之上，提供了一个状态化的、文本输入/文本输出的简洁API。典型流程是创建模型资产，构建指定 litert::lm::Backend::NPU 的引擎，然后创建会话进行内容生成。
  • 嵌入任务：使用更底层的LiteRT CompiledModel API，以张量输入/输出的方式进行，同样通过硬件加速器选项选择NPU。

开发者体验指南：C++ API与零拷贝内存

LiteRT引入了一套全新的、面向对象的C++ API，取代了旧的C接口，核心对象包括 Environment, Model, CompiledModel 和 TensorBuffer。

对于MediaTek NPU的开发者，这套API的一个关键优势是与Android硬件缓冲区的深度集成。你可以使用 TensorBuffer::CreateFromGlBuffer 等方法，直接从OpenGL或OpenCL缓冲区构造输入 TensorBuffer。这意味着，相机或视频处理流水线中的数据可以直接送入NPU进行计算，无需经过CPU内存的中转拷贝。在实时视频处理等对内存带宽极其敏感的场景中，避免每帧图像的多次拷贝至关重要。

下面是一个简化的C++代码示例，展示了如何使用新API在设备端运行一个已编译的模型：

// 1. 加载模型（可以是.tflite或预编译的AI包）
auto model = Model::CreateFromFile("model.tflite");

// 2. 创建配置选项，并明确指定使用NPU加速
auto options = Options::Create();
options->SetHardwareAccelerators(kLiteRtHwAcceleratorNpu);

// 3. 创建编译模型实例（LiteRT会根据选项和硬件自动选择最优路径）
auto compiled = CompiledModel::Create(*env, *model, *options);

// 4. 分配输入输出缓冲区
auto input_buffers = compiled->CreateInputBuffers();
auto output_buffers = compiled->CreateOutputBuffers();

// 5. 写入输入数据，执行推理，读取输出数据
input_buffers[0].Write<float>(input_span); // 可以是来自相机流的零拷贝缓冲区
compiled->Run(input_buffers, output_buffers);
output_buffers[0].Read(output_span);

无论你最终的目标是CPU、GPU还是MediaTek NPU，这段代码结构都保持一致，极大地减少了应用程序中的条件判断和平台相关代码。

常见问题解答

Q1: LiteRT NeuroPilot Accelerator 和以前的 TensorFlow Lite with NeuroPilot Delegate 有什么区别？
A1: 这是从“插件委托”到“一级集成”的架构升级。旧方案将NPU作为附加委托调用，流程割裂。新方案将NPU作为LiteRT运行时内部的一等加速目标，提供了统一的CompiledModel API，支持AOT和设备端编译，开发体验更连贯，性能调度更优。

Q2: 我是否必须使用AOT编译才能让我的LLM应用在手机上可用？
A2: 对于像Gemma-3-270M或更大的LLM，强烈建议使用AOT编译。因为实测显示，这类模型在设备端首次编译可能耗时超过1分钟，严重影响用户体验。AOT编译将耗时环节前置，用户安装的已经是针对其芯片优化的版本，打开即可高速运行。

Q3: 如果用户的手机NPU不支持我的模型，会发生什么？
A3: LiteRT运行时内置了优雅的回退机制。当你在代码中指定 Accelerator.NPU 后，如果目标设备的NPU因任何原因（不支持、内存不足、模型算子不兼容）无法执行，LiteRT会自动尝试使用GPU，如果GPU也不可用，则会回退到CPU执行。这保证了应用的功能在所有设备上都可用，只是在性能上有差异。

Q4: 支持哪些具体的MediaTek芯片？
A4: 目前官方文档明确支持的SoC包括：Dimensity 7300, 8300, 9000, 9200, 9300 和 9400系列。这基本涵盖了当前主流的中高端5G移动平台。

Q5: 除了文中提到的Gemma和Qwen，我能运行自己的自定义模型吗？
A5: 可以。该技术栈的基础是支持标准的 .tflite 格式。你可以将自己的模型转换为该格式，并尝试通过LiteRT NeuroPilot工作流进行编译和部署。不过，模型能否在NPU上获得完全加速，取决于其使用的算子是否被NeuroPilot NPU硬件和软件栈所支持。对于最佳体验，建议参考官方已优化验证的模型架构。

关键要点总结

  1. 统一抽象层：LiteRT NeuroPilot Accelerator在Google LiteRT和MediaTek NeuroPilot之间建立了首要的、深度集成的连接，通过统一的CompiledModel API，为开发者屏蔽了NPU硬件碎片化的复杂性。
  2. 生产就绪的模型支持：技术栈聚焦于具体的开源模型，如Qwen3-0.6B、Gemma-3系列和EmbeddingGemma，为设备端文本生成、多模态理解和嵌入任务提供了经过验证的高性能解决方案。
  3. AOT编译是关键：对于设备端LLM的实用化部署，预先编译是不可或缺的环节。它能将用户侧的分钟级等待变为零，是生产环境部署的必选项。
  4. 性能飞跃：在Dimensity 9500级别的NPU上，复杂模型可实现超1600 tokens/s的预填充速度，相比CPU和GPU有数量级的提升，使得手机本地运行实时、多轮交互的AI助手成为可能。
  5. 现代化的开发者体验：新的C++/Kotlin API、对零拷贝内存传输的支持，以及自动回退机制，共同构成了一个强大且易于使用的开发环境，让开发者能够专注于应用逻辑本身，而非底层硬件适配。

通过LiteRT NeuroPilot Accelerator，Google和MediaTek正携手将设备端AI，特别是大型语言模型，从实验室和高端原型机，推向亿万普通用户的掌心。这不仅是芯片性能的展示，更是一次深刻的软件开发范式转变，它让利用手机专用AI硬件变得前所未有的简单和高效。

退出移动版