Hi 👋

最近在建一條本地 AI 影片生成流水線，硬體是 RTX 3070 Laptop 8GB，完整的技術架構和參數設定記錄在技術文件。 這篇寫的是建構過程中幾個關鍵決策點——哪些地方 AI 幫了忙，哪些地方它的判斷是錯的，以及怎麼發現。 第一版：AI 憑空想像的流程 最初直接讓 AI 根據需求建 ComfyUI workflow。它建出來了，影片也能產，但有一個明顯的問題：風格帶著一種舊化感，像是幾年前的 AI 生成特徵。 原因事後回想很清楚——AI 沒有足夠的資訊。它沒有看過 Sulphur 2 的官方 workflow 定義，只憑訓練資料推斷出一個「合理的流程」。推斷不等於正確，結果就是一個能動、但不在最佳狀態的起點。 第一個決策：給 AI 官方參考，而不是讓它自己想。 第二版：引入官方 Workflow，效能卻掉了 重新提示 AI，要它去取得 Sulphur 2 官方 distilled T2V workflow 定義，按照那份結構重新拆成 pass1 + pass2 的兩段式設計。結構正確了，但發現生成效能直線下滑——同樣的段落，時間拉長了好幾倍。 這裡出現了第一個診斷題：效能問題出在哪？ 效能調整：AI 知道的設定，跟現在的軟體不一樣 排查過程中花了相當多時間在 ComfyUI 的 offload 策略上。AI 給的設定建議是舊版本的理解——當時的 ComfyUI 有多種 offload 模式可以細調。但實際操作下來發現，新版本的行為已經不同，選項基本收斂到「自動」或「關閉自動」兩種，中間的細調空間幾乎消失了。 A/B 測試了一輪後，最終穩定的方式是 --cache-none。 邏輯是：多 model 加上多 workflow 的情境下，讓 ComfyUI 做智能 cache 決策，反而容易造成記憶體用量難以預測——RAM 先爆，然後 pagefile 的問題就跟著浮現（這個問題在上一篇有說過）。放棄 cache 的好處，換來的是行為的可預測性。 ...

最近在建一條本地 AI 影片生成流水線，需要挑一個 T2I 模型做 keyframe 的上游。 硬體限制是 RTX 3070 Laptop，8GB VRAM，不能加卡。 挑模型的過程裡，順帶整理了一些平時容易混淆的概念，以及讓系統跑穩的幾個關鍵設定。 Fine-tune、LoRA、Distill 是三件不同的事 這三個詞在中文圈常常被混在一起講，但它們根本不是同一個維度： Fine-tune LoRA Distill 改什麼 畫風 / 內容 畫風 / 內容（同上） 推論速度 訓練範圍 整個模型 只訓練插件權重 訓練速度更快的學生模型 檔案大小 跟 base 一樣大 50–300 MB 跟 base 一樣大 可以疊？ ✗ 一次一個 ✓ 可以同時掛多個 ✗ 換 checkpoint 這三件事可以疊在同一個工作流裡。juggernautXL_v9-lightning.safetensors 這個常見的模型， 本質就是寫實 fine-tune + Lightning distill 的組合；用它的時候還可以再加角色 LoRA + 風格 LoRA。 弄清楚這個，選模型的時候就不會被名字搞混。 8GB VRAM 的候選名單 把常見的選項排一遍： 模型 VRAM 1024² 出圖時間 品質 8GB 可行？ SDXL Lightning（4–8 步） ~7 GB 4–6 s ★★★★☆ ✓ SDXL base + fine-tune（30 步） ~7 GB 15–22 s ★★★★☆ ✓ Flux Schnell GGUF Q4_K_M ~7 GB + offload 15–20 s ★★★★★ ✓ Flux Dev GGUF Q4_K_M ~7 GB + offload 60–90 s ★★★★★ ✓ 但慢 Flux fp16 12 GB+ — ★★★★★ ✗ 12B 的 Flux 為什麼能塞進 8GB？靠 GGUF Q4_K_M 量化——精度損失大約 5–10%， 但 Flux 的 prompt 理解能力幾乎全保留。Q4_K_M 是 4-bit 量化裡品質與速度的甜蜜點， Q4 還是 Flux 級的，不是閹割版。 ...

過去一個月，我把整套個人開發流程改成 agent 驅動。下面是目前的狀態，與一個還沒解完的問題。 Agent 架構 7 個 orchestrator skills、18 個 agents、23 個 utility skills,透過 MCP 與 Gitea、YouTrack、Kubernetes 整合。 三層架構： Planning：把模糊需求拆成模組、再拆成 lane-level issue Orchestrator：驅動「issue → 派工 → PR → merge」迴圈,最多 5 輪 Specialist：按技術棧切分（前端、後端、infra、docs、PR review 等）,在獨立 worktree 實作 流程 人類給幾行簡易的功能模組描述,剩下的事 agent 接手: planner 改寫規格 → orchestrator 派工 → designer 出 mockup → coder 實作 → reviewer 跑規格整合檢查 → resolver 處理改動 → merge 最近一次產出的速度 這個 epic 的目標是 WebRTC 視訊會議的基礎實作——視訊框、對話框、房間管理。 11 個 issue,從規格到 13 個 PR 全數 merge,總時間 3 小時 28 分鐘,產出 10,224 行 code,平均約 49 行 / 分鐘。 ...

Hello, this blog is live. 這個 Blog 以 Hugo + PaperMod 為技術棧， 透過 Gitea Actions CI 自動建置 Docker image，並由 FluxCD GitOps 部署至 K3s 叢集。 域名：blog.davidhsaiou.com