LLM on KnightLi的博客

筆記型電腦 RTX 4060 8GB 適合跑哪些本地 AI 模型

Fri, 08 May 2026 13:41:15 +0800

筆記型電腦 RTX 4060 8GB 可以玩本地 AI，但邊界很清楚：重點不是模型能不能啟動，而是顯存是否溢出。行動版 RTX 4060 也會受整機功耗、散熱、顯存頻寬和廠商調校影響。

在 2026 年，8GB 顯存仍是本地 AI 的入門基準線。選對量化模型和工具鏈，它可以執行 3B-8B LLM、SDXL、SD 1.5、部分 FLUX 量化工作流、Whisper 轉寫和圖像特徵提取。若強行跑 14B 以上 LLM、未量化大模型或高顯存生圖工作流，速度會在溢出到系統記憶體後明顯崩掉。

一句話：不要追最大模型，優先小模型、量化權重和低顯存工作流。

顯存預算

Windows 11、瀏覽器、驅動和背景程式會先佔一部分顯存。實際留給 AI 的顯存通常更接近 6.5GB-7.2GB。

LLM：優先 3B-8B，使用 4-bit 量化。
圖像生成：優先 SDXL、SD 1.5、FLUX GGUF/NF4 低顯存工作流。
多模態：優先 4B 左右輕量模型。
語音：Whisper large-v3 可跑，但長批次要注意發熱。
圖像索引：CLIP、ViT、SigLIP 很適合。

顯存一旦溢出到系統記憶體，體驗會很差。較小且完整放進 GPU 的模型，通常比半 offload 的大模型更好。

LLM：3B-8B 量化模型

本地聊天和文本推理可用 Ollama、LM Studio、koboldcpp、llama.cpp 或其他支援 GGUF 的前端。8GB 顯存最舒服的區間是 3B-8B 的 4-bit 量化模型。

全能輕量：Gemma 4 E4B

Gemma 4 E4B 是 Google 2026 年 Gemma 4 系列小模型之一，適合本地和端側使用。它可承擔日常問答、摘要、輕量多模態和低成本推理。

筆記型 RTX 4060 建議優先找官方或社群量化版本，不要一開始就追最高精度權重。

適合：

日常問答。
摘要和改寫。
輕量資料整理。
簡單程式碼解釋。
圖像理解輕任務。

推理與長文本：DeepSeek R1 Distill 7B/8B、Qwen 3 8B

如果重視邏輯、數學、複雜分析和中文長文本，可試 DeepSeek R1 distill 7B/8B 或 Qwen 3 8B 量化版。

Q4_K_M 通常能讓 8B 模型進入 8GB 可承受範圍。實際速度受上下文長度、後端、驅動和筆電功耗模式影響。

不建議一開始跑 14B、32B 或更大模型。即使能透過 CPU offload 啟動，體驗通常不如小模型全 GPU。

程式碼：Qwen 2.5 Coder 3B/7B

Qwen 2.5 Coder 3B 適合即時補全、解釋和小片段生成；7B 理解能力更好，但顯存和延遲更高。

即時補全：3B。
問答和解釋：3B 或 7B。
小型重構：7B 量化。
大型架構分析：不要期待 8GB 顯存容納完整專案上下文。

圖像生成

SD 1.5 和 SDXL

SD 1.5 對 8GB 很友好，速度快，生態成熟。SDXL 要求更高，但仍可用。

推薦工具：

ComfyUI
Stable Diffusion WebUI Forge
Fooocus

SD 1.5 適合快速出圖、LoRA、ControlNet；SDXL 更適合通用品質。

FLUX.1 schnell

FLUX 畫質和提示詞理解更強，但原始模型顯存壓力大。8GB 顯存建議使用 GGUF、NF4、FP8 等低顯存方案，搭配 ComfyUI-GGUF 或低顯存工作流。

使用 FLUX.1 schnell GGUF Q4/Q5。
降低解析度或 batch size。
使用 ComfyUI --lowvram。
不要同時掛太多 LoRA、ControlNet 和高清修復。
觀察工作流切換後顯存是否釋放。

可以嘗試 1024px，但不要照搬 16GB/24GB 桌機工作流。

多模態與效率工具

Whisper large-v3 可用於語音轉文字，適合會議錄音、課程音訊、影片字幕和素材整理。長批次要開性能模式並注意散熱。

照片檢索系統則很適合 4060 8GB。CLIP、ViT、SigLIP 對顯存要求不誇張，可快速處理幾千張圖片。

典型流程：

用 CLIP/ViT/SigLIP 提取 embedding。
保存到 SQLite 或向量庫。
用文字或相似圖片檢索。
用小型 LLM 生成標籤、描述或相簿摘要。

避坑

場景	建議
大模型	避免 14B+，除非接受明顯降速
量化	先選 `Q4_K_M`，再嘗試 Q5
顯存	用工作管理員或 `nvidia-smi` 監控
散熱	生圖和批次任務開性能模式
解析度	從 768px 或單張 1024px 開始
瀏覽器	關掉佔顯存的分頁
驅動	保持 NVIDIA 驅動較新
工作流	不要照搬 16GB/24GB ComfyUI 工作流

建議定位

筆記型 RTX 4060 8GB 最適合做高性價比本地 AI 入門平台。它適合 3B-8B LLM、小型程式碼模型、SDXL、SD 1.5、FLUX 量化體驗、Whisper、圖像向量索引和照片管理。

不適合長期跑 14B/32B、大型未量化模型、高解析度批量 FLUX、大規模影片生成或多模型同時常駐。

參考資料

適合 RTX 3060 顯卡運行的本地 LLM 模型推薦

Fri, 08 May 2026 09:25:24 +0800

RTX 3060 最常見的是 12GB 顯存版本。它不是頂級 AI 顯卡，但用來跑本地 LLM 很合適，尤其適合 7B、8B、9B、12B 級別模型。

如果只想快速選型，可以先記住一句話：

RTX 3060 12GB 優先選 8B 左右模型的 Q4_K_M 或 Q5_K_M 量化；想要更穩就選 Q4，想要更好品質再試 Q5。

不要一上來就追 32B、70B。它們即使用低位元量化和 CPU offload 能跑，速度和體驗通常也不適合日常使用。

先看顯存邊界

RTX 3060 12GB 跑本地 LLM，真正限制是顯存。

模型規模	推薦量化	3060 12GB 體驗
3B / 4B	Q4、Q5、Q8	很輕鬆，速度快
7B / 8B / 9B	Q4_K_M、Q5_K_M	最推薦，品質和速度平衡好
12B / 14B	Q4_K_M	可以嘗試，注意上下文不要太大
30B 以上	Q2 / Q3 或部分 offload	能折騰，但不推薦日常使用
70B 以上	極低量化或大量 CPU/RAM 參與	更像實驗，不適合普通使用

本地 LLM 不只是模型檔案大小占顯存。上下文長度、KV cache、批處理大小、推理框架和顯卡驅動都會占資源。

所以 12GB 顯存不等於可以直接載入 12GB 模型檔案。更穩的做法是給系統和上下文留餘量。

推薦一：Qwen3 8B

如果你主要用中文，Qwen3 8B 是 RTX 3060 上很值得優先嘗試的模型。

適合場景：

中文問答。
摘要和改寫。
日常知識助手。
簡單程式碼解釋。
本地 RAG。
輕量 Agent 流程。

建議選擇：

1
2
3

Qwen3 8B GGUF
Q4_K_M：優先推薦
Q5_K_M：品質更好，但顯存壓力更高

Qwen 系列對中文更友好，日常寫作、資料整理和中文指令理解通常比較順。如果你不知道第一款本地中文模型選什麼，可以先從它開始。

推薦二：Llama 3.1 8B Instruct

Llama 3.1 8B Instruct 是一個很穩的通用模型，英文能力和工具生態都比較成熟。

適合場景：

英文問答。
輕量程式碼輔助。
通用聊天。
文件摘要。
提示詞測試。
對比不同推理工具。

建議選擇：

1
2
3

Llama 3.1 8B Instruct GGUF
Q4_K_M：速度和顯存更穩
Q5_K_M：回答品質更好

如果你主要處理英文資料，或者想要一個生態成熟、教學多、相容性好的模型，Llama 3.1 8B 仍然是很好的基準選擇。

推薦三：Gemma 3 12B

Gemma 3 12B 更接近 3060 12GB 的上限選擇。

它比 8B 模型更吃顯存，但在 Q4 量化下仍然有機會在 3060 12GB 上跑起來。適合想在單卡上嘗試更大一點模型的人。

適合場景：

更高品質的通用問答。
英文內容處理。
較複雜的總結和分析。
對 8B 模型不滿意時的升級嘗試。

建議選擇：

1
2
3

Gemma 3 12B GGUF
Q4_K_M 或官方 QAT Q4
上下文不要開太大

如果運行時爆顯存，可以先降低上下文長度，或者換回 8B 模型。對 3060 來說，12B 是「能試」，不是「無腦推薦」。

推薦四：DeepSeek R1 Distill Qwen 8B

如果你想在本地體驗推理風格模型，可以試 DeepSeek R1 Distill Qwen 8B 一類 8B 蒸餾模型。

適合場景：

簡單推理題。
分步驟分析。
學習推理模型輸出風格。
本地低成本實驗。

建議選擇：

1
2

DeepSeek R1 Distill Qwen 8B GGUF
Q4_K_M

需要注意，這類模型有時會輸出更長的推理過程，速度和上下文占用可能比普通指令模型更明顯。日常聊天不一定比 Qwen3 8B 更舒服，但用來做推理實驗很合適。

推薦五：Phi / MiniCPM / 小尺寸模型

如果你的 3060 不是 12GB 版本，而是 8GB 版本，或者電腦記憶體也比較小，可以優先考慮 3B、4B 級別模型。

適合場景：

快速問答。
簡單摘要。
嵌入到本地小工具。
低延遲聊天。
老電腦測試。

這類模型品質不一定能和 8B、12B 相比，但勝在輕、快、部署簡單。

量化怎麼選

本地模型常見格式是 GGUF，常見量化包括 Q4、Q5、Q6、Q8。

量化	特點	適合誰
Q4_K_M	體積小，速度好，品質夠用	3060 首選
Q5_K_M	品質更好，占用更高	8B 模型可以試
Q6 / Q8	更接近原始品質，占用更大	小模型或顯存寬裕時
Q2 / Q3	很省顯存，但品質下降明顯	大模型折騰用

對 RTX 3060 12GB 來說，最實用的是：

1
2
3

8B 模型：Q4_K_M 或 Q5_K_M
12B 模型：優先 Q4_K_M
更大模型：不建議作為日常主力

用什麼工具運行

新手可以從 Ollama 開始，優點是安裝和運行簡單。

常見命令形式：

1
2

ollama run qwen3:8b
ollama run llama3.1:8b

如果想更細地控制 GGUF 檔案、GPU layers、上下文長度，可以用 llama.cpp 或基於 llama.cpp 的圖形工具。

常見選擇：

Ollama：最省心，適合新手。
LM Studio：圖形介面友好，適合手動下載和切換模型。
llama.cpp：控制最細，適合折騰效能。
text-generation-webui：功能多，適合測試不同後端。

如果只是本地聊天和簡單問答，Ollama 或 LM Studio 就夠了。

上下文不要開太大

很多模型宣傳支援很長上下文，但 RTX 3060 運行時不要盲目開到最大。

上下文越長，KV cache 占用越高，顯存壓力也越大。即使模型能載入，長上下文也可能導致速度下降。

建議：

1
2
3

普通聊天：4K 到 8K
文件摘要：8K 到 16K
長文件 RAG：優先切片，不要硬塞全文

3060 更適合「中等上下文 + 好模型 + 好檢索」，不適合把幾十萬 token 一次性塞進去。

不同用途怎麼選

如果你主要寫中文：

1
2

優先：Qwen3 8B Q4_K_M
備選：DeepSeek R1 Distill Qwen 8B

如果你主要寫英文：

1
2

優先：Llama 3.1 8B Instruct Q4_K_M
備選：Gemma 3 12B Q4_K_M

如果你想跑得快：

1
2
3

3B / 4B 模型
8B Q4_K_M
上下文控制在 4K 到 8K

如果你想品質更好：

1
2
3

8B Q5_K_M
12B Q4_K_M
接受速度變慢

如果你想寫程式碼：

1
2

8B 程式碼模型可以輔助解釋和小改動
複雜工程任務仍建議用雲端強模型

本地 3060 模型適合做程式碼解釋、函式補全、小腳本生成和離線輔助；大型專案重構、複雜 bug、跨檔案 Agent 任務，不要期待它達到 Claude Sonnet 或 GPT-5 級別。

3060 本地 LLM 的合理預期

RTX 3060 12GB 的定位很清楚：它適合把本地 LLM 從「玩具」變成「日常可用工具」，但不是讓你在家裡復刻頂級雲端模型。

它的優勢是：

成本低。
顯存比 8GB 卡寬裕。
8B 模型體驗不錯。
可以離線使用。
適合隱私敏感資料的本地處理。

它的限制是：

大模型很難流暢。
長上下文會吃顯存。
推理速度不如高階卡。
本地小模型複雜推理能力有限。
多模態和 Agent 工作流會更吃資源。

所以最穩的路線是：用 8B 模型做日常本地助手，用 12B 模型做品質嘗試，複雜任務交給雲端模型。

小結

RTX 3060 12GB 最推薦的本地 LLM 選擇是：

中文通用：Qwen3 8B Q4_K_M
英文通用：Llama 3.1 8B Instruct Q4_K_M
更高品質嘗試：Gemma 3 12B Q4_K_M
推理實驗：DeepSeek R1 Distill Qwen 8B Q4_K_M
低顯存快速體驗：3B / 4B 小模型

量化優先選 Q4_K_M，8B 模型可以嘗試 Q5_K_M。工具優先從 Ollama 或 LM Studio 開始。

不要把 3060 當成大模型伺服器。把它當成本地知識助手、隱私文件處理器、輕量程式碼助手和模型實驗卡，會更符合它的實際能力。

參考連結

Qwen3 8B GGUF：https://huggingface.co/Qwen/Qwen3-8B-GGUF
Llama 3.1 8B GGUF：https://huggingface.co/macandchiz/Llama-3.1-8B-Instruct-GGUF
Gemma 3 12B GGUF：https://huggingface.co/unsloth/gemma-3-12b-it-GGUF
llama.cpp：https://github.com/ggml-org/llama.cpp
Ollama：https://ollama.com

TradingAgents-CN：面向中文使用者的多智能體金融交易研究框架

Fri, 01 May 2026 03:14:15 +0800

TradingAgents-CN 是一個面向中文使用者的多智能體金融交易研究框架。

它的目標不是給出「買哪隻股票」的簡單答案，而是用多個 AI Agent 模擬一個更完整的金融分析團隊：有人看基本面，有人看技術面，有人關注新聞和情緒，也有人負責風險和最終決策。對想研究 LLM + Agent + 金融分析的人來說，這類專案很適合作為實驗入口。

需要先說清楚：這類工具適合學習、研究和輔助分析，不應該被當成實盤交易建議。金融市場有風險，模型輸出也可能出錯、滯後或過度自信。

它解決什麼問題

普通聊天模型當然也能分析股票。

你可以直接問：「幫我分析某某公司能不能買。」模型會給出一段看起來完整的回答。但這種方式有幾個問題：

分析鏈路不透明
不同維度容易混在一起
缺少角色分工
缺少正反觀點碰撞
風險提示可能流於形式
很難復現同一套分析流程

TradingAgents-CN 的思路是把金融分析拆成多個角色，讓不同 Agent 負責不同角度，再透過協作、討論和總結形成分析結果。

這更接近真實投研流程。一個投資判斷通常不會只看一條新聞或一個技術指標，而是要結合公司基本面、市場環境、價格走勢、資金情緒、政策風險和倉位控制。

多智能體分析是什麼意思

多智能體不是簡單地讓多個模型輪流說話。

更有價值的做法，是給不同 Agent 分配清楚職責。比如：

市場分析 Agent：關注行情走勢、價格變化和市場環境
基本面分析 Agent：關注公司業務、財務資料和長期價值
新聞分析 Agent：關注公告、新聞、輿情和事件影響
技術分析 Agent：關注趨勢、指標、支撐阻力和交易訊號
風險管理 Agent：關注波動、回撤、倉位和不確定性
決策 Agent：綜合不同意見，形成最終判斷

這樣的結構可以減少單個模型「一口氣說完所有結論」的問題。

當不同角色圍繞同一個標的展開分析時，系統更容易呈現出多維度判斷，也更容易暴露分歧。對學習者來說，這比只看一段總結更有啟發。

為什麼需要中文版本

金融分析和語言環境關係很深。

中文使用者關注的資料來源、市場習慣、股票名稱、交易制度、新聞表達和常見術語，都和英文環境不同。直接使用英文框架，經常會遇到幾類問題：

中文股票名稱和代碼處理不順
A 股、港股、美股語境混雜
中文財經新聞理解不穩定
國內資料源接入不方便
輸出風格不符合中文使用者閱讀習慣

TradingAgents-CN 的意義在於把這套多智能體金融分析流程面向中文使用者做了適配。它讓中文使用者更容易搭建、執行和理解整個交易分析實驗流程。

可以用來做什麼

這個專案更適合做研究和輔助分析，而不是自動下單。

比較合適的用途包括：

學習多智能體系統如何協作
研究 LLM 在金融分析中的表現
對股票進行多角度資訊整理
比較不同模型在投研任務中的差異
搭建自己的金融分析 Agent 原型
複盤某個標的的歷史資訊和風險點
練習把投研流程拆成可執行任務

如果你正在學習量化交易、金融工程、AI Agent 或 LLM 應用開發，這類專案可以幫助你理解「AI 投研助手」背後的工程結構。

不適合做什麼

它不適合被直接當成穩賺工具。

尤其不適合：

直接根據輸出滿倉買賣
用模型結論替代自己的風險判斷
把短期價格預測當成確定結果
忽略交易成本、滑點和流動性
不做回測就接入真實帳戶
用單次分析結論替代長期投資策略

LLM 擅長整理資訊、生成解釋、模擬推理流程，但它並不天然擁有穩定預測市場的能力。金融市場裡，資訊噪音、突發事件和行為博弈都很強，模型輸出只能作為參考材料之一。

和普通量化框架有什麼區別

傳統量化框架更關注資料、因子、回測、組合優化和交易執行。

比如你會定義策略規則：

均線突破
動量因子
價值因子
波動率過濾
止損止盈
倉位管理

然後用歷史資料回測策略表現。

TradingAgents-CN 更偏向「智能體分析框架」。它關注的是如何讓多個 LLM Agent 圍繞金融任務協作，如何模擬投研討論，如何把新聞、基本面、技術面和風險判斷組織起來。

兩者不是替代關係。

更現實的用法是：傳統量化系統負責可驗證的規則和回測，Agent 系統負責資訊整理、報告生成、觀點對比和輔助決策。最終能不能進入真實交易，還要經過嚴謹回測、風控和人工審核。

和直接問 ChatGPT 有什麼區別

直接問模型的門檻最低，但流程很鬆散。

你問一次，它答一次。換個問法，結論可能就變了。你很難保證它每次都從同樣的維度分析，也很難讓它穩定扮演多個互相制衡的角色。

TradingAgents-CN 的價值是把分析流程結構化：

角色更明確
步驟更可復現
資訊來源更容易組織
觀點碰撞更自然
風險檢查更容易單獨處理
輸出更像一份投研流程結果

這對學習和研究很有用。你可以觀察不同 Agent 如何影響最終結論，也可以替換模型、調整提示詞、修改角色分工，比較結果變化。

使用時要關注哪些風險

第一，資料品質。

金融分析非常依賴資料。如果行情、財報、新聞或公告資料不完整、不及時，Agent 分析再流暢也可能建立在錯誤基礎上。

第二，模型幻覺。

LLM 可能編造不存在的事實、誤解資料含義，或者把舊資訊當成新資訊。涉及具體股票時，必須回到資料源核對。

第三，過度解釋。

模型很擅長給出「看起來合理」的解釋，但市場價格變化未必真的來自它列出的原因。不要把事後解釋誤當成因果證明。

第四，回測和實盤差距。

即便某個策略在歷史資料中表現不錯，真實交易中仍然會遇到滑點、手續費、流動性、停牌、漲跌停、極端行情等問題。

第五，許可證和商用邊界。

README 中提到專案採用混合許可證。個人學習研究和商業使用的條件可能不同。如果準備把它放進商業產品或服務，需要先仔細閱讀專案許可證說明。

適合怎樣的人研究

TradingAgents-CN 適合這些人：

想學習 AI Agent 架構的開發者
想研究 LLM 金融分析能力的人
做量化交易但想加入自然語言分析的人
想搭建投研輔助工具的團隊
想了解多角色協作如何影響決策的人
希望用中文環境實驗交易 Agent 的使用者

如果你的目標只是獲得一個簡單的買賣建議，這個專案反而不是最合適的打開方式。它更值得關注的是流程、角色、協作和風險控制，而不是某一次輸出的結論。

可以怎麼擴展

這類框架後續有很多可擴展方向：

接入更多可靠資料源
增加本地模型支援
加入回測模組
細化 A 股、港股、美股不同市場規則
增加產業分析 Agent
增加組合管理和倉位控制
加強報告引用和資料溯源
把 Agent 結論和傳統量化訊號結合

真正有價值的金融 AI 系統，通常不是讓模型單獨決定一切，而是讓它嵌入一個可驗證、可追蹤、可風控的流程裡。

參考

hsliuping/TradingAgents-CN

最後一句

TradingAgents-CN 值得關注的地方，不是它能不能預測下一根 K 線，而是它把金融分析拆成了一個多智能體協作流程。

把它當作學習和研究工具，會比把它當作自動賺錢機器更合理。

Prompt Optimizer：開源提示詞優化、測試與 MCP 工具

Fri, 01 May 2026 03:09:07 +0800

Prompt Optimizer 是一個開源的提示詞優化工具，目標很直接：幫助你把一段粗糙的提示詞改得更清楚、更穩定，也更容易被大型語言模型執行。

它不只是一個「幫我潤飾 prompt」的頁面。專案同時提供提示詞優化、結果測試、對比評估、多模型接入、圖像生成提示詞處理，以及 MCP 整合。對經常寫系統提示詞、使用者提示詞、AI 工作流模板的人來說，它更像一個專門用來打磨提示詞的工作台。

它解決什麼問題

很多人使用 AI 時都會遇到類似問題：

提示詞越寫越長，但模型輸出沒有明顯變好
同一個需求換個模型就表現不穩定
系統提示詞和使用者提示詞混在一起，很難拆開除錯
改了一版 prompt，不知道是不是真的比上一版更好
想複用變數模板，但每次都要手動替換和測試
想把提示詞優化能力接入其他 AI 工具，卻缺少標準介面

Prompt Optimizer 主要圍繞這些問題設計。它把「寫 prompt」拆成優化、測試、評估、對比、迭代幾個環節，讓提示詞不再只靠感覺調整。

主要功能

1. 優化系統提示詞和使用者提示詞

提示詞並不只有一種。

系統提示詞通常負責定義角色、目標、邊界、輸出規範和工作方法；使用者提示詞則更接近一次具體任務的輸入。兩者混在一起時，模型容易抓不住重點，後續複用也困難。

Prompt Optimizer 支援系統提示詞優化和使用者提示詞優化。你可以分別處理長期複用的角色設定，也可以處理某次具體任務的輸入表達。

這對下面幾類場景比較有用：

寫 AI 編程助手的工作規則
寫客服、審稿、翻譯、分析類角色提示詞
優化文生圖提示詞
把臨時需求整理成可複用模板
為不同模型準備不同風格的 prompt

2. 測試和對比輸出

只優化提示詞還不夠，關鍵是要知道優化後有沒有變好。

專案支援分析、單結果評估、多結果對比評估。也就是說，你可以把原始提示詞和優化後的提示詞放到同一個任務裡跑，看模型輸出是否更準確、更穩定、更符合目標。

這比單純「看起來更專業」的 prompt 更實用。因為很多提示詞表面上寫得完整，實際輸出卻可能更囉嗦、更僵硬，甚至把模型引向錯誤方向。對比測試能幫助你盡早發現這種問題。

3. 支援多模型

README 中提到專案支援 OpenAI、Gemini、DeepSeek、智譜 AI、SiliconFlow 等模型服務，也支援自訂 OpenAI 相容介面。

這點很重要。提示詞效果和模型強相關，同一段 prompt 在不同模型上的表現可能差別很大。多模型測試可以幫助你判斷：

是提示詞本身寫得不好
還是某個模型不適合這個任務
是否需要為不同模型準備不同版本
小模型能否透過更清楚的提示詞接近可用效果

如果你在本地使用 Ollama，或者公司內部有相容 OpenAI 介面的模型服務，也可以透過自訂介面接入。

4. 高級測試模式

專案提供上下文變數管理、多輪會話測試和 Function Calling 支援。

變數管理適合模板化任務。比如你有一套二手交易回覆、商品描述、郵件回覆、程式碼審查或文件生成提示詞，只需要替換商品、價格、語氣、目標使用者等變數，就能快速測試不同輸入下的表現。

多輪會話測試適合驗證長期對話能力。很多 prompt 在單輪問答裡看起來不錯，一旦進入多輪追問，就會忘記約束、偏離角色或重複解釋。多輪測試可以更接近真實使用場景。

Function Calling 支援則適合更工程化的 AI 應用。它能幫助你驗證模型在工具呼叫、參數生成和結構化輸出上的表現。

5. 圖像生成提示詞

Prompt Optimizer 也支援文生圖和圖生圖相關能力，README 中提到整合 Gemini、Seedream 等圖像模型。

文生圖提示詞的優化重點和文字任務不同。它更關注主體、構圖、空間關係、風格、材質、光線、情緒和限制條件。把一句很模糊的想法拆成更可控的視覺描述，通常比單純加長提示詞更有價值。

如果你經常需要生成產品圖、封面、插畫、主視覺或風格參考圖，這類優化會比較實用。

使用方式

專案提供多種入口：

線上版本
Vercel 自部署
桌面應用
Chrome 擴充功能
Docker 部署
Docker Compose 部署
MCP Server

線上版本適合快速體驗。專案說明中提到它是純前端應用，資料儲存在瀏覽器本地，並直接與 AI 服務商互動。

桌面應用適合需要直接連接各種模型 API 的使用者。瀏覽器環境容易遇到跨域限制，桌面應用可以繞過這類問題，尤其適合連接本地 Ollama 或一些跨域策略嚴格的商業 API。

Docker 部署適合放在自己的伺服器或內網環境裡使用。README 給出的基礎命令如下：

`1`	`docker run -d -p 8081:80 --restart unless-stopped --name prompt-optimizer linshen/prompt-optimizer`

如果要配置 API 金鑰和存取密碼，可以透過環境變數傳入：

docker run -d -p 8081:80 \
  -e VITE_OPENAI_API_KEY=your_key \
  -e ACCESS_USERNAME=your_username \
  -e ACCESS_PASSWORD=your_password \
  --restart unless-stopped \
  --name prompt-optimizer \
  linshen/prompt-optimizer

國內存取 Docker Hub 較慢時，專案也提供了阿里雲映像地址，可按 README 中的說明替換映像名稱。

MCP 能做什麼

Prompt Optimizer 支援 Model Context Protocol，也就是 MCP。

透過 Docker 執行時，MCP 服務可以和 Web 應用一起啟動，並透過 /mcp 路徑存取。這樣它就不只是一個網頁工具，而是可以被 Claude Desktop 等支援 MCP 的應用呼叫。

README 中列出的 MCP 工具包括：

optimize-user-prompt：優化使用者提示詞
optimize-system-prompt：優化系統提示詞
iterate-prompt：對已有提示詞做定向迭代

這類介面很適合放進 AI 工作流裡。比如你在寫複雜任務提示詞時，可以讓支援 MCP 的客戶端直接呼叫提示詞優化能力，而不必每次打開網頁手動複製。

和普通聊天工具有什麼區別

普通聊天工具當然也能幫你改 prompt，但它通常缺少幾個環節：

不方便保存和對比多個版本
不方便同時測試多個模型
不方便把變數模板化
不方便做多輪會話驗證
不方便接入 MCP 或部署到自己的環境

Prompt Optimizer 的價值在於把提示詞優化做成一個可重複的流程。它不只是給你一版「看起來更完整」的文字，而是讓你圍繞實際輸出持續調整。

適合誰使用

如果你符合下面幾種情況，可以重點關注這個專案：

經常寫系統提示詞
經常為 AI 應用設計角色和輸出格式
需要比較不同模型的輸出效果
想把 prompt 做成可複用模板
需要測試多輪對話或工具呼叫
想把提示詞優化能力接入 MCP 工作流
希望在本地或內網部署提示詞工具

如果你只是偶爾問 AI 一個簡單問題，用普通聊天頁面就夠了。這個工具更適合那些把提示詞當成可維護資產的人。

使用時要注意什麼

第一，不要把優化結果當成絕對正確。

提示詞優化工具可以提高表達品質，但不能保證模型一定不會誤解。重要任務仍然需要測試樣例、人工檢查和版本對比。

第二，不要只追求更長。

好的 prompt 不一定更長。它應該更清楚地表達目標、邊界、輸入輸出格式和判斷標準。無意義的規則堆疊反而會讓模型抓不住重點。

第三，要按模型調 prompt。

不同模型對角色設定、格式約束、推理步驟和範例的敏感度不同。一個在大模型上表現很好的提示詞，不一定適合小模型。多模型測試正是這個工具值得使用的原因之一。

第四，部署時要考慮金鑰和存取控制。

如果你把它部署到公網，應該配置存取密碼，並謹慎處理 API key。專案支援透過環境變數配置存取控制，不要把敏感配置直接寫到公開倉庫裡。

參考

linshenkx/prompt-optimizer

最後一句

Prompt Optimizer 適合用來把提示詞從「臨時手寫的一段話」整理成「可以測試、可以比較、可以迭代的工作資產」。

當你開始在多個模型、多個場景、多個版本之間維護 prompt 時，這類工具會比普通聊天視窗更順手。

Google LangExtract：用 LLM 從長文本裡抽取結構化資料

Fri, 01 May 2026 02:58:21 +0800

LangExtract 是 Google 開源的一個 Python 函式庫，用來從非結構化文本中抽取結構化資訊。

它的使用場景很直接：給它一段文本、一個提示詞和少量範例，讓大型語言模型按你定義的欄位抽取內容，並把結果組織成可處理的資料。

和普通「讓模型總結一下」不同，LangExtract 更關注三件事：

按固定結構抽取資訊
保留抽取結果和原文位置的對應關係
支援長文件和視覺化檢查

如果你經常需要從報告、論文、病歷、合約、日誌或網頁文本裡抽取實體、事件、關係和屬性，這類工具會比手寫正則更靈活，也比純聊天式提問更容易進入後續資料處理流程。

它解決什麼問題

很多文本抽取任務看起來簡單，實際做起來很麻煩。

比如你想從一篇長文裡抽取：

人名、機構名、地點
事件、時間、參與方
藥物、劑量、不良反應
產品型號、參數、價格
合約條款、義務、期限
日誌裡的錯誤類型和上下文

如果格式固定，正則或傳統解析器可以解決。
但只要文本表達稍微自然一點，規則就會迅速變複雜。

大型語言模型適合理解自然語言，但直接讓模型「抽一下」又容易出現幾個問題：

輸出格式不穩定
不知道資訊來自原文哪裡
長文件容易漏
很難批量處理
結果不方便人工複核

LangExtract 想解決的就是這一層問題：把 LLM 的理解能力包裝成更可控的抽取流程。

LangExtract 的幾個特點

1. 用範例約束抽取格式

LangExtract 的思路不是只給一句含糊提示詞，而是透過 prompt 和 examples 告訴模型：

要抽取什麼
欄位叫什麼
每個欄位應該怎麼填
不確定時應該怎麼處理

這種 few-shot 方式很適合資訊抽取任務。
你給的範例越貼近真實資料，模型越容易穩定輸出相同結構。

2. 抽取結果能對應回原文

資訊抽取最怕「看起來對，但不知道從哪來的」。

LangExtract 的一個重點是把抽取結果和原文位置對齊。這樣你後續檢查時，不只是看到一個 JSON 結果，還能回到原文看這條資訊來自哪一段。

這對需要複核的場景很重要，比如醫學文本、法律文本、研究資料和企業內部文件。

3. 支援長文件

長文件抽取容易遇到上下文窗口、漏抽和重複抽取問題。

LangExtract 提供了面向長文本的處理方式，可以把長文件拆分後並行處理，再把抽取結果組織起來。

這讓它更適合處理完整報告、論文、長網頁、批量資料，而不是只處理一小段文本。

4. 支援視覺化檢查

抽取結果如果只能看 JSON，很容易漏掉問題。

LangExtract 支援把抽取結果視覺化，讓你更直觀地查看模型從哪裡抽了什麼。
這對調 prompt、查漏抽、查誤抽都很有幫助。

什麼時候適合用

LangExtract 適合這些場景：

你要從自然語言文本中抽結構化欄位
文本格式不完全固定
需要保留抽取結果和原文的對應關係
需要處理較長文件
結果需要人工複核
後續要進入表格、資料庫或資料分析流程

典型例子包括：

從醫學文本裡抽取症狀、藥物、劑量和反應
從合約裡抽取甲乙方、義務、金額和期限
從論文裡抽取研究對象、方法、結論
從產品資料裡抽取規格參數
從客服記錄裡抽取問題類型和處理結果

如果只是臨時問一段文本的大意，用普通聊天模型就夠。
如果你要把文本變成後續可處理的資料，LangExtract 會更合適。

基本安裝

專案支援透過 pip 安裝：

`1`	`pip install langextract`

也可以從原始碼安裝：

1
2
3

git clone https://github.com/google/langextract.git
cd langextract
pip install -e .

如果要使用模型 API，需要按對應模型提供方配置 API key。
專案文件裡重點展示了 Gemini 相關用法，也支援透過適配層接入其他模型提供方。

基本使用思路

一個典型流程大概是：

準備原始文本
寫清楚抽取目標
給少量範例
呼叫 LangExtract 執行抽取
檢查結構化結果
必要時產生視覺化頁面複核

這裡最關鍵的是第二步和第三步。

提示詞要描述清楚任務，例如：

只抽取文本中明確出現的資訊
不要根據常識補充
欄位缺失時留空
同一類實體保持欄位結構一致
輸出中保留原文片段或位置

範例要盡量接近真實輸入。
如果真實文本裡有雜訊、縮寫、換行、表格殘留，範例裡最好也體現出來。

用它時要注意什麼

第一，不要把抽取任務寫得太泛。

比如「抽取有用資訊」就太寬。
更好的寫法是「抽取藥物名稱、劑量、給藥頻率和不良反應」。

第二，不要完全信任模型輸出。

LangExtract 能把結果和原文對齊，但這不等於模型永遠不會漏抽或誤抽。重要場景仍然需要抽樣檢查，必要時加人工複核。

第三，範例比長篇解釋更有用。

資訊抽取任務裡，模型往往更依賴範例來理解輸出格式。
與其寫一大段抽象規則，不如給幾個高品質 example。

第四，長文件要關注成本和速度。

長文件拆分、並行抽取、模型呼叫都會帶來成本。正式批量處理前，最好先拿一小批樣本調好提示詞和欄位結構。

和正則、傳統 NLP 有什麼區別

正則適合格式穩定、規則清楚的文本。

傳統 NLP 管線適合任務邊界明確、模型或詞典已經準備好的場景。

LangExtract 更適合格式不那麼固定、但語義比較明確的文本。
它不要求你為每種表達都寫規則，而是讓 LLM 根據範例理解抽取目標。

但這也意味著它不是正則的完全替代品：

對格式固定的文本，正則更便宜、更穩定
對高風險場景，仍然要驗證和複核
對大規模批量處理，要考慮模型呼叫成本

比較實際的做法是：規則清楚的部分用程式處理，語義變化大的部分交給 LangExtract。

適合怎樣的開發者

如果你正在做下面這些事情，可以關注 LangExtract：

把長文本整理成表格
從文件中抽實體和關係
做知識庫入庫前的資料清洗
從業務文本中抽取欄位
做 LLM 驅動的資訊抽取原型
需要保留抽取結果和原文證據

它不是一個「點一下就自動懂所有文件」的工具，更像是一個幫你把 LLM 抽取流程工程化的函式庫。

你仍然需要設計欄位、寫範例、檢查結果。
但相比每次手寫模型呼叫、拼 prompt、解析輸出，它提供了更完整的抽取框架。

參考

google/langextract

最後一句

LangExtract 的價值在於把「讓 LLM 從文本裡找資訊」這件事做得更可控。

它適合的不是隨口總結，而是有欄位、有證據、有複核需求的資訊抽取任務。
如果你的工作裡經常要把長文本變成結構化資料，可以把它作為一個值得試用的工具。

大模型 API 為什麼按 Token 收費：一文講清輸入、輸出和上下文成本

Sat, 25 Apr 2026 08:44:32 +0800

在大模型 API 的計費方式裡，最容易讓人困惑的一點，就是為什麼幾乎所有平台最後都會落到 token 這個單位上：大模型為什麼按 token 收費，而且不同 token 還會有不同價格。

很多人剛接觸模型 API 時，最困惑的不是模型能力，而是帳單。明明只問了幾個問題，為什麼費用會漲得這麼快？為什麼輸入便宜、輸出更貴？為什麼上下文一長，成本就開始明顯失控？

如果把這件事講簡單一點，可以先記住一句話：模型收費，買的不是「一次回答」，而是整段推理過程中消耗的計算與帶寬資源。

1. 什麼是 token

在大模型計費裡，token 不是「字數」也不是「單詞數」，而是模型處理文字時使用的切分單位。

它可能是：

一個漢字
一個英文單詞的一部分
一個標點符號
一小段常見詞組

所以 API 平台通常不會按「每句話」或「每次請求」收費，而是按模型實際讀入和生成的 token 數量收費。
這比按請求次數計費更合理，因為同樣是一次請求，可能只輸入 20 個字，也可能塞進 20 萬 token 的上下文，兩者消耗完全不是一個量級。

2. 為什麼輸入和輸出要分開定價

現在大多數模型 API，都會把價格拆成兩部分：

輸入 token 價格
輸出 token 價格

而且常見情況是：輸出 token 比輸入 token 更貴。

原因並不難理解。

模型處理輸入時，本質上是在「讀」和「編碼」已有內容；但生成輸出時，它需要一步一步預測下一個 token，再繼續預測下一個 token。這個過程不只是讀取，而是持續進行推理和採樣，所以通常更耗算力。

你可以把它粗略理解成：

輸入：像把材料遞給模型
輸出：像讓模型現場寫答案

「現場寫」的計算成本，通常比「把材料讀一遍」更高，所以輸出價格更貴是很常見的設計。

3. 為什麼上下文越長，費用越容易失控

很多人以為自己只是在「多貼一點背景資料」，但從模型帳單的角度看，這件事的影響往往比想像中大。

原因在於：模型每次調用時，通常都要重新處理目前請求裡帶進去的整段上下文。

也就是說，如果你目前請求裡包含：

系統提示詞
歷史對話
工具返回結果
長文件片段
程式碼檔案內容

這些內容都會一起進入輸入 token 計費。

所以真正讓帳單變大的，往往不是最後那一句提問，而是它前面拖著的一大串上下文。
當對話輪數增加、工具調用變多、歷史訊息不斷回灌時，token 成本就會一輪一輪被放大。

4. 工具調用為什麼特別容易漲 token

在 Agent、程式碼助手、工作流自動化這類場景裡，token 消耗通常比普通聊天高得多。

問題不只是「模型回答了一段話」，而是整個流程裡會不斷出現這些內容：

讀檔案
看日誌
調 API
返回 JSON
把工具結果再回填給模型

每一次工具調用的結果，只要被重新塞回下一輪上下文，就會繼續變成新的輸入 token。

這就是為什麼很多開發者最後會發現：
不是模型本身單價特別離譜，而是工作流把 token 帳單一層層疊上去了。

例如一個編碼 Agent 連續做下面這些事：

讀取專案結構
打開幾個原始碼檔案
跑一次測試
把報錯日誌餵回模型
再讀更多相關檔案

每一步都可能讓後續請求背著更長的上下文繼續跑。這樣即使單價不變，總帳單也會很快增長。

5. 為什麼同樣是模型，價格會差很多

不同模型的 token 價格差異，背後通常不只是「廠商想賣貴一點」，而是和幾個因素直接相關：

模型規模
推理效率
上下文長度
部署成本
目標市場

模型越大、活躍參數越多、推理鏈路越複雜，單次生成一個 token 的成本通常就越高。
如果模型還支援超長上下文、複雜推理、工具調用優化，那它的基礎設施壓力也會進一步增加。

所以定價本質上是在覆蓋幾類成本：

GPU / 加速卡資源
顯存占用
推理延遲
網路與服務穩定性
峰值並發能力

便宜模型不一定差，貴模型也不一定適合所有場景。很多時候價格差，反映的是「這類能力大概值多少基礎設施成本」。

6. 為什麼快取輸入會更便宜

不少模型平台現在會提供：

cached input
prompt caching
prefix caching

這類能力的共同思路是：如果一大段輸入已經算過，就不要每次都從頭按原價重算。

比如一段固定 system prompt、固定工具說明、固定長文件前綴，如果每輪都完全重複發送，平台就有機會把其中一部分計算快取下來。這樣同樣是輸入 token，命中快取的部分就可以按更低價格計費。

這也解釋了為什麼很多 API 價格頁會出現三檔甚至更多價格：

普通輸入
快取輸入
輸出

它們反映的不是文字內容不同，而是底層計算是否可以重用。

7. 「便宜 token」為什麼不等於「總成本更低」

很多人看到某個模型「每百萬 token 超便宜」，第一反應是總成本一定更低。實際上不一定。

因為總帳單大致等於：

token 單價 × 實際消耗量

而實際消耗量又會被很多因素放大：

提示詞寫得太長
歷史訊息不清理
工具結果回填過多
輸出太囉唆
一個任務反覆重試

所以真正決定帳單的，通常不是單價一個變數，而是：

模型單價
每輪輸入長度
每輪輸出長度
調用次數
工作流設計

這也是為什麼「低單價模型」在某些 Agent 任務裡，最後總費用仍然可能不低。因為它可能需要更多輪互動、更多補充上下文、更多失敗重試。

8. 開發者該怎麼估算 token 成本

如果你想在專案裡更穩地控制預算，可以先用一個很樸素的估算方式：

統計平均每次請求的輸入 token
統計平均每次請求的輸出 token
估算一個任務會調用多少輪
再乘上對應模型單價

舉個思路上的例子：

每輪輸入 8k tokens
每輪輸出 1k tokens
一個任務跑 10 輪

那它真正消耗的就不是「一次問答」，而是：

輸入約 80k tokens
輸出約 10k tokens

如果中途還有日誌、工具結果、檔案內容不斷追加，總量還會繼續上升。

所以做預算時，最好不要只看單輪，而要看一個完整任務閉環到底會吃掉多少 token。

9. 怎麼實際控制帳單

如果你已經在用 API 或 Agent，下面這些做法通常最有效：

縮短 system prompt，避免重複廢話
定期裁剪歷史訊息
工具返回結果只保留必要欄位
長文件先檢索，再餵局部片段
控制輸出長度，避免模型無上限展開
高價值任務用貴模型，低價值任務用便宜模型

很多時候，省錢最有效的方式不是一味換更便宜的模型，而是先把工作流裡沒有意義的 token 消耗砍掉。

10. 這件事真正該怎麼理解

大模型 token 定價，說到底是在替「模型讀了多少、想了多少、寫了多少」計費。

它不是傳統軟體那種按帳號、按次數、按包月就能完全描述的資源模型，因為模型調用本身就是一個動態計算過程。你塞進去的上下文、拉起的工具、要求的輸出長度，都會直接影響成本。

所以理解 token 定價，最重要的不是背價格表，而是先建立一個直覺：

長上下文會漲輸入成本
長輸出會漲生成成本
工具鏈會放大總 token
快取和工作流設計會明顯影響帳單

只要把這幾個點想清楚，大多數模型 API 的價格結構其實都不難理解。

DeepSeek-V4 Preview 發布：1M 上下文、雙模型與 API 切換提醒

Fri, 24 Apr 2026 22:39:46 +0800

DeepSeek 在 2026-04-24 發布了 DeepSeek V4 Preview Release。從官方新聞頁來看，這次更新的重點非常集中：1M context、V4-Pro 與 V4-Flash 雙模型、針對 Agent 場景的專門優化，以及 API 側的模型切換。

如果只看一句話，這次發布的核心訊號是：DeepSeek 不只是繼續做更強的模型，而是在把超長上下文和 Agent 能力一起往「可以直接上線使用」的方向推進。

1. 這次一共發布了什麼

官方頁面裡，DeepSeek-V4 Preview 主要包含兩條產品線：

DeepSeek-V4-Pro
DeepSeek-V4-Flash

對應的官方描述也很直接：

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

從命名就能看出來，這次不是單模型升級，而是把高性能版本和更高性價比版本同時推出。

其中 V4-Pro 更強調上限，官方表示它的表現已經可以和全球頂級閉源模型競爭；V4-Flash 則更強調速度、效率和成本，更適合對回應速度和 API 成本更敏感的場景。

2. `1M context` 是這次最突出的賣點

官方頁面最醒目的表述之一，就是：「Welcome to the era of cost-effective 1M context length.」

DeepSeek 這次不只是說「支援長上下文」，而是明確把 1M context 當成這代模型的預設能力來講。頁面裡也寫得很清楚：

1M context 已經成為官方 DeepSeek 服務的預設標準
V4-Pro 和 V4-Flash 都支援 1M context

這件事的意義不只是「能塞更多 token」。它更直接影響下面這些任務：

長程式碼倉庫理解
長文件問答與資料整理
多輪 Agent 工作流
橫跨多檔案、多工具、多階段的複雜任務

如果上下文窗口夠大，模型就比較不容易因為中途丟失上下文而反覆回讀材料，這對 Agent 編碼和複雜知識工作會特別重要。

3. `V4-Pro` 主要在強調什麼

從官方頁的措辭來看，DeepSeek-V4-Pro 重點強調三件事：

Agentic Coding 能力
世界知識
推理能力

頁面提到，V4-Pro 在 Agentic Coding benchmark 上達到開源 SOTA；在世界知識方面領先目前的開源模型，只落後於 Gemini-3.1-Pro；在數學、STEM 和編碼能力上超過目前的開源模型，並且可以和頂級閉源模型競爭。

換句話說，V4-Pro 的定位並不是單純回答問題，而是更偏向高難度推理、複雜編碼和長任務執行。

4. `V4-Flash` 並不是簡單的縮水版

另一個值得注意的點是，官方沒有把 V4-Flash 包裝成「低配模型」，而是強調它在很多實際任務裡已經足夠強。

按照新聞頁給出的說法，V4-Flash：

推理能力已經很接近 V4-Pro
在簡單 Agent 任務上與 V4-Pro 表現相當
參數規模更小、回應更快、API 定價更便宜

這意味著 DeepSeek 這次給出的並不是「一個旗艦、一個入門」這種非常割裂的組合，而更像是：

V4-Pro：追求更高性能和更強上限
V4-Flash：追求更低延遲和更好的成本效率

對開發者來說，這樣的組合會更實用，因為很多線上任務真正需要的不是「理論最強」，而是「夠強、夠快、夠省」。

5. 官方特別強調了 Agent 優化

這次發布頁裡還有一個很明確的方向：DeepSeek 在主動把 V4 往 Agent 場景上推。

官方頁面提到，DeepSeek-V4 已經和一些主流 AI Agent 深度整合，包括：

Claude Code
OpenClaw
OpenCode

同時 DeepSeek 也提到，V4 已經在內部 agentic coding 場景中使用。

這說明它想覆蓋的，不再只是聊天或普通補全，而是更長鏈路的工作方式：讀程式碼、理解結構、調用工具、生成結果，再把整條流程串起來。

如果你最近剛好在關注 coding agent，這個訊號值得留意。因為它意味著模型廠商已經不再只拼 benchmark，而是在拼「能不能真正接進工作流」。

6. 底層結構創新是在為長上下文服務

在技術描述上，官方頁把這次的結構創新總結為：

token-wise compression
DSA (DeepSeek Sparse Attention)

頁面給出的方向非常明確：目標是把長上下文做得更便宜、更高效，盡量降低計算和顯存成本。

雖然新聞頁沒有展開完整技術細節，但這至少說明 DeepSeek 這次不是單純靠「更大算力硬堆更長窗口」，而是在結構層面針對長上下文效率做了專門優化。

對實際使用者來說，這通常比單純「窗口數字變大」更重要，因為真正決定可用性的，不只是能不能開到 1M，還包括：

速度是否還能接受
成本是否還能接受
長上下文任務是否真的穩定

7. API 已經可用，但要注意模型切換

官方頁面明確寫到，這次 API 當天就已經可用。

接入方式也比較簡單：

base_url 保持不變
把模型名切換為 deepseek-v4-pro 或 deepseek-v4-flash

同時頁面說明，這兩個模型都支援：

1M context
Thinking / Non-Thinking 雙模式
OpenAI ChatCompletions
Anthropic APIs

這意味著如果你原本已經接了 DeepSeek API，升級門檻並不高，主要是模型名切換和能力驗證。

8. 舊模型的退役時間也寫得很明確

對開發者來說，這次新聞頁裡最不能忽略的資訊之一，其實是舊模型退役提醒。

官方寫明：

deepseek-chat
deepseek-reasoner

會在 2026 年 7 月 24 日 15:59（UTC） 後完全退役並不可訪問。

頁面還說明，當前這兩個模型實際上已經路由到 deepseek-v4-flash 的非思考 / 思考模式。

這意味著如果你的專案裡還直接寫著 deepseek-chat 或 deepseek-reasoner，現在就應該開始安排遷移，而不要拖到正式下線前再處理。

9. 這次發布值得怎麼理解

如果把這次更新濃縮成幾個重點，大概可以這樣看：

DeepSeek 開始把 1M context 從「高配能力」變成預設標準
雙模型路線更清晰：一個衝性能上限，一個衝速度和性價比
Agent 能力已經被放到很核心的位置
API 升級路徑相對直接，但舊模型退役時間需要盡快關注

對一般使用者來說，最直觀的變化可能是：長文件、長程式碼、長流程任務會更容易放進一次上下文裡。
對開發者來說，更重要的是：如果你已經在做 Agent、程式碼助手、資料整理、複雜工作流，這一代模型顯然就是朝這些場景設計的。

DeepSeek 這次發布，不只是一次常規模型更新，更像是在明確它下一階段的產品方向：超長上下文 + Agent 優化 + 更實際的 API 可用性。

顯卡推理速度測試的常用指標具體含義：FA、pp512、tg128、Q4_0 都是什麼意思

Thu, 23 Apr 2026 00:15:00 +0800

只要你開始看本地大模型或顯卡推理速度測試，很快就會遇到一堆縮寫：FA、pp512、tg128、Q4_0。它們看起來都像是效能指標，但如果沒有上下文，確實很容易看得一頭霧水。

例如你可能會看到這樣一行：

`1`	`CUDA Scoreboard for Llama 2 7B, Q4_0 (no FA)`

再往下看，又會看到像這樣的欄位：

1
2

pp512 t/s
tg128 t/s

如果不把這些詞拆開理解，你很難真正看懂這類速度測試到底在測什麼，也很難知道兩張不同顯示卡的成績到底該怎麼比。

這篇文章不打算討論「哪張卡更值得買」，而是專門把顯卡推理速度測試裡最常見的幾個指標拆開講清楚。

先看整行標題到底在說什麼

像 CUDA Scoreboard for Llama 2 7B, Q4_0 (no FA) 這樣一行，其實已經把測試背景交代得差不多了。

它至少包含四層資訊：

CUDA：說明跑分是在 NVIDIA GPU 的 CUDA 路徑上完成的
Llama 2 7B：說明測試對象是 Llama 2 的 7B 參數版本
Q4_0：說明模型用了 4-bit 量化格式
no FA：說明這次測試關閉了 Flash Attention

也就是說，這種標題的完整意思通常是：

「在 NVIDIA 顯示卡上，執行某個量化版本的大模型，並測量它在特定推理路徑下的速度表現。」

FA 是什麼：Flash Attention

這裡的 FA，指的是 Flash Attention。

它是大模型推理和訓練中非常關鍵的一類加速技術，主要目標是優化注意力機制的計算方式。因為在 Transformer 模型裡，注意力計算本來就是最耗時、最吃顯存頻寬的部分之一。

傳統注意力實作的一個問題是：

需要頻繁讀寫顯存
中間結果很多
資料會在顯存和片上快取之間來回搬運
上下文一長，開銷會非常明顯

Flash Attention 做的事情，可以簡單理解成：

重新組織計算順序
減少中間結果落到顯存的次數
讓更多操作留在更快的快取裡完成

所以它的典型效果通常有三點：

更快
更省顯存
在數學上和普通注意力等價，不是「犧牲精度換速度」

這也是為什麼今天很多推理框架、訓練框架都把它當成非常重要的優化項。

no FA 是什麼意思

既然 FA 是 Flash Attention，那麼 no FA 就很好理解了：這次測試沒有啟用 Flash Attention。

也就是說，跑分用的是更傳統的注意力實作。

之所以很多跑分表會特地把 no FA 標出來，通常是為了下面幾件事：

做對照組，方便看出開啟 FA 後到底提升了多少
相容某些不支援 FA 的硬體或軟體環境
避免不同測試項混在一起，導致資料不可比

所以你看到 no FA 時，不要把它理解成「這張卡不行」，更準確的理解是：

「這個成績是在沒有開啟 Flash Attention 優化的前提下測出來的。」

Q4_0 是什麼：量化格式

Q4_0 指的是一種 4-bit 量化格式。

大模型原始權重通常不是這種低精度格式，直接載入時體積會非常大。量化做的事情，本質上就是把原本更高精度的權重壓縮成更低位寬的表示方式，讓模型更容易在消費級顯示卡上運行。

你可以先把它粗略理解成：

Q：Quantization，量化
4：4-bit
_0：某一種具體量化方案的標識

它的重要意義在於：

減少模型體積
降低顯存需求
讓本來裝不下的模型變得能跑起來

所以 Llama 2 7B, Q4_0 的意思，不是「一個普通的 7B 模型」，而是「一個已經經過 4-bit 量化壓縮的 7B 模型」。

pp512 t/s 是什麼意思

pp512 一般指的是：

Prompt Processing 512 tokens

它衡量的是模型處理輸入提示詞時的速度，單位通常是 t/s，也就是 tokens per second。

這裡的 512，表示測試時輸入的提示詞長度是 512 token。

這個指標測的不是「吐字速度」，而是模型在開始回答之前，對輸入內容做編碼和計算的速度。你可以把它理解成模型在「先把你說的話讀完」的階段有多快。

這個階段通常有一個很重要的特點：並行度比較高。

因為輸入序列可以成批處理，所以 GPU 在這個階段往往能把算力壓得很滿。也正因如此，pp512 的數值經常會非常高，看起來甚至高得有點誇張。

所以如果你看到：

`1`	`pp512 ≈ 14000 t/s`

不要驚訝，這測的是「輸入處理吞吐量」，不是模型一邊一邊吐字的速度。

tg128 t/s 是什麼意思

tg128 一般指的是：

Text Generation 128 tokens

它測的是模型連續生成 128 token 時的平均生成速度，單位同樣是 t/s。

這個指標更接近我們平時對「模型回答快不快」的直覺感受，因為它真的在測輸出階段。

但它和 pp512 最大的不同在於：文本生成通常是自回歸的。

簡單說就是：

要先算出第一個 token
才能繼續算第二個 token
再繼續算第三個 token

所以這個階段沒法像輸入處理那樣大規模並行，速度天然會慢很多。

這也是為什麼你經常會看到：

pp512 是上萬 t/s
tg128 卻只有幾百 t/s

這不是跑分出錯，而是它們本來就在測兩種完全不同的工作負載。

為什麼 pp512 和 tg128 會差這麼多

這是很多人第一次看 scoreboard 時最困惑的一點。

原因可以概括成一句話：

pp512 更像在測並行吞吐，tg128 更像在測逐 token 生成能力。`

再展開一點說：

輸入階段更容易並行
輸出階段更依賴逐步遞推
生成階段通常更吃顯存頻寬和快取效率
所以生成速度遠低於輸入處理速度是正常現象

也正因為這樣，很多時候兩張卡的表現會出現一種很有意思的情況：

在 pp512 上，一張卡更強
在 tg128 上，另一張卡反而略快

這並不矛盾。因為一個更偏算力峰值，一個更偏實際生成路徑下的頻寬和延遲表現。

t/s 到底怎麼理解

這裡的 t/s，就是 tokens per second。

它表示模型每秒能處理或生成多少個 token。

但需要注意，token 不是「字」，也不是「單詞」，它是模型分詞器切出來的單位。不同模型、不同語言環境下，一個 token 對應的文本長度可能差別很大。

所以在實際閱讀跑分時，t/s 更適合用來做：

同模型下不同顯示卡對比
同環境下不同參數設定對比
同一框架裡開啟或關閉某個優化項前後的對比

而不太適合直接拿來跨模型、跨框架、跨分詞器硬比「誰絕對更快」。

看 scoreboard 時，最該先抓住哪幾個點

如果你不想每次都被一堆縮寫淹沒，可以先抓這幾個核心問題：

1. 測試模型是什麼

比如是不是 Llama 2 7B，是不是同一個量化版本，例如 Q4_0。模型不同、量化不同，成績直接橫比意義不大。

2. 有沒有開啟關鍵優化

最常見的就是 FA。如果一個測試開了 Flash Attention，另一個沒開，那兩邊成績不能簡單直接對讀。

3. 看的是輸入速度還是輸出速度

pp512 和 tg128 分別在測不同階段。一個更像「讀題速度」，一個更像「回答速度」。

4. 關注的是吞吐還是體感

如果你更在意長提示詞載入速度，pp512 更有參考價值；如果你更在意模型回答時的流暢程度，tg128 往往更貼近真實體感。

一個更實用的理解方式

如果要把這些指標壓縮成一句最容易記住的話，可以這樣理解：

Q4_0：模型被壓縮成了 4-bit 量化版本
FA：是不是啟用了 Flash Attention 加速
pp512：處理 512 token 輸入時有多快
tg128：生成 128 token 輸出時有多快
t/s：速度單位，每秒多少 token

只要先把這五件事分清楚，再看類似的 CUDA Scoreboard 時，就更容易判斷「這個分數到底是在測什麼」。

結語

很多 GPU 跑分表看起來複雜，不是因為指標本身特別神祕，而是因為它把模型、量化、優化項和不同階段的吞吐都壓縮進了很短的幾行縮寫裡。

一旦把 FA、Q4_0、pp512、tg128 這些詞拆開，你會發現這類 scoreboard 其實並不難讀。

真正重要的，不是只記住某張卡跑了多少分，而是知道：

這個分數是在什麼模型下測的
有沒有開關鍵優化
它測的是輸入，還是輸出
它更反映算力，還是更接近實際生成體驗

這樣你以後再看類似跑分表時，就更容易判斷這些結果分別對應什麼測試條件和性能含義。

大模型常見張量類型入門：FP32、FP16、BF16、TF32 與 FP8

Wed, 22 Apr 2026 22:40:00 +0800

只要你開始接觸大模型訓練、推理或部署，很快就會遇到一組高頻縮寫：FP32、FP16、BF16、TF32、FP8。它們看起來像是模型頁面上的幾個附加標籤，但實際影響遠不只是「寫法不同」。

這些類型決定了數字在顯存裡怎麼存、在計算中怎麼表示，也直接影響模型訓練是否穩定、推理速度如何，以及一張顯示卡到底能裝下多大的模型。

所以如果你想真正理解大模型裡的精度取捨，最值得先補的一課，不是某個具體模型的跑分，而是先把這些常見張量類型各自是什麼、為什麼會這樣設計搞清楚。

張量類型到底在決定什麼

大模型本質上是海量參數參與的矩陣運算，而張量類型就是這些數字在顯存裡如何存、在計算中如何表示。

它的核心取捨通常圍繞三個維度展開：

精度
顯存占用
計算速度

這和圖片格式其實很像。無損格式保留細節更多，但體積大、載入慢；壓縮格式會丟掉一部分人眼不敏感的資訊，換來更小的體積與更快的處理速度。大模型之所以能接受這種取捨，是因為在極大量參數裡，很多微小數值變化並不會明顯影響最終輸出。

也正因如此，模型世界裡才會出現一整套不同精度的張量格式。

一個數字是怎麼被表示的

理解這些格式之前，可以先記住一個非常基礎的結構。一個浮點數通常由三部分組成：

符號位：決定正負
指數位：決定數值範圍
尾數位：決定數值精細程度

在大模型裡，尾數精度當然重要，但很多時候模型更怕的是數值範圍不夠，也就是指數位太小，導致溢出或訓練不穩定。很多張量格式的設計，本質上就是在「範圍」與「細節」之間重新分配有限的 bit 數。

下面這張圖可以先幫你建立一個整體印象：

FP32：最穩，但最貴

FP32 是最傳統的單精度浮點格式，總共 32 bit，也就是 4 個位元組。

它的優點很直接：

數值範圍大
精度高
訓練最穩

但問題也同樣明顯：太占顯存。

一個非常粗略的估算方式是：

`1`	`顯存占用 ≈ 參數量 × 每個參數的位元組數`

如果一個 27B 模型完全用 FP32 存權重，那麼光權重本身就大約需要：

`1`	`27B × 4 bytes ≈ 108GB`

這還沒算激活值、KV Cache、優化器狀態與其他執行期開銷。也就是說，FP32 在今天的大模型推理與訓練裡，已經不是「預設選擇」，而更像是「最穩的基線格式」。

FP16：體積減半，但穩定性一般

FP16 把每個參數壓縮到 2 個位元組，顯存占用相較 FP32 直接減半。

對同一個 27B 模型來說，如果只看權重體積：

`1`	`27B × 2 bytes ≈ 54GB`

這就已經能解釋為什麼很多部署說明裡，27B 模型的顯存需求會落在 50GB 左右。

FP16 的優勢很明顯：

顯存壓力大幅下降
吞吐更高
早期混合精度訓練大量使用

但它的問題在於指數位偏小，動態範圍不夠大。對大模型訓練來說，這會讓溢出更容易發生，需要額外依賴 loss scaling 一類技巧來補救，工程上比較麻煩。

所以現在 FP16 仍然常見，但在很多場景裡，它已經不再是最舒服的選擇。

BF16：大模型時代更實用的半精度

BF16 同樣只占 2 個位元組，但和 FP16 的設計重點不一樣。

它保留了更大的指數範圍，讓它在動態範圍上更接近 FP32，只是犧牲了一部分尾數精度。這種取捨對大模型尤其友好，因為很多時候模型對「範圍」更敏感，對尾數少幾位反而沒那麼敏感。

這也是為什麼現在很多訓練框架、很多大模型論文與大量實際部署方案，都更偏向 BF16。

你可以把它理解成：

顯存成本接近 FP16
穩定性體驗更接近 FP32

如果一套 27B 部署方案寫的是 50GB 左右顯存，而另一套經過進一步優化後接近 30GB，前者往往還停留在 FP16/BF16 這一層，後者則通常已經繼續往更低精度或量化方向走了。

TF32：不是省顯存，而是加速 FP32 工作流

TF32 很容易被誤會成「又一種更省的格式」，但它的定位其實不太一樣。

從常見理解上看，它可以近似視為一種保留較大指數範圍、但縮短尾數精度的計算格式。

不過要注意，TF32 更像是一條 Tensor Core 計算路徑裡的內部計算格式，而不是像 FP16/BF16 那樣主要拿來做權重存儲。

它主要是 NVIDIA 在較新的 GPU 上提供的一種計算模式，目標不是減少顯存占用，而是讓原本基於 FP32 的訓練流程，在盡量不大改程式碼的前提下跑得更快。

它的特點可以概括成一句話：

對外看起來還是 FP32 工作流
底層在矩陣乘法時做了更快的近似計算

所以 TF32 主要解決的是「FP32 太慢」的問題，而不是「FP32 太占顯存」的問題。如果你關心的是為什麼同一個模型部署時顯存需求不一樣，TF32 不是最主要的答案。

FP8：進一步壓縮，但更考驗工程能力

再往下走就是 FP8。它把單個數值繼續壓縮到更少 bit 數，進一步降低顯存頻寬與存儲成本。

它常見的不是單一一種格式，而是兩類變體：E4M3 和 E5M2。

但 FP8 的代價也很明顯：位數太少以後，你很難同時兼顧範圍和精度，因此實際工程裡通常會針對不同階段採用不同變體，分別照顧前向、反向與梯度的穩定性。

這類格式代表的是一種更激進的思路：

願意犧牲更多精度
換取更低的存儲與更高的吞吐
需要更成熟的硬體與訓練框架配合

它很有前景，但對一般使用者來說，日常最常碰到的核心分界點，通常還是 FP32、FP16 和 BF16。

為什麼理解這些類型很重要

很多人第一次看到這些縮寫，會把它們理解成「模型下載頁上的一些實作細節」。但實際上，它們會直接改變你對模型訓練與部署的理解方式。

例如同樣一張顯示卡：

為什麼有些模型訓練必須強調數值穩定性
為什麼有些推理方案會優先談量化與低精度
為什麼看起來參數量相近的模型，部署門檻卻差很多
為什麼有些格式適合存權重，有些格式更適合做計算路徑

這些問題往下拆，最後幾乎都會回到同一個核心：你到底怎麼在「精度、範圍、顯存和速度」之間做取捨。

也正因如此，理解 FP32、FP16、BF16、TF32 和 FP8，不只是為了看懂術語表，而是為了在面對訓練配置、推理引擎與部署門檻時，知道這些數字背後到底在交換什麼。

一個實用的理解框架

如果你不想一開始就記一堆格式細節，可以先用下面這個順序理解：

FP32：最穩、最貴
FP16：更省顯存，但範圍偏小
BF16：顯存接近 FP16，穩定性更適合大模型
TF32：主要解決 FP32 太慢，不主要解決顯存
FP8：更激進的壓縮與加速路線

當你以後再看到模型下載頁裡寫著 fp16、bf16、fp8，或者看到不同部署教學給出完全不一樣的顯存門檻時，就不會再覺得那只是「寫法不同」。它們背後其實對應的是完全不同的精度預算與工程取捨。

結語

大模型裡的張量類型，表面上是在討論 bit 數，實際上討論的是一整套工程取捨。

FP32、FP16、BF16、TF32 和 FP8 沒有絕對的好壞，它們只是分別站在不同的位置上，幫你在穩定性、範圍、精度、顯存和速度之間做平衡。

如果把這一層看懂，後面無論你是在讀訓練論文、調推理參數，還是比較不同部署方案，都會更容易抓住重點。

LLM on KnightLi的博客

筆記型電腦 RTX 4060 8GB 適合跑哪些本地 AI 模型

顯存預算

LLM：3B-8B 量化模型

全能輕量：Gemma 4 E4B

推理與長文本：DeepSeek R1 Distill 7B/8B、Qwen 3 8B

程式碼：Qwen 2.5 Coder 3B/7B

圖像生成

SD 1.5 和 SDXL

FLUX.1 schnell

多模態與效率工具

推薦組合

避坑

建議定位

參考資料

適合 RTX 3060 顯卡運行的本地 LLM 模型推薦

先看顯存邊界

推薦一：Qwen3 8B

推薦二：Llama 3.1 8B Instruct

推薦三：Gemma 3 12B

推薦四：DeepSeek R1 Distill Qwen 8B

推薦五：Phi / MiniCPM / 小尺寸模型

量化怎麼選

用什麼工具運行

上下文不要開太大

不同用途怎麼選

3060 本地 LLM 的合理預期

小結

參考連結

TradingAgents-CN：面向中文使用者的多智能體金融交易研究框架

它解決什麼問題

多智能體分析是什麼意思

為什麼需要中文版本

可以用來做什麼

不適合做什麼

和普通量化框架有什麼區別

和直接問 ChatGPT 有什麼區別

使用時要關注哪些風險

適合怎樣的人研究

可以怎麼擴展

參考

最後一句

Prompt Optimizer：開源提示詞優化、測試與 MCP 工具

它解決什麼問題

主要功能

1. 優化系統提示詞和使用者提示詞

2. 測試和對比輸出

3. 支援多模型

4. 高級測試模式

5. 圖像生成提示詞

使用方式

MCP 能做什麼

和普通聊天工具有什麼區別

適合誰使用

使用時要注意什麼

參考

最後一句

Google LangExtract：用 LLM 從長文本裡抽取結構化資料

它解決什麼問題

LangExtract 的幾個特點

1. 用範例約束抽取格式

2. 抽取結果能對應回原文

3. 支援長文件

4. 支援視覺化檢查

什麼時候適合用

基本安裝

基本使用思路

用它時要注意什麼

和正則、傳統 NLP 有什麼區別

適合怎樣的開發者

參考

最後一句

大模型 API 為什麼按 Token 收費：一文講清輸入、輸出和上下文成本

1. 什麼是 token

2. 為什麼輸入和輸出要分開定價

3. 為什麼上下文越長，費用越容易失控

4. 工具調用為什麼特別容易漲 token

5. 為什麼同樣是模型，價格會差很多

6. 為什麼快取輸入會更便宜

7. 「便宜 token」為什麼不等於「總成本更低」

2. `1M context` 是這次最突出的賣點

3. `V4-Pro` 主要在強調什麼

4. `V4-Flash` 並不是簡單的縮水版