https://www.communeify.com/tw/tag/vision/Communeify - Your Community PlatformHugohttps://www.communeify.com/tw/blog/prismml-ternary-bonsai-2-family-9b-gguf/https://www.communeify.com/tw/blog/prismml-ternary-bonsai-2-family-9b-gguf/Sun, 18 Oct 2026 01:20:00 +0800PrismML Ternary Bonsai 2 模型家族與 9B GGUF 完整解析：把 Qwen3.5 壓縮逾 9 倍的端側視覺語言代理模型在個人電腦、智慧型手機與穿戴式裝置上運行本地 AI 代理（On-Device AI Agents），模型必須在有限的記憶體與電力預算內做出準確決策。出自加州理工學院（Caltech）研究團隊、獲 Khosla Ventures、Cerberus、Google 與 Samsung 支持的 AI 公司 PrismML，於 2026 年 10 月 15 日正式發布 Ternary Bonsai 2 模型家族，推出基於 Qwen3.5 的 2B、4B 與 9B 三款三元權重（Ternary Weights）視覺語言模型，與既有的 Bonsai 2 27B 共同組成橫跨四種規模的產品線。 透過將權重編碼為 {-1, 0, +1} 三種數值，Ternary Bonsai 2 系列將 2B、4B 與 9B 模型的最小部署體積分別縮減至 0.43 GB、0.95 GB 與 2.00 GB，較全精度（FP16）版本縮小逾 9 倍。其中針對 llama.cpp 生態系釋出的 prism-ml/Ternary-Bonsai-2-9B-gguf，將原本約 17.9 GB 的 Qwen3.5-9B 語言模型壓縮至 2.00 GB（PTQ1_0 封裝）至 2.42 GB（預設 PQ2_0 封裝），完整保留 262K（262,144）Tokens 上下文視窗、視覺理解與工具呼叫能力，並以 Apache 2.0 授權開源。https://www.communeify.com/tw/blog/perplexity-pplx-decider-flash-v1-2-guide/https://www.communeify.com/tw/blog/perplexity-pplx-decider-flash-v1-2-guide/Sun, 18 Oct 2026 01:20:00 +0800Perplexity 開源輕量多模態決策模型 pplx-decider-flash-v1.2：以七分之一體積保留 27B 核心決策能力摘要：Perplexity AI 在 Hugging Face 釋出輕量級多模態決策模型 pplx-decider-flash-v1.2，基於 Qwen3.5-4B 架構，透過知識蒸餾與模型權重平均（Model Souping）技術，從 27B 規模的 pplx-decider-v1.2 蒸餾而成。該模型支援文字與最高 1.6 MP 的圖像輸入，僅需約 9 GiB 的 BF16 顯示記憶體即可部署，適合對延遲與推論成本高度敏感的分類、路由與評分場景。 模型定位與核心架構在實際生產環境中，將龐大的生成式語言模型用於分類、客服工單路由、工具檢索或內容審核，往往面臨延遲過高與算力成本昂貴的問題。Perplexity AI 推出的 pplx-decider-flash-v1.2 專為結構化決策任務設計，採用 Apache 2.0 授權條款開放權重。 pplx-decider-flash-v1.2 是 pplx-decider-v1.2（基於 Qwen3.8-27B）的小型化版本，參數規模約為 5B（基於 Qwen3.5-4B-Base 與 Qwen3.5-4B 微調），體積僅為 27B 版本的七分之一左右。模型具備以下四項核心設計特點： 全機率分佈知識蒸餾：學生模型在訓練過程中直接學習 27B 教師模型在訓練請求上的完整機率分佈，而非僅學習單一正確答案標籤，使小模型在未見過的決策任務（Held-out Tasks）上也具備良好的泛化能力。 權重平均（Model Souping）：模型結合了多次訓練運行的權重進行平均，在各項基準測試之間取得穩健的平衡。 分離式決策讀取頭（Readout Head）：模型不使用傳統的完整詞表語言模型頭（lm_head），而是配置一個 BF16 格式、維度為 [255, 2560] 的專屬決策讀取頭（readout.safetensors），並在每個問題結尾的 <|fim_suffix|> 標記位置直接讀取最多 255 個選項的 Logits。 混合注意力機制：完整注意力層（Full-attention layers）在整個請求序列上採用非因果（Noncausal）雙向注意力，而線性注意力層（Linear-attention layers）則維持原生因果行為。因此，一般預設的因果推論框架無法直接重現該模型的結果，需搭配官方提供的 pplx_decider 套件執行。 基準測試表現：Decision Index 0.3 與視覺能力根據官方公布的 Decision Index 0.3 公開基準測試與視覺決策測試結果，pplx-decider-flash-v1.2 在大幅縮減參數量的同時，保留了 27B 模型大部分的分類與多模態判斷能力，在工具調用（Tools）與檢索（Retrieval）項目上表現尤為接近。https://www.communeify.com/tw/blog/perplexity-pplx-decider-v1-2-and-flash-4b/https://www.communeify.com/tw/blog/perplexity-pplx-decider-v1-2-and-flash-4b/Sun, 18 Oct 2026 01:20:00 +0800Perplexity 開源多模態決策模型 pplx-decider-v1.2 與 Flash 4B 完整解析：聯合請求架構、Decision Index 評測與快速推論指南在建構 AI 代理（AI Agents）、客服路由、內容審核或檢索重排序（Reranking）系統時，工程團隊經常面臨一個效能瓶頸：如果為了判斷「是否需要人工介入」、「工單該分派給哪個部門」或「文章符合哪個評分等級」而呼叫傳統對話式大型語言模型（Chat LLM），不僅要承受自由文本生成的延遲與算力開銷，還必須在應用程式端撰寫複雜的正規表示式或 JSON 解析器來處理格式錯誤。 為了解決結構化決策場景的效率與機率校準問題，Perplexity 於 2026 年 10 月 16 日正式推出新一代開源多模態決策模型 perplexity-ai/pplx-decider-v1.2（27B 參數規模），並同步釋出體積僅約七分之一的輕量級蒸餾版本 perplexity-ai/pplx-decider-flash-v1.2（4B 參數規模）。兩款模型皆採用 Apache-2.0 授權協議，並於 OpenRouter 與 Vercel AI Gateway 同步上線。 本文依據 pplx-decider-v1.2 官方模型卡、pplx-decider-flash-v1.2 官方模型卡、Perplexity Decisions API 官方開發文件 與 OpenRouter 模型專頁，完整梳理這套決策模型的架構設計、聯合請求協議、基準評測數據、問題分組策略以及本地與雲端部署方式。 什麼是決策模型（Decision Model）？核心定位與三大問題型態根據 Perplexity Decisions API 官方文件 的定義，決策模型是一類專為「軟體可直接使用的快速結構化決策」所打造的模型。它如同多模態語言模型一樣能同時讀懂自然語言文本、結構化 JSON 與圖片，但不生成任何自由對話文字或推理過程（輸出 Token 數為 0），而是直接針對開發者定義的一或多個具名問題（Named Questions），回傳經過校準的機率分佈與型別化答案。 在 pplx-decider-v1.2 中，每次請求都由一個待評估的狀態脈絡（state，支援字串、字典、列表與最高 160 萬畫素圖片）以及一組問題（questions）組成。系統支援三種標準問題型態： 問題型態 (type)適用決策場景criteria 定義規範模型回傳結構 (answers) noul（是非二元判斷）條件閘門控制（如 Agent 工具呼叫安全審查、瑕疵判定、布林過濾）選填 {"true": 描述, "false": 描述}，定義何時為真或假noul：代表 $P(\text{true})$ 的機率值（介於 0 到 1 之間）choice（單選或多分類路由）客服工單分派、意圖分類、多標籤屬性勾選必填 {選項名稱: 描述或 None}，支援 1 至 255 個選項choice（最高機率選項）、probabilities（各選項機率分佈）、confidence（信心度）score（有序量表評分）嚴重程度分級、品質評分表（Rubric Grading）、潛在客戶評級必填由低至高排列的等級描述列表（本地 SDK 支援 2 至 255 級；雲端 API 支援 2 至 10 級）score（機率加權之期望等級索引）、probabilities（各等級機率）、legend（索引對照表）、confidence 透過這種設計，應用程式可以直接對模型回傳的機率設定門檻值（Thresholding）——例如當 noul >= 0.8 時自動放行代理執行資料庫操作，介於 0.4 至 0.8 時轉交人工審核，完全省去解析聊天文字的風險。https://www.communeify.com/tw/blog/openmoss-moss-image-5b-text-to-image/https://www.communeify.com/tw/blog/openmoss-moss-image-5b-text-to-image/Sun, 18 Oct 2026 01:20:00 +0800OpenMOSS 開源 MOSS-Image 5B 文生圖模型：原生支援 JSON 結構化排版與雙語長文渲染由上海創智學院（SII）、復旦大學、上海交通大學與 MOSI Intelligence 組成的 OpenMOSS 團隊，於 2026 年 10 月 16 日在 MOSS-Image 官方專案頁面 與 Hugging Face 正式開源 MOSS-Image 文生圖模型家族。該系列以 50 億參數（5B）的單流擴散 Transformer（Single-Stream DiT）為核心，同時釋出預訓練基礎模型 MOSS-Image-Base、監督微調模型 MOSS-Image-SFT 以及免安裝的 Hugging Face Spaces 線上互動 Demo。 相較於傳統開源文生圖模型在面對密集文字與多元素版面時容易出現字元扭曲或構圖混亂，MOSS-Image 在單一文本條件路徑中同時整合了自然語言描述、Booru 風格標籤序列（Tag Sequences）與 JSON 結構化版面控制。模型支援最長 4,096 個 Token 的輸入脈絡，能處理中英雙語長文渲染、海報設計、資訊圖表（Infographics）與 UI 介面生成，模型權重與推論程式碼均採用 Apache-2.0 授權條款開放商用與微調。 結合意圖感知提示詞代理與 5B DiT 解決圖文排版痛點根據官方發布的《MOSS-Image Technical Report》技術報告，生成包含密集資訊的視覺設計（如知識圖卡、商業海報或白板筆記）面臨兩項相互耦合的挑戰：文字與空間渲染能力（Rendering），以及從簡短指令轉化為具體版面規格的能力（Specification）。單純依賴提示詞擴寫無法保證底層模型能精確拼寫長文，而僅具備渲染能力的模型在面對「設計一張無尾熊知識資訊圖表」這類簡短指令時，往往缺乏合理的資訊層級與空間配置。 MOSS-Image 透過兩大模組協同運作解決上述問題： 支援文字與空間約束的 5B 單流 DiT 生成器：從頭預訓練 50 億參數的擴散 Transformer，將自然語言描述與結構化 JSON 版面座標統一於相同的文本條件介面（Text-Conditioning Pathway）中學習，使模型能直接聽懂邊界框（Bounding Box）座標與多行文字換行指令。 意圖感知代理提示詞增強模組（Agentic Prompt Enhancer）：在推論階段，MOSS-Image Prompt Enhancer 提示詞技能根據使用者輸入的媒介類型（如海報、資訊圖表或 UI）進行任務路由，自動檢索背景知識與視覺參考，並將少於十個字元的簡短需求轉換為包含逐字文本、元素描述、邊界框座標與排版層級的 JSON 規格。 採用 Qwen3.5-9B 與 FLUX.2 VAE 建構單流 5B 擴散架構在底層模型架構與預訓練流程上，官方技術報告揭露了多項針對長文本與複雜構圖的設計細節：https://www.communeify.com/tw/blog/meta-muse-spark-open-816b-a42b-guide/https://www.communeify.com/tw/blog/meta-muse-spark-open-816b-a42b-guide/Sun, 18 Oct 2026 01:20:00 +0800Meta Muse Spark Open (816B-A42B) 完整解析：原生多模態 MoE 架構、百萬上下文、評測數據與本地部署指南Meta Superintelligence Labs 於 2026 年 10 月 15 日正式釋出開放權重（Open-Weight）旗艦模型 Muse Spark Open（Hugging Face 權重代號為 meta-models/Muse-Spark-Open-816B-A42B）。官方將其定位為目前美國規模最大且能力領先的開放權重模型，專為長程代理工作流（Long-Horizon Agentic Workflows）、複雜軟體工程與多步驟深度推理所打造。 這款模型採用稀疏混合專家（Sparse Mixture-of-Experts, MoE）架構，具備 8,160 億（816B）總參數，在處理每個 Token 時僅激活約 420 億（42B）參數，並提供高達 100 萬（1M）Tokens 的上下文視窗。除了程式碼與文字處理外，Muse Spark Open 原生支援文字、圖片、音訊與影片四種模態輸入，讓開發者能透過單一模型同時閱讀大型程式碼庫、檢視螢幕截圖、聆聽語音備忘錄或分析螢幕錄影。 本文依據 Meta AI Research 官方發布部落格、Hugging Face 深度技術文章、Hugging Face 官方模型卡 以及 Meta 開發者技術部落格，完整整理 Muse Spark Open 的底層架構、多模態編碼設計、官方與第三方基準評測、Apple Silicon 桌面端部署方案、投機解碼加速與微調實戰指南。 核心架構拆解：816B 稀疏 MoE 與三大模態編碼器根據 Hugging Face 深度技術文章 與 官方模型卡 公開的架構細節，Muse Spark Open 是 Muse 模型家族的完整尺寸版本（同系列於 2026 年 8 月釋出的 Muse Glimmer 30B 為針對本地端常駐任務設計的輕量稠密模型，兩者共用相同的分詞器與詞彙表）。https://www.communeify.com/tw/blog/deepseek-v4-1-flash-1017-guide/https://www.communeify.com/tw/blog/deepseek-v4-1-flash-1017-guide/Sun, 18 Oct 2026 01:20:00 +0800DeepSeek-V4.1-Flash-1017 完整解析：552B 非對稱 CED 架構、11 項代理基準測試與本地部署指南DeepSeek（深度求索）於 2026 年 10 月 17 日正式開源並上線 DeepSeek-V4.1-Flash-1017，採用 MIT 開源授權。作為 DeepSeek-V4.1-Flash 的 10 月份更新版本，該模型延續了 552B 骨幹參數（含條件記憶與多模態模組之完整倉庫權重為 763B）的因果編碼器－解碼器（CED）稀疏混合專家架構，在預填充（Prefill）階段每 Token 僅激活 8B 參數、解碼（Decode）階段激活 16B 參數，並支援 100 萬（1M）Tokens 上下文視窗與原生圖像理解。根據 DeepSeek 官方發布公告，本次 1017 版本透過基於自反饋的強化學習（RL）大幅強化從零構建完整專案的「許願式編程」能力，在提升推理、程式開發、代理（Agent）與視覺基準表現的同時，進一步縮短任務執行時間與輸出 Token 長度。本文整理官方模型卡、技術報告與 API 文件的核心規格、11 項基準評測數據、部署方式與相關資訊。 DeepSeek-V4.1-Flash-1017 核心升級亮點根據 Hugging Face 官方模型卡與 DeepSeek API 官方新聞稿，本次 DeepSeek-V4.1-Flash-1017 更新聚焦於三個核心方向： 性能與成本的帕累托改進（更強、更快、輸出更精簡）：相較於 2026 年 9 月 10 日發布的初代 DeepSeek-V4.1-Flash，1017 版本在推理、程式碼、代理任務與多模態視覺基準上全面提升（例如 Terminal-Bench 4.0 從 31.2 分躍升至 42.3 分，ProgramBench 從 20.3 分提升至 29.1 分），同時縮短了模型執行代理任務的總耗時與輸出 Token 長度，在多個代理框架（Agent Harnesses）下降低單次任務的整體推論花費。 基於自反饋強化學習的「許願式編程」能力：官方公告指出，研發團隊採用基於自反饋的強化學習（Reinforcement Learning with Self-Feedback）後訓練技術，強化模型從零開始構建完整專案的端到端開發能力。在較少的提示詞與素材參考下，模型可在 DeepSeek Harness 等框架內以極短的互動輪次直接完成大型專案，官方展示案例包含： 故宮 3D 建模展示：直接透過程式碼建立精細的古建築群 3D 場景。 網頁版賽車遊戲：從零完成具備物理碰撞與賽道渲染的完整網頁遊戲。 基於 Godot 引擎的《傳送門 2》（Portal 2）復刻：構建包含傳送門空間邏輯與 3D 關卡的遊戲專案。 Valley of Ages 3D 動態歷史場景：以 3D 互動場景呈現從史前時代到現代文明的演進歷程。 主流代理框架適配與自研 Search / Fetch API 開放：本次更新特別針對 DeepSeek Harness（官方建議升級至 v0.2.1-rc.1 或以上版本）、騰訊 CodeBuddy、WorkBuddy、Claude Code 與 Mini-SWE-V2 進行最佳化。此外，支撐 DeepSeek 網頁端與 App 每日數億次請求的自研 AI 原生搜尋引擎，也隨本次更新正式對外開放 Search API 與 Fetch API（定價皆為每千次成功呼叫 5 元人民幣 / 0.75 美元，並具備過濾 SEO 作弊、GEO 操縱與低品質 AIGC 內容的識別機制）。 底層架構解析：為什麼骨幹是 552B，而模型頁顯示 763B？初次檢視 DeepSeek-V4.1-Flash-1017 模型卡的開發者常會注意到一個數字差異：官方技術報告《DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression》與相關評測頁均標示其為 552B 骨幹參數，但 Hugging Face 右側欄的 Safetensors 模型大小卻顯示 763B params（完整檔案總容量約 510 GB）。https://www.communeify.com/tw/blog/black-forest-labs-flux-3-image-klein-guide/https://www.communeify.com/tw/blog/black-forest-labs-flux-3-image-klein-guide/Sun, 18 Oct 2026 01:20:00 +0800Black Forest Labs 開源 5.6B 視覺生成與編輯模型 FLUX 3 Image Klein：架構原理、ComfyUI 部署與實戰指南Black Forest Labs（BFL）於 2026 年 10 月 15 日正式發布 FLUX 3 Image Klein，這是繼機器人控制模型 FLUX 3 Action 之後，FLUX 3 多模態家族釋出的第二款開放權重（Open Weights）模型。同日，Hugging Face Diffusers 與 ComfyUI 也同步完成首日原生支援。 FLUX 3 Image Klein（Hugging Face 權重庫） 的影像生成 Transformer 參數規模為 56 億（5.6B），在單一模型權重中同時整合了文字生成影像（Text-to-Image）、指令驅動影像編輯（Instruction-Driven Image Editing）、最多 10 張參考圖的多圖合成（Multi-Reference Generation），以及原生 0–1000 座標邊界框（Bounding Boxes）佈局控制，並支援最高 原生 4K 解析度直出。透過與 NVIDIA 合作開發的 INT8 ConvRot 量化與 16 步時間步蒸餾（Step-Distilled）權重，該模型可在僅有 8GB VRAM 的消費級 RTX 顯卡上透過 ComfyUI 本地運行。 本文整合 Black Forest Labs 官方發布部落格、Hugging Face 官方模型卡、ComfyUI 官方部落格、ComfyUI 官方教學文件 以及 Hugging Face Diffusers 架構解析專文，完整梳理 FLUX 3 Image Klein 的兩階段流匹配架構、4D RoPE 位置編碼、硬體效能實測、提示詞擴寫（Prompt Upsampler）機制、邊界框語法，以及本地部署與 LoRA 微調指南。https://www.communeify.com/tw/blog/openbmb-minicpm-v-4-7/https://www.communeify.com/tw/blog/openbmb-minicpm-v-4-7/Thu, 15 Oct 2026 00:05:00 +0800文章摘要：清華大學自然語言處理實驗室（THUNLP）與面壁智能（ModelBest）於 2026 年 10 月 12 日正式開源 MiniCPM-V 4.7 多模態大模型系列，採用 Apache-2.0 授權協議。本次更新同步推出系列首款混合專家架構模型 MiniCPM-V-4.7-35B-A3B 與輕量級稠密模型 MiniCPM-V-4.7-1B，延續單圖、多圖、文件解析與影片理解能力，並結合自研前瞻專家調度（LES）、精細層級量化與 DSpark 投機取樣技術，讓 35B 級 MoE 模型在行動裝置端流暢運行。本文完全依據官方開源倉庫與模型卡資料，整理兩款模型的技術細節、實測數據、推論參數與完整官方連結。 MiniCPM-V 4.7 系列核心定位與雙規格概覽根據 OpenBMB/MiniCPM-V 官方 GitHub 倉庫與官方中文技術指南，MiniCPM-V 4.7 針對不同算力與記憶體條件的端側與本地場景，提供兩種規格： MiniCPM-V-4.7-35B-A3B：這是 MiniCPM-V 系列首款混合專家（MoE）模型，總參數量為 35B，單次激活參數為 3B。官方測試指出，透過自研的前瞻專家調度（LES, Lookahead Expert Scheduling）技術、精細層級量化與 DSpark 投機取樣，該模型在 iPhone 17 Pro Max 上僅需 3 GB 記憶體即可達到每秒 13 個 Token 以上（13+ tokens/s）的解碼速度，且不犧牲模型原有的路由精度。在 Instruct 模式下，35B-A3B 以更短的推論時間取得高於 Qwen3.6 35B-A3B 的綜合評測得分。 MiniCPM-V-4.7-1B：針對輕量級端側部署設計的 1B 級稠密（Dense）模型（Hugging Face 模型頁標籤顯示包含視覺模組之總參數規模約 2B），體積小巧，可完整常駐於行動裝置記憶體中。根據 1B 官方模型卡，1B 版本在 Instruct 模式下持續提升前代 MiniCPM-V 4.6 的基礎能力，並在綜合評測得分與推論效率上顯著領先 Qwen3.5 0.8B。 全系列程式碼與模型權重均採用 Apache-2.0 授權協議，支援 iOS、Android 與 HarmonyOS NEXT 作業系統，並於發布首日支援瑞芯微（Rockchip）、後摩智能（Houmo）、Intel、AMD 與 Arm 等晶片平台。https://www.communeify.com/tw/blog/decision-3-0-open-multimodal-decision-models/https://www.communeify.com/tw/blog/decision-3-0-open-multimodal-decision-models/Mon, 12 Oct 2026 21:05:00 +0800開源多模態決策模型 Decision 3.0：架構規格、推論延遲與應用場景解析vLLM Semantic Router 團隊推出開源多模態決策模型家族 Decision 3.0，涵蓋 0.6B 至 27B 共六種參數規格。本文整理其以機率分佈為核心的分類架構、對文字、圖片與影片的判讀能力，以及在基準測試和推論延遲上的官方實測數據。 在現行的大型語言模型應用架構中，許多系統環節並不需要模型產出長篇文字，而是需要快速、精準的分類與路由判斷。例如在多模型協作系統中，系統必須先判斷使用者的提問屬於程式碼、數學推導還是日常對話，再將請求派發至合適的後端模型。過去這類工作常仰賴生成式模型輸出特定標籤，或是使用小型特製分類器。然而生成式模型延遲較高，小型分類器又往往缺乏足夠的上下文理解與跨模態能力。 為了解決這類決策需求，vLLM Semantic Router 開發團隊在 Hugging Face 上的 Decision 3.0 系列集合頁面 開源了 Decision 3.0（代號 d3）模型家族，並在 Reddit 的 LocalLLaMA 社群討論串 公布相關架構與評測成果。該系列以 Apache-2.0 授權釋出，主打無文字生成的單次前向傳遞決策機制，並將多模態輸入延伸至圖片與影片。 Decision 3.0 的核心運作機制：放棄文字生成，直接回傳結構化機率傳統生成式模型在處理分類問題時，通常需要透過自回歸解碼迴圈逐步生成 Token，再由應用端解析字串。這個過程不僅消耗運算資源，還可能因為格式解析失敗或幻覺而增加系統的不穩定性。 Decision 3.0 採取不同的設計取向。模型不包含文字解碼迴圈，而是專門負責計算特定選項的機率分佈。當應用端輸入一段狀態（可為純文字或 JSON，並可附帶圖片與影片）以及一組具名問題時，模型會直接回傳每種選項的數值機率。 開發團隊在架構中定義了三種核心問題類型： Choice（選項分類）：從給定的多個類別中挑選最符合的項目，模型會列出每個類別的獨立機率。 Yes/No 或 Noul（二元判定）：針對特定條件進行肯定或否定的判斷，例如檢查輸入是否需要多步驟推理。 Score（尺度評分）：在連續或離散的數值區間內給出評估分數。 值得注意的是，Decision 3.0 支援在單次呼叫中同時解答多個問題。模型會針對同一個輸入狀態，為每個問題執行各自的前向傳遞，並集中回傳所有問題的機率分佈。這項特性讓開發者能在單一 API 呼叫內完成多維度的內容檢驗，降低網路往返延遲。 從 0.6B 到 27B：Decision 3.0 的模型家族與基底架構Decision 3.0 家族依據不同算力環境與延遲要求，共推出了六個尺寸規格。所有模型均以 Qwen 系列作為骨幹網路進行構建，參數總量已將視覺編碼器計入： d3（26.09B）：以 Qwen3.8-27B 為基礎，內含 0.46B 視覺編碼器，屬於該家族體積最大且準確度最高的旗艦版本。 d3-flash（8.39B）：以 Qwen3.5-9B 為基礎，配置 0.46B 視覺編碼器。官方評測指出其綜合表現超越前一代 27B 規格的 Decision 2.0。 d3-mini（4.54B）：以 Qwen3.5-4B 為基礎，內含 0.33B 視覺編碼器，適合中階顯卡配置。 d3-nano（2.21B）：以 Qwen3.5-2B 為基礎，內含 0.33B 視覺編碼器，可在 8 GB 記憶體的環境順暢執行。 d3-lite（0.85B）：以 Qwen3.5-0.8B 為基礎，配置 0.10B 視覺編碼器。 d3-edge（0.59B）：同樣以 Qwen3.5-0.8B 為基礎進行精簡，配置 0.10B 視覺編碼器，專為邊緣運算裝置設計。 全系列權重均以 BF16 格式釋出，開發者可透過 Transformers 套件直接載入（需設定 trust_remote_code=True），亦可搭配 vLLM Semantic Router 的 Engine 模式以 System One API 形式本機啟動。https://www.communeify.com/tw/blog/digup-mac-semantic-local-file-search/https://www.communeify.com/tw/blog/digup-mac-semantic-local-file-search/Mon, 12 Oct 2026 21:05:00 +0800用語意理解搜尋 Mac 本地檔案：開源工具 DigUp 技術架構與運作解析DigUp 是一款專為 Apple Silicon Mac 設計的開源本機搜尋工具，結合 Google DeepMind 的多模態模型 EmbeddingGemma 2 與 llama.cpp。使用者只要以自然語言描述畫面或對話內容，就能快速定位圖片、PDF、影音與程式碼片段。 在日常使用電腦的過程中，尋找檔案往往受限於檔名或純文字關鍵字。若忘記簡報確切名稱，或是想找影片中某個特定畫面、錄音檔裡的一句發言，傳統的系統搜尋功能往往難以直接命中。 近期在 GitHub 上開源的 DigUp 專案，嘗試以端到端本機運算解決這個問題。它讓使用者直接用白話描述尋找目標，無論是「海灘上的狗」、「影片中斑馬出現的段落」還是「合約中關於寵物的條款」，系統都能透過多模態向量比對，將檔案與精確時間點或頁碼呈現在讀者眼前。 多模態向量空間：EmbeddingGemma 2 的底層支援DigUp 之所以能跨越文字與圖像的藩籬，核心在於 Google DeepMind 推出的開源模型 EmbeddingGemma 2。該模型參數量為 740M，採用 Apache 2.0 授權，足以在筆記型電腦上順暢執行。 這套模型將文字、圖片、語音與視訊影格映射至同一個 768 維度的向量空間。這項特性的實際效果在於： 一張海灘狗兒的照片，在數學空間中的位置會非常接近文字「a dog on the beach」；一段談論睡眠的語音片段，也會落在「where they talk about sleep」的語意範圍附近。模型本身具備多語言理解能力，涵蓋超過 100 種語言，因此即使輸入英文查詢，也能檢索到以其他語言撰寫的筆記內容。 本機隱私與技術運作流程許多使用者對 AI 搜尋工具最關心的問題是資料隱私。DigUp 採取純本機運算（Local-first）架構，除了首次啟動時下載模型檔案以及每日一次的自動更新檢查之外，不會對外傳輸任何檔案內容與索引資料。使用者也可以手動關閉每日更新檢查，完全杜絕聯網行為。 索引與比對架構DigUp 在背景的運作流程可拆解為三個主要階段： 檔案讀取：透過 macOS 系統原生的 ImageIO、PDFKit、AVFoundation 讀取多媒體與文件，並使用 Apple Vision 框架辨識截圖內的文字。 向量產生：透過以 Metal 加速的 llama.cpp 執行 8-bit 量化版 EmbeddingGemma 2，計算出各片段的向量。這個輔助程序只在索引時運作，建立完成後即自動釋放記憶體。 本機儲存與混合檢索：所有向量資料與關鍵字索引皆寫入單一 SQLite 資料庫。 當使用者按下快捷鍵發起查詢時，系統僅載入約 250 MB 的文字編碼器，在數毫秒內將搜尋詞轉換為向量，並與資料庫進行相似度比對。此外，考量到發票號碼、錯誤代碼或特定人名等精確字串難以完全依賴向量表徵，DigUp 同時保留了精準字詞比對機制，提高專有名詞搜尋的準確率。https://www.communeify.com/tw/blog/cloudflare-clef-omni-multimodal-decision-model/https://www.communeify.com/tw/blog/cloudflare-clef-omni-multimodal-decision-model/Mon, 12 Oct 2026 21:05:00 +0800Cloudflare 推出多模態決策模型 Clef-omni：支援音訊與影像輸入，同步調降 Clef-flash 費用與提升推論速度Cloudflare 發表支援音訊、影片、圖片與文字輸入的多模態決策模型 Clef-omni，以 Qwen3-Omni 為基礎架構，省略自由文字生成步驟，直接對指定題目計算選項機率。同時，官方宣布將託管版 Clef-flash 的輸入費用調降至每百萬 Token 0.038 美元，並透過 SGLang 伺服架構最佳化，使標準 Clef 模型的推論速度提升達 1.7 至 2 倍。 在自動化工作流程中，傳統決策管線往往需要串聯語音轉文字、影像辨識等多個專門模型，或是依賴大型語言模型輸出 JSON 格式。這類做法常面臨較高的運算延遲與輸出解析失敗風險。針對此類需求，Cloudflare 擴展了先前的開源決策模型系列，在 Cloudflare 官方部落格 正式推出具備跨模態理解能力的 Clef-omni，並針對現有模型提供更低的計費與更快的處理速度。 Clef-omni 架構解析：跳過文字生成的決策流程多數多模態語言模型在處理分類或決策任務時，通常必須經過自回歸解碼產生文字標籤，再由程式進行正規表達式或 JSON 解析。Clef-omni 採取了不同的運作方式，將重心放在單次推論評分上。 以 Qwen3-Omni 為核心的混合專家基礎根據官方技術說明，Clef-omni 採用開源模型 Qwen3-Omni-30B-A3B-Instruct 的混合專家（MoE）架構作為主幹。研發團隊保留了原模型的文字、影像與音訊編碼主幹，但捨棄了文字轉語音（TTS）相關元件。 由於模型定位為專用決策模型而非生成式語言模型，系統在接收多模態資料後，不進行檔案轉錄或圖片標註，而是直接執行預填（prefill）階段。音訊與影像資料會映射至同一序列中進行聯合處理，大幅降低預處理負擔。 雙階段注意力機制與聯合架構頭Clef-omni 藉由微調低秩適應模組（LoRA），並結合標籤平滑交叉熵損失與布萊爾分數（Brier score）校準進行後訓練。 在推論機制上，模型採用兩階段注意力路由。每個題目選項會先從輸入的文字、畫面或音訊串流中擷取證據特徵，接著透過聯合架構頭（Joint schema head）讓各欄位向量跨全上下文進行注意力計算，直接輸出每個選項的對數機率（Logits）。 透過 Softmax 運算後，系統能直接回傳機率數值。這種設計配合內建的詞彙語法限制，確保輸出結果嚴格符合既定綱要，避免格式錯誤。 支援格式與題型規範Clef-omni 相容於 Jev 與 SystemOne API 規範，且程式碼已透過 Apache-2.0 授權於 Hugging Face 模型庫 開源。 輸入資料支援以下類型： 文字與結構化資料：自然語言字串或 JSON 物件 靜態影像：支援 PNG、JPEG 等格式（本機環境需搭配 Pillow） 音訊檔案：支援 WAV 與 MP3，支援 16 kHz 單聲道取樣陣列 影片檔案：支援 MP4 與 WebM，預設以每秒 2 幀取樣，支援影音同步音軌（需搭配 av 函式庫） 在問題定義方面，模型提供三種判定型態：https://www.communeify.com/tw/blog/auroraimg-6m-lightweight-text-to-image-model/https://www.communeify.com/tw/blog/auroraimg-6m-lightweight-text-to-image-model/Mon, 12 Oct 2026 21:05:00 +08006.82M 輕量級文生圖模型 AuroraIMG-6M 技術架構與評測解析AuroraIMG-6M 是一個參數量僅 6.82M 的極輕量文生圖模型，涵蓋文字編碼器、去噪器與 VAE，完全由零開始在 CC12M 資料集上訓練完成。本文詳細解析其架構設計、訓練流程、評測數據與硬體適用限制。 現今主流的文字生成圖片模型通常擁有數億甚至數十億參數，且多半仰賴預訓練的大型文字編碼器（例如 CLIP 或 T5）與預訓練 VAE 來建構生成流程。由研究團隊在 AuroraAI-Research 的 Hugging Face 專案頁面 開源的 AuroraIMG-6M，則採取截然不同的實驗方向。 該專案嘗試驗證在極度受限的參數量下，是否能單純依靠小規模資料集從零訓練完整的文生圖系統。整個模型包含文字編碼器、去噪模型與變分自動編碼器（VAE），總參數量僅約 6.82M，能在一般個人電腦甚至 CPU 環境下完成推論。 輕量化文生圖設計：全模組 6.82M 參數從頭訓練AuroraIMG-6M 的原生生成解析度設定為 64×64 RGB。這項專案的所有模組均未借用任何既有的預訓練權重，全部以 pixparse 整理的 CC12M 資料集 進行自主訓練。 模型的參數配置相當精簡： 文字編碼器（Text Encoder）：約 1.32M 參數 去噪器（Denoiser）：約 4.42M 參數 變分自動編碼器（VAE）：約 1.08M 參數 這三個模組加總僅 6.82M，相較於 Stable Diffusion 1.5 單是 U-Net 就高達 0.86B 參數，AuroraIMG-6M 的體積縮小了超過百倍。 三大核心組件技術細節為了在極低參數量下維持合理的生成表現，AuroraIMG-6M 針對各個模組進行了針對性的架構精簡與損失函數設計。 1.08M 卷積 VAE該模型配備的 VAE 負責將 64×64×3 的輸入影像壓縮成 8 個通道、尺寸為 16×16 的潛在空間特徵（Latent）。https://www.communeify.com/tw/blog/youtu-parsing-omni/https://www.communeify.com/tw/blog/youtu-parsing-omni/Sat, 10 Oct 2026 00:05:00 +0800騰訊開源 5B 全模態解析模型 Youtu-Parsing-Omni：統一架構處理文件、圖表、音訊與影片騰訊優圖實驗室發布 50 億參數規模的全模態結構化解析模型 Youtu-Parsing-Omni，主打單一編碼器與統一 OmniSchema JSON 輸出格式。模型能直接解析一般文件、複雜圖表、幾何圖形、音訊以及視訊內容，並同步完成感知標註與語意摘要。本文整理該模型的技術架構、官方評測數據、部署注意事項與授權限制。 企業在建立知識庫或檢索增強生成（RAG）系統時，經常面臨跨模態資料格式不一致的困境。一份專案資料可能同時包含掃描合約、會議錄音、簡報投影片與產品展示影片，以往需要分別呼叫光學字元辨識、圖表分析與語音轉文字等多套專用工具，再由工程團隊手動拼接輸出欄位。針對這類繁瑣的資料前處理流程，騰訊優圖實驗室推出了 5B 規模的開源權重模型 Youtu-Parsing-Omni，嘗試以單一模型處理多種媒體格式，並將結果輸出為標準化的 JSON 資料。 什麼是 Youtu-Parsing-OmniYoutu-Parsing-Omni 是騰訊優圖實驗室推出的輕量級全模態解析模型，參數量約為 53 億（5.33B BF16）。根據開發團隊在 Hugging Face 專案頁面 與 GitHub 技術報告路徑 所公布的資訊，該模型能接收文件頁面、照片、統計圖表、流程圖、幾何圖案、音訊檔案以及影片，並針對不同任務輸出統一格式的 JSON 結果。 傳統的多模態解析工具通常只輸出 Markdown 文字，但 Youtu-Parsing-Omni 將解析目標擴展為感知（Perception）與認知（Cognition）兩層結構。在感知層面，模型會偵測版面元素的位置座標（Bounding Box）、識別文字內容、轉換數學公式為 LaTeX、將表格轉為 Markdown 或 OTSL，並標記語音說話者與時間戳。在認知層面，模型則會根據整體輸入產出全域摘要、說明文字或結構化分析報告。 模型依據任務提示詞（Task Prompt）切換解析模式，涵蓋以下七大解析家族： 文件頁面（document）：解析文字段落、表格、公式、流程圖與閱讀順序。 自然圖像（natural_image）：標記實體邊界框、物件標籤、局部描述與全域場景說明。 統計圖表（graphics_chart）：將長條圖、折線圖或圓餅圖還原為 Markdown 表格與文字說明。 流程圖（graphics_flowchart）：將圖形關係轉譯為 Mermaid 流程圖語法。 幾何圖形（graphics_geometric）：識別幾何點、線段、圓弧與尺寸標註數據。 音訊片段（audio）：區分語音與非語音區間，輸出時間戳、說話者標籤、語音轉文字（ASR）與聲學事件描述。 視訊內容（natural_video 與 textrich_video）：針對自然影片記錄動作、鏡頭移動與聲音事件，針對演講或教學影片則同步進行畫面 OCR 與語音辨識，產生整段影片的結構化總結報告。 單一編碼器與感知層音視頻融合機制多數現行的全模態系統習慣採用雙塔架構，也就是影像與聲音分別透過兩個各自預訓練的模型進行編碼，直到進入大型語言模型（LLM）解碼器時才進行特徵交會。Youtu-Parsing-Omni 則選擇不同的技術路線。 共享權重的 Youtu-Omni-Encoder研發團隊設計了 Youtu-Omni-Encoder，以文字語言模型作為權重初始化的基礎，以此強化模型對符號與排版結構的先驗理解能力。輸入端透過輕量化的模態專用通道（Stem），將影像像素轉換為視覺 token，同時將音訊的 log-mel 頻譜圖轉為音訊 token。 進入核心的雙向 Transformer 時，所有模態的特徵都會被放入同一個張量中進行計算。由於影像、音訊與影片共用絕大部分編碼器參數，模型在感知階段就能直接對不同訊號建立關聯，減少雙塔架構在特徵轉換時產生的資訊耗損。 時序座標對齊與感知層內部融合在處理影片輸入時，視訊影格與音訊切片會依照時間順序交錯排列。Youtu-Parsing-Omni 採用統一的三維座標系統 (t, h, w) 進行位置編碼。https://www.communeify.com/tw/blog/lightonocr-3-4b/https://www.communeify.com/tw/blog/lightonocr-3-4b/Sat, 10 Oct 2026 00:05:00 +0800開源視覺文件解析新選擇：LightOnOCR-3-4B 架構特點與應用解析法國人工智慧團隊 LightOn 正式開源 LightOnOCR-3-4B 模型，採用 Qwen3.5 視覺語言架構與 Apache 2.0 授權，提供整頁文字轉錄與精準視覺定位雙模式，能直接將複雜文件轉換為結構化 Markdown、圖表資料與座標標籤，有效降低企業打造文件處理流程的維護成本。 傳統光學字元辨識工具在處理包含多欄排版、複雜表格、手寫註記與統計圖表的文件時，往往需要串接多個獨立模型與啟發式規則。這種多階段管線除了提高部署與除錯難度，不同模組之間的誤差也容易累積放大。針對這項實務瓶頸，LightOn 推出了第三代開源光學字元辨識模型系列，其中最大規格的 LightOnOCR-3-4B 結合了文字轉錄與版面理解能力，提供開發者更簡潔的端到端解決方案。 LightOnOCR-3 系列規格與核心設計LightOnOCR-3 全系列均以開源形式釋出，涵蓋三種不同參數量級，方便開發者依據運算資源與辨識精度需求進行選型。 在模型架構方面，0.8B 與 4B 版本改採 Qwen3.5 視覺語言架構，相較於前代架構能更有效整合現有的推論引擎生態。1B 版本則保留 LightOnOCR-2 的專屬模型結構，適合希望直接平滑升級現有系統的使用者。全系列皆採用寬鬆的 Apache 2.0 開源授權，允許學術研究與商業系統自由使用。 模型版本參數規模架構特點適用情境 LightOnOCR-3-4B4.0BQwen3.5 視覺語言架構系列中辨識精度最高，適合各類複雜排版與圖表解析LightOnOCR-3-0.8B0.8BQwen3.5 視覺語言架構運算資源受限但要求高處理效率的邊緣或高通量環境LightOnOCR-3-1B1.0BLightOnOCR-2 專屬架構現有 LightOnOCR-2 部署架構的直接升級替代方案 轉錄與定位雙模式：彈性應對不同下游需求LightOnOCR-3-4B 透過簡單的文字提示詞即可切換輸出型態，大幅簡化系統整合門檻。https://www.communeify.com/tw/blog/liquid-ai-d1-3b/https://www.communeify.com/tw/blog/liquid-ai-d1-3b/Sat, 10 Oct 2026 00:05:00 +0800Liquid AI 開源決策模型 d1-3B：單次前向傳播的多模態判斷架構解析本篇介紹 Liquid AI 開源的 3.12B 多模態決策模型 d1-3B。文章深入探討其單次前向傳播、零輸出 Token 的技術特點，整理在 Decision Index 與邊緣硬體上的延遲測試數據，並說明該模型在分類、路由與安全防護等任務中的實際應用情境。 在多數自動化流程與系統閘道中，系統往往只需要明確的分類標籤、布林值或數值評分，而非冗長的對話回覆。傳統生成式大型語言模型仰賴自回歸生成，每產出一個 Token 就需執行一次運算，導致推論延遲與伺服器成本居高不下。 針對這類任務導向的判定需求，Liquid AI 釋出了開源權重模型 LiquidAI/d1-3B 模型頁面，並在 官方發布公告 中公布了架構細節與測試指標。d1-3B 並非文字生成模型，而是專門用於單次輸入、立即給出校準判斷結果的決策模型。 什麼是決策模型：零輸出 Token 與單次前向傳播機制一般語言模型在接收 Prompt 後，會逐字生成字串回應，需要反覆調用模型權重。d1-3B 採取不同的設計方向，將推論目標限定於狀態理解與預設問題的解答。 模型接受一個狀態（包含純文字、JSON 格式資料、圖片或兩者混合）以及一組預設問題。在一次前向傳播的過程中，模型會直接輸出帶有類型標註與信心分數的判斷結果。 這種設計使模型的輸出 Token 數維持在零（output_tokens: 0）。因為不需要自回歸解碼，推論延遲大幅降低，輸出結果也能直接對接既有程式的資料結構，不需要再撰寫正則表達式或額外解析 JSON 字串。 三種標準問題型態與校準機制d1-3B 遵循 Decision Index 的結構定義，主要支援三種提問型態： 布林判斷（noul）：判斷特定條件是否成立，回傳成立的機率值 P(yes)。 選項分類（choice）：從預先定義的具名選項中挑選最符合的一項，並回傳各選項機率與總體信心度。 程度評分（score）：在兩階至十階的有序等級中給予評分，回傳期望數值等級、機率分佈與對應說明。 由於模型經過專門的校準訓練，輸出的機率值更貼近真實信心水準，適合用於自動化分流與門檻過濾。 d1-3B 的核心規格與訓練方法根據官方技術文件與 LFM2 技術報告，d1-3B 擁有約 3.12B 參數，基礎模型衍生自 Liquid AI 自家的視覺語言模型 LFM2.5-VL-3B。 硬體規格與架構組成d1-3B 的主要架構規格包含： 參數量：3.12B 視覺編碼器：SigLIP2 NaFlex 形狀優化架構（約 400M 參數） 上下文長度：32,768 tokens 詞表大小：128,000 模型在視覺處理上整合了 SigLIP2 編碼器，支援原生形狀優化輸入，能直接處理不同長寬比的圖像，而不需要強制扭曲或過度裁切。https://www.communeify.com/tw/blog/agnes-3-0-flash/https://www.communeify.com/tw/blog/agnes-3-0-flash/Fri, 25 Sep 2026 17:07:22 +0800Agnes-3.0-Flash Preview：為高效能運算打造的多模態模型新選擇追求高階 AI 推理與多模態能力時，開發者常面臨頂級模型硬體門檻極高或完全封閉的困境。Agnes AI 發布了 Agnes-3.0-Flash Preview 開放權重多模態預覽模型，採用 Apache-2.0 開源授權，旨在讓開發者能在自有硬體上運行具備旗艦級推理、程式編碼與長上下文處理能力的模型。 該開放權重模型擁有 33B（330 億）參數與原生 262,144 tokens（262K） 上下文視窗，同時支援文字、圖像與影片的多模態輸入理解。 混合注意力機制與架構特點Agnes-3.0-Flash Preview 採用了高效的混合注意力解碼器（Hybrid-attention Decoder）： 72 層解碼器結構：由 54 層門控增量規則（Gated Delta Rule 遞迴層）與 18 層全域注意力（Global Attention）交替組成（比例為 3 : 1）。 降低 KV Cache 壓力：每 4 層中僅有 1 層需要維護會隨上下文長度增長的 KV Cache，其餘 3 層為狀態尺寸獨立於序列長度的遞迴層，能顯著降低長文本處理時的顯存需求。 視覺處理：內建 27 層 Vision Tower（隱藏層 1152、Patch 大小 16、2×2 空間合併），投影映射至 5120 主維度。 核心功能與推論控制 多模態理解：搭配內建的 AutoProcessor，可直接輸入圖像（Image）與影片（Video）進行理解與分析。 思考強度控制（Reasoning Effort）：Chat Template 支援可調式的思考強度，可傳遞 reasoning_effort="high"（預設，適合複雜推理）、medium、low，或設定 enable_thinking=False 直接關閉思維鏈以降低延遲。 原生工具調用（Tool Calling）：原生支援 Function Calling，模型會輸出 <tool_call> 標籤格式，便於掛載外部 API 或資料庫操作。 官方 Benchmark 評測（Preview 開放權重版本）官方模型卡公布了 Preview 開放權重 checkpoints 的評測結果：https://www.communeify.com/tw/blog/jina-ocr-v1/https://www.communeify.com/tw/blog/jina-ocr-v1/Fri, 25 Sep 2026 17:06:10 +0800Jina OCR v1：把文件轉成可用的 Markdown將 PDF、掃描檔或複雜版面交給 OCR，真正困難的往往不只是辨識文字，還包括表格、公式、段落與閱讀順序。Jina AI 開源的 Jina OCR v1 是一款端到端（Page-to-Markdown）的文件解析模型，旨在兼顧高品質輸出與高效推論，直接將文件頁面轉化為結構化的 Markdown。 模型架構與技術重點Jina OCR v1 採用輕量化與混合專家（MoE）架構設計： 模型規模：總參數量為 3.4B，但前向傳播每個 Token 僅需激活約 570M 活躍參數，兼具小模型的推論成本與大模型的容量。 視覺與解碼器架構：繼承 DeepSeek-OCR 架構，包含約 380M 參數的 DeepEncoder（將 1024×1024 圖像壓縮為 256 個視覺 Tokens），以及 12 層的 DeepSeek-3B-MoE 解碼器（64 個 Routed Experts 與 2 個 Shared Experts，Top-6 路由）。 FastMTP 投機解碼（Speculative Decoding）：透過遞迴共享單一密集草稿模組（K=3），並結合貪婪驗證（Greedy Verification），實現無損（Lossless）的解碼加速，產出與傳統自回歸完全一致的文字。 多語言與頁面處理：預訓練語料覆蓋約 100 種語言（支援多達 108 種語言）；預設會過濾重複的頁首與頁尾（Headers/Footers），並自動將公式轉為 LaTeX（$ / $$）、表格轉為 HTML <table> 格式。 評測表現與速度（標示測試條件）在官方報告的實測基準中，Jina OCR v1 展現出極高的推論吞吐量： OmniDocBench v1.6 評測：整體得分 91.14（公式 CDM 達 93.28、表格 TEDS 達 84.68）。 olmOCR-Bench 評測：整體得分 83.4（Base 基礎文本達 99.9、表格 88.8、多欄排版 85.5；但在嚴重損毀的舊掃描檔 OldScans 僅 42.6，建議難度極高的歷史檔案仍需人工覆核）。 吞吐量與速度測試：在單張 NVIDIA A100 (SXM4 40GB, 併發 32) 條件下，達到 2.57 pages/s 的吞吐量（平均每頁產生 1,085 Token）；在單張 NVIDIA L4 (Batch Size 1) 環境下，開啟 FastMTP (K=3) 可將解碼速度從 42.7 提升至 83.1 tokens/s（約 1.95 倍加速）。 如何開始與部署選項使用者可根據需求選擇雲端服務或地端部署：https://www.communeify.com/tw/blog/horus-cyber-nano-1-0-multimodal-security-model/https://www.communeify.com/tw/blog/horus-cyber-nano-1-0-multimodal-security-model/Fri, 25 Sep 2026 08:05:00 +0800 Horus Cyber Nano 1.0 的「Nano」指的是相對小的資安專用模型，不是低到可以忽略硬體需求的桌面小模型。它有 16B 總參數、文字與視覺輸入，主要要處理的是授權範圍內的安全分析工作。 它不是一般聊天模型換一個名字Horus Cyber Nano 1.0 由 TokenAI 研發（由 Assem Sabry 創立），定位為 TokenAI 首款採用混合專家架構（Mixture of Experts, MoE）的原生多模態資安推理模型，發表於 2026 年 9 月。其目標應用場景聚焦於四大防禦性技術工作流：安全程式碼審查（Secure Code Review）、紅隊任務推理（Red Team Task Reasoning）、終端機與工具工作流（Terminal and Tool Workflows）以及資安視覺理解（Cybersecurity Vision Understanding）。 模型的輸入支援文字、圖片與影片，輸出則為文字分析結果。這樣的定位很重要：資安工作不只是一段程式碼找漏洞，還可能需要同時看錯誤訊息、網路拓撲、螢幕截圖、錄製的操作過程，以及一串工具執行結果。多模態輸入可以縮短「先把畫面描述成文字，再交給模型」的中間步驟，但它仍然不能替代實際掃描器、沙箱或人工確認。 16B 總參數與 MoE 架構技術規格Horus Cyber Nano 1.0 採用原生多模態視覺語言架構搭配因果語言解碼器，整體層數與 MoE 結構設計如下： 語言解碼器層數與維度：採用 27 層 Transformer，隱藏維度為 2048，配置 16 個 Attention Heads、16 個 KV Heads，激活函數為 SiLU，RoPE Theta 為 800,000。 MoE 專家配置：每一層均為 MoE 層，包含 64 個 Routed Experts 與 2 個 Shared Experts。每個 Token 運算時會選擇 6 個 Routed Experts 參與計算。這代表 16B 總容量與單次推理的活躍計算量（Active Parameters）是兩件事，不能只看「16B」估算顯存或運算速度。 視覺編碼器規格：包含 27 層 Vision Encoder、隱藏維度 1152、16 個 Vision Attention Heads、Patch Size 為 14。每張圖片最高支援約 320 萬像素（3.2M pixels）總解析度，並支援影片輸入。 高解析度圖片與影片會增加上下文與記憶體負擔，實際部署時應依工作流進行切片，而不是把整段長影片一次塞進模型。https://www.communeify.com/tw/blog/qwen3-8-27b-multimodal-model/https://www.communeify.com/tw/blog/qwen3-8-27b-multimodal-model/Mon, 17 Aug 2026 12:37:13 +0800Qwen3.8-27B：開源模型新選擇Qwen 系列在開源 AI 領域始終維持領先。隨著 Qwen3.5 與 3.6 的普及，開發團隊正式發布了 Qwen3.8-27B。這不僅是數字的提升，也是目前 Qwen 開源家族中綜合能力最強的一代。 圖片來源: Qwen/Qwen3.8-27B · Hugging Face 什麼是 Qwen3.8-27B？這是一款擁有 270 億（27B）參數的稠密模型（Dense Model）。與常見的混合專家模型（MoE）不同，Qwen3.8-27B 採用了高度優化的稠密架構，旨在部署便利性與實戰效能之間取得完美平衡，特別適合編碼開發、專業研究與長週期自動化任務。 在底層設計上，它的參數規格為： 模型類型：帶有視覺編碼器的因果語言模型（Causal Language Model with Vision Encoder） 層數（Layers）：64 層 隱藏維度（Hidden Dimension）：5120 前饋網路（FFN）中間維度：17,408 隱藏層佈局（Hidden Layout）：16 × (3 × (Gated DeltaNet → FFN) → 1 × (Gated Attention → FFN))，其中融合了線性注意力機制 Gated DeltaNet（48 個 V 頭，16 個 QK 頭，頭維度 128）與 Gated Attention 門控注意力。 多代幣預測（MTP）：經多步訓練，大幅提升自回歸生成與推理的效率。 此外，該模型具備原生視覺處理能力，不只能處理文字，還能直接解讀圖像與影片。不論是複雜的科學圖表、文件，或是長達一小時的影片片段，它都能提供具體的分析反饋。 思考過程的靈活控制Qwen3.8 最主要的特性在於對「思考過程」的靈活控制與對話追蹤。模型預設啟用思考模式，會在給出最終答案前先進行邏輯推演。 本代產品在思考控制上引入了三項關鍵技術： 思考模式開關（Thinking Mode Switch）：模型預設啟用思考模式，產生標記為 ` …</think> 的推導內容；使用者也可以透過配置 API 參數關閉此功能（即 Instruct / 非思考模式），以縮短回應時間。 2. **思維力度調整（Reasoning Effort）**：使用者可透過reasoning_effort` 參數調整推理深度：https://www.communeify.com/tw/blog/dots3-note-open-source-ai/https://www.communeify.com/tw/blog/dots3-note-open-source-ai/Fri, 14 Aug 2026 14:23:48 +0800邁向服務真實生活的 AI Agent：dots3-note Preview 簡介在人工智慧發展的進程中，我們一直希望能構建出真正能解決生活問題的 AI。這需要模型不只是感知世界或進行複雜推理，更要具備主動性與持續學習的能力，能夠隨著世界的變化和與用戶的交互而不斷進化。 為此，小紅書團隊旗下 dots studio 正式開源了 dots3-note Preview。這是 dots3 智慧體模型家族（家族規劃包括 note、jazz 與 aria，用以覆蓋不同的任務複雜度、響應速度與計算成本）中首款開源且最輕量的多模態 Mixture-of-Experts (MoE) 基礎模型。模型採用 Apache 2.0 協議發布，在多項封閉可驗證任務、長程 Agent 任務及多模態感知評測中，展現出比肩甚至超越數倍於其尺寸的大模型之卓越實力。 圖片來源: dots-studio/dots3-note-prev · Hugging Face 🛠️ 極致的輕量化與多模態架構dots3-note Preview 擁有 280B 總參數，推論時實際僅需 16B 激活參數，這使其在保持極高計算效率與低延遲的同時，依然具備強悍的長文本與多模態理解能力。它原生支援高達 512K 字符的超長上下文視窗，可同時理解與處理文本、圖像、影片（包含影片內嵌音軌）以及語音等跨模態輸入。 其底層硬核架構規格如下： 架構屬性規格參數 骨幹類型混合專家多模態解碼器（Multimodal MoE）參數規模280B 總參數 / 16B 激活參數多代幣預測 (MTP)1 個共享層（1.13B 參數），顯著最佳化多步生成效率網路層數1 個稠密層（Dense） + 45 個稀疏專家層（MoE）專家路由機制256 個總專家 + 1 個共享專家，推論時動態路由啟用 Top-8 專家隱藏層維度 (Hidden Size)5120FFN 隱藏維度13824（稠密層） / 1536（每個專家獨立維度）注意力機制排程13 個全域雙自我注意力（DSA，Top-2048） + 33 個滑動視窗注意力（SWA）交替 (~1:3)視覺編碼器MoE ViT 架構（總參數 7B，推論激活 1.2B）語音編碼器稠密語音特徵提取器（800M 參數）支援精度與格式原生 BF16 與 FP8 極低精度推論 🧠 TEMPO 技術：自我評價與長程任務強化訓練在開發能夠執行長程複雜任務的 AI Agent 時，傳統的強化學習面臨兩大工程瓶頸：一是 Agent 完成一次探索往往需要十餘個小時，訓練效率極其低下；二是稀疏的外部反饋（Sparse Rewards）使得模型難以進行有效的信用分配（Credit Assignment）。PPO 等 Actor-Critic 方法雖然能緩解此問題，但傳統 Critic 僅能透過固定算力的前向計算來估算價值，無法像 Actor 一樣透過多步推理、反思或調用工具來動態推導狀態好壞。https://www.communeify.com/tw/blog/mage-vl-microsoft-multimodal-model/https://www.communeify.com/tw/blog/mage-vl-microsoft-multimodal-model/Thu, 13 Aug 2026 17:02:34 +0800揭開 Mage-VL 的面紗：以編解碼器思維處理多模態資料在人工智慧領域，我們常面臨一種現代版的「莫拉維克悖論（Moravec’s paradox）」：強大的多模態模型（VLM）雖然極其擅長複雜的離線推理，但在面對需要即時、低延遲的影音串流（Streaming）處理時，往往顯得反應遲鈍且耗費極高算力。 為了打破這個瓶頸，微軟推出了 Mage-VL（arXiv: 2607.24904）。這是一款主打**編解碼器原生、主動式串流（Codec-native, Proactive-streaming）**的多模態基礎模型。其總參數規模為 5B，核心優勢在於將影片壓縮標準與影片理解深度融合，能對即時影音串流進行極致高效且具主動性的處理。 圖片來源: microsoft/Mage-VL · Hugging Face 為什麼要「編解碼器原生」？傳統的影片多模態模型在處理影片時，通常將其拆解為均勻採樣的影格，再將海量的 16×16 影像塊（patches）送入凍結的、預訓練視覺編碼器。這種做法會產生極大的計算冗餘，因為相鄰影格間通常包含大量重複的靜態背景。 Mage-VL 則完全模仿現代影片編碼器（如 H.264/AVC、HEVC/H.265 或神經編碼器 DCVC-RT）的壓縮邏輯，將影片串流拆分為： 關鍵幀（I-frames/Anchor frames）：模型會完整保留其視覺圖像。 預測幀（P-frames/Predicted frames）：模型只保留編碼器實際「花費位元（spending bits）」記錄動作變化與新細節的運動顯著區域。 這種與編解碼器對齊的預測性塊保留機制（Predictive-patch mechanism），能將視覺令牌（Visual Tokens）的消耗減少 75% 以上（降至 dense 均勻採樣的 1/8 甚至更低）。在完全不丟失時空上下文與定位精度的前提下，這項設計帶來了高達 3.5 倍的牆鐘推理速度提升（Wall-clock inference speedup）。 圖片來源: Mage-VL Mage-ViT：資料高效的從零預訓練視覺大腦Mage-VL 的視覺處理核心是 Mage-ViT（Codec-ViT）。與目前市面上依賴數十億、甚至上百億圖像-文本對初始化權重的 VLM 前端不同，Mage-ViT 展現了極高的資料效率： 無須海量標註資料：它是在僅有 約 1 億張（100M）未標記的圖像與影片影格 上，透過集群判別（Cluster-discrimination）從零開始（from scratch）預訓練而成。 強悍的零樣本表現：其在 CIFAR-10 上取得了 99.33%、在 ImageNet 上取得了 85.69%（僅使用 256 tokens）的驚人成績，實力媲美甚至超越了使用數十億大數據集訓練的 SigLIP2 (10B params) 或 MoonViT (2B params)。 原生解析度單調擴展：支援可變解析度預訓練。隨著令牌預算（Token budget）的增加（最高達 676 tokens），其表現能持續單調提升（ImageNet 達到 86.3%、Food-101 達到 96.1%），解決了傳統固定解析度編碼器在 token 增加時性能飽和或退化的通病。 解碼器相容（Codec-agnostic）：Mage-ViT 具有通用的前端介面，無須修改架構或重新訓練，即可直接接收傳統編解碼器（透過運動向量與殘差能量）或神經編解碼器（透過 Rate map）。 雙處理系統：實現主動式低延遲串流Mage-VL 引入了生物學啟發的「系統 1 與系統 2」雙處理機制，在單一權重模型內實現了主動式串流（Proactive streaming），無須維護複雜的多 Agent 管道：https://www.communeify.com/tw/blog/thinking-machines-inkling-small-model/https://www.communeify.com/tw/blog/thinking-machines-inkling-small-model/Thu, 13 Aug 2026 16:55:21 +0800輕量級 AI 新選擇：Inkling-Small 的效率與效能平衡在人工智慧領域，開發團隊往往過度追求極致算力與模型參數規模，卻忽略了實際生產環境部署中的計算效率與邊際成本。Thinking Machines 近期推出的開源混合專家模型 Inkling-Small，在大幅縮減模型體積的同時，保留了前代旗艦模型 Inkling 的強大處理能力，為開發者與研究人員提供了一個極具成本效益比的全新選擇。 圖片來源: Introducing Inkling-Small - Thinking Machines Lab 核心設計：無編碼器多模態與混合專家架構Inkling-Small 的核心目標是極大化降低每一次推論的運算成本。它採用了以下創新的底層架構設計： 自適應稀疏混合專家（Sparse MoE）： 作為一款 42 層的解碼器（Decoder-only）Transformer 結構，模型擁有高達 276B 的總參數，但在推論時每個 Token 僅會路由至 6 個專屬專家（共 256 個專家組件） 加上 2 個在所有 Token 上皆保持動態激活的共享專家，使得實際活躍參數僅有 12B。相比於前代旗艦模型 Inkling（總參數 975B，活躍參數 41B），這種稀疏專家設計在不犧牲模型表達力的前提下，顯著縮減了運算開銷。 原生無編碼器多模態架構（Natively Multimodal Encoder-Free Architecture）： 該模型摒棄了傳統多模態模型外接獨立視覺（如 ViT）或音訊（如 Whisper）編碼器的做法。在 Inkling-Small 中： 音訊輸入 被直接表示為 dMel 頻譜圖（dMel spectrograms）； 圖像輸入 則被拆解為 40×40 像素的圖像貼片（patches），並通過一個輕量化的 四層分層多層感知器（four-layer hMLP） 進行轉換。 所有模態的信號最終都會經由輕量化的嵌入層直接投影至統一的隱存空間中，與文字 Token 進行聯合解碼處理。 混合注意力幾何（Hybrid Attention）： 模型的注意力機制融合了局部（Local）與全域（Global）注意力的混合設計，能更靈活地在超長上下文窗口（最大支援高達 1M Tokens）中權衡記憶吞吐量與流暢度。 卓越的推理、編程與代理能力得益於改進的預訓練數據集配比與優化的訓練秘方，加上在 NVIDIA GB300 NVL72 叢集系統上的高效預訓練，Inkling-Small 的後訓練（Post-training）管道展現了顯著的進化。其前置版本利用了以 Inkling 為教師模型的在線策略蒸餾（On-policy distillation）技術，隨後團隊更針對代理編程場景（Agentic coding RL）進行了長達兩週的強化學習規模擴展（Scaling RL）。https://www.communeify.com/tw/blog/shieldstral-multimodal-safety-classifier/https://www.communeify.com/tw/blog/shieldstral-multimodal-safety-classifier/Thu, 13 Aug 2026 16:31:21 +0800內容審核的新標準：Shieldstral 的應用邏輯與技術解析在人工智慧與大語言模型迅速發展的今天，內容審核的面貌正變得日益複雜。同一段文字或圖片，對於網路安全研究工具而言可能是至關重要的學術樣本，但對於心理健康平台卻可能是有害內容。傳統的內容安全防護（Guardrail）模型往往將特定的危害類別（Taxonomy）直接寫死在權重矩陣中，如果業務場景需要動態調整安全策略，開發團隊通常必須面臨昂貴的重新訓練與微調成本。 為了徹底打破這一瓶頸，Mistral 發布了 Shieldstral 1.0-3B。這是一款參數規模為 3B（基於 Ministral-3-3B-Base-2512 並整合原生 Pixtral 視覺編碼器，總參約 4B）的開源、多模態且**具備策略自適應能力（Policy-Adaptive）**的安全分類器。它將繁瑣的內容審核機制，轉化為可以透過自然語言動態調整的「問答任務」，為即時安全防護樹立了新標杆。 圖片來源: Introducing Shieldstral. | Mistral AI 核心設計：審核即「問答」Shieldstral 的核心創新在於其**「政策在推論時即時注入」**的架構。它不需要為了配合新法規或新政策重新訓練模型，而是透過一個簡單、統一的機制來處理所有審核請求： 模型要求將輸入內容結構化為以下三個關鍵區塊： 指令（<Instruct>）：定義評估的上下文、嚴格程度（如 strict / moderate / lenient），以及（可選的）具體需要防範的有害類別定義（例如暴力、仇恨言論、性內容、自殘和犯罪活動）。此區塊在特定的產品或業務場景中通常保持恆定。 查詢（<Query>）：一個具體的「是/否」自然語言問題。例如：“Does this content promote physical violence?”（此內容是否宣揚肢體暴力？）。 文件（<Document>）：需要審核的輸入主體。它可以是用戶提示詞、模型回覆、格式化的對話對（如 [User] … [Assistant] …），甚至是包含文字的圖片。 這種設計將安全政策從模型的靜態權重中抽離，完全移交給提示詞（Prompt）進行動態管理。這意味著在實際部署中，開發者僅需維持單個模型檢查點，就能透過在推論時修改 <Instruct> 與 <Query>，靈活應對瞬息萬變的安全審核標準。 Shieldstral 的四大構建科學儘管 Shieldstral 僅有 3B 的語言模型底座，但其在多項安全基準測試中，表現足以媲美甚至超越規模大上 7 倍的防護模型。這主要歸功於研發團隊在訓練數據與模型構建上的四項關鍵決策： 統一異構數據（Unify Heterogeneous Data）： 公共安全數據集通常存在分類法不一致、標籤定義衝突等問題。團隊為每個數據集開發了專用的處理器，將其統一轉換為 <Instruct>–<Query>–<Document> 的結構。同時，有意地變更指令與查詢的措辭，避免模型對特定句式產生過擬合，並針對不同數據源校準其嚴格程度，從而成功融合了原本互不兼容的異構數據。 訓練「精準判斷」而非「死記硬背」（Teach Discrimination, Not Memorization）： 如果僅在固定的政策標籤上進行訓練，模型只會學會簡單的分類，而無法理解政策與政策之間的精確邊界。為此，團隊建構了多組故意設計得極為相似且容易混淆的政策，並使用大語言模型（LLM）將安全文本改寫為「對比性文本對」（Contrastive Pairs）——每份改寫都刻意違反其中一項政策，但不違反其孿生政策。這訓練了模型在推論時分辨細微政策邊界的能力，使其能高度泛化至未曾見過的用戶自訂政策中。 精準的視覺安全數據過濾（Ground Safety in Images）： 由於不安全圖像無法像文本一樣由 LLM 輕易合成，多模態安全數據極為匱乏。團隊除了將通用的影像數據集作為高質量的「負樣本」外，在數據清洗階段，透過視覺－語言重排序器（Vision-Language Reranker）對所有的「影像－查詢對」進行嚴格過濾，以最大程度減少噪聲數據、錯誤標註與模型幻覺，確保多模態訓練數據的極致純淨。（註：重排序器是用於訓練數據的高校篩選，模型本身的即時圖像審核則是透過原生的 Pixtral 視覺編碼器流暢運行）。https://www.communeify.com/tw/blog/meta-muse-glimmer-30b-ai-agent/https://www.communeify.com/tw/blog/meta-muse-glimmer-30b-ai-agent/Thu, 13 Aug 2026 15:44:56 +0800Muse Glimmer：為本地裝置打造的智慧代理模型Meta 發布了 Muse Glimmer，一款 300 億參數的開源模型，並採用 Apache 2.0 授權。與大多數依賴雲端伺服器的 AI 不同，這款模型設計初衷是讓使用者直接在個人電腦上運行。 圖片來源: Introducing Muse Glimmer: An Open Agentic Model That Runs on Your Device | Meta AI Research 為何選擇本地運行？雲端 AI 助手常受限於網路連接與隱私疑慮。Muse Glimmer 則是一個為「始終在線」本地工作流優化的工具，只要電腦配置了單張消費級顯卡，即可處理程式編寫、函數呼叫及模型評判等任務。 Muse Glimmer 的核心能力這款模型針對代理任務進行了訓練，主要功能包括： 自主任務處理： 具備編寫、調試程式碼，以及執行多步驟任務的能力。 工具調用與自救： 系統能呼叫外部工具，若流程出錯，會嘗試自我診斷與重試（Failure Recovery），而非直接中斷。 多模態感知： 透過專用編碼器，能辨識截圖、圖表及各類文件。 靈活的效能調整： 使用者可根據任務複雜度調整推理強度（Reasoning Strength），平衡速度與品質。 圖片來源: meta-models/Muse-Glimmer-30B · Hugging Face 輕量化與運行效率300 億參數的模型通常極為龐大，Meta 透過以下技術實現了在個人電腦上的部署： 4-bit 量化技術： 將模型權重壓縮，使語言模型本體記憶體需求從超過 55 GB 降低至 20 GB 以內，同時維持了絕大多數的處理準確度（平均性能衰減僅約 1.0%）。這為 KV 快取、多模態感知編碼器與投機解碼草稿模型留出充足空間，使其能同時在 24 GB 或 32 GB 的記憶體環境中流暢運作。 DFlash 投機解碼： 透過預測機制，其輕量級草稿模型可在單次前向傳播中直接預測 16 個 Token 的完整區塊，再由主模型負責進行平行驗證與修正。這顯著提升了生成速度，在 NVIDIA RTX 5090 顯卡上解碼效率可提升約 3.1 倍，在 Mac M4 Max / M5 Max 晶片上亦有 1.5 到 1.8 倍的提升，且輸出品質完全不變。 常見問題 需要連網嗎？ 完全不需要。它設計為離線運行，保障隱私且無須雲端存取。 支援哪些硬體？ 針對消費級顯卡優化，支援 llama.cpp、MLX 與 ExecuTorch 等邊緣部署框架，涵蓋 Mac M 系列晶片與 NVIDIA 顯卡。 實際用途為何？ 適用於自主本地代理、程式開發、自動化處理重複性工作流程，或作為 LLM-as-a-judge 模型評判與個人助理。 如何開始？ 模型權重已於 Hugging Face 上架，開發者可參考 官方開發者中心 與 官方技術文件 進行部署。 隨著 Ollama、LM Studio 或 Unsloth 等整合工具與合作夥伴陸續支援，你現在就能嘗試將 AI 從雲端遷移至自己的桌機中。https://www.communeify.com/tw/blog/liquid-lfm-2-5-vl-3b/https://www.communeify.com/tw/blog/liquid-lfm-2-5-vl-3b/Thu, 13 Aug 2026 15:26:53 +0800邊緣運算的視覺語言模型：LFM2.5-VL-3B 實測與應用Liquid AI 推出的 LFM2.5-VL-3B 是一款專為邊緣裝置設計的視覺語言模型。這款擁有 3.1B（約 31 億）參數的模型在處理文件、螢幕畫面分析、物體定位與工具呼叫等方面，展現出極佳的反應速度與即時性。 圖片來源: LFM2.5-VL-3B for Better and Faster Vision Capabilities for the Edge 詳細發布說明請參閱 Liquid AI 官方部落格文章。 技術架構與創新LFM2.5-VL-3B 的核心架構是將 SigLIP2 400M NaFlex 視覺編碼器 與 LFM2.5-2.6B 文本模型底座進行深度結合。 在訓練與技術設計上，有以下幾項關鍵突破： 適應性解析度編碼： 採用的 SigLIP2 NaFlex（Native Flexible resolution）編碼器原生支援寬高比與解析度的自適應調整，這使模型在進行密集型任務（如 OCR 與精確定位）時能保留更豐富的局部語義特徵與細節。 大規模多模態預訓練： 該模型預訓練於高達 34T 的 Token 數據上，並使用了較以往多出 4 倍的精選多模態數據，涵蓋精緻的圖文配對（Image-caption）、OCR 文件、物體定位（Grounding）與多模態指令遵循數據集。 原位分詞器擴展（In-place Tokenizer Expansion）： 為了在不破壞已有語言表徵的前提下妥善支援非拉丁語系，研發團隊並未重新從頭訓練模型，而是採取「就地擴展分詞器」技術，將詞彙量直接加倍擴展至 128K。 先進的後訓練（Post-training）管線： 微調過程分為兩個階段。第一階段為監督微調（SFT），其融合了來自更大規模教師模型的知識蒸餾（Knowledge Distillation）與防崩潰的 Antidoom 訓練；第二階段則採用多獎勵強化學習（Multi-reward RL），全面強化模型的指令遵循與工具呼叫對齊。 其四大核心技術提升包括： 螢幕/UI 理解（Screen/UI understanding）：對跨設備的數位螢幕與使用者介面內容擁有極強的解析與互動定位能力。 物體定位（Grounding）：顯著提升了基於自然語言查詢的物體檢測、目標框選與空間定位精度。 多圖輸入（Multi-image input）：支援同時輸入多張影像，具備強大的跨多圖關聯推理與多輪對話能力。 功能呼叫（Function calling）：大幅強化了在純文字與多模態場景下的工具呼叫（Function calling）與工作流執行能力。 邊緣部署與實測表現LFM2.5-VL-3B 在邊緣端運行時的記憶體佔用僅需約 3 GB，非常適合在本地或消費級硬體上部署。其原生支援完整的推論生態系，包含 llama.cpp、MLX、vLLM、SGLang 與 ONNX。https://www.communeify.com/tw/blog/cohere-north-micro-vision/https://www.communeify.com/tw/blog/cohere-north-micro-vision/Thu, 13 Aug 2026 15:07:19 +0800輕量級視覺模型：North Micro Vision在人工智慧領域，我們習慣追求千億參數的巨型模型，但輕量化工具往往才是開發者的實際選擇。Cohere 近期發布了 North-Micro-Vision-Instruct，這是一個參數規模僅 2.4B 的開源輕量級視覺語言模型 (VLM)。該模型採用 Apache 2.0 授權，因為體積輕巧，能直接在筆記型電腦、行動端或邊緣裝置上運行，無須仰賴昂貴的雲端運算。 圖片來源: Meet North Micro Vision: A 2.4B Native-Resolution Vision-Language Model 為什麼選擇小模型？這裡的核心優勢是「原生解析度」的支援。傳統模型為了處理影像，常將輸入強制壓縮或裁切為正方形縮圖，這會導致文件、表格、圖表或網頁截圖中的微小細節流失。 North Micro Vision 支援原生解析度輸入，能完整保留原始影像的長寬比與精細結構。無論是掃描文件、網頁截圖、複雜表格或圖表，它都能精確解析微小的文字資訊與空間定位，這使其在文件理解（Document AI）與視覺問答（VQA）任務中表現極為突出。 架構設計模型由三個核心部分組成： 400M 參數的視覺編碼器：基於 SigLIP 2 SO400M 優化。開發團隊導入「連續旋轉位置編碼（C-RoPE，結合 2D RoPE 與雙線性插值的 1D 位置編碼）」技術，讓模型能靈活應對各種長寬比與原生解析度的輸入。 連接層（Projector）：將視覺特徵映射到語言模型的嵌入空間。遵循 DeepStack 架構，將視覺編碼器多個層級的特徵（Patch Embeddings）注入語言模型的早期層級，使語言模型能同時獲取不同抽象程度的視覺表徵。 2B 參數的語言模型（North Micro LLM）：採用 Command A+ 架構。該架構交替使用三個具有旋轉位置嵌入的滑動窗口注意力層（Sliding-window Attention）與一個無位置嵌入的全域注意力層（Global Attention）。 訓練流程模型經歷了四個嚴謹的訓練階段，其中第二階段拆分為兩個解析度升級期： Stage 1 — 視覺編碼器與連接層預訓練（10M 樣本）：在固定解析度 384 × 384 像素下進行。此階段保持語言模型（LLM）凍結，僅訓練視覺編碼器與 Projector，數據混合比例為 60% 密集描述（Dense Captions）與 40% OCR 數據。 Stage 2 — 漸進式解析度提升聯合訓練： Stage 2.1（13M 樣本）：解析度提升至 1024 × 1024 像素。此時解除語言模型凍結，將視覺編碼器、連接層與語言模型進行全模型聯合訓練（Joint Training）。數據混合比例為 50% 密集描述與 50% OCR。 Stage 2.2（10M 樣本）：解析度上限進一步提升至 1654 × 2339 像素（對應 A4 紙張在 200 dpi 下的解析度）。此階段繼續進行全模型聯合訓練，使模型能完整保留並適應 A4 單頁文檔的長寬比。 Stage 3 — 多模態指令微調（50M 樣本）：在原生解析度下進行全模型聯合訓練。訓練集涵蓋了 OCR、圖表分析、空間定位/計數、一般視覺問答（VQA）以及部分純文字數據（以維持語言基礎能力），大幅提升了模型在細節保留與指任意圖遵循上的表現。 Stage 4 — 偏好調整（500k 樣本）：採用簡化版的「混合偏好最佳化 (MPO)」技術。此階段將視覺編碼器與連接層凍結，僅微調語言模型。該算法移除了 BCO 損失，結合了 DPO 偏好損失與 15% 權重的輔助次標記預測/SFT 損失，以顯著提升模型的安全防護、格式化輸出與對話回應品質。 如何使用目前可透過 Hugging Face 的 Transformers 函式庫執行：https://www.communeify.com/tw/blog/jd-joyai-vl-interaction-real-time-video-ai-framework/https://www.communeify.com/tw/blog/jd-joyai-vl-interaction-real-time-video-ai-framework/Mon, 29 Jun 2026 14:19:00 +0800告別運算卡頓！京東開源 JoyAI-VL-Interaction 如何改寫即時影音互動規則 探討京東 Joy 未來學院最新發佈的 JoyAI-VL-Interaction 模型。透過獨特的雙環異步推理架構，輕鬆解決即時視覺推理的延遲痛點，實現毫秒級的人機影音互動。 大家可能都有過這樣的經驗。當你對著智慧助理展示一段影片，要求它即時給出反應時，系統往往會卡頓個半天。畫面還在播，AI 卻還在拼命思考上一秒的畫面。老實說，這種體驗真的很破壞心情。 視覺語言模型要走向完全即時化，一直面臨著一個核心痛點，也就是所謂的「延遲博弈」。系統必須在即時的視覺推理與極度耗費資源的計算任務之間找到平衡。不過，就在 2026 年 6 月 10 日，京東 Joy 未來學院的視覺理解團隊正式對外發佈了 JoyAI-VL-Interaction 開源模型。這款模型跳脫了傳統的線性處理邏輯，直接從底層架構著手，為即時人機互動立下了一個全新的技術標竿。 接下來，我們就來好好拆解一下這背後的技術奧秘。 雙環異步推理機制：讓大腦學會分工合作過去的 AI 模型處理連續影音時，習慣排隊做事。一幀畫面進來，處理完，再接下一幀。這其實非常沒有效率。JoyAI-VL-Interaction 採用了一套高度並行的雙環架構。你可以把它想像成人類的大腦，具備反射神經與進階思考神經兩種不同的運作模式。 首先是負責即時反應的「實時紅環」。這就像是模型的反射中樞。它會持續接收真實世界的即時影音流，並在毫秒之間做出判斷。你猜怎麼著？這裡面藏著一個非常聰明的「Silence」機制。當系統面對連續畫面時，如果每一幀都要生成文字，硬體早就崩潰了。這個機制就像一個智能過濾網，只有在偵測到關鍵的語意變化，或是收到明確指令時，才會觸發運算。平時它就保持安靜，大幅節省了計算資源。 再看看負責進階推理的「委派藍環」。當系統發現你要它處理一個需要大量運算的超大任務時，它不會讓紅環卡死。相反地，它會啟動後端委派機制，把任務丟給藍環慢慢算。這兩個環之間彼此獨立互不干擾，確保了前端的影音互動依然滑順如絲。 看見即反應：毫秒級的即時警告能力在很多高敏感度的應用場景下，比如說安全監控，反應速度就是一切。JoyAI-VL 透過剛才提到的紅環架構，展現了讓人驚豔的反射能力。 舉個日常會遇到的例子。假設你對著系統下達指令：「如果畫面起火請馬上提醒我。」此時模型的邊緣推理節點就會開始持續掃描影像流。一旦系統的像素級特徵識別到了火光，它根本不需要經過那些冗長的語義生成步驟。它會直接繞過常規路徑，瞬間發出「火災！」的警告。毫秒級的判斷。真正的毫秒級。這種低延遲預警，完美展現了模型在狀態管理與吞吐量平衡上的巨大優勢。 從容應對複雜任務：非同步委派與非阻塞回應我們常常會問，如果遇到真的很難的問題怎麼辦？這就是 JoyAI-VL 最迷人的地方。針對像是 HTML 代碼生成這種極度消耗算力的任務，它有著一套行雲流水的處理流程。 當你提出要求：「請幫我用 HTML 重現這個手機 App 的介面。」前端系統會立刻回覆你「請稍候」，藉此維持對話的連貫性。就在這同一秒鐘，視覺資訊已經被打包好，直接拋送給後端的藍環。藍環完成複雜的程式碼建構後，會自動把結果傳回來。這整個過程完全不佔用前端的推理頻寬。平行運算的魅力就在這裡展露無遺。 一心多用的藝術：並行多工與動態物件計數這年頭連人類都很難一心多用，但這套模型做到了。得益於雙環架構，它可以輕鬆處理複雜的併發互動。 想像一下剛才那個生成 HTML 程式碼的場景。後端還在瘋狂寫程式碼，這時候你突然指著畫面問：「幫我算算現在畫面上有幾個瓶子？」系統完全不需要中斷背景的程式碼生成任務，直接透過前端的即時路徑，立刻回覆你正確的數量。這種精準的計算優先級排程，讓它在各種動態環境下都能遊刃有餘。 如影隨形的旁白：即時時空關聯分析與持續解說最後，我們來聊聊這套系統在影視解說與教育領域的潛力。JoyAI-VL 具備極為強大的連續影像解說能力。 這牽涉到一種叫做即時時空關聯分析的技術。當系統在觀看一段關於超現實主義的藝術影片時，它不僅能流暢地唸出標題卡片，還能依序描述畫面中出現的夢幻畫作。更厲害的是情境感知問答。當你隨口問一句「影片裡剛才出現的是哪兩個人物？」系統能立刻將目前的視覺畫面與內建的跨領域知識圖譜進行動態連結，精準回答出 André Breton 與 Salvador Dalí 的名字。這已經超越了單純的視覺辨識，這是建立在連續上下文基礎上的真實語義理解。 未來展望：重新定義影音互動標準看到這裡，相信大家對於即時視覺運算有了全新的認識。有開發者可能會問，這樣的技術目前容易取得嗎？當然。身為開源界的先行者，JoyAI-VL 官方專案網頁 已經提供了完整的資源與技術文件。 透過智能過濾與雙環非阻塞機制，這套系統成功化解了長久以來的架構難題，為未來的 AI 助理發展鋪平了道路。京東團隊也承諾會持續優化狀態管理算法。這項技術的工業級落地，絕對值得大家拭目以待。 問與答 (Q&A)問：什麼是 JoyAI-VL-Interaction？它是由誰開發的？ 答：JoyAI-VL-Interaction 是由**京東 Joy 未來學院（Joy Future Academy, JD）**的影片理解團隊於 2026 年 6 月 10 日開源釋出的即時影音互動模型。這款模型專為真實世界的即時影音流（Real-world Live Stream）場景設計，旨在讓人機之間的視覺與語言互動變得流暢且毫無延遲。https://www.communeify.com/tw/blog/glm-4-6v-seamless-integration-vision-perception-action-execution/https://www.communeify.com/tw/blog/glm-4-6v-seamless-integration-vision-perception-action-execution/Tue, 09 Dec 2025 08:54:46 +0800 GLM-4.6V 系列模型正式亮相，帶來 106B 與 9B 兩個版本，分別針對雲端高效能與本地低延遲場景。本文將解析其原生 Function Calling 能力如何打通「看」與「做」的界線，並深入探討其長文檔理解、前端代碼生成以及混合圖文創作的實際應用。同時附上詳細評測數據與部署資源。 視覺模型的新里程碑：不僅僅是「看懂」人工智能領域的發展總讓人目不暇給。才剛習慣語言模型能說會道，多模態模型（Multimodal AI）又把標準拉高了一個檔次。這次 GLM-4.6V 的發布，帶來了一個相當有趣的訊號：模型不再滿足於「看圖說話」，它們開始嘗試「看圖辦事」。 GLM-4.6V 系列推出了兩個版本。一個是針對雲端和高效能運算集群設計的基礎模型 GLM-4.6V (106B)，另一個則是為了本地部署和低延遲應用優化的輕量級模型 GLM-4.6V-Flash (9B)。這兩款模型在訓練時都將上下文窗口擴展到了 128k token，這意味著它們能一次處理的資訊量相當驚人。 這不僅僅是參數量的堆疊。這次更新最核心的突破在於「原生 Function Calling（函數調用）」的整合。這聽起來可能有點技術化，但簡單來說，這就是讓 AI 從一個只會評論的觀察者，變成了一個能動手解決問題的執行者。 打通感知與行動：原生視覺驅動的工具使用以往的多模態模型在處理任務時，通常需要先把看到的圖片轉成文字描述，再根據文字去調用工具。這中間的轉換往往會丟失細節，甚至產生誤解。 GLM-4.6V 採取了不同的路徑。它引入了 Native Multimodal Function Calling。這意味著，圖片、螢幕截圖或是文檔頁面，可以直接作為工具的輸入參數，不需要經過文字轉換這道手續。想像一下，當你把一張複雜的報表截圖丟給模型，它不需要先「翻譯」成文字，而是直接「看著」圖片去調用搜尋工具或計算工具，最後輸出的結果（不管是圖表還是渲染後的頁面）也能直接整合進推理鏈中。 這真正實現了從「視覺感知」到「理解」，再到「執行」的閉環。對於開發者來說，這為構建能夠處理真實商業場景的 AI Agent（代理人）提供了更統一的技術地基。 混合圖文創作：像人類一樣組織內容內容創作者可能會對 Interleaved Image-Text Content Generation（交錯圖文內容生成）這個功能特別感興趣。 過去我們讓 AI 寫文章配圖，通常是分開進行的：先寫字，再找圖。但 GLM-4.6V 能夠處理包含文檔、用戶輸入和工具檢索圖片在內的多模態語境。它在生成內容的過程中，會主動調用搜尋和檢索工具，收集並篩選額外的文字和視覺素材。 最終生成的結果，是根據任務量身定做的、圖文並茂的連貫內容。這就像是一位經驗豐富的編輯，懂得在文字的關鍵處插入佐證的圖片，而不是生硬地拼湊素材。 長文檔與複雜圖表的剋星在處理商業文件時，最讓人頭痛的往往是那些格式複雜的 PDF 或掃描件。GLM-4.6V 具備 Multimodal Document Understanding 能力，可以處理高達 128K token 的多文檔或長文檔輸入。 這有個很大的優勢：它把格式豐富的頁面直接當作圖片來理解。也就是說，它能同時讀懂文字、排版、圖表、表格和圖片。這避免了傳統 OCR（光學字元識別）技術先把所有東西轉成純文字時，丟失排版結構或表格錯位的問題。對於需要分析大量財報或技術手冊的專業人士來說，這能節省大量的校對時間。 前端工程師的 AI 助手：從截圖到代碼對於網頁開發者而言，Frontend Replication & Visual Editing 是一個非常實用的功能。 你只需要給模型一張 UI 截圖，它就能從像素層面還原出對應的 HTML 和 CSS 代碼。它會視覺化地檢測佈局、組件和樣式，生成乾淨的代碼。更厲害的是，它支持自然語言驅動的修改。如果你覺得某個按鈕的顏色不對，或者佈局太擠，只需要像跟設計師說話一樣下達指令，模型就會進行迭代式的視覺修改。https://www.communeify.com/tw/blog/bytedance-vidi2-multimodal-video-understanding-generation-model/https://www.communeify.com/tw/blog/bytedance-vidi2-multimodal-video-understanding-generation-model/Tue, 02 Dec 2025 08:54:46 +0800 ByteDance Vidi2 震撼登場！ 深入了解字節跳動如何透過這款大型多模態模型，實現對長影片的精準理解與生成。Vidi2 不僅能精確定位影片中「穿棕色西裝的男人打鼓」等特定事件，更在基準測試中超越 Gemini 3 Pro 與 GPT-5 (Preview)。探索 Vidi2 核心技術，預見影片剪輯的未來！ 這是一個內容創作者與開發者都會深感共鳴的場景：你手邊有一段長達三十分鐘的影片，卻為了尋找某個特定畫面——比如「穿著棕色西裝的男人在室內打鼓」——而在時間軸上來回拖曳，耗費大量時間。這種大海撈針的過程，往往讓人感到枯燥且效率低落。 ByteDance（字節跳動）的智慧創作團隊（Intelligent Creation Team）近期發布了 Vidi2，這是一款針對影片理解與生成所設計的大型多模態模型（Large Multimodal Models）。Vidi2 不僅僅是「看過」影片，它還能理解影片中發生的細節，並精確指出事件發生的時間與位置。根據官方發布的報告，這款模型在特定的基準測試上，表現甚至超越了 Gemini 3 Pro (Preview) 與 GPT-5 等知名模型。 這篇文章將帶領讀者一探 Vidi2 的核心技術、全新的評測基準，以及它如何改變影片剪輯的未來。 什麼是 Vidi2？從單純觀看到精準定位Vidi2 是 ByteDance 推出的第二代多模態模型，專注於解決影片處理中的兩大難題：影片理解（Video Understanding）與影片生成（Video Creation）。 與一般的視覺模型不同，Vidi2 具備一種稱為「細粒度時空定位」（Fine-grained Spatio-Temporal Grounding, STG）的能力。這聽起來可能有點技術性，但原理其實很直觀。當你輸入一段文字描述時，Vidi2 能做兩件事： 時間定位：找出這段描述在影片中出現的確切時間段（Timestamps）。 空間定位：在該時間段的每一幀畫面中，用邊框（Bounding Boxes）精確標示出目標物件。 這意味著模型不僅知道「發生了什麼」，還知道「在哪裡」以及「在畫面中的哪個位置」發生。這種端到端的能力，讓複雜的編輯場景變得簡單許多，例如自動切換視角、理解劇情走向，或是根據畫面構圖進行智慧裁切。 為什麼這很重要？對於影片編輯軟體而言，能夠理解畫面內容是自動化的基礎。Vidi2 展示的應用場景包括「Smart Split」（智慧拆分），它可以自動將長影片剪輯成精彩短片，重新構圖以適應手機直式螢幕，甚至自動生成標題與字幕。這對於需要大量處理素材的創作者來說，無疑是一大福音。 重新定義標準：VUE-STG 與 VUE-TR-V2 基準測試為了證明 Vidi2 的實力，研究團隊發現現有的測試標準並不足以完全衡量模型的能耐。因此，他們引入了兩個全新的基準測試（Benchmark），這也是本次發布的一大亮點。 VUE-STG：挑戰長影片的時空定位現有的數據集通常影片較短，難以測試模型對長內容的理解能力。VUE-STG 針對這點進行了四項關鍵改進： 影片長度跨度大：涵蓋從 10 秒到 30 分鐘不等的影片，這要求模型具備長文本和長時間跨度的推理能力。 查詢格式優化：將查詢轉換為名詞片語，同時保留句子的表達力，更貼近人類自然的搜尋習慣。 高品質標註：所有的時間範圍和物件邊框均經過人工精確標註，確保測試結果的準確性。 更嚴謹的評估指標：採用改進的 vIoU 和 tIoU 機制，針對多片段的時空評估進行優化。 VUE-TR-V2：升級版的時間檢索除了空間定位，團隊也升級了之前的時間檢索基準，推出了 VUE-TR-V2。這個新版本平衡了影片長度的分佈，並引入了更多「用戶風格」的查詢語句。這意味著測試情境更接近真實世界中人們搜尋影片的方式，而不僅僅是實驗室裡的理想狀況。https://www.communeify.com/tw/blog/apple-opensource-ai-fastvlm-developers-not-so-fast/https://www.communeify.com/tw/blog/apple-opensource-ai-fastvlm-developers-not-so-fast/Sat, 30 Aug 2025 08:54:46 +0800 Apple 最近在 Hugging Face 平台上悄悄發布了幾個月前發布的的視覺語言模型 FastVLM。這一舉動震驚了整個 AI 社群，畢竟 Apple 一向以其封閉的生態系統聞名。然而，這次的「開源」附帶了嚴格的條件——僅限於學術研究。這究竟是 Apple 擁抱開放文化的一小步，還是另有盤算？ 過去，當我們談到 Apple，腦中浮現的總是「封閉花園」、「生態壁壘」這些詞。他們家的硬體和軟體總是緊密結合，自成一格。但最近，這個科技巨頭似乎開始鬆動了。 Apple 在知名 AI 開發者社群 Hugging Face 上，發布了一系列機器學習模型，其中最引人注目的就是 FastVLM 和 MobileCLIP2。這對研究人員來說無疑是個好消息，但對於想將這些模型應用於商業產品的開發者來說，可能就要失望了。 這款叫 FastVLM 的模型，到底強在哪？我們先來聊聊主角 FastVLM。它是一款「視覺語言模型」（Vision-Language Model, VLM），簡單來說，就是能同時理解圖片和文字的 AI。你可以給它一張圖，然後用文字問它問題，它能像人一樣看懂圖並回答你。 聽起來很酷，對吧？ FastVLM 的厲害之處在於它的效率。從名字中的「Fast」就能猜到，它的反應速度和處理效率都經過了優化。Apple 這次還很貼心地提供了不同大小的版本，從輕巧的 0.5B（5 億參數）到強大的 7.76B 版本（官方稱其為 7B，但我們都知道實際更大一些，這在業界也算常見）。 FastVLM-0.5B: https://huggingface.co/apple/FastVLM-0.5B FastVLM-1.5B: https://huggingface.co/apple/FastVLM-1.5B 完整的模型集： https://huggingface.co/collections/apple/fastvlm-68ac97b9cd5cacefdd04872e 不只如此，Apple 還提供了一個線上示範，讓你可以親身體驗 FastVLM 的威力，甚至連原始碼都一併附上，誠意滿滿。 線上示範與原始碼： https://huggingface.co/spaces/apple/fastvlm-webgpu 那 MobileCLIP2 又是什麼？與 FastVLM 一同亮相的還有 MobileCLIP2。CLIP 類型的模型專門用來建立文字和圖像之間的連結。你可以把它想像成一個「翻譯官」，能告訴 AI 「貓」這個詞和一張貓的照片是相關的。 而「Mobile」這個詞則暗示了它的設計初衷——為行動裝置而生。這意味著 MobileCLIP2 在效能和功耗上都進行了特別優化，非常適合在 iPhone 或 iPad 這類裝置上運行。 MobileCLIP2 模型集： https://huggingface.co/collections/apple/mobileclip2-68ac947dcb035c54bcd20c47 開源的背後：那條「僅限研究」的紅線看到這裡，你可能會想：「太棒了！我可以用 Apple 的模型來開發新的 App 了！」https://www.communeify.com/tw/blog/minicpm-v-4-5-8b-model-beats-gpt4o-vision/https://www.communeify.com/tw/blog/minicpm-v-4-5-8b-model-beats-gpt4o-vision/Tue, 26 Aug 2025 08:54:46 +0800 AI圈又迎來重磅消息！OpenBMB發布了僅有80億參數的視覺語言模型MiniCPM-V 4.5，並宣稱其在多項視覺基準測試中擊敗了GPT-4o、Gemini Pro等業界巨頭。這究竟是噱頭還是真材實料？本文將帶您深入解析這款模型的驚人能力、背後技術以及它為開源社群帶來的深遠影響。 AI競賽風雲再起，小模型也能挑戰巨人？近來，人工智慧的發展速度快得讓人幾乎喘不過氣。就在大家還在驚嘆於GPT-4o和Gemini等大型模型的強大能力時，一個名為MiniCPM-V 4.5的「小傢伙」卻悄悄地登上了舞台，並直接向這些行業巨頭發起了挑戰。 你沒聽錯，來自開源社群OpenBMB的這款最新模型，僅用了80億（8B）的參數規模，就敢宣稱在綜合視覺語言能力上超越了像GPT-4o和Qwen2.5-VL（72B）這樣的重量級選手。這聽起來有點不可思議，對吧？一個參數規模相差近10倍的模型，是怎麼實現這種越級挑戰的？讓我們一起來看看它到底有哪些真本事。 數字會說話：性能評測見真章空口無憑，數據是最有力的證明。在衡量多模態模型綜合能力的權威評測集OpenCompass上，MiniCPM-V 4.5取得了平均77.2分的驚人成績。 這分數意味著什麼？這意味著它不僅超越了前代模型，更是在多個關鍵指標上，勝過了目前廣泛使用的專有模型，如GPT-4o和Gemini Pro。在300億參數以下的模型中，它無疑是當前性能最強的。評測數據顯示，MiniCPM-V 4.5在多個維度上都展現了極強的競爭力。 老實說，當一個輕量級選手在賽場上展現出與重量級冠軍相匹敵甚至更強的力量時，你很難不對它刮目相看。 不僅是看懂，更是「看透」：三大核心亮點解析光看跑分可能還是有點抽象。MiniCPM-V 4.5的強大並非紙上談兵，而是體現在各種具體的應用場景中。 1. AI界的「火眼金睛」：頂級OCR與文件解析你是否曾被模糊不清、角度刁鑽的圖片文字，或是潦草的手寫筆記搞得頭痛不已？MiniCPM-V 4.5在這方面堪稱專家。 得益於LLaVA-UHD架構，它能處理高達180萬像素的超高解析度影像，而且使用的視覺token（可以理解為模型處理圖像的計算單元）比大多數模型少4倍。這帶來的好處是雙重的：既提升了效率，又保證了準確性。 想像一下，即使面對一張寫滿了密集、潦草字跡的會議紀錄，MiniCPM-V 4.5也能準確無誤地將其轉換為數位文字。在權威的OCRBench測試中，它的表現甚至超過了GPT-4o，這在文件數位化、智慧表單填寫等領域有著巨大的應用潛力。 2. 動態世界也能掌握：高效的長影片理解能力過去，讓AI理解影片是一件非常消耗資源的事情。如果要處理的影片長一點、畫質高一點，計算成本就會直線飆升。 MiniCPM-V 4.5透過一個創新的「統一3D-Resampler」技術徹底改變了這個局面。它能實現高達96倍的影片token壓縮率——舉例來說，一段其他模型可能需要1536個token來處理的影片片段，MiniCPM-V 4.5只需要64個！ 這項技術突破，讓它能夠以高達10FPS（每秒10幀）的刷新率來「觀看」和理解影片，這已經非常接近人類的感知了。無論是分析長時間的監控錄影，還是快速抓取體育賽事的精彩瞬間，都變得輕而易舉、效率極高。 3. 像人一樣思考：可控的「快思」與「慢想」人類在解決問題時，有時依賴直覺快速反應（快思），有時則需要深入分析、邏輯推理（慢想）。MiniCPM-V 4.5巧妙地引入了這種混合思維模式。 它支援「快速思考」模式，用於處理常規、高頻的任務，以求達到最佳效率；同時也支援「深度思考」模式，用來解決更複雜、需要多步驟推理的問題。更棒的是，這兩種模式可以根據使用者的需求靈活切換，完美兼顧了效率與性能。 實測見真章：看看它的實際表現理論說了這麼多，不如來看看幾個生活中的實際例子，感受一下它的威力。 場景一：路痴的救星試想一個常見的駕駛情境：你開車到一個陌生的路口，急著想知道去下一個出口要多久。這時，模型可以分析你拍下的路牌照片，準確識別上面的所有文字訊息（例如「East Perth」和「James St & Wellington St」），還能結合距離（700米）和普遍的城市交通規則（如限速），快速估算出大致需要的行車時間。 這種結合視覺辨識與現實世界常識進行推理的能力，非常實用。 場景二：行動的百科全書如果你在博物館裡對某個展品感興趣，但又看不懂旁邊的說明牌，怎麼辦？只需拍張照，MiniCPM-V 4.5就能化身為你的專屬解說員。 例如，當它分析一張始祖鳥（Archaeopteryx）化石的照片時，它不僅能立刻認出這是什麼，還能頭頭是道地講解它的生物學意義——比如它是連接恐龍和鳥類的關鍵物種，擁有羽毛、爪子等混合特徵，是演化論的重要證據。這種專業程度，簡直就像一位隨身的古生物學家。 人人都能上手：開放的生態與便捷的部署MiniCPM-V 4.5最強大的地方，或許還在於它的開放性。OpenBMB團隊深知，好的工具要讓大家都能用上，才能發揮最大價值。 因此，無論你是想在自己的筆電上用CPU跑（支援llama.cpp和ollama），還是需要在伺服器上進行高吞吐量的推理（支援SGLang和vLLM），它都提供了完整的解決方案。此外，還有各種量化版本（如int4、GGUF）和便捷的微調工具，甚至提供了iOS App，讓開發者和AI愛好者可以輕鬆地將其應用到自己的專案中。 你可以在 HuggingFace 上找到模型，並在 GitHub 上查看完整的程式碼和使用指南。 總結：AI的未來屬於更高效、更開放的社群MiniCPM-V 4.5的出現，不僅僅是一款新模型的發布，它更像是一個宣言：模型的性能並不完全取決於參數的堆砌。透過更優秀的架構設計、更高效的訓練方法和更聰明的演算法，小模型同樣可以爆發出驚人的能量。 它向我們證明了，開源社群的力量正在不斷推動AI技術的邊界，讓頂尖的技術不再是少數科技巨頭的專利。對於廣大開發者和中小企業來說，這無疑是一個令人振奮的好消息。一個更開放、更高效、更普及的AI時代，或許已經悄然來臨。 常見問題解答 (FAQ)Q1: MiniCPM-V 4.5 和 GPT-4o 相比，主要優勢是什麼？https://www.communeify.com/tw/blog/liquid-ai-lfm2-vl-on-device-visual-ai-mobile/https://www.communeify.com/tw/blog/liquid-ai-lfm2-vl-on-device-visual-ai-mobile/Thu, 21 Aug 2025 08:54:46 +0800 厭倦了需要時刻連網的 AI 嗎？Liquid AI 推出的全新視覺語言模型 LFM2-VL，專為手機、穿戴裝置等邊緣設備設計。它不僅速度快、效率高，還能保持頂尖的準確度，徹底改變我們對設備端 AI 的想像。 你有沒有想過，如果你的手機相機不只能拍照，還能即時理解你眼前所見的一切，並與你對話？這聽起來像是科幻電影的情節，但長期以來，強大的 AI 模型都因體積龐大而只能存在於雲端伺服器中，讓這個夢想顯得有些遙遠。 但現在，情況可能要改變了。 人工智慧公司 Liquid AI 最近投下了一顆震撼彈，正式推出 LFM2-VL——一個專為「設備端」部署而生的全新視覺語言基礎模型系列。這系列包含 LFM2-VL-450M 和 LFM2-VL-1.6B 兩個版本，它們的目標非常明確：讓強大的多模態 AI 能直接在你的智慧型手機、筆記型電腦、甚至智慧手錶上高效運行，而且速度和準確度一點都不馬虎。 速度與智慧的完美結合？LFM2-VL 的核心優勢過去，我們總要在 AI 的「速度」與「智慧」之間做出取捨。模型越聰明，通常就越龐大、越慢。但 LFM2-VL 似乎找到了那個完美的平衡點。 根據 Liquid AI 的說法，LFM2-VL 的 GPU 推理速度是現有同類模型的兩倍。這意味著什麼？這意味著 AI 應用程式的反應會更即時、延遲更低，無論是進行圖像描述、視覺問答還是複雜的多模態推理，都能有更流暢的體驗。 為了滿足不同設備的需求，LFM2-VL 提供了兩種選擇： LFM2-VL-450M： 擁有 4.5 億個參數，專為資源極度有限的環境設計，例如穿戴式裝置或入門級的嵌入式系統。 LFM2-VL-1.6B： 擁有 16 億個參數，在保持輕量級的同時，提供了更強大的性能，非常適合在高階智慧型手機或配備單一 GPU 的設備上運行。 這就像擁有一台輕便的筆記型電腦和一台高效能的工作站，你可以根據任務需求自由選擇。 拆解幕後黑科技：「像素解混」與原生解析度所以，LFM2-VL 是如何做到既快又強的？答案就在其創新的模組化架構和聰明的影像處理技術。 簡單來說，這個模型由三個核心部分組成：一個語言模型主幹（負責理解與生成文字）、一個視覺編碼器（負責「看懂」圖片），以及一個多模態投影器（負責將兩者串連起來）。 其中最關鍵的技術，是一種稱為**「像素解混 (pixel un-shuffling)」**的技巧。你可以把它想像成一種智慧壓縮。在處理圖片時，模型並非逐一分析每個像素，而是動態地減少需要處理的影像資訊數量，只保留最關鍵的特徵。這讓它在不犧牲太多細節的情況下，大幅提升了影像處理速度。 此外，LFM2-VL 還能以高達 512x512 像素的原生解析度處理影像，避免了傳統模型放大圖片時可能造成的失真。如果遇到更大的圖片，它會聰明地將其分割成多個 512x512 的區塊分別處理，確保了細節和長寬比的完整性。更有趣的是，1.6B 的版本還會額外為全圖生成一個縮圖，用來理解整張圖片的「全域脈絡」，既能看見樹木，也能看見森林。 實際表現如何？跑分數據見真章當然，光說不練假把戲。LFM2-VL 的實際表現究竟如何？讓我們直接看看數據。 ModelRealWorldQAMM-IFEvalOCRBenchMME LFM2-VL-1.6B65.2337.667421753.04LFM2-VL-450M52.2926.186551239.06InternVL3-2B65.1038.49*8312186.40SmolVLM2-2.2B57.5019.42*7251792.50 從上方的基準測試結果（Table 1）中，我們可以清楚看到，LFM2-VL-1.6B 在多項評測中，其表現都與體積更大的 InternVL3-2B 或 SmolVLM2-2.2B 不相上下，甚至在某些項目中更為出色。https://www.communeify.com/tw/blog/meta-ai-dinov3-opensource-visual-ai-game-changer/https://www.communeify.com/tw/blog/meta-ai-dinov3-opensource-visual-ai-game-changer/Mon, 18 Aug 2025 08:54:46 +0800 Meta AI 近日開源了新一代通用影像辨識模型 DINOv3。它憑藉強大的「自我監督學習」能力，無需人工標註就能在多項視覺任務中達到頂尖水準，從環境監測到醫療影像，其應用潛力正引發全球開發者的熱烈討論。 最近，AI 圈最熱門的話題莫過於 Meta AI 正式開源了他們最新的通用影像辨識模型——DINOv3。消息一出，立刻在全球的開發者和研究社群中掀起波瀾。這款模型最驚人的地方在於，它採用了「自我監督學習」框架，簡單來說，就是 AI 自己看圖學本事，完全不需要人類在一旁費力地標註「這是貓」、「那是狗」。這項突破，可以說是為電腦視覺領域開啟了一扇新的大門。 什麼是「自我監督學習」？為什麼它這麼重要？讓我們先聊聊這個聽起來有點玄乎的技術。過去，要訓練一個聰明的影像辨識模型，背後是成千上萬的人工標註工作。工程師們需要準備海量的圖片，並一張一張地告訴模型圖片裡有什麼。這個過程不僅耗時耗力，成本也高得嚇人。 但 DINOv3 徹底改變了這個遊戲規則。 它透過自我監督學習，能從沒有任何標註的影像中自主學習、歸納並提取關鍵特徵。想像一下，就像一個嬰兒透過觀察世界來認識萬物，而不是靠父母拿著字卡教學。這項創新不僅大幅降低了資料準備的門檻和成本，更讓 AI 在那些資料稀少或標註極其昂貴的領域（例如專業的醫學影像或罕見的物種辨識）展現出前所未有的潛力。 社群媒體上的開發者們也證實了這一點，許多回饋都指出，DINOv3 在多項基準測試中的表現，足以和 SigLIP 2、Perception Encoder 這些頂尖模型一較高下，甚至在某些任務上更勝一籌，展現了它驚人的通用性。 不只看得懂，還看得精！DINOv3 的高解析度特徵DINOv3 的另一個殺手鐧，是它高品質、高解析度的密集特徵表示能力。這是什麼意思呢？ 簡單來說，它既能掌握影像的「全局樣貌」，也能捕捉到畫面中那些極其微小的「局部細節」。就像我們看一幅畫，既能欣賞整體的構圖與意境，也能注意到畫家在角落裡藏的一個精巧簽名。這種「遠近皆宜」的視覺能力，讓 DINOv3 在處理各種視覺任務時都游刃有餘。 無論是影像分類、物體偵測、語意分割，還是更複雜的影像檢索和深度估計，DINOv3 都能提供強而有力的支援。更厲害的是，它的能力不限於處理我們日常手機拍的照片，還能輕鬆駕馭衛星影像、醫學影像（如 X 光或 CT 掃描）等高度專業且複雜的資料類型，為跨領域的 AI 應用打下了堅實的基礎。 數據會說話：DINOv3 的實力到底有多強？空口無憑，我們直接來看數據。根據 Meta AI 公布的效能比較表，DINOv3 的表現確實令人驚豔。 任務 (TASK)基準 (BENCHMARK)DINOv3DINOv2SigLIP 2PE 分割 (Segmentation)ADE-20k55.949.542.738.9深度估計 (Depth estimation)NYU ↓0.3090.3720.4940.436影片追蹤 (Video tracking)DAVIS83.376.662.949.8實例檢索 (Instance retrieval)Met55.444.613.910.6影像分類 (Image classification)ImageNet ReaL90.489.990.590.4影像分類 (Image classification)ObjectNet79.066.478.680.2細粒度影像分類iNaturalist 202189.886.182.787.0 從表格中可以清楚看到：https://www.communeify.com/tw/blog/rf-detr-open-source-commercial-real-time-object-detection/https://www.communeify.com/tw/blog/rf-detr-open-source-commercial-real-time-object-detection/Tue, 25 Mar 2025 08:00:46 +0800RF-DETR 是什麼？RF-DETR 是由 Roboflow 團隊開發並開源釋出的最新即時物件偵測（Real-time Object Detection）模型。如果你對 YOLO 模型的速度或準確度不太滿意，RF-DETR 可能就是你一直在找的解決方案。 這款模型不僅是即時物件偵測領域的佼佼者，還完全開源，允許開發者自由使用、修改，甚至整合到商業應用中。換句話說，它就像一位訓練有素的「AI 偵探」，能夠在即時影片流中精準識別關鍵物件，且速度與準確率兼具。 RF-DETR 的核心優勢🚀 突破即時物件偵測的限制根據官方數據，RF-DETR 是第一款在 COCO 資料集上達到超過 60% mAP（mean Average Precision，平均準確率）的即時模型。COCO 資料集是電腦視覺領域的「奧運會」，這樣的成績代表 RF-DETR 的表現遠超過許多傳統即時偵測技術。 更重要的是，它在不犧牲速度的情況下提升了準確度，並且在 GPU 上運行時的延遲極低。這對於自動駕駛、工業品質檢測、智慧安全系統等需要快速回應的應用場景來說，是一項重大突破。例如，在自動化生產線上，RF-DETR 能以極快的速度辨識並抓取物件，大幅提升作業效率。 技術創新：Transformer 架構 vs. 傳統 YOLO🔍 DETR 家族的強大優勢一直以來，CNN（卷積神經網路）為基礎的 YOLO 模型主導了即時物件偵測領域。然而，隨著技術演進，Transformer 架構逐漸展現出強大的潛力。RF-DETR 採用了 DETR（Detection Transformer）技術，具備以下優勢： 更強的全局上下文理解能力：Transformer 能夠一次性處理整張圖片的所有特徵，避免 YOLO 這類 CNN 模型需要額外的後處理步驟（如 NMS，非極大值抑制）。 更高的準確度：在複雜場景下，RF-DETR 能更準確地識別物件，而不會因為重疊或遮擋導致錯誤偵測。 更有效率的運算方式：Roboflow 在評估 RF-DETR 時，考慮到了 YOLO 需要執行 NMS 的額外延遲，因此 RF-DETR 在「總延遲」比較上展現出更好的競爭力。 這些特性讓 RF-DETR 在 COCO 資料集上的表現超越了 YOLO，並在速度與準確度的平衡點上達到 Pareto 最優（即在不犧牲某項性能的情況下，達到最佳表現）。 結合 CNN 與 Transformer：最佳化設計雖然 RF-DETR 屬於 DETR 家族，但它並未完全捨棄 CNN 的優勢。許多先進的 DETR 變種仍然會結合 CNN 與 Transformer，以取得更佳的效能。RF-DETR 採用 LW-DETR，並搭配 DINOv2 預訓練骨幹網路（backbone network），這樣的設計帶來以下好處：