Immich：開源自架相簿，Google Photos 的自架替代方案

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

照片放在雲端相簿，換來的是開 App 就有的方便；代價是容量方案、壓縮政策與帳號決定權都在別人手上。Immich 走的是反方向：它把時間軸、智慧搜尋、人臉辨識、手機自動備份這整套體驗，搬進你自己管的伺服器，月費歸零，換來的是一台要你照顧的機器。這篇以實際跑起來的 v3.1.0 為準，把台灣使用者最常卡住的三件事講清楚：硬體要多少、中文智慧搜尋行不行、自架要扛什麼風險。

先給結論。Immich 在 GitHub 上有 113,470 顆星、6,814 次 fork，以 AGPL v3 開源，背後由 FUTO 這家公司僱用全職工程師維護，2026 年的穩定版大致維持一個月到一個多月一版的節奏，星數在自架相簿這個品類裡居於前列。它適合「想拿回照片主權、也願意養一台常開機器」的人；如果只是想找免費又不用動腦的備份空間，它不是為你設計的。下面是實測細節。

Pin

這筆交換也要把失去的算進去。雲端相簿順手就能用的 AI 修圖、一鍵去除路人、跨裝置零設定同步，在 Immich 這邊要自己想辦法或沒有對應功能；它給你的回報是照片的完整原件、不受壓縮政策影響的畫質，以及關掉伺服器對外連線時照片依然全部都在的篤定。願意用一點方便換這些，再往下看。

四個容器組成的相簿，架構先看懂

Immich 不是一支單檔程式。用官方 Docker Compose 檔部署時，它會拉起四個容器：負責網頁與 API 的 immich-server、負責 AI 推論的 immich-machine-learning、快取用的 valkey，以及一個裝了向量搜尋擴充的 PostgreSQL 14（VectorChord）。照片的智慧搜尋與人臉辨識，就建立在這個資料庫的向量能力上，這也是它對硬體比較挑剔的根源。四個容器各有各的映像檔，光是伺服器與機器學習兩個就合計 3.7GB，加上資料庫與其他映像，第一次部署的下載量會接近 5GB，事先把這個數字記進規劃裡。

手機端有官方的 iOS 與 Android App，設定精靈的行動應用程式步驟裡就有 Obtainium 設定工具的入口，照顧不放 Google Play 的 Android 使用者。網頁端從設定精靈到時間軸都是完整的繁體中文介面，這點我全程實測，沒有遇到半簡體夾雜的選單，側邊欄的「相片」「探索」「地圖」「共享」「媒體庫」都是道地的台灣用語。想先看看長相，官方提供 demo 站（demo.immich.app，帳號 [email protected]、密碼 demo），不用架任何東西就能按一圈。

實際跑一次 v3.1.0：映像檔就緒後二十秒上線

我在 macOS 的 Docker Desktop 上用官方 docker-compose.yml 把 v3.1.0 跑起來，環境變數只需要填上傳資料夾位置、資料庫密碼與版本標籤三類。映像檔下載完成後，四個容器到網頁回應 HTTP 200，中間只隔了約二十秒。要留意的是官方文件對這條路的立場：非 Linux 系統的 Docker 體驗被明確標為不推薦，遇到問題時官方能幫的程度有限，正式做法是裝在完整虛擬機裡。我這台跑得動，只代表它能在 macOS 上動，不代表這是官方建議的長期方案。

第一次啟動的設定精靈共七個步驟，依序是主題、語言、伺服器隱私、使用者隱私、儲存範本、備份與行動應用程式，全程繁中介面。隱私被放進設定精靈而不是埋在管理後台，看得出這個專案把「自己管資料」落成實際的產品設計。

上傳測試用的是六張 6016×6016 的 JPEG 原圖，合計約 38.8MB。從網頁上傳後，時間軸很快補上縮圖，統計數字顯示六張照片、38.8MB，與上傳量一致。上傳後的媒體資料夾會長出 thumbs、encoded-video、upload、profile、backups 幾個子目錄，縮圖、轉檔產物與原始檔各自歸位，這個結構對之後做備份指令碼的人很有用。

Pin

整體介面走的是大家熟悉的雲端相簿邏輯：中間時間軸、右側年份快速導覽、左側欄收納媒體庫與工具，左下角還有一個即時的伺服器狀態區塊與版本號。長期用 Google Photos 或 Apple 相簿的人，不需要重新學一套操作。

智慧搜尋的中英文落差：預設模型聽不懂「橘色」

Immich 的智慧搜尋在繁中介面裡叫「脈絡」搜尋，原理是用 CLIP 類模型把照片內容轉成向量，再拿文字查詢去比對，所以可以用「海邊的狗」這種自然語言找圖，不依賴檔名或地點標籤。這是它被拿來跟雲端相簿對比時最大的賣點之一，但中文使用者在預設值下會踩到一個坑。

搜尋除了脈絡比對，官方文件列出的可搜尋維度還包含：人物臉孔、檔名或副檔名、完整資料夾路徑、你手動寫的描述、照片裡的文字（OCR）、城市與國家、標籤、相機廠牌型號與鏡頭、時間區間、媒體類型，以及封存、收藏、星級這些狀態篩選，進階篩選可以把它們組成複合條件。找圖的細緻度不輸雲端相簿，前提是索引都跑完了。

實測方式很直接：對同一個六張照片的小圖庫下中英文查詢，看排序。查英文 orange 時，六張裡唯一整張橘色的圖被排在第一名；查中文「橘色」時，同一張圖被排到倒數第二，離正確答案很遠。換查「山」和「藍色」，排名同樣給不出能對應直覺的順序。原因在設定值：預設的 CLIP 模型是 ViT-B-32__openai，這是英文語料訓練的型號，中文查詢餵進去等於雞同鴨講，回傳的順序接近隨機。六張圖的小庫只能當方向性證據，還稱不上統計結論；但預設模型是英文型號這件事，是寫在系統設定裡的事實。

Pin

官方文件給了解法：到管理設定的機器學習頁，把智慧搜尋模型換成支援多語的 nllb、xlm 或 siglip2 系列，然後到工作狀態頁把整個圖庫的智慧搜尋工作重跑一遍。nllb 系列在單一語言的搜尋品質最好，適合主要用中文找圖的人，但它預期查詢語言要跟使用者設定一致；xlm 和 siglip2 不吃語言設定，中英混著查的人用這兩個系列比較順。代價是模型更大、索引更慢、記憶體吃更多，換完模型等於讓伺服器把整個圖庫重讀一次。換句話說，中文使用者架完 Immich 的第一件事，不是上傳照片，是先換模型。

人臉辨識用的則是 buffalo_l 模型，自動偵測並分組相似臉孔，可以在人物頁手動命名。這部分我只確認了模型設定值與功能存在，沒有用真人照片實測辨識品質，家庭用戶請把它當成有待驗證的期待。

官方 6GB 記憶體門檻，對上實測的資源帳面

官方需求頁寫的硬體條件是：記憶體最低 6GB、建議 8GB，處理器最低雙核、建議四核，amd64 與 arm64 都支援，儲存建議用支援使用者與群組權限的 Unix 檔案系統。另外從 v3 開始，機器學習容器在 x86 上要求 x86-64-v2 指令集等級，官方給的經驗值是 2012 年以後的 CPU 多半符合；真跑不動的話，最後一個支援舊指令集的版本停在 v2.7.5，且已不再維護。

這個門檻不是嚇人的。在我的六張照片小庫上，四個容器閒置時合計就吃掉約 2.8GB 記憶體：機器學習容器 1.47GB 是最大戶，伺服器本體約 889MB，PostgreSQL 約 439MB，valkey 只佔 8MB。照片一多、上傳與索引工作開始跑，數字只會往上疊，6GB 的最低標對應的是官方說的「上傳時的順暢體驗」，想一邊跑索引一邊做別的事，8GB 是比較安全的起點。記憶體只有 4GB 的機器，官方明講要關掉機器學習功能才跑得動，等於砍掉它最核心的差異化。

硬碟也要另外記帳。官方文件也提醒縮圖與影片轉檔平均會讓媒體庫膨脹一到兩成；我這次純照片的量測只增加約 2.5%（38.8MB 的原圖生出約 1MB 縮圖），因為沒有影片可轉，實際有影片的庫會更接近官方區間。更值得注意的是資料庫：六張照片的新鮮資料庫就佔了 315MB，向量搜尋擴充與基礎結構本身就是一筆固定開銷，官方也說這個資料庫在實際圖庫通常長到 1 至 3GB，必須放在本地 SSD，放網路硬碟會直接拖垮體驗。

機器放哪也有講究。NAS 與常開的小主機是最常見的選擇，重點是硬碟可換、可擴充，之後還能再加一顆做鏡像；拿雲端 VPS 架相簿就要三思，照片庫只會越長越大，儲存空間與上傳流量的帳單很快就會追過雲端相簿的月費，自架的省錢邏輯從頭到尾建立在「機器和硬碟是你自己的」這件事上。arm64 的單板電腦官方也支援，但合理預期智慧搜尋的索引時間會拉得很長，小記憶體的板子建議把 AI 功能關掉再上場。

功能面：時間軸之外，你還拿到這些

從官方功能對照表與實際介面整理，行動版與網頁版都支援的包含：多帳戶、共享相簿、RAW 檔瀏覽、中繼資料檢視（EXIF 與地圖）、以中繼資料與照片內容搜尋、人臉辨識分組、回憶（多年前的今天）、封存與收藏、堆疊照片、唯讀相簿與資料夾檢視。網頁版獨有的有 360 度全景瀏覽、標籤與管理功能；行動版獨有的是離線瀏覽與背景自動備份，App 開著就會把新照片送上自己的伺服器。iPhone 的 LivePhoto 可以原樣備份和播放，想另外把動態照片轉成影片檔，可以搭配 LivePhoto 轉影片的轉換工具一起用。

對攝影工作流程比較重要的兩項是外部圖庫與儲存範本。外部圖庫可以把既有的資料夾掛成唯讀圖庫，Immich 只讀不寫，你的原始檔案結構與既有備份流程不用改；儲存範本則用變數自訂新上傳檔案的存放路徑，例如按拍攝年月與相機型號分層，之後要把整個資料夾搬去別的軟體也看得懂。照片的地理位置會被反解成城市與國家，地圖頁以圖釘呈現整庫的拍攝足跡；對於想從照片裡的字幕或看板直接找圖的情境，它也內建 OCR 搜尋。有 API Keys 與 OAuth，命令列工具與第三方整合都有官方支援的入口，想自己寫腳本把照片同步進別的服務並不難。

自架的代價集中在這裡

先是更新紀律。v3.0.0 在 2026 年 7 月 2 日發布，棄用了舊的 pgvecto.rs 擴充改用 VectorChord，也首次引入候選版流程，讓願意嘗鮮的人先幫忙抓 bug；v3.1.0 在 7 月 29 日跟上，v3.2.0 的第三個候選版在 9 月 4 日已經出現。穩定版大致每月推進的專案，代表功能與修正在快速前進，也代表你的維運要跟上，管理設定裡可以切換穩定版與候選版頻道，但正式圖庫跟著候選版跑等於自願當測試員。官方升級文件的要求比較直接：先讀 release notes，動手前備份資料庫；在這種更新節奏下，先在測試環境驗證再動正式庫，算是自保的基本功。

再來是備份責任回到你身上。README 頂部用警告區塊提醒：務必遵守 3-2-1 備份原則，也就是至少三份副本、兩種不同媒介、其中一份放在異地。自架相簿最常見的悲劇劇本，是把 Immich 本身當成備份：單一機器上的單份照片，硬碟一壞就全部消失，機器學習模型救不了這件事。把媒體資料夾與資料庫一起排進既有備份排程，是安裝完成後最該優先做的事。

授權與商業模式也要讀懂。原始碼以 AGPL v3 開放，這個授權對「把改過的程式碼拿來提供網路服務」的場景有原始碼揭露義務，商用整合前建議先讀條款原文；公司化經營的代價是官網設有 product key 購買頁，用支持全職團隊的名義收費，個人自用與商業部署的界線，以官方條款頁的現行文字為準。若你的伺服器上已經有其他自架服務，例如 自架記帳工具或 自架筆記服務，把 Immich 放進同一台機器管理是很自然的下一步，但記得它的記憶體胃口比多數輕量自架服務大。

中文搜尋的額外功課前面提過，這裡再收攏一次：預設模型對中文查詢無效這件事，安裝過程不會提醒你，要自己換多語模型並重跑索引，這段時間機器會多忙一輪，記得挑機器沒在跑其他事的時段做。另外像照片地點的 AI 反查這類周邊玩法，可以參考 從照片反推拍攝位置的 AI 工具，和 Immich 的地圖功能是互補的應用。

誰該現在就裝，誰該先去 demo 站按一按

家裡有 NAS、小主機或一台願意裝 Linux 的閒置電腦，記憶體 8GB 以上，而且照片對你來說是需要長期持有的資產，這三個條件都成立的話，Immich 值得直接架。家庭情境特別合適：每個成員一個帳號，空間互相隔離，長輩用網頁版看回憶，年輕人用手機 App 自動備份，共享相簿把出遊照片收在同一處。攝影工作流程也吃得到紅利，RAW 直讀、外部圖庫唯讀掛載、儲存範本自訂路徑，都是為了不動你既有檔案結構而設計的。

反過來說，只想備份、不想碰 Docker 與更新，或者機器只有 4GB 記憶體，那就先去 demo 站玩一輪，等硬體或心理準備好再說。安裝本身不複雜：到 GitHub 的 immich-app/immich 下載當前版本的 docker-compose.yml 與環境變數範本，填好上傳路徑與資料庫密碼，docker compose up -d 之後瀏覽器開伺服器的 2283 埠就能進設定精靈。真正決定體驗的，是你在按下安裝之前有沒有想清楚：這台機器要放哪、備份怎麼做、中文搜尋模型要換哪一個。這些想清楚了，雲端相簿的月費就可以省下來了。