---
title: "Qwen2.5-14B + GPUStack 兼顾精度与确定性的实现记录"
description: "解析 BASTION 为何选择以 GPUStack 运行本地 LLM（Qwen2.5-14B）而非云端 API。LLM 仅负责日志摘要、报告生成等，严重程度判定与阻断执行交由确定性逻辑；文中还介绍强制 JSON 输出与低 temperature。"
url: "https://bestnetllc.co.jp/zh-hans/docs/qwen2-5-14b-gpustack-%e5%85%bc%e9%a1%be%e7%b2%be%e5%ba%a6%e4%b8%8e%e7%a1%ae%e5%ae%9a%e6%80%a7%e7%9a%84%e5%ae%9e%e7%8e%b0%e8%ae%b0%e5%bd%95/"
updated: "2026-10-19"
category: BASTION
---

# Qwen2.5-14B + GPUStack 兼顾精度与确定性的实现记录

// BASTION 技术解析 2026-05-14

实现记录：Qwen2.5-14B + GPUStack 兼顾精度与确定性

 作者：Hideyuki Chinda / BESTNET LLC   **相关文章：** [多层相关活动检测机制的原理](https://bestnetllc.co.jp/zh-hans/docs/%e5%a4%9a%e5%b1%82%e7%9b%b8%e5%85%b3%e6%b4%bb%e5%8a%a8%e6%a3%80%e6%b5%8b%e6%9c%ba%e5%88%b6/) ／ [DMZ Agent 与验证引擎](https://bestnetllc.co.jp/zh-hans/docs/%e5%9c%a8%e5%8f%af%e8%83%bd%e8%a2%ab%e5%85%a5%e4%be%b5%e7%9a%84-dmz-%e7%8e%af%e5%a2%83%e4%b8%ad%e9%87%87%e7%94%a8%e4%b8%8d%e4%bf%a1%e4%bb%bb-agent%e5%89%8d%e6%8f%90%e7%9a%84%e8%ae%be%e8%ae%a1/)

## 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 为基础 | 绝不将敏感日志发送至外部，通过 GPUStack 运行 Qwen2.5-14B |
| ② 不将判断权交给 LLM | 活动判定与阻断执行均由确定性逻辑处理 |
| ③ 将 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 的角色 |
| --- | --- | --- |
| 摘要生成 | LLM | 将海量日志转换为“发生了什么”的自然语言描述 |
| 关联分析 | LLM | 将多台设备的摘要整合为整体趋势叙述 |
| 严重程度判定 | 确定性代码 | 不使用 LLM（规避误判风险） |
| 阻断执行 | 确定性代码 | 不使用 LLM（不可逆操作） |
| 通知文本生成 | LLM | 格式化为便于运维人员阅读的日语文本 |

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

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

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

  // 设计原则

#### “绝不将系统安全交由 LLM 判断”

LLM 会产生幻觉——生成虚假信息。即便技术不断进步，这一问题也不会完全消失。在将 LLM 引入基础设施运维时，设计必须假定**幻觉不会导致灾难性故障**。

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 选择 | 理由 |
| --- | --- | --- |
| 日常日志分析 | 本地（Qwen2.5） | 绝不外发敏感数据 |
| 常规任务自动化（报告整理等） | 外部 API | 不涉及敏感数据，结构化能力更优 |
| 针对意外问题的复杂推理 | 外部 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
- **按客户环境调优：** 针对每位客户的日志特征，自动优化提示词

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

## 12. 相关文章

- [多层相关活动检测机制的原理](https://bestnetllc.co.jp/zh-hans/docs/%e5%a4%9a%e5%b1%82%e7%9b%b8%e5%85%b3%e6%b4%bb%e5%8a%a8%e6%a3%80%e6%b5%8b%e6%9c%ba%e5%88%b6/) —— LLM 分析结果如何与确定性判断相衔接
- [DMZ Agent 与验证引擎](https://bestnetllc.co.jp/zh-hans/docs/%e5%9c%a8%e5%8f%af%e8%83%bd%e8%a2%ab%e5%85%a5%e4%be%b5%e7%9a%84-dmz-%e7%8e%af%e5%a2%83%e4%b8%ad%e9%87%87%e7%94%a8%e4%b8%8d%e4%bf%a1%e4%bb%bb-agent%e5%89%8d%e6%8f%90%e7%9a%84%e8%ae%be%e8%ae%a1/) —— 正如我们不信任 LLM，我们同样不信任 Agent 的设计
- [BASTION：从“安全产品”到“AI 运维平台”](https://bestnetllc.co.jp/zh-hans/docs/) —— BASTION 的演进历程
- 敬请期待 LLM 幻觉审计的实现

## 13. 联系我们

如贵司正在考虑引入 BASTION，或对联合验证（PoC）项目感兴趣，欢迎通过[联系表单](https://bestnetllc.co.jp/zh-hans/contact-4/)与我们联系。

我们同样可以在引入 BASTION 的同时，为本地 LLM 基础设施（GPUStack + Qwen2.5）的建设与运维提供咨询与支持。我们会根据具体需求范围提供个性化报价方案。

 [免费咨询与联系 →](https://bestnetllc.co.jp/zh-hans/contact-4/)

**BESTNET LLC**

日本国宫城县大崎市古川驿东 2-7-23 邮编 989-6116

[https://bestnetllc.co.jp](https://bestnetllc.co.jp/zh-hans/) ／ TEL: 0229-25-8716