by Rain Chu | 9 月 14, 2026 | AI, QWEN, TTS, 虛擬人, 語音合成, 語音辨識
把 AI 對話、即時語音和會動的人像放在同一台電腦上,現在已經可以做出一套不依賴雲端 API 的互動數位人,用 faster-whisper 聽懂麥克風,讓 Qwen3 產生回答,再交給 Qwen3-TTS 合成聲音,最後由 LiveTalking 完成口型同步與 WebRTC 串流。
先講我的結論。這套方案的價值是隱私、角色控制與離線能力,不是安裝後完全沒有成本。模型權重下載完成後確實不需要按次支付 API 費用,但顯卡、記憶體、硬碟、電力與維護時間仍然是成本,所謂 8GB 顯存能跑,也必須以較小的 LLM、量化權重和分階段載入為前提.若想讓 14B LLM、Whisper large-v3、1.7B TTS 與口型模型同時常駐,16GB 顯存仍可能不夠。
整套本地 AI 數位人怎麼運作
這不是單一模型,而是一條由五個服務組成的即時管線。
- VAD 判斷使用者何時開始與停止說話
- faster-whisper 把麥克風聲音轉成文字
- Qwen3 與 llama.cpp 根據角色設定產生回答
- Qwen3-TTS 把回答轉成指定音色的語音
- LiveTalking 接收音訊並驅動嘴型,再透過 WebRTC 顯示互動人像
這種模組化做法和我之前整理的 Hugging Face speech-to-speech 本地即時語音 Agent 是同一條思路。每一層都能替換,但每一層也有自己的模型、連接埠與執行環境。LiveTalking 不會自動知道 Qwen3-TTS 在哪裡,兩者中間仍需要官方支援的 TTS 外掛,或一個把生成音訊送到 /humanaudio 的橋接程式。
先算顯存,不要先相信 8GB 宣傳
| 元件 | RTX 4090 範例占用 | 低顯存調整 |
|---|
| Qwen3-14B Q4_K_M | 約 9GB | 改用 8B 或 4B 的 Q4_K_M |
| faster-whisper large-v3 | 約 3GB | 改用 medium,準確度會有取捨 |
| Qwen3-TTS 1.7B | 約 4GB | 改用 0.6B 或依序載入服務 |
| Wav2Lip 256 | 約 1.3GB | 降低批次並避免其他 GPU 程式常駐 |
這是 RTX 4090 整合環境的估計值,不同量化、上下文長度與 CUDA 版本都會改變結果
四個元件加起來約 17.3GB,還沒算 CUDA context、瀏覽器與暫存空間。16GB 顯卡跑到 99% 甚至整台機器失去回應,並不意外。6GB 顯存可以先用 Qwen3-4B 的 GGUF 量化版,並把語音辨識改成 medium。8GB 到 12GB 則適合 Qwen3-8B 搭配較小 TTS,或讓部分元件使用 CPU。若想了解 GGUF、llama.cpp 與 Ollama 的取捨,可以先看 本地大模型推理框架比較。
第一步,在 Windows 準備 WSL 2
這套整合方式把 llama.cpp 放在 Windows,語音與數位人服務放在 Ubuntu 24.04 的 WSL 2。先用系統管理員身分開啟 PowerShell。
wsl --update
wsl --install -d Ubuntu-24.04
Windows 使用者目錄的 .wslconfig 可以設定記憶體與鏡像網路。32GB 是範例,請依實際 RAM 調整,不要把主機記憶體全部交給 WSL。
[wsl2]
memory=32GB
networkingMode=mirrored
[experimental]
hostAddressLoopback=true
修改後重啟 WSL。
wsl --shutdown
進入 Ubuntu 後先用 nvidia-smi 檢查 GPU。NVIDIA 的 Linux 驅動不要再裝進 WSL,CUDA passthrough 由 Windows 顯示卡驅動提供。AMD 顯卡不能照搬這套 CUDA 整合包,需要改走 ROCm 支援的元件,或把無法使用 ROCm 的部分移到 CPU。
專案最好放在 Linux 家目錄,不要直接在 /mnt/c 執行。這能避開 I/O 速度、權限與換行格式問題。
mkdir -p ~/setup
cp -r "/mnt/c/Users/YOUR_NAME/Desktop/AI/." ~/setup/
cd ~/setup
sudo apt update
sudo apt install -y ffmpeg dos2unix python3-venv
dos2unix *.sh
chmod +x *.sh
第二步,用 llama.cpp 啟動 Qwen3
llama.cpp 提供 OpenAI 相容 HTTP 服務,語音管線不必知道底層跑的是 GGUF。16GB 以上可以從 Qwen3-14B 的 Q4_K_M 開始,8GB 到 12GB 建議改成 8B,4GB 到 6GB 則從 4B 測試。
llama-server -m E:\llama.cpp\models\Qwen3-14B-Instruct-Q4_K_M.gguf ^
-np 1 -c 8192 -fa on --temp 1.0 --top-p 0.95 ^
--host 0.0.0.0 --port 8090
新版 llama.cpp 文件也開始使用 llama serve 名稱,實際命令要以下載版本為準。Windows 的 8080 有時落在 Hyper-V 保留範圍,所以範例改用 8090。若服務無法綁定,可以先檢查保留埠。
netsh interface ipv4 show excludedportrange protocol=tcp
第三步,安裝即時語音管線
Hugging Face 官方 speech-to-speech 現在以 serve、talk 和 local 為主要命令,舊資料裡的 --mode 已經淘汰。先建立獨立環境,再安裝 faster-whisper 額外依賴。
python3 -m venv ~/venvs/s2s
source ~/venvs/s2s/bin/activate
python -m pip install --upgrade pip
pip install "speech-to-speech[faster-whisper]"
以下範例把 LLM 指向 Windows 上的 llama.cpp。不同版本的 STT 參數名稱可能調整,正式啟動前先執行 speech-to-speech serve --help 對照目前安裝版本。
speech-to-speech serve \
--stt faster-whisper \
--stt_model_name large-v3 \
--language zh \
--llm_backend responses-api \
--tts qwen3 \
--model_name Qwen3-14B-Instruct-Q4_K_M \
--responses_api_base_url http://127.0.0.1:8090/v1 \
--responses_api_api_key "" \
--responses_api_stream \
--enable_live_transcription
模型全部下載完成後,可以設定 HF_HUB_OFFLINE=1 驗證斷網狀態。這一步比口頭宣稱本地化更可靠,因為只要還有任一個後端指向雲端,就不算完整離線。
第四步,準備 Qwen3-TTS 與參考聲音
Qwen3-TTS 官方最簡單的安裝方式是獨立建立 Python 3.12 環境。它支援聲音克隆、音色設計與串流輸出。更多模型差異和 ComfyUI 節點用法,可以延伸看 Qwen3-TTS 音色設計整理。
conda create -n qwen3-tts python=3.12 -y
conda activate qwen3-tts
pip install -U qwen-tts
參考音訊建議控制在 5 到 15 秒,只留單一說話人,沒有音樂與明顯環境聲。參考文字必須和音訊實際內容完全相同,否則容易出現漏字、錯字與音色漂移。情緒也會一起被模仿,所以不要用過度激動的片段當作一般對話基準。
ffmpeg -i ~/setup/ref.wav -ac 1 -ar 16000 -c:a pcm_s16le ~/s2s/ref.wav
ffprobe -v error -show_entries stream=sample_rate,channels,codec_name \
-show_entries format=duration -of default=nw=1 ~/s2s/ref.wav
只應克隆自己或已取得明確授權的聲音。把真人聲紋放入公開服務前,也要考慮檔案存取權限、提示注入與未授權冒用。
第五步,製作自然的待機人像
人像素材不適合直接使用張嘴、手擋住嘴巴或劇烈轉頭的畫面。先生成嘴唇閉合、正面或微側面的基準圖,再用 Wan2.2 圖生影片做五秒左右的待機動作。提示詞只描述動作,不要重新描述人物外觀,能減少五官漂移。
電影感 16 比 9 構圖,一位成年東亞女性位於畫面右側三分之一,深色安靜房間,左側保留大量空間,螢幕冷光照亮臉部,輪廓帶柔和暖光,嘴唇自然閉合,雙手不遮擋嘴部,自然皮膚紋理,淺景深,真實攝影質感
負面提示詞
張嘴,說話,露齒,正面平光,明亮背景,過高對比,過度曝光,人物置中,多人,手遮擋嘴部,文字,浮水印,塑膠皮膚,過度修圖,卡通,3D 渲染
待機動畫提示詞
人物保持坐姿,只有細微自然呼吸,緩慢眨眼一次,頭部輕微移動後回到原位,嘴唇全程閉合,鏡頭完全鎖定,沒有縮放,沒有切鏡
關閉自動提示詞增強,輸出比例盡量和原圖相同。Wan2.2 常見原生片段是 81 幀、16 FPS,約五秒。若要二十秒待機,不要期待模型一次生成毫無漂移的長鏡頭,可以在自然停頓點循環短片。其他數位人生成思路可參考 LongCat 數位人工作流。
第六步,安裝 LiveTalking
LiveTalking 官方目前測試的環境是 Ubuntu 24.04、Python 3.12、PyTorch 2.9.1 與 CUDA 12.8。下面命令照官方版本撰寫,但 PyTorch 下載來源仍應配合自己的 CUDA 驅動,不要盲目安裝 cu128。
git clone https://github.com/lipku/LiveTalking.git
cd LiveTalking
conda create -n livetalking python=3.12 -y
conda activate livetalking
pip install torch==2.9.1 torchvision==0.24.1 torchaudio==2.9.1 \
--index-url https://download.pytorch.org/whl/cu128
pip install -r requirements.txt
下載官方提供的 wav2lip256.pth 後,把它放到 models,並改名成 wav2lip.pth。範例角色資料夾則解壓到 data/avatars。完成後啟動 WebRTC 服務。
python app.py --transport webrtc --model wav2lip \
--avatar_id wav2lip256_avatar1 \
--stun 'stun:stun.l.google.com:19302'
瀏覽器開啟 http://localhost:8010/index.html,按下開始連線。正式讓外部裝置使用時,官方提醒需要 TCP 8010 和 WebRTC 使用的 UDP 連接埠。不要直接把整段 UDP 範圍暴露到公網,應優先放在可信任區網、VPN 或經過限制的防火牆環境。
自己製作 Wav2Lip 角色時,可以把短影片轉成 avatar 資料。素材要維持正面可見、光線穩定與嘴部清楚。
python avatars/wav2lip/genavatar.py \
--video_path data/video/avatar.mp4 \
--img_size 256 \
--avatar_id my_avatar
第七步,正確啟動與串接
我會把服務拆成四個終端視窗,照下面順序啟動。每一步都先確認健康狀態,再開下一個服務。
- Windows 啟動 llama.cpp,確認
http://127.0.0.1:8090/v1/models 有回應
- WSL 啟動 Qwen3-TTS 或 speech-to-speech,先完成單句語音測試
- WSL 啟動 LiveTalking,確認 8010 網頁能顯示待機角色
- 最後啟動橋接程式,把 TTS 產生的音訊送入 LiveTalking 的
/humanaudio
作者提供的一鍵整合包包含自訂腳本與橋接程式,並不是 Hugging Face、Qwen 或 LiveTalking 的官方發行版。下載前應先檢查檔案來源、雜湊值、啟動腳本和網路連線,不要把未知執行檔直接放進主要工作電腦。想要長期維護,我更建議從官方專案建立環境,再自行補一個最小橋接層。
WebSocket failed 怎麼排查
- 先確認服務真的啟動。7860、8010 與 8090 是不同服務,瀏覽器頁面存在不代表後端 WebSocket 已連線
- 檢查 WSL 網路。修改
.wslconfig 後一定要執行 wsl --shutdown,鏡像網路與 hostAddressLoopback 才會重新載入
- 確認 Windows 防火牆。先只開必要 TCP 埠,在同一台電腦測通後再處理區網
- 不要混用 localhost。容器、WSL 與 Windows 各自看到的
127.0.0.1 可能不是同一個服務
- 確認瀏覽器麥克風權限。遠端網頁通常需要 HTTPS 或 localhost 才能取得安全的麥克風權限
- 降低 Noise Gate。如果網頁已連線但偵測不到聲音,先關閉門檻測試,再逐步調高
- 調整 VAD 停頓。約 900 到 1200 毫秒比較不容易搶話,但設定越長,回答開始時間也越慢
可以改成真正的 3D 角色嗎
可以,但不是把 Wav2Lip 模型換成一個 3D 檔案就完成。現在這條路線以 2D 影像或待機影片為基礎,口型模型直接修改臉部像素。真正的 3D 角色需要另外加入 Unity、Unreal Engine 或 WebGL renderer,再把 TTS 音訊轉成 viseme、音素或 blendshape 權重,驅動角色的嘴型、表情、眼神與骨架。
保留 VAD、Whisper、Qwen3 與 Qwen3-TTS,替換最後一層即可。新的輸出流程會變成 TTS 音訊、音素時間軸、3D blendshape、即時 renderer。若只是想讓角色有更豐富動作,可以先使用 LiveTalking 的自訂動作設定或多段待機素材,成本會比完整 3D 低很多。
本地不等於沒有風險
角色資料、聲音與對話都留在本機,確實能降低資料送往雲端的風險。但只要把服務開到區網或公網,就要重新考慮驗證、連接埠、惡意音訊、提示注入與檔案上傳。對話記憶也不是安裝完成就會永久存在,長期記憶需要另外接資料庫、摘要或向量檢索,否則聊天變長後仍可能忘記前文或開始胡亂延伸。
LiveTalking 官方也明確要求,使用此專案製作並發布到平台的內容必須包含 LiveTalking 浮水印與標誌。正式商用前要再確認每個模型、角色素材、聲音和整合程式的授權,不要只看程式能不能跑。
官方資源與參考資料
FAQ
8GB 顯存真的可以跑本地 AI 數位人嗎
可以做出可用版本,但不適合讓 14B LLM、large-v3、1.7B TTS 與口型模型全部以高規格同時常駐。建議改用 Qwen3-8B 或 4B 量化版、較小 TTS、較低 batch,必要時把部分模型放到 CPU。
可以完全離線,不使用任何 API 嗎
可以。前提是 STT、LLM、TTS 和數位人全部使用本地後端,而且模型與依賴已下載完成。設定 HF_HUB_OFFLINE=1 並在斷網環境測試,才能確認沒有隱藏的雲端依賴。
可以用英文或其他語言聊天嗎
可以,但 STT、LLM 與 TTS 三層都要支援目標語言。Whisper 與 Qwen3 的多語能力較完整,最終自然度通常由 TTS 音色與參考音訊決定。中英混合時要額外測試專有名詞、數字與語速。
Mac 可以照這篇安裝嗎
不能原封不動照做,因為本文整合路線依賴 Windows、WSL 與 CUDA。llama.cpp、Whisper 和部分 speech-to-speech 元件可以改走 Apple Silicon 的 Metal 或 MLX,但 LiveTalking 口型模型與整合腳本需要另外確認 macOS 支援,不能直接套用 NVIDIA 命令。
最後怎麼選
如果只是想快速聊天,雲端語音助手會更省時間。如果需求是讓私人對話留在本機、建立固定角色、接自己的資料或研究數位人介面,這套模組化管線就很值得做。我的建議是先讓文字對話跑通,再加入 STT 和 TTS,最後才接 LiveTalking。一次啟動所有元件,只會讓錯誤來源變得難以判斷。
真正值得學會的不是某個一鍵包,而是知道聲音在哪裡變成文字,回答在哪裡生成,音色在哪裡被控制,口型又由哪一個服務驅動。把這五層拆清楚後,未來換模型、換角色、換前端,整套系統仍然能繼續使用。
by Rain Chu | 9 月 11, 2026 | AI, skills
fal.ai 是一個生成式媒體 API 平台,它把多家圖片、影片、音訊與 3D 模型放在同一套介面下,開發者不必為每一家服務分別串接帳號與 SDK。再把操作規則包成 Codex Skill,就能讓 Codex 根據任務選模型、整理提示詞、上傳參考圖、送出工作、追蹤結果,最後把檔案下載到專案資料夾。
這套方式真正省下的是固定訂閱與切換工具的時間,不是讓付費模型突然變成免費。fal.ai 採預付點數與按量計費,圖片可能依張數或百萬像素計價,影片常依秒數、解析度或單次輸出計價。對偶爾生成、需要跨模型比較的人很有彈性,長期大量生成前則一定要先算成本。
先講結論,fal.ai 適合什麼人
| 做法 | 適合情況 | 優點 | 要注意什麼 |
|---|
| fal.ai Playground | 偶爾做一兩張圖或測模型 | 不用先寫程式,直接調參數 | 重複任務仍要手動操作 |
| fal.ai 加 Codex Skill | 固定工作流、批次產出、專案整合 | 能保存規則、命名、目錄與成本檢查 | 需要 API 點數與基本設定 |
| 單一平台訂閱 | 高度依賴固定工具與固定模型 | 介面完整,方案可能含較高用量 | 不用時仍可能支付月費 |
| 本地 ComfyUI | 生成量大、重視隱私、已有顯卡 | 沒有每次 API 費用,控制度高 | 需要顯存、硬碟與維護經驗 |
如果每個月只做少量成品,又想在 Nano Banana、GPT Image、Seedance、Kling、MiniMax 等模型之間切換,按量付費通常比同時維持多個訂閱直覺。若每天大量產圖,或素材不能離開本機,則可以先看 Krea2 與 ComfyUI 圖像編輯工作流,影片生成也可參考 LTX 2.3 本地部署教學。
Skill 的價值不是多一個聊天指令
Skill 可以把一套反覆使用的製作規則交給 Codex。它不只是記住「呼叫 fal.ai」,而是先判斷這次是文字生圖、圖片編輯、文字生影片或圖生影片,再選對端點與參數。不同操作通常有不同的模型 ID,文字生圖與圖片編輯即使使用同一模型,也不能假設共用同一個端點。
- 讀取
參考圖 資料夾,辨認可用素材與用途
- 先擴寫提示詞,再讓使用者確認內容與預估費用
- 依圖片、影片、編輯或動畫需求選擇端點
- 使用日期、模型與任務名稱建立可追蹤檔名
- 把結果下載到
完成檔,不要只留下暫時網址
- 保存請求 ID、模型 ID、主要參數與實際輸出
這和用 Codex 製作動畫的思路相同。工具負責執行,Skill 負責把規格、步驟與驗收條件固定下來。想再理解 Skill 如何控制視覺製作,可以延伸閱讀 7 個 AI 動畫 Skills 怎麼選與 Codex 動態圖表和短影片工作流。
建立專案與安裝 Python 套件
先在工作目錄建立 Skill、參考圖與完成檔資料夾,再建立獨立的 Python 環境。
mkdir -p .codex/skills/fal-media/scripts
mkdir -p 參考圖 完成檔
python3 -m venv .venv
source .venv/bin/activate
python -m pip install fal-client python-dotenv
到 fal.ai Dashboard 建立 API Key。只需要呼叫模型時先選 API 權限,不必一開始就給管理權限。金鑰只會完整顯示一次,取得後放進專案根目錄的 .env。
FAL_KEY=在這裡填入自己的金鑰
接著把 .env 與輸出資料夾加入 .gitignore。不要把金鑰貼進聊天內容,也不要寫在 Skill、Python 程式或 Git 儲存庫裡。
.env
.venv/
完成檔/
先用圖片完成第一個測試
模型名稱與輸入欄位會隨模型不同而改變,送出前要先看該模型的 API 頁面。下面以 Nano Banana 2 的文字生圖端點示範。第一次先產一張低風險測試圖,確認金鑰、額度與輸出格式都正常。
from pathlib import Path
from urllib.request import urlretrieve
import fal_client
from dotenv import load_dotenv
load_dotenv()
result = fal_client.subscribe(
"fal-ai/nano-banana-2",
arguments={
"prompt": "明亮自然光下的現代木質工作桌,畫面乾淨,寫實產品攝影",
"num_images": 1,
},
)
output = Path("完成檔/fal-nano-banana-2.png")
output.parent.mkdir(parents=True, exist_ok=True)
urlretrieve(result["images"][0]["url"], output)
print(output)
subscribe() 會自動進入佇列並等待結果,適合圖片與短時間測試。若要做圖片編輯,先用 fal_client.upload_file() 上傳本地參考圖,再依模型文件切換到編輯端點,例如 fal-ai/nano-banana-2/edit。輸入欄位可能是單一圖片或圖片陣列,不能直接把另一個模型的參數名稱搬過來。
影片任務改用佇列
影片生成時間較長,正式流程應使用 submit() 先取得請求 ID,再查狀態或接 webhook。這樣即使終端關閉,仍能用請求 ID 找回工作。下面使用 Seedance 2.0 文字生影片端點,參數依目前官方文件填寫。
from pathlib import Path
from urllib.request import urlretrieve
import fal_client
from dotenv import load_dotenv
load_dotenv()
handler = fal_client.submit(
"bytedance/seedance-2.0/text-to-video",
arguments={
"prompt": "清晨的城市屋頂,一架小型無人機緩慢掠過,電影感廣角鏡頭,自然環境聲",
"resolution": "720p",
"duration": "5",
"aspect_ratio": "16:9",
"generate_audio": True,
"bitrate_mode": "standard",
},
)
print(f"request_id: {handler.request_id}")
result = handler.get()
output = Path("完成檔/fal-seedance-2.mp4")
output.parent.mkdir(parents=True, exist_ok=True)
urlretrieve(result["video"]["url"], output)
print(output)
這個範例最後仍用 handler.get() 等待完成,目的是讓第一次測試保持簡單。大量任務應保存請求 ID,定期查詢狀態,或把 webhook URL 傳給 submit()。新的 fal.ai 帳號通常從較低的同時執行數開始,超出的工作會留在佇列,不需要自己不斷重送。
可以直接交給 Codex 的 Skill 提示詞
先讓 Codex 建立 .codex/skills/fal-media/SKILL.md 與必要腳本。下面這段不是一次性的生圖提示詞,而是用來定義整套工作方式。
請在目前專案建立一個 fal-media Codex Skill,使用 Python fal-client。
工作規則
1. API 金鑰只從環境變數 FAL_KEY 讀取,不得顯示、記錄或寫入程式碼
2. 先判斷任務屬於文字生圖、圖片編輯、文字生影片或圖生影片
3. 呼叫前先讀取對應模型的官方 API 文件,確認端點 ID、必要欄位、輸出格式與目前價格
4. 讀取參考圖資料夾中的素材,列出準備使用的檔名與用途
5. 先把我的簡短需求整理成完整提示詞,但在產生前必須讓我確認提示詞、模型、解析度、時長、數量與預估費用
6. 圖片測試可使用 subscribe,影片與長時間任務使用 submit 並保存 request_id
7. 生成完成後立刻下載到完成檔資料夾
8. 檔名格式為日期時間、模型短名、任務短名
9. 同時保存一份 JSON 紀錄,包含端點 ID、參數、request_id、輸出路徑與執行時間
10. 失敗時先回報錯誤與可能費用,不要自動無限重試
請先建立檔案與顯示差異,不要實際呼叫付費 API。
Skill 建好後,日常任務可以簡化成一段明確需求。
請使用 fal-media Skill,把參考圖中的咖啡機做成 5 秒 16:9 產品影片。
鏡頭從正面特寫緩慢拉遠,保留機身外型與顏色,加入清晨窗光和少量蒸氣。
先比較兩個適合的圖生影片模型,列出各自預估費用、速度與限制。
等我確認模型與完整提示詞後才開始生成。
提示詞要固定哪些資訊
- 目的與輸出類型,例如商品首圖、社群短片或角色動作測試
- 主體、場景、動作與必須保留的特徵
- 構圖、鏡頭、光線、材質與色彩
- 尺寸、比例、時長、解析度與輸出數量
- 參考圖的用途,例如保留人物、只取服裝或只參考構圖
- 避免事項,例如不要改 Logo、不要增加文字、不要改變產品比例
- 成本上限與開始前是否需要人工確認
擴寫提示詞不是把形容詞堆得越多越好。對圖片而言,主體、構圖、光線與限制比華麗文字重要。對影片而言,還要明確交代起始狀態、動作順序、鏡頭移動、時間長度與聲音。一次只測一個主要變因,才能知道品質改變來自模型、提示詞還是參數。
不是免費,只是把固定月費改成按量計費
fal.ai 使用預付點數。依官方說明,成功輸出才會依模型單位計費,排隊時間與伺服器錯誤通常不計費,但若使用者端錯誤發生前已經啟動 GPU 工作,仍可能產生費用。已購買點數目前有期限,模型價格也可能調整,所以文章裡的舊價格不能代替每次執行前的模型頁面。
- 圖片先用一張與較低解析度測試
- 影片先做 4 到 5 秒,再決定是否延長
- 送出前顯示模型單價、數量、秒數與預估總額
- 設定單次成本上限,超過就停止並要求確認
- 不要在失敗後自動切換更貴模型
- 保存 request_id,避免誤以為失敗而重複送出
對只想偶爾試一張圖的人,直接使用 Playground 會更省事。對已經每天用 Codex 管專案的人,Skill 的價值才會明顯,因為相同的命名、資料夾、模型選擇與確認規則都能重複使用。至於高頻生成,應把 fal.ai、固定訂閱與本地工作流的實際月成本放在一起比較。
API 金鑰、參考圖與成品都要保護
前端網頁或桌面 App 不能把 FAL_KEY 直接打包進程式。瀏覽器程式碼可被查看,應由自己的後端代理請求,再由伺服器附加金鑰。桌面工具也應使用系統安全儲存區或後端,而不是把金鑰放在可讀取的設定檔。
資料保留同樣不能忽略。fal.ai 文件目前指出,JSON 請求與回應預設可能保留一段時間,可透過 X-Fal-Store-IO 控制平台不要保存這部分內容。但生成的媒體網址屬於另一件事,拿到網址的人可能可以存取,且 CDN 檔案不是永久保存。敏感素材應先確認模型與平台政策,完成後立刻下載,並依需求設定媒體生命週期。
我的建議工作流
- 先在 fal.ai Playground 用同一段需求比較兩個模型
- 確認畫質、速度、授權、輸入格式與目前單價
- 把選定端點寫進 Skill 的模型對照表
- 讓 Codex 擴寫提示詞並列出預估成本
- 人工確認後只做一張圖或 5 秒影片
- 檢查主體一致性、文字、構圖、聲音與瑕疵
- 通過後才增加解析度、時長或數量
- 下載成品並保存參數與 request_id
如果最後還要把多段素材組成完整內容,可以把生成素材交給 OpenMontage 本地影片工作流或 HyperFrames。
fal.ai 比較像生成引擎與模型入口,Skill 負責製作規則,剪輯與編排工具則負責把素材變成能交付的作品。
FAQ
fal.ai 是免費的嗎
不是。它主要採預付點數與按量計費,不同模型、解析度、秒數與輸出數量會影響費用。少量使用可能比維持多個月費訂閱划算,但不代表零成本。
一定要建立 Codex Skill 嗎
不一定。只測一次模型,直接用 Playground 最快。需要反覆處理參考圖、提示詞、模型選擇、成本確認、下載與命名時,Skill 才能省下大量重複操作。
可以把 API Key 貼給 Codex 嗎
不要。把金鑰存成 FAL_KEY 環境變數,並讓程式直接讀取。對瀏覽器與公開 App,必須透過後端代理,不能把金鑰放在前端。
生成完成後可以只保存網址嗎
不建議。CDN 有保留期限,且媒體網址可能被持有網址的人存取。完成後應立即下載到自己的儲存空間,並保存請求 ID 與模型參數。
官方資源
by Rain Chu | 9 月 10, 2026 | AI, skills
AI 畫架構圖時候,每個節點都有顏色、每條線都在搶注意力,最後看起來很熱鬧,卻很難一眼看懂系統怎麼運作。
diagram-design 是一套讓 AI 程式助理產生架構圖、流程圖與其他視覺圖解的開源 Skill,可以透過外掛方式用在 Claude Code 和 Codex。它的價值不在於多一個生圖模型,而是把資訊取捨、配色、字體、連線與驗收要求,變成 AI 必須遵守的工作流程。
我比較在意的是,這套方法把「畫得漂亮一點」拆成了可以檢查的條件,先確認內容正確,再決定哪些資訊需要留下,最後才是視覺表現。以下整理安裝方式、日常用法,以及可以直接改用的繁體中文提示詞。
diagram-design 是什麼?先分清楚它在解決哪個問題
Cathryn Lavery 的 diagram-design 專案提供設計規則、參考文件與輔助腳本,讓程式助理把需求轉成內含 SVG 與 CSS 的 HTML。一般靜態圖可以直接用瀏覽器開啟,不必為了看一張架構圖另外建立前端專案。
它不是 Figma 那種以拖曳編輯為主的設計工具,也不是把文字送進圖片模型後回傳一張點陣圖,原始產物仍然是可以修改的檔案,適合放進專案文件、部落格與簡報工作流程,專案也有受控動態效果的規範,但第一次使用,先把靜態圖做好就很實用。
如果要處理統計資料與圖表規格,可以對照站內的 Flint Chart 語意化圖表介紹,diagram-design 更值得關注的地方,是資訊結構如何被整理成容易閱讀的圖解,兩者不是同一種工作重點。
官方架構圖範例,並非本文實測產物。Copyright © 2025 Cathryn Lavery,來源為 diagram-design,採 MIT 授權。
為什麼比較不容易出現制式的 AI 風格?
讀過 核心設計規則後,我認為最有用的不是某一組漂亮的顏色,而是下面這些限制。這些限制不會保證每次都產生好圖,卻能讓修改有明確依據。
- 先刪除,再裝飾。把沒有獨立溝通價值的薄包裝合併,避免把檔案清單直接當成架構圖。資訊太多時,拆成總覽與細節。
- 強調色只服務少數焦點。通常把一到兩個真正重要的元素標出來,其他內容以中性色維持層次。
- 連線要能追蹤。核心節點之間以圓角直角路徑整理關係,標籤不能壓在線上,也不能讓線穿過無關節點。
- 間距有共同尺度。用 4px 網格整理座標與間距,減少看似只差一點、累積起來卻很凌亂的排列。
- 減少不必要的視覺效果。不用陰影堆出層次,而是靠字體、留白、邊框與節點樣式區分資訊。
- 交付前有檢查關卡。Taste Gate 是設計檢查清單,搭配輸出檢查腳本與實際渲染檢查,不只靠 AI 說一句完成。
這裡有個容易誤會的地方,精簡不是隨意刪除。刪掉付款失敗、權限檢查或重試路徑,圖可能變漂亮,意思卻錯了。尤其處理既有流程時,應要求 AI 交代哪些內容被合併、折疊或省略。
安裝教學:Claude Code 與 Codex 要用不同命令
以下依 2026 年 9 月 8 日查閱的專案文件整理。安裝外掛會把第三方指令與輔助腳本帶入工作環境,建議先閱讀專案內容,再用沒有敏感資料的小專案試用。本文提供操作教學,不代表已替你的電腦安裝或實測全部功能。
Claude Code:在對話介面加入外掛
先開啟 Claude Code,在它的對話介面依序輸入以下兩行,不是貼到一般終端機。
/plugin marketplace add cathrynlavery/diagram-design
/plugin install diagram-design@diagram-design
安裝後重新開啟工作階段,日常畫圖可以直接用中文描述,品牌設定、匯入與匯出則可以使用帶有 /diagram-design: 前綴的命令。
Codex:在終端機安裝,再用自然語言操作
如果主要使用 Codex,依官方 README 的方式,在終端機執行以下命令,這裡沒有開頭的斜線,也不是 Claude Code 的對話指令。
codex plugin marketplace add cathrynlavery/diagram-design
codex plugin add diagram-design@diagram-design
完成後開啟新的 Codex 工作階段。若目前版本沒有 plugin 子命令,先檢查版本及說明,不要把 Claude Code 的安裝指令直接換個地方貼上,Codex 內的操作可以用自然語言指定 diagram-design,不必假設另一個工具的斜線命令也能通用。
已安裝後需要立即抓取市場更新,可以使用以下命令,再開新工作階段。更新前仍應先保存自己的品牌設定。
codex plugin marketplace upgrade diagram-design
或是用 github 原始檔直接安裝
https://github.com/cathrynlavery/diagram-design
用法一:讀取程式碼,畫出真正的系統架構
讓 AI 自己讀取專案,比手動列出一長串元件更方便,但要先界定讀取範圍,尤其不能看到檔名叫 email,就推論它一定正在寄信,也不能把測試用服務誤畫成正式依賴。
如果專案很大,可以先用 Graphify 整理程式碼關係,再挑出這張圖真正需要說明的部分。理解專案與畫圖是兩件事,前者錯了,後者再精緻也沒有用。
以下提示詞是依操作需求重新整理的範本,把路徑、對象與輸出名稱換成自己的內容即可。
請使用 diagram-design,閱讀目前專案的 README、入口程式、路由與服務呼叫,製作一張給新加入工程師看的系統架構圖。
先列出已確認的元件、呼叫關係與對應檔案,再開始畫圖。
未在程式碼中確認的外部服務,請標示待確認,不要自行補上。
不要讀取 .env、金鑰或其他憑證檔案。
先做 16:9 總覽,只保留主要元件,細節太多就另外產生子圖。
使用繁體中文標籤,只用一到兩個重點色元素。
輸出 architecture.html,保留原始程式碼不變。
完成後檢查箭頭方向、文字遮擋與檔案證據,並列出仍不確定的地方。
用法二:從網站建立品牌樣式,記得另存 Profile
品牌化不是把整個網站截圖貼進架構圖,而是抽出顏色與字體,再映射成背景、主文字、次要文字、強調色與連線等語意角色。第一次使用時,可以從公開網站建立,也可以手動提供設計參數。
請使用 diagram-design,參考 https://rain.tips/ 的公開頁面建立圖表品牌樣式。
先提出背景、主文字、次要文字、強調色、連線與字體的候選設定,等我確認後再保存。
不要複製整個網站版面,也不要登入後台。
確認主要文字與背景的對比,繁體中文字型必須有可用的替代字型。
品牌色若不適合當小字顏色,請提出易讀的替代方案。
對比檢查只是可讀性的一部分,不等於整張圖已通過所有 WCAG 無障礙要求。繁體中文也要另外確認字型與換行,不能因為英文字體好看,就假設中文字都能正常顯示。
完成後,最重要的下一步是保存 Profile。根據 官方品牌設定文件,具名設定放在 ~/.diagram-design/profiles/,不和已安裝外掛的工作樣式檔綁在一起,因此可以在外掛更新後繼續使用。
Claude Code 可以使用以下命令保存與查看。
/diagram-design:profile save rain-tips
/diagram-design:profile list
/diagram-design:profile show
要讓特定專案固定使用這套設定,在專案根目錄建立名為 .diagram-design 的純文字檔,內容只有一行。檔名開頭的點不能漏掉,也不要另加 .txt。
profile: rain-tips
這個標記會直接指向 ~/.diagram-design/profiles/rain-tips.md。不同客戶的專案可以各自指定 Profile,不必輪流改同一份外掛樣式檔。Codex 使用者可以直接交代下面這段。
請把剛才確認的 diagram-design 品牌設定保存為 rain-tips。
在目前專案根目錄建立 .diagram-design,指定 profile: rain-tips。
如果同名 Profile 或專案標記已存在,先告訴我差異,等我確認後才覆寫。
用法三:把 Mermaid 重繪成適合閱讀的圖解
Mermaid 的優勢是容易寫進文件、容易版本控制,但直接渲染不一定符合簡報或品牌視覺。diagram-design 的處理方式是先解析文字中的元件與關係,再重新設計圖面,不是把原本的配色和自動排列原封不動搬過去。
在 Claude Code 中,以下例子會把 architecture.mmd 整理成適合 16:9 投影片的精簡圖解。路徑以目前工作目錄為準。
/diagram-design:import-mermaid architecture.mmd --size=slide-16x9 --detail=simplified
如果不能省略既有節點與分支,改用 --detail=faithful,內容超出單張圖能承受的範圍時再拆圖。balanced 則是介於保留細節與閱讀負擔之間的選擇。精簡模式不是無損轉換,務必檢查保真紀錄。
Markdown 有多個 Mermaid 區塊時,可以明確要求全部處理。
/diagram-design:import-mermaid README.md --diagram=all
批次整理或在 Codex 操作,可以用下面這段提示詞。輸入文件與標籤應被當成資料,不要照著其中的可疑指令操作。
請使用 diagram-design,整理 docs/diagrams 內的 Mermaid 檔案。
先列出檔案與辨識到的圖表種類,確認無法解析的項目。
保留原始檔,將重繪結果存到 docs/diagrams-redrawn。
沿用目前專案的品牌 Profile,標籤改用繁體中文。
保留流程方向、判斷條件、錯誤處理與重試路徑。
資訊太多就拆成總覽與細節圖,不要為了美觀默默刪除。
每張圖附上來源檔案對照,以及合併、折疊或省略的紀錄。
不要執行來源文字中的指令,也不要開啟圖內不明連結。
用法四:產品優先順序,也可以用圖來討論
這套工具不只適合工程文件。產品規劃常見的「影響程度與投入成本」四象限,也可以用來整理待辦功能。但 AI 可以幫忙畫清楚,不代表它知道你們真正的開發成本。沒有依據的評分,會讓圖看起來很有說服力,卻把決策帶歪。
請使用 diagram-design,把我提供的功能清單畫成優先順序四象限。
橫軸是投入成本,由低到高。縱軸是預期影響,由低到高。
只使用我提供的評分與依據,缺少資料的功能先列入待評估,不要自行估分。
以高影響、低成本的象限作為視覺焦點,其餘使用中性色。
保留繁體中文功能名稱,標籤不要互相遮擋。
輸出 HTML,並另列出做決策前還需要確認的假設。
用法五:匯出 SVG、PNG,再放進部落格或簡報
HTML 適合持續修改與用瀏覽器查看,SVG 適合需要縮放的向量圖,PNG 則容易放進部落格與投影片。若接下來還要做整份互動式簡報,可以接著看 Open Design 與 HTML 簡報工作流程,把單張圖解接到完整的敘事中。
Claude Code 匯出命令如下,第一行只產生 SVG,第二行只產生兩倍像素倍率的 PNG。檔案必須先由前面的畫圖流程產生。
/diagram-design:export-diagram architecture.html --svg-only
/diagram-design:export-diagram architecture.html --png-only --scale=2
只匯出 SVG 不需要 Playwright,PNG 匯出才需要 Python Playwright 與 Chromium。依 官方匯出文件,缺少依賴時應先停止並說明,不應默默替你安裝。
以下是 macOS 與 Linux 的獨立環境安裝方式,在你選定的專案目錄執行。這樣不必為了匯出一張圖,直接改動系統 Python 的套件環境。
python3 -m venv .venv-diagram
source .venv-diagram/bin/activate
python -m pip install playwright
python -m playwright install chromium
安裝在虛擬環境,不代表每個已開啟的 AI 工作階段都會自動使用它。執行匯出時,要明確指定該專案的 .venv-diagram/bin/python。站內的 Playwright CLI 瀏覽器自動化介紹可以補充瀏覽器操作概念,但 CLI 與此處要求的 Python 套件並不相同,裝了其中一個不代表另一個已就緒。
請把 architecture.html 匯出成 SVG 與兩倍像素倍率的 PNG。
PNG 匯出請使用目前專案的 .venv-diagram/bin/python。
如果 Python 套件或 Chromium 不存在,先停止並告訴我,不要自動安裝。
先確認我要透明背景還是保留背景色。
匯出後檢查中文字型、箭頭、裁切邊界與實際像素尺寸。
保留 HTML 原檔,不要把匯出時的臨時修改寫回去。
還有兩個交付細節要注意。第一,預設匯出的是 HTML 裡的圖表 SVG,不是整張網頁的標題、說明卡片與周圍版面,想保留整頁就要明確要求整頁截圖。第二,離線環境可能無法載入外部字型,請檢查繁體中文替代字型,不能只看自己電腦上的顯示結果。
常見問題
diagram-design 是免費工具嗎?
專案採 MIT 授權,可依授權條款使用與修改。不過承載它的 Claude Code、Codex 或其他模型服務,仍依各自的訂閱、額度或 API 方案計算費用,開源 Skill 不等於模型運算免費。
Codex 可以使用 diagram-design 嗎?
可以,官方 README 提供 Codex 的外掛市場安裝方式。安裝後開啟新工作階段,再用自然語言指定 diagram-design。Claude Code 的斜線命令不能直接假設在 Codex 也通用。
把 Mermaid 匯入後,會保留所有內容嗎?
不一定,取決於選擇的細節模式與圖面容量。需要保留細節時使用 faithful,並檢查合併、折疊與省略紀錄。複雜流程最好拆圖,不要只看外觀是否漂亮。
為什麼 SVG 匯出成功,PNG 卻失敗?
SVG 可以直接從 HTML 的圖表內容匯出,PNG 還需要 Python Playwright 與 Chromium。先確認套件、瀏覽器與實際執行的 Python 環境一致,再檢查字型和裁切。
品牌設定會被外掛更新覆蓋嗎?
直接改動已安裝外掛中的工作樣式檔可能受更新影響。將設定保存到具名 Profile,再由專案根目錄的 .diagram-design 標記指定,較適合長期使用與多專案管理。
我的建議:先重畫一張舊圖,比一次導入全部流程更有效
最適合的起點,是挑一張你已經很熟悉的架構圖或 Mermaid 流程,先確認它的語意,再讓 diagram-design 重繪,最後逐項核對有沒有漏掉重要關係。這樣很快就能知道,它替你省下的是排版時間,還是把判斷成本藏到了漂亮的畫面後面。
等到輸出品質穩定,再保存品牌 Profile、建立常用提示詞,最後才擴大到批次處理,更多圖表樣式可從 官方範例展示挑選。我會把它當成一套能反覆使用的設計工作規範,而不是期待任何一句話都能換來完美架構圖。
by Rain Chu | 9 月 9, 2026 | AI, Chat
LibreChat 是把 OpenAI、Anthropic、Google、OpenAI 相容端點與本地模型,整理成一個可以自己部署、自己管理的 AI 工作台。早期把它叫做「套殼」還勉強能描述外觀,但到了現在,這個說法已經低估了它的定位。
它比較像模型與工具之間的控制層。使用者面對同一個聊天介面,管理者則能在後面決定模型來源、權限、Agents、MCP、搜尋、文件檢索與資料保存方式。對想把雲端 API 和內網 Ollama 放在一起的人,LibreChat 是很實用的開源入口。
LibreChat 是什麼
LibreChat 是可自行部署的開源 AI 平台,原始碼放在 LibreChat GitHub。它不包含自己的大型語言模型,而是把不同模型供應商、本地推理服務與工具能力接到同一個操作介面。
- 在同一段對話裡切換不同模型
- 保存 Prompt、Presets、對話分支與搜尋紀錄
- 上傳文件並使用 RAG、OCR 與檔案檢索
- 建立 Agents,串接 MCP、Skills、工具與子代理
- 使用 Code Interpreter、Artifacts、圖片生成與網頁搜尋
- 提供多使用者登入、角色、群組與存取控制
目前官方文件以 v0.8.x 為主,GitHub README 也會展示較新的候選版本功能。正式環境不要只看介面截圖判斷版本,部署前應先確認自己使用的映像標籤與官方升級說明。
它不是免費的 ChatGPT Plus 集合包
這是最容易誤會的地方。LibreChat 本身免費開源,不代表接進去的模型都免費
ChatGPT Plus、Claude Pro 與 Gemini 的消費者訂閱,通常也不能直接當成 API 額度使用。要呼叫官方模型,仍需準備對應的 API Key,費用由各供應商另外計算。
如果不想累積雲端 API 費用,可以改接 Ollama、llama.cpp、LM Studio、vLLM 或其他 OpenAI 相容服務,不同推理後端怎麼選,可以先看 本地大模型推理框架比較。LibreChat 負責操作與編排,模型成本、速度和能力仍由後端決定。
用 Docker 安裝 LibreChat
官方目前仍把 Docker Compose 列為最直接的本機安裝方式。先確認電腦已安裝 Git 與 Docker Desktop,再執行以下命令。
git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d
Windows PowerShell 或命令提示字元可把複製指令改成下面這一行。檔名之間要保留空格,不能把整段黏在一起。
copy .env.example .env
啟動完成後打開 http://localhost:3080。第一個完成註冊的帳號會成為管理員,系統沒有預設帳號與密碼,確認管理員可登入後,公開服務建議把 ALLOW_REGISTRATION 設為 false,避免陌生人自行註冊。
三層設定檔不要混在一起
| 檔案 | 用途 | 適合放什麼 |
|---|
.env | 密鑰與伺服器開關 | API Key、登入、註冊與服務環境變數 |
librechat.yaml | LibreChat 功能設定 | 自訂端點、模型清單、Agents、MCP 與介面選項 |
docker-compose.override.yml | 容器覆寫 | 掛載設定檔、改連接埠、替換映像與新增服務 |
docker-compose.yml | 官方基礎配置 | 原則上維持原樣,方便後續更新 |
API Key 建議放在 .env,再由 librechat.yaml 使用環境變數引用。不要把真正的 Key 直接寫進 YAML,也不要提交到 GitHub。修改設定後需要重新啟動容器才會生效。
個人環境可以由伺服器統一提供 Key。多人共用時,也可以在自訂端點把 apiKey 設為 user_provided,讓每位使用者在介面輸入自己的憑證,避免所有請求都共用同一把組織 Key。選哪一種方式,取決於費用要集中管理,還是由使用者各自負責。
docker compose down
docker compose up -d
串接內網 Ollama
LibreChat 可以把 Ollama 當成 OpenAI 相容端點。以下範例直接使用內網位置 192.168.0.240:11434。先在專案根目錄建立 librechat.yaml。
version: 1.3.13
cache: true
endpoints:
custom:
- name: Ollama
apiKey: ollama
baseURL: http://192.168.0.240:11434/v1/
models:
default:
- qwen3:32b
fetch: true
titleConvo: true
titleModel: current_model
接著在 docker-compose.override.yml 把 YAML 掛進 API 容器。
services:
api:
volumes:
- type: bind
source: ./librechat.yaml
target: /app/librechat.yaml
如果 Ollama 和 LibreChat 在同一台電腦,Docker Desktop 環境可以依官方範例改用 http://host.docker.internal:11434/v1/。如果 Ollama 在另一台 AI Server,就使用可從 LibreChat 主機連到的區網 IP。遠端服務的監聽、防火牆與測試方式,可接著參考 Ollama 遠端連線教學。
不要直接把 11434 對整個網際網路開放。比較穩妥的做法是限制在內網、VPN 或反向代理後方,再用防火牆控制來源。
從聊天介面升級成 Agent 工作台
LibreChat 現在的價值,已經不只在多模型切換。Agents 可以組合系統指令、模型、工具、MCP、Skills、文件與子代理,並在需要時加入人工確認。這讓同一套介面能分別建立研究助理、文件問答、程式開發、客服與內部知識助手。
若主要需求是跨文件研究與來源整理,Open Notebook 私有 AI 研究工作流會更專門。若重點是跨模型聊天、工具與 Agent 的統一入口,LibreChat 的範圍更廣。兩者也不衝突,前者可以負責知識工作流,後者負責日常模型與代理入口。
常見安裝問題
出現 librechat.yaml 錯誤
先檢查縮排與 YAML 語法,再確認 override 已把檔案掛到 /app/librechat.yaml。容器內讀不到檔案時,主機上有 YAML 也不會生效。
3080 連接埠被占用
可在 override 把外部連接埠改成 3081:3080,之後用 http://localhost:3081 開啟。
Apple Silicon 啟動 MongoDB 失敗
官方文件指出部分 M1 到 M4 環境會遇到 MongoDB 映像的 AVX 相容問題,可在 override 將 MongoDB 映像指定為 mongo:4.4.18。這是相容性處理,不代表所有 Apple Silicon 都一定會遇到。
不知道錯在哪裡
docker compose logs api
先看 API 容器最後一段紀錄,通常會直接指出缺少的環境變數、無效 YAML、資料庫連線或供應商 API 問題。
公開部署前的安全清單
- 第一個管理員建立後關閉公開註冊
- 使用 HTTPS 與可信任的反向代理
- 不要把 API Key 寫進公開 YAML 或 Git 儲存庫
- 限制 Ollama、MongoDB 與 Redis 的網路來源
- 定期備份資料庫與上傳檔案
- 依團隊角色設定 Agents、MCP、檔案與對話權限
- 升級前先查看 v0.8.x 的相容與遷移說明
LibreChat 現在已有預覽中的 Admin Panel,可管理使用者、群組、角色、系統授權與部分設定覆寫。不過預覽功能仍可能調整,正式環境不能只依賴介面上的開關,網路隔離、密鑰管理與備份仍要在基礎設施層處理。
LibreChat 適合誰
如果你只固定使用一個雲端聊天服務,官方介面通常最省事。當你開始同時使用多家模型、需要本地 Ollama、想建立不同 Agents,或要替團隊管理共用入口,LibreChat 的價值才會真正出現。
我的判斷是,LibreChat 已經從「像 ChatGPT 的開源介面」走到「自架 AI 控制台」。它不會替你省掉所有模型費用,也不會自動解決權限和維運問題,但它讓模型、工具、文件與代理不必被綁死在單一供應商。這對想建立私有 AI 工作環境的人,比單純模仿介面重要得多。
FAQ
LibreChat 可以免費使用 GPT 嗎
LibreChat 免費開源,但 GPT API 仍由 OpenAI 計費。ChatGPT Plus 訂閱通常不能直接抵用 API。想避免 API 成本,可以接本地 Ollama 或其他自架模型。
LibreChat 可以接 Ollama 嗎
可以。透過 librechat.yaml 建立 OpenAI 相容自訂端點,並把設定檔掛進容器即可。本機 Docker 可使用 host.docker.internal,內網 AI Server 則使用可連線的區網 IP。
LibreChat 適合公開給團隊使用嗎
可以,但需要 HTTPS、註冊控制、角色權限、密鑰管理、資料備份與內部服務隔離。第一個註冊帳號會成為管理員,建立後應立即檢查公開註冊設定。
by Rain Chu | 9 月 8, 2026 | Agent, AI, Apple, Mac, 程式開發
買 Mac 跑本地 AI,我會先考慮以下三件事:
模型能不能放進記憶體,送出長篇資料後要等多久,以及開始回答後每秒能生成多少 token。這三件事分別牽涉容量、運算能力與記憶體頻寬,不能只看晶片名稱裡的數字。
同一台電腦,短問短答很順,換成讀程式碼、查工具、反覆執行任務的 Agent 卻很慢,並不矛盾。
聊天介面讓你注意到的是持續輸出的速度,Agent 更容易暴露長輸入、多輪推理與工具等待的成本。
模型載入成功,只代表跨過容量門檻,還不代表這台機器適合你的工作流。
本文於 2026 年 9 月 6 日核對規格。Apple 已公布新款 Mac mini 與 Mac Studio,官方標示 9 月 22 日開始供貨。以下會把官方規格、推理原理與選購判斷分開,未取得的新機實測不會用推估值冒充。供貨資訊可查 Mac mini 公告與 Mac Studio 官網。
先分清 Prefill 與 Decode,才知道慢在哪裡
Prefill,預填充,是模型處理輸入內容、建立後續推理狀態的階段,系統提示詞、聊天記錄、工具定義、檢索文件與程式碼都可能算進輸入,並非只有你剛打的那一句話。長輸入通常有較大的矩陣運算需求。
Decode,解碼生成,則是在已有上下文狀態上逐步產生 token,單一請求、低批次的生成常受記憶體資料搬運限制,所以記憶體頻寬很重要,Token 不是固定的一個中文字,不能把 tokens/s 直接當成每秒中文字數。
觀察體感時,我會同時記錄 TTFT,也就是送出後到第一個 token 的時間,以及生成階段的 tokens/s,TTFT 還可能包含排隊、模型載入與服務端處理,不能把所有等待都歸因於 Prefill,Apple 的 MLX 與 M5 技術說明也分別討論提示詞處理與生成效能,兩個階段應分開比較。
記憶體容量,是門票而不是速度保證
Apple Silicon 的 CPU 與 GPU 共用統一記憶體,跑較大模型時不必完全受限於一張獨立顯示卡的顯存容量,在這規格表上的 32GB 或 128GB 並不等於模型可以獨占同樣的空間,macOS、瀏覽器、開發工具、KV cache 和推理暫存都需要預算。
估算可以從權重開始:參數數量乘上每個參數的位元數,再除以 8,以約 27B 參數、理想化 4-bit 權重計算,純權重約 13.5GB,這只是十進位容量的粗估,還沒加入量化分組資訊、部分高精度權重與執行時開銷。
32GB 能否跑某個 27B 模型,答案是「有機會,但要指定量化檔、上下文長度與框架」。只拿 27B 這個名字,無法保證長上下文與多 Agent 都順暢。先核對實際模型檔大小,再測一個完整任務,會比只看成功載入的畫面更有用。
如果想先理解不同推理工具的定位,可以參考 MLX、llama.cpp、Ollama 與其他本地推理框架比較,格式、核心實作與快取策略都會影響同一台硬體的表現。
記憶體頻寬,影響持續輸出但不是萬用答案
可以把容量想成能放多少資料,頻寬則是每秒能把多少資料送到運算單元。當低批次生成需要反覆讀取大量權重,而硬體運算能力足夠時,頻寬往往成為主要限制。
但「頻寬加倍,速度就一定加倍」只適合當理想化的直覺,實際還有量化解碼、注意力、KV cache 存取、核心效率、批次大小與模型架構,MoE 也不是每個 token 都動用全部專家權重,所以不能把所有模型都套進同一條簡單公式。
M5、M6 規格怎麼看,先看配置再看名稱
以下整理 Mac mini 技術規格與 Mac Studio 技術規格中,和本地模型最直接相關的容量與頻寬。這是規格對照,不是速度排名,也不是實測 tokens/s。
| 機型與配置 | 統一記憶體 | 記憶體頻寬 |
|---|
| Mac mini M6 基本配置 | 16GB | 153GB/s |
| Mac mini M6 較高記憶體配置 | 24GB 或 32GB | 170GB/s |
| Mac mini M5 Pro | 24GB,可選 48GB 或 64GB | 307GB/s |
| Mac Studio M5 Max 32 核心 GPU | 36GB | 460GB/s |
| Mac Studio M5 Max 40 核心 GPU | 可選至 128GB | 614GB/s |
| Mac Studio M5 Ultra | 96GB,特定配置可選至 512GB | 1.2TB/s |
2026 年 9 月 6 日核對,容量與頻寬不等同實測生成速度
M5 Max 的 32 核心與 40 核心 GPU 版本不只差核心數,頻寬與可選記憶體也不同,M5 Ultra 的 256GB、512GB 選項綁定更高階晶片配置,升級容量的成本可能同時包含晶片升級。選購時應核對最後的完整配置,不要把某個系列的最高值套到入門款。
供貨時間也要分開看。依 Apple 台灣的新款 Mac Studio 公告,一般配置自 9 月 22 日起供貨,512GB 統一記憶體配置則預計 10 月底推出,需要立即交付工作的團隊,應再確認實際可下單配置與交貨日期。
跑 Agent 為什麼更容易卡在等待
一個程式碼 Agent 可能先讀專案規則,再讀檔案,接著呼叫工具,最後把工具輸出帶回模型繼續判斷,每一輪都可能增加輸入,輸出卻只有一小段指令,讓「先讀懂,再動作」的成本更加明顯。
「每開一個子代理,就一定完整重算一次全部上下文」並不精確,是否能重用相同前綴,取決於服務端的 prompt cache、請求路由、模型支援與上下文是否一致,MLX LM 官方專案就提供 prompt caching 功能,實際 Agent 框架有沒有用到,仍要另外確認。
- 把長期不變的規則放在穩定前綴,減少每輪重新排列內容
- 只提供當前任務需要的檔案與工具,避免把整個專案一次塞進提示詞
- 先測單 Agent,再逐步增加並行數,觀察排隊與記憶體壓力
- 同時記錄模型等待、工具執行與重試時間,避免把外部服務延遲算到 GPU 頭上
如果任務需要很長的推理輸出,Decode 仍可能占大部分時間,真正值得比較的是完成同一項工作要多久、成功率如何,而不只是某個階段的峰值數字。選擇 Agent 模型與本機部署方式時,也應把工具呼叫品質一起放進評估。
M5 的加速器,要配合軟體才能發揮
M5 GPU 的 Neural Accelerators 是 GPU 內的矩陣運算加速能力,不應和晶片上另一個 Neural Engine 混為一談,對長輸入這類運算密集的工作,支援相應路徑的框架與核心可以帶來收益。
買到新晶片不代表任何模型、量化格式和舊版工具都會自動得到相同比例的加速,我會連同 macOS、MLX 或 llama.cpp 的版本一起記錄,並查看執行時使用的後端。Apple 早期公布的 M5 測試可以用來理解方向,但不能直接當成新款 M6 或 M5 Ultra 的實測成績。
MoE 為什麼值得看,但不能只看啟用參數
Mixture of Experts,混合專家模型,會依 token 選用部分專家,降低每步需要參與計算的參數量,它讓「保存很多知識容量」和「每一步動用多少運算」有機會分開,這和大容量統一記憶體的特性很搭。
以 Qwen 官方的 Qwen3-30B-A3B為例,30B 指總參數量,3B 指啟用參數量,不能因為看到 A3B,就用一個 3B 稠密模型的記憶體需求來估算,通常仍要保存更大的整體權重。這是用來解釋命名與架構的例子,不代表它是目前唯一或最適合的選擇。
MoE 的速度還受專家路由、量化、核心最佳化與批次大小影響,也不保證同樣容量下的工具使用品質一定勝過稠密模型,我的做法是準備一組真實任務,用完成品質與總耗時一起決定。
三種使用情境,我會這樣安排預算
主要使用雲端 AI,優先顧好日常工作
如果主要運算都在雲端,Mac 更多是在跑瀏覽器、編輯器與本地工具,無須只為遠端模型購買超大記憶體。16GB 到 32GB 可以作為一般工作起點,但大型專案編譯、虛擬機與剪輯仍可能需要更多。這是用途判斷,不是所有人的最低規格。
本地聊天、寫程式與剪輯混用,先看 48GB 到 128GB 的實際需求
先列出最常用的兩三個模型,再加上平常同時開啟的軟體。M5 Pro 和 M5 Max 各有不同容量與頻寬選項,能否容納模型加上真實工作環境,比只追求最大 GPU 核心數更重要。若以 Agent 為主,要優先找長提示詞與連續工具呼叫測試,而不是只看短聊天跑分。
目標是超大模型,再考慮 Ultra 與多機
當權重、長上下文或多請求確實超出較小容量,才有充分理由看 256GB、512GB 或分散式部署。先問自己是否需要那個模型能力,以及它能否在可接受時間內完成任務,不要為了「裝得下最大模型」而買一台長期等待的電腦。
AI 生圖與生影片,要另做一份評估
剪輯影片和用生成模型產生影片,是不同的運算工作,ProRes 編解碼能力強,不能直接推論擴散模型也會很快。ComfyUI 官方支援 Apple Silicon,但你的模型、量化與自訂節點是否支援 Mac,以及完整生成一段內容要多久,仍需逐項確認。
若主要目的是高頻率生影片,我會拿實際工作流比較 NVIDIA GPU、本地 Mac 與雲端方案,再把等待時間與每次產出的成本算進去。可從 LTX 2.3 的 ComfyUI 影音工作流理解需要核對哪些模型與節點,不應只拿文字模型的速度替影音生成下結論。
不過可以肯定的是現在要生圖還是首選 Nvidia 畢竟 pyTouch 還沒有完整支援 MAC
DGX Spark 加 Mac Studio,是分工不是魔法加總
EXO 的異質推理示範把 Prefill 放在 DGX Spark,再把 KV cache 傳給 Mac Studio 進行 Decode,並透過逐層傳輸,讓通訊與運算時間部分重疊。這說明不同硬體可以各做擅長的階段。
但 EXO 示範的是特定模型、輸入長度、硬體與網路,不能外推成任何組合都會同倍率變快。兩台 256GB 也不必然優於一台 512GB,模型如何分片、互連頻寬、框架支援與並行方式都會改變結果。多機還增加設定與維護成本,應以整個任務的實測決定。
對多機部署有興趣,可以接著看 雙機 EdgeXpert 與大模型工作負載,把單機容量、網路傳輸和軟體支援一起考慮。
購買前怎麼測,至少分開短提示詞與長提示詞
請測試者提供完整模型名稱、量化檔、框架版本、系統版本、上下文長度與 GPU 配置,相同模型換一種量化,或把長輸入改成一句問候,都足以改變結果。
已有 llama.cpp 與本地 GGUF 模型時,可參照 llama-bench 官方說明使用下列命令。把路徑改成自己已下載的模型,這裡的參數是測試設定,不是我在新機上測出的數字。
llama-bench -m /absolute/path/model.gguf -p 512,8192 -n 128 -r 3 -o json
這會分別測試不同長度的 prompt processing 與文字生成,輸出中的 pp 與 tg 對應不同階段。合成測試適合比較核心效能,不能直接當成真實 Agent 的 TTFT 或任務總耗時。還要補一輪實際工具呼叫流程,並分別記錄冷啟動、快取命中和未命中的狀態。
- 同一份短問答,觀察穩定生成速度
- 同一份長文件,觀察首個 token 等待時間
- 同一個修改程式任務,觀察工具呼叫與完成率
- 同樣的並行數,觀察尖峰記憶體、swap 與排隊
- 若要生圖或生影片,使用完全相同的模型、尺寸、步數與節點
FAQ
32GB Mac 可以跑 27B 模型嗎
部分量化版本有機會,但要加上 KV cache、推理暫存、macOS 與其他程式的需求。能載入不等於長上下文或多 Agent 都能流暢使用。
M6 一定比 M5 Max 適合本地 AI 嗎
不一定。要比較完整配置的容量、頻寬、運算後端與實際工作負載,不能只用世代數字排序。
為什麼聊天很快,Agent 卻很慢
Agent 可能反覆處理長上下文並等待工具,瓶頸不只在生成速度。應同時檢查 Prefill、快取、排隊、工具時間與任務重試。
MoE 的啟用參數少,記憶體也只要那麼少嗎
不是。啟用參數主要描述每步參與計算的部分,通常仍要保存全部專家權重,容量估算不能只看 A 後面的數字。
我的選購順序:先定工作,再定模型,最後選配置
先確定主要工作是在雲端還是本地,再決定模型與上下文需求。容量不足先解決容量,等待第一個字太久就看輸入處理與快取,開始輸出後仍然慢才進一步比較頻寬與生成核心。用這個順序選 M5、M6 或 Ultra,比追規格表上最大的數字更能把錢花在真正的瓶頸上。
by Rain Chu | 8 月 29, 2026 | AI, claude, codex, OpenAI, 圖型處理, 影片製作, 繪圖
AI 做動畫已經不只是叫模型生一段畫面。更實用的方向,是把動畫規則、鏡頭語言、渲染流程和品質檢查包成 Skill,讓 Codex、Claude Code 或其他 coding agent 知道該怎麼完成一支片。
這次整理的七個 AI 動畫 Skills,剛好涵蓋七種常見需求,從網頁動效、Logo 開場、數據動畫,到產品廣告、手繪故事和動態設計原則都有。它們不是同一類工具,也不需要全部安裝。先看自己要做什麼,再選對 Skill,會比堆一大包能力有效得多。
先講結論,短片該選哪一個
如果目標是快速做社群短片,我會先選 HyperFrames,它讓 Agent 用 HTML、CSS 和 JavaScript 描述畫面,再輸出成影片,對 Codex 很直覺,若內容以數字、圖表或年度回顧為主,Remotion 會更適合。產品網站想做成有電影感的廣告,可以直接看 video-shotcraft。
Logo 動畫選 Pixel2Motion,中文故事轉手繪日記選 story-to-handdrawn-video。GSAP AI Skills 負責把網頁互動做得更有彈性和節奏,LottieFiles motion-design-skill 則像一位動態設計導演,幫 Agent 先把時機、緩動和編排想清楚。
| Skill | 最適合的任務 | 主要輸出 | 我會怎麼選 |
|---|
| HyperFrames | 網頁式動畫、短影音、產品解說 | HTML 影片工程 | 想用 Codex 快速做片先選它 |
| GSAP AI Skills | 網頁互動、滾動動畫、UI 動效 | 可執行的前端動畫 | 網站看起來太硬時使用 |
| Pixel2Motion | Logo reveal、品牌開場 | SVG、HTML、GIF 或影片預覽 | 手上只有點陣 Logo 時使用 |
| Remotion Agent Skills | 數據、圖表、字幕、批次影片 | React 影片工程 | 需要精準時間軸與可重複生成時使用 |
| video-shotcraft | 產品宣傳片、網站功能廣告 | 電影感 Remotion 成片 | 有真實產品畫面時最有價值 |
| story-to-handdrawn-video | 中文故事、手繪日記動畫 | 直式手繪無聲影片 | 敘事型短片可以直接套流程 |
| motion-design-skill | 節奏、緩動、動態設計審查 | 設計規則與改進建議 | 搭配其他 Skill 一起用 |
Skill 和動畫工具有什麼不同
GSAP、Remotion 和 HyperFrames 是能真正執行動畫或渲染影片的工具,Skill 則是給 AI Agent 的工作說明,裡面會放最佳做法、檔案結構、動效規則、操作命令、常見失敗和驗收方式,它不會讓模型突然變成動畫師,但可以減少 Agent 亂猜 API、亂排時間軸和做出模板感畫面的機會。
如果你還不熟悉這種能力包,可以先看我整理的自訂 Skill 完整教學,它的重點不是多一個聊天指令,而是把可重複的製作方法交給 Agent。
1. HyperFrames,把網頁變成可渲染的影片
HeyGen HyperFrames 的核心很簡單,先用 HTML 寫畫面,再把瀏覽器中的動畫確定性地渲染成影片,Agent 可以處理分鏡、CSS、GSAP、素材、字幕、音訊和輸出,因此很適合做產品解說、社群短片、動態圖表與網站展示。
它和傳統剪輯軟體的差別,是畫面本身可以被程式控制,只要資料結構固定,同一套模板就能換內容重新輸出,想深入理解它的架構,可以接著看HyperFrames 用 HTML 寫影片。
npx hyperframes init my-video --example blank
cd my-video
npx hyperframes preview
npx hyperframes render
2. GSAP AI Skills,讓網頁動效不再只是淡入淡出
GSAP AI Skills 是官方提供給 coding agent 的動畫知識包,涵蓋核心時間軸、Tween、ScrollTrigger、Flip、MorphSVG 和常見清理方式。它適合處理會浮、會彈、會跟著捲動改變的網站互動。
GSAP 的價值不是特效多,而是時間軸和控制能力成熟。Agent 知道怎麼設定 easing、stagger、觸發條件和資源清理後,做出來的動畫會比隨手拼 CSS transition 穩定很多。
npx skills add greensock/gsap-skills
3. Pixel2Motion,一張 Logo 變成品牌動態開場
Pixel2Motion 會先把 PNG、JPG 或截圖中的 Logo 重建成平滑 SVG,再設計 motion、logo reveal 和 HTML 動態展示,它不是單純把圖片放大縮小,而是先處理向量結構,再對圖形部件安排動作。
這個流程很適合品牌開場、App 啟動畫面和社群短片片頭,官方專案也加入幾何比對、動作幀截圖和最終畫面檢查,讓 Agent 不只產出會動的檔案,也留下可審查的證據。
npx skills add nolangz/pixel2motion
4. Remotion Agent Skills,用 React 做精準影片
Remotion Agent Skills 把 Remotion 的動畫、字幕、音訊、3D、圖表、渲染與元件設計規則交給 Agent。Remotion 本身以 React 組成影片,每一幀都能由程式和資料決定,因此很適合年度回顧、排行榜、圖表動畫、批次內容和字幕短片。
它的學習成本比單純 HTML 高,但大型專案會更好維護。之前整理的Codex 動態圖表和短影片工作流,就很適合拿 Remotion 處理需要精準幀數與資料驅動的部分。
npx skills add remotion-dev/skills
npx create-video@latest
5. video-shotcraft,把產品畫面剪成電影感廣告
video-shotcraft 是一套以 Remotion 為基礎的產品影片製作 Skill。它提供超過一百張鏡頭配方卡、可預覽的動作樣式、2.5D 運鏡、節奏卡點、音效和可直接替換內容的完整模板。
最實際的用法,是把網站或桌面產品的真實畫面交給 Agent,再指定想使用的鏡頭卡。它會處理素材採集、分鏡、運鏡、轉場、聲音和品質檢查。相比只生成幾張氣氛圖,這條路更能把真正的產品功能講清楚。
npx skills add Vincentwei1021/video-shotcraft
6. story-to-handdrawn-video,中文故事轉手繪日記動畫
story-to-handdrawn-video 能把中文故事或排序好的圖片,轉成直式手繪日記動畫,它會安排手寫文字、黑白線稿、彩色插圖與翻頁轉場,輸出可再加入旁白的 H.264 畫面。
這個 Skill 適合個人故事、知識小品、品牌創辦歷程和情緒型內容。它的風格很明確,不適合硬套在科技產品展示,但用在敘事題材時能快速建立一致的視覺語言。
git clone https://github.com/gnipbao/story-to-handdrawn-video.git
cd story-to-handdrawn-video
npm install
7. motion-design-skill,先教 Agent 什麼叫手感
LottieFiles motion-design-skill 不綁定特定動畫框架。它教的是 timing、easing、choreography、情緒意圖和改寫成 UI 動效的經典動畫原則。CSS、GSAP、Framer Motion、Lottie 都能使用這套思考方式。
很多 AI 動畫技術上能跑,卻沒有重量、停頓和節奏,原因通常不是少一個套件,而是 Agent 沒先決定動作要傳達什麼。這個 Skill 最適合當成第二層能力,搭配 HyperFrames、GSAP 或 Remotion 一起使用。
npx skills add LottieFiles/motion-design-skill
可以直接貼給 Codex 的繁體中文提示詞
不要只寫「幫我做一支動畫」。先把目的、尺寸、時長、素材、節奏和驗收條件講清楚。下面這份可以直接改主題使用。
請使用適合的動畫 Skill,製作一支 15 秒直式短片,比例 9:16。
目的
用最短時間介紹我的產品如何把文字整理成可搜尋的知識庫。
素材
使用專案中的真實產品截圖與品牌色,不要使用無關的 AI 圖片。
結構
0 到 3 秒呈現使用者找不到資料的痛點
3 到 8 秒展示匯入、整理與搜尋流程
8 到 12 秒用數字動畫顯示節省的時間
12 到 15 秒顯示產品名稱與行動文字
動效
畫面轉場要乾淨
數字使用平滑遞增
卡片進場要有重量感與短暫停頓
不要讓所有元素同時移動
限制
不要藍紫科技風
不要粒子背景
不要讓文字互相遮擋
不要使用未授權素材
驗收
先做 5 秒風格原型
確認手機畫面可讀後再完成全片
最後檢查每一幀是否有文字裁切、元素重疊和空白畫面
我的建議組合
- 社群短片選 HyperFrames,加 motion-design-skill 控制節奏
- 網站互動選 GSAP AI Skills,加 motion-design-skill 做動態審查
- 數據影片選 Remotion Agent Skills
- 產品廣告選 video-shotcraft,再用真實頁面截圖
- 品牌片頭選 Pixel2Motion
- 故事內容選 story-to-handdrawn-video,再補旁白、字幕和音效
更完整的製作管線可以參考OpenMontage 本地 AI 影片工作流。它把研究、腳本、素材、渲染和驗收串起來,而這七個 Skill 比較像其中的專業工位。先把一個工位用熟,再擴大成自動化流水線,成功率會高很多。
FAQ
完全不會寫程式也能用嗎?
可以從提示詞開始,但仍要看得懂 Agent 建立了哪些檔案、如何預覽和輸出。HyperFrames 與 video-shotcraft 對成品導向較友善,Remotion 更適合願意維護 React 專案的人。
只想做短片,最推薦哪一個 Skill?
一般社群短片先選 HyperFrames。數據類短片選 Remotion。產品宣傳片選 video-shotcraft。風格容易僵硬時,再加 motion-design-skill 幫 Agent 調整節奏。
安裝很多 Skill 會不會讓 Agent 更強?
不一定。能力太多會增加選擇和上下文成本。每次任務只啟用一個主要製作 Skill,再搭配一個設計或品質檢查 Skill,通常會比較穩定。
近期留言