Chinese-CLIP 使用、训练与量化全梳理

中文多模态里，Chinese-CLIP 一直是一个很实用但也很容易被“半懂不懂地使用”的模型。很多人知道它能做图文检索、零样本分类，也知道它有 ViT-B/16、ViT-L/14、ViT-H/14 这些规模，但一旦往工程里落，问题马上就会变具体：

• 我到底应该用 cn_clip 官方 API，还是直接走 Hugging Face 的 ChineseCLIPModel？
• 训练是不是只能全量训？有没有更省资源的办法？
• 它官方支持到什么程度？哪些压缩/量化路线是 Chinese-CLIP 原生支持，哪些只是通用工具链“理论可套”？

我把公开资料重新过了一遍，尽量只看原作者和主流官方工具链的第一手文档。下面这篇，等价于一个截至 2026 年 7 月 21 日 的“Chinese-CLIP 可落地方法地图”。

先说结论：Chinese-CLIP 的方法别混着看

如果把 Chinese-CLIP 相关方案全堆在一起，很容易出现一种误解：好像“会用模型”“会训练模型”“会量化模型”是同一件事。其实不是。

更准确的拆法应该是三层：

1. 官方原生使用层 直接跑 Chinese-CLIP 已经公开的 API、检索、零样本分类、特征抽取和部署脚本。
2. 官方训练增强层 在官方训练脚本基础上，继续加显存优化、蒸馏、梯度累积、FlashAttention 这些作者已经放进仓库的能力。
3. 通用压缩量化层 这部分很多不是 Chinese-CLIP 仓库自己内建的，而是要借助 PyTorch、ONNX Runtime、OpenVINO NNCF、Hugging Face 量化生态去接。

这三层混在一起，最容易出错的地方就是：把“官方支持 TensorRT 导出”误以为“官方已经把各种 int8 / int4 量化都打通了”。截至我这次整理时，Chinese-CLIP 官方最明确支持的部署加速路线，仍然是 PyTorch 到 ONNX，再到 TensorRT 的导出与推理。更广义的量化，更多是“通用框架可以接入”，不是“仓库作者已经把每条路替你验完了”。

第一层：Chinese-CLIP 现在到底怎么用

1. 直接用 cn_clip 官方 API

这是最贴近原仓库的方式，也是上手成本最低的方式。

官方仓库提供了 cn_clip 包，可以直接做：

• 图像特征提取
• 文本特征提取
• 图文相似度计算
• 图文检索

这条路最适合两类场景：

• 你想快速做一个中文图文检索原型
• 你已经接受“我就围绕官方仓库的工程组织方式来跑”

它的优点是最接近作者验证过的路径，缺点是工程自由度没那么高，很多时候你会自然走进它定义好的数据组织和脚本体系里。

2. 直接用 Hugging Face ChineseCLIPModel

Chinese-CLIP 后来已经合入了 Hugging Face Transformers，这意味着它不再只能用原仓库那套 API。

如果你本来就在 Hugging Face 生态里做事，这条路会更顺手：

• ChineseCLIPModel.from_pretrained(...)
• ChineseCLIPProcessor.from_pretrained(...)
• get_image_features
• get_text_features

这条路的好处很明显：

• 更容易和现有的 Transformers 工程拼接
• 更方便接统一推理、设备映射和后续量化工具
• 更适合把 Chinese-CLIP 当作一个标准双塔编码器来使用

如果你是做服务化、流水线化、批量 embedding 计算，我反而更推荐优先看 Hugging Face 这条线，因为后面的压缩和部署生态会更完整。

3. 官方检索与零样本分类脚本

如果你的目标不是“嵌入到业务代码”，而是想复现 Chinese-CLIP 在公开任务上的标准用法，那原仓库已经给了相对完整的流程：

• 用 extract_features.py 抽图文特征
• 用 make_topk_predictions.py / make_topk_predictions_tr.py 做双向检索
• 用 evaluation.py / evaluation_tr.py 算 Recall
• 用 zeroshot_eval.sh 做零样本图像分类

这套脚本路线的价值，不是优雅，而是可复现。你如果后面要比较自己 finetune 前后到底有没有提升，这些官方脚本能帮你少很多“评测口径漂移”的坑。

第二层：Chinese-CLIP 训练有哪些方法

1. 论文里的两阶段预训练

Chinese-CLIP 论文里最值得记住的一点，不是“它是中文 CLIP”，而是它提出了一个非常明确的预训练节奏：

• 第一阶段先冻结图像编码器
• 第二阶段再放开全参数训练

这个两阶段方法是 Chinese-CLIP 原始能力形成的重要前提。也就是说，如果你问“从头预训练 Chinese-CLIP 的正统方式是什么”，答案不是随便拼个对比学习训练脚本，而是按论文里的两阶段路线来。

但也要现实一点：这条路通常不是普通团队的默认选项。因为它意味着你不仅要有大规模中文图文数据，还要有足够稳定的训练资源和较强的数据清洗能力。

所以在今天的实际工程里，“从头预训练”更像研究路线，而不是大多数业务团队的首选。

2. 官方推荐的主路：基于预训练权重做 finetune

这才是 Chinese-CLIP 仓库真正为多数用户准备的训练入口。

官方文档对 finetune 的要求很清楚：

• 先准备好图文数据
• 图片侧建议转为 base64 + tsv
• 文本侧用 jsonl
• 再转成 LMDB
• 最后跑官方 run_scripts/*.sh

这套设计很“工程派”，不是为了好看，而是为了训练时随机读取效率和大规模数据可控性。

如果你要做的是：

• 自己行业里的图文检索
• 电商图搜图
• 中文图文对齐
• 垂直领域 zero-shot 能力补强

那这条基于预训练权重继续 finetune 的路，就是 Chinese-CLIP 的默认正解。

3. 显存和吞吐优化：官方已经给了 4 个增强开关

很多人对 Chinese-CLIP 训练的印象还停在“官方脚本太重”。其实从后来的仓库演进看，作者已经逐步把一些非常实用的训练增强加进去了。

grad-checkpointing

这是显存换算力的老办法。它不保留前向激活，在反向阶段重算一部分内容，适合显存先不够、训练还想继续跑的情况。

mask-ratio 对应的 FLIP

Chinese-CLIP 仓库后来加入了 FLIP 策略，本质上是训练时随机遮挡一部分图像 patch，用更少的显存和更快的速度换取相对可接受的训练效果。

对大图像、长训练、显存紧张场景，这个开关很实用。

--use-flash-attention

这是我很推荐认真看的一个点。因为它不是泛泛而谈，而是 Chinese-CLIP 作者专门补了说明文档和样例脚本。

你可以把它理解成：

• 更快的 attention 计算
• 更低的显存占用
• 对较大规模视觉 backbone 的收益更明显

如果你训的是 ViT-L/14、ViT-H/14 这种更大的模型，这个收益通常会比小模型明显。

accum-freq 梯度累积

这个能力后加进来很关键。官方自己在 README 里也明确提醒过：对比学习的收敛和稳定性，对总 batch size 非常敏感。

这意味着：

• 你卡少，显存不够
• 单卡 batch 上不去
• 但你又不想训练质量明显掉下去

这时梯度累积是非常现实的补救手段。它不是让你“变成真正的大集群”，但能更像大 batch 地去模拟训练效果。

4. 知识蒸馏微调

Chinese-CLIP 仓库在 2023 年又补了一条非常有工程价值的路：基于 ModelScope teacher 的蒸馏式 finetune。

这条路线的核心目标很实际：

• 让较小的 Chinese-CLIP 模型保留更快推理速度
• 同时尽量向更大 teacher 模型学习

它不是泛化意义上的“所有侧都蒸馏”，而是更偏向图像侧检索能力提升。官方文档里给了可用的 teacher 模型名，也给了配置项：

• --distillation
• --teacher-model-name
• --kd_loss_weight

如果你的目标是：

• 不想直接上大模型长期在线推理
• 但又不想让小模型召回效果太差

那么蒸馏会比“盲目继续加训练轮数”更像正经工程手段。

第三层：Chinese-CLIP 的量化和压缩到底有哪些路

这里最需要讲清楚一句话：

Chinese-CLIP 官方原生最明确支持的是格式转换和推理加速，不是把所有低比特量化路径都内建好了。

所以我把这部分分成“官方直连”和“通用工具链套用”两类。

1. 官方直连：PyTorch -> ONNX -> TensorRT

这是 Chinese-CLIP 仓库自己写了转换脚本和说明文档的路线。

官方文档强调的是：

• 从 PyTorch checkpoint 导到 ONNX
• 再从 ONNX 转到 TensorRT
• 主要目标是提升特征推理速度

注意，这里文档描述的主线仍然是 FP16 推理加速，不是“开箱即用的 INT8 量化全流程”。

所以如果你今天的目标是：

• NVIDIA GPU 在线服务
• 重点是图文 embedding 或相似度推理吞吐
• 不想自己重写模型图

那么这条官方 TensorRT 路线应该是第一优先级。

2. ONNX Runtime 量化：动态量化、静态量化、QDQ / QOperator

如果你已经能把 Chinese-CLIP 导成 ONNX，那么下一层就是 ONNX Runtime 的量化工具链。

根据 ONNX Runtime 官方文档，这条路大体包括：

• 预处理
• 动态量化
• 静态量化
• 调试量化前后激活与权重差异

这里比较重要的判断是：

• 动态量化：更省事，不一定要校准集
• 静态量化：通常更偏生产化，但需要校准数据
• QDQ / QOperator：是两种不同的量化图表示方式

对 Chinese-CLIP 这种双塔模型来说，这条路很适合：

• 你已经有 ONNX 导出
• 你想在 CPU 或通用推理后端上做 INT8
• 你愿意准备少量校准样本来换更稳的效果

它的优势是框架成熟、调试工具比较完整；它的代价是你要自己对图像塔和文本塔的数值变化负责，尤其要看相似度排序是否出现明显漂移。

3. OpenVINO + NNCF：PTQ、Accuracy Control、QAT

如果你更在意 CPU 推理、Intel 平台或 OpenVINO 生态，那么 NNCF 这条线值得看。

OpenVINO 官方把量化方法拆得很清楚：

• Basic PTQ 只要代表性校准集，先做最简单的 8-bit 后训练量化
• Accuracy Control PTQ 在量化同时控制精度下降
• QAT 如果 PTQ 掉点不可接受，再走训练时量化感知训练

更妙的是，OpenVINO 官方还专门做过 CLIP 模型的 PTQ notebook。虽然它举的是 OpenAI CLIP，不是 Chinese-CLIP，但模型形态同样是视觉塔 + 文本塔 + 对比相似度头，所以这条路对 Chinese-CLIP 很有参考价值。

如果你今天要的是：

• 更偏 CPU / OpenVINO 部署
• 你能准备校准集
• 你对吞吐和模型体积都比较敏感

那这条路通常会比“生硬套 4-bit GPU 量化”更稳。

4. PyTorch 原生量化：动态量化、静态 PTQ、QAT

PyTorch 官方量化文档本身给的是通用能力，不是 Chinese-CLIP 专项文档。但 Chinese-CLIP 如果你走的是 Hugging Face 或自定义 PyTorch 模块实现，这条路理论上可以接。

可以把它理解成三档：

• Dynamic Quantization 更适合先快速试文本塔或线性层的压缩收益
• Static PTQ 需要校准流程，适合更正式的推理模型
• QAT 量化感知训练，训练成本更高，但通常能换更稳的精度

这条路适合“你自己愿意改模型代码”的团队，不适合“我只想直接套现成命令”的团队。

5. Hugging Face 低比特路线：bitsandbytes、torchao

这一类我要特别谨慎地讲。

Hugging Face 官方量化文档现在已经覆盖了很多方法，其中对工程最友好的两条是：

• bitsandbytes
• torchao

但它们的主要叙事场景长期更偏大语言模型，而不是 Chinese-CLIP 这种双塔对比学习模型。所以我会把它们归为：

“可尝试接入的通用低比特加载与训练工具，而不是 Chinese-CLIP 官方已经背书的默认路径。”

bitsandbytes

适合：

• 你在 Hugging Face 体系里加载 Chinese-CLIP
• 你主要想省 GPU 显存
• 你接受 8-bit / 4-bit 更像工程实验，而不是作者标准结果复现

torchao

适合：

• 你更偏 PyTorch 原生
• 想尝试 int8 / int4 / fp8 这些更灵活的量化方案
• 接受它更像“框架能力”，而不是 Chinese-CLIP 现成 recipe

如果你只是想把 Chinese-CLIP 更稳定地上线，我不会建议一上来就冲这两条。它们更像你已经有 Hugging Face 路线、并且愿意做额外验证时的扩展方案。

真正能落地的选择建议

如果你让我把这些方法压成最实用的选择表，我会这样选：

场景 1：我要最快把 Chinese-CLIP 用起来

优先级：

1. cn_clip 官方 API
2. Hugging Face ChineseCLIPModel

如果你偏研究复现，先走前者。
如果你偏工程系统集成，先走后者。

场景 2：我要继续训练自己的领域模型

优先级：

1. 官方 finetune 脚本
2. 梯度累积
3. grad-checkpointing
4. FLIP
5. FlashAttention
6. 知识蒸馏

这条线本质上是：先用官方训练范式站稳，再一点点把训练资源效率拉上去。

场景 3：我要做 GPU 推理加速

优先级：

1. 官方 ONNX / TensorRT
2. 再看是否需要额外低比特实验

原因很简单：这是 Chinese-CLIP 作者自己给出的最明确部署链路。

场景 4：我要做 CPU 或通用推理后端压缩

优先级：

1. ONNX Runtime INT8
2. OpenVINO NNCF PTQ
3. 如果 PTQ 掉点明显，再考虑 QAT

场景 5：我要在 Hugging Face 体系里继续折腾省显存

优先级：

1. bitsandbytes
2. torchao

但一定要记住：这条线不是 Chinese-CLIP 官方仓库的标准主路，验证成本要自己承担。

我最后的判断

如果只看工程价值，而不是“方法名听起来酷不酷”，Chinese-CLIP 目前最值得记住的不是某一个神奇压缩算法，而是下面这三句话：

1. 使用层面最稳的是官方 API 和 Hugging Face 两条线。
2. 训练层面真正有价值的是官方 finetune + FlashAttention + FLIP + 梯度累积 + 蒸馏这一整套组合。
3. 量化层面最现实的是 ONNX Runtime 和 OpenVINO NNCF，低比特 Hugging Face 方案要把它看成“可试验扩展”，不要误当成 Chinese-CLIP 官方标准答案。

也就是说，如果你今天要给 Chinese-CLIP 做路线图，最稳的顺序不是“先上 4-bit”，而是：

1. 先把推理和评测链路跑通
2. 再把 finetune 跑通
3. 再做 PTQ
4. 如果精度和速度都还不满意，再往 QAT、蒸馏、低比特压缩继续深入

这比一开始就把所有压缩词汇都往项目里塞进去，成功率高得多。

参考资料

• Chinese-CLIP 官方仓库
• Chinese-CLIP 论文（arXiv）
• Chinese-CLIP Hugging Face 文档
• Chinese-CLIP ONNX / TensorRT 部署说明
• Chinese-CLIP FlashAttention 训练加速说明
• Chinese-CLIP 蒸馏微调说明
• ONNX Runtime 量化文档
• OpenVINO NNCF 模型优化总览
• OpenVINO CLIP 量化示例
• PyTorch 量化文档
• Hugging Face Quantization Overview
• Hugging Face bitsandbytes 文档
• Hugging Face torchao 文档