Lingbot-Depth-Pretrain-Vitl-14 性能优化利用GPU算力提升推理速度你肯定遇到过这种情况深度估计模型跑起来慢吞吞的处理一张图要等好几秒要是批量处理一堆图片那更是等到花儿都谢了。尤其是在做实时应用或者需要处理大量数据的场景下这个速度简直让人抓狂。我之前部署了 Lingbot-Depth-Pretrain-Vitl-14 来做场景深度估计模型效果不错但推理速度成了瓶颈。后来我花了一些时间在星图GPU平台上折腾摸索出了一套从模型转换到运行时调优的“组合拳”成功把推理速度提升了好几倍而且成本还控制得不错。今天这篇文章我就把这些实战经验分享给你。咱们不聊那些空洞的理论直接上干货手把手教你如何利用GPU算力让这个深度估计模型“飞”起来。无论你是刚接触模型部署的新手还是正在为性能发愁的开发者相信都能找到有用的技巧。1. 优化前的准备理解瓶颈在哪里在开始动手优化之前咱们得先搞清楚模型跑得慢问题到底出在哪儿。盲目优化就像蒙着眼睛修车可能费了半天劲效果却不明显。对于 Lingbot-Depth-Pretrain-Vitl-14 这类视觉模型推理速度的瓶颈通常来自几个方面计算密集型操作模型里大量的卷积、注意力机制等操作需要强大的算力支持。如果你的GPU性能不足或者代码没有充分利用GPU这里就会卡住。内存带宽限制模型参数、中间计算结果都需要在GPU显存里搬来搬去。如果数据搬运的效率不高GPU再强的算力也得等着“喂数据”这就是所谓的内存墙。框架与运行时开销你用的推理框架比如PyTorch、数据加载方式、前后处理逻辑都可能引入额外的延迟。有时候模型本身计算很快但被这些“外围”工作拖累了。批处理策略不当一次只处理一张图Batch Size1GPU的并行计算能力就浪费了。但批处理太大显存又可能爆掉。如何找到这个平衡点是个技术活。所以我们的优化思路也要对症下药一是让模型本身的计算更高效比如用TensorRT转换二是让计算资源利用率更高比如调Batch Size、用半精度三是减少不必要的开销。接下来我们就从这几个方面逐一突破。2. 第一板斧使用TensorRT转换与加速如果你想让模型在GPU上跑出极致速度TensorRT几乎是绕不开的工具。它是专门为NVIDIA GPU设计的高性能推理优化器能对模型进行层融合、精度校准、内核自动调优等一系列“魔法操作”。2.1 为什么选择TensorRT简单来说TensorRT主要干三件事优化网络结构把一些能合并的计算层合并起来减少内存访问次数和内核启动开销。选择最优内核针对你的具体GPU型号比如V100、A100、RTX 4090自动选择计算最快的内核实现。动态调整精度支持FP16半精度甚至INT8整型推理在精度损失很小的前提下大幅提升计算速度和减少显存占用。对于 Lingbot-Depth-Pretrain-Vitl-14 这种固定结构的模型经过TensorRT优化后通常能有1.5倍到3倍甚至更高的速度提升。2.2 动手转换从PyTorch到TensorRT假设你的模型原本是用PyTorch加载的。转换过程并不复杂但需要一些步骤。这里我提供一个清晰的路径。首先确保你的环境里安装了必要的库pip install torch torchvision pip install nvidia-pyindex pip install tensorrt # 还需要安装对应的 cuDNN 和 CUDA Toolkit版本要匹配转换的核心思路是先将PyTorch模型导出为ONNX格式一种通用的模型交换格式然后再用TensorRT的解析器将ONNX模型转换为高度优化的TensorRT引擎。下面是一段关键的转换代码示例import torch import tensorrt as trt import onnx # 1. 加载你训练好的PyTorch模型 # 假设你的模型类定义为 LingbotDepthModel model LingbotDepthModel(pretrainedTrue) model.eval() # 切换到评估模式 device torch.device(cuda) model.to(device) # 创建一个示例输入张量模拟一张图片 dummy_input torch.randn(1, 3, 480, 640).to(device) # [batch, channel, height, width] # 2. 导出模型到ONNX格式 onnx_model_path lingbot_depth.onnx torch.onnx.export( model, dummy_input, onnx_model_path, input_names[input], output_names[output], opset_version12, # 选择一个合适的ONNX算子集版本 dynamic_axes{input: {0: batch_size}}, # 支持动态batch size do_constant_foldingTrue ) print(f模型已导出至: {onnx_model_path}) # 3. 使用TensorRT构建引擎 logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) with open(onnx_model_path, rb) as f: if not parser.parse(f.read()): for error in range(parser.num_errors): print(parser.get_error(error)) # 设置构建配置 config builder.create_builder_config() config.max_workspace_size 1 30 # 1GB的临时工作空间 # 启用FP16精度以加速如果GPU支持 if builder.platform_has_fast_fp16: config.set_flag(trt.BuilderFlag.FP16) # 定义优化配置文件处理动态形状 profile builder.create_optimization_profile() profile.set_shape( input, # 输入张量名 min(1, 3, 480, 640), # 最小形状 opt(4, 3, 480, 640), # 最优形状TensorRT会为此形状做优化 max(16, 3, 480, 640) # 最大形状 ) config.add_optimization_profile(profile) # 构建引擎并序列化保存 serialized_engine builder.build_serialized_network(network, config) trt_engine_path lingbot_depth.engine with open(trt_engine_path, wb) as f: f.write(serialized_engine) print(fTensorRT引擎已保存至: {trt_engine_path})这段代码完成后你就得到了一个.engine文件。这个文件是专门针对你当前GPU优化过的后续推理直接加载它就行速度会比原版PyTorch模型快很多。3. 第二板斧调整批处理大小Batch Size模型转换完了接下来要从运行时找优化空间。调整批处理大小Batch Size是性价比最高的一招它直接决定了GPU的“饱腹感”。3.1 Batch Size的平衡艺术想象一下GPU是一个厨房计算核心是厨师。一次只炒一盘菜Batch Size1大部分厨师都在闲着。一次炒太多盘Batch Size很大厨房台面显存可能放不下或者厨师忙不过来导致出菜慢。我们的目标是找到那个“黄金点”在显存不溢出的前提下尽可能让GPU的计算核心保持忙碌从而摊薄处理每张图片的平均时间。3.2 如何找到最佳Batch Size没有放之四海而皆准的值你需要在自己的机器和模型上实测。下面是一个简单的寻找策略从1开始先测一下Batch Size1时的显存占用和单张图推理时间作为基线。逐步翻倍将Batch Size依次设置为2, 4, 8, 16... 每次增加后运行推理并记录显存占用是否接近GPU总显存留出约1GB安全余量。吞吐量每秒能处理的图片数Images Per Second, IPS。计算公式是Batch Size / 处理该批次的总时间。单张图延迟处理该批次所有图片的平均时间。观察拐点随着Batch Size增大吞吐量会先快速上升然后增速放缓最后可能持平甚至下降因为数据搬运或调度开销变大。那个增速开始明显放缓的点往往就是性价比最高的点。你可以写个简单的脚本来自动化这个测试过程import time import torch # 假设 trt_infer 是你写的一个用TensorRT引擎推理的函数 from your_inference_module import trt_infer def benchmark_batch_size(engine_path, image_list, batch_sizes[1, 2, 4, 8, 16]): results {} for bs in batch_sizes: # 准备批次数据这里假设image_list里是已经预处理好的张量 batches [image_list[i:ibs] for i in range(0, len(image_list), bs)] start_time time.time() for batch in batches: # 将batch中的图片堆叠成一个张量 batch_tensor torch.stack(batch).cuda() _ trt_infer(engine_path, batch_tensor) # 执行推理忽略输出 end_time time.time() total_time end_time - start_time total_images len(image_list) throughput total_images / total_time # 获取当前显存占用近似 torch.cuda.synchronize() mem_used torch.cuda.max_memory_allocated() / 1024**3 # 转换为GB results[bs] { throughput (ips): round(throughput, 2), total_time (s): round(total_time, 2), mem_used (GB): round(mem_used, 2) } torch.cuda.reset_peak_memory_stats() # 重置内存统计 print(fBatch Size {bs}: {results[bs]}) return results跑完这个测试你就能清晰地看到不同Batch Size下的表现然后做出选择。通常对于Lingbot-Depth这类模型在显存充足的卡上比如24GBBatch Size设为8或16往往能取得很好的吞吐量收益。4. 第三板斧启用半精度FP16推理现代GPU如Volta架构及以后对半精度浮点数FP16计算有专门的硬件加速单元速度可以比全精度FP32快很多同时显存占用直接减半。4.1 FP16安全吗精度损失大吗对于深度估计任务模型输出的是每个像素的深度值是一个回归问题。通常模型在训练时用的是FP32但推理时转为FP16精度损失非常微小人眼几乎无法察觉深度图的变化完全在可接受范围内。这是一种用极小的精度代价换取显著性能提升的经典手段。在上面的TensorRT转换代码里我们已经通过config.set_flag(trt.BuilderFlag.FP16)启用了FP16支持。TensorRT会自动处理层与层之间的精度转换并在内部使用FP16进行计算。4.2 检查与验证FP16效果引擎构建好后你可以通过TensorRT的API检查引擎是否真正使用了FP16或者在推理时验证结果。更直接的方法是对比开启FP16前后模型推理的速度和显存占用。你会发现吞吐量通常有显著的提升尤其是对于计算密集型的模型。5. 实战工具监控GPU利用率优化不是一劳永逸的你需要工具来验证优化效果并持续监控运行状态。光靠感觉不行得有数据。5.1 命令行利器nvidia-smi最基础也最强大的工具是nvidia-smi。在终端运行它你可以看到GPU利用率Volatile GPU-Util百分比表示GPU计算核心的忙碌程度。优化目标就是让这个值在推理期间稳定在较高水平如70%-95%。显存占用Memory-Usage确认你的Batch Size设置没有导致显存爆满。功耗与温度辅助判断GPU是否在高效工作。你可以使用watch -n 0.5 nvidia-smi来半秒刷新一次实时观察推理时的状态。5.2 Python中的监控在Python脚本里你也可以方便地获取这些信息import pynvml import time pynvml.nvmlInit() handle pynvml.nvmlDeviceGetHandleByIndex(0) # 0表示第一块GPU def get_gpu_info(): util pynvml.nvmlDeviceGetUtilizationRates(handle) mem_info pynvml.nvmlDeviceGetMemoryInfo(handle) return { gpu_util (%): util.gpu, mem_util (%): util.memory, mem_used (GB): mem_info.used / 1024**3 } # 在推理循环中定期打印 for batch in data_loader: start time.time() output infer(batch) end time.time() print(fInference time: {end-start:.3f}s, {get_gpu_info()})看到GPU利用率在推理时飙高显存占用稳定那说明你的优化工作正在见效GPU这颗“引擎”正在全力输出。6. 把这些技巧串起来一个完整的优化示例说了这么多我们来模拟一个完整的优化流程看看效果如何。场景在星图平台的一台配备 NVIDIA A1024GB显存的GPU服务器上优化Lingbot-Depth-Pretrain-Vitl-14模型处理一批100张室内场景图片的速度。原始状态PyTorch FP32, Batch Size1吞吐量~3.2 张/秒单张延迟~312 毫秒GPU利用率~25%波动大大量时间在等待优化步骤与效果应用TensorRT转换FP32模型计算图得到优化。效果吞吐量提升至 ~5.1 张/秒提升约60%。调整Batch Size至8更充分利用GPU并行能力。效果吞吐量跃升至 ~28 张/秒单张平均延迟降至 ~36 毫秒。GPU利用率稳定在75%左右。启用TensorRT FP16推理利用硬件加速。效果吞吐量进一步提升至 ~41 张/秒显存占用从11GB减少到6GB。GPU利用率达到90%以上。最终对比经过一套“组合拳”处理同样100张图片总时间从最初的约31秒缩短到了约2.4秒速度提升了近13倍。而GPU的成本因为处理速度大幅加快任务的总计费时长反而减少了实现了真正的降本增效。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
Lingbot-Depth-Pretrain-Vitl-14 性能优化：利用GPU算力提升推理速度
发布时间：2026/5/26 11:08:50
Lingbot-Depth-Pretrain-Vitl-14 性能优化利用GPU算力提升推理速度你肯定遇到过这种情况深度估计模型跑起来慢吞吞的处理一张图要等好几秒要是批量处理一堆图片那更是等到花儿都谢了。尤其是在做实时应用或者需要处理大量数据的场景下这个速度简直让人抓狂。我之前部署了 Lingbot-Depth-Pretrain-Vitl-14 来做场景深度估计模型效果不错但推理速度成了瓶颈。后来我花了一些时间在星图GPU平台上折腾摸索出了一套从模型转换到运行时调优的“组合拳”成功把推理速度提升了好几倍而且成本还控制得不错。今天这篇文章我就把这些实战经验分享给你。咱们不聊那些空洞的理论直接上干货手把手教你如何利用GPU算力让这个深度估计模型“飞”起来。无论你是刚接触模型部署的新手还是正在为性能发愁的开发者相信都能找到有用的技巧。1. 优化前的准备理解瓶颈在哪里在开始动手优化之前咱们得先搞清楚模型跑得慢问题到底出在哪儿。盲目优化就像蒙着眼睛修车可能费了半天劲效果却不明显。对于 Lingbot-Depth-Pretrain-Vitl-14 这类视觉模型推理速度的瓶颈通常来自几个方面计算密集型操作模型里大量的卷积、注意力机制等操作需要强大的算力支持。如果你的GPU性能不足或者代码没有充分利用GPU这里就会卡住。内存带宽限制模型参数、中间计算结果都需要在GPU显存里搬来搬去。如果数据搬运的效率不高GPU再强的算力也得等着“喂数据”这就是所谓的内存墙。框架与运行时开销你用的推理框架比如PyTorch、数据加载方式、前后处理逻辑都可能引入额外的延迟。有时候模型本身计算很快但被这些“外围”工作拖累了。批处理策略不当一次只处理一张图Batch Size1GPU的并行计算能力就浪费了。但批处理太大显存又可能爆掉。如何找到这个平衡点是个技术活。所以我们的优化思路也要对症下药一是让模型本身的计算更高效比如用TensorRT转换二是让计算资源利用率更高比如调Batch Size、用半精度三是减少不必要的开销。接下来我们就从这几个方面逐一突破。2. 第一板斧使用TensorRT转换与加速如果你想让模型在GPU上跑出极致速度TensorRT几乎是绕不开的工具。它是专门为NVIDIA GPU设计的高性能推理优化器能对模型进行层融合、精度校准、内核自动调优等一系列“魔法操作”。2.1 为什么选择TensorRT简单来说TensorRT主要干三件事优化网络结构把一些能合并的计算层合并起来减少内存访问次数和内核启动开销。选择最优内核针对你的具体GPU型号比如V100、A100、RTX 4090自动选择计算最快的内核实现。动态调整精度支持FP16半精度甚至INT8整型推理在精度损失很小的前提下大幅提升计算速度和减少显存占用。对于 Lingbot-Depth-Pretrain-Vitl-14 这种固定结构的模型经过TensorRT优化后通常能有1.5倍到3倍甚至更高的速度提升。2.2 动手转换从PyTorch到TensorRT假设你的模型原本是用PyTorch加载的。转换过程并不复杂但需要一些步骤。这里我提供一个清晰的路径。首先确保你的环境里安装了必要的库pip install torch torchvision pip install nvidia-pyindex pip install tensorrt # 还需要安装对应的 cuDNN 和 CUDA Toolkit版本要匹配转换的核心思路是先将PyTorch模型导出为ONNX格式一种通用的模型交换格式然后再用TensorRT的解析器将ONNX模型转换为高度优化的TensorRT引擎。下面是一段关键的转换代码示例import torch import tensorrt as trt import onnx # 1. 加载你训练好的PyTorch模型 # 假设你的模型类定义为 LingbotDepthModel model LingbotDepthModel(pretrainedTrue) model.eval() # 切换到评估模式 device torch.device(cuda) model.to(device) # 创建一个示例输入张量模拟一张图片 dummy_input torch.randn(1, 3, 480, 640).to(device) # [batch, channel, height, width] # 2. 导出模型到ONNX格式 onnx_model_path lingbot_depth.onnx torch.onnx.export( model, dummy_input, onnx_model_path, input_names[input], output_names[output], opset_version12, # 选择一个合适的ONNX算子集版本 dynamic_axes{input: {0: batch_size}}, # 支持动态batch size do_constant_foldingTrue ) print(f模型已导出至: {onnx_model_path}) # 3. 使用TensorRT构建引擎 logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) with open(onnx_model_path, rb) as f: if not parser.parse(f.read()): for error in range(parser.num_errors): print(parser.get_error(error)) # 设置构建配置 config builder.create_builder_config() config.max_workspace_size 1 30 # 1GB的临时工作空间 # 启用FP16精度以加速如果GPU支持 if builder.platform_has_fast_fp16: config.set_flag(trt.BuilderFlag.FP16) # 定义优化配置文件处理动态形状 profile builder.create_optimization_profile() profile.set_shape( input, # 输入张量名 min(1, 3, 480, 640), # 最小形状 opt(4, 3, 480, 640), # 最优形状TensorRT会为此形状做优化 max(16, 3, 480, 640) # 最大形状 ) config.add_optimization_profile(profile) # 构建引擎并序列化保存 serialized_engine builder.build_serialized_network(network, config) trt_engine_path lingbot_depth.engine with open(trt_engine_path, wb) as f: f.write(serialized_engine) print(fTensorRT引擎已保存至: {trt_engine_path})这段代码完成后你就得到了一个.engine文件。这个文件是专门针对你当前GPU优化过的后续推理直接加载它就行速度会比原版PyTorch模型快很多。3. 第二板斧调整批处理大小Batch Size模型转换完了接下来要从运行时找优化空间。调整批处理大小Batch Size是性价比最高的一招它直接决定了GPU的“饱腹感”。3.1 Batch Size的平衡艺术想象一下GPU是一个厨房计算核心是厨师。一次只炒一盘菜Batch Size1大部分厨师都在闲着。一次炒太多盘Batch Size很大厨房台面显存可能放不下或者厨师忙不过来导致出菜慢。我们的目标是找到那个“黄金点”在显存不溢出的前提下尽可能让GPU的计算核心保持忙碌从而摊薄处理每张图片的平均时间。3.2 如何找到最佳Batch Size没有放之四海而皆准的值你需要在自己的机器和模型上实测。下面是一个简单的寻找策略从1开始先测一下Batch Size1时的显存占用和单张图推理时间作为基线。逐步翻倍将Batch Size依次设置为2, 4, 8, 16... 每次增加后运行推理并记录显存占用是否接近GPU总显存留出约1GB安全余量。吞吐量每秒能处理的图片数Images Per Second, IPS。计算公式是Batch Size / 处理该批次的总时间。单张图延迟处理该批次所有图片的平均时间。观察拐点随着Batch Size增大吞吐量会先快速上升然后增速放缓最后可能持平甚至下降因为数据搬运或调度开销变大。那个增速开始明显放缓的点往往就是性价比最高的点。你可以写个简单的脚本来自动化这个测试过程import time import torch # 假设 trt_infer 是你写的一个用TensorRT引擎推理的函数 from your_inference_module import trt_infer def benchmark_batch_size(engine_path, image_list, batch_sizes[1, 2, 4, 8, 16]): results {} for bs in batch_sizes: # 准备批次数据这里假设image_list里是已经预处理好的张量 batches [image_list[i:ibs] for i in range(0, len(image_list), bs)] start_time time.time() for batch in batches: # 将batch中的图片堆叠成一个张量 batch_tensor torch.stack(batch).cuda() _ trt_infer(engine_path, batch_tensor) # 执行推理忽略输出 end_time time.time() total_time end_time - start_time total_images len(image_list) throughput total_images / total_time # 获取当前显存占用近似 torch.cuda.synchronize() mem_used torch.cuda.max_memory_allocated() / 1024**3 # 转换为GB results[bs] { throughput (ips): round(throughput, 2), total_time (s): round(total_time, 2), mem_used (GB): round(mem_used, 2) } torch.cuda.reset_peak_memory_stats() # 重置内存统计 print(fBatch Size {bs}: {results[bs]}) return results跑完这个测试你就能清晰地看到不同Batch Size下的表现然后做出选择。通常对于Lingbot-Depth这类模型在显存充足的卡上比如24GBBatch Size设为8或16往往能取得很好的吞吐量收益。4. 第三板斧启用半精度FP16推理现代GPU如Volta架构及以后对半精度浮点数FP16计算有专门的硬件加速单元速度可以比全精度FP32快很多同时显存占用直接减半。4.1 FP16安全吗精度损失大吗对于深度估计任务模型输出的是每个像素的深度值是一个回归问题。通常模型在训练时用的是FP32但推理时转为FP16精度损失非常微小人眼几乎无法察觉深度图的变化完全在可接受范围内。这是一种用极小的精度代价换取显著性能提升的经典手段。在上面的TensorRT转换代码里我们已经通过config.set_flag(trt.BuilderFlag.FP16)启用了FP16支持。TensorRT会自动处理层与层之间的精度转换并在内部使用FP16进行计算。4.2 检查与验证FP16效果引擎构建好后你可以通过TensorRT的API检查引擎是否真正使用了FP16或者在推理时验证结果。更直接的方法是对比开启FP16前后模型推理的速度和显存占用。你会发现吞吐量通常有显著的提升尤其是对于计算密集型的模型。5. 实战工具监控GPU利用率优化不是一劳永逸的你需要工具来验证优化效果并持续监控运行状态。光靠感觉不行得有数据。5.1 命令行利器nvidia-smi最基础也最强大的工具是nvidia-smi。在终端运行它你可以看到GPU利用率Volatile GPU-Util百分比表示GPU计算核心的忙碌程度。优化目标就是让这个值在推理期间稳定在较高水平如70%-95%。显存占用Memory-Usage确认你的Batch Size设置没有导致显存爆满。功耗与温度辅助判断GPU是否在高效工作。你可以使用watch -n 0.5 nvidia-smi来半秒刷新一次实时观察推理时的状态。5.2 Python中的监控在Python脚本里你也可以方便地获取这些信息import pynvml import time pynvml.nvmlInit() handle pynvml.nvmlDeviceGetHandleByIndex(0) # 0表示第一块GPU def get_gpu_info(): util pynvml.nvmlDeviceGetUtilizationRates(handle) mem_info pynvml.nvmlDeviceGetMemoryInfo(handle) return { gpu_util (%): util.gpu, mem_util (%): util.memory, mem_used (GB): mem_info.used / 1024**3 } # 在推理循环中定期打印 for batch in data_loader: start time.time() output infer(batch) end time.time() print(fInference time: {end-start:.3f}s, {get_gpu_info()})看到GPU利用率在推理时飙高显存占用稳定那说明你的优化工作正在见效GPU这颗“引擎”正在全力输出。6. 把这些技巧串起来一个完整的优化示例说了这么多我们来模拟一个完整的优化流程看看效果如何。场景在星图平台的一台配备 NVIDIA A1024GB显存的GPU服务器上优化Lingbot-Depth-Pretrain-Vitl-14模型处理一批100张室内场景图片的速度。原始状态PyTorch FP32, Batch Size1吞吐量~3.2 张/秒单张延迟~312 毫秒GPU利用率~25%波动大大量时间在等待优化步骤与效果应用TensorRT转换FP32模型计算图得到优化。效果吞吐量提升至 ~5.1 张/秒提升约60%。调整Batch Size至8更充分利用GPU并行能力。效果吞吐量跃升至 ~28 张/秒单张平均延迟降至 ~36 毫秒。GPU利用率稳定在75%左右。启用TensorRT FP16推理利用硬件加速。效果吞吐量进一步提升至 ~41 张/秒显存占用从11GB减少到6GB。GPU利用率达到90%以上。最终对比经过一套“组合拳”处理同样100张图片总时间从最初的约31秒缩短到了约2.4秒速度提升了近13倍。而GPU的成本因为处理速度大幅加快任务的总计费时长反而减少了实现了真正的降本增效。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
