---
title: "Qwen2.5-14B + GPUStack 實現精度與確定性兼具的實作記錄"
description: "解說 BASTION 為何選擇以 GPUStack 運行本機 LLM（Qwen2.5-14B）而非雲端 API。LLM 僅負責日誌摘要、報告生成等，嚴重度判定與封鎖執行交由確定性邏輯；文中也介紹強制輸出 JSON 與低 temperature。"
url: "https://bestnetllc.co.jp/zh-hant/docs/qwen2-5-14b-gpustack-%e5%af%a6%e7%8f%be%e7%b2%be%e5%ba%a6%e8%88%87%e7%a2%ba%e5%ae%9a%e6%80%a7%e5%85%bc%e5%85%b7%e7%9a%84%e5%af%a6%e4%bd%9c%e8%a8%98%e9%8c%84/"
updated: "2026-10-14"
category: BASTION
---

# Qwen2.5-14B + GPUStack 實現精度與確定性兼具的實作記錄

// BASTION 技術解說 2026-05-14

實作記錄：以 Qwen2.5-14B + GPUStack 兼顧精度與確定性

 作者：Hideyuki Chinda / BESTNET LLC   **相關文章：** [多層關聯活動偵測機制的運作原理](https://bestnetllc.co.jp/zh-hant/docs/%e5%a4%9a%e5%b1%a4%e9%97%9c%e8%81%af%e6%b4%bb%e5%8b%95%e5%81%b5%e6%b8%ac%e6%a9%9f%e5%88%b6/) ／ [DMZ Agent 與驗證引擎](https://bestnetllc.co.jp/zh-hant/docs/%e5%9c%a8%e5%8f%af%e8%83%bd%e9%81%ad%e5%8f%97%e5%85%a5%e4%be%b5%e7%9a%84-dmz-%e7%92%b0%e5%a2%83%e4%b8%ad%e6%8e%a1%e7%94%a8%e3%80%8c%e4%b8%8d%e4%bf%a1%e4%bb%bb-agent%e3%80%8d%e5%89%8d%e6%8f%90%e7%9a%84/)

## 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 是**全天候 24 小時持續運作**的，成本會隨著日誌量呈線性增加，月度預算變得難以預測。

結果就是「攻擊多的月份預算爆表」，「平靜的月份則浪費了已編列的預算」，成本最佳化變得極為困難。

### 2.3 網路依賴性

雲端 LLM 需要網際網路連線。在封閉網路（以專線隔離的網路等）中，根本無法使用。

部分 BASTION 的目標客群希望擁有「在無網際網路連線環境中也能運作的監控系統」。掌握這個客群正是差異化的關鍵所在。

## 3. BASTION 的 LLM 運用策略 — 三大原則

基於上述因素，BASTION 在 LLM 的使用上遵循三項原則：

| 原則 | 意義 |
| --- | --- |
| ① 以本機 LLM 為基礎 | 絕不將敏感日誌外傳。透過 GPUStack 運行 Qwen2.5-14B |
| ② 不將判斷交給 LLM | 攻擊活動的判定與封鎖的執行，均由確定性（deterministic）邏輯處理 |
| ③ 將 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**，供外部存取
- **易於切換模型**（主模型失效時可作為 fallback）
- **可進行分散式運作**（跨多台 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 會產生幻覺（hallucinate）— 生成虛假的資訊。即使技術不斷進步，這個問題也不會完全消失。將 LLM 導入基礎設施維運時，設計上必須假設**幻覺不會導致災難性的失敗**。

BASTION 從設計階段開始，就將「可信任 LLM 輸出」與「不可信任 LLM 輸出」的情境明確區分：

### 6.1 可以信任 LLM 的部分

- **自然語言日誌摘要** — 些微的用詞差異是可接受的
- **將多台設備的狀態彙整成一段文字** — 供人閱讀
- **Slack 通知文字的格式化** — 依嚴重度加上表情符號與強調標示，交由 LLM 處理
- **參照過往類似事件** — 提示「上週也發生過這種情況」

### 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. 模型失效時的 fallback：** 若主模型（Qwen2.5-14B）無回應，則會 fallback 至輕量模型。持續提供基本的摘要功能，總比完全停擺來得好。

## 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。複雜的多步驟推理可能需要 fallback 至外部 API。

**3. 模型更新的追蹤：** 新模型推出時，需要進行評估與切換的決策，這需要內部具備相應的技術判斷能力（此部分涵蓋於 BASTION 維護合約中）。

**4. 持續的提示詞調校：** 最佳提示詞因環境而異。初期調校與持續的維運改善都是必要工作。

這些都是**「選擇本機 LLM 無可避免的取捨」**。我們接受這些代價，以換取資料主權、成本可預測性，以及封閉網路環境下的可用性。

## 11. 未來發展

LLM 基礎設施將持續演進：

- **追蹤新一代模型：** 評估並遷移至 Qwen3 及下一代模型
- **將混合式 LLM 策略落地：** 將依使用情境自動分流的機制標準化
- **支援多模態：** 將網路架構圖與流量圖表輸入 LLM
- **依客戶環境調校：** 自動化提示詞最佳化，使其符合各客戶日誌的特性

我們將逐步推進這些項目。

## 12. 相關文章

- [多層關聯活動偵測機制的運作原理](https://bestnetllc.co.jp/zh-hant/docs/%e5%a4%9a%e5%b1%a4%e9%97%9c%e8%81%af%e6%b4%bb%e5%8b%95%e5%81%b5%e6%b8%ac%e6%a9%9f%e5%88%b6/) — 如何將 LLM 分析結果串接至確定性判斷
- [DMZ Agent 與驗證引擎](https://bestnetllc.co.jp/zh-hant/docs/%e5%9c%a8%e5%8f%af%e8%83%bd%e9%81%ad%e5%8f%97%e5%85%a5%e4%be%b5%e7%9a%84-dmz-%e7%92%b0%e5%a2%83%e4%b8%ad%e6%8e%a1%e7%94%a8%e3%80%8c%e4%b8%8d%e4%bf%a1%e4%bb%bb-agent%e3%80%8d%e5%89%8d%e6%8f%90%e7%9a%84/) — 正如我們不信任 LLM，我們也同樣不信任 Agent 的設計
- [BASTION：從「安全產品」到「AI 維運平台」](https://bestnetllc.co.jp/zh-hant/docs/) — BASTION 的進化故事
- 即將推出 LLM 幻覺稽核實作記錄

## 13. 聯絡我們

正在考慮導入 BASTION 的企業，或對聯合概念驗證計畫有興趣的組織，歡迎透過我們的[聯絡表單](https://bestnetllc.co.jp/zh-hant/contact-3/)與我們聯繫。

我們也能針對搭配 BASTION 導入的本機 LLM 基礎設施（GPUStack + Qwen2.5）建置與運作，提供諮詢與支援。我們將依需求範圍提供個別報價的提案。

 [免費諮詢與聯絡 →](https://bestnetllc.co.jp/zh-hant/contact-3/)

**BESTNET LLC**

2-7-23 Ekihigashi, Furukawa, Osaki, Miyagi 989-6116

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