LLM on KnightLi的博客

笔记本 RTX 4060 8GB 适合跑哪些本地 AI 模型

Fri, 08 May 2026 13:38:47 +0800

笔记本 RTX 4060 8GB 可以玩本地 AI，但它的边界很清楚：核心不是“能不能启动”，而是“显存是否溢出”。移动版 RTX 4060 还会受到整机功耗、散热、显存带宽和厂商调校影响，同样是 8GB 显存，不同笔记本的持续性能可能差不少。

在 2026 年的软件环境下，8GB 显存仍然是本地 AI 的入门基准线。只要选择合适的量化模型和工具链，它可以流畅运行 3B-8B 级 LLM、SDXL、SD 1.5、部分 FLUX 量化工作流、Whisper 转写和图像特征提取。反过来，如果强行跑 14B 以上 LLM、未量化大模型或高显存图像工作流，就很容易掉进系统内存，速度会明显崩掉。

一句话建议：笔记本 4060 8GB 不要追求“大而全”，优先选择小模型、量化版和低显存工作流。

先看显存预算

Windows 11 桌面、浏览器、驱动、后台程序会先吃掉一部分显存。实际留给本地 AI 的显存通常不是完整 8GB，而更接近 6.5GB-7.2GB。

因此模型选择要留余量：

LLM：优先 3B-8B，使用 4-bit 量化。
图像生成：优先 SDXL、SD 1.5、FLUX GGUF/NF4 低显存工作流。
多模态：优先 4B 左右的轻量模型。
语音转写：Whisper large-v3 可以跑，但注意批量任务发热。
图像索引：CLIP、ViT 这类特征提取非常适合 4060。

如果显存溢出到系统内存，推理速度可能从“可用”变成“等得烦”。所以宁可选小一点的模型，也不要让显存长期贴边。

LLM：优先 3B-8B 量化模型

本地聊天和文本推理建议使用 Ollama、LM Studio、koboldcpp、llama.cpp 或其他支持 GGUF 的前端。8GB 显存下，最舒服的区间是 4-bit 量化的 3B-8B 模型。

全能轻量：Gemma 4 E4B

Gemma 4 E4B 是 Google 2026 年推出的 Gemma 4 系列小模型之一，定位适合本地和端侧使用。它的优势是模型规模较小，适合 8GB 显存设备承担日常问答、总结、轻量多模态和低成本推理。

在笔记本 RTX 4060 上，建议优先找官方或社区提供的量化版本。不要一开始就追求最高精度权重，先用 4-bit 或适合本地推理的格式确认速度、显存占用和回答质量。

适合任务：

日常问答。
摘要和改写。
轻量资料整理。
简单代码解释。
图像理解类轻任务。

推理与长文本：DeepSeek R1 Distill 7B/8B、Qwen 3 8B

如果你更看重逻辑、数学、复杂分析和长文本处理，可以考虑 DeepSeek R1 distill 系列的 7B/8B 模型，或 Qwen 3 8B 的量化版本。

8B 级模型使用 Q4_K_M 这类 4-bit 量化时，通常能压到 8GB 显存可承受范围内。实际速度会受上下文长度、后端、驱动、笔记本功耗模式影响。经验上，短上下文聊天比较流畅；上下文拉长后，速度和显存压力都会明显上升。

适合任务：

逻辑推理。
数学题。
中文长文本分析。
代码审查草稿。
结构化信息抽取。

不建议一开始就跑 14B、32B 或更大的模型。它们即使能通过 CPU offload 启动，体验也往往不如更小的全 GPU 模型。

代码辅助：Qwen 2.5 Coder 3B/7B

代码场景推荐 Qwen 2.5 Coder 3B 或 7B。3B 版本速度快，适合本地实时补全、函数解释和小范围代码生成；7B 版本理解能力更好，但显存和响应时间更高。

如果你想接到 IDE 插件或本地 agent，3B 版本通常更舒服。对于一次性代码生成、单文件重构、脚本编写，可以再切到 7B 量化版本。

建议：

实时补全：3B。
问答和解释：3B 或 7B。
小型重构：7B 量化。
大型项目架构分析：不要期待 8GB 显存单机完成全部上下文。

图像生成：SDXL 稳，FLUX 要量化

RTX 4060 8GB 跑图像生成完全可用，但要分模型。

SD 1.5 和 SDXL

SD 1.5 对 8GB 显存非常友好，出图速度快，插件生态成熟。SDXL 对显存要求更高，但在 4060 8GB 上仍然属于可用范围。

推荐工具：

ComfyUI
Stable Diffusion WebUI Forge
Fooocus

SD 1.5 适合快速出图、LoRA、ControlNet、老模型生态。SDXL 更适合通用品质和更自然的图像结果。对新手来说，SDXL + Forge 或 ComfyUI 是比较稳的起点。

FLUX.1 schnell

FLUX 的画质和提示词理解更强，但原始模型显存压力大。8GB 显存设备建议使用 GGUF、NF4、FP8 等低显存方案，并搭配 ComfyUI-GGUF 或相应的低显存工作流。

可行策略：

使用 FLUX.1 schnell 的 GGUF Q4/Q5 版本。
降低分辨率或批量大小。
在 ComfyUI 中使用低显存节点或 --lowvram。
不要同时挂太多 LoRA、ControlNet 和高清修复。
每次改工作流后观察显存是否释放。

1024px 出图可以尝试，但不要用桌面 16GB/24GB 显卡的工作流照搬。4060 8GB 能跑 FLUX，不代表每个 FLUX 工作流都适合它。

多模态和效率工具

除了聊天和生图，4060 8GB 也很适合做一些“工具型 AI”任务。

Whisper large-v3

Whisper large-v3 可以用于语音转文字。RTX 4060 处理普通音频通常很快，适合会议录音、课程音频、视频字幕和素材整理。

如果是长音频批量转写，建议注意两点：

开启笔记本性能模式。
保持散热，不要长时间闷在低转速模式。

CLIP / ViT 图像索引

如果你要做照片检索系统，RTX 4060 8GB 很合适。CLIP、ViT、SigLIP 这类图像特征模型对显存要求不算夸张，扫描几千张照片的向量通常很快。

典型流程：

用 CLIP/ViT/SigLIP 提取图片 embedding。
保存到本地向量库或 SQLite。
用文本或图片做相似度检索。
再用小型 LLM 生成标签、描述或相册摘要。

这种工作负载比跑大 LLM 更适合 8GB 显卡，因为它更偏批处理和特征提取，显存压力可控，收益也很明显。

避坑指南

场景	建议
大模型	不要强行跑 14B 以上模型，除非接受明显降速
量化	LLM 优先选 `Q4_K_M`，再按效果尝试 Q5
显存	用任务管理器或 `nvidia-smi` 观察显存占用
散热	跑生图、转写、批处理时开启性能模式
分辨率	图像生成先从 768px 或 1024px 单张开始
浏览器	跑模型时少开占显存的浏览器标签
驱动	保持 NVIDIA 驱动较新，避免旧驱动导致后端异常
工作流	不要直接照搬 16GB/24GB 显卡的 ComfyUI 工作流

如果显存占用长期超过 7.5GB，就要主动降模型、降量化精度、减少上下文、关掉其他程序，或者启用低显存模式。最差的情况不是“跑不起来”，而是跑起来后每一步都在 CPU 和内存之间来回搬数据。

我的建议

笔记本 RTX 4060 8GB 的最佳定位是“高性价比本地 AI 入门平台”。

它适合：

3B-8B 本地 LLM。
代码辅助小模型。
SDXL 和 SD 1.5。
FLUX 量化体验。
Whisper 转写。
图像向量索引。
照片管理和本地资料整理。

它不适合：

长期跑 14B/32B 大模型。
未量化大模型。
高分辨率批量 FLUX 工作流。
大规模视频生成。
多模型同时常驻。

如果你的目标是继续做照片检索系统，4060 8GB 很合适。推荐把 GPU 用在 CLIP/SigLIP 特征提取和小模型标签生成上，再用 SQLite、FAISS 或 LanceDB 做索引。LLM 选择 Gemma 4 E4B、Phi-4 Mini、Qwen 2.5 Coder 3B/7B 这类小模型，整体效率会比硬上大模型更好。

参考资料

适合 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 消耗通常比普通聊天高得多。

问题不只是“模型回答了一段话”，而是整个流程里会不断出现这些内容：

读文件
看日志
调接口
返回 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

看显卡推理速度测试时，最容易把人看晕的不是分数本身，而是这些缩写：

1
2
3

CUDA Scoreboard for Llama 2 7B, Q4_0 (no FA)
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 显卡上的推理速度测试，而且没有开启 Flash Attention。

FA 是什么：Flash Attention

FA 就是 Flash Attention，它是注意力计算的加速技术。核心作用可以直接记成三点：

更快
更省显存
在数学上和普通注意力等价，不是“牺牲精度换速度”

no FA 是什么意思

no FA 就是没开 Flash Attention。它通常出现在跑分表里，主要是为了：

做对照组，方便看出开启 FA 后到底提升了多少
兼容某些不支持 FA 的硬件或软件环境
避免不同测试项混在一起，导致数据不可比

Q4_0 是什么：量化格式

Q4_0 是一种 4-bit 量化格式，可以先这样记：

Q：Quantization，量化
4：4-bit
_0：某一种具体量化方案的标识

它的作用是：

减少模型体积
降低显存需求
让本来装不下的模型变得能跑起来

pp512 t/s 是什么意思

pp512 一般是 Prompt Processing 512 tokens，测的是输入处理速度。

pp：prompt processing
512：测试输入长度是 512 token
t/s：每秒多少 token

它测的不是模型吐字速度，而是模型“先把输入读完”的速度。这个阶段并行度高，所以数值通常会很大，比如：

`1`	`pp512 ≈ 14000 t/s`

tg128 t/s 是什么意思

tg128 一般是 Text Generation 128 tokens，测的是输出生成速度。

tg：text generation
128：测试连续生成 128 token
t/s：每秒多少 token

它更接近我们平时感受到的“模型回答快不快”。因为生成是逐 token 递推的，所以它通常会明显低于 pp512，例如：

pp512 是上万 t/s
tg128 却只有几百 t/s

为什么 pp512 和 tg128 会差这么多

核心原因就一句话：

pp512 测的是并行吞吐，tg128 测的是逐 token 生成。`

具体来说：

输入阶段更容易并行
输出阶段更依赖逐步递推
生成阶段通常更吃显存带宽和缓存效率
所以生成速度远低于输入处理速度是正常现象

t/s 到底怎么理解

t/s 就是 tokens per second。它表示模型每秒能处理或生成多少 token。

但 token 不是“字”也不是“单词”，所以 t/s 更适合做这些对比：

同模型下不同显卡对比
同环境下不同参数设置对比
同一框架里开启或关闭某个优化项前后的对比

一页记住

Q4_0：模型被压缩成了 4-bit 量化版本
FA：是不是启用了 Flash Attention 加速
pp512：处理 512 token 输入时有多快
tg128：生成 128 token 输出时有多快
t/s：速度单位，每秒多少 token

结语

看这类显卡推理速度测试时，最重要的不是只看分高不高，而是先分清：

模型和量化格式
有没有开 FA
测的是输入处理还是文本生成
单位是不是 t/s

把这几件事分清楚，绝大多数 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

图像生成：SDXL 稳，FLUX 要量化

SD 1.5 和 SDXL

FLUX.1 schnell

多模态和效率工具

Whisper large-v3

CLIP / ViT 图像索引

推荐组合

避坑指南

我的建议

参考资料

适合 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. 为什么同样是模型，价格会差很多

2. `1M context` 是这次最突出的卖点

3. `V4-Pro` 主要在强调什么

4. `V4-Flash` 并不是简单的缩水版