魔搭AI工具See-Through：一键生成二次元立绘分层PSD

项目背景与部署价值

我们的开源项目公开后，收到了国内AI模型部署平台的运营邀请，他们正在测试创空间服务，允许我们免费使用高性能显卡来部署演示demo，方便国内用户直接访问运行。当时我们第一反应是尝试一下，后续发现这个选择非常划算：相当于在国内获得了稳定的CDN加速和随时可用的推理服务器，用户无需复杂的网络配置就能直接使用工具。对于没有预算的学术项目来说，“点开即用”的门槛至关重要，同时也能让更多国内用户接触到我们的工作，实现了双向的价值。

我们的研究组专注于二次元图形学方向，项目没有商业化计划，也没有预算租用常驻推理服务器。我们的模型单次运行需要占用十几个G的显存，耗时两三分钟，如果自行租用服务器很容易产生超额费用。这类免费的部署服务对我们来说帮助极大。

我们使用的平台资源为Ada系列显卡、48G显存、8 vCPU、64G内存的空间，目前已稳定使用一段时间，累计的使用数据相当可观：

• 45,789次访问，15,798位独立访客
• 26,978次真实推理
• 279个点赞，7条社区反馈帖

我们也收到了来自社区的不少反馈，尤其是来自画师、独立游戏开发者和Live2D创作者群体。在此之前，他们访问我们的工具存在不少困难：我们在HuggingFace上也部署了Space，但国内访问不够顺畅，且ZeroGPU的免费额度一天仅能运行一两次。该平台提供的国内友好的演示环境，让我们能够和国内社区更顺畅地互动。

项目核心功能与技术细节

我们的项目核心功能是为动漫角色立绘自动生成带透明通道的语义分层，并按深度排序输出分层PSD文件。用户上传一张立绘，就能得到头发、脸部、眼睛、衣物、配饰等独立的修复后图层，被遮挡的部分也会被自动补全。对于需要拆分立绘做Sprite、Live2D前期分层或者游戏角色部件拆解的创作者来说，手工完成这类工作耗时极长，这个工具能大幅提升效率。

整个系统由两个核心模块串联而成：一是基于SDXL的LayerDiff 3D扩散模型，负责生成带透明度的分层内容，这是整个流程的核心部分；二是经过微调的Marigold模型，用于估计图像深度，以此确定各个图层的前后顺序。我们的训练数据来自自行标注的一批Live2D模型，这类模型天然具备分层结构，每个Drawable都是独立图层，带有明确的深度和遮挡关系，且由专业艺术家设计，质量很高。

模型资源占用与推理耗时

和大语言模型相比，我们的模型并不算特别重量级，但在图像扩散模型领域属于偏重的类型。这不仅体现在分辨率上，更源于其独特的结构设计：我们同时生成23个图层，将每个图层视为“帧”送入Transformer3DModel结构，在每个空间位置上跨图层进行注意力计算，确保前发层和后发层、衣领和脖子的位置能够准确对应。从结构上来说，这个模型更像是一个视频生成模型，只是将时间维度替换为图层维度。以1280分辨率的推理为例，本质上相当于执行一次30步、23帧的视频生成任务。

在1024分辨率下，我们的推理时间大致为：

[21:11:32] LayerDiff done (103.4s)
[21:11:47] Marigold done (15.4s)
[21:11:47] PSD assembly done (0.4s)
[21:11:47] Total inference time: 119.7s

1280分辨率下总耗时约198.7秒：

[03:00:33] Total inference time: 198.7s

同时，两个Pipeline的权重在bf16精度下需要占用十几个G的显存，因此运行这个工具确实需要大显存、高性能的显卡。该平台提供的资源刚好满足需求：同一份模型在该平台默认支持1024分辨率，最高可拉到1600；而在HuggingFace上默认仅支持768分辨率，最高1280，超过1280分辨率很容易超时。

完整部署流程

如果已经有可运行的Gradio应用，迁移到该平台的流程会非常顺畅。我们的初始代码来自HuggingFace Space，app.py文件已经准备就绪，下面总结一下完整的部署步骤：

1. 创建空间并选择硬件

新建部署创空间，选择Gradio作为部署框架，在部署设置中选择硬件配置。平台的免费xGPU资源分为Tesla系列（16G显存）和Ada系列（48G显存），我们选择了后者，需要先加入专属资源组织并向运营申请开通。平台默认的镜像版本为ubuntu22.04-py311-torch2.9.1-modelscope1.35.0，预装了Python3.11、PyTorch2.9.1和相关依赖。

2. 推送代码至仓库

创空间本质上是一个Git仓库，和HuggingFace Space类似，需要注意默认分支是master而非main。通过git remote添加平台仓库地址，使用个人访问令牌进行推送，令牌可以在平台的个人设置页面获取。仓库中至少需要包含三个文件：app.py、requirements.txt和README.md。其中README的frontmatter需要按照平台的规范配置，包括domain、tags、关联的模型仓库地址和许可证信息，这个字段能帮助其他用户找到对应的模型资源，建议务必填写。

# 注意默认分支是 master，不是 main
git remote add modelscope https://oauth2:<你的令牌>@www.modelscope.cn/studios/<用户名>/<空间名>.git
git push modelscope master

3. 模型存储与下载

将模型权重上传到平台的模型库后，使用官方的下载接口进行拉取。国内的上传和下载速度都非常快，且空间启动时直接从模型库拉取数据，基本不会出现中断的情况，整个权重仓库的校验和下载通常不到30秒。平台会自动配置缓存目录到/mnt/workspace，该目录是持久化的，重启空间后无需重新下载权重。

from modelscope import snapshot_download
_local_layerdiff = snapshot_download("ljsabc/seethroughv0.0.2_layerdiff3d")
_local_depth     = snapshot_download("ljsabc/seethroughv0.0.1_marigold")

4. GPU资源配置

这是从HuggingFace迁移时最需要调整的部分。ZeroGPU这类免费资源采用“预扣额度”模式，需要显式使用@spaces.GPU(duration=N)装饰器，从调用者的每日额度中扣除时间，超时则会拒绝执行。而该平台的xGPU资源则更为简单，容器初始化时GPU就已就绪，无需额外的装饰器，直接将模型加载到cuda设备即可。

# 模块级直接加载到 GPU，不需要任何装饰器
_layerdiff_pipe.unet.to(dtype=torch.bfloat16, device="cuda")
_layerdiff_pipe.vae.to(dtype=torch.bfloat16, device="cuda")
# ...
_marigold_pipe.to(device="cuda", dtype=torch.bfloat16)

冷启动时间约100秒（包含拉取权重、校验和Pipeline初始化），但根据我们的日志，空间大部分时间都处于热启动状态，无需重新初始化。当初提交这个改动时我们心里没底，还在commit message里写了“如果xGPU在init阶段拿不到GPU就回滚”，结果一路顺畅，一直运行到现在。

部署踩坑与适配技巧

在部署过程中我们遇到了不少需要注意的细节，这里整理出来供大家参考：

1. 不要在requirements.txt中固定torch版本：平台镜像已经预装了torch2.9.1，如果在requirements中写入torch==2.8.0，pip会先卸载镜像中的版本再重新安装，若同时保留了--extra-index-url指向境外PyPI源，会触发近4G的PyTorch包下载，耗时极长。正确的做法是删除requirements中关于torch、torchvision的固定版本声明，以及额外的境外源配置，避免不必要的重装流程。

2. 使用>=版本号对镜像预装包不会生效：平台执行pip install -r requirements.txt时默认不带--upgrade参数，因此如果requirements中写入peft>=0.14.0，而镜像已经预装了符合版本的peft，pip只会提示“Requirement already satisfied”而不会进行升级。只有当写入的版本下限高于镜像预装的版本时，才会触发升级操作。因此，对于需要明确覆盖镜像预装版本的包，建议使用==指定精确版本，或者使用远高于当前版本的下限。

提示：>= 只用来表示“我不想覆盖镜像里的版本”（比如 torch）。任何你需要真正改变版本的包，得用 ==，或者一个明确高于镜像版本的下限。

3. 不要将gradio、pydantic写入requirements.txt：平台的安装顺序是先预装gradio和相关依赖，再升级modelscope，最后执行用户的requirements.txt。gradio的安装过程会将pydantic降级到特定版本，而pydantic和pydantic-core是严格绑定的，版本不匹配会导致import pydantic时抛出SystemError。因此这两个包不需要在用户的requirements中声明，平台会自动处理。

4. 正确导入snapshot_download函数：平台提供的modelscope库中，正确的导入方式是from modelscope import snapshot_download，如果错误地写成from modelscope.hub import snapshot_download，虽然不会直接报错，但Python会将模块对象而非函数导入，后续调用时会抛出TypeError: 'module' object is not callable，这个问题需要特别注意。

5. 搜索代码中硬编码的huggingface.co域名：部分依赖库可能会硬编码访问huggingface.co来获取小配置文件，比如我们遇到的情况是某个依赖库会拉取juggernautXL仓库的scheduler_config.json，虽然代码和requirements中都没有显式声明，但会触发境外网络请求，导致启动失败。这类小配置文件可以提前下载到本地，在代码中显式传入路径，避免联网拉取。部署前可以通过grep命令快速排查所有相关的域名和from_pretrained调用。如果实在无法修改，也可以通过设置HF_ENDPOINT=https://hf-mirror.com来使用镜像源兜底。

grep -rn "huggingface.co\|from_pretrained(\"[a-zA-Z0-9_-]*/" your_project/

另外，查看运行日志是排查问题的关键。平台的日志入口位于空间管理页面的“查看日志”→“运行日志”，需要注意的是，Gradio类型的创空间的“构建日志”为空，pip install的输出会被打印在运行日志中。日志支持切换构建/运行日志、5秒自动刷新、搜索和整包下载，会保留近7天内的1万条日志，通过日志可以快速定位启动和运行过程中的问题。

这里整理了从HuggingFace迁移到该平台的速查表：

社区反馈与最终感谢

截至目前，我们的部署空间已经拥有超过45000次访问，15000多位独立访客，完成了近27000次真实推理，获得了279个点赞和7条社区反馈。在所有的演示渠道中，这里的使用量是最高的，作为项目维护者，看到有这么多用户使用我们的工具，我们感到非常欣慰。

社区反馈的价值

社区的反馈对我们来说非常重要：有用户指出发饰类的小部件在分层时容易缺失，但耳坠这类部件不会消失，这确实是我们模型的已知弱点，小尺寸高频细节在分层时容易被相邻图层吸附；有用户询问为什么导出的PSD没有颜色，还有人报告突然出现502错误；也有用户留言说“今天效果棒棒的，是不是进化了”，虽然我们并没有修改模型，但看到这样的留言还是会感到非常开心。

社区的反馈和论文中的测试数据同样重要，论文中的统计数据来自我们内部的测试集，但真实用户会上传各种我们未曾预料到的图片：超长的立绘、多人构图、非常规的画风和角色设计，这些反馈将成为我们下一版模型改进的重要参考。

最后的感谢

正如开头所说，二次元图形学方向的工具相对小众，和大模型、具身智能等领域相比，关注度和影响力都要小很多，但这类工具确实能为创作者提供实实在在的帮助。很多时候，阻碍我们前进的不是技术想法，而是真实的用户反馈和社区的声音。

感谢该平台提供的免费试用空间，让我们能够长期为国内用户提供稳定的演示服务，未来我们也计划将组内的其他老demo陆续迁移过来。欢迎各位用户前往对应部署空间体验我们的工具，上传一张动漫立绘，三分钟后就能拿到一个完整的分层PSD文件。同时也感谢平台运营人员的耐心支持和跟进。

See-Through 是我们组发表在 ACM SIGGRAPH 2026 Conference Proceedings 的工作。代码、模型权重、GUI 和训练代码均已开源。欢迎试用，也欢迎在创空间的交流反馈区拍砖。

声明：本项目为开源研究项目，我们未开设任何付费服务。如遇到以此功能收费的网站，均与我们无关，请注意甄别。

项目部署空间：国内开源模型托管平台对应地址

项目代码：GitHub开源仓库地址

研究论文：arXiv预印本链接