AI工具 on KnightLi的博客

大型模型量化詳解：FP16、Q8、Q5、Q4 到 Q2 怎麼選？

Sun, 05 Apr 2026 22:09:11 +0800

量化的核心目標很簡單：用少量精度損失，換取更小體積、更低顯存占用與更快推理速度。
對本地部署使用者來說，選對量化版本，通常比盲目追求大參數更重要。

什麼是量化

量化是指把模型參數從高精度格式（如 FP16）壓縮為更低位寬格式（如 Q8、Q4）。

可以把它理解為：

原始模型：像高精度照片，清晰但檔案大。
量化模型：像壓縮照片，細節略有損失但更輕更快。

常見量化版本對比

量化版本	精度/位寬	體積	品質損失	推薦場景
FP16	16 位浮點	最大	幾乎無損	研究、評測、追求極致品質
Q8_0	8 位整數	較大	幾乎無損	高配電腦，兼顧品質與效能
Q5_K_M	5 位混合	中等	輕微損失	日常主力，平衡方案
Q4_K_M	4 位混合	較小	可接受損失	通用預設，性價比高
Q3_K_M	3 位混合	很小	明顯損失	低配設備，先求能跑
Q2_K	2 位混合	最小	較大損失	極限資源場景，臨時可用

量化命名規則

以 gemma-4:4b-q4_k_m 為例：

gemma-4:4b：模型名稱與參數規模。
q4：4 位量化。
k：K-quants（改進的量化方法）。
m：medium（中等級別，常見還有 s/small、l/large）。

如何按顯存快速選型

內存/顯存	推薦量化
4 GB	Q3_K_M / Q2_K
8 GB	Q4_K_M
16 GB	Q5_K_M / Q8_0
32 GB+	FP16 / Q8_0

建議先從能穩定跑起來的版本開始，再逐步提高精度，而不是一開始就追求最大模型。

實戰建議

預設從 Q4_K_M 開始，先驗證真實任務效果。
如果答案品質不夠，再升到 Q5_K_M 或 Q8_0。
如果主要瓶頸是顯存或速度，再降到 Q3_K_M。
每次切換量化版本，都用同一批測試問題做對比。

結論

品質優先：FP16 或 Q8_0。
平衡優先：Q5_K_M。
通用預設：Q4_K_M。
低配兜底：Q3_K_M 或 Q2_K。

選型的本質不是「越大越好」，而是「在你的硬體條件下，達到最穩定可用的效果」。

Google Gemma 4 模型對比：2B/4B/26B/31B 怎麼選？

Sun, 05 Apr 2026 08:30:00 +0800

Gemma 4 主打 多模態 與 本地離線運行，並提供從輕量端到高性能端的完整模型梯度。對大多數本地部署使用者來說，關鍵不是選最大，而是選最符合硬體與任務需求的版本。

Gemma 4 各模型對比

下表用於快速選型參考；具體性能與資源占用請以實際部署環境測試為準。

模型	參數規模	定位	主要優勢	主要限制	推薦場景
Gemma 4 2B	20 億	超輕量	延遲低、資源占用小、部署門檻最低	複雜推理與長鏈路任務能力有限	行動端、IoT、輕量問答、簡單自動化
Gemma 4 4B	40 億	輕量增強	比 2B 更穩定的理解與生成能力，仍易於本地部署	高強度編碼與複雜 Agent 任務上限有限	本地助手、基礎文件處理、多語言日常任務
Gemma 4 26B	260 億	高性能（專家混合）	推理與工具調用能力明顯提升，適合生產工作流	顯存需求顯著上升，硬體門檻更高	編程助手、複雜工作流、企業內部 Agent
Gemma 4 31B	310 億	高性能（稠密）	綜合能力最強，複雜任務穩定性更好	資源成本最高，部署與調優成本更大	高要求推理、複雜程式任務、重度自動化

怎麼選：按硬體和任務倒推

如果你主要關心「能不能跑、跑得順不順」，可以按下面選：

8GB 顯存：優先 2B/4B。
12GB 顯存：優先 4B 或更高模型的量化版本。
24GB 顯存：可重點考慮 26B，並依任務評估 31B 量化版。
更高顯存或多卡：可嘗試 31B 的高精度配置。

建議先保證穩定性與推理速度，再逐步提升模型規模。

四類典型使用場景

1) 本地通用助手

優先模型：4B
原因：成本與效果平衡佳，適合長期常駐運行。

2) 程式與自動化

優先模型：26B
原因：在多步驟任務、工具調用、腳本生成上更穩。

3) 高難度推理與複雜 Agent

優先模型：31B
原因：在複雜上下文下穩定性更高、容錯更好。

4) 邊緣設備與輕量離線

優先模型：2B
原因：最容易在資源受限設備落地。

部署建議（Ollama 方向）

更實用的做法是小步快跑：

先用 4B 建立可運行基線（速度、記憶體、效果）。
把真實任務做成固定測試集（例如 20 條常見問題 + 10 個自動化任務）。
再升級到 26B/31B 對比準確率、時延與顯存成本。
只在收益明顯時升級大模型。

這樣可以避免一開始就追求大參數，導致卡頓、吞吐低與維護複雜度上升。

結論

Gemma 4 的真正價值，不是單純參數更大，而是提供了從輕量到高性能的一整套可落地梯度：

想低成本快速上線：從 2B/4B 開始。
想讓本地 AI 真正接入生產流程：優先 26B。
想衝擊複雜推理與重度自動化：再上 31B。

Gemma 4 的最佳選擇通常不是參數最大，而是與硬體條件與任務目標匹配度最高的版本。

分析 Anthropic 的 Agent Skill docx：功能、程式組成、使用方法與注意事項

Sat, 04 Apr 2026 11:00:00 +0800

Anthropic 的 skills/docx 本質上是一套「讓 AI 更穩定處理 Word 文件」的工作規範與腳本工具集。
它不是只告訴模型「去寫一個 .docx」，而是把 Word 文件處理拆成幾條明確路徑：新建文件、讀取內容、編輯既有文件、處理修訂、加入評論、格式轉換、校驗 OOXML 結構。

如果只用一句話概括：

讓 agent 不再把 .docx 當黑盒，而是把它當成 ZIP + XML + Office 相容性問題來處理。

這個 skill 解決什麼問題

一般模型在處理 Word 文件時，常見問題大致有這幾類：

只會輸出文字，不會真正產生結構正確的 .docx
修改既有文件時，容易破壞 OOXML 結構
遇到批註、修訂、評論串時，不知道要改哪些 XML
文件能產生，但在 Word、LibreOffice、Google Docs 間相容性不穩
不清楚何時該用 pandoc，何時該直接解包改 XML

docx skill 的價值就在這裡，它把「該怎麼做」先規範好了：

讀內容時，優先用 pandoc 或解包
新建 .docx 時，優先用 docx-js
編輯既有 .docx 時，優先走「解包 -> 修改 XML -> 重新打包 -> 校驗」
處理接受修訂、評論、schema 校驗等細節時，用配套腳本而不是硬寫

這套方法很實用，因為 Word 文件問題通常不是「文字對不對」，而是「文件結構是否還能被 Office 正常接受」。

目錄與程式組成

這個 skill 大致可以分成四層。

1. 說明層：`SKILL.md`

SKILL.md 是入口，主要做兩件事：

定義觸發條件
只要需求涉及 Word、.docx、評論、修訂、目錄、頁碼、模板、格式化文件等內容，就應啟用這個 skill。
規定工作路徑
明確指定不同任務要走哪條技術路線，而不是每次臨場發揮。

它同時是使用說明與操作規範。裡面最有價值的是相容性規則，例如：

docx-js 預設是 A4，不是 US Letter
橫向頁面時，寬高參數要按它的內部邏輯傳
列表不能手工插入 Unicode bullet
表格寬度要同時設 table 與 cell
插入圖片時 type 不能省
生成後要跑 validate

這反映出它追求的不只是「能生成」，而是「能穩定開啟、穩定渲染、穩定相容」。

2. Office 包操作層：`scripts/office/*`

這一層負責把 .docx/.pptx/.xlsx 當成 Office Open XML 套件來處理。

`unpack.py`

作用是把 Office 文件解包到目錄，並做一些整理：

解壓 ZIP 包
對 XML / .rels 做 pretty print
對 .docx 可選執行 merge_runs
對 .docx 可選執行 simplify_redlines
將智慧引號轉成 XML 實體，降低後續處理風險

它不只是「解壓」，而是把內容整理成更適合 agent 與人類繼續編輯的狀態。

`pack.py`

作用是把修改後目錄重新打包成 .docx/.pptx/.xlsx。
打包前還會做兩件要事：

可選執行校驗與自動修復
重新壓縮整理 XML，移除無意義空白與註解

若提供 --original，會結合 validator 比對，這點很關鍵。
因為很多 Word 修改不是「能打包回去」就算成功，而是要確認結構與修訂語義都成立。

`validate.py`

這是整個 skill 的品質閘門。
它會校驗：

XML 是否良構
namespace 是否正確
各類 ID 是否唯一
relationship / content type 是否匹配
是否符合 XSD schema
空白保留規則是否正確
插入、刪除、評論標記是否合法

對 .docx 來說，這幾乎是核心能力。
很多「看起來只改一點 XML」的問題，都會在這裡暴露。

`soffice.py`

這是一個很有工程味的輔助工具。
它不是單純呼叫 LibreOffice，而是為受限環境做兼容處理，會設置 SAL_USE_VCLPLUGIN=svp，必要時還會用 shim 處理 AF_UNIX socket 限制。

這代表它考慮的不是只有本機手動場景，也包含 agent、CI、沙箱等自動化環境。

3. Word 專項能力層：評論、修訂與 redline

`comment.py`

這個腳本負責幫 DOCX 加評論。
它做的不只是寫一段 comment XML，因為 Word 評論涉及多個部件協同：

word/comments.xml
commentsExtended.xml
commentsIds.xml
commentsExtensible.xml
document.xml 中的 comment range marker
[Content_Types].xml 與 document.xml.rels 中的關係宣告

腳本已把這些依賴關係處理好。
若是第一次加評論，會自動補模板檔、relationship 與 content types，能大幅降低手工改 OOXML 的出錯率。

`accept_changes.py`

這個腳本目標很明確：接受所有修訂。
做法不是硬改 XML，而是透過 LibreOffice headless + Basic macro 呼叫 .uno:AcceptAllTrackedChanges。

這很穩妥，因為「接受修訂」在 Word 語義中不只是刪 <w:ins> / <w:del>。
直接改 XML 很容易留下邊角問題；由 Office 引擎處理通常更可靠。

`validators/redlining.py`

這是我認為很關鍵的一段。
它會把「某作者的修訂」分別從原始文件與修改後文件中剝離，再比較正文文字是否一致，以判斷修訂是否被正確包在 tracked changes 結構裡。

也就是說，它不只驗 XML 格式，而是在驗「是否按修訂語義編輯」。

這對 agent 特別重要，因為 AI 常見錯誤是：

直接改正文，沒包進 <w:ins> / <w:del>
在別人的插入或刪除結構裡改壞層級
最終文字改了，但 redline 語義不成立

這個 validator 就是在擋這類「看似可用、其實語義錯誤」的問題。

4. Schema 與輔助層：`schemas/`、`helpers/`、`templates/`

`schemas/`

這裡放的是一整套 OOXML / ECMA / Microsoft 擴展相關 XSD。
代表校驗規則盡量基於正式 schema，而不是臨時規則。

`helpers/`

這裡主要有：

merge_runs.py
simplify_redlines.py

作用是對解包後的 Word XML 做適度清理，讓結構更穩定、更易編輯與比對。

`templates/`

這裡存放評論功能依賴的 XML 模板，如：

comments.xml
commentsExtended.xml
commentsIds.xml
commentsExtensible.xml
people.xml

這些模板很重要，因為很多 Word 部件不是「缺了會自動補」，而是必須按 Office 接受的格式預置。

典型使用方法

從 SKILL.md 的建議看，這個 skill 很適合以下工作流。

場景一：讀取或分析既有 DOCX

若目標是抽取內容、閱讀結構、轉 Markdown，優先用：

`1`	`pandoc --track-changes=all document.docx -o output.md`

若要看底層 XML，則用：

`1`	`python scripts/office/unpack.py document.docx unpacked/`

前者適合讀內容，後者適合看結構。

場景二：新建 DOCX

這個 skill 建議用 docx-js 生成，而不是手搓 OOXML：

`1`	`npm install -g docx`

生成後再校驗：

`1`	`python scripts/office/validate.py doc.docx`

適合報告、memo、letter，以及含標題、目錄、頁腳、分頁、表格的正式文件。

場景三：編輯既有 DOCX

這是最核心的流程：

1
2
3

python scripts/office/unpack.py document.docx unpacked/
# 修改 unpacked/ 下的 XML
python scripts/office/pack.py unpacked/ output.docx --original document.docx

重點在 --original。
它讓系統在回包時做 schema 與 redline 層面的驗證，而不是盲目打包。

場景四：接受所有修訂

`1`	`python scripts/accept_changes.py input.docx output.docx`

這一步依賴 LibreOffice，適合把已審閱文件整理成乾淨版。

場景五：添加評論

1
2

python comment.py unpacked/ 0 "Comment text"
python comment.py unpacked/ 1 "Reply text" --parent 0

要注意：腳本會補評論內容與必要部件，但仍需按註解在 document.xml 補上 comment range marker，才能把評論正確掛到文字範圍。

這個 skill 最值得注意的幾個坑

若只快速掃過 SKILL.md，很容易低估裡面「相容性規則」的價值。以下幾點尤其重要。

1. `.docx` 不是純文字檔，而是 Office 套件

最大的誤區是把它當作「有格式的文字檔」。
實際可能同時涉及正文 XML、relationships、content types、comments / people / ids、schema 約束、修訂語義。

所以這個 skill 才會強調「解包 - 編輯 - 校驗 - 回包」。

2. `docx-js` 能生成，不代表預設值符合你的目標

SKILL.md 明確提到多個預設陷阱，例如 A4 預設、橫向頁面寬高邏輯、列表 bullet、表格寬度雙重宣告、Google Docs 百分比寬度相容性等。

生成工具只是起點，不是最終品質保證。

3. 評論與修訂都不是單點修改

無論 comment 或 tracked changes，都不是改一個 XML 就結束。
需要維護多部件一致性，這正是腳本化的價值。

4.「能開啟」不等於「改對了」

文件能被 Word 開啟，不代表結構正確。
很多問題會在再次編輯、審閱模式、批註顯示、Google Docs 開啟、重新接受修訂時才暴露。

因此 validate.py 和 pack.py --original 非常關鍵。

5. 依賴外部工具時要先備好環境

這個 skill 依賴：

pandoc
LibreOffice / soffice
docx-js
Python 依賴，如 defusedxml、lxml

如果環境缺工具，即使流程正確也無法完整執行。

這個 skill 適合什麼，不適合什麼

適合

批量生成 Word 報告
結構化產生正式文件
自動化修改 .docx
保留或處理 tracked changes
自動加入批註
把 Word 文件納入腳本或 agent 工作流

不太適合

只做簡單 PDF 導出
只要純文字內容，不在意 Word 格式
完全依賴手動可視化編輯
期待零依賴、零環境準備完成全部 Word 自動化

總結

Anthropic 的 skills/docx 強項不在「會生成 Word」，而在「知道 Word 為什麼容易出問題，並先把問題拆開處理」。
它把文件生成、底層 XML 編輯、修訂語義、schema 校驗、Office 相容性等原本零散的知識，整理成一條可執行工作流。

若只是偶爾導出簡單文件，它可能略重；
但只要場景涉及既有 .docx 修改、評論、修訂、自動化批處理或相容性要求，這套 skill 的價值就很高，因為它補上的正是 AI 最容易忽略、也是 Office 文件最容易翻車的細節。

簡單總結：

SKILL.md 負責定義路徑
scripts/office/* 負責解包、回包、校驗與相容性
comment.py 與 accept_changes.py 負責 Word 專項能力
schemas/ 與 validators 把「看起來能用」提升到「結構上可靠」

程式位置：https://github.com/anthropics/skills/tree/main/skills/docx