1. 引言 —— 为什么选择本地 LLM #

BASTION 的核心是本地 LLM（Qwen2.5-14B）。我们并没有选择 GPT-4 或 Claude 这类最前沿的外部 LLM API，而是选择在自有 GPU 服务器上运行的 Qwen2.5。

自然会有人问：「既然有精度更高的选项，为什么要选择性能较弱的本地模型？」本文将说明这一决策背后的理由，以及我们实际的运营方式。

先说结论：本地 LLM 拥有三项与「精度」无关的强大优势，而在基础设施运维领域，这些优势更为重要。

2. 云端 LLM 面临的三大障碍 #

在 BASTION 开发初期，我们自然也考虑过使用 OpenAI API 或 Anthropic API。然而，我们遇到了三个障碍：

2.1 数据主权障碍 #

BASTION 处理的日志中包含敏感的客户信息：攻击来源 IP、内部系统架构、用户名、认证失败详情等。将这些信息发送给外部 LLM API，在许多客户合同中是被禁止的。

尤其在金融、政府、医疗等行业，「将日志外发即构成违约」的情况并不罕见。在这些场景下，云端 LLM 根本无法使用。

2.2 成本不透明 #

外部 LLM API 按使用量计费。像 AWS DevOps Agent 这类服务是按秒计费的。而 BASTION 7×24 小时持续运行，成本会随日志量线性增长，导致月度预算难以预测。

结果就是：「攻击较多的月份预算超支」，而「平静的月份又浪费已分配的预算」，成本优化因此变得极为困难。

2.3 网络依赖问题 #

云端 LLM 需要互联网连接。在封闭网络（例如通过专线隔离的网络）中，根本无法使用。

部分 BASTION 的目标客户希望获得「在无互联网连接的环境中也能运行的监控系统」。捕捉这一细分需求正是我们实现差异化的关键。

3. BASTION 的 LLM 使用策略 —— 三大原则 #

基于上述因素，BASTION 在 LLM 使用上遵循三大原则：

简而言之，将 LLM 用作「聪明的秘书」，而将判断交给确定性代码。这与业界主流的 LLM 使用方式略有不同。

4. 架构 —— GPUStack + Qwen2.5-14B #

BASTION 的 LLM 基础设施采用了简单的架构：

BASTION Central Server (AI-SLOG)
  │
  ├── rsyslog receives logs from each device
  ├── Shell script group for preprocessing and summarization
  │     │
  │     ↓ HTTP API call (OpenAI-compatible)
  │
  └── GPUStack Cluster
        ├── Qwen2.5-14B (primary model)
        ├── Lightweight model (fallback)
        └── Automatic load balancing + automatic restart

以下是我们选择这一方案的理由：

4.1 为什么选择 Qwen2.5-14B #

在 BASTION 中，日志摘要与自然语言报告生成是主要任务。这些任务要求：

• 自然的日语输出 —— 中英文混杂的客户报告无法使用
• 14B 的模型规模 —— 无需量化即可在单张 24GB 显存的 GPU 上运行
• 长上下文支持 —— 日志摘要需要足够的上下文长度
• 开放的许可协议 —— 明确允许商用

我们也评估过 Llama 3 系列，但 Qwen2.5 在日语自然度上更胜一筹。这是我们内部评估得出的结论。

4.2 为什么选择 GPUStack #

GPUStack 是一款将多台 GPU 服务器整合为集群的开源软件。对于 BASTION 而言：

• 与 OpenAI 兼容的 API，可用于外部访问
• 模型切换简便（主模型故障时可回退至备用模型）
• 支持分布式运维（可在多台 GPU 服务器上并行处理）
• 自带运维仪表盘（可一目了然地查看模型状态）

这些都符合我们商用环境的要求。

5. 处理流水线 —— 从日志到通知 #

BASTION 对 LLM 的使用横跨多个环节：

1. Receive device logs        (rsyslog)
        ↓
2. Classify and save by device (shell + filesystem)
        ↓
3. Summarize per device       (LLM call #1)
        ↓
4. Full correlation analysis  (LLM call #2)
        ↓
5. Severity determination     (deterministic logic)
        ↓
6. Slack notification         (auto-post only if CRITICAL)
        ↓
7. Detailed analysis          (operator calls on mention)

关键在于，每个环节中 LLM 的职责都被明确划定。

「不让 LLM 做判断，只把格式化工作交给它」——这一原则贯穿始终。

6. 哪些交给 LLM，哪些不交给 LLM #

这是 BASTION 设计理念的核心部分，因此我在此详细说明：

BASTION 从设计阶段起就明确区分了可信任 LLM 输出的场景与不可信任的场景：

6.1 可以交给 LLM 的事项 #

• 自然语言日志摘要 —— 细微的措辞差异可以接受
• 将多台设备的状态整合为一段文字 —— 供人阅读
• Slack 通知文本的格式化 —— 按严重程度添加表情符号与强调标记的工作交由其完成
• 参考过往类似事件 —— 提示「上周也发生过这种情况」

6.2 不能交给 LLM 的事项 #

• 某 IP 是否为恶意的最终判定 —— 通过数学方式决定
• 是否执行阻断的决策 —— 条件在代码中明确写死
• 是否解除阻断的决策 —— 仅通过 24 小时自动过期或运维人员操作
• 生产环境配置的变更 —— 仅由运维人员手动操作
• 安全严重等级的最终评定 —— 基于规则判定

虽然运维人员常常会阅读 LLM 的输出来做决策，但在 BASTION 中，LLM 的输出几乎从不直接控制系统行为。

7. 混合 LLM 策略 —— 本地与外部 API 的协作 #

截至 2026 年 5 月，BASTION 不仅在使用本地 LLM，还处于探索阶段，尝试与 Claude、GPT 等高性能外部 LLM API 进行集成。

不过，这并非「放弃本地 LLM，转而迁移至外部」。我们正在构建一套基于使用场景的选择机制。

对于数据主权要求严格的客户，我们仍然提供断开外部 LLM、仅在本地运行的配置。这款产品的定位是「在需要时可扩展使用外部 LLM」，而非「必须使用外部 LLM」。

8. 关键设计决策 #

在本地 LLM 的运维过程中，我们形成了若干重要决策：

1. 对提示词进行版本管理： LLM 的提示词（查询语句）像代码一样纳入版本管理。输出质量会随提示词的改动显著变化，因此我们保留了完整的变更历史。

2. 强制 JSON 格式输出： 自由格式的 LLM 输出无法被下游代码解析。BASTION 强制要求 JSON 格式输出，并在解析出错时进行重试。

3. 保持较低的 temperature： 为使相同输入产生稳定输出，temperature 保持在较低水平（0.0–0.3）。这里不需要创造性，确定性才是关键。

4. 在提示词中加入「禁止编造」的指令： 始终包含诸如「绝不编造日志中不存在的信息」「不确定时明确返回『unknown』」之类的指令。这并不能完全消除幻觉，因此我们在下游还进行了幻觉审计（详情将另文说明）。

5. 模型故障时的回退机制： 若主模型（Qwen2.5-14B）无响应，我们会回退至轻量级模型。持续进行基础摘要，总好过完全停摆。

9. 运维成果 —— 噪音降低与确定性 #

BASTION 投入生产运行约一个月后，LLM 的运维记录如下：

• 日志分析自动化率： 约 95%（以 LLM 摘要取代了运维人员手工 tail 日志）
• Slack 通知噪音降低： 改为仅在 CRITICAL 时通知后，常规通知频率降低约 8 倍
• 判定确定性： 相同输入始终得到相同判定结果（消除了 LLM 概率性输出的影响）
• 误报率： 0%（未发生过误阻断内部或合作伙伴 IP 的事件）
• 幻觉检测： 审计逻辑持续检测幻觉；检测到的事件会被丢弃并重新分析

「100% 确定性」尤为重要。基于 LLM 的判断对相同输入可能给出不同结果，而 BASTION 避免将判断交给 LLM，因此「不可复现的异常行为」永远不会发生。

10. 设计上的权衡 #

坦率地说，本地 LLM 运维也存在一些限制：

1. 初期 GPU 成本： 要流畅运行 Qwen2.5-14B，需要 24GB 级别的 GPU。最低配置也要花费数万美元。与云端 API 不同，这里没有「免费额度」可用。

2. 推理性能的上限： 14B 模型的推理能力比不上 GPT-4 或 Claude 3.5 Sonnet。复杂的多步推理可能需要回退至外部 API。

3. 模型更新的跟进： 新模型的出现需要评估与切换决策，这需要内部具备相应的技术判断能力（这一点包含在 BASTION 的维护合同中）。

4. 持续的提示词优化： 最优提示词因环境而异，初期调优与持续的运维改进都是必不可少的。

这些都是「选择本地 LLM 所无法回避的权衡」。我们接受这些代价，以换取数据主权、成本可预测性以及在封闭网络中运行的能力。

11. 未来发展 #

LLM 基础设施将持续演进：

• 跟进新一代模型： 对 Qwen3 及下一代模型进行评估与迁移
• 混合 LLM 策略的规范化： 将基于使用场景的自动路由标准化
• 多模态支持： 将网络拓扑图与流量图输入给 LLM
• 按客户环境调优： 针对每位客户的日志特征，自动优化提示词

我们将逐步推进这些工作。