演讲嘉宾｜曾书霖 博士
策划｜QCon 全球软件开发大会
AI 2.0 模型对算力和数据的需求激增，导致硬件系统的能耗开销逐渐“供不应求”，亟需软硬协同为 AI 行业提供高质量的 AI 系统能效（ Tokens/J） 。本文整理自无问芯穹总经理曾书霖博士在 2025 年 QCon 全球软件开发大会（上海站） 的演讲 “AI 2.0 时代的大模型推理：从模型到硬件的协同优化”。他介绍了软硬件协同优化以提升智能系统能效的研究成果，包括模型稀疏量化压缩、高效推理系统设计与大模型加速器设计。并且结合华为昇腾集群的工程实践，探讨下一代 AI 推理系统的演进趋势。
预告：将于 4 月 16 - 18 召开的 QCon 北京站设计了「AI 原生基础设施」专题，本专题重点交流探讨如何构建 AI 原生基础设施，包括业界容器 / Serverless 等云原生基础设施如何朝 AI 演进，以及如何利用一些新兴分布式技术构建 AI 原生基础设施等等。敬请关注。
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
各位好，今天我想和大家介绍一下我们无问芯穹在大模型时代围绕大模型推理所开展的一些实践工作，以及我们观察到的一些趋势。我将主要从云和端两个维度展开，并结合我们在华为昇腾集群上进行优化的实践经验进行分享。
在开始之前，我想先简要回顾一下大的背景。我们相信，大家聚集在这里交流今天的工程实践，是因为我们都认同我们正处于一个非常重要的时间节点。通过人工智能，尤其是大模型技术，我们有望对整个产业进行深刻的变革。在大模型时代，最核心的工具是一套大模型算法以及底层的算力芯片，它们共同实现新的劳动价值创造。而我们最核心的任务是通过软硬协同，将上层的算法与底层的芯片通过中间的模型推理软件栈连接起来，以此作为放大 AI 产业价值的关键。这涉及如何在各种芯片和算力集群上进行有效的资源调度，以及如何优化模型在芯片上的推理过程，包括模型压缩、图算融合以及云和端的协同。接下来，我将分别从云和端两个维度详细介绍我们所开展的工作。
以智能革命，引领大模型推理范式变革
快速回顾一下过去十年 AI 发展的一些重要节点。相信各位对大模型的典型发展趋势也十分熟悉，无论是在国内还是国外。推动这些模型不断演进、不断涌现出新的创意结构的核心因素，其实是底层坚实的 AI 基础设施，包括芯片的演进以及整个推理基础设施的演进。
从发展历程来看，2022 年大家还在关注如何制定一个良好的预训练方案。随后，通过 Post-Training 使模型能够更好地适应各种垂直领域以及与人类思维方式对齐。如今，我们已经进入了一个新的阶段，即推理的规模拓展阶段。这一阶段的关键是如何将更优质的模型应用于各种垂直领域场景，以及在长文本和更大规模的推理服务中进行拓展，从而真正实现不同行业的落地应用。
在这一过程中，我们观察到一些重要的趋势。首先是推理范式的变化。从最初的逐 Token 推理，到现在基于 Agent 和强化学习的引入，推理计算需求发生了显著变化。从最初的几倍增长，到现在由于引入了长上下文推理等因素，算力需求已经增长了 10 到 100 倍。这对于从事基础设施建设，尤其是推理优化的我们来说，无疑带来了更大的挑战。
我们探讨模型推理，从产业界的角度来看，未来对算力的需求正逐渐从训练转向推理。今年年初，在 NVIDIA 的 GTC 大会上，黄仁勋也提到，未来我们需要更大规模的集群来支撑大模型在各行业的落地。集群规模越大，优化空间越高，由此带来的企业收益或 AI 应用的效益也会越大。然而，这一切都离不开一套强大的 AI 推理基础设施的支撑。
接下来，我将从几个方面展开分析。首先，我们来看优化的对象。端侧包括手机、PC 等小型设备，而云侧则涵盖一体机和数据中心的集群。我们对应用及其理论性能进行了分析。从端侧来看，现有的手机或 PC 设备在运行本地 3B 或 7B 模型时，推理性能大致在每秒 10 到 20 个 Token 左右，基本能满足正常对话需求。但如今，人们不再满足于单纯的对话，还希望 AI 能处理更复杂的任务，如日程规划、屏幕内容分析等。这些任务所需的 Token 量，随着 Test-Time Scaling 和多模态的发展，相比现有能力存在 1 到 2 个量级的差距。如何弥补这一差距，是端侧需要思考的问题。而在云侧，无论是单台机器还是大规模集群，核心都是要充分释放芯片、存储和互联的能力，尽可能用满集群的算力资源。目前，一些运行 DeepSeek 的推理系统，其实际性能与理论值仍有 2 到 3 倍的差距，这需要我们从基础设施层面去提高利用率，挖掘芯片的每一分潜力。
从实际应用场景来看，端侧和云侧各有特点。端侧主要针对单用户、少请求场景，需要将单个模型、单个用户请求的性能优化到极致。这是一个资源受限的场景，手机和 PC 的功耗、芯片算力、存储和带宽都是有限的。如何选择合适的模型，使其与芯片协同，满足端侧需求，是一个关键问题。云侧则从基础设施角度出发，要考虑多用户、资源抢占以及不同用户上下文、模型和 Agent 场景的差异。这种差异化的访问请求，为云侧优化提供了更大的空间，也带来了不同的优化目标和约束条件。
这些场景背后都绕不开几个核心挑战。如何提升计算利用率，以及如何充分利用存储资源，无论是在笔记本还是集群中，都是关键问题。最近两个月，内存价格几乎翻了一倍，HBM、DRAM 等供应商也在控制产能。随着模型规模增大、上下文变长，存储挑战将越来越大。在端侧，我们还要关注 SOC 的异构调度，包括 CPU、GPU 和 NPU。而在云侧，要在保证每个用户的 SLO 以及低延迟和高吞吐量的前提下，尽可能用满整个集群的资源。
以弹性算力集群，驱动云侧智能升级
我们先回顾一下在云侧进行大模型推理所面临的基本挑战，这些挑战主要集中在计算、存储和调度三个维度。
在计算方面，模型推理中的 Prefill（填充）和 Decode（解码）阶段本身就存在较大差异。Prefill 更倾向于计算密集型任务，而 Decode 则更偏向于访存密集型任务。在存储方面，尽管人们可能天然认为云侧的存储资源是充足的，但我们发现，许多端云推理引擎都存在存储利用率低的问题。这主要是由于 Prefill 和 Decode 对显存的占用不同，以及多用户之间的碎片化导致的。此外，在云侧，调度问题也是不可避免的，包括如何进行虚拟化、如何实现多用户的性能隔离，同时还要尽可能提升资源利用率。这些就是目前我们在云侧大模型推理中所面临的一些挑战。
从 2022 年大模型出现以来，无论是产业界还是学术界，都有一些代表性的工作，从计算、存储、调度等多个不同维度对大模型在云侧的推理服务进行了针对性的优化。今天，我将重点介绍其中一项工作，即围绕 Prefill 和 Decode 分离（P/D 分离）的优化实践。
最初，在进行大模型推理时，我们通常会将 Prefill 和 Decode 请求都放在同一张 GPU 卡或一个 GPU 节点内。在这种情况下，它们需要共享 GPU 的计算资源，同时它们的权重、激活值以及 KV Cache 都存储在 GPU 的 HBM 中。这种融合式场景在早期被广泛采用，包括 Kimi 和 DeepSeek 等项目，都是在 P/D 分离的基础上进行大模型推理的实践。P/D 分离的简单逻辑是将 Prefill 实例和 Decode 实例进行分解，将 Prefill 实例部署在一些算力较高的 GPU 集群上，而将 Decode 实例部署在另一些存储容量大、带宽高的 GPU 集群上。例如，对于 Prefill 实例，我们可以选择算力更强的 GPU 集群；而对于 Decode 实例，我们可以选择像 H20 这样算力稍小但 HBM 容量和带宽较大的集群进行部署。这种方案目前在业界较为常见。
我们分析一下这两种方案各自的优劣势。对于融合式推理方案，它首先面临的是我们在云上进行推理时不可避免的问题，即资源冲突和资源抢占。Prefill 和 Decode 请求本身对计算和存储的需求就不一致。我们之前提到，Prefill 是一个算力密集型任务，而 Decode 是一个访存密集型任务。将它们都放在同一张 GPU 卡或一个节点上，自然会面临由于需求不同导致的延时干扰和计算资源分配不均的问题。在这种情况下，想要对它们进行细粒度的调控是非常困难的。然而，这种融合式方案也有它的优势，即将存储融合在一起，无需进行 KV Cache 之间的传输，相应地，存储管理的实现会更加简单。
再来看 P/D 分离的方式，它的核心优势在于解决了融合式方案中 Prefill 和 Decode 计算资源抢占的问题。将 Prefill 和 Decode 拆开后，可以根据它们各自对计算和存储的需求进行针对性的管理。如果 Prefill 实例对计算的要求比较一致，它们的行为和模式就更容易预测，因此在资源调度上可以采用更粗粒度、更可预测的方式进行管理，Decode 实例也是如此。此外，P/D 分离还可以更好地进行资源配比。然而，这种方式也引入了一些新的问题。首先，它对存储的开销和切换会带来额外的挑战。例如，P/D 分离后，P 实例和 D 实例之间的 KV Cache 存储非常不均衡。在 P 实例上，可能只有 23% 的存储用于 KV Cache，而在 Decode 实例上，可能有 70% 的存储开销都用于存储 KV Cache。这就导致 P 实例和 D 实例之间需要频繁进行 KV Cache 的传输，这就要求 GPU 之间以及节点之间的互联带宽需要更大，同时需要对通信库进行更底层的优化支持。此外，由于 P 实例和 D 实例之间存储的不均衡，在进行内存管理时，P 实例上可能会出现显存浪费的情况。例如，除了存储权重和 KV Cache 之外，可能有 30% 到 40% 的显存无法被充分利用，这些未被利用的显存会导致整个集群出现显存浪费的问题。由于显存成本较高，这种浪费会显著增加整个推理系统的成本。
如何将两者的优点结合起来，同时避免它们的不足。基于上述分析，我们提出了一个名为“P/D 半分离”的方式。在计算层面，我们对 Prefill 和 Decode 进行隔离，而在存储层面则进行融合。我们希望既能享受计算隔离带来的优势，又能减少存储融合导致的 KV Cache 传输开销。
在 P/D 半分离的整体架构中，首先从计算层面来看，我们希望对 Prefill 和 Decode 进行分离。这种分离借鉴了云计算领域常用的虚拟化技术。早在 20 年云游戏兴起时，就涉及如何在 GPU 的 SM 或其他计算单元上对不同游戏实例进行隔离式切分，当时采用了多种进程间虚拟化和隔离技术。类似地，在大模型出现之前，许多 AI 推理服务也在进程维度对多个任务进行隔离和虚拟化。因此，我们同样以进程间的方式对 Prefill 和 Decode 实例进行隔离，并按照 SM 的粒度对资源进行分配。这样做的好处是可以实现细粒度的资源管控，同时尽可能确保 P 实例和 D 实例之间有较好的分离。
在存储维度，我们主要针对 Prefill 和 Decode 的不同需求进行了针对性优化。之前的主要问题是，如果将它们融合，由于 Prefill 和 Decode 对显存的需求是动态的，核心逻辑是尽可能高效地利用显存。这就需要了解当前显存的使用情况以及任务所需的显存量。具体来说，分为三个步骤：第一步是分析当前显存的使用情况；第二步是确定当前是 Prefill 还是 Decode，以及该任务所需的显存量；第三步是对显存空间进行资源申请。如果将 Prefill 和 Decode 放在一起运行，它们之间可能会出现读后写依赖，以及细粒度访存请求互相干扰的问题。因此，我们首先将 Prefill 和 Decode 的细粒度内存访问融合成一个大的原子操作，然后在这个原子操作上对 Prefill 和 Decode 分别进行管理。这样做的好处是，融合后 Prefill 和 Decode 之间不会出现读后写依赖冲突，同时也能更好地管理显存碎片化。
在资源分配方面，我们举了一个例子。在优化前，我们可能给 Prefill 分配了约 2/3 的资源，给 Decode 分配了 60% 的资源。但如果在下一时刻我们认为应该给 Prefill 分配更多资源，由于这两个进程本身获得的资源不同，理论上需要重新加载和拷贝 KV Cache、上下文等参数，这会产生额外的资源调整开销。于是，我们想到引入一个常驻进程来管理 KV Cache 和模型权重的加载。这样，原有的 Prefill 和 Decode 进程可以预先依托常驻进程进行资源加载，无需引入额外的拷贝开销，从而减少 KV Cache 和资源分配方面的问题。
除了前面提到的方案，我们在实际生产环境中，也针对实例推理以及集群规模的 P/D 融合方式进行了支持。在实例级别，我们主要关注一台或两台 8 卡、16 卡的服务器规模。在这种情况下，Prefill 实例和 Decode 实例分别进行通信，且 Prefill 和 Decode 之间采用异步方式，这样可以更好地进行管理，并减少同步开销。
在集群规模方面，我们主要与现有的框架，包括 Kimi 开源的一些 P/D 分离框架进行融合。你可以选择直接使用现有的 Prefill 和 Decode 实例，也可以使用我们这种半分离的实例。核心目标是打开整个集群规模的优化空间，从而在上面进行更精细化的优化空间探索，找到一些更好的设计点。
与 SGLang 相比，我们的吞吐率提升了 10%，延时降低了两倍。同时，我们的 TTFT 和 ITL 的整体延时都得到了显著优化。从完成率曲线可以看出，与 SGLang 相比，我们在实际线上业务中完成请求的占比提升明显快于 SGLang 的结果。
面向华为昇腾的推理优化部署实践
最近，我们在华为昇腾平台，特别是其 910B 的 384 超节点上，进行了一些探索。这些探索主要集中在百卡到千卡规模的集群推理实践上。在开始之前，我们首先进一步分析了为什么需要超节点，以及华为开发超节点背后的逻辑。从下图左边可以看到，OpenAI 提出了从 L1 到 L5 的演进趋势，横轴代表智能水平。理论上，从 L1 到 L5，模型的智能水平应该越来越强。我们经过分析发现，要支撑这种智能水平的演进，整个推理的能效，即 Token/J，也需要持续迭代。我们之前介绍的实例推理主要围绕 L1 到 L2，或接近 L3 的部分。但未来，如果要支持多智能体、超大的 MoE，就需要更强的系统能力。
从右边的趋势可以看出，首先，模型规模越来越大。DeepSeek、Llama、Kimi 等模型从千亿规模演进到万亿规模，这意味着原来的实例推理已经无法满足需求，需要更大的模型来提供支持。其次，目前大家都有意识地向 MoE 的超稀疏多专家方向发展，且专家数量越来越多。例如，DeepSeek 有 256 个专家，而 Kimi 有 384 个专家。这种多专家的变化与超节点多卡的方式天然契合，便于进行大规模 EP（Expert Parallelism，专家并行）部署。此外，超长上下文也是一个趋势。现在，上下文长度已经从 8K、50K 发展到 128K，甚至更长。
接下来，我们来看在昇腾平台上部署会面临哪些问题。最近，昇腾的许多团队围绕 910B 和 920C 进行了一些具体的实践，这是一个令人欣喜的过程。从最初的实例推理到现在的集群推理，性能有了量级的提升。然而，从“能用”到“好用”之间仍存在差距。这个差距主要体现在两个方面：一方面，模型的上下文越来越长，这带来了计算、存储和通信的匹配问题；另一方面，华为的昇腾架构是一个 NPU 架构，其算子生态需要整个行业共同迭代。这自然会面临开源社区和整个软件栈迭代的问题。未来，模型肯定会逐步演进，如何将模型与集群更好地匹配起来，也是一个亟待解决的问题。
在这里，我想和大家分享一些我们在超节点上以及结合未来模型发展所遇到的挑战。首先是长文本问题。长文本的需求在 Agent 以及未来的具身智能等领域肯定会不断增加。长文本的核心特点是对 KV Cache 的占用会越来越大。如果文本较短，实例推理或许还能应对，最多支持 4K 到 8K 的上下文。但如果要支持 128K，甚至未来是 512K 以及更长的上下文，现有的实例推理显存显然已经无法满足需求。因此，自然而然地需要从实例推理转向集群推理，以获得更大的存储池来支持 KV Cache 的存储。
这自然带来了另一个问题：如何解决 KV Cache 之间的传输挑战。从计算层面来看，上下文越长，对应的 KV Cache 以及在 Prefill 阶段进行 Attention 计算时的计算需求也会越大。因为 Attention 计算本身是随着上下文长度呈二次方增长的，这就必然涉及到 MLA 以及 MoE 算子的计算优化问题。在通信层面，KV Cache 越来越大，必然会带来更多的通信和同步开销。过去，我们更多关注的是实例推理中的 TP（张量并行）并行。但现在，我们可能需要从张量并行切换到序列并行，甚至融合序列并行和专家并行的方式，来解决计算和通信开销问题。从框架层面来看，过去我们主要关注如何在 P 实例和 D 实例之间进行调度。但如今，超节点本身是一个融合方案，超节点与超节点之间如何协同支持，以及未来如何将不同模型部署到不同的超节点上，这都是框架层面需要考虑的模型适配问题。
在对昇腾架构的探索中，我们重点关注了计算层面的优化问题，尤其是与长文本处理和集群推理相关的挑战。首先，从计算层面来看，随着模型上下文长度的增加，注意力机制（Attention）的算力需求显著增大。这不仅体现在对张量核心（Tensor Core）的计算需求上，还体现在对标量计算的需求上。在昇腾架构中，标量计算单元（Scalar Unit）和向量计算单元（Vector Unit）的算力与矩阵计算单元（Cube Unit）存在较大差距。我们通过分析发现，随着上下文长度的增加，标量和向量计算的时间占比可能会从 10% 飙升到 30% 至 40%。这种非张量计算带来的瓶颈需要从芯片层面进行针对性优化。
针对长上下文导致的 KV Cache 存储不均问题，这与之前提到的 P/D 分离优化类似，但面向的是超节点内 NPU 和 NPU 之间，甚至是 GPU 和 GPU 之间的部署问题。在长上下文和云端推理场景中，计算力需求与存储需求的绑定因素不同。算力需求与请求数（batch size）紧密相关，而存储需求则与上下文长度相关。这种不一致性导致在集群推理和云端推理场景中，需要考虑的因素更多，且它们之间的相互影响也更为复杂。
资源匹配问题也是一个关键挑战。例如，在 384 超节点上部署 DeepSeek 模型时，由于模型的专家权重数量（320）与超节点数量（384）无法整除，导致部分 NPU 或 GPU 资源浪费。这表明 384 超节点在设计时可能并未完全针对特定模型进行优化，未来新模型的出现将进一步加剧这一问题。
针对这些问题，我们与清华大学和上海交通大学的团队进行了探索，并针对一些关键算子进行了底层优化。这些优化包括 L2、L1、L0 缓存之间的数据搬运和复用策略，以及基于昇腾 CCE 的底层支持。最近，我们还发表了一篇论文《FlashOverlap》 ，提出了针对昇腾架构的细粒度计算和通信流水优化方法，感兴趣的朋友可以查阅。
总结来说，我们认为集群推理其实是一个更为复杂的优化问题。在进行 AI 推理优化时，本质上我们都在做各种各样的多目标优化。我们既希望延时低，又希望吞吐量高，还希望资源利用率强，并且能够尽可能地服务更多用户。然而，在这个过程中，我们需要考虑诸多因素，包括模型的类型、规模，芯片的算力构成，可用的带宽、显存，以及整个节点的规模和节点之间的互联带宽等。我们一直强调软硬协同，其本质便是在这样一个庞大的优化空间里，尝试对计算、通信以及框架等资源配比进行合理的映射和优化搜索。所以，我觉得这个领域是需要持续进行技术攻关的，而我们目前也正在不断地探索，从计算到框架再到通信层面，我们都在持续地进行尝试。
以有限算力架构，释放终端应用潜能
在一些资源受限的芯片上，比如手机、PC 上，我们还能做哪些工作呢？大的背景是，我们坚信未来大模型将在更广泛的智能终端设备上落地，包括大家手里的手机、笔记本电脑，以及现在比较火的机器人，还有各种新形态的终端，这些都将是未来重要的智能入口。这个智能入口不仅会影响到云侧的配合，也会涉及到端侧有一个更懂你的智能体来帮你处理越来越多的事情。所以，这块带来的想象空间是越来越大的。结合现在比较火的具身智能，不管是自动驾驶、无人机还是机器人的场景，其实对 Token 的需求还是很大的，至少是在 100 到 1000 个 Token 这个量级。那么，如何用一个比较好的芯片和基础设施去支撑这样大的 Token 需求，至少在端侧这个场景是一个需要解决的问题。
在端侧，我们也是从计算、存储、通信这几个方面做了一些分析，包括在 GPU 和 CPU 上的一些优化。这可能涉及到在 SOC 上，能否把上面的 NPU 也利用起来。因为端侧本身就是一个存储非常有限的设备，所以如何把一个很大的模型进行蒸馏、压缩，压缩完以后是否还能满足需求，以及是否能在有限的空间里用计算去换存储的方式做一些优化。
目前业界的优化也分为几类。一类是做一些投机解码等技术，本质上是因为端侧存储比较贵，而算力相对来说有一些富余。因为在端侧，你不需要跑很大的 batch size，一般都是单 batch 和单用户的推理，所以大部分情况下计算是有富余的。那么，多出来的计算就可以用来换取存储。所以，现在所有的投机解码方式都是在做这块的事情。另一类是模型压缩，不管是做稀疏量化还是蒸馏，都是为了让模型在保持智能水平的情况下变得越来越小。其实，包括 MIT 和我们团队之前都做了很多这种压缩的工作。还有一类是端侧本身是一个 SOC 平台，那如何在上面做一些协同优化，也是一个重要的方向。
我们团队最近开展了一项工作，这是一个典型的软硬件协同优化方案。我们的思路是从投机采样等技术入手，从模型和软件两个层面进行探索。简单来说，正常情况下，模型推理包含多个层级。之前有早退技术的概念，即无需完成所有层级的计算就能输出结果。例如，一个 32 层的模型，可能在计算到第 31 层时，结果的概率就已经接近阈值，可以提前结束。但关键问题在于，何时应该结束？这需要一个判断过程。如果将这个判断过程建模，实际上是在一个上万规模的词表中进行搜索分类。对于典型的大模型，词表通常是万级的，比如一个 3 万词表，这样的搜索开销非常大。我们希望在享受早退技术带来的计算和存储开销减少优势的同时，尽量使其可用，否则每次都要搜索一遍，可能会带来不可接受的开销。
核心问题在于如何构建一个中间预测模型，以缩短在线搜索的开销。比如在某一层判断是否可以结束时，能够通过一个小的推测模型，在极低开销下进行判断。这个推测模型会根据输入，将原本庞大的词表缩减为一个非常小的词表。因为在对话场景中，下一个词相对比较确定，本质上不需要在大词表中搜索。理论上，可以提前训练一个小模型，让它知道在什么范围内找到这个词，然后在这个小词表下进行搜索，从而尽可能降低开销。
如何以低开销、高精度的方式进行这种级联计算。由于我们本质上是在做软硬件协同优化，修改算法不可避免地会引入一些开销。因此，如果预测错误，就需要一些在线修正机制。我们在这方面也做了一些工程优化，以确保预测错误时能够快速修正，从而保证精度不受损失。此外，针对频繁调度的开销问题，我们在端侧开发了一个调度引擎，用于记录早退的位置，并提前存储早退的概率，结合离线调度和在线调度，优化整体的调度效率。
从结果来看，下图黄色部分是基于一些稀疏化的优化，绿色部分是量化优化。我们可以看到，通过软硬件协同的方式，在保证精度的同时提升了速度，使性能尽可能向右上角提升。在实际部署中，我们在联想的 AI PC 上进行了部署，端到端的性能大约提升了两倍。
以大模型推理技术创新，融合人工智能产业创新
我们与各位探讨了在云和端侧部署大模型时面临的效率挑战。我们的核心目标是无论在云端还是端侧设备上，都能充分利用大模型的优势，同时尽可能降低对硬件资源的需求，并满足用户对推理服务质量的要求。一直以来，我们致力于将推理系统部署到云端，推动整个产业链的运转。因为，尽管从事基础设施和技术工作的人员主要关注 Token 的性能，但仅靠 Token 性能是不够的。我们还需要让足够多的应用企业参与进来，形成产业闭环。只有当大家广泛使用大模型，探索其在各行业的应用，并在 Token 量大幅提升后，才能有足够的需求推动基础设施的发展。我认为这是一个良好的正向循环。在端侧，我们则与联想等企业以及各种端设备进行了探索，希望未来无论是 AI PC、AI 手机，还是其他终端设备，都能为用户带来使用体验上的变革。
我们认为未来端和云并非解耦的，而是需要协同支撑的。在相当长的一段时间里，端和云将相互补充、共同存在。在端侧，我们可以部署 3B、7B 或 13B 左右的模型，用于本地化处理和个人个性化助理功能。这些模型能够了解用户的想法，帮助管理个人日程，并分析个性化需求。由于涉及隐私性要求，这些功能需要在本地实现。而当用户需要处理更复杂的任务时，端侧设备可以调用云端的 Agent 和更强大的模型，为用户提供辅助支持。我们相信，在未来很长一段时间里，需要探索出一个云与端协同的框架，以确保大模型在各行业的更好落地。
我们的愿景是，就像 30 年前水电走进千家万户一样，如今我们希望通过端云协同和更高效的基础设施，与上下游通力合作将大模型的成本降低万倍，使其普及到更多领域。
演讲嘉宾介绍
曾书霖，无问芯穹总经理，于 2018 年和 2023 年在清华大学电子工程系获得工学学士和博士学位，师从清华大学电子工程系教授、IEEE Fellow 汪玉，研究领域为软硬协同优化研究和 AI 加速器设计。在相关领域发表高水平国际会议和期刊论文 20 余篇，谷歌学术施引九百余次，包括以第一作者或共同一作发表高水平论文于可重构计算领域旗舰会议（ FPGA · 25, FPGA · 24）、体系结构领域顶级会议 (HPCA · 25, MICRO · 23)、以及顶级期刊 IEEE TC、ACM TRETS 等。曾获 FPGA 2025 会议最佳论文奖（ FPGA 会议首次将该奖项授予完全由中国大陆科研团队主导的研究工作，也是亚太国家团队首次获此殊荣）、IEEE TC 2023 Featured Paper of the Month、清华大学研究生国家奖学金等。在创新创业方面，作为创始成员参与创立上海无问芯穹智能科技有限公司，并作为智能终端业务负责人，带领团队打造“端模型 + 端软件 + 端 IP ”的智能终端一体化解决方案。
