Model Genome 这个方向一句话概括就是通过给大语言模型做“指纹识别”判断某个 LLM 是从零训练出来的原始模型还是从已有模型继续训练、微调、合并或蒸馏出来的派生模型。这个能力在模型资产管理、许可证合规、供应链安全和大模型安全审计里非常关键。适合谁看正在管理多个开源模型的企业开发者、做模型选型和模型审计的算法工程师、以及需要发布模型或使用第三方模型的团队。最值得关注的一点是它不只对比模型名称和参数结构而是从权重分布、层激活、输出行为这些“基因级”特征去判断模型血缘。实际工作里很多团队会同时维护十几个开源模型时间一长根本分不清哪个模型基于哪个底座。有的模型下载页写了 base model很多却没写。还有的模型改个名就当作新模型发布上游许可证是否兼容也无从查起。Model Genome 这类指纹识别方法就是为了解决这种“模型血缘不明”的问题。下面我按照从思路到落地的顺序拆开讲。1. 为什么需要判断 LLM 是原始训练还是派生模型1.1 模型资产管理不能只靠 README 里的描述开源社区的大模型越来越多。同一个名字下面可能有继续预训练版本、指令微调版本、LoRA 合并版本、多模型融合版本。只看模型卡上的描述经常判断不出来它到底是独立训练的还是派生的。更常见的情况是一个模型在 Hugging Face 上发布后又被别人拿去加了一层 adapter重新命名再发布。如果没有指纹分析只用目录结构和参数名去比对很容易漏掉真实的派生关系。做企业级模型资产盘点时这种血缘关系尤其重要。一个团队可能需要回答我们手里的 A 模型和外部公开的 B 模型到底有没有同源关系如果 B 模型后来又更新了我们是否需要同步升级底座这些问题靠人肉翻阅文档很难回答可靠的做法是对模型本身做特征提取和比对。1.2 许可证合规需要“证据”而不只是声明很多开源模型使用的是带有继承性要求的许可证比如要求派生模型继续开源、保留版权声明、或者禁止商用。如果某个模型是基于另一个模型微调出来的那它本质上就是“派生作品”。但现实是很多发布者不会主动标注“本模型基于某底座模型修改”。这时候如果你想使用这个模型就需要自己判断它是否派生自某个许可证更严格的原始模型。Model Genome 的指纹结果可以作为一种辅助证据。虽然不是法律结论但它能把“模型 A 与模型 B 的某些层激活分布高度一致”这类技术事实呈现出来帮助合规同事做初步风险判断。至少能提示你这个模型不是完全独立训练的可能继承了上游模型的信息。1.3 安全审计时模型来源是一个不可忽略的检查项安全团队在评估一个外部模型能不能接入内部系统时会考虑模型是否可能藏有后门、是否被恶意植入异常行为。指纹分析不能直接发现后门但它能帮助回答一个前置问题这个模型到底从哪来的如果它和你已经审计过的某个模型惊人地相似那后续评估可以复用很多已知信息。反过来如果它声称是基于某个开源底座训练的但指纹比对结果却和底座差异很大那就要警惕它是否被做了额外改动。还有一个常见场景是模型发布平台的自动审核。发布者上传模型后平台希望识别“这个模型是不是从平台上已有的模型复制或改造来的”避免违规搬运。这种自动审核本质上就需要模型指纹。2. Model Genome 的核心思路从权重到“基因指纹”2.1 为什么参数名和网络结构不能作为判断依据最简单的思路是对比两个模型的参数名和网络结构。如果层名都一样就以为同源。但这个思路很容易被击穿。模型导出、重新打包、转换框架后参数名可能被修改加上一层 adapter、重命名部分层、或者做一次参数重排列结构上就看不出明显关系了。更关键的是两个完全独立从头训练的模型如果采用相同的开源代码框架结构可能几乎一样但参数值完全不同。所以 Model Genome 的做法不是看模型“长什么样”而是看模型内部计算产生的“信号”。这些信号包括激活值分布、注意力模式、最终输出概率分布等。它们就像 DNA 片段一样能反映模型训练过程中留下的痕迹。2.2 哪些信号可以作为“基因标记”实际做模型指纹比对时我一般会关注下面几类信号各层 hidden state 的均值和方差分布。不同模型在相同输入下中间层特征的统计量往往有明显差异。相邻层之间的特征变化量。从头训练的模型和微调得到的模型层与层之间的信息流动模式不一样。特定层输出的 token 概率分布。同一个输入 prompt两个模型如果血缘关系近预测概率分布会很接近。梯度或 Hessian 特征。虽然计算成本高但对判断继续训练和微调比较敏感。注意力矩阵的统计特征。主要是头与头之间的重叠程度、注意力熵等。最直接、最容易落地的是中间层 hidden state 的对比。因为从零训练和微调得到的模型虽然最终任务表现可能相似但特征空间的内在结构不同。这也是为什么很多论文会使用 CKA、余弦相似度这类指标来做表征相似性分析。2.3 派生方式不同指纹保留程度也不同并非所有“派生”都会让模型保留完整指纹。模型微调、LoRA 合并、向量融合、模型蒸馏、量化和剪枝对原始模型特征的改变程度差别很大。如果你的目标是从已知底座判断某个新模型是否派生需要注意一个事实微调程度越轻、参数改动越少指纹越容易检测蒸馏或重度量化后指纹会明显退化但仍然可能留下部分痕迹。比如 LoRA 合并后的模型大部分权重来自底座指纹应该很清晰。如果是知识蒸馏学生模型学的是教师模型的输出行为而不是直接复制权重这时参数层面的对比可能不明显但输出概率分布仍然可能高度相关性。所以 Model Genome 不能只依赖一种特征最好把权重分布、激活分布、输出分布三方面都纳入。3. 实操流程怎么给两个模型做指纹对比3.1 环境准备和输入约定这一节给出通用流程具体的模型路径和参数按你自己的环境调整。比较两个模型不需要特别高的门槛。如果没有大型 GPU可以先用百亿参数以下的模型在 CPU 上跑。重点是提取中间层输出不是做完整推理所以占用通常可控。但如果你要分析几百亿参数的模型或者一次对比几十个模型那还是建议准备一张至少 16GB 显存的 GPU否则排队时间会比较久。依赖方面主要需要Python 3.9 以上PyTorchTransformersNumPyscikit-learn用来算相似度矩阵或 CKA安装示例pip install torch transformers numpy scikit-learn输入数据准备。你需要准备一组评测文本一般 50 到 200 条就可以。文本要尽量覆盖不同类型的任务比如问答、摘要、代码、结构化数据生成。不要只用一条 prompt那样指纹会非常不稳定。所有模型必须使用完全相同的文本并且按相同的顺序输入。3.2 第一步抽取模型结构和元数据加载两个模型之前先把模型的配置信息记录下来模型参数量层数隐藏层维度词表大小是否使用 tie word embeddings是否带 LoRA 或 adapter 层这些元数据可以帮助你判断哪些层可以对齐。如果两个模型的层数和维度完全不一样那层到层的直接对比就没有意义需要退回到只看输出概率分布或 token 级相似度。代码里可以这样取元数据from transformers import AutoConfig config AutoConfig.from_pretrained(your-model-path) print(config.num_hidden_layers) print(config.hidden_size) print(config.vocab_size)3.3 第二步用同一批输入跑前向采集激活这是最核心的一步。关键是让两个模型接收完全相同的输入 token并从同样的层位置取出 hidden state。示例脚本的思路如下import torch from transformers import AutoTokenizer, AutoModel def collect_hidden_states(model_path, model_type, sample_texts, layer_indices): tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModel.from_pretrained(model_path, output_hidden_statesTrue) model.eval() collected {idx: [] for idx in layer_indices} with torch.no_grad(): for text in sample_texts: inputs tokenizer(text, return_tensorspt, truncationTrue, max_length512) outputs model(**inputs) hidden_states outputs.hidden_states # tuple of layer outputs for idx in layer_indices: # 取出第 idx 层并做 mean pooling h hidden_states[idx].mean(dim1).squeeze(0) collected[idx].append(h.cpu().numpy()) return collected这个脚本不是完整工具只展示采集思路。实际使用时你可能要考虑 padding mask避免把 [PAD] token 也平均进去。正确做法是对非 pad 位置做均值池化。如果两个模型使用不同的 tokenizer就需要先统一文本到同一套 tokenizer或者对两个模型分别 tokenize 后做对齐。最简单的方案是选择一个公共 tokenizer比如原始模型的 tokenizer但这样另一个模型可能产生很多 unknown token影响结果。3.4 第三步计算相似度并生成报告拿到激活值之后就可以计算两个模型在同一层上的相似度。常用指标有余弦相似度CKACentered Kernel AlignmentKL 散度L2 距离Spearman 相关系数示例代码以余弦相似度为例import numpy as np from sklearn.metrics.pairwise import cosine_similarity def layer_similarity(features_a, features_b): # features_a, features_b: list of numpy arrays a np.stack(features_a) b np.stack(features_b) sims [] for i in range(a.shape[0]): sims.append(cosine_similarity(a[i:i1], b[i:i1])[0][0]) return np.mean(sims), np.std(sims)把每一层的相似度都算出来最终你会得到一张表层索引余弦相似度均值标准差00.99820.0008100.99450.0012200.98710.0030如果两个模型是从同一个底座派生出来的通常浅层和中间层的相似度会非常高深层因为微调任务不同会低一些。如果是从零训练的模型即使结构完全相同各层相似度也会很低。3.5 每次都做阳性对照和阴性对照只看两个模型的相似度数字很难判断“高”到底是多高。所以我建议每轮对比都加两组对照阳性对照同一个模型加载两份或者同一个模型在不同随机 seed 下各训练很短的一段然后对比得到“同源模型相似度应该有多高”的参考。阴性对照拿两个完全无关的模型比如 Llama 系和 Qwen 系做同样的对比得到“异源模型相似度大概多低”。有了这两个基线再看目标模型的相似度落在哪个区间判断会可靠很多。需要注意阴性对照的模型如果共享了训练数据或 tokenizer相似度也不会太低实际要先跑一轮再看。4. 关键指标和判断标准别只盯一个相似度4.1 常用指标分别适合什么场景不同指标对“派生”的敏感程度不一样。下面这个表是根据我自己的测试经验整理的不代表所有模型都完全符合但可以作为初始参考指标适合场景判断方式余弦相似度同结构、同 layer 对比越接近 1越可能同源CKA不同结构、不同宽度数值越高表征越相似KL 散度输出概率分布对比越小越相似L2 距离权重或激活差异越小越相似线性探针判断特征是否包含相同信息可以在同一组特征上训练分类器再迁移测试只用一个指标很容易误判。比如两个模型在浅层特征上余弦相似度很高但深层差异很大可能是“只做了浅层适配”。反过来两个模型在输出分布上接近可能是蒸馏的结果不一定是直接复制权重。4.2 阈值不是拍脑袋定的不少模型指纹分析工具会在结果里给一个相似度分数然后告诉你“超过 0.95 就是派生”。这个做法看起来很省事但实际工程里很危险。不同模型家族、不同层数、不同 tokenizer它们的基线相似度差异很大。比如同一个模型的两个导出格式余弦相似度可能接近 1但两个独立训练且共享 tokenizer 的同架构模型相似度也可能有 0.9 以上。所以更稳妥的阈值设定方式是先建立基线库把已知的同源模型和异源模型分别算一遍画出分布图再根据分位数设阈值。这样哪怕最终你仍然选 0.95至少你知道它依据的是什么数据。4.3 多输入、多层的聚合判断单条输入、单层特征的相似度不能作为最终结论。一个模型可能在特定 prompt 下表现出与另一个模型相似换了 prompt 就完全不同。稳妥做法是至少在 50 条以上输入上取均值。至少对比 3 到 5 个代表性层。分别看浅层、中层、深层的结果。综合输出概率分布的 KL 散度做二次验证。如果所有层都高度相似并且多组输入都稳定那“派生”的判断就很可信。如果只有某几层相似就要进一步分析可能是模型共享了 embedding 或对某些任务做了定向对齐。5. 从单次对比到批量模型扫描5.1 先做模型指纹库单次对比适合排查个别模型。如果团队要维护一批模型更合理的做法是先建一个指纹库。把每个已知模型的代表层激活均值、输出分布直方图、配置信息保存成独立文件后续新模型只需要和库里的模型一一对比。指纹库至少应该包含这些字段模型内部 ID来源路径或仓库地址参数量、层数、隐藏维度提取指纹时的 tokenizer 版本采样文本版本各层激活统计量输出概率分布采样结果要注意指纹库本身不能只看相似度还要记录提取条件。如果今天用文本集合 A 提取明天用文本集合 B 提取得到的同一层激活均值会有差异对比时会引入噪声。最好的办法是固定一套评测文本所有模型都用它。5.2 批量任务设计命名、队列、重试批量扫描时最容易踩的坑是没有输出命名规范。如果自动跑几十个模型的指纹结果文件必须能反查到模型路径和提取时间。我一般会这样设计任务目录fingerprint_scan/ run_20250101/ config.yaml inputs.jsonl models/ outputs/ modelA_20250101.json modelB_20250101.json logs/批量任务不应该一上来就开最大并发。模型加载非常耗显存和内存并发过高会导致 OOM然后整个任务中断。更务实的做法是顺序加载模型或者在显存充足时只开 2 到 4 个并发。每个模型提取完立即释放显存。如果某个模型加载失败不要立刻终止全批任务把错误记录到日志中继续跑下一个模型。等全部结束后再单独处理失败项。5.3 输出报告不要只给一个结论最终报告最好同时输出原始指标和判断结论。比如{ candidate_model: modelA, base_model: modelB, cosine_similarity: { layer_0: 0.99, layer_10: 0.98, layer_20: 0.95 }, kl_divergence: 0.003, inference: likely_derived, confidence: high }给业务方看的时候务必附上为什么得出这个结论。不要只给一个“是”或“否”因为下游不管是合规还是安全都需要知道判断依据是什么、是否存在不确定性。6. 边界、踩坑和实际落地建议6.1 量化、剪枝、蒸馏会让指纹失真模型量化是实际场景中最常见的影响因素。一个 fp16 模型转成 int8 后权重分布会发生变化激活统计也会漂移。这时候拿量化后的模型去和原始模型对比余弦相似度可能从 0.99 掉到 0.85 左右。这并不代表两个模型不同源只是指纹提取环境变了。处理方法有三个方向尽量在相近精度下对比比如都是 fp16 或都是 int8。使用 logits 或最终输出概率分布做补充判断这类信号受量化影响相对小。对激活做归一化后再计算相似度减少尺度偏移带来的干扰。蒸馏模型的问题更隐蔽。学生模型学习的是教师模型的输出分布而不是直接复制权重因此权重层面的相似度可能不高。这时应该把主指标换成输出 logits 的 KL 散度和顶层表征的 CKA。如果两个模型在输出分布上高度接近但权重层面对不上通常说明“行为派生”而不是“权重派生”。6.2 多阶段派生和混合来源会提高判断难度现实中的模型不一定是“单一底座 一次微调”这么干净。它可能是 A 模型继续训练然后和 B 模型做权重合并再用 C 模型的对话数据做指令微调。这种多阶段派生会让不同层的来源变得不一致。碰到这种情况不要试图用一个总相似度盖棺定论。更好的做法是分层分析哪些层更像 A哪些层更像 B哪些层像 C然后输出一个“来源构成”的推测而不是简单判断 Y/N。当然如果所有层都来自同一个底座判断就简单很多。Model Genome 真正擅长的是揭示这种可直接观察的同源关系对复杂混合模型的判断只能作为辅助不能当成绝对真值。6.3 常见误判排查顺序如果你的比对结果明显异常比如同一个模型的两次导出竟然相似度很低按下面的顺序排查先确认输入文本是否完全一致包括文本顺序和截断长度。再确认是否用了同一个 tokenizer。如果 tokenizer 版本不一致token 不会对齐。然后确认 padding mask 是否正确pad token 参与均值池化会造成统计偏移。检查模型路径是否确实指向不同版本。很多模型仓库会自定义model_type名称相同不代表结构相同。最后检查依赖版本尤其是 Transformers 版本。不同版本对某些层输出的封装方式可能不同导致取出的 hidden state 坐标不一致。如果步骤都排查过了还是异常那就把模型下载到本地重新提取一次排除远程加载时的缓存污染。6.4 建议先做小规模验证再上生产我踩过几次坑之后最大的体会是模型指纹分析这事最忌讳一上来就做全量扫描。先选两个已知关系的模型做一次 PoC一个是从零训练的底座一个是基于它微调的模型看看你的指标和阈值能不能分开。如果连已知关系都复现不了后面结果就不可信。PoC 通过后再扩大到五个模型、十个模型再逐步建立指纹库。使用人员也要配合不能只看分数就宣布“同源”或“不同源”要理解每项指标的边界。最后说一点和部署相关的题外话很多人在讨论 LLM 框架时会把“模型溯源”和“模型部署”混在一起。比如有人问 ComfyUI 和 LLM 是不是必须在同一台电脑上这其实是一个部署架构问题和模型是否派生没有关系。Model Genome 分析只关心模型权重和行为不需要模型和某个应用跑在同一台机器上。只要你能把模型加载到本地或拿到足够的激活输出指纹分析就能继续。综合来看Model Genome 这一类指纹识别方法最核心的价值不是给你一个百分百确定的“父子关系结论”而是把模型之间的相似程度量化出来。它适合用于模型资产盘点、许可证合规辅助、安全审计和开源社区溯源。落地时记得控制好输入文本、依赖版本、指标阈值和批量任务设计真正跑通之后你就能用同一套流程持续监控新增模型而不是每次手工翻模型卡。 大语言模型指纹识别：辨别原始模型与派生模型
Model Genome 这个方向一句话概括就是通过给大语言模型做“指纹识别”判断某个 LLM 是从零训练出来的原始模型还是从已有模型继续训练、微调、合并或蒸馏出来的派生模型。这个能力在模型资产管理、许可证合规、供应链安全和大模型安全审计里非常关键。适合谁看正在管理多个开源模型的企业开发者、做模型选型和模型审计的算法工程师、以及需要发布模型或使用第三方模型的团队。最值得关注的一点是它不只对比模型名称和参数结构而是从权重分布、层激活、输出行为这些“基因级”特征去判断模型血缘。实际工作里很多团队会同时维护十几个开源模型时间一长根本分不清哪个模型基于哪个底座。有的模型下载页写了 base model很多却没写。还有的模型改个名就当作新模型发布上游许可证是否兼容也无从查起。Model Genome 这类指纹识别方法就是为了解决这种“模型血缘不明”的问题。下面我按照从思路到落地的顺序拆开讲。1. 为什么需要判断 LLM 是原始训练还是派生模型1.1 模型资产管理不能只靠 README 里的描述开源社区的大模型越来越多。同一个名字下面可能有继续预训练版本、指令微调版本、LoRA 合并版本、多模型融合版本。只看模型卡上的描述经常判断不出来它到底是独立训练的还是派生的。更常见的情况是一个模型在 Hugging Face 上发布后又被别人拿去加了一层 adapter重新命名再发布。如果没有指纹分析只用目录结构和参数名去比对很容易漏掉真实的派生关系。做企业级模型资产盘点时这种血缘关系尤其重要。一个团队可能需要回答我们手里的 A 模型和外部公开的 B 模型到底有没有同源关系如果 B 模型后来又更新了我们是否需要同步升级底座这些问题靠人肉翻阅文档很难回答可靠的做法是对模型本身做特征提取和比对。1.2 许可证合规需要“证据”而不只是声明很多开源模型使用的是带有继承性要求的许可证比如要求派生模型继续开源、保留版权声明、或者禁止商用。如果某个模型是基于另一个模型微调出来的那它本质上就是“派生作品”。但现实是很多发布者不会主动标注“本模型基于某底座模型修改”。这时候如果你想使用这个模型就需要自己判断它是否派生自某个许可证更严格的原始模型。Model Genome 的指纹结果可以作为一种辅助证据。虽然不是法律结论但它能把“模型 A 与模型 B 的某些层激活分布高度一致”这类技术事实呈现出来帮助合规同事做初步风险判断。至少能提示你这个模型不是完全独立训练的可能继承了上游模型的信息。1.3 安全审计时模型来源是一个不可忽略的检查项安全团队在评估一个外部模型能不能接入内部系统时会考虑模型是否可能藏有后门、是否被恶意植入异常行为。指纹分析不能直接发现后门但它能帮助回答一个前置问题这个模型到底从哪来的如果它和你已经审计过的某个模型惊人地相似那后续评估可以复用很多已知信息。反过来如果它声称是基于某个开源底座训练的但指纹比对结果却和底座差异很大那就要警惕它是否被做了额外改动。还有一个常见场景是模型发布平台的自动审核。发布者上传模型后平台希望识别“这个模型是不是从平台上已有的模型复制或改造来的”避免违规搬运。这种自动审核本质上就需要模型指纹。2. Model Genome 的核心思路从权重到“基因指纹”2.1 为什么参数名和网络结构不能作为判断依据最简单的思路是对比两个模型的参数名和网络结构。如果层名都一样就以为同源。但这个思路很容易被击穿。模型导出、重新打包、转换框架后参数名可能被修改加上一层 adapter、重命名部分层、或者做一次参数重排列结构上就看不出明显关系了。更关键的是两个完全独立从头训练的模型如果采用相同的开源代码框架结构可能几乎一样但参数值完全不同。所以 Model Genome 的做法不是看模型“长什么样”而是看模型内部计算产生的“信号”。这些信号包括激活值分布、注意力模式、最终输出概率分布等。它们就像 DNA 片段一样能反映模型训练过程中留下的痕迹。2.2 哪些信号可以作为“基因标记”实际做模型指纹比对时我一般会关注下面几类信号各层 hidden state 的均值和方差分布。不同模型在相同输入下中间层特征的统计量往往有明显差异。相邻层之间的特征变化量。从头训练的模型和微调得到的模型层与层之间的信息流动模式不一样。特定层输出的 token 概率分布。同一个输入 prompt两个模型如果血缘关系近预测概率分布会很接近。梯度或 Hessian 特征。虽然计算成本高但对判断继续训练和微调比较敏感。注意力矩阵的统计特征。主要是头与头之间的重叠程度、注意力熵等。最直接、最容易落地的是中间层 hidden state 的对比。因为从零训练和微调得到的模型虽然最终任务表现可能相似但特征空间的内在结构不同。这也是为什么很多论文会使用 CKA、余弦相似度这类指标来做表征相似性分析。2.3 派生方式不同指纹保留程度也不同并非所有“派生”都会让模型保留完整指纹。模型微调、LoRA 合并、向量融合、模型蒸馏、量化和剪枝对原始模型特征的改变程度差别很大。如果你的目标是从已知底座判断某个新模型是否派生需要注意一个事实微调程度越轻、参数改动越少指纹越容易检测蒸馏或重度量化后指纹会明显退化但仍然可能留下部分痕迹。比如 LoRA 合并后的模型大部分权重来自底座指纹应该很清晰。如果是知识蒸馏学生模型学的是教师模型的输出行为而不是直接复制权重这时参数层面的对比可能不明显但输出概率分布仍然可能高度相关性。所以 Model Genome 不能只依赖一种特征最好把权重分布、激活分布、输出分布三方面都纳入。3. 实操流程怎么给两个模型做指纹对比3.1 环境准备和输入约定这一节给出通用流程具体的模型路径和参数按你自己的环境调整。比较两个模型不需要特别高的门槛。如果没有大型 GPU可以先用百亿参数以下的模型在 CPU 上跑。重点是提取中间层输出不是做完整推理所以占用通常可控。但如果你要分析几百亿参数的模型或者一次对比几十个模型那还是建议准备一张至少 16GB 显存的 GPU否则排队时间会比较久。依赖方面主要需要Python 3.9 以上PyTorchTransformersNumPyscikit-learn用来算相似度矩阵或 CKA安装示例pip install torch transformers numpy scikit-learn输入数据准备。你需要准备一组评测文本一般 50 到 200 条就可以。文本要尽量覆盖不同类型的任务比如问答、摘要、代码、结构化数据生成。不要只用一条 prompt那样指纹会非常不稳定。所有模型必须使用完全相同的文本并且按相同的顺序输入。3.2 第一步抽取模型结构和元数据加载两个模型之前先把模型的配置信息记录下来模型参数量层数隐藏层维度词表大小是否使用 tie word embeddings是否带 LoRA 或 adapter 层这些元数据可以帮助你判断哪些层可以对齐。如果两个模型的层数和维度完全不一样那层到层的直接对比就没有意义需要退回到只看输出概率分布或 token 级相似度。代码里可以这样取元数据from transformers import AutoConfig config AutoConfig.from_pretrained(your-model-path) print(config.num_hidden_layers) print(config.hidden_size) print(config.vocab_size)3.3 第二步用同一批输入跑前向采集激活这是最核心的一步。关键是让两个模型接收完全相同的输入 token并从同样的层位置取出 hidden state。示例脚本的思路如下import torch from transformers import AutoTokenizer, AutoModel def collect_hidden_states(model_path, model_type, sample_texts, layer_indices): tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModel.from_pretrained(model_path, output_hidden_statesTrue) model.eval() collected {idx: [] for idx in layer_indices} with torch.no_grad(): for text in sample_texts: inputs tokenizer(text, return_tensorspt, truncationTrue, max_length512) outputs model(**inputs) hidden_states outputs.hidden_states # tuple of layer outputs for idx in layer_indices: # 取出第 idx 层并做 mean pooling h hidden_states[idx].mean(dim1).squeeze(0) collected[idx].append(h.cpu().numpy()) return collected这个脚本不是完整工具只展示采集思路。实际使用时你可能要考虑 padding mask避免把 [PAD] token 也平均进去。正确做法是对非 pad 位置做均值池化。如果两个模型使用不同的 tokenizer就需要先统一文本到同一套 tokenizer或者对两个模型分别 tokenize 后做对齐。最简单的方案是选择一个公共 tokenizer比如原始模型的 tokenizer但这样另一个模型可能产生很多 unknown token影响结果。3.4 第三步计算相似度并生成报告拿到激活值之后就可以计算两个模型在同一层上的相似度。常用指标有余弦相似度CKACentered Kernel AlignmentKL 散度L2 距离Spearman 相关系数示例代码以余弦相似度为例import numpy as np from sklearn.metrics.pairwise import cosine_similarity def layer_similarity(features_a, features_b): # features_a, features_b: list of numpy arrays a np.stack(features_a) b np.stack(features_b) sims [] for i in range(a.shape[0]): sims.append(cosine_similarity(a[i:i1], b[i:i1])[0][0]) return np.mean(sims), np.std(sims)把每一层的相似度都算出来最终你会得到一张表层索引余弦相似度均值标准差00.99820.0008100.99450.0012200.98710.0030如果两个模型是从同一个底座派生出来的通常浅层和中间层的相似度会非常高深层因为微调任务不同会低一些。如果是从零训练的模型即使结构完全相同各层相似度也会很低。3.5 每次都做阳性对照和阴性对照只看两个模型的相似度数字很难判断“高”到底是多高。所以我建议每轮对比都加两组对照阳性对照同一个模型加载两份或者同一个模型在不同随机 seed 下各训练很短的一段然后对比得到“同源模型相似度应该有多高”的参考。阴性对照拿两个完全无关的模型比如 Llama 系和 Qwen 系做同样的对比得到“异源模型相似度大概多低”。有了这两个基线再看目标模型的相似度落在哪个区间判断会可靠很多。需要注意阴性对照的模型如果共享了训练数据或 tokenizer相似度也不会太低实际要先跑一轮再看。4. 关键指标和判断标准别只盯一个相似度4.1 常用指标分别适合什么场景不同指标对“派生”的敏感程度不一样。下面这个表是根据我自己的测试经验整理的不代表所有模型都完全符合但可以作为初始参考指标适合场景判断方式余弦相似度同结构、同 layer 对比越接近 1越可能同源CKA不同结构、不同宽度数值越高表征越相似KL 散度输出概率分布对比越小越相似L2 距离权重或激活差异越小越相似线性探针判断特征是否包含相同信息可以在同一组特征上训练分类器再迁移测试只用一个指标很容易误判。比如两个模型在浅层特征上余弦相似度很高但深层差异很大可能是“只做了浅层适配”。反过来两个模型在输出分布上接近可能是蒸馏的结果不一定是直接复制权重。4.2 阈值不是拍脑袋定的不少模型指纹分析工具会在结果里给一个相似度分数然后告诉你“超过 0.95 就是派生”。这个做法看起来很省事但实际工程里很危险。不同模型家族、不同层数、不同 tokenizer它们的基线相似度差异很大。比如同一个模型的两个导出格式余弦相似度可能接近 1但两个独立训练且共享 tokenizer 的同架构模型相似度也可能有 0.9 以上。所以更稳妥的阈值设定方式是先建立基线库把已知的同源模型和异源模型分别算一遍画出分布图再根据分位数设阈值。这样哪怕最终你仍然选 0.95至少你知道它依据的是什么数据。4.3 多输入、多层的聚合判断单条输入、单层特征的相似度不能作为最终结论。一个模型可能在特定 prompt 下表现出与另一个模型相似换了 prompt 就完全不同。稳妥做法是至少在 50 条以上输入上取均值。至少对比 3 到 5 个代表性层。分别看浅层、中层、深层的结果。综合输出概率分布的 KL 散度做二次验证。如果所有层都高度相似并且多组输入都稳定那“派生”的判断就很可信。如果只有某几层相似就要进一步分析可能是模型共享了 embedding 或对某些任务做了定向对齐。5. 从单次对比到批量模型扫描5.1 先做模型指纹库单次对比适合排查个别模型。如果团队要维护一批模型更合理的做法是先建一个指纹库。把每个已知模型的代表层激活均值、输出分布直方图、配置信息保存成独立文件后续新模型只需要和库里的模型一一对比。指纹库至少应该包含这些字段模型内部 ID来源路径或仓库地址参数量、层数、隐藏维度提取指纹时的 tokenizer 版本采样文本版本各层激活统计量输出概率分布采样结果要注意指纹库本身不能只看相似度还要记录提取条件。如果今天用文本集合 A 提取明天用文本集合 B 提取得到的同一层激活均值会有差异对比时会引入噪声。最好的办法是固定一套评测文本所有模型都用它。5.2 批量任务设计命名、队列、重试批量扫描时最容易踩的坑是没有输出命名规范。如果自动跑几十个模型的指纹结果文件必须能反查到模型路径和提取时间。我一般会这样设计任务目录fingerprint_scan/ run_20250101/ config.yaml inputs.jsonl models/ outputs/ modelA_20250101.json modelB_20250101.json logs/批量任务不应该一上来就开最大并发。模型加载非常耗显存和内存并发过高会导致 OOM然后整个任务中断。更务实的做法是顺序加载模型或者在显存充足时只开 2 到 4 个并发。每个模型提取完立即释放显存。如果某个模型加载失败不要立刻终止全批任务把错误记录到日志中继续跑下一个模型。等全部结束后再单独处理失败项。5.3 输出报告不要只给一个结论最终报告最好同时输出原始指标和判断结论。比如{ candidate_model: modelA, base_model: modelB, cosine_similarity: { layer_0: 0.99, layer_10: 0.98, layer_20: 0.95 }, kl_divergence: 0.003, inference: likely_derived, confidence: high }给业务方看的时候务必附上为什么得出这个结论。不要只给一个“是”或“否”因为下游不管是合规还是安全都需要知道判断依据是什么、是否存在不确定性。6. 边界、踩坑和实际落地建议6.1 量化、剪枝、蒸馏会让指纹失真模型量化是实际场景中最常见的影响因素。一个 fp16 模型转成 int8 后权重分布会发生变化激活统计也会漂移。这时候拿量化后的模型去和原始模型对比余弦相似度可能从 0.99 掉到 0.85 左右。这并不代表两个模型不同源只是指纹提取环境变了。处理方法有三个方向尽量在相近精度下对比比如都是 fp16 或都是 int8。使用 logits 或最终输出概率分布做补充判断这类信号受量化影响相对小。对激活做归一化后再计算相似度减少尺度偏移带来的干扰。蒸馏模型的问题更隐蔽。学生模型学习的是教师模型的输出分布而不是直接复制权重因此权重层面的相似度可能不高。这时应该把主指标换成输出 logits 的 KL 散度和顶层表征的 CKA。如果两个模型在输出分布上高度接近但权重层面对不上通常说明“行为派生”而不是“权重派生”。6.2 多阶段派生和混合来源会提高判断难度现实中的模型不一定是“单一底座 一次微调”这么干净。它可能是 A 模型继续训练然后和 B 模型做权重合并再用 C 模型的对话数据做指令微调。这种多阶段派生会让不同层的来源变得不一致。碰到这种情况不要试图用一个总相似度盖棺定论。更好的做法是分层分析哪些层更像 A哪些层更像 B哪些层像 C然后输出一个“来源构成”的推测而不是简单判断 Y/N。当然如果所有层都来自同一个底座判断就简单很多。Model Genome 真正擅长的是揭示这种可直接观察的同源关系对复杂混合模型的判断只能作为辅助不能当成绝对真值。6.3 常见误判排查顺序如果你的比对结果明显异常比如同一个模型的两次导出竟然相似度很低按下面的顺序排查先确认输入文本是否完全一致包括文本顺序和截断长度。再确认是否用了同一个 tokenizer。如果 tokenizer 版本不一致token 不会对齐。然后确认 padding mask 是否正确pad token 参与均值池化会造成统计偏移。检查模型路径是否确实指向不同版本。很多模型仓库会自定义model_type名称相同不代表结构相同。最后检查依赖版本尤其是 Transformers 版本。不同版本对某些层输出的封装方式可能不同导致取出的 hidden state 坐标不一致。如果步骤都排查过了还是异常那就把模型下载到本地重新提取一次排除远程加载时的缓存污染。6.4 建议先做小规模验证再上生产我踩过几次坑之后最大的体会是模型指纹分析这事最忌讳一上来就做全量扫描。先选两个已知关系的模型做一次 PoC一个是从零训练的底座一个是基于它微调的模型看看你的指标和阈值能不能分开。如果连已知关系都复现不了后面结果就不可信。PoC 通过后再扩大到五个模型、十个模型再逐步建立指纹库。使用人员也要配合不能只看分数就宣布“同源”或“不同源”要理解每项指标的边界。最后说一点和部署相关的题外话很多人在讨论 LLM 框架时会把“模型溯源”和“模型部署”混在一起。比如有人问 ComfyUI 和 LLM 是不是必须在同一台电脑上这其实是一个部署架构问题和模型是否派生没有关系。Model Genome 分析只关心模型权重和行为不需要模型和某个应用跑在同一台机器上。只要你能把模型加载到本地或拿到足够的激活输出指纹分析就能继续。综合来看Model Genome 这一类指纹识别方法最核心的价值不是给你一个百分百确定的“父子关系结论”而是把模型之间的相似程度量化出来。它适合用于模型资产盘点、许可证合规辅助、安全审计和开源社区溯源。落地时记得控制好输入文本、依赖版本、指标阈值和批量任务设计真正跑通之后你就能用同一套流程持续监控新增模型而不是每次手工翻模型卡。