38 篇博文 含有标签「AI」

一、概述​

YOLO26 是 Ultralytics 于 2026 年 1 月正式发布的新一代 YOLO 系列目标检测模型，核心定位是专为边缘计算与低功耗设备设计的端到端视觉 AI 模型，并非对 YOLO11 的小幅迭代，而是从架构、训练机制、部署适配等层面的代际性升级。本报告从新增功能、核心特性、性能指标、架构差异、应用适配等维度，全面对比分析 YOLO26 与 YOLO11 的核心差异与提升点。

Agent Skills 是由 Anthropic 于 2025 年确立并推进为开放标准的AI 智能体能力扩展方案，本质是将复杂的 Prompt 工程、领域知识库、执行逻辑与脚本，封装成标准化的文件夹结构（核心为 SKILL.md ），支持模型动态发现、按需加载，大幅提升任务执行的稳定性与 Token 效率，避免重复的 Prompt 粘贴与维护。通过模块化技能封装提升AI智能体的专业能力，让AI模型能够按需加载、自主调用特定任务的能力包。

Agent被视为AI系统的基本构成单元。一个功能完备的智能体必须具备一套核心技能，即 “Agent skills”。这些技能使其不仅能执行简单指令，还能像人类一样进行复杂的任务处理。文档明确指出，这些技能包括：

• 规划能力（Planning）: 智能体能够将复杂的用户目标分解成一系列可执行的子任务和步骤，并制定出合理的行动方案。
• 推理能力（Reasoning）: 智能体具备逻辑思考和因果推断的能力。它能够根据已知信息、环境状态和物理常识，判断如何行动以及为什么要这样行动。这在解决现实世界中的“长尾问题”（罕见或不可预见的场景）时至关重要。
• 执行能力（Execution）: 智能体能够调用工具、API或模型，将规划好的任务步骤转化为具体的操作。例如，编写代码、操控软件、控制机械臂等。
• 研究能力（Research）: 智能体能够主动搜索、获取并整合新信息和知识，以完成当前任务或优化未来的决策。这使其具备持续学习和适应的潜力。

在CES 2026上，英伟达创始人兼CEO黄仁勋发表了主题为 “计算的炼金术”（The Alchemy of Computation） 的演讲。本次演讲的核心论点是：计算行业正在经历从软件到硬件的全面重构，AI将从数字世界走向物理世界，而英伟达通过其全栈技术，正成为这场新工业革命的基石引擎。

核心战略：引领双重平台变革​

英伟达指出，计算行业正同时经历两场十年一遇的平台级变革：

1. 从通用计算到加速计算：传统计算范式正在被加速计算所取代。
2. 从传统应用到生成式AI：应用范式正在被生成式AI重塑。

这场变革导致了整个技术栈的全面重构，具体表现为：从代码驱动转向模型驱动、从CPU转向GPU、从预编译转向生成式、从应用优先转向AI优先。这催生了一个价值高达10万亿美元的待现代化的计算市场。

2025年，我聚焦AI技术应用与全栈开发能力提升，以“技术赋能业务、沉淀个人价值”为核心目标，扎实推进各项工作任务。在项目实践中积极探索AI工具融合应用，在个人技术沉淀上持续深耕，既完成了团队交付的核心任务，也实现了个人技术能力与价值输出的双重突破。现将全年工作情况总结如下：

一、核心工作成果：AI驱动业务落地​

AI智能体与系统搭建成果丰硕​

• 基于Coze平台完成多款智能体及工作流搭建，包括地震小助手、设备管理小助手、Viki等。通过API调用实现智能体与实际项目的深度融合，有效简化了业务流程、提升了工作协同效率，其中设备管理小助手已在相关项目中投入使用，显著降低了设备运维的沟通成本与响应时间。
• 运用Dify平台搭建智能客服智能体，整合VAD（语音活动检测）、ASR（自动语音识别）、TTS（语音合成）等多模型能力，成功构建全流程智能客服系统。系统实现了语音交互、问题精准识别与智能应答的闭环，为用户提供了便捷的服务体验，同时减轻了人工客服的工作负担。

AI辅助开发创新实践​

• 全年广泛运用AI工具赋能开发全流程，熟练使用多款工具提升开发效率与代码质量。基于此，自主完成一款Flutter APP的开发，并通过AI优化产品逻辑与运营策略，成功实现商业盈利，验证了AI辅助开发模式的可行性与商业价值。
• 积极引入并订阅了多类AI辅助开发工具，涵盖代码生成、智能问答与专项优化等方向。在IDE领域，充值并熟练使用Cursor、CodeBuddy、Qoder等工具，有效提升了编码效率与质量。在大模型平台方面，接入了DeepSeek、AutoGLM、硅基流动等国内优秀模型服务，并结合豆包、MiniMax等平台，在日常开发、代码调试与方案设计中实现了AI全流程协同。

随着人工智能技术的快速发展，多模态大语言模型（MLLMs）已成为 AI 领域的核心研究方向。在这一领域中，MiniCPM-V 系列作为面壁智能与清华大学自然语言处理实验室联合推出的端侧导向多模态模型，凭借其在低参数量下实现高性能的独特优势，正在重新定义边缘设备 AI 的可能性边界。与此同时，InternVL和Qwen-VL作为分别由上海人工智能实验室和阿里云推出的主流多模态模型，也在各自的技术路线上取得了显著进展。

当前，边缘计算和隐私保护需求的增长，使得在资源受限设备上部署高性能多模态 AI 成为行业迫切需求。MiniCPM-V 系列通过创新的架构设计和优化策略，在保持 8B 参数规模的同时，实现了与大参数量模型相当甚至更优的性能表现。本研究旨在通过深入分析 MiniCPM-V 的技术架构、性能表现、部署方案以及与 InternVL、Qwen-VL 的全面对比，为多模态 AI 模型的选型和部署提供科学依据。

一、GGUF 的基本含义​

GGUF 是 "GPT-Generated Unified Format" 的缩写，是一种专为大语言模型 (LLM) 设计的二进制文件存储格式，由 llama.cpp 创始人 Georgi Gerganov 于 2023 年 8 月 21 日正式推出，作为 GGML 格式的继任者。

二、GGUF 的核心作用​

GGUF 是专门为本地推理优化的模型格式，特别是针对CPU 和低显存 GPU 环境。它将模型运行所需的所有信息打包在一个文件中，包括：

• 模型权重 (量化后)
• 架构参数 (隐藏层大小、层数等)
• tokenizer (分词器) 信息
• 量化方案详情

三、GGUF 解决的痛点​

在 GGUF 出现前，AI 模型存储面临三大问题：

四、GGUF 的技术特点​

1. 文件结构​

GGUF 采用三层架构设计：

• Header (文件头)：存储版本号、元数据大小、张量数量等基本信息
• Metadata (元数据区)：包含模型架构、tokenizer、量化类型等完整配置
• Tensor Data (张量区)：存储量化后的权重矩阵，按层组织

这种设计类似 "模型 = 配置 + 权重" 的打包形式，但更轻量、更专注推理。

2. 强大的量化支持​

GGUF 是量化模型的理想载体，支持多种量化方案：

关键优势：每个张量可独立选择量化类型，支持混合量化 (不同层使用不同精度)，最大化性能与精度平衡。

五、GGUF 命名规则解析​

以qwen2-7b-instruct.Q4_K_M.gguf为例：

• qwen2-7b-instruct：模型名称 (通义千问 2，7B 参数，指令微调版)
• Q4_K_M：量化方案 (4 位，基于 K-means 聚类，多向量)
• .gguf：文件格式后缀

量化后缀是 GGUF 文件名的重要组成部分，它直接告诉用户模型的压缩程度和推理性能。

六、GGUF vs GGML：核心差异​

七、应用场景：为何 GGUF 如此重要？​

1. 本地 AI 部署：让普通电脑也能运行大模型，保护隐私，避免 API 费用
2. 边缘计算：适用于手机、IoT 设备等资源受限环境
3. 研究与实验：快速测试不同模型和量化配置，无需复杂环境搭建
4. 模型分发：Hugging Face 等平台已支持 GGUF，一键下载即用

总结：GGUF 是大模型走向大众化的关键一步，正如 MP3 让音乐普及一样，它让 "人人都能在自己电脑上跑大模型" 成为现实。

八、如何使用 GGUF 模型？​

使用非常简单：

# 使用llama.cpp推理
./main -m model.Q4_K_M.gguf -p "你好，GGUF!"

# 使用Python库
from llama_cpp import Llama
llm = Llama(model_path="model.Q4_K_M.gguf")
output = llm("写一首关于GGUF的诗")

GGUF 文件已包含所有必要信息，无需额外配置即可使用。

九、其它格式​

除了GGUF格式以外，还有以下常用格式，主要区别：

int4：极致压缩的 4 位整数量化

• 量化是将浮点权重转为低精度整数，int4 用 4 位存储权重，大幅减少存储与计算开销。

• 优点：极致压缩，适合低显存设备；缺点：长文本易掉精度，需配合 AWQ/GPTQ 等算法弥补。

• 常见组合：int4+AWQ（精度更稳）、int4+GPTQ（逐层误差最小化）。

AWQ：激活感知的低比特量化算法

• 核心是通过激活分布识别关键权重通道，按通道缩放并保护约 1% 关键权重，降低量化误差。

• 相比普通 int4：精度更高（接近无损）、推理更快（硬件友好），但实现较复杂，依赖专用库（AutoAWQ）。

• 适配：NVIDIA GPU 优先，支持 TensorRT-LLM、vLLM 等推理引擎。

GGUF：本地部署的统一模型格式

• 不是量化算法，而是存储量化后模型的二进制格式，单文件包含权重、元数据、分词器，支持 mmap 快速加载。

• 支持多种量化等级（如 Q4_K_M、Q5_K_S），适配 llama.cpp/Ollama，CPU 推理优化显著，适合无高端 GPU 的本地部署。

• 常见命名：Model-Instruct.Q4_K_M.gguf（指令微调 + Q4_K_M 量化 + GGUF 格式）。

Instruct：面向指令交互的微调标识

• 基线模型经指令数据集微调，强化对用户指令的理解与执行，减少幻觉，提升回复相关性。

• 与 Base（基础模型）、Chat（对话优化）并列，是用途标签，不涉及量化或格式。

十、小结​

GGUF 代表着 AI 模型存储与推理的重大进步，它通过统一格式、支持量化、单文件部署三大核心优势，正在成为开源大模型分发的事实标准。它是一个专为本地推理设计的 "模型压缩包"，将大型语言模型变成普通人电脑也能运行的轻量级应用。

MiMo-V2-Flash 正式开源！这是一个专为极致推理效率自研的总参数 309B（激活 15B）的 MoE 模型，通过 Hybrid 注意力架构创新及多层 MTP 推理加速，在多个 Agent 测评基准上保持进入全球开源模型 Top 2；代码能力超过所有开源模型，比肩标杆闭源模型 Claude 4.5 Sonnet，但推理成本仅为其 2.5%，生成速度提升 2 倍，成功将大模型推理效率推向极致。

秉持开放精神，模型权重和推理代码均采用 MIT 协议全面开源。API 限时免费。

12月1日，字节跳动豆包团队联合中兴努比亚，发布豆包手机助手，并搭配努比亚M153工程样机面向开发者发售。这款被称为“手机自动驾驶”的产品，彻底打破了传统手机助手的边界——不仅能完成定闹钟、查天气等基础操作，更能实现点外卖、订机票、跨平台比价、自动回复微信、运行小程序游戏等复杂场景，真正做到“一句话搞定一切”。

与华为小艺、小米小爱、OPPO小布等传统助手不同，豆包手机助手无需用户手动操作APP：无需打开应用、无需点击界面、无需滑动屏幕，AI会模拟真人逻辑自动完成全流程操作，如同为每个用户配备了专属真人助理。这种“跳过APP直接解决需求”的模式，迅速引发行业震动，360创始人周鸿祎更是发布视频直言：“美团、淘宝的高管们可能要连夜开会了。”

周鸿祎的判断并非危言耸听。过去十几年，互联网大厂构建的核心商业模式，本质是“流量漏斗”：用户有购物需求，需打开淘宝/京东，刷首页推荐、看信息流广告、搜索比价、筛选产品、加入购物车，最终完成下单——每一个环节都是大厂精心设计的流量变现节点。而豆包手机助手的出现，直接绕开了这一漏斗：用户无需打开淘宝首页、无需浏览广告、无需手动比价，只需说一句“帮我买一件适合冬天的羽绒服”，AI就能自动完成全流程操作。这意味着，大厂花费十几年搭建的流量壁垒、广告变现体系，被AI直接“短路”，这才是真正让互联网大厂彻夜难眠的核心原因。

“大模型善后工程师”这个说法虽然带点调侃意味，但非常精准地抓住了当前生成式AI落地实践中的一个核心现实——大模型是强大的“初稿生成器”，但离“端到端可靠交付”仍有距离。

• ✅ 80%：大模型在开放域、非关键路径、容错性高的任务上表现惊艳——比如：
  • 写一封普通邮件初稿
  • 生成常规SQL查询
  • 用标准框架搭一个简单网页
  • 翻译/摘要/头脑风暴类创意
• ❌ 20%：剩下那部分往往涉及：
  • 准确性要求高（如金融计算、医疗建议、法律条款）
  • 上下文深度耦合（需精准理解业务逻辑、历史数据、用户意图）
  • 边界case处理（异常输入、歧义提示、多轮意图漂移）
  • 合规与安全（隐私脱敏、偏见过滤、版权规避）
  • 工程化集成（API封装、缓存策略、错误重试、日志追踪）

ONNX（Open Neural Network Exchange）和 PT（PyTorch 模型文件）是两种不同的模型格式，主要区别体现在设计目标、兼容性、用途和特性上，具体如下：

格式定义与设计目标​

• PT 格式：

  是 PyTorch 框架的原生模型格式（文件后缀通常为 .pt 或 .pth），本质上是 PyTorch 张量和模型结构的序列化文件，紧密依赖 PyTorch 的运行时环境和 API。

  设计目标是方便 PyTorch 模型的保存、加载和断点续训，更适合 PyTorch 生态内的模型开发、调试和训练。

• ONNX 格式：

  是一种跨框架的开放格式（由微软、Facebook 等联合推出），旨在标准化神经网络模型的表示方式，实现不同深度学习框架（如 PyTorch、TensorFlow、MXNet 等）之间的模型互转和部署兼容。

  设计目标是解决 “模型格式碎片化” 问题，专注于模型的跨平台部署。

兼容性​

• PT 格式：

  仅能被 PyTorch 框架识别和加载，依赖 PyTorch 的版本和具体算子实现（不同 PyTorch 版本可能存在兼容性问题），无法直接在其他框架（如 TensorFlow、ONNX Runtime）中使用。

• ONNX 格式：

  与框架无关，支持多种深度学习框架导出（如 PyTorch 的 torch.onnx.export、TensorFlow 的 tf2onnx 工具），并可被多种推理引擎加载运行（如 ONNX Runtime、TensorRT、OpenVINO 等），兼容性更强。

用途场景​

• PT 格式：

  主要用于模型训练阶段，例如：

  • 保存训练过程中的模型权重和结构，方便断点续训；
  • 在 PyTorch 环境下进行模型微调、评估或修改网络结构。

• ONNX 格式：

  主要用于模型部署阶段，例如：

  • 将训练好的模型（无论来自 PyTorch 还是 TensorFlow）转换为 ONNX 格式，再部署到不同硬件（CPU、GPU、移动端、嵌入式设备）或平台（Windows、Linux、Android 等）；
  • 结合推理引擎（如 ONNX Runtime）进行高效推理优化（如算子融合、量化等）。

存储内容​

• PT 格式：

  通常存储模型的参数权重、计算图结构（PyTorch 的动态图定义），还可能包含优化器状态（用于续训）等额外信息，文件大小可能较大。

• ONNX 格式：

  存储的是静态计算图（节点、算子、输入输出张量信息）和模型权重，结构更标准化，不包含训练相关的优化器状态等信息，更适合推理。

灵活性与优化​

• PT 格式：

  依赖 PyTorch 的动态图机制，加载后可灵活修改网络结构或参数，适合研发阶段的灵活调试，但推理时需要 PyTorch runtime 支持，优化手段相对受限。

• ONNX 格式：

  作为静态图格式，一旦导出后结构相对固定，但可被专用推理引擎深度优化（如 TensorRT 的 FP16/INT8 量化、层融合），通常能获得更高的推理效率，尤其在生产环境中优势明显。

总结​

• PT 是 PyTorch 原生格式，适合训练、调试和 PyTorch 生态内的开发；
• ONNX 是跨框架开放格式，适合模型部署和跨平台推理。

实际流程中，常先在 PyTorch 中用 PT 格式保存模型，训练完成后导出为 ONNX 格式，再部署到生产环境。