本文深入剖析了大模型技术的整体架构从Agent应用层到硬件层进行分层阐述。文章详细梳理了大模型框架、训练范式及推理技术的演变逻辑揭示了Transformer、Dense、MoE、MLA、Hybrid Retention等架构选择的核心矛盾与趋势。同时探讨了多模态统一路径、Benchmark评估方式选择以及关键基础设施差异为读者提供了全面且深入的大模型技术理解。概念不清地动山摇要想搞清楚一件事一定要从底层概念开始用劲。温馨提示文章很长技术概念较多建议先收藏不迷路。01 大模型总体技术栈分层大模型技术可以分为以下层次从顶到底┌─────────────────────────────────────────────────┐ │ Agent 应用层 │ │ Agent框架 / Skills / Memory / Multi-Agent │ ├─────────────────────────────────────────────────┤ │ 模型服务层 │ │ 推理(Inference) / API / TPS / 端侧/云端 │ ├─────────────────────────────────────────────────┤ │ 后训练层 (Post-train) │ │ SFT → RLHF → Reasoning RL → Agent RL │ ├─────────────────────────────────────────────────┤ │ 预训练层 (Pretrain) │ │ 自回归语言建模 / next token prediction │ ├─────────────────────────────────────────────────┤ │ 模型架构层 │ │ Transformer → Dense → MoE → MLA/Hybrid Retention│ ├─────────────────────────────────────────────────┤ │ 基础设施层 (Infra) │ │ 集群 / 通信算子 / 监控 / RL Infra │ ├─────────────────────────────────────────────────┤ │ 硬件层 │ │ 训练卡 / 推理卡 / 端侧芯片 │ └─────────────────────────────────────────────────┘02 大模型框架的演变逻辑演变路线图Transformer (2017) │ ├──→ Dense模型 (LLaMA, 2023) │ │ │ │ 问题参数全激活又贵又慢 │ ▼ │ GQA (LLaMA_2, 2023) │ │ 多个Query head共享KV减少KV Cache │ │ │ │ 问题仍是Densescaling成本高 │ ▼ │ MoE (DeepSeek V2/V3, 2024) │ │ 稀疏激活每次只用部分Expert │ │ Router负责调度 │ │ Expert负载均衡防专家死亡 │ │ │ │ 问题MLA设计针对特定推理卡不支持MTP加速 │ ▼ │ MLA (DeepSeek V2, 2024) │ │ 低秩压缩KV Cache │ │ 访存/计算完美平衡在Chat时代 │ │ │ │ 问题已达Compute Bound/Memory Bound临界点 │ │ 上MTP后又被卡回Compute Bound │ │ 后训练周期拉长架构假设易失效 │ ▼ │ MLA MTP ❌ 不兼容 │ └──→ Hybrid Retention (MemoVR, 2025) │ │ Full Attention层 Sliding Window层交替堆叠 │ 稀疏比 5:1 → 7:1更大模型可更稀疏 │ ├──→ MTP ✅ 兼容 │ │ 利用计算剩余的算力 │ │ 预训练提升基座能力 │ │ 推理时投机解码加速 │ └──→ Agent时代最优解 │ 长上下文效率高KV Cache小 │ 推理速度快60-150 TPS │ 架构简洁留有调整余地架构选择的核心矛盾判断与洞察后训练周期从1个月拉长到半年到一年预训练阶段做的假设用什么卡、什么场景、多长上下文全部可能失效。因此需要更简洁的架构而非更精细的架构。03 训练范式的演变逻辑三阶段演变阶段1Chat时代 (2022-2024) ═══════════════════════════ 预训练(Pretrain) ──→ SFT ──→ 轻量RLHF │ │ │ 大规模语料 人工标注 人类偏好 (互联网数据) (指令-回答对) (哪个更好) │ 核心学习语言知识和世界知识 算力比预训练 后训练 (33:5) 代表ChatGPT, LLaMA 阶段2Reasoning时代 (2024-2025) ═══════════════════════════════ 预训练(Pretrain) ──→ SFT ──→ Reasoning RL │ │ │ 大规模语料 人工标注 Code/Math验证 Code数据 │ (有标准答案) │ │ │ 核心模型学会思考 │ 模型长链推理 算力比预训练 ≈ 后训练 │ Chain-of-Thought 代表DeepSeek R1, o1 │ │ Reward来自验证器(自动) 而非人类标注 阶段3Agent时代 (2025-2026) ═══════════════════════════ 预训练(Pretrain) ──→ SFT ──→ Agent RL │ │ │ 大规模语料 Skills数据 环境交互 Code数据 (人机共创) (多轮长程) │ │ │ 核心模型学会做事 │ 模型与Agent框架耦合 算力比预训练 后训练 │ Trajectory级训练 代表Claude Opus 4.6 │ │ Reward来自任务完成率 RL Infra完全不同于Reasoning关键转变后训练重心的迁移Chat时代 预训练 ████████████████████████████ 后训练 ████ 33份算力 5份算力 Reasoning时代预训练 ████████████ 后训练 ████████████ 15份算力 15份算力 Agent时代 预训练 ████ 后训练 ████████████████████████████ 1份算力 1份算力但研究占3份以上 研究 ████████████████████████████████████████████████████ 3份算力各阶段的数据逻辑Code的特殊地位在三个阶段都扮演关键角色——预训练中提供长上下文依赖数据、Reasoning中提供可验证reward、Agent中提供天然的长程复杂任务环境。04 推理技术的关系网推理流程输入文本 │ ▼ ┌─────────┐ │ Prefill │ ← 计算密集并行处理所有输入token │ (读题) │ 生成KV Cache └────┬────┘ │ ▼ ┌─────────┐ │ Decode │ ← 访存密集逐个生成输出token │ (写答案) │ 每步读取KV Cache └────┬────┘ │ ├──→ 普通Decode一个一个token生成 │ └──→ MTP加速Decode │ ▼ ┌──────────┐ │ MTP Head │ ← 小模型/额外层快速猜多个token │ (小助手) │ └────┬─────┘ │ ▼ ┌──────────┐ │ Verify │ ← 主模型并行验证 │ (检查) │ 命中→采纳未命中→重新生成 └──────────┘ │ ▼ 速度提升成本下降MTP的双重价值预训练阶段 推理阶段 MTP MTP │ │ ▼ ▼ 提升基座能力 投机解码加速 (预测未来多个token (猜对了直接用) 的训练信号更丰富) │ │ │ ▼ ▼ 更好的模型效果 更快的推理速度 更低的成本为什么MLA不能用MTPMLA的计算/访存平衡 访存 ████████████████████████████████ ← 已到极限 计算 ████████████████████████████████ ← 已到极限 ↑ 两者完美平衡 加上MTP后 计算 ████████████████████████████████░░░░ ← 又被卡满 访存 ████████████████████████████████ ↑ 又变成Compute BoundMTP白加了 Hybrid Retention MTP 计算 ████████████████████░░░░░░░░░░░░░░ ← 有剩余 访存 ████████████████████████████████ ↑ MTP刚好填补计算剩余05 Agent框架的技术栈Agent框架的组成┌──────────────────────────────────────────────┐ │ 用户交互层 │ │ (UI/消息通道/定时任务/心跳任务) │ ├──────────────────────────────────────────────┤ │ Agent框架层 │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Memory │ │ Skills │ │ 多模型 │ │ │ │ 记忆系统 │ │ 技能包 │ │ 调度 │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Context │ │ 评估 │ │ 工具 │ │ │ │ 编排 │ │ 体系 │ │ 调用 │ │ │ └──────────┘ └──────────┘ └──────────┘ │ ├──────────────────────────────────────────────┤ │ 模型层 │ │ 语言模型 多模态模型 TTS │ │ (Pro/Omni/TTS 协同工作) │ ├──────────────────────────────────────────────┤ │ 环境层 │ │ 代码执行 / 文件系统 / API调用 / 搜索 │ └──────────────────────────────────────────────┘Skills的来源与价值互联网公开知识 vs 企业/个人私有知识 (预训练数据) (Skills) │ │ ▼ ▼ 模型已学会 模型学不到 │ │ ▼ ▼ 通用能力 场景化能力 (能聊天、能写代码) (能按你的规范写代码) │ │ └───────────┬──────────────────────┘ │ ▼ Skills 预训练的补充 人与Agent共创的产物 群体智能的具象化OpenClaw vs Claude Code核心洞察先用Opus 4.6在OpenClaw上把框架改好自定义Memory系统、Multi-Agent架构然后切换到更便宜的模型效果依然很好。框架弥补了模型短板。06 多模态的统一路径当前状态两条路线并行路线A离散化统一小米AI大模型在探索的方向 ═══════════════════════════════ 文本 ──→ Token ID离散 ──┐ │ 音频 ──→ RVQ编码 ──→ Token ID离散──→ 同一套LLM处理 │ 图像 ──→ RVQ编码 ──→ Token ID离散──┘ (正在进行中) (尚未走通) 优势统一架构、统一RL Infra、统一训练范式 劣势离散化有损、研究成本高 路线B连续表征拼接主流做法 ═══════════════════════════════ 文本 ──→ Token Embedding ──┐ │ 图像 ──→ VIT编码 ──→ 连续表征 ──→ 拼接后送入LLM │ 音频 ──→ 语音编码器 ──→ 连续表征 ──┘ 优势成熟、效果好 劣势各模态编码器独立、架构不够优雅07 Benchmark的取舍逻辑❌被放弃的Benchmark SWE-Bench ──→ 只测修bug不代表真正软件开发能力 BrowseComp ──→ 信息检索太specific换个方式就不行 TerminalBench ──→ 终端操作能力实际场景不常用 判断 在这上面训练模型只能在这种数据集上测 换的方式哪怕也是做信息检索最终能力还是放不出去 ✅被采用的评估方式 体感评估 ──→ 接到OpenClaw/Claude Code里实际用 │ ├──→ Agent框架适配度是否理解框架 ├──→ 任务完成率端到端成功率 ├──→ 长程任务表现复杂软件开发 └──→ 多框架稳定性在不同scaffold上都好用 当你路径走对了靠体感就能立马测出非常大的质的差异08 关键技术名词的关联图Transformer │ ┌──────────────┼──────────────┐ │ │ │ Dense MoE Attention变体 (LLaMA) (DeepSeek V3) │ │ │ ┌────┴────┐ │ │ MLA Hybrid │ │ (DeepSeek) Retention │ │ │ (MemoVR) │ │ │ │ │ │ │ ┌──┴──┐ │ │ │ Full Sliding │ │ │ Attn Window │ │ │ │ │ 不支持MTP 支持MTP │ │ │ │ └──────┬───────┘ │ │ │ │ │ GQA │ │ (减少KV Cache) │ │ │ │ │ └────────┬────────┘ │ │ │ KV Cache │ (显存瓶颈) │ │ │ ┌─────────┴─────────┐ │ │ │ │ Prefill Decode │ (读题) (写答案) │ │ │ │ │ ┌──────┴──────┐ │ │ 普通Decode MTP │ │ (逐个生成) (投机解码)│ │ │ │ │ Speculative │ │ Decoding ◄───┘ │ └──────────→ KV Cache管理 (长上下文核心)09 训练与推理的Infra差异预训练Infra ═══════════ 需求稳定性、吞吐量 │ ├── Loss Spike必须解决 ├── Expert负载均衡 ├── 通信算子正确性 └── 数值稳定性Clip/Norm │ 特点追求精确不容错 Reasoning RL Infra ═══════════════════ 需求推理引擎 验证器 │ ├── 模型推理引擎长思考 ├── Code执行验证器 ├── Math验证器 └── Reward计算 │ 特点以推理rollout为中心 Agent RL Infra ═══════════════ 需求推理引擎 Agent框架耦合 │ ├── 模型推理引擎 ├── Agent环境交互黑盒/白盒 ├── 异构资源调度GPUCPU存储 ├── 容错任务可能中途断开 ├── 训练/推理一致性容忍 └── 框架变化的兼容性 │ 特点以Agent为核心模糊地带多 灵活性和敏捷性要求极高10 一句话总结各技术的为什么存在01什么是AI大模型应用开发工程师如果说AI大模型是蕴藏着巨大能量的“后台超级能力”那么AI大模型应用开发工程师就是将这种能量转化为实用工具的执行者。AI大模型应用开发工程师是基于AI大模型设计开发落地业务的应用工程师。这个职业的核心价值在于打破技术与用户之间的壁垒把普通人难以理解的算法逻辑、模型参数转化为人人都能轻松操作的产品形态。无论是日常写作时用到的AI文案生成器、修图软件里的智能美化功能还是办公场景中的自动记账工具、会议记录用的语音转文字APP这些看似简单的应用背后都是应用开发工程师在默默搭建技术与需求之间的桥梁。他们不追求创造全新的大模型而是专注于让已有的大模型“听懂”业务需求“学会”解决具体问题最终形成可落地、可使用的产品。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】02AI大模型应用开发工程师的核心职责需求分析与拆解是工作的起点也是确保开发不偏离方向的关键。应用开发工程师需要直接对接业务方深入理解其核心诉求——不仅要明确“要做什么”更要厘清“为什么要做”以及“做到什么程度算合格”。在此基础上他们会将模糊的业务需求拆解为具体的技术任务明确每个环节的执行标准并评估技术实现的可行性同时定义清晰的核心指标为后续开发、测试提供依据。这一步就像建筑前的图纸设计若出现偏差后续所有工作都可能白费。技术选型与适配是衔接需求与开发的核心环节。工程师需要根据业务场景的特点选择合适的基础大模型、开发框架和工具——不同的业务对模型的响应速度、精度、成本要求不同选型的合理性直接影响最终产品的表现。同时他们还要对行业相关数据进行预处理通过提示词工程优化模型输出或在必要时进行轻量化微调让基础模型更好地适配具体业务。此外设计合理的上下文管理规则确保模型理解连贯需求建立敏感信息过滤机制保障数据安全也是这一环节的重要内容。应用开发与对接则是将方案转化为产品的实操阶段。工程师会利用选定的开发框架构建应用的核心功能同时联动各类外部系统——比如将AI模型与企业现有的客户管理系统、数据存储系统打通确保数据流转顺畅。在这一过程中他们还需要配合设计团队打磨前端交互界面让技术功能以简洁易懂的方式呈现给用户实现从技术方案到产品形态的转化。测试与优化是保障产品质量的关键步骤。工程师会开展全面的功能测试找出并修复开发过程中出现的漏洞同时针对模型的响应速度、稳定性等性能指标进行优化。安全合规性也是测试的重点需要确保应用符合数据保护、隐私安全等相关规定。此外他们还会收集用户反馈通过调整模型参数、优化提示词等方式持续提升产品体验让应用更贴合用户实际使用需求。部署运维与迭代则贯穿产品的整个生命周期。工程师会通过云服务器或私有服务器将应用部署上线并实时监控运行状态及时处理突发故障确保应用稳定运行。随着业务需求的变化他们还需要对应用功能进行迭代更新同时编写完善的开发文档和使用手册为后续的维护和交接提供支持。03薪资情况与职业价值市场对这一职业的高度认可直接体现在薪资待遇上。据猎聘最新在招岗位数据显示AI大模型应用开发工程师的月薪最高可达60k。在AI技术加速落地的当下这种“技术业务”的复合型能力尤为稀缺让该职业成为当下极具吸引力的就业选择。AI大模型应用开发工程师是AI技术落地的关键桥梁。他们用专业能力将抽象的技术转化为具体的产品让大模型的价值真正渗透到各行各业。随着AI场景化应用的不断深化这一职业的重要性将更加凸显也必将吸引更多人才投身其中推动AI技术更好地服务于社会发展。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】
大模型技术栈深度解析：从底层概念到Agent应用，一文读懂演变逻辑！
发布时间：2026/6/5 0:29:59
本文深入剖析了大模型技术的整体架构从Agent应用层到硬件层进行分层阐述。文章详细梳理了大模型框架、训练范式及推理技术的演变逻辑揭示了Transformer、Dense、MoE、MLA、Hybrid Retention等架构选择的核心矛盾与趋势。同时探讨了多模态统一路径、Benchmark评估方式选择以及关键基础设施差异为读者提供了全面且深入的大模型技术理解。概念不清地动山摇要想搞清楚一件事一定要从底层概念开始用劲。温馨提示文章很长技术概念较多建议先收藏不迷路。01 大模型总体技术栈分层大模型技术可以分为以下层次从顶到底┌─────────────────────────────────────────────────┐ │ Agent 应用层 │ │ Agent框架 / Skills / Memory / Multi-Agent │ ├─────────────────────────────────────────────────┤ │ 模型服务层 │ │ 推理(Inference) / API / TPS / 端侧/云端 │ ├─────────────────────────────────────────────────┤ │ 后训练层 (Post-train) │ │ SFT → RLHF → Reasoning RL → Agent RL │ ├─────────────────────────────────────────────────┤ │ 预训练层 (Pretrain) │ │ 自回归语言建模 / next token prediction │ ├─────────────────────────────────────────────────┤ │ 模型架构层 │ │ Transformer → Dense → MoE → MLA/Hybrid Retention│ ├─────────────────────────────────────────────────┤ │ 基础设施层 (Infra) │ │ 集群 / 通信算子 / 监控 / RL Infra │ ├─────────────────────────────────────────────────┤ │ 硬件层 │ │ 训练卡 / 推理卡 / 端侧芯片 │ └─────────────────────────────────────────────────┘02 大模型框架的演变逻辑演变路线图Transformer (2017) │ ├──→ Dense模型 (LLaMA, 2023) │ │ │ │ 问题参数全激活又贵又慢 │ ▼ │ GQA (LLaMA_2, 2023) │ │ 多个Query head共享KV减少KV Cache │ │ │ │ 问题仍是Densescaling成本高 │ ▼ │ MoE (DeepSeek V2/V3, 2024) │ │ 稀疏激活每次只用部分Expert │ │ Router负责调度 │ │ Expert负载均衡防专家死亡 │ │ │ │ 问题MLA设计针对特定推理卡不支持MTP加速 │ ▼ │ MLA (DeepSeek V2, 2024) │ │ 低秩压缩KV Cache │ │ 访存/计算完美平衡在Chat时代 │ │ │ │ 问题已达Compute Bound/Memory Bound临界点 │ │ 上MTP后又被卡回Compute Bound │ │ 后训练周期拉长架构假设易失效 │ ▼ │ MLA MTP ❌ 不兼容 │ └──→ Hybrid Retention (MemoVR, 2025) │ │ Full Attention层 Sliding Window层交替堆叠 │ 稀疏比 5:1 → 7:1更大模型可更稀疏 │ ├──→ MTP ✅ 兼容 │ │ 利用计算剩余的算力 │ │ 预训练提升基座能力 │ │ 推理时投机解码加速 │ └──→ Agent时代最优解 │ 长上下文效率高KV Cache小 │ 推理速度快60-150 TPS │ 架构简洁留有调整余地架构选择的核心矛盾判断与洞察后训练周期从1个月拉长到半年到一年预训练阶段做的假设用什么卡、什么场景、多长上下文全部可能失效。因此需要更简洁的架构而非更精细的架构。03 训练范式的演变逻辑三阶段演变阶段1Chat时代 (2022-2024) ═══════════════════════════ 预训练(Pretrain) ──→ SFT ──→ 轻量RLHF │ │ │ 大规模语料 人工标注 人类偏好 (互联网数据) (指令-回答对) (哪个更好) │ 核心学习语言知识和世界知识 算力比预训练 后训练 (33:5) 代表ChatGPT, LLaMA 阶段2Reasoning时代 (2024-2025) ═══════════════════════════════ 预训练(Pretrain) ──→ SFT ──→ Reasoning RL │ │ │ 大规模语料 人工标注 Code/Math验证 Code数据 │ (有标准答案) │ │ │ 核心模型学会思考 │ 模型长链推理 算力比预训练 ≈ 后训练 │ Chain-of-Thought 代表DeepSeek R1, o1 │ │ Reward来自验证器(自动) 而非人类标注 阶段3Agent时代 (2025-2026) ═══════════════════════════ 预训练(Pretrain) ──→ SFT ──→ Agent RL │ │ │ 大规模语料 Skills数据 环境交互 Code数据 (人机共创) (多轮长程) │ │ │ 核心模型学会做事 │ 模型与Agent框架耦合 算力比预训练 后训练 │ Trajectory级训练 代表Claude Opus 4.6 │ │ Reward来自任务完成率 RL Infra完全不同于Reasoning关键转变后训练重心的迁移Chat时代 预训练 ████████████████████████████ 后训练 ████ 33份算力 5份算力 Reasoning时代预训练 ████████████ 后训练 ████████████ 15份算力 15份算力 Agent时代 预训练 ████ 后训练 ████████████████████████████ 1份算力 1份算力但研究占3份以上 研究 ████████████████████████████████████████████████████ 3份算力各阶段的数据逻辑Code的特殊地位在三个阶段都扮演关键角色——预训练中提供长上下文依赖数据、Reasoning中提供可验证reward、Agent中提供天然的长程复杂任务环境。04 推理技术的关系网推理流程输入文本 │ ▼ ┌─────────┐ │ Prefill │ ← 计算密集并行处理所有输入token │ (读题) │ 生成KV Cache └────┬────┘ │ ▼ ┌─────────┐ │ Decode │ ← 访存密集逐个生成输出token │ (写答案) │ 每步读取KV Cache └────┬────┘ │ ├──→ 普通Decode一个一个token生成 │ └──→ MTP加速Decode │ ▼ ┌──────────┐ │ MTP Head │ ← 小模型/额外层快速猜多个token │ (小助手) │ └────┬─────┘ │ ▼ ┌──────────┐ │ Verify │ ← 主模型并行验证 │ (检查) │ 命中→采纳未命中→重新生成 └──────────┘ │ ▼ 速度提升成本下降MTP的双重价值预训练阶段 推理阶段 MTP MTP │ │ ▼ ▼ 提升基座能力 投机解码加速 (预测未来多个token (猜对了直接用) 的训练信号更丰富) │ │ │ ▼ ▼ 更好的模型效果 更快的推理速度 更低的成本为什么MLA不能用MTPMLA的计算/访存平衡 访存 ████████████████████████████████ ← 已到极限 计算 ████████████████████████████████ ← 已到极限 ↑ 两者完美平衡 加上MTP后 计算 ████████████████████████████████░░░░ ← 又被卡满 访存 ████████████████████████████████ ↑ 又变成Compute BoundMTP白加了 Hybrid Retention MTP 计算 ████████████████████░░░░░░░░░░░░░░ ← 有剩余 访存 ████████████████████████████████ ↑ MTP刚好填补计算剩余05 Agent框架的技术栈Agent框架的组成┌──────────────────────────────────────────────┐ │ 用户交互层 │ │ (UI/消息通道/定时任务/心跳任务) │ ├──────────────────────────────────────────────┤ │ Agent框架层 │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Memory │ │ Skills │ │ 多模型 │ │ │ │ 记忆系统 │ │ 技能包 │ │ 调度 │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Context │ │ 评估 │ │ 工具 │ │ │ │ 编排 │ │ 体系 │ │ 调用 │ │ │ └──────────┘ └──────────┘ └──────────┘ │ ├──────────────────────────────────────────────┤ │ 模型层 │ │ 语言模型 多模态模型 TTS │ │ (Pro/Omni/TTS 协同工作) │ ├──────────────────────────────────────────────┤ │ 环境层 │ │ 代码执行 / 文件系统 / API调用 / 搜索 │ └──────────────────────────────────────────────┘Skills的来源与价值互联网公开知识 vs 企业/个人私有知识 (预训练数据) (Skills) │ │ ▼ ▼ 模型已学会 模型学不到 │ │ ▼ ▼ 通用能力 场景化能力 (能聊天、能写代码) (能按你的规范写代码) │ │ └───────────┬──────────────────────┘ │ ▼ Skills 预训练的补充 人与Agent共创的产物 群体智能的具象化OpenClaw vs Claude Code核心洞察先用Opus 4.6在OpenClaw上把框架改好自定义Memory系统、Multi-Agent架构然后切换到更便宜的模型效果依然很好。框架弥补了模型短板。06 多模态的统一路径当前状态两条路线并行路线A离散化统一小米AI大模型在探索的方向 ═══════════════════════════════ 文本 ──→ Token ID离散 ──┐ │ 音频 ──→ RVQ编码 ──→ Token ID离散──→ 同一套LLM处理 │ 图像 ──→ RVQ编码 ──→ Token ID离散──┘ (正在进行中) (尚未走通) 优势统一架构、统一RL Infra、统一训练范式 劣势离散化有损、研究成本高 路线B连续表征拼接主流做法 ═══════════════════════════════ 文本 ──→ Token Embedding ──┐ │ 图像 ──→ VIT编码 ──→ 连续表征 ──→ 拼接后送入LLM │ 音频 ──→ 语音编码器 ──→ 连续表征 ──┘ 优势成熟、效果好 劣势各模态编码器独立、架构不够优雅07 Benchmark的取舍逻辑❌被放弃的Benchmark SWE-Bench ──→ 只测修bug不代表真正软件开发能力 BrowseComp ──→ 信息检索太specific换个方式就不行 TerminalBench ──→ 终端操作能力实际场景不常用 判断 在这上面训练模型只能在这种数据集上测 换的方式哪怕也是做信息检索最终能力还是放不出去 ✅被采用的评估方式 体感评估 ──→ 接到OpenClaw/Claude Code里实际用 │ ├──→ Agent框架适配度是否理解框架 ├──→ 任务完成率端到端成功率 ├──→ 长程任务表现复杂软件开发 └──→ 多框架稳定性在不同scaffold上都好用 当你路径走对了靠体感就能立马测出非常大的质的差异08 关键技术名词的关联图Transformer │ ┌──────────────┼──────────────┐ │ │ │ Dense MoE Attention变体 (LLaMA) (DeepSeek V3) │ │ │ ┌────┴────┐ │ │ MLA Hybrid │ │ (DeepSeek) Retention │ │ │ (MemoVR) │ │ │ │ │ │ │ ┌──┴──┐ │ │ │ Full Sliding │ │ │ Attn Window │ │ │ │ │ 不支持MTP 支持MTP │ │ │ │ └──────┬───────┘ │ │ │ │ │ GQA │ │ (减少KV Cache) │ │ │ │ │ └────────┬────────┘ │ │ │ KV Cache │ (显存瓶颈) │ │ │ ┌─────────┴─────────┐ │ │ │ │ Prefill Decode │ (读题) (写答案) │ │ │ │ │ ┌──────┴──────┐ │ │ 普通Decode MTP │ │ (逐个生成) (投机解码)│ │ │ │ │ Speculative │ │ Decoding ◄───┘ │ └──────────→ KV Cache管理 (长上下文核心)09 训练与推理的Infra差异预训练Infra ═══════════ 需求稳定性、吞吐量 │ ├── Loss Spike必须解决 ├── Expert负载均衡 ├── 通信算子正确性 └── 数值稳定性Clip/Norm │ 特点追求精确不容错 Reasoning RL Infra ═══════════════════ 需求推理引擎 验证器 │ ├── 模型推理引擎长思考 ├── Code执行验证器 ├── Math验证器 └── Reward计算 │ 特点以推理rollout为中心 Agent RL Infra ═══════════════ 需求推理引擎 Agent框架耦合 │ ├── 模型推理引擎 ├── Agent环境交互黑盒/白盒 ├── 异构资源调度GPUCPU存储 ├── 容错任务可能中途断开 ├── 训练/推理一致性容忍 └── 框架变化的兼容性 │ 特点以Agent为核心模糊地带多 灵活性和敏捷性要求极高10 一句话总结各技术的为什么存在01什么是AI大模型应用开发工程师如果说AI大模型是蕴藏着巨大能量的“后台超级能力”那么AI大模型应用开发工程师就是将这种能量转化为实用工具的执行者。AI大模型应用开发工程师是基于AI大模型设计开发落地业务的应用工程师。这个职业的核心价值在于打破技术与用户之间的壁垒把普通人难以理解的算法逻辑、模型参数转化为人人都能轻松操作的产品形态。无论是日常写作时用到的AI文案生成器、修图软件里的智能美化功能还是办公场景中的自动记账工具、会议记录用的语音转文字APP这些看似简单的应用背后都是应用开发工程师在默默搭建技术与需求之间的桥梁。他们不追求创造全新的大模型而是专注于让已有的大模型“听懂”业务需求“学会”解决具体问题最终形成可落地、可使用的产品。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】02AI大模型应用开发工程师的核心职责需求分析与拆解是工作的起点也是确保开发不偏离方向的关键。应用开发工程师需要直接对接业务方深入理解其核心诉求——不仅要明确“要做什么”更要厘清“为什么要做”以及“做到什么程度算合格”。在此基础上他们会将模糊的业务需求拆解为具体的技术任务明确每个环节的执行标准并评估技术实现的可行性同时定义清晰的核心指标为后续开发、测试提供依据。这一步就像建筑前的图纸设计若出现偏差后续所有工作都可能白费。技术选型与适配是衔接需求与开发的核心环节。工程师需要根据业务场景的特点选择合适的基础大模型、开发框架和工具——不同的业务对模型的响应速度、精度、成本要求不同选型的合理性直接影响最终产品的表现。同时他们还要对行业相关数据进行预处理通过提示词工程优化模型输出或在必要时进行轻量化微调让基础模型更好地适配具体业务。此外设计合理的上下文管理规则确保模型理解连贯需求建立敏感信息过滤机制保障数据安全也是这一环节的重要内容。应用开发与对接则是将方案转化为产品的实操阶段。工程师会利用选定的开发框架构建应用的核心功能同时联动各类外部系统——比如将AI模型与企业现有的客户管理系统、数据存储系统打通确保数据流转顺畅。在这一过程中他们还需要配合设计团队打磨前端交互界面让技术功能以简洁易懂的方式呈现给用户实现从技术方案到产品形态的转化。测试与优化是保障产品质量的关键步骤。工程师会开展全面的功能测试找出并修复开发过程中出现的漏洞同时针对模型的响应速度、稳定性等性能指标进行优化。安全合规性也是测试的重点需要确保应用符合数据保护、隐私安全等相关规定。此外他们还会收集用户反馈通过调整模型参数、优化提示词等方式持续提升产品体验让应用更贴合用户实际使用需求。部署运维与迭代则贯穿产品的整个生命周期。工程师会通过云服务器或私有服务器将应用部署上线并实时监控运行状态及时处理突发故障确保应用稳定运行。随着业务需求的变化他们还需要对应用功能进行迭代更新同时编写完善的开发文档和使用手册为后续的维护和交接提供支持。03薪资情况与职业价值市场对这一职业的高度认可直接体现在薪资待遇上。据猎聘最新在招岗位数据显示AI大模型应用开发工程师的月薪最高可达60k。在AI技术加速落地的当下这种“技术业务”的复合型能力尤为稀缺让该职业成为当下极具吸引力的就业选择。AI大模型应用开发工程师是AI技术落地的关键桥梁。他们用专业能力将抽象的技术转化为具体的产品让大模型的价值真正渗透到各行各业。随着AI场景化应用的不断深化这一职业的重要性将更加凸显也必将吸引更多人才投身其中推动AI技术更好地服务于社会发展。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】
