在 Apple Silicon 上运行本地法学硕士以进行安全分类

一个将网络连接分类为值得一看或不值得一看的模型，在建立连接的同一台 Mac 上运行，会立即改变三件事：离开机器的东西、运行的成本以及当网络本身受到怀疑时它是否继续工作。对于安全工具来说，这三者比对于语言模型的大多数其他用途更重要，这就是为什么本文专门讨论设备上的情况，而不是调用 API。

为什么在设备上，专门用于分类

将连接日志行发送到云模型进行分类意味着对于每一个决策，Mac 上的哪个应用程序现在正在与哪个主机、哪个端口进行通信。这些都不像密码那样是秘密，但它正是一种具有安全意识的设置试图尽量减少共享的元数据，而一个工具的全部目的是决定你的 Mac 是否可以发送到其他地方，它本身有一个明显的理由不依赖于将某些内容发送到其他地方来做出每个决定。在本地运行模型完全消除了这种依赖性：日志行永远不会离开设备，因为决策路径中根本没有网络调用。

第二个原因是连续性。基于云的分类步骤仅在您的互联网连接和供应商的 API 时可用，而这两者正是在真实事件中可能被降级或故意削减的东西。在本地内存中运行的模型会在网络中断、Wi-Fi 关闭或 API 调用可能使用的同一链接上出现可疑的泄露时不断做出响应。

MLX：Apple自己的数组框架

MLX 是苹果机器学习研究团队专门为苹果芯片构建的数组框架，具有 Python、C++、C 和 Swift API。它自己的文档将统一内存模型描述为其定义的设计选择：MLX 中的数组位于共享内存中，对它们的操作可以在任何支持的设备（CPU 或 GPU）上运行，而无需首先在单独的内存池之间复制模型的权重。这对于笔记本电脑来说尤其重要：离散 GPU 机器必须通过总线将模型的权重复制到 GPU 内存中，然后才能计算任何内容，这会花费时间并使内存占用量增加一倍；在Mac的统一内存架构上，CPU和GPU已经共享相同的物理内存，因此没有什么可以复制的。

mlx-lm 是在 MLX 上运行语言模型的配套软件包，使用单个命令即可安装，并提供开箱即用的默认模型：

$ pip install mlx-lm
# runs the default model (mlx-community/Llama-3.2-3B-Instruct-4bit)
$ mlx_lm.generate --prompt "How tall is Mt Everest?"
# or name a specific quantized model from the mlx-community hub
$ mlx_lm.generate --model mlx-community/Mistral-7B-Instruct-v0.3-4bit --prompt "..."
# interactive chat session instead of a single prompt
$ mlx_lm.chat
# convert and quantize a model yourself
$ mlx_lm.convert --model mistralai/Mistral-7B-Instruct-v0.3 -q

llama.cpp：便携式选项

llama.cpp 是两者中较旧的、移植更广泛的，用 C/C++ 编写，推理时不需要 Python 运行时。它自己的自述文件直接说明了该项目在该硬件上的立场：用该项目的话说，苹果芯片被视为“一等公民——通过 ARM NEON、Accelerate 和 Metal 框架进行优化”，其构建文档确认，在 macOS 上，Metal GPU 后端默认启用，如果您特别想要仅 CPU 推理，则可以使用构建时标志将其禁用。

$ git clone https://github.com/ggml-org/llama.cpp
$ cd llama.cpp
$ cmake -B build
$ cmake --build build --config Release
# Metal is on by default on macOS; add -DGGML_METAL=OFF to the first
# command above if you need to force CPU-only inference
$ llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF
# or run it as a local server instead of a one-shot command
$ llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

llama.cpp 使用 GGUF 文件，这是一种单文件模型格式，捆绑了量化权重以及运行它们所需的所有内容；上面的命令直接从 Hugging Face 存储库中按名称提取一个。相比之下，MLX 更接近原生 Python 工作流程，提前将模型转换和量化为自己的格式。严格来说，两者都不是更好：如果您想要一个不依赖 Python 的编译二进制文件，则可以使用 llama.cpp；如果您已经在 Python 中构建管道的其余部分，并且希望从那里对 Apple 的统一内存模型进行一流的访问，则可以使用 MLX。

量化：你实际用什么换取更小的模型

量化以比模型训练时使用的 16 或 32 位更少的位数存储每个模型权重，从而缩小了磁盘上的文件和运行该文件所需的内存，但会牺牲输出质量。 llama.cpp 自己的量化文档列出了它支持的每个方案的精确位/权重数字，这是比通常的“4 位”或“8 位”简写更精确的权衡方式：

将模型的参数计数乘以每权重的位数即可得出单独权重的粗略内存估计：Q4_K_M 每权重 4.89 位的 70 亿参数模型需要大约 7,000,000,000 × 4.89 ÷ 8 字节，或大约 4.3 GB，然后再考虑上下文窗口和中间激活，这会根据您输入的文本量添加更多内存它。这是根据引用的每权重位数计算得出的，而不是任何一个项目直接发布的数字，一旦加载了真实的提示及其上下文，实际的内存使用量将会更高。从表中得出的实用指南很简单：对于一次对一个连接日志行进行分类这样的任务，其中输入很短并且所需的输出是一个小的结构化判决，Q4_K_M 类模型通常是正确的选择 - 比 Q8_0 或 F16 明显更小且更快，而不会下降到输出质量急剧下降的极端压缩层。

这两个项目都没有公布每个 Mac 配置的内存要求，因此实际的方法是从上面的估计开始向后工作，并留出真正的空间：macOS 本身、您的浏览器和正在运行的其他任何东西也都需要统一内存，而一个几乎不适合任何其他打开的模型将在您切换到另一个应用程序时交换或停止。在具有适量统一内存的 Mac 上，建议保留上表中较小的一端（Q4_K_M 的数十亿个参数，而不是相同量化的更大模型），并为有备用内存的机器保留更大、更高精度的选项。对于像本文所讨论的狭窄分类任务，提出精确问题的较小模型往往比给出模糊问题的较大模型更快，而且在实践中更一致。

这两个项目都在积极开发中，诚实的比较不是“哪个更好”，而是“哪个适合您的管道”。 llama.cpp 编译为单个二进制文件，在推理时不需要 Python 运行时，如果您想将其嵌入到另一个软件中而不附带 Python 解释器，这一点很重要。 MLX 假设您已经在使用 Python（或 Swift，它还提供了绑定），并通过更紧密地集成到 Apple 自己的机器学习堆栈和上述统一内存模型中来奖励您。作为独立 macOS 应用程序构建的安全工具，这就是 FireAI 本身所处的情况，更接近该范围的 llama.cpp 端；靠近 MLX 端的研究笔记本探索哪种提示模式最有效。

用于对一个连接进行分类的提示模式

你向小型本地模型提出的问题越窄，它的回答就越可靠。对于单一连接，这意味着准确地给出人类审阅者会查看的字段——仅此而已，没有任何推断——并要求结构化的判决而不是自由形式的散文：

System: You review one outbound network connection at a time. You are
given only the fields listed below. Do not assume anything not stated.
Respond with exactly two lines: a verdict (allow, ask, or block) and a
one-sentence reason a non-expert could understand.

Connection:
  app: UpdaterHelper.app
  code_signature: unsigned
  destination: 91.203.xxx.xxx:4444
  protocol: TCP
  threat_feed_hit: none
  first_seen: yes (no prior rule for this app)

Verdict:

重要的字段是代码签名检查和威胁源实际上可以在无需猜测的情况下生成的字段：二进制文件是否由谁签名、尝试连接的位置和端口、该目标是否显示在威胁源上，以及这是否是该应用程序第一次尝试连接。要求固定的两行输出，而不是开放式的解释，使得结果更容易记录，更容易在数千个连接之间进行比较，并且模型更难用听起来很权威的对冲语言来填充，而不说任何可检查的内容。

无论如何，小模型偶尔会忽略所请求的格式 - 三行而不是两行，一个额外的警告，一个不是您要求的三行之一的结论词。将其视为一个工程问题，而不是建模问题：根据您期望的确切形状验证输出，如果不匹配，则重新询问或回退到最安全的判决（询问，意思是向人类展示），而不是尝试解析较宽松的答案。在格式错误的输出上安全失败的分类步骤比偶尔生成看似自信但无法解析的行并默默丢弃它的分类步骤有用得多。

在一整天的连接尝试中运行此模式，而不是一次一个，并且工作负载的形状会发生变化：大多数连接来自具有现有规则的应用程序，并且根本不会到达模型，少数连接是真正第一次看到并获得判决，并且这些判决中只有一小部分是例程允许之外的任何内容。此时，模型的真正工作不是成为安全专家；而是成为安全专家。它是将一长串首次看到的连接削减为一个人实际需要查看的小子集，对于数十亿参数的模型来说，这是比开放式安全判断更容易实现的目标。

哪里出了问题

• 一个小的本地模型可以产生一个自信的、写得很好的、完全错误的理由。本地运行不会改变这种风险；它只会改变错误发生的位置，而不改变错误是否会发生。
• 上下文窗口是有限的，不适合长而嘈杂的日志。在模型看到数据之前进行总结或预过滤会引入其自身的故障点 - 您可能会在模型有机会查看数据之前丢失一行重要的数据。
• 该模型只能看到日志行包含的内容。它无法看到内部加密流量，无法验证威胁源是否是最新的，并且无法了解您的意图 - 来自您刚刚特意安装的工具的连接看起来与来自您从未听说过的工具的连接相同。
• 判决不是行动。这里的任何内容都不应阻止、删除或默默地允许连接；人们仍然需要查看原因并确认它，并且如果模型出错，则能够撤销调用。

最后一点并不是特定于笔记本电脑上运行的小型量化模型的限制 - 对于每个自动化安全决策（本地或云，小型模型或大型模型）都是如此。在本地运行它的价值在于它从等式中消除了一些东西（网络依赖、经常性账单、接收连接元数据的第三方），而不是声称它消除了对循环中的人员的需要。

FireAI 适合这种模式的地方

FireAI 是 HisnLabs 的 Mac 防火墙，它提供了基于相同想法构建的东西，但范围比通用聊天模型更窄：一个可选的本地模型，额外下载约 1.5 GB，完全在 Mac 上运行，并审查来自尚无规则的应用程序的连接。它需要 Apple 芯片上的 macOS 14 或更高版本，在本地应用公共威胁源，而不是根据远程服务检查它们，并在用于要求您允许或拒绝连接的同一权限提示中显示其决定的原因 - 每个决定都成为可见的、可编辑的规则，并且其中任何一个都可以撤消。值得准确说明它是什么和不是什么：它不是本文描述的开放式、数十亿参数的聊天模型，也不是防病毒软件或 VPN——它在本地执行一项狭窄的分类工作，并将最终决定权留给阅读提示的人。

FireAI 和 HisnLabs 在其中扮演的角色

FireAI’s own connection reviewer is this exact bet, made narrower still: an optional, roughly 1.5 GB on-device model, macOS 14 and up, Apple silicon only, reviewing one thing (should this unknown app reach this destination) with a visible reason and an undo button — and, like the triage pattern in this article, it still needs a person to confirm anything consequential.

FireAI 是 HisnLabs 自己的产品：一款直接在 Mac 上运行的 AI 防火墙。它用通俗易懂的语言显示你的应用建立的每一个连接，并让你决定哪些数据可以离开你的 Mac——它的 AI 在本地运行，因此你的流量永远不会发送给我们或任何其他人。HisnLabs 的安全研究团队负责让这些判断保持准确：归类哪些域名只是普通的遥测、哪些属于真正的服务，追踪连接背后的国家和网络，并用真实的流量模式训练设备端模型（Autopilot 功能）——这一切都不会离开你的 Mac。

你可以阅读它背后的技术决策，或试用 FireAI 17 天：HisnLabs 出品的 FireAI。