知識庫是燃料，地端模型是引擎：地端 AI 部署，從入門到企業級一次搞懂

知識庫是燃料，地端模型是引擎：地端 AI 部署，從入門到企業級一次搞懂

在開始之前，先接上上一篇的脈絡。

上一篇我們談的是「為什麼台灣建築營造產業需要一個開源知識庫」——因為這個產業最寶貴的資產是經驗，而經驗正以每天幾個人的速度消失。那套知識庫已經開源在 GitHub 上（HJPLUS_Taiwan_Architect_KB），目前有 150+ 筆條目、119 個 fork，內容同時是給人看的 Wiki、也是給 AI 讀的「技能」。

但文章發出後，我被問得最多的一個問題是：

「知識庫很棒，但我到底怎麼用它？一定要買 API 嗎？我的資料會不會外洩？」

這正是本篇要回答的。

知識庫是燃料，地端模型是引擎。 沒有引擎，燃料就只是 GitHub 上一堆 Markdown 檔案。這篇文章要講清楚怎麼讓引擎在你自己的硬體上轉起來——從四種運行環境、怎麼把你的資料接進去，到怎麼算這筆帳划不划算。

如果還沒讀上一篇，建議先從那裡開始：為什麼台灣建築營造產業需要一個開源知識庫

為什麼地端模型很重要？

地端模型不只是「技術愛好者的玩具」，它對不同組織層級都有實際的意義：

1. 對個人來說——你可以完全掌控自己的 AI 工具。不需要依賴雲端服務、不怕帳號被停、不用擔心你的對話內容被拿去訓練。你想試什麼模型就試什麼模型，想怎麼用就怎麼用。
2. 對小型公司來說——如果以知識管理出發，這是成本與隱私的雙贏。你不需要花大錢買雲端 API 的用量，也不用擔心客戶資料、專案文件被傳到第三方伺服器。用自己的硬體跑模型，一次投入、長期使用，對預算有限的團隊來說非常划算。
3. 對大型企業來說——地端部署是合規與安全的基本功。金融、醫療、政府等產業對資料外洩零容忍，模型必須跑在內部。加上併發處理、多機串接的需求，企業級框架（如 vLLM）才能真正滿足生產環境的吞吐量要求。更進一步，有資源的大型企業甚至可以用自己的產業資料訓練專屬的小語言模型（SLM）——在特定任務上，一個訓練好的小模型可以達到跟通用大模型差不多的效果，成本卻低非常多。這不是「用便宜的替代貴的」，而是「用對的取代通用的」。
4. 對學術單位來說——地端模型讓研究不再受限於算力資源。你可以用自己的資料集做實驗、調整模型參數、驗證假設，而不需要排隊等雲端 GPU 或申請研究經費。這也是開放共享精神最直接的體現。
5. 對已經有固定工作流的團隊來說——如果你的 parser、RAG 流程、模型版本都已經固定下來，地端模型可以一用到底。雲端 API 隨時可能改版、換底層模型、調整輸出行為，你的流程會跟著抖；地端模型的權重在你手上，版本固定、行為可預期，不會因為上游一改版就要重調整條工作流。

總結一句：地端模型的核心價值就是「自主」——你掌控硬體、掌控模型、掌控資料。

市場現況：NVIDIA 仍是最大，但不再是唯一

提到 AI 算力，NVIDIA 至今仍是市占最大的玩家。但這個格局正在鬆動：

• AMD 的 ROCm 生態系已經默默崛起，支援度越來越好，成本效益也開始具備競爭力。很多地端框架（包含 llama.cpp）已經能很好地跑在 AMD 的顯示卡上。
• Intel 也開始推 B 系列顯示卡往 AI 運算方向走，雖然目前成熟度還比較弱，但方向是明確的。
• Apple Silicon 則用另一條路——M 系列晶片把 CPU、GPU、記憶體整合在一起，在地端推理上表現不差，尤其適合個人開發者。

這代表什麼？代表你不需要非得買 NVIDIA 才能玩地端模型。硬體選擇變多，框架也在追，門檻正在下降。

不是二選一：地端跟雲端是混用的

很多人以為地端模型的意思是「把雲端全部砍掉」，其實不是。實務上最常見的架構是混用，而地端在這裡有一個很關鍵的角色：去識別化（資料脫敏）。

做法是這樣：

1. 敏感資料先過地端模型——客戶名稱、工地地址、法規機密、合約數字，這些東西先讓本地的模型處理：識別出個人與商業敏感資訊、替換成代號、抽出需要的結構化欄位。這一步資料完全不出你的門。
2. 脫敏後的資料才送雲端——需要大模型處理的重活（長文件分析、複雜推理、大量生成），用已經去掉敏感資訊的版本送上去。就算用了最強的雲端模型，它看到的也只是乾淨的資料。
3. 結果回本地整合——雲端的輸出拿回來，由地端模型套上你的格式、對照你的知識庫做最後校驗。

這個架構同時解決了兩件事：隱私（敏感資料從不離開你的機器）跟成本（只有真正需要大算力的部分才花 API 錢）。對有客戶機密、法規資料的產業來說，這不只是省錢，是合規上的必要設計。

關鍵概念：量化（Quantization）與 VRAM

在進入框架之前，有兩個概念一定要懂：

量化（Quantization）——想像一個 IQ 160 的人，知識精確到極致，但「腦容量」巨大、佔的記憶體多到一般顯卡裝不下。量化就是把他壓縮成 IQ 130：核心推理還在、日常場景幾乎看不出差距，只是極端精細的地方會稍微糊掉。好處是「腦容量」（佔用記憶體）縮小 2 到 4 倍——Q8 約 2 倍、Q4 約 4 倍。這就是為什麼你的 16GB 顯示卡能跑 70 億參數的模型：它被量化過了。GGUF 是目前地端推理最主流的量化模型檔格式，HuggingFace 上熱門模型幾乎都找得到對應的 GGUF 版本。

VRAM（顯示卡記憶體）是硬瓶頸——地端模型最常被問的問題就是「我的顯卡夠不夠？」答案取決於兩件事：模型大小跟量化等級。13B 的模型用 Q4 量化大概需要 8GB VRAM，70B 則需要 40GB 以上。如果你的 VRAM 不夠，有些框架（如 llama.cpp）可以把部分層放到 CPU 跑，速度會變慢但不會跑不起來。

如果你最近有在玩地端 AI 模型，你可能會發現一個現象：同樣是「在自己電腦上跑模型」，但不同的人用的工具完全不同、效果也差很多。

其實地端模型運行環境，大致可以按上手容易程度分成四種。以下逐一列出，各自適合不同需求的人。

第一級：Ollama —— 最簡單的起點

Ollama 是上手門檻最低的環境。

它的優點很單純：簡單。安裝之後，打一行指令就能拉模型、跑模型，幾乎不需要任何設定。第一次嘗試在地端跑模型的人，通常會從這裡開始。

🔗 https://ollama.com

它的限制也很明顯：功能單純、自訂空間有限。如果只是「想看看模型長怎樣」，它夠用了；想要更細部的控制，它就會開始不夠用。但他們也有提供雲端的服務，如果你們沒有 GPU，也能用他們的雲端算力。

第二級：LM Studio —— 開發者友善的折衷方案

LM Studio 在介面和功能之間找到了很好的平衡。

它有完整的圖形介面，操作體驗比 Ollama 好很多。模型則是直接從 HuggingFace 拉取，你在上面看到什麼新模型，基本上下載就能跑，使用的格式是 GGUF。

「有介面、好操作、又有一定自由度」這個組合，是 LM Studio 的定位。不少開發者和進階使用者會從這裡開始。

🔗 https://lmstudio.ai

第三級：llama.cpp —— 有門檻，但性能很好

llama.cpp 是這四個環境中，性能最強的一個。

它的操作方式稍微麻煩一些——沒有圖形介面，設定需要靠指令列和設定檔。但它的優點也很明確：

• 更新極快：GitHub 上幾乎每天都有新分支和新功能被合併進來
• 支援所有 GGUF 模型：HuggingFace 上找得到的模型，幾乎都能跑
• 性能遠超前面兩種：同樣的硬體，llama.cpp 能跑出明顯更好的速度
• 硬體支援最廣：無論你是 Apple M 系列晶片、NVIDIA、還是 AMD，它都有對應的優化

如果你願意花一點時間學習設定，llama.cpp 帶來的性能提升是前面兩種比不了的。這也是很多認真玩地端模型的人最終會走向的地方。

第四級：vLLM —— 企業級部署的首選

vLLM 的設計目標不是個人使用者，而是企業級部署。它的強項有兩個：

1. 併發效率極高：同時處理大量請求時，效率遠超其他框架
2. Tensor Parallelism 做得非常好：可以將多台設備串接在一起運作

舉個例子：假設你有兩台 DGX、或者四張 RTX 5090，vLLM 可以把這些硬體串起來，做出高吞吐量的運算，真正把顯示卡的算力榨到乾。

在企業環境中，vLLM 不是「跑模型」的工具，而是「營運模型」的基礎設施。

🔗 https://vllm.ai

其他值得注意的框架

上面四個是主流，但還有幾個框架在不同場景下非常強：

• Text Generation WebUI（Oobabooga） — 支援多種推理後端（含 llama.cpp、Transformers、ExLlama）的完整圖形介面，功能比 LM Studio 更豐富，支援角色扮演、外掛系統、多模型切換。進階玩家和角色扮演社群非常愛用。🔗 https://github.com/oobabooga/text-generation-webui
• Llamafile — 把模型權重和執行環境打包成單一可執行檔，雙擊就能跑，不需要安裝任何東西。適合快速分享、臨時部署、或是想給完全不懂技術的人用。🔗 https://github.com/Mozilla-Ocho/llamafile
• MLC LLM — 專注於把模型編譯到邊緣設備：手機、樹莓派、甚至瀏覽器。目標是「任何裝置都能跑 AI」，是未來邊緣運算的重要方向。🔗 https://llm.mlc.ai
• TensorRT-LLM — NVIDIA 官方的企業級推理引擎，效能極強但綁定 NVIDIA 硬體。跟 vLLM 定位類似，但更底層、更靠近硬體。🔗 https://github.com/NVIDIA/TensorRT-LLM
• SGLang — 另一套企業級推理引擎，跟 vLLM 定位接近，強項是大規模結構化輸出（要模型穩定輸出 JSON、多階段推理、工具呼叫）。它的編排器在複雜的 agentic 工作流上表現非常好，是現在很多 AI agent 系統的底層首選。🔗 https://github.com/sgl-project/sglang

讓模型讀你的資料：RAG

講到這裡，你可能有個問題：模型跑起來了，那我的資料要怎麼跟它串接？

答案就是 RAG（檢索增強生成，Retrieval-Augmented Generation）。

做法很直覺：把你的文件、PDF、會議記錄、專案資料全部轉成向量（embedding），存進向量資料庫。當使用者提問時，系統先從資料庫找出最相關的資料片段，再把這些片段跟問題一起餵給模型。模型不需要「記住」你的資料，它只需要「讀到」正確的片段，就能給出準確的回答。

這就是為什麼結論會說「你的資料才是金礦」——RAG 就是那個把金礦開採出來的工具。

好消息是，上面提到的框架大多都能跟 RAG 架構串接。Ollama 有現成的 RAG 範例，llama.cpp 也可以搭配 LangChain 或 LlamaIndex 使用。

我們知識庫採的標準：OKF

講到怎麼把知識「餵」給模型，還有一個標準值得特別提——OKF（Open Knowledge Format），2026 年 6 月由 Google Cloud 發布的 v0.1 開放規範。核心很簡單：

把知識整理成一組 Markdown 檔案，每個檔案帶 YAML frontmatter（type、title、description、tags、resource 等），檔案之間用 Markdown 連結互相關聯，形成一張知識圖。人和 AI agent 都能直接讀寫，不需要任何專用工具或 SDK。

我們那套知識庫就是照 OKF 的結構建的。 每一則條目都是一個 Markdown 檔案、帶 frontmatter 的元資料、條目之間用連結互相關聯——跟 OKF 的定義完全一致。

這代表什麼？代表當 OKF 被更多 agent 生態採用（Google 已經讓 Cloud 的 Knowledge Catalog 能匯入 OKF），我們那套知識庫不用重做，任何支援 OKF 的 agent 都能直接讀。過去各團隊都在各自造輪子——AGENTS.md、CLAUDE.md、Obsidian 資料夾、各種自訂格式——互相不兼容。OKF 想把這一百種做法統一成一個標準，而我們是照這個標準從頭建的，往後移植成本最低。

對建築營造業，我們的建議很明確：RAG + OKF 是成本效益最高的選項，fine-tune 通常沒有條件做。

原因很實際：fine-tune 需要大量特定任務的資料，訓練與評估的成本也不低，多數營造業沒有這個條件。但你的知識庫已經是 Markdown + frontmatter 的格式，接上 RAG 就能讓模型「有憑有據」地回答——法規、SOP、專案資料這些用處，RAG + OKF 已經覆蓋了絕大多數場景，而且當天就能用。fine-tune 留給真正需要模型「學會某種風格」的少數場合就好。

另一條路：微調（Fine-tuning）與 LoRA

RAG 是「查資料後回答」，微調（Fine-tuning）則是「內化知識」。

微調是用你的資料去重新訓練模型，讓它真正學會你的領域語言、風格或特定規則。過去微調需要昂貴的 GPU 叢集，但 LoRA（Low-Rank Adaptation） 技術改變了一切。它只訓練模型的一小部分參數，讓你在單張消費級顯卡（如 RTX 3090/4090）上就能完成微調。

RAG 適合「事實性知識」（如法規條文、專案資料），微調適合「風格與行為」（如自動生成特定格式的報告、學習你們公司的用語）。兩者結合，就是最強的地端 AI 應用。

硬體甜蜜點：你的 VRAM 能跑什麼模型？

看完框架，最實際的問題來了：「那我該買什麼硬體？我的顯卡能跑什麼模型？」

地端模型的選擇，VRAM（顯示卡記憶體）就是硬限制——你的顯示卡有多少 VRAM，就決定你能跑多大的模型。模型太大，不是「跑比較慢」，是「根本裝不下」。

怎麼判斷？一個很直覺的經驗法則：模型參數越大，需要的 VRAM 越多。舉例來說，Llama（Meta 家）是最常被討論的地端模型家族，Qwen（阿里家）的中小模型在 16GB 顯示卡上跑得很順，DeepSeek 則代表「用 MoE 架構把大模型塞進有限記憶體」的方向——它總參數很大，但每次只「活躍」一小部分，所以比同級直列模型省記憶體。

實際買硬體前，建議直接去 HuggingFace 看該模型的 VRAM 需求，對照你手上（或預算內）顯示卡的 VRAM。然後最近的硬體是真的貴……

地端部署的成本：硬體只是開始

選完硬體，很多人會忽略一件事：地端部署是「一次投入 + 持續支出」的模型，跟雲端 API 的「按量付費」完全不同。 比較之前，先把成本拆成四塊看。（以下價格與行情皆以 2026 年 8 月為例，之後請依當時行情調整。）

一、硬體成本（一次性）

2026 年的行情要特別注意：AI 資料中心搶走了大量 GDDR7 記憶體產能，顯示卡價格普遍比建議售價高很多，短期內看不到回落。目前大致行情（2026 年 8 月，美元價換算約 31 元台幣/美元）：

再往上看，伺服器等級的設備（如 A100、H100、H200 等）就更不用說了。 到了這個級別，單張就是幾十萬起跳，還要搭配機櫃、散熱、供電，一台 8 卡機器的硬體成本動輒百萬以上。這已經不是「買顯卡」，而是「蓋機房」。

每 GB 成本是比較不同配置最公平的尺。 你會發現兩極：二手 3090 是「每 GB 最便宜的 NVIDIA 顯卡」，DGX Spark 則是「每 GB 最便宜的 128GB 方案」——但它的記憶體頻寬遠低於獨立顯卡，速度會慢很多。便宜跟快速，不能同時拿到。

二、電力成本（持續）

顯示卡不關機就在耗電，功耗越高電費越高——消費級顯卡全開 24 小時，一個月幾千塊，一年下來累積起來不小；DGX Spark 功耗遠低於獨立顯卡，這一項幾乎可以忽略。不精算了，只要記得：長跑的話，電費會慢慢追上一張二手 3090 的價格。

三、隱藏成本

• 散熱與空間：500W 以上的顯示卡全速運轉，房間沒有適當散熱會很慘，機房化（隔音、排氣）又是一筆錢
• 維運：驅動更新、模型更新、服務監控，這些時間也是成本
• 折舊：顯卡技術更新快，三到五年後成本效益會被新一代產品取代

四、跟雲端 API 比，什麼時候地端划算？

沒有標準答案，取決於你的用量。最實用的估法是把 API 月費拆成一個公式：

月成本 ≈ 人數 × 每人每月 token 數 × 每百萬 token 價格 ÷ 100 萬

（token 數請代入實際數字，例如每人每月 500 萬 token 就代入 5,000,000。）

單位成本（2026 年 8 月實際行情）：開放權重模型 API 的價格已經很低。以幾款主流開放模型為例（依 31 元/美元換算）：

用最便宜的開放模型、NT$10/百萬 token 做保守估算（實際可能更低），情境如下：

你會看到一個跟直覺相反的事實：

• 月成本幾百到幾千（左邊兩格）：API 一年才幾千到一兩萬，買一張 5090（17 萬＋年電費約 1.5–2 萬）完全不划算，API 贏。
• 月成本到 1 萬（部門重度）：API 一年 12 萬，接近一張 5090 的價格，但還沒超過「硬體＋電費＋散熱＋維運」的總成本，仍在臨界點附近。
• 月成本到 10 萬（全公司高併發）：API 一年 120 萬，遠超任何單機配置，地端在成本上明確划算。

但這不是地端唯一的理由。 對多數中小團隊，純看成本 API 比較便宜。地端真正的殺手鐧是：

• 資料主權：客戶機密、法規文件、內部 SOP 從不離開你的機器
• 合規：金融、醫療、政府等產業對資料外洩零容忍，這不是成本問題
• 不受限：不怕 API 停服、漲價、改條款

一句話總結：小團隊用 API 省錢，大團隊用地端省錢＋保資料。你的資料是金礦，金礦該不該鎖在自己的地裡，跟花多少錢是兩個問題。

回到本業：把上一篇的知識庫真正跑起來

上一篇我們建好了知識庫，這篇把引擎裝好了。現在把兩件事接起來——對建築、營造、工程產業（AEC）來說，地端模型最實際的用法，就是讓你的 AI agent 直接讀那套知識庫：

• 條目即技能：知識庫裡每則知識都定義成 AI 可讀取的「技能」。把知識庫餵給地端模型，你就能直接問「防火區劃的門寬度限制是多少？」，模型會去查「容積計算」「防火區劃」這些技能條目，而不是憑空猜。
• RAG 就是串接點：前面講的 RAG（把資料向量化、存進向量資料庫），最自然的資料來源就是那套知識庫。條目越多、品質越高，模型回答越準——知識庫的厚度，直接決定地端 AI 的上限。
• 資料不出門：法規、客戶機密、內部 SOP，全都可以放在自己的機器上跑，這正是地端相對 API 最硬的優勢。

所以整個閉環是：業界貢獻知識 → 知識庫累積 → 地端模型 + RAG 把它變成立即可用的 AI → 再回饋更多實務。上一篇解決「燃料從哪來」，這篇解決「引擎怎麼轉」。

補充一點：如果你不想從零把 RAG、知識庫一個個接起來，我們自家的 HJPLUS Desktop Agent 也能直接搭配地端模型使用——其中 LITE 版本就提供了這套 AEC 開源知識庫的外掛可供下載使用，讓你把上面談的東西開箱即用，省去自己組裝的功夫。

結論：你的資料才是金礦，硬體是硬需求

說到底，語言模型本質上只是一個「推理單元」——它的角色是把你的知識和資料提取出來、整理好、拿去運作。

真正的金礦是你的資料。

模型再強，如果沒有你的領域知識、專案經驗、產業資料，它跑出來的東西就是空的。硬體（顯示卡、晶片）是硬需求，沒有它你連門都進不去；但進去之後，真正有價值的東西是你自己的知識資產。

而 Ollama、LM Studio、llama.cpp、vLLM 這些框架，就是幫你打通「硬體 → 模型 → 你的資料」這條路徑的工具。

評估一下你的需求、你的硬體、你的使用場景，選一個最適合自己、最好入手的環境開始。然後慢慢往上爬。