1. 从生态拐点说起昇腾这次到底跨过了什么生态拐点这个词做AI基础设施的人这两年听得耳朵起茧但真正能说清楚它意味着什么的人不多。我自己的理解是一个计算平台从能跑通demo到有人愿意在上面做长期投入中间隔着一道看不见的墙。墙的这边是我试试看墙的那边是我把生产业务放上去。昇腾这次被反复提及跨过拐点核心不在于某一颗芯片的算力数字而在于软件栈的成熟度、框架适配的完整度、以及开发者迁移成本这三件事同时到了一个可接受的水平。先把这个判断拆开讲。过去几年国产AI加速卡最大的痛点从来不是峰值算力不够而是跑起来费劲。你拿到一张卡装驱动、配环境、改算子、调精度一套流程下来可能一周就没了最后发现某个自定义算子不支持还得自己写。这种体验下没人敢把核心业务往上放。而拐点的标志就是这套流程从一周压缩到半天从必须改代码变成基本零改动。昇腾这条线上的关键抓手是CANNCompute Architecture for Neural Networks它是整个软件栈的底座相当于英伟达生态里的CUDA那一层。CANN往上对接PyTorch、MindSpore、TensorFlow这些框架往下管理NPU的算力和内存。CANN的版本迭代节奏、算子覆盖度、图编译优化能力直接决定了开发者愿不愿意留下来。我观察到的一个明显变化是现在主流的开源模型——不管是LLaMA系、Qwen系还是各类多模态模型——在昇腾上的适配周期已经从月级别缩短到周甚至天级别这个速度变化才是拐点的真实含义。再说Agentic计算这个提法。它不是单纯把大模型跑起来就完事而是指模型要能自主规划、调用工具、多轮迭代、长期记忆。这对底层计算提出了完全不同的要求传统推理是一问一答请求来了算完就走Agentic场景下一个任务可能触发几十次模型调用、若干次工具执行、多次上下文重写计算模式从单次前向变成了持续编排。这就解释了为什么华为要把云和鸿蒙拉进来一起讲——单靠一颗芯片解决不了Agent的完整生命周期问题。适合读这篇内容的人我大致分三类一是正在做AI基础设施选型的技术负责人需要判断昇腾能不能承接生产业务二是做Agent应用开发的工程师想搞清楚底层计算平台的变化会怎样影响自己的架构设计三是对国产算力生态感兴趣、想动手试一试的开发者。不管你是哪一类下面这些拆解应该都能给你一些可落地的参考。2. Agentic计算的五大变化逐条拆解与背后逻辑华为提出的Agentic计算五大变化如果只当成宣传口号看就浪费了。我把它当成一份架构设计检查清单来读每一条背后都对应着真实的工程约束。下面逐条拆并且补上我理解的实现路径。2.1 变化一从单次推理到持续编排计算负载形态变了传统推理服务的负载模型很简单请求进来batch一下前向算完返回结果。QPS、延迟、吞吐这三个指标基本能描述清楚。但Agentic场景下一个用户请求可能触发一条推理链——模型先规划然后调用搜索工具拿到结果后再推理再调用代码执行器再推理……整条链路上有多次模型调用中间还夹着工具执行和状态管理。这对计算平台的影响是根本性的。负载不再是均匀的而是突发性的、长尾的。一个Agent任务可能跑几秒钟也可能跑几分钟中间还有大量等待工具返回的空闲时间。如果底层还是按单次推理的思路做资源调度就会出现算力利用率极低的情况——NPU在等工具返回的时候完全闲置。我理解昇腾这边的应对思路是推理与编排解耦。把模型推理做成可被高频调用的服务把编排逻辑放到上层比如云侧的Agent框架底层NPU专注做它擅长的事——高吞吐的矩阵计算。这样资源调度可以按推理请求粒度来做而不是按Agent任务粒度利用率能拉回来不少。实操上如果你要在昇腾上搭Agent服务我建议把推理服务化和编排逻辑分层作为第一条设计原则。别把整个Agent循环塞进一个进程里那样既不好扩缩容也不好排查问题。2.2 变化二上下文长度暴涨KV Cache管理成了核心矛盾Agentic场景下上下文长度是个绕不开的坎。多轮对话、工具返回结果、历史记忆全都往context里塞动辄几万甚至几十万token。这对显存在昇腾上是HBM的压力是灾难性的因为KV Cache的大小和上下文长度成正比。这里得补一个基础知识点方便不太熟悉推理优化的读者理解。Transformer推理时每生成一个token都要用到之前所有token的Key和Value向量这些向量缓存起来就是KV Cache。上下文越长缓存越大。一个13B模型上下文32KKV Cache可能就要吃掉十几GB显存。上下文拉到128K单请求就能把一张卡撑爆。昇腾这边的解法我了解到的主要是几条路并行一是PagedAttention类的分页管理把KV Cache切成固定大小的块按需分配减少碎片二是量化KV Cache把Key/Value从FP16压到INT8甚至更低用精度换空间三是前缀共享多个请求如果有相同的system prompt这部分KV可以复用。提示KV Cache量化是有精度风险的尤其是长上下文场景下误差会累积。我实测下来的经验是INT8量化在大多数对话任务上感知不明显但涉及精确数值计算或代码生成时要谨慎最好做A/B对比再上线。2.3 变化三多模型协同异构调度成为常态一个成熟的Agent系统很少只用一个模型。规划用大模型执行用小模型embedding用专门的向量模型可能还有rerank模型、语音模型、视觉模型。这些模型大小不同、精度需求不同、调用频率不同怎么在一堆NPU上高效调度是个真问题。这就引出了异构调度的需求。昇腾系列本身就有不同规格的产品从边缘侧的推理卡到数据中心的高密训练卡算力和显存差异很大。Agentic场景下把合适的模型放到合适的硬件上比单纯堆算力更重要。比如embedding模型对算力要求低但对并发要求高就可以放到性价比更高的卡上大模型规划器则需要大显存和高算力。我个人的经验是别追求一个模型一张卡的静态分配那样资源利用率很难看。更好的做法是把模型服务化用统一的调度层按负载动态分配。华为云在这块的思路是把推理服务做成弹性资源池按请求量自动扩缩这个方向是对的。2.4 变化四工具调用引入外部依赖稳定性设计被提到台前Agent要调用工具工具可能是数据库查询、API请求、代码执行、文件操作。这些外部依赖的延迟和成功率直接决定了整个Agent任务的成功率。一个工具调用超时可能导致整个任务链失败。传统推理服务不太需要考虑这些因为它是自包含的。但Agentic计算必须把外部依赖的容错纳入设计。我踩过的坑是早期做Agent demo时没做超时和重试结果一个搜索API偶尔抽风整个任务就卡死了用户等半天没响应。昇腾和华为云这条线上我理解的做法是把工具调用做成可观测、可重试、可降级的标准组件。超时设短一点失败快速重试重试还不行就走降级路径比如返回暂时无法完成而不是一直转圈。这些看起来是应用层的事但底层计算平台如果能提供统一的工具调用框架和监控开发者能省很多事。2.5 变化五从云到端的连续体鸿蒙补上了最后一环这是我认为最有意思的一条。Agentic计算的完整闭环不只是云侧跑模型还包括端侧的能力。为什么因为很多Agent任务需要访问用户本地数据、调用本地硬件摄像头、麦克风、传感器、在离线状态下也能工作。鸿蒙在这里的角色是提供一个端侧Agent的运行环境。手机、平板、PC、车机这些设备上的Agent可以处理隐私敏感的任务数据不出端、低延迟的任务不用往返云端、以及需要本地硬件的任务。云侧负责重计算和全局知识端侧负责轻量推理和本地交互两者通过统一的协议协同。这个云-端连续体的构想技术上依赖几个东西端侧要有足够强的NPU昇腾在端侧也有布局、要有统一的模型格式和推理框架、要有安全的云端通信机制。鸿蒙的分布式能力在这里能派上用场但具体落地效果还得看生态成熟度。3. 云与鸿蒙如何撑起Agent进化分层架构实操解析把五大变化串起来看会发现它们指向同一个架构需求分层。云侧管重计算和编排端侧管轻推理和本地交互中间用统一的服务协议连接。下面我把这个分层架构拆开讲并给出可参考的落地思路。3.1 云侧推理服务化与Agent编排框架云侧的核心任务是把NPU算力变成可被Agent调用的服务。这里的关键设计是推理服务与编排逻辑分离。推理服务层我建议用标准的服务化框架来封装模型。昇腾生态里有对应的推理服务组件能把模型加载、batch调度、KV Cache管理这些脏活累活包掉对外暴露HTTP或gRPC接口。这样上层Agent框架只需要发请求、收结果不用关心底层是NPU还是别的什么。编排层负责Agent的大脑逻辑任务规划、工具选择、状态管理、多轮迭代。这一层用Python写最方便因为生态成熟。华为云这边提供的Agent开发框架思路是把常见的编排模式ReAct、Plan-and-Execute、Reflection等做成模板开发者填空即可。我实操下来的体会是编排层一定要做无状态化。Agent的状态对话历史、中间结果存到外部存储比如Redis或对象存储这样编排服务可以随意扩缩容某个实例挂了也不影响任务恢复。有状态的服务在Agent这种长任务场景下是运维噩梦。3.2 端侧鸿蒙上的轻量Agent运行时端侧Agent的约束和云侧完全不同算力有限、内存有限、功耗敏感、还要考虑隐私。所以端侧不能照搬云侧那套得做减法。鸿蒙上跑Agent我理解的技术路径是小模型 本地工具 云端兜底。小模型比如1B到3B级别负责意图理解、简单规划、本地工具调用遇到搞不定的复杂任务把请求转发到云端大模型。这样既保证了响应速度和隐私又不牺牲能力上限。具体到开发鸿蒙的AI框架提供了端侧推理能力模型需要提前转换和量化。这里有个实操细节端侧模型的量化策略和云侧不一样。云侧可以用INT8甚至FP8端侧为了省内存和功耗可能要用INT4但INT4对精度的影响在小模型上更明显需要针对具体任务调优。注意端侧Agent的调试比云侧麻烦得多因为设备资源受限日志和断点都不好打。我的建议是先在PC模拟器上把逻辑跑通再上真机验证性能和功耗别一上来就在手机上硬调。3.3 云端协同协议、安全与状态同步云和端要协同最麻烦的不是技术是协议设计。端侧发什么给云侧云侧返回什么状态怎么同步隐私数据怎么保证不出端我的理解是云端协同要遵循最小必要原则端侧只把完成任务必需的信息发给云侧能本地处理的绝不外传。比如用户说帮我订明天去上海的机票端侧Agent理解意图后只需要把订票意图日期目的地发给云侧不需要把用户的完整对话历史都传上去。安全方面云端通信要加密端侧要有明确的权限控制哪些数据可以出端、哪些不行。鸿蒙的权限体系在这里能提供基础保障但Agent层面的数据分级还需要开发者自己设计。状态同步是个容易被忽视的点。用户在手机上发起一个Agent任务切换到PC上想继续状态怎么迁移这需要把Agent的会话状态做成可序列化、可跨设备恢复的格式。技术上不难但设计时要提前考虑别等做完了才发现状态散落在各处。4. 实操避坑从环境搭建到性能调优的完整路径前面讲了不少架构层面的东西这一节落到具体的操作。我按从零开始跑通一个昇腾上的Agent服务这个目标把关键步骤和踩过的坑整理出来。4.1 环境准备CANN版本与框架适配的匹配关系第一步永远是环境。昇腾这套栈最容易出问题的就是版本匹配。CANN、驱动、PyTorch适配版、Python版本这几者之间有严格的对应关系错一个就可能跑不起来。我的建议是从官方提供的镜像或容器开始别自己从裸机装。官方镜像里版本都是配好的能省掉大量排查时间。如果必须自己装记住这个顺序先装驱动再装CANN最后装框架适配包。顺序错了会出现各种诡异的链接错误。组件作用常见坑驱动管理NPU硬件版本和CANN不匹配会导致设备识别失败CANN算子库与图编译版本升级后旧模型可能需要重新编译框架适配包对接PyTorch等必须用昇腾官方适配版不能用原生版Python运行环境版本过高或过低都可能导致依赖冲突4.2 模型迁移从GPU代码到NPU代码的最小改动原则把已有的GPU代码迁到昇腾核心原则是最小改动。大部分情况下你不需要重写模型只需要改设备指定和少量算子。典型改动包括把.cuda()换成.npu()把torch.cuda相关的调用换成对应的NPU接口检查是否有不支持的算子需要替换。昇腾的适配工具能自动扫描代码里的不兼容点先跑一遍扫描心里有数再动手。我踩过的一个坑是自定义算子。如果你的模型里有自己写的CUDA kernel那迁移工作量就大了需要用昇腾的算子开发框架重写。所以选型阶段就要评估模型里有多少自定义算子如果太多迁移成本可能高到不划算。4.3 精度选择昇腾310P3该用什么精度热词里有人问昇腾310P3使用什么精度这个问题很实际。310P3是推理卡精度选择直接影响性能和精度表现。我的经验是分场景纯推理任务优先用FP16这是精度和性能的平衡点大多数模型FP16下精度损失可忽略。如果显存吃紧或者要极致吞吐可以试INT8量化但一定要做精度对比测试。INT8在分类、检测类任务上通常没问题在生成类任务上要小心尤其是长文本生成误差会累积。至于FP32除非你的任务对数值精度极其敏感比如某些科学计算否则没必要性能损失太大。310P3这类推理卡的设计初衷就是高吞吐低精度硬上FP32是逆着硬件设计走。4.4 性能调优batch、并发与KV Cache的三角平衡性能调优这块核心是平衡三个变量batch size、并发数、KV Cache占用。它们互相制约调好一个可能恶化另一个。batch size增大能提升吞吐但会增大显存占用和单请求延迟。并发数增大能提升资源利用率但KV Cache总量会线性增长。KV Cache量化能省显存但可能影响精度。我的调优顺序是先定精度FP16还是INT8再定KV Cache策略是否量化、是否分页然后压测找batch和并发的最优组合。压测时别只看吞吐要看P99延迟Agent场景下长尾延迟比平均延迟重要得多。提示Agent场景的压测和传统推理不一样要模拟多轮调用工具等待的真实模式不能只压单次推理。否则测出来的数据会过于乐观。5. 常见问题速查与独家避坑技巧这一节把我遇到的和社区里高频出现的问题整理成速查表方便你对号入座。5.1 环境与部署类问题问题现象可能原因排查方向设备识别不到驱动未装或版本不匹配检查驱动版本与CANN对应关系模型加载报算子不支持CANN版本过低或算子未实现升级CANN或替换算子推理结果和GPU不一致精度设置不同或算子实现差异对齐精度设置逐层对比输出多卡训练卡死通信库配置问题检查HCCL配置和网络5.2 Agent场景特有的坑Agent场景有几个传统推理没有的坑我单独列出来。第一个坑是上下文管理失控。多轮对话加上工具返回context会越滚越大最后撑爆显存。解法是设计上下文压缩策略老对话摘要化、工具结果只保留关键字段、设置硬性长度上限。第二个坑是工具调用超时拖垮整个任务。一个工具卡住整个Agent循环就停了。解法是给每个工具调用设独立超时超时就走降级或跳过别让单点故障扩散。第三个坑是状态不一致。Agent任务跨多个服务状态散落各处出问题时很难定位。解法是统一状态存储给每个任务一个全局ID所有日志带上这个ID排查时能串起来。5.3 我个人的几条硬核经验做了这么多项目有几条经验我觉得比任何文档都值钱。别迷信零改动迁移。宣传上都说零改动实际多少要改点东西。预留20%的时间做适配和调试心态会好很多。压测要趁早。别等功能全做完再压测那时候发现问题改架构成本太高。模型一跑通就压一轮心里有底。端侧和云侧分开调。端侧的问题功耗、内存和云侧的问题吞吐、并发性质完全不同混在一起调会互相干扰。先把云侧调稳再上端侧。日志要打够。Agent任务链路长出问题时没有足够日志就是抓瞎。关键节点模型调用、工具调用、状态变更都要打日志宁可多打也别漏。6. 这套东西后续还能怎么扩展聊到最后说几个我觉得值得继续深挖的方向。一个是Agent的可观测性。现在Agent跑起来像黑盒出了错很难知道是哪一步的问题。把推理、工具调用、状态变更都做成可追踪的span用类似分布式追踪的方式呈现这个方向我觉得会越来越重要。另一个是端侧Agent的评测体系。云侧模型有成熟的benchmark端侧Agent怎么评功耗、延迟、隐私、能力这几个维度怎么量化目前还没有公认的标准谁先做出来谁有话语权。还有就是多Agent协同。单个Agent能力有限多个Agent分工协作能解决更复杂的问题。但多Agent之间的通信、协调、冲突解决都是开放问题。昇腾和华为云如果能在这块提供基础设施支持会很有价值。我自己在实际项目里的体会是Agentic计算现在还处在能用但不好用的阶段工具链和最佳实践都在快速演进。这个时候入场好处是能参与定义标准坏处是要忍受不成熟带来的各种坑。怎么选看你的业务节奏和团队承受能力。但有一点是确定的这个方向的计算需求会持续增长早布局比晚布局主动。
