MNN端侧部署 on huluhuluu

LLM QNN 插件推理流程

Thu, 04 Jun 2026 12:00:00 +0800

LLM QNN 插件推理流程

LLM QNN 插件推理流程

本篇梳理移动设备侧运行 QNN 后端主图 qnn/llm.mnn 时的代码路径。离线编译阶段会把部分子图编译成 QNN 后端使用的 qnn/*.bin 二进制文件，并把主图改写成调用插件算子 OpType_Plugin(type="QNN") 的形式。推理时，核心调用链路如下：

[LLM 生成层]
llm->response()
└── generate(input_ids)
    ├── embedding()
    └── forwardVec()
        └── forwardRaw()
            │
            ▼
[MNN Express Module 层]
Module::onForward()
├── [阶段 1: resize / 形状推导]
│   └── StaticModule::_resize()
│       └── ShapePlugin
│           └── PluginShapeRaw::compute()
│               └── 根据 allInputShape 选择 shapeIndex，并读取 o_<shapeIndex>_* 输出描述
│
└── [阶段 2: execute / 真正执行]
    └── StaticModule::_execute()
        └── CPUPlugin::onExecute()
            └── PluginExecuteRaw::compute()
                └── RawExecutorWrapper::invokModel()
                    └── QNN graphExecute()

1. `config_qnn.json` 配置

QNN 模型运行时一般使用 config_qnn.json 配置文件：

{
  "llm_model": "qnn/llm.mnn",
  "backend_type": "cpu",
  "chunk_limits": [128, 1]
}

LlmConfig::llm_model() 会把 llm_model 拼到模型目录下：

// transformers/llm/engine/src/llmconfig.hpp:279
std::string llm_model() const {
    return base_dir_ + config_.value("llm_model", "llm.mnn");
}

所以，最终加载主图路径就是 <model_dir>/qnn/llm.mnn，也就是 Llm::load() 里会用这个路径加载 Module：

// transformers/llm/engine/src/llm.cpp:280
std::string model_path = mConfig->llm_model();
...
mRuntimeManager->setExternalFile(mConfig->llm_weight());
mModule.reset(Module::load(inputNames, outputNames, model_path.c_str(), mRuntimeManager, &module_config));
mRuntimeManager->setExternalFile("");

这里加载的 qnn/llm.mnn 是一个带 QNN 插件算子的主图。同时，Llm::setRuntimeHint() 会设置 NPU 文件目录：

1
2

// transformers/llm/engine/src/llm.cpp:153
rtg->setExternalPath(mConfig->npu_model_dir(), MNN::Interpreter::EXTERNAL_NPU_FILE_DIR);

npu_model_dir() 默认返回模型的根目录：

// transformers/llm/engine/src/llmconfig.hpp:311
std::string npu_model_dir() const {
    return base_dir_ + config_.value("npu_model_dir", "");
}

这个路径会先写入 RuntimeManager 中：

// transformers/llm/engine/src/llm.cpp:153
rtg->setExternalPath(mConfig->npu_model_dir(), MNN::Interpreter::EXTERNAL_NPU_FILE_DIR);

// express/Executor.cpp:242
void Executor::RuntimeManager::setExternalPath(std::string path, int type) {
    if (type == MNN::Interpreter::EXTERNAL_NPU_FILE_DIR) {
        mInside->mContent->mNpuDir = path;
        return;
    }
    mInside->mContent->modes.setExternalPath(path, type);
}

后面 StaticModule 构造时会把它写到 CPU 后端的 pNPUModelDirPath：

1
2
3

// express/module/StaticModule.cpp:340
bnCache.cache.first->pNPUModelDirPath = rtm->getInside()->mContent->mNpuDir;
bnCache.cache.second->pNPUModelDirPath = rtm->getInside()->mContent->mNpuDir;

并在 QNN 插件读取 path 属性时，使用该目录拼出完整 .bin 路径，例如：

`1`	`<model_dir>/qnn/graph0.bin`

2. LLM 生成链路

文本输入最常见的入口是：

`1`	`llm->response(prompt);`

对应源码里，response(string) 会先按配置套 chat template，再使用 tokenizer 分词为 token id，最后转到 response(input_ids) 方法：

// transformers/llm/engine/src/llm.cpp:912
void Llm::response(const std::string& user_content, std::ostream* os, const char* end_with, int max_new_tokens) {
    auto prompt = user_content;
    if (mConfig->use_template()) {
        prompt = mPrompt->applyTemplate(user_content, true);
    }
    std::vector<int> input_ids = tokenizer_encode(prompt);
    response(input_ids, os, end_with, max_new_tokens);
}

在 response(input_ids) 方法中，会初始化一些记录的数据，随后继续走 generate(input_ids) 接口生成输出：

// transformers/llm/engine/src/llm.cpp:900
void Llm::response(const std::vector<int>& input_ids, std::ostream* os, const char* end_with, int max_new_tokens) {
    if (!end_with) { end_with = "\n"; }
    generate_init(os, end_with);
    generate(input_ids, max_new_tokens);
}

在 generate(input_ids) 里会根据 prompt 长度决定是一次 embedding，还是按 mBlockSize 分块：

// transformers/llm/engine/src/llm.cpp:786
mContext->history_tokens.insert(mContext->history_tokens.end(), input_ids.begin(), input_ids.end());
if(!passExecute) {
    if (0 == mBlockSize || input_ids.size() <= mBlockSize) {
        auto hidden_states = embedding(input_ids);
        return generate(hidden_states, max_tokens);
    }
    int total_size = (int)input_ids.size();
    int loop_size = UP_DIV(total_size, mBlockSize);
    for (int i = 0; i < loop_size; i++) {
        ...
        auto input_embeds = embedding(chunk_ids);
        generate(input_embeds, 0);
    }
}
generate(max_tokens);

3. `prefill` / `decode` 形状

Llm::set_config() 读取 chunk_limits 后，会排序并把最大值作为 mBlockSize，代码块如下：

// transformers/llm/engine/src/llm.cpp:104
if (mConfig->config_.document.HasMember("chunk_limits")) {
    auto& size_limit = mConfig->config_.document["chunk_limits"];
    ...
    for (auto iter = size_limit.GetArray().begin(); iter != size_limit.GetArray().end(); iter++) {
        mValidBlockSize.emplace_back(iter->GetInt());
    }
    ...
    std::sort(mValidBlockSize.begin(), mValidBlockSize.end());
    mBlockSize = mValidBlockSize[mValidBlockSize.size()-1];
}

以 chunk_limits: [128, 1] 为例，内部结果是：

1
2

mValidBlockSize = [1, 128]
mBlockSize = 128

这和离线导出阶段的两组形状对上：

阶段	`seq len`	作用
`prefill`	`128`	`prompt` 分块或 `pad` 后的大块前向
`decode`	`1`	自回归单 `token` 前向

forwardVec(input_embeds) 会按 mBlockSize 拆分长 prompt：

// transformers/llm/engine/src/llm.cpp:572
std::vector<VARP> Llm::forwardVec(MNN::Express::VARP input_embeds) {
    int seq_len = input_embeds->getInfo()->dim[mSeqLenIndex];
    if (0 == mBlockSize) {
        mMeta->add = seq_len;
        auto attention_mask = gen_attention_mask(seq_len);
        auto position_ids = gen_position_ids(seq_len);
        auto res = forwardRaw(input_embeds, attention_mask, position_ids);
        return res;
    }
    auto blockNumber = seq_len / mBlockSize;
    auto blockRemain = seq_len % mBlockSize;

整块部分直接按 mBlockSize 调 forwardRaw()：

// transformers/llm/engine/src/llm.cpp:604
for (int i=0; i<blockNumber; ++i) {
    logits.clear();
    mMeta->add = blockSize;
    auto embed = embeddings[i];
    auto attention_mask = gen_attention_mask(blockSize);
    auto position_ids = gen_position_ids(blockSize);
    logits = forwardRaw(embed, attention_mask, position_ids);
    ...
    updateContext(blockSize, 0);
}

剩余长度如果不是合法形状，会 pad 到 mValidBlockSize 中最近的合法大小：

// transformers/llm/engine/src/llm.cpp:623
if (!mValidBlockSize.empty()) {
    forwardSize = mValidBlockSize[mValidBlockSize.size()-1];
    for (int j=mValidBlockSize.size()-2; j>=0; --j) {
        if (mValidBlockSize[j] < blockRemain) {
            break;
        }
        forwardSize = mValidBlockSize[j];
    }
    if (blockRemain < forwardSize) {
        hasPad = true;
        auto dim = input_embeds->getInfo()->dim;
        dim[mSeqLenIndex] = forwardSize;
        auto newEmbed = _Input(dim, NCHW);
        ::memcpy(newEmbed->writeMap<void>(), input_embeds->readMap<void>(), input_embeds->getInfo()->size * sizeof(float));
        ::memset(newEmbed->writeMap<float>() + input_embeds->getInfo()->size, 0, (newEmbed->getInfo()->size - input_embeds->getInfo()->size) * sizeof(float));
        input_embeds = newEmbed;
    }
}

比如剩余 prompt 长度是 80，会 pad 到 128；decode 阶段长度是 1，直接匹配 1。

这个形状需要匹配离线导出时 compilefornpu 写入插件属性的 allInputShape。

4. 算子前向

forwardRaw() 构造主模型输入：

// transformers/llm/engine/src/llm.cpp:448
std::vector<Express::VARP> Llm::forwardRaw(Express::VARP hiddenState, Express::VARP mask, Express::VARP inputPos, Express::VARPS extraArgs) {
    Express::VARP logitsIndex;
    bool inDecode = mContext->gen_seq_len > 0;
    bool isAllLogists = mConfig->all_logits() ? true : (inDecode ? mInSpec : false);
    auto seqLen = hiddenState->getInfo()->dim[mSeqLenIndex];
    int seqLenKey = inDecode ? hiddenState->getInfo()->dim[mSeqLenIndex] : mPrefillKey;
    ...
std::vector<Express::VARP> inputs {
    hiddenState,
    mask,
    inputPos,
    logitsIndex
};

然后选择 Module 模块：

// transformers/llm/engine/src/llm.cpp:480
std::vector<Express::VARP> inputs {hiddenState, mask, inputPos, logitsIndex};
inputs.insert(inputs.end(), extraArgs.begin(), extraArgs.end());
std::vector<Express::VARP> outputs = selectModule->onForward(inputs);

这里的 selectModule 通常有两种：

prefill 走主 mModule；
decode 会按 (seqLenKey, isAllLogits) 从 mModulePool 里取 clone 出来的模块。

对应代码里，默认先使用 mModule，在没有 mValidBlockSize 的路径下会按输入长度等 key 复制模块：

// transformers/llm/engine/src/llm.cpp:455
auto moduleKey = std::make_pair(seqLenKey, isAllLogists);
std::shared_ptr<Module> selectModule = mModule;
if (mValidBlockSize.empty()) {
    if(mModulePool.find(moduleKey) == mModulePool.end()) {
        MNN_PRINT("Warning: module need new clone, cloning now.\n");
        mRuntimeManager->setHintPtr(Interpreter::KVCACHE_INFO, mMeta.get());
        mModulePool[moduleKey].reset(Module::clone(mModule.get()));
    }
    selectModule = mModulePool[moduleKey];
}

进入 Module::onForward() 后，实际对象通常是 StaticModule。StaticModule::onForward() 的核心顺序是：

// express/module/StaticModule.cpp:566
std::vector<Express::VARP> StaticModule::onForward(const std::vector<Express::VARP>& inputs) {
    ...
    Variable::compute(inputs);
    ...
    if (runResize) {
        code = _resize(inputs);
    }
    if (NO_ERROR == code && runCompute) {
        code = _execute();
    }

_resize() 会把输入 VARP 绑定到 Session 输入张量，并触发 mSession->resize()，从而向下执行 Pipeline::encode() 和 Pipeline::allocMemory()，完成创建算子 Execution 类的准备。对于 QNN 图来说，这里是在准备 OpType_Plugin 算子：

// express/module/StaticModule.cpp:521
for (int i = 0; i < inputs.size(); ++i) {
    ...
    if (_resizeTensor(mInputTensors[i], inputTensor, mSession.get(), nullptr)) {
        mSession->setNeedResize();
    }
}
mSession->getInfo(Interpreter::RESIZE_STATUS, &curStatus);
code = mSession->resize();

最终 _execute() 会调用 Session 的 run() 方法，执行流水线中的算子。这里使用 QNN 图时，对应的是 OpType_Plugin 算子的执行：

// express/module/StaticModule.cpp:550
ErrorCode StaticModule::_execute() {
    ErrorCode code;
    if (mResource->mModes.callBackMode == Interpreter::Session_Debug) {
        ...
        code = mSession->runWithCallBack(debug->before, debug->after);
    } else {
        code = mSession->run();
    }
    return code;
}

所以 QNN 插件会经历两个不同阶段：

resize 阶段：走 ShapePlugin -> PluginShapeRaw::compute()，确定输出形状；
execute 阶段：走 CPUPlugin::onExecute() -> PluginExecuteRaw::compute()，真正调用 QNN 计算图。

5. `resize` 阶段

上一节已经走到 StaticModule::_resize()：

StaticModule::onForward()
└── _resize(inputs)
    └── mSession->resize()
        └── Pipeline::encode()
            ├── ShapePlugin / PluginShapeRaw::compute()
            └── CPUPluginCreator -> CPUPlugin -> PluginExecuteRaw::init()

这里要分清两件事：

ShapePlugin 负责输出形状推导；
CPUPluginCreator 负责创建真正参与后续 execute 的 Execution。

这两件事都发生在 resize 这条链路上，所以第 5 节先看形状推导，再看 QNN 内核的注册和创建。

5.1 `ShapePlugin`

通用插件形状入口在 source/shape/ShapePlugin.cpp。它会从 Plugin 参数里读出 type，再用这个 type 找到对应的形状推导内核：

// source/shape/ShapePlugin.cpp:35
const Plugin* plugin_param = op->main_as<Plugin>();
std::shared_ptr<plugin::InferShapeKernel> kernel =
    getInferShapeKernel(plugin_param->type()->str());
...
plugin::InferShapeContext ctx(inputs, outputs);
for (const Attribute* attr : *(plugin_param->attr())) {
    ctx.setAttr(attr->key()->str(), attr);
}
bool status = kernel->compute(&ctx);

QNN 插件的 type 是 "QNN"。这个 type 对应的形状推导内核和计算内核都在 QNNBackend.cpp 里注册：

// source/backend/qnn/backend/QNNBackend.cpp:1837
#ifdef MNN_WITH_PLUGIN
plugin::InferShapeKernelRegister::add("QNN", []() {
    return new plugin::shape_inference::PluginShapeRaw;
});
plugin::ComputeKernelRegistry<plugin::backend::PluginExecuteRaw::KernelT>::add("QNN", []() {
    return new plugin::backend::PluginExecuteRaw;
});
#endif

这里注册了两条不同阶段的入口：

注册项	阶段	作用
`InferShapeKernelRegister::add("QNN", ...)`	`resize` / 形状推导	用 `allInputShape` 匹配当前输入形状，并写出输出形状
`ComputeKernelRegistry::add("QNN", ...)`	`resize` / `execute`	创建 `PluginExecuteRaw`，后面加载 `QNN` 上下文二进制并执行计算图

QNN 注册的 InferShapeKernelRegister 是 PluginShapeRaw::compute()，它会先调用 computeIndex()。这一步的输入是当前插件算子的输入张量形状：

// source/backend/qnn/backend/QNNBackend.cpp:361
static bool computeIndex(PluginContext* ctx, int & index) {
    const std::vector<Tensor *> & inputs = ctx->inputs();
    auto attrAllShape = ctx->getAttr("allInputShape");
    if (nullptr == attrAllShape || nullptr == attrAllShape->list() || nullptr == attrAllShape->list()->i()) {
        MNN_ERROR("MNN_QNN: Incorrect Plugin Op, can't find 'allInputShape' attr.\n");
        return false;
    }
    int dimSum = 0;
    for (int i = 0; i < inputs.size(); i++) {
        auto inputDim = inputs[i]->dimensions();
        dimSum += inputDim;
    }
    ...
}

随后与离线 compilefornpu 写进插件属性的多组合法输入 allInputShape 对比，找到匹配当前输入形状的 shapeIndex：

// source/backend/qnn/backend/QNNBackend.cpp:378
auto indexNumber = attrAllShape->list()->i()->size() / dimSum;
for (int si=0; si<indexNumber; ++si) {
    auto dstSi = attrAllShape->list()->i()->data() + si * dimSum;
    bool valid = true;
    for (int i=0; i<inputs.size(); ++i) {
        auto inputDim = inputs[i]->dimensions();
        for (int j = 0; j < inputDim; j++) {
            if (inputs[i]->length(j) != dstSi[j]) {
                valid = false;
                break;
            }
        }
        dstSi += inputDim;
        if (!valid) {
            break;
        }
    }
    if (valid) {
        index = si;
        return true;
    }
}

匹配成功后得到的 shapeIndex 是后面 QNN 路径的关键索引：

shapeIndex
├── resize 阶段: 读取 o_<shapeIndex>_<outputIndex> 写输出形状
├── PluginExecuteRaw::resize(): 记录 mShapeIndex
└── execute 阶段: 选择 mQnnGraphHandleVec[mShapeIndex]

因此，运行时输入形状必须能在 allInputShape 里找到，否则 QNN 插件的形状推导会失败。

当匹配到 shapeIndex 后，PluginShapeRaw::compute() 会读取 o_<shapeIndex>_<outputIndex>，把离线记录的输出类型、形状和格式写回当前输出张量：

// source/backend/qnn/backend/QNNBackend.cpp:403
bool PluginShapeRaw::compute(InferShapeContext* ctx) {
    ...
    int shapeIndex = 0;
    if (!(computeIndex(ctx, shapeIndex))) {
        MNN_ERROR("MNN_QNN: Failed to compute shape for Plugin Op.\n");
        return false;
    }

    std::string prefix = "o_" + std::to_string(shapeIndex) + "_";
    for (int i=0; i<ctx->outputs().size(); ++i) {
        auto dst = ctx->output(i);
        std::string key = prefix + std::to_string(i);
        auto attr = ctx->getAttr(key.c_str());
        ...
        auto blob = attr->tensor();
        dst->setType(blob->dataType());
        if (nullptr != blob->dims()) {
            dst->buffer().dimensions = blob->dims()->size();
            for (int j=0; j<blob->dims()->size(); ++j) {
                dst->setLength(j, blob->dims()->data()[j]);
            }
        } else {
            dst->buffer().dimensions = 0;
        }
        TensorUtils::getDescribe(dst)->dimensionFormat = blob->dataFormat();
    }
    return true;
}

5.2 创建 `QNN` 算子

形状推导完成后，Pipeline::encode() 还会为每个算子创建后端 Execution。这里不是直接手写调用 new CPUPlugin(...)，而是走 MNN 后端的通用算子创建路径：

Pipeline::encode()
└── OpCommonUtils::createExecutionWithExternal(...)
    └── backend->onCreate(inputs, outputs, op)
        └── CPUBackend::onCreate(...)
            └── gCreator[OpType_Plugin]->onCreate(...)
                └── CPUPluginCreator::onCreate(...)
                    └── new CPUPlugin(ctx)
                        └── getCPUComputeKernel("QNN")
                            └── ComputeKernelRegistry<CPUComputeKernel>::get("QNN")
                                └── new PluginExecuteRaw

在 Pipeline::encode() 里，当前 command 还没有 Execution 时，会调用 createExecutionWithExternal(...)：

// source/core/Pipeline.cpp:563
std::shared_ptr<BufferStorage> tmpStorage;
if (nullptr == iter.execution) {
    iter.execution.reset(OpCommonUtils::createExecutionWithExternal(
        mBackend.get(), iter.inputs, iter.outputs, iter.op, &loader, tmpStorage));
}

OpCommonUtils::createExecutionWithExternal(...) 对没有外部权重重建需求的算子，会直接转到后端的 onCreate(...)：

// source/core/OpCommonUtils.cpp:664
Execution* OpCommonUtils::createExecutionWithExternal(
    Backend* backend,
    const std::vector<Tensor*>& inputs,
    const std::vector<Tensor*>& outputs,
    const MNN::Op* op,
    FileLoader* externalFile,
    std::shared_ptr<BufferStorage>& tmpstore) {
    ...
    if (!hasExternal) {
        return backend->onCreate(inputs, outputs, op);
    }

当前模型运行在 CPU 后端上，所以这里进入 CPUBackend::onCreate(...)。它用 op->type() 去 gCreator 表里找创建器：

// source/backend/cpu/CPUBackend.cpp:720
Execution* CPUBackend::onCreate(const std::vector<Tensor*>& inputs, const std::vector<Tensor*>& outputs,
                                const MNN::Op* op) {
    ...
    auto opType = op->type();
    ...
    auto map  = gCreator;
    auto iter = map->find(opType);
    if (iter == map->end() ) {
        MNN_PRINT("Don't support type [%s]\n", MNN::EnumNameOpType(op->type()));
        return nullptr;
    }
    Execution* exe = nullptr;
    if (exe == nullptr) {
        exe = iter->second->onCreate(inputs, outputs, op, this);
    }
    return exe;
}

OpType_Plugin 对应的创建器在 CPUPlugin.cpp 文件尾部注册：

1
2

// source/backend/cpu/CPUPlugin.cpp:98
REGISTER_CPU_OP_CREATOR(CPUPluginCreator, OpType_Plugin);

这个宏展开后的核心动作是把 CPUPluginCreator 放进 CPUBackend::gCreator：

// source/backend/cpu/CPUBackend.hpp:218
#define REGISTER_CPU_OP_CREATOR(name, opType)     \
    void ___##name##__##opType##__() {            \
        static name _temp;\
        CPUBackend::addCreator(opType, &_temp); \
    }

所以对于 OpType_Plugin(type="QNN")，最终会调用 CPU 后端里的 CPUPluginCreator::onCreate(...)：

// source/backend/cpu/CPUPlugin.cpp:70
class CPUPluginCreator : public CPUBackend::Creator {
public:
    virtual Execution* onCreate(const std::vector<Tensor*>& inputs,
                                const std::vector<Tensor*>& outputs,
                                const MNN::Op* op, Backend* backend) const {
        ...
        const Plugin* plugin_param = op->main_as<Plugin>();
        const std::string& op_type = plugin_param->type()->str();
        std::unique_ptr<plugin::CPUKernelContext> ctx(
            new plugin::CPUKernelContext(op_type, backend, inputs, outputs, static_cast<CPUBackend *>(backend)->pNPUModelDirPath));

        for (const Attribute* attr : *(plugin_param->attr())) {
            ctx->setAttr(attr->key()->str(), attr);
        }
        return new CPUPlugin(std::move(ctx));
    }
};

这里把三类信息塞进了 CPUKernelContext：

op_type：这里是 "QNN"；
pNPUModelDirPath：模型目录，后面用来拼 QNN 计算图 qnn/graph0.bin；
插件属性：包括 path、inputs、outputs、allGraphName、allInputShape。

CPUPluginCreator::onCreate(...) 最后一行真正进入 CPUPlugin 构造函数。构造函数里会通过 op_type 找到 QNN 计算内核，并立刻调用 kernel_->init(...)：

// source/backend/cpu/CPUPlugin.cpp:27
class CPUPlugin : public Execution {
public:
    CPUPlugin(std::unique_ptr<plugin::CPUKernelContext> ctx)
        : Execution(ctx->backend()), ctx_(std::move(ctx)) {
        kernel_ = getCPUComputeKernel(ctx_->op_type());
        MNN_CHECK(nullptr != kernel_.get(),
                  "CPU compute kernel has not been registered for plugin op.");
        kernel_->init(ctx_.get());
        mNeedAllocIO = kernel_->needAllocIO();
    }

getCPUComputeKernel(...) 本身只是从 ComputeKernelRegistry 里按名字取工厂函数：

// source/backend/cpu/CPUPlugin.cpp:21
static std::shared_ptr<plugin::CPUComputeKernel> getCPUComputeKernel(
    const std::string& name) {
    return std::shared_ptr<plugin::CPUComputeKernel>(
        plugin::ComputeKernelRegistry<plugin::CPUComputeKernel>::get(name));
}

其 get(name) 会查 gFactoryMap，然后执行对应工厂函数：

// source/plugin/PluginKernel.cpp:48
PluginKernelT* ComputeKernelRegistry<PluginKernelT>::get(const std::string& name) {
    auto* gFactoryMap = ComputeKernelRegistry<PluginKernelT>::getFactoryMap();
    if (!gFactoryMap->count(name)) {
        MNN_PRINT("Factory has not been registered for name %s.", name.c_str());
        return nullptr;
    }
    return gFactoryMap->at(name)();
}

QNN 在前面注册过 "QNN" 这个工厂函数：

// source/backend/qnn/backend/QNNBackend.cpp:1841
plugin::ComputeKernelRegistry<plugin::backend::PluginExecuteRaw::KernelT>::add("QNN", []() {
    return new plugin::backend::PluginExecuteRaw;
});

所以这里的实际对象就是 PluginExecuteRaw。因此 CPUPlugin 构造函数里的 kernel_->init(ctx_.get()) 会动态分发到 PluginExecuteRaw::init(...)，执行加载 qnn/graph*.bin。

5.3 加载 `QNN` 图

PluginExecuteRaw::init() 先确保 QNN 全局上下文已经创建，然后用模型目录和插件属性 path 拼出 QNN 图的上下文二进制路径：

// source/backend/qnn/backend/QNNBackend.cpp:907
bool init(CPUKernelContext* ctx) override {
    if (QNN::gContext.deviceHandle == nullptr){
        QNN::createQnnContext();
    }
    auto path = MNNFilePathConcat(ctx->dir_path(), ctx->getAttr("path")->s()->str());

这里的路径关系是：

1
2
3

ctx->dir_path()              = <model_dir>
ctx->getAttr("path")->s()    = qnn/graph0.bin
最终 path                    = <model_dir>/qnn/graph0.bin

随后读取 allGraphName。一个 .bin 里可能包含多个计算图，比如 prefill 和 decode，所以运行时必须知道计算图名字顺序：

// source/backend/qnn/backend/QNNBackend.cpp:913
std::vector<std::string> allGraphName;
auto allGraphNameAttr = ctx->getAttr("allGraphName");
if (allGraphNameAttr && allGraphNameAttr->list() && allGraphNameAttr->list()->s()) {
    auto graphNames = allGraphNameAttr->list()->s();
    for (int i = 0; i < graphNames->size(); ++i) {
        allGraphName.push_back(graphNames->GetAsString(i)->str());
    }
} else {
    MNN_ERROR("MNN_QNN: Incorrect Plugin Op, can't find 'allGraphName' attr.\n");
    return false;
}

最后创建 RawExecutorWrapper，把上下文二进制交给 compileModel(...)：

1
2
3

// source/backend/qnn/backend/QNNBackend.cpp:952
mRawExecutor.reset(new RawExecutorWrapper());
return mRawExecutor->compileModel(path, binaryOffset, binarySize, allGraphName);

compileModel(...) 先读入 .bin。如果插件属性里有 offset / size，就从文件指定位置读取；否则直接 mmap 整个文件：

// source/backend/qnn/backend/QNNBackend.cpp:772
bool compileModel(const std::string& path, size_t offset, size_t size, const std::vector<std::string>& allGraphName) {
    mPath = path;
    void* buffer = nullptr;
    std::vector<char> bufferVec(size, 0);
    MMapReader reader;
    if (size > 0) {
        buffer = bufferVec.data();
        std::unique_ptr<FileLoader> binaryFile(new FileLoader(path.c_str()));
        binaryFile->offset((int64_t)offset);
        binaryFile->read((char *)buffer, (int64_t)size);
    } else {
        reader.open(path.c_str());
        buffer = reader.addr();
        size = reader.size();
    }

接着通过 QNN system API 解析二进制里的计算图元信息：

// source/backend/qnn/backend/QNNBackend.cpp:790
QnnSystemContext_Handle_t systemContextHandle = nullptr;
QNN::gContext.systemInterface.systemContextCreate(&systemContextHandle);
Qnn_ContextBinarySize_t binarySize = 0;
const QnnSystemContext_BinaryInfo_t* binaryInfo = nullptr;
CALL_QNN(QNN::gContext.systemInterface.systemContextGetBinaryInfo(
    systemContextHandle, buffer, size, &binaryInfo, &binarySize));
copyMetadataToGraphsInfo(binaryInfo, mGraphsInfo, mGraphCount);
QNN::gContext.systemInterface.systemContextFree(systemContextHandle);

然后校验二进制，并从二进制创建 QNN 上下文：

// source/backend/qnn/backend/QNNBackend.cpp:807
auto error = QNN::gContext.interface.contextValidateBinary(
    QNN::gContext.backendHandle,
    QNN::gContext.deviceHandle,
    mQnnContextConfig,
    buffer,
    size);
...
CALL_QNN(QNN::gContext.interface.contextCreateFromBinary(
    QNN::gContext.backendHandle,
    QNN::gContext.deviceHandle,
    mQnnContextConfig,
    buffer,
    size,
    &mQnnContextHandle,
    mQnnProfileHandle));

最后按 allGraphName 的顺序整理 mGraphsInfo，并取回每个计算图句柄：

// source/backend/qnn/backend/QNNBackend.cpp:820
std::vector<GraphInfo*> sortedGraphsInfo(mGraphCount, nullptr);
std::map<std::string, GraphInfo*> graphInfoMap;
for (int i = 0; i < mGraphCount; ++i) {
    graphInfoMap[mGraphsInfo[i]->graphName] = mGraphsInfo[i];
}

for (int i = 0; i < mGraphCount; ++i) {
    auto it = graphInfoMap.find(allGraphName[i]);
    MNN_ASSERT(it != graphInfoMap.end());
    sortedGraphsInfo[i] = it->second;
}
for (int i = 0; i < mGraphCount; i++) {
    CALL_QNN(QNN::gContext.interface.graphRetrieve(
        mQnnContextHandle,
        mGraphsInfo[i]->graphName,
        &(mQnnGraphHandleVec[i])));
}

这一步结束后，QNN 插件已经持有：

RawExecutorWrapper
├── mQnnContextHandle
├── mGraphsInfo[shapeIndex]
└── mQnnGraphHandleVec[shapeIndex]

后面 execute 阶段不再重新创建 QNN 计算图，而是根据 shapeIndex 选择已经取回的计算图句柄。

5.4 `PluginExecuteRaw::resize()`

CPUPlugin::onResize() 会把当前输入输出张量重置到 CPUKernelContext，再调用 QNN 内核的 resize()：

// source/backend/cpu/CPUPlugin.cpp:49
ErrorCode CPUPlugin::onResize(const std::vector<Tensor*>& inputs,
                              const std::vector<Tensor*>& outputs) {
    ctx_->reset(inputs, outputs);
    auto success = kernel_->resize(ctx_.get());
    ...
}

PluginExecuteRaw::resize() 会再次通过 computeIndex() 得到当前 shapeIndex，并保存到成员变量 mShapeIndex：

// source/backend/qnn/backend/QNNBackend.cpp:956
bool resize(CPUKernelContext* ctx) override {
    int shapeIndex = 0;
    if (!(shape_inference::computeIndex(ctx, shapeIndex))) {
        MNN_ERROR("MNN_QNN: Failed to execute Plugin Op.\n");
        return false;
    }
    mShapeIndex = shapeIndex;

随后读取插件属性里的 inputs / outputs。这些名字一般是 t<tensor_index>，由离线 compilefornpu 按主图张量索引写入：

// source/backend/qnn/backend/QNNBackend.cpp:964
auto inputs = ctx->getAttr("inputs")->list();
auto inputTensor = ctx->inputs();
MNN_ASSERT(inputs->s()->size() == inputTensor.size());
mInputs.resize(inputs->s()->size());
mRealInputs.resize(inputTensor.size());
for (int i=0; i<inputs->s()->size(); ++i) {
    mRealInputs[i].reset(new Tensor(inputTensor[i], Tensor::CAFFE));
    mInputs[i].second = inputs->s()->GetAsString(i)->str();
    mInputs[i].first = mRealInputs[i].get();
}

输出也是同样处理：

// source/backend/qnn/backend/QNNBackend.cpp:974
auto outputs = ctx->getAttr("outputs")->list();
auto outputTensor = ctx->outputs();
mOutputs.resize(outputs->s()->size());
MNN_ASSERT(outputs->s()->size() == outputTensor.size());
mRealOutputs.resize(outputTensor.size());
for (int i=0; i<outputs->s()->size(); ++i) {
    mRealOutputs[i].reset(new Tensor(outputTensor[i], Tensor::CAFFE));
    mOutputs[i].second = outputs->s()->GetAsString(i)->str();
    mOutputs[i].first = mRealOutputs[i].get();
}

这里保存的是 MNN 张量和 QNN 张量名的对应关系：

1
2
3

mRealInputs / mRealOutputs: 临时 Tensor，后面交给 QNN graphExecute 使用
mInputs / mOutputs: (临时 Tensor 指针, QNN tensor name)
mShapeIndex: 当前输入 shape 对应的 graph index

到这里，resize 阶段完成了三件事：输出形状已经确定，QNN 上下文二进制已经加载，当前形状的输入输出映射也准备好了。

6. `execute` 阶段

StaticModule::_execute() 最后会走到 Session::run()。当流水线执行到 OpType_Plugin(type="QNN") 时，CPU 后端调用的是 CPUPlugin::onExecute()：

// source/backend/cpu/CPUPlugin.cpp:59
ErrorCode CPUPlugin::onExecute(const std::vector<Tensor*>& inputs,
                               const std::vector<Tensor*>& outputs) {
    if (kernel_->compute(ctx_.get())) {
        return NO_ERROR;
    } else {
        MNN_ERROR("Plugin kernel compute failed with false returned.\n");
        return INVALID_VALUE;
    }
}

对 QNN 插件来说，这里的 kernel_ 就是前面 init 阶段创建好的 PluginExecuteRaw。

6.1 重新确认 `shapeIndex`

PluginExecuteRaw::compute() 开头会重新调用 computeIndex()，确认当前输入形状对应哪个计算图：

// source/backend/qnn/backend/QNNBackend.cpp:988
bool compute(CPUKernelContext* ctx) override {
    AUTOTIME;
    int shapeIndex = 0;
    if (!(shape_inference::computeIndex(ctx, shapeIndex))) {
        MNN_ERROR("MNN_QNN: Failed to execute Plugin Op.\n");
        return false;
    }
    std::string graphName = ctx->getAttr("allGraphName")->list()->s()->GetAsString(shapeIndex)->str();

当前源码后面传给 invokModel() 的是成员变量 mShapeIndex，也就是 resize 阶段记录的 shape index。compute() 里重新算出的局部 shapeIndex 主要用于读取 allGraphName 和调试打印。

6.2 准备输入输出 `Tensor`

compute() 里会重新创建一次实时输入输出张量映射。源码注释写的是 in-time inputs and outputs tensor：

// source/backend/qnn/backend/QNNBackend.cpp:997
// compute and alloc real in-time inputs and outputs tensor
{
    auto inputs = ctx->getAttr("inputs")->list();
    auto inputTensor = ctx->inputs();
    MNN_ASSERT(inputs->s()->size() == inputTensor.size());
    mInputs.resize(inputs->s()->size());
    mRealInputs.resize(inputTensor.size());
    for (int i=0; i<inputs->s()->size(); ++i) {
        mRealInputs[i].reset(new Tensor(inputTensor[i], Tensor::CAFFE));
        mInputs[i].second = inputs->s()->GetAsString(i)->str();
        mInputs[i].first = mRealInputs[i].get();
    }
    ...
}

这和 resize 阶段的映射逻辑有重复。resize 阶段先建立一次映射并记录 mShapeIndex；execute 阶段再基于当前 ctx->inputs() / ctx->outputs() 建立实时 Tensor，保证后面的拷贝和 QNN 的 clientBuf 绑定使用的是本次运行的缓冲区。

6.3 拷贝输入、执行 `QNN`、拷回输出

真正执行前，MNN 会先把当前输入张量拷到 mRealInputs：

// source/backend/qnn/backend/QNNBackend.cpp:1024
auto inputTensor = ctx->inputs();
auto outputTensor = ctx->outputs();

for (int i=0; i<mInputs.size(); ++i) {
    ctx->backend()->onCopyBuffer(inputTensor[i], mRealInputs[i].get());
}
mRawExecutor->invokModel(mInputs, mOutputs, mShapeIndex);
for (int i=0; i<mOutputs.size(); ++i) {
    ctx->backend()->onCopyBuffer(mRealOutputs[i].get(), outputTensor[i]);
}

随后在 invokModel() 里执行，最后把结果从 mRealOutputs 拷回 ctx->outputs()。

6.4 `invokModel()`执行入口

RawExecutorWrapper::invokModel() 先根据 shapeIndex 选择 QNN 计算图：

// source/backend/qnn/backend/QNNBackend.cpp:844
void invokModel(const std::vector<std::pair<const MNN::Tensor *, std::string>>& inputs, std::vector<std::pair<const MNN::Tensor *, std::string>>& outputs, int shapeIndex) {
    GraphInfo* graph = mGraphsInfo[shapeIndex];
    Qnn_GraphHandle_t qnnGraphHandle = mQnnGraphHandleVec[shapeIndex];

然后按张量名把 MNN 缓冲区绑定到 QNN 输入张量的 clientBuf：

// source/backend/qnn/backend/QNNBackend.cpp:849
for (int i=0; i<inputs.size(); ++i) {
    auto t = inputs[i].first;
    bool find = false;
    for (int j=0; j<graph->numInputTensors; ++j) {
        auto& dstT = graph->inputTensors[j];
        if (inputs[i].second == dstT.v1.name) {
            dstT.v1.clientBuf.data = t->host<void>();
            dstT.v1.clientBuf.dataSize = t->usize();
            find = true;
            break;
        }
    }
}

输出张量也是同样按名字绑定：

// source/backend/qnn/backend/QNNBackend.cpp:868
for (int i=0; i<outputs.size(); ++i) {
    auto t = outputs[i].first;
    bool find = false;
    for (int j=0; j<graph->numOutputTensors; ++j) {
        auto& dstT = graph->outputTensors[j];
        if (outputs[i].second == dstT.v1.name) {
            dstT.v1.clientBuf.data = t->host<void>();
            dstT.v1.clientBuf.dataSize = t->usize();
            find = true;
            break;
        }
    }
}

这里的名字来自离线阶段写进插件属性的 inputs / outputs。

6.5 `graphExecute()` 执行点

绑定完输入输出缓冲区后，RawExecutorWrapper::invokModel() 会调用 QNN 接口 graphExecute() 执行计算图：

// source/backend/qnn/backend/QNNBackend.cpp:887
CALL_QNN(QNN::gContext.interface.graphExecute(
    qnnGraphHandle,
    graph->inputTensors,
    graph->numInputTensors,
    graph->outputTensors,
    graph->numOutputTensors,
    mQnnProfileHandle,
    nullptr));
MNN::QNN::doProfile(QNN::gContext.interface, mQnnProfileHandle);

到这一行，计算已经交给了 QNN 后端：

通过 shapeIndex 选中了正确的 QNN 计算图句柄；
通过 inputs / outputs 名字把缓冲区绑到 QNN 张量；
把执行交给 QNN 运行时。

.bin 里面的 HTP 计算图执行由 QNN 后端负责。MNN 运行时在这里主要做计算图选择、缓冲区绑定和结果回拷。

7. 小结

把第 4 到第 6 节串起来看，QNN 插件的运行时路径是：

StaticModule::onForward()
├── _resize()
│   ├── ShapePlugin
│   │   └── PluginShapeRaw::compute()
│   │       ├── allInputShape -> shapeIndex
│   │       └── o_<shapeIndex>_* -> 输出 shape
│   │
│   └── Pipeline::encode() 创建 Plugin Execution
│       └── CPUPluginCreator
│           └── CPUPlugin
│               └── PluginExecuteRaw::init()
│                   └── RawExecutorWrapper::compileModel()
│                       ├── mmap/read qnn/graph*.bin
│                       ├── contextCreateFromBinary()
│                       └── graphRetrieve()
│
└── _execute()
    └── CPUPlugin::onExecute()
        └── PluginExecuteRaw::compute()
            ├── 准备实时输入输出 Tensor
            ├── onCopyBuffer(input -> mRealInputs)
            ├── RawExecutorWrapper::invokModel(mShapeIndex)
            │   ├── mQnnGraphHandleVec[mShapeIndex]
            │   ├── 绑定 QNN input/output clientBuf
            │   └── graphExecute()
            └── onCopyBuffer(mRealOutputs -> output)

LLM QNN 离线导出流程

Thu, 04 Jun 2026 12:00:00 +0800

LLM QNN 离线导出流程

LLM QNN 离线导出流程

本文记录 transformers/llm/export/npu/generate_llm_qnn.py 将 MNN 格式模型导出到 QNN 后端的链路。主要把 llm.mnn / llm.mnn.weight 文件转成 QNN 运行需要的两类产物：

qnn/llm.mnn：已经插入 OpType_Plugin(type="QNN") 的主模型；
qnn/*.bin：QNN HTP context binary，运行时由 QNN Plugin 直接加载执行。

整体流程分为四步：

generate_llm_qnn.py
  -> convert(args)
    -> makeIO(args)
    -> seperate(args)
    -> compile_qnn(args)
    -> output_qnn(args)

1. 入口参数

脚本入口在 transformers/llm/export/npu/generate_llm_qnn.py，常用参数如下：

参数	说明
`--model`	MNN LLM 模型目录
`--soc_id`	QNN 目标 SoC id
`--dsp_arch`	QNN DSP 架构，例如 `v75`、`v79`
`--mnn_path`	MNN build 目录，需要包含 `generateLlmIO` 和 `compilefornpu`
`--cache_path`	临时工作目录，默认 `tmp`
`--chunk_size`	写入 `config_qnn.json` 的 prefill shape，默认 `128`

脚本大量通过 os.getcwd() 拼路径，所以运行目录很重要。常见执行方式是从仓库根目录进入导出目录后运行。soc_id 和 dsp_arch 需要和目标 SoC / Hexagon 版本对应，可以参考 Qualcomm 官方设备信息：

cd ${MNN_ROOT}
cd transformers/llm/export

python3 npu/generate_llm_qnn.py \
  --model /data/HF_MODELS/Qwen3-1.7B-MNN \
  --soc_id 69 \
  --dsp_arch v79 \
  --mnn_path ../../../build/

模型目录至少需要这些文件，可以直接使用官方提供的模型 Qwen3-1.7B-MNN：

Qwen3-1.7B-MNN/
├── config.json
├── llm_config.json
├── tokenizer.txt
├── llm.mnn
└── llm.mnn.weight

npu_convert.py 还会读取 QNN_SDK_ROOT，所以开发机环境里需要先配置 QAIRT / QNN SDK。

2. Step1：生成 IO 样本

LLM QNN 导出从 convert(args) 方法开始。Step1 对应的是 makeIO(args)：

# transformers/llm/export/npu/generate_llm_qnn.py:67
def convert(args):
    cache = os.path.join(os.getcwd(), args.cache_path)
    os.makedirs(cache, exist_ok=True)
    print("Step1: Make IO")
    makeIO(args)

makeIO(args) 本身没有解析 llm_config.json，它只是拼出可执行文件 generateLlmIO 的路径（由主库编译产生，详见 QNN 模型导出），并把模型目录、输出目录和 chunk_size 传进去：

# transformers/llm/export/npu/generate_llm_qnn.py:10
def makeIO(args):
    exe = os.path.join(os.getcwd(), args.mnn_path, "generateLlmIO")
    output = os.path.join(args.cache_path, 'testdir')
    print(os.popen(exe + " " + args.model + " " + output + ' %d' %args.chunk_size).read())

所以 Step1 实际执行的命令可以展开成：

<cwd>/<mnn_path>/generateLlmIO \
  <model_dir> \
  tmp/testdir \
  <chunk_size>
# 如果没有 tmp/testdir 目录，可能需要手动创建

这里 <model_dir> 是整个 MNN LLM 模型目录，不是单独的 llm.mnn 文件。llm_config.json、llm.mnn、llm.mnn.weight 等文件会由 generateLlmIO 在模型目录内部继续读取。

generate_llm_qnn.py 只关心两个后续会被 compilefornpu 读取的样本目录：

用途	样本目录
prefill	`testdir/<chunk_size>`
decode	`testdir/1`

生成结果会落在 tmp/testdir 下，后续 compilefornpu 会按 testdir/1、testdir/<chunk_size> 读取这些输入输出样本。

生成结果包含两组不同长度的输入输出样本：

➜  export git:(master) ✗ ../../../build/generateLlmIO /data/HUGGINGFACE/Qwen3-1.7B-Eagle3-MNN tmp/testdir 128
blockSize=128 in main, 148
modelPath.c_str()=s /data/HUGGINGFACE/Qwen3-1.7B-Eagle3-MNN/llm.mnn in main, 152
llmConfigPath.c_str()=s /data/HUGGINGFACE/Qwen3-1.7B-Eagle3-MNN/llm_config.json in main, 153
Can't open file:/sys/devices/system/cpu/cpufreq/boost/affected_cpus
Can't open file:/sys/devices/system/cpu/cpufreq/ondemand/affected_cpus
CPU Group: [ 95  17  83  55  118  27  93  65  5  37  75  47  19  85  57  29  108  67  7  39  101  10  77  49  111  20  87  59  121  30  97  69  33  112  21  88  122  31  98  41  104  13  51  114  23  61  1  124  9  71  43  106  15  81  53  116  25  91  63  3  126  35  73  45  94  117  26  92  64  4  127  36  74  46  109  18  84  56  119  28  54  66  6  38  100  76  48  110  86  58  120  96  68  8  102  11  105  40  103  12  79  50  113  22  89  60  0  123  32  99  70  42  78  14  80  52  115  24  90  62  2  125  34  72  44  107  16  82 ], 1500000 - 2900000
The device supports: i8sdot:0, fp16:0, i8mm: 0, sve2: 0, sme2: 0
Successfully generate tmp/testdir/128/input.mnn and tmp/testdir/128/output.mnn.
Successfully generate tmp/testdir/1/input.mnn and tmp/testdir/1/output.mnn.

输入由 createInputsForLLM(...) 构造，输出由这些输入跑一次 LLM 网络前向得到：

// transformers/llm/engine/tools/generateLlmIO.cpp:117
{
    std::vector<MNN::Express::VARP> inputs;
    std::vector<MNN::Express::VARP> outputs;
    createInputsForLLM(blockSize, hiddenSize, attentionMaskType, false, inputs);
    outputs = net->onForward(inputs);
    saveInputOutputs(net->getInfo(), inputs, outputs, outputDir, blockSize);
}

// transformers/llm/engine/tools/generateLlmIO.cpp:125
{
    std::vector<MNN::Express::VARP> inputs;
    std::vector<MNN::Express::VARP> outputs;
    createInputsForLLM(1, hiddenSize, attentionMaskType, true, inputs);
    outputs = net->onForward(inputs);
    saveInputOutputs(net->getInfo(), inputs, outputs, outputDir, 1);
}

3. Step2：切图

convert(args) 的 Step2 直接调用 seperate(args)：

1
2
3

# transformers/llm/export/npu/generate_llm_qnn.py:76
print("Step2: Seperate Model")
seperate(args)

seperate(args) 先定位可执行文件 compilefornpu（由主库编译产生，详见 QNN 模型导出）和原始 llm.mnn，再写一个临时 qnn.json。这里的 seperate 是源码里的函数名拼写，文档里保持不改：

# transformers/llm/export/npu/generate_llm_qnn.py:15
def seperate(args):
    exe = os.path.join(os.getcwd(), args.mnn_path, "compilefornpu")
    model = os.path.join(os.getcwd(), args.model, 'llm.mnn')
    config = {
        "type":"QNN",
        "skips":[],
        "testdir":[],
        "cache":"qnn"
    }
    config['testdir'].append(os.path.join("testdir", '1'))
    config['testdir'].append(os.path.join("testdir", '%d' %args.chunk_size))

写出的配置内容对应下面这样：

{
  "type": "QNN",
  "skips": [],
  "testdir": [
    "testdir/1",
    "testdir/<chunk_size>"
  ],
  "cache": "qnn"
}

然后它在 tmp 目录下执行 compilefornpu：

# transformers/llm/export/npu/generate_llm_qnn.py:29
cache = os.path.join(os.getcwd(), args.cache_path)
with open(os.path.join(cache, 'qnn.json'), 'w') as f:
    f.write(json.dumps(config, indent=4))

process = subprocess.Popen(
    exe + ' ' + model + ' qnn/llm.mnn qnn.json',
    cwd = cache,
    shell=True
)

命令展开后是：

<build>/compilefornpu \
  <model_dir>/llm.mnn \
  qnn/llm.mnn \
  qnn.json

compilefornpu 的入口在 tools/cpp/compilefornpu.cpp。这一步会在原图上做三件事：

先根据输入输出 tensor 找出真正需要计算的 op；
再把连续可下沉的 op 区间整理成 SubModuleInfo；
最后把每个可下沉区间替换成一个 OpType_Plugin(type="QNN")。

代码调用关系如下：

generate_llm_qnn.py
└── seperate(args)                                      # 生成切图配置并启动 compilefornpu
    ├── 写 tmp/qnn.json                                # 告诉 compilefornpu 目标后端和测试 shape
    │   ├── type = "QNN"
    │   ├── testdir = ["testdir/1", "testdir/<chunk_size>"]
    │   └── cache = "qnn"
    │
    └── subprocess.Popen(...)
        └── compilefornpu <model_dir>/llm.mnn qnn/llm.mnn qnn.json
            │
            ├── main(argc, argv)                       # 切图工具主入口
            │   ├── 解析 qnn.json                      # 初始化 QNN 离线导出参数
            │   │   ├── gNPUType = MNN_CONVERT_QNN
            │   │   ├── gNeedOffline = true
            │   │   └── gCacheDir = "qnn"
            │   ├── 读取 testdir/*/input.mnn 和 output.mnn # 取得 decode / prefill 两组输入输出
            │   ├── Interpreter::createFromFile(srcMNN)    # 读取原始 llm.mnn
            │   ├── initConstTensorsNoAlloc(...)           # 标记常量 tensor
            │   └── _createSubModuleInfo(...)              # 生成候选子图列表
            │       ├── _collectNeededOps(...)             # 从输出反向追依赖 op
            │       ├── isBreakOp(...)                     # 遇到控制流 / 不支持 op 就切断
            │       ├── _splitSubModuleForShapeConst(...)  # shape 依赖输入内容时补切
            │       └── _computeTensorMask(...)            # 计算子图输入输出边界
            │
            ├── for 每组 testdir 输入 shape                  # 分别处理 decode / prefill
            │   ├── _getSubModuleIO(...)                    # 跑原图收集子图参考 IO
            │   │   └── 记录 KV state shape                 # KV 下沉时写 Plugin state
            │   ├── 过滤不含 Convolution 的子图              # 当前导出只保留卷积子图
            │   └── _compileSubModule(...)                  # 编译子图并生成 Plugin op
            │       ├── RuntimeManager(type = MNN_CONVERT_QNN)
            │       ├── setCache("qnn/graph*")              # 指定 QNN graph 源目录
            │       ├── Module::load(...)
            │       ├── Module::onForward(...)              # 触发 QNN convert backend 导出 graph
            │       └── 生成 OpType_Plugin(type="QNN")      # 用一个 Plugin 表示整段子图
            │
            ├── 用 Plugin 替换原始连续 op 区间               # 改写主图
            ├── _reIndexTensor(...) / _reOrderOp(...)       # 清理 tensor 并重排拓扑
            ├── 多 shape 结果用 _fuse(...) 合并 Plugin attr  # 合并 decode / prefill graph 信息
            ├── 写 qnn/llm.mnn                              # 插入 QNN Plugin 后的主模型
            └── 写 npu_postreat.json                        # 给 npu_convert.py 继续生成 context binary
                └── merge: qnn/graph*.bin -> [qnn/graph*, qnn/graph1_*, ...]

3.1 QNN 离线模式

compilefornpu 的命令格式是：

// tools/cpp/compilefornpu.cpp:836
int main(int argc, const char* argv[]) {
    if (argc < 3) {
        MNN_PRINT("Usage: ./compilefornpu src.mnn dst.mnn npu.json\n");
        return 0;
    }
    const char* srcMNN = argv[1];
    const char* dstMNN = argv[2];

当 qnn.json 里写的是 "type": "QNN" 时，代码会把后端类型设成 MNN_CONVERT_QNN，并打开 gNeedOffline：

// tools/cpp/compilefornpu.cpp:859
gNPUName = document["type"].GetString();
if (gNPUName == "QNN") {
    MNN_PRINT("Convert for QNN, QualComn's NPU\n");
    gNPUType = MNN_CONVERT_QNN;
    gNeedOffline = true;
    gOfflieSrc = "";
    gOfflieDst = "bin";
}

gNeedOffline = true 之后，_compileSubModule(...) 会通过一次 Module::onForward() 触发 QNN convert 后端导出 graph 材料。

3.2 读取 testdir

generate_llm_qnn.py 写入了两组 testdir：

"testdir": [
  "testdir/1",
  "testdir/<chunk_size>"
]

compilefornpu 会逐个读取里面的 input.mnn 和 output.mnn：

// tools/cpp/compilefornpu.cpp:898
if (document.HasMember("testdir")) {
    auto testdir = document["testdir"].GetArray();
    for (auto iter = testdir.Begin(); iter != testdir.End(); iter++) {
        std::string dirname = iter->GetString();
        auto subinputs = MNN::Express::Variable::load((dirname + "/input.mnn").c_str());
        inputs.emplace_back(subinputs);
        inputNames.clear();
        for (int i=0; i<subinputs.size(); ++i) {
            inputNames.emplace_back(subinputs[i]->name());
        }
        auto outputs = MNN::Express::Variable::load((dirname + "/output.mnn").c_str());
        outputNames.clear();
        for (int i=0; i<outputs.size(); ++i) {
            outputNames.emplace_back(outputs[i]->name());
        }
    }
}

这里的 input.mnn / output.mnn 提供了：

主图输入名；
主图输出名；
decode / prefill 两组真实输入 shape 和数据；

3.3 生成候选子图列表

compilefornpu 使用 _createSubModuleInfo(...) 生成需要转换的候选子图列表，流程如下。

3.3.1 反向收集 op

切图的第一步是 _collectNeededOps(...)。它先给输入和输出 tensor 打标记，再从 outputIndexes 反向追溯数据依赖，直到遇到 inputIndexes：

// tools/cpp/compilefornpu.cpp:261
static std::vector<SubModuleInfo> _createSubModuleInfo(
    const Net* net,
    const std::set<int>& inputIndexes,
    const std::set<int>& outputIndexes,
    const std::set<int>& noComputeIndexes,
    std::shared_ptr<Schedule::ScheduleInfo> sharedConst) {
    std::vector<SubModuleInfo> submodule;
    auto selectOps = _collectNeededOps(net, inputIndexes, outputIndexes);
    // ...
}

// tools/cpp/compilefornpu.cpp:116
static std::vector<int> _collectNeededOps(
    const MNN::Net* net,
    const std::set<int>& inputIndexes,
    const std::set<int>& outputIndexes) {
    // 0: not set, 1: output, 2:input
    std::vector<int> tensorMask(net->tensorName()->size());
    ...
    for (auto v : outputIndexes) {
        tensorMask[v] = 1;
    }
    for (auto v : inputIndexes) {
        tensorMask[v] = 2;
    }

接着沿着输出到输入的方向反复传播标记：如果某个 op 的输出已经被标成需要保留，就把这个 op 标成需要计算，并继续把它的输入 tensor 标成依赖项：

// tools/cpp/compilefornpu.cpp:134
do {
    change = false;
    for (int i=0; i<opMask.size(); ++i) {
        ...
        if (nullptr != op->outputIndexes()) {
            for (int j=0; j<op->outputIndexes()->size(); ++j) {
                auto index = op->outputIndexes()->data()[j];
                if (tensorMask[index] == 1) {
                    opMask[i] = 1;
                    change = true;
                }
            }
        }
        if (nullptr != op->inputIndexes() && opMask[i]) {
            for (int j=0; j<op->inputIndexes()->size(); ++j) {
                auto index = op->inputIndexes()->data()[j];
                if (tensorMask[index] != 2) {
                    tensorMask[index] = 1;
                }
            }
        }
    }
} while (change);

3.3.2 按 break op 切图

_createSubModuleInfo(...) 会按原图 op 顺序扫描上一步采集的算子 selectOps：普通 op 缓存到 current.opList；遇到 break op，就先把前面的连续算子保存成一个子模块，再把这个 break op 单独保存成一个 SubModuleInfo：

// tools/cpp/compilefornpu.cpp:267
for (int si=0; si<selectOps.size(); ++si) {
    auto i = selectOps[si];
    auto op = net->oplists()->GetAs<Op>(i);
    if (isBreakOp(op)) {
        if (current.opList.size() > 0) {
            submodule.emplace_back(std::move(current));
        }
        SubModuleInfo controlOp;
        controlOp.opList = {i};
        controlOp.isBreak = true;
        ...
        submodule.emplace_back(std::move(controlOp));
        continue;
    }
    current.opList.emplace_back(i);
}

isBreakOp(...) 的判别规则是，控制流算子属于 break op，例如 OpType_While、OpType_If 等：

// tools/cpp/compilefornpu.cpp:102
static bool isBreakOp(const Op* op) {
    bool isWhileControlflow = false;
    if (op->type() == OpType_While && op->main_as_WhileParam() != nullptr) {
        isWhileControlflow = true;
    }
    if (op->type() == OpType_If || isWhileControlflow || op->type() == OpType_Where || op->type() == OpType_Segment || op->type() == OpType_Unique || op->type() == OpType_NonMaxSuppressionV2) {
        return true;
    }
    if (!_npuSupportOp(op)) {
        return true;
    }
    return false;
}

对当前 QNN LLM 导出，需要注意 Attention + kv_cache。默认配置下，使用 KV cache 的注意力算子会被 _npuSupportOp(...) 判成不支持，随后被 isBreakOp(...) 切断：

// tools/cpp/compilefornpu.cpp:89
static bool _npuSupportOp(const Op* op) {
    if (gMaxKVSize > 0) {
        return true;
    }
    if (op->type() == OpType_Attention) {
        auto attn = op->main_as_AttentionParam();
        if (nullptr != attn && attn->kv_cache()) {
            return false;
        }
    }
    return true;
}

3.3.3 补切动态 shape

第一次切图主要看 op 类型。接下来还会用 _splitSubModuleForShapeConst(...) 做第二次切分：

1
2

// tools/cpp/compilefornpu.cpp:295
submodule = _splitSubModuleForShapeConst(submodule, net, sharedConst);

这一步处理的是“shape 推导依赖输入内容”的 op。判断入口在 _findBreakIndex(...)：

// tools/cpp/compilefornpu.cpp:214
int inputNum = op->inputIndexes()->size();
auto dims = SizeComputer::needInputContent(op, inputNum);
for (auto index : dims) {
    if (index < inputNum) {
        if (constMask[op->inputIndexes()->data()[index]] != 1) {
            res.emplace_back(v);
            break;
        }
    }
}

含义是：如果某个 op 的 shape 计算需要读取输入 tensor 的内容，并且这个输入不是常量，就把这个 op 作为切分点。这样可以避免把动态 shape / 内容相关 shape 逻辑直接塞进 NPU 子图里。

3.3.4 计算子图边界

SubModuleInfo 里真正描述切图边界的是：

// tools/cpp/compilefornpu.cpp:56
struct SubModuleInfo {
    std::vector<int> opList;
    std::vector<int> inputs;
    std::vector<int> outputs;
    std::vector<int> tensorMask;
    bool isBreak = false;
};

每个连续子图的 inputs / outputs 都是根据子图内部 op 的 tensor 使用情况计算出来。_computeTensorMask(...) 会先给 tensor 打标记，含义如下：

1
2
3

1: 这个 tensor 被当前子图消费，是子图输入
2: 这个 tensor 由当前子图产生，是子图输出
3: 这个 tensor 既被当前子图消费又由当前子图产生，是子图内部中间 tensor

对应代码在 _createSubModuleInfo(...) 里：

// tools/cpp/compilefornpu.cpp:299
if (!m.isBreak) {
    _computeTensorMask(m, net);
    for (int i=0; i<m.tensorMask.size(); ++i) {
        if (1 == m.tensorMask[i]) {
            if (noComputeIndexes.find(i) != noComputeIndexes.end()) {
                continue;
            }
            m.inputs.emplace_back(i);
            continue;
        }
        if (2 == m.tensorMask[i]) {
            m.outputs.emplace_back(i);
            continue;
        }
        if (3 == m.tensorMask[i]) {
            if (outputIndexes.find(i) != outputIndexes.end()) {
                m.outputs.emplace_back(i);
            }
        }
    }
}

产生的边界规则可以写成：

子图消费、但不是子图内部产生的 tensor，是子图输入；
子图产生、并且需要给后续 op 或最终输出使用的 tensor，是子图输出；
子图内部产生又内部消费的 tensor，是中间 tensor，默认不暴露；
如果某个中间 tensor 被后续子图需要，代码会把它补进前一个子图的 outputs，对应逻辑如下：

// tools/cpp/compilefornpu.cpp:348
for (int sub=0; sub < moduleIndex; ++sub) {
    if (submodule[sub].tensorMask.empty()) {
        continue;
    }
    if (submodule[sub].tensorMask[index] == 2) {
        find = true;
        break;
    }
    if (submodule[sub].tensorMask[index] == 3) {
        submodule[sub].outputs.emplace_back(index);
        submodule[sub].tensorMask[index] = 2;
        find = true;
        break;
    }
}

compilefornpu 切图时不按层数、名字或者固定 pattern 切分，而是按 tensor 的数据依赖关系确定子图边界。

3.4 过滤非卷积子图

_createSubModuleInfo(...) 得到的是候选子图。还有一个过滤条件：如果候选子图里没有 OpType_Convolution，就重新标记成 isBreak = true：

// tools/cpp/compilefornpu.cpp:1068
bool hasConvolution = false;
for (auto opIndex : subModulesInfo[i].opList) {
    auto op = net->oplists()->GetAs<Op>(opIndex);
    if (op->type() == OpType_Convolution) {
        hasConvolution = true;
        break;
    }
}
if (!hasConvolution) {
    subModulesInfo[i].isBreak = true;
}

这个过滤的效果是：只转换含有卷积算子的子图，其他子图直接保留在主图中。

3.5 收集子图 IO

切图完成后，主流程会按每一组 testdir 输入跑所有子图：

// tools/cpp/compilefornpu.cpp:1040
for (int inputIndex=0; inputIndex < inputs.size(); ++inputIndex) {
    std::map<int, MNN::Express::VARP> stackes;
    ...
    std::vector<SubModuleIO> moduleIO(subModulesInfo.size());
    for (int i=0; i<subModulesInfo.size(); ++i) {
        auto& current = subModulesInfo[i];
        std::vector<MNN::Express::VARP> subInputs;
        for (auto index : current.inputs) {
            subInputs.emplace_back(stackes[index]);
        }
        moduleIO[i] = _getSubModuleIO(subInputs, current, bufferPair.first, bufferPair.second, srcMNN);
        for (int j=0; j<current.outputs.size(); ++j) {
            stackes.insert(std::make_pair(current.outputs[j], moduleIO[i].outputs[j]));
        }
    }

这里的 stackes 是一个 tensor index -> VARP 表。每跑完一个子图，就把它的输出放回 stackes，给后续子图继续使用。

_getSubModuleIO(...) 会用原始 MNN 模型加载当前子图的输入输出名，然后跑 CPU/default 路径得到参考输出：

// tools/cpp/compilefornpu.cpp:399
static SubModuleIO _getSubModuleIO(
    std::vector<MNN::Express::VARP> inputs,
    const SubModuleInfo& info,
    const void* buffer,
    size_t bufferSize,
    std::string srcpath) {
    ...
    std::shared_ptr<MNN::Express::Module> m(
        MNN::Express::Module::load(inputNames, outputNames, (const uint8_t*)buffer, bufferSize, rtmgr),
        MNN::Express::Module::destroy);
    ...
    auto outputs = m->onForward(inputs);
    io.inputs = inputs;
    io.outputs.resize(outputs.size());
    for (int i=0; i<outputs.size(); ++i) {
        io.outputs[i] = MNN::Express::_Clone(outputs[i], true);
    }
    return io;
}

如果子图里有带 kv_cache 的 Attention，这里还会通过 callback 记录 KV state 的形状：

// tools/cpp/compilefornpu.cpp:419
MNN::TensorCallBackWithInfo beforeCallBack = [&](const std::vector<MNN::Tensor*>& ntensors, const MNN::OperatorInfo* info) {
    auto opName = info->name();
    if (info->type() != "Attention") {
        return true;
    }
    if (attentionNames.find(opName) != attentionNames.end()) {
        auto query = ntensors[0];
        auto key = ntensors[1];
        auto value = ntensors[2];
        int seq_len = query->length(1);
        auto numHead = query->length(2);
        auto headDim = query->length(3);
        auto kvNumHead = key->length(2);
        std::vector<int> kvDims = {kvNumHead, 1, 1, headDim};
        io.kvcache.emplace_back(kvDims);
    }
    return true;
};

3.6 编译并替换 Plugin

真正触发 QNN 导出的是 _compileSubModule(...)：

// tools/cpp/compilefornpu.cpp:450
static std::unique_ptr<MNN::OpT> _compileSubModule(
    const SubModuleIO& io,
    SubModuleInfo& info,
    const void* buffer,
    size_t bufferSize,
    const std::string& path,
    std::string srcpath,
    const std::string& targetNpuPath,
    float& cpuTotal,
    float& npuTotal,
    int shapeIndex,
    std::string graphicName) {

该方法的核心调用在下面这段，其中 config.type = MNN_CONVERT_QNN：

// tools/cpp/compilefornpu.cpp:470
MNN::ScheduleConfig config;
config.type = gNPUType;
std::shared_ptr<MNN::Express::Executor::RuntimeManager> rtmgr(
    MNN::Express::Executor::RuntimeManager::createRuntimeManager(config));
rtmgr->setExternalFile((srcpath + ".weight").c_str());
rtmgr->setCache(path.c_str());
rtmgr->setHint(MNN::Interpreter::KVCACHE_SIZE_LIMIT, gMaxKVSize);
MNN::Express::Module::Config mdconfig;
mdconfig.shapeMutable = false;
std::shared_ptr<MNN::Express::Module> m(
    MNN::Express::Module::load(inputNames, outputNames, (const uint8_t*)buffer, bufferSize, rtmgr, &mdconfig),
    MNN::Express::Module::destroy);
auto predict = m->onForward(io.inputs);
if (gNeedOffline) {
    break;
}

这里的 onForward(io.inputs) 不只是为了拿一次输出。对于 QNN 离线导出，它的主要作用是驱动一次 StaticModule 前向，让 QNN convert 后端根据当前子图输入 shape 生成子图 graph 材料。因为 gNeedOffline == true，触发导出后会直接 break，不会继续做误差检查和测速。

导出完成后，_compileSubModule(...) 会创建一个新的 Plugin op：

// tools/cpp/compilefornpu.cpp:532
std::unique_ptr<MNN::OpT> op(new OpT);
op->inputIndexes = info.inputs;
op->outputIndexes = info.outputs;
op->name = targetNpuPath;
op->type = MNN::OpType_Plugin;
op->main.type = MNN::OpParameter_Plugin;
op->main.value = new MNN::PluginT;
auto extra = op->main.AsPlugin();
extra->type = gNPUName;

这个 Plugin 保留了原子图的输入输出 tensor index，相当于用一个 op 占住原来整段子图的输入输出边界。写入的关键 attr 包括：

attr	作用
`path`	最终 QNN binary 的相对路径，例如 `qnn/graph0.bin`
`inputs`	Plugin 输入对应的 QNN tensor 名，一般是 `t<tensor_index>`
`outputs`	Plugin 输出对应的 QNN tensor 名
`allGraphName`	`.bin` 内多个 graph 的名字顺序
`allInputShape`	当前 graph 对应的输入 shape
`o_<shapeIndex>_<outputIndex>`	当前 shape 下输出 tensor 的形状、类型和 format
`state`	KV cache state 信息，存在 KV 下沉时使用

以 inputs / outputs 为例，代码直接用子图边界 tensor index 生成 QNN tensor 名：

// tools/cpp/compilefornpu.cpp:547
attr->key = "inputs";
attr->list.reset(new ListValueT);
attr->list->s.resize(inputNames.size());
for (int i=0; i<inputNames.size(); ++i) {
    attr->list->s[i] = std::string("t") + std::to_string(info.inputs[i]);
}

// tools/cpp/compilefornpu.cpp:625
attr->key = "outputs";
attr->list.reset(new ListValueT);
attr->list->s.resize(outputNames.size());
for (int i=0; i<outputNames.size(); ++i) {
    attr->list->s[i] = std::string("t") + std::to_string(info.outputs[i]);
}

随后发生主图替换：

// tools/cpp/compilefornpu.cpp:1124
for (int moduleIndex=0; moduleIndex<subModulesInfo.size(); ++moduleIndex) {
    auto moduleInfo = subModulesInfo[moduleIndex];
    if (moduleInfo.isBreak) {
        continue;
    }
    for (auto& index : moduleInfo.opList) {
        dstNet->oplists[index].reset();
    }
    dstNet->oplists[moduleInfo.opList[0]] = std::move(npuOps[moduleIndex]);
}

替换关系如下：

原始连续 op 区间:
  opA -> opB -> opC

替换后:
  Plugin(type="QNN", inputs=原区间输入, outputs=原区间输出)

然后再调用 _reIndexTensor(...) 和 _reOrderOp(...) 清理未使用 tensor，并重新拓扑排序：

1
2
3

// tools/cpp/compilefornpu.cpp:1140
_reIndexTensor(dstNet.get());
_reOrderOp(dstNet.get());

3.7 onForward 生成 graph 材料

_compileSubModule(...) 里的 onForward(io.inputs) 走的是一次真实的 MNN 模块执行入口，但在 MNN_CONVERT_QNN 后端下，执行的重点不是计算数值结果，而是触发 QNN graph 的构建和记录。

完整调用关系可以看成：

_compileSubModule(...)
├── RuntimeManager(type = MNN_CONVERT_QNN)
├── rtmgr->setCache("qnn/graph0")
│   └── QnnRuntime::onSetCachePath(...)
│       └── QNNConvertor::OutputDir = "qnn/graph0"
├── Module::load(...)
└── m->onForward(io.inputs)
    └── StaticModule::onForward(...)
        ├── Variable::compute(inputs)
        ├── StaticModule::_resize(inputs)
        │   └── Session::resize()
        │       ├── Pipeline::encode(...)
        │       │   └── 把 ScheduleInfo 整理成 command buffer
        │       └── Pipeline::allocMemory(...)
        │           ├── QnnBackend::onResizeBegin()
        │           │   └── graphCreate(...)
        │           │       └── QNNConvertor::RecordBegin(...)
        │           ├── Execution::onResize(...)
        │           │   └── QNNCommonExecution::onEncode(...)
        │           │       ├── tensorCreateGraphTensor(...)
        │           │       │   └── QNNConvertor::RecordTensor(...)
        │           │       └── graphAddNode(...)
        │           │           └── QNNConvertor::RecordNode(...)
        │           └── QnnBackend::onResizeEnd()
        │               └── graphFinalize(...)
        │                   └── QNNConvertor::RecordEnd()
        └── StaticModule::_execute()
            └── Session::run()
                └── QNN convert 模式下 graphExecute(...) 不走真实 QNN 执行

创建 RuntimeManager 时，config.type = gNPUType。QNN 导出场景下，这个类型就是 MNN_CONVERT_QNN；setCache(path) 传入的是当前子图 graph 源目录，例如 qnn/graph0：

// tools/cpp/compilefornpu.cpp:470
MNN::ScheduleConfig config;
config.type = gNPUType;
std::shared_ptr<MNN::Express::Executor::RuntimeManager> rtmgr(
    MNN::Express::Executor::RuntimeManager::createRuntimeManager(config));
rtmgr->setExternalFile((srcpath + ".weight").c_str());
rtmgr->setCache(path.c_str());

setCache(path) 最终会进入 QnnRuntime::onSetCachePath(...)，并把这个路径记录到 QNNConvertor::OutputDir。后续所有 RecordTensor(...) / RecordNode(...) 写文件时都会落到这个目录：

// source/backend/qnn/backend/QNNBackend.cpp:1726
bool QnnRuntime::onSetCachePath(const char* path, int mode) {
#ifdef ENABLE_QNN_CONVERT_MODE
    MNN_ASSERT(path != nullptr);
    QNNConvertor::OutputDir = std::string(path);
    MNNCreateDir(path);
#endif
    return true;
}

onForward(io.inputs) 进入 StaticModule 后，先根据 io.inputs 里的真实输入张量更新子图输入 shape。_resize(...) 里会把外部 VARP 对应的 tensor 形状同步到 mInputTensors，一旦 shape 变化就标记 Session 需要 resize：

// express/module/StaticModule.cpp:530
if (_resizeTensor(mInputTensors[i], inputTensor, mSession.get(), nullptr)) {
    mSession->setNeedResize();
}
...
code = mSession->resize();

所以 testdir/1 和 testdir/<chunk_size> 会在这里进入 Session::resize()，分别生成 decode / prefill 两份 graph 材料。

Session::resize() 接着会先调用 encode，再调用 allocMemory：

// source/core/Session.cpp:285
if (mNeedResize) {
    bool debug = mCallBackMode == Interpreter::Session_Debug;
    for (auto& iter : mPipelines) {
        auto error = iter->encode(debug, permitCodegen);
        ...
    }
    mNeedResize = false;
    mNeedMalloc = true;
    firstMalloc = true;
}
if (mNeedMalloc) {
    for (auto& iter : mPipelines) {
        auto error = iter->allocMemory(firstMalloc, forbidReplace);
        ...
    }
}

Pipeline::encode(...) 的作用是把 ScheduleInfo 里的 op / tensor 依赖整理成 MNN 内部的 command buffer。后续 allocMemory(...) 会基于这些 command 创建后端算子 Execution，并调用每个 Execution 的 onResize(...)：

// source/core/Pipeline.cpp:537
static ErrorCode _createExecutions(
    Schedule::PipelineInfo& mInfo,
    const std::string& externalFile,
    std::vector<std::shared_ptr<BufferStorage>>& extraStorage) {
    ...
    iter.execution.reset(OpCommonUtils::createExecutionWithExternal(
        mBackend.get(), iter.inputs, iter.outputs, iter.op, &loader, tmpStorage));
}

// source/core/Pipeline.cpp:962
mBackend->onResizeBegin();
...
auto code = iter.execution->onResize(iter.workInputs, iter.workOutputs);
...
auto code = mBackend->onResizeEnd();

在 QNN 后端下，这些 Execution 通常就是对应的 QNN 执行器，例如 QNNConvolution。后续会在 onResize() 里把它们编码成 QNN graph 节点。

onResize() 前后还会配合两个 backend 生命周期回调：QnnBackend::onResizeBegin() 创建 QNN graph；QnnBackend::onResizeEnd() finalize graph：

// source/backend/qnn/backend/QNNBackend.cpp:1141
void QnnBackend::onResizeBegin() {
    clean();
    createContextAndGraph();
    return;
}

// source/backend/qnn/backend/QNNBackend.cpp:1147
ErrorCode QnnBackend::onResizeEnd() {
    buildOutputCast();
    buildOutputDequant();
    finalizeGraph();
    ...
}

QNN convert 模式的“记录动作”是通过 QNN API 函数表替换实现的。QNN_INTERFACE_VER_TYPE 本身是一张函数表，QnnBackend 后续调用 graphCreate(...)、graphAddNode(...)、tensorCreateGraphTensor(...) 时，都是从 mQnnInterface 这张表里取函数。

在普通 QNN 推理模式下，createQnnContext() 会从真实 QNN SDK 里拿 interface provider；在 ENABLE_QNN_CONVERT_MODE 下，qnnInterface 会被设置成 MNN 自己定义的 gQnnConvertorInterface：

// source/backend/qnn/backend/QNNBackend.cpp:43
#ifndef ENABLE_QNN_CONVERT_MODE
{
    QnnInterface_t** interfaceProviders = nullptr;
    uint32_t numProviders = 0;
    if (QNN::QnnInterface_getProviders((const QnnInterface_t***)&interfaceProviders, &numProviders) != QNN_SUCCESS) {
        ...
    }
    ...
    qnnInterface = interfaceProviders[pIdx]->QNN_INTERFACE_VER_NAME;
}
#else
    qnnInterface = QNN::gQnnConvertorInterface;
#endif

QnnRuntime::create(...) 会把 gContext.interface 传进 QnnRuntime，构造函数里再保存到 mQnnInterface：

// source/backend/qnn/backend/QNNBackend.cpp:1711
QnnRuntime* QnnRuntime::create(const Backend::Info& info) {
    if (QNN::gContext.deviceHandle == nullptr){
        QNN::createQnnContext();
    }
    return new QnnRuntime(info, gContext.interface, gContext.logHandle, gContext.backendHandle, gContext.deviceHandle);
}

// source/backend/qnn/backend/QNNBackend.cpp:1635
QnnRuntime::QnnRuntime(
    const Backend::Info& info,
    QNN_INTERFACE_VER_TYPE qnnInterface,
    Qnn_LogHandle_t qnnLogHandle,
    Qnn_BackendHandle_t qnnBackendHandle,
    Qnn_DeviceHandle_t qnnDeviceHandle) {
    ...
    mQnnInterface = qnnInterface;
}

所以 QnnBackend 里的调用代码不需要区分“真实 SDK”还是“离线导出”。它仍然写成：

// source/backend/qnn/backend/QNNBackend.cpp:1489
CALL_QNN(mRuntime->mQnnInterface.graphAddNode(mQnnGraphHandle, opConfig));

// source/backend/qnn/backend/QNNBackend.cpp:1532
CALL_QNN(mRuntime->mQnnInterface.tensorCreateGraphTensor(mQnnGraphHandle, staticTensor));

区别只在 mQnnInterface 指向哪张函数表。gQnnConvertorInterface 把这些 QNN API 槽位填成了 convertor 函数：

// source/backend/qnn/convertor/QNNConvertorInterface.cpp:96
QNN_INTERFACE_VER_TYPE gQnnConvertorInterface = {
    ...
    /* graphCreate */                            QnnConvertorGraph_Create,
    /* graphAddNode */                           QnnConvertorGraph_AddNode,
    /* graphFinalize */                          QnnConvertorGraph_Finalize,
    ...
    /* tensorCreateGraphTensor */                QnnConvertorTensor_CreateGraphTensor,
    ...
};

真实 QNN SDK 返回的 interface 和 gQnnConvertorInterface 是同一个类型：QNN_INTERFACE_VER_TYPE。这个类型本质上是一组函数指针槽位，只要每个槽位填进去的函数签名匹配，后续调用方就不需要知道这个函数来自真实 QNN SDK，还是来自 MNN 的 convertor。

可以用一个简化版结构理解：

struct QnnInterfaceLike {
    Qnn_ErrorHandle_t (*graphCreate)(...);
    Qnn_ErrorHandle_t (*graphAddNode)(Qnn_GraphHandle_t graphHandle, Qnn_OpConfig_t opConfig);
    Qnn_ErrorHandle_t (*graphFinalize)(...);
    Qnn_ErrorHandle_t (*tensorCreateGraphTensor)(Qnn_GraphHandle_t graph, Qnn_Tensor_t* tensor);
};

真实 QNN SDK 会提供一张类似这样的表：

QnnInterfaceLike realQnnInterface = {
    QnnGraph_Create,
    QnnGraph_AddNode,
    QnnGraph_Finalize,
    QnnTensor_CreateGraphTensor,
};

而 MNN convert 模式自己构造了一张同类型的表：

QnnInterfaceLike convertInterface = {
    QnnConvertorGraph_Create,
    QnnConvertorGraph_AddNode,
    QnnConvertorGraph_Finalize,
    QnnConvertorTensor_CreateGraphTensor,
};

QnnBackend 后续只持有 mQnnInterface，调用时等价于：

1
2

auto fn = mRuntime->mQnnInterface.graphAddNode;
fn(mQnnGraphHandle, opConfig);

如果 mQnnInterface 保存的是 gQnnConvertorInterface，这里的 fn 就是 QnnConvertorGraph_AddNode，调用链等价于：

mRuntime->mQnnInterface.graphAddNode(...)
    == gQnnConvertorInterface.graphAddNode(...)
    == QnnConvertorGraph_AddNode(...)
    -> QNNConvertor::RecordNode(opConfig)

这些 convertor 函数不会真正调用 QNN SDK，而是转成 QNNConvertor::Record*：

// source/backend/qnn/convertor/QNNConvertorInterface.cpp:58
Qnn_ErrorHandle_t QnnConvertorGraph_Create(...) {
    *graphHandle = NOTNULL;
    QNNConvertor::RecordBegin(graphName);
    return QNN_SUCCESS;
}

// source/backend/qnn/convertor/QNNConvertorInterface.cpp:76
Qnn_ErrorHandle_t QnnConvertorGraph_AddNode(Qnn_GraphHandle_t graphHandle, Qnn_OpConfig_t opConfig) {
    QNNConvertor::RecordNode(opConfig);
    return QNN_SUCCESS;
}

// source/backend/qnn/convertor/QNNConvertorInterface.cpp:90
Qnn_ErrorHandle_t QnnConvertorTensor_CreateGraphTensor(Qnn_GraphHandle_t graph, Qnn_Tensor_t* tensor) {
    QNNConvertor::RecordTensor(tensor);
    return QNN_SUCCESS;
}

QNN convert 模式复用了原来的 backend 建图路径，同时把 QNN SDK 函数表换成了 convertor 函数表。

每个 QNN Execution 的 onResize(...) 会继续调用自己的 onEncode(...)，把当前 MNN op 翻译成 QNN tensor 和 QNN node。公共入口在 QNNCommonExecution：

// source/backend/qnn/execution/QNNCommonExecution.cpp:19
ErrorCode QNNCommonExecution::onResize(
    const std::vector<Tensor *> &inputs,
    const std::vector<Tensor *> &outputs) {
    this->setNodeName(mOp, inputs, outputs);
    ErrorCode result = this->onEncode(inputs, outputs);
    ...
    return NO_ERROR;
}

例如卷积 op 会通过注册器创建 QNNConvolution：

// source/backend/qnn/execution/QNNConvolution.cpp:748
class QNNConvolutionCreator : public QnnBackend::Creator {
public:
    virtual QNNCommonExecution * onCreate(
        const std::vector<Tensor*>& inputs,
        const std::vector<Tensor*>& outputs,
        const MNN::Op* op,
        Backend* backend) const override {
        ...
        return new QNNConvolution(backend, op);
    }
};

REGISTER_QNN_OP_CREATOR(QNNConvolutionCreator, OpType_Convolution)

在具体 onEncode(...) 里，权重、bias、临时 tensor 会通过 createStaticTensor(...) / createStaticFloatTensor(...) 注册成 QNN tensor，算子本身会通过 addNodeToGraph(...) 注册成 QNN node：

// source/backend/qnn/execution/QNNCommonExecution.cpp:68
void QNNCommonExecution::createStaticTensor(
    const std::string & name,
    Qnn_DataType_t dataType,
    const std::vector<uint32_t> & dimensions,
    const void * buffer,
    Qnn_QuantizeParams_t quantizeParam) {
    std::string tensorName = mNodeName + "_" + name;
    std::shared_ptr<QNNTensorWrapper> tensorWrapper =
        QNNTensorWrapper::createStaticTensor(tensorName, dataType, dimensions, buffer, quantizeParam);
    mBackend->addStaticTensorToGraph(tensorWrapper->getNativeTensor());
    ...
}

// source/backend/qnn/execution/QNNCommonExecution.cpp:167
mBackend->addNodeToGraph(
    mOpConfigVersion,
    mNodeName.c_str(),
    mPackageName.c_str(),
    mNodeType.c_str(),
    mParams,
    mInputs,
    mOutputs);

这些调用最终进入 QnnBackend，再通过 mQnnInterface 转到 convertor 函数表里的 tensorCreateGraphTensor(...) 和 graphAddNode(...)：

// source/backend/qnn/backend/QNNBackend.cpp:1472
void QnnBackend::addNodeToGraph(
    Qnn_OpConfigVersion_t version,
    const char* nodeName,
    const char* packageName,
    const char* nodeType,
    std::vector<Qnn_Param_t> & params,
    std::vector<Qnn_Tensor_t> & inputs,
    std::vector<Qnn_Tensor_t> & outputs) {
    ...
    CALL_QNN(mRuntime->mQnnInterface.graphAddNode(mQnnGraphHandle, opConfig));
}

// source/backend/qnn/backend/QNNBackend.cpp:1530
void QnnBackend::addStaticTensorToGraph(Qnn_Tensor_t * staticTensor) {
    MNN_ASSERT(staticTensor->v1.type == QNN_TENSOR_TYPE_STATIC);
    CALL_QNN(mRuntime->mQnnInterface.tensorCreateGraphTensor(mQnnGraphHandle, staticTensor));
}

QNNConvertor 的 RecordBegin(...) / RecordTensor(...) / RecordNode(...) / RecordEnd(...) 会把这些调用整理成内部 QNNCommand。每个 QNNCommand 再交给 Translate(cmd)，写进当前 graph 的 .cpp：

// source/backend/qnn/convertor/QNNConvertor.cpp:57
void QNNConvertor::RecordBegin(const char* graphName) {
    MNN_ASSERT(!(QNNConvertor::OutputDir.empty()));
    QNNTranslator::GraphNameSymbol = GetLastDirName(QNNConvertor::OutputDir);
    ...
    std::string cppFilePath = MNNFilePathConcat(
        QNNConvertor::OutputDir,
        QNNTranslator::GraphNameSymbol + ".cpp");
    QNNConvertor::CppFilePointer = std::fopen(cppFilePath.c_str(), "w");
}

// source/backend/qnn/convertor/QNNConvertor.cpp:79
void QNNConvertor::RecordTensor(const Qnn_Tensor_t * tensor) {
    ...
    QNNConvertor::Translate(cmd);
    if (cmd.commandTensor.type == Qnn_Convertor_Tensor_t::TENSOR_STATIC) {
        QNNConvertor::DumpBuffer(
            cmd.commandTensor.name,
            cmd.commandTensor.clientBuf.data,
            cmd.commandTensor.clientBuf.dataSize);
    }
}

// source/backend/qnn/convertor/QNNConvertor.cpp:124
void QNNConvertor::RecordNode(const Qnn_OpConfig_t & opConfig) {
    ...
    QNNConvertor::Translate(cmd);
}

每个记录函数都包括Translate(cmd)方法，其本身分两步：

调用 QNNTranslator::TranslateCommand(cmd)，把 QNNCommand 翻译成一组 C++ 源码行；
把这些源码行追加到 CppBuffer，再通过 fwrite(...) 写入 CppFilePointer。

// source/backend/qnn/convertor/QNNConvertor.cpp:159
void QNNConvertor::Translate(const QNNCommand & cmd) {
    std::vector<std::string> cppLines = QNNTranslator::TranslateCommand(cmd);
    for (const std::string& line : cppLines) {
        QNNConvertor::CppBuffer.append(line);
        QNNConvertor::CppBuffer.push_back('\n');
    }
    size_t written = std::fwrite(
        QNNConvertor::CppBuffer.data(),
        1,
        QNNConvertor::CppBuffer.size(),
        QNNConvertor::CppFilePointer);
    ...
    QNNConvertor::CppBuffer.clear();
}

TranslateCommand(...) 按命令类型分发：

// source/backend/qnn/convertor/QNNConvertor.cpp:195
std::vector<std::string> QNNTranslator::TranslateCommand(const QNNCommand & cmd) {
    switch (cmd.type) {
        case QNNCommandTypeBegin:
            return QNNTranslator::TranslateBegin();
        case QNNCommandTypeTensor:
            return QNNTranslator::TranslateTensor(cmd.commandTensor);
        case QNNCommandTypeNode:
            return QNNTranslator::TranslateNode(cmd.commandNode);
        case QNNCommandTypeEnd:
            return QNNTranslator::TranslateEnd();
        ...
    }
}

这几类命令对应的输出内容是：

命令	翻译函数	写入 `.cpp` 的内容
`QNNCommandTypeBegin`	`TranslateBegin()`	`#include`、`QnnModel_composeGraphs(...)` 函数头、`QnnModel graph*` 初始化
`QNNCommandTypeTensor`	`TranslateTensor(...)`	`Qnn_Tensor_t` 定义、维度、数据类型、量化参数、`addTensor(...)`
`QNNCommandTypeNode`	`TranslateNode(...)`	node 的 params / inputs / outputs 数组，以及 `graph.addNode(...)`
`QNNCommandTypeEnd`	`TranslateEnd()`	`getGraphInfoFromModels(...)`、`QnnModel_freeGraphsInfo(...)` 和函数收尾

以 tensor 和 node 为例，TranslateTensor(...) 会生成 Qnn_Tensor_t 并在需要时写入 addTensor(...)：

// source/backend/qnn/convertor/QNNConvertor.cpp:254
std::vector<std::string> QNNTranslator::TranslateTensor(const QNNCommandTensor& cmdT) {
    ...
    result.push_back("  Qnn_Tensor_t " + tensorNameSymbol + " = QNN_TENSOR_INIT;");
    ...
    result.push_back("  " + tensorNameSymbol + ".v1.name = \"" + sName +"\";");
    result.push_back("  " + tensorNameSymbol + ".v1.type = " + QNNTranslator::MapTensorType(cmdT.type) + ";");
    result.push_back("  " + tensorNameSymbol + ".v1.dataType = " + QNNTranslator::MapDataType(cmdT.dataType) + ";");
    ...
    if (shouldBeAdded) {
        result.push_back("  VALIDATE(" + QNNTranslator::GraphNameSymbol + ".addTensor(\"" + sName + "\", " + tensorNameSymbol + "), err);");
    }
    return result;
}

TranslateNode(...) 会生成 params_*、inputs_*、outputs_*，再写一行 addNode(...)：

// source/backend/qnn/convertor/QNNConvertor.cpp:303
std::vector<std::string> QNNTranslator::TranslateNode(const QNNCommandNode& cmdN) {
    ...
    APPEND_VECTOR(result, QNNTranslator::TranslateNodeParamArray(...));
    APPEND_VECTOR(result, QNNTranslator::TranslateNodeInputArray(...));
    APPEND_VECTOR(result, QNNTranslator::TranslateNodeOutputArray(...));
    result.push_back("  VALIDATE(" + QNNTranslator::GraphNameSymbol + ".addNode(QNN_OPCONFIG_VERSION_1, \"" + sName + "\", \"" + std::string(cmdN.packageName) + "\", \"" + std::string(cmdN.typeName) + "\",");
    ...
    return result;
}

.raw 文件不是 Translate(cmd) 写的，而是 RecordTensor(...) 遇到 TENSOR_STATIC 时额外调用 DumpBuffer(...) 写出来：

// source/backend/qnn/convertor/QNNConvertor.cpp:117
if (cmd.commandTensor.type == Qnn_Convertor_Tensor_t::TENSOR_STATIC) {
    QNNConvertor::DumpBuffer(
        cmd.commandTensor.name,
        cmd.commandTensor.clientBuf.data,
        cmd.commandTensor.clientBuf.dataSize);
}

// source/backend/qnn/convertor/QNNConvertor.cpp:173
void QNNConvertor::DumpBuffer(const char * name, const void * buffer, size_t size) {
    std::string dataPath = MNNFilePathConcat(QNNConvertor::OutputDir, std::string(name) + ".raw");
    FILE* fp = std::fopen(dataPath.c_str(), "wb");
    ...
    std::fwrite(buffer, 1, size, fp);
}

所以 Step2 生成的 graph 源目录可以这样理解：

graph*.cpp：RecordBegin/RecordTensor/RecordNode/RecordEnd -> Translate(cmd) 逐段写出来的 QNN model 源码；
*.raw：RecordTensor(...) 遇到 static tensor 时，把常量 buffer 单独 dump 出来的二进制数据。

因此这一句代码：

1
2

// tools/cpp/compilefornpu.cpp:479
auto predict = m->onForward(io.inputs);

会让 QNN 后端看到具体输入 / 输出 tensor 形状、常量权重和每个 op 的参数，并把这些信息记录成 qnn/graph*/graph*.cpp 和 qnn/graph*/*.raw。

3.8 合并多 shape

因为 testdir 有 decode 和 prefill 两组输入，main 会为每组输入都生成一个 dstNet：

// tools/cpp/compilefornpu.cpp:1040
for (int inputIndex=0; inputIndex < inputs.size(); ++inputIndex) {
    ...
    allNets.emplace_back(std::move(dstNet));
}

第一组 shape 生成 graph0，第二组 shape 会生成类似 graph1_0 的 graph 名：

// tools/cpp/compilefornpu.cpp:1094
if (inputIndex == 0) {
    srcPath = gCacheDir + "/" + gGraphName +  std::to_string(npuIndex);
    graphicName = gGraphName +  std::to_string(npuIndex);
} else {
    srcPath = gCacheDir + "/" + gGraphName + std::to_string(inputIndex) + "_" +  std::to_string(npuIndex);
    graphicName = gGraphName + std::to_string(inputIndex) + "_" +  std::to_string(npuIndex);
}

最后 _fuse(...) 会把后续 shape 的 Plugin attr 合并回第一组 dstNet：

// tools/cpp/compilefornpu.cpp:1145
auto dstNet = allNets[0].get();
for (int i=1; i<allNets.size(); ++i) {
    _fuse(dstNet, allNets[i].get());
    allNets[i].reset();
}

_fuse(...) 会跳过 inputs / outputs，只追加 allGraphName、allInputShape、o_<shapeIndex>_<outputIndex> 这类 shape 相关 attr：

// tools/cpp/compilefornpu.cpp:690
for (auto&& srcAttr : src->attr) {
    if (srcAttr->key == "inputs" || srcAttr->key == "outputs") {
        continue;
    }
    auto dstIter = dstKeys.find(srcAttr->key);
    if (dstIter == dstKeys.end()) {
        dst->attr.emplace_back(std::move(srcAttr));
        continue;
    }
    if (dstIter->second->list != nullptr && srcAttr->list != nullptr) {
        dstIter->second->list->s.insert(dstIter->second->list->s.end(), srcAttr->list->s.begin(), srcAttr->list->s.end());
        dstIter->second->list->i.insert(dstIter->second->list->i.end(), srcAttr->list->i.begin(), srcAttr->list->i.end());
    }
}

这一步结束后，qnn/llm.mnn 里的同一个 Plugin 会同时保存 decode / prefill 两组 graph：

Plugin(type="QNN")
├── path: qnn/graph0.bin
├── allGraphName: [graph0, graph1_0, ...]
├── allInputShape: [decode 输入 shape..., prefill 输入 shape...]
└── o_0_0 / o_1_0 / ...: 不同 shape 下的输出描述

3.9 产物

Step2 结束时，真正落盘的产物有三类：

tmp/
├── qnn/
│   ├── llm.mnn                 # 插入 Plugin(type="QNN") 后的主图
│   ├── graph0/                 # 第一组 shape 的 QNN graph 源目录
│   │   ├── graph0.cpp
│   │   └── *.raw
│   └── graph1_0/               # 第二组 shape 的 QNN graph 源目录
│       ├── graph1_0.cpp
│       └── *.raw
└── npu_postreat.json           # Step3 合成 context binary 的 merge 配置

4. npu_postreat.json 的作用

compilefornpu 还会写 npu_postreat.json，里面最重要的是 merge：

{
  "type": "QNN",
  "merge": {
    "qnn/graph0.bin": [
      "qnn/graph0",
      "qnn/graph1_0"
    ]
  },
  "cache": "qnn"
}

merge 的含义是：

`1`	`最终生成的 QNN binary -> 参与合并的 graph 源目录列表`

一个 Plugin 可能对应多组 shape。离线阶段先为每个 shape 生成 graph 源目录，再通过 merge 合成一个 context binary。运行时通过 shapeIndex 选择 .bin 里的具体 graph handle。

5. Step3：生成 context binary

convert(args) 的 Step3 调用 compile_qnn(args)：

1
2
3

# transformers/llm/export/npu/generate_llm_qnn.py:81
print("Step3: Compile to QNN")
compile_qnn(args)

compile_qnn(args) 会从 args.mnn_path 反推出源码树里的 source/backend/qnn/npu_convert.py 路径，并在 tmp 目录下执行它：

# transformers/llm/export/npu/generate_llm_qnn.py:39
def compile_qnn(args):
    exe = os.path.join(os.getcwd(), args.mnn_path, "..", "source", "backend", "qnn", "npu_convert.py")
    cache = os.path.join(os.getcwd(), args.cache_path)
    process = subprocess.Popen(
        "python3 " + exe + ' npu_postreat.json %d ' %args.soc_id + ' ' + args.dsp_arch,
        cwd = cache,
        shell=True
    )

命令展开后是：

python3 <repo>/source/backend/qnn/npu_convert.py \
  npu_postreat.json \
  <soc_id> \
  <dsp_arch>

到 Step3 时，compilefornpu 已经把 MNN 子图导出成 QNN graph 的源码材料。npu_convert.py 会继续调用 QNN SDK，把这些材料编译成运行时可直接加载的 HTP context binary。

整体调用关系是：

npu_postreat.json
└── merge: qnn/graph0.bin -> [qnn/graph0, qnn/graph1_0, ...]  # 一个 Plugin 的多组 shape graph
    ├── for each graph 源目录
    │   ├── tar *.raw -> graph*.bin                            # 打包 graph 依赖的 raw 常量数据
    │   ├── qnn-model-lib-generator
    │   │   ├── -c graph*.cpp                                  # QNN graph C++ 源码
    │   │   ├── -b graph*.bin                                  # 上一步打包的 raw 数据
    │   │   └── -> x86_64-linux-clang/libgraph*.so             # 生成 QNN model library
    │   └── 记录 graph name 和 lib 路径
    │
    └── qnn-context-binary-generator
        ├── --model libgraph0.so,libgraph1_0.so,...             # 多个 shape graph 一起写入 context
        ├── --backend <QNN_SDK_ROOT>/lib/.../libQnnHtp.so        # 目标 HTP backend
        ├── --config_file ./context_config.json                 # 指向 HTP backend extension 配置
        ├── --binary_file graph0
        └── --output_dir qnn
            └── qnn/graph0.bin                                  # 最终 Plugin 加载的 context binary

5.1 读取后处理配置

npu_convert.py 一开始从环境变量和命令参数读取输入：

# source/backend/qnn/npu_convert.py:8
qnn_sdk = os.environ["QNN_SDK_ROOT"]
with open(sys.argv[1]) as f:
    post_treat = json.load(f)
soc_id = int(sys.argv[2])
dsp_arch = sys.argv[3]

sys.argv[1] 就是 npu_postreat.json。soc_id 和 dsp_arch 来自导出命令参数，用来写入 HTP backend 的设备配置。

随后脚本定位 QNN SDK 的两个工具，并取出 merge：

# source/backend/qnn/npu_convert.py:15
qnn_bin_path = os.path.join(qnn_sdk, 'bin', 'x86_64-linux-clang')
qnnModelLibGenerator = os.path.join(qnn_bin_path, 'qnn-model-lib-generator')
qnnContextBinaryGenerator = os.path.join(qnn_bin_path, 'qnn-context-binary-generator')
merges = post_treat["merge"]

merge 的 key 是最终要生成的 context binary 路径，例如 qnn/graph0.bin；value 是这个 binary 内要合并的 graph 源目录，例如 qnn/graph0 和 qnn/graph1_0。

5.2 写 QNN context 配置

脚本会生成两个配置文件。

第一个是 context_config.json，它只负责告诉 qnn-context-binary-generator 去哪里加载 HTP backend extension：

# source/backend/qnn/npu_convert.py:23
context_config = {
    "backend_extensions": {
        "shared_library_path": os.path.join(qnn_sdk, "lib","x86_64-linux-clang","libQnnHtpNetRunExtensions.so"),
        "config_file_path": "./htp_backend_extensions.json"
    }
}
htp_so = os.path.join(qnn_sdk, 'lib','x86_64-linux-clang','libQnnHtp.so')

第二个是 htp_backend_extensions.json 的主体配置：

# source/backend/qnn/npu_convert.py:33
htp_backend_extensions = {
    "graphs": [
        {
            "vtcm_mb": 8,
            "O": 3.0,
            "fp16_relaxed_precision": 1,
            "hvx_threads": 4
        }
    ],
    "devices": [
        {
            "soc_id": soc_id,
            "dsp_arch": dsp_arch,
            "cores": [
                {
                    "core_id": 0,
                    "perf_profile": "burst",
                    "rpc_control_latency": 100
                }
            ]
        }
    ],
    "context": {
        "weight_sharing_enabled": True
    }
}

这些配置会进入 QNN context binary 生成过程。graphs 里是 HTP graph 编译参数；devices 里绑定目标 SoC 和 DSP 架构；weight_sharing_enabled 表示同一个 context 里的多个 graph 可以共享权重。

5.3 生成每个 graph 的 model library

接下来脚本遍历 post_treat["merge"]。每个 key 对应一个最终 .bin，每个 src 对应一个 graph 源目录：

# source/backend/qnn/npu_convert.py:60
for key in post_treat["merge"]:
    srcs = merges[key]
    dst = key
    dstname = key.split('/')
    dstname = dstname[len(dstname)-1]
    dstname = dstname.replace('.bin', '')

以 qnn/graph0.bin -> [qnn/graph0, qnn/graph1_0] 为例，dstname 会变成 graph0。这个名字后续会作为 qnn-context-binary-generator --binary_file graph0 的参数。

然后对每个 graph 源目录打包 .raw：

# source/backend/qnn/npu_convert.py:69
for i,src in enumerate(srcs):
    graphname = src.split('/')
    graphname = graphname[len(graphname)-1]
    graphs.append(graphname)
    workdir = os.path.join(os.getcwd(), src)
    workdirs.append(workdir)
    print(subprocess.run("tar -cf " + graphname + '.bin' + ' *.raw', cwd=workdir, capture_output=True, text=True, shell=True))

graphname 是 graph0、graph1_0 这样的名字。workdir 目录里已经有 Step2 导出的 graphname.cpp 和若干 .raw 文件，.raw 是 QNN graph 依赖的常量数据。脚本先把这些 .raw 打包成 graphname.bin，给下一步的 qnn-model-lib-generator 使用。

随后调用 qnn-model-lib-generator：

# source/backend/qnn/npu_convert.py:80
compile_cmd = 'python3 ' + qnnModelLibGenerator + ' -c ' + os.path.join(workdir, graphname + '.cpp') + ' -b ' + os.path.join(workdir, graphname + '.bin') + ' -t x86_64-linux-clang -o ' + workdir
print(os.popen(compile_cmd).read())
libs.append(os.path.join(workdir, 'x86_64-linux-clang', 'lib' + graphname + '.so'))

这一步的输入是：

graphname.cpp：Step2 由 QNN convert backend 导出的 graph 构建代码；
graphname.bin：刚才打包出来的 raw 常量数据；
x86_64-linux-clang：生成 host 侧工具可加载的 model library。

输出是 workdir/x86_64-linux-clang/libgraphname.so。这个 .so 还不是运行时最终加载的产物，它只是 qnn-context-binary-generator 的输入。

5.4 合成 context binary

同一个 key 下的所有 graph 源目录都编译出 libgraph*.so 后，脚本会把 graph 名字写入 htp_backend_extensions.json：

# source/backend/qnn/npu_convert.py:85
htp_backend_extensions['graphs'][0]['graph_names'] = graphs
with open('htp_backend_extensions.json', 'w') as f:
    f.write(json.dumps(htp_backend_extensions, indent=4))

graphs 顺序很重要。compilefornpu 写入 Plugin attr 时，也会保存同一组 allGraphName：

// tools/cpp/compilefornpu.cpp:556
attr->key = "allGraphName";
attr->list.reset(new ListValueT);
attr->list->s = {graphicName};

多 shape 合并时，_fuse(...) 会把后续 shape 的 allGraphName 追加进去。运行时 QNN Plugin 会读取 allGraphName，并按这个顺序重新排列 context binary 里的 graph 信息：

// source/backend/qnn/backend/QNNBackend.cpp:913
std::vector<std::string> allGraphName;
auto allGraphNameAttr = ctx->getAttr("allGraphName");
if (allGraphNameAttr && allGraphNameAttr->list() && allGraphNameAttr->list()->s()) {
    auto graphNames = allGraphNameAttr->list()->s();
    for (int i = 0; i < graphNames->size(); ++i) {
        allGraphName.push_back(graphNames->GetAsString(i)->str());
    }
}

最后脚本把所有 libgraph*.so 拼成逗号分隔的 --model 参数，调用 qnn-context-binary-generator：

# source/backend/qnn/npu_convert.py:88
libsStr = ""
for i in range(0, len(libs)):
    if i > 0:
        libsStr+=','
    libsStr += libs[i]
print(os.popen(qnnContextBinaryGenerator + ' --model ' + libsStr + ' --backend '+ htp_so + ' --binary_file ' + dstname + ' --config_file ./context_config.json ' + ' --output_dir ' + cache_dir).read())

展开后大致是：

qnn-context-binary-generator \
  --model <tmp>/qnn/graph0/x86_64-linux-clang/libgraph0.so,<tmp>/qnn/graph1_0/x86_64-linux-clang/libgraph1_0.so \
  --backend <QNN_SDK_ROOT>/lib/x86_64-linux-clang/libQnnHtp.so \
  --binary_file graph0 \
  --config_file ./context_config.json \
  --output_dir qnn

输出目录由 npu_postreat.json 里的 "cache": "qnn" 决定：

# source/backend/qnn/npu_convert.py:19
cache_dir = 'res'
if 'cache' in post_treat:
    cache_dir = post_treat['cache']

最终产物会写到：

`1`	`tmp/qnn/graph0.bin`

这就是 Plugin attr 里的 path: qnn/graph0.bin 对应的文件。

5.5 运行时使用 binary

运行时 QNN Plugin 初始化时，会从 Plugin attr 里读 path 和 allGraphName，然后调用 RawExecutorWrapper::compileModel(...)：

// source/backend/qnn/backend/QNNBackend.cpp:911
auto path = MNNFilePathConcat(ctx->dir_path(), ctx->getAttr("path")->s()->str());
...
mRawExecutor.reset(new RawExecutorWrapper());
return mRawExecutor->compileModel(path, binaryOffset, binarySize, allGraphName);

compileModel(...) 会读取 context binary，并通过 QNN API 从 binary 里恢复 context 和 graph handle：

// source/backend/qnn/backend/QNNBackend.cpp:797
CALL_QNN(QNN::gContext.systemInterface.systemContextGetBinaryInfo(systemContextHandle, buffer, size, &binaryInfo,&binarySize));
copyMetadataToGraphsInfo(binaryInfo, mGraphsInfo, mGraphCount);

// source/backend/qnn/backend/QNNBackend.cpp:816
CALL_QNN(QNN::gContext.interface.contextCreateFromBinary(QNN::gContext.backendHandle, QNN::gContext.deviceHandle, mQnnContextConfig, buffer, size, &mQnnContextHandle, mQnnProfileHandle));

然后按 allGraphName 的顺序取出每个 graph handle：

// source/backend/qnn/backend/QNNBackend.cpp:826
for (int i = 0; i < mGraphCount; ++i) {
    auto it = graphInfoMap.find(allGraphName[i]);
    MNN_ASSERT(it != graphInfoMap.end());
    sortedGraphsInfo[i] = it->second;
}
for (int i = 0; i < mGraphCount; i++) {
    CALL_QNN(QNN::gContext.interface.graphRetrieve(mQnnContextHandle, mGraphsInfo[i]->graphName, &(mQnnGraphHandleVec[i])));
}

所以 Step3 生成的 qnn/graph0.bin 不是普通权重文件，而是一个 QNN HTP context binary。它里面可以包含多个 graph，分别对应 decode / prefill 等不同输入 shape。执行时，Plugin 通过 shapeIndex 选择 mQnnGraphHandleVec[shapeIndex] 去调用 QNN graph。

6. Step4：移动产物并写 config_qnn.json

最后 convert(args) 调用 output_qnn(args) 做收尾：

1
2
3

# transformers/llm/export/npu/generate_llm_qnn.py:85
print("Step4: Move result file to ", args.model)
output_qnn(args)

output_qnn(args) 先把临时目录里的 qnn 移到模型目录（tmp/qnn -> <model_dir>/qnn）：

# transformers/llm/export/npu/generate_llm_qnn.py:47
def output_qnn(args):
    if os.path.exists(os.path.join(args.model, 'qnn')):
        shutil.rmtree(os.path.join(args.model, 'qnn'))
    shutil.move(os.path.join(args.cache_path, 'qnn'), os.path.join(args.model, 'qnn'))

然后脚本直接写出一个新的 config_qnn.json，不是读取 config.json 后做增量修改：

# transformers/llm/export/npu/generate_llm_qnn.py:51
config_npu = {
    "llm_model": "qnn/llm.mnn",
    "backend_type": "cpu",
    "thread_num": 1,
    "precision": "low",
    "chunk_limits":[args.chunk_size, 1],
    "memory": "low",
    "sampler_type": "penalty",
    "penalty": 1.1
}
with open(os.path.join(args.model, "config_qnn.json"), 'w') as f:
    f.write(json.dumps(config_npu, indent = 4))
shutil.rmtree(args.cache_path)

其中最关键的字段是：

{
  "llm_model": "qnn/llm.mnn",
  "chunk_limits": [128, 1]
}

实际运行时还需要确认 config_qnn.json 里有正常的运行配置，例如：

{
  "llm_model": "qnn/llm.mnn",
  "backend_type": "cpu",
  "thread_num": 1,
  "precision": "low",
  "chunk_limits": [128, 1],
  "memory": "low",
  "sampler_type": "penalty",
  "penalty": 1.1
}

这里 backend_type 写成 cpu 是正常的。外层 MNN 主图仍然由 CPU backend 执行；真正下沉到 QNN 的部分已经变成 Plugin(type="QNN")，运行时会由 Plugin 机制加载 qnn/*.bin 并调用 QNN graph。

7. 最终目录结构

完成后，模型目录会变成类似这样：

Qwen3-1.7B-MNN/
├── config.json
├── config_qnn.json
├── llm_config.json
├── tokenizer.txt
├── llm.mnn
├── llm.mnn.weight
└── qnn/
    ├── llm.mnn
    ├── graph0.bin
    └── graph*.bin

整个离线执行链路如下：

generate_llm_qnn.py 负责编排；
generateLlmIO 负责造多 shape 样本；
compilefornpu 负责切图、导出 QNN graph 材料并改写 MNN 主图；
npu_convert.py 负责调用 QNN SDK 生成最终 HTP context binary。

以 llm_demo 为例的 QNN 后端运行

Wed, 27 May 2026 12:00:00 +0800

QNN 后端运行

QNN 后端运行

以 transformers/llm/engine/demo/llm_demo.cpp 为例，在 Android 设备上执行 QNN 后端流程：服务器交叉编译 -> 构建 QNN 模型 -> adb push 推送到手机 -> 端侧设备运行。需要准备下面环境：

adb devices 能看到目标设备，本文测试设备为 adb connect 127.0.0.1:40404
ANDROID_NDK 已配置，参考交叉编译环境配置
QNN_SDK_ROOT 已配置，参考QNN环境配置

整体构建流程参考官方文档。

1. 环境

以下面环境为例：

开发机(编译设备)：Ubuntu 22.04
测试机(目标设备)：arm64-v8a + SM8750
QNN SDK：/root/qairt/2.40.0.251030
编译目录：project/android/build_64
手机测试目录：/data/local/tmp/mnn-llm-qnn
测试模型：taobao-mnn/Qwen3-1.7B-MNN

首先需要拉取仓库到编译设备,当前测试分支是8d9f6131ac3ea61cde7e1d0edab52f56c7420926：

`1`	`➜ git clone https://github.com/alibaba/MNN`

这次设备侧属性如下：

➜ adb connect 127.0.0.1:40404
➜ adb shell "cat /sys/devices/soc0/soc_id; getprop ro.soc.model; getprop ro.product.cpu.abi"
618
SM8750
arm64-v8a

在服务器准备原始测试模型Qwen3-1.7B-MNN，目录结构至少包含这些文件：

Qwen3-1.7B-MNN/
├── config.json         # 运行时配置 包括后端设置、线程数、采样参数等
├── llm_config.json     # 导出时写入的模型元信息
├── tokenizer.txt       # 分词器文件
├── llm.mnn             # 模型计算图
└── llm.mnn.weight      # 模型权重

建议使用hf-mirror镜像站下载：

wget https://hf-mirror.com/hfd/hfd.sh && chmod a+x hfd.sh # 下载工具脚本

export HF_ENDPOINT=https://hf-mirror.com # 设置 Hugging Face 镜像站点
./hfd.sh taobao-mnn/Qwen3-1.7B-MNN # 下载模型到当前目录

2. 交叉编译

QNN 后端的运行需要准备两类产物：

Android 设备侧运行的 llm_demo和所需的MNN编译产生动态库
导出的QNN模型和依赖的QNN动态库

2.1 交叉编译 `llm_demo`

QNN 版 llm_demo 编译时需要打开 MNN_QNN 和 MNN_WITH_PLUGIN。在编译设备执行：

# 要求 QNN_SDK_ROOT 已配置，指向 QAIRT SDK 根目录
cd ${MNN_ROOT}
cd project/android
mkdir -p build_64
cd build_64

# 交叉编译 Android arm64 版本的 QNN llm_demo
# 这里同步会编译模型转换工具，后续生成 QNN 模型时会用到
# 记住当前的目录
../build_64.sh -DMNN_QNN=ON -DMNN_WITH_PLUGIN=ON -DMNN_BUILD_LLM=ON -DMNN_LOW_MEMORY=ON

这次构建结束后，设备运行只用到了下面两个产物：

`1`	`ls -lh llm_demo libMNN.so`

2.2 导出 QNN 模型

导出QNN模型依赖主库编译产生的工具，需要先在服务器编译工具，注意这不是交叉编译

cd ${MNN_ROOT}
mkdir build && cd build
cmake .. -DMNN_QNN=ON -DMNN_QNN_CONVERT_MODE=ON -DMNN_BUILD_TOOLS=ON -DMNN_BUILD_LLM=ON
make -j256

MNN使用python脚本按 NPU 格式导出 MNN 模型。先安装python依赖：

cd ${MNN_ROOT}  
cd ./transformers/llm/export
conda create -n mnn python=3.11 -y
conda activate mnn
uv pip install -r requirements.txt

再从MNN模型目录导出 QNN 模型，参数说明参考, soc和Hexagon版本参考（这一步导出会出现部分导出错误的节点，MNN会把这部分计算交给CPU处理，导出没有失败）

cd ${MNN_ROOT}
cd transformers/llm/export
export MODEL_DIR=/data/HF_MODELS/Qwen3-1.7B-MNN
python3 npu/generate_llm_qnn.py \
  --model "$MODEL_DIR" \
  --soc_id=69 \
  --dsp_arch=v79 \
  --mnn_path ../../../build/
  # 最后的参数是前面服务器上产生编译工具的路径，脚本会调用工具生成 QNN 模型并放在 `qnn/` 目录下

直接下载的 taobao-mnn/Qwen3-1.7B-MNN 使用 tokenizer.txt，config_qnn.json 不需要额外写 tokenizer_file。如果是自己用 llmexport.py 导出的模型，分词器可能是 tokenizer.mtok，这时需要给 config_qnn.json 补上：

{
  "llm_model": "qnn/llm.mnn",
  "backend_type": "cpu",
  "thread_num": 1,
  "precision": "low",
  "chunk_limits": [
    128,
    1
  ],
  "memory": "low",
  "sampler_type": "penalty",
  "penalty": 1.1,
  "tokenizer_file": "tokenizer.mtok"
}

QNN 模型准备完成后，目录至少包含这些文件：

Qwen3-1.7B-MNN/
├── config_qnn.json     # QNN 运行配置
├── llm_config.json     # 导出时写入的模型元信息
├── tokenizer.txt       # 直接下载模型的分词器文件
├── llm.mnn.weight      # 模型权重，也包含 tie_embeddings 使用的 embedding 数据
└── qnn/
    ├── llm.mnn         # QNN Plugin 替代模型
    ├── graph0.bin
    ├── graph1.bin
    └── ...             # QNN 离线产物

config_qnn.json 里的 backend_type 通常仍然是 cpu。这是 QNN LLM 离线产物的运行方式：QNN 图已经封装进 qnn/llm.mnn，外层还是通过 CPU 后端加载 Plugin，本次 Qwen3-1.7B 生成的 qnn/ 目录约 3.3G。

3. 推送并运行

3.1 推送编译产物、模型和 QNN 依赖

llm_demo 不是静态单文件程序，除了可执行文件本身，还需要把 MNN 动态库、QNN 动态库、QNN 离线模型一起推送到手机。

下面命令按本次 SM8750/v79 测试环境整理, 按需要修改对应的环境变量：

export PHONE_DIR=/data/local/tmp/mnn-llm-qnn
export PHONE_MODEL_DIR=$PHONE_DIR/model/Qwen3-1.7B-MNN
export BUILD_DIR=/workspace/code/MNN/project/android/build_64
export MODEL_DIR=/data/HF_MODELS/Qwen3-1.7B-MNN
export QNN_SDK_ROOT=/root/qairt/2.40.0.251030
export HEXAGON_ARCH=79

# 创建手机侧目录
adb shell "rm -rf $PHONE_DIR && mkdir -p $PHONE_MODEL_DIR"

# 推送二进制和 MNN 动态库
# 如果是静态链接版本，llm_demo 会比较大，但不需要推其余动态库
adb push "$BUILD_DIR/llm_demo" "$PHONE_DIR/"
adb push "$BUILD_DIR/libMNN.so" "$PHONE_DIR/"
# adb push "$BUILD_DIR/libllm.so" "$PHONE_DIR/"
# adb push "$BUILD_DIR/libMNN_Express.so" "$PHONE_DIR/"

# 推送 QNN 运行库
adb push "$QNN_SDK_ROOT/lib/aarch64-android/libQnnHtp.so" "$PHONE_DIR/"
adb push "$QNN_SDK_ROOT/lib/aarch64-android/libQnnHtpV${HEXAGON_ARCH}Stub.so" "$PHONE_DIR/"
adb push "$QNN_SDK_ROOT/lib/hexagon-v${HEXAGON_ARCH}/unsigned/libQnnHtpV${HEXAGON_ARCH}Skel.so" "$PHONE_DIR/"
adb push "$QNN_SDK_ROOT/lib/aarch64-android/libQnnSystem.so" "$PHONE_DIR/"

# 推送 QNN 运行需要的最小模型文件
adb push "$MODEL_DIR/config_qnn.json" "$PHONE_MODEL_DIR/"
adb push "$MODEL_DIR/llm_config.json" "$PHONE_MODEL_DIR/"
adb push "$MODEL_DIR/tokenizer.txt" "$PHONE_MODEL_DIR/"
adb push "$MODEL_DIR/llm.mnn.weight" "$PHONE_MODEL_DIR/"
adb push "$MODEL_DIR/qnn" "$PHONE_MODEL_DIR/"

# 准备一个文件输入，便于首次验证
printf 'hello\n' > prompt.txt
adb push prompt.txt "$PHONE_DIR/"

# 给可执行文件加权限
adb shell "chmod +x $PHONE_DIR/llm_demo"

HEXAGON_ARCH 必须和设备、QNN 模型生成参数匹配。本次如果误推 V75 库，会在 logcat 里看到 Stub lib id mismatch，随后 QNN 初始化失败。

3.2 运行

QNN LLM 运行时传入 config_qnn.json，不要传普通 config.json。

adb shell "cd $PHONE_DIR && \
export LD_LIBRARY_PATH=$PHONE_DIR && \
export ADSP_LIBRARY_PATH=$PHONE_DIR && \
./llm_demo $PHONE_MODEL_DIR/config_qnn.json $PHONE_DIR/prompt.txt"

测试后有正常输出：

config path is /data/local/tmp/mnn-llm-qnn/model/Qwen3-1.7B-MNN/config_qnn.json
Prepare for tuning opt Begin
Prepare for tuning opt End
prompt file is /data/local/tmp/mnn-llm-qnn/prompt.txt
Hello! How can I assist you today?

prompt tokens num = 9
decode tokens num = 217
prefill speed = 37.52 tok/s
decode speed = 15.03 tok/s

llm_demo 还支持交互运行模式：

adb shell
cd /data/local/tmp/mnn-llm-qnn
export LD_LIBRARY_PATH=/data/local/tmp/mnn-llm-qnn
export ADSP_LIBRARY_PATH=/data/local/tmp/mnn-llm-qnn
./llm_demo /data/local/tmp/mnn-llm-qnn/model/Qwen3-1.7B-MNN/config_qnn.json

进入交互模式后，直接输入问题即可。

Eagle 推理流程

Sun, 24 May 2026 23:00:00 +0800

Eagle 推理流程

本篇记录MNN的Eagle3推理流程，主要内容包括：

Eagle 推理流程

1. Eagle 入口

LLM 在加载阶段会统一创建生成策略对象，入口在：

// transformers/llm/engine/src/speculative_decoding/generate.cpp:19
std::shared_ptr<Generation> GenerationStrategyFactory::create(Llm* llm, std::shared_ptr<LlmContext> context, std::shared_ptr<LlmConfig> config, bool canSpec) {
    std::shared_ptr<Generation> res;
    if(canSpec) {
        if(config->speculative_type() == "lookahead") {
            res.reset(new LookaheadGeneration(llm, context, config));
        } else if(config->speculative_type() == "mtp") {
            res.reset(new MtpGeneration(llm, context, config));
        } else if(config->speculative_type() == "eagle") {
            res.reset(new EagleGeneration(llm, context, config));
        } else {
            res.reset(new ArGeneration(llm, context, config));
        }
    } else {
        res.reset(new ArGeneration(llm, context, config));
    }
    return res;
}

使用Eagle3进行推理的前提是：

配置文件中 speculative_type = "eagle"；

2. Eagle 配置

Eagle 路径依赖的主要配置在 llmconfig.hpp：

// transformers/llm/engine/src/llmconfig.hpp:576
std::string speculative_type() const {
    return config_.value("speculative_type", "");
}
int draft_predict_length() const {
    return config_.value("draft_predict_length", 3);
}
std::string eagle_model() const {
    return base_dir_ + config_.value("eagle_model", "eagle.mnn");
}
std::string eagle_fc() const {
    return base_dir_ + config_.value("eagle_fc", "eagle_fc.mnn");
}
std::string eagle_d2t() const {
    return base_dir_ + config_.value("eagle_d2t", "eagle_d2t.mnn");
}
int eagle_depth() const {
    return config_.value("eagle_depth", 3);
}
int eagle_topk() const {
    return config_.value("eagle_topk", 1);
}

这里几项配置的作用可以直接对应到实现：

eagle_model：主 Eagle draft 模块，输入 (input_embed + hidden_states, mask, position_ids, logits_index)；
eagle_fc：把主模型浅层、中层、深层的 hidden states 变成 Eagle draft 模块需要的 hidden states；
eagle_d2t：draft token 到真实 token 的映射表；
draft_predict_length：每轮从草稿树里取多少个 draft node 交给主模型验证，默认是 3；
eagle_depth：草稿树的深度；
eagle_topk：每层扩展多少个候选分支。

3. Eagle 加载

EagleGeneration::load() 会在普通主模型之外，再额外加载两份模块和一份映射表，对应上面的eagle_model/eagle_fc/eagle_d2t,加载代码如下：

// transformers/llm/engine/src/speculative_decoding/eagle.cpp:28
void EagleGeneration::load(Module::Config module_config) {
    mEagleMeta.reset(new KVMeta);
    mLlm->mRuntimeManager->setHintPtr(Interpreter::KVCACHE_INFO, mEagleMeta.get());

    std::vector<std::string> inputNames{"input_embed", "hidden_states", "attention_mask", "position_ids", "logits_index"};
    std::vector<std::string> outputNames {"logits", "out_hidden_states"};
    mEagleModules.resize(2);
    mEagleModules[0].reset(Module::load(inputNames, outputNames, mLlm->mConfig->eagle_model().c_str(), mLlm->mRuntimeManager, &module_config));

    mEagleModules[1].reset(Module::load({"fc_hidden"}, {"hidden_states"}, mLlm->mConfig->eagle_fc().c_str(), mLlm->mRuntimeManager, &module_config));

    mD2t = Express::Variable::load(mLlm->mConfig->eagle_d2t().c_str())[0];

    mTopK = mLlm->mConfig->eagle_topk();
    mDepth = mLlm->mConfig->eagle_depth();
    mTreePosition = _Input({1, mTopK}, NCHW, halide_type_of<int>());
}

在Eagle3推理情况下：

目标模型仍然由 Llm::mModule 负责；
Eagle3草稿模型额外持有两份 Module：
- mEagleModules[0]：主模型，一层注意力层+一层线性层lm_head
- mEagleModules[1]：hidden state 投影模块
Eagle3草稿模型维护草稿模型到目标模型token的词汇映射表 mD2t

另外，草稿模型额外维护一份 draft 路径上的 KV 状态 mEagleMeta，在EagleGeneration::load() 里会进行初始化：

1
2
3

// transformers/llm/engine/src/speculative_decoding/eagle.cpp:29
mEagleMeta.reset(new KVMeta);
mLlm->mRuntimeManager->setHintPtr(Interpreter::KVCACHE_INFO, mEagleMeta.get());

4. Eagle 推理主流程

EagleGeneration::generate() 的流程大致是：

主模型 prefill logits
    ↓
先采样出第一个 token
    ↓
Eagle draft 生成草稿树
    ↓
主模型 tree decoding 验证草稿树
    ↓
选择接受路径
    ↓
把接受 token 回写主模型 KV
    ↓
再基于新的验证得到的 hidden states 继续生成下一轮 draft

对应大致代码结构如下：

// transformers/llm/engine/src/speculative_decoding/eagle.cpp:298
void EagleGeneration::generate(GenerationParams& param) {
    mEaglePastLen = 0;
    mEagleRemove  = mEagleMeta->previous;
    ...
    auto sampleToken  = mLlm->sample(param.outputs[0]);
    ...
    auto draftInfo  = topkGenerate(inputIds, hiddenStates, inputEmbeds);
    while (true) {
        auto decodingInfo = treeDecoding(draftInfo);
        auto acceptInfo = evaluatePosterior(draftInfo, decodingInfo[0]);
        ...
        draftInfo = updateDraft(acceptInfo, decodingInfo[1]);
    }
}

4.1 首 token

Eagle 不是从空状态直接建树，而是先消费主模型 prefill 后的第一轮 logits：

// transformers/llm/engine/src/speculative_decoding/eagle.cpp:305
auto sampleToken  = mLlm->sample(param.outputs[0]);
mContext->current_token = sampleToken;
mContext->history_tokens.push_back(mContext->current_token);
mContext->output_tokens.push_back(mContext->current_token);
mLlm->updateContext(0, 1);

然后把这个 token 对应的 embedding 拼到输入尾部，作为 Eagle draft 的起点：

// transformers/llm/engine/src/speculative_decoding/eagle.cpp:317
auto cur_embed  = mLlm->embedding({sampleToken});
auto pre_embeds = _Split(inputEmbeds, {1, seqLen - 1}, 0);
inputEmbeds     = _Concat({pre_embeds[1], cur_embed}, 0);

这里给草稿模型的输入是上一个token的hidden state+新一个的embedding，第一个token没有前序hidden state, 所以pre_embeds需要切掉第一个token的embedding，拼上新token的embedding作为草稿树的输入。

4.2 draft tree 生成

draft tree 的生成入口是 topkGenerate(...)：

// transformers/llm/engine/src/speculative_decoding/eagle.cpp:110
EagleGeneration::DraftInfo EagleGeneration::topkGenerate(const std::vector<int>& inputIds, VARP hiddenStates, VARP inputEmbeds) {
    TokenTree tokenTree(mTopK, d2tPtr);
    ...
    auto inputHidden = mEagleModules[1]->forward(hiddenStates);
    outputs      = eagleForward(inputEmbeds, inputHidden);
    ...
    auto topKV = MNN::Express::_TopKV2(lastP, MNN::Express::_Scalar<int>(mTopK));
    tokenTree.init(indices, scores);
    ...
    for (int d = 0; d < mDepth - 1; d++) {
        inputEmbeds   = mLlm->embedding(tokenTree.getIds());
        auto attentionMask = getMask(tokenTree.getMask(), seqLen);
        outputs = eagleForwardRaw({inputEmbeds, inputHidden, attentionMask, mTreePosition, mLlm->logitsAllIdx});
        ...
        tokenTree.grow(indices, scores);
    }
    auto output = tokenTree.finalize(sampleToken, mLlm->mDraftLength);
    ...
}

这里的核心点有三个：

先通过 mEagleModules[1] 把主模型 hidden states 映射到 Eagle draft 模型所需空间；
再用 mEagleModules[0] 递归生成每层 top-k 候选；
借助 TokenTree 累积候选树、mask、位置和最终检索索引。

这一步的输出是一个 DraftInfo结构体，包括：

draftTokens: 主模型要验证的 token 列表
retrieveIndices：每条候选路径怎么从 draftTokens 里取，是一个二维列表，第一维是路径数，第二维是每条路径对应的 token 索引；
attentionMask：树形解码的 attention mask，主模型验证时需要用到
positionIds：树形解码的 position id，主模型验证时需要用到

由草稿树TokenTree 负责把多轮 topk 候选整理成主模型一次性验证需要的 draftTokens / attentionMask / positionIds / retrieveIndices。

4.3 TokenTree 接口

TokenTree 定义在 transformers/llm/engine/src/speculative_decoding/tokentree.hpp。它是一个纯 CPU 侧的草稿树整理器。EagleGeneration::topkGenerate(...) 每轮拿到 Eagle 模型输出的 topk token 后，会把候选交给 TokenTree 维护。

基础数据结构是 TokenTreeNode 和 TreeOutputs：

// transformers/llm/engine/src/speculative_decoding/tokentree.hpp:24
class TokenTreeNode : public std::enable_shared_from_this<TokenTreeNode> {
public:
    int mTokenId, mNodeId, mDepth;
    double mLogProb, mCumulativeLogProb;
    std::weak_ptr<TokenTreeNode> mParent;
    std::vector<NodePtr> mChildren;
    ...
};

// transformers/llm/engine/src/speculative_decoding/tokentree.hpp:48
struct TreeOutputs {
    std::vector<int> draftTokens;
    std::vector<int> positionIds;
    std::vector<std::vector<bool>> attentionMask;
    std::vector<std::vector<int>> retrieveIndices;
};

TokenTreeNode 里最重要的是四类信息：

mTokenId：当前节点代表的 token；
mNodeId：创建顺序，后面 finalize(...) 会用它恢复 draft token 的稳定顺序；
mDepth：节点在草稿树里的层数，用来生成 positionIds；
mCumulativeLogProb：从根到当前节点的累计分数，用来裁剪候选路径。

TreeOutputs是把内部维护的“树结构”整理成后面主模型验证能直接使用的四类数据，还需要在 topkGenerate(...) 把它转换成 DraftInfo给后续验证使用。

TokenTree 初始化时会创建一个虚拟根节点，并初始化第一层 mask：

// transformers/llm/engine/src/speculative_decoding/tokentree.hpp:57
TokenTree(int topK, const int* d2tPtr = nullptr) : mTopK(topK), mD2tPtr(d2tPtr), mCounter(0) {
    mRoot = std::make_shared<TokenTreeNode>(-1, 0.0, nullptr, -1);
    mRoot->mDepth = -1;
    mMask.assign(topK, std::vector<bool>(topK, false));
    for (int i = 0; i < topK; i++) {
        mMask[i][i] = true;
    }
}

这里的 d2tPtr 来自 eagle_d2t。Eagle 模型输出的是 draft vocab 上的 id，TokenTree::d2t(...) 会把它映射回目标模型 token：

// transformers/llm/engine/src/speculative_decoding/tokentree.hpp:243
int d2t(int token) {
    if (mD2tPtr) {
        return token + mD2tPtr[token];
    }
    return token;
}

第一轮 topk 通过 init(...) 建第一层节点：

// transformers/llm/engine/src/speculative_decoding/tokentree.hpp:67
void init(const int* indices, const float* scores) {
    for (size_t i = 0; i < mTopK; i++) {
        auto node = std::make_shared<TokenTreeNode>(
            d2t(indices[i]), scores[i], mRoot, mCounter++
        );
        mRoot->addChild(node);
        mActives.push_back(node);
    }
}

后续每一层调用 grow(...)。它会对当前 mActives 中的每个叶子节点扩展 topK 个孩子，然后按 mCumulativeLogProb 排序，只保留全局最优的 topK 个节点作为下一轮 active leaf：

// transformers/llm/engine/src/speculative_decoding/tokentree.hpp:77
void grow(const int* indices, const float* scores) {
    std::vector<NodePtr> candidates;
    std::map<NodePtr, int> parant2index;
    for (size_t i = 0; i < mActives.size(); ++i) {
        auto parent = mActives[i];
        parant2index[parent] = i;
        for (size_t j = 0; j < mTopK; j++) {
            auto child_node = std::make_shared<TokenTreeNode>(
                d2t(indices[i * mTopK + j]),
                scores[i * mTopK + j],
                parent,
                mCounter++
            );
            parent->addChild(child_node);
            candidates.push_back(child_node);
        }
    }
    std::sort(candidates.begin(), candidates.end(), [](const NodePtr& a, const NodePtr& b) {
        return a->mCumulativeLogProb > b->mCumulativeLogProb;
    });
    ...
    mActives = std::move(newActives);
}

getIds() 和 getMask() 是给下一轮 Eagle 模型用的接口：

// transformers/llm/engine/src/speculative_decoding/tokentree.hpp:215
const std::vector<std::vector<bool>>& getMask() const {
    return mMask;
}

// transformers/llm/engine/src/speculative_decoding/tokentree.hpp:219
std::vector<int> getIds() const {
    std::vector<int> tokenIds;
    for (auto& active : mActives) {
        tokenIds.push_back(active->mTokenId);
    }
    return tokenIds;
}

在 topkGenerate(...) 里对应这段：

// transformers/llm/engine/src/speculative_decoding/eagle.cpp:146
inputEmbeds   = mLlm->embedding(tokenTree.getIds());
auto attentionMask = getMask(tokenTree.getMask(), seqLen);
outputs = eagleForwardRaw({inputEmbeds, inputHidden, attentionMask, mTreePosition, mLlm->logitsAllIdx});
...
tokenTree.grow(indices, scores);

最后 finalize(sampleToken, mDraftLength) 把内部树整理成验证输入：

// transformers/llm/engine/src/speculative_decoding/tokentree.hpp:135
TreeOutputs finalize(int sampleToken, int maxDraftTokens) {
    auto allNodes = getAllNodes();
    std::sort(allNodes.begin(), allNodes.end(), [](const NodePtr& a, const NodePtr& b) {
        return a->mCumulativeLogProb > b->mCumulativeLogProb;
    });
    if (allNodes.size() > maxDraftTokens) {
        allNodes.resize(maxDraftTokens);
    }
    std::sort(allNodes.begin(), allNodes.end(), [](const NodePtr& a, const NodePtr& b) {
        return a->mNodeId < b->mNodeId;
    });
    ...
}

这里有两个排序：

先按累计分数选出最值得验证的 maxDraftTokens 个节点；
再按 mNodeId 恢复创建顺序，保证 draftTokens 的布局稳定。

finalize(...) 会先把已经由主模型采样出的 sampleToken 放到 draftTokens[0]，再追加选中的树节点：

// transformers/llm/engine/src/speculative_decoding/tokentree.hpp:154
outputs.draftTokens.push_back(sampleToken);
outputs.positionIds.push_back(0);
for(size_t i = 0; i < allNodes.size(); ++i) {
    outputs.draftTokens.push_back(allNodes[i]->mTokenId);
    outputs.positionIds.push_back(allNodes[i]->mDepth + 1);
    nodeId2Idx[allNodes[i]->mNodeId] = i;
}

后面的 attentionMask 表示树上可见关系：每个节点可以看自己和祖先节点，不能看其它分支节点。retrieveIndices 则把每个叶子节点对应的根到叶路径整理出来：

// transformers/llm/engine/src/speculative_decoding/tokentree.hpp:162
outputs.attentionMask.assign(numDraftTokens, std::vector<bool>(numDraftTokens, false));
for (int i = 0; i < numDraftTokens; ++i) {
    outputs.attentionMask[i][i] = true;
    auto node = allNodes[i];
    auto parent = node->mParent.lock();
    if (parent && parent->mNodeId != -1 && nodeId2Idx.count(parent->mNodeId)) {
        int parentIdx = nodeId2Idx[parent->mNodeId];
        for (int j = 0; j < numDraftTokens; ++j) {
            if (outputs.attentionMask[parentIdx][j]) {
                outputs.attentionMask[i][j] = true;
            }
        }
    }
}

// transformers/llm/engine/src/speculative_decoding/tokentree.hpp:201
for (const auto& leaf : leafNodes) {
    std::vector<int> path;
    auto curr = leaf;
    while(curr && curr->mNodeId != -1) {
        path.push_back(nodeId2Idx[curr->mNodeId] + 1);
        curr = curr->mParent.lock();
    }
    path.push_back(0);
    std::reverse(path.begin(), path.end());
    outputs.retrieveIndices.push_back(path);
}

topkGenerate(...) 拿到 TreeOutputs 后，会把 bool mask 转成主模型需要的 float mask，并把相对位置加上当前 seqLen：

// transformers/llm/engine/src/speculative_decoding/eagle.cpp:195
int inputLen = output.draftTokens.size();
DraftInfo info;
info.draftTokens = std::move(output.draftTokens);
info.retrieveIndices = std::move(output.retrieveIndices);
info.attentionMask = _Input({1, 1, inputLen, inputLen}, NCHW, halide_type_of<float>());
for (int i = 0; i < inputLen; i++) {
    for (int j = 0; j < inputLen; j++) {
        info.attentionMask->writeMap<float>()[i * inputLen + j] =
            output.attentionMask[i][j] ? 0.0 : std::numeric_limits<float>::lowest();
    }
}
info.positionIds = _Input({1, inputLen}, NCHW, halide_type_of<int>());
for (int i = 0; i < inputLen; i++) {
    info.positionIds->writeMap<int>()[i] = seqLen + output.positionIds[i];
}

所以 TokenTree 的接口可以按这个顺序理解：

接口	输入	输出 / 作用
`init(indices, scores)`	首轮 `topk` token 和分数	建第一层候选节点，初始化 `mActives`
`getIds()`	当前 active leaf	返回下一轮要送入 `Eagle` 模型的 token
`getMask()`	当前 active leaf 可见关系	返回下一轮 `Eagle` 模型用的树形 mask
`grow(indices, scores)`	每个 active leaf 的下一层 `topk`	扩展候选树，并按累计分数裁剪到 `topK` 个 active leaf
`finalize(sampleToken, maxDraftTokens)`	当前主模型采样 token 和草稿长度上限	生成主模型验证用的 `draftTokens / positionIds / attentionMask / retrieveIndices`
`toString(decoder)`	token 解码函数	`EAGLE_DEBUG` 下打印树结构

4.4 tree decoding 验证

draft tree 建好以后，会进入 treeDecoding(...)：

// transformers/llm/engine/src/speculative_decoding/eagle.cpp:212
VARPS EagleGeneration::treeDecoding(const EagleGeneration::DraftInfo& drafInfo) {
    auto inputEmbeds   = mLlm->embedding(drafInfo.draftTokens);
    int inputLen = drafInfo.draftTokens.size();
    mLlm->mMeta->add = inputLen;
    auto outputs = mLlm->forwardRaw(inputEmbeds, drafInfo.attentionMask, drafInfo.positionIds);
    return outputs;
}

这一层做的事情很直接：把 draft tree 里的所有候选 token 一次性交给主模型，让主模型跑一次树形解码，得到树形输入对应的logits。

这里执行 treeDecoding() 的 KV 语义如下：

// transformers/llm/engine/src/speculative_decoding/eagle.cpp:214
int inputLen = drafInfo.draftTokens.size();
mLlm->mMeta->add = inputLen;
auto outputs = mLlm->forwardRaw(inputEmbeds, drafInfo.attentionMask, drafInfo.positionIds);

主模型在 tree decoding 阶段会先把“整棵 draft tree 扁平化后的 token 序列”都视为待验证输入，一次性把这些候选写进当前前向路径里。后面才需要 updateDraft() 时通过 remove + reserve 把接受的token的 KV 缓存保留。

4.5 接受token

主模型验证完 draft tree 后，会通过 evaluatePosterior(...) 选出最佳接受路径，主要是根据路径验证各个路径上的token是否都被接受，保留最长路径：

// transformers/llm/engine/src/speculative_decoding/eagle.cpp:220
EagleGeneration::AcceptInfo EagleGeneration::evaluatePosterior(const EagleGeneration::DraftInfo& drafInfo, VARP logits) {
    auto sampleTokens = MNN::Express::_ArgMax(logits, -1);
    std::vector<int> samples(drafInfo.draftTokens.size());
    ::memcpy(samples.data(), sampleTokens->readMap<int>(), samples.size() * sizeof(int));
    std::vector<int> bestCandidate;
    int nextSample = 0;
    for (auto indices : drafInfo.retrieveIndices) {
        std::vector<int> candidate;
        int next = -1;
        for (int i = 0; i < indices.size() - 1; i++) {
            int sampleIdx = indices[i];
            int draftIdx  = indices[i + 1];
            if (samples[sampleIdx] != drafInfo.draftTokens[draftIdx]) {
                break;
            }
            candidate.push_back(sampleIdx);
            next = draftIdx;
        }
        if (candidate.size() > bestCandidate.size()) {
            bestCandidate = candidate;
            nextSample = next;
        }
    }
}

然后在 updateDraft(...) 里把接受结果回写到主模型 KV 状态：

// transformers/llm/engine/src/speculative_decoding/eagle.cpp:267
mLlm->updateContext(acceptLen, acceptLen);
mLlm->mMeta->remove = acceptInfo.sampleTokens.size();
mLlm->mMeta->n_reserve = acceptLen;
mLlm->mMeta->reserve = new int[mLlm->mMeta->n_reserve * 2];
for (size_t i = 0; i < acceptLen; i++) {
    mLlm->mMeta->reserve[2 * i] = acceptInfo.acceptIndices[i];
    mLlm->mMeta->reserve[2 * i + 1] = 1;
}

这里的逻辑是：

sampleTokens.size() 表示这次 tree decoding 验证过的整棵候选树长度；
acceptLen 表示最终真正接受了多少个 token；
remove + reserve 保留了接受token位置的 KV 状态。

随后 updateDraft(...) 还会用接受路径对应的 hidden states 继续调用 topkGenerate(...)，进入下一轮 draft tree 生成。

以 llm_demo 为例的交叉编译与设备运行

Sun, 24 May 2026 12:00:00 +0800

交叉编译与设备运行

以 transformers/llm/engine/demo/llm_demo.cpp 在 Android 设备上执行流程：服务器交叉编译 -> adb push推送到手机 -> 端侧设备运行。需要准备下面环境：

adb devices 能看到目标手机，参考远程ADB环境配置
ANDROID_NDK 已配置，参考交叉编译环境配置

1. 环境

以下面环境为例：

开发机(编译设备)：Ubuntu 22.04
测试机(目标设备)：arm64-v8a + SanpDragon 8 Gen 3
编译目录：project/android/build_64
手机测试目录：/data/local/tmp/mnn-llm-demo

首先需要拉取仓库到编译设备

`1`	`git clone https://github.com/alibaba/MNN`

并且在编译设备上准备模型，模型以Qwen3-4B-Instruct-MNN，目录结构至少包含这些文件：

Qwen3-4B-Instruct-2507-MNN/
├── config.json         # 运行时配置 包括后端设置、线程数、采样参数等
├── llm_config.json     # 导出时写入的模型元信息
├── tokenizer.mtok      # 分词器文件
├── llm.mnn             # 模型计算图
└── llm.mnn.weight      # 模型权重

建议使用hf-mirror镜像站下载：

wget https://hf-mirror.com/hfd/hfd.sh && chmod a+x hfd.sh # 下载工具脚本

export HF_ENDPOINT=https://hf-mirror.com # 设置 Hugging Face 镜像站点
./hfd.sh taobao-mnn/Qwen3-4B-Instruct-2507-MNN # 下载模型到当前目录

2. 交叉编译 `llm_demo`

llm_demo 位于 transformers/llm/engine/demo/llm_demo.cpp，编译它时至少要打开 MNN_BUILD_LLM。这一篇只保留能直接运行 LLM 的常用宏，在编译设备执行：

# 服务器端运行
cd /workspace/zjh/code/MNN/project/android
mkdir -p build_64
cd build_64

# 交叉编译 Android arm64 版本的 llm_demo
../build_64.sh \
  -DMNN_LOW_MEMORY=true \
  -DMNN_CPU_WEIGHT_DEQUANT_GEMM=true \
  -DMNN_BUILD_LLM=true \
  -DMNN_SUPPORT_TRANSFORMER_FUSE=true \
  -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

这一步结束后，当前目录下有下面几个产物：

`1`	`ls -lh llm_demo libMNN.so libMNN_Express.so libllm.so`

如果还要测试 OpenCL，可以继续加上 -DMNN_OPENCL=true。

3. 推送并运行

3.1 推送编译产物和模型

llm_demo 不是静态单文件程序，除了可执行文件本身，还需要把依赖的动态库 .so 一起推送到手机。

下面假设服务器上的模型目录是 /data/HUGGINGFACE/Qwen3-4B-Instruct-MNN，需要按自己的模型下载路径替换。

# 服务器端运行
export PHONE_DIR=/data/local/tmp/mnn-llm-demo # 手机侧测试目录
export MODEL_DIR=/data/HUGGINGFACE/Qwen3-4B-Instruct-MNN # 服务器侧模型目录

# 创建手机侧目录
adb shell "mkdir -p $PHONE_DIR/model"

# 推送二进制和动态库
# 执行时当前目录位于编译产物所在目录，即 `project/android/build_64`
adb push llm_demo "$PHONE_DIR/"
adb push libMNN.so "$PHONE_DIR/"
adb push libMNN_Express.so "$PHONE_DIR/"
adb push libllm.so "$PHONE_DIR/"

# 推送模型目录
adb push "$MODEL_DIR/" "$PHONE_DIR/model/"

# 准备一个文件输入，便于首次验证
printf 'hello\n' > prompt.txt
adb push prompt.txt "$PHONE_DIR/"

# 给可执行文件加权限
adb shell "chmod +x $PHONE_DIR/llm_demo"

3.2 运行

1
2
3

adb shell "cd $PHONE_DIR && \
export LD_LIBRARY_PATH=$PHONE_DIR && \
./llm_demo $PHONE_DIR/model/config.json $PHONE_DIR/prompt.txt"

正常情况下会看到类似输出：

config path is /data/local/tmp/mnn-llm-demo/model/config.json
Prepare for tuning opt Begin
Prepare for tuning opt End
hello
A: Hello! How can I help you today?

llm_demo还支持交互运行模式：

adb shell
cd /data/local/tmp/mnn-llm-demo
# 需要先设置环境变量 程序才能找到编译出来的动态库
export LD_LIBRARY_PATH=/data/local/tmp/mnn-llm-demo
# 这里传入的参数是模型配置文件的路径
./llm_demo /data/local/tmp/mnn-llm-demo/model/config.json

进入交互模式后，直接输入问题即可。

LLM 加载流程

Thu, 26 Feb 2026 23:00:00 +0800

LLM 加载流程

LLM 加载流程

本篇针对transformers/llm/engine/src/llm.cpp 的 Llm::load()接口，梳理 MNN LLM 如何把 config.json、llm_config.json、llm.mnn 和 llm.mnn.weight 装配成可执行状态，源码执行顺序如下。

`Llm::createLLM(config_path)`
    ↓
`LlmConfig`
    ↓
`Llm::load()`
    ↓
`initRuntime()`
    ↓
`Tokenizer::createTokenizer(...)`
    ↓
读取 `context.json`
    ↓
构造 `DiskEmbedding` / `Prompt` / `Sampler`
    ↓
`Module::load(...)`
    ↓
`loadInternal(...)`
    ↓
`PipelineModule::load(...)`
    ↓
`StaticModule(...)`
    ↓
`Session(...)`
    ↓
`Pipeline(...)`
    ↓
初始化 `ModulePool` / `mask` / `position ids`

1. LLM配置

LLM 的入口通常是：

1
2

// transformers/llm/engine/src/llm.cpp:72
Llm* llm = Llm::createLLM(config_path);

入口逻辑在 Llm::createLLM：

// transformers/llm/engine/src/llm.cpp:72
Llm* Llm::createLLM(const std::string& config_path) {
    std::shared_ptr<LlmConfig> config(new LlmConfig(config_path));
    Llm* llm = nullptr;
    if (config->is_visual() || config->is_audio() || config->has_talker()) {
        llm = new Omni(config);
    } else {
        llm = new Llm(config);
    }
    return llm;
}

这里先做了一次很轻量的模型分流：

纯文本模型返回 Llm
多模态/语音模型返回 Omni

此时模型还没有真正加载，只读取配置并做基础成员的初始化：

// transformers/llm/engine/src/llm.cpp:930
Llm::Llm(std::shared_ptr<LlmConfig> config) : mConfig(config) {
    mExecutor = MNN::Express::Executor::newExecutor(MNN_FORWARD_CPU, backendConfig, 1);
    mContext.reset(new LlmContext);
    mMeta.reset(new KVMeta);
    mMeta->layer_nums = mConfig->layer_nums();
    mMeta->attn_scale = mConfig->attn_scale();
    mGenerateParam.reset(new GenerationParams);
}

该阶段会构建LLM类运行时频繁使用的核心对象：

mExecutor：Express 执行器；
mContext：记录 prompt 长度、decode 长度、耗时、token 历史；
mMeta：KV Cache 元信息；
mGenerateParam：各个生成策略使用参数

2. LLM加载整体流程

先看 Llm::load() 的主骨架：

// transformers/llm/engine/src/llm.cpp:238
bool Llm::load() {
    initRuntime();

    mTokenizer.reset(Tokenizer::createTokenizer(mConfig->tokenizer_file()));
    // 2. load context
    mDiskEmbedding.reset(new DiskEmbedding(mConfig));
    mPrompt.reset(Prompt::createPrompt(mContext, mConfig));
    mSampler.reset(Sampler::createSampler(mContext, mConfig));

    Module::Config module_config;
    if (mConfig->backend_type() == "opencl" || mConfig->backend_type() == "vulkan" || mConfig->backend_type() == "npu") {
        module_config.shapeMutable = false;
    } else {
        module_config.shapeMutable = true;
    }
    module_config.rearrange = true;

    mRuntimeManager->setExternalFile(mConfig->llm_weight());
    mModule.reset(Module::load(inputNames, outputNames, mConfig->llm_model().c_str(), mRuntimeManager, &module_config));
    mRuntimeManager->setExternalFile("");

    setSpeculativeConfig();
    mGenerationStrategy = GenerationStrategyFactory::create(this, mContext, mConfig, mInSpec);
    ...
}

这段代码会：

先初始化 Runtime，准备后端、线程和 hint；
再构造 tokenizer、embedding、prompt 和 sampler；
然后准备 Module::Config 和模型路径；
接着装载 llm.mnn；
最后准备解码策略 Generation 和 ModulePool。

3. Runtime 初始化

Runtime 初始化在 initRuntime()方法中：

// transformers/llm/engine/src/llm.cpp:166
ScheduleConfig config;
BackendConfig cpuBackendConfig;
config.type      = backend_type_convert(mConfig->backend_type());
config.numThread = mConfig->thread_num();
config.backendConfig = &cpuBackendConfig;
if(config.type == 3){
    // opencl need set numThread = 64(buffer mode)
    config.numThread |= 64;
}
if (mConfig->power() == "high") {
    cpuBackendConfig.power = BackendConfig::Power_High;
} else if (mConfig->power() == "low") {
    cpuBackendConfig.power = BackendConfig::Power_Low;
}
if (mConfig->memory() == "high") {
    cpuBackendConfig.memory = BackendConfig::Memory_High;
} else if (mConfig->memory() == "low") {
    cpuBackendConfig.memory = BackendConfig::Memory_Low;
}
if (mConfig->precision() == "high") {
    cpuBackendConfig.precision = BackendConfig::Precision_High;
} else if (mConfig->precision() == "low") {
    cpuBackendConfig.precision = BackendConfig::Precision_Low;
}
config.backendConfig = &cpuBackendConfig;

// transformers/llm/engine/src/llm.cpp:191
mRuntimeManager.reset(Executor::RuntimeManager::createRuntimeManager(config));
setRuntimeHint(mRuntimeManager);

首先会做两件事：

把 JSON 配置翻译成 MNN 的 ScheduleConfig/BackendConfig；
创建 RuntimeManager，后续 Module::load() 就绑定到这个运行时上。

紧接着会调用 setRuntimeHint()，把很多 LLM 相关配置设置，例如：

// transformers/llm/engine/src/llm.cpp:136
rtg->setHint(MNN::Interpreter::ATTENTION_OPTION, attentionMode);
rtg->setHint(MNN::Interpreter::DYNAMIC_QUANT_OPTIONS, mConfig->config_.value("dynamic_option", 0));
rtg->setHintPtr(Interpreter::KVCACHE_INFO, mMeta.get());
rtg->setExternalPath(tmpPath, MNN::Interpreter::EXTERNAL_WEIGHT_DIR);
rtg->setExternalPath(cachePath, MNN::Interpreter::EXTERNAL_PATH_PREFIXCACHE_DIR);
rtg->setHint(MNN::Interpreter::MMAP_FILE_SIZE, mConfig->mmap_size());

会配置：attention 执行模式、动态量化相关选项、KV Cache 元信息地址、权重 mmap 路径、prefix cache 路径、mmap 文件大小。

4. tokenizer、embedding 和 sampler 初始化

Runtime 就绪后，load() 开始准备推理前端所需的组件。

4.1 tokenizer 初始化

// transformers/llm/engine/src/llm.cpp:243
mTokenizer.reset(Tokenizer::createTokenizer(mConfig->tokenizer_file()));
if (mTokenizer == nullptr) {
    MNN_ERROR("[Error]: Failed to load tokenizer from: %s\n", mConfig->tokenizer_file().c_str());
    return false;
}

Tokenizer::createTokenizer() 会先读 tokenizer 文件的头部，判断它是哪一种格式：

// transformers/llm/engine/src/tokenizer.cpp:71
Tokenizer* Tokenizer::createTokenizer(const std::string& filename) {
    ...
}

然后按类型创建不同的分词器：

Sentencepiece
Tiktoken
BertTokenizer
HuggingfaceTokenizer
PipelineTokenizer（.mtok 二进制格式）

4.2 context.json 和 chat template

如果配置目录里有 context.json，load() 会把它读出来并 merge 到 jinja.context，然后调用：

// transformers/llm/engine/src/llm.cpp:246
std::ifstream contextFile(mConfig->context_file());
if (contextFile.is_open()) {
    std::ostringstream contextStream;
    contextStream << contextFile.rdbuf();
    auto contextStr = contextStream.str();
    rapidjson::Document contextDoc;
    contextDoc.Parse(contextStr.c_str());
    if (!contextDoc.HasParseError()) {
        std::string config_json = R"({
            "jinja": {
                "context": )" + contextStr + R"(
            }
        })";
        mConfig->config_.merge(config_json.c_str());
    }
}

完成提示词拼接后，Llm 会用 Prompt::createPrompt(...) 统一封装模板对象。

4.3 DiskEmbedding 初始化

LLM 的词向量不是直接塞在图里，而是通过 DiskEmbedding 从独立文件或权重文件里读取：

1
2
3

// transformers/llm/engine/src/llm.cpp:264
mDiskEmbedding.reset(new DiskEmbedding(mConfig));
mPrompt.reset(Prompt::createPrompt(mContext, mConfig));

DiskEmbedding 没有把 embedding lookup 写成一个常规算子，而是直接：

根据 token id 在磁盘文件里定位 offset；
读出对应向量；
如有量化则现场反量化；
写入输入 embedding Tensor。

这个设计减少了 embedding 的常驻内存占用。

如果继续顺着 DiskEmbedding 往下追，当前仓库里的实际读盘入口在：

1
2
3

// transformers/llm/engine/src/diskembedding.cpp:96
void DiskEmbedding::embedding(const std::vector<int>& input_ids, float* dst) {
}

对应 embedding() 里会按 token 循环执行“计算偏移 -> 读权重 -> 反量化/类型转换 -> 写入目标 Tensor”这条路径。也就是说，加载阶段把 DiskEmbedding 构造出来以后，后面推理阶段就能直接按 token 做随机读取，而不需要把整张 embedding 表常驻在内存里。

4.4 Sampler 初始化

1
2

// transformers/llm/engine/src/llm.cpp:266
mSampler.reset(Sampler::createSampler(mContext, mConfig));

这里把采样器也提前准备好。这样后续 Prefill 得到 logits 后，就能直接进入 decode，不需要在推理热路径里临时构建采样规则。

Sampler::createSampler() 中真正的组装逻辑在构造函数和 configSampler()：

// transformers/llm/engine/src/sampler.cpp:158
Sampler::Sampler(std::shared_ptr<LlmContext> context, std::shared_ptr<LlmConfig> config) {
    mContext = context;
    // mConfig = getSamplerConfig(config);
    mConfig.max_all_tokens = config->max_all_tokens();
    mConfig.max_new_tokens = config->max_new_tokens();
    mConfig.type = config->sampler_type();
    mConfig.configSampler(mConfig.type, config);
}

/* ----------SamplerConfig---------- */
void Sampler::SamplerConfig::configSampler( std::string sampler_type, std::shared_ptr<LlmConfig> llmConfig) {
    if (sampler_type == "greedy"){
        this->configGreedy(llmConfig);
    } else if (sampler_type == "temperature"){
        this->configTemperature(llmConfig);
    } else if (sampler_type == "topK"){
        this->configTopK(llmConfig);
    } else if (sampler_type == "topP"){
        this->configTopP(llmConfig);
    } else if (sampler_type == "minP"){
        this->configMinP(llmConfig);
    } else if (sampler_type == "tfs"){
        this->configTFS(llmConfig);
    } else if (sampler_type == "typical"){
        this->configTypical(llmConfig);
    } else if (sampler_type == "penalty"){
        this->configPenalty(llmConfig);
    } else if (sampler_type == "mixed"){
        this->configMixed(llmConfig);
    }
}

这里把 temperature、topK、topP、penalty 等采样参数直接保存。

5. Module 加载与执行层装配

前面在 llm.cpp 里看到的模型加载部分：

// transformers/llm/engine/src/llm.cpp:282
std::vector<std::string> inputNames {"input_ids", "attention_mask", "position_ids", "logits_index"};
std::vector<std::string> outputNames {"logits"};

mRuntimeManager->setExternalFile(mConfig->llm_weight());
mModule.reset(Module::load(inputNames, outputNames, mConfig->llm_model().c_str(), mRuntimeManager, &module_config));
mRuntimeManager->setExternalFile("");

这里只是加载入口。真正重要的是：Module::load() 往下会继续经过 loadInternal()、PipelineModule、StaticModule、Session、Pipeline 这几层，最后把 llm.mnn 装配成可执行对象，流程如下：

`Module::load(...)`
    ↓
读取 `llm.mnn`，绑定外部权重文件
    ↓
`loadInternal(...)`
    ↓
解析 `Net` 元信息，构造 `NetModule`
    ↓
`PipelineModule::load(...)`
    ↓
把静态图整理成 `ScheduleInfo + sharedConst`
    ↓
`StaticModule(...)`
    ↓
创建 `Session`，准备输入输出和权重重排
    ↓
`Session(...)`
    ↓
为每条 pipeline 创建 `Pipeline`
    ↓
`Pipeline::encode / allocMemory / execute`
    ↓
具体算子的 `Execution`

5.1 加载策略

在进入 Module::load() 之前，llm.cpp 先准备了 module_config：

// transformers/llm/engine/src/llm.cpp:269
if (mConfig->backend_type() == "opencl" || mConfig->backend_type() == "vulkan" || mConfig->backend_type() == "npu") {
    module_config.shapeMutable = false;
} else {
    module_config.shapeMutable = true;
}
module_config.rearrange = true;

对应的配置结构在：

// include/MNN/expr/Module.hpp:56
struct Config {
    bool dynamic = false;
    bool shapeMutable = true;
    bool rearrange = false;
    BackendInfo* backend = nullptr;
    const Module* base = nullptr;
};

这几个字段分别决定：

dynamic：走动态 Expr 图加载，还是走静态模块加载；
shapeMutable：输入 shape 是否允许频繁变化；
rearrange：是否在加载阶段预重排权重；
base：是否复用已有基础模块，例如 LoRA 场景。

对当前 LLM 路径来说，最关键的是后两个：

shapeMutable 会影响后面 Session 的输入模式和 resize 策略；
rearrange 会影响 StaticModule 是否提前做权重重排。

这一层还没有真正读模型，它只是先把“后面按什么方式装配执行模块”定下来。

5.2 加载模型

Module::load(const char* fileName, ...) 本身先把模型文件读进内存：

// express/module/Module.cpp:355
FileLoader loader(fileName, true);
loader.read();
loader.merge(buffer);

然后补运行时和外部权重路径，这里的运行时基于上一篇提到的config创建：

// express/module/Module.cpp:356
AutoStorage<uint8_t> buffer;
{
    FileLoader loader(fileName, true);
    if (!loader.valid()) {
        MNN_ERROR("Error for open %s\n", fileName);
        return nullptr;
    }
    loader.read();
    if (!loader.valid()) {
        return nullptr;
    }
    loader.merge(buffer);
    if (buffer.get() == nullptr) {
        return nullptr;
    }
}

// express/module/Module.cpp:372
if (nullptr == rtMgr.get()) {
    rtMgr.reset(_createDefaultRuntimeManager(config));
}
if (rtMgr->getInside()->mContent->mExternalFile.empty()) {
    rtMgr->setExternalFile(std::string(fileName) + ".weight");
}
auto res = loadInternal(inputs, outputs, buffer.get(), buffer.size(), rtMgr, config);

这里的流程包括两个关键点：

llm.mnn 会先整体读成内存 buffer；
llm.mnn.weight 不在这里直接解析，而是通过 RuntimeManager::setExternalFile() 传下去，供后面常量张量和权重重排阶段使用。

接下来真正做网络解析的是 loadInternal()方法。

5.3 网络解析

loadInternal() 在 express/module/Module.cpp 里，核心骨架如下：

// express/module/Module.cpp:397
auto net = GetNet(buffer);
std::shared_ptr<Module::Info> info(new Module::Info);
info->inputNames = inputs;
info->outputNames = outputs;

std::shared_ptr<Module> m(PipelineModule::load(inputs, outputs, buffer, length, rtMgr, config));
return new NetModule(m, info, net, length, ...);

loadInternal() 对应的是“把 FlatBuffers 模型解释成 MNN 内部模块”的入口层。它做的事情可以压成四步：

校验 MNN buffer 是否合法；
解析 Net 里的 uuid、version、bizCode、metaData；
整理输入输出名字与输入信息，如调用侧未显式传入输入输出name，会扫描 net->oplists()、net->tensorName()、net->outputName()，自动推导真实输入输出；
调用 PipelineModule::load(...) 继续往下构建真正的执行模块。

这里的NetModule 是一个最外层包装：

持有 Module::Info 这里包含了属性runTimeManager；
在 onForward() 前后做 RuntimeExecuteWrap；
调完内部模块后清缓存；
对外暴露统一的 Module 接口。

5.4 把图拆成静态执行模块

LLM 加载路径会继续进入 PipelineModule::load(...) 的静态加载分支：

// express/module/PipelineModule.cpp:682
auto net = GetNet(buffer);
bool needGeometry = net->usage() != Usage_INFERENCE_STATIC;
sharedConst.reset(new Schedule::ScheduleInfo);
initConstTensors(sharedConst->allTensors, net, defaultBackend.get(), code, &fileLoader);
return new StaticModule(info.inputs, info.outputs, std::move(buffers), std::move(scheduleInfo), sharedConst, std::move(modes), std::move(rt), config);

PipelineModule::load() 对应的是“把图整理成可执行调度信息”，这里的重点是为下一层 StaticModule准备直接可用的数据结构：

sharedConst：共享常量张量和默认后端信息；
Schedule::ScheduleInfo：调度后的 pipeline 信息；
oplists：每个 op 的输入输出 Tensor、Op 指针和执行缓存信息；
needGeometry：是否还需要做 geometry transform。

按 express/module/PipelineModule.cpp 的真实代码顺序看，这一层可以再细分成下面几步：

复制 `llm.mnn` buffer 到 `BufferStorage`
    ↓
创建 `subGraphMap`
    ↓
初始化 `sharedConst`
    ↓
`initConstTensors(...)` 解析常量张量
    ↓
收集输入/输出 tensor index
    ↓
`_createSubModuleInfo(...)` 划分子模块
    ↓
`_createSubModule(...)` 为每个子模块构造执行模块
    ↓
生成最外层 `PipelineModule`

其中：

initConstTensors(...) 会结合外部 llm.mnn.weight 文件，把网络里的常量张量准备好。
preReplaceConstTensor：PipelineModule::load() 会尝试把常量张量预拷贝或预替换到目标后端。
subModules：支持按子图拆成多个子模块，再由最外层 PipelineModule 统一调度。

5.5 创建`Session`

上一层的_createSubModule会把各个子模块最终构造成 StaticModule类，StaticModule 的构造函数在：

// express/module/StaticModule.cpp:311
StaticModule::StaticModule(..., Schedule::ScheduleInfo&& scheduleInfo, ..., std::shared_ptr<Executor::RuntimeManager> rtm, const Module::Config& config) {
    Session::createPipelineBackend(scheduleInfo.pipelineInfo[0], rt);
    if (config.rearrange) {
        mResource->mBuffer = preRearrangeWeights(scheduleInfo, ...);
    } else {
        mResource->mBuffer = std::move(buffer);
    }
    mSession.reset(new Session(std::move(scheduleInfo), mResource->mModes, std::move(rt)));
    resetInputOutputs();
    if (canResize && (!config.rearrange)) {
        mSession->resize();
    }
}

StaticModule 类进行真正的执行装配：

先根据 ScheduleInfo 创建 pipeline 对应的后端；
如果 rearrange=true，就在加载阶段预重排权重；
构造 Session；
绑定输入输出 Tensor；
条件满足时，提前做一次 resize()。

5.5.1 预重排权重

preRearrangeWeights(...) 对应 config.rearrange=true 时的加载阶段权重预处理，分成下面几步：

// express/module/StaticModule.cpp:37
std::map<const std::string, std::shared_ptr<Execution>> base_executions;
if (base != nullptr) {
    auto static_module = getStaticModule(base);
    auto session = static_module->getSession();
    std::vector<Schedule::OpCacheInfo> op_caches = session->getPipelineInfo(0).second;
    // 从 base module 的 executionCache 里按 op name 收集可复用 Execution
}

// express/module/StaticModule.cpp:54
FileLoader loader(scheduleInfo.externalWeightPath.c_str());
auto&& pipelineInfo = scheduleInfo.pipelineInfo[0].second;

处理clone场景：从 base module 的 Session 里收集已有 executionCache。可以直接clone 部分已经预处理过的算子Execution，不需要重新读取和重排权重。
进入预处理分支，包括下面的算子类型：

// express/module/StaticModule.cpp:66
switch (op->type()) {
    case MNN::OpType_DepthwiseConvInt8:
    case MNN::OpType_ConvInt8:
    case MNN::OpType_ConvolutionDepthwise:
    case MNN::OpType_Convolution:
        ...
    case MNN::OpType_Attention:
        ...
    case MNN::OpType_LayerNorm:
        ...
}

以卷积为例，权重预处理入口是调用 OpCommonUtils::createExecutionWithExternal(...)：

// express/module/StaticModule.cpp:109
exe.reset(OpCommonUtils::createExecutionWithExternal(backend, info.inputs, info.outputs, op, &loader, tmpstorage));
if (exe.get() == nullptr) {
    exe.reset(OpCommonUtils::createExecutionWithExternal(backupBackend, info.inputs, info.outputs, op, &loader, tmpstorage));
}

createExecutionWithExternal(...) 中先判断当前 Op 是否使用 external data。如果是卷积、Scale 或 LayerNorm 这类带外部权重的算子，它会调用 _RebuildExternalOp(...) 临时重建一个带权重信息的 Op，再交给 backend->onCreate(...)：

// source/core/OpCommonUtils.cpp:669
bool hasExternal = false;
switch (op->main_type()) {
    case OpParameter_Convolution2D:
        hasExternal = USE_EXTERNAL_DATA(op->main_as_Convolution2D());
        break;
    case OpParameter_Scale:
        hasExternal = USE_EXTERNAL_DATA(op->main_as_Scale());
        break;
    case OpParameter_LayerNorm:
        hasExternal = USE_EXTERNAL_DATA(op->main_as_LayerNorm());
        break;
}

// source/core/OpCommonUtils.cpp:692
bool res = _RebuildExternalOp(externalFile, op, builder);
auto newOp = flatbuffers::GetRoot<MNN::Op>(builder.GetBufferPointer());
execution = backend->onCreate(inputs, outputs, newOp);

具体来说，对于卷积，_RebuildExternalOp(...) 会根据 Convolution2D.external 里的 offset/size 读外部权重文件。PTQ / sparse 量化卷积会把 quanParameter->buffer、alpha 等字段读回 Op；bias、index 这类字段则按 external 里的长度决定是否读取。非量化卷积会把 externalPath 写回新的 Op，并把 bias 读出来，后面的 ConvolutionCommon::load 再继续按 externalPath 加载权重：

// source/core/OpCommonUtils.cpp:604
case OpParameter_Convolution2D: {
    std::unique_ptr<Convolution2DT> param(origin->main_as_Convolution2D()->UnPack());
    if (param->quanParameter) {
        external->offset(param->external[0]);
        param->quanParameter->buffer.resize(param->external[1]);
        external->read((char*)param->quanParameter->buffer.data(), param->external[1]);
        param->quanParameter->alpha.resize(param->external[2] / sizeof(float));
        external->read((char*)param->quanParameter->alpha.data(), param->external[2]);
        ...
    } else {
        param->quanParameter.reset(new IDSTQuanT);
        param->quanParameter->type = 8;
        externalPathFbb = builder.CreateString(external->path());
        param->bias.resize(param->external[2] / sizeof(float));
        external->read((char*)param->bias.data(), param->external[2]);
    }
}

重建op后，会继续调用backend->onCreate(...)方法创建 Execution 。以 CPU dense convolution 为例，会进入 DenseConvolutionTiledExecutor类的初始化。这里的卷积会走 im2col + GEMM 思路，所以卷积核最终要变成 matmul 的 B 矩阵。原始权重可以理解成：

`1`	`weight[outputChannel, inputChannel, kernelY, kernelX]`

CPU 后端需要的不是这个连续布局，而是按 matmul kernel 的 pack 参数整理过的 mResource->mWeight：

// source/backend/cpu/compute/DenseConvolutionTiledExecutor.cpp:163
auto outputCount = (int)biasSize;
core->MNNGetMatMulPackMode(&eP, &lP, &hP);
auto srcCount = originWeightSize / outputCount / common->kernelX() / common->kernelY();
auto kernelSize = common->kernelX() * common->kernelY();
auto hU = UP_DIV(outputCount, hP);
auto lU = UP_DIV(srcCount, lP) * kernelSize;

// source/backend/cpu/compute/DenseConvolutionTiledExecutor.cpp:192
mResource->mWeight.reset(Tensor::createDevice<uint8_t>({hU * hP, lU * lP, bytes}));
initWeight(mResource->mWeight->host<float>(), originWeight, cache->host<float>(), srcCount, outputCount, kernelSize, core);

float 权重的重排分两步。第一步先在每个输出通道内交换 kernel 和 input channel 的顺序：

// source/backend/cpu/compute/ConvolutionTiledExecutor.cpp:24
void ConvolutionTiledExecutor::initWeight(...) {
    // Swap k, ic
    int dims[4] = { depth, kernelSize, kernelSize, depth };
    for (int o = 0; o < outputCount; ++o) {
        auto dO = cache + o * depth * kernelSize;
        auto sO = source + o * depth * kernelSize;
        MNNTranspose32Bit((int32_t*)dO, (const int32_t*)sO, &dims[0]);
    }
}

也就是从每个输出通道下的：

`1`	`[inputChannel, kernelY * kernelX]`

转成：

`1`	`[kernelY * kernelX, inputChannel]`

第二步再调用 MNNPackForMatMul_B(...)，把这个二维矩阵打包成 CPU matmul kernel 最容易读取的 B 矩阵布局：

// source/backend/cpu/compute/DenseConvolutionTiledExecutor.cpp:25
void DenseConvolutionTiledExecutor::initWeight(...) {
    ConvolutionTiledExecutor::initWeight(source, cache, depth, outputCount, kernelSize, function);
    function->MNNPackForMatMul_B(dest, cache, outputCount, kernelSize, depth, true);
}

把原始卷积核从 outputChannel/inputChannel/kernel 顺序，改成后端 GEMM 内核按 hP/lP 分块读取的布局。这样执行阶段只需要做输入的 im2col/blit，再直接和预打包好的 mResource->mWeight 做 packed matmul，不需要第一次 forward 时再整理权重。

如果是 int8/int4 权重，重排对象还包括量化信息。initQuantizeResource(...) 会把 int4 先展开成 int8，然后按 hU/lU/hP/lP 写入 resource->mWeight，同时把 scale/bias 保存到 mDequantize.mScaleBias：

// source/backend/cpu/compute/DenseConvolutionTiledExecutor.cpp:55
if (int8Info->canUseInt4) {
    // Revert int4 to int8
    blob.resize(int8Info->weight.size() * 2);
    ...
}

// source/backend/cpu/compute/DenseConvolutionTiledExecutor.cpp:70
resource->mWeight.reset(Tensor::createDevice<int8_t>({hU, lU * lP, hP}));
for (int y = 0; y < outputCount; ++y) {
    int yo = y / hP;
    int yi = y % hP;
    auto srcY = srcWInt8 + y * srcChannel * kernelSize;
    auto dstY = dstWInt8 + yo * lP * hP * lU + yi;
    for (int iz = 0; iz < srcChannel; ++iz) {
        for (int k = 0; k < kernelSize; ++k) {
            int sx = iz * kernelSize + k;
            int dx = iz + k * srcChannel;
            dstY[dx * hP] = srcY[sx];
        }
    }
}

此时Execution 里已经持有适合 Backend 执行的 mResource->mWeight、bias、scale 等资源。当后续 Session::resize() / Pipeline::allocMemory() 遇到同一个 Op，可以直接复用 info.executionCache 里的 Execution，不再重新进行 external weight 解析和 pack 权重。

卷积分支创建成功后，还会清掉 op_table 里的原始权重字段：

// express/module/StaticModule.cpp:122
op_table->main.AsConvolution2D()->bias.clear();
op_table->main.AsConvolution2D()->weight.clear();
if (nullptr != op_table->main.AsConvolution2D()->symmetricQuan) {
    op_table->main.AsConvolution2D()->symmetricQuan->bias.clear();
    op_table->main.AsConvolution2D()->symmetricQuan->weight.clear();
}
if (nullptr != op_table->main.AsConvolution2D()->quanParameter) {
    op_table->main.AsConvolution2D()->quanParameter->alpha.clear();
    op_table->main.AsConvolution2D()->quanParameter->buffer.clear();
}

这一步的含义是：权重已经被 backend 的 Execution 使用并重排，原始 Op 里的 raw weight / bias / 量化 buffer 等不再继续保留。

5.6 创建 `Pipeline`

StaticModule 里构造 Session 后，Session 构造函数会继续为每条 pipeline 创建 Pipeline 对象：

// source/core/Session.cpp:157
for (auto& iter : mInfo.pipelineInfo) {
    createPipelineBackend(iter, mRuntime);
    std::shared_ptr<Pipeline> newPipeline(
        new Pipeline(mInfo.externalWeightPath, std::move(iter), ..., rt, cpuRuntime.get(), geoMask));
    mPipelines.emplace_back(std::move(newPipeline));
}

Session 这一层负责把调度结果落成真正的执行流水线：

Session 持有运行时 RuntimeInfo；
Session 会把调度阶段生成的 pipelineInfo 落成一组真正的 Pipeline；
每个 Pipeline 不在构造函数里直接执行算子，而是在 Session::resize() 和 Session::run() 里分阶段执行 encode、allocMemory、execute等算子生成、分配内存、执行等命令。

对 LLM 推理路径来说，可以把 Session 理解成“执行层总控”：

resize() 负责让所有 Pipeline 完成 command 生成、Execution 创建和内存分配；
run() 负责按顺序调用每条 Pipeline::execute()；
clone(...) 则允许 ModulePool 在加载完成后快速复制出多份可独立运行的执行实例。

源码里这两个阶段直接调用所有执行流水线的接口：

// source/core/Session.cpp:272
ErrorCode Session::resize() {
    if (mNeedResize) {
        for (auto& iter : mPipelines) {
            iter->encode(debug, permitCodegen);
        }
        mNeedMalloc = true;
    }
    if (mNeedMalloc) {
        for (auto& iter : mPipelines) {
            iter->allocMemory(firstMalloc, forbidReplace);
        }
    }
}

// source/core/Session.cpp:243
ErrorCode Session::run() const {
    for (auto& iter : mPipelines) {
        iter->execute();
    }
}

5.7 执行具体算子

Pipeline 再往下就是具体执行阶段，这里的 encode() 是把调度结果整理成 MNN 内部的 command buffer，其包括算子、输入输出等属性：

// source/core/Pipeline.cpp:201
ErrorCode Pipeline::encode(bool supportDebug, bool permitCodegen) {
    if (!mInfo.first.needComputeGeometry) {
        // Static Model just copy info to command buffer
        cmd->op = info.op;
        cmd->inputs = info.inputs;
        cmd->outputs = info.outputs;
        info.executeBuffer.command = {cmd};
    } else {
        GeometryComputerUtils::shapeComputeAndGeometryTransform(...);
    }
}

encode()方法主要是把 OpCacheInfo 里的 op / inputs / outputs 拷到 executeBuffer.command。如果需要 geometry transform，它会调用 GeometryComputerUtils::shapeComputeAndGeometryTransform(...)，在 resize 阶段重新做 shape compute、常量计算和 command buffer 生成。

Session的resize方法还会调用 Pipeline::allocMemory()方法，为每个 command 创建具体 Execution，绑定 tensor backend，并分配输入、中间结果和输出 tensor 的内存。

执行时调用Pipeline::execute() 方法按顺序真正执行这些 command。模型已经从“图结构”落成了“可执行算子序列”。

从Pipeline的执行视角如下：

`encode()`
    ↓
把 `OpCacheInfo` 整理成 command buffer
    ↓
`allocMemory()`
    ↓
为每条 command 创建 `Execution`，绑定 backend，并分配 Tensor 内存
    ↓
`execute()`
    ↓
循环调用 `Execution::onExecute(...)`

5.8 总览

把前面几层连起来，可以把 Module::load(...) 之后的对象关系分成两段看。

第一段是模块包装和调度信息生成：

NetModule 是 Module::load(...) 返回的最外层包装，保存模型 Info，并在 onForward() 里转调内部真实模块；
PipelineModule 负责把 Net 整理成输入输出索引、执行顺序、子模块和 ScheduleInfo；
静态加载路径下，PipelineModule::load(...) 最终会创建 StaticModule。

第二段才是实际执行层：

StaticModule 管输入输出和 Session
Session 管多条 Pipeline
Pipeline 管 command buffer
Execution 才是真正单个算子的后端实现

6. 其它准备

6.1 解码策略

主 Module 加载完成后，llm.cpp 还会继续准备与解码策略相关对象：

1
2
3

// transformers/llm/engine/src/llm.cpp:312
setSpeculativeConfig();
mGenerationStrategy = GenerationStrategyFactory::create(this, mContext, mConfig, mInSpec);

其中包括ArGeneration、LookaheadGeneration、MtpGeneration、EagleGeneration等多种解码策略，然后初始化模型池 ModulePool，这是输入长度seq_len+isAllLogists(当前是否需要返回全量 logits)到Module类的映射，如果不存在对应长度需要clone模型：

// transformers/llm/engine/src/llm.cpp:318
if (mInSpec) {
    mModulePool[std::make_pair(verify_length, true)].reset(Module::clone(mModule.get()));
}
mModulePool[std::make_pair(1, false)].reset(Module::clone(mModule.get()));
mModulePool[std::make_pair(mPrefillKey, mConfig->all_logits())] = mModule;

6.2 预分配常用变量

加载最后还会创建常用的输入变量缓存如attention mask 和 position ids：

// transformers/llm/engine/src/llm.cpp:332
logitsLastIdx = _var<int>({-1}, {1});
logitsAllIdx = _var<int>({0}, {1});

mAttentionMaskVarVec.resize(decode_type_num);
mPositionIdsVarVec.resize(decode_type_num);

然后针对 decode 场景预写好常用 mask 和 position id Tensor，避免单 token decode 时反复重新建图、重新分配小 Tensor。

6.3 加载结束

load() 成功返回时，程序里不只包含“模型”，同时已经具备了完整的推理状态，此时已经就绪的核心对象

mRuntimeManager：已绑定好后端、线程、mmap、KV hint；
mTokenizer：已能编码/解码和套用模板；
mDiskEmbedding：已能按 token 从磁盘拉 embedding；
mSampler：已按配置搭好采样流水线；
mModule：已完成图加载；
mModulePool：已准备好 prefill/decode 所需模块副本；
mMeta：已带上层数、KV 状态、attention scale；
mGenerationStrategy：已选好 AR / Lookahead / MTP / Eagle。

LLM 配置

Thu, 26 Feb 2026 23:00:00 +0800

LLM 配置

MNN的LLM的推理流程涉及很多配置信息，本篇梳理 transformers/llm/engine/src/llmconfig.hpp 和 llm.cpp 中提到到 MNN LLM 的配置项config.json，它同时负责模型文件定位、Runtime 选项、生成行为和导出阶段写入的模型元信息。

LLM 配置

1. 配置文件加载

通常一份部署目录中会包括：

model_dir/
├── config.json        # 运行时和部署侧配置
├── llm_config.json    # 导出时写入的模型结构配置
├── llm.mnn            # 模型文件
├── llm.mnn.weight     # 权重文件
├── tokenizer.txt / tokenizer.mtok # tokenizer 文件
└── embeddings_bf16.bin            # 磁盘词向量表

配置入口类是 LlmConfig。构造函数里做了两步 merge：

// transformers/llm/engine/src/llmconfig.hpp:234
LlmConfig(const std::string& path) {
    if (has_suffix(path, ".json")) {
        std::ifstream config_file(path);
        config_ = ujson::json::parse(...);
        base_dir_ = base_dir(path);
    } else {
        // 兼容旧用法
    }
    base_dir_ = config_.value("base_dir", base_dir_);

    std::ifstream llm_config_file(llm_config());
    if (llm_config_file.is_open()) {
        auto llm_config_ = ujson::json::parse(...);
        config_.merge_and_clear(llm_config_);
    }
    mllm_config_ = config_.contains("mllm") ? config_["mllm"] : ujson::json();
}

主要包括：

启动配置：通常是用户显示传入的 config.json，包括运行时和部署侧配置；
模型配置：默认会继续读取同目录下的 llm_config.json，包括模型结构和导出元信息；
多模态子配置：如果有 mllm 字段，会单独保存给视觉/音频侧使用。

配置类的构造函数实际做的是：

先读取用户传入的 config.json，并确定 base_dir_；
再根据 llm_config() 找到同目录下的 llm_config.json；
调用 config_.merge_and_clear(llm_config_) 把模型导出时写入的元信息合并进来；
最后单独取出 mllm 子配置，给多模态路径复用。

2. 各项参数

LlmConfig 包含了各项参数，如模型文件参数、运行时参数等等，简单说明如下。

2.1 模型文件

参数中涉及模型文件的参数有: 模型文件、权重文件和 tokenizer 文件：

// transformers/llm/engine/src/llmconfig.hpp:279
std::string llm_model() const { return base_dir_ + config_.value("llm_model", "llm.mnn"); }
std::string llm_weight() const { return base_dir_ + config_.value("llm_weight", "llm.mnn.weight"); }
std::string tokenizer_file() const { return base_dir_ + config_.value("tokenizer_file", "tokenizer.txt"); }

除了主图和权重外，MNN-LLM 还会额外读这些资源：

配置项	默认值	用途
`embedding_file`	`embeddings_bf16.bin`	磁盘词向量表，`DiskEmbedding` 读取
`context_file`	`context.json`	聊天模板上下文，会合并到 `jinja.context`
`llm_config`	`llm_config.json`	导出阶段写入的模型结构信息
`npu_model_dir`	`""`	NPU 后端缓存/编译结果目录

如果聊天模板依赖额外上下文字段，这部分不是硬编码在引擎里的，而是通过 context.json 注入：

// transformers/llm/engine/src/llm.cpp:246
std::ifstream contextFile(mConfig->context_file());
if (contextFile.is_open()) {
    auto contextJson = ujson::json::parse(contextStr);
    std::string config_json = R"({
        "jinja": {
            "context": )" + contextStr + R"(
        }
    })";
    mConfig->config_.merge(ujson::json::parse(config_json));
}

LlmConfig 还定义了很多可选文件，用来支持多模态与扩展模型等，比如：

visual_model：视觉子模型路径，用于图像/视频侧 embedding 或多模态编码。
audio_model：音频子模型路径，用于语音输入相关的特征提取。
talker_model：语音/多模态输出侧的 talker 子模型路径。
mtp_model：MTP speculative decoding 使用的 draft 模型路径。
eagle_model：Eagle speculative decoding 使用的 draft 模型路径。

这些字段覆盖多模态 Omni 模型、推测解码的 MTP / Eagle 草稿模型，以及 talker 一类的扩展分支。

2.2 运行时配置

运行时配置的核心目标是：配置MNN后端、精度、内存策略等, 常见字段有：

// transformers/llm/engine/src/llmconfig.hpp:343
std::string backend_type(bool mllm = false) const {
    if (mllm) return mllm_config_.value("backend_type", "cpu");
    return config_.value("backend_type", "cpu");
}
int thread_num(bool mllm = false) const {
    if (mllm) return mllm_config_.value("thread_num", 4);
    return config_.value("thread_num", 4);
}
std::string precision(bool mllm = false) const {
    if (mllm) return mllm_config_.value("precision", "low");
    return config_.value("precision", "low");
}
std::string power(bool mllm = false) const {
    if (mllm) return mllm_config_.value("power", "normal");
    return config_.value("power", "normal");
}
std::string memory(bool mllm = false) const {
    if (mllm) return mllm_config_.value("memory", "low");
    return config_.value("memory", "low");
}

此外，Llm::setRuntimeHint() 会继续把很多配置转成 Interpreter Hint：

// transformers/llm/engine/src/llm.cpp:132
int legacyAttentionMode = mConfig->config_.value("quant_qkv", 8);
int attentionMode = mConfig->config_.value("attention_mode", legacyAttentionMode);
rtg->setHint(MNN::Interpreter::ATTENTION_OPTION, attentionMode);
rtg->setHint(MNN::Interpreter::DYNAMIC_QUANT_OPTIONS, mConfig->config_.value("dynamic_option", 0));
rtg->setHintPtr(Interpreter::KVCACHE_INFO, mMeta.get());

这些字段会直接影响底层 Runtime 的执行策略，例如：

attention_mode 代码读取的 attention 执行模式配置；
quant_qkv 兼容旧字段入口；
dynamic_option 会直接作为动态量化相关 Hint 传给 Interpreter。

2.3 推理行为配置

这部分配置决定“模型怎么生成token”,从配置到实际类参数设置的流程如下：

`LlmConfig`
    ↓
`generate_init()`                 # `reuse_kv`
`Prompt::createPrompt()`         # `system_prompt` / `prompt_template` / `chat_template`
`Sampler::createSampler(...)`    # `temperature` / `topK` / `topP`
`forwardVec(...)`                # `chunk` / `chunk_limits`
`GenerationStrategyFactory`      # `speculative_type` / `eagle_model`

最基础的一组生成参数如下：

// transformers/llm/engine/src/llmconfig.hpp:325
int max_all_tokens() const { return config_.value("max_all_tokens", 2048); }
int max_new_tokens() const { return config_.value("max_new_tokens", 512); }
bool reuse_kv() const { return config_.value("reuse_kv", false); }
bool all_logits() const { return config_.value("all_logits", false); }

它们分别影响：

最长上下文和最长新生成 token 数；
多轮对话时是否复用内存中的 KV Cache；
Prefill 是否保留全量 logits。

此外，LLM 的 prompt 模板不只是 prompt_template 一个字段，LlmConfig 里还定义了下面的模板：

system_prompt：默认系统提示词内容。
system_prompt_template：system 角色的模板。
user_prompt_template：user 角色的模板。
assistant_prompt_template：assistant 角色的模板。
chat_template：完整对话模板，通常用于多轮消息拼接。
prompt_template：单轮 prompt 包装模板，兼容较简单的输入格式。
use_template：是否启用模板拼接。

采样相关配置则基本都在 transformers/llm/engine/src/sampler.hpp的Sampler 类里使用：

sampler_type：采样器类型，例如 penalty / mixed 等策略入口。
temperature：采样温度，控制 logits 分布平滑程度。
topK：只在概率最高的前 K 个 token 中采样。
topP：nucleus sampling 阈值，按累计概率截断候选 token。
minP：按最大概率比例过滤过低概率 token。
tfsZ：tail free sampling 参数。
typical：typical sampling 参数。
repetition_penalty：重复 token 惩罚。
presence_penalty：出现过的 token 惩罚。
frequency_penalty：按出现频率增加惩罚。
penalty_window：重复惩罚的历史窗口长度。
logit_bias：对指定 token 的 logits 做偏置调整。
banned_tokens：禁止生成的 token 列表。

如果 prompt 很长，MNN-LLM 还支持分块 prefill：

// transformers/llm/engine/src/llm.cpp:101
if (mConfig->config_.document.HasMember("chunk")) {
    mBlockSize = mConfig->config_.document["chunk"].GetInt();
}
if (mConfig->config_.document.HasMember("chunk_limits")) {
    ...
}

另外，推测解码相关配置包括：

speculative_type：选择推测解码类型，例如 MTP / Eagle / lookahead。
draft_predict_length：draft 阶段一次预测的 token 数。
draft_match_strictness：主模型验证 draft token 时的匹配严格程度。
draft_selection_rule：draft 候选 token 的选择规则。
ngram_match_maxlen：lookahead / ngram 路径里最大匹配长度。
ngram_update：是否更新 ngram 相关缓存。
draft_model：通用 draft 模型路径。
mtp_model：MTP draft 模型路径。
eagle_model：Eagle draft 模型路径。

GenerationStrategyFactory::create(...) 会根据这些字段决定使用哪些解码策略：

ArGeneration：自回归贪心解码策略。
LookaheadGeneration：lookahead / ngram 相关生成策略。
MtpGeneration：MTP 推测解码策略。
EagleGeneration：Eagle3 推测解码策略。

3. 配置实例

以 Qwen3-1.7B-MNN 的配置为例：

{
    "llm_model": "llm.mnn",
    "llm_weight": "llm.mnn.weight",
    "backend_type": "cpu",
    "thread_num": 4,
    "precision": "low",
    "memory": "low",
    "sampler_type": "mixed",
    "mixed_samplers": [
        "penalty",
        "topK",
        "topP",
        "min_p",
        "temperature"
    ],
    "penalty": 1.1,
    "temperature": 0.6,
    "topP": 0.95,
    "topK": 20,
    "min_p": 0
}

这个配置里包括了模型文件、运行时选项和采样策略的配置，实际运行时可以按需配置参数。

MNN Backend 介绍

Thu, 26 Feb 2026 23:00:00 +0800

MNN 后端介绍

本文将介绍MNN框架的后端支持，并介绍后端有关的核心代码与功能。

MNN 后端介绍
- 1. 后端介绍
- 2. 后端代码
  - 2.1 后端文件说明
  - 2.2 后端调用设置
    - 2.2.1 Core Function

1. 后端介绍

MNN是阿里巴巴开源的高效轻量级深度学习推理框架，提供了较为全面的后端支持。主要包括:

架构/精度	类型	Normal	FP16	BF16	Int8
CPU	Native	B	C	B	B
CPU	x86/x64-SSE4.1	A	C	C	A
CPU	x86/x64-AVX2	S	C	C	A
CPU	x86/x64-AVX512	S	C	C	S
CPU	ARMv7a	S	S（ARMv8.2）	C	S
CPU	ARMv8	S	S（ARMv8.2）	S（ARMv8.6）	S
GPU	OpenCL	A	S	C	S
GPU	Vulkan	A	A	C	A
GPU	Metal	A	S	C	S
GPU	CUDA	A	S	C	A
NPU	CoreML	A	C	C	C
NPU	HIAI	A	C	C	C
NPU	NNAPI	B	B	C	B
NPU	QNN	C	B	C	C

S（Support and work well）：深度优化，推荐使用
A（Support and work well）：支持良好，可以使用
B（Support but has bug or not optimized）：支持但有bug或未优化，不推荐使用
C（Not Support）：不支持

1.1 CPU后端系列

1.1.1 x86/x64-SSE4.1后端

技术背景： SSE4.1（Streaming SIMD Extensions 4.1）是Intel在2007年推出的SIMD指令集扩展，提供了47条新指令，主要用于加速多媒体和浮点运算。

适用设备：一般是较老CPU

Intel Core系列处理器（2008年后）
AMD处理器（部分支持）
服务器和桌面PC
部分笔记本电脑

技术特点：

128位SIMD寄存器
支持打包整数和浮点运算
提供点积、混合、提取和插入操作

1.1.2 x86/x64-AVX2后端

技术背景： AVX2（Advanced Vector Extensions 2）是Intel在2013年推出的256位SIMD指令集，是AVX的增强版本，提供了更宽的向量寄存器和更多的指令。

适用设备：主流CPU

Intel Haswell架构及以后的处理器
AMD Excavator架构及以后的处理器
现代服务器和高性能工作站
游戏PC和高端笔记本

1.1.3 x86/x64-AVX512后端

技术背景： AVX512是Intel最新的512位SIMD指令集，首次出现在Xeon Phi处理器中，后来扩展到Xeon和Core系列。

适用设备：主流高性能CPU

Intel Xeon Scalable处理器
Intel Core i7/i9高端处理器（部分型号）
高性能计算服务器
AI训练和推理专用硬件

1.1.4 ARMv7a后端

技术背景： ARMv7-A是ARM公司的32位架构，广泛应用于早期智能手机和嵌入式设备。支持NEON SIMD指令集。

适用设备：一般是比较老旧的移动端CPU

早期Android手机（2010-2015年）
Raspberry Pi 2
部分嵌入式开发板
工业控制设备

1.1.5 ARMv8后端

技术背景： ARMv8-A是ARM的64位架构，是现代移动设备的主流架构，提供了更强的性能和更大的内存寻址空间。

适用设备：当前主流的移动端CPU

现代智能手机（iPhone 5s以后，Android旗舰机）
平板电脑
ARM服务器（如AWS Graviton）
Apple M系列芯片设备
Raspberry Pi 3/4

1.2 GPU后端系列

1.2.1 OpenCL后端

技术背景： OpenCL（Open Computing Language）是Khronos Group制定的开放标准，用于异构计算平台的并行编程。

适用设备：除专用的GPU后端外，主流的GPU后端

支持OpenCL的GPU（NVIDIA、AMD、Intel）
部分移动GPU（Adreno、Mali、PowerVR）
FPGA设备
DSP处理器

1.2.2 Vulkan后端

技术背景： Vulkan是Khronos Group开发的低开销、跨平台的3D图形和计算API，提供了更直接的GPU控制。

适用设备：大部分GPU支持的后端

现代GPU（NVIDIA GTX 900系列以后）
AMD GCN架构GPU
Intel集成显卡（部分支持）
Android设备（API 24+）

1.2.3 Metal后端

技术背景： Metal是Apple开发的低级图形和计算API，专为Apple设备优化，提供了接近硬件的性能。

适用设备：ios设备的GPU后端

iPhone iPad Mac等

1.2.4 CUDA后端

技术背景： CUDA（Compute Unified Device Architecture）是NVIDIA开发的并行计算平台和编程模型，专为NVIDIA GPU设计。

适用设备：NVIDIA GPU的专用后端

NVIDIA GeForce系列GPU
NVIDIA Quadro专业卡
NVIDIA Tesla计算卡
NVIDIA Jetson嵌入式平台

1.2.5 OpenGL后端

技术背景：OpenGL（Open Graphics Library）是一个图形渲染 API 标准，可以利用 GPU 并行计算能力处理非图形任务

适用设备：大部分GPU支持的后端

支持OpenCL的GPU（NVIDIA等）
部分移动GPU（Adreno等）

1.3 专用加速器

1.3.1 CoreML后端

技术背景： Core ML是Apple的机器学习框架，能够利用Apple设备的Neural Engine进行AI推理加速。

适用设备：当前主流的apple ai加速器

iPhone（A11芯片以后，支持Neural Engine）
iPad Pro（A12芯片等）
Mac（M1芯片等）

1.3.2 HIAI后端

技术背景： HIAI（Huawei Intelligent Acceleration Infrastructure）是华为开发的AI加速平台，利用华为麒麟芯片的NPU。

适用设备：当前主流的华为 ai加速器

华为/荣耀手机（麒麟970以后）
华为平板电脑
华为笔记本电脑（部分型号）

1.3.3 NNAPI后端

技术背景： NNAPI（Neural Networks API）是Google在Android 8.1中引入的API，为Android设备提供统一的AI加速接口。

适用设备：在 Android 15 中已弃用。在专用供应商驱动程序的Android设备运行，缺乏时运行在 CPU 上

Android 8.1+设备

1.3.4 QNN后端

技术背景： QNN（Qualcomm Neural Network SDK）是高通开发的AI推理SDK，专为高通Snapdragon平台优化。

适用设备：主流的高通芯片NPU后端

搭载Snapdragon处理器的设备
支持Hexagon DSP的设备
高通AI开发套件

1.3.5 NeuroPilot 后端

技术背景： NeuroPilot SDK是联发科自研的专用 AI 加速硬件单元SDK，集成于天玑（Dimensity）系列 SoC 中。主要通过 NNAPI 间接调用 APU 硬件加速

适用设备：主流的天玑芯片APU后端

搭载天玑系列处理器的设备
支持 NeuroPilot SDK 且 Android 10+（API 29+）的联发科平台设备

2. 后端代码

MNN的后端实现集中在source/backend/目录中：

source/backend/
├── cpu/              # CPU 通用后端
│   ├── x86_x64/
│   │   ├── avx/      # x86 AVX2 优化
│   │   ├── avx512/   # x86 AVX512 优化
│   │   ├── avxfma/   # x86 AVX FMA 优化
│   │   └── sse/      # x86 SSE 优化
│   └── arm/
│       ├── arm32/    # 32 位 ARM 指令支持，如 ARMv7-A
│       └── arm64/    # 64 位 ARM 指令支持
├── arm82/            # ARMv8.2 支持
│   └── asm/
│       ├── arm32/    # 32 位 ARM 指令兼容
│       └── arm64/    # 64 位 ARM 指令支持
├── nnapi/        # NNAPI后端
├── metal/        # Metal后端（iOS/macOS）
├── opencl/       # OpenCL后端
├── opengl/       # OpenGL后端
├── vulkan/       # Vulkan后端
├── cuda/         # CUDA后端
├── tensorrt
├── coreml/       # CoreML后端
├── hiai/         # HIAI后端
├── qnn/          # QNN后端
└── neuropilot/   # NeuroPilot后端

相应的后端需要设置指定的编译宏，例如-DMNN_OPENCL=true表示启用OPENCL后端支持，但是具体调用需要在程序中设置，例如MNN-LLM需要设置… 具体见后续的代码梳理

2.1 后端文件说明

MNN 的后端系统由以下几个核心类组成，大致执行顺序如下：

创建关系

Runtime
├── 表示一类硬件运行时，例如 `CPURuntime`、`OpenCLRuntime`
└── onCreate(...)
    ↓
Backend
├── 表示一次具体的执行层后端实例，例如 `CPUBackend`、`OpenCLBackend`
└── onCreate(inputs, outputs, op)
    ↓
Execution
└── 表示单个算子的具体执行对象，例如 `CPUConvolution`、`CPUAttention`


执行关系

Shape 推导
`SizeComputer::computeOutputSize()`

Resize 阶段
`Backend::onResizeBegin()`
        ↓
`Execution::onResize()`
        ↓
`Backend::onResizeEnd()`

Execute 阶段
`Backend::onExecuteBegin()`
        ↓
`Execution::onExecute()`
        ↓
`Backend::onExecuteEnd()`

如果只看职责分层，可以把这三个类理解成：

Runtime 负责“这一类硬件资源如何初始化、如何配置”；
Backend 负责“这一轮推理具体使用哪份资源、如何管理张量和中间缓冲区”；
Execution 负责“某个算子在这个后端上如何真正执行”。

它们不是并列关系，而是 Runtime -> Backend -> Execution 逐层下沉。前面的 Shape 推导则是另一条独立流程，主要由 source/shape/ 下的 SizeComputer 系统完成，执行层会在 resize 阶段消费这部分结果。

2.1.1 Runtime - 运行时抽象层

位置：source/core/Backend.hpp

Runtime 是硬件运行时的抽象层，负责管理整个后端的生命周期和资源配置。

核心职责：

创建 Backend 实例
管理线程池和内存分配器
提供垃圾回收机制
支持异步执行和并发控制

关键接口：

class Runtime : public NonCopyable {
public:
    // 创建 Backend
    virtual Backend* onCreate(const BackendConfig* config,  Backend* origin) const = 0;
    // 重置运行时配置
    virtual void onReset(int numberThread,  const BackendConfig* config,  bool full);
    
    // 垃圾回收
    virtual void onGabageCollect(int level) = 0;
    // 获取内存使用量
    virtual float onGetMemoryInMB();
	
    // 主要是cpuruntime使用 cpu后端实现了线程池(source/backend/cpu/ThreadPool.hpp)
    virtual void onConcurrencyBegin() const = 0;
    virtual void onConcurrencyEnd() const = 0;
	
    // 执行优化,  mnn以算子图形式运行 下面是不同的运行方式
    enum CompilerType {
        Compiler_Geometry = 0,  // 部分执行几何计算，分解形变算子，但不分解 BatchMatMul / Gather 等算子
        Compiler_Origin = 1,  // 直接使用原始算子，不进行分解
        Compiler_Loop = 2,  // 完全执行几何计算，仅此模式下，可以在算子不支持时自动回退到CPU计算
    };
private:    
    // 记录运行时信息 如kvcacheSizeLimit cpuIds等
    RuntimeHint mHint;
};

2.1.2 Backend - 后端抽象基类

位置：source/core/Backend.hpp

Backend 是所有硬件后端的基类，定义了后端必须实现的接口。

核心职责：

管理内存分配和释放
创建 Execution
处理张量缓冲区操作
支持多种存储策略

存储类型枚举：

enum StorageType {
    STATIC,            // 不可重用内存，分配后立即释放
    DYNAMIC,           // 可重用内存，优先重用已有内存
    DYNAMIC_SEPERATE,  // 不可重用内存，但延迟释放
    DYNAMIC_IN_EXECUTION // 执行时动态分配
};

关键接口：

class Backend : public NonCopyable {
public:
    // 创建 Execution 
    virtual Execution* onCreate(const std::vector<Tensor*>& inputs, 
                                const std::vector<Tensor*>& outputs, 
                                const MNN::Op* op) = 0;

    // 执行算子Resize 的开始/结束的一些准备/收尾工作
    virtual void onResizeBegin();
    virtual ErrorCode onResizeEnd() = 0;
    // 执行算子execute 的开始/结束的一些准备/收尾工作
    // 例如OpenCLBackend中 
    virtual void onExecuteBegin() const = 0;
    virtual void onExecuteEnd() const = 0;

    // 内存管理
    virtual MemObj* onAcquire(const Tensor* tensor,  StorageType storageType) = 0;
    virtual bool onClearBuffer() = 0;
    virtual void onCopyBuffer(const Tensor* srcTensor,  const Tensor* dstTensor) const = 0;
    
    // 把数据映射到指定后端 / 从指定后端映射回数据
    virtual void* onMapTensor(Tensor::MapType mtype,  Tensor::DimensionType dtype,  const Tensor* srcTensor);
    virtual bool onUnmapTensor(Tensor::MapType mtype,  Tensor::DimensionType dtype,  const Tensor* dstTensor,  void* mapPtr);
    
    // 利用backend后端传递指针,  llm中主要传递kvmeta(kv cache有关信息)
    void setMetaPtr(void* ptr);

private:
    // 枚举类 记录执行后端 如cpu opencl为: MNN_FORWARD_CPU MNN_FORWARD_OPENCL
    const MNNForwardType mType;
};

2.1.3 Execution - 执行器抽象基类

位置：source/core/Execution.hpp

Execution 是算子执行的抽象基类，每个算子都有对应的 Execution 实现。

核心职责：

响应输入输出张量的形状变化
执行算子计算
支持克隆和共享权重

关键接口：

class Execution : public NonCopyable {
public:
    // 根据输入seq_len长度变化 调整执行时用到的值
    virtual ErrorCode onResize(const std::vector<Tensor*>& inputs, 
                               const std::vector<Tensor*>& outputs);

    // 执行计算
    virtual ErrorCode onExecute(const std::vector<Tensor*>& inputs, 
                                const std::vector<Tensor*>& outputs) = 0;

    // 克隆执行器 这在llm推理中很有用 例如prefill和decode之间的seq_len输入长度不一样 就会触发克隆 mnn默认保存不同输入长度的计算图
    // 这里通常不克隆权重,  权重在Op* op中 这里会通过指针引用
    virtual bool onClone(Backend* bn,  const Op* op,  Execution** dst);

    // 获取后端 例如在CPUAttention中利用这里获取kvmeta信息(mMeta = (KVMeta*)(backend->getMetaPtr());)
    Backend* backend() const;
};

2.2 后端调用设置

除了后端架构中的 Runtime、Backend、Execution 等核心类，MNN中还有部分特定基础算子的优化代码，例如source/backend/cpu/x86_x64/avx512/_AVX512_MNNGemmFloatUnit16x8.S 等，前者是汇编代码，后者是opencl的代码。

这里指的算子一般都是底层支持的基础算子，会在更上层的算子中被调用，例如CPUAttention中会调用core->Int8GemmKernel;以使用int8矩阵乘算子

2.2.1 Core Function

下面以CPU的后端在实例化过程中调用的不同后端的指令集为例说明，在source/backend/cpu/compute/CommonOptFunction.h中定义了CoreFunctions

struct CoreFunctions {
    // CPU 特性标志
    bool supportFp16arith = false;  // 支持 FP16 算术运算
    bool supportSDot = false;       // 支持 ARM S-Dot 指令
    bool supportI8mm = false;       // 支持 ARM I8MM 指令
    bool supportSME2 = false;       // 支持 ARM SME2 指令
    int  smeCoreNumber = 0;         // SME2 核心数量

    // 矩阵乘法相关函数
    void(*MNNGetMatMulPackMode)(int* eP,  int *lP,  int* hP);
    void(*MNNPackC4ForMatMul_A)(float* destOrigin,  float const** sourceGroup, 
                                 const int32_t* info,  const int32_t* el);
    void(*MNNPackForMatMul_B)(float* dest,  const float* source, 
                              size_t h,  size_t kernelsize,  size_t ic,  bool transpose);
    void(*MNNPackedMatMul)(float* C,  const float* A,  const float* B, 
                           const size_t* parameter,  const float* postParameters, 
                           const float* bias,  const float* k,  const float* b);
    void(*MNNPackedMatMulRemain)(float* C,  const float* A,  const float* B, 
                                 size_t eSize,  const size_t* parameter, 
                                 const float* postParameters,  const float* bias, 
                                 const float* k,  const float* b);
    // 激活函数
    void(*MNNReluInt8)(int8_t* dst,  const int8_t* src,  size_t size,  ssize_t zeroPoint);
    void(*MNNHardSwish)(float* dst,  const float* src,  size_t size);
    void(*MNNGelu)(float* dst,  const float* src,  size_t size,  float* parameters);
    const float *beta,  float epsilon,  size_t size,  bool RMSNorm);

    // 其他函数...
};

MNN 使用全局单例 gCoreFunction 来存储当前平台的最优函数实现，在程序启动时会选择各个函数的最优实现代码

// 在source/backend/cpu/CPUBackend.cpp 中创建runtime时 会进入到不同指令集的初始化注册过程
{
#ifdef MNN_SUPPORT_BF16
extern void registerBF16Backend();
#endif
#ifdef ENABLE_ARMV82
extern void registerArm82RuntimeCreator();
#endif
void registerCPURuntimeCreator() {
    MNNCoreFunctionInit();
    CPUBackend::initCreatorMap();
    registerCPUOps();
#ifdef MNN_SUPPORT_BF16
    registerBF16Backend();
#endif
#ifdef MNN_USE_ARMV82
    registerArm82RuntimeCreator();
#endif
    // TODO: Merge _initCoreFunction MNNFunctionInit and cpuinfo_arm_init
    MNNInsertExtraRuntimeCreator(MNN_FORWARD_CPU,  new CPURuntimeCreator);
}

// 下面以armv82的初始化为例 在Arm82Functions::init()中
Arm82Functions::init(){
    
    // 部分特殊优化的底层代码
    FUNC_PTR_ASSIGN(gInstance->MNNPackC4ForMatMul_A,  Arm82MNNPackForMatMul_A);
    /* 在声明中 这个代码是外部导入的,  路径位置source/backend/arm82/asm/arm64/Arm82MNNPackForMatMul_A.S
    extern "C" {
    // (UP_DIV(l, 8),  e,  8) -> (UP_DIV(e, eP),  l,  eP)
        void Arm82MNNPackForMatMul_A(float* destOrigin,  float const** sourceGroup,  const int32_t* info,  const int32_t* el);
    }
    */
    
    // 其它代码...
}

在cpu后端使用时通过调用后端的core function执行底层算子，如

// source/backend/cpu/CPUAttention.cpp
ErrorCode CPUAttention::onExecute(const std::vector<Tensor*>& inputs,  const std::vector<Tensor*>& outputs) {
    auto gcore  = static_cast<CPUBackend *>(backend())->functions();
    auto core   = static_cast<CPUBackend*>(backend())->int8Functions();
    // 其它代码...
 	
    // 调用后端的core functions终端矩阵乘法
    gcore->MNNPackedMatMul(...);
    
    // 其它代码...
}

其它后端的底层代码调用可能不同，如opencl后端的.cl代码source/backend/opencl/execution/cl/attention_buf.cl等通过运行时加载 Kernel 源码方式使用。

MNN 工厂模式介绍

Thu, 26 Feb 2026 23:00:00 +0800

MNN 介绍

MNN 同时支持多种硬件后端、多种算子实现以及多套算子 Shape 推导逻辑，MNN 把“选择谁来创建对象”统一交给工厂模式，避免多分支判断的方式选择实例化对象：运行时由 RuntimeCreator 工厂创建，执行阶段由各个后端自己的 Creator 工厂创建，Shape 推导则由 SizeComputerSuite 统一管理。本文按这三层工厂模式来梳理 MNN 的实现。

MNN 介绍

1. 工厂模式

MNN 中至少有三类“对象创建”场景：

层级	被创建的对象	解决的问题
Runtime 层	`Runtime` / `Backend`	不同硬件后端如何接入统一调度框架
Execution层	`Execution`	不同 `OpType` 如何绑定到对应后端实现
Shape 层	`SizeComputer`	不同算子如何推导输出形状

这三层在组织方式上基本一致：

维护一份 类型 -> Creator 的注册表；
各实现模块通过注册宏把对应 Creator 写入注册表；
执行阶段根据 type 或 OpType 查表并完成对象创建。

这种组织方式对应的工程效果主要有三点：

调用层与实现层分离：调度逻辑依赖统一接口，不直接依赖具体实现类。
扩展点清晰：新增后端或新增算子实现时，通常只需要补充 Creator 和对应注册逻辑。
编译边界明确：OpenCL、Metal、QNN 这类后端可以按编译选项决定是否参与注册。

2. Runtime 工厂

这一层对应的核心类是 RuntimeCreator、Runtime 和 Backend。RuntimeCreator 负责把后端类型映射到具体 Runtime 创建逻辑，Runtime 负责管理某个后端族的资源、能力和 Backend 创建过程，Backend 则是后续执行阶段真正参与算子执行的对象。

2.1 全局 RuntimeCreator 注册表

Runtime 工厂入口位于 source/core/Backend.cpp。核心结构是一张以 MNNForwardType 为 key 的全局注册表：

static std::map<MNNForwardType, std::pair<const RuntimeCreator*, bool>>& GetExtraCreator() {
    static std::once_flag gInitFlag;
    static std::map<MNNForwardType, std::pair<const RuntimeCreator*, bool>>* gExtraCreator;
    // 延迟初始化全局 RuntimeCreator 注册表
    std::call_once(gInitFlag,
                   [&]() { gExtraCreator = new std::map<MNNForwardType, std::pair<const RuntimeCreator*, bool>>; });
    return *gExtraCreator;
}

这里构建的是后端类型到RutimeCreator的映射表，RuntimeCreator 是一个抽象接口，定义了创建 Runtime 的方法，后端类型包括 MNN_FORWARD_CPU、MNN_FORWARD_OPENCL、MNN_FORWARD_METAL等。

对外暴露的两个核心接口如下：

1
2

const RuntimeCreator* MNNGetExtraRuntimeCreator(MNNForwardType type);
bool MNNInsertExtraRuntimeCreator(MNNForwardType type, const RuntimeCreator* creator, bool needCheck);

这一层的职责很明确：维护 后端类型 -> RuntimeCreator 的映射，并在运行时按后端类型返回对应的创建入口。

2.2 注册过程

注册入口在 source/core/Backend.cpp 的 registerBackend()：

void registerBackend() {
    std::call_once(s_flag, [&]() {
        // 先注册 CPU Runtime，再初始化 shape / geometry 相关工厂
        registerCPURuntimeCreator();
        SizeComputerSuite::init();
        GeometryComputer::init();
        // 其它后端按编译选项继续注册
    });
}

CPU 后端的注册逻辑位于 source/backend/cpu/CPUBackend.cpp：

void registerCPURuntimeCreator() {
    MNNCoreFunctionInit();
    CPUBackend::initCreatorMap();
    registerCPUOps();
    MNNInsertExtraRuntimeCreator(MNN_FORWARD_CPU, new CPURuntimeCreator);
};

这段初始化顺序对应三件事：

初始化 CPU 核心函数表；
初始化 CPU 后端自己的 OpType -> Creator 表；
把 CPURuntimeCreator 注册到全局 Runtime 工厂中。

2.3 实例化过程

Express 侧请求 Runtime 时，会进入 express/Executor.cpp 的 Executor::_getOrCreateRuntime：

auto cre = MNNGetExtraRuntimeCreator(type);
if (nullptr == cre) {
    return nullptr;
}
Backend::Info info;
// 组装 Runtime 创建参数
info.type = type;
info.mode = Backend::Info::DIRECT;
info.numThread = numberThread;
info.user = (BackendConfig*)config;
std::shared_ptr<Runtime> rt(cre->onCreate(info));

这里的调用信息只有 type 和 Backend::Info：

type 用来确定后端类型；
Backend::Info 携带线程数、模式和用户配置；
真正的 Runtime 实例由 Creator 返回。

因此这一层解决的是后端接入问题。调度层不直接依赖具体后端类，只依赖统一的创建接口。

RuntimeCreator::onCreate() 返回的是 Runtime，例如 source/backend/cpu/CPUBackend.cpp 里的 CPURuntimeCreator::onCreate() 会创建 CPURuntime。真正的 Backend 实例化在对应 Runtime 的 onCreate() 里完成，再由后续执行流程使用。

CPU 的实现路径可以直接对上：

CPURuntimeCreator::onCreate() 创建 CPURuntime
CPURuntime::onCreate() 创建 CPUBackend 或其变体
CPUBackend 再进入执行层的 Creator 分发

3. Execution层工厂

这一层对应的核心类是 Execution 和各后端自己的 Creator。Execution 表示一个算子在特定后端上的具体执行实现，Creator 负责根据 OpType 返回对应的 Execution 创建逻辑。

Runtime 层确定后端以后，下一步是确定当前 Op 由哪个 Execution 实现执行。这一层对应的是后端内部的算子工厂。

3.1 全局注册表

以 CPU 后端为例，source/backend/cpu/CPUBackend.hpp 中定义了 Creator 抽象接口：

class Creator {
public:
    // 由具体后端 Creator 返回对应的 Execution 实现
    virtual Execution* onCreate(const std::vector<Tensor*>& inputs,
                                const std::vector<Tensor*>& outputs,
                                const MNN::Op* op,
                                Backend* backend) const = 0;
};

static bool addCreator(OpType t, Creator* c);
static std::map<OpType, CPUBackend::Creator*>* gCreator;

这一层的 key 已经不是后端类型，而是 OpType：

Runtime 工厂确定后端；
后端工厂确定该后端下某个算子的执行实现。

3.2 注册过程

CPU 后端通过注册宏把 Creator 写入 gCreator：

#define REGISTER_CPU_OP_CREATOR(name, opType)     \
    void ___##name##__##opType##__() {            \
        static name _temp;                        \
        /* 把当前 opType 对应的 Creator 写入全局表 */ \
        CPUBackend::addCreator(opType, &_temp);   \
    }

典型注册形式如下：

1
2
3

REGISTER_CPU_OP_CREATOR(CPUSoftmaxCreator, OpType_Softmax);
REGISTER_CPU_OP_CREATOR(CPUMatMulCreator, OpType_MatMul);
REGISTER_CPU_OP_CREATOR_TRANSFORMER(CPUAttentionCreator, OpType_Attention);

宏展开以后，实际还是调用 CPUBackend::addCreator 把 Creator 插入 gCreator：

bool CPUBackend::addCreator(OpType t, Creator* c) {
    auto map = gCreator;
    // 每个 OpType 只允许注册一个 Creator
    if (map->find(t) != map->end()) {
        MNN_PRINT("Error: %d type has be added\n", t);
        return false;
    }
    map->insert(std::make_pair(t, c));
    return true;
}

这一层和 Runtime 工厂的结构一致，只是映射关系从 后端类型 -> Creator 变成了 OpType -> Creator。

同样的组织方式也出现在 OpenGL、Metal、QNN 等后端。例如 QNN 后端直接使用：

#define REGISTER_QNN_OP_CREATOR(name, opType)       \
    void ___##name##__##opType##__() {              \
        QnnBackend::addCreator(opType, new name);   \
    }

这说明这一层不是 CPU 特例，而是 MNN 后端扩展的通用组织方式。

3.3 实例化过程

当调度层已经把当前 Op 分配给 CPUBackend，最终会进入 source/backend/cpu/CPUBackend.cpp 的 CPUBackend::onCreate：

Execution* CPUBackend::onCreate(const std::vector<Tensor*>& inputs,
                                const std::vector<Tensor*>& outputs,
                                const MNN::Op* op) {
    auto opType = op->type();
    auto map  = gCreator;
    // 按 OpType 查找对应 Creator
    auto iter = map->find(opType);
    if (iter == map->end() ) {
        MNN_PRINT("Don't support type [%s]\n", MNN::EnumNameOpType(op->type()));
        return nullptr;
    }
    // 委托 Creator 构造具体 Execution
    Execution* exe = iter->second->onCreate(inputs, outputs, op, this);
    return exe;
}

这里的执行过程可以直接拆成三步：

根据 op->type() 取得 OpType；
去 gCreator 查表；
让对应的 Creator 创建真正的 Execution。

对应的调用链如下：

调度器决定使用 CPUBackend
    ↓
CPUBackend::onCreate(op)
    ↓
gCreator[OpType]
    ↓
具体 Creator::onCreate(...) 的算子实例化
    ↓
返回具体 Execution

CPUBackend 在这里承担的是分发角色。它不直接依赖 CPUSoftmax、CPUConvolution、CPUAttention 这类具体实现，只负责查表并调用对应 Creator。

4. Shape 工厂

这一层对应的核心类是 SizeComputer 和 SizeComputerSuite。SizeComputer 负责单个算子的输出 shape、格式和部分属性推导，SizeComputerSuite 维护 OpType 到 SizeComputer 的映射关系，并在推导阶段按算子类型返回对应实例。

Shape 工厂和前面的 Runtime、执行层工厂是并行关系。它不参与算子执行实现选择，而是负责在执行前完成输出信息推导。

4.1 全局注册表

SizeComputerSuite 的接口定义位于 source/shape/SizeComputer.hpp，实际注册表管理位于 source/shape/SizeComputer.cpp。这一层同样维护一张按 OpType 索引的全局表：

void SizeComputerSuite::init() {
    // 已初始化则直接返回
    if (nullptr != gInstance) {
        return;
    }
    // 创建全局单例
    gInstance = new SizeComputerSuite;
    // 按 OpType 范围分配注册表空间
    gInstance->mRegistry.resize(OpType_MAX + 1);
    // 初始状态全部置空
    ::memset(gInstance->mRegistry.data(), 0, gInstance->mRegistry.size() * sizeof(SizeComputer*));
    // 统一注册各个算子的 SizeComputer
    registerShapeOps();
}

void SizeComputerSuite::insert(SizeComputer* t, OpType type) {
    // 把当前 OpType 对应的 SizeComputer 写入表中
    mRegistry[type] = t;
}

SizeComputer* SizeComputerSuite::search(OpType name) {
    // 按 OpType 直接查表
    auto iter = mRegistry[name];
    if (iter == nullptr) {
        return nullptr;
    }
    return iter;
}

这套结构和前两节是一致的：

init() 负责初始化注册表并触发统一注册；
insert() 负责把具体 SizeComputer 写入指定 OpType；
search() 负责在推导阶段按 OpType 查表。

4.2 注册过程

注册入口在 source/shape/SizeComputer.hpp：

#define REGISTER_SHAPE(name, op)                          \
    void ___##name##__##op##__() {                        \
        name* _temp = new name;                           \
        /* 把当前 OpType 对应的 SizeComputer 写入注册表 */ \
        SizeComputerSuite* ts = SizeComputerSuite::get(); \
        ts->insert(_temp, op);                            \
    }

典型注册形式如下：

1
2
3

REGISTER_SHAPE(ConvolutionSizeComputer, OpType_Convolution);
REGISTER_SHAPE(MatMulSizeComputer, OpType_MatMul);
REGISTER_SHAPE(ArgMaxComputer, OpType_ArgMax);

宏展开以后，本质上仍然是创建具体 SizeComputer 对象，并调用 SizeComputerSuite::insert() 写入全局表。这一步和前面两层的区别只在于注册对象类型不同，注册流程本身没有变化。

4.3 实例化过程

在 Express 侧，Expr::requireInfo()、Executor::computeInfo() 等流程最终都会进入 SizeComputer::computeOutputSize() 或 SizeComputer::computeFlops()。这两个静态函数内部都会先查表，再调用对应 SizeComputer：

float SizeComputer::computeFlops(const MNN::Op* op,
                                 const std::vector<Tensor*>& inputs,
                                 const std::vector<Tensor*>& outputs) {
    auto computeFactory = SizeComputerSuite::get();
    auto computer       = computeFactory->search(op->type());
    if (nullptr != computer) {
        return computer->onComputeFlops(op, inputs, outputs);
    }
    ...
}

computeOutputSize() 的调用方式也是同一条路径：先按 OpType 取出对应 SizeComputer，再进入该算子的 onComputeSize()。

这一层的调用链可以整理成：

Expr::requireInfo() / Executor::computeInfo()
    ↓
SizeComputer::computeOutputSize(...) / computeFlops(...)
    ↓
SizeComputerSuite::search(OpType)
    ↓
具体 SizeComputer::onComputeSize(...) / onComputeFlops(...)

对应关系可以直接理解为：

后端工厂负责执行实现选择；
Shape 工厂负责输出信息推导。

5. 其它工程化做法：局部策略选择器

前面几节对应的是典型的注册表式工厂。除此之外，MNN 里还有一类更局部的选择逻辑，形式上更接近模块内部的策略分发器。例如：CPU 卷积算子链路：

OpType_Convolution 首先仍然走标准的 CPUBackend::Creator 注册链路：

class ConvolutionFactory : public CPUBackend::Creator {
public:
    virtual Execution* onCreate(const std::vector<Tensor*>& inputs,
                                const std::vector<Tensor*>& outputs,
                                const MNN::Op* op,
                                Backend* backend) const override {
        return ConvolutionFloatFactory::create(inputs, outputs, op, backend);
    }
};

REGISTER_CPU_OP_CREATOR(ConvolutionFactory, OpType_Convolution);

第一层入口并没有变化，仍然是 OpType -> Creator。

但卷积不在这一步直接落到单一实现。ConvolutionFactory 继续把选择逻辑转交给 ConvolutionFloatFactory::create()：

Execution* ConvolutionFloatFactory::create(const std::vector<Tensor*>& inputs,
                                           const std::vector<Tensor*>& outputs,
                                           const MNN::Op* op,
                                           Backend* backend)

这个函数内部会继续根据卷积参数和运行时条件做二次分发，例如：

是否是多输入卷积
是否带量化参数
当前 Backend 是否处于 low memory 模式
是否可以走稀疏卷积
是否可以走 Winograd
是否适合走 1x1 Strassen
是否能走 KleidiAI / OneDNN 等特定实现

例如卷积带量化参数时，会继续进入 ConvolutionIntFactory：

if (conv2d->quanParameter()->has_scaleInt()) {
    if (bytes < 4) {
        return nullptr;
    }
    return ConvolutionIntFactory::create(inputs[0], outputs[0], op, backend, quanCommon.get());
}

ConvolutionIntFactory 内部还会继续区分是否为 group convolution：

if (1 == group) {
    return createUnit(input, output, op, backend, common,
                      conv2d->bias()->data(), conv2d->bias()->size());
}

return new ConvolutionGroup(backend, subConvolution);

这一条路径可以简化成：

OpType_Convolution
    ↓
ConvolutionFactory
    ↓
ConvolutionFloatFactory::create(...)
    ↓
按卷积参数 / 精度 / 内存模式 / 指令集继续分支
    ↓
ConvolutionIntFactory / DenseConvolution / Winograd / Strassen / Group ...

6. 小结

工厂化结构把框架调度逻辑和具体实现逻辑分离，后端与算子的扩展点都落在 Creator 或对应注册入口上，关系如下：

执行时实例化流程是：
MNNForwardType
    ↓
RuntimeCreator 工厂
    ↓
Runtime / Backend
    ↓
OpType
    ↓
Backend::Creator 工厂
    ↓
Execution

同时 执行时的形状计算：

OpType
    ↓
SizeComputer 工厂
    ↓
输出 shape / 格式推导

MNN 核心类介绍

Thu, 26 Feb 2026 23:00:00 +0800

MNN 核心类介绍

MNN 框架作为一个高性能的深度学习推理引擎，核心设计围绕着几个关键的抽象类展开。其中，VARP、Expr、Op 等类是整个框架的基石，它们不仅定义了数据的表示方式，还构建了计算图的基本结构。本文按当前仓库代码，直接看这些核心类的职责、文件位置和相互关系。

MNN 核心类介绍
- 1. MNN核心类

1. MNN核心类

MNN 中的核心类主要包括：

类名	职责	文件位置
`VARP`	智能指针包装的 `Variable`，表示表达式中的变量节点	`include/MNN/expr/Expr.hpp`
`Variable`	表达式图中的变量节点，持有张量数据或计算信息	`include/MNN/expr/Expr.hpp`
`Expr`	表达式边，表示一个计算操作以及输入节点和输出节点	`include/MNN/expr/Expr.hpp`、`express/Expr.cpp`
`Tensor`	张量数据容器，存储实际的多维数据	`include/MNN/Tensor.hpp`
`Op`	算子描述符，定义计算的类型和参数、模型权重等	`schema/current/MNN_generated.h`
`Runtime`	运行时抽象层，负责创建具体 `Backend` 并管理线程、内存与运行时资源	`source/core/Backend.hpp`
`Backend`	执行层后端抽象基类，负责创建 `Execution` 并管理张量内存与设备资源	`source/core/Backend.hpp`
`Execution`	单个算子的执行抽象基类，负责 `resize` 和 `execute` 两阶段计算	`source/core/Execution.hpp`
`Pipeline`	一条执行流水线，负责 `encode`、`allocMemory` 和 `execute`	`source/core/Pipeline.hpp`
`Session`	一次推理会话，持有 `Runtime`、`Pipeline` 和输入输出 `Tensor`	`source/core/Session.hpp`、`source/core/Session.cpp`
`Interpreter`	模型数据持有者，也是创建 `Session` 的入口	`include/MNN/Interpreter.hpp`
`Executor`	`Express` 层的执行协调器，负责 shape 推导、缓存和临时 `Session`	`include/MNN/expr/Executor.hpp`、`express/Executor.cpp`
`ExecutorScope`	`Executor` 的线程局部作用域，用来切换当前执行上下文	`include/MNN/expr/ExecutorScope.hpp`、`express/ExecutorScope.cpp`

其中 Runtime、Backend、Execution 这三个类属于执行层的核心抽象。这里只先给出职责总览，具体的分层关系、调用顺序和关键接口可结合后端介绍的第 2 节一起看。

1.1 类之间关系

1.1.1 逻辑依赖关系

VARP 和 Expr 是 MNN 计算图格式的核心，分别表示计算图的节点和边，Op 类负责描述 Expr 对应的计算操作。关系图如下：

VARP (Variable Ptr)
    ↓ 指向
Variable
    ↓ 包含
   Expr ───────────────→ Op (操作描述)
    ↓包含输出张量
Tensor (存储数据)

其中：

每个 Expr 边都有 std::vector<VARP> mInputs; 记录输入节点，const Op* mOp; 代表当前边的计算操作；
同时 Expr 还持有一个 std::shared_ptr<Inside> mInside;，其中保存了当前边的输出 Tensor、shape 信息等；
每个 VARP 节点内部持有一个 std::shared_ptr<Variable>；
Variable 继续朝输入方向指向 std::shared_ptr<Expr> mFrom 输入边，从而一步一步构成计算图；
叶节点就是用 VARP 指向输入边 Expr，这个输入边没有 mOp 和 mInputs，只持有一个 Tensor 数据。

一个简单的计算图VARP z = _Add(x, y)可以表示如下：

Expr (mFrom) -> Tensor x(data)      Expr (mFrom) -> Tensor y(data)
            │                                     │
            │                                     │
            VARP x                               VARP y
            ↓                                     ↓
            └──────────────┬──────────────────────┘
                           │
                           ▼
         Tensor z ←────── Expr ───────→ Op(Add)
                           │
                           ↓
                       VARP z

1.1.2 执行依赖关系

MNN 的计算图有两种模式，Defer（延迟计算）模式或 Eager（立即计算）模式：Defer 模式下，调用表达式相关 API 不会直接计算，而是先搭建模型，在需要获取输出值时才执行（如 Variable::readMap() 或 Variable::writeMap() 接口）；Eager 模式下会直接进行计算，对应地无法搭建模型。下面以 Eager 模式为例，梳理 MNN 中表达式计算顺序，更具体的代码分析见readmap详解:

用户定义 `VARP` 计算代码 // 如：`VARP x = _Input({2,  3}); VARP y = _Input({2,  3}); VARP z = _Add(x,  y);`
    ↓
`varp->readMap()`  // 触发延迟计算接口
    ↓
//计算节点信息
`ExecutorScope::Current()->computeInfo()`   ─→ `SizeComputer::computeOutputSize()` // 动态计算中间节点/输出的形状
    ↓
`ExecutorScope::Current()->makeCache()` // 计算缓存，可复用，按数据依赖顺序准备中间节点的 `Tensor` 以及 `Session` 会话的计算信息
    ↓
`Executor::ComputeCache::compute()` // 按数据依赖顺序执行计算缓存中的 `resize` 和执行，算子执行会从计算缓存的 `mSession` 进入下一步
    ↓
`Session::run()` // 这里继续进入 `Session::mPipelines` 的执行
    ↓
`Pipeline::execute()` // 这里执行 `execution->onExecute` 进入算子的后端执行
    ↓
`Execution::onExecute()`	// 按计算图依次执行各算子的后端计算，计算结果存在 `Tensor` 中，最后从 `readMap` 读取为指针
    ↓
获得数据指针

这当中主要配置的信息是在 ExecutorScope::Current()->makeCache() 中写入的 Session，后续执行都依赖这份缓存。

1.2 VARP类

VARP 本质是 Variable 的智能指针包装类。当前实现位于 include/MNN/expr/Expr.hpp，比较运算符直接比较内部指针。

// include/MNN/expr/Expr.hpp
class MNN_PUBLIC VARP {
public:
    // 绑定 / 解绑底层 Variable
    VARP();
    VARP(std::shared_ptr<Variable> c);
    VARP(Variable* c);

    // 直接取内部的 Variable 指针
    Variable* get() const;

    enum InputType {
        INPUT = 0,
        CONSTANT = 1,
        TRAINABLE = 2,
    };

    // 标记当前 VARP 的输入类型和维度格式
    bool fix(InputType type) const;
    void setOrder(Dimensionformat format);
    
private:
    std::shared_ptr<Variable> mContent;
};

1.2.1 Variable 类

Variable 描述算子图里的一个变量节点，既提供图结构接口，也提供数据访问接口，部分核心代码如下：

// include/MNN/expr/Expr.hpp
class MNN_PUBLIC Variable {
public:
    // 节点命名，便于调试和导出
    const std::string& name() const;
    void setName(const std::string& name);

    struct Info {
        Dimensionformat order = NHWC;
        INTS dim;
        halide_type_t type;
        size_t size;
        void syncSize();
    };

    // 读取当前节点的 shape / dtype / format 信息
    const Info* getInfo();
    // 建立 Variable 到 Expr 的反向引用
    void setExpr(EXPRP expr,  int index);
    std::pair<EXPRP,  int> expr() const;
    // 返回当前节点关联的 Tensor
    const Tensor* getTensor() const;
    // 仅调整逻辑 shape，不直接触发算子执行
    bool resize(INTS dims);

    // 序列化 / 反序列化相关入口
    static std::vector<VARP> load(const char* fileName);
    static void save(const std::vector<VARP>& vars,  NetT* dest);

    // 直接把底层 Tensor 映射成可读 / 可写指针
    template <typename T>
    const T* readMap();
    template <typename T>
    T* writeMap();
private:
    // 核心类属性 表示入边
    EXPRP mFrom;
    int mFromIndex;
};

1.2.2 readMap详解

Variable::readMap<T>() 只是模板包装，真正逻辑在 express/Expr.cpp 的 Variable::readInternal()。这条调用链基本就是 Express 图执行的主入口之一，顺着它往下看，能把 shape 推导、缓存构建、Session 执行和结果回传这几步串联，最后会返回数据指针用于数据读取。

// express/Expr.cpp
void* Variable::readInternal(bool forShape) {
    if (nullptr == mFrom->get()) {
        // 输入 / 常量 / 可训练参数，直接走已有 Tensor
        return mFrom->inside()->mOutputTensors[0]->buffer().host;
    }
    // 普通 Expr，先补齐 shape 信息
    if (!mFrom->requireInfo()) {
        return nullptr;
    }
    // 没有 cache 时，先把当前子图收敛成一个临时 Session
    auto cache = mFrom->inside()->mCache;
    if (nullptr == cache) {
        ExecutorScope::Current()->makeCache({mFrom}, forShape);
        cache = mFrom->inside()->mCache;
    }
    if (nullptr == cache || NO_ERROR != cache->compute()) {
        return nullptr;
    }
    return cache->mapOutput(mFrom->mInside->mCacheOffset + mFromIndex,
                            mFrom->mInside->mOutputTensors[mFromIndex]);
}

这里的 mFrom->get() 实际对应当前 Expr 持有的 Op。如果它是空，说明当前 Variable 对应的不是普通计算算子，而是输入、常量或者可训练参数这类叶子节点。这种情况下不需要再走调度和执行流程，直接返回已有 Tensor 的 host 指针。(实际代码还有额外处理：如果底层数据在其它设备后端上，或带量化属性，会先构造一个 host Tensor把数据同步回 CPU)

1.2.2.1 shape 推导

接下来普通算子节点会先进入：Expr::requireInfo()，确保当前节点以及依赖输入的 shape / dtype / format 都已经准备好。对应代码在 express/Expr.cpp：

bool Expr::requireInfo() {
    if (!mInside->mInfoDirty) {
        return true;
    }
    if (nullptr == mOp) {
        return !HasUnknownDim(mInside->mOutputInfos[0].dim);
    }
    // 递归补齐所有的输入链节点信息
    for (int i = 0; i < mInputs.size(); ++i) {
        auto inputInfo = mInputs[i]->getInfo();
        if (nullptr == inputInfo) {
            mValid = false;
            return false;
        }
    }
    for (int i = 0; i < mInputs.size(); ++i) {
        if (mInside->mReq.shapeNeedContent[i]) {
            auto ptr = mInputs[i]->readInternal(true);
            if (nullptr == ptr) {
                return false;
            }
        }
    }
    auto res = ExecutorScope::Current()->computeInfo(this);
    if (NO_ERROR == res) {
        mInside->mInfoDirty = false;
    }
    return NO_ERROR == res;
}

这里有两个重点：

requireInfo() 会递归调用输入节点的 getInfo()，因此会沿着当前 Expr 一直向前，把依赖链上的 shape 信息逐层补齐；
如果某些算子的 shape 推导依赖输入内容而不只是维度，比如部分 shape 相关算子，那么它会通过 readInternal(true) 先把输入内容读出来。

接下来真正做执行shape 推导的是 Executor::computeInfo()：

// express/Executor.cpp
ErrorCode Executor::computeInfo(Expr* expr) {
    auto op = expr->get();
    std::vector<Tensor*> inputTensors(expr->inputs().size());
    for (int i = 0; i < inputTensors.size(); ++i) {
        auto inputExpr = expr->inputs()[i]->expr();
        inputTensors[i] = inputExpr.first->inside()->mOutputTensors[inputExpr.second];
    }
    bool res = SizeComputer::computeOutputSize(op, inputTensors, expr->inside()->mOutputTensors);
    if (!res) {
        return COMPUTE_SIZE_ERROR;
    }
    for (int i = 0; i < expr->outputSize(); ++i) {
        auto tensor = expr->inside()->mOutputTensors[i];
        TensorUtils::setLinearLayout(tensor);
        auto shape = expr->outputInfo(i);
        Utils::copyTensorToInfo(shape, tensor);
    }
    return NO_ERROR;
}

这一层最终会进入 SizeComputer::computeOutputSize()，也就是前面讲过的 shape 工厂系统，各个算子会根据输入信息推导输出维度。执行完成后，当前 Expr 的输出 Tensor 和 Variable::Info 会同步更新，后面才能继续构建执行缓存。

1.2.2.2 把子图收敛成 `ComputeCache`

shape 信息准备好之后，Variable::readInternal() 函数会继续检查当前节点有没有现成的执行缓存：

// express/Expr.cpp
auto cache = mFrom->inside()->mCache;
if (nullptr == cache) {
    ExecutorScope::Current()->makeCache({mFrom}, forShape);
    cache = mFrom->inside()->mCache;
}

然后调用 makeCache() 把未缓存算子的整段子图收敛成一个临时 Session类，对应 express/Executor.cpp 里的 Executor::_makeCache()函数。这个过程主要做四件事：

从目标 Expr 开始反向 DFS，找到所有真正参与本次输出计算的依赖节点；
按依赖顺序把每个 Expr 改写成 Schedule::OpCacheInfo，整理出输入输出 Tensor；
生成 Schedule::ScheduleInfo，并给目标输出记录 mCacheOffset；
用这份 ScheduleInfo 构造一个临时 Session，保存到 ComputeCache::mSession。

核心代码如下：

// express/Executor.cpp
void Executor::_makeCache(const std::vector<EXPRP>& expr, bool forceCPU) {
    Schedule::ScheduleInfo scheduleInfo;
    scheduleInfo.pipelineInfo.resize(1);
    auto& pipeline = scheduleInfo.pipelineInfo[0].second;
    // 反向遍历 Expr 子图，构造 pipeline 里的 OpCacheInfo
    while (!dfsStack.empty()) {
        // ...
        Schedule::OpCacheInfo opInfo;
        opInfo.op = expr->get();
        opInfo.inputs.resize(inputs.size());
        opInfo.outputs.resize(expr->outputSize());
        // ...
        pipeline.emplace_back(std::move(opInfo));
    }
    std::shared_ptr<ComputeCache> cahce(new ComputeCache);
    for (auto& iter : dstExpr) {
        iter.first->inside()->mCacheOffset = iter.second;
        iter.first->inside()->mCache = cahce;
    }
    cahce->mSession.reset(new Session(std::move(scheduleInfo), group, std::move(rt)));
}

最后这里的 ComputeCache 是“某一段 Expr 子图对应的可执行快照”，里面最重要的成员就是 mSession，后面将用于计算。

1.2.2.3 `compute()`时触发 `resize` 和 `run`

缓存建好以后，Variable::readInternal() 会调用cache->compute()在 express/Utils.cpp 里，核心逻辑如下：

ErrorCode Executor::ComputeCache::compute() {
    while (!dfsStack.empty()) {
        auto cache = dfsStack.top();
        if (cache->mShapeDirty) {
            auto code = cache->resize();
            if (NO_ERROR != code) {
                return code;
            }
        }
        if (!cache->mContentDirty) {
            // 已有可复用结果，跳过执行
            continue;
        }
        // 输入依赖都满足后，真正执行 Session
        code = cache->mSession->run();
        if (NO_ERROR != code) {
            return code;
        }
        cache->mContentDirty = false;
    }
    return NO_ERROR;
}

这里可以看到两层状态：

mShapeDirty 控制是否需要重新 resize；
mContentDirty 控制是否需要真正重新执行算子。

其中 resize() 最终会走到：

ErrorCode Executor::ComputeCache::resizeImpl() {
    mShapeDirty = false;
    mSession->setNeedResize();
    mSession->resize();
    mContentDirty = true;
    return NO_ERROR;
}

也就是先把临时 Session 标记为需要重新调整，再执行 Session::resize()。这一层会继续进入 Pipeline，为每个算子创建 Execution、分配内存并调用 Execution::onResize()。

而真正执行计算时，ComputeCache::compute() 会调用 Session::run()：

// source/core/Session.cpp
ErrorCode Session::run() const {
    for (auto& iter : mPipelines) {
        auto error = iter->execute();
        if (NO_ERROR != error) {
            return error;
        }
    }
    return NO_ERROR;
}

继续往下就是 Pipeline::execute()，再到每个算子的 Execution::onExecute()。也就是说，readMap() 表面上是“读一个变量”，底下实际上已经把整段子图执行完了。

1.2.2.4 映射结果

执行完成后，Variable::readInternal() 最后一步是cache->mapOutput(),通过mCacheOffset + mFromIndex 用来定位当前输出在临时 Session 里的目标 Tensor(前面1.2.2.2时记录的位置)。mapOutput() 对应代码如下：

// express/Utils.cpp
void* Executor::ComputeCache::mapOutput(int offset, Tensor* dest) {
    auto tensor = mSession->getTensor(offset);
    if (0 == tensor->deviceId() && TensorUtils::getDescribe(tensor)->quantAttr.get() == nullptr) {
        auto ptr = tensor->host<void>();
        dest->buffer().host = (uint8_t*)ptr;
        return ptr;
    }
    Utils::allocMemoryForHostTensor(dest);
    tensor->copyToHostTensor(dest);
    return dest->host<void>();
}

这里分成两种情况：

如果结果本身就在 host 内存上，直接返回底层指针；
如果结果在其它后端设备上，例如 GPU，或者需要量化相关处理，就先复制回 host Tensor，再返回 host 指针。

1.2.2.5 整体流程

把上面的步骤合起来，readMap() 的完整调用路径可以按函数栈层次看。主路径从 Variable::readInternal() 开始，里面分出四段：先补 shape，再构建 ComputeCache，然后通过临时 Session 执行，最后把输出 Tensor 映射成 host 指针。

Variable::readMap<T>()
# 模板接口，只负责把 readInternal() 返回的 void* 转成 T*
└── Variable::readInternal(forShape = false)
    # readMap 的真正入口；forShape=false 表示这次是为了读取最终数据
    ├── [叶子节点] mFrom->get() == nullptr
    │   # 没有关联 Op，说明是 Input / Const / Trainable 这类已持有 Tensor 的节点
    │   └── 直接返回 mOutputTensors[0]->buffer().host
    │
    ├── Expr::requireInfo()
    │   # 普通算子节点先保证输出 shape / dtype / format 已经推导完成
    │   ├── 递归补齐输入 shape
    │   │   # 当前 Expr 的 shape 依赖所有输入 Variable 的 Info
    │   │   └── input VARP -> Variable::getInfo()
    │   │       └── input Expr -> Expr::requireInfo()
    │   ├── [shape 依赖输入内容]
    │   │   # 部分 shape 算子不只依赖维度，还要先读输入 Tensor 的真实内容
    │   │   └── input VARP -> Variable::readInternal(forShape = true)
    │   └── ExecutorScope::Current()->computeInfo(this)
    │       └── Executor::computeInfo(expr)
    │           └── SizeComputer::computeOutputSize(op, inputs, outputs)
    │               # 进入算子 shape 推导注册表，写回 Expr 输出 Tensor 的形状信息
    │
    ├── [当前 Expr 没有 cache] ExecutorScope::Current()->makeCache({mFrom}, forShape)
    │   # 第一次真正求值时才会把 Expr 子图收敛成可执行缓存
    │   └── Executor::makeCache(outputs, forceCPU)
    │       └── Executor::_makeCache(outputs, forceCPU)
    │           ├── 从目标 Expr 反向 DFS 收集依赖
    │           │   # 只收集本次输出真正依赖的 Expr，已有 cache 的输入会作为边界
    │           ├── 按依赖顺序生成 Schedule::OpCacheInfo
    │           │   # 每个 OpCacheInfo 记录一个 Op、它的输入 Tensor 和输出 Tensor
    │           ├── 填充 Schedule::ScheduleInfo::pipelineInfo
    │           │   # pipelineInfo 后续会被 Session / Pipeline 用来创建 command
    │           ├── 记录目标 Expr 的 mCacheOffset / mCache
    │           │   # mCacheOffset 用于 mapOutput() 时找到目标输出 Tensor
    │           └── new Session(scheduleInfo, group, runtime)
    │               └── 保存到 ComputeCache::mSession
    │                   # ComputeCache 持有临时 Session，后续 resize/run 都靠它
    │
    ├── Executor::ComputeCache::compute()
    │   # cache 已经存在后，从这里开始决定是否 resize、是否重新执行
    │   ├── DFS 检查依赖的 input cache
    │   │   # 保证上游 cache 已经完成，输入内容没有脏状态
    │   ├── [mShapeDirty] ComputeCache::resize()
    │   │   # shape 脏时先重新 resize；resize 后内容也会变脏
    │   │   └── ComputeCache::resizeImpl()
    │   │       ├── Session::setNeedResize()
    │   │       └── Session::resize()
    │   │           ├── Pipeline::encode()
    │   │           │   # 根据 ScheduleInfo 生成 command，并创建算子 Execution
    │   │           │   └── Backend 创建每个 Op 对应的 Execution
    │   │           └── Pipeline::allocMemory()
    │   │               # 为 command 里的 Tensor 分配或复用后端内存
    │   │               └── 为输入、中间结果和输出 Tensor 分配后端内存
    │   └── [mContentDirty] Session::run() / Session::runWithCallBack()
    │       # 内容脏时才真正执行；有 debug callback 时走 runWithCallBack()
    │       └── Pipeline::execute()
    │           # 按 command buffer 顺序执行每个算子
    │           └── cmd.execution->onExecute(...)
    │               └── 具体 Backend Execution 执行算子
    │
    └── Executor::ComputeCache::mapOutput(mCacheOffset + mFromIndex, outputTensor)
        # 从临时 Session 的输出 Tensor 映射回当前 Variable 持有的 Tensor
        ├── host Tensor 且无 quantAttr
        │   # 已经在 CPU host 内存上，可以零拷贝返回指针
        │   └── 直接返回 tensor->host<void>()
        └── 设备 Tensor / 量化 Tensor
            # GPU / NPU 等设备内存或量化 Tensor，需要先复制到 host
            ├── Utils::allocMemoryForHostTensor(dest)
            ├── tensor->copyToHostTensor(dest)
            └── 返回 dest->host<void>()

1.3 Expr类

Expr 表示计算图中的一条边，核心属性就是输入 VARP、输出 Tensor 和计算算子 Op。当前公开声明在 include/MNN/expr/Expr.hpp。

// include/MNN/expr/Expr.hpp
class MNN_PUBLIC Expr {
public:
    struct Inside;
    enum MemoryType {
        COPY,
        MOVE,
        REF
    };
    // 用不同来源构造 Expr
    static EXPRP create(Tensor* tensor,  bool own = false);
    static EXPRP create(Variable::Info&& info,  const void* ptr,  VARP::InputType type,  MemoryType copy = COPY);
    static EXPRP create(const OpT* op,  std::vector<VARP> inputs,  int outputSize = 1);
    static EXPRP create(std::shared_ptr<BufferStorage> extra,  std::vector<VARP>&& inputs,  int outputSize = 1);
    static EXPRP create(std::unique_ptr<OpT>&& op,  std::vector<VARP> inputs,  int outputSize = 1);

    // 当前边关联的算子和输入
    const Op* get() const;
    const std::vector<VARP>& inputs() const;
    int outputSize() const;
    // 当前边的名字和输出名
    void setName(const std::string& name);
    const std::string& name() const;
    const std::string& outputName(int index);
    // 替换旧边，供图改写使用
    static void replace(EXPRP oldExpr,  EXPRP newExpr);
    VARP::InputType inputType() const;
    // 递归补齐 shape 信息
    bool requireInfo();
    // 遍历输出引用
    void visitOutputs(const std::function<bool(EXPRP,  int)>& visit);
    static void visit(EXPRP expr,  const std::function<bool(EXPRP)>& before,  const std::function<bool(EXPRP)>& after);

private:
    const Op* mOp; // 核心属性 表示边的操作 如果为空表示当前边的输出VARP节点是常量节点
    std::vector<VARP> mInputs; // 核心属性 表示边的输入节点
    VARP::InputType mType;
    std::string mName;
    std::vector<std::string> mOutputNames;
    std::shared_ptr<Inside> mInside = nullptr; // 包括当前边的输出信息
};

其中边有关输出信息都存在 Inside 类中，其内部状态定义在 express/Utils.hpp:

// express/Utils.hpp
struct Expr::Inside {
    // 按输出个数初始化内部状态
    Inside(int outputSize);
    // 直接用已有 Tensor 构造 Expr 的内部表示
    Inside(Tensor* tensor, bool own = false);
    // 释放输出 Tensor / Host Tensor 等内部资源
    ~ Inside();
    std::vector<Variable::Info> mOutputInfos;  // 每个输出对应的 shape / dtype / format 描述
    std::vector<Tensor*> mOutputTensors;       // 每个输出真正绑定的 Tensor 指针
    Executor::Requirement mReq;                // 当前 Expr 对输入内容和 shape 的依赖要求
    std::shared_ptr<Executor::ComputeCache> mCache; // 当前 Expr 关联的执行缓存，里面会持有临时 Session
    int mCacheOffset = 0;                      // 当前 Expr 的第一个输出在 cache Tensor 列表中的偏移
    bool mInfoDirty = true;                    // 输出信息是否失效，失效时需要重新做 shape 推导
    bool mContentDirty = true;                 // 输出内容是否失效，失效时需要重新执行算子
    bool mOwnTensor = true;                    // 当前 Inside 是否负责释放 mOutputTensors
    Tensor* mHostTensor = nullptr;             // 设备 Tensor 读回 Host 时使用的临时拷贝 Tensor
    std::shared_ptr<Backend> mHoldBackend;     // 持有输出数据的后端，避免底层资源被提前释放
};

1.3.1 requireInfo 详解

Expr::requireInfo() 的职责是把当前 Expr 和所有输入 Expr 的 shape、dtype、format 信息补齐，必要时会读取部分输入内容。

// express/Expr.cpp
bool Expr::requireInfo() {
    // 已经计算过就直接返回
    if (!mInside->mInfoDirty) {
        return true;
    }
    // 节点本身已经失效，直接失败
    if (!mValid) {
        return false;
    }
    // 没有算子时，只检查输出维度是否还包含未知值
    if (nullptr == mOp) {
        return !HasUnknownDim(mInside->mOutputInfos[0].dim);
    }
    // 先把所有输入节点的信息补齐
    for (int i = 0; i < mInputs.size(); ++i) {
        auto inputInfo = mInputs[i]->getInfo();
        if (nullptr == inputInfo) {
            mValid = false;
            return false;
        }
    }
    // 某些算子的 shape 推导需要真实输入内容
    for (int i = 0; i < mInputs.size(); ++i) {
        if (mInside->mReq.shapeNeedContent[i]) {
            // 某些算子的 shape 推导依赖输入内容
            if (nullptr == mInputs[i]->readInternal(true)) {
                return false;
            }
        }
    }
    // 交给 Executor 做真正的 shape / info 推导
    auto res = ExecutorScope::Current()->computeInfo(this);
    if (NO_ERROR == res) {
        mInside->mInfoDirty = false;
    } else {
        mValid = false;
    }
    return NO_ERROR == res;
}

这里有两个点需要特别注意：

mInside->mReq.shapeNeedContent 不是固定为真，它来自 Executor::getRequirement()，只有少数算子会在 shape 阶段要求真实输入内容；
真正做 shape 推导的是 Executor::computeInfo()，里面会继续调用 SizeComputer::computeOutputSize()。

1.4 Tensor类

张量数据类，包括数据指针，数据格式，数据维度等信息，所有属性存储在下面两个结构体对象中，

// include/MNN/Tensor.hpp
class MNN_PUBLIC Tensor{
// 其它代码
private:
    halide_buffer_t mBuffer;
    struct InsideDescribe* mDescribe;
};

1.4.1 数据格式

MNN支持下面列出的常见的数据格式，其中N C H W分别表示批次大小通道数高度宽度。这个格式是对图片格式的兼容，在大模型推理中输入embedding的shape是(batch_size, seq_len, hidden_size)，依次是输入、序列长度和隐藏层大小(大模型推理过程中的shape变化可以参考这篇介绍)。

// include/MNN/Tensor.hpp
// 维度类型
    enum DimensionType {
        TENSORFLOW,   // TensorFlow 格式：NHWC
        CAFFE,        // Caffe 格式：NCHW
        CAFFE_C4     // Caffe 格式：NC4HW4（4通道对齐）
    };

在 LLM 场景里, MNN-LLM默认把输入整理成 [seq_len, 1, hidden_size] 或 [1, seq_len, hidden_size]维度, 具体流程可以参考这篇介绍。

我尝试在MNN框架上做了Chunk prefill，把不同输入请求合并在seq_len维度上，并在Attention算子中展开:传送门

1.4.2 底层数据格式

从更底层出发，Tensor类的数据格式信息由halide_buffer_t结构体存储，对应Tensor::halide_buffer_t mBuffer属性，其中存储了数据的指针、数据类型、数据维度等信息，核心代码如下：

// include/MNN/HalideRuntime.h
/**
 * The raw representation of an image passed around by generated
 * Halide code. It includes some stuff to track whether the image is
 * not actually in main memory,  but instead on a device (like a
 * GPU). For a more convenient C++ wrapper,  use Halide::Buffer<T>. */
typedef struct halide_buffer_t {
    /** A device-handle for e.g. GPU memory used to back this buffer. */
    uint64_t device; // 设备句柄

    /** The interface used to interpret the above handle. */
    const struct halide_device_interface_t *device_interface; // 接口指针

    /** A pointer to the start of the data in main memory. In terms of
     * the Halide coordinate system,  this is the address of the min
     * coordinates (defined below). */
    uint8_t* host; // 指针 指向数据

    /** flags with various meanings. */
    uint64_t flags;	

    /** The type of each buffer element. */
    struct halide_type_t type;	// 数据类型

    /** The dimensionality of the buffer. */
    int32_t dimensions;	// 数据维度，如 [batch_size, seq_len, hidden_size] 就是 3 维

    /** The shape of the buffer. Halide does not own this array - you
     * must manage the memory for it yourself. */
    halide_dimension_t *dim; // 数据各维度的数值,  如如[batch_size,  seq_len,  hidden_size]大小的Tensor数据 dim[0]就表示batch_size维度的信息

    /** Pads the buffer up to a multiple of 8 bytes */
    void *padding; // 用来对齐内存
} halide_buffer_t;

其中的数据类型halide_type_t type通过数据占比特数和数据的性质判断数据的类型，例如code = halide_type_float并且bits = 16表示半精度浮点数。核心代码如下：

// include/MNN/HalideRuntime.h
/** A runtime tag for a type in the halide type system. Can be ints, 
 * unsigned ints,  or floats of various bit-widths (the 'bits'
 * field). Can also be vectors of the same (by setting the 'lanes'
 * field to something larger than one). This struct should be
 * exactly 32-bits in size. */
struct halide_type_t {
    /** The basic type code: signed integer,  unsigned integer,  or floating point. */
    
    // 这个code表示数据的性质 见本代码块最下方结构体，例如 halide_type_int = 0,  表示 signed integers 有符号整型
#ifndef _MSC_VER
    HALIDE_ATTRIBUTE_ALIGN(1) halide_type_code_t code; // halide_type_code_t
#else
    HALIDE_ATTRIBUTE_ALIGN(1) uint8_t code; // halide_type_code_t
#endif

    /** The number of bits of precision of a single scalar value of this type. */
    HALIDE_ATTRIBUTE_ALIGN(1) uint8_t bits;	// 数据占用比特数

    /** How many elements in a vector. This is 1 for scalar types. */
    HALIDE_ATTRIBUTE_ALIGN(2) uint16_t lanes; // 一次处理的数据宽度 用于SIMD

    // 构造函数
#ifdef __cplusplus
    /** Construct a runtime representation of a Halide type from:
     * code: The fundamental type from an enum.
     * bits: The bit size of one element.
     * lanes: The number of vector elements in the type. */
    HALIDE_ALWAYS_INLINE halide_type_t(halide_type_code_t code,  uint8_t bits,  uint16_t lanes = 1)
        : code(code),  bits(bits),  lanes(lanes) {
    }
    /** Default constructor is required e.g. to declare halide_trace_event
     * instances. */
    HALIDE_ALWAYS_INLINE halide_type_t() : code((halide_type_code_t)0),  bits(0),  lanes(0) {}

    // 重载了对比函数
    /** Compare two types for equality. */
    HALIDE_ALWAYS_INLINE bool operator==(const halide_type_t &other) const {
        return (code == other.code &&
                bits == other.bits &&
                lanes == other.lanes);
    }
    HALIDE_ALWAYS_INLINE bool operator!=(const halide_type_t &other) const {
        return !(*this == other);
    }
    
	// 单个数据占据的内存字节数,  按8bit向上对齐
    /** Size in bytes for a single element,  even if width is not 1,  of this type. */
    HALIDE_ALWAYS_INLINE int bytes() const { return (bits + 7) / 8; }
#endif
};

typedef enum halide_type_code_t
{
    halide_type_int = 0,    //!< signed integers
    halide_type_uint = 1,   //!< unsigned integers
    halide_type_float = 2,  //!< IEEE floating point numbers
    halide_type_handle = 3,  //!< opaque pointer type (void *)
    halide_type_bfloat = 4  //!< floating point numbers in the bfloat format
} halide_type_code_t;

halide_buffer_t结构体记录的数据维度信息 halide_dimension_t *dim 包含该维度的元素个数(extent)和在该维度移动一步时内存地址的偏移量信息(stride，通常在 TensorUtils::setLinearLayout 中计算)。核心代码如下：

// include/MNN/HalideRuntime.h
typedef struct halide_dimension_t { 
    // extend: 该维度的元素个数
    // stride: 在该维度移动一步时内存地址的偏移量信息
    int32_t min,  extent,  stride;

    // Per-dimension flags. None are defined yet (This is reserved for future use).
    uint32_t flags;

#ifdef __cplusplus
    HALIDE_ALWAYS_INLINE halide_dimension_t() : min(0),  extent(0),  stride(0),  flags(0) {}
    HALIDE_ALWAYS_INLINE halide_dimension_t(int32_t m,  int32_t e,  int32_t s,  uint32_t f = 0) :
        min(m),  extent(e),  stride(s),  flags(f) {}

    HALIDE_ALWAYS_INLINE bool operator==(const halide_dimension_t &other) const {
        return (min == other.min) &&
            (extent == other.extent) &&
            (stride == other.stride) &&
            (flags == other.flags);
    }

    HALIDE_ALWAYS_INLINE bool operator!=(const halide_dimension_t &other) const {
        return !(*this == other);
    }
#endif
} halide_dimension_t;

1.4.3 核心接口

Tensor类的核心接口包括设置/获取数据信息、把数据映射到执行设备、调整大小等，MNN文档有详细介绍, 需要用到时可以自己查看，比较常用的调试接口是打印数据和打印形状，这里打印数据中有根据数据底层的bits和code信息自动转换成对应数据类型的指针进行打印的转化。

// include/MNN/Tensor.hpp
class MNN_PUBLIC Tensor {
public:
    /**
        * @brief print tensor data. for DEBUG use only.
        */
    void print() const;

    /**
        *@brief print tensor shape
        */
    void printShape() const;
}

1.5 Op类

这一层的核心包括 Op 和 OpT 两个结构体:

Op 是 FlatBuffers 映射出来的只读视图，主要用于运行时读取算子类型、参数和输入输出索引；
OpT 是 FlatBuffers 对应的 NativeTable 结构，主要用于修改、构造和重新打包算子信息。
两者之间可以通过 UnPack() / Pack()接口切换，其中Op 适合“读”，OpT 适合“改”。
具体的算子则包括ArgMax、QuantizedAdd、InstanceNorm等，每个算子都有对应的参数结构体，例如 ArgMaxT、QuantizedAddT、InstanceNormT等。

从宏观角度看，Op 和 OpT 的关系如下：

构造阶段（NativeTable，可修改）

OpT
├── type = OpType_ArgMax                  # 算子类型
├── inputIndexes / outputIndexes / name  # 输入输出索引和算子名
└── main : OpParameterUnion
    ├── type  = OpParameter_ArgMax        # 参数类型标签
    └── value -------> ArgMaxT            # 指向具体参数结构体
                         ├── axis
                         ├── topK
                         ├── outMaxVal
                         └── softmaxThreshold


模型二进制转换过程（FlatBuffers）

OpT
  └── Pack / CreateOp(...)                # 把 NativeTable 打包成 FlatBuffers 二进制
        ↓
   FlatBuffer binary                      # 模型中的实际存储形式
        ↓
flatbuffers::GetRoot<Op>(...)             # 从二进制上取得 Op 只读视图
        ↓
       Op
       ├── type()
       ├── inputIndexes()
       └── main_as_ArgMax()               # 按参数类型取出 ArgMax 只读视图
              ↓
            ArgMax
              └── UnPack()                # 如需修改，再转回 NativeTable
                    ↓
                  ArgMaxT

其中：

OpT 和 ArgMaxT 都是 NativeTable 风格的可编辑结构体，适合在内存里构造、修改和重写参数；
flatbuffers::GetRoot<Op>(...) 拿到的 Op 不是重新分配出来的新对象，而是对模型二进制 buffer 的只读映射，因此 ArgMax 也是只读参数视图；
只有继续调用 UnPack()，才会把 Op 或 ArgMax 重新转换成可修改的 OpT、ArgMaxT。

1.5.1 `OpT`结构体

Op 是算子的描述类，定义了神经网络中各种操作的类型和参数。MNN 使用内存高效的 FlatBuffers 库来序列化/反序列化 Op 等信息。其底层通过 OpT结构体存储各参数属性，核心代码如下：

// schema/current/MNN_generated.h
struct OpT : public flatbuffers::NativeTable {
    std::vector<int32_t> inputIndexes;      // 输入张量索引列表
    OpParameterUnion main;                   // 算子参数（联合体）
    std::string name;                        // 算子名称
    std::vector<int32_t> outputIndexes;     // 输出张量索引列表
    OpType type;                             // 算子类型枚举
    MNN_DATA_FORMAT defaultDimentionFormat; // 默认数据格式（NHWC/NCHW等）
    std::string externalPath;               // 外部权重路径
};

这里 OpType 是一个枚举类型，用于表示不同的算子类型，例如 Conv2D、Add、Relu 等。MNN 中定义了多个算子类型，每个类型对应一个具体的算子实现，部分代码如下：

// schema/current/MNN_generated.h
enum OpType {
    OpType_AbsVal = 0, 
    OpType_QuantizedAdd = 1, 
    OpType_ArgMax = 2, 
    OpType_AsString = 3, 
    OpType_InstanceNorm = 4, 
    // ...
};

OpT结构体的main成员是一个联合体（OpParameterUnion），根据算子类型的不同存储不同的参数结构体，例如 QuantizedAdd 算子会存储一个 QuantizedAddT 结构体，ArgMax 算子会存储一个 ArgMaxT 结构体，对应的算子结构体通过OpParameterUnion的方法进行**参数值指针 value**的类型转换，例如AsQuantizedAdd(),AsArgMax()等。

// schema/current/MNN_generated.h
struct OpParameterUnion {
  OpParameter type; // 参数类型
  void *value;      // 参数值，指向具体的参数结构体，如 QuantizedAddT、ArgMaxT 等

  // 根据参数类型转换成对应的参数结构体指针
  QuantizedAddT *AsQuantizedAdd() {
    return type == OpParameter_QuantizedAdd ?
      reinterpret_cast<QuantizedAddT *>(value) : nullptr;
  }
  const QuantizedAddT *AsQuantizedAdd() const {
    return type == OpParameter_QuantizedAdd ?
      reinterpret_cast<const QuantizedAddT *>(value) : nullptr;
  }
  ArgMaxT *AsArgMax() {
    return type == OpParameter_ArgMax ?
      reinterpret_cast<ArgMaxT *>(value) : nullptr;
  }
  const ArgMaxT *AsArgMax() const {
    return type == OpParameter_ArgMax ?
      reinterpret_cast<const ArgMaxT *>(value) : nullptr;
  }

OpParameterUnion中出现的OpParameter type是枚举类型，其包括不同的算子参数类型，例如 QuantizedAdd、ArgMax、InstanceNorm 等，部分枚举如下：

// schema/current/MNN_generated.h
enum OpParameter {
  OpParameter_NONE = 0, 
  OpParameter_QuantizedAdd = 1, 
  OpParameter_ArgMax = 2, 
  // ... 其它代码 
};

也就是一个算子通过OpType来区分算子类型，通过OpParameter来区分参数类型，二者共同决定了算子具体的计算逻辑和参数结构，例如ArgMax算子的构建主要是确定类型以及参数：

// express/MathOp.cpp
VARP _ArgMax(VARP input, int axis) {
    input = _checkNC4HW4(input);
    std::unique_ptr<OpT> op(new OpT);
    // 设置算子类型和参数
    op->main.type                         = OpParameter_ArgMax;
    op->type                              = OpType_ArgMax;
    // 构造参数结构体并设置参数值
    op->main.value                        = new ArgMaxT;
    op->main.AsArgMax()->axis = axis;
    op->main.AsArgMax()->outMaxVal = 0;
    op->main.AsArgMax()->topK = 0;
    op->main.AsArgMax()->softmaxThreshold = 0;
    return (Variable::create(Expr::create(std::move(op), {input})));
}

相对应的 ArgMaxT 结构体可以通过 OpParameterUnion::AsArgMax() 获得，其包含 outMaxVal、topK、axis、softmaxThreshold 等参数，核心代码如下：

struct ArgMaxT : public flatbuffers::NativeTable {
  typedef ArgMax TableType;
  int32_t outMaxVal;
  int32_t topK;
  int32_t axis;
  int32_t softmaxThreshold;
  ArgMaxT()
      : outMaxVal(0), 
        topK(0), 
        axis(0), 
        softmaxThreshold(0) {
  }
};

OpT 不能直接强转成 Op，要先 Pack 成 FlatBuffers，才能通过GetRoot<Op>(uoffset_t i) 接口取出来。例如，Module类加载模型时：

1
2

// express/module/Module.cpp:461
auto op = net->oplists()->GetAs<Op>(i);

1.5.2 `Op`结构体

Op 结构体是模型二进制上的只读视图，主要在读取、解析、构建算子的 Execution 时，部分核心代码如下：

// schema/current/MNN_generated.h
struct Op FLATBUFFERS_FINAL_CLASS : private flatbuffers::Table {
  typedef OpT NativeTableType;
  static const flatbuffers::TypeTable *MiniReflectTypeTable() {
    return OpTypeTable();
  }
  // 获取输入索引列表
  const flatbuffers::Vector<int32_t> *inputIndexes() const {
    return GetPointer<const flatbuffers::Vector<int32_t> *>(4);
  }
  // 获取参数类型
  OpParameter main_type() const {
    return static_cast<OpParameter>(GetField<uint8_t>(6,  0));
  }
  // 获取指针
  const void *main() const {
    return GetPointer<const void *>(8);
  }
  
  // 通过一组 main_as_XXX 函数，根据参数类型转换成对应的参数结构体
  template<typename T> const T *main_as() const;
  const QuantizedAdd *main_as_QuantizedAdd() const {
    return main_type() == OpParameter_QuantizedAdd ? static_cast<const QuantizedAdd *>(main()) : nullptr;
  }
  const ArgMax *main_as_ArgMax() const {
    return main_type() == OpParameter_ArgMax ? static_cast<const ArgMax *>(main()) : nullptr;
  }
  // ... 其它代码

  // 通过 FlatBuffers 在 Op 和 OpT 之间切换
  OpT *UnPack(const flatbuffers::resolver_function_t *_resolver = nullptr) const;
  void UnPackTo(OpT *_o,  const flatbuffers::resolver_function_t *_resolver = nullptr) const;
  static flatbuffers::Offset<Op> Pack(flatbuffers::FlatBufferBuilder &_fbb,  const OpT* _o,  const flatbuffers::rehasher_function_t *_rehasher = nullptr);
};

在Op结构体中，算子有一个自己的参数解析方法: 通过main_type() 获取参数类型(OpParameter 枚举类型), 并通过一组 main_as_XXX 函数来把Op转换成具体算子的结构体，例如，通过 main_as_ArgMax() 转换成 ArgMax 结构体指针。 ArgMax结构体核心代码如下，是flatbuffers生成的解析函数，可以解析对应参数的值：

// schema/current/CaffeOp_generated.h
struct ArgMax FLATBUFFERS_FINAL_CLASS : private flatbuffers::Table {
  typedef ArgMaxT NativeTableType;
  static const flatbuffers::TypeTable *MiniReflectTypeTable() {
    return ArgMaxTypeTable();
  }
  // 获取各种算子的参数
  int32_t outMaxVal() const {
    return GetField<int32_t>(4,  0);
  }
  int32_t topK() const {
    return GetField<int32_t>(6,  0);
  }
  int32_t axis() const {
    return GetField<int32_t>(8,  0);
  }
  int32_t softmaxThreshold() const {
    return GetField<int32_t>(10,  0);
  }
  bool Verify(flatbuffers::Verifier &verifier) const {
    return VerifyTableStart(verifier) &&
           VerifyField<int32_t>(verifier,  4) &&
           VerifyField<int32_t>(verifier,  6) &&
           VerifyField<int32_t>(verifier,  8) &&
           VerifyField<int32_t>(verifier,  10) &&
           verifier.EndTable();
  }
  // `UnPack`接口可以把反序列化成包含了算子参数的各种属性
  ArgMaxT *UnPack(const flatbuffers::resolver_function_t *_resolver = nullptr) const;
  void UnPackTo(ArgMaxT *_o,  const flatbuffers::resolver_function_t *_resolver = nullptr) const;
  static flatbuffers::Offset<ArgMax> Pack(flatbuffers::FlatBufferBuilder &_fbb,  const ArgMaxT* _o,  const flatbuffers::rehasher_function_t *_rehasher = nullptr);
};

因此，执行层最常见的访问路径通常是 Op -> main_as_ArgMax() -> ArgMax -> 读取字段。例如source/backend/cpu/CPUArgMax.cpp中构建Execution时就通过Op结构体获取到ArgMax参数结构体，然后通过FlatBuffers生成的访问接口获取参数，核心代码如下：

// source/backend/cpu/CPUArgMax.cpp
class CPUArgMaxCreator : public CPUBackend::Creator {
public:
    virtual Execution *onCreate(const std::vector<Tensor *> &inputs, const std::vector<Tensor *> &outputs,
                                const MNN::Op *op, Backend *backend) const {
        // 通过 Op 结构体获取 ArgMax 参数结构体
        auto argMax = op->main_as_ArgMax();
        if (op->type() == OpType_ArgMin) {
            return new CPUArgMax(backend, CPUArgMax::ArgMinOrMax::ARGMIN,
                    argMax->topK(), argMax->outMaxVal(), argMax->softmaxThreshold(), argMax->axis());
            // 上面通过topK()、outMaxVal()、softmaxThreshold()、axis()等接口获取算子的参数值
        } else {
            return new CPUArgMax(backend, CPUArgMax::ArgMinOrMax::ARGMAX,
                    argMax->topK(), argMax->outMaxVal(), argMax->softmaxThreshold(), argMax->axis());
        }
    }
};

1.5.3 其他细节

总结一下：读取算子时通常用 Op 结构体，修改/写入时通常用 OpT 结构体。阅读代码时可以优先留意带 T 的结构体名称，例如 ArgMaxT、ConvolutionT，它们一般更接近可编辑的上层表示。

MNN 中会把常见的线性层转换为卷积 Convolution 算子，常用算子 UnaryOp 和 BinaryOp 分别表示一元和二元算子。

常用接口：可以使用 EnumNameXXX 方式获取 OpType、OpParameter 等枚举类型的字符串名称，便于调试，例如：

// schema/current/MNN_generated.h
inline const char *EnumNameOpType(OpType e);
inline const char *EnumNameOpParameter(OpParameter e);

// schema/current/TensorflowOp_generated.h
inline const char *EnumNameBinaryOpOperation(BinaryOpOperation e);

这里的获取都是从一个静态数组中取值实现的，例如二元操作的各个名称存储在静态数组中，并且通过 EnumNameBinaryOpOperation() 根据枚举值获取对应的名称字符串，代码如下：

// schema/current/TensorflowOp_generated.h
inline const char * const *EnumNamesBinaryOpOperation() {
  static const char * const names[] = {
    "ADD", 
    "SUB", 
    "MUL", 
    "DIV", 
    "MAX_TEMP", 
    "MIN_TEMP", 
    "POW", 
    "REALDIV", 
    "MINIMUM", 
    "MAXIMUM", 
    "GREATER", 
    "GREATER_EQUAL", 
    "LESS", 
    "FLOORDIV", 
    "SquaredDifference", 
    "EQUAL", 
    "LESS_EQUAL", 
    "FLOORMOD", 
    "", 
    "MOD", 
    "ATAN2", 
    "LOGICALOR", 
    "NOTEQUAL", 
    "BITWISE_AND", 
    "BITWISE_OR", 
    "BITWISE_XOR", 
    "LOGICALXOR", 
    "LEFTSHIFT", 
    "RIGHTSHIFT", 
    nullptr
  };
  return names;
}
inline const char *EnumNameBinaryOpOperation(BinaryOpOperation e) {
  if (e < BinaryOpOperation_ADD || e > BinaryOpOperation_RIGHTSHIFT) return "";
  const size_t index = static_cast<int>(e);
  return EnumNamesBinaryOpOperation()[index];
}

1.5.4 GEMM转卷积算子

端侧执行LLM时MNN框架会把Linear/MatMul算子替换成Conv2d算子，这一节形式化的描述“卷积”和“矩阵乘法”之间的等价关系。

1.5.4.1 二维卷积

最常见的二维卷积输入可以写成：

输入：$[N, C_{\mathrm{in}}, H, W]$
卷积核：$[C_{\mathrm{out}}, C_{\mathrm{in}}, K_h, K_w]$
输出：$[N, C_{\mathrm{out}}, H_{\mathrm{out}}, W_{\mathrm{out}}]$

这个四维卷积核有$C_{\mathrm{out}}$个输入通道数为$C_{\mathrm{in}}$大小为$[K_h, K_w]$的二维维积核，每个卷积核的计算就是通常的二维卷积：在$[H,W]$的二维矩阵上把卷积核滑动，每个位置上做输入局部矩阵(大小和卷积核一致)与卷积核的点积，得到一个输出值：

$$Y[h, w] = \sum_{k_h=0}^{K_h-1}\sum_{k_w=0}^{K_w-1} X[h+k_h, w+k_w] \cdot K[k_h, k_w]$$

叠加上输入通道和输出通道的维度后，

$$\mathrm{output}[n, c_{\mathrm{out}}, h, w] = \sum_{c_{\mathrm{in}}, k_h, k_w}\mathrm{input}[n, c_{\mathrm{in}}, h + k_h, w + k_w] \cdot \mathrm{weight}[c_{\mathrm{out}}, c_{\mathrm{in}}, k_h, k_w]$$

每个输出通道都有自己的一套跨输入通道权重，用它把输入通道混合成一张新的输出特征图。

1.5.4.2 `im2col`

卷积直接按窗口滑动实现效率低下，工程上更常见的做法是先把输入展开成二维，再把卷积改写成一次大的矩阵乘法，这个展开过程通常就叫 im2col。

以二维卷积为例，im2col 的思路是：

对每一个输出空间位置，取出对应的输入感受野；
把这个局部窗口拉平成一行；
把所有输出位置对应的局部窗口按行堆起来，形成一个大矩阵。

如果卷积核大小是 $K_h \times K_w$，输入通道数是 $C_{\mathrm{in}}$，那么每个局部窗口拉平后长度就是：

$$C_{\mathrm{in}} \times K_h \times K_w$$

如果总共有

$$H_{\mathrm{out}} \times W_{\mathrm{out}}$$

个输出位置，那么 im2col 后的输入矩阵可以理解成：

$$\left[H_{\mathrm{out}} \times W_{\mathrm{out}}, C_{\mathrm{in}} \times K_h \times K_w\right]$$

而卷积核本身也可以拉平成另一个矩阵：

$$\left[C_{\mathrm{out}}, C_{\mathrm{in}} \times K_h \times K_w\right]$$

这样卷积就被改写成了一个标准的矩阵乘法：

$$\left[H_{\mathrm{out}} \times W_{\mathrm{out}}, C_{\mathrm{in}} \times K_h \times K_w\right] \times \left[C_{\mathrm{in}} \times K_h \times K_w, C_{\mathrm{out}}\right] = \left[H_{\mathrm{out}} \times W_{\mathrm{out}}, C_{\mathrm{out}}\right]$$

最后再把结果 reshape 回 $[C_{\mathrm{out}}, H_{\mathrm{out}}, W_{\mathrm{out}}]$ 即可。

1.5.4.3 `GEMM`等价成卷积

以 LLM 推理里常见的线性层 $xW$ 为例。设：

$x$ 的维度是 $[\mathrm{bs}, \mathrm{seq}, \mathrm{hidden}]$；
$W$ 的维度是 $[\mathrm{hidden}, \mathrm{hidden}]$；
输出 $y$ 的维度仍然是 $[\mathrm{bs}, \mathrm{seq}, \mathrm{hidden}]$。

矩阵乘法写成：

$$y = xW$$

展开到单个 batch、token 位置和输出通道：

$$y[b, i, o] = \sum_{d=0}^{\mathrm{hidden}-1} x[b, i, d] \cdot W[d, o]$$

这里 $i$ 是 token 位置，$d$ 是输入 hidden 通道，$o$ 是输出 hidden 通道。这个计算对每个 token 位置独立发生，不混合相邻 token。

可以想象成有 bs 个输入通道数是 hidden，空间大小是 $[1, \mathrm{seq}]$的样本，与输入/输出通道数都是 hidden二维卷积核大小是 $[1, 1]$的卷积核进行卷积。把算子替换成卷积可以复用底层卷积实现的高效计算，同时也能更好地适配端侧的内存访问模式。

1.6 Pipeline类

这一层对应的核心类是 Pipeline。Pipeline 不是单个算子，而是一条已经切分好的执行流水线，负责把 Schedule::PipelineInfo 里的算子信息真正落到 Execution、Tensor 和运行时后端上。

source/core/Pipeline.hpp 里最重要的三个阶段是：

encode()：计算 shape、做 geometry transform，并把 op / tensor 信息写入缓冲；
allocMemory()：为每个 op 创建 Execution 并分配内存；
execute()：按流水线顺序真正跑算子。

// source/core/Pipeline.hpp
class Pipeline : public NonCopyable {
public:
    ErrorCode encode(bool supportDebug = false, bool permitCodegen = false);
    ErrorCode allocMemory(bool firstMalloc, bool permitCodegen);
    ErrorCode execute();
};

这里可以把 Pipeline 理解成一次“从调度信息到可执行算子序列”的落地过程。

/** encode :
   1. compute shape for every op's inputs and outputs;
   2. geometry transform;
   3. copy op, inputs and outputs tensor info to mBuffer
*/
ErrorCode encode(bool supportDebug = false, bool permitCodegen = false);

Pipeline 干的是把调度阶段已经决定好的结果继续往后推进：

先把 shape 和几何变换补齐；
再创建每个算子的 Execution；
最后按顺序进入 execute()。

流程如下：

Session::run()
    ↓
Pipeline::execute()
    ↓
Execution::onExecute()

这里的 Pipeline 是 Session 下面去调用“算子序列”执行的层。

1.7 Session类

这一层对应的核心类是 Session。Session 负责把模型切成一组 Pipeline，再把当前运行时、输入输出张量、resize 状态和 cache 状态串起来。

source/core/Session.hpp 里可以直接看到它的职责：

持有 RuntimeInfo；
持有 std::vector<std::shared_ptr<Pipeline>> mPipelines；
提供 run()、runWithCallBack()、resize()、getInput()、getOutput() 等入口。

// source/core/Session.hpp
class MNN_PUBLIC Session {
public:
    ErrorCode run() const;
    ErrorCode runWithCallBack(const TensorCallBackWithInfo& before,
                              const TensorCallBackWithInfo& after,
                              bool sync = false) const;
    ErrorCode resize();
};

Session 的关键不只是“有一组 Pipeline”，而是它把运行模式、后端、输入输出张量和 cache 策略放到了同一个上下文里。比如 ModeGroup 里就直接收了这些控制项：

struct ModeGroup {
    Interpreter::SessionMode inputMode = Interpreter::Session_Input_Inside;
    Interpreter::SessionMode outputMode = Interpreter::Session_Output_Inside;
    Interpreter::SessionMode backendMode = Interpreter::Session_Backend_Fix;
    Interpreter::SessionMode resizeMode = Interpreter::Session_Resize_Direct;
    Interpreter::SessionMode memoryUsageMode = Interpreter::Session_Memory_Collect;
};

在source/core/Session.cpp里的createPipelineBackend()` 会进一步把调度结果落成具体后端：

// source/core/Session.cpp
auto rt         = runtime.first.find(iter.first.info.type)->second.get();
auto cpuRuntime = runtime.second;
iter.first.cache.first.reset(rt->onCreate(iter.first.info.user));

if (iter.first.cache.first->type() == MNN_FORWARD_CPU && (!specialUsage)) {
    iter.first.cache.second = iter.first.cache.first;
} else {
    iter.first.cache.second.reset(cpuRuntime->onCreate(&defaultConfig, origin));
}

这里的设计重点是：

主后端负责按用户选择真正执行算子；
CPU 备份后端负责 shape 计算和不支持算子的兜底；
一个 Session 里可以有多个 Pipeline，每个 Pipeline 共享同一套运行时上下文。

这里的Session 不是单纯的数据容器，而是一次推理的完整执行上下文。

1.8 Executor & ExecutorScope类

这一层对应的核心类是 Executor 和 ExecutorScope。Executor 负责 Express 图的 shape 推导、依赖收集和 ComputeCache 构建；ExecutorScope 则是线程局部的当前执行器入口。

先看 Executor 的公开接口：

// include/MNN/expr/Executor.hpp
class MNN_PUBLIC Executor {
public:
    struct Requirement {
        std::vector<bool> contentNeedContent;
        std::vector<bool> shapeNeedContent;
    };
    Requirement getRequirement(Expr* expr) const;
    ErrorCode computeInfo(Expr* expr);
    void makeCache(const std::vector<EXPRP>& expr, bool forceCPU = false);
};

分别对应三层职责：

getRequirement()：判断一个 Expr 的输入到底是“只要 shape”还是“必须读内容”；
computeInfo()：调用 SizeComputer::computeOutputSize() 推导输出张量信息；
makeCache()：把当前 Expr 子图整理成 ComputeCache，并在里面构造临时 Session。

express/Executor.cpp 里的 computeInfo() 实现是这条链路的核心：

// express/Executor.cpp
bool res = SizeComputer::computeOutputSize(op, inputTensors, expr->inside()->mOutputTensors);
if (!res) {
    return COMPUTE_SIZE_ERROR;
}
for (int i = 0; i < expr->outputSize(); ++i) {
    auto tensor = expr->inside()->mOutputTensors[i];
    TensorUtils::setLinearLayout(tensor);
    auto shape  = expr->outputInfo(i);
    Utils::copyTensorToInfo(shape, tensor);
}

而 _makeCache() 是“小型调度器”，它会：

从输出 Expr 逆向遍历依赖；
收集每个算子的输入输出 Tensor；
组装 Schedule::ScheduleInfo；
最后直接构造一个临时 Session 塞进 ComputeCache。

// express/Executor.cpp
scheduleInfo.pipelineInfo.resize(1);
auto& pipeline = scheduleInfo.pipelineInfo[0].second;
...
pipeline.emplace_back(std::move(opInfo));
...
cahce->mSession.reset(new Session(std::move(scheduleInfo), group, std::move(rt)));

这里的Executor 在 Express 层的作用包括做 shape 推导和把动态图临时收敛成一次可执行的 Session。

ExecutorScope 则负责解释当前代码到底应该使用哪个 Executor。

// express/ExecutorScope.cpp
const std::shared_ptr<Executor> ExecutorScope::Current() {
    auto exe = _getGlobalScope()->Content();
    if (exe) {
        return exe;
    }
    return Executor::getGlobalExecutor();
}

它的设计点在于线程局部作用域：

显式进入 ExecutorScope(current) 后，当前线程会临时绑定新的 Executor；
作用域结束时自动退出；
如果当前线程没有显式绑定，就回退到全局 Executor。

普通使用不需要手动进入 ExecutorScope。直接调用 ExecutorScope::Current() 时，如果当前线程没有绑定过局部执行器，它会返回全局作用域 Executor::getGlobalExecutor()。只有在需要临时切换到某个自定义 Executor 时，才需要手动创建一个 ExecutorScope 对象：

BackendConfig config;
auto exe = Executor::newExecutor(MNN_FORWARD_CPU, config, 1);
{
    ExecutorScope scope(exe);
    // 这个作用域内，ExecutorScope::Current() 返回 exe
    auto y = _Add(x0, x1);
    y->readMap<float>();
}
// 离开作用域后，自动恢复到上一层 Executor；
// 如果没有上一层，就继续回退到全局 Executor。

交叉编译开发环境配置与远程调试

Thu, 26 Feb 2026 23:00:00 +0800

交叉编译开发环境配置与远程调试

本文以MNN框架为例介绍交叉编译环境中的常见设置。

交叉编译开发环境配置与远程调试

1. ANDROID_NDK配置

交叉编译的流程是在机器A上编译生成在机器B上运行的可执行文件，随后把可执行文件推送到机器B运行，而这里机器A和机器B的系统架构不同，所以需要在编译过程中指定编译器和相关工具链。对于安卓开发来说，交叉编译工具链是ANDROID_NDK。

步骤1：下载最新版软件包, 获取地址(选择对应平台最新稳定版, 点击后出现 “Android 软件开发套件许可协议”，勾选后鼠标右键下载按钮可以复制下载链接)

# 服务器端运行
# 到指定目录 下载 解压 android_ndk 
cd ~ && mkdir android_ndk && cd ~/android_ndk
wget https://googledownloads.cn/android/repository/android-ndk-r29-linux.zip
unzip android-ndk-r29-linux.zip # 这个文件名和下载的版本有关
# 删除压缩包
rm android-ndk-r29-linux.zip # 这个文件名和下载的版本有关

# 进入并记住解压后的目录
# 在目录用"pwd"命令可以获取绝对路径
cd android-ndk-r29 # 这个目录和下载的版本有关 可以通过ls -lah 显示目录

步骤2：配置环境变量

# 服务器端运行
# 通常会配置ANDROID_NDK_ROOT的环境变量
# 但MNN中在project/android/build_64.sh 中使用的是$ANDROID_NDK环境变量 所以都设置一下
➜ export ANDROID_NDK="$HOME/android_ndk/android-ndk-r29" # 环境变量
➜ $ANDROID_NDK/ndk-build --version	# 验证环境变量
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation,  Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY,  to the extent permitted by law.

# 在命令行单次export只会在当前命令行有效 新开的终端不生效
# 需要把环境变量写到shell的配置文件中 bash对应~/.bashrc zsh对应~/.zshrc
# !!注意这里重定向是重定向文件末尾 '>>' 符号
echo 'export ANDROID_NDK="$HOME/android_ndk/android-ndk-r29"' >> ~/.zshrc # 环境变量
echo 'export ANDROID_NDK_ROOT="$HOME/android_ndk/android-ndk-r29"'  >> ~/.zshrc # 环境变量
echo 'export PATH="$ANDROID_NDK:$PATH"' >> ~/.zshrc
# 验证
➜  ndk-build
Android NDK: Could not find application project directory !
Android NDK: Please define the NDK_PROJECT_PATH variable to point to it.
/root/android_ndk/android-ndk-r29/build/core/build-local.mk:151: *** Android NDK: Aborting    .  Stop.

编译测试，MNN官方文档

# 服务器端运行
# 克隆仓库
git clone https://github.com/alibaba/MNN.git
# 进入仓库
cd MNN && cd project/android
# 主库编译
# 可以根据开发服务器cpu适当调高 project/android/build_64.sh里编译的线程数
# make -j256 # 原脚本4线程编译慢
mkdir build64 && cd build64 && ../build_64.sh
# 无报错，编译通过

编译脚本大概如下：

#!/bin/bash
cmake ../../../ \
-DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK/build/cmake/android.toolchain.cmake \ # 指定工具链文件
-DCMAKE_BUILD_TYPE=Release \
-DANDROID_ABI="arm64-v8a" \ # 指定编译架构
-DANDROID_STL=c++_static \ 
-DMNN_USE_LOGCAT=false \
-DMNN_BUILD_BENCHMARK=ON \
-DMNN_USE_SSE=OFF \
-DMNN_BUILD_TEST=ON \
-DANDROID_NATIVE_API_LEVEL=android-21  \ # 指定安卓API版本
-DMNN_BUILD_FOR_ANDROID_COMMAND=true \
-DMNN_LOW_MEMORY=ON \
-DMNN_BUILD_DIFFUSION=ON \
-DMNN_BUILD_OPENCV=ON \
-DMNN_IMGCODECS=ON \
-DMNN_OPENCL=ON \
-DMNN_SEP_BUILD=OFF \
-DMNN_SUPPORT_TRANSFORMER_FUSE=ON \
-DNATIVE_LIBRARY_OUTPUT=. -DNATIVE_INCLUDE_OUTPUT=. $*

make -j256

1.1 logcat

MNN中的MNN_PRINT MNN_ERROR等信息在android调试上需要通过logcat捕获

#include <android/log.h>
#define MNN_ERROR(format,  ...) __android_log_print(ANDROID_LOG_ERROR,  "MNNJNI",  format,  ##__VA_ARGS__)
#define MNN_PRINT(format,  ...) __android_log_print(ANDROID_LOG_INFO,  "MNNJNI",  format,  ##__VA_ARGS__)
#endif

在连接了adb的终端可以使用， logcat参考

1
2
3

adb logcat # 所有日志 可以用grep过滤
adb logcat -c # 清除缓冲区
adb logcat -s <Tag>:<Level> # 仅显示指定标签的日志 <Tag>日志的标签 <Level>日志级别 如D(Debug) W(Warning) E(Error)等

2 VSCode Clangd配置

平时使用IDEA进行cpp开发时，可以智能补全代码、快速跳转到定义/声明，交叉编译环境下可以选择使用Clangd实现。

步骤1：VSCode安装clangd插件
- 在插件商店搜索下载clangd
- 下载 C/C++插件，并且禁用该插件的补全，（这个插件的补全会与clangd插件冲突，但是cmake tools依赖该插件
  
  在设置中搜索Intelli Sense Engine，并且设置为disable

步骤2：添加编译选项 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

# 同上编译位置 MNN目录位置可能不同
cd MNN && cd project/android/build64
# 添加编译选项
../build_64.sh -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
# 该命令会在编译目录生成compile_commands.json 文件
# 记录了项目中每个源文件的完整编译命令， 给clangd提供编译信息

步骤3：配置clangd

配置settings.json，在项目根目录中创建文件夹.vscode，在文件夹.vscode中创建文件settings.json

// path: MNN/.vscode/settings.json 用于为当前项目配置编辑器行为和开发环境设置的文件
{
    "clangd.arguments": [
        "-j=16", 	// 索引时使用16线程
        "--header-insertion=never",  // 禁用自动插入头文件
        "--compile-commands-dir=${workspaceFolder}/project/android/build64",  // compile_commands.json 文件路径，可用绝对路径 
        "--query-driver=/root/android-ndk/android-ndk-r29/toolchains/llvm/prebuilt/linux-x86_64/bin/clang*",  //解析 NDK 的 Clang 编译器,  这个路径在compile_commands.json中的个文件编译命令"command"可以找到，带上*号表示通配符,  这个路径也和NDK安装路径有关 因人而异
        "--clang-tidy" // 代码静态分析
    ], 
    "clangd.path": "/root/android-ndk/android-ndk-r29/toolchains/llvm/prebuilt/linux-x86_64/bin/clangd",  //cland路径
}

这里使用ANDROID_NDK中的clangd.path

# 不同版本路径可能略有不同,  可以通过find命令查找，
# 使用找到的clangd的绝对路径
➜  cd $ANDROID_NDK      
➜  find . -type f -iname "clangd"
./toolchains/llvm/prebuilt/linux-x86_64/bin/clangd

在vscode中使用ctrl+shift+p调出命面板，搜索选择clangd: Restart language server或者Developer: Reload Window，可以在vscode中进行正常代码跳转

配置.clangd, 在MNN根目录下创建文件.clangd

# 消除一些无意义的报错
Diagnostics:
  UnusedIncludes: None # 禁用“未使用头文件”警告
  Suppress:	# 屏蔽指定的警告/提示 按需使用
    - "macro_is_not_used"
    - "pp_including_mainfile_in_preamble"
    - "misleading-indentation"

Suppress屏蔽的报错信息可以把鼠标靠近报错的地方查找，例如：括号中的pp_file_not_found

部分无法索引的可能因为编译宏未打开，例如llm.hpp需要打开-DMNN_BUILD_LLM=true才会编译，查找文件是否编译可以直接在compile_commands.json中搜索对应文件。

步骤4：最后的目录结构

MNN/
├── .vscode/
│   └── settings.json
├── .clangd
└── ...（其他项目文件和目录，如 include/,  source/,  transformers/ 等）

3 调试

3.1 服务器调试

代码出错一直靠printf打印需要麻烦且看不到调用栈，vscode中有直接在服务器上进行逻辑调试的插件。

注意：这里服务器调试是在服务器上运行，所以编译指令与前面在移动手机运行不同，最终运行是在服务器运行

步骤1：在vscode中安装插件cmake tools
步骤2：安装完成后侧边栏多出cmake功能区
步骤3：点击选择工具包，选择在服务器测试时的编译器，如果没有编译器，需自行安装gcc clang等
步骤4：选择好工具包后，会自动扫描根目录的cmakelist, 进行配置，也可以执行点击按钮配置，下图中的按钮是配置、生成所有文件

步骤5：配置cmake 生成构建系统, 如果需要添加编译宏需要在.vscode/settings.json中添加如下参数

{
    // 下面内容和前面的clagnd设置放在一个{}中
    "cmake.configureArgs": [ // 编译宏
        "-DMNN_LOW_MEMORY=true",  
        "-DMNN_CPU_WEIGHT_DEQUANT_GEMM=true", 
        "-DMNN_BUILD_LLM=true",  // 编译MNN-LLM模块
        "-DMNN_SUPPORT_TRANSFORMER_FUSE=true",  // attention模块融合成算子 而不是进一步拆成算子
    ], 
    "cmake.buildArgs" : ["-j128"],  // 编译线程
    "cmake.generator": "Unix Makefiles",  // 使用make构建
}

步骤6：在项目大纲的配置中选择”使用cmake调试器配置所有项目“，然后打开控制面板选择Developer: Reload Window; 重新配置的对象就会刷新在左侧项目大纲
步骤7：在项目大纲这里选择想调试/生成的文件，右键鼠标可以选择调试

如果调试的可执行文件执行时需要args，需要在.vscode/settings.json中添加参数，

这里以llm_demo为例，运行llm_demo的命令是./llm_demo /data/HUGGINGFACE/Qwen3-4B-Instruct-2507-Eagle3-MNN/llm.mnn ，如果follow这个步骤需要自行下载Qwen3-4B-Instruct-2507-Eagle3-MN模型，并且复制到llm.mnn的路径
1 2 3 4 5

{ // 添加到.vscode/settings.json "cmake.debugConfig": { "args": ["/data/HUGGINGFACE/Qwen3-4B-Instruct-2507-Eagle3-MNN/llm.mnn"], } }
步骤8：在程序中打断点按照上一步开始调试。如果没有调试器，需自行安装gdb lldb等；这一步需要c/c++插件，未安装见[VSCode Clangd配置](#2 VSCode Clangd配置), 需要禁用部分与clangd冲突功能。

在终端输入”hello“后成功卡在断点，说明配置成功。

说明：cmake tools的配置编译产物在根目录的build文件夹下

3.2 远程调试（launch模式）

部分在指定手机的后端运行的代码无法在服务器调试，需要通过远程调试。远程调试需要建立服务器到手机的通信链路，如果链路带宽有限启动调试会很慢，所以部分与运行后端无关的逻辑推荐服务器调试，并且推荐的服务器到手机的通信链路使用TailScale/EasyTier隧道的方式

原理：服务器上通过ANDROID_NDK目录下的lldb 借助服务器->手机的通信链路与手机上运行的ANDROID_NDK目录下的lldb-server通信，进行远程调试。总结需要完成的事情是: (1)找ANDROID_NDK目录下的lldb lldb-server文件， (2)做两个端口的通信转发链路，在手机运行lldb-server (3)编译把所需运行文件推送到手机 (4)下载配置CodeLLDB插件 (5) 配置调试参数开始调试
步骤1：VSCode安装CodeLLDB插件官方文档

步骤2：查找lldb lldb-server。lldb和lldb-server是一对，调试时服务器上的lldb会连接设备端中启动的lldb-server。lldb文档

# 服务器端运行
➜  cd $ANDROID_NDK                     
➜  find . -type f -iname "lldb"  
./toolchains/llvm/prebuilt/linux-x86_64/bin/lldb
➜  find . -type f -iname "lldb-server"
./toolchains/llvm/prebuilt/linux-x86_64/lib/clang/21/lib/linux/arm/lldb-server
./toolchains/llvm/prebuilt/linux-x86_64/lib/clang/21/lib/linux/i386/lldb-server
./toolchains/llvm/prebuilt/linux-x86_64/lib/clang/21/lib/linux/riscv64/lldb-server
./toolchains/llvm/prebuilt/linux-x86_64/lib/clang/21/lib/linux/x86_64/lldb-server
./toolchains/llvm/prebuilt/linux-x86_64/lib/clang/21/lib/linux/aarch64/lldb-server

步骤3：构建通信链路，lldb与lldb-server之间的通信需要启动额外的通信端口，所以构建通信链路时需要开启两个端口

# 本地运行
# 为了简化说明 adb调试端口统一设置为30303 lldb通信端口设置为31313

# adb 远程调试端口应该设置为30303
adb tcpip 30303 # 插入usb连接手机 启动无线adb调试，部分机型可能需要在开发者模式设置允许无线调试
adb connect ip_P:30303  # 验证无线adb连接，手机的ip可能会随着网络变化，可以在手机设置中搜索ip查看，或者路由器页面查看，或者adb shell ip a查看

# 下面的host_name是本地通过SSH连接服务器时config中的Host别名
# 可以修改为本地L通过ssh连接服务器S的user ip port,  不是需要转发的ip和端口

# 构建adb调试端口转发
ssh -N -R 0.0.0.0:30303:localhost:30303 host_name # 将服务器30303端口转发至本地30303端口
adb forward tcp:30303 tcp:30303 # 将本地30303端口转发给adb设备30303端口

# 构建lldb通信端口转发
ssh -N -R 0.0.0.0:31313:localhost:31313 host_name # 将服务器31313端口转发至本地31313端口
adb forward tcp:31313 tcp:31313 # 将本地31313端口转发给adb设备31313端口

步骤4：给手机端推送并启动lldb-server，由于adb连接根目录下有许多系统文件不root没有权限所以通常文件推送到/data/local/tmp目录下运行

# 服务器运行

# 1. 连接adb
# sudo apt install adb -y 若无adb
adb connect 127.0.0.1:30303 # 连接adb
# 2. 查看指令集，大部分手机是arm64-v8a架构，需要aarch64 版本的lldb-server
➜  adb shell getprop ro.product.cpu.abi
arm64-v8a

# 3. 把lldb-server推送给手机端 根据上面的查找路径 推送
➜  adb shell mkdir /data/local/tmp/mnn-test/   # 创建路径
➜  adb push $ANDROID_NDK/toolchains/llvm/prebuilt/linux-x86_64/lib/clang/21/lib/linux/aarch64/lldb-server /data/local/tmp/mnn-test/ # !!注意末尾的 / 表示目录

# 4. 进入adb 运行lldb-server
➜  adb shell  
RE602CL1:/ $ cd /data/local/tmp/mnn-test/                                           
RE602CL1:/data/local/tmp/mnn-test $ chmod a+x lldb-server               
RE602CL1:./lldb-server platform --server --listen "*:31313" --log-channels "lldb process" # 这里端口要对应上lldb链路的端口

# 说明可以通过下面命令清理/查看adb转发的端口列表
# adb forward --remove-all
# adb forward --list

# 5. 测试
# 另起一个shell 启动lldb
➜ cd $ANDROID_NDK
➜ export PATH=$(pwd)/toolchains/llvm/prebuilt/linux-x86_64/python3/bin:$PATH # 临时设置python路径，后面调试无需设置
➜ export LD_LIBRARY_PATH=$(pwd)/toolchains/llvm/prebuilt/linux-x86_64/python3/lib:$LD_LIBRARY_PATH # 临时设置环境变量，后面调试无需设置
# 具体路径可以根据缺失的包查找 如下
# ➜ find . -type f -iname "libpython3.11.so.1.0"
#./toolchains/llvm/prebuilt/linux-x86_64/python3/lib/libpython3.11.so.1.0
➜ adb connect 127.0.0.1:30303 # 连接adb
already connected to 127.0.0.1:30303
➜ ./toolchains/llvm/prebuilt/linux-x86_64/bin/lldb # 启动lldb
No entry for terminal type "xterm-256color";
using dumb terminal settings.
(lldb) version
lldb version 21.0.0 (/mnt/disks/build-disk/src/googleplex-android/llvm-r563880-release/out/llvm-project/lldb revision 5e96669f06077099aa41290cdb4c5e6fa0f59349)
  clang revision 5e96669f06077099aa41290cdb4c5e6fa0f59349
  llvm revision 5e96669f06077099aa41290cdb4c5e6fa0f59349
(lldb) platform select remote-android	# 选择平台
  Platform: remote-android
 Connected: no
(lldb) platform connect connect://localhost:31313 # 连接设备
  Platform: remote-android
    Triple: aarch64-unknown-linux-android
OS Version: 35 (6.6.30-android15-8-g013ec21bba94-abogki383916444-4k)
  Hostname: localhost
 Connected: yes
WorkingDir: /data/local/tmp/mnn-test
    Kernel: #1 SMP PREEMPT Tue Dec 17 23:36:49 UTC 2024
(lldb) quit # 以上流程验证成功说明链路测试成功，!!!!!quit退出当前lldb!!!!!

# -------------------------------
# 连接成功后lldb-server侧出现连接建立提示
# RE602CL1:/data/local/tmp/mnn-test $ ./lldb-server platform --server --listen "*:31313"
# Connection established.

步骤5：配置.vscode/launch.json文件，设置调试参数, 依旧以llm_demo为例，部分参数需要和前面的设置一致。这里使用launch模式无法使用标准输入，样例使用llm_demo的另一个用法–文件输入。需要标准输入要使用attach模式在adb窗口运行进程并attach给lldb。

{
    "version": "0.2.0", 
    "configurations": [
        {
            "name": "Android Native Debug (CodeLLDB)", 
            "type": "lldb",    
            "request": "launch", 
            "program": "${workspaceFolder}/project/android/build64/llm_demo",  // 要调试的可执行文件
            "initCommands": [
                "platform select remote-android",  // 选择远程android平台，参考lldb文档https://lldb.llvm.org/use/remote.html
                "platform connect connect://127.0.0.1:31313",  // 连接lldb-server
                "settings set target.inherit-env false",  // 禁用继承本地环境变量
                "platform settings -w /data/local/tmp/mnn-test",  // 设置调试目录
                "platform status",  // 验证连接状态
            ], 
            "preRunCommands": [
                "settings set target.env-vars LD_LIBRARY_PATH=/data/local/tmp/mnn-test",  //设置环境变量，MNN端侧运行需要设置环境变量
            ], 
            "args": [
                "/data/local/tmp/mnn-test/Qwen3-4B-Instruct-2507-Eagle3-MNN/llm.mnn",  // 调试参数
                "hello.txt
            ], 
        }
    ]
}

步骤6：编译，并且推送代码和所需的动态链接库。!!注意这里一定要把编译修改为Debug才能运行

# 服务器运行
# 移动到编译目录
cd MNN && cd project/android/build64
# 编译类型为从Release改为Debug
vim ../build_64.sh # -DCMAKE_BUILD_TYPE=Debug \ # 从Release改为Debug
# 编译
../build_64.sh -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DMNN_LOW_MEMORY=true -DMNN_CPU_WEIGHT_DEQUANT_GEMM=true -DMNN_BUILD_LLM=true -DMNN_SUPPORT_TRANSFORMER_FUSE=true

# 推送可执行文件和动态库，需要的动态链接库可以运行测试 缺啥补啥
adb connect 127.0.0.1:30303
adb push llm_demo /data/local/tmp/mnn-test/
adb push /data/HUGGINGFACE/Qwen3-4B-Instruct-2507-Eagle3-MNN/ /data/local/tmp/mnn-test/Qwen3-4B-Instruct-2507-Eagle3-MNN/
adb push libllm.so /data/local/tmp/mnn-test/
adb push libMNN_Express.so /data/local/tmp/mnn-test/
adb push libMNN.so /data/local/tmp/mnn-test/
# 使用launch模式 无法使用标准输入 使用文件方式输入
echo hello > hello.txt && adb push hello.txt /data/local/tmp/mnn-test/ 

# 测试能否运行
adb shell # 进入adb
cd /data/local/tmp/mnn-test/ # 进入目录
export LD_LIBRARY_PATH=/data/local/tmp/mnn-test # 临时设置环境变量
./llm_demo /data/local/tmp/mnn-test/Qwen3-4B-Instruct-2507-Eagle3-MNN/llm.mnn # 运行测试

# 测试如下 输入hello 有输出生成 表示能够编译运行
CPU Group: [ 0  1  2  3  4  5 ],  384000 - 3532800
CPU Group: [ 6  7 ],  1017600 - 4320000
(last_midr & (CPUINFO_ARM_MIDR_IMPLEMENTER_MASK | CPUINFO_ARM_MIDR_PART_MASK))=0x 51000010 in _getInfoArm,  1234 
The device supports: i8sdot:1,  fp16:1,  i8mm: 1,  sve2: 0,  sme2: 0
config path is /data/local/tmp/mnn-test/Qwen3-4B-Instruct-2507-Eagle3-MNN/llm.mnn
main,  267,  cost time: 5396.304199 ms
Prepare for tuning opt Begin
Prepare for tuning opt End
main,  275,  cost time: 475.540009 ms

User: hello

A: Hello! How can I help you today? 😊

# 调试前应该有下面文件
130|RE602CL1:/data/local/tmp/mnn-test $ ls -lah
total 33K
drwxrwxrwx 3 shell shell 3.3K 2026-01-30 15:53 .
drwxrwx--x 7 shell shell 3.3K 2026-01-29 17:18 ..
drwxrwxr-x 3 shell shell 3.3K 2026-01-30 12:34 Qwen3-4B-Instruct-2507-Eagle3-MNN
-rw-rw-rw- 1 shell shell    6 2026-01-30 15:53 hello.txt
-rwxrwxrwx 1 shell shell 2.6M 2026-01-30 12:39 libMNN.so
-rwxrwxrwx 1 shell shell 714K 2026-01-30 12:40 libMNN_Express.so
-rwxrwxrwx 1 shell shell 1.4M 2026-01-30 12:40 libllm.so
-rwxrwxrwx 1 shell shell  28M 2025-10-03 04:45 lldb-server
-rwx------ 1 shell shell  30K 2026-01-30 12:40 llm_demo

步骤7：断点调试（记得把前面测试的lldb进程结束释放端口，这里设置的参数不同断点位置也修改了下）

开始调试后，会通过通信加载大量符号表，然后停在断点处

交叉编译环境，codelldb插件使用的lldb可能与ANDROID_NDK目录下的lldb-server版本不匹配, 但是目前测试暂时没遇到，修改插件使用的lldb可能比较麻烦，包括lldb.library等应该都要修改（前面测试lldb用到的环境变量）

3.3 远程调试（Attach模式尝试失败）

理论上“launch模式不能同步标准输入，改用attach模式可以在adb启动调试进程并通过lldb直接attach到该进程，随后调试程序在adb中应该可以正常进行stdio行为。”但lldb命令行模式可以成功，使用vscode插件测试无法成功。

步骤1：同样的构建lldb与lldb-server链路并且在adb执行lldb-server

步骤2：配置launch.json

{
    "version": "0.2.0", 
    "inputs": [
        {
            "id": "PidAttach", 
            "type": "promptString", 
            "description": "Enter the PID to attach to", 
            "default": ""
        }
    ], 
    "configurations": [
        {
            "name": "Android LLDB Attach", 
            "type": "lldb", 
            "request": "attach", 
            "pid": "${input:PidAttach}", 
            "program": "${workspaceFolder}/project/android/build64/llm_demo",  
            "initCommands": [
                "platform select remote-android", 
                "platform connect connect://127.0.0.1:31313", 
                "settings set target.inherit-env false", 
                "platform settings -w /data/local/tmp/mnn-test", 
                // "platform status", 
                // "platform process list",   // 查看进程列表
                "settings set target.disable-stdio true",  // 禁用lldb的stdio拦截 如果希望使用stdio参数应该也要禁用
            ], 
        }
    ]
}

步骤3：启动调试，先在adb内启动llm_demo

adb shell # 进入adb
cd /data/local/tmp/mnn-test/ # 进入目录
export LD_LIBRARY_PATH=/data/local/tmp/mnn-test # 临时设置环境变量
./llm_demo /data/local/tmp/mnn-test/Qwen3-4B-Instruct-2507-Eagle3-MNN/llm.mnn # 运行测试

然后设置断点开始调试，失败log:

# 另起一个adb发现llm_demo应该成功被attach
RE602CL1:/ $ ps -a                                                                    
USER           PID  PPID        VSZ    RSS WCHAN            ADDR S NAME                
shell         9239  9226    7086452 2820732 ptrace_st+         0 t llm_demo
shell         9243  9221    8732304   6912 do_sys_po+          0 S lldb-server
shell         9246  9243    8697360   7552 do_select           0 S lldb-server
shell         9250  9243    8700968  10536 do_sys_po+          0 S lldb-server
shell         9285  9232    2289024   5864 0                   0 R ps

# 在vscode输出中找到lldb(需要在settings.json中设置"lldb.verboseLogging": true)
# 正常执行命令 并且加载了部分符号表
# 但是调试没有正常开始

vscode log

  Verbose logging: on  (Use "lldb.verboseLogging" setting to change)
  Platform: linux x64
  Initial debug configuration: {
    name: 'Android LLDB Attach', 
    type: 'lldb', 
    request: 'attach', 
    pid: '${input:PidAttach}', 
    program: '${workspaceFolder}/project/android/build64/llm_demo', 
    initCommands: [
      'platform select remote-android', 
      'platform connect connect://127.0.0.1:31313', 
      'settings set target.inherit-env false', 
      'platform settings -w /data/local/tmp/mnn-test', 
      'platform status', 
      'platform process list', 
      'settings show target.disable-stdio', 
      'settings set target.disable-stdio true', 
      'settings show target.disable-stdio', 
      'settings set target.preload-symbols false'
    ], 
    __configurationTarget: 6
  }
  Resolved debug configuration: {
    name: 'Android LLDB Attach', 
    type: 'lldb', 
    request: 'attach', 
    pid: '9239', 
    program: '/workspace/code/MNN/project/android/build64/llm_demo', 
    initCommands: [
      'platform select remote-android', 
      'platform connect connect://127.0.0.1:31313', 
      'settings set target.inherit-env false', 
      'platform settings -w /data/local/tmp/mnn-test', 
      'platform status', 
      'platform process list', 
      'settings show target.disable-stdio', 
      'settings set target.disable-stdio true', 
      'settings show target.disable-stdio', 
      'settings set target.preload-symbols false'
    ], 
    __configurationTarget: 6, 
    relativePathBase: '/workspace/code/MNN', 
    _adapterSettings: {
      displayFormat: 'auto', 
      showDisassembly: 'auto', 
      dereferencePointers: true, 
      suppressMissingSourceFiles: true, 
      evaluationTimeout: 5, 
      consoleMode: 'commands', 
      sourceLanguages: null, 
      scriptConfig: {}, 
      evaluateForHovers: true, 
      commandCompletions: true
    }
  }
  Launching adapter
  liblldb: 
  lldbServer: 
  environment: {}
  settings: { evaluateForHovers: true,  commandCompletions: true }
  [0.10 INFO codelldb] Loaded "/root/.vscode-server/extensions/vadimcn.vscode-lldb-1.12.1/lldb/lib/liblldb.so",  version="lldb version 21.1.7-codelldb"
  [0.376 DEBUG codelldb] Connecting to 127.0.0.1:35049
  [0.376 DEBUG codelldb] New debug session
  [0.402 DEBUG codelldb::python] Compiling code: codelldb.interface.update_adapter_settings("""{"displayFormat":null, "showDisassembly":null, "dereferencePointers":null, "containerSummary":null, "evaluationTimeout":null, "summaryTimeout":null, "suppressMissingSourceFiles":null, "consoleMode":null, "sourceLanguages":null, "scriptConfig":null, "evaluateForHovers":true, "commandCompletions":true}""",  globals())
  [0.402 DEBUG codelldb::python] Created code object at 0x7f6fc0597110
  [0.402 DEBUG codelldb::python] Evaluating code object at 0x7f6fc0597110
  [0.402 DEBUG codelldb::python] Evaluation result: (void) result =

  [0.416 DEBUG codelldb::python] Dropping object at 0x7f6fc0597110
  [0.434 DEBUG codelldb::dap_codec] --> {"command":"initialize", "arguments":{"clientID":"vscode", "clientName":"Visual Studio Code", "adapterID":"lldb", "pathFormat":"path", "linesStartAt1":true, "columnsStartAt1":true, "supportsVariableType":true, "supportsVariablePaging":true, "supportsRunInTerminalRequest":true, "locale":"zh-cn", "supportsProgressReporting":true, "supportsInvalidatedEvent":true, "supportsMemoryReferences":true, "supportsArgsCanBeInterpretedByShell":true, "supportsMemoryEvent":true, "supportsStartDebuggingRequest":true, "supportsANSIStyling":true}, "type":"request", "seq":1}
  [0.435 DEBUG codelldb::dap_codec] <-- {"seq":1, "type":"response", "request_seq":1, "success":true, "command":"initialize", "body":{"exceptionBreakpointFilters":[{"default":true, "filter":"cpp_throw", "label":"C++: on throw", "supportsCondition":true}, {"default":false, "filter":"cpp_catch", "label":"C++: on catch", "supportsCondition":true}], "supportTerminateDebuggee":true, "supportsCancelRequest":true, "supportsClipboardContext":true, "supportsCompletionsRequest":true, "supportsConditionalBreakpoints":true, "supportsConfigurationDoneRequest":true, "supportsDataBreakpointBytes":true, "supportsDataBreakpoints":true, "supportsDelayedStackTraceLoading":true, "supportsDisassembleRequest":true, "supportsEvaluateForHovers":true, "supportsExceptionFilterOptions":true, "supportsExceptionInfoRequest":true, "supportsFunctionBreakpoints":true, "supportsGotoTargetsRequest":true, "supportsHitConditionalBreakpoints":true, "supportsInstructionBreakpoints":true, "supportsLogPoints":true, "supportsModulesRequest":true, "supportsReadMemoryRequest":true, "supportsRestartRequest":true, "supportsSetVariable":true, "supportsStepInTargetsRequest":true, "supportsSteppingGranularity":true, "supportsWriteMemoryRequest":true}}
  [0.479 DEBUG codelldb::dap_codec] --> {"command":"attach", "arguments":{"name":"Android LLDB Attach", "type":"lldb", "request":"attach", "pid":"9239", "program":"/workspace/code/MNN/project/android/build64/llm_demo", "initCommands":["platform select remote-android", "platform connect connect://127.0.0.1:31313", "settings set target.inherit-env false", "platform settings -w /data/local/tmp/mnn-test", "platform status", "platform process list", "settings show target.disable-stdio", "settings set target.disable-stdio true", "settings show target.disable-stdio", "settings set target.preload-symbols false"], "__configurationTarget":6, "relativePathBase":"/workspace/code/MNN", "_adapterSettings":{"displayFormat":"auto", "showDisassembly":"auto", "dereferencePointers":true, "suppressMissingSourceFiles":true, "evaluationTimeout":5, "consoleMode":"commands", "sourceLanguages":null, "scriptConfig":{}, "evaluateForHovers":true, "commandCompletions":true}, "__sessionId":"d48f9fb7-6d82-457d-8328-c1b37b556795"}, "type":"request", "seq":2}
  [0.479 DEBUG codelldb::python] Compiling code: codelldb.interface.update_adapter_settings("""{"displayFormat":"auto", "showDisassembly":"auto", "dereferencePointers":true, "containerSummary":null, "evaluationTimeout":5.0, "summaryTimeout":null, "suppressMissingSourceFiles":true, "consoleMode":"commands", "sourceLanguages":null, "scriptConfig":{}, "evaluateForHovers":true, "commandCompletions":true}""",  globals())
  [0.479 DEBUG codelldb::python] Created code object at 0x7f6fc0597110
  [0.479 DEBUG codelldb::python] Evaluating code object at 0x7f6fc0597110
  [0.479 DEBUG codelldb::python] Evaluation result: (void) result =

  [0.480 DEBUG codelldb::python] Dropping object at 0x7f6fc0597110
  [0.480 DEBUG codelldb::dap_codec] <-- {"seq":2, "type":"event", "event":"output", "body":{"category":"console", "output":"Console is in 'commands' mode,  prefix expressions with '?'.\n"}}
  [0.480 DEBUG codelldb::dap_codec] <-- {"seq":3, "type":"event", "event":"output", "body":{"category":"console", "output":"Executing script: initCommands\n"}}
  [0.480 DEBUG codelldb::debug_session] platform select remote-android -> SuccessFinishResult,  Error:  Success
  Output Message:
    Platform: remote-android
   Connected: no

  [0.480 DEBUG codelldb::dap_codec] <-- {"seq":4, "type":"event", "event":"output", "body":{"category":"console", "output":"  Platform: remote-android\n Connected: no\n\n"}}
  [1.37 DEBUG codelldb::debug_session] platform connect connect://127.0.0.1:31313 -> SuccessFinishResult,  Error:  Success
  Output Message:
    Platform: remote-android
      Triple: aarch64-unknown-linux-android
  OS Version: 35 (6.6.30-android15-8-g013ec21bba94-abogki383916444-4k)
    Hostname: localhost
   Connected: yes
  WorkingDir: /data/local/tmp/mnn-test
      Kernel: #1 SMP PREEMPT Tue Dec 17 23:36:49 UTC 2024

  [1.37 DEBUG codelldb::dap_codec] <-- {"seq":5, "type":"event", "event":"output", "body":{"category":"console", "output":"  Platform: remote-android\n    Triple: aarch64-unknown-linux-android\nOS Version: 35 (6.6.30-android15-8-g013ec21bba94-abogki383916444-4k)\n  Hostname: localhost\n Connected: yes\nWorkingDir: /data/local/tmp/mnn-test\n    Kernel: #1 SMP PREEMPT Tue Dec 17 23:36:49 UTC 2024\n\n"}}
  [1.37 DEBUG codelldb::debug_session] settings set target.inherit-env false -> SuccessFinishResult,  Error:  Success
  [1.137 DEBUG codelldb::debug_session] platform settings -w /data/local/tmp/mnn-test -> SuccessFinishNoResult,  Error:  Success
  [1.233 DEBUG codelldb::debug_session] platform status -> SuccessFinishResult,  Error:  Success
  Output Message:
    Platform: remote-android
      Triple: aarch64-unknown-linux-android
  OS Version: 35 (6.6.30-android15-8-g013ec21bba94-abogki383916444-4k)
    Hostname: localhost
   Connected: yes
  WorkingDir: /data/local/tmp/mnn-test
      Kernel: #1 SMP PREEMPT Tue Dec 17 23:36:49 UTC 2024

  [1.234 DEBUG codelldb::dap_codec] <-- {"seq":6, "type":"event", "event":"output", "body":{"category":"console", "output":"  Platform: remote-android\n    Triple: aarch64-unknown-linux-android\nOS Version: 35 (6.6.30-android15-8-g013ec21bba94-abogki383916444-4k)\n  Hostname: localhost\n Connected: yes\nWorkingDir: /data/local/tmp/mnn-test\n    Kernel: #1 SMP PREEMPT Tue Dec 17 23:36:49 UTC 2024\n\n"}}
  [1.947 DEBUG codelldb::debug_session] platform process list -> SuccessFinishNoResult,  Error:  Success
  Output Message:
  6 matching processes were found on "remote-android"

  PID    PARENT USER       TRIPLE                         NAME
  ====== ====== ========== ============================== ============================
  3264   1      shell                                     
  9221   3264   shell      aarch64-unknown-linux-android  sh
  9226   3264   shell      aarch64-unknown-linux-android  sh
  9232   3264   shell      aarch64-unknown-linux-android  sh
  9239   9226   shell      aarch64-unknown-linux-android  llm_demo
  10599  9221   shell      aarch64-unknown-linux-android  lldb-server

  [1.947 DEBUG codelldb::debug_session] settings show target.disable-stdio -> SuccessFinishResult,  Error:  Success
  Output Message:
  target.disable-stdio (boolean) = false

  [1.947 DEBUG codelldb::dap_codec] <-- {"seq":7, "type":"event", "event":"output", "body":{"category":"console", "output":"6 matching processes were found on remote-android\n\nPID    PARENT USER       TRIPLE                         NAME\n====== ====== ========== ============================== ============================\n3264   1      shell                                     \n9221   3264   shell      aarch64-unknown-linux-android  sh\n9226   3264   shell      aarch64-unknown-linux-android  sh\n9232   3264   shell      aarch64-unknown-linux-android  sh\n9239   9226   shell      aarch64-unknown-linux-android  llm_demo\n10599  9221   shell      aarch64-unknown-linux-android  lldb-server\n\n"}}
  [1.947 DEBUG codelldb::debug_session] settings set target.disable-stdio true -> SuccessFinishResult,  Error:  Success
  [1.947 DEBUG codelldb::debug_session] settings show target.disable-stdio -> SuccessFinishResult,  Error:  Success
  Output Message:
  target.disable-stdio (boolean) = true

  [1.947 DEBUG codelldb::debug_session] settings set target.preload-symbols false -> SuccessFinishResult,  Error:  Success
  [1.947 DEBUG codelldb::dap_codec] <-- {"seq":8, "type":"event", "event":"output", "body":{"category":"console", "output":"target.disable-stdio (boolean) = false\n\n"}}
  [1.947 DEBUG codelldb::dap_codec] <-- {"seq":9, "type":"event", "event":"output", "body":{"category":"console", "output":"target.disable-stdio (boolean) = true\n\n"}}
  INFO(Python) 13:09:06 lang_support: languages: set()
  [2.51 DEBUG codelldb::dap_codec] <-- {"seq":10, "type":"event", "event":"initialized"}
  [2.94 DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints", "arguments":{"source":{"name":"llm_demo.cpp", "path":"/workspace/code/MNN/transformers/llm/engine/demo/llm_demo.cpp"}, "lines":[197, 246, 265, 301], "breakpoints":[{"line":197}, {"line":246}, {"line":265}, {"line":301}], "sourceModified":false}, "type":"request", "seq":3}
  [2.104 DEBUG codelldb::debug_session] Debug event: 0x55938b1e6058 Event: broadcaster = 0x55938b1cafb0 (lldb.target),  type = 0x00000001 (breakpoint-changed),  data = {bkpt: 1 type: breakpoint added}
  [2.104 DEBUG codelldb::debug_session] Debug event: 0x55938bbb0cd8 Event: broadcaster = 0x55938b1cafb0 (lldb.target),  type = 0x00000001 (breakpoint-changed),  data = {bkpt: 2 type: breakpoint added}
  [2.104 DEBUG codelldb::dap_codec] <-- {"seq":11, "type":"response", "request_seq":3, "success":true, "command":"setBreakpoints", "body":{"breakpoints":[{"id":1, "line":198, "message":"Resolved locations: 0", "verified":true}, {"id":2, "line":246, "message":"Resolved locations: 0", "verified":true}, {"id":3, "line":265, "message":"Resolved locations: 0", "verified":true}, {"id":4, "line":301, "message":"Resolved locations: 0", "verified":true}]}}
  [2.104 DEBUG codelldb::debug_session] Debug event: 0x55938be74b38 Event: broadcaster = 0x55938b1cafb0 (lldb.target),  type = 0x00000001 (breakpoint-changed),  data = {bkpt: 3 type: breakpoint added}
  [2.104 DEBUG codelldb::debug_session] Debug event: 0x55938be759d8 Event: broadcaster = 0x55938b1cafb0 (lldb.target),  type = 0x00000001 (breakpoint-changed),  data = {bkpt: 4 type: breakpoint added}
  [2.104 DEBUG codelldb::dap_codec] --> {"command":"setFunctionBreakpoints", "arguments":{"breakpoints":[]}, "type":"request", "seq":4}
  [2.104 DEBUG codelldb::dap_codec] --> {"command":"setInstructionBreakpoints", "arguments":{"breakpoints":[]}, "type":"request", "seq":5}
  [2.104 DEBUG codelldb::dap_codec] --> {"command":"setExceptionBreakpoints", "arguments":{"filters":[], "filterOptions":[{"filterId":"cpp_throw"}, {"filterId":"cpp_catch"}]}, "type":"request", "seq":6}
  [2.104 DEBUG codelldb::dap_codec] --> {"command":"setDataBreakpoints", "arguments":{"breakpoints":[]}, "type":"request", "seq":7}
  [2.104 DEBUG codelldb::dap_codec] <-- {"seq":12, "type":"response", "request_seq":4, "success":true, "command":"setFunctionBreakpoints", "body":{"breakpoints":[]}}
  [2.104 DEBUG codelldb::dap_codec] <-- {"seq":13, "type":"response", "request_seq":5, "success":true, "command":"setInstructionBreakpoints", "body":{"breakpoints":[]}}
  [2.104 DEBUG codelldb::debug_session] Debug event: 0x55938be759d8 Event: broadcaster = 0x55938b1cafb0 (lldb.target),  type = 0x00000001 (breakpoint-changed),  data = {bkpt: 5 type: breakpoint added}
  [2.104 DEBUG codelldb::debug_session] Debug event: 0x55938be74b38 Event: broadcaster = 0x55938b1cafb0 (lldb.target),  type = 0x00000001 (breakpoint-changed),  data = {bkpt: 6 type: breakpoint added}
  [2.104 DEBUG codelldb::dap_codec] <-- {"seq":14, "type":"response", "request_seq":6, "success":true, "command":"setExceptionBreakpoints", "body":{"breakpoints":[{"id":5, "message":"Resolved locations: 0", "verified":false}, {"id":6, "message":"Resolved locations: 0", "verified":false}]}}
  [2.104 DEBUG codelldb::dap_codec] <-- {"seq":15, "type":"response", "request_seq":7, "success":true, "command":"setDataBreakpoints", "body":{"breakpoints":[]}}
  [2.208 DEBUG codelldb::dap_codec] --> {"command":"configurationDone", "type":"request", "seq":8}
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/8C68F140-AAA2-F707-F730-F2EE4E510120/libandroidfw.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/47A4DF2E-C980-CA7B-EE2C-5162D1311A67/libpowermanager.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/9DF5DFA7-C0A9-BEE1-18E8-59821ACCE119/libhidlbase.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/B91287F0-90CF-9F69-4DDD-2F1A515321DD/libandroid_runtime.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/59856B9D-1F82-D3A6-C71D-66834CA846B9/libGLESv2.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F4D570AA-256C-18CF-EA9D-AE414A89DA7D/libm.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/E5A3DA1A-4375-273B-68D0-BD446CDE5B09/libPlatformProperties.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/DE46E75F-F2ED-1E2C-471D-4636BABCB461/libgralloctypes.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/59EDC081-6CC9-8412-738C-D7D9FD088A51/android.hardware.graphics.bufferqueue@2.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F7541D18-8FBA-9039-6D97-EC2354A99C0C/libandroid.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/B18C8A03-80E8-9331-80E2-E5D0A8F17968/libhardware.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/236EA1BC-94E0-AFD5-BC7F-F1431CE6E873/libui.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/9C5275F2-9E5F-BCAB-CA91-F471539F6C33/libharfbuzz_ng.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/49F04F9F-4BAB-7644-EBE0-CD12D5CBA422/android.media.audiopolicy-aconfig-cc.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F643E105-5895-E50E-6646-2991C8BD651A/libsensor.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D4EFBE1C-EE05-5ADB-7BC0-6563275B325A/libactivitymanager_aidl.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F4788000-0CAD-34AE-85A3-A6D6EB47AF56/libnetd_client.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/E9F6E11C-F330-D7B5-DA0A-E574B08DE2BF/libappfuse.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/1ABE5FF0-44ED-C7D5-EDEC-7513BEFDFB08/libhwui.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/6616E752-0D49-82C8-B16F-490C2FCE7B07/libxml2.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D7BFEF10-7332-8147-237F-DCD213DDB0F4/libEGL.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/5A4C3962-7C1C-0C27-B85E-2B07FF8406E8/android.hardware.configstore@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/5794558E-3A70-DE27-7ACE-8D96CC135A6E/libprocessgroup.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/E53513AD-07B9-A2D3-8E10-BB9640873A51/android.os.flags-aconfig-cc.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/17FB6C42-A328-8C80-F6B1-2E8DCE44BA87/android.hardware.common.fmq-V1-ndk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/BCF22BAF-8100-0E78-7DBF-DA0634CDCAE3/libdng_sdk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/53E0091D-25A7-8880-2D2D-3A5324F79B52-7DF4913F/libc++.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F813C105-4BF3-8946-F3DD-ACFA5A0F5D92/libaconfig_storage_read_api_cc.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D2388CD6-B4A2-3C03-AAC6-A43F69DBE3E7/libprotobuf-cpp-lite.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F51A883E-B8A3-E395-D776-028AAFD911B2/libincfs.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/1D37DF90-6550-A769-0656-A118D5D3E48C/libtinyxml2.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/71BEA50E-B26B-2551-6A93-71624A6F6C48/libapexsupport.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/75F07E30-8942-51A2-09D9-EFD05765443E/libcutils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/ACCECA4F-7FDF-AAB5-8CA4-D22F02EFCFA2/android.hardware.graphics.allocator@2.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/268C25BF-EE33-DEFE-E41F-04FA65438E3F/android.hardware.graphics.mapper@3.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/7249C1EE-880D-5DC5-6D20-218B90D0EE70/liblog.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D1D3BF8F-E6FE-CD69-21AC-714B5EF42E28/libutils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/FD865493-6014-8D9B-9146-148D898ACE8B/android.hardware.graphics.bufferqueue@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/4FC00C98-6358-5F87-0F76-2CDD96F8D6FE/android.hardware.graphics.common@1.1.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D6FD5669-9855-0295-6CD6-3C15A6BA2463/libnativewindow.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F100ABB4-5F8D-9443-385E-41FAA8C60894/libbinder_ndk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/10880913-0278-27E8-B7B9-E2B0073332E6/libpermission.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/E7298183-6700-D01A-9E07-A7EFE0463AB4/libgui.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D3BDEF9F-76E0-0746-698A-FDB95AFBC4E3/android.hardware.configstore@1.1.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/65F76722-B6BA-9085-2F32-C65B2917B63B/android.media.audio.common.types-V4-cpp.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/622B1765-4662-9AB1-9F5E-C1DFBBC18E6A/av-types-aidl-cpp.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/AE1416DE-9C2C-8E2A-03B1-9B4A77B111D1/libandroid_net.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/92739A8D-5622-5793-8128-28A5C6293AF2/libminikin.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/6A5F8F94-CFE5-65DC-C001-95D7A3CA9602/libdebuggerd_client.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/FB11B3F2-0030-F996-41AD-EBC1949142B6/libsqlite.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D33A3544-5B95-B61F-40F2-1B097B982B2E/android.hardware.configstore-utils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/93CCDE3F-366F-7E38-3EC0-899B87F4C45F/libselinux.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/89BD714E-5DEF-C9AE-88C7-2982F3EF3AC8/libnativeloader_lazy.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D4B2FFC5-F138-6CF1-32E1-2AB8C6DCFB37/liboplusplugin.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/3E69A5D9-5456-0A62-90D7-0565B0B436B0/libultrahdr.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/90259EF0-41B0-1885-8D40-258E8170B217/aconfig_text_flags_c_lib.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/070EE97F-074D-C13F-D642-DC3627F7CE57/libz.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D89F718A-0F70-5B6B-21A7-444F4CB496F3/libheif.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/EEA2E831-DF57-26D5-5A9E-100BA0E291AF/libft2.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/6E0FBED8-8045-2E8A-276A-ED99974D2903/lib-platform-compat-native-api.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/7926FF37-5B46-6646-59D5-04CBC606B997/libpackagelistparser.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F05BB986-1975-74CF-310A-A7F2244D981F/android.hardware.power@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/217D4A46-760A-940D-FED2-1538F547262D/libbinder.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/B8FA905C-387B-6EC6-2B8C-29E3B0D5E1C1/android.hardware.power@1.1.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/E1E52A3B-FD01-7616-6655-977ED25478CF/android.hardware.power@1.2.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/48EDFCD7-4765-28A8-2472-D6BA77AA16C1/android.hardware.power@1.3.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/7F0888CC-ACBD-22DC-6197-E024D61DB019/com.android.media.audioclient-aconfig-cc.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/27AA0829-9412-F262-58C6-9E6226585DEA/android.hardware.graphics.common@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D1234763-4E7A-21ED-F65D-AE44CB959CDB/libaudiomanager.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/5A118426-37D9-7B8C-323D-5ACA6BB7AA92/android.hidl.token@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/4EB1AD8B-2324-C684-BF89-FDBAA325836A/framework-permission-aidl-cpp.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/22F4901A-3743-4C39-8C4E-5F0BEA118079/effect-aidl-cpp.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/5B965CF4-265D-81F2-1F99-DA9B6B0EBF34/shared-file-region-aidl-cpp.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/68D733EC-E14A-6DDF-08A5-0C37D3EE00E8/android.hardware.camera.common@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F891BE37-E405-66BF-2B9B-8C8C5474A680/android.hardware.memtrack@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/4D0532B3-F1D1-B4FC-ED69-FC5BD7A829BC/android.hardware.memtrack-V1-ndk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/CE04558B-0A23-351D-CADD-5E511B6B8953/libETC1.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/BC2C7F87-8C6B-0064-210F-D4977F2C66F0/libandroid_runtime_lazy.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/4B758857-1C68-D480-E403-0D92344242F7/libcgrouprc.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/A8BBDFEA-E174-30B5-7E6A-5BABCBA908B1/libbpf_bcc.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/24CF4CEC-1D73-44C8-ED75-5884E4953E22/libdatasource.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/4D599915-9EC2-D153-B954-35161286B527/libmediadrm.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/8A8683E2-3717-CC18-680C-E0EFE97EAA96/libmedia_omx.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/A96DAF57-6898-C714-C5EC-DC88B80C294B/libmedia_jni_utils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/4E0635FF-666C-8B48-8CCF-5566C7FDBD40/libstagefright.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/EEBAA949-2A40-455A-8475-F7E9A76F87D2/libstagefright_foundation.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/3C0DB02C-271B-A2E2-CC7B-63E904E5638E/libmediandk_utils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F1D853BA-297B-CA2A-3014-65C02F8CF647/android.hardware.drm-V1-ndk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D7E60A1B-02A0-A89D-5AB7-E1883A8B5067/libSurfaceFlingerProp.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/0C7C0800-AF68-65E6-4893-CE47B8AB6DA3/camera_platform_flags_c_lib.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/4E788058-CF19-E541-C41C-22663B333A4D/libunwindstack.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/3B0FA744-EEA5-F951-8170-DE832FD9F1CE/libziparchive.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/FCDD8634-77D9-C35A-04F7-E46E76ADF01C/libpcre2.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/CFB68FE0-E192-4651-97FC-C0D3F944F7A0/libmedia_codeclist.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/1EC03020-A00F-FCAD-59B4-6CDF97537D05/liboplusremotedisplay.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/CEAF7077-8476-ED6E-BBBB-10D160D6BD60/liboplusremotedisplayclient.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/1F7EED6E-4DD5-6CBB-45B6-E89615257E9D/android.hardware.drm@1.4.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/2158C75E-4988-C285-1896-357F99993475/android.hardware.media.omx@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/AC68D018-F02B-14CC-1B51-F5E83226129C/capture_state_listener-aidl-cpp.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/01DF55F6-1428-95DC-DBAA-4FE0203DE907/libaudio_aidl_conversion_common_cpp.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/63A840F8-69D6-5DFC-BD42-B430C2F559F9/libcodec2.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/75FC895D-0EDC-4A29-C95B-D983A003758F/libaudioutils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F4EB4AAA-F8B1-F58E-6040-561179D5E38E/libmedia_omx_client.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F8CCC3F7-ABD2-6816-EE77-C2BBBC1EF11F/libnblog.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F4D585C7-43F3-C29F-70F0-60B139280236/libshmemcompat.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/BC87EF18-DF8F-7AA9-77EE-59BE3A33D4BD/libcamera_metadata.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/8D5546FC-C984-4C53-AE4D-A68376649C07/packagemanager_aidl-cpp.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/3BC123B3-2E0D-1DA2-4608-CBE1EFDFEDF3/liboplusmmdebug.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/8C6E0D1F-F75D-74B0-94BC-781C562A7092/libnativedisplay.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/52C82393-C710-2821-9339-0A5C5CE8BF91/libbpf_minimal.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F862C6CB-6B56-928F-7B24-D2A3B49ADA5E/liboplusloadframe.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/364C8677-368A-1BA8-E6F8-CBCBF5B8FF74/libjpegencoder.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/61F0425A-F9C9-47CE-4E65-7AC31E7BAAC8/android.hardware.media.bufferpool@2.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/9B34299E-EB2E-93CF-3C80-9A6B855ABDC5/liblzma.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/BC304671-6DBD-7AFD-44CB-44531D3F3C53/libmediadrmmetrics_lite.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/C1BED4E7-F50E-454B-3115-B12789484E9C/android.hardware.drm@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/16EE5061-D6A1-1B5D-3C3A-58B595FE99E1/android.hardware.drm@1.1.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/59C7A5B8-100F-C786-A237-534275FFF031/vendor.dolby.dvs-V1-ndk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D8133337-22F8-4E5C-FC7E-81580D92885D/android.system.suspend-V1-ndk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D0870D5B-92DD-9BD8-990C-2A6C5D189A33/android.hardware.drm@1.2.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/6576446C-95B5-8FC8-12D0-19864EAF1A6E/libcodec2_client.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/56EE6975-54BD-8AF9-256B-E8F25D7B5093/android.hardware.drm@1.3.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/773E4036-29F6-0510-7FE9-D09F3ACBFC17/mediametricsservice-aidl-cpp.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/B13CB8E9-12AE-139B-DFD0-F590ADC67617/libhidlallocatorutils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/42F83B19-A621-BCAE-5536-880C786C936D/audiopolicy-aidl-cpp.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/8571E439-E7CC-207A-B9E8-3981166AA953/android.hidl.memory@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/C62C6178-578C-7D26-455F-B1F590F8624C/android.hardware.cas@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/94E17DA2-D20D-C000-3672-D0C4933C9BF3/libcodec2_vndk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/470D87DF-0FBB-48DE-058A-BF31ED48D4BA/libcodec2_hal_common.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/090FF4C1-571A-EF9F-4679-C5600FF8886B/libsfplugin_ccodec.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/A11669AA-BD01-1D70-2046-55568F4BC3B6/libsfplugin_ccodec_utils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/39D4A1F6-8339-7BE8-174D-C8C26569B3D3/libstagefright_codecbase.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D488A480-3BB5-3EAF-655D-4B4D6793C0A9/libstagefright_omx_utils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/5141AA36-4CA6-DEB3-0E83-899F3A211574/libhidlmemory.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/C85E596D-528C-8413-61FD-1543C6A468A4/android.hidl.allocator@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/4FDA2AC3-923D-7AFB-EA12-7D310D09CC33/android.hardware.cas.native@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/45386C91-5C0E-7873-D765-C358266F5F5B/aconfig_mediacodec_flags_c_lib.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/6CF112A3-E61A-25C9-DF8C-4B0C67589CF7/libspeexresampler.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/C7F41251-6A79-5DC6-5A07-3BF6241A7C9C/com.android.media.audio-aconfig-cc.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F9CB190B-FDC3-6AC0-2DFE-AF1A0887DDA2/libjpegdecoder.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/1FA53D37-49E7-8B23-E3B4-20BD59C68B49/libshmemutil.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/30BB277C-5D0B-993A-92A2-FB5C746FE461/libandroidicu.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F6613968-B4EC-FA82-4056-2754492D3640/android.os.flags-aconfig-cc-host.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/05E97885-D5B8-746E-8213-2727CC62D273/android.hardware.media.bufferpool2-V2-ndk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/91696B8B-0757-00FC-B0F2-BFA26B9DCA0C/android.hardware.media.c2-V1-ndk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D69A31D4-3CA9-6A0F-9FF7-695A6AAF01B8/libdmabufheap.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/A608E5AE-1FC9-711B-200A-F2FB29BE6197/libbsproxy.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F7332E1E-E32D-AAD0-791F-F4D8CFC6877D/libstagefright_bufferpool@2.0.1.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/7CF0AFB8-6366-A80A-9D9A-A2350B697FBC/libstagefright_aidl_bufferpool2.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/44DB7622-A843-97FB-D032-22840478D1E4/android.hardware.media.c2@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D471166E-5DD7-A800-8B7E-465E56DD000E/liboplusvideoboostclient.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/26B88FA8-5E98-04BD-532B-C2BA5C3E86B6/libstagefright_bufferqueue_helper.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/62F6DFE5-993D-3537-C5B0-6D67D64BFB3C/libstagefright_graphicbuffersource_aidl.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/E392C887-912B-D578-93AE-F162D3B45C0A/libstagefright_omx.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/FD199BBD-8790-6261-A65B-5208D1BD269F/libstagefright_surface_utils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D15566A0-561C-7926-F6FC-29385CEE8E55/libstagefright_xmlparser.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/C7A683E7-6644-0421-38F2-BA9883A3AC3A/libstagefright_framecapture_utils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/1412FD82-5729-D5FE-9E90-E3DAB35F0785/android.hidl.memory.token@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/29E601BA-E033-65DD-3170-6DD393D601FC/libopluscfgpolicy.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/A051CC35-7764-8479-301A-98F0F8E6766D/android.hardware.media@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F595F888-ADB0-0AEE-048E-C2D74AE8DC79/android.hidl.safe_union@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/36E68CBB-F317-919C-458E-33CC44855754/libmediautils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/3733209E-B9F5-F655-C2A7-5B82D7C640A8/libcodec2_aidl_client.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/B41BE3A5-3B4A-FC6D-DC12-E9C67A361AE2/android.hardware.media.c2@1.1.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/BCED8136-6039-1212-C20A-492C58E80466/android.hardware.media.c2@1.2.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/37E43EAB-0240-B0A8-A9F0-EF72DC2D5B17/libcodec2_hidl_client@1.0.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/B7503E25-16EE-CD1A-8742-9B5B1A01F5BB/libcodec2_hidl_client@1.1.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/DCBAF5C2-CC21-0D9D-BFCD-FDD334B0431D/libcodec2_hidl_client@1.2.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/5C9EE94B-207A-672D-08E7-48164014FB06/libstagefright_httplive.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/977C3587-F5F1-6B11-C61B-35D997D61738/libicu.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/4F4D5F18-A6BE-4344-EA17-DC9DC7411427/libicuuc.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/63DA7563-739E-6B10-0281-6046A3D1FF9D/libatlasservice.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/5BA0567C-E2DB-159D-2FBC-A7A1553C861A/libostatslog.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/44104D0C-22BC-EB23-188C-DC8D9879E00E/libinputextensionsimpl.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/2D06A995-3D42-EDC9-126A-602DEA5F176E/libdrmframeworkcommon.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/C3618A49-D5FE-BCC0-33B1-8F81144623B9/libion.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/5CE798D7-1505-31D7-04C9-931E7E821859/libskjpegencoderextimpl.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/55CC7435-9BEE-63CE-66EF-B7E49A8E25C3/vendor.oplus.hardware.urcc-V1-ndk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/0369ED75-A4C8-871F-CAC0-CA5058B89AF4/graphicbuffersource-aidl-ndk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/7725EFB8-4388-9F2F-AC5E-381796F1A207/libstatssocket.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/4438F18D-386D-940E-CB37-6C59BB81938B/libstatspull.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/3DACF6CB-307A-C2BD-6BC6-41B4705D805E/libaudioclientextimpl.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/8724936D-12B0-0A45-E855-DE82BD2BF9F5/vendor.oplus.hardware.performance-V1-ndk.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/2A91ADBC-2C8D-8343-B339-45A3530E3D97/libiatlasservice.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/FB393EC0-4529-BBE4-7DE1-CDC2B623642A/libimmlistservice.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/80072B39-258E-25AD-482F-BCA4E522757A/liboplusaudioDump.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/145692BC-7B48-FA7D-4DEE-9F3647C9F400/libvibrator.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/86AFE71B-BEDF-86F9-96DD-27031077E951/libmmlistparser.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/2472CDC5-FA7D-3D3C-FBF6-4F6F6CB161FA/liboplusavenhancements.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/7401D122-F709-E469-F346-2FA68B905BB8/libavenhancements.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/0B7AB220-8D7B-1F08-5CC8-36C34FBDA133/liboplusstagefright.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/7EF0AF17-81DE-160C-6E4D-62A930D5CDAD/libmediaplayerservice.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/1883C9A5-0D74-FFBB-8BEB-975550D98460/liboplusmediaplayerservice.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/F33FF539-76AE-26D3-0A5F-7307FE509EEE/liboplusutils.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/4BDDFB25-F00A-C2AA-33E7-F04B4FEAB5DE/liboplussfplugin_ccodec.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/0D38A646-14CF-FFED-7FDC-57868CBD5B7C/audio-permission-aidl-cpp.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/6150C4DB-DC98-5D10-3D67-8BFF53218D0B/libnbaio.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/BC19C49B-365B-EC00-D092-32719922C4E7/libicui18n.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/6C75C77B-BF27-8F15-9C20-8538923D24D5/liboplusmultimediaconfig.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/1DDB624D-F713-CBA4-5D72-9CE6CD7B0E43/libdrmframework.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/8BC19754-BC9E-4207-00A5-8416B1FF940F/liboplusvideoboostservice.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/7D4D1F92-679E-170A-1058-DD60CB619122/liboplus_multimedia_kernel_event.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/BE5A17FD-B8C5-DB79-ECCF-C69F19FB4B1B/libstatslog.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/602B6754-2D58-D7AE-C164-2BDE3EB18001/liboplus-uah-client.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/D5C4EBD4-46F8-8579-13D9-E6959D84C26B/liboplus_imageprocessing.so No LZMA support found for reading .gnu_debugdata section
  warning: (aarch64) /root/.lldb/module_cache/remote-android/.cache/B325B13A-EDD2-831A-56E3-75A6A4C9332A/libolc.so No LZMA support found for reading .gnu_debugdata section

3.4 内存错误检测工具

AddressSanitizer（ASan） 是 CMake 构建系统中用于启用内存检测工具，能够高效识别多种难以察觉的内存问题，包括：堆/栈/全局缓冲区溢出、释放后使用（use-after-free）、内存分配/释放不匹配、越界访问等。

开启下面编译选项，在运行时发生内存越界过程程序会立刻停止并且打印报告，帮助更好定位内存问题。

`1`	`-DCMAKE_CXX_FLAGS=-fsanitize=address, -DCMAKE_C_FLAGS=-fsanitize=address`

例如在重新开发CPUAttention算子时，触发的下面内存越界log：

=================================================================
==271723==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61500004ad4f at pc 0x7f65d4c2fabe bp 0x7f65d08f72b0 sp 0x7f65d08f72a8
WRITE of size 16 at 0x61500004ad4f thread T3
    #0 0x7f65d4c2fabd in void _AVX_MNNPackednMatMulRemainCommon<float>(float*,  float const*,  float const*,  unsigned long,  unsigned long const*) /workspace/code/MNN/source/backend/cpu/x86_x64/avxfma/../avx/GemmFunction.hpp:815:9
    #1 0x7f65d4c2cc84 in _AVX_MNNPackedMatMulRemainFMA /workspace/code/MNN/source/backend/cpu/x86_x64/avxfma/GemmAVX2FMA.cpp:58:5
    #2 0x7f65d4772393 in MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_1::operator()(int) const /workspace/code/MNN/source/backend/cpu/CPUAttention.cpp:615:25
    #3 0x7f65d476b03d in void std::__invoke_impl<void,  MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_1&,  int>(std::__invoke_other,  MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_1&,  int&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:61:14
    #4 0x7f65d476af81 in std::enable_if<__and_<std::is_void<void>,  std::__is_invocable<MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_1&,  int> >::value,  void>::type std::__invoke_r<void,  MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_1&,  int>(MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_1&,  int&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:154:7
    #5 0x7f65d476aab1 in std::_Function_handler<void (int),  MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_1>::_M_invoke(std::_Any_data const&,  int&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/std_function.h:290:9
    #6 0x7f65d608b921 in std::function<void (int)>::operator()(int) const /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/std_function.h:590:9
    #7 0x7f65d4778e9f in MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_2::operator()(int) const /workspace/code/MNN/source/backend/cpu/CPUAttention.cpp:757:9
    #8 0x7f65d4778e3d in void std::__invoke_impl<void,  MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_2&,  int>(std::__invoke_other,  MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_2&,  int&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:61:14
    #9 0x7f65d4778d91 in std::enable_if<__and_<std::is_void<void>,  std::__is_invocable<MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_2&,  int> >::value,  void>::type std::__invoke_r<void,  MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_2&,  int>(MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_2&,  int&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:154:7
    #10 0x7f65d4778c81 in std::_Function_handler<void (int),  MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_2>::_M_invoke(std::_Any_data const&,  int&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/std_function.h:290:9
    #11 0x7f65d608b921 in std::function<void (int)>::operator()(int) const /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/std_function.h:590:9
    #12 0x7f65d49c0274 in MNN::ThreadPool::ThreadPool(int)::$_1::operator()() const /workspace/code/MNN/source/backend/cpu/ThreadPool.cpp:63:29
    #13 0x7f65d49bff9c in void std::__invoke_impl<void,  MNN::ThreadPool::ThreadPool(int)::$_1>(std::__invoke_other,  MNN::ThreadPool::ThreadPool(int)::$_1&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:61:14
    #14 0x7f65d49bff2c in std::__invoke_result<MNN::ThreadPool::ThreadPool(int)::$_1>::type std::__invoke<MNN::ThreadPool::ThreadPool(int)::$_1>(MNN::ThreadPool::ThreadPool(int)::$_1&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:96:14
    #15 0x7f65d49bff04 in void std::thread::_Invoker<std::tuple<MNN::ThreadPool::ThreadPool(int)::$_1> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/std_thread.h:259:13
    #16 0x7f65d49bfed4 in std::thread::_Invoker<std::tuple<MNN::ThreadPool::ThreadPool(int)::$_1> >::operator()() /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/std_thread.h:266:11
    #17 0x7f65d49bfdf8 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<MNN::ThreadPool::ThreadPool(int)::$_1> > >::_M_run() /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/std_thread.h:211:13
    #18 0x7f65d3ec8252  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xdc252) (BuildId: e37fe1a879783838de78cbc8c80621fa685d58a2)
    #19 0x7f65d3b50ac2 in start_thread nptl/./nptl/pthread_create.c:442:8
    #20 0x7f65d3be1a03 in __clone misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:100

0x61500004ad4f is located 7 bytes to the right of 456-byte region [0x61500004ab80, 0x61500004ad48)
allocated by thread T0 here:
    #0 0x55656862c61e in malloc (/workspace/code/MNN/build/llm_demo+0xac61e) (BuildId: 5f2185528b18e8c779d7ac797dd7f7b8df7019f2)
    #1 0x7f65d43b126c in MNNMemoryAllocAlign /workspace/code/MNN/source/core/MNNMemoryUtils.cpp:24:30
    #2 0x7f65d4355009 in MNN::DefaultAllocator::onAlloc(unsigned long,  unsigned long) /workspace/code/MNN/source/core/BufferAllocator.cpp:59:25
    #3 0x7f65d4347bfb in MNN::EagerBufferAllocator::alloc(unsigned long,  bool,  unsigned long) /workspace/code/MNN/source/core/BufferAllocator.cpp:223:30
    #4 0x7f65d4787cd4 in MNN::CPUBackend::allocBuffer(unsigned long,  MNN::Tensor*,  MNN::Backend::StorageType) /workspace/code/MNN/source/backend/cpu/CPUBackend.cpp:591:49
    #5 0x7f65d4bc55e9 in MNN::AVX2Backend::onAcquire(MNN::Tensor const*,  MNN::Backend::StorageType) /workspace/code/MNN/source/backend/cpu/x86_x64/AVX2Backend.cpp:344:16
    #6 0x7f65d4340670 in MNN::Backend::onAcquireBuffer(MNN::Tensor const*,  MNN::Backend::StorageType) /workspace/code/MNN/source/core/Backend.cpp:133:22
    #7 0x7f65d47600a6 in MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&) /workspace/code/MNN/source/backend/cpu/CPUAttention.cpp:301:16
    #8 0x7f65d4435b17 in MNN::Pipeline::execute() /workspace/code/MNN/source/core/Pipeline.cpp:1165:40
    #9 0x7f65d449dfb1 in MNN::Session::run() const /workspace/code/MNN/source/core/Session.cpp:249:28
    #10 0x7f65d5413db8 in MNN::Express::StaticModule::_execute() /workspace/code/MNN/express/module/StaticModule.cpp:545:26
    #11 0x7f65d5414580 in MNN::Express::StaticModule::onForward(std::vector<MNN::Express::VARP,  std::allocator<MNN::Express::VARP> > const&) /workspace/code/MNN/express/module/StaticModule.cpp:582:16
    #12 0x7f65d53d95db in MNN::Express::PipelineModule::onForward(std::vector<MNN::Express::VARP,  std::allocator<MNN::Express::VARP> > const&) /workspace/code/MNN/express/module/PipelineModule.cpp:240:57
    #13 0x7f65d53add01 in MNN::Express::NetModule::onForward(std::vector<MNN::Express::VARP,  std::allocator<MNN::Express::VARP> > const&) /workspace/code/MNN/express/module/Module.cpp:224:32
    #14 0x7f65d5dcce5e in MNN::Transformer::Llm::generate(std::vector<std::vector<int,  std::allocator<int> >,  std::allocator<std::vector<int,  std::allocator<int> > > > const&,  int) /workspace/code/MNN/transformers/llm/engine/src/llm.cpp:866:56
    #15 0x7f65d5dd0f52 in MNN::Transformer::Llm::response(std::vector<std::vector<std::pair<std::__cxx11::basic_string<char,  std::char_traits<char>,  std::allocator<char> >,  std::__cxx11::basic_string<char,  std::char_traits<char>,  std::allocator<char> > >,  std::allocator<std::pair<std::__cxx11::basic_string<char,  std::char_traits<char>,  std::allocator<char> >,  std::__cxx11::basic_string<char,  std::char_traits<char>,  std::allocator<char> > > > >,  std::allocator<std::vector<std::pair<std::__cxx11::basic_string<char,  std::char_traits<char>,  std::allocator<char> >,  std::__cxx11::basic_string<char,  std::char_traits<char>,  std::allocator<char> > >,  std::allocator<std::pair<std::__cxx11::basic_string<char,  std::char_traits<char>,  std::allocator<char> >,  std::__cxx11::basic_string<char,  std::char_traits<char>,  std::allocator<char> > > > > > > const&,  std::ostream*,  char const*,  int) /workspace/code/MNN/transformers/llm/engine/src/llm.cpp:1034:5
    #16 0x55656866b0de in chat(MNN::Transformer::Llm*) /workspace/code/MNN/transformers/llm/engine/demo/llm_demo.cpp:284:18
    #17 0x55656866cb2b in main /workspace/code/MNN/transformers/llm/engine/demo/llm_demo.cpp:349:9
    #18 0x7f65d3ae5d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16

Thread T3 created by T0 here:
    #0 0x556568615a9c in __interceptor_pthread_create (/workspace/code/MNN/build/llm_demo+0x95a9c) (BuildId: 5f2185528b18e8c779d7ac797dd7f7b8df7019f2)
    #1 0x7f65d3ec8328 in std::thread::_M_start_thread(std::unique_ptr<std::thread::_State,  std::default_delete<std::thread::_State> >,  void (*)()) (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xdc328) (BuildId: e37fe1a879783838de78cbc8c80621fa685d58a2)
    #2 0x7f65d49bfb50 in void __gnu_cxx::new_allocator<std::thread>::construct<std::thread,  MNN::ThreadPool::ThreadPool(int)::$_1>(std::thread*,  MNN::ThreadPool::ThreadPool(int)::$_1&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/ext/new_allocator.h:162:23
    #3 0x7f65d49bf55c in void std::allocator_traits<std::allocator<std::thread> >::construct<std::thread,  MNN::ThreadPool::ThreadPool(int)::$_1>(std::allocator<std::thread>&,  std::thread*,  MNN::ThreadPool::ThreadPool(int)::$_1&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/alloc_traits.h:516:8
    #4 0x7f65d49bf85d in void std::vector<std::thread,  std::allocator<std::thread> >::_M_realloc_insert<MNN::ThreadPool::ThreadPool(int)::$_1>(__gnu_cxx::__normal_iterator<std::thread*,  std::vector<std::thread,  std::allocator<std::thread> > >,  MNN::ThreadPool::ThreadPool(int)::$_1&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/vector.tcc:449:4
    #5 0x7f65d49b6fbe in void std::vector<std::thread,  std::allocator<std::thread> >::emplace_back<MNN::ThreadPool::ThreadPool(int)::$_1>(MNN::ThreadPool::ThreadPool(int)::$_1&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/vector.tcc:121:4
    #6 0x7f65d49b6703 in MNN::ThreadPool::ThreadPool(int) /workspace/code/MNN/source/backend/cpu/ThreadPool.cpp:58:18
    #7 0x7f65d49b52bf in MNN::ThreadPool::init(int,  unsigned long,  MNN::ThreadPool*&) /workspace/code/MNN/source/backend/cpu/ThreadPool.cpp:26:35
    #8 0x7f65d477d3a7 in MNN::CPURuntime::_resetThreadPool() const /workspace/code/MNN/source/backend/cpu/CPUBackend.cpp:120:25
    #9 0x7f65d477f872 in MNN::CPURuntime::onReset(int,  MNN::BackendConfig const*,  bool) /workspace/code/MNN/source/backend/cpu/CPUBackend.cpp:219:5
    #10 0x7f65d51719f6 in MNN::Express::Executor::_getOrCreateRuntime(MNNForwardType,  MNN::BackendConfig const*,  int,  bool) /workspace/code/MNN/express/Executor.cpp:57:23
    #11 0x7f65d51772d5 in MNN::Express::Executor::RuntimeManager::createRuntimeManager(MNN::ScheduleConfig const&) /workspace/code/MNN/express/Executor.cpp:324:20
    #12 0x7f65d5db9405 in MNN::Transformer::Llm::initRuntime() /workspace/code/MNN/transformers/llm/engine/src/llm.cpp:205:27
    #13 0x7f65d5dbae4e in MNN::Transformer::Llm::load() /workspace/code/MNN/transformers/llm/engine/src/llm.cpp:254:5
    #14 0x55656866ca94 in main /workspace/code/MNN/transformers/llm/engine/demo/llm_demo.cpp:337:25
    #15 0x7f65d3ae5d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /workspace/code/MNN/source/backend/cpu/x86_x64/avxfma/../avx/GemmFunction.hpp:815:9 in void _AVX_MNNPackednMatMulRemainCommon<float>(float*,  float const*,  float const*,  unsigned long,  unsigned long const*)
Shadow bytes around the buggy address:
  0x0c2a80001550: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a80001560: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a80001570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2a80001580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2a80001590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c2a800015a0: 00 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa fa
  0x0c2a800015b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a800015c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2a800015d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2a800015e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2a800015f0: 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==271723==ABORTING

日志大致分为四段：

第一段发生越界写入的位置，也就是log中WRITE of size 16 at 0x61500004ad4f thread T3，根据开发需求在该部分log的调用栈中找到出现内存越界写入位置的代码：

    #2 0x7f65d4772393 in MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&)::$_1::operator()(int) const /workspace/code/MNN/source/backend/cpu/CPUAttention.cpp:615:25

这里发生越界写入位置的是我代码中的这一行

gcore->MNNPackedMatMulRemain((float*)(qkPacked + (loop_e * eP * mPack) * mBytes),  (float*)(qReordered + loop_e * qStride0),  (float*)keyPtr,  remain,  shapeParameters,  nullptr,  nullptr,  nullptr,  nullptr);

往下对应，发现是中间的计算缓冲区内存开小了

第二段被越界写入的内存分配的位置，对应log中的allocated by thread T0 here: 对应日志中可以看到，内存分配位置在算子CPUAttention::onExecute中的第301行，可以根据需求继续顺着调用栈向上或者向下查代码

#7 0x7f65d47600a6 in MNN::CPUAttention::onExecute(std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&,  std::vector<MNN::Tensor*,  std::allocator<MNN::Tensor*> > const&) /workspace/code/MNN/source/backend/cpu/CPUAttention.cpp:301:16

第三段是发生越界写入的线程被启动的位置，MNN中为CPU设计了线程池，根据需求可以查看对应线程的创建日志。
第四段是堆缓冲区溢出的错误报告

远程ADB环境配置

Thu, 26 Feb 2026 23:00:00 +0800

1. 远程ADB环境配置

当开发服务器位于内网、手机在开发者本地时，“编译-传输-测试”、调试比较麻烦。

实际上adb提供了远程连接方式，可以通过端口转发链路，让内网开发服务器直接adb connect本地手机。

本文以将介绍远程ADB环境的配置

1. 远程ADB环境配置

1.1 网络拓扑

现有网络拓扑：本地机器可以通过跳板机连接开发服务器，同时可以连接测试手机

[开发服务器 S,  Server] 
       ▲
       │ (内网，仅J可达)
[跳板机 J,  Jump] ←──┐
       ▲       (Frp穿透)
       |           │
[本地机器 L,  Local] ┘
       │ (adb无线/USB)
       ▼
[测试手机 P,  Phone]

预期网络拓扑：开发服务器可以直接连接测试手机

[开发服务器 S,  Server] 
       │ (内网，仅J可达)
       ▼
[跳板机 J,  Jump] ←──┐
       │       (Frp穿透)
       ▼           │
[本地机器 L,  Local] ┘
       │ (adb无线/USB)
       ▼
[测试手机 P,  Phone]

S (Server)：代码开发服务器，IP为 $ip_S$，端口 $port_S$
J (Jump)：跳板机
L (Local)：开发者本地机器（Windows/Linux/WSL）
P (Phone)：测试手机，已开启ADB over TCP，IP为 $ip_P$，SSH端口 $port_P$

1.2 原理

构建端口转发链路：S($ip_S$: $port_S$) → L($ip_L$: $port_L$) → P($ip_P$: $port_P$)

1.3 本地ADB环境配置

手机端开启ADB网络调试，需要自行安装配置adb， adb介绍

1
2
3

# 通过USB临时连接手机后执行
adb tcpip port_P	# 插入usb连接手机 启动无线adb调试，部分机型可能需要在开发者模式设置允许无线调试
adb connect ip_P:port_P  # 验证无线adb连接，手机的ip可能会随着网络变化，可以在手机设置中搜索ip查看，或者路由器页面查看

这里注意WSL中USB设备需由Windows层接管，需要把USB访问权给WSL，参考文档

1.4 构建服务器->本地转发链路(S->L)

方案1: SSH端口转发

步骤1：服务器S → 本地L（在本地L建立远程端口转发）

# 本地L 执行
# 后面user@ip -p port 是本地L通过ssh连接服务器S的user ip port,  不是需要转发的ip和端口
ssh -N -R 0.0.0.0:port_S:localhost:port_L user@ip -p port 

# 如果本地配置了config,  (参考配置链接: https://zhuanlan.zhihu.com/p/1984208939030684698)
# 假设别名是host_name,  可以修改成下面形式
ssh -N -R 0.0.0.0:port_S:localhost:port_L host_name

# -N: 只用来转发数据
# -R: 反向转发
# 0.0.0.0: 监听跳板机的所有网卡

步骤2：测试链路连通，参考

# 每一步可以通过netcat测试链路连通
# netcat安装: https://www.trae.cn/article/706600706

# 例如: 测试 服务器S → 本地L 连通性
# 服务器 服务器S端口port_S是否已经转发给本地L端口port_L
echo "hello" | nc 127.0.0.1 port_S
# 本地
nc -l -p port_L
# 测试成功本地输出hello

方案2: TailScale/EasyTier隧道 (推荐)

直接用TailScale/EasyTier打通服务器到本地隧道，TailScale会尝试直连打通隧道，打通成功网速不受限于Frp穿透机器，比较推荐。

步骤1：本地L和服务器S分别部署TailScale/EasyTier, TailScale参考tutorial， EasyTier参考tutorial 下面以EasyTier为例，注意EasyTier需要root权限并且docker默认不具备TUN 支持，建议联系集群管理员提供隧道通信方式

本地L安装：从github-relase界面，选择对应版本，如winodws选择easytier-gui_2.5.0_x64-setup.exe 随后手动安装

打开EasyTier, 左下角可以切换中文模式

设置网络名称和密码，然后点击创建新网络，只有网络名和密码匹配才会加入同一个网络，所以网络名设置不要太简单。

滑倒底下运行网络，本地节点就启动了

服务器S节点安装

# 安装
wget -O- https://raw.githubusercontent.com/EasyTier/EasyTier/main/script/install.sh | sudo bash -s install
# 配置，需要和前面一致的网络名和密码,  把下面passwd替换密码
sudo easytier-core -d --network-name test --network-secret "passwd" -p tcp://public.easytier.cn:11010

# 查看节点，这里docker不具备
easytier-cli peer

结果如下，这里的公共服务器可以替换为自己的公网服务器。

ipv4	hostname	cost	lat(ms)	loss	rx	tx	tunnel	NAT	version
$ip_{S1}$	—–	Local	-	-	-	-	-	Symmetric	2.4.5-4c4d172e
	PublicServer_hubei-public.easyti	p2p	9.42	0.0%	82.91 kB	8.78 kB	tcp	Restricted	2.5.0-db059c17~
$ip_{L1}$	—–	relay(2)	18.00	0.0%	0 B	0 B		Symmetric	2.5.0-88a45d11~

在本地的gui界面可以看见两个节点和对应IP, 这里测试的docker不支持TUN所以无法打通，自己搭建需要有docker权限且支持TUN

步骤2：登录TailScale，获取本地L和服务器S分配的ip, 分别记录为$ip_{L1}$ 和$ip_{S1}$。EasyTier直接在界面中获取。
步骤3：建立本地L到服务器S的SSH连接，其余配置一样，只需要修改原来通过SSH连接到服务器S的ip为$ip_{S1}$
步骤4：同[方案1](#方案1: SSH端口转发)，在本地建立到服务器的反向端口转发
注：同理，可以建立服务器到本地的SSH连接，然后在服务器开本地端口转发，ssh转发参考

1.5 构建本地->手机的转发链路(L->P)

1
2

# 本地L执行,  将本地L端口转发至 手机P的adb连接端口
adb forward tcp:port_L tcp:port_P

1.6 测试

# 服务器S执行,  已经将服务器端口port_S转发给手机adb端口
# sudo apt install adb -y 若服务器无adb
adb connect 127.0.0.1:port_S
adb devices # 正常显示连接设备

MNN端侧部署 on huluhuluu

LLM QNN 插件推理流程

LLM QNN 插件推理流程

1. config_qnn.json 配置

2. LLM 生成链路

3. prefill / decode 形状

4. 算子前向

5. resize 阶段

5.1 ShapePlugin

5.2 创建 QNN 算子

5.3 加载 QNN 图

5.4 PluginExecuteRaw::resize()

6. execute 阶段

6.1 重新确认 shapeIndex

6.2 准备输入输出 Tensor

6.3 拷贝输入、执行 QNN、拷回输出

6.4 invokModel()执行入口

6.5 graphExecute() 执行点

7. 小结

LLM QNN 离线导出流程

LLM QNN 离线导出流程

1. 入口参数

2. Step1：生成 IO 样本

3. Step2：切图

3.1 QNN 离线模式

3.2 读取 testdir

3.3 生成候选子图列表

3.3.1 反向收集 op

3.3.2 按 break op 切图

3.3.3 补切动态 shape

3.3.4 计算子图边界

3.4 过滤非卷积子图

3.5 收集子图 IO

3.6 编译并替换 Plugin

3.7 onForward 生成 graph 材料

3.8 合并多 shape

3.9 产物

4. npu_postreat.json 的作用

5. Step3：生成 context binary

5.1 读取后处理配置

5.2 写 QNN context 配置

5.3 生成每个 graph 的 model library

5.4 合成 context binary

5.5 运行时使用 binary

6. Step4：移动产物并写 config_qnn.json

7. 最终目录结构

以 llm_demo 为例的 QNN 后端运行

QNN 后端运行

1. 环境

2. 交叉编译

2.1 交叉编译 llm_demo

2.2 导出 QNN 模型

3. 推送并运行

3.1 推送编译产物、模型和 QNN 依赖

3.2 运行

Eagle 推理流程

Eagle 推理流程

1. Eagle 入口

2. Eagle 配置

3. Eagle 加载

4. Eagle 推理主流程

4.1 首 token

4.2 draft tree 生成

4.3 TokenTree 接口

4.4 tree decoding 验证

4.5 接受token

以 llm_demo 为例的交叉编译与设备运行

交叉编译与设备运行

1. 环境

2. 交叉编译 llm_demo

3. 推送并运行

3.1 推送编译产物和模型

3.2 运行

LLM 加载流程

LLM 加载流程

1. LLM配置

2. LLM加载整体流程

3. Runtime 初始化

4. tokenizer、embedding 和 sampler 初始化

4.1 tokenizer 初始化

1. `config_qnn.json` 配置

3. `prefill` / `decode` 形状

5. `resize` 阶段

5.1 `ShapePlugin`

5.2 创建 `QNN` 算子

5.3 加载 `QNN` 图

5.4 `PluginExecuteRaw::resize()`

6. `execute` 阶段

6.1 重新确认 `shapeIndex`

6.2 准备输入输出 `Tensor`

6.3 拷贝输入、执行 `QNN`、拷回输出

6.4 `invokModel()`执行入口

6.5 `graphExecute()` 执行点

2.1 交叉编译 `llm_demo`

2. 交叉编译 `llm_demo`

5.5 创建`Session`

5.6 创建 `Pipeline`