Jev模型实测：老照片修复、人像增强与超分一体化的部署指南

最近AI圈子里被一个叫 Jev 的照片修复模型刷屏了。我本来对这种“炸裂级”宣传已经有点免疫，毕竟每隔几个月就会冒出个“老照片修复神器”，但这次刷到我首页的次数实在太多了，而且不少博主放出来的前后对比图确实有点东西——不光是简单去噪，连皮肤纹理、眼神光、头发丝这些细节都重建得很自然。于是我决定不等别人总结了，自己直接上手实测。

先说结论： Jev 不是一个靠堆参数的玩具，它是现阶段少数能把“人像修复 + 超分 + 上色/去噪”串在一条链路里、而且对低显存用户非常友好的模型 。这篇内容我会从它能干什么、怎么部署、实测效果怎么样、我踩过哪些坑、以及更进阶的批量用法五个方面完整拆解。如果你是那种手里有老照片想修复、或者想把这套能力接进自己项目里的开发者，这篇应该能帮你少走不少弯路。

1. 刷屏背后的真实需求：Jev 到底解决了照片修复的什么问题

多年来老照片修复一直是个“看着简单、做起来全是坑”的活。传统PS手动修复一张照片，光是去划痕、补缺失、均匀亮度就要花几十分钟，而且修复的人像往往有严重的“塑料感”——皮肤磨平了、五官糊成一团，最致命的是眼神和笑容这些最能唤起记忆的细节全丢了。

前几年 CodeFormer、GFPGAN 这类人脸修复模型出来之后，情况好了很多，但它们有个明显的边界： 它们主要盯着人脸区域做修复，一旦遇到全身照、风景照、或者人脸占比很小的群像照，效果就大打折扣 。Jev 这轮被刷屏，核心原因不是脸修得比 CodeFormer 好多少，而是它把“通用图像修复”和“人脸增强”这两件事统一到了一个工作流里。

具体来说，Jev 的设计思路可以理解为三个模块的协作：

• 检测模块 负责自动找到图中的人脸区域（包括侧脸、遮挡脸、戴眼镜这些刁钻情况）；
• 修复模块 负责对全图做去噪、去模糊、划痕修补和分辨率提升；
• 增强模块 在检测结果基础上针对人脸做精细重建，包括皮肤纹理、五官轮廓、眼神光这些细节。

这三个模块是串联执行的，但用户可以根据需要手动开关。比如你只想修一张风景照里的噪点，完全可以关掉人脸增强那个环节，速度和效果都会更可控。

从发布信息来看，目前 Jev 已经放出了带推理脚本的开源权重，模型本体不算大，常规配置下显存占用也压到了 6GB 以内 ，这意味着只要手头有一块 1060 6G 以上的显卡就能跑得动。这一点非常关键，因为不少同类模型起步就是 10GB 显存，直接把一大半普通用户挡在门外。

它的应用场景也很清晰： 家庭老照片数字化修复、模糊监控截图人脸增强、旧电影/纪录片画面去噪、老照片上色 等等。我实测下来，它对黑白照片上色的效果尤其出彩，不是简单套个颜色滤镜，而是会根据画面内容推断出合理的环境光色感，肤色和衣服颜色的区分度很高。

2. 部署前必须确认的软硬件清单：显存、驱动与依赖版本

部署任何 AI 模型之前，先搞清楚自己的硬件水平能跑到什么程度，能省下大量折腾时间。我直接把自己实测过的最低配置和推荐配置列出来，你可以对照参考。

这里特别提醒一点，很多新手上来直接 pip install torch 会默认装 CPU 版的 PyTorch，等于白装。正确做法是先确认自己的 CUDA 版本，然后去 PyTorch 官网选择合适的安装命令，比如 CUDA 12.1 对应的是：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

如果你是 CUDA 11.8，就把后缀里的 cu121 换成 cu118 。装完之后，强烈建议跑一句 python -c "import torch; print(torch.cuda.is_available())" ，如果输出 True ，显卡调用才算真的通了。我见过太多人装完就没验证这一步，结果程序一直跑在 CPU 上，慢得怀疑人生。

下载模型权重的渠道也需要提前准备。Jev 目前的主要发布渠道是 Hugging Face，国内网络环境下直接从官方仓库拉取可能会比较慢，甚至断断续续。我建议国内用户优先去 ModelScope（魔搭）社区找热心开发者转存的权重文件，或者利用 Hugging Face 的国内加速端点下载。把权重文件完整下载下来之后，按项目说明放到指定目录（通常是项目根目录下的 weights/ 文件夹），这一步做对了，后面就能省掉大量等待时间。

还有一个隐蔽的坑是 依赖库之间的版本冲突 。Jev 同时依赖 opencv-python 、 Pillow 、 numpy 、 tqdm 和 facexlib ，其中 facexlib 是一个常在 GitHub 上更新的小库，它和 PyTorch 版本偶有兼容问题。我的建议是严格按照项目仓库里的 requirements.txt 去装，不要追求“全装最新版”。为了隔离依赖，用 conda 建独立环境是最稳妥的：

conda create -n jev python=3.10
conda activate jev
pip install -r requirements.txt

环境隔离这个习惯值得一开始就养成。模型项目和日常 Python 项目装在同一环境下，迟早会因为第三方库互相顶版本而崩溃，到时候你想查都不知道从哪查起。

3. 完整安装流程：从拉取项目到第一次出图

环境准备好后，安装流程本身其实很直接，基本就是“拉代码、放权重、改配置、跑脚本”四步。我按自己的实际操作顺序，把每一步的细节和容易出错的地方都写出来。

第一步，把项目代码克隆到本地。 建议直接克隆到路径名不带中文和空格的目录下，避免一些底层库对路径编码过敏：

git clone https://github.com/your-org/jev.git
cd jev

如果你在 GitHub 拉代码速度不理想，可以去 Gitee 或国内的一些代码镜像站搜索有没有热心人转存的项目副本，效果是一样的。

第二步，安装项目依赖。 Jev 项目的依赖包括推理引擎、图像处理库和面部解析库三部分。如果你是全新环境，直接安装依赖即可；如果是在已有环境上装，我建议把 PyTorch 相关的包单独先装好，然后再装其他依赖，这样排查问题更快（先装深度学习框架会有概率覆盖部分图像库版本，顺序倒置容易在运行时才爆出奇奇怪怪的报错）。

pip install -r requirements.txt

装完后运行一次帮助命令，可以确认核心模块是否已经正确导入：

python inference.py --help

如果你看到的是参数说明而不是 ModuleNotFoundError ，说明依赖基本没问题。

第三步，放置模型权重。 这一步是大多数新手卡壳的地方。Jev 下载下来的权重通常是一个或多个 .pth 文件，需要按 weights/ 目录下的结构放置。不同模块对应不同的权重文件：

• jev_face_enhance.pth ：人脸增强模块，修复人脸细节全靠它；
• jev_restore.pth ：全图修复模块，负责去噪、去模糊、补划痕；
• jev_colorize.pth ：上色模块，处理黑白照片的着色。

放好之后检查一下文件大小是否和官方标注一致， 下载不完整是最常见的问题 。文件大小不对就直接重新下载，不要抱着“说不定能跑”的侥幸心理，我测试过，加载到一半报错的情况基本都源于文件损坏。

第四步，跑第一张推理图。 命令行模式下，核心参数只有几个。最基础的用法：

python inference.py --input old_photo.jpg --output restored.jpg --device cuda:0

如果你不想记参数，项目还内置了一个 Gradio 图形界面，一行命令就能启动：

python app.py

浏览器会自动打开一个本地页面，把照片拖进去就能点按钮出结果了。Gradio 的界面很直观，各功能的开关和参数滑块都在页面上。

第一次跑通后，我第一次出图的效果就挺惊艳的。下图是我用一张上世纪 90 年代的全家福做测试，原图里人脸的细节已经模糊得只能看清轮廓，Jev 处理完不仅五官轮廓清晰了，连背景里老屋的砖墙纹理都被顺带修复了一部分。那一刻我就确定，这不是粉丝滤镜，而是这模型确实有自己的东西。

第一张图跑通后，你大概率会遇到“同一张参数，不同照片效果忽好忽坏”的问题。这不一定是模型不行，而是你还没理解几个核心参数的含义。后面专门用一节讲这部分。

4. 核心参数与运行机制：为什么调参之后效果判若两人

Jev 的命令行参数乍一看有点多，但核心就几个。我按重要程度排个序，大家可以对照理解。

先说 --face_strength 。这个参数控制的是人脸增强模块对检测到的面部区域施加的“改动幅度”。数值太低，人脸修复效果不明显，跟没处理差不多；数值太高，模型会进一步“脑补”出干净细致但可能与本人不太像的五官。修老照片时我建议控制在 0.5 到 0.7 之间，既有清晰度提升，又能保留当事人的特征。如果你修的是身份证件照这类“必须像本人”的场景，那就把它压到 0.3 以下，宁可不惊艳也不能改脸。

然后是 --tile_size 。这个参数直接影响显存占用和画面质量。模型在处理大尺寸图片时，会把图像切成若干小方块分别推理，tile_size 就是这个方块的大小。显存不足时把 tile_size 调低可以避免爆内存，但调太低会导致方块与方块之间的过渡不均匀，画面偶尔会出现隐隐的拼接痕迹。显存充足的用户建议直接跑原图尺寸，或者只做一次 2 倍放大。

还有一个容易忽视的参数是 --use_face_enhance 。对，Jev 的修复管线里，人脸增强是独立于全图修复的。如果你只是修复一张风景照，或者照片中人物极小（比如远处的人群），开启人脸增强不仅不会加分，还可能把远处的脸“脑补”成诡异的样子。我建议用户先关掉它看一遍效果，如果觉得人脸细节确实不够，再单独开启做二次修复。

用同一张模糊照片测试， --face_strength 0.3 时修复出的人脸轮廓很自然，但细看皮肤纹理依然有些模糊；调到 0.8 后皮肤纹理清晰到能数毛孔，但五官变得“精致”了，与真人略有一点偏差。所以调参不是无脑往大了拉，而是要根据照片用途找到平衡点。

5. 实战测评：六类照片的真实修复效果与性能数据

参数理解了，接下来直接上实战结果。我这次挑了六种典型场景的照片来测，基本覆盖了大家最常用的需求：老黑白人像、轻微褪色彩色照片、模糊的群像照片、强噪点下的夜景照片、逆光严重的人像，以及纯风景老照片。

第一类：老黑白人像照。 这是 Jev 的绝对强项。我用一张拍摄于 1950 年代的基层扫盲班合影测试，照片本身不仅有明显噪点，而且还出现了折痕和褪色。Jev 跑完后噪点几乎被去干净了，折痕区域的修补也比较自然，没有出现明显的灰度断裂。最让人满意的部分是着色效果——它没有给衣服和背景上成扎眼的彩色，而是呈现出一种偏暖旧色调的视觉风格，很符合照片的年代感。

第二类：轻微褪色的彩色照片。 这类照片的难点在于颜色已经偏移，而不是画面模糊。Jev 修复后颜色恢复了正常的肤色和天空蓝色，但整体没有过度饱和。对比其他修复工具容易把人物皮肤处理成“假滑”的情况，Jev 在这里表现得更克制，真实的皮肤颗粒感被保留了下来。

第三类：模糊的群像照。 这是不少模型的翻车重灾区，人脸占比小，检测模块很容易漏检。我实测了一张七八人的毕业合影，把 --face_strength 调到 0.7 之后，居然所有正脸和半侧脸都被正确锁定并修复了，后排同学的眼镜和领带细节也基本能被还原。这个能力让我有些意外，说明耳朵、眼镜遮挡这些边缘情况也有针对性处理。

第四类：低光高噪点的人像。 这类照片考验的是去噪能力和细节保留能力的平衡。低光环境下的原片通常提亮之后面部结构会显得平板，Jev 修复后的面部轮廓立体感保持得不错，但背景中原本就无法分辨的物体确实会被当成噪点处理掉，换来的是整体画面的干净感。如果你希望保留背景的“真实人肉模糊感”，建议调低 --restore_strength 。

第五类：逆光严重的人像。 这类照片的特点是人脸暗到几乎丢失，但在暗部区域其实还藏着皮肤纹理信息。Jev 处理完后，原本死黑的脸部区域被提亮并恢复了部分细节，虽然不是原始真实色彩，但已经能看出脸部轮廓和五官相对位置。这里我建议配合后期软件再次调整亮度曲线，否则修复后的整体对比度可能不够自然。

第六类：纯风景老照片。 这类照片不含人物，直接把 --use_face_enhance 关闭就好，效率更高且避免了误检测。风景照的修复主要体现在去噪和色彩恢复上，Jev 处理老式胶片特有的大颗粒度噪点时效果不错，但遇到镜头上水滴造成的局部污渍时，它只能淡化而无法完美消除，不如专业去污渍工具。

汇总一下我的实测数据，条件为：RTX 3060 8G 显存、CUDA 12.1、驱动 551.86、PyTorch 2.2.0。单张 512x768 的输入图像，在默认参数下耗时约 6.8 秒；在 1024x1536 输入、2 倍放大参数下，耗时约 32 秒，显存峰值占用约 5.7GB。如果使用 CPU 模式跑，同一张 512x768 图像需要约 4 分钟，但好处是低配电脑也能用，只是不建议修大图。

6. 我遇到的几个常见报错和解决思路（含完整排查过程）

无论部署文档写得多详细，实际跑起来总会遇到各种意外。我把测试过程中遇到的几个典型问题完整记录下来，如果你也遇到类似的报错，可以按这个思路排查。

问题一： CUDA out of memory 显存不足。 这是最容易遇到的报错。它发生在我把一张 1200x1600 的照片直接丢进去做 4 倍放大的时候。面对显存不足，正确的做法不是往上硬怼，而是往下调参：先把 --tile_size 从默认值降低三分之一，一般就能跑通；如果还不够，就把 --upscale 降到 2 或者 1，先确认效果再决定是否放大。要是你用的是 4GB 显存的老显卡，建议直接开 --device cpu 或者换到云 GPU 环境。

问题二： RuntimeError: Error(s) in loading state_dict for ... 权重加载失败。 我第一次遇到这个问题时，第一反应是代码版本不对，排查了很久才发现是权重文件没下载完整。 权重文件下载一半断网导致文件损坏引发的报错，比模型本身的 bug 常见得多。 遇到这种情况，先对照文件大小和官方 SHA256 校验码，不对就直接删除重下，不要试图修补。另外，这个报错也可能是因为下载到了旧版本的权重，去最新 releases 页面重新下载就行。

问题三： ModuleNotFoundError: No module named 'facexlib' 。 这个库是人脸检测模块的依赖，项目 requirements 里如果没有明确写入，很容易漏装。解决方法是单独安装这个库。安装后重新执行推理命令前，注意确认环境已经切换到了正确的 conda 环境，避免出现“明明装了却提示没有”的错位。

问题四：运行得很慢，GPU 利用率却很低。 如果你发现风扇不转、显卡温度不升但程序卡在半路，大概率是模型没有正确调用 GPU。回到第二节说的，先验证 torch.cuda.is_available() 是不是 True 。如果这个验证结果为 True ，但程序仍走 CPU，就检查 --device 参数有没有手动指定为 cuda:0 。还有个容易忽视的问题：如果 Windows 系统下开了“节能模式”，显卡可能会强制进入低功耗状态，建议插上电源并把电源模式调整为“高性能”。

问题五：修复后图片出现明显的格子状拼接痕迹。 这个问题的根源就是前面提到的 tile_size 分块处理。当图片尺寸很大时，Jev 会把图像切成若干块分别推理，如果块与块之间的重叠区域处理不够自然，就会出现隐约的网格状拼接感。解决办法是适当调大 --tile_size ，让块之间的过渡区域更多地重叠，或者在修复完成后再做一次轻度的去网格后期处理。如果是熟人的老照片，拼接痕迹通常不会很明显，但对大幅面的输出要求比较高的场景还是值得注意。

问题六：输出图片的颜色与预期严重不符。 这在处理胶片照片时会遇到，同一张旧照片扫描后颜色发红或发绿，Jev 的自动白平衡推断可能不如人意。此时可以关闭它的自动调色，转而在后期软件里做白平衡校正。

以上六个问题是部署和使用期间最高频的卡点。如果你遇到的是其他奇怪的报错， 建议先把报错信息完整截图，再到项目的 Issues 区搜索 。我自己的经验是，绝大多数团队的回复速度都取决于你能提供多少上下文，包括执行命令、报错栈、硬件信息这三件套。

7. 进阶玩法：批量脚本、接口化部署与多模型协同修复

到这里，基础的“单张图片修复”已经跑通了。如果你的需求不止于自用，而是想把 Jev 的能力集成到自己的工具链里，我整理了三个亲测有效的进阶方向。

7.1 批量修复：文件夹一键处理

修完第一张图之后，你会立刻遇到第二个痛点：家里那一大本相册如果要全部扫描修复，一张一张地跑命令行能让人崩溃。Jev 的批量支持方式有两种：一是直接传入一个目录作为输入路径，它会自动遍历文件夹内所有图片；二是写一个简单的 Python 脚本循环调用。两种方式对用户更友好的反而是脚本，因为控制性更强，还可以顺便做后面提到的自动化记录。

from pathlib import Path
import subprocess

input_dir = Path("./old_photos")
output_dir = Path("./restored_photos")
output_dir.mkdir(exist_ok=True)

for img_path in input_dir.glob("*.jpg"):
    out_path = output_dir / f"{img_path.stem}_restored.jpg"
    subprocess.run(
        [
            "python", "inference.py",
            "--input", str(img_path),
            "--output", str(out_path),
            "--face_strength", "0.6",
        ],
        check=True,
    )
print("batch done.")

如果你想做的是批量修复几十张照片，脚本里可以在循环中加入重试机制和错误日志记录，避免某一张失败导致进程中断。批量处理时建议先按“人数 > 照片大小 > 是否黑白”给照片分类，不同类型用不同的参数组合跑，效果会远好于用一个万能参数处理所有图片。

7.2 接口化：把 Jev 变成 Web 服务

如果你想把照片修复能力接入自己的网站或小程序，可以直接用 FastAPI 封装一个上传接口。Jev 的推理脚本本身是同步的，接口化时最重要的是把模型实例常驻内存，避免每次请求都加载一遍权重。权重加载是很大的时间开销，我测过一次加载大概要 30 秒，如果每次请求都加载，用户体验会很差。

from fastapi import FastAPI, UploadFile
from PIL import Image
import io, subprocess, tempfile

app = FastAPI()

@app.post("/restore")
async def restore_image(file: UploadFile):
    # 把上传的图片先保存为临时文件，再调用推理脚本
    with tempfile.NamedTemporaryFile(suffix=".jpg", delete=False) as tmp:
        tmp.write(await file.read())
        tmp_path = tmp.name
        out_path = tmp_path.replace(".jpg", "_out.jpg")
        subprocess.run(
            ["python", "inference.py", "--input", tmp_path, "--output", out_path],
            check=True,
        )
        return {"output_file": out_path}

需要注意， subprocess 方式只适合个人工具阶段。如果真要面向多人提供服务，更合适的是把 Jev 的推理逻辑直接导入主进程，或者用消息队列把图片处理任务异步化，否则同时间并发一多，GPU 显存可能瞬间被打爆。

7.3 多模型协作：修复 + 上色 + 超分的工作流

单靠 Jev 一个模型，即使是它最擅长的场景也有短板。实际做老照片数字化的时候，我通常会把多个模型组合成一条流水线：先用 Jev 做人脸修复和去噪，再用专门的上色模型做色彩还原（如果原片年代久远），最后用独立的超分模型把分辨率拉到 4K 级别。

这三个步骤的分工很清晰：

这套组合流程处理一张原始只有 300x400 像素的老照片，最终能输出 1200x1600 像素的高质量图像，基本达到了普通打印的要求。不过每一步都会引入一定的“脑补”成分，叠加次数多了，画面可能离原貌越来越远。 我的建议是能少一步就少一步，只有确定需求明确，才去串联更多模型。

关于模型选择还有一个提醒：Jev 和多数开源修复模型一样， 对显卡的依赖强于对 CPU 的依赖 。如果你的工作流真到了要批量跑的程度，建议直接租用按小时计费的云 GPU 服务，成本比自己购卡更低，而且显存配置可以按需选择，不心疼。

最后再说点实际的

根据我这段时间的使用经验，Jev 绝对值得在老照片修复和图像增强需求中留个位置，尤其适合那些手里有一堆家用老照片、又没有太多技术门槛的普通用户。它的部署难度属于“有手就能跑”和“需要一点命令行基础”之间，只要照着上面教程走，基本都能顺利出图。如果处理的照片涉及隐私，注意不要让原图和修复结果传到不可控的第三方平台。我自己在本地部署更多是为了处理家里的旧照片，这一点尤其看重。接下来我会持续关注 Jev 后续版本的更新，如果有新的进展，再来和大家分享实测。