Posts

MoE：用参数量换计算效率 MoE（Mixture of Experts）的核心思想很简单：不是所有参数都需要参与每次计算。通过路由机制，只激活与当前输入最相关的"专家"子网络，在保持大参数量的同时大幅降低计算量。 基本原理 稠密模型 vs 稀疏模型 传统稠密模型：每个token经过所有参数的计算。 输入token → [Attention] → [MLP(d, d_ff)] → 输出 所有参数参与计算 MoE模型：MLP层被替换为多个专家MLP，路由器选择激活哪些专家。 输入token → [Attention] → [Router] → 选择Top-K专家 ↓ [Expert1] [Expert2] ... [ExpertN] ↓ (仅K个被激活) 加权合并 → 输出 关键参数 专家数(N)：总专家数量。通常8-64个 激活数(K)：每个token激活的专家数。通常2-8个 稀疏率：1 - K/N。如8/64的配置，稀疏率为87.5% 以DeepSeek-V3为例：256个专家，每token激活8个，总参数671B但推理时只激活37B——等效于37B模型的计算量，但拥有671B参数的知识容量。 路由机制 基础路由 最简单的路由方式： def route(token, experts): # 计算token与每个专家的亲和度 scores = softmax(W_router @ token) # [N] # 选择Top-K个专家 top_k_indices = argsort(scores)[-K:] top_k_scores = scores[top_k_indices] # 归一化 top_k_scores /= top_k_scores.sum() # 加权合并 output = sum(experts[i](token) * top_k_scores[i] for i in top_k_indices) return output 负载均衡问题 基础路由有一个严重问题：路由坍缩。模型倾向于总是选择少数几个"好"专家，其他专家得不到训练。 ...

数据是新的代码 传统软件的"代码"在大模型时代变成了"数据"。模型的智能本质上是训练数据的压缩和重组。数据质量决定模型能力上限，算法和算力决定我们能多接近这个上限。 数据全流程 1. 数据采集 预训练数据来源 来源 占比(典型) 质量 说明 网页爬取 60-70% 中低 Common Crawl为主 书籍 5-10% 高 长文本、知识密集 论文 3-5% 高 学术知识 代码 5-10% 高 GitHub/The Stack 对话 5-10% 中 Reddit/社交平台 多语言 10-20% 中 各语言网页 合成数据 2026年趋势：合成数据占比越来越高。用强模型生成高质量训练数据： 知识合成：生成教科书式知识讲解 指令合成：生成多样化指令-回答对 推理合成：生成带思维链的推理过程 合成数据的关键风险是"模型坍缩"（model collapse）——如果训练数据全部来自模型生成，可能退化。需要确保一定比例的真实数据。 2. 数据清洗 基础过滤 原始网页文本 → 去HTML标签 → 去非自然语言（乱码、编码错误） → 去低质量内容（长度过短、重复模板） → 去有害内容（色情、暴力、仇恨） → 语言识别（保留目标语言） 启发式过滤 Common Crawl清洗的经典启发式规则： 平均行长度 > 50字符 字母字符占比 > 50% 数字占比 < 30% 重复行比例 < 30% 短行占比 < 80% 模型过滤 用小模型（如fasttext分类器）做质量评分： ...

工具调用：Agent的双手 没有工具调用能力的LLM只是一个"会说话的大脑"。真正的Agent需要调用API、执行代码、读写文件——这些都需要工具调用机制。 演进历程 阶段一：Prompt工程时代（2022-2023） 最早的工具调用靠Prompt引导： 你可以使用以下工具： 1. search(query): 搜索网页 2. calculator(expr): 数学计算 如果需要使用工具，请输出以下格式： <tool>search("天气")</tool> 这种方式的问题： 格式不稳定，模型经常不遵守 参数提取容易出错 无法处理多步工具调用 阶段二：Function Calling时代（2023-2024） OpenAI在2023年6月推出Function Calling，将工具调用作为原生API能力： response = openai.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": "北京天气"}], tools=[{ "type": "function", "function": { "name": "get_weather", "description": "获取城市天气", "parameters": { "type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"] } } }] ) # response.choices[0].message.tool_calls 模型输出结构化的工具调用请求，API层解析后执行。 阶段三：标准化时代（2024-2026） MCP协议将工具调用标准化，实现"一次开发，处处可用"。 Function Calling的技术细节 工作流程 1. 用户消息 + 工具定义 → LLM 2. LLM输出 → tool_call(name, args) 3. 应用层执行工具 4. 工具结果 → LLM 5. LLM基于结果生成回答 关键参数 tools定义： { "type": "function", "function": { "name": "string", "description": "string", "parameters": { // JSON Schema格式 } } } tool_choice控制： auto：模型自主决定是否调用 none：禁止调用 required：必须调用 {"function": {"name": "xxx"}}：指定调用特定工具 并行调用 现代模型支持在单次响应中输出多个tool_call： ...

向量数据库：RAG时代的基石 所有RAG系统都需要向量数据库。2026年市场已经从"有没有"过渡到"哪个好"——选型不当会带来性能瓶颈、扩展困难、功能不足等问题。 三大主流方案 Milvus：大规模分布式 架构特点 Milvus采用存算分离架构： Coordinator：元数据管理和调度 Worker Node：查询节点和数据节点分离 对象存储：数据持久化（S3/MinIO） 消息队列：变更数据捕获（Kafka/Pulsar） 核心优势 水平扩展：支持十亿级向量 混合检索：向量+标量过滤 多索引：HNSW、IVF、DiskANN、GPU索引 云原生：K8s原生部署 适用场景 大规模生产环境（亿级向量） 需要高可用和水平扩展 团队有K8s运维能力 注意事项 部署复杂度高（微服务架构） 小规模场景（<100万向量）过重 内存占用较大 Qdrant：高性能轻量级 架构特点 Qdrant用Rust编写，单二进制部署： Collection：数据集合 Payload：向量关联的元数据 量化支持：标量量化(SQ8)、乘积量化(PQ)、二进制量化 磁盘索引：支持大于内存的数据集 核心优势 简单部署：单二进制+Docker 高性能：Rust实现，无GC暂停 丰富过滤：Payload过滤能力强大 量化压缩：内存占用极低 适用场景 中小规模（<1亿向量） 快速原型开发 对延迟敏感的场景 运维资源有限的团队 注意事项 分布式能力不如Milvus 不支持多租户隔离 生态插件较少 Weaviate：AI原生设计 架构特点 Weaviate定位为"AI原生数据库"： GraphQL API：内置API层 模块化向量化：内置多种embedding模型 对象存储+向量索引：一体化设计 多模态支持：图像/文本/视频嵌入 核心优势 开箱即用：内置embedding模型 GraphQL接口：前端友好 多模态：原生支持多种数据类型 混合检索：BM25+向量融合 适用场景 快速构建AI应用 需要多模态检索 前端团队主导的项目 不想单独管理embedding流程 注意事项 性能不如Qdrant极致 大规模部署经验较少 Go实现，性能依赖GC调优 性能对比 写入性能 数据库 单线程写入 批量写入(10K) 索引构建速度 Milvus 5K/s 50K/s 中等 Qdrant 8K/s 80K/s 快 Weaviate 3K/s 30K/s 中等 查询性能 数据库 p50延迟 p99延迟 并发QPS Milvus 5ms 20ms 10K+ Qdrant 2ms 8ms 5K+ Weaviate 8ms 30ms 3K+ 注：测试条件为1M向量，768维，HNSW索引，单节点。实际性能受数据规模、硬件、配置影响。 ...

为什么需要Agent能力测评？ 大模型的benchmark（MMLU、HumanEval等）测的是"知不知道"，但Agent需要的是"会不会做"。一个MMLU分数90的模型，在Agent任务中可能表现很差——因为Agent需要规划、决策、工具使用、错误恢复等综合能力。 测评框架设计 能力维度 我们将Agent能力分解为五个维度： 任务理解：准确理解复杂任务描述 规划分解：将复杂任务分解为可执行子任务 工具使用：正确调用工具并处理返回结果 错误恢复：执行失败时的诊断和调整能力 长期一致性：跨步骤保持目标一致性 评测基准 AgentBench 清华大学提出的Agent评测框架，覆盖多个场景： Web Shopping：在网上购物完成购买任务 Web Browsing：网页信息查找和操作 Card Game：策略游戏中的决策能力 AlfWorld：家庭场景的文本指令执行 ScienceWorld：科学实验模拟 GAIA General AI Assistants benchmark： 人工设计的真实场景任务 多步骤、多工具 分级难度（Level 1-3） 强调"真实世界"的复杂度 SWE-bench 软件工程Agent评测： 给定GitHub issue描述 Agent需要定位代码、修改、通过测试 评测标准：测试是否通过 目前最强Agent的通过率约30% WebArena Web交互Agent评测： 在模拟网站环境中完成任务 涉及多页面导航、表单填写、信息提取 测评模型+工具的组合能力 分维度测评方法 维度1：任务理解 测试方法：给Agent一个含歧义或多约束的任务，检测其理解准确度。 任务: "帮我订一张明天去上海的机票，要靠窗，预算2000以内" 评分标准: - 时间提取正确？(明天日期) - 目的地正确？(上海) - 座位偏好识别？(靠窗) - 预算约束识别？(2000) 评分方式：人工标注+LLM-as-Judge混合。 维度2：规划分解 测试方法：给定复杂任务，评估Agent的任务分解质量。 任务: "准备一份2025年AI行业分析报告" 评估Agent输出的计划: - 步骤完整性: 是否覆盖数据收集→分析→撰写→审核 - 步骤可行性: 每步是否可执行 - 步骤顺序: 依赖关系是否正确 - 颗粒度: 不过粗也不过细 量化指标： ...

Prompt工程不是玄学 很多人认为Prompt工程就是"试不同的话术看哪个效果好"。这是误解。好的Prompt工程是系统工程——有方法论、有评估标准、有优化路径。 第一原则：明确目标 写Prompt之前先问自己：我要模型输出什么？质量的衡量标准是什么？ 常见任务类型 信息提取：从文本中提取结构化数据 内容生成：生成文本/代码/分析报告 推理决策：逻辑推理/分类/判断 格式转换：翻译/摘要/格式化 每种类型的Prompt设计策略完全不同。信息提取追求精确，内容生成追求创意，推理决策追求严谨。 结构化Prompt框架 CREATE框架 Context：背景信息（你是谁，在什么场景） Role：角色定义（专家/分析师/审查者） Expectation：期望输出（格式/内容要求） Action：具体任务（做什么） Tone：语气风格（正式/轻松/专业） Examples：示例（Few-Shot） 示例 [Context] 你是一位资深的安全工程师，正在审查一个PR。 [Role] 你以严谨著称，不放过任何安全风险。 [Action] 审查以下代码变更，识别： 1. 潜在的安全漏洞（SQL注入、XSS、CSRF等） 2. 敏感信息泄露 3. 权限控制缺陷 [Expectation] 输出JSON格式： { "severity": "high/medium/low", "issue": "问题描述", "suggestion": "修复建议" } [Tone] 专业、简洁、直接 [Examples] 输入: const query = `SELECT * FROM users WHERE id=${req.query.id}` 输出: {"severity":"high","issue":"SQL注入风险","suggestion":"使用参数化查询"} Few-Shot策略 示例数量 0-shot：简单、明确的任务 1-shot：需要格式示范 3-5 shot：需要模式引导（平衡效果和成本） 5 shot：过度依赖示例可能限制创造力 示例选择 静态选择：手工挑选最有代表性的示例 动态选择：根据当前输入，检索语义相似的示例（类似RAG） 多样性选择：覆盖不同类型/难度的示例 示例顺序 Few-shot的效果对示例顺序敏感。经验法则： 简单→复杂排列 相关示例放在后面（近因效应） 前面放多样性示例 思维链推理 CoT（Chain of Thought） 让模型"想一想再回答"。将推理过程显式化： Q: 一个商店有23个苹果，卖出17个，又进了12个，还有多少？ A: 让我们一步步算： 1. 初始有23个苹果 2. 卖出17个：23 - 17 = 6 3. 又进了12个：6 + 12 = 18 答案：18个 适用场景 CoT对以下场景特别有效： ...

为什么需要边缘AI？ 云计算解决了大规模AI部署问题，但很多场景无法依赖云端： 隐私要求：医疗、金融数据不能上云 延迟要求：自动驾驶、实时翻译需要毫秒级响应 离线场景：野外、飞机模式、网络不稳定 成本控制：大量设备同时运行，云推理成本不可控 边缘AI的目标：在手机、车载芯片、IoT设备上本地运行AI模型。 模型压缩四件套 1. 量化 将模型从FP32压缩到INT8/INT4： 精度 模型大小(7B) 精度损失 推理速度 FP16 14GB 0% 基准 INT8 7GB <1% 1.5-2x INT4 3.5GB 1-3% 2-3x 2-bit 1.75GB 5-10% 3-4x 移动端推荐INT4量化，使用GGUF格式（llama.cpp生态）。常用方案： GPTQ：基于二阶信息的权重量化 AWQ：基于激活分布的权重量化 GGUF Q4_K_M：移动端最常用格式 2. 蒸馏 将大模型知识"蒸馏"到小模型： Teacher模型(70B) → 生成回答/中间表示 → Student模型(1B)学习 任务特定蒸馏：只蒸馏目标任务的能力，而非通用能力。效果通常比直接训练小模型好20-30%。 3. 剪枝 移除不重要的参数： 结构化剪枝：移除整个attention head或MLP中间维度，可实际加速 非结构化剪枝：移除稀疏参数，需特殊硬件支持 移动端推荐结构化剪枝，因为标准硬件就能获得加速。 4. 架构搜索（NAS） 针对特定硬件搜索最优模型结构： 确定目标硬件的延迟/功耗预算 搜索满足约束的最高精度模型 MobileNet、EfficientNet就是NAS的经典成果 移动端推理引擎 llama.cpp C++实现，无依赖 支持GGUF格式 iOS/Android均可运行 支持CPU推理和GPU加速 典型使用: 1. 将模型量化为GGUF格式 2. 编译llama.cpp for Android/iOS 3. 通过JNI或C API调用 4. 管理上下文窗口和内存 MLC-LLM 基于TVM编译器 自动优化模型到目标硬件 支持GPU加速（Metal/Vulkan） 跨平台：iOS/Android/Web ONNX Runtime Mobile 微软出品，支持ONNX格式 Android/iOS支持完整 包体积极小（<10MB运行时） 支持NNAPI/CoreML后端加速 平台原生方案 iOS：CoreML + MLX Android：ML Kit + NNAPI 华为：CANN + NPU 端侧部署实战 iOS部署 // 使用MLX框架运行LLM import MLX import MLXLMCommon let model = try await loadModel(name: "qwen-2-1.5b-4bit") let result = try await model.generate( prompt: "你好", maxTokens: 256 ) 关键配置： ...

AI视频生成的技术跃迁 2024年OpenAI发布Sora，AI视频生成从"能动"走向"能看"。到2026年，视频生成已经发展出完整的技术栈和商业生态。 技术路线全景 路线一：扩散模型+时空注意力（主流） Sora采用的核心架构是DiT（Diffusion Transformer）： 噪声视频块 → 去噪(迭代) → 清晰视频 关键组件: - 时空Transformer：处理空间和时间维度的联合注意力 - 时空Patch：将视频切分为时空块（类似ViT的patch机制） - 扩散过程：从纯噪声逐步去噪到清晰视频 核心创新是"时空Patch"机制： 将视频分解为时空立方体 每个patch作为token输入Transformer 类比：文本token→视频时空token 好处：统一的框架，可处理不同分辨率和时长 路线二：自回归模型 将视频帧序列视为token序列，用next-token prediction方式生成： 每帧量化为离散token 自回归生成帧序列 代表：VideoPoet、Kinetix 优势：天然支持文本条件 劣势：时间一致性不如扩散模型 路线三：掩码建模 类似MAE（Masked Autoencoder），随机遮蔽部分帧后重建： 训练：随机遮蔽视频帧，学习重建 推理：从部分帧"补全"完整视频 优势：速度快（只需1-2次forward而非50步去噪） Sora架构深度分析 时空Patch化 输入视频被切分为时空patch： 空间维度：每16×16像素为一个patch 时间维度：每4帧为一个时间块 每个patch编码为一个向量 这种设计让模型天然支持不同分辨率和长宽比——不需要裁剪到固定尺寸。 扩散Transformer 去噪过程在patch token空间中进行： x_t = 噪声视频tokens t = 扩散时间步 c = 文本条件(text encoding) ε = DiT(x_t, t, c) # 预测噪声 x_{t-1} = 去噪一步(x_t, ε) DiT使用大规模Transformer（数十亿参数），支持长序列的时空建模。 ...

数字人的本质 数字人是多模态AI的集大成者——它需要看起来像人、动起来像人、说起来像人。技术上需要融合3D图形、语音合成、NLP、计算机视觉等多个领域。 技术栈分层 第一层：外观创建 3D建模 传统管线：Maya/Blender手工建模→UV展开→纹理绘制→绑定骨骼 AI生成：单张照片生成3D模型（如PifuHD、DreamGaussian） 数字分身：3D扫描+AI增强，快速生成高保真数字人 2D数字人 2D数字人（如HeyGen、D-ID）不需要3D模型，直接在2D图像上做面部动画： 输入：一张正面照片 + 音频 输出：说话的视频 技术：基于扩散模型的面部动画生成 2D方案成本低、速度快，但角度受限。 第二层：语音合成 数字人的"声音"是核心体验。TTS技术已非常成熟： 流式TTS 延迟要求：首音延迟<300ms，支持流式输入 情感控制：通过ssml或prompt控制语气（开心、悲伤、严肃） 多语言：支持中英日韩等多语言自然切换 声音克隆 少量样本（3-10秒）克隆目标音色 使用说话人编码（speaker encoder）技术 需注意Deepfake伦理问题 代表方案 商用：Azure TTS、ElevenLabs、火山引擎 开源：ChatTTS、GPT-SoVITS、CosyVoice 第三层：唇形同步 唇形同步是数字人的技术难点——嘴型需要精确匹配语音内容。 3D方案：BlendShape驱动 预定义一组口型（ARKit的52个BlendShape） 音素到口型映射（ viseme mapping） 音频特征→音素识别→口型映射→BlendShape权重 2D方案：面部驱动 音频特征提取（mel-spectrogram） 基于扩散模型或GAN生成面部帧 时序一致性处理（光流+时间一致性损失） Wav2Lip类方法 核心思想是用音频直接驱动任意视频中的嘴唇运动： 输入：视频 + 新音频 输出：嘴型匹配新音频的视频 局限：仅嘴部区域，其他部位不动 第四层：动作驱动 身体动作 动作捕捉：光学/惯性动捕，精度高但成本高 视频驱动：单摄像头提取3D姿态，驱动数字人 AI生成：文本→动作序列（如动作扩散模型） 表情驱动 面部关键点检测（68/468点） FACS（面部动作编码系统）映射 实时跟踪摄像头数据→表情重定向到数字人 眼神控制 眼神是数字人"活起来"的关键： 注视追踪：让数字人看着对话者 扫视（saccade）：模拟自然眼动 眨眼频率：6-15次/分钟的自然频率 第五层：大脑驱动 数字人的"大脑"由LLM驱动： 用户输入 → ASR(语音转文字) → LLM(生成回复) → TTS(文字转语音) → 面部/动作驱动 关键要求： ...

AI算力市场的变与不变 过去三年，AI芯片市场经历了前所未有的变化。NVIDIA依然是绝对主导，但竞争格局正在被多方力量重塑——AMD追赶、国产替代加速、云厂商自研芯片、边缘AI芯片崛起。 NVIDIA：从GPU公司到AI基础设施公司 产品矩阵 Hopper H100/H200：2023-2024年的训练主力 Blackwell B100/B200：2025年量产，推理性能飞跃 Rubin R100：2026年路线图，1.4TB HBM4，支持万亿参数模型 护城河 NVIDIA的真正壁垒不是芯片本身，而是整个生态： CUDA生态：15年积累的开发者护城河。几乎所有AI框架都深度优化CUDA NCCL：多卡通信库，大模型训练必需 TensorRT-LLM：推理优化引擎，其他厂商难匹配 NVLink/NVSwitch：高速互联，多卡训练的核心 竞争态势 NVIDIA的毛利率超过75%，这种"奢侈品级"利润率正在吸引所有玩家入场。但短期内其生态优势难以撼动。 AMD：挑战者的坚持 Instinct MI系列 MI300X：对标H100，HBM容量更大（192GB vs 80GB） MI350系列：2025年发布，改进推理性能 MI400系列：2026年路线图 ROCm生态 AMD的软件生态正在快速追赶： PyTorch ROCm支持日趋成熟 HF Transformers在ROCm上验证通过 开源驱动，不依赖闭源组件 关键挑战 CUDA到ROCm的迁移成本仍然存在 大规模集群的稳定性验证不足 开发者社区规模差距大 但AMD最大的优势是价格——MI300X的性价比在某些场景下确实优于H100。 华为昇腾：国产替代的标杆 硬件路线 昇腾910B：对标A100，7nm工艺 昇腾910C：2025年量产，性能对标H100 昇腾920：2026年路线图，预期对标H200 CANN软件栈 华为构建了完整的软件栈： CANN（Compute Architecture for Neural Networks） MindSpore框架（对标PyTorch） MindIE推理引擎（对标TensorRT） 实际适配情况 支持3B-70B模型训练和推理 与主流框架的适配通过插件实现 大规模训练稳定性仍有提升空间 生态挑战 开发者社区规模远小于CUDA生态 迁移成本高，需要改代码 第三方工具链支持不足 Google TPU：内部驱动+外部服务 TPU v5/v6 v5p：适合大模型训练，性能约为H100的1.5倍 v6：2025-2026部署，推理性能大幅提升 软件生态 JAX/XLA：Google力推的ML框架 PaxML：大模型训练框架 Triton后端支持 特点 TPU是面向大模型的专用芯片： ...