首页 文章 精选 留言 我的

精选列表

搜索[VR 全景],共3932篇文章
优秀的个人博客,低调大师

AI 处理器全景指南

编者按: 当大模型的算力需求呈指数级增长,GPU 还是唯一答案吗?在 AI 硬件军备竞赛愈演愈烈的今天,是否存在更高效、更专精、甚至更具颠覆性的替代方案? 我们今天为大家带来的文章,作者的核心观点是:AI 硬件生态正在迅速多元化,除了广为人知的 CPU、GPU 和 TPU 之外,一系列新兴架构 ------ 如 ASIC、NPU、IPU、FPGA 乃至存内计算与神经形态芯片,正从不同维度重塑 AI 的算力未来。 文章系统梳理了三大经典处理单元(CPU、GPU、TPU)的原理与局限,并深入剖析了包括 Cerebras 晶圆级引擎、AWS Trainium/Inferentia、AMD APU、NPU 在内的专用芯片设计思路;进而拓展至 IPU、RPU、FPGA 等前沿架构,揭示它们如何针对稀疏计算、图神经网络、边缘推理或存算一体等特定场景提供突破性性能。 作者 | Ksenia Se and Alyona Vert 编译 | 岳扬 目录 01 CPU、GPU、TPU -- 三种核心硬件架构 1.1 中央处理单元(Central Processing Unit, CPU) 1.2 图形处理单元(Graphics Processing Unit, GPU) 1.3 张量处理单元(Tensor Processing Unit, TPU) 02 专用集成电路(Application-Specific Integrated Circuits, ASICs) 2.1 Cerebras 晶圆级引擎(Wafer-Scale Engine, WSE) 2.2 AWS Trainium 与 AWS Inferentia 2.3 加速处理单元(Accelerated Processing Unit, APU) 2.4 神经网络处理单元(Neural Processing Unit, NPU) 03 其他有前景的替代架构 3.1 智能处理单元(Intelligence Processing Unit, IPU) 3.2 阻变处理单元(Resistive Processing Unit, RPU) 3.3 现场可编程门阵列(Field-Programmable Gate Arrays, FPGAs) 04 新兴架构(Emerging Architectures) 4.1 量子处理器(Quantum Processors) 4.2 存内计算(Processing-in-Memory, PIM)与基于 MRAM 的芯片 4.3 神经形态芯片(Neuromorphic Chips) 05 结语(Conclusion) 如今连小孩子都知道 GPU(图形处理单元)是什么了 ------ 这得归功于 AI,也归功于英伟达(Nvidia),它始终在不遗余力地推进自家芯片的发展。当然,硬件既是绊脚石,也是推动模型运行及其技术栈的引擎。但为什么人们讨论的焦点只集中在 GPU 上呢?难道没有其他竞争者可能塑造 AI 硬件的未来吗?CPU 和 TPU 当然算 ------ 但仅此而已吗? 今天,让我们跳出 GPU 的思维茧房,将视线拓展到 GPU、CPU、TPU 这"老三样"之外。全球开发者一直在探索各类替代设计方案,每一种都承诺带来可观的效率提升和全新的创新路径。 我们希望能各位读者打造一份完整的 AI 硬件指南,因此先从这三大巨头讲起,再转向那些虽不主流却内有乾坤的方案:例如 Cerebras WSE 和 AWS 自研的定制 ASIC;还有 APU、NPU、IPU、RPU 以及 FPGA。我们会帮你厘清这些术语,让你全面掌握 AI 硬件的完整图景。这篇文章必将让你收获满满! 01 CPU、GPU、TPU -- 三种核心硬件架构 在探讨其他替代方案之前,先来剖析一下这些我们耳熟能详的 CPU、GPU 和 TPU 到底是什么。 这三大巨头都属于处理单元(Processing Units,简称 PUs) ------ 即专门用于执行软件程序指令、进行计算的电子电路。许多人称它们为计算机系统的"大脑"。PUs 执行各类算术、逻辑、控制以及输入/输出操作,将原始数据处理成有用的信息。 不同类型的 PU 针对不同的工作负载进行了优化 → 1.1 中央处理单元(Central Processing Unit, CPU) 中央处理单元(CPU)专为通用计算和顺序任务执行而设计。 CPU 是三者中最古老的。其前身的故事始于 1945 年 ------ 约翰·莫奇利(John Mauchly)与 J. 普雷斯珀·埃克特(J. Presper Eckert Jr.)推出了 ENIAC(Electronic Numerical Integrator and Computer)。这是世界上第一台可编程、电子式、通用型的数字计算机,能通过重新编程解决多种数值问题,使用了约 18,000 个真空管。 同年,约翰·冯·诺依曼(John von Neumann)发表了《First Draft of a Report on the EDVAC》,提出将数据和指令存储在同一内存中。这一"存储程序"模型成为现代 CPU 的设计蓝本。 到了 1950 年代中期,真空管被晶体管取代。从那时起,处理器开始由大量基于晶体管的元件组成,并安装在电路板上,使计算机变得更小、更快、更省电。 1960 年代,集成电路(ICs)出现,将多个晶体管集成到单块硅片上。最终在 1971 年,英特尔(Intel)推出了 4004 ------ 全球首款商用微处理器,即一颗集成在单一芯片上的 4 位 CPU。这标志着现代 CPU 的真正诞生。 Intel 8086 是如今 x86 CPU 架构的始祖,而目前提升效率的主流方案则是多核处理器 ------ 将多个 CPU 核心集成在单一芯片上。 那么,现代 CPU 内部究竟包含什么?它们又是如何工作的? CPU 的核心是控制单元(control unit),它包含复杂的电路,通过发出电信号来控制整台计算机,并将数据和指令引导至正确的位置。算术逻辑单元(ALU)负责执行数学与逻辑运算,而寄存器(registers)和高速缓存(cache)则提供了极小但极快的存储空间,用于存放处理器频繁需要的数据。 Image Credit: Wikipedia CPU 还包含核心(cores) ------ 即 CPU 内部的处理单元,每个核心都能独立处理指令;以及线程(threads),允许一个核心同时处理多条指令流。这些组件都按照时钟信号(clock)的节拍运行,时钟提供了同步整个系统所需的节拍。此外,还有总线(buses,用于数据传输)、指令寄存器(instruction register)和指令指针(instruction pointer,用于追踪下一步要执行的内容)等辅助组件,将整个系统紧密连接,使指令能顺畅地从一个步骤流转到下一个。 CPU 的工作遵循一个简单却强大的循环:取指(fetch)→ 译码(decode)→ 执行(execute) 。 它从内存中取指数据或指令, 将它们译码为硬件能理解的信号, 然后执行所需的操作(例如计算、数值比较,或将数据发送到其他地方)。 在现代处理器中,这一过程每秒可发生数十亿次,多个核心与线程并行工作提升性能,使 CPU 如同一个高度协同的组件团队。CPU 核心数量较少(例如 1 到 2 个)时,通常更注重能效(即单位功耗下完成更多有效工作),适合轻量或日常任务,而核心数量较多的 CPU 则用于支撑高性能、高负载的任务。 如今的 CPU 主要来自以下厂商: Intel,产品包括 Core 系列(消费级)、Xeon(服务器/工作站)、Pentium 和 Celeron(入门级)芯片; AMD,提供 Ryzen(消费级/高性能)和 EPYC(服务器)处理器,以及 APU(Accelerated Processing Unit),它将 CPU 和 GPU 集成在同一颗芯片上(我们稍后会详细讨论)。 CPU 用于 AI 时面临的主要问题是:它针对的是顺序执行的通用任务,而非大规模并行的矩阵运算,因此在速度和能效上远逊于 GPU 或专用芯片。 接下来,让我们转向介绍第二款芯片 ------ 著名的 GPU。 1.2 图形处理单元(Graphics Processing Unit, GPU) 图形处理单元(GPU)专为高吞吐量的大规模并行数据处理而优化。GPU 最初被发明用于加速图像和视频中的计算机图形渲染,但后来人们发现它在非图形计算任务中同样大有用武之地。如今,GPU 被广泛应用于可并行化的工作负载,例如处理数据密集型任务和训练 AI 模型。 如今,GPU 是推动 AI 性能提升的核心力量,也是衡量 AI 计算能力的一项关键指标。 "图形处理单元"(GPU)这一术语由 NVIDIA 于 1999 年正式提出,随 GeForce 256 显卡一同发布。NVIDIA 称其为全球首款 GPU,其官方定义为:"集成变换、光照、三角形设置/裁剪及渲染引擎的单芯片处理器。" 那么,这款传奇的 GPU 究竟是如何工作的?→ GPU 内部是一块硅芯片,上面蚀刻着数十亿个微型晶体管,被组织成数千个轻量级处理核心。这些核心通过复杂的布线相互连接,并由高带宽内存和缓存提供支持,使数据能在核心之间高速流动。整个芯片被封装在保护材料中,并配有散热系统来维持稳定运行。 (了解芯片历史的最佳读物之一是克里斯·米勒(Chris Miller)所著的《芯片战争:世界最关键技术的争夺战》(Chip War: The Fight for the World's Most Critical Technology),强烈推荐。) 与 CPU 不同,GPU 专为并行计算而生 ------ 它会将一项大型任务拆分成成千上万个更小、彼此独立的子任务,并将它们分发到各个核心上同步计算。正因如此,GPU 非常适合训练和运行 AI 模型,因为这些模型涉及对海量数据集进行重复的矩阵与张量运算。得益于 GPU 的并行架构,原本需要数月的训练如今几天就能完成,推理速度也足以支撑实时应用 ------ 比如聊天机器人。 全球 GPU 生产的领军者是 NVIDIA,它打造了完整的并行计算平台 CUDA(Compute Unified Device Architecture),将 GPU 硬件能力释放到通用计算领域,大幅降低了 GPU 编程的门槛。 NVIDIA 面向 AI 基础设施和行业应用的主要 GPU 产品包括: V100(Volta 架构) -- 专为深度学习加速而设计,首次引入 Tensor Core(张量核心) ------ 专用于加速 AI 训练中矩阵运算的硬件单元。 A100(Ampere 架构) -- 拥有更多 Tensor Core、更高内存带宽,并支持多实例 GPU(MIG)技术,可将一块物理 GPU 划分为多个逻辑 GPU,提升资源利用效率。 H100、H200(Hopper 架构) -- 当前 AI 领域的行业标准。H 系列支持 Transformer Engine、超大内存带宽,以及极致的训练与推理速度。 图片来源:NVIDIA H100 NVL GPU 产品文档 Blackwell(例如 B200 和 GB200 Grace-Blackwell "超级芯片") 专为下一代拥有数万亿甚至十万亿级参数的 AI 模型而设计。作为 Hopper 架构的继任者,它引入了 FP4 精度,并在推理吞吐量上实现了大幅提升,尤其针对超大规模 Transformer 工作负载。 随着行业对 AI 专用处理器的需求日益增长,第三类核心硬件 ------ TPU 应运而生。 1.3 张量处理单元(Tensor Processing Unit, TPU) 张量处理单元(TPU)是由 Google 专为加速神经网络运算(尤其是矩阵乘法与机器学习工作流)定制的芯片。它最初在 2016 年 Google I/O 大会上亮相,属于 ASIC(Application-Specific Integrated Circuits,专用集成电路)类别。TPU 的基本架构如下: 图片来源:论文《In-Datacenter Performance Analysis of a Tensor Processing Unit》 其核心组件是矩阵乘法单元(Matrix Multiply Unit) ------ 一个巨大的 256×256 乘加单元(MAC)阵列,采用脉动阵列(systolic array)结构,数据以"波"的形式在网格中流动。 TPU 还配备了大容量片上存储器: <!-- --> 统一缓冲区(Unified Buffer,24 MB):用于存放中间激活值; 权重存储器/ FIFO(Weight Memory/FIFOs):用于存储神经网络权重; 累加器(Accumulators,4 MB):用于收集求和结果。 控制逻辑、PCIe 接口和激活单元(用于 ReLU、sigmoid 等函数)为矩阵引擎提供支持,但芯片的大部分面积都用于原始计算和高速数据传输。 TPU 的主要特点是作为协处理器工作: 主机 CPU 通过 PCIe 向 TPU 发送指令,TPU 直接执行这些指令。 其指令集非常精简(仅约十几条指令),硬件通过流水线设计确保矩阵单元始终处于忙碌状态。 像 TensorFlow 这样的框架会将模型编译成这些底层指令。 256 个小型片上存储器(分布式累加器 RAM)用于收集部分和,而脉动阵列则执行乘加(MAC)运算。通过将权重和数据持续流入脉动阵列,并在片上缓冲区中本地复用,TPU 最大限度地减少了对片外内存的访问。因此,大部分计算任务(逐层进行)都能直接在芯片上完成。 图片来源:论文《In-Datacenter Performance Analysis of a Tensor Processing Unit》 总结来说,TPU 中的每个单元执行小规模计算,并将部分结果传递下去,从而节省功耗,并极大加快 AI 模型背后的数学运算速度。 这正是 TPU 在相同任务中能实现高吞吐量,同时功耗远低于 CPU/GPU 的原因。根据 Google 2017 年的分析,TPU 在能效比(每瓦性能)上比同期 CPU 和 GPU 高出约 30--80 倍(在推理任务中,拿 TPU 和 K80 这类 GPU 做能效对比)。 然而,仅靠这三种硬件(CPU、GPU、TPU),我们仍无法全面理解驱动 AI 发展的全部技术力量。因此,我们还需梳理整个领域还有哪些技术可供选择。由于 TPU 属于 ASIC 类 AI 芯片,我们将从这一类别出发,探索更多强有力的替代方案。接下来,让我们来深入看看它们如何构想未来 → 02 专用集成电路(Application-Specific Integrated Circuits, ASICs) ASIC 是完全定制的硅芯片,专为某一种特定的 AI 工作负载而设计。这类芯片既包括云服务巨头的自研芯片,也涵盖初创企业打造的专用 AI 硬件。在这一领域,我们不得不提及...... 2.1 Cerebras 晶圆级引擎(Wafer-Scale Engine, WSE) Cerebras 将未来押注于晶圆级芯片。其最新款 Cerebras WSE-3 芯片实际上是史上尺寸最大的 AI 芯片之一 ------ 面积高达 46,255 mm²。其核心技术在于:Cerebras 将整片硅晶圆直接制成一颗芯片,而不是像传统 CPU 或 GPU 那样将晶圆切割成数百个小处理器。 WSE-3 包含 4 万亿个晶体管、90 万个专为 AI 优化的核心,以及 44 GB 片上 SRAM 内存。每个核心都配备有独立的本地内存,并通过横跨整个晶圆的超高带宽互连网络(fabric)彼此连接,从而大幅缩短计算单元与内存之间的距离。 图片来源:Cerebras Wafer-Scale Engine (WSE) 产品手册 Cerebras 的晶圆级理念带来了令人瞩目的成果: 单颗 WSE-3 可提供 125 petaFLOPS 的 AI 算力。 据 Cerebras 声称,将 WSE-3 组合成晶圆级集群(Wafer-Scale Cluster, WSC),并集成 MemoryX(用于存储超大模型权重的片外存储)和 SwarmX(用于在节点间广播权重并聚合梯度),即可高效支持数万亿参数模型的训练,且几乎能随硬件规模线性提升性能,同时规避传统 GPU 集群中复杂的通信开销。 目前有哪些模型已在 Cerebras WSE 上运行? 以下是两个典型示例: 1)阿里巴巴的 Qwen3 Coder 480B Instruct,推理速度达到 每秒 2,000 个 token。 2)混合专家模型(Mixture-of-Experts, MoE):Cerebras 使其大规模训练变得更加简单高效。这类模型可在单个设备上完成训练,无需模型并行(而使用 GPU 时通常必须依赖模型并行)。Cerebras 采用的注意力批处理分块(Batch Tiling on Attention, BTA)技术,解决了稀疏 MoE 模型的计算效率问题 ------ 它将注意力层与专家层的批处理需求解耦:注意力层在较小的"分块"(tiles)上运行,以降低内存压力;专家网络则处理更大的有效批次,确保其核心始终处于高利用率状态。 由此可见,这是一项以规模制胜的强大技术。 2.2 AWS Trainium 与 AWS Inferentia 亚马逊同样推出了突破 GPU 垄断的替代方案,并形成了自己对高效硬件的独特构想。其两款自研芯片专为 AI 工作负载设计,并深度集成于 AWS 生态系统之中。 AWS Trainium 专用于模型训练,AWS Inferentia 则面向推理任务。这两款芯片内部均采用定制的 NeuronCore、高带宽内存(HBM),以及用于张量运算、集合通信和稀疏性加速的专用引擎。 配备 64 颗 Trainium 2 芯片的 Trainium 2 UltraServer 服务器,在处理稀疏模型时,最高可提供 83.2 petaflops 的 FP8 算力;在处理稠密模型时,FP8 算力约为 20.8 petaflops。相比之下,单颗 NVIDIA H100 GPU 的 FP8 算力大约只有 4 petaflops。 AWS Inferentia 2 支持大规模部署大语言模型(LLM)和扩散模型(diffusion models),其每瓦性能比基于 GPU 的同类 EC2 实例(例如 G5 系列)提升约 50 %。 因此,AWS 硬件为生成式 AI 的需求提供了在规模、性能与成本效益三者之间高度平衡的解决方案。 在了解了这些定制化的高效 ASIC 的案例后,我们再回到那些名字中带有 "..PU" 的硬件新锐。接下来是...... 2.3 加速处理单元(Accelerated Processing Unit, APU) 如前文所述,AMD 开发了一种混合型处理单元架构,将 CPU 与 GPU 的能力融合进单一芯片封装中,由此诞生了加速处理单元(APU)。这种设计消除了在独立处理器之间来回传输数据所带来的性能瓶颈。 迄今为止,该理念的最大代表作是 AMD Instinct MI300A。它集成了 24 个 "Zen 4" CPU 核心、228 个 GPU 计算单元,以及高达 128 GB 的 HBM3 内存。 其内部采用 AMD 的 chiplet(小芯片)与 3D 堆叠技术打造。MI300A 的内存能够在 CPU 和 GPU 之间共享,峰值带宽高达 5.3 TB/s。其多芯片架构通过 chiplet 与裸片堆叠,将 CPU 和 GPU 计算单元紧邻高带宽内存布置,并由 AMD 的 Infinity Fabric 与 Infinity Cache 统一互联。此外,该芯片全面支持主流 AI 数据格式,并具备硬件级稀疏性加速能力。 图片来源:AMD INSTINCT™ MI300A APU 产品手册 那么问题来了:既然可以拥有"一体式引擎",又何必在 CPU 和 GPU 之间做选择? NVIDIA 也在其 NVIDIA Grace Hopper Superchip 中践行了类似理念 ------ 这是一款统一模块,将基于 Arm 架构的 Grace CPU 与 Hopper GPU 通过 NVIDIA 自研的 NVLink-C2C 芯片间互连技术紧密耦合。其核心优势与 AMD MI300A 高度一致: CPU 与 GPU 线程可直接访问彼此的内存, 能够执行原子操作, 并实现更高效的同步管理。 NVIDIA 表示,Grace Hopper Superchip 在图神经网络(GNN)训练上,速度比通过 PCIe 互联的 H100 GPU 快最多 8 倍;在嵌入向量(embedding)生成任务上,比纯 CPU 方案快约 30 倍。 然而,这种 CPU 与 GPU 的融合也带来了更高的功耗、更低的灵活性以及更复杂的制造工艺。 接下来,我们将转向一些更小巧的硬件类型。 2.4 神经网络处理单元(Neural Processing Unit, NPU) 你可以想象一下,在一颗普通芯片内部专门内置一个用于 AI 任务的加速器 ------ 这也正是神经网络处理单元(NPU)的核心理念。NPU 本质上是现代芯片中专为运行 AI 工作负载而打造的小型引擎,用于处理神经网络、图像与语音识别,甚至本地运行的大语言模型(LLM)。通过模拟人脑神经网络架构,NPU 针对 AI 工作负载的计算模式进行专门优化:大量矩阵乘法、激活函数运算,以及在极低功耗下实现高速数据移动。 以下是一些我们如今能在各种设备中实际找到的 NPU 示例: 高通(Qualcomm)Snapdragon 芯片中的 Hexagon NPU,为智能手机、汽车、可穿戴设备等提供 AI 功能支持。 Apple Neural Engine:首次亮相于 2017 年的 A11 Bionic 芯片,如今已集成于所有搭载 Apple Silicon 的 iPhone、iPad 和 Mac 中,用于驱动 Face ID、图像处理和 Sir 等功能。 英特尔 NPU(搭载于新一代酷睿 Ultra AI PC 处理器,如 Lunar Lake、Arrow Lake),专为在本地运行 Windows Copilot+ 功能而设计。 AMD 的 XDNA / XDNA 2 NPU:出现在面向笔记本的 Ryzen AI 处理器中,AI 性能高达 55 TOPS。 NPUs 非常适合端侧推理,但尚不足以用于训练大语言模型或运行极高负载的任务。 此外,它们也无法取代 CPU 或 GPU 来执行通用计算任务。 如果你运行的不是神经网络类负载,NPU 甚至无法正常发挥作用。正是这种高度专精的特性,使 NPU 在众多"PU"中独树一帜。 03 其他有前景的替代架构 3.1 智能处理单元(Intelligence Processing Unit, IPU) Graphcore 开发的 IPU 是一款具备 1,472 个独立处理器核心的大规模并行处理器,可同时运行近 9,000 个并行线程,并紧密耦合 900 MB 高速片上内存。这意味着数据可以在存储位置直接被处理。IPU 专为机器学习工作负载设计,凭借极高的细粒度并行能力和片上内存架构,它在图计算方面表现出色,能够通过并行处理图中各个节点上的操作,高效应对不规则且稀疏的工作负载。 图片来源:Graphcore IPU 博客,《Colossus™ MK2 GC200 IPU》 3.2 阻变处理单元(Resistive Processing Unit, RPU) RPU 是一种实验性的存内计算(in-memory compute)单元,利用阻变存储器(如忆阻器 memristor 或 RRAM)直接在内存阵列中执行矩阵运算。这种方法极大减少了数据搬运,有望显著降低能耗与延迟。2025 年,IBM 研究人员展示了基于 ReRAM 的模拟存内 AI 加速器,支持片上训练与推理,具备低电压开关特性和多比特存储能力。 3.3 现场可编程门阵列(Field-Programmable Gate Arrays, FPGAs) FPGA 在可重构 AI 领域具有重要地位,尤其适合需要完全掌控并行性、内存和延迟的场景。与 GPU 或 ASIC 不同,我们可以根据模型的具体需求定制 FPGA 的硬件逻辑,并在架构变更后重新编程。 典型案例如 AMD Versal™ AI Edge 系列 Gen 2,它属于 AMD 的自适应 SoC(System-on-Chip)家族。该芯片在传统 FPGA 可编程逻辑的基础上,进一步在同一裸片上集成了 Arm CPU 和专用 AI 引擎。 04 新兴架构(Emerging Architectures) 4.1 量子处理器(Quantum Processors) 量子芯片使用量子比特(qubits),而非经典比特,利用叠加(superposition)与纠缠(entanglement)等量子特性进行计算。目前,它们正被用于优化、搜索和模拟等任务领域的测试 ------ 这些领域在理论上有望借助量子力学实现指数级加速。然而,量子比特仍然极其脆弱且易受噪声干扰,因此当前的量子计算机仅能处理"玩具级"问题。就现阶段而言,它仍是一个长期的"登月计划",尚无法替代 GPU 或 ASIC。 4.2 存内计算(Processing-in-Memory, PIM)与基于 MRAM 的芯片 AI 面临的一大瓶颈在于内存与计算单元之间的数据搬运。PIM 技术将计算逻辑直接集成到内存阵列中,从而大幅减少这种来回传输。MRAM(磁阻随机存储器)是一种前景广阔的非易失性存储技术,能够支持这一范式转变,助力打造更高密度、更节能的 AI 加速器。三星等大厂以及 Mythic 等初创公司已开始试验相关原型。PIM 并非科幻概念 ------ 未来十年内有望实际进入数据中心与边缘设备。 4.3 神经形态芯片(Neuromorphic Chips) 神经形态处理器受人脑脉冲神经元(spiking neurons)启发。与传统依赖密集的、时钟驱动的矩阵乘法不同,它们采用稀疏的、事件驱动的脉冲信号进行计算。例如 Intel 的 Loihi 和 IBM 的 TrueNorth,目标是在传感器、物联网(IoT)和机器人等场景中实现超低功耗的智能。其主要挑战在于:脉冲神经网络(SNN)仍处于早期阶段。尽管神经形态硬件在低功耗边缘 AI 领域潜力巨大,但尚不确定它能否扩展至像大型 Transformer 这类的主流工作负载。 05 结语(Conclusion) 总体而言,各类硬件的定位如下: CPU(中央处理单元)------通用处理器。 GPU(图形处理单元)------专为并行图形计算/数学计算优化。 TPU(张量处理单元)------Google 的 AI 加速器。 ASICs(专用集成电路)------为特定 AI 工作负载定制的芯片。 APU(加速处理单元)------AMD 的 CPU + GPU 融合架构。 NPU(神经网络处理单元)------专为端侧 AI/ML 推理优化的小型芯片。 IPU(智能处理单元)------提供极高细粒度的并行性与片上内存架构。 RPU(阻变处理单元)------基于阻变存储器的存内计算单元。 FPGAs(现场可编程门阵列)------支持对并行性、内存和延迟的完全控制。 由此可见,如今"PU"家族选项丰富,GPU 之外也涌现出多种替代方案,这使得硬件生态呈现多样化的态势,并为未来多方向的突破敞开大门。近期,多家科技巨头纷纷宣布正在研发新一代硬件:NVIDIA 正在推进 Rubin 架构,Meta 在测试自研芯片,阿里巴巴及其他中国公司也在开发 AI 推理芯片,以构建自主的硬件生态。这意味着更多全新的技术栈将陆续登场。 若跳出 GPU 和 CPU 的传统框架,我们能清晰看到一个趋势:AI 硬件市场正加速碎片化,各大厂商都在推动各自的软硬一体化生态。 这对开发者和企业而言,既是机遇,也是挑战 ------ 如何在不断扩张的硬件版图中,有效应对兼容性、软件支持与成本效益等问题,将成为未来的关键课题。 END 本期互动内容 🍻 ❓AI 硬件生态正加速碎片化,你认为未来是"一超多强"还是"百花齐放"? 原文链接: https://www.artificialintelligencemadesimple.com/p/inside-the-ai-hardware-race-guest

优秀的个人博客,低调大师

2026 多模态架构选型全景指南

## 引言:你的"文本模型 + 外挂视觉"系统,正在变成技术债 2026 年 2 月,Qwen 团队做了一个当时没引起足够注意的决定:视觉能力并入主线,-VL 系列停止迭代。此后发布的 Qwen3.5、3.6、3.8 全部是 image-text-to-text 的统一模型。官方模型卡里那句话说得非常直白——"统一视觉-语言基础模型,多模态 token 早期融合训练,跨代达到与 Qwen3 纯文本对齐的水平,且在推理/编码/Agent/视觉理解基准上超过 Qwen3-VL"。 一个以视觉子模型闻名的产品线,亲手给自己画了句号。这不是孤例。Gemini 3 把"所有模态映射到同一表征空间"写进了架构叙事;GLM-5.3-Flash 以 320B 总参/18B 激活的 MoE 体量开源了原生多模态底座。中外两大阵营,在"early fusion 统一底座"这件事上形成了罕见共识。 对架构师来说,这意味着一个不太舒服的推论:如果你现在的新项目还在按"文本 LLM + 外挂视觉编码器 + 中间胶水层"设计,这套系统大概率活不过下一次大版本升级。独立视觉模型正在失去迭代动力——过去十个月里,头部模型厂商没有一个在往"独立视觉模型"方向投入新算力,投入全部涌向了统一底座。 但换底座只是故事的开始。视觉融进底座之后,部署经济学变了(一张 24GB 显卡能跑 27.8B 的原生多模态旗舰)、计费模型变了(视觉"零溢价"正在成为新默认)、能力兑现路径也变了(多模态的商业价值不在"看图说话",而在"看屏幕干活")。这篇文章把 2026 年 8 月底这波发布潮里值得架构师认真对待的事实全部摊开:early fusion 到底改变了什么、API 与私有化的 TCO 怎么算、GUI Agent 落地的真实口径、多模态 RAG 的"上不上"红线,以及一份可以直接抄进架构评审的治理 checklist。截至 2026 年 9 月初,文中所有数据均可追溯到原始发布信息,个别单一来源数据已明确标注。 --- ## 一、三个信号:巨头们在同一件事上"意外"合流 判断一个技术趋势是真拐点还是伪热点,最省力的办法是看竞争双方是否在暗中做了同一个选择。2026 年上半年,三个来自不同阵营的信号指向了同一个结论。 **信号一:Qwen 砍掉了 -VL 产品线。** 从 3.5 开始,视觉不再是独立分支而是主线的默认属性。到了 8 月 14 日发布的 Qwen3.8-27B,这已经不是产品策略问题,而是工程事实:27.8B 稠密参数、原生多模态、24GB 显卡可跑、Apache 2.0 协议。它在 OSWorld-Verified 上拿到 84.3 分——这个数字的分量后面 GUI Agent 一章会展开,先说一句结论:全面第一,超过 GPT-5.4 的 75 和 Claude Opus 4.6 的 72.7。 **信号二:Gemini 把统一表征写进架构叙事。** Gemini 3(2025 年 11 月 18 日发布)以 1501 的 LMArena Elo、MMMU-Pro 81%、Video-MMMU 87.6% 站稳了第一梯队,而它对外的架构表述是"所有模态映射到同一表征空间"。这句话的工程含义比听起来激进:不存在"先过视觉编码器再拼给语言模型"的转换损耗问题,模态在底层就是同一种东西。 **信号三:GLM-5.3-Flash 开源了原生多模态。** 8 月 26 日发布,320B 总参/18B 激活的 MoE,注意力计算量降 3 倍、KV 缓存降 4.4 倍,1,048,576 token 上下文,价格 $0.15/$0.50(输入/输出每百万 token)——约为同级闭源旗舰的十分之一。在 AA 智能指数上它拿到 57,超过 Gemini 3.7 Flash 的 56。一个原生多模态模型以这个价格和许可证姿态出现,本身就是一份宣言。 三个信号背后还有一层容易被忽略的含义:**早期融合不再是能力妥协的代名词**。历史上"统一模型"的隐忧是——为了塞进多种模态,单项能力会被稀释。Qwen3.5 模型卡的表述直接回应了这个隐忧:统一模型在推理、编码、Agent、视觉理解四个维度上全面超过此前的专项视觉模型 Qwen3-VL,且文本能力对齐同代纯文本模型。换句话说,融合的代价没有被转移到能力上,而是被架构演进(混合注意力、MoE 稀疏激活)消化掉了。这是"外挂路线还有没有存在必要"这个问题的最终答案。 再看时间密度。Qwen3.5 到 Qwen3.8 之间只隔了半年左右,每一代都是 image-text-to-text 的统一底座,中间没有出现任何"视觉专项模型"的回潮。产品线的连续性比单点性能更能说明路线的决心——团队级的工程投入一旦转向,掉头成本极高,这本身就是可信度。 三个信号叠起来,指向的判断是:**独立视觉模型将在 12 个月内失去迭代动力**。这不是预测某个具体产品的死亡时间,而是观察资源流向的结果——当所有头部团队的训练算力都压在统一底座上,"文本模型 + 外挂视觉"路线能拿到的迭代带宽会持续萎缩,直到某天你发现依赖的视觉编码器已经一年没更新了。 顺带一提这波合流的注脚:Meta 的 Muse Glimmer(30B)8 月 10 日发布,四天后就被 Qwen3.8-27B 全面超越——Terminal-Bench +21.3、SWE-bench Pro +10.5、OSWorld +18.4。开源多模态的迭代速度已经快到"发布即被超"的程度,这既是机会(能力红利持续释放),也是风险(你追的任何一个版本都可能是短期峰值)。 对架构师的直接影响只有一个:**新项目应默认按"统一多模态底座 + 模态特化产品矩阵"设计,而不是"文本底座 + 视觉外挂"**。存量系统的迁移问题,第七章会给路线图。 --- ## 二、Early Fusion 到底改变了什么:从管线架构到成本曲线 "早期融合"这个词容易被当成又一个营销话术。但它对系统架构的改变是实打实的,主要在三个层面。 **第一层:管线的消解。** 过去做多模态应用,你的系统里必然有一串级联组件:VAD(语音活动检测)→ ASR → LLM → TTS,视觉侧则是视觉编码器 → 投影层 → 语言模型。级联架构的致命伤是累积延迟——每一级都要等上一级输出完整结果。以实时语音场景为例,级联架构的累积延迟普遍在 1.8 到 5 秒之间。字节 8 月 5 日在豆包全量上线的 SeedRealtime 选择了另一条路:端到端单模型内生建模,轮次切换由模型内部处理而非外部 VAD 判断,嘈杂环境语音识别做到 92%。需要说明的是,SeedRealtime 目前是产品内可用、无 API、无权重、无公开基准,无法独立验证,只能作为路线信号而非选型依据——但这个信号本身足够响亮:**端到端对级联的替代,已经从论文走进了日活产品的生产环境**。 ![级联多模态架构与端到端原生多模态架构的对比.png](https://developer.qcloudimg.com/http-save/yehe-7660620/4487f6893f2afd8f602cb73b0f46f3ca.png) **第二层:长上下文的成本结构。** 多模态天然是上下文大户——一张高分辨率截图动辄几千 token。早期融合模型这波在注意力机制上做足了文章:Qwen3.8-27B 用 Gated DeltaNet 线性注意力与门控全注意力按 3:1 混合(64 层),原生 256K 上下文经 YaRN 扩展到 1M;GLM-5.3-Flash 把注意力计算量降 3 倍、KV 缓存降 4.4 倍。这些数字的选型含义是:**多模态长上下文正在从"能不能"变成"贵不贵"**,而"贵不贵"的答案每季度都在改善。当你的视觉 Agent 需要盯着一个屏幕连续操作几十步、每步都带高分辨率截图时,KV 缓存降 4.4 倍不是优化项,是可行性前提。 **第三层:定价的收敛。** 模态融合进底座后,视觉 token 的边际成本趋近文本,定价必然跟着收敛。看三个数据点:DeepSeek-V4-Flash-Vision-Exp(8 月 21 日)视觉能力不加价,沿用 V4 Flash 的 $0.44/$1.32 费率(谷时五折);GLM-5.3-Flash 的 $0.15/$0.50;视频侧 Wan 2.6 开源模型 $0.05/秒对标 Sora 2 的 $0.10/秒。"视觉溢价"这个在 2024 年还被写进无数成本测算的科目,正在被快速抹平。 这对架构师有一个非常具体的行动项:**把你团队过去一年因"视觉 token 成本"被否决的需求清单翻出来重新评估一遍**。当时算不过来的账,按现在的费率很可能已经是另一番结果。反过来,供应商格局也可能在 12 个月内洗牌——Anthropic 的 Opus 4.1 已经在 8 月 5 日退役,价格战打起来之后,押注单一供应商的系统的重写成本会集中暴露。 把成本曲线再往下拆一层,能看到结构性原因。早期融合模型这波普遍采用 MoE 加线性注意力的组合拳:GLM-5.3-Flash 用 320B 总参但只激活 18B,推理的边际成本只跟激活参数挂钩,跟"模型懂多少模态"关系不大——这是视觉零溢价能成立的架构基础。DeepSeek-V4-Flash-Vision-Exp 的做法更直接:视觉能力作为实验特性挂载到 V4 Flash 的费率上($0.44/$1.32,峰时价,谷时五折),还提供三种 API 格式、三种图片传入方式,摆明了是让开发者无成本试水。这些定价动作的共同点在于:**视觉 token 的计价单位正在向文本 token 靠拢,"多模态预算"作为独立科目正在失去存在的理由**。你 2025 年做的三年成本模型,如果里面还有"视觉 token 单价是文本 3 倍"这类假设,现在应该重做。 还有一条经常被忽略的技术红利:早期融合让**模态联合推理**成为可能。最典型的例子是 GUI Agent——当用户说"点那个'确认'按钮"时,模型需要同时看屏幕画面和听用户语音,画面能消解"确认"这个词的同音歧义。级联架构里 ASR 只能瞎猜一个转写结果,端到端模型则在统一表征空间里直接联合推断。这类"模态互相救场"的场景,是级联架构结构上做不到的,也是早期融合最深层的价值。 --- ## 三、部署决策树:API 还是单卡私有化,这道题的题干变了 "私有化部署多模态模型"在过去意味着什么?意味着要么接受能力妥协(开源视觉模型与闭源旗舰差距明显),要么准备一屋子 A100/H100。2026 年 8 月之后,这道题的题干变了。 Qwen3.8-27B 给出了一个此前不存在的组合:**旗舰级多模态能力 + Apache 2.0 + 消费级硬件**。27.8B 稠密模型在 24GB 显卡上可跑,Unsloth 4-bit GGUF 量化版约 17GB;部署路径 vLLM 与 llama.cpp 双支持,前者面向吞吐、后者面向端侧。它的基准面也撑得住"旗舰"二字:OSWorld-Verified 84.3(全面第一)、WebArena 64.8、AndroidWorld 81.9,SWE-bench Pro 61.7 超过 Claude Opus 4.6 Max 的 53.4。开源生态的势能还在放大——Qwen 在 Hugging Face 月下载 1.536 亿次,超过第二到第九名的总和;全球累计下载超 30 亿次、衍生模型 30 万+、占 HF 总下载量 50% 以上。月下载量是工程问题被解决程度的间接指标:踩过的坑越多、社区修复越多,你的部署越顺。 这个组合直接改写了金融、医疗等数据敏感行业的多模态落地路径:**私有化不再意味着能力妥协**。过去被迫在"能力够但数据出域"和"数据安全但能力拉胯"之间二选一的团队,现在有了第三条路。 但把决策树画出来,会看到这条路的分支并不少: ![多模态模型部署方式选型决策树.png](https://developer.qcloudimg.com/http-save/yehe-7660620/1da635061288e09c3760074ac5a5e9bf.png) 决策树里埋着几个必须展开说的坑。 **坑一:Blackwell 上的 FP8。** Qwen3.8-27B 官方 FP8 权重在 Blackwell 架构 GPU 上启用 MTP(多 token 预测)投机解码时存在兼容问题,需要社区修复版(huggingface 上的 huginnfork)才能正常用。MTP 能带来 15–25% 的推理提速,这意味着"为了新卡反而丢了投机解码"是个真实存在的性能陷阱。买卡之前先确认权重矩阵,这条要写进采购评审。 **坑二:TCO 的算法。** API 按量计费、私有化按固定成本摊销,两者的交叉点取决于你的调用量。这里不给具体数字(显卡采购价、电费、机房成本因人因时而异),但给计算框架:私有化侧的成本 = 硬件摊销 + 运维人力 + **升级带宽**。最后一项最容易被低估——开源模型迭代速度已经快到"发布即被超"(Muse Glimmer 四天被超的案例就在眼前),私有化意味着每次能力升级都要你自己重新部署、重新评测、重新过一遍回归测试。API 侧的隐性成本则是:计费口径漂移(Opus 4.7 换新分词器后 token 数是旧版的 1.0–1.35 倍,同一份输入的账单可能凭空多三成)和供应商退役节奏(Opus 4.1 已退役)。**把"计费口径漂移"当成 API 的 TCO 组成部分来算,很多"API 更便宜"的结论会动摇。** 决策树之外,自托管侧还有几个工程事实需要进部署文档。其一,MTP(多 token 预测头)投机解码带来 15–25% 的提速,但这个收益建立在权重与硬件匹配的前提下——上一节说的 Blackwell 兼容问题就是典型反例。其二,稠密 27.8B 与 MoE 架构的选型权衡在单卡场景下并不对称:稠密模型对批量大小更友好、推理行为更可预测,这也是 Qwen3.8-27B 选择稠密而非 MoE 的现实理由之一;而 GLM-5.3-Flash 那种 320B/18B 的 MoE 走的是 API 侧规模换质量的路线,两者服务的是不同部署形态,不能直接比参数量。其三,上下文长度的实际可用性要实测——Qwen3.8-27B 原生 256K、YaRN 扩展到 1M,但"扩展"档位的长上下文质量与原生档存在差距,多模态长会话(比如连续几十步的 GUI 操作轨迹)落在哪个区间,要在你自己的评测集上验证,不能只看模型卡数字。 **坑三:供给集中度。** Meta 转闭源(Muse Spark)之后,开源多模态旗舰的供给高度集中于中系模型。这是事实陈述而非立场判断,但它应该出现在你的架构评审风险页上:许可证政策、出口管制、地缘因素,任何一个变量都可能影响你依赖的那个开源权重的后续迭代。对冲方式是保持部署层与模型层的解耦——vLLM 这类推理框架的价值在供应链风险场景下会被重新定价。 一个可以参考的务实策略:**双路径验证**。新能力先打闭源 API 验证业务价值(快、便宜、随时可换),验证通过后再评估是否值得为数据合规或长期成本迁到自托管开源旗舰。反过来做(先建私有化基建再找场景)在当前迭代速度下是踩坑重灾区——基建建好的那天,模型可能已经落后两代。 --- ## 四、GUI Agent 进入生产:多模态的"真金白银"不在看图说话 如果说前两章是架构层面的"道",这一章是兑现层面的"术"。多模态能力的商业价值,2026 年最清晰的兑现路径不是文生图、不是看图问答,而是 **GUI Agent(图形界面智能体)/ 计算机使用(Computer Use)**——让模型直接看屏幕、点按钮、填表单,替人操作那些没有 API 的系统。 为什么是它?因为企业里海量的遗留系统——政务门户、老 ERP、行业内部审批流——永远不会为了 AI 重构 API。操作它们的唯一接口就是屏幕本身。谁能让模型可靠地"看屏幕干活",谁就拿到了这一层自动化的钥匙。 **能力侧的梯队长这样**(OSWorld-Verified 口径):Qwen3.8-27B 84.3 > GPT-5.4 75 > Claude Opus 4.6 72.7。注意这是"Verified"口径——任务完成经过独立验证,剔除"看起来完成了"的假阳性。刷分口径和 Verified 口径的差距,是评估任何 Agent 基准时首先要问的问题。 但比基准分更有信息量的是企业实测。GPT-5.4(2026 年 3 月 5 日发布)在约 3 万个政务门户的企业实测中,首轮成功率 95%、三轮内 100%——而上一代 CUA(计算机使用 Agent)的同类数字是 73–79%。同一场景、同一任务,一个代际的跨越。附带收益:会话速度快 3 倍、token 消耗省 70%($2.5/$15 每百万 token,cached input $0.25/M)。需要标注场景限定:这是**政务门户**的实测口径,封闭、结构相对规整;开放互联网上的泛化任务成功率会显著低于此。但对企业级落地而言,政务门户恰恰是最高价值的场景形态——流程确定、合规要求高、人工成本贵。 **支撑这个跨越的,是两个"枯燥"的工程细节。** 这部分值得所有做 Agent 的工程师细看,因为基准分数不会告诉你这些。 细节一:**坐标的像素级 1:1 映射**。Claude Opus 4.7(4 月 16 日发布)把图像输入分辨率从 1568px 提到 2576px(约 3.75MP),并实现了模型输出坐标与屏幕像素的 1:1 映射。这解决的是 GUI Agent 最古老的痛:模型"看得到"按钮却说不对位置。坐标偏一个图标宽度的距离,任务就失败——下游再强的重试逻辑都救不回来。视觉分辨率的提升(GPT-5.4 的 original 档做到 10.24M 像素/6000px 长边)和坐标精度的提升,是 GUI Agent 从"演示"走向"生产"的硬前提,一点都不可跳过。 细节二:**能力是"模型 + 工具链"的组合,不是裸模型属性**。GPT-5.4 在 GUI 视觉任务里,如果不开 Python 工具,ScreenSpot-Pro 成绩显著下降。这个现象的选型含义很直接:你拿到的"GUI 能力"取决于你的 Agent 框架给模型配了什么工具。同一个模型,工具链配置不同,表现可以差出一个档位。评估 GUI Agent 方案时只看模型跑分,等于只看发动机功率不看变速箱。GPT-5.4 在 Codex 里内置的 "Playwright (Interactive)" 技能、effort 从 none 到 xhigh 的五档调控,都是这个思路的延伸——模型把一部分"怎么干活"的判断外包给了推理档位和工具编排,系统集成商要负责把这套组合调到业务场景的最优配比。 细节三(补充一个容易被高估的维度):**通用基准与 GUI 场景的相关性有限**。GPT-5.4 的 MMMU-Pro 81.2%(无工具口径)很漂亮,但决定 GUI 成败的不是学科级多模态理解,而是"像素坐标 + 动作序列 + 状态追踪"这组窄能力。Qwen3.8-27B 在 WebArena 64.8、AndroidWorld 81.9 的表现说明开源侧在这组窄能力上已经成体系——这两个基准测的正是浏览器和安卓环境里的真实任务完成率,比泛化的多模态理解分数更贴近生产含义。选型评估时,建议直接用你自己的目标系统录一批任务轨迹做回归集,权重压在这上面,基准分只做初筛。 顺带一个失败模式的提醒:GUI Agent 的失败不是均匀分布的,而是集中在几类结构性场景——长表单的中后段字段(上下文注意力稀释)、动态加载的界面元素(截图时机问题)、需要滚动才能看到的目标(视口外推理)。生产系统的容错设计要针对这几类集中失败做专项处理,而不是泛泛地加"失败重试"。 生产化之后,架构上的核心增量是**审计**。GUI Agent 替人点按钮,每一步都要能回放、能追责——这在金融、政务场景是合规硬要求,不是加分项。下面这套审计留痕架构可以作为参考骨架: ![GUI Agent 生产环境的审计留痕架构.png](https://developer.qcloudimg.com/http-save/yehe-7660620/8026008cbe86700241dc4d6e08aaef2b.png) 未来 12 个月这个赛道会发生什么?三个可预期的变化:其一,**CUA 从演示转向 SLA 化交付**——客户不再为"能演示"付费,而为"首轮成功率 ≥ X%、失败自动回滚"的 SLA 付费,企业实测口径取代基准分成为采购依据;其二,**人机协作审计(每步截图留痕)成为合规标配**,监管对"AI 替人操作"的追责要求会把这个架构模式固化下来;其三,**开源 Qwen3.8-27B 催生私有化内部 GUI Agent**——当模型 Apache 2.0、24GB 可跑、OSWorld 84.3 三件事同时成立,"在自己机房里跑一个操作内部系统的 Agent"从实验项目变成了预算可立项的工程。金融行业的遗留核心系统改造、内部审批流自动化,会是第一批吃螃蟹的场景。 --- ## 五、多模态 RAG 生产范式:六段管线、15% 红线与成本陷阱 多模态 RAG 是另一块已经从"能不能"进入"怎么落地"的阵地。2026 年的生产范式已经基本定型,可以直接照抄,不需要再发明。 先说架构。当前生产环境验证过的标准形态是六段式管线: ![多模态 RAG 六段式生产管线.png](https://developer.qcloudimg.com/http-save/yehe-7660620/8c865a19621fcec9374c5226961dbe35.png) 这套管线里几个关键设计决策,展开说。 **为什么是双路索引而不是单路?** 视觉嵌入(ColPali/ColQwen2/DSE 这类模型)擅长"以图搜图"式的视觉相似性,文本嵌入擅长语义查询。生产系统里两类查询都会出现——"找出带这个 logo 的页面"和"找出讨论违约金条款的页面"是两种检索问题。双路嵌入加复合索引(Vespa、Qdrant 都支持 MaxSim 晚期交互),配合混合检索与重排,是目前兼顾两者的标准解。2026 年 1 月 9 日开源的 Qwen3-VL-Embedding + Reranker 补上了开源侧最后一块拼图:统一语义空间、支持跨模态互检,意味着"文本 query 检索视觉文档"不需要再跨两个不兼容的嵌入空间做 hack。 跨模态互检这个能力值得多说两句,因为它改变了一个长期以来只能"将就"的工程局面。过去文本嵌入和视觉嵌入是两个独立空间,跨模态检索要么靠中间.caption(给图像生成文字描述再入文本索引,语义损耗大),要么靠双路检索后暴力融合(召回质量不稳定)。统一语义空间把这个中间层拿掉了:嵌入和重排共享同一个表征基础,"用文字找图、用图找文"变成同一套索引的原生操作。对语料异构性强的企业(一半是扫描合同、一半是结构化文档)来说,这直接决定了检索基建是一套还是两套——基建减半,运维复杂度跟着减半。 **收益数据要分开看。** 布局感知 chunking(把版面结构纳入切分决策,而不是无脑按固定长度切)将视觉类查询准确率从 30–55% 提升到 55–70%;在此之上叠加 ColPali 类视觉嵌入,再加 10–20 个百分点。这两个数字的口径是生产环境统计(来源为社区工程实践汇总),具体幅度因语料而异,但量级方向可靠:**布局感知是地基,视觉嵌入是增益,顺序不能反**。跳过布局感知直接上视觉嵌入,等于在歪地基上加层。 **表格要走双轨序列化。** 表格是多模态 RAG 里最典型的"两种消费方式"内容:检索时用 Markdown 序列化(语义可检索),计算时用 JSON 序列化(结构可编程)。单一格式必然牺牲一边。这个细节不起眼,但直接决定下游 LLM 是"引用对了表格但算错了数"还是两者都对。 **引用要精确到 bounding box 级。** 生成端的 grounding 校验是最后一道质量闸门:Vision-LLM 给出的每个引用,都应该能定位回原始页面的具体区域。这在金融、医疗场景不只是体验问题,是审计问题——监管问"你这个结论的依据是哪份文件哪个位置"时,段落级引用都不够,区域级才站得住。 然后是那条最重要的红线:**视觉内容占比 < 15% 的语料,不值得上视觉管线**。原因很直白——成本。Vision LLM 抽取的 token 账单在大型语料上可以远超文本处理,为 15% 的视觉内容上全套视觉管线(渲染、布局 OCR、双路嵌入、视觉重排),是用 100% 的基建成本服务 15% 的内容。先统计语料的视觉占比再决策,这个顺序不能反。实践中更稳妥的做法是抽样统计:随机抽几百份文档人工标注视觉元素占比,一天的功夫就能把"上不上"这道题的题干写清楚——多数团队在这个环节省掉的一星期,后来都在错误的管线选型上加倍还了回去。反过来,如果你的语料是扫描件、设计稿、图纸、发票流这类视觉占比超过一半的形态,视觉管线不是选择题,且收益空间(准确率 30%→70% 的翻倍级提升)大到可以支撑一次认真的基建投入。 医疗行业可以作为一个校准案例:影像+文本联合检索的辅助诊断知识库在 6–18 个月窗口内可落地,但细粒度实时场景还没就绪——第三方评测机构 Roboflow 对 Opus 4.7 的测试显示,Object Understanding 85.7% 的同时,目标计数仅 30%、响应时间 17.8 秒(官方口径则强调其在 MCP-Atlas 上领先 GPT-5.4 达 9.2 个百分点、SWE-bench Pro 64.3%)。两组数字并陈的意思是:**同一个模型,在"理解图像语义"上是生产级,在"精确数数"和"实时响应"上还差得远**。选型时先问你的场景要哪种能力,再看模型在那个维度上的数字,而不是被综合跑分带偏。 --- ## 六、选型治理 checklist:2026 年,"模型能力"只占选型清单的一半 这一章可能是全文最"反直觉"的部分:2026 年的多模态选型,能力对比只是半道题,另外半道是工程治理。四类真实的坑,每一类都有 2026 年的鲜活案例。 **坑一:Preview 状态锁定。** Gemini 3.1 Pro(2 月 19 日发布)至今仍是 Preview 状态——ARC-AGI-2 77.1%(前代 31.1%)、GPQA Diamond 94.3% 的成绩确实亮眼,但 Preview 意味着行为可能变更、无完整 SLA、随时可能下线。把它接进生产系统,需要版本锁定(显式 pin 版本)+ 回归隔离(Preview 版本的变更不污染主链路测试集)。8 月底这波发布潮里还有一串 Preview 标签的模型——Qwen3.8-Flash-Next(预览 Qwen4 架构:微块级 Qwen Sparse Attention + Gated DeltaNet,125B 总参/6B 激活、262K 上下文)、混元 4 Preview(770B 总参/49B 激活、1M 上下文,8 月 28 日)——接入前都要按"随时会变"来设计你的调用层。另外注意接入方式的细节差异:Gemini 3.1 Pro 的 thinking_level 默认 MEDIUM 档、agentic 场景走 customtools 端点,这些和稳定版 API 的行为差异都要在适配层处理。 **坑二:许可证条款与承诺不符。** GLM-5.3-Flash 宣传中承诺 MIT 协议,实际以 "other" 许可证发布。这不是阴谋论,是需要在商用前逐条核对的事实:MIT 意味着几乎无限制商用,"other" 则需要逐字读条款,里面可能有商用限制、地区限制或后续变更权。开源不等于免费随便用——**任何开源模型进商用系统前,法务过一遍许可证全文,这一步在 2026 年不能省**。Apache 2.0 的 Qwen3.8-27B 之所以被反复强调,正是因为它是少数"许可证干净"的原生多模态旗舰。 **坑三:API 兼容性陷阱。** 三个具体案例:Opus 4.7 起传 temperature/top_p/top_k 参数直接报 400——你的老代码里那些采样参数配置,在新模型上会当场炸掉;Opus 4.7 换了新分词器,同样的输入 token 数是旧版的 1.0–1.35 倍,成本模型要重算;Opus 4.1 已经在 8 月 5 日退役,依赖它的系统经历了被迫迁移。API 破坏性变更的节奏在加快,适配层的防腐设计(参数过滤、token 计数校准、模型路由可配置)从"好实践"升级成了"生存必需"。 **坑四:分层访问与合规设计。** Anthropic 对 Opus 4.7 实行了分层访问:Mythos Preview、Cyber Verification Program 等能力按资格分层开放。这不是个例而是趋势——前沿能力的开放节奏会越来越多地受合规和滥用防控约束。选型时要把"你要的能力在你的访问层级里是否可用"列为前置检查项,而不是签完合同才发现高级能力需要额外的验证流程。 补充一个值得纳入观察的工程接口演化:Opus 4.7($5/$25 每百万 token)把 xhigh 设为最高 effort 档,并公测了 task budgets(任务级预算控制)。task budgets 这个接口形态值得关注——它把"这个任务最多花多少钱/多少推理步"的控制权交给了调用方,等于把成本治理从架构层下沉到了 API 契约层。如果你的系统已经在做多模型路由和成本闸门,这类原生预算接口迟早要接进你的成本控制面。类似的还有 GPT-5.4 的 cached input $0.25/M 定价——缓存命中的价格只有标准输入的十分之一,上下文重复率高的 Agent 场景(GUI Agent 每步都带着大段重复的系统提示和界面历史)收益尤其明显,做 Agent 成本优化时值得专门设计缓存友好型的提示词结构。 把这四类坑整理成可直接抄进架构评审的 checklist: - [ ] 模型是否为 Preview/预览状态?若是:版本 pin + 回归测试隔离 + 下线预案 - [ ] 许可证逐条核对(尤其"other"类):商用范围、地区限制、变更权 - [ ] API 兼容性验证:采样参数白名单、分词器 token 计数校准、错误码兼容 - [ ] 供应商退役节奏纳入依赖风险页:单一供应商依赖有无退路 - [ ] 计费口径变更监控:token 计数逻辑与账单对账自动化 - [ ] 高级能力访问层级前置确认 - [ ] 硬件兼容矩阵:FP8/量化权重在目标 GPU 架构上的已知问题 - [ ] 审计与合规:GUI Agent 截图留痕、RAG 引用 bounding box 级定位 --- ## 七、展望:实时流合流与未来 12 个月的迁移路线图 最后把视线放到未来 12 个月。三条正在收敛的线,最终会拧成一股。 **线一:实时流式生成走向 API 化。** 三个证据点:MiniMax H3 Max 据报道生成 5 秒音视频内容耗时不到 3 秒,并上线了 24 小时 AI 直播(单一来源报道,作趋势佐证);京东开源的 JoyAI-Video-Edit 以 30.19 FPS@720×1280 的实时编辑能力进入生产,计费按帧率×分辨率×时长——**计费单位从 token 变成了流的物理属性**;视频生成侧价格已经贴地(Veo 3.1 Lite 层 $0.05/秒@720p 含 48kHz 同步音频、Sora 2 $0.10/秒、Kling 2.6/3 Pro 支持到 3 分钟、开源的 Wan 2.6 $0.05/秒),业界流行的"旗舰生成 + Runway Gen-4 精修"双工具栈也说明生成环节的工程化已经分层成熟。当全双工能力以 API 形式开放(SeedRealtime 目前产品内可用、无 API、无法独立验证,但它代表的方向大概率会在 12 个月内 API 化),会触发一轮延迟与成本竞赛,级联架构的存量系统会集中进入改造期。 **线二:网关层的适配成为云厂商的下一个战场。** 流式协议(WebSocket/gRPC)、按流计费、场景路由——这三个词写进你的网关层需求池,现在不算早。计费模型从 token 切换到时长×分辨率,意味着成本核算、预算告警、配额管理的整套基建都要重做。 这个切换的工程冲击比表面看起来大。token 计费体系下,团队已经建立了"输入多少字、输出多少字、缓存命中多少"的心智模型和对应的监控告警;切到按流计费后,账单变量变成了分辨率档位、帧率、并发流数、时长,成本归因的粒度从"一次调用"变成"一段会话",FinOps 的分摊逻辑要跟着重构。JoyAI-Video-Edit 的计费公式(帧率×分辨率×时长)可以作为当前形态的参考:先在你的成本模型里预留这三个维度,等全双工 API 大规模开放时,迁移的就不是模型调用层而是整个财务口径。还有一个建议:流式场景的监控要从"请求-响应"模式改成"会话健康度"模式——卡顿率、首字延迟、轮次切换延迟这些流式指标,现有 APM 体系大多不原生支持,需要提前搭。 **线三:8 月发布潮预演了底座的下一次进化。** MiniMax H3 开源全模态(2K 视频 + 原生立体声)、商汤 SenseNova U1 统一推理与图像生成、Qwen3.8-Flash-Next 预览 Qwen4 架构——"全模态统一底座"从视觉+文本扩展到音频、视频的原生融合,趋势一(早期融合)的下一阶段已经开演。 **给架构师的 12 个月迁移路线图**,按优先级排: **0–3 个月**:存量"文本+外挂视觉"系统完成技术债盘点,标记退役时间表;新项目一律按统一多模态底座设计;把因视觉 token 成本被否的需求重新过一遍成本测算;GUI Agent 选 1–2 个高价值遗留系统做 PoC,用企业实测口径(不是基准分)验收。 **3–6 个月**:数据敏感场景启动单卡私有化评估(Qwen3.8-27B 路径),先过硬件兼容矩阵和许可证审查;多模态 RAG 按六段管线重构,语料视觉占比 ≥15% 的才上视觉路;网关层预留流式协议与按流计费的扩展点。 **6–12 个月**:GUI Agent 从 PoC 转 SLA 化交付,审计留痕架构过合规评审;关注全双工 API 开放动态,实时音视频场景(直播、陪伴、导购)做技术预演;供应链风险复审——开源供给集中于中系模型的现状,用部署层与模型层解耦来对冲。 落到行业,节奏各有不同,给一张粗粒度的时间窗参照:云计算行业是 0–6 个月的窗口,流式协议网关、按流计费、Preview 版本治理、GPU 部署兼容这些事就是云厂商自己的产品路线;金融是 6–12 个月的窗口,遗留核心系统的 CUA 自动化改造、bounding box 级引用的合规审计 RAG、数据不出域的多模态能力栈三件事会在监管框架明确后集中启动;医疗是 6–18 个月的窗口,影像+文本联合检索的辅助诊断知识库可以先行,细粒度实时场景(前述目标计数 30%、响应 17.8 秒的能力现状)则要等模型能力补课;消费科技是 0–12 个月的窗口,端侧/App 内实时音视频助手和 AI 直播会在 2026 年内看到规模化落地,中国厂商在这条线上结构性领先——对做 to C 产品的团队来说,这不是趋势判断而是排期问题。 --- ## 结语:选型清单过期速度的应对之道 回到开头那个判断:视觉正在从"外挂能力"变成"模型底座属性"。这个判断背后是三层连锁反应——架构上,级联管线被端到端消解,"文本+外挂视觉"系统进入技术债清单;经济上,单卡开源旗舰(Apache 2.0 + 24GB 可跑 + 旗舰能力三合一)打通了私有化路径,视觉"零溢价"让旧的否决决策失效;兑现上,多模态的商业价值收敛到 GUI Agent 和多模态 RAG 两个生产范式上,坐标 1:1 映射和 bounding box 级引用这类"枯燥细节"才是落地关键。 还有一个贯穿全文的元判断值得单独强调:**2026 年的选型难度不在能力对比,而在迭代速度**。发布即被超(Muse Glimmer 四天)、退役常态化(Opus 4.1)、Preview 满天飞、计费口径漂移(token 数 1.0–1.35 倍)——任何"选定一个模型用三年"的规划都已失效。应对之道不是追新,而是把解耦和可迁移性设计进系统骨架:模型路由层可配置、评测集自有(用你自己的业务数据定义"够用",而不是被基准分牵着走)、审计与治理基建先于能力采购。这三件事没有一件是新技术,但它们在你架构里的权重,2026 年应该翻倍。 留给读者的三个思考题:你的存量系统里,有多少视觉调用会在底座统一后变成冗余层?你的私有化 TCO 模型里,有没有计入"升级带宽"这项最被低估的成本?如果明天你的主力视觉模型供应商宣布退役,你的系统需要多久能切换? 这三个问题的答案,就是你 2026 年多模态架构的成熟度评分。

优秀的个人博客,低调大师

大模型推理服务全景图

作者:望宸 随着 DeepSeek R1 和 Qwen2.5-Max 的发布,国内大模型推理需求激增,性能提升的主战场将从训练转移到推理。 由于无论是训练还是推理,如何提升性能都是业内讨论最多的话题之一。为什么是性能呢?做过在线业务工程化的人都知道,性能的提升,直接带来的效果有两个: 计算资源成本的下降,更便宜 客户端体验的提升,内容生成更快 在大模型消耗计算资源多、客户端内容流式生成的场景下,性能显得尤为重要。 推理性能的提升涉及底层硬件、模型层,以及其他各个软件中间件层的相互协同,因此了解大模型技术架构的全局视角,有助于我们对推理性能的优化方案进行评估和选型。 说明:图中未包含所有 vendor;部分 vendor 会涉及多个领域。 芯片层 芯片层是计算系统的物理基础,负责执行底层算术逻辑操作,其设计直接影响算力密度、能耗比及并行计算能力。国外有 NVIDIA、AMD 等 GPU 厂商,还有 Groq 等专门针对 AI 推理进行性能优化的芯片制造商。国内是阿里的平头哥、华为的 AScend、寒武纪,以及多家创业公司,包括摩尔线程、燧原科技、沐曦集成、壁仞等。 面向芯片的编程语言和芯片开发包层 硬件编程的抽象接口,实现高效资源调度与指令映射,平衡编程便利性与计算效率。NVIDIA CUDA、AMD ROCm、平头哥 HGAI、Ascend C、寒武纪 BangC、摩尔线程 MUSA、燧原科技 Tops Riser、沐曦集成 MXMACA、壁仞 SUPA,除了提供面向硬件的编程语言,还会提供库、工具和文档等一系列开发者工具。NVIDIA CUDA 技术生态一家独大,对开发者而言,切换编程语言,成本较大。 通用深度学习框架层 提供一系列基础工具和功能,简化了大模型的开发、训练和部署流程。教练水平决定训练效果,PyTorch 和 TensorFlow 是两大"顶流私教",主流框架包括: PyTorch: 由 Facebook AI Research 开发并维护。采用动态计算图技术,在执行过程中能动态调整计算流程,与 Python 深度集成,提供直观的 API 接口和灵活的编程体验。适用于快速原型开发、研究和实验,尤其是需频繁修改和迭代模型的场景。 TensorFlow: 由谷歌基于 DistBelief 研发的第二代人工智能学习系统,可用于 Python、JavaScript、C++ 和 Java 等多种编程语言,广泛应用于语音识别、图像识别等机器学习和深度学习领域,支持 CNN、RNN 和 LSTM 等算法。 JAX: 由谷歌开发,旨在为科研人员提供一个既能够方便进行算法实验,又能充分利用硬件资源加速计算的工具,尤其在需要进行自动求导和并行计算的场景中表现出色。 MindSpore: 有华为开源,是一种适用于端边云场景的新型开源深度学习训练/推理框架,为 Ascend AI 处理器提供原生支持,以及软硬件协同优化。 PaddlePaddle: 由百度开源,支持多种深度学习模型的高效训练,能在多 GPU 和多节点环境下分布式训练,优化计算资源使用效率。 MXNet: 由 Carlos Guestrin 在华盛顿大学共同开发,是亚马逊云计算服务的首选深度学习框架,支持 C++、Python、Java、Julia、MATLAB、JavaScript、Go、R、Scala 等多种编程语言。 Caffe: 由伯克利人工智能研究小组和伯克利视觉和学习中心开发,内核用 C++ 编写,有 Python 和 Matlab 相关接口。以模块化原则设计,实现了对新的数据格式、网络层和损失函数的轻松扩展。 大模型推理加速层 针对推理阶段优化计算效率与资源利用率,通过编译、量化、批处理等技术降低延迟与成本。这一层参与的行业玩家众多,有芯片制造商、云厂商、软件企业、模型社区、科研机构,提供包括开源方案和商业服务,后端接入大模型,提供 API 调用服务。 推理加速的本质是"显存刺客" vs "算力魔术师",谁能用更少的资源跑出更高的性能,谁就是赢家。业内主流方案包括: vLLM (Vectorized Large Language Model Inference) : 由 UC Berkeley 研究团队开源的大语言模型推理和服务框架,采用 PagedAttention 技术,有效减少内存碎片,提升内存利用率,支持多种大语言模型,如通义、LLaMA 等,与 Hugging Face 生态集成良好,可直接加载 HF 上的模型权重。 TensorRT-LLM: 是 NVIDIA 基于 TensorRT 优化的 LLM 开源推理库,深度集成 NVIDIA GPU 硬件特性,如 Tensor Core,可与 NVIDIA 其他工具和库(如 CUDA、cuBLAS 等)无缝配合,还可以与 Triton 框架结合,以提升服务在 NVIDIA GPU 上的推理效率。 ONNX Runtime: 是一个轻量级、跨平台的高性能推理引擎,由微软开发并维护,旨在打破不同深度学习框架之间的壁垒,使得模型可以在多种环境中高效运行,提高模型的可移植性和部署效率。 TGI (Text Generation Inference) : 由 Hugging Face 团队开发,紧密集成 Hugging Face 的 Transformer 库,可轻松加载和使用 Hugging Face 上的众多模型;支持分布式推理,可在多 GPU 环境下扩展服务能力。 Deepytorch Inference: 是阿里云 GPU 云服务器自研的 AI 推理加速器,专注于为 Torch 模型提供高性能的推理加速。通过对模型的计算图进行切割、执行层融合以及高性能 OP 的实现,大幅度提升 PyTorch 的推理性能。 BladeLLM: 是阿里云人工智能平台 PAI 自研的为大语言模型优化的推理引擎,在模型计算、生成引擎、服务框架、应用场景层均作了提升,性能优于主流开源框架。 SiliconLLM: 硅基流动科技推出的专注于大模型推理加速的框架,自主研发了高效的算子和调度策略,支持多种硬件平台,可与多种深度学习框架协同工作。 TurboMind: 上海人工智能实验室开源,专为 LLaMA 系列大语言模型设计的推理加速引擎,支持动态批处理、持续批处理(Continuous Batching)技术。 模型层 国外主流方案:OpenAI 的 GPT、Google 的 Gemini、Meta 的 LLaMA、Anthropic 的 Claude、Mistral AI、X 的 Grok,其中,Meta 的 LLaMA 和 Mistral AI 对模型核心能力进行了开源,其他大模型也有通过技术报告分享,或者部分能力开源的方式反馈社区。 国内主流方案:阿里云 Qwen、DeepSeek、百度文心一言、字节豆包、腾讯云混元、讯飞星火、kimi 等六小龙...其中,Qwen、DeepSeek 对模型核心能力进行了开源,其他大模型也有通过技术报告分享,或者部分能力开源的方式反馈社区。 开源 LLM 已经不再仅仅是闭源模型的追随者,而是开始主导 AI 发展的方向,DeepSeek、Qwen 和 LLaMA 是目前领跑的开源项目。 计算平台层 计算平台层,由于依赖 GPU 算力资源,国内以公共云厂商为主,例如阿里云的人工智能计算平台 PAI、百炼、提供 Serverless GPU 能力的函数计算 FC、容器计算服务 ACS、GPU 服务器等。国外因不受美国出口管制条例的影响,以及大模型技术生态更加完善的原因,vendor 种类和数量更加丰富。除了公共云厂商提供的算力服务外,还有芯片厂商、软件厂商,均提供了推理计算服务。例如 Groq、together.io、Fireworks.ai 等。 by EricFlaningam on X 随着国产 GPU 和 AI 芯片能力的增强,相信这一层国内的 vendor 也会越来越多,提供更加丰富多样的推理计算服务,进一步完善大模型产品链。 应用编排层 大模型的应用编排层是大模型落地产业的核心中间层,是连接大模型能力与业务场景的"粘合剂",主要用于整合模型、工具、数据和服务,实现复杂 AI 任务的自动化流程构建与执行,并提升生成效果。 Langchain:由 Harrison Chase 于 2022 年创建的开源项目,通过 Chain、Agent、Memory 三大组件,像搭乐高一样组合工具链,支持 OpenAI 等 30+ 模型 API,集成 Wikipedia、Wolfram Alpha 等 200+ 外部服务,内置Chroma/Pinecone 等向量数据库接口,实现知识库实时检索增强。 LlamaIndex:聚焦于数据处理和索引构建,适用于需要对大量数据进行有效管理和利用的场景,特别是当你希望 LLM 能够基于特定领域的知识进行回答。 以上两个开源项目,适用于 Python 开发者。 Spring AI Alibaba:专为 Spring 和 Java 开发者设计的智能体开发框架,对 AI 智能体应用的通用开发范式做了很好的抽象,从原子能力层次如对话模型接入、提示词模板到函数调用,再到高层次抽象如智能体编排、对话记忆,和国内大模型做了深度适配,还提供了应用从部署到运维的最佳实践,包括网关、配置管理、部署、可观测等。 以上三个开源项目,都是代码级编程框架,自由度高。 Dify:是一个开源的 LLM 应用开发平台,提供从 Agent 构建到 AI workflow 编排、RAG 检索、模型管理等能力,轻松构建和运营生成式 AI 原生应用。 阿里云百炼:是一站式的大模型开发及应用构建平台。不论是开发者还是业务人员,都能深入参与大模型应用的设计和构建。无须代码,通过简单的界面操作,就可以开发 AI 应用。 此外,也可以使用云原生应用开发平台 CAP+函数计算 FC,以 Serverless 的范式,调用算力资源和编排 AI 应用。 以上三个是低代码平台,使用门槛更低,其中,百炼和云原生应用开发平台 CAP+函数计算 FC,提供了推理的算力支持。 流量管理层 大模型的流量层是大模型服务化部署的核心中间件,主要负责流量、服务、安全和 API 的管理,确保大模型服务在高负载下仍能保持稳定、低延迟的响应。此前国内的大模型需求集中在训练阶段,对流量管理层的需求并不强烈,但随着推理需求的激增,流量管理也将成为类似 Web 应用架构中不可或缺的角色。 但不同于 Web 应用,大模型应用对流量、服务、安全和 API 的管理,呈现了新的特征、提出了新的需求: 长连接。由 AI 场景常见的 Websocket 和 SSE 协议决定,长连接的比例很高,要求网关更新配置操作对长连接无影响,不影响业务。 高延时。LLM 推理的响应延时比普通应用要高出很多,使得 AI 应用面向恶意攻击很脆弱,容易被构造慢请求进行异步并发攻击,攻击者的成本低,但服务端的开销很高。 大带宽。结合 LLM 上下文来回传输,以及高延时的特性,AI 场景对带宽的消耗远超普通应用,网关如果没有实现较好的流式处理能力和内存回收机制,容易导致内存快速上涨。 相比传统 Web 应用,大模型应用的内容生成时间更长,对话连续性对用户体验至关重要,如何避免后端插件更新导致的服务中断? 相比传统 Web 应用,大模型应用在服务端处理单个请求的资源消耗会大幅超过客户端,来自客户端的攻击成本更低,后端的资源开销更大,如何加固后端架构稳定性? 很多 AI 应用都会通过免费调用策略吸引用户,如何防止黑灰产爬取免费调用量封装成收费 API 所造成的资损? 不同于传统 Web 应用基于信息的匹配关系,大模型应用生成的内容则是基于人工智能推理,如果保障生产内容的合规和安全? 当接入多个大模型 API 时,如何屏蔽不同模型厂商 API 的调用差异,降低适配成本? 针对以上新特征、新需求,传统 Nginx 网关已经无法应对,因此国内外均出现了大量基于 Envoy 为内核的新一代开源网关。 Higress: 内核基于 Istio 和 Envoy,并基于生产业务需求做了增强,可用于部署 Web 类应用和大模型应用,在 AI 领域,已经支撑了通义千问 APP、百炼大模型 API、机器学习 PAI 平台、FastGPT、中华财险等 AI 业务。 Kong AI Gateway: 基于 Kong 的插件架构,Kong AI Gateway 具有很强的可扩展性。开发者可以根据自己的需求开发自定义插件,以实现特定的功能,如自定义的流量控制策略、数据转换、模型框架的调度等。 阿里云云原生 API 网关: 提供大模型相关的 API 的全生命周期管理,和阿里云其他云产品集成体验好,例如 PAI、函数计算等,同时基于 Higress 提供了诸多开源增强能力。 此外,还有大模型应用的实施层,这一层中的 vendor 或是具备行业 know-how 的能力,或是具备大模型基建 know-how 的能力,他们充分利用开源大模型、开源中间件,并结合各自的技术沉淀,提供集成、线下部署等多元化的服务,也是大模型技术和应用生态的关键角色,由于厂家众多,不再一一枚举。

优秀的个人博客,低调大师

2020全球网络威胁全景报告

根据最新的IBM全球威胁调查报告《X-Force威胁情报指数2020》,受攻击网络中60%的初始访问都是利用以前窃取的凭据或已知的软件漏洞,从而使攻击者更少依赖欺骗来获取访问权限。 2019六大初始攻击向量:钓鱼攻击、扫描与利用、账户非授权使用、暴力攻击、移动设备攻击、水坑攻击(下图)。 TOP3初始攻击向量 网络钓鱼依然是最有效的初始感染媒介,但占比呈现下降趋势,在报告调查的事件中不到三分之一(31%),而在2018年约占一半。 扫描和利用漏洞导致的事件占30%,而2018年仅为8%。实际上,Microsoft Office和Windows Server Message Block中较旧的已知漏洞在2019年仍发现很高的利用率。 在观察到的事件中,使用先前被窃取的凭据作为首选的进入点也正在逐渐普及,占29%。仅在2019年,该报告就指出有超过85亿条记录遭到泄露,导致所报告的暴露数据同比增长200%,这也增加了网络罪犯可用被盗凭据的数量。 IBM X-Force威胁情报副总裁Wendi Whitmore表示: 我们今天看到的公开记录数量众多,这意味着网络犯罪分子可用的攻击对象数据越来越丰富。攻击者无需花费时间来为企业设计复杂的攻击方法,只需使用已知的信息即可部署攻击,例如使用窃取的凭据登录。 保护措施,例如多因素身份验证和单点登录,对于组织的网络弹性以及用户数据的保护和隐私至关重要。 错误配置后果严重 在2019年报告的超过85亿条违规记录中,有70亿(占85%以上)是由于云服务器和其他系统配置错误造成的,而2018年配置错误导致的违规记录还不到总记录的一半。 银行木马勒索软件化 今年报告中发现的一些最活跃的银行木马(上图),例如TrickBot,几乎完全依托勒索软件实施攻击,这确立了一个新的攻击基调。实际上,与该报告中讨论的其他恶意软件变体相比,银行木马和勒索软件使用的全新代码位居榜首。 网络钓鱼利用人们的科技信任 家喻户晓的科技、社交媒体和内容流媒体品牌构成了网络攻击者在钓鱼攻击中最常冒充的对象。下图为十大被冒充科技品牌: 这种转变可能表明,相比历史悠久的零售和金融品牌,人们对科技品牌的信任度日益提高。 勒索软件攻击不断发展 报告揭示了针对公共和私营部门的全球勒索软件攻击的趋势。 去年,虽然有100多个美国政府实体受到勒索软件攻击,但也有针对零售、制造和运输的重大攻击。在攻击者眼里,这些“肥羊”行业持有大量可变现数据,同时安全技术落伍且漏洞蔓延。 在观察到的80%勒索软件尝试中,攻击者正在利用Windows Server消息块漏洞,类似于WannaCry的策略,后者在2017年破坏了150个国家的企业网络。 2019年勒索软件攻击给组织造成的损失超过75亿美元,攻击者获利丰厚,2020年势必变本加厉。在45%的银行木马和36%的勒索软件中发现了新的恶意软件代码。这表明,通过开发新的代码,攻击者将继续加大攻击力度并逃避检测。 同时,报告观察到勒索软件和银行木马之间的紧密关系,后者被用来为有针对性的高风险勒索软件攻击打开大门,从而使勒索软件的部署方式多样化。 例如,根据该报告,TrickBot是最活跃的金融恶意软件,被怀疑在企业网络上部署Ryuk,而其他各种银行木马,例如QakBot、GootKit和Dridex,也正为勒索软件变种进行多样化演变。 受攻击行业排名中零售业反弹 十大受攻击行业排名变化 在今年的报告中,零售业跃居第二大受攻击行业,与金融服务业的竞争非常激烈,金融服务业已连续第四年保持高位。Magecart攻击是针对零售业最突出的攻击之一,据报道,2019年夏季影响了80个电子商务网站。 网络犯罪分子似乎将目光投向了消费者的个人识别信息,支付卡数据甚至有价值的会员计划信息。零售商还遭受了大量勒索软件攻击。 ICS和OT攻击激增 2019年,针对OT的针对性攻击同比增长2000%,对ICS和OT基础设施的攻击比前三年中任何一年都要多。观察到的大多数攻击都利用SCADA和ICS硬件中的已知漏洞以及密码喷射攻击的组合。 北美和亚洲被针对 北美和亚洲在过去一年中观察到的攻击次数最多,报告的数据损失也最大,分别暴露了50亿和20亿条记录。 报告地址:https://www.ibm.com/security/data-breach/threat-intelligence 【本文是51CTO专栏作者“李少鹏”的原创文章,转载请通过安全牛(微信公众号id:gooann-sectv)获取授权】 戳这里,看该作者更多好文

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册