把大模型装进相机：打造 AI 驱动的照片修复系统

观熵

已于 2025-04-15 00:14:18 修改

阅读量662

点赞数 24

分类专栏：计算机视觉文章标签：数码相机人工智能 android 深度学习计算机视觉

于 2025-03-27 09:02:19 首次发布

本文链接：https://blog.csdn.net/sinat_28461591/article/details/146547539

版权

计算机视觉专栏收录该内容

21 篇文章

订阅专栏

个人简介

作者简介：全栈研发，具备端到端系统落地能力，专注大模型的压缩部署、多模态理解与 Agent 架构设计。热爱“结构”与“秩序”，相信复杂系统背后总有简洁可控的可能。
我叫观熵。不是在控熵，就是在观测熵的流动
个人主页：观熵
个人邮箱：privatexxxx@163.com
座右铭：愿科技之光，不止照亮智能，也照亮人心！

专栏导航

观熵系列专栏导航：
AI前沿探索：从大模型进化、多模态交互、AIGC内容生成，到AI在行业中的落地应用，我们将深入剖析最前沿的AI技术，分享实用的开发经验，并探讨AI未来的发展趋势
AI开源框架实战：面向 AI 工程师的大模型框架实战指南，覆盖训练、推理、部署与评估的全链路最佳实践
计算机视觉：聚焦计算机视觉前沿技术，涵盖图像识别、目标检测、自动驾驶、医疗影像等领域的最新进展和应用案例
国产大模型部署实战：持续更新的国产开源大模型部署实战教程，覆盖从模型选型 → 环境配置 → 本地推理 → API封装 → 高性能部署 → 多模型管理的完整全流程
TensorFlow 全栈实战：从建模到部署：覆盖模型构建、训练优化、跨平台部署与工程交付，帮助开发者掌握从原型到上线的完整 AI 开发流程
PyTorch 全栈实战专栏： PyTorch 框架的全栈实战应用，涵盖从模型训练、优化、部署到维护的完整流程
深入理解 TensorRT：深入解析 TensorRT 的核心机制与部署实践，助力构建高性能 AI 推理系统
Megatron-LM 实战笔记：聚焦于 Megatron-LM 框架的实战应用，涵盖从预训练、微调到部署的全流程
AI Agent：系统学习并亲手构建一个完整的 AI Agent 系统，从基础理论、算法实战、框架应用，到私有部署、多端集成
DeepSeek 实战与解析：聚焦 DeepSeek 系列模型原理解析与实战应用，涵盖部署、推理、微调与多场景集成，助你高效上手国产大模型
端侧大模型：聚焦大模型在移动设备上的部署与优化，探索端侧智能的实现路径
行业大模型 · 数据全流程指南：大模型预训练数据的设计、采集、清洗与合规治理，聚焦行业场景，从需求定义到数据闭环，帮助您构建专属的智能数据基座
机器人研发全栈进阶指南：从ROS到AI智能控制：机器人系统架构、感知建图、路径规划、控制系统、AI智能决策、系统集成等核心能力模块
人工智能下的网络安全：通过实战案例和系统化方法，帮助开发者和安全工程师识别风险、构建防御机制，确保 AI 系统的稳定与安全
智能 DevOps 工厂：AI 驱动的持续交付实践：构建以 AI 为核心的智能 DevOps 平台，涵盖从 CI/CD 流水线、AIOps、MLOps 到 DevSecOps 的全流程实践。
C++学习笔记？：聚焦于现代 C++ 编程的核心概念与实践，涵盖 STL 源码剖析、内存管理、模板元编程等关键技术
AI × Quant 系统化落地实战：从数据、策略到实盘，打造全栈智能量化交易系统

一、引言：为什么我们需要“AI 修图”？

1.1 用户对照片质量的期待，在不断提升

随着手机摄影技术的进步，用户对照片质量的要求也水涨船高：

拍照不仅要清晰，还要美观；
照片不能有杂物、不能有路人甲，甚至不能有“闭眼”；
拍出来不好，也希望“一键变完美”。

但在真实拍摄场景中，我们很容易遇到以下这些痛点：

场景	常见问题
夜景/抓拍	手抖、拍糊、焦点跑偏
外景旅行	电线杆、垃圾桶、标识牌遮挡
合照自拍	某人闭眼、表情不佳、姿态不自然
旧照片修复	图片划痕、色彩失真、信息缺失

这些问题，传统图像处理技术（如高斯滤波、边缘保留等）解决能力有限，而卷积神经网络虽然强大，但理解能力不足。

1.2 为什么是“大模型”能够解决这些问题？

近年来以 Stable Diffusion、BLIP、Segment Anything、GPT-4V 为代表的大模型技术，具备以下能力：

对图片语义有更深理解：不再仅仅“看图”，而是能描述“这是一个穿蓝裙子的小女孩在跑步，右边是一个电线杆”
可以有目的地进行修复：不仅是修复一片模糊区域，而是可以根据上下文“补全楼梯”，“补上人的眼睛”，“重建缺失的背景”
支持人机交互：你可以告诉模型“去掉电线”、“修一下闭眼的人”，它能听懂并执行

简而言之，我们不再局限于图像滤镜和模板化“美颜算法”，而是拥有了一个会思考的图像修复师。

1.3 项目目标：打造一套“真正有 AI 的修复系统”

我们设定的目标非常清晰：

在我们自研的相机系统中，加入一个大模型驱动的照片修复能力，支持模糊图、遮挡图、老照片、表情缺陷等多种场景。

并且要做到：

用户只需“一键点击”或自然语言指令
云端推理快速、端上可离线使用
支持连续交互（用户可以不断修改）
支持开发者二次开发与模型切换

二、系统方案设计总览：先想清楚，再动手干

说到“用大模型修复照片”，大家第一反应可能是：是不是直接拿个开源模型，跑个推理就行了？

说实话，如果只是为了玩一玩，这当然没问题。但如果你真的想把这个功能集成进相机产品里，而且是面向真实用户使用——那就不能一股脑堆模型了，得从系统层面好好设计一套方案。

这章我就来讲讲我们这个“AI 修图引擎”是怎么搭建出来的，踩了哪些坑，做了哪些取舍。

2.1 首先，一个关键理念：解耦！解耦！解耦！

我们一开始就定了个技术原则：

把图像理解、语义构建、修复推理、后处理这些模块“解耦”出来，模块之间只通过标准格式（比如 JSON / 图片 + mask）通信。

为啥？有三个原因：

方便后续替换模型：今天用的是 SD-Inpaint，明天可能换成 GPT-4V+SAM；
支持不同部署形式：有的模块跑在云端 GPU，有的模块必须本地离线；
便于联调 & 回溯问题：出问题了，不用怀疑整个链路，只看出错模块。

2.2 系统结构长什么样？

别急，先看图：

[原图] 
  ↓
[图片预处理]（分辨率统一 / 探测是否损坏）
  ↓
[图像语义理解]（BLIP-2 / GPT-4V）
  ↓
+ 用户描述（可选：“去掉电线”）
  ↓
[Prompt 构建]（自动 + 手动融合）
  ↓
[图像修复模型]（如 SD-Inpainting / LaMa）
  ↓
[增强后处理]（GFPGAN、超分、色彩平衡）
  ↓
[输出结果 + 可视化对比]

整个流程拆成了这几个核心模块：

模块	干嘛的	举例模型
图像理解	看懂图片、生成描述	BLIP-2、GPT-4V
Prompt 构建	合成用户意图 + 图像语义	自定义 NLP 模块
修复模块	具体执行图像重建	StableDiffusion、LaMa
后处理	把结果“收尾”，变得更真实	Real-ESRGAN、GFPGAN
UI 接口	提供“涂抹、指令、对比”交互	Android/iOS/小程序

2.3 两种部署形态，按需切换

为了兼顾性能和用户体验，我们支持两种部署模式：

✅ 云端部署（主要模式）

后端部署了 SD-Inpainting、BLIP-2、控制引导模块
用户拍完图，图片上传至服务器修复
优势：修复效果最强、模型可升级
注意：需要网络 + 数据安全加密传输

✅ 本地轻量修复（离线模式）

本地使用剪枝后的 LaMa 或自研模型（支持遮挡消除、小面积修复）
模型转换成 TensorRT / NCNN，在移动端运行
优势：离线可用、不依赖网络、隐私友好
缺点：无法处理大面积重建任务

我们的策略是：默认使用云端修复，本地作为 fallback。 如果用户开启“省流量”模式或离线，就切换到本地小模型。

2.4 一些我们坚持做的“小细节”

在实际开发过程中，有几个我们后来非常庆幸坚持做的设计：

✅ 所有中间结果都可以 Debug（保存 mask、prompt、语义标签）
✅ 模型服务和业务服务分离（后端用 FastAPI 做统一转发）
✅ 用户可选多种交互方式（滑动涂抹、语音输入、自然语言）

这让我们在后期优化的时候非常轻松，不用到处查 log 和复现 bug。

三、核心模块拆解：让模型看得懂图、听得懂人话

在这部分，我们来深入讲讲这个系统里最重要也最“聪明”的两个模块：图像语义理解 + Prompt 构建。

大多数人会以为“修图”这件事就是拿张图，找个模型一推理完事，但我们发现——真正让修图效果更自然、更智能的关键，是：让模型“知道你要干啥”，而不仅仅是“补个洞”。

3.1 图像语义理解：先看懂图，再动手修

传统的修图模型是不懂图的，它只看遮挡、缺失、边缘纹理。这就像让一个完全没概念的美术生去修一幅画，他只知道哪里缺颜色，却不知道那原本可能是一只猫还是一棵树。

为了解决这个问题，我们先让模型理解图像本身的内容，也就是“看图说话”：

✅ 我们用的是：BLIP-2（高效、可部署）

BLIP-2 是一个图像字幕生成模型，它能快速提取出图像的语义描述，给我们一段“图片描述文字”。

示例代码：

from transformers import BlipProcessor, BlipForConditionalGeneration

processor = BlipProcessor.from_pretrained("Salesforce/blip-image-captioning-base")
model = BlipForConditionalGeneration.from_pretrained("Salesforce/blip-image-captioning-base")

inputs = processor(images=image, return_tensors="pt")
out = model.generate(**inputs)
caption = processor.decode(out[0], skip_special_tokens=True)

生成的 caption 大概像这样：

"a woman walking near a temple with wires in the sky"

很好，这说明模型知道照片里有“人”、“庙”、“电线”和“天空”。

3.2 引入 DeepSeek：让模型懂你说什么，还会帮你说得更清楚

图像理解完了，接下来我们要解决第二个问题：

“用户说的” → “模型能理解的命令”

这是 Prompt 构建环节的核心。

有经验的研发都知道，语言指令很难标准化：

有人说“去掉电线”；
有人说“清理背景的乱东西”；
有人写“蓝天要清楚一点”；
还有人直接一句：“这张图修得跟旅游杂志一样。”

这时候，如果你只是简单把用户输入 + BLIP caption 拼一拼，不够智能也不够稳。

所以我们引入了 DeepSeek-V2 / DeepSeek-Chat 来承担这部分的工作。

✅ DeepSeek 用来干啥？三件事：

① 智能 Prompt 构建器

你给它图像 caption 和用户意图，它帮你生成一条专业的、适合送给修复模型的英文指令。

② 多轮交互的语境记忆器

用户说“再修一修右上角”，“这次修得自然一点”，DeepSeek 能记住上下文，构造合理的下一条指令。

③ 中文 → 英文的风格翻译器

用户输入中文，DeepSeek 负责把它转换成地道的英文修复 prompt，同时补充合理的上下文。

示例：构建 Prompt 的过程

用户输入：

“这张图把后面的电线去掉吧，人物保留。”

BLIP 输出：

“A woman standing in front of power lines with a cloudy sky”

→ 发送给 DeepSeek 的 prompt：

请基于以下内容，生成一条适合图像修复模型的英文指令：

图像描述：A woman standing in front of power lines with a cloudy sky
用户希望：这张图把后面的电线去掉吧，人物保留。

→ DeepSeek 输出：

"Remove the background power lines while preserving the woman in the foreground. Ensure the sky looks natural and consistent."

是不是比我们自己拼接的 prompt 更专业、更清晰？

3.3 可选增强：mask 自动生成与语义辅助分割

有些用户是“手涂选区”，这很好，我们直接用 mask。

但大多数用户，尤其是普通用户，不会手动标注区域。他们说“把电线去了”，“把人修清楚”——那怎么办？

这时候我们引入了：

✅ Segment Anything (SAM)：自动找到明显的区域（比如电线、人、楼）
✅ Grounding DINO + BLIP：用文本找图中物体
✅ YOLOv8 + 分割模型：快速本地部署

结合起来，给修复模型喂 mask，就能做到“指哪修哪”，而不是“全图漫改”。

小结：修复之前，先让 AI 真正理解任务

你可以把整个模块理解为一个“中控系统”：

BLIP 负责“看图”
用户负责“说需求”
DeepSeek 负责“翻译成标准指令”
SAM / YOLO / DINO 负责“找到要修的部分”

四、图像修复模型选型与实战对比

前面几章我们做了很多准备工作：把图片看懂了、用户需求搞清了、Prompt 写好了，mask 也找到了——接下来就轮到修复模型出场了。

这一部分就像整个系统的“工匠”角色：前面的人都在沟通和规划，到了这一步，就要真正“落笔成图”了。

4.1 我们为什么不能只选一个模型？

这事听起来简单：修图 → 用一个模型不就行了？

但现实告诉我们：不同场景、不同目标，需要不同的模型。

举几个典型例子你就明白了：

场景	最适合的模型类型
小面积遮挡 / 平滑背景	✅ LaMa / DeepFill v2
语义级重建（比如“闭眼 → 睁眼”）	✅ Stable Diffusion Inpaint
自定义 mask / 图文修复	✅ SD + ControlNet / T2I-Adapter
多区域去除 + 场景替换	✅ SD Inpaint + Prompt 联动
端侧修复，轻量级	✅ 自研 LaMa-lite 模型

所以我们团队内部讨论的共识是：

“选一个通用模型是不够的，我们要的是一个‘修复模型池’，针对不同任务调度最合适的那个。”

4.2 模型评估与效果对比

我们从三个角度去比较了多个修复模型：

模型	类型	画质质量	推理速度（GPU）	是否可本地部署	特点
LaMa	局部修复	⭐⭐⭐	⚡️⚡️⚡️（<100ms）	✅	结构补全强，部署轻便
DeepFill v2	GAN 修复	⭐⭐	⚡️⚡️（~300ms）	✅	模糊边缘恢复好
Stable Diffusion Inpaint	文本引导重建	⭐⭐⭐⭐	⏳（800ms~1.2s）	⚠️ 不建议端侧部署	支持复杂 prompt 修复
ControlNet (Inpaint)	条件生成	⭐⭐⭐⭐	⏳（1.5s）	⚠️	支持边缘、语义分割
T2I-Adapter + SD	多模态输入控制	⭐⭐⭐⭐	⏳（1~2s）	❌	控制粒度细，画质好
自研 LaMa-lite (INT8)	轻量版	⭐⭐	⚡️⚡️⚡️（<50ms）	✅ Android可运行	适合本地小修补

示意效果图（建议实际博客配图）

我们在 500 张不同类型的样图中做了横向对比，发现：

SD-Inpaint 的“理解能力”最强，能修出语义正确的新内容；
LaMa 的边缘延展和平滑填补效果最自然；
ControlNet 更适合结构复杂的区域，比如人物边界修复；
DeepFill v2 虽然老，但部署快，效果稳定。

4.3 模型调用方式（推理流程）

示例：Stable Diffusion Inpaint 模型（用 diffusers）

from diffusers import StableDiffusionInpaintPipeline

pipe = StableDiffusionInpaintPipeline.from_pretrained(
    "runwayml/stable-diffusion-inpainting",
    revision="fp16",
    torch_dtype=torch.float16,
).to("cuda")

image = Image.open("input.png").convert("RGB")
mask = Image.open("mask.png").convert("RGB")

output = pipe(
    prompt="remove the electric wires and restore clean sky",
    image=image,
    mask_image=mask,
).images[0]

4.4 端侧部署经验：LaMa 模型是好朋友

要部署到移动端，最核心是：

模型够轻（<10MB，最好 INT8）；
推理快（<300ms）；
不依赖太多复杂算子（否则编译不过或不兼容 Vulkan）。

我们尝试把 LaMa 模型：

✅ 转为 ONNX
✅ 用 TensorRT 量化
✅ 编译为 Android NNAPI 接口模型（或用 NCNN）

结果在 Pixel 7 上可以 150ms 内完成一次局部修复，极其丝滑。

4.5 修复调度策略（系统智能分配）

我们最终把多个模型封装为一个统一接口，根据任务类型自动调度：

def select_model(prompt, mask_area, latency_tolerance):
    if "闭眼" in prompt or "补脸" in prompt:
        return "SD-Inpaint"
    if mask_area < 10% and latency_tolerance < 300ms:
        return "LaMa-lite"
    if prompt and "风格" in prompt:
        return "SD + ControlNet"
    return "LaMa"

这样我们可以在用户无感知的情况下选择最佳修复路径。

五、用户交互体验设计：把强大的修复力藏在一键背后

5.1 核心原则：修得再好，不如“用得舒服”

一句话总结我们在这部分的思路：

“让用户不需要懂模型，只需要点一下，就能看到‘哇！牛逼！’的修复效果。”

AI 修复再强，如果交互复杂、按钮太多、选项太难懂，用户根本不愿意尝试。

所以我们从一开始就把交互体验设计作为核心模块来思考，而不是“UI 最后补一补”。

5.2 主要交互模式设计

我们为用户提供了三种入口方式，每种都对应不同的用户使用习惯：

✅ 模式一：一键修复（默认入口）

场景：快速拍照后发现模糊/遮挡，想马上“救一救”
交互：点击“智能修复”按钮，系统自动识别问题区域并修复
底层动作：
- 检测模糊程度、识别遮挡
- BLIP 提取图像语义
- DeepSeek 生成默认 Prompt（例如“please recover blurry face”）
- LaMa 或 SD Inpaint 自动修复并展示前后对比

用户体感是：“我啥都没说，但你真修好了，还挺懂我。”

✅ 模式二：区域涂抹修复（用户标注 + AI 处理）

场景：用户想指定清楚某块区域（如电线、路人、水印）
交互：
- 用户手指涂抹区域
- 系统生成 mask，结合图像语义识别被选区域
- DeepSeek 生成目标引导 prompt（如“remove the person in the lower right”）
- 修复并展示前后对比

用户感知是：“我画哪就修哪，不多动其他地方。”

✅ 模式三：自然语言指令修复（全场景能力）

场景：用户有明确意图（比如“让人脸更清晰”、“去掉上方的广告牌”）
交互：
- 输入框或语音输入
- DeepSeek 分析指令、结合图像描述生成精准修复 Prompt
- 使用 Stable Diffusion Inpaint + Prompt 控制修复
- 展示结果 + 是否满意（用户可以说“还不够自然”继续二次修复）

用户感觉：“我说你就懂，修得还真准。”

5.3 前后对比交互设计（体验瞬间打动人）

我们发现，大部分用户第一次觉得“AI 修复太神了”，不是因为算法有多复杂，而是看到修复前后切换那一瞬间。

所以我们实现了：

🔁 拖动对比条：可左右滑动查看前后图
🕶 双图切换：点击按钮在原图/修复图间快速切换
🧠 修复过程动画：模拟“AI 正在思考和修复中”的过程动画，增强科技感

5.4 错误处理和兜底体验

我们还为一些边缘场景设计了贴心的兜底逻辑：

情况	处理方式
修复失败（GPU负载高）	自动回退至 LaMa 轻量修复
无法识别区域（mask 异常）	提示用户重新圈选区域
网络中断	切换至本地离线修复模式（LaMa-lite）
用户不满意修复结果	提供“换一种方式修复”选项，调用备选模型 + 新 Prompt

5.5 快速反馈机制（体验闭环）

为了让用户感知“系统真的理解他”，我们引入了快速反馈按钮：

👍 / 👎
“这次修得不够自然” → 自动生成新的 Prompt → 修复
“保留原图” → 恢复原始图并保存

这些设计不仅增强了交互，还帮助我们收集数据、优化模型策略。

六、系统性能评估与部署调优：让修图系统跑得快、修得稳、扛得住

6.1 为什么评估这件事这么重要？

我们一开始也很兴奋地搞了各种大模型拼搭实验，效果都“肉眼可见的强”，但上线前发现几个严重问题：

一张图修一次 2 秒，用户直接关掉；
GPU 一高负载，API 整个炸掉；
有些图修得很好，有些完全跑偏，用户体验极不一致。

所以，我们必须系统性地建立一套评估指标体系，才能知道：

“修得好”到底是怎么定义的？
“跑得快”是多快？“修得准”是多准？“用户满意”又从哪里衡量？

6.2 我们构建的三类指标体系

✅ 一类：模型推理性能指标（硬指标）

指标项	目标值	说明
平均推理耗时（云端）	< 1.2 秒	SD-Inpaint，A10 GPU
平均推理耗时（端侧）	< 300 ms	LaMa-lite，INT8
端到端接口响应	< 2 秒	包含图上传/修复/下载
显存占用	< 8 GB	控制多个模型共存不爆

✅ 二类：修复质量评分（主观 + 客观混合）

我们构建了 1000 张图的测试集（包括模糊图、划痕图、遮挡图、人脸图），通过以下方式评估修复效果：

维度	指标	说明
图像结构相似度	SSIM	修复后是否保留原图结构
视觉相似度	LPIPS	与真实图像的语义接近度
人脸一致性	FaceID-CosSim	修复前后人脸特征偏差
主观满意度	用户打分（1~5）	实际用户评分（满意/不满意）

我们目标是：主观满意率 ≥ 87%，LPIPS 控制在 0.2 以下。

✅ 三类：系统稳定性与资源评估

维度	指标	说明
并发支持	QPS ≥ 30	每秒可处理请求数，支持小流量公测
容错率	< 2% 错误率	推理失败 / 预处理异常占比
日均 GPU 时长	< 18 小时 / GPU	控制云端资源成本
异常报警	全链路监控 + 邮件通知	任何模块异常及时报警通知研发组

6.3 模型优化实战：精度、速度、容量的平衡术

🎯 SD-Inpaint 模型优化

原模型加载 6.7GB，推理时间 2.5s；
我们用 fp16 精度压缩 + TensorRT 编译；
最终部署到 A10 上推理耗时降至 1.1s；

提示：换 diffusers pipeline 的 scheduler 可以带来 10~30% 提速！

🎯 LaMa-lite 模型本地化流程

从原始 PyTorch 模型导出为 ONNX；
使用 TensorRT 将其量化为 INT8；
编译成 Android 端用的 .ncnn；
使用 Vulkan 推理，平均耗时 < 200ms；

6.4 系统部署方案一览

我们把修图系统分为两层部署：

✅ 云端部署架构

[Nginx API 网关]
      ↓
[FastAPI 服务层]
      ↓
[修复任务调度器]
  ↓           ↓            ↓
[BLIP-2]   [DeepSeek]   [修复模型池]

GPU 环境部署于阿里云裸金属服务器（A10x 2卡）
每个模型独立容器，按需启动
使用 Celery + Redis 做异步任务队列

✅ 移动端部署架构

[Android 摄像头拍照]
      ↓
[图片压缩 + 模糊检测]
      ↓
[修复引擎 LaMa-lite (本地)]
      ↓
[修复图预览 + 对比 UI]

使用 Jetpack Compose 构建前端界面
修复结果落地缓存，支持一键恢复原图

6.5 线上压测结果（Beta 内测阶段）

内测 7 天，5000+ 次修复调用
平均响应时间：1.8s（云端），260ms（端侧）
用户主动点赞率：61%
常见负反馈：“某些图修得不自然”——我们已反馈至 Prompt 生成模块调优

小结

评估和优化是一项“看起来没那么炫酷，但做得好能救命”的工作。

我们不是为了展示“AI 修得多炫”，而是要做到：

快速返回、不拖体验；
稳定运行、不怕量大；
修图质量稳定，能抗复杂场景；
用户用得开心，愿意留下来。

七、部署到移动端：把“AI 修图师”装进用户的口袋里

7.1 为什么要做移动端部署？

虽然云端模型效果更强大，但我们始终认为：

AI 修图系统最终应该成为用户手机里的“随身修图助手”。

原因很简单：

✅ 用户拍照完就想立刻修复，不想等上传；
✅ 离线使用是刚需（比如在高铁、景区、无信号区域）；
✅ 用户数据不能随便上传（尤其是人像/隐私图）；
✅ 云端成本高，本地部署能分担压力、节省资源；

所以，我们从一开始就规划了端侧修复引擎 + 云端高阶修复能力双轨策略。

7.2 我们怎么把修复系统部署到手机上？

说白了，就两件事：

把核心模型部署到手机能运行的形式；
把整体流程适配到用户使用习惯里。

✅ 模型部分：轻量化 + 端上适配

以我们部署的 LaMa-lite 为例：

✔️ PyTorch → ONNX；
✔️ ONNX → TensorRT INT8（或 NCNN）；
✔️ 编译支持 Android NPU/Vulkan/NNAPI；
✔️ 控制模型大小 < 10MB，推理耗时 < 250ms；
✔️ 关键算子：卷积、Relu、Upsample、InstanceNorm 等均适配良好。

如果你想部署 SD 类模型到移动端，不建议使用原始模型，而是考虑：

转为 GGUF 格式，用 llama.cpp 的分支改造；
或使用 MLC LLM/MNN/NCNN 等推理框架，性能控制在 1-2 秒。

✅ 产品部分：交互优化 + 用户感知

修图按钮集成到相机拍照后预览界面，点击一键修复；
修复过程加动画 + “AI 正在处理…”提示，增强信任感；
可离线使用提示：“当前为本地修复模式，推荐连接网络获取高清效果”；
修复结果落地缓存 + 一键恢复原图，防止误操作；
用户反馈入口嵌入 UI 中，便于收集样本调优模型。

7.3 我们踩过的几个坑（一定要避开）

问题	解决方案
INT8 模型量化后精度严重下降	局部层保留 FP16，使用混合精度量化
部分 Android 设备 Vulkan 不兼容	检测 NNAPI 支持情况，动态切后备路径
修复区域不准，边缘残留	控制 mask 滤波平滑 + 模型后处理裁边
用户误点击后无感知	添加遮罩 Loading UI + 修复进度条
模型加载慢	使用热加载 + 模型缓存在 App 初始化阶段预载