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 當作「聰明的秘書」來使用，判斷則交給確定性程式碼。這與業界主流的 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 做判斷，只將格式化工作交給它」 — 這項原則始終一致貫穿全流程。

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

這是 BASTION 設計理念的核心，因此我會詳加說明：

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、僅以本機運作的組態。此產品的定位是「可視需求擴充使用外部 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
• 依客戶環境調校： 自動化提示詞最佳化，使其符合各客戶日誌的特性

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