随着大模型技术的发展进入深水区，AI 应用的体验、成本、与隐私性正在成为愈来愈关键的命题。大模型若能直接在终端侧部署，对产业应用毫无疑问有着巨大的吸引力。那么，端侧大模型落地应如何克服庞大的模型尺寸与计算复杂度呢？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请了 蚂蚁集团 xNN 引擎负责人，支付宝多模态应用实验室研究员朱世艾博士 担任主持人，和 北京邮电大学副教授、博士生导师徐梦炜博士、华为 CANN 端侧生态技术专家章武 一起，在  QCon 全球软件开发大会2025 上海站 即将召开之际，交流端侧大模型发展的现状，有哪些实实在在的进展以及未来的机会点。 

部分精彩观点如下：

• 无论在传统 AI 还是大模型时代，实时性、隐私和成本优势都奠定了端侧 AI 的发展基础。尽管与过去相比，大模型的规模和算力需求使端侧落地更具挑战，但随着生成式 AI 的发展，端侧 AI 也应沿着这一趋势不断突破技术瓶颈。
• 大模型将逐步下沉为操作系统的系统级服务，随着其在终端和智能硬件中的作用愈发重要，操作系统也需要适应这种变化。
• 端侧 AI 的优势在于隐私保护和快速响应，云端 AI 则擅长利用大数据和强大算力。结合两者特点，端云协同无疑是理想方案。
• 如果真正想创业、寻求更高上限，仅依赖大模型本身会比较困难。研发大模型当然很重要，但要独立支撑一家公司的发展，还需结合实际场景，如应用开发、智能 Agent、无人机或其他深度垂直领域。

以下内容基于直播速记整理，经 InfoQ 删减。

端侧大模型如何落地？ 

朱世艾：端侧大模型目前的发展现状如何，有哪些实实在在的进展？ 

徐梦炜： 端侧大模型是指将大模型的运行（主要是推理）直接部署在终端设备上，而与之相对的是目前主流的闭源 SOTA 模型通常运行在云端的大型 GPU 集群或数据中心，通过远程请求完成推理，这一过程通常称为 serving。“端侧”的范围很广，从算力较弱的仅有低性能 CPU 的 IoT 设备，到算力中等的智能手机，再到机器人和 PC，只要不是放在远端数据中心或边缘云的设备，都可以称为端侧 AI。

早在二三年前我们团队开始研究端侧大模型时，很多人觉得“模型放在端上”就不算“大”。实际上，大模型并没有统一标准，我个人认为，只要是基于 decoder-only 的、Transformer（包括 attention 或更轻量的 Linear attention），参数规模超过百兆的自回归模型，都可称为大模型。换句话说，只要它是 foundation model，能处理多种任务，经过简单微调即可适应不同下游任务，就可以称为大模型。

为什么要在端侧部署大模型？虽然调用云端 API 很方便，但端侧部署有几方面优势，与传统端侧 AI 类似。首先是隐私。在大模型时代，模型可能利用端上产生的几乎所有数据，包括录音、文本、输入、屏幕点击等，因此隐私问题比以往更为突出。其次，端侧推理可以摆脱网络依赖，提升可用性，即使离线也能运行。同时，它避免了云端 serving 的网络往返延迟（RTT）和批量调度带来的时延问题。如果在端上优化得当，整体延迟可显著降低。最后，从企业角度看，将计算分摊到用户终端，可以减少维护超大 GPU 集群的成本，这也是强有力的商业动机。

在学术界，端侧大模型并不是一个单一领域，而是一个场景下的多学科技术。研究者大致分为三类：一类是算法方向，关注大模型轻量化、剪枝、蒸馏及新架构设计；另一类是软件方向，涉及系统软件、高性能计算、移动或边缘计算，以及嵌入式系统；第三类是硬件体系结构方向，关注电路与加速器设计。在云端领域竞争英伟达很难，但在端侧研究中机会更多。

章武： 我从几个维度谈谈将云端大模型迁移到端侧面临的挑战。首先是内存问题，云端内存几乎可以无限扩展，而手机等终端较大占比的是 8~12GB 内存配置，因此云侧的 BF16 的推理精度在端上无法继承的，需要通过极致量化与压缩来适配有限的内存。其次是精度对齐，云端模型通常无需量化，而端侧必须将 FP32 模型压缩到 4bit 甚至更低，不同厂商对量化算法的支持差异较大，带来了精度对齐难题。此外还有开发适配的成本问题，在云端只需将 PyTorch 工程做部分推理部署优化即可快速上线，而端侧几乎要从零开始，厂商需开发自己的高性能算子来构建推理能力，开发成本远高于云端。

针对这些问题，华为的 CANN 工具链为开发者提供了一套快速在端侧部署 AI 模型的解决方案。首先是量化与内存优化，CANN 工具链提供了 NPU 友好的低比特量化算法，显著降低模型内存占用，使大模型能够运行在手机等终端上。其次是自定义算子能力，由于各厂商的量化算法不同，手机厂商无法逐一适配。CANN 工具链支持 Ascend C 自定义算子开发，例如我们与支付宝合作时，对方希望在 NPU 量化精度能与 CPU 的实现精度一致，支付宝团队通过 Ascend C 实现 NPU 版本的自有算法的 QuantMatmul，最终确保精度一致。同时，Ascend C 算子端云统一，支持一次开发多端部署，大大提高了后续跨平台移植的开发效率。最后是模型泛化支持。CANN 工具链已针对业界主流开源模型（如通义、千问、LLaMA、ChatGLM 等）提供适配方案，并持续优化多模态和 MoE 等大模型场景。

朱世艾：支付宝作为互联网大厂，在实际应用中关注三大优势：实时性、隐私和成本。 

首先，在大模型时代，语音助手、流式识别、实时翻译等交互场景对时延要求越来越高，端侧推理可避免网络传输与云端计算开销，显著提升响应速度。其次，支付宝端侧 AI 的发展源于“新春五福”大促活动带来的流量峰值，当时单靠云端负载难以支撑，这促生了 X 引擎，也奠定了端侧 AI 在支付宝的地位。如今进入大模型时代，计算压力更大，端侧 AI 能有效分担峰值流量和计算成本。第三，个性化推荐和基于用户行为的实时决策常涉及敏感数据。如果在端侧实现这些算法，可以降低数据风险，同时提升用户体验。

因此，无论在传统 AI 还是大模型时代，实时性、隐私和成本优势都奠定了端侧 AI 的发展基础。尽管与过去相比，大模型的规模和算力需求使端侧落地更具挑战，但随着生成式 AI 的发展，端侧 AI 也应沿着这一趋势不断突破技术瓶颈。

朱世艾：从“可用”到“好用”：端侧大模型落地过程中最大的挑战是什么？当前究竟被哪些挑战给‘卡住了脖子’？ 

章武：“将大模型塞进手机里的过程”与“将大象塞进冰箱里”一样困难。我们可以从以下几个维度来谈一谈大模型入端的技术 挑战：

• 放的下： 当前主流的旗舰手机还处在 8~12GB 起步的阶段，所以大模型入端首要解决的问题是内存占用问题。在有限的应 用内存增量（500MB 左右）和必要大模型参数量（0.5~1B），我们必须要提供一些内存瘦身技术将模型尽可能压缩在可控 的范围内，当前 CANN 工具链提供了低 bit 量化，Embeding In Flash 等方案，将模型的实际内存占用控制在参数量内存的 50% 以下。
• 跑的快： 端侧 AI 的核心价值在于隐私保护和低时延，在大模型场景，为了在端侧为开发者提供快速的大模型响应体验，我 们 CANN 提供的亲和量化算法提供了混合 bit 量化能力可以充分利用好 NPU 的算力，同时 CANN 工具链也提供了 Flash Attention、Prompt Cache 等技术进一步优化端侧推理耗时，1B 开源生态左右的模型当前可以做到 1000token/1s 的快速 响应体验。
• 功能泛化： 与云侧统一的 python 生态不同，端侧 AI 当前软件生态没有统一，开发者将大模型从云到端的迁移过程，要完成 从 0 起步的端侧 AI 适配过程，调试工作量较大。CANN 工具链面向业界主流的开源模型做了功能的泛化，当前支持 qwen、 llama、chatglm 等系列开源大模型等，帮助开发者快速完成从 0 到 1 的过程，同时我们也在积极的适配和优化多模态、全模 态、MOE 等新型的大模型技术。我们提供的 ASC 自定义算子编程能力，开发者可以根据业务需要，自行的调整算子计算优 化策略。后续我们会逐步地开放大模型对接解决方案，提供对应的模型样例，指导手册，适配代码 demo 等，帮助开发者 快速的在手机侧集成大模型能力。

徐梦炜： 大模型与操作系统的融合是一个有趣且前景广阔的话题。虽然多数技术人员认可这一趋势，但其进展仍然缓慢，目前缺乏成熟成果，多是对未来的愿景设想。我们认为，大模型将逐步下沉为操作系统的系统级服务，随着其在终端和智能硬件中的作用愈发重要，操作系统也需要适应这种变化。

未来，应用可能逐渐演化为 agent，底层调用大模型，而大模型的功耗与内存占用可能达到 90% 甚至更高，这意味着操作系统需重新定义资源管理。例如，大模型的 KV cache 是否应与 APP 内存采用同一管理方式？若采用统一机制，可能导致 recompute 开销巨大，且系统现有的 Low Memory Killer 策略不适用于这种场景。

资源调度也是挑战。目前 NPU 架构相对简单，缺乏类似 CPU 的灵活调度机制。若未来多应用同时使用 NPU，如何实现隔离、抢占和调度将是新问题。学术界刚开始研究这些课题，而工业界目前更关注如何先把推理性能做好。不过，随着端侧对低功耗和高效率的要求，大模型高度通用的特性将使 NPU 的价值显著提升。

传统 CNN 时代，NPU 因碎片化等问题未被充分利用，许多任务在 GPU 或 CPU 上即可满足性能。但在大模型时代，NPU 的重要性将显著增强。此外，手机厂商与应用厂商的角色与合作模式也会影响生态发展，进而影响技术研究方向与成果转化。

朱世艾：从应用角度看，端侧模型在实际业务中面临的挑战，源于其能力与预期之间的差距。端侧的能力必须限定在“可控范围”内完成任务，主要指带参考的推理任务，例如总结摘要、翻译、自动语音识别，以及 function call、MCP 等工具调用。未来要解决这些问题，仍需要“端—云结合”的方案，这也将成为重要的技术方向。 

从 APP 端视角看，我们还面临一些终端厂商所没有的特殊问题，其中之一是模型的部署与下发。首先，APP 的安装包通常不能太大。然而，即便对模型进行了低比特量化，规模仍可能达到几百兆。如果要将这种体量的模型下发到手机端，即使不考虑其他 APP 的占用，仅就支付宝 APP 本身而言，内存压力也不容忽视。能否在保证用户体验的前提下，实现模型的即时触达、加载和初始化，是一项重要挑战。

对此，支付宝方面正尝试多种方案。首先，与多家终端厂商的思路一致，我们优先通过更低比特量化，尽量缩小模型尺寸。其次，我们将模型参数规模聚焦在 0.5~1.5 亿区间。同时，在终端框架和工程架构上，原本各业务独立调用推理引擎，如今逐步演进为统一的大模型运行时管理框架，类似于“端侧 AI 容器”。

朱世艾：针对这些挑战，目前业界有哪些破局思路和技术方案？ 请分享一些你们正在使用的、或认为最有潜力的技术方案和实战经验。 

徐梦炜： 手机及各类终端的内存容量非常有限，短期内难以实现大幅提升，这会制约端侧大模型的规模。但我认为，我们可以借鉴计算机“金字塔式”存储结构的理念，通过更精细的存储管理来突破限制。计算机从缓存到内存、外存形成分层体系，是基于时间和空间的局部性因此缓存技术才有效。

大模型也存在类似的局部性特征：部分参数被频繁激活，而另一些参数则很少使用。这可能来自训练时的 MoE 结构，其中 attention 参数几乎每次都会激活，而多数 expert 的调用频率较低。即便不是按 MoE 方式训练，标准 Transformer 的激活也呈现冷热分布，有些参数经常活跃，有些则很少。研究还表明，可以通过后处理增强这种稀疏性。

这种稀疏性可以与存储分层结合：把频繁激活的参数常驻内存，而不常用的参数按需加载。如果冷参数数量足够少，或 IO 速度足够快，就能与计算重叠，从而几乎不增加时间开销。

这一思想不仅适用于端侧，在云端或更大型设备上，主存与显存之间的交换也是常用技术。端上利用稀疏性同样重要，这是扩大端侧可运行模型规模的关键途径。量化当然必不可少，但其上限约在 2–4 比特，而稀疏加载仍有潜力，让更大的模型在有限算力上运行。MoE 结构因算力需求较低，天然适合端上芯片。

我们团队一直尝试利用模型稀疏性与存储结构相结合，提升在 NPU 上高效部署模型的能力。虽然看似直接，但实际上在不同 NPU 上优化部署仍然是难题。去年我们发表了一篇 SDOS 论文，介绍在商用手机上实现端到端 NPU 推理的工作，当时使用的是高通芯片。今年也在研究华为平台。高通 2023 年发布的新 SoC 宣称是为生成式 AI 设计，但我们发现其与 Transformer 模型仍存在较大差距，例如缺乏对动态 shape、group-level 量化等的支持。传统 CNN 跑得很好，但大模型在硬件接口层仍有空白。

因此，我们从算法与系统协同设计角度优化，虽不能完全解决，但能缓解部分瓶颈并提升效率。然而，即便经过各种优化，decode 阶段仍常受内存带宽限制，尚未实现理想加速。可以结合投机计算等手段，但系统复杂性也随之增加。总的来说，要想充分榨取硬件潜力，需要算法、系统与硬件的极致协同设计。这是我们在端侧模型部署上关注的两个关键方向。

章武： 我想重点谈性能优化问题，因为端侧与云端的技术路径差异明显。云端算力充足，优化的核心是通过多用户会话实现 Prefill 和 Decode 的分离推理，最大化算力和带宽利用率。而端侧多为单会话场景，Prefill 阶段算力受限，Decode 阶段则受带宽限制，两者需采用不同策略。

在 Prefill 阶段，我们通过减少计算量来缓解算力瓶颈。例如利用 prompt cache 缓存通用 token，避免重复推理；同时结合混合低比特量化、激活量化进一步发挥端侧算力。这些 training-free 技术无需重新训练模型，只需借助工具链简单调优，即可在端上显著提速。此外，部分研究提出基于训练的方法，如用小模型压缩输入 token 数量，进一步缩短 Prefill 推理时间。

对于 Decode 阶段的带宽瓶颈，目前业界的主要方案有两类：一是更低比特的量化，减小权重体积，提高带宽利用率；二是升级硬件，如使用更高规格的 DDR 内存。在固定硬件下，常见方法包括 MoE、投机推理，以及近期热门的 Diffusion LLM 技术，它们将带宽瓶颈转化为算力瓶颈，从而加速 Decode。但这些方法通常与模型训练密切相关，需要厂商与互联网企业合作，而非单靠工具链即可完成，我们也期待出现类似 training-free 的技术来解决带宽问题。

最后是异构架构。目前多 IP 协同往往带来额外调度开销，而大模型通常包含上千个算子，层间频繁切换会显著增加耗可以时。因此，现阶段异构并不能完全提升推理性能，但未来可能出现专门为大模型设计的新型推理架构，这仍是值得业界探索的方向。

朱世艾：我们与华为等厂商在早期合作时，就选择了低比特量化路线，这是与许多通用方案的显著差异。原因在于应用层面的大模型面临两大瓶颈：一是模型物理尺寸过大，影响下载；二是不同手机内存差异大且整体有限，约束了模型运行。因此，我们一开始便采用 2 比特量化，而非从 4 或 8 比特起步。 

2 比特量化涉及多种方案，如线性量化、基于码本的量化等。在探索过程中，我们将推理实现与压缩算法深度融合，既关注模型尺寸和内存占用，又平衡精度损失与实现友好性。例如，针对 2 比特较大的精度损失，我们选用更小的 block size（如 64，甚至 32），而不是常见的 128 或更大值。但更小块也会增加量化参数存储开销，因此我们引入了二级量化（by-level count）来压缩 scale，减少模型物理体积和加载内存。

在量化策略上，我们尝试了 PTQ、training-free 和 QAT 等方案。PTQ 对 4 或 8 比特效果较好，但在 2 比特上表现有限，因此我们最终主要采用 QAT，并将其推广至多模态模型和 ASR 模型。

关于 NPU 的使用，虽然手机每年迭代，但用户更换设备的周期较长，许多存量手机 SoC 并非为大模型推理设计，也缺乏足够的工具链支持。因此我们采用异构推理方案，充分利用 CPU、GPU 和 NPU 的优势。CPU 具备良好的可编程性，GPU 在浮点计算精度上表现出色，而 NPU 则在算力密度和功耗方面更优。我们基于自研量化算法，针对不同 SoC 进行优化。虽然部署复杂度有所增加，但收益明显。

另一方面，直接在模型计算图层面切分任务并不容易，收益可能抵消调度成本，因此我们也探索如 VLM 模型中将前置 ViT 子图下放到 NPU，以减少调度并充分利用硬件计算资源。这些工作需要与硬件生态密切合作，才能将异构方案真正落地到端侧设备。

观众：IoT 采集部分有端侧的案例吗？ 

朱世艾： 车机、智能眼镜和机器人等设备，其实都属于“端侧”范畴。但今天的讨论主题更多聚焦在手机端。当前已有不少 IoT 案例，如各类新势力品牌的汽车，其车载终端往往包含交互场景，许多计算都基于端侧完成；机器人则更典型，它们需要实时动作反馈，因此端侧大模型推理是必不可少的。不过，这些设备的芯片往往可以采用更强大的设计，技术路线与手机或消费电子端侧推理存在显著差异。

端侧大模型的应用与商业化 

朱世艾：哪些场景最有希望率先跑通端侧大模型？商业模式可能是什么样？ 

章武： 从技术角度看，我们的工具链已适配业界主流的第三方模型，并提供详细的部署指导，大幅降低了中小开发者的研发成本。我们的开发网站不仅包含这些大模型样例，还提供计算机视觉、音频、自然语言处理、AIGC 等领域的小模型库，帮助开发者快速找到适合其场景的模型。

这些模型大多经过端侧调优或选型优化，开发者在此基础上训练模型时，只要满足精度要求，就能自然解决端侧部署和性能适配问题。其次，工具链支持 Ascend C 自定义算子功能，开发者可在端侧调试自定义算子，并同步在云侧使用，实现一次开发多端迁移，从而显著提升 AI 研发效率。

此外，工具链还提供丰富的算子和算力调优工具，开发者可借助 Profiling 工具分析性能，调整模型结构，剔除端侧不适用的算子，替换为更优实现，从而快速设计出端侧友好的模型结构，兼顾部署性能与效果。

徐梦炜： 在数字世界，我们近期重点研究 Computer Use Agent，包括 GUI Agent 和 Function Code Agent。这类 Agent 非常个性化，类似私人秘书，会访问大量本地数据或操作手机屏幕，因此隐私价值高，用户往往不愿把这些数据上传云端。尽管目前大家仍关注精度，需要使用最新的大模型，但我认为未来落地时，端侧将是主要方向。在物理世界，具身智能同样需要端侧大模型。一方面是隐私因素，例如设备采集的视频流用户不希望上传云端；另一方面是成本与可用性问题，如无人机在无网络环境下仍需自主决策。

朱世艾：从落地角度看，自去年起，端侧大模型已成为商业化技术方案，终端侧运行已基本成熟。华为、vivo、荣耀、苹果等厂商的新旗舰手机均具备端侧大模型能力，可处理文档、本地搜索、简单问答等任务，还支持相机算法优化和离线 ASR 等场景。Apple Intelligence 也提供了较完整的端侧能力，供开发者和上层应用使用。然而，大规模应用仍有距离，目前主要集中在 APP 中，如支付宝等复杂业务场景。 

在 APP 中应用大模型，需要关注机型覆盖和算力差异。我们不仅要跟进手机迭代速度，还需在技术和算法上优化旧设备的推理能力，这是当前投入较多的方向。今年我们计划在部分小场景做 POC，但要将其发展为终端基础设施，可能还需一到两年。

另一方面，APP 的产品设计对大模型的精度和能力依赖较强，纯端侧难以支撑如支付宝这类复杂场景，因此我们与内部云侧方案合作，同时也与终端厂商和芯片公司探索联合落地。在场景设计中，GUI Agent 是重点方向。对于以 GUI 页面交互为主的 APP，如何利用端侧大模型更便捷地服务用户，是我们端云协同技术方案的核心议题之一。这一方向涉及实时交互、隐私与安全，是端云结合中最容易形成实际应用和商业价值的领域，因此近期我们在这一技术方向上加大了投入。

展望未来 

朱世艾：未来 3-5 年，端侧智能的世界会变成什么样？端 / 边 / 云会如何分工协同？终端设备的形态是否会因大模型而改变？ 

章武： 随着大模型的出现，用户越来越希望在手机中拥有一个“全能秘书”，即 AI Agent，能够随时处理各种事务。这一场景对端侧的本地算力提出了很高要求。然而，由于端侧硬件的发展仍有限，我们认为“端云协同”将成为必然趋势。端侧 AI 的优势在于隐私保护和快速响应，云端 AI 则擅长利用大数据和强大算力。结合两者特点，未来大模型将在多种场景中深度赋能，端云协同无疑是理想方案。

端侧 AI 可作为“神经末梢”，负责大模型的部分 token 计算，以及采集用户情感、偏好与隐私相关数据，经过整合后交由云端“大脑”完成推理决策。云端运行完整的大模型，端侧运行轻量模型，实现从信息采集到推理决策再到快速响应的完整闭环。这种分工既能保证端侧的隐私与实时性，又能发挥云端在大数据和算力方面的优势。

针对端云协同的未来布局，华为提出了一些生态战略。我们计划在年底前完成“看”框架的开源与开放，通过定义统一的计算架构和开放的编程工具链，让开发者可以在端或云中灵活编写与调试算子，并在多端同步部署 AI 推理能力，从而显著提升端云分工下的应用开发效率。

徐梦炜： 未来端和云必然都会运行大模型，但分工不同。云端大模型更接近 AGI，致力于拓展人类知识边界，例如解决数学难题或研究蛋白质结构；端侧则更贴近生产力场景，处理与用户本地数据或上下文相关、需要个性化和隐私保护的任务。高通的白皮书中提到“未来的 AI 是混合式的”，我认为这一定会发生在端与云上。

至于如何协同，最简单也可能最合理的方式是“简单任务在端上处理，复杂任务交由云端”。但这并不容易，因为我们需要判断端侧模型能否正确完成任务，或何时应交由云端处理，这与“幻觉”检测及其边界问题密切相关。因此，端云协同是一个重要课题，值得学术界和工业界持续探索与研究。

朱世艾：大模型的建模方式和业务使用方式的发展，使过去复杂的业务逻辑得到简化。如今，将 AI 融入业务已无需过于繁重的产品设计，交互方式也逐渐统一，例如流式输入输出。产品设计中，我们常首先考虑“大模型能否胜任该功能”。端侧仍是智能化能力的主要入口，这一定位在未来三到五年不会改变。同时，端不仅是入口，还可能成为计算节点，承担部分智能化能力。 

端的形态已不限于手机，还包括车机、机器人、智能眼镜和具身智能设备等，它们都是智能入口。部分设备如眼镜，因功耗、尺寸与佩戴舒适性限制，算力较弱；但其他设备算力正日益增强，未来端将成为应用中的重要计算节点。

端与边缘的协同仍是复杂问题，既与任务复杂度相关，也取决于环境变化。例如，机器人在无网络环境中执行排险任务，或手机在高铁、弱网等环境下，如何保持服务连续性与体验质量？这都需要端侧介入，且方式因应用场景不同而异，尚无统一范式。目前我们希望将部分功能独立部署在端，如离线 ASR 关键词识别或对话中的关键问题识别，同时将简单任务交由端处理。

当然，端侧决策需确保足够准确，而无法面面俱到的任务可交给云侧处理。这是我们正在探索的多种端云协作方式之一，目标是在保证端侧决策可靠性的同时，让云端补充其不足，从而实现更完整高效的系统。

观众：端侧大模型应该从哪个方面入手学习？ 

章武： 端侧大模型的核心在于端侧推理。针对这一方向，我建议首先要读懂 Transformer 库的推理源码，这是理解端侧推理的根本。同时，可以从 llama.cpp 入手，它是一个面向 CPU、GPU 等多种硬件进行入端适配的优秀开源项目，通过参与其中，可以快速了解端侧推理模式，尤其是端侧优化的实现。

通过这些学习，大家能更快理解端侧推理与云侧推理的差异。LLaMA CPP 还提供 2~4bit 等多种量化方案，包括 group 量化，并在设计文档和代码中都有详细实现，同时适配多种硬件平台，这些内容有助于深入理解端侧量化的重要性。

徐梦炜： 从不同角度看端侧大模型也很有价值。门槛其实很高：首先要精通算法，例如 Attention 的数学形式必须熟悉；其次要看得懂 Transformer 库的底层源码，理解其中的数学原理，这是基本功。此外，作为系统方向，还需掌握底层 kernel 的编写，与硬件和高性能优化相关，并能在复杂系统架构中修改代码和调试。

刚才提到的 LLaMA CPP 是经典项目。如果觉得它代码量大、阅读门槛高，可以尝试我们开源的简化版本 MLLM，在 GitHub 搜索即可找到。虽然只有约一千个 star，只是 LLaMA CPP 的零头，但完全国产、代码简洁，便于学习，有问题也欢迎交流。

朱世艾：相较去年，今年从基础模型研发到推理引擎和量化算法，开源社区已更加繁荣。如果大家想投身这一方向，这是非常值得深耕的领域，它能让你全面了解模型从算法到底层实现的细节。此外，端侧与云侧技术并非完全割裂，尽管场景和硬件形态不同，很多技术理念是相通的。对端侧有较深入的理解，也便于转向云侧或其他相关赛道。

朱世艾：对于想投身于此的开发者和初创公司，现在的机会点在哪里？是做模型、做应用、还是做工具？ 

徐梦炜： 大模型更像是一项具体技术，而非完整产品。如果想用它创业，当然有成功案例，尤其在硅谷，资本更看重技术并购，所以只要技术足够优秀就有机会。但在国内，软件创业并不容易，因此更适合将大模型与具体应用场景结合。例如，如果我在大模型上有积累，是否可以考虑把它与制造业、机器人或其他领域相结合？当然，这又涉及如何训练模型、优化推理等一系列问题。

如果真正想创业、寻求更高上限，仅依赖大模型本身会比较困难。研发大模型当然很重要，但要独立支撑一家公司的发展，还需结合实际场景，如应用开发、智能 Agent、无人机或其他深度垂直领域。

朱世艾：无论是做模型、应用还是基础工具，都各有机会。但对普通开发者而言，做应用更容易取得成果。目前生态已相当繁荣，许多开源资源可以直接使用，降低了门槛。此外，许多 OEM 厂商和操作系统未来可能会开放端侧模型推理的 API 或工具链，开发者可以基于这些能力发挥创意，探索更多有趣的应用。这不仅有助于生态繁荣，也更容易取得成功。