美國伺服器

01.08.2026

如何在美國伺服器上部署自有 AI 聊天助手和知識庫

你可以在一臺美國伺服器上自建私有環境，運行自有的AI 聊天助手。這種架構讓你對敏感檔案擁有完全控制權。你透過疊加 Docker 容器、Ollama 執行環境、向量索引器以及開源 Web 介面來搭建整體技術棧。此一體系讓聊天機器人智慧直接運行在本地硬體上。

關鍵優勢：你可以保護內部檔案，並消除依 token 計費成本。

建置私有知識庫，可以讓知識驅動的智能體在安全前提下檢索內部文件。你的 AI 智能體離線處理資料，無需外部 API。這個本地知識庫讓專有知識完全與外部隔離。

指標 / 情境	自建本地 LLM	基於 API 的 LLM	對比 / 優勢
低存取量（100 萬 tokens/日）	基礎設施成本高	顯著更加便宜	API 方案在成本上約便宜 733 倍
損益平衡點	約 110 億 tokens/月	約 110 億 tokens/月	達到此規模後，自建才開始更省錢
高峰延遲（美東時間下午 2 點）	延遲可預期 / 穩定	4.3 秒（尖峰）	自建部署可以規避高峰時段的延遲波動
低谷延遲（美東時間凌晨 3 點）	延遲可預期 / 穩定	0.8 秒	作為 API 的基線效能表現

你的自建 AI 聊天機器人可以在業務高峰期依舊保持穩定的回應時間，你也因此獲得對效能與隱私的完全掌控。

關鍵要點

自建 AI 聊天助手可以保護敏感檔案，並消除依 token 計費的 API 經常性成本。
本地伺服器在繁忙高峰期依然能提供穩定回應時間與可預期的效能。
合適的 GPU 硬體與 Docker 容器能讓你的自訂 AI 模型持續平穩運行。
本地向量資料庫讓 AI 在不洩漏企業資料的前提下搜尋內部文件。

美國伺服器環境與 AI 部署

在運行本地軟體之前，你需要在美國伺服器上準備好合適的實體硬體。合理的配置可以讓你完全掌控運算速度與系統隱私。

硬體規格與作業系統設定

你目標模型的參數規模將決定 GPU 顯示記憶體與整體系統硬體需求。模型愈大，就愈需要強勁的繪圖處理器來高效服務線上智能體。

模型規模	建議硬體
7B 模型	NVIDIA RTX 5060 Ti 16GB / RTX 4060 8GB
13B–34B 模型	AMD RX 9070 XT 16GB / NVIDIA RTX 5080 16GB
70B 模型	Mac Studio M4 Max 或 Mac Studio M3 Ultra 192GB

在 4 位元精度下運行 700 億參數模型，大約需要 40GB 顯示記憶體。你可以使用兩張 RTX 3090 顯示卡，或一張 A100 GPU。若僅用 CPU 執行，至少需要 64GB 記憶體，而 128GB 記憶體則能在複雜 AI 工作流程下提供更流暢的系統表現。請務必將 Linux 安裝在 NVMe 硬碟上，以加速文件知識檢索。

Docker 容器基礎設施搭建

💡 提示：容器可以將軟體相依關係清楚隔離，並簡化整體環境的安裝與管理。

你可以透過以下六個步驟，在 Ubuntu 上設定 Docker 與 GPU 支援：

使用 sudo apt-get remove -y docker docker-engine docker.io containerd runc 移除舊版本相關軟體套件。
使用 sudo apt-get update && sudo apt-get install -y docker-ce docker-ce-cli containerd.io 安裝 Docker。
透過 sudo usermod -aG docker $USER 將一般使用者加入 Docker 群組，並使用 newgrp docker 更新目前工作階段設定。
匯入 NVIDIA keyring，並在 /etc/apt/sources.list.d/nvidia-container-toolkit.list 中加入對應軟體來源。
使用 sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit 安裝加速工具。
透過 sudo nvidia-ctk runtime configure --runtime=docker 設定執行階段驅動，並使用 sudo systemctl restart docker 重新啟動服務。

接下來，要保護你的網路環境。為每位授權使用者啟用防火牆規則，阻擋未授權連線。設定 SSH 金鑰驗證並停用密碼登入。這些步驟可以保護你的本地 AI 引擎，使自訂智能體和智慧代理在查詢本地知識庫時不會洩露內部資料。

部署本地 AI 模型引擎

完成伺服器軟體部署後，你就可以在不暴露敏感檔案的前提下運行本地 AI 聊天機器人。你可以利用開源工具，將美國伺服器實例升級為私有推理引擎。

使用 Ollama 執行本地模型

Ollama 是在本地硬體上直接運行大型語言模型的核心引擎。你可以透過 Docker Compose 對整體服務棧進行優雅編排。

先決條件與 GPU 設定：在宿主環境中，透過 sudo apt-get install -y nvidia-container-toolkit 安裝 NVIDIA Container Toolkit，然後使用 sudo nvidia-ctk runtime configure --runtime=docker 將該執行階段註冊到容器守護行程中。
專案初始化：使用 git clone https://github.com/mythrantic/ollama-docker.git 下載設定儲存庫；再透過 cd ollama-docker 進入工作目錄。
在 docker-compose.yml 中定義服務：設定 ollama 容器服務，映像為 ollama/ollama:latest，並將宿主連接埠 11434:11434 進行對應。將資料目錄指向 ./model_files，並指定 run_ollama.sh 為主要入口腳本。將 Web 前端服務對應為 3000:8080，並設定 OLLAMA_API_BASE_URL=http://ollama:11434/api。
建立啟動腳本（model_files/run_ollama.sh）：使用 ollama serve & 啟動後端服務，再使用 ollama create finetuned_mistral -f model_files/Modelfile 和 ollama run finetuned_mistral 建置並運行自訂模型。
設定模型相依性（Modelfile）：透過 FROM ./mistral-7b-instruct-v0.1.Q2_K.gguf 將模型指向本地權重檔案。
部署與運行：使用 docker compose up -d 啟動標準 CPU 部署；如需啟用 GPU 加速，則透過 docker compose -f docker-compose-ollama-gpu.yaml up -d 啟動。隨後在瀏覽器中造訪 http://localhost:8080 進入介面。

💡 提示：合理調校環境變數可以最佳化顯示記憶體占用，並提升並發請求處理速度。

你可以透過在容器環境中設定專用環境變數來優化效能：

環境變數	類別	效能與記憶體影響
`OLLAMA_FLASH_ATTENTION`	GPU / 記憶體	為 CUDA 啟用 FlashAttention，加速長上下文處理並降低記憶體開銷。
`OLLAMA_KV_CACHE_TYPE`	記憶體最佳化	對 KV cache 進行量化（例如 `q8_0` 或 `q4_0`），可顯著降低顯示記憶體占用，並在結合 Flash Attention 時支援最多 2 倍上下文長度。
`OLLAMA_GPU_OVERHEAD`	顯示記憶體預留	為宿主作業系統或其他應用程式預留指定位元組數的顯示記憶體，防止 OOM 當機。
`OLLAMA_MAX_QUEUE`	佇列管理	限制並發待處理 API 請求數量，確保高峰期系統負載穩定。
`OLLAMA_NUM_PARALLEL`	並發控制	設定每個已載入模型允許的最大並行請求數。
`OLLAMA_MAX_LOADED_MODELS`	記憶體管理	控制可同時載入在記憶體中的模型數量上限。
`OLLAMA_KEEP_ALIVE`	記憶體保留	設定模型在被卸載前保持載入於記憶體中的時間長度。
`OLLAMA_CONTEXT_LENGTH`	記憶體限制	設定預設上下文視窗大小，直接影響每個會話的顯示記憶體分配。
`OMP_NUM_THREADS`	CPU 多執行緒	為多核心宿主系統指定平行執行所使用的 CPU 執行緒數。

合理設定後，你的 AI 智能體就能在不耗盡系統資源的前提下快速回應使用者請求。

用於離線查詢的模型選擇

選擇合適的模型架構，決定了你的知識驅動智能體在處理複雜文件時的表現。現代開源權重模型可以為本地知識庫提供出色的推理能力。

模型名稱	主要優勢與應用情境	上下文視窗	參數配置	授權條款
Gemma 4 26B A4B	高效本地文件分析、私有工作流程、輕量筆電端部署	256K tokens	總參數 25.2B（其中 3.8B 啟用）	Apache 2.0
Llama 4 Scout	超長上下文處理，適合法律文件、程式碼儲存庫、大型資料夾	10M tokens	109B 總參數 MoE（17B 啟用）	Llama 4 Community
Phi-4-reasoning	適合輕量本地推理、數學、理工科與程式輔助情境	標準上下文	基於 Phi-4 的推理微調版本	MIT
DeepSeek R1	適合離線高階推理（可透過蒸餾變體在一般硬體上運行）	128K tokens	671B MoE（37B 啟用）/ 蒸餾模型（1.5B–70B）	開源權重

底層模型的選擇會決定智能體如何從內部文件庫中解析與擷取資訊。你可以透過量化等方式調整模型參數，在文件準確度與顯示記憶體占用之間取得平衡。

量化等級	量化變體	記憶體 / 儲存占用	模型精度影響
8 位元	Q8_0	需要較高的儲存與記憶體占用	作為高保真基準，效能與精度非常接近 FP16
4 位元	Q4_1、Q4_K_S/M	顯著降低記憶體需求	以較小的精度犧牲換取更高的運行速度

部署 4 位元量化模型可以讓標準硬體運行高階自治智能體，同時不會顯著犧牲核心分析能力。自治智能體在本地處理文件上下文，整個過程無需將內容暴露給任何外部網路，從而確保企業內部知識完全在可控範圍內。

構建 AI 聊天助手與知識庫

將本地大型語言模型與專有檔案打通，可以構建一個智慧工作空間。你能夠搭建僅面向內部問題的私有知識庫，而不會洩露資料。自建系統可以把靜態檔案轉換為面向每位授權使用者的動態情境化回應。

文件匯入與向量嵌入

部署流程首先要把內部檔案轉化為數值表示。文件載入器從 PDF、Markdown 筆記、試算表等原始檔案中擷取文字。LangChain 與 Hugging Face 等框架可以將大型文件拆分為更小、更易檢索的文字區塊。

文字切分策略會直接影響系統的檢索速度。設定 20%–30% 的片段重疊比例，可以在分段邊界上保留必要的上下文。

切分方式	典型應用	建議片段大小	建議重疊範圍	檢索表現
語義切分	科研論文與知識庫	150–400 tokens	0–30 tokens	透過保持語義一致性，獲得最高的檢索相關度

💡 提示：將語義切分與視窗重疊結合使用，可以在檢索過程中降低幻覺風險。

在完成文字切分後，嵌入模型會將文字區塊轉換為數學向量。系統會將這些向量儲存到專用向量資料庫中。將向量資料庫部署在本地，可以在知識庫層面實現完整的網路隱私。

安全與合規面向	自建 / 本地向量儲存	雲端向量服務
資料控制與暴露	對資料位置、網路邊界與操作具完全掌控，消除外部資料外流途徑。	引入潛在的外部傳輸風險、被動雲端依賴與複雜設定需求。
合規框架契合度	透過將敏感資料嚴格保留在本地基礎設施中，更易滿足 GDPR、HIPAA、FedRAMP、GLBA、APRA 等嚴格監管要求。	需要持續合規審查、複雜合約安排以及大量核准流程。
稽核與地理邊界	透過清晰的實體 / 地理邊界，簡化合規稽核流程，方便監管機構判定。	需要複雜的法律與技術手段來滿足跨境傳輸限制。
風險隔離與負載分離	允許將高風險、強監管資料安全地留在本地，而將非敏感任務部署在其他環境。	如果沒有嚴格的管轄限制，所有工作負載都會同時承受公有雲基礎設施的風險。

選擇合適的向量引擎，需要在記憶體占用與檢索速度之間達成平衡。你的硬體規格會決定向量索引在處理高密度向量時的效率。

資料庫	記憶體效率與使用	索引速度與建置特性	RAG 與生產適配性
Qdrant	在 HNSW 索引下，100 萬條 768 維向量約需 1.4 GB 記憶體。	查詢效能快速（p95 延遲約 8ms），HNSW 索引建置時間也得到最佳化。	非常適合需要低延遲、高 QPS 的生產級 RAG 流水線。
pgvector	HNSW 索引相較 IVFFlat 需要 3–4 倍記憶體；記憶體有限時，IVFFlat 更合適。	HNSW 索引建置速度較慢，且記憶體開銷明顯高於 IVFFlat。	適合與 Postgres 深度整合的系統，但在索引建置時需要權衡記憶體與速度。
ChromaDB	暫無公開詳細的基準記憶體數據。	以本地行程方式運行，無需額外安裝設定，適於快速上手。	非常適合早期 RAG 原型開發，但缺乏生產運維能力（高可用、監控等）。

你可以透過自動化低程式碼工具簡化知識接入流程。將 n8n 或 Flowise 等編排器容器化，可以在不撰寫自訂程式碼的前提下，將文件收集工作流程與本地向量資料庫打通。

服務 / 工具	在容器中的角色	在文件處理與 AI 流程中的作用
n8n	主編排器	低程式碼自動化平臺，用於設計工作流程並連結整合的 AI 節點。
Flowise	AI 智能體建構器	用於構建複雜 AI 智能體，可由 n8n 觸發，或反向觸發 n8n 工作流程（`flowise.yourdomain.com`）。
Docling	文件解析器	將 PDF、DOCX、XLSX、圖片等多種格式轉為乾淨的 Markdown/JSON，可透過 REST API 整合進 n8n。
向量儲存（Qdrant/Weaviate）	知識儲存	儲存與檢索向量嵌入，用於 RAG（檢索增強生成）任務。
Ollama / LLMs	推理引擎	以本地或 API 方式提供語言模型，可直接在 n8n 或 Flowise 節點中設定呼叫。

基於 Docker 的封裝環境，為所有解析相依提供自洽的執行空間，提升可靠性。
預先構建的容器可以在本地基礎設施中打通業務自動化與自訂智能體。
專門的文件解析器可以在資料入庫前自動清洗原始內容。

這些自動化工作流程可以確保知識驅動智能體能夠即時索引新進企業文件。

搭建 Web 介面與使用者管理

現代 Web 介面可以為團隊成員提供直觀的對話體驗。Open WebUI 提供了類似 ChatGPT 的簡潔入口，同時仍然保持完整的使用者隱私。

你可以透過幾條簡單的 Docker 指令，將 Open WebUI 連接到本地容器環境：

部署情境	硬體 / 設定	Docker 指令
Ollama 運行在宿主機上	預設設定	`docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main`
Ollama 運行在宿主機上	Nvidia GPU 支援	`docker run -d -p 3000:8080 --gpus all --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:cuda`
Ollama 運行在外部伺服器	自訂 URL（`OLLAMA_BASE_URL`）	`docker run -d -p 3000:8080 -e OLLAMA_BASE_URL=https://example.com -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main`
整合 Ollama 容器	GPU 加速	`docker run -d -p 3000:8080 --gpus=all -v ollama:/root/.ollama -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama`
整合 Ollama 容器	僅 CPU	`docker run -d -p 3000:8080 -v ollama:/root/.ollama -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama`
連線故障排查	Host 網路模式	`docker run -d --network=host -v open-webui:/app/backend/data -e OLLAMA_BASE_URL=http://127.0.0.1:11434 --name open-webui --restart always ghcr.io/open-webui/open-webui:main`

當直接在宿主機上管理 Ollama 時，可以將 Docker 容器設定為透過 http://host.docker.internal:11434 這個端點與之通信。

Web 管理控制台為你的團隊環境提供了完善的存取控制能力：

基於角色的存取控制（RBAC）：為每個新使用者帳號分配不同的管理者或一般權限。
存取隔離：根據組織職責，為不同團隊授予僅限於其所屬知識庫索引的存取權。
自訂模型分配：將特定的專業智能體分配給對應部門，限制對全域模型的濫用。
互動式檢索測試：允許團隊成員直接與本地 AI 聊天助手對話，驗證文件檢索表現。

這個介面層讓你的私有伺服器基礎設施具備企業級 AI 聊天助手能力。使用者可以輕鬆查詢複雜的內部知識，同時整個敏感檔案體系仍由你完全掌控。透過部署專門的知識驅動智能體，你可以把原始企業資訊轉化為整個團隊隨時可用的 AI 服務台。自治 AI 智能體在本地處理內部搜尋請求，確保企業知識庫不會將機密資產暴露給公有雲環境。

安全網路設定與最佳化

設定 Nginx 反向代理與 SSL

在對外發布 Web 服務前，你必須先確保網路架構是安全的。Nginx 反向代理可以保護你的 AI 應用免於被外部直接存取。它負責處理所有對外 Web 請求，並安全地將其路由到本地智能體。大型語言模型在回應時往往以串流方式逐字輸出，時間可能較長。預設伺服器逾時設定可能會在長回應過程中中斷連線。因此，你需要調整特定逾時參數，以確保每位授權使用者的長連線穩定性。

設定指令	解決問題	預設值	推薦設定與作用
`proxy_read_timeout`	長回應時出現 504 Gateway Timeout	60 秒	設定為 `600s`（或更長），以延長讀取逾時時間，適應長時間推理；每收到新的資料區塊時，該計時器會被重置。
`proxy_send_timeout`	串流傳輸中途連線被重置	預設較短時間	適當增加該逾時時長，以保持用戶端連線存活，防止在慢速串流輸出時被過早中斷。

合理的代理設定可以在執行複雜內部知識庫查詢時，確保連線的穩定性。

針對美國路線的延遲最佳化

美國伺服器的實體位置會直接影響資料傳輸速度。為私有知識系統選擇合適的機房區域，可以顯著改善查詢效能。

美國伺服器區域	美國本土延遲表現	跨大西洋 / 海外影響	建議使用族群
美國東部（NY, NJ）	東岸傳輸表現出色（至 DC 約 15–25ms）；到西岸延遲一般（60–75ms）	由於直連跨大西洋光纖，對歐洲存取延遲較低	面向美國東部或同時服務美東與歐洲使用者的企業
美國中部（芝加哥、達拉斯）	對美國各區域提供較平衡的全境延遲表現	芝加哥是北美重要的跨大西洋光纖樞紐，有利於降低歐洲存取延遲	面向全美、無明顯區域流量傾斜的全國性應用
美國西部（洛杉磯、矽谷）	本地區存取延遲極佳；到美國東部延遲一般（60–75ms）	為環太平洋地區提供最佳的跨太平洋光纖路由（對歐洲相對不利）	面向美國西岸與環太平洋使用者的業務

你可以採用以下關鍵網路路由策略來提升傳輸效能：

地理距離與光纖樞紐：芝加哥是北美跨大西洋海底光纜的核心樞紐之一，因此相較於內陸城市（例如 Roswell），對歐洲的延遲更低。
基礎設施接入：沿主幹光纖通道部署伺服器，可以減少歐洲請求的中間跳數，相較於遠離東岸登陸點的南部內陸地區，延遲更具優勢。
邊緣運算：在靠近終端使用者的區域部署推理節點，可以縮短實體傳輸距離與往返時間（RTT），對於即時應用，回應速度最多可提升約 50%。
現代資料傳輸協定：使用 gRPC、HTTP/2 等現代協定取代傳統 HTTP，可以降低網路開銷，將回應時間提升約 30%。

透過這些部署與路由策略，你的自治智能體可以快速查詢內部知識引擎，並以較高精度將領域知識回傳給第一線團隊，同時持續保護企業知識資產。
至此，你已經在伺服器上掌控了一套完整的本地部署架構。你將 AI 聊天助手與本地向量儲存結合在一起，使 AI 智能體可以在不依賴第三方的情況下處理使用者查詢，並高效分析本地檔案。

💡 提示：請定期為向量庫執行備份，以便在系統升級期間保護索引紀錄。

你可以透過增加更多自動化工作流程來擴展這套系統。同時，後續也可以升級硬體配置，以運行更大參數規模的智能體，並持續擴充中央知識庫。

成本維度	自建 AI 知識庫	託管雲端 LLM 平臺
主要成本來源	前期硬體採購與持續的電力消耗	依 token 計費的 API 使用成本
邊際單次查詢成本	極低（主要是電力消耗）	每處理一個 token 都會產生持續費用
預估月度開支	數百美元（主要為電費）	對於重度請求情境，可能每月需 1 萬至 5 萬美元甚至更高