企业官网建设流程全解析

个人免费网站创建入口,上海网站推荐,三亚高端服务网站,江苏南京最新通告文章目录1. 前言#xff1a;为什么选择Qwen2.5与昇腾#xff1f;2. 环境准备2.1 获取昇腾算力资源2.2 环境深度验证2.3 安装核心依赖3. 模型下载#xff08;Git LFS高速通道#xff09;4. 部署实战#xff1a;基于Torch-NPU的原生推理4.1 编写推理脚本 inference_npu.py4.…文章目录1. 前言为什么选择Qwen2.5与昇腾2. 环境准备2.1 获取昇腾算力资源2.2 环境深度验证2.3 安装核心依赖3. 模型下载Git LFS高速通道4. 部署实战基于Torch-NPU的原生推理4.1 编写推理脚本 inference_npu.py4.2 运行结果分析5. 进阶生成稳定性与显存压力测试5.1 编写测试脚本 benchmark_npu.py5.2 测试结果与分析5.3 进阶测试显存占用监控5.4 极限挑战高并发下的显存与吞吐量压测1. 编写极限压测脚本 benchmark_extreme_npu.py2. 压测结果分析3. 探底极限NPU OOM 临界点测试5.5 开发者实战感悟关于“动态Shape”的性能抖动6. 常见问题与踩坑总结 (Troubleshooting)Q1: 内存碎片导致OOM (RuntimeError: NPU out of memory)Q2: 首次推理极慢或卡死Q3: 报错 ImportError: cannot import name TeQuantizer ...总结1. 前言为什么选择Qwen2.5与昇腾眼下这国产化大潮是越来越猛了昇腾Ascend算力卡俨然成了咱们国内AI圈的中流砥柱。而Qwen2.5通义千问作为阿里开源的“最强”系列模型在各项基准测试里那是相当能打尤其是7B这个版本性能不错显存占用还不大简直是为开发者上手的“梦中情模”。这次咱们直接拿Qwen2.5-7B-Instruct当主角手把手带大家走一遍在AtomGit Notebook上的部署全流程。从搭环境、下模型、写推理代码到用torch_npu跑原生推理和性能测试最后再聊聊踩过的坑。目的就一个整出一篇能复现、有干货的技术实战指南。文章目录1. 前言为什么选择Qwen2.5与昇腾2. 环境准备2.1 获取昇腾算力资源2.2 环境深度验证2.3 安装核心依赖3. 模型下载Git LFS高速通道4. 部署实战基于Torch-NPU的原生推理4.1 编写推理脚本 inference_npu.py4.2 运行结果分析5. 进阶生成稳定性与显存压力测试5.1 编写测试脚本 benchmark_npu.py5.2 测试结果与分析5.3 进阶测试显存占用监控5.4 极限挑战高并发下的显存与吞吐量压测1. 编写极限压测脚本 benchmark_extreme_npu.py2. 压测结果分析3. 探底极限NPU OOM 临界点测试5.5 开发者实战感悟关于“动态Shape”的性能抖动6. 常见问题与踩坑总结 (Troubleshooting)Q1: 内存碎片导致OOM (RuntimeError: NPU out of memory)Q2: 首次推理极慢或卡死Q3: 报错 ImportError: cannot import name TeQuantizer ...总结2. 环境准备想在昇腾平台上把AI模型跑得溜第一步得先搞定开发环境。AtomGitGitCode提供的云端Notebook服务正好能解燃眉之急而且它是开箱即用的昇腾环境都给配好了。2.1 获取昇腾算力资源大家先登录GitCode平台点一下右上角的头像选那个 “我的 Notebook”。如果是第一次来的朋友系统给的免费试用额度还是挺足的。在创建Notebook实例的时候千万别手抖一定要照着下面的配置选不然兼容性可能会出问题计算资源选NPU basic · 1 * NPU 910B · 32v CPU · 64GB说明这里使用的是昇腾 Atlas 800T A2训练/推理服务器搭载 Atlas 800T 处理器算力非常强劲。注意这一步必须选NPU资源要是选了CPU后面的torch_npu代码是跑不起来的。系统镜像选euler2.9-py38-torch2.1.0-cann8.0-openmind0.6-notebook这个镜像里 Python 3.8、PyTorch 2.1.0 (Ascend适配版)、CANN 8.0 驱动这些都已经装好了省得咱们再去折腾驱动安装那些麻烦事。存储配置建议选50GB的存储空间大模型文件毕竟不小大点儿保险。点完“立即启动”稍微等几分钟就能进到JupyterLab界面了。2.2 环境深度验证打开终端Terminal咱们先给环境做个“体检”这一步很关键得确保NPU和PyTorch版本是对得上的。1. 检查NPU物理状态npu-smi info这时候应该能看到Atlas 800T显卡的信息而且显存Memory-Usage应该是空的。2. 验证PyTorch与NPU适配在终端里跑一下这个Python单行脚本# 检查PyTorch版本python -cimport torch; print(fPyTorch版本: {torch.__version__})# 检查torch_npu版本python -cimport torch_npu; print(ftorch_npu版本: {torch_npu.__version__})# 验证NPU可用性python -cimport torch; import torch_npu; print(fNPU Available: {torch.npu.is_available()})这儿有几个关键点得盯着PyTorch版本得是2.1.0或者更高。torch.npu.is_available()必须得返回True不然就没法玩了。2.3 安装核心依赖虽说基础镜像里已经带了Torch但要跑Qwen2.5这种新模型transformers和accelerate库还得是用最新的。强烈建议大家用清华源或者阿里源来下载速度快不少。# 升级transformers以支持Qwen2.5 (必须大于4.37)pipinstall--upgrade transformers accelerate -i https://pypi.tuna.tsinghua.edu.cn/simple3. 模型下载Git LFS高速通道因为modelscope的Python库在Python 3.8环境下有时候会闹别扭比如报个TypeError啥的为了稳妥起见咱们直接用Git LFS (Large File Storage)从ModelScope仓库把模型克隆下来。这种方式不挑Python版本而且自带断点续传在Notebook环境里用起来特别顺手。1. 初始化Git LFS在终端里敲这行命令确把LFS装好gitlfsinstall只要看到输出Git LFS initialized.就妥了。2. 克隆模型仓库咱们把模型下到当前目录下的models文件夹里# 创建存储目录mkdir-p models/Qwen# 使用Git Clone下载 (ModelScope国内线路速度极快)gitclone https://www.modelscope.cn/Qwen/Qwen2.5-7B-Instruct.git ./models/Qwen/Qwen2.5-7B-Instruct提醒一句下载的时候网别断。万一断了进到目录里敲个git lfs pull就能接着下。下载完事儿后模型就在./models/Qwen/Qwen2.5-7B-Instruct这个位置。大家把这个路径记一下待会儿写推理脚本的时候要用的。4. 部署实战基于Torch-NPU的原生推理这一步咱们直接用HuggingFace原生的transformers库配合torch_npu来跑推理。4.1 编写推理脚本inference_npu.py这里有几个代码优化的小细节要注意得显式地指定devicenpu。用torch.bfloat16Atlas 800T对BF16支持比较好还能防溢出。加上torch.npu.synchronize()不然计时可能不准。importtorchimporttorch_npufromtransformersimportAutoTokenizer,AutoModelForCausalLMimporttime# 1. 配置路径与设备DEVICEnpuMODEL_PATH./models/Qwen/Qwen2.5-7B-Instruct# 请确保路径与下载时一致print(fLoading model from{MODEL_PATH}...)# 2. 加载TokenizertokenizerAutoTokenizer.from_pretrained(MODEL_PATH,trust_remote_codeTrue)# 3. 加载模型到NPU# Atlas 800T推荐使用 bfloat16modelAutoModelForCausalLM.from_pretrained(MODEL_PATH,device_mapDEVICE,torch_dtypetorch.bfloat16,trust_remote_codeTrue)print(Model loaded successfully!)# 4. 构造Promptprompt请用Python写一个快速排序算法并解释其原理。messages[{role:system,content:You are a helpful assistant.},{role:user,content:prompt}]texttokenizer.apply_chat_template(messages,tokenizeFalse,add_generation_promptTrue)model_inputstokenizer([text],return_tensorspt).to(DEVICE)# 5. 推理生成print(Generating response...)# NPU是异步执行的计时前需要同步torch.npu.synchronize()start_timetime.time()generated_idsmodel.generate(model_inputs.input_ids,max_new_tokens512,do_sampleTrue,temperature0.7,top_p0.9)# 计时结束同步torch.npu.synchronize()end_timetime.time()# 6. 解码输出generated_ids[output_ids[len(input_ids):]forinput_ids,output_idsinzip(model_inputs.input_ids,generated_ids)]responsetokenizer.batch_decode(generated_ids,skip_special_tokensTrue)[0]print(-*20 Output -*20)print(response)print(-*20 Stats -*20)print(fTime taken:{end_time-start_time:.2f}s)4.2 运行结果分析跑一下脚本python inference_npu.py看看实际运行结果参考看看输出日志咱们能确认这么几件事儿模型加载成功日志里打出了Model loaded successfully!而且关于“快速排序算法”的代码和原理解释都出来了逻辑没毛病说明 Qwen2.5 在 NPU 上脑子很清醒。首次运行耗时JIT编译截图里那个Time taken: 31.59 s其实是包含了模型推理时间外加**首次算子编译Operator Compilation**的时间。在昇腾架构里第一次跑 PyTorch 代码的时候CANN 会自动去编译和优化计算图里的算子。这是正常操作。预期优化你要是再跑一次同样的脚本因为算子已经缓存了耗时立马就能降下来通常几秒钟就完事。结论脚本跑得挺顺没报 Traceback 错误生成的内容也对路这标志着 Qwen2.5-7B 在Atlas 800T 上算是部署成功了5. 进阶生成稳定性与显存压力测试光跑通了还不行咱们得看看NPU的性能到底咋样。下面这个脚本能算出Tokens/s (TPS)而且我还加了个 Warmup预热环节模拟真实的服务状态。5.1 编写测试脚本benchmark_npu.pyimporttorchimporttorch_npufromtransformersimportAutoTokenizer,AutoModelForCausalLMimporttime DEVICEnpuMODEL_PATH./models/Qwen/Qwen2.5-7B-Instructprint(Loading model...)tokenizerAutoTokenizer.from_pretrained(MODEL_PATH,trust_remote_codeTrue)modelAutoModelForCausalLM.from_pretrained(MODEL_PATH,device_mapDEVICE,torch_dtypetorch.bfloat16,trust_remote_codeTrue)# ----------------- 预热 (Warmup) -----------------# 目的触发算子编译填充缓存print(Warming up (compiling operators)...)dummy_inputtokenizer(Hello world,return_tensorspt).to(DEVICE)model.generate(**dummy_input,max_new_tokens20)torch.npu.synchronize()print(Warmup done.)# ----------------- 正式测试 -----------------prompt作为一名资深导游请详细介绍一下北京故宫的旅游攻略包括必去景点、路线规划和注意事项字数不少于500字。inputstokenizer(prompt,return_tensorspt).to(DEVICE)input_leninputs.input_ids.shape[1]print(Starting Benchmark...)torch.npu.synchronize()start_timetime.time()outputmodel.generate(**inputs,max_new_tokens512,do_sampleFalse,# 使用Greedy Search以获得稳定性能指标use_cacheTrue)torch.npu.synchronize()end_timetime.time()# ----------------- 结果计算 -----------------total_tokensoutput.shape[1]new_tokenstotal_tokens-input_len elapsed_timeend_time-start_time tpsnew_tokens/elapsed_timeprint(f\n{*20}Benchmark Report{*20})print(fInput Tokens:{input_len})print(fGenerated Tokens:{new_tokens})print(fTotal Time:{elapsed_time:.4f}s)print(fThroughput:{tps:.2f}tokens/s)print(f{*58})5.2 测试结果与分析脚本跑完之后我们主要关注以下几个关键指标以验证环境的稳定性来解读一下这几个关键指标生成完整性 (Generated Tokens)结果代码设置了max_new_tokens512模型成功生成了满额的 token期间没有出现中断或报错。这证明了在Atlas 800T上Qwen2.5-7B 进行长文本推理是完全稳定的。预热机制 (Warmup)结果日志显示Warmup done说明算子编译JIT机制正常工作。在预热完成后后续的推理过程非常平滑没有出现首次运行时的卡顿现象。5.3 进阶测试显存占用监控在实际干活的时候除了速度咱们最担心的就是显存爆没爆。Atlas 800T这显存可是够大的32GB/64GB跑个7B模型那叫一个宽裕。咱们改几行代码就能精确监控峰值显存# 在推理结束后end_time time.time() 之后加入以下代码max_memorytorch.npu.max_memory_allocated()/1024/1024/1024print(fPeak NPU Memory:{max_memory:.2f}GB)看看实测结果参考深度解析一下这个数据Peak NPU Memory: 14.29 GB数据解读这个数是模型权重 (Weights)KV Cache推理时的临时激活值 (Activations)加起来的总和。资源利用率Qwen2.5-7B (BF16) 光权重大概就得占 14GB 左右。显示峰值才 14.29 GB说明在 batch_size1, input_len30 这种轻量级测试里额外的显存开销几乎可以忽略不计。潜力评估余量充足对于 32GB 显存的 Atlas 800T 卡来说咱们还剩下大概17GB的空闲地盘。扩容建议这 17GB 的“富余”意味着咱们完全可以搞点大动作把Batch Size加到 16 甚至 32吞吐量直接起飞。部署参数量更大的14B 模型通常占 ~28GB 显存刚好能塞进单卡。上vLLM框架把这些空闲显存当成 PagedAttention 的 KV Cache 池支持数千 token 的超长文本推理。性能稳定性验证在持续的显存监控过程中推理过程非常平稳说明 NPU 热身之后输出那是相当稳定的。5.4 极限挑战高并发下的显存与吞吐量压测既然官方给到了64GB 显存的豪华配置而 Qwen2.5 采用了 GQA分组查询注意力技术极大地节省了显存普通的 Batch Size 根本“喂不饱”这块卡。为了探探这块卡的底咱们搞个地狱级压测构造长文本输入输入长度拉到 1024 tokens。超大 Batch Size直接拉到64甚至更高。1. 编写极限压测脚本benchmark_extreme_npu.pyimporttorchimporttorch_npufromtransformersimportAutoTokenizer,AutoModelForCausalLMimporttime DEVICEnpuMODEL_PATH./models/Qwen/Qwen2.5-7B-Instructprint(Loading model...)tokenizerAutoTokenizer.from_pretrained(MODEL_PATH,trust_remote_codeTrue)tokenizer.pad_token_idtokenizer.eos_token_id modelAutoModelForCausalLM.from_pretrained(MODEL_PATH,device_mapDEVICE,torch_dtypetorch.bfloat16,trust_remote_codeTrue)# ----------------- 极限构造 -----------------# 1. 构造一个长 Prompt (约 1000 tokens)long_promptExplain the theory of relativity in detail. *50# 2. 设置超大 Batch Size (针对 64GB 显存)BATCH_SIZE64print(fPreparing inputs for Batch Size {BATCH_SIZE}with Long Context...)input_list[long_prompt]*BATCH_SIZE inputstokenizer(input_list,return_tensorspt,paddingTrue,max_length2048,truncationTrue).to(DEVICE)input_leninputs.input_ids.shape[1]print(fInput Sequence Length:{input_len}tokens)# 预热print(Warming up...)model.generate(**inputs,max_new_tokens10,do_sampleFalse)torch.npu.synchronize()print(Starting Extreme Benchmark...)torch.npu.synchronize()start_timetime.time()outputmodel.generate(**inputs,max_new_tokens256,do_sampleFalse# 压测通常关闭采样)torch.npu.synchronize()end_timetime.time()# 显存监控max_memorytorch.npu.max_memory_allocated()/1024**3# 计算结果total_new_tokens(output.shape[1]-input_len)*BATCH_SIZE elapsed_timeend_time-start_time tpstotal_new_tokens/elapsed_timeprint(f\n{*20}Extreme Benchmark Report{*20})print(fBatch Size:{BATCH_SIZE})print(fInput Length:{input_len})print(fPeak NPU Memory:{max_memory:.2f}GB)print(fTotal Generated Tokens:{total_new_tokens})print(fTotal Time:{elapsed_time:.4f}s)print(fSystem Throughput:{tps:.2f}tokens/s)print(f{*64})2. 压测结果分析数据解读深不见底的显存潜力 (20.38 GB)这结果属实让人惊讶即便我们把Batch Size 拉到了 64输入长度也接近 500 tokens显存占用竟然才刚刚突破20GB仅占总显存的 30%。原因这得益于 Qwen2.5 优秀的GQA (Grouped Query Attention)显存优化技术以及 Atlas 800T 庞大的 64GB 显存池。结论这意味着在生产环境下这块卡理论上能支撑Batch Size 200的超高并发或者处理32k级别的超长上下文硬件上限深不可测。吞吐量狂飙 (785 tokens/s)相比单 Batch系统整体吞吐量提升了十几倍。每秒能生成近 800 个 token足以支撑一个中型规模的 AI 对话服务集群。3. 探底极限NPU OOM 临界点测试我们进一步尝试将Batch Size 拉升至 128且Input Length 增加至 1800试图彻底“榨干”显存。结果在显存分配阶段触发了 OOM 保护RuntimeError: NPU out of memory. Tried to allocate 21.68 GiB (NPU 0; 60.97 GiB total capacity; 44.94 GiB already allocated...实战结论与建议安全水位线在64GB 显存的 Atlas 800T 上部署 Qwen2.5-7B (BF16) 的最佳并发区间建议控制在Batch Size 64 ~ 96之间。极限性能在此区间内既能享受到700 tokens/s的极致吞吐又能保证显存有 30% 左右的安全余量防止突发长文本导致的 OOM。5.5 开发者实战感悟关于“动态Shape”的性能抖动在反复折腾测试的时候你可能会碰上个挺有意思的现象当你改了输入Prompt的长度推理怎么突然变慢了这就是昇腾 NPU 在开发过程中最常见的一个“坑”也是它的架构特性决定的——算子编译JIT Compilation。现象第一次输 10 个 token慢吞吞第二次输 10 个 token嗖嗖的。但第三次输 100 个 token又变慢了。原因NPU 得针对不同的 Input Shape输入形状去编译计算图。如果输入的长度老在变CANN 就得苦哈哈地不停编译。实战建议别慌卡没坏代码也没写错。生产环境策略在实际业务里通常会用“分桶Bucketing”或者“Padding”把输入长度固定在几个档位比如 128, 512, 1024这样就能避免反复编译性能也就稳了。6. 常见问题与踩坑总结 (Troubleshooting)Q1: 内存碎片导致OOM (RuntimeError: NPU out of memory)现象模型加载了一半或者生成长文本的时候突然报错但npu-smi一看物理显存明明还有空地儿。原因PyTorch原生的内存分配器在NPU上可能会产生碎片。解决方案设个环境变量PYTORCH_NPU_ALLOC_CONF限制一下内存块切分的大小。# 在终端执行或加入 .bashrcexportPYTORCH_NPU_ALLOC_CONFmax_split_size_mb:128Q2: 首次推理极慢或卡死原因昇腾架构的“静态图/动态图”算子编译机制。只要遇到新shape的输入底层编译就会触发。解决方案耐心等待正常现象让它飞一会儿。固定Shape生产环境里尽量固定输入长度或者用分档Bucketing来减少编译次数。Q3: 报错ImportError: cannot import name TeQuantizer ...原因transformers版本太老了跟Qwen2.5的代码八字不合。解决方案pip install --upgrade transformers升级一下就好。总结这篇文章咱们详细跑了一遍Qwen2.5-7B-Instruct在AtomGit (Atlas 800T)环境下的部署全流程。事实证明只要环境配置对路、用ModelScope下载、配合Torch-NPU原生推理国产算力跑最新的开源大模型完全没压力。最后再划个重点环境EulerOS CANN 8.0 是目前的“黄金搭档”。代码记得加torch.npu.synchronize()不然性能耗时都不准。调优BF16 FlashAttention 是提升性能的关键法宝。作者简介本文作者为AI技术专家专注于大型语言模型和国产AI芯片的应用研究具有丰富的开发经验。版权声明本文内容基于开源协议欢迎转载和分享请注明出处。联系方式如有技术问题或合作需求欢迎通过GitCode平台联系作者。免责声明本文基于实际测试数据编写所有代码和配置均经过验证。重点在于给社区开发者传递基于昇腾跑通和测评的方法和经验欢迎开发者在本模型基础上交流优化