某企业建设了内部模型训练平台。平台中有数个基础大模型，单个模型约 200GB—400GB；数十个 Python 业务模块负责不同场景下的模型调用。
原有自研方案要求每次调用前解密完整模型。文件达到数百 GB 后，等待时间会影响推理响应。Python 模块直接以 .py 文件部署，业务逻辑、调用路径和数据处理流程也可能被分析。
针对这两类问题，Virbox Protector（VBP）使用 Python 字节码保护、Native 主程序加壳和 DS（Data Security）资源加密，分别保护业务代码、模型加载程序与模型文件。
VBP 大模型安全方案摘要
- VBP 的 DS 资源加密可处理 ONNX、PT、SafeTensors、BIN 和自定义模型文件。
- 受保护的 Native 主程序按需读取并解析加密模型，无需在模型加载前将完整的明文模型数据写入内存。
- VBP Python 安全方案支持 Python 3.6—3.13，并可配合 PyInstaller 使用。
- VBP可以对Python 脚本进行保护，无缝切换保护前的Python脚本。
大模型平台需要保护两类文件
第一类是模型文件。该企业的基础模型数量不多，单个文件约 200GB—400GB。原有方案需要全量解密，模型越大，调用前的等待越明显。完整明文进入内存后，也可能被读取或转储。
第二类是 Python 业务模块。数十个模块保存模型调用和数据处理逻辑，需要统一执行代码保护。两类文件的使用方式不同，适合分别处理。
ONNX 文件里可以看到什么
先看模型文件。ONNX 的开放格式使模型部署更方便，也让未保护文件更容易被读取。
ONNX（Open Neural Network Exchange）是常用的模型交换格式。PyTorch 模型导出为 ONNX 后，可以交给 ONNX Runtime、TensorRT、OpenVINO 等推理工具使用。
ONNX 使用 Protobuf 保存计算图、算子节点、权重参数、输入输出定义和元数据。未保护的文件可以被标准工具直接读取：
- Netron 可以显示模型的计算结构；
onnx.load()可以读取节点信息和权重数值；- ONNX Runtime 可以加载模型执行推理。
| 风险类型 | 具体表现 |
|---|---|
| 计算结构暴露 | 计算图和算子节点可被标准工具读取和展示 |
| 权重参数被提取 | Initializers 中保存的权重与偏置可通过 API 获取 |
| 文件被修改 | 权重或计算图可能被修改后重新打包 |
| 训练特征被推断 | 模型逆向分析可能反推出部分训练数据特征 |
模型部署在固件或边缘设备中，同样可能被识别和提取。binwalk 等工具可以在固件镜像中识别 ONNX 模型图，提取出的文件仍能交给标准工具分析。
模型加密后，内存中仍可能出现明文
文件加密保护的是磁盘上的模型。推理程序执行计算时，仍要取得可用的模型数据。
调用前解密完整模型，会让数百 GB 的明文数据进入内存。模型加载期间，相关数据可能被截获或转储。
Linux 环境中的 LD_PRELOAD 可用于劫持推理引擎的动态库加载流程。例如，相关人员可以拦截 TensorRT 的 deserializeCudaEngine 接口，在模型进入内存时获取数据。
模型保护还要处理运行期间的明文暴露。只对磁盘文件加密，无法消除解密后数据被读取的风险。
常见模型保护方式的局限
| 保护方式 | 处理方法 | 主要局限 |
|---|---|---|
| 文件级加密 | 完整模型文件加密，使用前全量解密 | 大文件解密耗时，完整明文会进入内存 |
| 分段加密 | 将模型拆分后逐段解密 | 分段较大时仍要处理大量数据，计算图加载也更复杂 |
| 自定义模型格式 | 将 ONNX 转为私有格式部署 | 影响标准工具兼容性，运行时仍要把数据转换为可用形式 |
模型达到 200GB—400GB 后，全量解密带来的等待和内存占用会更加明显。保护方法需要结合模型体积、推理框架和加载方式选择。
VBP 如何保护 200GB—400GB 模型
VBP 先对 Native 主程序加壳，再使用 DS 资源加密处理模型文件。加密后的模型无法被 Netron、ONNX Runtime、TensorRT 等标准工具直接打开，也无法脱离受保护主程序独立调用。
受保护主程序控制模型的加载和解析。推理运行时，程序处理当前请求所需的数据，使用后释放， 无需在加载模型前，在内存中生成完整明文模型数据。这样可以缩短调用前的等待，并减少完整明文模型在内存中的停留。
DS 资源加密处理文件数据，不依赖模型的计算图或算子类型。平台完成二次微调后，新生成的模型文件可以继续加密。
少量基础模型供多个 Python 模块调用时，DS 加密密码可以统一设置。上层业务模块通过受保护主程序调用模型，不必在每个业务单元中重复处理模型加密逻辑。
VBP 如何保护 Python 业务代码
模型文件处理完成后，平台中的 Python 业务模块还需要单独保护。
Python 业务模块包含模型调用策略和数据处理逻辑。直接交付 .py 文件时，接收方可以阅读源码。代码编译为 .pyc 后，dis 等标准库工具仍能反汇编字节码并继续分析执行逻辑。
VBP 的 Python 安全方案在字节码层处理代码，支持运行时无源码加载、实时加解密和内存防护，并限制 dis 按常规方式反汇编受保护字节码。
该方案兼容 Python 3.6—3.13，可以配合 PyInstaller 使用。VBP支持对Python 脚本批量进行保护,团队不必逐个手动操作。无缝切换保护前的Python脚本。
企业大模型平台如何部署 VBP
模型文件和 Python 代码分别处理后，两部分通过受保护的 Native 主程序建立调用关系。
Python 业务模块（数十个）
│ VBP Python 字节码级保护
▼
受保护的业务逻辑与模型调用代码
│
▼
Native 主程序（VBP 加壳）
│ 解析 DS 加密资源
▼
DS 加密后的模型文件
│ 处理当前请求所需数据
▼
基础大模型（单个 200GB—400GB）与微调模型
| 对比项目 | 原有方式 | VBP 方案 |
|---|---|---|
| 大模型加载 | 使用前解密完整模型文件 | 运行时处理当前请求所需数据 |
| Python 代码 | 缺少统一保护 | 通过命令行批量执行字节码保护 |
| 模型调用入口 | 各业务单元分别处理加解密 | 统一通过受保护主程序调用模型 |
| 微调模型更新 | 新模型缺少对应保护 | ONNX 等微调模型可继续加密 |
| 内存明文 | 解密后完整明文进入内存 | 按请求处理数据，减少完整明文长期驻留 |
实际效果仍需结合模型结构、推理框架和运行环境验证。
哪些场景适合使用 VBP
VBP 适合需要外置部署模型、使用大量 Python 业务代码，或持续生成微调模型的团队。
建设或使用大模型平台的企业通常需要处理大型基础模型、业务微调模型及大量调用模块。自动驾驶、工业视觉和机器人项目会把模型部署在域控制器、工控机、边缘设备或机器人本体中，设备可能被物理接触。医疗 AI、金融 AI 和科研项目也可能把模型放在本地服务器或多个计算环境中运行。
这些场景有一个共同点：模型文件会离开单一的训练环境，业务代码和推理程序也会交付给更多人员使用。接入前需要确认模型格式、Python 版本、推理框架和主程序的文件读取方式。
模型文件离开训练环境后，静态文件与运行过程都可能出现暴露风险。VBP 使用 Python 字节码保护、Native 主程序加壳和 DS 资源加密，分别处理业务代码、模型加载和模型文件。对于数百 GB 模型与多模块调用场景，该组合可以减少全量解密带来的等待，并限制模型文件脱离受保护主程序独立使用。
大模型与 Python 业务代码保护，是 VBP 在 AI 软件交付场景中的一项应用。
深盾科技 · Virbox | 让数字世界充满信任
Virbox Protector（VBP）是一套面向软件交付安全的全栈软件加密与应用加固解决方案，广泛覆盖本地程序、移动应用、Java/.NET/Python、Unity、SDK、静态库、目标文件与 AI 模型等软件资产，帮助企业在交付之后依然保持代码、算法、资源和业务价值可控。
