1. 先搞清楚迁移到底在迁什么DeepSeek的模型权重和昇腾Ascend相关组件陆续开源之后我身边不少做AI应用的朋友第一反应是是不是可以把整套系统搬过去。这个想法很自然但实际操作下来会发现迁移从来不是全有或全无的选择题而是一道需要逐层拆解的工程题。你的AI应用里真正跟硬件强绑定的部分其实只占一小块大部分业务逻辑、数据管道、提示词工程、前后端交互跟底层跑在什么芯片上关系并不大。我先把结论摆出来一个典型的AI应用从下往上大致可以切成五层——算力与驱动层、推理运行时层、模型服务层、应用编排层、业务交互层。DeepSeek昇腾组件开源主要影响的是下面三层上面两层基本可以原样保留。很多人一听到迁移就头大是因为把整栋楼当成一个整体在搬实际上你只需要换地基和承重结构家具和装修风格完全可以不动。这里有个容易被忽略的点迁移的粒度不是按应用划分的而是按依赖划分的。同一个应用里可能有的模块迁移成本极低比如纯Python的业务逻辑有的模块迁移成本极高比如用了特定算子融合的推理加速代码。所以第一步不是急着动手改代码而是先做一次依赖盘点把每个模块跟硬件的耦合程度标出来。我一般会用一个简单的三分法来标记强耦合直接调用了特定芯片的运行时API、自定义算子、专用通信库这部分必须改。弱耦合通过标准接口比如OpenAI兼容的HTTP接口调用模型底层换什么芯片对它透明这部分基本不用动。无耦合纯业务逻辑、数据库操作、前端页面跟算力完全无关这部分一行都不用改。做完这个盘点你会发现真正需要投入精力的地方往往只占整个代码库的20%到30%。剩下的部分迁移的本质其实是重新部署而不是重写。提示依赖盘点阶段不要只看代码还要看配置文件、环境变量、Docker镜像里的基础层、CI/CD流水线里的构建脚本。很多迁移翻车不是因为代码没改对而是因为某个环境变量指向了旧的运行时路径。2. 推理运行时层迁移的主战场2.1 为什么这一层最难搬推理运行时层是整个迁移过程中最硬的一块骨头。它负责把模型权重加载进显存、管理KV Cache、调度请求批次、执行算子计算。这一层跟硬件的绑定最深因为不同芯片的显存结构、算子实现、通信拓扑都不一样。DeepSeek模型本身是Transformer架构核心计算是大规模的矩阵乘法和注意力机制。在通用GPU上这些计算有成熟的CUDA内核和cuBLAS库支撑。换到昇腾平台对应的就是CANNCompute Architecture for Neural Networks这套软件栈以及它提供的算子库和通信库。关键差异不在于能不能算而在于算得对不对、快不快。我实测下来迁移推理运行时层主要有三条路径成本从高到低排列迁移路径适用场景工作量风险点基于开源组件重新编译适配需要深度定制推理逻辑高算子兼容性、精度对齐使用官方提供的推理框架标准模型部署中版本匹配、配置调优通过标准API间接调用只关心模型输出低功能受限、延迟不可控2.2 算子对齐是第一个坎Transformer里的算子看起来标准但实际实现差异很大。比如LayerNorm不同框架对epsilon的处理、对数值精度的处理都不一样。再比如注意力机制里的softmax在长序列场景下数值稳定性处理方式不同可能导致输出结果的细微偏差。这些偏差在单次推理里可能看不出来但在需要严格复现的场景下就是问题。我的做法是先跑通一个最小可验证单元拿一段固定的输入文本在原始环境和迁移后环境分别跑一遍逐层对比中间激活值。不要一上来就跑完整模型那样出了问题根本定位不到是哪一层。具体操作上我会构造一个包含典型输入的测试集覆盖短文本、长文本、特殊字符、多轮对话等场景。然后在两个环境里分别导出每一层的输出用余弦相似度或者最大绝对误差来衡量对齐程度。一般来说误差在1e-3量级以内是可以接受的超过这个量级就要查是哪个算子的问题。2.3 显存管理的坑比想象中多昇腾平台的显存管理机制跟通用GPU有差异。最典型的是显存碎片问题。在长时间运行的服务里如果请求的序列长度变化很大显存分配器可能产生大量碎片最终导致明明总显存够用却分配失败。我踩过的一个坑是模型加载时预留的显存比例设得太满导致运行时没有足够的余量处理动态shape。解决办法是留出至少15%到20%的显存余量并且在服务启动参数里显式配置显存分配策略。另外KV Cache的管理也要注意如果用的是分页注意力机制页大小设置不合理会显著影响吞吐。还有一个容易被忽略的点是多卡通信。如果模型大到需要多卡并行通信库的选择和配置就变得关键。昇腾平台有自己的集合通信库跟通用GPU上的方案在API层面不完全一样。迁移时需要确认通信拓扑、带宽配置、以及是否支持你需要的并行策略张量并行、流水线并行等。3. 模型服务层接口兼容比性能更重要3.1 把模型服务当成一个黑盒模型服务层是推理运行时之上、应用编排之下的那一层。它的职责是接收请求、做预处理、调用推理引擎、做后处理、返回结果。这一层迁移的核心原则是尽量把它做成一个黑盒让上层应用感知不到底层变化。具体做法是保持接口协议不变。如果你的应用之前是通过HTTP接口调用模型服务迁移后依然保持同样的接口路径、同样的请求体格式、同样的响应体格式。这样上层应用一行代码都不用改。我见过太多迁移项目明明只需要换底层结果把接口协议也一起改了导致上层所有调用方都要跟着改工作量翻了好几倍。3.2 批处理策略需要重新调批处理是提升推理吞吐的关键手段但不同硬件平台的最优批处理策略不一样。通用GPU上可能适合较大的批大小因为并行计算单元多昇腾平台的并行结构不同最优批大小可能更小但可以通过更高的并发请求数来弥补。我一般会做一个简单的压测矩阵固定输入长度变化批大小比如1、2、4、8、16测量吞吐和延迟。找到吞吐开始下降或者延迟开始飙升的拐点那就是这个平台上的最优批大小。这个值跟模型大小、序列长度、显存容量都有关系没有万能公式必须实测。另外要注意动态批处理的实现。如果你的服务支持动态批处理把不同时刻到达的请求攒成一批迁移后要重新验证批处理窗口的设置。窗口太短攒不够请求吞吐上不去窗口太长延迟增加用户体验下降。这个平衡点在不同平台上是不一样的。3.3 精度与性能的取舍推理时用的数值精度直接影响性能和显存占用。常见的精度选项有FP32、FP16、BF16、INT8等。迁移到新平台后需要确认目标平台支持哪些精度以及每种精度下的实际性能表现。我的经验是先保证精度对齐再优化性能。先用FP16或者BF16跑通确认输出结果跟原始环境一致然后再尝试更低精度。如果直接上INT8出了问题很难判断是量化误差还是算子实现问题。还有一个细节是累加精度。即使输入是FP16累加过程如果用FP32结果会更稳定。不同平台对累加精度的默认处理可能不同需要在配置里显式指定。4. 应用编排层这里才是迁移的主战场4.1 编排逻辑跟硬件无关应用编排层是很多人忽略的地方但它其实是迁移过程中工作量最大的部分。这一层包含提示词模板、上下文管理、工具调用、多轮对话状态维护、RAG检索逻辑等等。这些东西跟底层跑在什么芯片上完全无关但它们是AI应用的核心价值所在。我之所以说这里是主战场是因为迁移项目里80%的代码改动其实发生在这里。不是因为硬件变了要改而是因为迁移是一个重新审视和优化编排逻辑的好机会。很多应用在早期快速迭代时积累了大量技术债编排逻辑混乱、提示词硬编码、上下文管理没有统一抽象。迁移的时候正好一并重构。4.2 提示词工程的平台无关性提示词是AI应用里最软的部分但它的效果高度依赖于模型本身。DeepSeek模型有自己的提示词偏好比如对系统提示的响应方式、对few-shot示例的敏感度、对输出格式的遵循程度。迁移到昇腾平台后如果用的还是同一个DeepSeek模型提示词基本不用改但如果换了模型版本或者量化方式提示词可能需要微调。我的做法是建立一个提示词回归测试集收集一批典型用户输入记录原始环境下的模型输出迁移后跑同样的输入对比输出质量。如果发现某些场景下输出质量下降再针对性调整提示词。4.3 上下文管理的重新设计上下文管理是AI应用里最容易被低估的部分。它涉及对话历史怎么存、怎么截断、怎么压缩、怎么检索。迁移到新平台后如果推理服务的上下文窗口大小变了或者KV Cache的管理方式变了上下文管理策略也要跟着调整。举个例子原来模型支持32K上下文你可以在对话历史里保留很多轮。迁移后如果实际可用的上下文窗口变小了就需要更激进的截断策略或者引入摘要压缩机制。这些改动都在应用编排层跟底层硬件无关但直接影响用户体验。5. 业务交互层基本不用动但要验证5.1 前端和API网关的稳定性业务交互层包括前端页面、移动端App、API网关、鉴权、限流、日志、监控等等。这一层跟AI模型的关系最远迁移时基本不需要改动。但有一个前提模型服务的接口协议保持不变。只要接口不变前端和网关就感知不到底层变化。我一般会在迁移完成后做一轮端到端的回归测试覆盖主要的用户路径。重点验证请求延迟是否在可接受范围内、错误率是否正常、超时重试逻辑是否正常工作、日志和监控是否能正确采集到新环境的数据。5.2 监控指标的重新校准迁移后监控指标需要重新校准。原来在通用GPU上你可能关注GPU利用率、显存占用、温度等指标。迁移到昇腾平台后对应的指标名称和采集方式可能不同。需要确保监控系统能正确采集新平台的指标并且告警阈值要重新设置。我踩过的一个坑是迁移后没有及时更新告警阈值结果因为新平台的正常波动触发了大量误报运维团队被折腾了好几天。建议迁移后先观察一周收集正常运行的指标基线再据此设置告警阈值。5.3 成本模型的重新计算迁移到新平台后成本模型也要重新算。不只是硬件采购成本还包括运维成本、电力成本、机房空间成本等。昇腾平台在能效比上可能有优势但软件生态的成熟度可能不如通用GPU这意味着运维人力成本可能更高。我一般会做一个简单的TCO总拥有成本对比表把硬件、软件、人力、电力、机房等各项成本列出来按三年周期计算。这个表不需要很精确但能帮你判断迁移在经济上是否划算。6. 迁移后的验证与调优6.1 功能验证的完整清单迁移完成后功能验证不能只跑几个demo就完事。我一般会准备一个完整的验证清单覆盖以下维度基础功能模型能否正常加载、能否正常推理、输出格式是否正确。边界场景超长输入、空输入、特殊字符、多语言混合。并发场景多请求同时到达时的表现、批处理是否正确工作。异常场景请求超时、显存不足、网络中断时的错误处理。性能指标吞吐、延迟、显存占用、CPU占用。每个维度都要有明确的通过标准不能凭感觉判断。6.2 性能调优的优先级性能调优要有优先级不要一上来就抠细节。我的优先级排序是先保证正确性输出结果跟原始环境一致这是底线。再保证稳定性长时间运行不崩溃、不泄漏、不降级。然后优化吞吐通过批处理、并发、缓存等手段提升单位时间处理量。最后优化延迟通过算子优化、精度调整、流水线并行等手段降低单次请求延迟。这个顺序不能乱。如果正确性都没保证就去优化性能优化出来的结果可能是错的白费功夫。6.3 持续迭代的心态迁移不是一次性的项目而是一个持续迭代的过程。新平台在早期可能有一些不完善的地方随着软件栈的更新会逐步改善。我的建议是建立一个迁移后的持续观察机制定期收集性能数据、用户反馈、错误日志发现瓶颈就针对性优化。另外保持跟社区和官方的沟通也很重要。很多坑别人已经踩过了只是你还不知道。多看看技术社区的讨论能少走很多弯路。7. 一些实操中的经验教训7.1 不要追求一步到位我见过最典型的失败案例就是想把整个系统一次性全部迁移过去。结果迁移过程中问题层出不穷团队疲于奔命最后项目延期好几个月。正确的做法是分阶段迁移先迁移一个非核心的、流量小的服务跑通整个流程积累经验再逐步迁移核心服务。7.2 保留回滚能力迁移过程中一定要保留回滚能力。万一新环境出了问题能快速切回旧环境。这要求你在迁移期间保持两套环境并行运行并且数据要能双向同步。虽然成本高一点但这是保险绳不能省。7.3 文档和知识沉淀迁移过程中会遇到各种问题解决之后一定要记录下来。不只是记录怎么解决的还要记录为什么会出现这个问题、下次怎么避免。这些经验是团队最宝贵的资产比任何官方文档都有价值。7.4 关注社区动态DeepSeek和昇腾的生态都在快速演进今天遇到的问题可能明天就有官方解决方案了。保持对社区动态的关注能帮你省下大量重复造轮子的时间。我一般会定期看几个关键渠道官方仓库的issue区、技术社区的讨论帖、以及一些活跃开发者的分享。8. 回到最初的问题究竟能迁移哪一部分绕了一大圈回到标题的问题。我的答案是你的AI应用里跟硬件强绑定的部分推理运行时层需要重点迁移工作量占比约20%到30%模型服务层需要适配但接口可以保持不变工作量占比约10%到20%应用编排层和业务交互层基本可以原样保留工作量占比约50%到70%。这个比例不是绝对的取决于你的应用架构有多干净。如果你的应用从一开始就做好了分层抽象迁移成本会低很多如果是一坨意大利面式的代码那迁移就是一次痛苦的重构。我个人在实际操作中的体会是迁移的最大价值不在于换了什么硬件而在于借这个机会把系统重新梳理了一遍。很多在迁移过程中发现的问题其实跟硬件无关是架构本身的问题。把这些理顺了不管跑在什么平台上系统都会更健康。最后分享一个小技巧在迁移开始之前先画一张依赖关系图把每个模块跟硬件的耦合程度标出来。这张图不用很精确但能帮你快速判断哪些地方需要投入精力哪些地方可以放心跳过。我每次做迁移项目这张图都是第一步也是最有用的一步。 
长河君 · 2026/10/10 7:37:37 · 阅读 1.2k DeepSeek昇腾迁移实战：AI应用分层拆解与工程适配指南
1. 先搞清楚迁移到底在迁什么DeepSeek的模型权重和昇腾Ascend相关组件陆续开源之后我身边不少做AI应用的朋友第一反应是是不是可以把整套系统搬过去。这个想法很自然但实际操作下来会发现迁移从来不是全有或全无的选择题而是一道需要逐层拆解的工程题。你的AI应用里真正跟硬件强绑定的部分其实只占一小块大部分业务逻辑、数据管道、提示词工程、前后端交互跟底层跑在什么芯片上关系并不大。我先把结论摆出来一个典型的AI应用从下往上大致可以切成五层——算力与驱动层、推理运行时层、模型服务层、应用编排层、业务交互层。DeepSeek昇腾组件开源主要影响的是下面三层上面两层基本可以原样保留。很多人一听到迁移就头大是因为把整栋楼当成一个整体在搬实际上你只需要换地基和承重结构家具和装修风格完全可以不动。这里有个容易被忽略的点迁移的粒度不是按应用划分的而是按依赖划分的。同一个应用里可能有的模块迁移成本极低比如纯Python的业务逻辑有的模块迁移成本极高比如用了特定算子融合的推理加速代码。所以第一步不是急着动手改代码而是先做一次依赖盘点把每个模块跟硬件的耦合程度标出来。我一般会用一个简单的三分法来标记强耦合直接调用了特定芯片的运行时API、自定义算子、专用通信库这部分必须改。弱耦合通过标准接口比如OpenAI兼容的HTTP接口调用模型底层换什么芯片对它透明这部分基本不用动。无耦合纯业务逻辑、数据库操作、前端页面跟算力完全无关这部分一行都不用改。做完这个盘点你会发现真正需要投入精力的地方往往只占整个代码库的20%到30%。剩下的部分迁移的本质其实是重新部署而不是重写。提示依赖盘点阶段不要只看代码还要看配置文件、环境变量、Docker镜像里的基础层、CI/CD流水线里的构建脚本。很多迁移翻车不是因为代码没改对而是因为某个环境变量指向了旧的运行时路径。2. 推理运行时层迁移的主战场2.1 为什么这一层最难搬推理运行时层是整个迁移过程中最硬的一块骨头。它负责把模型权重加载进显存、管理KV Cache、调度请求批次、执行算子计算。这一层跟硬件的绑定最深因为不同芯片的显存结构、算子实现、通信拓扑都不一样。DeepSeek模型本身是Transformer架构核心计算是大规模的矩阵乘法和注意力机制。在通用GPU上这些计算有成熟的CUDA内核和cuBLAS库支撑。换到昇腾平台对应的就是CANNCompute Architecture for Neural Networks这套软件栈以及它提供的算子库和通信库。关键差异不在于能不能算而在于算得对不对、快不快。我实测下来迁移推理运行时层主要有三条路径成本从高到低排列迁移路径适用场景工作量风险点基于开源组件重新编译适配需要深度定制推理逻辑高算子兼容性、精度对齐使用官方提供的推理框架标准模型部署中版本匹配、配置调优通过标准API间接调用只关心模型输出低功能受限、延迟不可控2.2 算子对齐是第一个坎Transformer里的算子看起来标准但实际实现差异很大。比如LayerNorm不同框架对epsilon的处理、对数值精度的处理都不一样。再比如注意力机制里的softmax在长序列场景下数值稳定性处理方式不同可能导致输出结果的细微偏差。这些偏差在单次推理里可能看不出来但在需要严格复现的场景下就是问题。我的做法是先跑通一个最小可验证单元拿一段固定的输入文本在原始环境和迁移后环境分别跑一遍逐层对比中间激活值。不要一上来就跑完整模型那样出了问题根本定位不到是哪一层。具体操作上我会构造一个包含典型输入的测试集覆盖短文本、长文本、特殊字符、多轮对话等场景。然后在两个环境里分别导出每一层的输出用余弦相似度或者最大绝对误差来衡量对齐程度。一般来说误差在1e-3量级以内是可以接受的超过这个量级就要查是哪个算子的问题。2.3 显存管理的坑比想象中多昇腾平台的显存管理机制跟通用GPU有差异。最典型的是显存碎片问题。在长时间运行的服务里如果请求的序列长度变化很大显存分配器可能产生大量碎片最终导致明明总显存够用却分配失败。我踩过的一个坑是模型加载时预留的显存比例设得太满导致运行时没有足够的余量处理动态shape。解决办法是留出至少15%到20%的显存余量并且在服务启动参数里显式配置显存分配策略。另外KV Cache的管理也要注意如果用的是分页注意力机制页大小设置不合理会显著影响吞吐。还有一个容易被忽略的点是多卡通信。如果模型大到需要多卡并行通信库的选择和配置就变得关键。昇腾平台有自己的集合通信库跟通用GPU上的方案在API层面不完全一样。迁移时需要确认通信拓扑、带宽配置、以及是否支持你需要的并行策略张量并行、流水线并行等。3. 模型服务层接口兼容比性能更重要3.1 把模型服务当成一个黑盒模型服务层是推理运行时之上、应用编排之下的那一层。它的职责是接收请求、做预处理、调用推理引擎、做后处理、返回结果。这一层迁移的核心原则是尽量把它做成一个黑盒让上层应用感知不到底层变化。具体做法是保持接口协议不变。如果你的应用之前是通过HTTP接口调用模型服务迁移后依然保持同样的接口路径、同样的请求体格式、同样的响应体格式。这样上层应用一行代码都不用改。我见过太多迁移项目明明只需要换底层结果把接口协议也一起改了导致上层所有调用方都要跟着改工作量翻了好几倍。3.2 批处理策略需要重新调批处理是提升推理吞吐的关键手段但不同硬件平台的最优批处理策略不一样。通用GPU上可能适合较大的批大小因为并行计算单元多昇腾平台的并行结构不同最优批大小可能更小但可以通过更高的并发请求数来弥补。我一般会做一个简单的压测矩阵固定输入长度变化批大小比如1、2、4、8、16测量吞吐和延迟。找到吞吐开始下降或者延迟开始飙升的拐点那就是这个平台上的最优批大小。这个值跟模型大小、序列长度、显存容量都有关系没有万能公式必须实测。另外要注意动态批处理的实现。如果你的服务支持动态批处理把不同时刻到达的请求攒成一批迁移后要重新验证批处理窗口的设置。窗口太短攒不够请求吞吐上不去窗口太长延迟增加用户体验下降。这个平衡点在不同平台上是不一样的。3.3 精度与性能的取舍推理时用的数值精度直接影响性能和显存占用。常见的精度选项有FP32、FP16、BF16、INT8等。迁移到新平台后需要确认目标平台支持哪些精度以及每种精度下的实际性能表现。我的经验是先保证精度对齐再优化性能。先用FP16或者BF16跑通确认输出结果跟原始环境一致然后再尝试更低精度。如果直接上INT8出了问题很难判断是量化误差还是算子实现问题。还有一个细节是累加精度。即使输入是FP16累加过程如果用FP32结果会更稳定。不同平台对累加精度的默认处理可能不同需要在配置里显式指定。4. 应用编排层这里才是迁移的主战场4.1 编排逻辑跟硬件无关应用编排层是很多人忽略的地方但它其实是迁移过程中工作量最大的部分。这一层包含提示词模板、上下文管理、工具调用、多轮对话状态维护、RAG检索逻辑等等。这些东西跟底层跑在什么芯片上完全无关但它们是AI应用的核心价值所在。我之所以说这里是主战场是因为迁移项目里80%的代码改动其实发生在这里。不是因为硬件变了要改而是因为迁移是一个重新审视和优化编排逻辑的好机会。很多应用在早期快速迭代时积累了大量技术债编排逻辑混乱、提示词硬编码、上下文管理没有统一抽象。迁移的时候正好一并重构。4.2 提示词工程的平台无关性提示词是AI应用里最软的部分但它的效果高度依赖于模型本身。DeepSeek模型有自己的提示词偏好比如对系统提示的响应方式、对few-shot示例的敏感度、对输出格式的遵循程度。迁移到昇腾平台后如果用的还是同一个DeepSeek模型提示词基本不用改但如果换了模型版本或者量化方式提示词可能需要微调。我的做法是建立一个提示词回归测试集收集一批典型用户输入记录原始环境下的模型输出迁移后跑同样的输入对比输出质量。如果发现某些场景下输出质量下降再针对性调整提示词。4.3 上下文管理的重新设计上下文管理是AI应用里最容易被低估的部分。它涉及对话历史怎么存、怎么截断、怎么压缩、怎么检索。迁移到新平台后如果推理服务的上下文窗口大小变了或者KV Cache的管理方式变了上下文管理策略也要跟着调整。举个例子原来模型支持32K上下文你可以在对话历史里保留很多轮。迁移后如果实际可用的上下文窗口变小了就需要更激进的截断策略或者引入摘要压缩机制。这些改动都在应用编排层跟底层硬件无关但直接影响用户体验。5. 业务交互层基本不用动但要验证5.1 前端和API网关的稳定性业务交互层包括前端页面、移动端App、API网关、鉴权、限流、日志、监控等等。这一层跟AI模型的关系最远迁移时基本不需要改动。但有一个前提模型服务的接口协议保持不变。只要接口不变前端和网关就感知不到底层变化。我一般会在迁移完成后做一轮端到端的回归测试覆盖主要的用户路径。重点验证请求延迟是否在可接受范围内、错误率是否正常、超时重试逻辑是否正常工作、日志和监控是否能正确采集到新环境的数据。5.2 监控指标的重新校准迁移后监控指标需要重新校准。原来在通用GPU上你可能关注GPU利用率、显存占用、温度等指标。迁移到昇腾平台后对应的指标名称和采集方式可能不同。需要确保监控系统能正确采集新平台的指标并且告警阈值要重新设置。我踩过的一个坑是迁移后没有及时更新告警阈值结果因为新平台的正常波动触发了大量误报运维团队被折腾了好几天。建议迁移后先观察一周收集正常运行的指标基线再据此设置告警阈值。5.3 成本模型的重新计算迁移到新平台后成本模型也要重新算。不只是硬件采购成本还包括运维成本、电力成本、机房空间成本等。昇腾平台在能效比上可能有优势但软件生态的成熟度可能不如通用GPU这意味着运维人力成本可能更高。我一般会做一个简单的TCO总拥有成本对比表把硬件、软件、人力、电力、机房等各项成本列出来按三年周期计算。这个表不需要很精确但能帮你判断迁移在经济上是否划算。6. 迁移后的验证与调优6.1 功能验证的完整清单迁移完成后功能验证不能只跑几个demo就完事。我一般会准备一个完整的验证清单覆盖以下维度基础功能模型能否正常加载、能否正常推理、输出格式是否正确。边界场景超长输入、空输入、特殊字符、多语言混合。并发场景多请求同时到达时的表现、批处理是否正确工作。异常场景请求超时、显存不足、网络中断时的错误处理。性能指标吞吐、延迟、显存占用、CPU占用。每个维度都要有明确的通过标准不能凭感觉判断。6.2 性能调优的优先级性能调优要有优先级不要一上来就抠细节。我的优先级排序是先保证正确性输出结果跟原始环境一致这是底线。再保证稳定性长时间运行不崩溃、不泄漏、不降级。然后优化吞吐通过批处理、并发、缓存等手段提升单位时间处理量。最后优化延迟通过算子优化、精度调整、流水线并行等手段降低单次请求延迟。这个顺序不能乱。如果正确性都没保证就去优化性能优化出来的结果可能是错的白费功夫。6.3 持续迭代的心态迁移不是一次性的项目而是一个持续迭代的过程。新平台在早期可能有一些不完善的地方随着软件栈的更新会逐步改善。我的建议是建立一个迁移后的持续观察机制定期收集性能数据、用户反馈、错误日志发现瓶颈就针对性优化。另外保持跟社区和官方的沟通也很重要。很多坑别人已经踩过了只是你还不知道。多看看技术社区的讨论能少走很多弯路。7. 一些实操中的经验教训7.1 不要追求一步到位我见过最典型的失败案例就是想把整个系统一次性全部迁移过去。结果迁移过程中问题层出不穷团队疲于奔命最后项目延期好几个月。正确的做法是分阶段迁移先迁移一个非核心的、流量小的服务跑通整个流程积累经验再逐步迁移核心服务。7.2 保留回滚能力迁移过程中一定要保留回滚能力。万一新环境出了问题能快速切回旧环境。这要求你在迁移期间保持两套环境并行运行并且数据要能双向同步。虽然成本高一点但这是保险绳不能省。7.3 文档和知识沉淀迁移过程中会遇到各种问题解决之后一定要记录下来。不只是记录怎么解决的还要记录为什么会出现这个问题、下次怎么避免。这些经验是团队最宝贵的资产比任何官方文档都有价值。7.4 关注社区动态DeepSeek和昇腾的生态都在快速演进今天遇到的问题可能明天就有官方解决方案了。保持对社区动态的关注能帮你省下大量重复造轮子的时间。我一般会定期看几个关键渠道官方仓库的issue区、技术社区的讨论帖、以及一些活跃开发者的分享。8. 回到最初的问题究竟能迁移哪一部分绕了一大圈回到标题的问题。我的答案是你的AI应用里跟硬件强绑定的部分推理运行时层需要重点迁移工作量占比约20%到30%模型服务层需要适配但接口可以保持不变工作量占比约10%到20%应用编排层和业务交互层基本可以原样保留工作量占比约50%到70%。这个比例不是绝对的取决于你的应用架构有多干净。如果你的应用从一开始就做好了分层抽象迁移成本会低很多如果是一坨意大利面式的代码那迁移就是一次痛苦的重构。我个人在实际操作中的体会是迁移的最大价值不在于换了什么硬件而在于借这个机会把系统重新梳理了一遍。很多在迁移过程中发现的问题其实跟硬件无关是架构本身的问题。把这些理顺了不管跑在什么平台上系统都会更健康。最后分享一个小技巧在迁移开始之前先画一张依赖关系图把每个模块跟硬件的耦合程度标出来。这张图不用很精确但能帮你快速判断哪些地方需要投入精力哪些地方可以放心跳过。我每次做迁移项目这张图都是第一步也是最有用的一步。