1. 为什么要在鸿蒙应用里接入开源大模型1.1 从一次真实需求说起去年底我接手了一个鸿蒙原生应用的外包项目客户是做企业知识管理的他们的核心诉求很直接员工在手机上就能对着内部文档提问答案要基于企业自己的资料库生成数据不能出内网。这个需求翻译成技术语言就是——在 HarmonyOS NEXT 应用里跑一个本地或半本地的大模型推理链路。一开始我想得很简单找个开源模型塞进去不就完了。真正动手才发现鸿蒙的生态和安卓、iOS 完全不是一回事。ArkTS 的运行机制、Native 层的调用方式、模型文件的存放路径、推理框架的编译工具链每一步都有坑。更麻烦的是网上关于 HarmonyOS NEXT 接入大模型的资料少得可怜大部分还停留在“鸿蒙AI”的概念层面真正能落地的工程细节几乎为零。这篇文章就是把我踩过的坑、做过的取舍、最后跑通的方案完整记录下来。如果你也在做鸿蒙应用开发并且有接入开源大模型的需求不管是做本地问答、文档摘要、还是智能助手这里面的工程决策思路应该能帮你少走不少弯路。1.2 先搞清楚鸿蒙上跑大模型到底难在哪很多人第一反应是“安卓能跑鸿蒙应该也能跑”。逻辑上没错但工程上完全是两码事。安卓那边有成熟的 NNAPI、有 TensorFlow Lite、有 MNN 和 NCNN 这些推理框架社区方案一抓一大把。鸿蒙这边呢HarmonyOS NEXT 已经彻底剥离了 AOSP你没法直接用安卓的那套 Native 库。ArkTS 虽然语法像 TypeScript但它的运行时是方舟编译器那套东西跟 Node.js 环境差别很大。具体来说在鸿蒙上接入开源大模型你会遇到这几个核心难题推理框架的适配主流的 llama.cpp、MNN、NCNN 都需要针对鸿蒙的 NDK 重新编译而且鸿蒙的 Native API 和安卓并不完全兼容。模型文件的部署大模型动辄几个 G怎么打包进 HAP、怎么在首次启动时释放到沙箱、怎么管理版本都是问题。算力调度鸿蒙设备有 NPU、GPU、CPU 三种算力但开放给第三方应用的接口有限你得决定用哪种、怎么用。内存管理手机内存本来就紧张加载一个 3B 参数的模型稍微不注意就 OOM 了。ArkTS 与 Native 的通信推理跑在 Native 层UI 在 ArkTS 层两边怎么高效传数据、怎么处理异步回调直接影响用户体验。这五个问题每一个都对应着至少一个工程决策。下面我就按实际项目的推进顺序把这五个决策一个一个拆开讲。2. 决策一推理框架选型——为什么我最终选了 MNN 而不是 llama.cpp2.1 候选方案对比在项目启动阶段我花了大概一周时间做技术选型。当时进入候选名单的有四个llama.cpp、MNN、NCNN、ONNX Runtime。框架优势鸿蒙适配难度社区活跃度模型格式支持llama.cpp生态最成熟GGUF 量化方案完善高需要自己写 CMake 工具链极高GGUF 为主MNN阿里出品移动端优化好有 NPU 支持中官方有部分鸿蒙适配高MNN、ONNXNCNN腾讯出品轻量中高文档偏少中NCNN、ONNXONNX Runtime通用性强高依赖较多高ONNX一开始我最想用的是 llama.cpp因为它的量化方案最成熟Q4_K_M 这种量化级别在效果和体积之间平衡得很好。但实际编译的时候发现llama.cpp 的构建系统对鸿蒙的 OHOS toolchain 支持很不友好光是解决 CMake 的交叉编译问题就花了两天而且编译出来的库在真机上跑还有各种符号缺失。后来转向 MNN发现它在移动端的优化确实到位。MNN 本身就是为了端侧推理设计的对 ARM 架构的支持很好而且它有一个MNN_NPU的选项可以尝试调用设备的 NPU 算力。虽然鸿蒙上的 NPU 接口还不完善但至少框架层面留了口子。2.2 最终选择 MNN 的三个理由第一个理由是编译工具链相对成熟。MNN 的 CMake 配置对 OHOS 的支持虽然不算完美但至少能跑通。你需要准备的是鸿蒙的 Native SDK然后在 CMake 里指定OHOS_STL和CMAKE_TOOLCHAIN_FILE基本能编译出 arm64-v8a 的动态库。第二个理由是内存占用可控。MNN 支持模型的分段加载和内存复用这对手机端特别重要。我实测下来一个 1.8B 参数的模型用 MNN 的 INT4 量化方案运行时内存占用能控制在 1.2G 左右而 llama.cpp 同样的模型要吃到 1.8G 以上。第三个理由是ArkTS 侧的调用封装更简单。MNN 提供了比较清晰的 C API你可以在 Native 层封装一层 C 接口然后用鸿蒙的 NAPI 机制暴露给 ArkTS。这个链路我后面会详细讲。注意如果你选的是 llama.cpp建议直接找社区里已经编译好的鸿蒙版本自己从零编译的时间成本太高。但要注意版本兼容性不同版本的 llama.cpp 对模型格式的要求不一样。2.3 一个容易被忽略的细节量化方案的选择选完框架之后紧接着要决定量化方案。MNN 支持 INT8、INT4 甚至 INT2 的量化但量化级别越低模型效果损失越大。我的经验是1B 到 3B 参数的模型用 INT4 量化比较合适。再低的话模型在中文理解任务上的表现会明显下降尤其是涉及多轮对话和上下文推理的场景。如果是 7B 以上的模型可以考虑 INT8但内存占用会大幅上升手机端基本扛不住。具体操作上你可以用 MNN 提供的mnnquant工具对 ONNX 模型进行量化。命令大概长这样./mnnquant --model input.onnx --output output.mnn --quant_bits 4 --quant_algorithm kl这里的--quant_algorithm kl指的是用 KL 散度做校准比默认的 min-max 校准效果更好但耗时会长一些。建议在 PC 上提前量化好直接把量化后的.mnn文件打包进应用。3. 决策二模型部署策略——打包进 HAP 还是首次启动下载3.1 两种方案的取舍模型文件怎么放到用户设备上这个问题看起来简单实际上涉及包体积、用户体验、合规要求等多个维度。方案 A直接打包进 HAP优点是用户装完就能用不需要联网下载。缺点是 HAP 包体积会暴涨。一个 INT4 量化的 1.8B 模型大概 1.2G加上应用本身的代码和资源整个包接近 1.5G。这在应用市场上架时会有麻烦而且用户下载安装的时间也很长。方案 B首次启动时从服务器下载优点是初始包体积小可以快速上架。缺点是首次使用需要等待下载而且如果模型文件放在公网服务器上会有带宽成本和合规风险。我最后采用的是混合方案应用包里只带一个极小的基础模型大概 200M 左右用于保证基本功能可用完整模型在首次启动时引导用户下载下载完成后释放到应用沙箱。3.2 模型文件在鸿蒙沙箱里的存放位置鸿蒙应用有自己的沙箱目录你不能随便往系统目录里写文件。模型文件应该放在context.filesDir下面这是应用私有的文件目录卸载应用时会被自动清理。在 ArkTS 里获取这个路径的代码是import common from ohos.app.ability.common; let context getContext(this) as common.UIAbilityContext; let filesDir context.filesDir; let modelPath filesDir /models/model.mnn;下载模型的时候建议用鸿蒙的request.downloadFile接口它支持断点续传和进度回调。下载完成后把临时文件移动到filesDir下面然后做一次完整性校验比如 MD5 比对确保文件没有损坏。3.3 模型版本管理的一个小技巧模型文件不是下载完就一劳永逸的。后续你可能需要更新模型版本这时候如果直接覆盖旧文件正在使用模型的推理线程可能会崩溃。我的做法是每次更新模型时下载到一个新的目录比如models/v2/然后在应用启动时读取一个model_config.json文件里面记录当前使用的模型版本和路径。切换版本时先让推理线程停止再更新配置文件最后重新初始化推理引擎。这样即使更新过程中出现问题也可以回滚到旧版本。4. 决策三算力调度——CPU、GPU、NPU 到底用哪个4.1 三种算力的实际表现鸿蒙设备上你的推理任务可以跑在 CPU、GPU 或 NPU 上。但开放给第三方应用的接口并不对等。CPU最通用任何设备都能用。MNN 在 CPU 上的优化做得不错支持多线程和 NEON 指令集。我实测在麒麟 9000S 上1.8B 模型 INT4 量化后推理速度大概在 8-12 tokens/s日常问答够用了。GPU鸿蒙对 GPU 的通用计算接口开放有限MNN 虽然支持 OpenCL但在鸿蒙上调用 GPU 需要额外的适配层。而且 GPU 推理的功耗比较高手机发热明显。NPU这是最理想的方案速度快、功耗低。但鸿蒙目前对第三方应用开放 NPU 的接口还很少基本只能通过华为自家的 HiAI Foundation 来调用而且对模型格式有严格要求。4.2 我的选择CPU 为主NPU 做可选加速考虑到项目周期和兼容性我最终选择了以 CPU 推理为主同时在代码里预留了 NPU 的调用接口。如果检测到设备支持 HiAI 且模型格式匹配就尝试走 NPU否则自动回退到 CPU。这个决策的逻辑是先保证功能可用再追求性能优化。CPU 推理虽然慢一点但胜在稳定、兼容性好。NPU 加速可以作为后续迭代的优化项而不是第一版的必须项。在 MNN 里配置 CPU 推理的代码大概是这样std::shared_ptrMNN::Interpreter interpreter; MNN::ScheduleConfig config; config.type MNN_FORWARD_CPU; config.numThread 4; config.backendConfig backendConfig;这里的numThread建议设置为 4这是我在多台设备上测试后的经验值。设得太高线程切换的开销会抵消并行计算的收益设得太低又跑不满 CPU 算力。4.3 一个关于线程调度的坑鸿蒙的 ArkTS 层和 Native 层是运行在不同线程上的。如果你在 Native 层开了一个推理线程然后直接在 ArkTS 层等待结果很容易造成 UI 卡顿。正确的做法是在 Native 层用异步回调的方式把推理结果传回 ArkTS 层。具体来说你可以在 Native 层创建一个napi_async_work把推理任务放到工作线程里执行执行完成后通过napi_resolve_deferred把结果返回给 ArkTS 的 Promise。这个链路我踩过坑一开始没做异步直接在 Native 同步调用结果每次推理 UI 都要卡两三秒。改成异步之后UI 流畅度明显提升用户可以在等待推理结果的同时继续操作界面。5. 决策四ArkTS 与 Native 的通信设计5.1 NAPI 接口的封装原则ArkTS 和 Native 之间的通信靠的是鸿蒙的 NAPI 机制。你可以把它理解成一座桥ArkTS 这边调用一个方法NAPI 层把请求转发给 C 代码C 处理完再把结果传回来。封装 NAPI 接口的时候我遵循了三个原则第一接口粒度要粗。不要为每个小功能都暴露一个 NAPI 方法那样 ArkTS 和 Native 之间的切换开销会很大。最好是暴露几个高层接口比如initModel、chat、releaseModel每个接口内部完成一系列操作。第二数据格式要统一。ArkTS 和 C 之间的数据传递建议统一用 JSON 字符串。ArkTS 这边把请求参数序列化成 JSONC 这边解析 JSON 拿到参数处理完再把结果序列化成 JSON 返回。这样虽然有一点序列化开销但接口清晰不容易出错。第三错误处理要完善。Native 层的错误不能直接抛到 ArkTS 层否则会导致应用崩溃。正确的做法是在 Native 层捕获所有异常把错误信息封装成错误码和错误描述通过 NAPI 返回给 ArkTS由 ArkTS 层决定怎么展示。5.2 一个完整的 NAPI 调用示例假设我们要暴露一个chat方法ArkTS 这边这样调用import nativeModel from libmodel.so; async function chatWithModel(question: string): Promisestring { try { let result await nativeModel.chat(question); return result; } catch (error) { console.error(推理失败:, error); return 抱歉暂时无法回答这个问题。; } }Native 这边的 NAPI 封装大概是static napi_value Chat(napi_env env, napi_callback_info info) { size_t argc 1; napi_value args[1]; napi_get_cb_info(env, info, argc, args, nullptr, nullptr); // 获取 ArkTS 传入的字符串 size_t strSize; napi_get_value_string_utf8(env, args[0], nullptr, 0, strSize); char* input new char[strSize 1]; napi_get_value_string_utf8(env, args[0], input, strSize 1, strSize); // 创建 Promise napi_deferred deferred; napi_value promise; napi_create_promise(env, deferred, promise); // 把推理任务放到异步工作线程 AsyncWorkData* data new AsyncWorkData(); > 鸿蒙应用接入开源大模型：MNN推理框架与NAPI通信实战
1. 为什么要在鸿蒙应用里接入开源大模型1.1 从一次真实需求说起去年底我接手了一个鸿蒙原生应用的外包项目客户是做企业知识管理的他们的核心诉求很直接员工在手机上就能对着内部文档提问答案要基于企业自己的资料库生成数据不能出内网。这个需求翻译成技术语言就是——在 HarmonyOS NEXT 应用里跑一个本地或半本地的大模型推理链路。一开始我想得很简单找个开源模型塞进去不就完了。真正动手才发现鸿蒙的生态和安卓、iOS 完全不是一回事。ArkTS 的运行机制、Native 层的调用方式、模型文件的存放路径、推理框架的编译工具链每一步都有坑。更麻烦的是网上关于 HarmonyOS NEXT 接入大模型的资料少得可怜大部分还停留在“鸿蒙AI”的概念层面真正能落地的工程细节几乎为零。这篇文章就是把我踩过的坑、做过的取舍、最后跑通的方案完整记录下来。如果你也在做鸿蒙应用开发并且有接入开源大模型的需求不管是做本地问答、文档摘要、还是智能助手这里面的工程决策思路应该能帮你少走不少弯路。1.2 先搞清楚鸿蒙上跑大模型到底难在哪很多人第一反应是“安卓能跑鸿蒙应该也能跑”。逻辑上没错但工程上完全是两码事。安卓那边有成熟的 NNAPI、有 TensorFlow Lite、有 MNN 和 NCNN 这些推理框架社区方案一抓一大把。鸿蒙这边呢HarmonyOS NEXT 已经彻底剥离了 AOSP你没法直接用安卓的那套 Native 库。ArkTS 虽然语法像 TypeScript但它的运行时是方舟编译器那套东西跟 Node.js 环境差别很大。具体来说在鸿蒙上接入开源大模型你会遇到这几个核心难题推理框架的适配主流的 llama.cpp、MNN、NCNN 都需要针对鸿蒙的 NDK 重新编译而且鸿蒙的 Native API 和安卓并不完全兼容。模型文件的部署大模型动辄几个 G怎么打包进 HAP、怎么在首次启动时释放到沙箱、怎么管理版本都是问题。算力调度鸿蒙设备有 NPU、GPU、CPU 三种算力但开放给第三方应用的接口有限你得决定用哪种、怎么用。内存管理手机内存本来就紧张加载一个 3B 参数的模型稍微不注意就 OOM 了。ArkTS 与 Native 的通信推理跑在 Native 层UI 在 ArkTS 层两边怎么高效传数据、怎么处理异步回调直接影响用户体验。这五个问题每一个都对应着至少一个工程决策。下面我就按实际项目的推进顺序把这五个决策一个一个拆开讲。2. 决策一推理框架选型——为什么我最终选了 MNN 而不是 llama.cpp2.1 候选方案对比在项目启动阶段我花了大概一周时间做技术选型。当时进入候选名单的有四个llama.cpp、MNN、NCNN、ONNX Runtime。框架优势鸿蒙适配难度社区活跃度模型格式支持llama.cpp生态最成熟GGUF 量化方案完善高需要自己写 CMake 工具链极高GGUF 为主MNN阿里出品移动端优化好有 NPU 支持中官方有部分鸿蒙适配高MNN、ONNXNCNN腾讯出品轻量中高文档偏少中NCNN、ONNXONNX Runtime通用性强高依赖较多高ONNX一开始我最想用的是 llama.cpp因为它的量化方案最成熟Q4_K_M 这种量化级别在效果和体积之间平衡得很好。但实际编译的时候发现llama.cpp 的构建系统对鸿蒙的 OHOS toolchain 支持很不友好光是解决 CMake 的交叉编译问题就花了两天而且编译出来的库在真机上跑还有各种符号缺失。后来转向 MNN发现它在移动端的优化确实到位。MNN 本身就是为了端侧推理设计的对 ARM 架构的支持很好而且它有一个MNN_NPU的选项可以尝试调用设备的 NPU 算力。虽然鸿蒙上的 NPU 接口还不完善但至少框架层面留了口子。2.2 最终选择 MNN 的三个理由第一个理由是编译工具链相对成熟。MNN 的 CMake 配置对 OHOS 的支持虽然不算完美但至少能跑通。你需要准备的是鸿蒙的 Native SDK然后在 CMake 里指定OHOS_STL和CMAKE_TOOLCHAIN_FILE基本能编译出 arm64-v8a 的动态库。第二个理由是内存占用可控。MNN 支持模型的分段加载和内存复用这对手机端特别重要。我实测下来一个 1.8B 参数的模型用 MNN 的 INT4 量化方案运行时内存占用能控制在 1.2G 左右而 llama.cpp 同样的模型要吃到 1.8G 以上。第三个理由是ArkTS 侧的调用封装更简单。MNN 提供了比较清晰的 C API你可以在 Native 层封装一层 C 接口然后用鸿蒙的 NAPI 机制暴露给 ArkTS。这个链路我后面会详细讲。注意如果你选的是 llama.cpp建议直接找社区里已经编译好的鸿蒙版本自己从零编译的时间成本太高。但要注意版本兼容性不同版本的 llama.cpp 对模型格式的要求不一样。2.3 一个容易被忽略的细节量化方案的选择选完框架之后紧接着要决定量化方案。MNN 支持 INT8、INT4 甚至 INT2 的量化但量化级别越低模型效果损失越大。我的经验是1B 到 3B 参数的模型用 INT4 量化比较合适。再低的话模型在中文理解任务上的表现会明显下降尤其是涉及多轮对话和上下文推理的场景。如果是 7B 以上的模型可以考虑 INT8但内存占用会大幅上升手机端基本扛不住。具体操作上你可以用 MNN 提供的mnnquant工具对 ONNX 模型进行量化。命令大概长这样./mnnquant --model input.onnx --output output.mnn --quant_bits 4 --quant_algorithm kl这里的--quant_algorithm kl指的是用 KL 散度做校准比默认的 min-max 校准效果更好但耗时会长一些。建议在 PC 上提前量化好直接把量化后的.mnn文件打包进应用。3. 决策二模型部署策略——打包进 HAP 还是首次启动下载3.1 两种方案的取舍模型文件怎么放到用户设备上这个问题看起来简单实际上涉及包体积、用户体验、合规要求等多个维度。方案 A直接打包进 HAP优点是用户装完就能用不需要联网下载。缺点是 HAP 包体积会暴涨。一个 INT4 量化的 1.8B 模型大概 1.2G加上应用本身的代码和资源整个包接近 1.5G。这在应用市场上架时会有麻烦而且用户下载安装的时间也很长。方案 B首次启动时从服务器下载优点是初始包体积小可以快速上架。缺点是首次使用需要等待下载而且如果模型文件放在公网服务器上会有带宽成本和合规风险。我最后采用的是混合方案应用包里只带一个极小的基础模型大概 200M 左右用于保证基本功能可用完整模型在首次启动时引导用户下载下载完成后释放到应用沙箱。3.2 模型文件在鸿蒙沙箱里的存放位置鸿蒙应用有自己的沙箱目录你不能随便往系统目录里写文件。模型文件应该放在context.filesDir下面这是应用私有的文件目录卸载应用时会被自动清理。在 ArkTS 里获取这个路径的代码是import common from ohos.app.ability.common; let context getContext(this) as common.UIAbilityContext; let filesDir context.filesDir; let modelPath filesDir /models/model.mnn;下载模型的时候建议用鸿蒙的request.downloadFile接口它支持断点续传和进度回调。下载完成后把临时文件移动到filesDir下面然后做一次完整性校验比如 MD5 比对确保文件没有损坏。3.3 模型版本管理的一个小技巧模型文件不是下载完就一劳永逸的。后续你可能需要更新模型版本这时候如果直接覆盖旧文件正在使用模型的推理线程可能会崩溃。我的做法是每次更新模型时下载到一个新的目录比如models/v2/然后在应用启动时读取一个model_config.json文件里面记录当前使用的模型版本和路径。切换版本时先让推理线程停止再更新配置文件最后重新初始化推理引擎。这样即使更新过程中出现问题也可以回滚到旧版本。4. 决策三算力调度——CPU、GPU、NPU 到底用哪个4.1 三种算力的实际表现鸿蒙设备上你的推理任务可以跑在 CPU、GPU 或 NPU 上。但开放给第三方应用的接口并不对等。CPU最通用任何设备都能用。MNN 在 CPU 上的优化做得不错支持多线程和 NEON 指令集。我实测在麒麟 9000S 上1.8B 模型 INT4 量化后推理速度大概在 8-12 tokens/s日常问答够用了。GPU鸿蒙对 GPU 的通用计算接口开放有限MNN 虽然支持 OpenCL但在鸿蒙上调用 GPU 需要额外的适配层。而且 GPU 推理的功耗比较高手机发热明显。NPU这是最理想的方案速度快、功耗低。但鸿蒙目前对第三方应用开放 NPU 的接口还很少基本只能通过华为自家的 HiAI Foundation 来调用而且对模型格式有严格要求。4.2 我的选择CPU 为主NPU 做可选加速考虑到项目周期和兼容性我最终选择了以 CPU 推理为主同时在代码里预留了 NPU 的调用接口。如果检测到设备支持 HiAI 且模型格式匹配就尝试走 NPU否则自动回退到 CPU。这个决策的逻辑是先保证功能可用再追求性能优化。CPU 推理虽然慢一点但胜在稳定、兼容性好。NPU 加速可以作为后续迭代的优化项而不是第一版的必须项。在 MNN 里配置 CPU 推理的代码大概是这样std::shared_ptrMNN::Interpreter interpreter; MNN::ScheduleConfig config; config.type MNN_FORWARD_CPU; config.numThread 4; config.backendConfig backendConfig;这里的numThread建议设置为 4这是我在多台设备上测试后的经验值。设得太高线程切换的开销会抵消并行计算的收益设得太低又跑不满 CPU 算力。4.3 一个关于线程调度的坑鸿蒙的 ArkTS 层和 Native 层是运行在不同线程上的。如果你在 Native 层开了一个推理线程然后直接在 ArkTS 层等待结果很容易造成 UI 卡顿。正确的做法是在 Native 层用异步回调的方式把推理结果传回 ArkTS 层。具体来说你可以在 Native 层创建一个napi_async_work把推理任务放到工作线程里执行执行完成后通过napi_resolve_deferred把结果返回给 ArkTS 的 Promise。这个链路我踩过坑一开始没做异步直接在 Native 同步调用结果每次推理 UI 都要卡两三秒。改成异步之后UI 流畅度明显提升用户可以在等待推理结果的同时继续操作界面。5. 决策四ArkTS 与 Native 的通信设计5.1 NAPI 接口的封装原则ArkTS 和 Native 之间的通信靠的是鸿蒙的 NAPI 机制。你可以把它理解成一座桥ArkTS 这边调用一个方法NAPI 层把请求转发给 C 代码C 处理完再把结果传回来。封装 NAPI 接口的时候我遵循了三个原则第一接口粒度要粗。不要为每个小功能都暴露一个 NAPI 方法那样 ArkTS 和 Native 之间的切换开销会很大。最好是暴露几个高层接口比如initModel、chat、releaseModel每个接口内部完成一系列操作。第二数据格式要统一。ArkTS 和 C 之间的数据传递建议统一用 JSON 字符串。ArkTS 这边把请求参数序列化成 JSONC 这边解析 JSON 拿到参数处理完再把结果序列化成 JSON 返回。这样虽然有一点序列化开销但接口清晰不容易出错。第三错误处理要完善。Native 层的错误不能直接抛到 ArkTS 层否则会导致应用崩溃。正确的做法是在 Native 层捕获所有异常把错误信息封装成错误码和错误描述通过 NAPI 返回给 ArkTS由 ArkTS 层决定怎么展示。5.2 一个完整的 NAPI 调用示例假设我们要暴露一个chat方法ArkTS 这边这样调用import nativeModel from libmodel.so; async function chatWithModel(question: string): Promisestring { try { let result await nativeModel.chat(question); return result; } catch (error) { console.error(推理失败:, error); return 抱歉暂时无法回答这个问题。; } }Native 这边的 NAPI 封装大概是static napi_value Chat(napi_env env, napi_callback_info info) { size_t argc 1; napi_value args[1]; napi_get_cb_info(env, info, argc, args, nullptr, nullptr); // 获取 ArkTS 传入的字符串 size_t strSize; napi_get_value_string_utf8(env, args[0], nullptr, 0, strSize); char* input new char[strSize 1]; napi_get_value_string_utf8(env, args[0], input, strSize 1, strSize); // 创建 Promise napi_deferred deferred; napi_value promise; napi_create_promise(env, deferred, promise); // 把推理任务放到异步工作线程 AsyncWorkData* data new AsyncWorkData(); >