黑丝空姐-造相Z-Turbo开发实战Git版本管理下的模型微调与迭代你是不是也遇到过这种情况团队里几个人一起折腾一个AI模型今天张三改了下训练脚本明天李四更新了提示词模板结果没过几天谁也说不清哪个版本的效果最好想回退到上周那个生成效果特别棒的模型参数却发现文件早就被覆盖了。混乱的版本管理简直就是协作开发的噩梦。今天咱们就来聊聊怎么用Git这个程序员的老朋友把“黑丝空姐-造相Z-Turbo”这类模型的微调过程管得明明白白。这不仅仅是保存代码更是把训练脚本、配置文件、提示词甚至训练好的模型权重都纳入一个清晰、可追溯的版本流里。下次再有人说“用我电脑上这个版本试试”你直接甩给他一个分支名就行。1. 为什么模型微调需要Git你可能觉得Git不就是管代码的吗模型文件那么大也能用Git管没错直接塞进去肯定不行但我们的思路要变一变。Git管理的核心是“变化”和“协作”这对于模型微调项目来说价值巨大。想象一下你们团队在优化“造相Z-Turbo”的生成效果。A同学调整了一组超参数发现人物面部细节更好了B同学改写了一批提示词模板让“空姐”的制服质感更逼真C同学则尝试了不同的LoRA训练策略。如果没有Git这些尝试可能就是一堆名字混乱的文件夹final_v2/、really_final/、use_this_one_latest/。更头疼的是当你想融合A的参数和B的提示词时根本无从下手。Git能帮你解决三个核心问题可追溯性每一次训练对应的脚本、配置、数据准备方式都被完整记录。你可以精准地回答“三月份那个爆款图的生成参数是什么”并行实验每个人可以在独立的分支上大胆尝试不同的微调思路比如一个分支专攻服装纹理一个分支优化背景光影互不干扰。安全回滚当新的训练方向效果不佳时可以轻松地退回到之前任何一个稳定的版本而不是在文件堆里绝望地翻找。所以我们不只是用Git来存.py文件更是用它来管理整个微调实验的“配方”。模型权重文件如LoRA虽然不适合直接入库但我们可以通过巧妙的策略将其与特定的“配方”版本关联起来。2. 项目初始化与仓库结构设计万事开头难一个好的仓库结构是成功的一半。我们不搞复杂的那一套就从最实用、最清晰的结构开始。2.1 初始化Git仓库首先在你的项目根目录下打开终端执行以下命令# 初始化一个新的Git仓库 git init # 将当前目录的所有文件添加到暂存区首次添加 git add . # 提交你的第一次更改并附上说明信息 git commit -m “初始提交项目基础结构包含数据预处理脚本和基础训练配置”这就完成了本地仓库的创建。如果你需要和团队成员协作接下来可以把它推送到像GitLab、Gitee或GitHub这样的远程平台。# 关联远程仓库以Gitee为例 git remote add origin https://gitee.com/your_username/zturbo-finetune.git # 将本地提交推送到远程主分支 git push -u origin main2.2 设计清晰的目录结构一个混乱的文件夹是协作的灾难。我建议为“造相Z-Turbo”微调项目设计这样一个结构zturbo-finetune-project/ ├── .gitignore # Git忽略文件至关重要 ├── README.md # 项目说明文档 ├── configs/ # 存放所有配置文件 │ ├── train_base.yaml # 基础训练配置 │ ├── train_lora_v1.yaml # 针对LoRA的v1配置 │ └── dataset_v1.yaml # 数据集预处理配置 ├── scripts/ # 存放可执行脚本 │ ├── preprocess.py # 数据预处理脚本 │ ├── train.py # 主训练脚本 │ └── inference.py # 推理测试脚本 ├── prompts/ # 提示词模板库 │ ├── character/ # 角色类提示词如空姐 │ ├── style/ # 风格类提示词 │ └── template_v1.jinja2 # 提示词组合模板 ├── data/ # 数据集通常被.gitignore忽略 │ └── raw_images/ # 原始图像数据 ├── experiments/ # 实验记录与产出部分被忽略 │ ├── 20240501_lora_outfit/ # 按日期和主题命名实验 │ │ ├── train_log.txt │ │ └── checkpoints/ # 训练好的模型如LoRA权重 │ └── README.md # 记录实验目标和结论 └── requirements.txt # Python依赖列表这个结构的关键在于分离配置与代码分离数据与代码分离实验产出与核心资产分离。2.3 配置.gitignore文件这是保护仓库纯净、避免误提交大文件的神器。在你的项目根目录创建或编辑.gitignore文件# 忽略Python虚拟环境 venv/ .env/ # 忽略数据集和缓存文件 data/raw_images/ *.zip *.tar.gz __pycache__/ *.py[cod] # 忽略训练产生的大文件核心 experiments/*/checkpoints/ *.ckpt *.safetensors *.pth *.bin # 忽略日志文件可选建议提交精简日志 *.log train_log.txt # 忽略IDE配置文件 .vscode/ .idea/通过这个文件我们明确告诉Gitdata/里的原始图片、experiments/下的模型权重文件都不要纳入版本管理。我们只管理产生这些结果的“配方”脚本和配置。3. Git核心工作流在微调中的实践有了好的结构我们来看看日常开发中怎么用Git。3.1 基础操作提交你的每一次实验每次开始一个新的微调尝试比如你想试试新的学习率调度策略都应该基于一个清晰的状态开始。# 1. 在开始修改前确保你在一个干净的主分支上 git checkout main git pull origin main # 同步团队最新更改 # 2. 为这次实验创建一个新分支名字最好能描述目的 git checkout -b experiment/lr_scheduler_cosine # 3. 进行你的修改编辑configs/train_lora_v1.yaml中的学习率配置 # ... (用编辑器修改yaml文件) ... # 4. 将修改加入暂存区并提交 git add configs/train_lora_v1.yaml git commit -m “实验尝试使用Cosine退火学习率调度器预期使训练更稳定” # 5. 运行训练脚本开始实验 python scripts/train.py --config configs/train_lora_v1.yaml # 6. 实验结束后将结果记录在experiments/目录下 # 模型权重保存在experiments/20240510_lr_cosine/checkpoints/被.gitignore忽略 # 但你可以创建一个README或日志文件记录本次实验参数和结论 echo “实验Cosine LR Scheduler 最终loss下降至0.12生成图像细节更柔和。” experiments/20240510_lr_cosine/README.md git add experiments/20240510_lr_cosine/README.md git commit -m “记录Cosine学习率实验结论”你看我们提交的不是巨大的模型文件而是导致这个模型产生的配置变更和实验结论。这样仓库依然轻巧但历史却完整无比。3.2 分支策略管理并行实验分支是Git的超级武器。对于模型微调我们可以约定一个简单的分支策略main分支存放稳定、经过验证的配置和脚本。任何合并到main的代码都应该是可运行的、相对可靠的版本。feature/*或experiment/*分支用于开发新功能或进行实验。例如experiment/prompt_engineering_v2专门优化提示词模板的分支。feature/add_face_restoration增加人脸修复后处理模块的分支。experiment/dataset_augmentation尝试新的数据增强方法的分支。当某个实验分支比如优化提示词的分支取得了显著效果并经过测试后就可以将其合并回main分支。# 1. 切换回主分支并更新 git checkout main git pull origin main # 2. 合并实验分支 git merge experiment/prompt_engineering_v2 # 3. 解决可能出现的合并冲突如果有 # 4. 推送更新到远程仓库 git push origin main3.3 处理合并冲突冲突并不可怕它只是提醒你同一处地方被不同的人以不同的方式修改了。在微调项目中冲突常发生在配置文件(.yaml)或提示词模板(.jinja2)上。假设你和同事都修改了configs/train_lora_v1.yaml中的batch_size在合并时Git会提示冲突。文件会变成这样 HEAD batch_size: 4 # 你修改的版本 batch_size: 8 # 同事修改的版本 experiment/colleague_branch learning_rate: 1e-4你需要手动决定保留哪个值或者协商出一个新值比如batch_size: 6。编辑文件删除冲突标记保存文件然后完成提交。# 手动解决冲突后 git add configs/train_lora_v1.yaml git commit -m “解决batch_size冲突合并为6”清晰的沟通和定期的git pull可以减少冲突的发生。4. 模型权重的版本管理策略这是最棘手的问题LoRA模型文件.safetensors动辄几十到几百MB直接放进Git仓库会让仓库体积爆炸克隆和同步变得极其缓慢。我们有更聪明的办法。4.1 关联法使用版本标签和文档核心思想用Git的版本来标记模型文件但模型文件本身存放在别处。训练并保存模型训练完成后将最好的LoRA权重保存为有版本号的名字例如zturbo_lora_v1.2.safetensors。提交“配方”并打标签将这次训练所用的完整配置、脚本和提示词提交到Git并创建一个标签Tag来标记这个重要的版本。# 提交本次训练的所有相关代码和配置 git add configs/train_lora_v1.2.yaml scripts/train.py prompts/template_v1.2.jinja2 git commit -m “发布模型权重 v1.2 对应的代码版本优化了制服材质提示词” # 创建一个轻量级标签指向这次提交 git tag -a “model-v1.2” -m “对应LoRA权重文件zturbo_lora_v1.2.safetensors 专注于空姐制服纹理增强。” git push origin main --tags # 将标签也推送到远程存储模型文件将zturbo_lora_v1.2.safetensors文件存放在团队共享的网盘、NAS或者专门的对象存储如阿里云OSS、腾讯云COS中。在项目的README.md或MODELS.md文件里维护一个模型版本清单表格模型版本Git 标签/提交ID权重文件位置主要改进训练配置v1.2model-v1.2\\nas\models\zturbo_lora_v1.2.safetensors制服纹理、面部光泽configs/train_lora_v1.2.yamlv1.1a1b2c3d\\nas\models\zturbo_lora_v1.1.safetensors基础姿态稳定性configs/train_lora_v1.1.yaml这样任何人只要克隆Git仓库查看标签和文档就能知道去哪里获取对应的模型文件以及用哪个版本的代码来复现或使用它。4.2 使用Git LFS管理小规模权重如果团队规模小模型文件不多比如只有几个关键的LoRA适配器可以考虑使用Git LFS。它会将大文件存储在单独的服务器上而在Git仓库中只保存一个指针文件。# 1. 安装Git LFS # 2. 在项目仓库中启用LFS并指定要管理的大文件类型 git lfs install git lfs track “*.safetensors” “*.ckpt” # 3. 像往常一样添加、提交文件。LFS会自动处理。 git add .gitattributes # 必须提交这个配置文件 git add experiments/final_model/lora.safetensors git commit -m “添加v1.0最终版LoRA权重使用LFS管理” git push origin main注意对于免费托管的Git服务如GitHub免费账户LFS有流量和存储限制。对于频繁更新的大型模型权重长期来看关联法4.1通常是更可持续和经济的方案。5. 实战一次完整的微调迭代记录让我们模拟一个团队协作的小场景把上面的流程串起来。目标为“造相Z-Turbo”微调一个生成“黑丝空姐”时丝袜质感更好的LoRA模型。立项与分支小王从main分支创建新分支feature/improve_hosiery_texture。数据与提示词准备小王收集了一批高质量丝袜特写图片并编写了新的提示词模板prompts/hosiery_detail_v1.jinja2提交到该分支。配置调整他修改了训练配置configs/train_lora_hosiery.yaml降低了学习率专注于纹理学习。实验与记录小王启动训练并将训练日志和最终的LoRA权重zturbo_lora_hosiery_v1.safetensors保存到experiments/20240515_hosiery/目录下。他在该目录添加了RESULTS.md文件记录了本次训练的关键参数和生成样例的主观评价。内部评审小王将分支推送到远程并发起合并请求。团队成员小李查看代码变更和RESULTS.md中的样例觉得效果不错但建议增加一些侧光场景的提示词。迭代与合并小王根据反馈更新了提示词模板并进行了第二轮快速微调更新了模型文件和实验记录。最终这个功能分支被合并到main分支。同时团队在共享存储中更新了模型文件并在项目的模型清单里添加了hosiery_v1的记录关联到这次合并的提交ID。版本发布团队决定将此版本作为一个小里程碑在Git上打标签release/hosiery-v1.0。整个过程中每一次意图提交信息、每一次更改代码差异、每一次讨论合并请求评论都被完整记录。几个月后当你想知道“那个丝袜质感很棒的版本是怎么调出来的”时一切都有迹可循。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
黑丝空姐-造相Z-Turbo开发实战：Git版本管理下的模型微调与迭代
黑丝空姐-造相Z-Turbo开发实战Git版本管理下的模型微调与迭代你是不是也遇到过这种情况团队里几个人一起折腾一个AI模型今天张三改了下训练脚本明天李四更新了提示词模板结果没过几天谁也说不清哪个版本的效果最好想回退到上周那个生成效果特别棒的模型参数却发现文件早就被覆盖了。混乱的版本管理简直就是协作开发的噩梦。今天咱们就来聊聊怎么用Git这个程序员的老朋友把“黑丝空姐-造相Z-Turbo”这类模型的微调过程管得明明白白。这不仅仅是保存代码更是把训练脚本、配置文件、提示词甚至训练好的模型权重都纳入一个清晰、可追溯的版本流里。下次再有人说“用我电脑上这个版本试试”你直接甩给他一个分支名就行。1. 为什么模型微调需要Git你可能觉得Git不就是管代码的吗模型文件那么大也能用Git管没错直接塞进去肯定不行但我们的思路要变一变。Git管理的核心是“变化”和“协作”这对于模型微调项目来说价值巨大。想象一下你们团队在优化“造相Z-Turbo”的生成效果。A同学调整了一组超参数发现人物面部细节更好了B同学改写了一批提示词模板让“空姐”的制服质感更逼真C同学则尝试了不同的LoRA训练策略。如果没有Git这些尝试可能就是一堆名字混乱的文件夹final_v2/、really_final/、use_this_one_latest/。更头疼的是当你想融合A的参数和B的提示词时根本无从下手。Git能帮你解决三个核心问题可追溯性每一次训练对应的脚本、配置、数据准备方式都被完整记录。你可以精准地回答“三月份那个爆款图的生成参数是什么”并行实验每个人可以在独立的分支上大胆尝试不同的微调思路比如一个分支专攻服装纹理一个分支优化背景光影互不干扰。安全回滚当新的训练方向效果不佳时可以轻松地退回到之前任何一个稳定的版本而不是在文件堆里绝望地翻找。所以我们不只是用Git来存.py文件更是用它来管理整个微调实验的“配方”。模型权重文件如LoRA虽然不适合直接入库但我们可以通过巧妙的策略将其与特定的“配方”版本关联起来。2. 项目初始化与仓库结构设计万事开头难一个好的仓库结构是成功的一半。我们不搞复杂的那一套就从最实用、最清晰的结构开始。2.1 初始化Git仓库首先在你的项目根目录下打开终端执行以下命令# 初始化一个新的Git仓库 git init # 将当前目录的所有文件添加到暂存区首次添加 git add . # 提交你的第一次更改并附上说明信息 git commit -m “初始提交项目基础结构包含数据预处理脚本和基础训练配置”这就完成了本地仓库的创建。如果你需要和团队成员协作接下来可以把它推送到像GitLab、Gitee或GitHub这样的远程平台。# 关联远程仓库以Gitee为例 git remote add origin https://gitee.com/your_username/zturbo-finetune.git # 将本地提交推送到远程主分支 git push -u origin main2.2 设计清晰的目录结构一个混乱的文件夹是协作的灾难。我建议为“造相Z-Turbo”微调项目设计这样一个结构zturbo-finetune-project/ ├── .gitignore # Git忽略文件至关重要 ├── README.md # 项目说明文档 ├── configs/ # 存放所有配置文件 │ ├── train_base.yaml # 基础训练配置 │ ├── train_lora_v1.yaml # 针对LoRA的v1配置 │ └── dataset_v1.yaml # 数据集预处理配置 ├── scripts/ # 存放可执行脚本 │ ├── preprocess.py # 数据预处理脚本 │ ├── train.py # 主训练脚本 │ └── inference.py # 推理测试脚本 ├── prompts/ # 提示词模板库 │ ├── character/ # 角色类提示词如空姐 │ ├── style/ # 风格类提示词 │ └── template_v1.jinja2 # 提示词组合模板 ├── data/ # 数据集通常被.gitignore忽略 │ └── raw_images/ # 原始图像数据 ├── experiments/ # 实验记录与产出部分被忽略 │ ├── 20240501_lora_outfit/ # 按日期和主题命名实验 │ │ ├── train_log.txt │ │ └── checkpoints/ # 训练好的模型如LoRA权重 │ └── README.md # 记录实验目标和结论 └── requirements.txt # Python依赖列表这个结构的关键在于分离配置与代码分离数据与代码分离实验产出与核心资产分离。2.3 配置.gitignore文件这是保护仓库纯净、避免误提交大文件的神器。在你的项目根目录创建或编辑.gitignore文件# 忽略Python虚拟环境 venv/ .env/ # 忽略数据集和缓存文件 data/raw_images/ *.zip *.tar.gz __pycache__/ *.py[cod] # 忽略训练产生的大文件核心 experiments/*/checkpoints/ *.ckpt *.safetensors *.pth *.bin # 忽略日志文件可选建议提交精简日志 *.log train_log.txt # 忽略IDE配置文件 .vscode/ .idea/通过这个文件我们明确告诉Gitdata/里的原始图片、experiments/下的模型权重文件都不要纳入版本管理。我们只管理产生这些结果的“配方”脚本和配置。3. Git核心工作流在微调中的实践有了好的结构我们来看看日常开发中怎么用Git。3.1 基础操作提交你的每一次实验每次开始一个新的微调尝试比如你想试试新的学习率调度策略都应该基于一个清晰的状态开始。# 1. 在开始修改前确保你在一个干净的主分支上 git checkout main git pull origin main # 同步团队最新更改 # 2. 为这次实验创建一个新分支名字最好能描述目的 git checkout -b experiment/lr_scheduler_cosine # 3. 进行你的修改编辑configs/train_lora_v1.yaml中的学习率配置 # ... (用编辑器修改yaml文件) ... # 4. 将修改加入暂存区并提交 git add configs/train_lora_v1.yaml git commit -m “实验尝试使用Cosine退火学习率调度器预期使训练更稳定” # 5. 运行训练脚本开始实验 python scripts/train.py --config configs/train_lora_v1.yaml # 6. 实验结束后将结果记录在experiments/目录下 # 模型权重保存在experiments/20240510_lr_cosine/checkpoints/被.gitignore忽略 # 但你可以创建一个README或日志文件记录本次实验参数和结论 echo “实验Cosine LR Scheduler 最终loss下降至0.12生成图像细节更柔和。” experiments/20240510_lr_cosine/README.md git add experiments/20240510_lr_cosine/README.md git commit -m “记录Cosine学习率实验结论”你看我们提交的不是巨大的模型文件而是导致这个模型产生的配置变更和实验结论。这样仓库依然轻巧但历史却完整无比。3.2 分支策略管理并行实验分支是Git的超级武器。对于模型微调我们可以约定一个简单的分支策略main分支存放稳定、经过验证的配置和脚本。任何合并到main的代码都应该是可运行的、相对可靠的版本。feature/*或experiment/*分支用于开发新功能或进行实验。例如experiment/prompt_engineering_v2专门优化提示词模板的分支。feature/add_face_restoration增加人脸修复后处理模块的分支。experiment/dataset_augmentation尝试新的数据增强方法的分支。当某个实验分支比如优化提示词的分支取得了显著效果并经过测试后就可以将其合并回main分支。# 1. 切换回主分支并更新 git checkout main git pull origin main # 2. 合并实验分支 git merge experiment/prompt_engineering_v2 # 3. 解决可能出现的合并冲突如果有 # 4. 推送更新到远程仓库 git push origin main3.3 处理合并冲突冲突并不可怕它只是提醒你同一处地方被不同的人以不同的方式修改了。在微调项目中冲突常发生在配置文件(.yaml)或提示词模板(.jinja2)上。假设你和同事都修改了configs/train_lora_v1.yaml中的batch_size在合并时Git会提示冲突。文件会变成这样 HEAD batch_size: 4 # 你修改的版本 batch_size: 8 # 同事修改的版本 experiment/colleague_branch learning_rate: 1e-4你需要手动决定保留哪个值或者协商出一个新值比如batch_size: 6。编辑文件删除冲突标记保存文件然后完成提交。# 手动解决冲突后 git add configs/train_lora_v1.yaml git commit -m “解决batch_size冲突合并为6”清晰的沟通和定期的git pull可以减少冲突的发生。4. 模型权重的版本管理策略这是最棘手的问题LoRA模型文件.safetensors动辄几十到几百MB直接放进Git仓库会让仓库体积爆炸克隆和同步变得极其缓慢。我们有更聪明的办法。4.1 关联法使用版本标签和文档核心思想用Git的版本来标记模型文件但模型文件本身存放在别处。训练并保存模型训练完成后将最好的LoRA权重保存为有版本号的名字例如zturbo_lora_v1.2.safetensors。提交“配方”并打标签将这次训练所用的完整配置、脚本和提示词提交到Git并创建一个标签Tag来标记这个重要的版本。# 提交本次训练的所有相关代码和配置 git add configs/train_lora_v1.2.yaml scripts/train.py prompts/template_v1.2.jinja2 git commit -m “发布模型权重 v1.2 对应的代码版本优化了制服材质提示词” # 创建一个轻量级标签指向这次提交 git tag -a “model-v1.2” -m “对应LoRA权重文件zturbo_lora_v1.2.safetensors 专注于空姐制服纹理增强。” git push origin main --tags # 将标签也推送到远程存储模型文件将zturbo_lora_v1.2.safetensors文件存放在团队共享的网盘、NAS或者专门的对象存储如阿里云OSS、腾讯云COS中。在项目的README.md或MODELS.md文件里维护一个模型版本清单表格模型版本Git 标签/提交ID权重文件位置主要改进训练配置v1.2model-v1.2\\nas\models\zturbo_lora_v1.2.safetensors制服纹理、面部光泽configs/train_lora_v1.2.yamlv1.1a1b2c3d\\nas\models\zturbo_lora_v1.1.safetensors基础姿态稳定性configs/train_lora_v1.1.yaml这样任何人只要克隆Git仓库查看标签和文档就能知道去哪里获取对应的模型文件以及用哪个版本的代码来复现或使用它。4.2 使用Git LFS管理小规模权重如果团队规模小模型文件不多比如只有几个关键的LoRA适配器可以考虑使用Git LFS。它会将大文件存储在单独的服务器上而在Git仓库中只保存一个指针文件。# 1. 安装Git LFS # 2. 在项目仓库中启用LFS并指定要管理的大文件类型 git lfs install git lfs track “*.safetensors” “*.ckpt” # 3. 像往常一样添加、提交文件。LFS会自动处理。 git add .gitattributes # 必须提交这个配置文件 git add experiments/final_model/lora.safetensors git commit -m “添加v1.0最终版LoRA权重使用LFS管理” git push origin main注意对于免费托管的Git服务如GitHub免费账户LFS有流量和存储限制。对于频繁更新的大型模型权重长期来看关联法4.1通常是更可持续和经济的方案。5. 实战一次完整的微调迭代记录让我们模拟一个团队协作的小场景把上面的流程串起来。目标为“造相Z-Turbo”微调一个生成“黑丝空姐”时丝袜质感更好的LoRA模型。立项与分支小王从main分支创建新分支feature/improve_hosiery_texture。数据与提示词准备小王收集了一批高质量丝袜特写图片并编写了新的提示词模板prompts/hosiery_detail_v1.jinja2提交到该分支。配置调整他修改了训练配置configs/train_lora_hosiery.yaml降低了学习率专注于纹理学习。实验与记录小王启动训练并将训练日志和最终的LoRA权重zturbo_lora_hosiery_v1.safetensors保存到experiments/20240515_hosiery/目录下。他在该目录添加了RESULTS.md文件记录了本次训练的关键参数和生成样例的主观评价。内部评审小王将分支推送到远程并发起合并请求。团队成员小李查看代码变更和RESULTS.md中的样例觉得效果不错但建议增加一些侧光场景的提示词。迭代与合并小王根据反馈更新了提示词模板并进行了第二轮快速微调更新了模型文件和实验记录。最终这个功能分支被合并到main分支。同时团队在共享存储中更新了模型文件并在项目的模型清单里添加了hosiery_v1的记录关联到这次合并的提交ID。版本发布团队决定将此版本作为一个小里程碑在Git上打标签release/hosiery-v1.0。整个过程中每一次意图提交信息、每一次更改代码差异、每一次讨论合并请求评论都被完整记录。几个月后当你想知道“那个丝袜质感很棒的版本是怎么调出来的”时一切都有迹可循。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
