by Rain Chu 7 月 28, 2026 | AI , skills , Tool , 圖型處理
AI Agent 很會理解「月份、營收、百分比變化」代表什麼，卻不一定能穩定處理座標軸、刻度、色階、標籤間距與版面配置，直接要求模型輸出完整 Vega-Lite 或 ECharts 規格，常見結果不是設定冗長，就是參數彼此衝突，甚至渲染後只得到空白畫布。
Flint Chart 的做法，是讓 AI 只負責描述資料的意義與圖表意圖，再由確定性的編譯器完成幾何與渲染細節 ，這不只是圖表工具的改良，也是一種值得用在 AI Agent 系統的架構。模型產生小型、可驗證的中介格式，程式再負責執行可重現的工作。
如果你正在用 Codex 製作視覺內容，可以先參考站內的Codex 動態圖表與短影音工作流程 ，Flint 則更專注在資料圖表的語意、驗證與多後端輸出。
Flint Chart 是什麼
Flint 是微軟研究院與中國人民大學 IDEAS Lab 合作開發的開源視覺化中介語言，它不是另一套直接把圖畫到畫布上的函式庫，而是位在 AI Agent 與 Vega-Lite、Apache ECharts、Chart.js、Plotly、Excel 之間的語意層。
AI Agent 判斷欄位代表月份、價格、利潤、國家、排名或百分比變化Flint 規格 保存資料、語意型別、圖表種類與欄位映射Flint 編譯器 推導日期解析、聚合、刻度、色彩、標籤與版面繪圖後端 接收原生規格並渲染互動圖表、PNG、SVG 或 Excel 原生圖表
截至 2026 年 7 月 28 日，官方 GitHub 顯示 JavaScript 與 TypeScript 函式庫已能輸出 Vega-Lite、ECharts、Chart.js、Plotly 與 Office.js 使用的 Excel 原生圖表。7 月 11 日的 iThome 報導只列出前三種，是因為後續 0.4.0 版才加入 38 種 Plotly 圖表與 18 種可編輯 Excel 範本。
為什麼 AI 直接產生圖表容易失敗
製作圖表其實包含兩種不同工作。第一種是理解語意，例如 revenue 是金額，month 是年月，growth 是百分比變化。第二種是安排幾何，例如軸的範圍、刻度密度、文字旋轉、圖例位置與色彩映射。
語言模型擅長第一種工作，第二種工作卻牽涉許多互相依賴的數值與規則。Flint 把兩者拆開後，AI 不必一次猜完所有低階設定。規格也從難以檢查的大段設定，縮成可閱讀、可修改、可在渲染前驗證的小型 JSON。
模型負責意義，編譯器負責數學。真正的價值不是少寫幾行，而是讓每一步都能被驗證與重現。
Flint 規格的三個核心部分
一份 Flint 輸入主要由資料、semantic_types 與 chart_spec 組成。下面用季度營收長條圖示範最小結構。
{
"data": {
"values": [
{ "quarter": "Q1", "revenue": 1200 },
{ "quarter": "Q2", "revenue": 1450 },
{ "quarter": "Q3", "revenue": 980 },
{ "quarter": "Q4", "revenue": 1800 }
]
},
"semantic_types": {
"quarter": "Quarter",
"revenue": "Price"
},
"chart_spec": {
"chartType": "Bar Chart",
"encodings": {
"x": { "field": "quarter" },
"y": { "field": "revenue" }
},
"baseSize": { "width": 480, "height": 320 }
}
}
data 可以直接放入列資料，也能在本機 MCP 模式下引用 JSON、CSV 或 TSV 檔案。semantic_types 告訴編譯器每個欄位的實際意義。chart_spec 則決定圖表種類，以及欄位要放在 x、y、color、size、shape、column、row、group 或 detail 等通道。
語意型別可以重複使用。探索同一份資料時，多半只要更換 chart_spec。例如把 Quantity 改成 PercentageChange，編譯器就能改用適合正負變化的發散色階、百分比格式與對應的軸設定。這比每次都讓模型重新生成完整圖表設定更穩定。
在 Codex 安裝 Flint MCP
本機版本需要 Node.js 18 以上。Codex 可以用一行命令加入 stdio MCP 伺服器。
codex mcp add flint -- npx -y flint-chart-mcp接著確認伺服器是否已經出現在清單。
codex mcp list如果資料不需要從本機檔案讀取，可以關閉檔案引用。這個設定要求代理把資料列直接放進 data.values，能縮小不受信任工作流程的檔案存取範圍。
codex mcp add flint-safe -- npx -y flint-chart-mcp --disable-file-reference官方也提供遠端 MCP 端點，適合只能連接 HTTP MCP 的客戶端。處理私有資料時，仍建議優先選擇本機 stdio 版本。
codex mcp add flint-remote --url https://flint.data-formulator.ai/mcp第一次使用的提示詞
安裝後不要只下「幫我畫圖」。把資料來源、語意、圖表目的、驗證方式與輸出格式一起交代，結果會更可靠。
請載入 flint://agent-skill，並呼叫 list_chart_types 檢查 vegalite 後端是否可用。讀取目前資料夾的 sales.csv，把 month 判定為 YearMonth，revenue 判定為 Price，growth 判定為 PercentageChange。先用 validate_chart 驗證，再建立每月營收折線圖，並用顏色標示成長率。若支援 MCP Apps 就使用 create_chart_view，否則用 render_chart 輸出 SVG。最後列出所有警告與被截斷的資料。
Flint MCP 提供五個主要工具。create_chart_view 適合互動調整，validate_chart 用來檢查規格與警告，render_chart 產生 PNG 或 SVG，compile_chart 回傳後端原生 JSON，list_chart_types 則用來確認可用的圖表與通道。
這套做法和讓 Codex 用 Playwright CLI 操作瀏覽器 有相同精神。模型不必自己模擬每個底層步驟，而是呼叫邊界清楚、結果可檢查的工具。
在 JavaScript 與 TypeScript 專案使用
若你正在開發產品，而不是只在對話中產生圖表，可以直接安裝函式庫。
npm install flint-chartimport { assembleVegaLite } from "flint-chart"
const input = {
data: { values: myData },
semantic_types: {
weight: "Quantity",
mpg: "Quantity",
origin: "Country"
},
chart_spec: {
chartType: "Scatter Plot",
encodings: {
x: { field: "weight" },
y: { field: "mpg" },
color: { field: "origin" }
},
baseSize: { width: 400, height: 300 }
}
}
const spec = assembleVegaLite(input) 相同輸入可以交給 assembleECharts、assembleChartjs、assemblePlotly 或 assembleExcel。後端若不支援指定圖表，組裝器會在渲染前拋出錯誤，因此產品端應先查詢範本支援狀態，再把錯誤與警告顯示給使用者。
Excel 原生圖表特別適合需要後續人工編輯的報表工作。如果工作流程還包含 Word、PowerPoint 或試算表處理，可以延伸閱讀OfficeCLI 與 AI Agent 的 Office 自動化教學 。
Flint、Vega-Lite、Mermaid 與一般 Chart MCP 的差異
工具 主要用途 AI 要處理的細節 適合情境 Flint 語意中介格式與編譯 資料意義、圖表意圖與欄位映射 需要可靠生成、多後端與可驗證規格 Vega-Lite 統計視覺化文法 較完整的編碼、比例尺與版面設定 需要精細控制與成熟生態 Mermaid 流程圖與軟體圖解 節點、關係與圖形語法 架構圖、流程圖與文件 一般 Chart MCP 把特定繪圖服務包成工具 視工具設計而定 已有固定渲染服務或單一後端
Flint 並不是 Vega-Lite 的替代品，因為它可以直接編譯成 Vega-Lite 規格。它處理的是更前面的一層，讓模型先表達「這些資料是什麼」，再由編譯器決定「如何正確畫出來」。
目前限制與使用前要知道的事
仍是研究專案 官方論文尚未正式公開，產品決策不能只靠宣傳數字Python 套件尚未發布 目前只有原始碼預覽，正式套件仍以 JavaScript 與 TypeScript 為主後端支援並不完全相同 同一圖表不一定能在所有後端輸出，MCP 指南目前列出的編譯後端仍以 Vega-Lite、ECharts 與 Chart.js 為主Flint 不負責完整資料整理 聚合、過濾、關聯、樞紐與衍生欄位最好先在上游完成自動版面可能截斷資料 離散項目超過空間預算時會套用保留策略，整合端必須顯示 _warnings本機渲染仍要管理權限 預設會讀取代理指定的本機檔案，不受信任的環境應啟用 –disable-file-reference
iThome 整理的測試顯示，Flint 在 GPT-5.1、GPT-5-mini 與 GPT-4.1 三組 LLM 評分中，都優於直接產生完整 Vega-Lite 規格的 DirectVL。不過官方仍標示研究論文即將公開，因此比較結果適合視為早期證據，不能取代自己的資料集與視覺驗收。
真正值得帶走的是代理系統的分工方式
Flint 最值得學習的不只是圖表規格，而是代理系統的分工。讓模型輸出小型、結構化、可以先驗證的意圖，再讓確定性程式負責計算、渲染與錯誤處理。這個模式也能延伸到 UI 元件、文件排版、測試流程與自動化操作。
但「成功回傳 JSON」不等於任務完成。視覺工作必須真的渲染，再檢查畫布是否空白、文字是否重疊、顏色是否誤導、資料是否被截斷。AI Agent 的可靠性，來自可驗證的中介格式與最後一哩的實際驗收，而不是更長的提示詞。
常見問題
Flint 可以取代 ECharts 或 Vega-Lite 嗎
不會。Flint 是位在 AI 與繪圖函式庫之間的中介語言，最後仍會輸出 ECharts、Vega-Lite 等後端可使用的原生規格。
Flint MCP 會把資料上傳到外部服務嗎
本機 stdio 版本會在主機上執行，內嵌資料與本機檔案不會送到遠端渲染服務。若改用官方 HTTP 端點，資料會透過遠端連線處理，因此敏感資料仍應優先採用本機版本。
Codex 看不到互動圖表怎麼辦
create_chart_view 需要客戶端支援 MCP Apps。若目前介面不支援，可以要求 Flint 使用 render_chart 輸出 SVG 或 PNG，再直接檢查成品。
Flint 適合什麼工作
它適合需要大量產生資料圖表、希望規格可被人工修改、需要切換不同後端，或不能接受偶發空白與錯誤圖表的 Agent 工作流程。若只是一次性的簡單圖表，現有大型模型或熟悉的圖表函式庫可能已經足夠。
參考資料
by Rain Chu 7 月 12, 2026 | AI , 圖型處理
Krea2 開始變得有趣，不只是因為它能做漂亮的圖，而是因為它正在被接進 ComfyUI 的節點工作流。當圖像編輯、多圖參考、LoRA、KSampler 和 4K 出圖放在同一張節點圖裡，Krea2 就不只是單次生成工具，而是可以被拆解、調參、複用的內容生產流程。
我會把這次重點整理成三件事。
第一，Krea2 edit LoRA 的 ComfyUI 節點怎麼理解。
第二，私模與社群模型要怎麼分開看。
第三，4K 工作流不是單純放大，而是先控制訓練尺寸，再用 latent 放大與第二次採樣補細節。
Krea2 圖像編輯的真正重點
Krea2 圖像編輯最吸引人的地方，是它把「參考圖」和「提示詞」放到同一個生成條件裡 ，這比單純丟一張圖做 img2img 更細，因為參考圖可以被視覺編碼器理解，再和 prompt 一起影響模型輸出。
ComfyUI-Krea2-Ostris-Edit 這個節點包就是關鍵之一，它的 README 說明，這套節點是為了執行用 AI Toolkit 訓練的 Krea 2 edit LoRA，安裝方式是放到 ComfyUI 的 `custom_nodes` 目錄，重新啟動後節點會出現在 `ostris/krea2` 類別。
它不是模型本體，而是讓 ComfyUI 能正確吃進 Krea2 edit LoRA 的橋，這點很重要，因為很多人看到節點就以為模型已經包含在裡面，實際上模型、LoRA、節點和工作流是四個不同層次。
多圖參考不是把圖片塞進去就好
Krea2 Ostris Edit 的文字編碼節點可以接受 prompt，也可以接受 `image1` 到 `image3` 這類參考圖。GitHub 說明裡提到，參考圖會透過 Krea2 的 Qwen3-VL text encoder 編碼，並用 Krea 的 conditioning template 加入 `Picture N:` 這類視覺 placeholder。
換句話說，多圖參考的重點不是「圖片有沒有接上節點」，而是參考圖有沒有被正確轉成 conditioning。若接了 VAE，參考圖也會被 VAE 編碼成 reference latents，再交給 model patch 節點使用。這也是為什麼工作流裡會看到 Text Encode、Model Patch、VAE、KSampler 連在一起。
Text Encode Krea 2 Ostris Edit 負責把 prompt 與參考圖一起編碼
Krea 2 Ostris Edit Model Patch 讓模型真的消化 reference latents
如果文字編碼 checkpoint 沒有 Qwen3-VL vision weights，參考圖就無法被正確編碼
如果 conditioning 沒有 reference latents，patch 後的模型會像原本的 Krea2 一樣運作
這也是我會把它歸類為進階 ComfyUI 工作流，而不是單純的模型推薦，若你對節點式 AI 生產平台還不熟，可以先看我整理過的 RunningHub 與 ComfyUI 工作流平台 ，會比較容易理解為什麼同一個模型放進工作流後，價值會完全不一樣。
私模、社群模型與合規使用要分清楚
這次素材裡有一個很值得注意的提醒：老白訓練的 Krea2 亞洲女性私模不是開源模型，它是投入大量訓練步數與算力成本做出來的商業模型，這類模型能不能商用、能不能轉售、能不能放到平台上提供他人使用，都要看授權條款。
所以我會把工作流和模型分成兩條線來看。工作流可以學，節點可以研究，參數邏輯也值得整理，但私模本身不是「看到連結就能自由拿來用」的資源。若只是想理解 Krea2 工作流，可以先從社群模型、公開節點和 RunningHub 上的示範流程開始。
另外，Krea2 的圖像編輯能力很容易碰到肖像、換裝、仿真與身份一致性問題。越是接近真人或商業素材，越需要確認素材來源、肖像權、授權和平台規範。技術可以做到，不代表每個場景都適合做。
4K 工作流的核心不是暴力放大
這套 4K 思路有一個實用點：先用接近訓練尺寸的長邊出圖，再在 latent 空間放大，最後用第二次採樣補細節。以這次整理的參數來看，長邊 1536 是一個被反覆提到的基準，因為後面還要做倍率放大。
第一個 KSampler 會用比較高的 denoise，例如 `denoise 1`，步數可以抓 8 到 10 步。這一步不是最後成品，而是建立整體構圖與質感。接著在 latent 空間放大，例如 2.5 倍，再進入第二個 KSampler。第二次採樣通常要更保守，避免把第一輪已經穩定的畫面重新打亂。
階段 用途 重點 第一輪採樣 建立構圖與主要質感 可用較高 denoise，步數約 8 到 10 latent 放大 把畫面放到更高解析度 倍率要配合原始長邊與顯存 第二輪採樣 補細節與穩定質感 採樣器與 denoise 要保守，避免重新洗圖
這個思路和傳統 Stable Diffusion 的高解析修復很像，但放到 Krea2 和 LoRA 組合後，更需要注意模型本身的訓練尺寸與美學方向。你如果常玩本機模型部署，也可以對照我之前寫的 ComfyUI 本機部署 AI 繪圖模型 ，兩者都在處理「模型能力」和「工作流控制」之間的平衡。
LoRA 權重不是越高越好
這次工作流裡多次出現 LoRA 疊加。單獨使用某個風格 LoRA 時，權重可以先從 0.8 附近測。若兩個 LoRA 一起用，總權重抓在 0.9 到 1.0 比較容易控制，例如一個 0.5，另一個 0.4。
這不是死規則，而是避免模型過度偏移的起點。Krea2 本身的細節與光影已經很強，LoRA 的目的應該是加強風格或概念，而不是把底模原本的結構感整個蓋掉。若出現臉部變形、姿勢不穩、材質變髒，第一個要檢查的通常不是 prompt，而是 LoRA 權重和第二輪採樣是否太激進。
Krea2 工作流適合誰
我覺得 Krea2 這類流程比較適合三種人。第一種是已經熟悉 ComfyUI，想要把參考圖、LoRA、放大與後處理串成固定模板的人。第二種是需要穩定產出社群圖像、封面、人像素材或商品視覺的人。第三種是想研究圖像編輯模型訓練方向的人，因為 Krea2 edit LoRA 的節點設計能看出參考圖 conditioning 的實作脈絡。
如果只是偶爾修圖，可能用線上工具會比較快。如果要長期做工作流、批量產圖、測 LoRA 權重，ComfyUI 仍然比較有彈性。也可以用 AIX Studio 這類 AI 繪圖平台 做比較，看看自己需要的是封裝好的產品，還是可拆解的節點流程。
實作前可以先檢查這幾件事
確認 Krea2 模型與 LoRA 來源，尤其是授權和商用限制
安裝 ComfyUI-Krea2-Ostris-Edit 節點後再重啟 ComfyUI
確認 text encoder checkpoint 含有 Qwen3-VL vision weights
多圖參考要檢查 VAE reference latent 是否真的接進 conditioning
第一輪採樣先穩構圖，第二輪採樣再補細節
LoRA 疊加時總權重不要一開始就拉太高
真人、換裝、仿真、商業圖像要先確認合規與授權
若你想直接在線上試工作流，可以看 RunningHub 的 Krea2 Realism Engineer v2 工作流頁面。若人在海外，RunningHub 也有海外站。這類平台的好處是不用先處理本地顯卡和節點衝突，但缺點是工作流可控性和資料隱私要自己評估。
結論
Krea2 圖像編輯真正值得看的，不只是單張效果圖，而是它如何被拆成 ComfyUI 裡的節點、conditioning、model patch、LoRA 權重和雙採樣流程。這讓它從「好看的模型」變成「可調整的生產系統」。
我的建議是先從公開節點和可取得的工作流開始，把參考圖進 conditioning 的路徑搞懂，再去看私模或商業模型是否值得投入。尤其是人像與商業素材，合規使用要放在技術嘗試前面。能生成不是終點，能穩定、可控、可授權地生成，才是 Krea2 工作流真正能落地的地方。
延伸資源
by Rain Chu 7 月 11, 2026 | OCR , 圖型處理
InternVL3 值得注意的地方，不只是又一個開源多模態模型，而是它把本地 VLM 的使用場景推得更實際，OCR、掃描文件、模糊表格、手寫字、截圖理解，這些都不是聊天模型的展示題，而是每天真的會卡住工作的資料入口。
如果之前已經在玩 本地多模態分析 ，InternVL3 可以看成下一個很適合放進實驗清單的模型。它不只是看圖說話，而是更接近能處理文件、表格與複雜畫面的視覺語言模型。
InternVL3 的重點是文件理解，而不是炫技
AIVI 的整理把 InternVL3 放在企業級 OCR 和多模態理解的脈絡裡看。這個定位很合理。現在很多人把 VLM 拿來做圖片描述，但真正有價值的地方，往往是把原本不適合丟給文字模型的資料變成可處理的結構。
例如模糊 PDF 掃描件、手寫備註、拍歪的表格、截圖裡的 UI 狀態，這些資料以前要靠人工整理，或用傳統 OCR 加一堆後處理。InternVL3 這類模型讓流程變成另一種樣子。先讓 VLM 看懂畫面，再把結果交給下游的 RAG、資料庫、工作流或 Agent。
這也能和 MarkItDown 這類文件轉換工具 互補。文字型文件可以先轉 Markdown，掃描影像、複雜表格和視覺內容則交給 VLM 補上理解能力。
InternVL3 有哪些技術方向值得看
AIVI 筆記提到三個重點。第一個是原生多模態預訓練。它不是先訓練純文字模型，再把視覺模組接上去，而是在同一個訓練階段同時學文字和多模態資料。這個方向的好處，是減少後期對齊的落差，讓模型在文字能力與視覺理解之間更一致。
第二個是可變視覺位置編碼。這類設計的核心，是讓視覺 token 的位置表示更彈性，支援更長的多模態上下文。對文件理解很重要，因為真實文件常常不是單張乾淨圖片，而是多頁、表格、註記、圖文混排。
第三個是偏好優化與測試時擴展。簡單說，就是讓模型不只會回答，也能在推理過程中更穩定地挑出比較好的答案。這對 OCR 類任務尤其重要，因為一個字看錯、欄位對錯、單位錯置，都可能讓後面的分析整個歪掉。
為什麼要用 lmdeploy
InternVL3 本身是模型，真正要落到日常使用，還需要部署層，這就是 InternLM 的 lmdeploy 進場的地方。它的定位是壓縮、部署和服務化 LLM 與 VLM，官方 README 強調高效推理、量化、多機多卡服務和相容性。
用比較白話的方式說，lmdeploy 是把模型從「可以下載」變成「可以被應用呼叫」。當它用 OpenAI 相容 API 跑起來後，Open WebUI、自寫腳本、內部工具或 Agent 流程都可以用同一套 API 方式接進來。
這一點對本地部署很重要，單次 demo 可以直接跑 notebook，但長期使用要考慮服務常駐、併發、顯存、量化、監控和前端介面。這也是為什麼本地 AI 不該只停在安裝成功，而要慢慢走向像 OpenMontage 本地部署 那樣，把模型、服務和工作流串起來。
建議部署流程
AIVI 的流程可以整理成四段。第一段是準備 Linux 或 WSL 環境，第二段是建立 conda 環境，第三段是安裝 lmdeploy 與必要套件，第四段是啟動 API server 並接到 Open WebUI。
conda create -n lmdeploy python=3.11 -y
conda activate lmdeploy
pip install lmdeploy partial_json_parser timm 模型服務可以先用 14B 版本做測試。AIVI 範例使用 TurboMind backend，port 設在 23333，並指定 InternVL 相關 chat template。
lmdeploy serve api_server OpenGVLab/InternVL3-14B-Instruct --backend turbomind --server-port 23333 --tp 2 --chat-template internvl2_5 啟動後，OpenAI 相容呼叫大致長這樣。重點不是 API key 本身，而是 base_url 指向本機服務。
from openai import OpenAI
client = OpenAI(
api_key="local-key",
base_url="http://127.0.0.1:23333/v1"
)
model_name = client.models.list().data[0].id 如果要給一般使用者操作，可以再裝 Open WebUI。
pip install open-webui
open-webui serve Open WebUI 的價值不是漂亮而已，而是讓 VLM 從工程實驗變成日常工具。你可以把它當成公司內部的視覺文件入口，讓同事不用碰 Python，也能上傳圖片、掃描件或表格截圖測試效果，這個方向也和 AI Agent 進入可視化操作介面 的趨勢一致。
部署前要先想清楚硬體與模型大小
InternVL3 有不同參數規模。不要一開始就衝最大模型，除非你已經有足夠顯存和多卡環境，比較務實的做法，是先用 14B 或更小版本建立流程，確認 API、Open WebUI、圖片上傳、OCR 品質和下游應用都通，再決定是否升級。
lmdeploy 官方支援量化與多種推理引擎，這表示部署時可以在速度、顯存、品質之間取平衡。若是個人工作站，應該先關心能不能穩定跑起來。若是團隊服務，才進一步考慮併發、多卡與監控。
如果已經在比較本地模型格式與顯卡路線，可以順手參考 Ollama 與 Qwen 量化選擇 這類文章。雖然工具不同，但同樣是在處理顯存、速度和品質的取捨。
適合拿來做什麼
把掃描 PDF 或圖片文件轉成可分析的文字與表格。
判讀手寫註記、發票、表單、截圖與複雜版面。
為內部知識庫補上圖片與文件理解能力。
替 GUI Agent 提供畫面理解與狀態判斷。
建立不依賴雲端 API 的企業內部 VLM 服務。
我會特別看好文件處理和內部工具場景。因為這些工作通常資料敏感，而且每家公司文件格式不同，雲端通用 OCR 未必能直接解決。能本地跑，代表可以把資料留在自己的機器或內網裡，再慢慢針對真實樣本調整流程。
我的結論
InternVL3 加 lmdeploy 的組合，真正值得看的不是安裝命令，而是它讓本地 VLM 服務變得更像一個可長期使用的基礎設施。模型負責看懂圖片與文件，lmdeploy 負責把模型服務化，Open WebUI 或其他前端負責降低使用門檻。
如果你的工作裡有大量掃描件、圖片表格、手寫內容、UI 截圖或需要保密的文件，這條路線很值得測。它不一定會取代所有 OCR 工具，但會讓 OCR 從單純辨識文字，升級成理解畫面裡的結構與意圖。
延伸資源
FAQ
InternVL3 適合做什麼？
InternVL3 適合處理 OCR、掃描件、手寫字、表格截圖、圖文混排文件和 GUI 畫面理解。它的價值不只是描述圖片，而是把視覺資料轉成可被後續流程使用的資訊。
lmdeploy 在這裡扮演什麼角色？
lmdeploy 是部署與服務化工具。它可以把 InternVL3 這類模型包成 API server，讓 Open WebUI、Python 腳本或內部工具用 OpenAI 相容方式呼叫。
一定要用最大版本的 InternVL3 嗎？
建議先用較小版本把流程跑通，確認 OCR 品質、顯存占用、API 和前端整合都穩定，再依需求升級到更大的模型。
by Rain Chu 7 月 11, 2026 | AI , 圖型處理 , 影片製作
RunningHub 最值得看的地方，不是它又做了一個線上 AI 繪圖平台，而是它把 ComfyUI 工作流、AI 應用、模型 API、工作流 API 和內容模板包成一個可營運的創作平台。對內容團隊來說，這比較像是把原本散在本機、模型網站、工作流社群和 API 文件裡的能力，整理成同一個生產入口。
如果你之前已經在玩 本機 ComfyUI 與開源繪圖模型 ，RunningHub 可以看成另一條路。它不是要求每個人都先理解節點、環境、顯卡和模型路徑，而是把工作流託管在雲端，讓創作、分享、調用和商業化更接近一般工具的使用方式。
RunningHub 是什麼
RunningHub 官方把自己定位成原生 AI 智能體驅動的全能內容創作平台，支援 ComfyUI 工作流、無限畫布、AI 應用和模型 API 調用。這句話拆開看，其實代表三層產品。
第一層是創作入口，包含快捷創作、無限畫布、rhTV、RHSTORY、VibeX 和各種模板。
第二層是工作流市場，讓創作者基於 ComfyUI 做出可複用的流程，並提供給其他人直接使用。
第三層是 API 與開發者工具，把模型、AI 應用和工作流變成可以被產品或內部系統調用的服務。
這三層合在一起，RunningHub 的野心就比較清楚了，它不是只想做一個 ComfyUI 雲端版，而是想做 AI 內容生產的基礎平台。創作者可以在上面做模板，團隊可以用模板產出素材，開發者可以透過 API 把同一套能力接到自己的產品裡。
和本機 ComfyUI 最大差別
本機 ComfyUI 的好處是自由度高，模型和節點都能自己控制，缺點也很明顯，安裝、模型管理、節點衝突、顯卡限制和工作流維護都會吃掉大量時間。RunningHub 則把這些麻煩轉成雲端服務與平台規則。
面向 本機 ComfyUI RunningHub 環境管理 自己安裝 Python、節點、模型和驅動 平台託管工作流與模型能力 硬體成本 需要自己的 GPU 或雲端機器 按平台資源與調用方式使用 分享方式 通常分享 JSON、模型清單與安裝說明 可直接變成模板、AI 應用或 API 適合對象 技術玩家、研究者、重度創作者 內容團隊、電商、短劇、行銷、開發者 商業化路徑 需要自己包服務或教學 平台內有模板、應用與創作者激勵
這和 Liblib 這類中國 AI 創作平台 很像，都是把模型能力、創作者生態與素材生產流程放進平台。差別在於 RunningHub 特別強調 ComfyUI 工作流、AI 應用和 API 的連動，對想把流程產品化的人更有吸引力。
工作流才是核心資產
RunningHub 的 ComfyUI 頁面不是只展示模型，而是展示大量工作流。像商品圖、角色設計、短劇分鏡、動作模仿、去水印、高清修復、影片超分、圖生影片等，都不是單一模型能解決的問題，而是由多個節點和步驟組成的流程。
這一點很重要。AI 內容創作正在從 prompt 時代走向 workflow 時代。單次生成可以靠運氣，多次穩定產出就需要流程。誰能把流程沉澱成模板、應用和 API，誰就更接近可複製的生產力。
這也能和 OpenMontage 本地影片工作流 放在一起看。一邊是本地自架、可控性更高，另一邊是平台化、上手更快。真正要選哪一邊，不是看哪個比較酷，而是看團隊需要的是控制權，還是交付速度。
API 讓 RunningHub 不只是一個網站
RunningHub 的 API 頁面有一個關鍵說法，單一接口可以直連 400 多個主流大模型。它也把能力拆成模型 API、AI 應用 API 和工作流 API。這代表開發者不一定要讓使用者進 RunningHub 網站操作，也可以把平台能力接進自己的產品。
官方列出的生產環境重點包括全模態聚合、工作流託管、彈性按需計費與企業級安全。這幾個詞不是行銷話術而已。對公司來說，真正麻煩的往往不是模型能不能跑，而是能不能穩定調用、能不能控權限、能不能算成本、能不能把工作流變成內部服務。
RunningHub 也提供 RH_CLI、RH_Skills、ComfyUI 插件與 AI Developer Kit。這些工具的意義是降低接入門檻。創作者可以從平台模板開始，工程團隊則可以把流程變成自動化服務。這和 AI 代理走向工作平台 是同一個方向，重點不只是模型，而是把模型放進可用的工作系統。
哪些人最適合用 RunningHub
我會把 RunningHub 的使用者分成四類。
電商與品牌團隊，需要大量商品圖、短影片、模特圖、場景圖和廣告素材。
短劇與內容團隊，需要分鏡、角色、場景、動作模仿和影像增強。
ComfyUI 創作者，想把自己的工作流變成模板、應用或可被調用的服務。
開發者與企業團隊，想用 API 把模型和工作流接進既有系統。
如果只是偶爾玩圖，本機工具或單一模型網站就夠了。如果是每天要產內容、測素材、上架商品、做短劇或替客戶交付，RunningHub 這種平台化工具才會開始有價值。因為它解決的不是單張圖，而是內容生產流程。
我會怎麼開始測
第一步不要先研究所有功能，而是挑一個真實任務。例如電商商品圖、短劇分鏡、社群廣告短片或角色一致性測試。用官方模板跑出第一版，記錄效果、成本和可修改程度。
第二步才是比較工作流。看同一個任務能不能換模型、改節點、調提示詞、保留角色一致性，或直接變成 AI 應用。這一步能判斷 RunningHub 是臨時工具，還是能進入你的固定流程。
第三步看 API。如果你要把內容生產接到網站、內部後台、自動化任務或客戶服務流程，工作流 API 才是長期價值。這時候就要評估調用成本、回傳格式、權限控管和失敗重試。
我的結論
RunningHub 的定位很清楚，它想把 ComfyUI 從高手工具變成內容生產平台，這件事不只是降低門檻，也是在改變 AI 創作的價值重心。過去大家比的是誰會寫 prompt，現在會慢慢變成誰能設計穩定工作流，誰能把工作流包成應用，誰能把應用接成 API。
如果你只想偶爾生成圖片，RunningHub 可能會顯得太大。如果你在做短劇、電商、廣告素材、品牌內容或 AI 工具產品，它就很值得看。因為它賣的不是單次生成，而是從創作、模板、工作流到 API 的整套生產鏈。
延伸資源
FAQ
RunningHub 是什麼？
RunningHub 是一個 AI 內容創作平台，整合 ComfyUI 工作流、AI 應用、無限畫布、模型 API 和工作流 API，適合把圖像、影片和內容流程平台化。
RunningHub 和本機 ComfyUI 有什麼差別？
本機 ComfyUI 自由度高，但需要自己管理環境、模型和顯卡。RunningHub 把工作流和模型能力雲端化，適合需要快速創作、分享模板、建立 AI 應用或調用 API 的團隊。
RunningHub 適合哪些場景？
它適合電商商品圖、短劇分鏡、品牌素材、影片生成、角色一致性、高清修復，以及把 ComfyUI 工作流變成可重複調用的內部工具或 API 服務。
by Rain Chu 6 月 6, 2026 | AI , 圖型處理
2026 年最受矚目的 AI 繪圖模型之一，莫過於 Ideogram 團隊正式釋出的：
Ideogram 4
這是 Ideogram 首次公開模型權重（Open Weight），也是目前開源陣營中，在：
文字生成（Text Rendering）
海報設計
品牌廣告
排版控制
JSON 結構化提示詞
官方 資料顯示，Ideogram 4 採用 9.3B 參數的單流 Diffusion Transformer（DiT）架構，並支援原生 2K 圖像生成。
本篇將帶你使用 ComfyUI，在本機部署 Ideogram 4。
系統需求
官方模型共有兩個版本：
版本 量化 Ideogram 4 FP8 品質最佳 Ideogram 4 NF4 VRAM需求較低
目前 ComfyUI 官方整合版本主要使用：
其中 FP8 畫質最佳。
第一步：下載模型
ComfyUI 專用模型
官方：
Comfy-Org Ideogram-4
原始模型：
Ideogram 4 FP8 官方 模型
第二步：放置模型檔案
依照官方說明建立目錄。
ComfyUI
│
├─ models
│ ├─ diffusion_models
│ │ ├─ ideogram4_fp8_scaled.safetensors
│ │ └─ ideogram4_unconditional_fp8_scaled.safetensors
│ │
│ ├─ text_encoders
│ │ └─ qwen3vl_8b_fp8_scaled.safetensors
│ │
│ └─ vae
│ └─ flux2-vae.safetensors 第三步：了解每個模型用途
ideogram4_fp8_scaled
主模型
負責：
ideogram4_unconditional_fp8_scaled
CFG 引導模型
負責：
提升細節
強化 Prompt Follow
改善品質
官方建議兩個模型一起使用。若只載入主模型雖可運作，但畫質會下降。
qwen3vl_8b_fp8_scaled
文字編碼器
負責：
Prompt 理解
JSON 理解
空間推理
海報版面配置
flux2-vae
VAE 解碼器
負責將 Latent 轉換成圖片。
第四步：更新 ComfyUI
Ideogram 4 需要最新版本的 ComfyUI。
更新方式：
或：
官方於 Day-0 即已原生支援 Ideogram 4。
第五步：載入官方 Workflow
ComfyUI 官方已提供範例工作流。
建議直接從：
Comfy Blog
下載 Workflow 。
基礎工作流架構
Prompt
↓
Qwen3-VL Encoder
↓
Ideogram 4
↓
Sampler
↓
Flux VAE Decode
↓
Save Image 第六步：第一張圖片
測試 Prompt：
A futuristic cyberpunk city at night,
neon signs in Chinese,
cinematic lighting,
ultra detailed,
high contrast,
8k photography 生成尺寸：
推理模式：
第七步：體驗 JSON Prompt
Ideogram 4 最大特色就是：
Structured JSON Prompt
官方模型訓練時即使用 JSON Caption。
範例：海報設計
{
"scene_summary": "Professional technology conference poster",
"background": {
"description": "Modern convention center stage with blue ambient lighting, large LED screen, clean professional environment"
},
"style": {
"description": "Corporate marketing design, professional conference poster, clean typography, premium branding, modern layout"
},
"objects": [
{
"description": "Conference stage",
"bbox": [100, 150, 900, 850],
"colors": ["#0A2540", "#1E88E5", "#FFFFFF"]
}
],
"text_elements": [
{
"text": "AI SUMMIT 2026",
"bbox": [150, 120, 850, 260],
"style": "Large bold white sans-serif title"
},
{
"text": "Future of Artificial Intelligence",
"bbox": [180, 280, 820, 350],
"style": "Medium white subtitle"
},
{
"text": "Taipei International Conference Center",
"bbox": [180, 1050, 820, 1120],
"style": "Small white footer text"
}
]
} Bounding Box 控制
可直接指定位置。
{
"text_elements":[
{
"text":"SALE 50%",
"bbox":[100,100,500,300]
}
]
} 座標範圍：
原點：
這是目前 FLUX 與 Stable Diffusion 所不具備的能力。
色彩盤控制
品牌設計超級好用。
{
"color_palette":[
"#FF6600",
"#FFFFFF",
"#000000"
]
} 官方支援：
與 FLUX 比較
FLUX 強項
Ideogram 4 強項
Logo
海報
Banner
電商素材
排版設計
中文文字生成
若你是：
Ideogram 4 很可能比 FLUX 更適合。
結論
Ideogram 4 不只是另一個 AI 繪圖模型。
它最大的創新在於：
把 Prompt 從自然語言升級為結構化設計規格。
透過：
Qwen3-VL
Diffusion Transformer
JSON Prompt
Bounding Box
Color Palette
使用者終於可以像操作 Figma 一樣控制 AI 生成內容。
對於需要：
海報設計
品牌素材
Banner 製作
AI Agent 自動產圖
的開發者來說，Ideogram 4 是目前最值得研究與部署的開源模型之一。
by rainchu 12 月 18, 2025 | AI , 圖型處理 , 影片製作
眾多 AI 創作平台之中，Liblib 憑藉其高度整合的功能、生態完整度以及對中文使用者的極致友善設計，迅速成為中國最領先的 AI 創作平台之一 。
一站式 AI 影像與視頻創作平台
Liblib 不僅僅是一個圖片生成網站，而是一個超級齊全的 AI 創作平台 ，涵蓋：
AI 圖片生成 AI 視頻特效與動畫 模型管理與分享 視覺化工作流（Workflow） LoRA 訓練與應用
透過雲端化的設計，使用者無需自行架設環境，即可直接在瀏覽器中使用高階 AI 生成能力。
深度整合 WebUI 與 ComfyUI
對於熟悉 Stable Diffusion 生態的使用者而言，Liblib 最大的優勢之一，在於它同時支援：
WebUI ：操作直覺、上手快速，適合大多數創作者ComfyUI ：節點式工作流，適合進階用戶進行複雜控制與自動化生成
這種雙軌並行的設計，讓初學者與專業用戶都能在同一平台中找到最適合自己的創作方式。
強大的 LoRA 訓練能力
Liblib 在 LoRA 訓練 方面表現尤為突出，提供完整且視覺化的訓練流程：
上傳資料集即可開始訓練
支援多種風格與角色 LoRA
訓練完成後可直接套用於生成
社群分享與模型市集機制
這讓創作者能快速打造專屬風格模型 ，大幅降低 AI 模型訓練的門檻。
中文使用者極度友善
相較於許多國外 AI 平台對中文支援不足，Liblib 在以下方面明顯優於同類產品：
完整繁體與簡體中文介面 中文 Prompt 理解度高
中文模型與 LoRA 資源豐富
適合華語創作者的社群內容
對中文內容創作者來說，這是一個真正「為中文而生」的 AI 創作平台。
工作流與創作效率全面升級
Liblib 內建的 工作流系統（Workflow） ，讓使用者可以：
將複雜生成流程模組化
重複使用高品質生成邏輯
快速套用他人分享的創作流程
大幅提升商業與批量創作效率
這對於需要大量產出視覺內容的團隊與個人創作者而言，是極具價值的功能。
為什麼 Liblib 是中國最領先的 AI 創作平台？
綜合來看，Liblib 的核心優勢包括：
✅ 視頻特效 + 圖片模型完整整合
✅ WebUI 與 ComfyUI 同時支援
✅ 強大且易用的 LoRA 訓練
✅ 中文高度友善，資源豐富
✅ 從新手到專業用戶皆適用
這不僅是一個工具，更是一個完整的 AI 創作生態系 。
官方網站
👉 Liblib 官方平台 https://www.liblib.art/
近期留言