一、从容器到微VM为什么你还需要再多一层隔离在这个系列前几篇里你已经给本地的 Ollama Qwen3.5 做了相当多的安全加固网络侧只监听127.0.0.1前面加 API 网关做鉴权和限流系统侧容器内非 root、--read-only根文件系统、--cap-dropALL内核侧seccomp 限制系统调用、AppArmor 限制可访问路径和设备逻辑侧统一的「零信任工具调用网关」白名单、参数校验、路径限制、审计日志攻防侧用 5 类 Prompt Injection 攻击样例对网关做了回归测试。这些加固已经能挡住大量「普通」问题但现实里还有两个更狠的场景你要跑的代码本身就不可信例如代码助手/Notebook Agent 直接执行用户输入的 Python / Shell / Node 代码或者给内外部用户提供“在线运行脚本”的能力你不完全信任“模型 网关 你自己写的逻辑”工程里总会有 bug新人接入新工具时忘了走网关、少写一层校验这种事情本身就很难完全避免。在这两类场景下哪怕你前面那些层做得再好只要在“容器 同一个内核”这条线上出了一个洞攻击者就有机会利用内核漏洞、容器配置错误、逻辑缺陷做横向移动。所以很多生产级 LLM Agent / 代码执行平台在 2025–2026 年都走向了同一个方向在容器之外再套一层「微VMmicroVM」把不可信代码和高风险工具调用关进一个真正的“迷你虚拟机”里。二、gVisor、Firecracker、Kata三种隔离选择怎么选现在主流的几种“比容器更硬”的方案大致是这三类维度gVisorFirecracker 微VMKata Containers隔离级别用户态“伪内核”拦 syscalls真实轻量级 VM 自己的内核用 QEMU/Firecracker 跑一份常规容器典型模式替换容器 runtime直接管理 VM/通过上层平台使用作为containerd/K8s 的 runtime启动速度非常快接近容器比容器慢一点百毫秒秒级相对最慢内存开销相比原生容器略高会多一份客体内核开销相对最大集成难度低Docker/Containerd 一行配置中需管理内核/镜像/网络略高K8s 场景更多隔离强度比普通容器明显更强接近“小号 KVM 虚机”和常规 VM 类似结合这条系列文章的定位本地 Ollama Qwen3.5偏工程实践可以有一个比较务实的选择对绝大多数「读文件、调内网 API、生成周报/监控报表」这类任务gVisor 就够了—— 操作简单、兼容性好、性能损耗低。对少数「执行用户代码、跑 Shell/Python 脚本、接第三方工具」这类高危任务用 Firecracker 或基于 Firecracker 的平台比如一些开源沙箱框架作为真正的“铁罩盔”。下面按照这种思路分别给出一个gVisor 接入 Ollama和一个Firecracker 驱动高危工具执行的落地路线。三、用 gVisor 给 Ollama 换一层“特制 runtime 盔甲”3.1 gVisor 是什么一句话概括gVisor 在用户态实现了一层“伪内核”把容器里的系统调用都转发给它处理从而在「应用 → 宿主机内核」之间加了一道缓冲墙。优点对应用基本透明大部分容器镜像可以直接跑不需要为每个任务起 VM启动速度和容器差不多在很多研究和云厂商实践中都被用来跑不太信任的容器化工作负载。3.2 在 Docker 上启用 gVisor runtime示例1安装 gVisor以 Debian/Ubuntu 为例curl -fsSL https://gvisor.dev/install.sh | sh# 或按照官方文档复制二进制到 /usr/local/bin/runsc 等路径2配置 Docker runtime# /etc/docker/daemon.json { runtimes: { gvisor: { path: runsc, runtimeArgs: [ --debug-log, /var/log/gvisor/debug.log, --debug-level, warn ] } } }3重启 Dockerbash复制sudo systemctl restart docker4用 gVisor 跑一个最小容器测试docker run --rm --runtimegvisor busybox uname -a如果能正常输出说明 gVisor runtime 已经可用。3.3 把 Ollama 放进 gVisor 沙箱在你原本的docker run基础上只需要加上--runtimegvisor即可其余安全参数继续保留docker run -d \ --name ollama-gvisor \ --runtimegvisor \ --restartunless-stopped \ --user 1000:1000 \ --read-only \ --cap-dropALL \ --security-opt seccomp/path/to/ollama-seccomp.json \ --security-opt apparmorollama-secure \ -p 127.0.0.1:11434:11434 \ -v /data/ollama-models:/models:ro \ -v /data/ollama-tmp:/tmp \ -e OLLAMA_HOST127.0.0.1 \ -e OLLAMA_PORT11434 \ ollama/ollama:latest3.4 对性能的实际影响有多大可以用两类简单测试1容器启动time docker run --rm hello-world time docker run --rm --runtimegvisor hello-world2一次小 prompt 推理time curl -s http://127.0.0.1:11434/api/generate -d { model: qwen3.5:7b-instruct-q4_0, prompt: 用一句话自我介绍一下 } /dev/null在常规 CPU/GPU 服务器上gVisor 相对原生容器的额外开销通常在几十毫秒百毫秒级对于已经包含模型加载/推理开销的整体链路而言可以接受。四、用 Firecracker 微VM 关住“高危工具执行器”4.1 为什么 Firecracker 适合干这件事Firecracker 是 AWS 为 Lambda / Fargate 做的开源微VM特点是极简虚机只支持最少子集硬件设备减小攻击面启动快可以做到百毫秒到几百毫秒级别内存占用小相比常规 VM 轻不少非常适合“一次性任务”。对「本地 LLM 工具调用」来说非常适合把高危“代码执行器”例如Python REPL、Shell Runner、数据分析脚本塞进 Firecracker 微VM 里跑即便模型被 prompt 注入成功只要攻击活动在 microVM 内部就很难直接打穿到宿主机即便这台 microVM 被彻底搞崩最多销毁这台虚机再重新拉一台。4.2 一个极简 Firecracker 微VM 沙箱架构思路我们不追求一篇文章内做完所有生产级细节而是先给出一个可落地的小 Demo 架构Qwen3.5在 gVisor 容器中 ↓ 工具调用 安全工具网关Python ↓ 根据风险等级 ┌────────────┴────────────┐ │ │ 低风险工具本机/容器内 高风险工具Firecracker 微VM 内 ↓ [微VM 内的小型 HTTP/VSock 服务]网关逻辑大致如下def call_tool(name: str, params: dict, risk: str, caller_id: str): if risk low: return call_safe_tool_locally(name, params, caller_id) elif risk high: return call_tool_in_microvm(name, params, caller_id)4.3 Firecracker 微VM 启动思路简化版在真实环境中你通常不会手写所有 Firecracker API 调用而是用现成的开源沙箱框架例如一些“代码执行沙箱”项目或者自己写一个小服务管理 Firecracker用 Python/Go 管理“VM 池”。这里用伪代码给一个「单机实验用小脚本」思路具体命令需要按你系统调整1准备最小 rootfs 镜像可以用 Alpine/Ubuntu Minimal自行制作 qcow2/raw 镜像2写个 Python 管理脚本import subprocess import json from pathlib import Path FIRECRACKER_BIN /usr/local/bin/firecracker SOCK_PATH /tmp/fc-llm.sock KERNEL_IMG /var/lib/firecracker/vmlinux.bin ROOTFS_IMG /var/lib/firecracker/rootfs.ext4 def start_microvm(vm_id: str): sock f/tmp/fc-{vm_id}.sock Path(sock).unlink(missing_okTrue) # 启动 firecracker 进程 fc subprocess.Popen( [FIRECRACKER_BIN, --api-sock, sock], ) # 通过 API 配置 VM伪代码 import requests, time time.sleep(0.1) base fhttpunix:///{sock.replace(/, %2F)} # 1) 设置 boot-source、drives、machine-config 等 # 2) 在 rootfs 内预置一个小型 HTTP 服务用于接收“执行任务”请求 return sock def call_tool_in_microvm(tool_name: str, params: dict, caller_id: str): vm_id fjob-{caller_id} sock start_microvm(vm_id) # 通过 vsock/HTTP 把要执行的任务发送到 VM 内的服务 # 这里略实际需要一个 agent 在 VM 内监听 # 再拿回执行结果返回给 LLM现实建议如果你不是要做“通用代码执行平台”其实没必要从零开始绑定 Firecracker API可以直接用现成的开源“代码执行沙箱”有的就是基于 Firecracker或用支持 Firecracker 作为后端 runtime 的平台某些云原生平台已经支持。你的 LLM 工具网关只需要把「高危工具」的执行请求转发到这些沙箱平台即可。五、如何在项目里实际“分流”哪些工具用 gVisor哪些工具用微VM可以按**“风险 x 复杂度”**做个非常简单的分级表工具类型示例建议执行环境纯读文件 / 写安全目录读周报日志、写 Markdown 报告gVisor 容器内调内部 HTTP APIPrometheus / Jira / 内网 RESTgVisor 容器内只做 SQL 只读查询几个固定的报表 SQL不允许任意拼接gVisor 容器内配合 DB 权限最小化执行用户传入代码Python 片段、JS 片段、Notebook CellFirecracker 微VM执行 shell 命令ls,grep,tar等命令组合Firecracker 微VM访问外部第三方服务不完全信任的 HTTP/SSH 等Firecracker 微VM 或专用跳板沙箱工具网关里只需要为每个工具做一个简单标注TOOLS { read_file: {func: read_file, risk: low}, list_files: {func: list_files, risk: low}, run_python_snippet: {func: run_in_sandbox, risk: high}, run_shell_command: {func: run_in_sandbox, risk: high}, }然后在统一入口里根据 risk 选择路径即可。六、和前几篇防护层串起来现在你的“本地 LLM 安全堆栈”长这样如果把这一篇和你前几篇一起看你的本地 LLM 安全架构大概可以画成这样一条“洋葱”最外层API 网关 / 访问控制只对内网或零信任通道开放鉴权、限流、基础防火墙。第二层容器 gVisorOllama Qwen3.5 工具网关跑在 gVisor runtime 上容器本身非 root、只读根文件系统、去除所有 capabilities。第三层内核安全策略seccomp 限制系统调用禁止 execve/fork/ptrace 等AppArmor 限制可访问路径和设备。第四层工具网关逻辑零信任所有工具能力统一注册、白名单化参数/路径校验、输出截断、审计日志不允许模型直接拿到“任意 Shell”/“任意 SQL”能力。第五层Prompt / 数据流防护输入侧Prompt Injection 关键词/模式过滤输出侧敏感信息/危险命令检测。第六层高危任务微VM 沙箱只有打上riskhigh标签的工具才进微VM即便逻辑层出 Bug 或模型被注入也最大限度把“事故”封在一台小 VM 里。这样一套组合拳打下来本地 Ollama Qwen3.5 就从“单机 Demo”升级成了一套可以认真讨论「生产级安全」的 LLM 基础设施。 本文所有脚本与配置均在本地实验环境实际测试后整理请结合自身操作系统、虚拟化支持情况和风险等级进行调整。 你现在在本地 LLM 部署里做到的隔离层级是纯容器 / 容器 seccomp / gVisor / 微VM以及你最想先在哪一块上微VM欢迎在评论区聊聊你的实践我可以按你的场景帮你细化一版“高危工具分流策略”。