各位做 LLM 安全、模型部署和算法机制研究的同学，大家好。今天想和大家深入聊一个比较新的安全攻击方向： Hollow-LLM Attack（空心大模型攻击） 。这个方向的核心是利用 Ghost Weights（幽灵权重） 来欺骗基于 Zero-Knowledge（零知识） 的大模型验证机制。说实话，我第一次看到这个概念时也很困惑：权重明明就在那里，凭什么说是“空心的”？验证不是已经做了零知识证明吗，怎么还能被绕过？带着这些问题，我整理了这篇系统性的技术拆解文章。文章会从背景概念讲起，逐步拆解攻击原理、威胁模型，然后给出验证逻辑的脆弱性演示代码，最后总结防御思路和工程最佳实践。无论你是做 AI 安全的、做模型部署的，还是研究 LLM 对齐与可验证计算的，这篇文章都值得耐心读完。

1. 背景：为什么大模型需要可验证性

1.1 大模型可信问题

随着大语言模型（LLM）在搜索、编程、客服、金融、医疗等场景中大规模落地，模型本身的完整性、真实性和可信度变得至关重要。过去我们关注的是模型“输出质量”，比如回答准不准、有没有幻觉。但今天，一个更底层的安全问题浮出水面： 我们加载的模型，真的还是发布者声称的那个模型吗？

这个问题不是凭空出现的。模型以二进制权重文件的形式分发，可能经过 HDFS、对象存储、CDN、镜像站等多跳传递。任何一个环节被篡改，模型行为就可能被植入后门。而在实际工程中，很多团队加载模型时只检查文件大小、路径是否存在，并没有做完整的完整性校验。

1.2 模型分发中的安全风险

我们可以把模型分发过程简化成一条链路：

模型发布方 -> 模型仓库/镜像站 -> 下载节点 -> 本地加载 -> 推理服务

这条链路的每一跳都可能成为攻击面：

• 模型仓库被入侵，权重被替换。
• 传输链路被中间人劫持，权重被篡改。
• 本地缓存被污染，加载的是旧版或被修改的权重。
• 推理服务在运行时被注入内存补丁，模型行为被动态篡改。

更棘手的是，有些攻击甚至不需要修改所有权重。攻击者可以只修改某几层、某几个张量，甚至只调整特定通道的数值，让模型在绝大多数输入上表现几乎一致，但在特定触发条件下输出截然不同的内容。这种“定向微调”式攻击比整体替换更难被察觉。

1.3 零知识验证的引入

为了在不暴露模型权重的前提下证明模型的可信性，密码学界和 AI 安全社区开始引入 Zero-Knowledge Proof（零知识证明） 方案。核心思路是：模型发布方在发布权重时，同时生成一份密码学证明；验证方可以在不获取原始权重的情况下，验证这个模型确实满足某些性质，比如“权重没有被篡改”、“推理结果确实来自该权重”。

听起来很完美。但 Hollow-LLM Attack 告诉我们： 如果验证协议本身的设计存在漏洞，攻击者可以构造一个“看起来被验证通过”、实际上权重已经被动过手脚的模型 。这就是“空心”的含义——模型外壳是合法的，内部价值已经被掏空。

2. 核心概念拆解：Hollow-LLM、Ghost Weights 与零知识验证

2.1 什么是 Hollow-LLM Attack

Hollow-LLM Attack 可以翻译为“空心大模型攻击”。这里的“空心”是一个比喻：

• 外壳 ：模型的权重文件、目录结构、文件大小、元信息、哈希值等表面特征全部正常。
• 内部 ：模型的实际行为已经被篡改，比如被植入了触发后门、特定主题偏见、数据泄露通道等。

攻击的核心目标是 绕过验证机制 。如果验证机制认为“哈希一致”，那就让哈希一致；如果验证机制认为“证明有效”，那就让证明有效。攻击者的核心工作不在模型本身，而在 欺骗验证协议 。

2.2 Ghost Weights（幽灵权重）

Ghost Weights 是这个攻击的关键技术载体。什么叫“幽灵权重”？我个人的理解是： 在验证者的视角下，权重是连续的、一致的、可验证的；但在模型实际推理时，部分权重被替换成了另一组恶意权重 。

听起来自相矛盾？这正是“幽灵”的微妙之处。它暗示验证者看到的权重和推理器实际使用的权重不是同一份数据。实现这种分离的技术手段可能包括：

• 双份权重存储 ：验证时加载“干净副本”，推理时加载“恶意副本”。
• 索引重映射 ：权重张量在磁盘上是完整的“干净版本”，但推理框架的加载逻辑被劫持，按恶意索引去读取另一组参数。
• 条件权重生成 ：部分权重不是固定的静态参数，而是由触发器动态生成的辅助参数。
• 数值精度陷阱 ：在 fp16、bf16、fp32 之间转换时，利用低精度表示与高精度验证之间的不一致性，让验证通过但实际推理产生偏差。

后一种思路特别值得关注。大模型推理中精度问题（fp16、bf16、fp32）一直是工程实践中的热点。如果攻击者把恶意行为隐藏在低精度量化误差的边界处，验证方用高精度做校验，推理方用低精度做计算，就可能出现验证与推理不一致的情况。

2.3 Zero-Knowledge LLM Verification

零知识 LLM 验证，是指在不泄露模型权重具体数值的前提下，向验证者证明模型满足某些性质。传统方式比如：

1. 哈希校验 ：直接对权重文件计算 SHA-256，与发布值比对。
2. 承诺方案 ：先对权重做密码学承诺，验证时打开承诺。
3. 零知识证明电路 ：把模型的一小段计算逻辑表示成算术电路，然后生成 zk-SNARK 或 zk-STARK 证明。

零知识验证的最大优势是隐私保护。模型权重是商业资产，不可能直接公开给第三方验证者。零知识方案允许“不给你看，但证明给你看”。

但零知识方案的前提是： 被验证的计算逻辑与真实运行的计算逻辑完全一致 。如果攻击者能打破这个一致性，再强的密码学协议也会变成空壳。

3. 攻击原理分析：验证与推理的“双轨分离”

3.1 攻击者的核心目标

Hollow-LLM Attack 的思路非常清晰，攻击者要做的事情可以归纳为三步：

1. 保留验证所需的外观 ：让模型在验证者检查的维度上完全正常。
2. 植入恶意行为 ：在验证者不检查的维度上修改模型，或者修改模型的行为路径。
3. 维持正常行为表象 ：在绝大多数输入上，模型输出与原始模型无明显差异，只有在特定条件下才触发恶意逻辑。

3.2 攻击的四个切入点

要理解 Hollow-LLM Attack，我们需要关注四个可能被利用的切入点：

第一，验证的静态性与推理的动态性。

验证者通常对静态文件做校验，而推理框架在运行时可能动态加载、变换、重组权重。攻击者可以让静态文件保持“干净”，但在动态加载过程中加入恶意逻辑。例如，PyTorch 的 torch.load() 本身就支持部分键值替换、 weights_only=False 时可以执行自定义代码；如果验证流程没有覆盖加载阶段的检查，攻击者就能在加载时注入恶意行为。

第二，验证粒度过粗。

如果验证器只检查整个文件哈希，攻击者可以利用文件内偏移、填充数据、注释段等区域隐藏恶意代码或后门权重。文件级别校验通过，但模型行为已经被改变。

第三，验证框架与推理框架不一致。

零知识验证电路通常对权重做静态约束，而推理框架的算子融合、量化、并行策略可能改变权重的实际参与方式。例如，验证电路假设权重按 fp32 参与计算，推理时却按 bf16 执行，两者存在精度差异，攻击者可以利用这个差异隐藏后门。

第四，验证逻辑可以被打补丁。

很多验证流程是旁路式的，比如独立脚本、独立进程或独立 API。攻击者如果已经攻入推理服务所在的主机，可以直接修改验证器进程、替换验证库、或者 hook 验证函数的返回值。这种情况下，即使验证逻辑本身再强，也相当于“让裁判看录像，但录像带是伪造的”。

3.3 Ghost Weights 的构造思路

下面用更工程化的语言描述 Ghost Weights 的可能构造方式。以下是一个概念性示意，不是真实攻击代码，目的是帮助读者理解攻击者的思考方式。

假设原模型包含权重矩阵 (W)，攻击者希望构造一对权重 ((W_{clean}, W_{evil}))，同时满足：

• (W_{clean}) 可以通过某种完整性验证。
• 正常输入 (x) 下，模型输出几乎不受影响：(f(x; W) \approx f(x; W_{clean}))。
• 特定触发输入 (x_{trigger}) 下，模型输出变成恶意结果：(f(x_{trigger}; W) = y_{evil})。

攻击者的核心问题是如何让两个权重在验证和推理之间切换。一种可能思路是：构造一个“通用权重” (W)，其中包含一个极小的扰动项 (\Delta)，使得：

[ W = W_{orig} + \Delta ]

正常输入下，(\Delta) 对输出的影响小于可感知阈值；触发输入下，(\Delta) 的方向与梯度方向对齐，输出被放大到目标结果。

这种攻击实际上非常接近传统神经网络后门攻击（BadNets 等），但 Hollow-LLM Attack 的关键创新在于 让 (\Delta) 绕过验证机制 。如果验证器只检查 (W) 的整体统计特征（比如均值、方差、奇异值分布），攻击者可以让 (\Delta) 在这些统计维度上不可见。

4. 威胁模型与典型攻击场景

4.1 模型供应链攻击

模型供应链是 Hollow-LLM Attack 最高发的场景。攻击者可以伪装成模型提供方，上传一个“空心模型”到模型仓库。用户在下载后执行验证，发现一切正常（因为验证逻辑被绕过了），然后部署到生产环境。

这种攻击一旦成功，影响范围将是所有下载该模型的用户。尤其是在企业内部，模型通常一次下载、多方复用，安全团队更难逐个排查。

4.2 模型托管与推理平台

在当前大模型落地过程中，很多团队选择调用第三方推理 API，或者使用托管的模型服务。这类平台的验证流程通常由平台方负责，用户只能看到模型 ID 和版本号。

如果攻击者成功在推理平台上发布一个空心模型，用户拿到的推理结果可能是被定向篡改的结果。对于金融、法律、医疗类应用来说，这种攻击会造成严重后果。

4.3 联邦学习与分布式训练

在联邦学习场景中，客户端模型权重需要上传到中心服务器聚合。攻击者作为恶意客户端，可以提交一个“外观正常”但内部携带恶意行为的权重更新。中心服务器用零知识验证来检查权重更新的合法性，但如果验证协议存在漏洞，恶意更新就能混入全局模型，影响整个联邦系统的行为。

4.4 模型量化与格式转换链路

大模型部署中，经常需要将 fp32 模型转换为 fp16、bf16 甚至 int8 量化格式。每次格式转换都是一次重新编码的过程。如果攻击者在转换工具中植入恶意逻辑，就可能生成一个量化后的“空心模型”：量化后的权重表面统计符合预期，但特定层的行为已经偏差。

这里要特别提醒：很多团队使用开源仓库自带的转换脚本，对脚本本身的完整性和安全性关注不足。在实际工程中， 转换工具链本身也应该被纳入完整性验证范围 。

5. 验证逻辑脆弱性演示：从哈希到零知识

为了让读者更直观地理解问题，下面给出一个从简单哈希验证到零知识验证的演进示例，并在最后展示攻击者可能利用的薄弱点。

5.1 基础哈希验证及其局限

这是最常见的验证方式：

# 文件路径：scripts/verify_model_hash.py
import hashlib
import sys

def verify_model_hash(model_path: str, expected_hash: str) -> bool:
    """计算模型文件SHA-256并与期望值比对"""
    sha256_hash = hashlib.sha256()
    with open(model_path, "rb") as f:
        for block in iter(lambda: f.read(4096), b""):
            sha256_hash.update(block)
    actual_hash = sha256_hash.hexdigest()
    return actual_hash == expected_hash


if __name__ == "__main__":
    model_file = sys.argv[1]
    expected = sys.argv[2]
    if verify_model_hash(model_file, expected):
        print("验证通过：模型文件完整")
    else:
        print("验证失败：模型文件被篡改")

这个方案的局限很明显：它只能证明文件完整，不能证明“文件内部逻辑正确”。攻击者可以：

• 在文件末尾追加额外字节，然后再重新计算哈希并发布新的“期望哈希”。
• 修改文件中间的权重，同时让哈希匹配（理论上极难，但如果攻击者控制哈希发布渠道，就毫无意义）。

更重要的是，哈希验证是 静态验证 ，完全无法感知运行时行为的变化。

5.2 改进版：权重张量级校验

稍微进阶一点的方案是对权重张量逐个做校验：

# 文件路径：scripts/verify_tensors.py
import torch
import hashlib
import json
from pathlib import Path

def tensor_sha256(tensor: torch.Tensor) -> str:
    """对单个张量计算哈希（在CPU上执行）"""
    data = tensor.detach().cpu().numpy().tobytes()
    return hashlib.sha256(data).hexdigest()

def verify_tensors(model_path: str, manifest_path: str) -> bool:
    """
    按清单校验每个张量
    manifest格式: {"layer_name": {"hash": "...", "shape": "...", "dtype": "..."}}
    """
    model = torch.load(model_path, map_location="cpu")
    manifest = json.loads(Path(manifest_path).read_text())
    
    for name, meta in manifest.items():
        if name not in model:
            print(f"缺少张量: {name}")
            return False
        tensor = model[name]
        if list(tensor.shape) != meta["shape"]:
            print(f"形状不匹配: {name}")
            return False
        if tensor.dtype.__str__() != meta["dtype"]:
            print(f"数据类型不匹配: {name}")
            return False
        if tensor_sha256(tensor) != meta["hash"]:
            print(f"哈希不匹配: {name}")
            return False
    return True

这种方案看似更细，但仍存在问题：它只校验了 torch.load 读取结果。如果攻击者自定义了模型加载逻辑，比如在 torch.load 之后、模型前向推理之前注入修改，那么张量级校验依然会被绕过。

5.3 零知识验证的正确姿势

零知识验证的实践形态通常是一个独立的验证进程或协议，不直接暴露模型权重。为了便于理解，这里用一个简化的承诺-验证流程来说明：

# 文件路径：scripts/simplified_zk_verification.py
from hashlib import sha256
import random

class SimplifiedZKPVerifier:
    """
    简化版零知识验证演示
    使用哈希承诺模拟权重承诺
    注意：这不是真正的零知识证明协议，仅用于理解流程
    """
    
    def __init__(self, weights_hash: str, salt: str):
        self.weights_hash = weights_hash
        self.salt = salt

    def verify(self, proof: dict) -> bool:
        # 验证者拿到证明，但不接触原始权重
        reconstructed = sha256(
            (proof["claim"] + self.salt).encode()
        ).hexdigest()
        return reconstructed == self.weights_hash


# 演示流程
if __name__ == "__main__":
    # 模型发布方
    weight_hash = sha256(b"real_weights_placeholder").hexdigest()
    salt = "random_salt_12345"
    verifier = SimplifiedZKPVerifier(weight_hash, salt)

    # 验证方验证
    valid_proof = {"claim": "real_weights_placeholder"}
    print("合法证明验证结果:", verifier.verify(valid_proof))

    # 攻击者尝试伪造
    fake_proof = {"claim": "fake_weights_placeholder"}
    print("伪造证明验证结果:", verifier.verify(fake_proof))

这段代码只是用来展示“承诺-证明-验证”的基本结构，实际项目中的 zk-SNARK、zk-STARK 方案要复杂得多，涉及多项式承诺、算术电路、可信设置等概念。

但即使是最复杂的零知识协议，也逃不开一个根本前提： 验证协议所覆盖的计算过程，必须与真实推理过程完全一致 。如果存在协议外的计算路径，攻击者就可以利用它。

5.4 Hollow-LLM 攻击如何绕过零知识验证

结合上面的分析，我们可以推演 Hollow-LLM 攻击绕过零知识验证的一种可能策略：

1. 确认验证电路覆盖的范围 ：攻击者反编译验证合约或分析验证服务，确定它证明了哪一段计算（例如：只证明权重承诺有效，不证明推理过程完整）。
2. 寻找未覆盖区域 ：如果验证电路只覆盖权重承诺，攻击者可以在推理框架层加入额外逻辑，比如自定义 forward 函数、注册钩子、修改算子调度。
3. 在未覆盖区域注入恶意逻辑 ：恶意逻辑可以是简单的后门判断，也可以是通过条件权重生成的 Ghost Weights。
4. 维持验证区域的“正常”状态 ：因为验证区域只需要承诺，攻击者只需要保证承诺对应的静态数据不发生变化，验证自然通过。

换句话说， 零知识验证证明了“数据是什么”，但没有证明“计算如何发生” 。Hollow-LLM Attack 利用的正是这个空隙。

6. 代码实践：构造一个可复现的防御检测工具

理解了攻击原理之后，我们来做一件更有意义的事情：编写一个简单的防御检测工具，用于在部署前检测模型是否存在“空心”特征。

6.1 检测思路

防御检测的核心思路是 多维度一致性检查 ：

1. 权重文件哈希与发布方声明一致。
2. 权重统计特征（均值、方差、奇异值分布）与基线一致。
3. 加载后的模型行为与基线模型在标准测试集上一致。
4. 对触发输入（trigger）的敏感度不高于正常输入。

6.2 检测工具代码

以下是一个概念性检测工具，适合放在模型部署前的 CI 流程中：

# 文件路径：security/check_hollow_model.py
import torch
import hashlib
import numpy as np
from typing import Callable, Dict, List


class HollowModelChecker:
    """
    空心模型检测器
    通过对比基线模型与待检模型在多个维度的表现来发现异常
    """

    def __init__(self, baseline_model, suspect_model, test_inputs: List[torch.Tensor]):
        self.baseline = baseline_model
        self.suspect = suspect_model
        self.test_inputs = test_inputs
        self.baseline_outputs = None

    def snapshot_baseline(self):
        """保存基线模型在测试输入上的输出"""
        self.baseline.eval()
        self.baseline_outputs = []
        with torch.no_grad():
            for x in self.test_inputs:
                out = self.baseline(x)
                self.baseline_outputs.append(out.detach().cpu())

    def check_output_similarity(self, threshold: float = 0.99) -> bool:
        """检查输出相似度，确保待检模型与基线在正常输入上行为一致"""
        self.suspect.eval()
        with torch.no_grad():
            for idx, x in enumerate(self.test_inputs):
                out = self.suspect(x).detach().cpu()
                baseline_out = self.baseline_outputs[idx]
                cosine_sim = torch.nn.functional.cosine_similarity(
                    out.flatten(), baseline_out.flatten(), dim=0
                )
                if cosine_sim.item() < threshold:
                    print(f"[异常] 输入{idx}的输出相似度过低: {cosine_sim.item():.4f}")
                    return False
        return True

    def check_weight_statistics(self, top_k: int = 10) -> bool:
        """
        检查权重统计特征是否存在异常
        通过比较模型各层权重的奇异值分布来发现潜在篡改
        """
        for (base_name, base_param), (sus_name, sus_param) in zip(
            self.baseline.named_parameters(), self.suspect.named_parameters()
        ):
            if base_name != sus_name:
                print(f"[异常] 层名不一致: {base_name} vs {sus_name}")
                return False

            if base_param.ndim < 2:
                continue

            base_sv = torch.linalg.svdvals(base_param.detach().cpu())
            sus_sv = torch.linalg.svdvals(sus_param.detach().cpu())

            if len(base_sv) < top_k:
                continue

            base_sv = base_sv[:top_k]
            sus_sv = sus_sv[:top_k]

            rel_error = torch.norm(base_sv - sus_sv) / torch.norm(base_sv)
            if rel_error > 1e-3:
                print(f"[异常] 层 {base_name} 奇异值偏差较大: {rel_error:.6f}")
                return False
        return True

    def check_trigger_sensitivity(
        self, trigger_generator: Callable[[torch.Tensor], torch.Tensor], 
        sensitivity_threshold: float = 10.0
    ) -> bool:
        """
        触发敏感度检测
        对测试输入施加轻微扰动后，观察模型输出变化是否异常剧烈
        """
        self.suspect.eval()
        with torch.no_grad():
            for idx, x in enumerate(self.test_inputs):
                x_trigger = trigger_generator(x)
                out_normal = self.suspect(x).detach().cpu()
                out_trigger = self.suspect(x_trigger).detach().cpu()
                diff = torch.norm(out_normal - out_trigger)
                # 如果某个输入的敏感度异常高，说明可能存在后门触发器
                if diff > sensitivity_threshold:
                    print(f"[异常] 输入{idx}的触发敏感度过高: {diff:.4f}")
                    return False
        return True

    def run_full_check(self) -> Dict[str, bool]:
        """执行全部检测"""
        self.snapshot_baseline()
        results = {
            "output_similarity": self.check_output_similarity(),
            "weight_statistics": self.check_weight_statistics(),
        }
        return results

6.3 使用示例

# 文件路径：scripts/run_security_check.py
import torch
from security.check_hollow_model import HollowModelChecker

# 加载基线模型与待检模型（示例）
baseline = torch.load("models/baseline_model.pt")
suspect = torch.load("models/suspect_model.pt")

# 构造测试输入
test_inputs = [torch.rand(1, 768) for _ in range(20)]

# 构造检测器
checker = HollowModelChecker(baseline, suspect, test_inputs)

# 运行检测
results = checker.run_full_check()
print("\n=== 检测结果 ===")
for key, value in results.items():
    print(f"{key}: {'通过' if value else '失败'}")

这个工具只是一个起点，实际问题中还需要：

• 更大的测试集，覆盖更多业务场景。
• 对抗性触发输入集，用于发现隐藏后门。
• 深度学习解释性工具（如梯度归因、注意力可视化），用于定位可疑神经元。

6.4 检测工具的局限性

需要诚实地指出， 这类检测工具无法百分百发现空心模型 。原因很简单：攻击者拥有完全的构造自由，他们可以针对任何检测指标设计绕过方案。检测工具的作用是 提高攻击成本 ，而不是彻底消除风险。

所以，工程上必须把多个层面的防御结合起来，而不是只依赖一个检测脚本。

7. 常见问题与排查思路

下面整理几个关于 LLM 验证与空心攻击的高频问题，方便你对照排查。

问题现象	常见原因	解决思路
模型哈希校验通过，但线上推理结果异常	验证与推理加载路径不一致，存在运行时篡改	检查加载逻辑，对推理进程做运行时完整性监控
同一模型在不同环境输出不同	环境依赖不一致，算子实现差异或精度设置不同	统一容器镜像，锁定依赖版本，使用确定性算子配置（如 torch.use_deterministic_algorithms(True) ）
零知识验证通过，但模型仍表现出恶意行为	验证电路与推理计算覆盖范围不一致	审计验证协议，扩展验证到推理全链路
模型在 fp16 和 bf16 下表现差异大	精度转换的边界误差被攻击者利用	对关键层做双精度校验，在部署配置中固定精度格式
权重统计正常，但特定输入触发异常输出	可能是后门触发器导致 Ghost Weights 激活	使用触发敏感度检测、梯度归因和样本探测
验证服务返回通过，但验证过程已被劫持	验证进程本身被攻破，验证结果被伪造	分离验证与推理环境，使用 TEE（可信执行环境）保护验证逻辑

再补充一些排查步骤建议：

1. 先确认验证链路 ：从权重文件读取、哈希计算、协议验证到结果输出，每个环节都要确认没有被 hook 或替换。
2. 再确认推理链路 ：从权重加载、模型构造、前向传播到算子执行，每个环节都要确认使用的是验证过的同一份数据。
3. 然后对比行为 ：在标准测试集和潜在触发输入集上，比较待检模型与基线模型的输出差异。
4. 最后检查依赖 ：确认 PyTorch、CUDA、算子库等依赖的完整性，防止依赖包被投毒。

8. 最佳实践与工程建议

8.1 安全设计原则

在模型验证与部署实践中，我有几条经验想分享给大家：

第一，验证必须覆盖推理全链路，而不是只看静态权重文件。 静态文件校验是基础，但远远不够。至少要覆盖加载后的模型结构、关键层权重、以及首轮前向推理的输出结果。

第二，验证与推理使用独立的运行环境。 如果验证器和推理器跑在同一台机器上、同一个进程内、甚至共享同一份依赖库，攻击者一旦突破任意一环，整个验证体系就形同虚设。推荐的架构是：

• 验证进程运行在独立的容器或沙箱中。
• 验证进程与推理进程之间通过受控接口通信。
• 验证结果使用签名或消息认证码（MAC）保护，防止传输被篡改。

第三，零知识验证要关注“覆盖范围”而不是“证明强度”。 一个 zk-SNARK 证明即使密码学上非常安全，如果电路没有覆盖某个关键计算步骤，依然是白费功夫。在做协议设计时，一定要画出完整的计算流程图，把每一步都问一遍： 这个步骤是否被验证电路覆盖？

8.2 工程实施建议

下面这些建议来自实际的模型部署项目经验，按优先级排序：

1. 建立模型签名与发布基线 ：每个正式发布的模型都应附带签名，签名私钥由专门的安全团队保管。签名信息包括模型文件哈希、模型结构描述、依赖环境描述、精度格式说明。

2. 使用可信执行环境（TEE） ：如果安全级别要求高，可以把验证逻辑和模型加载逻辑放入 TEE，如 Intel SGX、AMD SEV 等。TEE 能从硬件层面保护验证过程不被篡改。

3. 固定精度格式，杜绝隐式转换 ：大模型推理中的 fp16、bf16、fp32 精度问题已经足够复杂，不要让攻击者再利用格式转换的漏洞。在配置文件中明确声明每个算子的输入输出精度，并在测试阶段覆盖所有精度路径。

4. 建立运行时异常监控 ：监控推理服务的输出分布、权重加载时间、算子执行时间等指标。如果模型被偷偷替换，某些统计指标往往会发生微小的变化。这种变化可能不足以被肉眼发现，但自动化监控能够捕捉到。

5. 回归测试中加入触发探测 ：在模型更新的 CI/CD 流程中加入触发敏感度测试，用随机扰动和变异输入检测模型是否存在异常敏感的区域。

6. 供应链安全审查 ：对模型仓库、依赖镜像、转换工具进行定期安全审查。尤其是使用了第三方量化工具、蒸馏工具、微调工具时，要确认工具本身没有被投毒。

8.3 给安全研究者的建议

如果你打算深入这个方向，下面几个研究点非常值得关注：

• 验证协议覆盖范围的自动化审计 ：目前缺少自动化工具来检测“验证与计算不一致”。如果能开发出针对 PyTorch 模型计算图的验证覆盖审计工具，会非常有价值。
• Ghost Weights 的形式化定义 ：现有攻击研究对“幽灵权重”的定义还比较模糊，如何给出一个严格的形式化定义，对后续检测方案的设计非常重要。
• 针对量化模型的验证方案 ：量化模型的验证比全精度模型复杂得多，因为量化误差本身就接近噪声水平。如何在噪声中区分正常的量化误差和恶意篡改，是一个很好的研究方向。
• 联邦学习场景下的空心客户端检测机制 ：如何在中心服务器不接触客户端原始数据的前提下，验证客户端权重更新中不存在恶意逻辑，这也是一个极具实际意义的问题。

9. 结语

Hollow-LLM Attack 和 Ghost Weights 这个概念提醒我们： 当安全验证做得越来越复杂时，攻击者的目标往往不是打破密码学算法，而是打破“验证所假设的边界” 。零知识验证解决的是“如何在不泄露秘密的前提下证明秘密正确”，但当秘密的“正确”不再等价于模型的“安全”时，整个验证体系就需要重新设计。

对普通开发者来说，我的建议其实很简单：不要迷信任何单一的验证手段，也不要把安全性寄托在一个哈希值或一份证明上。把安全思维融入模型分发的每一个环节——校验加载链路、固定精度格式、监控运行时行为、在 CI 中集成回归测试，这些基础的工程习惯比任何复杂的密码学协议都更能兜底。

如果你正在做 LLM 部署或安全相关工作，希望这篇文章能给你带来一些启发。模型安全是一个攻防双方不断博弈的领域，我们没有一招制敌的方法，但至少可以通过系统化的防御让攻击成本变得足够高。如果这篇文章对你有帮助，可以收藏备用，也欢迎在实践中多动手验证这些思路。