在 E 系列上使用 llama.cpp 和 千问3.5 运行 OpenCode

发布时间：2026-11-05 14:40:14 来源：服务器搭建前端制作_精准干货整理 作者：焦点

当模型不再只是系行回答提示词，而是列上能够规划、调用工具，使用并持续朝着一个目标推进时，和千边缘AI就变得更加有意思了。问运这正是系行智能体工作负载（agentic workloads）的吸引力所在，也是列上我们探索在Imagination E系列上通过llama.cpp适配千问3.5运行OpenCode的原因。

这篇博客将介绍我们采用的使用方法、为什么这条软件路径是和千切实可行的、我们在过程中做了哪些优化，问运以及为什么E系列GPU非常适合这类工作负载。系行

核心成果：通过这套以性能分析为导向的列上优化流程，我们在6周内实现了20倍的使用性能提升，从最初的和千bring-up阶段，推进到在E系列上运行一个响应速度大幅提升的问运OpenCode + llama.cpp +千问3.5路径。

为什么这个组合是合理的

OpenCode为我们提供了智能体循环（agent loop）。llama.cpp为我们提供了一个实用的推理运行时，拥有成熟的生态、灵活的模型支持，以及通向高效本地执行的路径。千问3.5是一个现代模型系列，适用于编码和助手类用例。E系列则提供了可编程的GPU架构，具备矩阵加速能力，能够在同一平台上处理图形、AI和计算工作负载。

这个组合之所以重要，是因为边缘端的智能体AI不仅仅关乎原始TOPS算力。关键在于让真实的软件栈协同工作，并使其响应足够迅速，以带来切实的实用体验。在我们的案例中，目标是让一个流行的模型在真实的运行环境中运行，并将其与智能体式工作流相连接，而不是孤立地优化一个合成基准测试。

我们的关注点在于实际部署：上层是OpenCode，底层是llama.cpp，模型是千问3.5，计算引擎是E系列。

为什么我们的软件栈让这件事变得简单直接

可编程GPU方案的最大优势之一就是软件灵活性。我们不需要一个定制的、一次性的演示栈。相反，我们基于熟悉的组件进行构建，并通过标准接口将它们连接起来。

哪些因素起到了帮助作用

llama.cpp中的OpenCL后端支持

• 针对优化路径的自定义内核集成
• 对Q4等实用量化模型格式的支持
• 跨运行时和内核层面的性能分析与调优工作流

为什么这很重要

在真实硬件上实现快速bring-up

复用开源工具和模型格式

从“能跑”到“跑得好”有清晰的路径

减少对固定功能软件栈的依赖

整体路径概览

从宏观层面来看，路径很简单：

通过llama.cpp使用OpenCL后端运行千问3.5。

将llama.cpp接入OpenCode，以运行智能体工作流。

对执行进行性能分析，了解时间花在哪里。

优化影响最大的内核和数据搬运模式。

重新测量并迭代。

这正是成熟的GPU软件栈应该能够支持的工作流程。你可以从开源软件出发，使用熟悉的API，然后在最关键的地方逐步添加架构感知的优化。

bring-up过程中我们学到了什么

让大型语言模型（LLM）运行起来只是第一步。要使其高效运行，需要综合理解模型、运行时环境和硬件。

早期，我们研究了千问3.5在llama.cpp中的拓扑结构和行为，包括量化选择以及哪些执行路径回退到了优化程度较低的路径。我们还隔离了工作负载的特定部分，比如decode层，这样就能更快地迭代，而不必每次都运行完整的端到端测试。

这帮助我们区分了三个不同的问题：

模型是否正确运行？

在prefill和decode阶段，哪些操作占主导时间？

这些操作中哪些最值得优先优化？

答案很明确：以矩阵运算为主的工作占据了重要路径的主导地位，而根据阶段和形态的不同，关注和辅助操作也会起到一定作用。这正是E系列能发挥最大作用的地方。

关键观察：prefill和decode的行为不同。Prefill往往由较大的矩阵运算主导，而decode通常对GEMV类工作、内存行为和运行时开销高度敏感。

我们的优化过程

我们将优化视为一个工程循环，而不是猜测练习。性能分析结果会与利用率预期进行对照，以便我们优先处理最有可能产生高影响的工作。

为了找到合适的解决方案，我们综合运用了应用层计时、运行时仪器分析以及针对PowerVR的特定性能分析方法。PVRTune - Imagination Developers工具特别有用，因为它让我们不仅能关注tokens-per-second这一单一指标，还能深入了解在llama.cpp执行预填充和解码过程中GPU的实际使用情况。通过关联命令提交、内核执行时长、硬件利用率、内存活动以及空闲间隔，我们可以判断某个疑似瓶颈究竟是真正的计算瓶颈、受带宽限制，还是仅仅在等待内核之间的协调。

该工作流有助于将性能分析转化为一系列具体的实验方案。PVRTune主要用于识别运行时开销和CPU侧的性能瓶颈，并突出显示启动和调度开销变得显著的情况。我们将这些发现与内核级计数器以及一个可运行的目标模型相结合，从而更详细地了解各个内核的行为和性能。

关键在于将这些工具结合使用。PVRTune给了我们时间线和利用率视图，而更低层级的内核分析和受控的llama.cpp运行帮助确认根因。这防止了我们过度优化视觉上明显但影响很小的内核，并将精力集中在对用户可见响应速度最关键的路径上。

我们主要关注的领域包括：

Matmul改进：针对相关形状引入了更优质的、支持 CMM 并经过调优的矩阵内核。

Flash attention工作：集成和改进OpenCL flash-attention路径，包括围绕softmax和缓冲行为的持续工作。

转换开销：降低f32f16风格转换路径的成本，这些路径的贡献超出了预期。

卷积和归一化内核：针对conv1D和RMSnorm等内核进行了优化，这些优化在可测量的性能提升中发挥了作用。

内存/布局处理：通过试验转置、基于图像的路径、子缓冲区和平铺方案，以提升有效吞吐量。

批处理实验：测试微批处理方案，以更好地将工作负载与硬件匹配

有些改动带来了快速收益。另一些则教会了我们什么不该优先做。在时间有限的优化工作中，这同样重要。

性能提升：最重要的成果是倍数提升：通过在真实应用路径上快速迭代，我们在6周内实现了约20倍的提升，而不仅仅是孤立的微基准改进。

我们看到的优化成果示例包括：

conv1D调优带来了可衡量的token速率提升，并在相关路径中节省了周期。

随着实现的成熟，flash-attention工作在内部测量中显著降低了内核周期数。

在convert和GEMV路径上的额外工作显示出了有前景的改进，尤其是对decode导向的行为。

若干低影响的想法被有意降低优先级，以便精力集中在热点上。

为什么E系列MMA非常适合智能体AI

智能体工作负载很好地说明了为何灵活的矩阵加速至关重要。这些系统不仅仅是在运行一个巨大的离线批处理任务。它们具有交互性，通常对延迟敏感，并且由重复的矩阵运算与控制流、运行时协调以及工具使用相结合而组成。

E系列非常适合这种环境，原因有三。

1.在LLM最需要的地方提供矩阵加速

大语言模型将绝大多数执行时间和内存带宽花在稠密矩阵数学上。E系列包含专用的MMA能力，旨在原生加速这些计算模式，同时支持半精度（FP16、BF16）和低精度格式（INT8、FP8）。在低精度数据类型上运算为边缘部署带来了根本性的低功耗优势：缩小权重和激活的占用空间大幅减少了缓存和内存层级中的内存流量，而这是边缘推理中能耗的主要驱动因素。对于连续的多步智能体循环，这种效率确保了高token吞吐量和持续性能，而不会超出严格的热和功耗预算。

2.可编程路径而非狭窄路径

智能体应用发展迅速。模型在变，量化方案在变，运行时在变，工作流也在变。可编程GPU加上OpenCL软件栈为开发者提供了适应空间，而不必等待固定功能流水线跟上。

3.共享的图形、AI和计算基础

在边缘计算场景中，开发人员通常需要在同一台设备上运行多个工作负载。E系列基于统一的图形、AI和计算架构设计，因此对于需要本地智能处理以及其他交互式工作负载的系统而言，它是一个天然的理想平台。

为什么这对智能体很重要：智能体工作负载能够从这样一个平台中获益——该平台不仅能提供出色的矩阵性能、低摩擦的软件可移植性，还具备随时间推移灵活支持不断变化的模型和工具链的能力。

这对开发者意味着什么

从开发者的角度来看，更大的故事不仅仅是我们用千问3.5在E系列上运行了OpenCode。而是我们使用了一套易于获取的技术栈：

开放的智能体框架，

广泛使用的本地推理运行时，

标准的GPU计算API，以及

在关键之处进行有针对性的架构感知优化。

这降低了实验门槛。团队可以从已知软件开始，快速bring-up一个真实模型，然后逐步调优性能，而不需要从第一天就拥有一套完全定制的技术栈。

优化精力进一步投向何处

我们的性能分析强化了一条在GPU上部署LLM的实用规则：先关注主导性数学运算，然后消除其周围可避免的开销。

在实践中，这意味着：

先改进矩阵内核，再去追逐次要算子，

在基线支持到位后，将注意力机制视为重大机会，

密切关注转换和转置成本，以及

衡量端到端影响，而不是仅信任孤立的内核增益。

最后一点很重要。一个内核在孤立测试中看起来更快，但如果内存行为或编排成本抵消了收益，它仍然无法提升用户可见的tokens per second。通过llama.cpp运行OpenCode的工作之所以有价值，正是因为它让我们始终立足于完整的应用路径。

结语

在E-Series上使用Qwen 3.5通过llama.cpp运行OpenCode，生动地展示了灵活的GPU AI软件栈在实际应用中应具备的形态。我们成功整合了开源软件组件，通过OpenCL将工作负载部署到E-Series上，分析了实际存在的瓶颈，并通过对最耗资源的内核和数据路径进行针对性优化，从而提升了性能。

对于外部受众而言，核心要点很简单：E-Series不仅能够运行现代本地AI工作负载，而且与这些工作负载高度契合。其可编程的软件路径使集成变得简单易行；由MMA支持的计算架构使得针对代理推理中矩阵密集型核心的优化大有裨益；而本研究还表明，通过有针对性的调优，可在短时间内实现20倍的性能提升。

随着边缘AI从单次提示演变为持久化、会使用工具的助手，这种灵活性与加速能力的结合变得越来越重要。我们还计划将开发的优化方案回流到llama.cpp中，以便更广泛的社区能够从这些性能优化中受益，并在各个平台上在此基础上进行扩展。

英文链接：https://blog.imaginationtech.com/running-opencode-with-llama.cpp-and-qwen-3.5-on-e-series

声明：本文为原创文章，转载需注明作者、出处及原文链接。

相关文章