行业与公司 * **行业**：CPU产业，特别是面向AI Agent应用的高性能计算领域[1] * **公司**：英特尔、AMD、NVIDIA等核心芯片供应商；提及的互联网大厂包括国内平台（如豆包、kimi、扣子、美团、字节跳动等）和海外公司（如Google、OpenAI、Groq等）[1][5][6][13][25] 核心观点与论据 AI Agent应用驱动CPU需求增长 * **新兴应用场景消耗大量CPU资源**：AI Agent在信息检索与处理（如从多个网页生成PPT）、AI编程（高频代码编写与验证）等场景显著提升了对高性能、多核CPU的需求[1][3][4] * **PPT生成场景**：付费用户任务可能消耗100个物理核，且每个核需在几秒内完成任务；内容提取、过滤、清洗、排序等操作占用普通CPU 60-70%算力；最终生成时的双层渲染进一步消耗30-40%算力[3] * **AI编程场景**：AI写代码速度快且需高频运行验证，消耗平台提供方大量计算资源[3] * **多模态检索增加CPU需求**：处理图片、声音等非文本数据时，需CPU进行初步处理和分发，增加了对工作型和调度型CPU的依赖[1][15] * **海外大模型服务对CPU依赖大**：如ChatGPT、DeepResearch等平台拥有数亿日活用户，其复杂任务处理流水线增加了对高级别CPU的依赖[16] 计算资源架构与配置趋势 * **三类计算资源池形成**：Agent服务中发展出GPU集群、工作型CPU集群和调度型CPU集群，分别负责GPU协调、任务执行和数据流转[1][10] * **工作型CPU集群需扩容**：为满足付费用户对速度和效果的需求，需构建大规模工作型CPU集群（如64核、128核甚至200多核的高端产品）[10][11] * **调度型CPU需高性能以避免瓶颈**：其最低配置也需64核，以确保快速响应，避免GPU等待，保持GPU高利用率[12] * **主流CPU配置**：国内Agent场景主流CPU配置在64核到128核之间；涉及复杂任务（如图像理解）会使用核心数在228到288之间的第六代至强处理器[9] 市场动态与产业变化 * **CPU价格上涨原因**：第五代、第六代英特尔和AMD CPU性价比高但产能有限；AI应用增多推高需求；GPU算力提升需要更强大的CPU配合，共同推动价格上涨[14] * **国内需求尚未完全释放**：国内生成PPT、查阅资料等助手型应用活跃度较低，日活用户少，需求未完全释放，主要受限于GPU和CPU资源不足以及平台为节省成本限制免费用户使用次数[1][6][7] * **海外需求参考指标**：海外报告显示，Google、Groq和OpenAI的DeepReach付费用户与日活用户（DAU）存在比例关系，每个DAU大约对应0.5个CPU，表明需提前准备CPU以满足增长[25][26] * **NV投资英特尔优化架构**：旨在优化服务器机柜体系中的调度瓶颈，新架构（如GB系列、R系列）提高GPU利用率，并增加了对高性能CPU的需求[1][13] 技术演进与替代趋势 * **任务向GPU转移趋势**：许多数据库查询、多模态检索等任务因GPU的并行计算优势而转向GPU，成为一个相对成熟的领域[23] * **GPU化产生滚动需求**：任务GPU化后，会产生新的应用场景（如电商平台图片识别与描述），从而带来新的CPU需求[24] * **SSD替代DRAM趋势**：NVIDIA推出直接连接SSD与GPU的数据互通技术；在延迟要求较低、任务执行时间较长的场景中，SSD可部分替代DRAM[2][28] * **存储成本优化**：SSD价格上涨推动云厂商通过按存储时长收费和优化KV Cache（如关闭应用后释放并压缩缓存）来降低存储用量[2][27] 其他重要内容 资源分配与具体场景需求差异 * **大厂应对资源压力策略**：并非简单增加CPU数量，而是通过构建工作型CPU集群优化调度，例如建立万颗CPU集群并行处理任务以提高效率、降低成本[1][8] * **不同类型Agent对资源需求不同**： * **调度型CPU需求相对较小**，工作型CPU需求较大[10][17] * **跨APP任务**：对CPU需求更大，主要由后台x86 CPU支撑调度和操作，GPU仅负责简单指令理解[18] * **医疗类Agent**：处理历史病例和诊断推理时，因激活大量参数（可能达20B~30B），对GPU需求更大[18] * **沙盒工作原理**：主流方式是在Linux服务器上分配独立硬盘空间供特定Agent访问，一个128核CPU可同时监控大量沙箱实现高效调度[19][20] * **具体操作资源消耗**：打开一个网页通常需要1个物理核；打开一个APP占用核数时间短暂，仅需几十毫秒[21] 国内外市场差异 * **高频使用场景差异**：国内高频使用Agent和Coding的用户量小，未出现严重资源消耗问题；海外在极端复杂Agent任务中会出现CPU与GPU协调工作量大、资源消耗激增的情况[22]

技术突破与核心创新 - 中国联通数据科学与人工智能研究院团队提出HiMo-CLIP模型，成功突破现有CLIP模型在处理长文本时性能下降的局限[2][3] - 模型核心创新在于建模"语义层级"与"语义单调性"，使模型能自动捕捉当前语境下的语义差异点，无需改变编码器结构[2] - 该工作解决了视觉-语言对齐中长期被忽视的结构化问题，在长文本和组合性文本检索上达到SOTA水平，同时兼顾短文本性能[3][4] 现有技术痛点 - 现有CLIP等模型将文本视为扁平序列，忽略语言内在层级结构，导致文本描述越详细，其与图像的匹配度（对齐分数）反而可能下降[6] - 当文本从简短描述扩展为包含大量细节的长文本时，细节信息淹没核心语义，模型无法在复杂上下文中捕捉最具区分度的特征[6] - 如图1所示，多数SOTA模型在文本变长时对齐分数下降，而HiMo-CLIP（绿勾）分数稳步提升，例如HiMo-CLIP分数从0.242升至0.252，而CLIP从0.290降至0.219[9] HiMo-CLIP方法框架 - 框架包含两个核心组件：层级分解模块（HiDe）和单调性感知对比损失（MoLo）[10] - HiDe模块利用Batch内的PCA动态提取最具区分度的语义成分，自适应构建语义层级，无需人工干预[12][15] - MoLo损失函数强制模型同时对齐"全量文本"和"语义成分"，其公式为MoLo=InfoNCE(f1, feat)+λ*InfoNCE(f2, feat)，实现单调性约束[12][17] 性能优势与实验结果 - 在长文本检索任务中，HiMo-CLIP使用ViT-L/14骨干网络和仅1M训练数据，在Urban1k数据集上取得I2T/T2I 93.0/93.1的分数，优于使用400M数据的CLIP（68.7/52.8）和使用100M数据的LoTLIP等方法[20] - 在短文本检索任务中，HiMo-CLIP在Flickr30k数据集上取得I2T/T2I 92.5/78.2的分数，优于使用400M数据的CLIP（86.1/66.0）[21] - 在自建深度层级数据集HiMo-Docci上，HiMo-CLIP保持了极高的单调性相关系数0.88，远超对比方法，其对齐分数随文本描述完整度增加呈现完美上升趋势[22][25] 技术应用价值 - HiMo-CLIP具备高数据效率，仅使用1M训练数据就击败了使用100M甚至10B数据的方法，例如在长文本检索上优于使用10B数据的SigLIP[17][20] - 模型能动态提取机器认为的差异点，消除了人类语言和机器理解之间的隔阂，训练长文本的同时自动获得短文本匹配能力[19] - 该技术让多模态模型的对齐机制更符合人类认知逻辑，为未来更复杂的多模态理解任务指明方向[4]

文章核心观点 - 团队提出了一种名为UniME-V2的统一多模态嵌入模型，其核心创新在于利用多模态大模型（MLLM）的深层语义理解能力，通过“MLLM-as-a-Judge”机制生成软语义匹配分数，以精准挖掘高质量、多样化的困难负例，并以此指导模型训练，从而显著提升模型在多模态检索、跨模态检索及组合理解等任务上的判别能力和性能 [3][4][9] 方法创新 - **核心机制**：提出“MLLM-as-a-Judge”机制，利用MLLM评估查询-候选对的语义对齐性，生成软语义匹配分数，以指导困难负例挖掘和模型训练 [3][10][14] - **困难负例挖掘流程**：首先使用现有模型（如VLM2Vec）进行全局检索，为每个查询获取前50个相关候选作为潜在困难负例集；随后利用MLLM计算语义匹配分数进行精炼，通过设定阈值排除错误负例，并采用间隔采样策略确保负例的多样性和高质量 [13][18][19][21] - **训练框架**：UniME-V2采用基于分布对齐的框架，将模型计算的相似度矩阵与MLLM生成的软语义匹配分数矩阵对齐，使用JS散度作为损失函数，使模型学会辨析候选间的细微语义差异 [5][27][29] - **重排序模型**：进一步提出UniME-V2-Reranker，采用配对与列表联合优化策略，利用挖掘的困难负例进行训练，以提升基于初始嵌入的检索精度 [6][30] 性能表现 - **多模态检索（MMEB基准）**：UniME-V2在各种基础模型上均实现性能提升。基于Qwen2-VL-2B和7B模型时，比VLM2Vec分别高出3.5%和2.2%；基于LLaVA-OneVision-7B时，比之前的最先进模型（如QQMM、LLaVE和UniME）提高了0.5%-0.9%，并在分布外数据集上获得66.7分，展现了鲁棒性和卓越的迁移能力 [35][36][37][38] - **跨模态检索（零样本）**： - **短描述任务**：在Flickr30K和MS-COCO的**图像到文本检索**任务中，比UniME性能提升2.2%至9.7% [41] - **长描述任务**：在ShareGPT4V和Urban1K上取得显著改进，得益于增强的区分能力和丰富语义内容 [42] - **组合理解任务**：在SugarCrepe数据集上，UniME-V2表现卓越。基于Qwen2-VL-2B时，比UniME性能提升5.3%、6.0%、4.5%；模型扩展至7B后，性能进一步提升9.0%、9.2%、9.2%。与EVA-CLIP-8B相比，也实现了2.7%、3.4%、3.8%的改进 [45][46][47][48] - **重排序性能**：UniME-V2-Reranker在多个下游任务上表现优于基线模型LamRA。使用UniME-V2 (Qwen2-VL-2B) 检索时，重排后性能提升；在仅使用0.6M数据（LamRA使用1.1M）的情况下，结果更优。使用UniME-V2 (Qwen2-VL-7B) 检索时，UniME-V2-Reranker在四个任务上分别比LamRA获得0.5%、0.4%、0.3%和7.4%的性能提升，尤其在组合理解检索任务中优势显著 [50][51][52][53]

核心技术框架与目标 - 构建名为UNITE的多模态统一嵌入框架，旨在解决多模态检索中的跨模态干扰问题 [2][3] - 核心目标是打造一个能同时处理文本、图像、视频及其融合模态输入的统一嵌入器 [3] - 从数据策划与训练机制两个关键视角出发，通过对比学习重新定义统一多模态表示学习的范式 [4] 核心技术创新：模态感知掩码对比学习 - 提出模态感知掩码对比学习机制，以缓解不同模态混合训练导致的语义扭曲或干扰噪声 [7][8] - 核心思想是模态掩码约束，仅在与当前查询目标模态一致的负样本中进行对比，避免模态间的错误竞争 [11][15] - 通过构造模态感知掩码相似度矩阵，确保在计算损失时仅考虑模态一致的样本 [14][16] 两阶段训练方案 - 采用“检索适应 + 指令微调”的两阶段训练方案，以平衡模型的泛化能力与判别能力 [17] - 检索适应阶段使用多模态数据训练基本检索能力，并引入高粒度视频-文本数据提升细粒度区分能力 [17] - 指令微调阶段基于复杂多模态指令任务训练，增强模型的指令遵循能力和扩展性 [17] 图像-文本检索性能 - 在ShareGPT4V数据集上，UNITE 7B模型在文本到图像检索任务中达到93.3分，图像到文本检索任务中达到93.2分 [19] - 在Urban1K数据集上，UNITE 7B模型在文本到图像和图像到文本检索任务中分别达到95.5分和95.6分 [19] - 在DOCCI数据集上，UNITE 7B模型在文本到图像和图像到文本检索任务中分别达到87.2分和85.8分 [19] 视频-文本检索性能 - 在CaReBench基准的General子任务中，UNITE 7B模型在文本到视频检索的R@1指标达到86.0分，视频到文本检索的R@1指标达到86.9分 [22] - 在Spatial子任务中，UNITE 7B模型在文本到视频和视频到文本检索的R@1指标分别达到86.5分和84.8分 [22] - 在Temporal子任务中，UNITE 7B模型在文本到视频和视频到文本检索的R@1指标分别达到52.4分和55.4分 [22] 指令检索与综合评估性能 - 在涵盖分类、VQA、检索、定位四类任务的MMEB Benchmark中，UNITE 7B模型达到70.3的平均分，超越更大规模的模型 [23][25] - 在合成视频检索任务CoVR上，UNITE 2B和7B模型分别达到69.1和72.5分，显著领先于现有SOTA模型的60.1分 [23][24] - 在标准跨模态检索任务上，UNITE 7B在Flickr30K的文本到图像检索R@1达到86.1分，图像到文本检索R@1达到94.4分 [26][27] 关键数据发现 - 视频-文本对数据在所有配置中表现最为突出，不仅在视频检索任务中领先，甚至在图文检索任务中也超越基于图像-文本对训练的模型 [29] - 复杂检索指令跟随类任务更依赖文本主导的数据支撑，Text–Text数据提升语言理解能力，Text–Image数据提供精准的视觉语义映射 [30] - 在“检索适应”阶段直接融合细粒度视频-文本样本，能带来整体性能最优解，相比传统做法更加有效且高效 [30]

文章核心观点 智源研究院联合多所高校开发多模态向量模型BGE - VL，借助大规模合成数据MegaPairs训练，在多模态检索任务中取得最佳效果，MegaPairs数据具有优异可扩展性和卓越数据质量，BGE - VL模型性能表现优异 [1][2][7] MegaPairs构造 - 信息检索需满足多样化需求，现有多模态检索模型基于单一跨模态配对数据训练，难以处理复杂组合模态输入，以往多模态检索指令数据集依赖人工标注限制大规模多样化数据获取，智源BGE团队提出MegaPairs数据合成方法解决限制 [4] - MegaPairs从现有大规模图文语料库中挖掘并构造多模态检索指令数据集，构造分两个关键步骤，先挖掘多样图像对，再合成开放域检索指令，基于开源数据集和模型自动化构建和标注，可扩展性生成大规模、高质量且多样化数据集 [5][6] - MegaPairs结合多种模型在海量图文语料库中高效挖掘多模态三元组数据，算法能低成本持续生成多样化高质量数据，本次发布版本涵盖2600万条样本，仅需1/70数据量即可实现更优训练效果 [7] - MegaPairs合成超2600万条三元数据对，对每组挖掘的图像对数据选取其他相似图片作为难负例 [8] BGE - VL模型 - 基于MegaPairs数据集，智源BGE团队训练出3款不同尺寸多模态检索模型，仅用MegaPairs三元组数据训练就在多个任务上有领先性能优势 [9] - 在MMEB基准测试上，BGE - VL零样本性能表现优，MegaPairs未包含大部分任务类型数据却有良好泛化能力，有监督微调后平均性能指标比VLM2Vec (LLaVA - 1.6) 模型高9.1个百分点，在分布外数据集上平均表现比两版VLM2Vec分别高11.6%和7.1% [10][12] - 在组合图像检索评测集CIRCO上，BGE - VL各模型尺寸显著刷新现有基准，超越对比基线，BGE - VL - MLLM较之前SOTA模型提升8.1个百分点，BGE - VL - Base以不到1/50参数量超越大模型底座多模态检索器 [14] - 随着MegaPairs数据规模增加，BGE - VL模型性能增长，与Google MagicLens相比，MegaPairs仅需1/70数据规模即可实现显著性能优势 [15] 未来展望 智源将继续探索MegaPairs与更丰富多模态检索场景结合，打造更全能通用多模态检索器 [17]