Pocket 在 2025 年熄燈之後，Karakeep 用本地 LLM 接手了閱讀清單這個位置

Mozilla 在 2025 年 5 月宣告關閉 Pocket，7 月正式停服，11 月把所有使用者資料連同伺服器一起銷毀。這個被收購十年、內建在 Firefox 裡的閱讀清單服務，從此走進歷史。對長期把文章丟進去「之後再讀」的人來說，Pocket 留下的空缺意外地難填——商業替代品要綁帳號，免費版動輒上限封頂；既有的自架選項 Wallabag 介面老派，AI 功能薄弱。

直到 Karakeep 把這件事重新定義。它的前身是 2024 年走紅的 Hoarder，今年初改名重整之後，把書籤管理、AI 自動分類、全文檢索、瀏覽器擴充與行動 App 整套打包，GitHub 星數半年內突破三萬。對於想擺脫 SaaS、又不願意放棄智慧型功能的使用者，這套自架書籤系統補上了長期缺席的那一塊。

不只是書籤，是一個會自己歸檔的數位倉庫

Karakeep 的定位比傳統閱讀清單更廣。除了存連結，它同時支援純文字筆記、圖片、PDF 三種主要型態，每一筆都會經過後台 worker 處理：抓取網頁原文、用 monolith 把完整頁面封存成單一 HTML、用 yt-dlp 把 YouTube 影片下載備份、用 Tesseract 對圖片做 OCR。原始來源網站關站了也不影響資料。

抓回來的內容會丟進 Meilisearch 做全文索引。輸入幾個關鍵字就能跨連結、筆記、PDF 一起搜，速度比想像中快——Meilisearch 在這個資料量級下單核心就能撐住每秒上百筆查詢。

對 RSS 玩家而言還有一個亮點：訂閱來源後 Karakeep 會自動把每篇新文章加進清單，整套變成「個人化的長期保存型 RSS 閱讀器」。這跟 Pocket 過去單純存連結的模式已經是兩種產品。

AI 自動標籤把整理這件事從手動變成自動

Karakeep 最有辨識度的功能是 LLM 自動分類。每一筆新書籤進來，後台會把抓到的網頁內文送進設定好的語言模型，要求它產出三到五個語意相關的標籤，再附上一段不超過兩百字的摘要。

支援的後端不限於 OpenAI。設定 OPENAI_BASE_URL 與 OPENAI_API_KEY 兩個環境變數就能改指向任何 OpenAI 相容介面，這代表 Ollama、vLLM、LM Studio、甚至自架的 LiteLLM proxy 都能直接接上。在 VPS 上跑一個 7B 等級的開源模型（Llama 3、Qwen 2.5、Mistral），分類品質已經夠用，每筆書籤的成本是零。

實務上有兩個值得注意的細節。一是模型不需要很大：tagging 任務對推理品質的要求遠低於對話，3B 到 8B 的模型表現足夠，硬塞 70B 反而讓單筆處理時間從幾秒變成幾十秒。二是 tagging 與 summary 可以分開設定不同模型，常見組合是用小模型做標籤、用大一點的做摘要，整體吞吐量更高。

若手邊沒有 GPU 而 CPU 又跑不動 LLM，把 tagging 流量導向 OpenAI 也是務實選擇。粗估每千筆書籤的 API 成本不到一美元，遠低於把整套 LLM 自己撐起來的硬體投入。

服務拆分：四到六個容器組成的後台

Karakeep 不是單體應用，docker-compose 一拉起來會跑出幾個獨立容器，各自負責不同職責：

web：Next.js 前端與 tRPC API，使用者點到的所有介面都從這裡來。
workers：背景處理佇列，所有抓取、OCR、AI 標籤、影片下載都在這層完成，是整套系統最吃資源的部分。
meilisearch：全文搜尋引擎，獨立常駐。
chrome 或 browserless：無頭瀏覽器，負責渲染 JavaScript 站台與封存頁面。
可選的 ollama：本地 LLM 推論，若使用雲端 API 則不需要。

最低資源建議是 2 vCPU、4 GB 記憶體。若同時啟用本地 LLM，至少要拉到 4 vCPU、8 GB；想跑 GPU 推論的話另外掛一張入門卡也夠用。儲存方面，Karakeep 會把每筆書籤的 HTML 快照與圖片存進磁碟，重度使用者每萬筆書籤大約佔用 10 到 20 GB，視是否啟用影片封存而定。

一份能直接動的 docker-compose

官方 repo 提供完整範例，實際部署可以濃縮成這樣的骨架：

services:
  web:
    image: ghcr.io/karakeep-app/karakeep:release
    restart: unless-stopped
    volumes:
      - data:/data
    environment:
      MEILI_ADDR: http://meilisearch:7700
      BROWSER_WEB_URL: http://chrome:9222
      OLLAMA_BASE_URL: http://ollama:11434
      INFERENCE_TEXT_MODEL: qwen2.5:7b
      DATA_DIR: /data
    ports:
      - "3000:3000"

  chrome:
    image: gcr.io/zenika-hub/alpine-chrome:123
    restart: unless-stopped
    command:
      - --no-sandbox
      - --remote-debugging-address=0.0.0.0
      - --remote-debugging-port=9222
      - --hide-scrollbars

  meilisearch:
    image: getmeili/meilisearch:v1.13
    restart: unless-stopped
    environment:
      MEILI_NO_ANALYTICS: "true"
    volumes:
      - meili_data:/meili_data

volumes:
  data:
  meili_data:

外層通常套一層 Caddy 或 Nginx Proxy Manager 處理 HTTPS。授權設定建議走 OIDC：Karakeep 支援 Authentik、Pocket ID、Authelia 等任何 OIDC 提供者，這比預設的內建帳號好管理。

NEXTAUTH_SECRET 與 MEILI_MASTER_KEY 千萬不要用範例值，用 openssl rand -base64 36 各產一組塞進去。生產環境還要把 web 的 port 從 host 拿掉，只透過反向代理對外。

整理舊資料：從 Pocket 匯出到 Karakeep 的路徑

Mozilla 在關站前提供了完整的匯出機制，使用者可以下載一份 HTML 格式的 Pocket 書籤檔。Karakeep 內建解析這個格式的功能，從設定頁進入「Import / Export」上傳就好，標籤與 archive 狀態都會保留。

匯入完還有一個有趣的玩法：對所有舊書籤強制重新跑一次 AI 標籤。Pocket 多年累積的資料往往沒分類或標籤亂七八糟，跑完 LLM 之後整套會被重新組織得很清爽。這個操作在 worker queue 會排隊跑很久，視書籤數量可能要幾小時到一兩天，安排在離峰時段比較不會卡到日常使用。

自架的代價值不值得

Karakeep 把 Pocket 十年來做的事情重做一次，再加上 AI 與資料主權，問題是這份體驗的維護成本誰扛。

明顯的優勢有三點：資料完全在自己手上、AI 標籤可以選擇不出境、長期成本比商業方案低很多。代價也清楚——每月要花時間更新容器、處理 Meilisearch 偶爾出現的 index 失敗、注意 worker queue 是否塞車。對於每天會用到的工具來說，這份維護心力通常值得；對於一年點開兩次的服務則未必。

另一個常被低估的成本是頻寬。Karakeep 預設會把每個網頁完整封存下來，外加圖片和影片，重度使用者一個月吃掉幾十 GB 流量並不誇張。VPS 的傳輸量計算要事先看清楚，避免月底超量。

選 VPS 時建議優先看記憶體與磁碟，CPU 反而不是瓶頸——除非要在同一台跑本地 LLM。NVMe SSD 對 Meilisearch 的索引建立速度差異明顯，普通 SATA SSD 在書籤過萬之後會感受到搜尋變慢。

結語與下一步

Pocket 的退場讓自架書籤管理從「技術愛好者的玩具」變成正常人也該考慮的選項。Karakeep 在這個時間點補上 AI 自動化與行動端體驗，把過去自架方案最弱的兩個環節同時解決，幾乎是目前唯一能直接對標 SaaS 的選擇。

要把 Karakeep 跑得穩，底層 VPS 的選型比想像中重要。NCSE Network 提供位於臺灣是方電訊機房的 VPS，採用 Intel Gold CPU、NVMe SSD，IPv4 與 IPv6 雙堆疊，網路出口直連多家上游，適合需要長期保存資料又重視低延遲存取的自架應用。前往 ncse.tw 了解方案細節，把閱讀清單真正搬回自己的伺服器。