LLM

先说一个很多团队没算过的账。 假设你的 Agent 有一段 4000 token 的 system prompt:角色设定、工具说明、几个 few-shot 例子,雷打不动。用户每轮真正输入的,可能就 30 个字。一天 10 万次请求,这 4000 token × 10 万,就是 4 亿个 token 反复进入模型做同一件事——把固定前缀重新算一遍。 这部分计算,90% 是白烧的。因为前缀一模一样,模型每次算出来的中间结果(KV cache)也一模一样。Prompt caching 就是把这份中间结果存下来,下次直接复用。 它不改你的代码逻辑,不动模型质量,却能把输入侧成本砍掉一大半,顺带把首 token 延迟压下去。 2026 年,它依然是被严重低估的省钱手段。不是因为难,恰恰是因为太简单——简单到大家以为"开了就行",结果断点放错位置,缓存全程没命中,白付一笔写入费还不自知。 它到底缓存了什么 要用对,先得知道模型推理分两个阶段。 Prefill(预填充):把你的整段 prompt 一次性喂进模型,逐 token 算出每一层的 KV(key/value)向量。这一步是并行的、算力密集的,prompt 越长越慢。 Decode(解码):基于 prefill 的结果,一个一个吐出回答 token。 Prompt caching 缓存的,就是 prefill 阶段算出来的那份 KV。注意:它缓存的是前缀,不是"整个 prompt"。模型从第一个 token 开始,一段一段比对——只要某个位置往前的内容和缓存里的完全一致,这段就能复用;一旦遇到第一个不一样的 token,从那里往后全部得重算。 flowchart LR A["请求 prompt"] --> B{"逐 token 比对前缀"} B -->|"前缀命中"| C["复用 KV(便宜 + 快)"] B -->|"遇到第一个差异"| D["从这里往后重新 prefill"] C --> D D --> E["Decode 出 token"] 这张图就是 prompt caching 的全部精髓。所有的"怎么用对",归结成一句话:让不变的东西待在前面,让变化的东西待在后面。 ...

去年这个时候,如果你跟人说"我们生产环境跑开源模型",对方多半会礼貌地点点头,心里默认你是预算不够。开源模型当时的人设就是"省钱的次选"。 2026 年 4 月 24 日,DeepSeek 把 V4-Pro 的权重直接挂上了 Hugging Face,1.6 万亿参数,MIT 许可证,1M 上下文。它在编程基准上的得分,跟当月最强的几个闭源旗舰之间,差的不是一个段位,是几个百分点。 这件事的信号比"又一个新模型"大得多。它意味着:当你今天选开源,你放弃的不再是能力,而是别的东西。 这篇就来复盘开放权重这一年的格局——谁在领跑、中国开源为什么这么猛、剩下的那点差距到底在哪、许可证这个没人爱看的细节怎么反而成了关键,以及开源那套微调量化部署的生态,现在到底成不成熟。 需要先说清一个词。这篇说的"开源",严格讲是开放权重(open weights):权重能下载、能自己跑、能商用。它和教科书意义上的开源软件不是一回事——绝大多数模型不公开训练数据、不公开训练代码,你拿到的是一个能跑的成品,不是一份能复现的菜谱。后面我还是用"开源"这个习惯叫法,但你心里得清楚,这是个有水分的词。 领跑的三家,其实是三种活法 把 2026 年 5 月的开放权重阵营摊开看,DeepSeek、Qwen、Llama 这三个名字最响,但他们根本不在同一条赛道上。 模型家族 代表版本(2026.05) 架构 / 规模 许可证 它在赌什么 DeepSeek V4-Pro / V4-Flash MoE,1.6T 总参 / 49B 激活;Flash 284B/13B MIT 用前沿能力 + 极宽松许可证,直接当闭源旗舰的平替 Qwen Qwen 3.6 系列,六档尺寸 + 3.6-VL Dense 与 MoE 混编,从手机到集群 Apache 2.0(开放档) 用"全尺寸覆盖 + 最强多语言"做开发者默认底座 Llama Llama 4 Scout / Maverick MoE,17B 激活(16 / 128 experts) Llama 4 社区许可(有条件) 守住最大的部署装机量和生态惯性 Mistral Large 3、Small 4 Large 3:675B/41B;Small 4:119B/6B Apache 2.0 欧洲牌照 + 干净许可证,做合规友好的那一个 这张表里我最想让你看的是最后一列。三家头部各自押的东西完全不同:DeepSeek 押"能力对标 + 许可证无摩擦",Qwen 押"尺寸谱系最全",Llama 押"我已经在几十亿设备和无数教程里了"。 ...

把一份 80 万字的项目文档整个粘进对话框,模型没报错,也回答了你的问题。你松了口气:看,1M 上下文真香。 但你有没有验证过——它引用的那段需求,是真的从文档第 40 万字的位置取出来的,还是它顺着上下文的语气编了一段听起来很对的话? 这是 2026 年长上下文最尴尬的地方:“放得进"是确定的,“用得好"是不确定的,而大多数人只测了前者。 模型厂商标 1M、2M,你看到的是窗口大小;你真正需要的是这个窗口里有多少 token 是"模型会认真看"的。这两个数字,差得比你想的大。 标称上下文 vs 有效上下文 先把两个概念分清楚。 标称上下文(advertised context)是模型 API 允许你塞进去的最大 token 数,超了就报错。有效上下文(effective context)是模型在性能开始明显掉档之前,真正能可靠利用的 token 数。 RULER 这个 benchmark 当年就是为了量化这件事造出来的。它的结论很扎心:很多号称 32K+ 的模型,在 32K 长度下能维持及格表现的,只有一半。到了 2026 年,百万级窗口普及之后,这个差距并没有消失——多份独立测试给出的经验值是,有效上下文通常只有标称值的 60%~70%,而且性能下滑的方式,简单的 token 计数根本看不出来:漏检的内容、编造的细节、断掉的推理链。 把 2026 年几个主流模型的标称窗口和实测召回放在一起看: 模型 标称窗口 1M 长度实测召回 备注 Claude Opus 4.6 1M ~76% 256K 下约 93%,长度档位领先 Gemini 3.1 Pro 1M ~70% 次于 Opus Gemini 1.5 Pro 2M ~55%~65% 窗口最大,召回反而靠后 Llama 4 Scout 10M 1M 后明显衰减 标称最大,有效区间远小于标称 注意 Gemini 1.5 Pro 这一行:它标 2M,是表里窗口最大的,但 1M 长度下的召回反而排在后面。窗口大小和有效质量,不是同一个排行榜。 标称 10M 的 Llama 4 Scout 也一样,过了 1M 之后衰减得很明显,适合做的是"检索式"任务,不是"全局理解"任务。 ...

2025 年初,DeepSeek 放出一组叫 R1-Distill 的模型,其中那个 7B 版本在 AIME 2024 数学竞赛题上拿到了 55.5% 的 pass@1。 这个数字有意思的地方在于:它比 QwQ-32B-Preview 还高。一个 7B 的小模型,在硬核推理题上,打过了一个参数量是它四倍多的模型。 更反常识的是后面这句——DeepSeek 自己说的:直接拿强化学习去训练那个 7B 小模型,效果还不如蒸馏。小模型自己练,练不出这种推理能力;但你拿一个 671B 的大模型当老师,把它的思考过程喂给小模型学,小模型就学会了。 这就是蒸馏。它不是模型压缩里的某种玄学技巧,而是 2026 年几乎每家做小模型的团队都在用的标准动作。这篇把它讲清楚:蒸馏到底搬走了什么,和微调是什么关系,能搬多少,做不到什么,以及一套能落地的流程。 为什么要蒸馏:质量和成本之间那道墙 先说动机。 大模型好用,但贵。一个 400B 参数的旗舰模型,推理延迟高、单次调用成本高、显存吃得狠,你不可能把它塞进每一台手机、每一个边缘设备、每一条高并发的客服管道。可小模型呢?便宜、快、能本地跑,但你直接拿一个 7B 模型出来用,它在复杂任务上的回答质量,和旗舰模型差着一大截。 这就是那道墙:质量在大模型这边,成本和延迟在小模型那边,你想两个都要。 传统的过墙办法有两种。一种是直接训练一个小模型——但小模型受参数量限制,见的数据再多,某些能力(尤其是多步推理)就是练不出来,这是容量天花板。另一种是把大模型剪枝、量化——这能省一点,但省不了数量级,而且剪过头质量就崩。 蒸馏是第三条路,也是目前性价比最高的一条:不让小模型自己悟,而是让大模型手把手教它。Meta 拿 Llama 4 Behemoth 去训 Llama 4 的 Scout 和 Maverick,Google 用 Gemini 去带 Gemma 2 和 Gemma 3,DeepSeek 用 R1 蒸出 1.5B 到 70B 一整个系列——2026 年你能叫得出名字的小模型,背后基本都站着一个大模型老师。 道理很朴素:让一个聪明人把题做一遍、把思路讲给你听,比你自己对着标准答案死磕,学得快得多。 蒸馏到底在传递什么 很多人对蒸馏的第一印象是"用大模型造点数据,拿去训小模型"。这个理解对了一半,但漏掉了最关键的东西。 蒸馏的精髓在于软标签(soft label)。 举个例子。你问模型"这句话情感是正面还是负面",一个普通的训练样本只会告诉小模型一个硬标签:正面。但大模型老师给出的不是一个字,而是一整个概率分布——比如"正面 0.82、负面 0.11、中性 0.07"。 ...

先说一个数字:同样问"帮我查一下这个 bug",发给聊天机器人和发给 Agent,token 消耗能差 50 倍。 聊天机器人就一来一回:你发一段、它回一段,结束。Agent 不一样——它跑的是一个循环:看任务、调工具、读文件、改代码、再检查。循环里的每一步,都要把到目前为止积累的全部上下文,重新发给模型一次。 这就是 Agent 账单的根源。2026 年有人审计了 30 个在生产环境跑 Agent 的工程团队,一个 20 人的团队,单月 API 账单能冲到 11 万美元;用 Claude Code 或 Cursor 这类编码 Agent 的开发者,人均每月 400 到 1500 美元,失控的案例几天就烧掉 4000 美元以上。 更要命的是,这笔钱不是匀速烧的。Demo 跑得好好的,一上量就爆——大部分企业的 Agent 项目,在大规模铺开后的头 90 天里,实际花销会超出试点预算 4 到 11 倍。所以做 Agent,成本不是上线之后再优化的事,是设计时就得算进去的一笔账。 这篇把这笔账拆开:钱花在哪、怎么找到大头、有哪些真能省的手段、怎么设预算和熔断、怎么监控。 钱到底花在哪 先建立一个最反直觉的认知:Agent 跑一个任务的成本,主要不是输出,是输入。 模型 API 按 token 收费,输入和输出分开计价。聊天场景里,大家盯着输出看。但 Agent 不一样,它的成本大头在输入侧的重复计费。 为什么?因为对话历史会"滚雪球"。Agent 每调一次工具,就要把整段对话历史连同工具返回的结果,一起再发一次。一段已经积累到 10 万 token 的上下文,在后续每一次调用里,都按 10 万输入 token 收费——不是只收新增的那部分。一个跑到第 20 步的编码 Agent,光是文件读取塞进来的内容,单步输入就能超过 5 万 token,按 Sonnet 4.6 的价(每百万输入 token 3 美元)算,每一步 0.15 美元,二十步就是 3 美元,而这还只是一个任务。 ...

先说一个数字:Guardrails AI 在 2025 年初做过一次基准测试,结论里有句话很刺眼——单个护栏哪怕准确率有 90%,串五个,误杀率就到 40%。 这句话基本能概括做护栏的全部难处。你不是在"加保护",你是在一条已经够慢、够贵、够不确定的链路上,再叠一层会拖慢、会误判、还得自己维护的东西。问题不是"要不要护栏"——上线的 LLM 应用一定要有——问题是护栏管什么、做多厚、放哪一层。这三件事做错,护栏要么形同虚设,要么把好用户也一起赶跑了。 这篇不讲注入攻击的具体手法(那是另一篇的事),讲更宽的一件事:把用户的输入、模型的输出当成两道关口,这两道关口该怎么修。 护栏到底在拦什么 很多团队上来就装个 moderation API,以为护栏就是"过滤脏话"。不是。护栏分两侧,两侧拦的东西完全不一样。 输入侧,拦的是用户递进来的东西: 敏感信息。用户在对话里贴了身份证号、银行卡、内部工号、客户手机号。你不想把这些原样喂给第三方模型 API,更不想它们出现在日志里。 越界请求。一个做企业财报问答的 Bot,用户问"帮我写一首失恋的诗"。这不危险,但它不是这个产品该干的事——回答了,就是在替竞品做免费体验。 明显的恶意输入。攻击意图、自动化刷量、超长 prompt 灌爆上下文。 输出侧,拦的是模型吐出来的东西,这一侧更难,因为输出是模型生成的、不可预测的: 有害内容。暴力、仇恨、自残、违法信息。这是最经典的一类,也是 moderation API 唯一管得好的一类。 幻觉。模型一本正经地编了一个不存在的退款政策、一个错误的药品剂量。在 RAG 场景里,这意味着输出和检索到的资料对不上。 格式错误。你要的是一段能直接 JSON.parse 的结构化数据,模型给你前面加了句"好的,这是您要的结果:"。下游程序当场崩。 品牌口径。模型说了"我们的竞品确实更便宜",或者用了一个法务明令禁止的承诺词(“保证收益"“绝对安全”)。没毒,但能上财经新闻。 注意最后两类——格式和品牌口径——很多人根本不把它当护栏。但它们恰恰是上线后最高频出事的地方。有害内容一年可能出一次,格式错误一天能出一百次。 四种做法,从便宜到贵 护栏不是一种技术,是一个工具箱。按"成本/能力"从低到高,有四档。 第一档:规则与正则。 关键词黑名单、正则匹配身份证/手机号、长度限制、JSON schema 校验。便宜到几乎不要钱,延迟个位数毫秒,而且结果可解释——你能准确说出"它是因为命中了第几条规则被拦的”。缺点也明显:绕得过,且管不了语义。规则适合拦"形状固定"的东西:PII、超长输入、明确的禁用词。 第二档:专门的分类模型。 这是 2026 年的主力。Meta 的 Llama Guard 是一个专门微调出来的输入输出安全模型,自带六大类不安全分类,还能自定义类目;OpenAI 的 omni-moderation-latest 免费、能同时分类文本和图像。它们的关键优势是快——一个专用 guard 模型跑一次大约 29 毫秒,而拿一个大模型当审查员要 5 到 11 秒。但要清楚它们的边界:OpenAI moderation 只做内容分类,不查注入、不查幻觉、不做 PII 脱敏。它是基线,不是全部。 第三档:用 LLM 审查 LLM。 让另一个模型(或同一个模型换个 prompt)去判断"这条输出有没有问题"。最灵活,能处理"品牌口径"“答非所问"这种规则和分类器都搞不定的模糊判断。代价是它慢且贵——等于每个请求多一次完整的 LLM 调用,延迟翻倍,成本也翻倍。LLM 审查适合留给"少量、高风险、规则写不出来"的判断。 ...

Voice Agent 是什么 一句话：能听会说的AI助手。 graph LR A[用户说话] --> B[ASR语音识别] B --> C[LLM理解+生成] C --> D[TTS语音合成] D --> E[播放给用户] 看起来简单，但要做好有三个核心挑战： 延迟 - 用户说完到AI回复，要控制在1-2秒内 打断 - 用户随时可以打断AI说话 自然度 - 不能像机器人一样僵硬 核心架构 方案一：串行流水线 1 用户说话 → [等说完] → ASR → LLM → TTS → 播放 优点：实现简单 缺点：延迟高（3-5秒） 适合：对延迟不敏感的场景（如语音留言） 方案二：流式处理 1 用户说话 → [边说边识别] → [边生成边合成] → [边合成边播放] 优点：延迟低（1-2秒） 缺点：实现复杂，需要处理中间状态 适合：实时对话场景 关键组件 1. ASR（语音识别） 方案 延迟 准确率 成本 Whisper API 1-2s 95%+ 按时长计费 Deepgram 200ms 90%+ 按时长计费 本地Whisper 500ms-2s 95%+ 需要GPU 实时识别关键： ...

RAG是什么 一句话：先查资料，再回答问题。 大模型直接回答问题容易编造内容。RAG让它先从你的知识库里找到相关内容，再基于这些内容回答。 1 用户问题 → 搜索知识库 → 找到相关文档 → 喂给LLM → 生成答案 最简实现 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 from langchain.vectorstores import Chroma from langchain.embeddings import OpenAIEmbeddings from langchain.chat_models import ChatOpenAI # 1. 把文档切块并存入向量数据库 docs = load_and_split_documents("./docs") vectorstore = Chroma.from_documents(docs, OpenAIEmbeddings()) # 2. 检索相关内容 retriever = vectorstore.as_retriever(k=3) relevant_docs = retriever.get_relevant_documents("什么是RAG？") # 3. 生成答案 llm = ChatOpenAI() answer = llm.invoke(f""" 根据以下内容回答问题： {relevant_docs} 问题：什么是RAG？ """) 就这么简单。30行代码就能跑起来。 ...

开场：同样的问题，天差地别的回答 先看一个真实场景： ❌ 普通人的提问： “帮我写一篇文章” AI回答：好的，请问您想写什么主题的文章？（然后开始无尽的追问…） ✅ 高手的提问： “你是一位资深科技博主。请用轻松幽默的语气，写一篇800字左右的文章，介绍AI编程助手（如Cursor、Copilot）如何改变程序员的工作方式。文章需要包含：1个生动的开场故事、3个具体的使用场景、1个数据对比、结尾的行动号召。” AI回答：直接输出一篇结构完整、语气生动、可直接发布的高质量文章。 这就是提示词工程的魔力。 第一章：CRISP框架 —— 黄金提示词公式 我总结了一个简单易记的框架：CRISP 字母 含义 说明 C Context（背景） 告诉AI"你是谁"和"场景是什么" R Role（角色） 让AI扮演专家身份 I Instructions（指令） 清晰的任务描述 S Specification（规格） 输出的格式、长度、风格 P Proof（示例） 给出1-2个例子（Few-Shot） 实战模板 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # 背景 (Context) 我正在为技术博客写一篇关于[主题]的文章，读者是有一定编程基础的开发者。 # 角色 (Role) 你是一位拥有10年经验的资深技术作家，擅长用通俗易懂的语言解释复杂概念。 # 指令 (Instructions) 请帮我撰写这篇文章，要求： 1. 开头用一个真实案例或故事引入 2. 核心内容分为3-4个要点 3. 每个要点配有代码示例 4. 结尾总结并给出行动建议 # 规格 (Specification) - 字数：1500-2000字 - 语气：专业但不枯燥，适当加入幽默 - 格式：Markdown，使用代码块、列表、表格 # 示例 (Proof) 类似风格的文章参考：[给出一段示例文字] 第二章：Chain of Thought —— 让AI学会思考 核心原理：不要让AI直接给答案，让它先"想一想"。 ...

Agent的核心循环 一个Agent本质上在做这件事： 1 感知 → 思考 → 行动 → 反馈 → 继续思考... 用代码表示： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 while not done: # 1. 理解用户要什么 intent = understand(user_input) # 2. 想想怎么做 plan = think(intent, memory) # 3. 动手执行 result = act(plan, tools) # 4. 看看结果对不对 if verify(result): done = True else: memory.add(result) # 记住失败，下次改进 三个关键模块 1. 记忆系统 Agent和普通LLM调用的区别：Agent会记东西。 1 2 3 4 5 6 7 8 9 class Memory: short_term = [] # 当前对话历史 long_term = {} # 跨对话的知识 def remember(self, key, value): self.long_term[key] = value def recall(self, query): return search(self.long_term, query) 实际应用： ...

引言 2025年，LangGraph正式发布1.0版本，成为构建生产级AI Agent的首选框架。作为LangChain生态系统的核心组件，LangGraph提供了图状态编排（Graph-based Orchestration）能力，支持Agent的循环、分支、回溯和动态决策。更重要的是，它内置了持久化执行（Durable Execution）、**检查点（Checkpointing）和人工干预（Human-in-the-Loop）**等企业级功能。本文将深入探讨LangGraph的概念、工作原理、应用场景以及实践技巧。 知识图谱与LangChain Graph基础 什么是知识图谱？ 知识图谱(Knowledge Graph)是一种结构化数据模型，用于表示实体(Entities)之间的关系(Relations)。它以图的形式组织信息，其中： 节点(Nodes)：代表实体或概念 边(Edges)：代表实体间的关系 graph LR A["艾伦·图灵"] -->|"发明"| B["图灵机"] A -->|"出生于"| C["英国"] A -->|"被誉为"| D["计算机科学之父"] B -->|"是"| E["理论计算模型"] LangChain Graph的定义与价值 LangChain Graph是LangChain框架中专注于知识图谱构建、存储和查询的模块集合。它将LLM的自然语言处理能力与图数据库的结构化表示结合，实现了： 自动从文本中提取实体和关系 构建和维护知识图谱 基于图结构进行复杂查询和推理 增强LLM应用的上下文理解和回答质量 LangChain Graph架构 LangChain Graph的整体架构可以通过以下图示来理解： flowchart TB subgraph "输入层" A["文本文档"] --> B["网页内容"] C["结构化数据"] --> D["用户查询"] end subgraph "处理层" E["实体提取 EntityExtractor"] F["关系提取 RelationExtractor"] G["知识图谱构建 KnowledgeGraphCreator"] end subgraph "存储层" H["图数据库 Neo4j/NetworkX"] I["向量存储 VectorStores"] end subgraph "应用层" J["图查询 GraphQuery"] K["图推理 GraphReasoning"] L["QA系统 GraphQAChain"] end A --> E B --> E C --> F D --> F E --> G F --> G G --> H G --> I H --> J H --> K I --> L 核心组件详解 1. 实体和关系提取器 这些组件负责从文本中识别实体和它们之间的关系： ...