Self-Hosting

為什麼把翻譯模型搬回本機 沉浸式翻譯（Immersive Translate）這類瀏覽器擴充預設走雲端 API，品質夠用，但有三個煩人的地方：網路 round-trip 是延遲主因、開「網頁語言檢測」每開一個 tab 就燒掉上千 token、敏感內容也得送出去。 翻譯是少數很適合丟給小模型的任務——它不需要通用推理，只要把一段文字準確地搬到另一個語言。一顆 1~2B 的翻譯專用模型在 Apple Silicon 上就跑得飛快，延遲、成本、隱私三件事一次解決。 我原本用的是 Tencent 的 Hunyuan-MT v2 1.8B（Hy-MT2-1.8B Q4_K_M，量化後 1.13GB），搭 llama.cpp 跑在一台 16GB 的 M4 上。在 M4 16GB 上實測約 72 tok/s，日常網頁、技術文件、字幕都夠。但用久了會撞到它的天花板。 1.8B 的弱點：跟 7B 同句對照就現形 同系列除了 1.8B 還有一顆 7B（Hy-MT2-7B，Q4_K_M 量化後磁碟上約 4.3 GiB；HuggingFace 頁面標 4.62 GB，差在 GiB 與 GB 的進位——這篇剛好在講單位）。把同一句餵給兩顆，差距很直接。以下都是 M4 16GB 上的實測輸出，目標語言只給泛稱「Traditional Chinese」： 來源句 1.8B Q4（~72 tok/s） 7B Q4（~19 tok/s） The Transformer is the backbone of… …現代大型语言模型的核心组件 …現代大型語言模型的核心 エヴァンゲリオン初号機にシンジが… 希真登上 EVA 初号机出击 真嗣駕駛初號機出擊 …about 1.1 gigabytes 模型文件大小约为 1.1 吉字节 模型檔案的大小約為 1.1 GB 差距落在三類。人名與單位是硬傷：日文人名「シンジ（真嗣）」1.8B 翻成不存在的「希真」、單位 gigabytes 翻成「吉字节」沒保留 GB；7B 兩個都對。這類要模型記得住約定俗成的譯名，1.8B 容量不夠，換 prompt 也救不回來。 ...

為什麼要自建資訊流 每天早上打開手機，幾十個 tab、幾百則未讀。技術論壇、社群媒體、新聞源——每個都說自己很重要。花 30 分鐘刷完，真正有用的可能三條。 更糟的是，演算法幫你選的東西，跟你真正需要的東西，往往不是同一批。演算法優化的是你的停留時間，不是你的知識密度。 所以我想做的事很簡單：自己選來源、讓 AI 幫我篩重點、每天早上給我一份摘要。 不是讓 AI 取代我讀東西——是讓它幫我從 200 則裡挑出值得讀的 20 則，然後我自己決定要不要點進去看全文。 Pipeline 一：RSS 路線 RSS 是最乾淨的資訊來源。沒有演算法、沒有廣告、格式統一。大多數技術論壇和部落格都還支援 RSS，只是很多人忘了它的存在。 架構 自架 Tiny Tiny RSS（TTRSS），訂閱想追的 feed。TTRSS 有完整的 API，可以程式化操作一切。 流程長這樣： cron（每天早上） → shell script 呼叫 TTRSS API 抓未讀 → 餵給 AI agent 做分類摘要 → shell script 上傳靜態頁面 + 標記已讀 TTRSS API 操作 # 登入拿 session SID=$(curl -s -X POST "https://rss.example.com/api/" \ -H "Content-Type: application/json" \ -d '{"op":"login","user":"myuser","password":"mypass"}' \ | python3 -c "import json,sys; print(json.load(sys.stdin)['content']['session_id'])") # 抓未讀文章（最多 200 篇） curl -s -X POST "https://rss.example.com/api/" \ -H "Content-Type: application/json" \ -d "{\"op\":\"getHeadlines\",\"sid\":\"$SID\",\"feed_id\":2,\"view_mode\":\"unread\",\"limit\":200}" # 處理完後標記已讀 curl -s -X POST "https://rss.example.com/api/" \ -H "Content-Type: application/json" \ -d "{\"op\":\"catchupFeed\",\"sid\":\"$SID\",\"feed_id\":2}" API 回來的是 JSON，每篇有 title、link、excerpt。腳本把這些整理成一個大 prompt，丟給 AI agent 做摘要。 ...

為什麼要自己跑 TTS？ 市面上的 TTS API 不缺——ElevenLabs、OpenAI TTS、Azure Speech。但如果你想要的是用自己的聲音說話，而且不想每個月付錢、不想把錄音傳到別人的 server，那選擇就少很多了。 我的需求很簡單：讓我的 AI agent（跑在 OpenClaw 上）能用我的聲音回覆語音訊息。Agent 跑在 Oracle Cloud 的 ARM VPS 上，沒有 GPU。但家裡有一台 Windows 桌機，裝了 RTX 4070 Ti。 所以架構很明確：VPS 負責 agent 邏輯，Windows 桌機負責 GPU 推理，中間用 SSH tunnel 串起來。 聽起來簡單。實際上花了三代 TTS 模型、無數次 WSL 踩坑，才到今天穩定運作的狀態。 第一代：Fish Speech（2025 年底） Fish Speech 是最早嘗試的方案。它支援 voice cloning，品質不錯，社群也活躍。 部署在 WSL 上，port 8880，透過 autossh reverse tunnel 讓 VPS 能連到。一開始跑得還行，但遇到幾個問題： 模型更新頻繁，API 不太穩定 VRAM 吃得多，跟其他任務搶資源 後來有更好的選擇出現，就換了 Fish Speech 的功勞是：它驗證了整個架構是可行的——WoL 喚醒、WSL systemd、autossh tunnel、VPS 呼叫腳本這一整套 pipeline。後面換模型只需要改 server 端，其他都能重用。 ...