Posts

为什么需要边缘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是面向大模型的专用芯片： ...

多模态的意义 真实世界的信息本就是多模态的——文字、图像、声音、视频。纯文本大模型只能理解被"文字化"的世界，而多模态模型直接感知原始信号，能力上限更高。 技术演进路线 阶段一：双塔模型（CLIP时代） CLIP开创了图文对齐的标准范式： 图像 → Image Encoder → 图像向量 I ∈ R^d 文本 → Text Encoder → 文本向量 T ∈ R^d 对比损失: 最大化匹配对的相似度，最小化不匹配对的相似度 CLIP的核心贡献是证明了"大规模弱监督预训练"的有效性——用4亿图文对训练，不需要精细标注。 但双塔模型有根本限制：图文交互只在最终向量层发生，无法做细粒度的图文理解（如"图片左上角的红色物体是什么"）。 阶段二：桥接模型（BLIP/LLaVA时代） 桥接模型用一个适配层将视觉特征"翻译"到语言空间： 图像 → ViT → 视觉特征 → MLP Projector → 语言特征 tokens ↓ 文本 prompt + 视觉tokens → LLM → 回答 LLaVA的关键创新： 用GPT-4生成图文指令数据 两阶段训练：先训projector，再SFT 证明了"视觉编码器+投影层+LLM"的简洁架构有效 局限： 视觉token数量固定，不能动态调整 投影层能力有限，可能丢失视觉信息 训练分阶段，无法端到端优化 阶段三：原生多模态（GPT-4V/Qwen-VL时代） 原生多模态模型将视觉编码器和语言模型在预训练阶段就联合训练： 关键设计： 视觉编码器提取多分辨率特征 视觉token可变长（根据图像复杂度动态生成不同数量token） 在预训练阶段就混合图文数据 支持任意位置插入图像token Qwen-VL的技术细节： 图像 → ViT(变体) → 图像token序列 → 位置感知的adapter → 与文本token拼接 → Qwen LLM处理 Qwen-VL支持动态分辨率：大图像生成更多token，小图像生成更少token。通过这种方式保留了图像细节。 ...

代码生成的三个时代 第一代：智能补全（2021-2023） GitHub Copilot开创了AI代码补全时代。核心模式是在编辑器中实时预测下一段代码，从单行补全到多行生成。技术上是将光标前后的代码作为上下文送入LLM，生成候选代码。 局限性很明显： 缺乏项目级上下文，只看当前文件 无法理解运行时行为 生成代码质量依赖使用者审查能力 第二代：对话式编程（2023-2025） Cursor、Windsurf等AI IDE引入了对话模式。开发者可以用自然语言描述需求，AI生成完整函数甚至文件。关键改进： 上下文扩展到整个项目（通过embedding检索相关文件） 支持多轮对话迭代修改 自动应用diff编辑到文件 第三代：自主编程Agent（2025-2026） 最新一代代码Agent不再需要人类逐步指导，而是： 理解完整需求描述 自主规划实现步骤 创建/修改多个文件 运行测试验证结果 自主调试修复错误 自主编程Agent的架构 核心组件 [需求理解] → [任务规划] → [代码实现] → [测试执行] → [调试修复] → [完成] ↑ | └──────────────────反馈循环──────────────────────────────┘ 需求理解模块 将自然语言需求转化为结构化的技术规格： 提取功能需求列表 识别技术约束（语言、框架、数据库） 识别非功能需求（性能、安全） 输出：结构化的规格文档 任务规划模块 将规格分解为可执行的子任务序列： 文件创建/修改计划 依赖关系图 每步的验证标准 关键挑战是规划粒度——太粗导致单步过于复杂，太细则浪费token。实践中采用自适应粒度：简单模块整块生成，复杂模块逐步拆解。 代码实现模块 实际生成代码的引擎。关键技术： 1. 上下文构建 不是简单把整个代码库塞进context，而是智能构建： 上下文 = 系统prompt + 项目结构概览(目录树) + 相关文件内容(RAG检索) + 接口定义(类型签名) + 当前任务描述 2. 增量编辑 ...

开源模型的黄金时代 2026年，开源大模型已经不再是闭源模型的"平替"——在很多维度上，顶级开源模型已经追平甚至超越同代闭源模型。三大阵营各有千秋，形成了真正的三足鼎立格局。 Meta Llama系列：生态标杆 技术路线 Llama系列坚持稠密Transformer架构，通过大规模数据+ Scaling Law驱动能力提升。Llama-4引入了原生多模态和长上下文（1M tokens），在推理基准上达到GPT-4级别。 优势 生态最成熟：社区工具链最完整，从训练到部署有完整方案 许可证友好：Llama许可证允许商用（用户量限制逐步放宽） 变体丰富：1B到400B多规格覆盖从边缘到数据中心 量化生态好：GPTQ、AWQ、GGUF格式支持最完整 局限 中文能力相对偏弱（训练语料以英文为主） 大尺寸版本硬件需求高 闭源模型同源技术，可能有OpenAI API兼容性问题 阿里Qwen系列：中文之王 技术路线 Qwen走"多尺寸+多模态+专精化"路线。Qwen-3系列覆盖0.5B到110B，每个尺寸都有Base和Instruct版本，外加专门的Coder、Math、VL变体。 优势 中文能力最强：在C-Eval、CMMLU等中文基准上持续领先 多模态原生：Qwen-VL在视觉理解任务上表现突出 部署友好：提供GGUF、MLX等多种推理格式 全栈覆盖：从文字到代码到数学到视觉，每条线都有专精模型 局限 社区生态不如Llama丰富（西方开发者优先支持Llama） 许可证对大规模商用有一定限制 小尺寸版本能力上限有限 DeepSeek系列：效率之王 技术路线 DeepSeek走技术创新驱动路线，核心创新包括： MoE架构：DeepSeek-V3/V4采用DeepSeekMoE，稀疏激活 MLA注意力：Multi-head Latent Attention大幅压缩KV Cache 多Token预测（MTP）：训练时预测多个未来token，推理时可做投机解码 极致性价比：以远低于同行的训练成本达到同等能力 优势 推理能力突出：在数学和代码基准上持续领先 推理效率极高：MLA+MoE让推理成本远低于同参数稠密模型 API价格极低：DeepSeek API定价远低于竞品 技术创新活跃：不断推出原创架构创新 局限 模型尺寸选择较少（主要集中在大尺寸） 多模态能力起步较晚 社区工具链适配不如Llama 能力对比矩阵 维度 Llama-4 Qwen-3 DeepSeek-V4 英文能力 ★★★★★ ★★★★ ★★★★ 中文能力 ★★★ ★★★★★ ★★★★ 代码能力 ★★★★ ★★★★ ★★★★★ 数学推理 ★★★★ ★★★★ ★★★★★ 多模态 ★★★★ ★★★★★ ★★★ 推理成本 ★★★ ★★★ ★★★★★ 部署便捷性 ★★★★★ ★★★★ ★★★ 选型指南 按场景选型 通用对话助手 ...

为什么需要智能体框架？ 大模型本身只是一个文本生成引擎。要构建能自主完成复杂任务的智能体，需要解决编排、状态管理、工具调用、多Agent协作等问题。智能体框架就是提供这些能力的"操作系统"。 LangGraph：图驱动的精细控制 设计哲学 LangGraph将Agent工作流建模为有向图： 节点：每个节点是一个处理步骤（LLM调用、工具执行、条件判断） 边：定义节点间的转移关系 状态：在图中流转的共享数据结构 核心概念 from langgraph.graph import StateGraph # 定义状态 class AgentState(BaseModel): messages: list = [] tool_results: dict = {} # 创建图 graph = StateGraph(AgentState) graph.add_node("think", think_node) graph.add_node("act", act_node) graph.add_node("observe", observe_node) # 定义边 graph.add_edge("think", "act") graph.add_conditional_edges("act", route_by_result, { "continue": "observe", "done": END }) graph.add_edge("observe", "think") 优势 精细控制：图结构让你明确定义每一步逻辑 状态管理：支持checkpointer持久化状态，可恢复中断的运行 人机协作：内置human-in-the-loop中断点 可视化：图结构天然可可视化，便于调试 劣势 学习曲线较陡，概念抽象 简单任务用图建模略显笨重 与LangChain深度绑定，迁移成本高 适用场景 复杂多步工作流（审批流程、数据处理管道） 需要精确控制每一步的系统 需要状态持久化和恢复的场景 AutoGen：多Agent对话编排 设计哲学 AutoGen（微软出品）采用对话式编排——多个Agent通过对话协作完成任务。核心是将Agent视为对话参与者，而非图节点。 核心概念 from autogen import AssistantAgent, UserProxyAgent coder = AssistantAgent( name="coder", system_prompt="你是一个Python开发者", llm_config=llm_config ) reviewer = AssistantAgent( name="reviewer", system_prompt="你是代码审查专家", llm_config=llm_config ) user = UserProxyAgent( name="user", human_input_mode="TERMINATE" ) # 多Agent对话 user.initiate_chat( coder, message="实现一个排序算法", reviewer作为审查者加入对话 ) 优势 多Agent协作：天然支持多个Agent角色对话 灵活性高：Agent对话模式接近自然，不需要预定义流程 群聊模式：支持多个Agent在群聊中自主决定谁发言 人机混合：UserProxy支持真人参与 劣势 对话难以精细控制，可能进入无意义循环 调试困难，对话历史长 Token消耗大（每个Agent都需完整上下文） 适用场景 需要多角色协作的复杂任务（开发、审查、测试） 创意生成（头脑风暴、方案探索） 模拟社会实验（多视角讨论） CrewAI：角色驱动的团队模拟 设计哲学 CrewAI将Agent协作建模为一个组织/团队，每个Agent有明确的角色、目标和背景。强调"像真实团队一样协作"。 ...

为什么需要对齐？ 大模型在预训练阶段从海量互联网文本中学习了知识和语言能力，但也继承了人类文本中的偏见、有害信息和不良价值观。对齐（Alignment）的目标是让模型的行为符合人类期望——有用（helpful）、诚实（honest）、无害（harmless）。 RLHF：经典三阶段 阶段一：SFT（监督微调） 用人类标注的高质量对话数据微调基座模型，让模型学会"怎么回答"。这一步不改变模型的知识储备，主要塑造输出格式和交互方式。 阶段二：奖励模型训练 训练一个奖励模型（Reward Model, RM）来评估回答质量： 对同一个prompt，让模型生成多个回答 人类标注员对这些回答做偏好排序（A>B>C） 训练RM，使其对人类偏好的排序准确率最大化 奖励模型的目标函数： L = -E[log(σ(r(x,y_w) - r(x,y_l)))] 其中y_w是偏好回答，y_l是不偏好回答，r是RM的标量输出。 阶段三：PPO强化学习 用RM的分数作为奖励信号，通过PPO算法优化模型策略： r_total = r_RM(x,y) - β·KL[π_new(y|x) || π_ref(y|x)] KL惩罚项防止模型偏离参考模型太远（避免"奖励黑客"问题——模型钻RM的漏洞产生高奖励但无意义的输出）。 RLHF的痛点 成本高：需要大量人类标注，RM训练和PPO训练各需一轮 不稳定：PPO对超参数敏感，训练容易崩溃 奖励黑客：模型学会欺骗RM而非真正提升质量 DPO：简化路线 Direct Preference Optimization（DPO）的核心洞察是：RLHF的最优策略可以用闭式解表示，不需要显式训练奖励模型和强化学习。 DPO直接从偏好数据中优化模型，目标函数： L_DPO = -E[log σ(β·(log π(y_w|x)/π_ref(y_w|x) - log π(y_l|x)/π_ref(y_l|x)))] DPO的优势 无需训练独立的奖励模型 无需PPO，训练稳定 计算成本约为RLHF的1/3 效果接近甚至优于RLHF DPO的变体 方法 改进 IPO 引入正则化，防止过拟合偏好数据 KTO 不需要成对比较，只需二元标注 ORPO 将SFT和对齐合并为一步训练 SimPO 去除参考模型，更简单高效 Constitutional AI：自我对齐 Anthropic提出的Constitutional AI（CAI）路线，核心思想是让AI自己监督自己： 用少量人类编写的规则（“宪法”）作为准则 模型生成回答后，用模型自己评估回答是否违反规则 模型自我修正后，用修正后的数据做SFT 用模型生成的偏好对训练奖励模型 宪法规则示例 规则1：不要生成歧视性内容 规则2：拒绝有害请求但不生硬 规则3：当不确定时，承认不确定性 CAI的流程 用户prompt → 模型生成回答A → 模型自我评估(按宪法) → 修正为回答B → (A, B)作为偏好对 → 训练RM → RLHF/PPO CAI的最大优势是减少对人类标注的依赖，可扩展性更好。Claude系列模型的对齐核心就是CAI。 ...

微调方法全景 大模型微调主要有三种技术路线，各有适用场景： 全参微调（Full Fine-tuning）：更新所有参数，效果上限最高，但成本最高 LoRA：冻结主干参数，仅训练低秩适配矩阵，性价比极高 QLoRA：在LoRA基础上对基座模型4bit量化，进一步降低显存需求 LoRA技术详解 原理 LoRA（Low-Rank Adaptation）的核心思想是：模型适配过程中的参数变化具有低秩特性。具体做法： 将原始权重矩阵W∈R^(d×d)的更新分解为两个小矩阵的乘积： W' = W + ΔW = W + B × A 其中A∈R^(r×d)，B∈R^(d×r)，r远小于d（通常取8-64）。 参数量从d²降低到2rd，以r=16、d=4096为例，参数量从16.7M降到131K，缩减了127倍。 关键超参数 rank (r)：秩大小。r越大表达能力越强但训练越慢。推荐8-64起步 alpha：缩放系数，实际缩放为α/r。推荐设为r的2倍 target_modules：应用LoRA的层。至少q_proj和v_proj，推荐all-linear 适用场景 风格定制（让模型用特定语气说话） 领域适配（法律、医疗等垂直领域） 任务适配（将通用模型适配到特定任务格式） QLoRA：极致显存优化 QLoRA在LoRA基础上增加了两个优化： 4-bit NormalFloat量化 将基座模型权重量化为4-bit NF4数据类型。NF4是一种正态分布感知的量化方案，比均匀量化精度更高： 原始: W ∈ FP16 (每参数2字节) 量化: W → NF4 (每参数0.5字节) 训练: 仅LoRA参数为FP32 双重量化 对LoRA的适配矩阵本身也进行量化，进一步压缩梯度检查点的显存占用。 页面优化器 将优化器状态在CPU/GPU之间分页，避免显存峰值溢出。 效果对比 方法 7B模型显存 70B模型显存 效果损失 全参 120GB+ 1200GB+ 0% LoRA 20GB 160GB <1% QLoRA 6GB 48GB 1-2% QLoRA让单张消费级显卡（如RTX 3090, 24GB）就能微调7B模型，极大降低了定制化门槛。 ...