跳到主要内容

45 篇博文 含有标签「Inference」

AI inference acceleration and optimization

查看所有标签

长上下文的硬件账本:稀疏注意力如何改写显存需求

· 阅读需 3 分钟
Industry Research Team

模型上下文窗口每翻一倍,硬件的隐形成本就翻着倍地涨。预训练计算量的平方增长还算显性,真正卡脖子的是注意力机制带来的 KV Cache:它随上下文长度线性膨胀,随并发数再乘一遍。要读懂长上下文的硬件账本,得从每 token 的 KV 开销算起。

KV Cache:线性膨胀的隐形成本​

自回归解码时,注意力要回看全部历史 token,历史位置的键值向量必须缓存下来。每 token 每层的 KV 开销等于 2 乘以 KV 头数乘以头维度乘以精度字节数,再乘层数。一个 70B 级模型若采用传统多头注意力,单条 128K 上下文的 KV Cache 可以膨胀到几十 GB;并发 16 路,几张 H100 都不够放。这就是长上下文推理服务成本居高不下的结构性原因。

第一轮减负来自注意力结构本身。分组查询注意力(GQA)让多个查询头共享一组 KV 头,KV 开销直接砍掉数倍,如今几乎是长上下文模型的标配。DeepSeek 的 MLA 走得更远:把键值投影到低秩潜空间,缓存的是压缩后的潜向量,据其公开技术报告,KV 显存占用相比传统方案下降了一个数量级,这为 DeepSeek 系列的高并发长上下文服务提供了硬件红利。

稀疏注意力:少读多用​

结构压缩之外,更激进的思路是承认一个经验事实:注意力权重高度集中,绝大多数历史 token 对当前生成的贡献可以忽略。稀疏注意力据此只挑选一小部分关键块参与计算——DeepSeek 的原生稀疏注意力(NSA)、月之暗面的 MoBA 以及 Quest 等方法,都在"选块策略"上做文章:按块粒度估计重要性,只把少数高分块读进计算,其余不碰。

对硬件来说,稀疏注意力省的是 HBM 带宽——解码阶段的瓶颈正是 KV 读取,KV 读取量被压掉一个量级,长上下文解码的速度与显存压力同步缓解。但代价也要看清:选块与索引本身有计算开销,稀疏访问模式让 GPU 利用率下降;更关键的是精度风险,"哪块重要"的判断如果失误,模型会漏看关键信息,长文检索类任务最先暴露问题。

方案对照​

方案KV 显存/读取量精度风险实现与迁移成本
多头注意力(MHA)基线无无,但硬件成本最高
分组查询(GQA)降至数分之一极低,已充分验证训练时确定,改动小
MLA 潜空间压缩下降一个数量级低,需配套训练需专有算子支持
稀疏注意力选块读取量与长度近似解耦中,依赖选块策略框架与算子支持要求高

实操建议​

百万级上下文没有银弹,主流配方是三层叠加:模型侧选 GQA 或 MLA 压缩 KV 本体;注意力侧按业务特性选稀疏策略——代码改写、文档问答这类"相关内容集中"的任务收益最大,全局推理类任务要谨慎评估;系统侧用 KV 量化与 CPU/SSD 分层卸载兜底容量缺口。评估时重点跑长文大海捞针与多跳检索测试,稀疏方案的短板往往藏在最需要"看全文"的样本里。

显存带宽 vs 容量:推理瓶颈的一体两面

· 阅读需 3 分钟
Industry Research Team

买推理卡时,"显存多大"和"带宽多快"是两个经常打架的问题。有人为了 192GB 大容量牺牲带宽,有人反过来。要选对,得先弄清它们各自卡住的是哪一段。

解码阶段:带宽为王​

大模型自回归解码时,每生成一个 token 都要把全部权重从显存读一遍。以 70B 模型 FP16 部署为例,权重约 140GB;H100 的显存带宽 3.35TB/s,意味着单个解码步的理论下限约 42 毫秒,对应单流不超过约 24 tokens/s。此时矩阵运算本身只占极小一部分时间——算术强度太低,大量算力单元处于"等数据"状态。

这就是为什么推理被称为带宽受限负载:加多少 FLOPS 都没用,瓶颈在搬运。大 batch 是经典的缓解手段——一批请求共享同一次权重读取,把每次搬运摊给更多 token,算术强度随之上升,系统逐渐转向算力受限。代价是排队延迟变长,吞吐与延迟开始互相拉扯。

容量:决定"装得下多少并发"​

带宽决定单条请求跑多快,容量则决定同时服务多少条请求。显存里要同时放下三样东西:模型权重、KV Cache(随并发数与上下文长度线性增长)、以及运行时开销。70B FP16 权重约 140GB,在 80GB 的 H100 上单卡放不下,只能拆两卡或量化到 4bit;而 KV Cache 在长上下文场景下动辄吃掉几十 GB,直接挤压可用的并发额度。

容量不足时只能做模型切分,切分带来的通信开销进一步拉低有效带宽;带宽不足时则只能降速。两者都会触发,只是触发条件不同:小模型高并发先撞容量,大模型单流先撞带宽。

主流规格对照​

芯片显存容量显存带宽同代定位
H100 80GB80GB3.35TB/sHopper 基线
H200141GB4.8TB/s同款计算芯片,纯内存升级
AMD MI300X192GB5.3TB/s大容量路线
AMD MI325X256GB6TB/s容量再加码(据公开规格)
NVIDIA B200192GB8TB/s带宽与容量双升级

H200 是最直观的案例:它与 H100 用同一颗计算芯片,算力完全相同,仅把 HBM3 换成更大更快的 HBM3e,推理收益却立竿见影——因为负载本来就卡在内存子系统上。这也是选型时"同算力不同内存配置、价差悬殊"现象的根源。

实操建议​

先定义业务形态,再定侧重:单流低延迟(对话、Agent)优先带宽,够用的容量即可;高并发吞吐(批量 API)优先容量,用大 batch 摊薄权重读取;长上下文服务两者都要,容量缺口考虑 KV 量化与分层卸载。最后提醒一句:带宽和容量都是理论值,实际有效带宽受访存模式与软件栈影响很大,选型前务必用自家模型和框架实测一遍。

Meta MTIA v3 进入量产:拆解式架构背后的自研推理芯片雄心

· 阅读需 4 分钟
Industry Research Team

当同行还在讨论要不要自研芯片时,Meta 已经给出了激进的答案:在 2027 年底之前连续部署四代自研加速器。九月进入量产的 MTIA v3,是这条快车道上最新的里程碑。

Iris 亮相:从单片走向芯粒​

据多家媒体报道,Meta 第三代自研芯片 MTIA v3 由博通担任设计伙伴、台积电负责制造,代号 Iris,产品序列上称为 MTIA 300,已于 2026 年 9 月启动量产。与 2024 年问世的 MTIA v2 采用单片架构不同,v3 转向拆解式芯粒设计,将计算与内存接口拆分为独立硅片,可在不重做计算核心的前提下更换网络或内存模块,灵活应对不同模型对内存与算力配比的要求。

新芯片基于台积电 N3P 级 3 纳米工艺,封装内集成扩展互联结构,用于支撑跨数千节点的分布式推理。在关键指标上,Meta 称其稀疏计算性能较前代提升 7 倍,推荐类模型吞吐量为上代的 3.5 倍,能效提升 2.8 倍。据分析师估算,v3 的内部生产成本比采购同级商用 GPU 低约 40%。

维度MTIA v2MTIA v3
制程台积电 5 纳米台积电 N3P(3纳米级)
架构单片拆解式芯粒
推荐模型吞吐基准3.5 倍
能效基准2.8 倍
稀疏计算性能基准提升最多 7 倍

砍掉训练用途:只做推理的理由​

MTIA 路线图上有一个耐人寻味的转折。据彭博社等报道,Meta 取消了原定兼顾训练与推理的 Olympus 项目,理由是双用途芯片成本要高出约 30%,在吉瓦级部署规模下这笔溢价无法接受。Meta 工程副总裁 Yee Jiun Song 公开解释过这一取舍:推理负载占 Meta 计算消耗的大头,专用设计在每瓦与每美元性能上远比通用设计划算。

后续产品也已排定:第三代 MTIA 450(代号 Arke)于 2026 年 9 月收到台积电交付的 12 颗工程样片,实测性能与仿真结果偏差在 2% 到 3% 之间,计划 2027 年上半年进入数据中心;第四代 MTIA 500(代号 Astrid)设计收尾在即,目标 2027 年底部署。Meta 承诺未来任何 12 个月内投入服务超过 1 吉瓦的自研芯片。

推荐系统是主场,模型生态在扩圈​

MTIA v3 的第一个主战场依然是 Facebook 与 Instagram 的排序推荐系统——这是 Meta 广告业务的算力底座。2026 年 9 月,Meta 确认已将 Muse 系列模型优化适配 MTIA 300,用于推荐基础设施;芯片同时具备运行 Llama 4 等生成式模型的能力,Meta 内部也测试过 DeepSeek 等第三方模型。大规模预训练则继续交给英伟达 GPU。

资本与电力为这条路线提供了后盾。Meta 预计 2026 年资本开支在 1150 亿至 1450 亿美元之间,较 2025 年的 720 亿美元大幅跃升,并计划在 2026 年上半年签约超过 5 吉瓦的数据中心容量。2026 年 7 月成立的 Meta Compute 部门还计划将富余算力对外出售,自研芯片由此从成本工具升级为潜在收入来源。

小结​

MTIA v3 的意义不在于单点性能对标英伟达,而在于验证了一条"专用化加快速迭代"的自研路线:用芯粒架构对冲制程风险,用推荐推理的确定性负载摊薄成本,用四代连发的节奏压榨学习曲线。对于所有承载海量推理负载的平台而言,Meta 的这份答卷值得细读。

MoE 架构对芯片意味着什么:稀疏激活的算力新账

· 阅读需 4 分钟
Industry Research Team

当前主流大模型几乎清一色采用混合专家(MoE)架构。很多人知道它"省算力",但少有人意识到:省下的算力并没有变成免费的午餐,而是被换成了对显存容量和互连带宽的更高要求。这笔账值得每个选型的人算一遍。

参数量与算力解耦​

稠密模型里每个参数在每个 token 上都要参与计算;MoE 把 Transformer 中的前馈层复制成许多"专家",由路由器为每个 token 挑选少数几个激活。以 DeepSeek-V3 为例,据其公开技术报告:总参数 671B,每 token 仅激活 37B,路由层包含 256 个路由专家外加 1 个常驻共享专家,每个 token 激活其中 8 个路由专家。计算量因此比同规模稠密模型低了一个数量级,但训练成本与模型能力并未等比打折——671B 总参的学习容量还在。

Mixtral 8x7B 是更早的参照:总参数约 47B,每 token 激活约 13B。规律一致:FLOPS 可以省,参数一个都省不掉。

瓶颈迁移:从算力到显存与通信​

对硬件而言,MoE 带来三个直接后果。

其一,显存容量压力反而更大。 671B 参数即使量化到 FP8 也要 600GB 以上,权重必须常驻显存等待被路由命中。算力需求降了,容量需求没降,"用小卡跑 MoE"的幻想在容量这一关就会破灭。

其二,通信成为新瓶颈。 专家分布在不同的卡上,每个 token 都要经历 dispatch(发给选中的专家所在卡)与 combine(收回结果)两次 all-to-all 通信,且跨层反复发生。DeepSeek 团队在技术报告中专门讨论了跨节点 all-to-all 的通信瓶颈,并用 DualPipe 流水线做计算通信重叠来掩盖它。对芯片来说,这意味着互连带宽的权重显著上升,节点内 NVLink 级带宽与跨节点网络都直接决定 MoE 的实际效率。

其三,负载不均衡。 热门专家可能被打爆,冷门专家闲置,硬件利用率随之波动。DeepSeek-V3 在推理部署中采用冗余专家策略,复制高负载专家来均衡压力——这又进一步推高了显存占用。

稠密与 MoE 的硬件账对照​

维度稠密模型MoE 模型
每 token 算力与参数量成正比远低于参数量
显存容量需求等于全部参数等于全部参数(一个不少)
主要通信模式数据并行的 AllReduce专家并行的 All-to-All
负载特征均匀可预测随路由波动,需均衡策略
选型关键带宽与算力平衡容量、互连带宽、通信软件栈

实操建议​

为 MoE 服务选硬件时,按优先级排:先看显存容量能否装下全量参数加运行时开销;再看节点内互连是否支撑专家并行的 all-to-all,卡间带宽不足时专家应尽量收拢在节点内;跨节点部署要评估网络带宽与通信计算重叠能力。推理侧尽量用大 batch,让分散命中各专家的 token 聚合成足够大的矩阵,维持算力利用率。一句话总结:MoE 时代,"算力够不够"的提问正在被"显存装不装得下、数据送不送得过来"取代。

多模态推理卡怎么选:VLM、语音与视频生成的硬件差异

· 阅读需 4 分钟
Industry Research Team

"多模态"是一个筐,但 VLM、语音和视频生成装的是三种完全不同的负载。把它们混在一起选卡,要么算力浪费,要么显存爆掉。本文按模态分别算账。

一、VLM 推理:显存带宽决定一切​

视觉语言模型的负载形态和纯文本 LLM 接近:自回归解码受显存带宽约束,视觉编码器只在首 token 前跑一次,算力占用是脉冲式的。选卡的关键是"模型量化后能否装下"加"带宽决定吐字速度"。

7B 级 VLM(如 Qwen-VL 系列 7B)Q4 量化约 4 至 6GB,24GB 消费卡轻松承载并留出图像 token 的 KV cache 余量;30B 至 72B 级 VLM(如 Qwen-VL-Max 同级开源模型)Q4 约 18 至 40GB,需要 48GB 专业卡或 80GB HBM 卡;90B 至 100B+ 级则应直接看 H200 的 141GB——大上下文图文混合场景下,KV cache 增长很快,8B 模型在 128K 上下文时仅 KV cache 就可能超过 20GB,显存买大不为过。

二、语音推理:延迟与并发的平衡术​

语音管线的显存需求小得出人意料:Whisper large-v3 FP16 仅约 3GB、INT8 约 1.5GB;TTS 侧轻量方案(Kokoro 类)不足 1GB,中量级方案(Qwen3-TTS 类 1.7B)约 4GB,重表达力方案(Step-Audio 类 7B 级)约 6 至 8GB。完整的 STT 加 LLM 加 TTS 管线,10 至 20GB 显存即可全部常驻。

真正的门槛是延迟与并发。实时对话要求端到端低于 500 毫秒,语音流有天然停顿,10 路并发同时活跃的转写任务通常只有 4 至 5 路,一张 16 至 24GB 的卡即可承载 10 路并发语音助手。高并发客服外呼场景(百路以上)才需要考虑 80GB HBM 卡或国产推理卡集群。

场景模态组合推荐配置预算区间理由
单机 VLM 应用(7B 级)图文理解RTX 4090 或 5090 单卡1.5 万至 2.5 万元Q4 量化余量充足,带宽够用
企业 VLM 服务(30B 至 72B)图文、文档 OCR2 至 4 卡 4090 或单卡 A100 80GB8 万至 30 万元48 至 80GB 显存覆盖 Q4 至 FP8
实时语音助手(10 路并发)STT 加 LLM 加 TTSRTX 5060 Ti 16GB 或 4090 单卡0.6 万至 2 万元三模型常驻,延迟低于 500 毫秒
视频生成工作站DiT 类视频模型RTX 5090 单卡起步2 万至 3 万元32GB 显存加高带宽承接长序列
视频生成生产服务高分辨率长时长8 卡 H100 或 H200180 万至 240 万元多路生成排队,机内并行摊薄单条成本
国产化多模态服务图文与语音Atlas 300I Duo 集群单卡约 2 万至 4 万元低功耗高密度,OCR 与转写场景成熟

三、视频生成:被低估的算力黑洞​

视频生成是三者中唯一"算力吃紧"的场景。DiT 类视频模型在去噪阶段是密集矩阵运算,且长时长、高分辨率视频的隐空间序列长度线性增长,显存压力接近训练。经验值是:数秒级 720P 视频生成,24 至 32GB 消费卡可行但排队慢;分钟级或 1080P 以上,需要多卡并行与 80GB 级显存。做视频生成业务的公司,推理集群的卡时成本远高于 VLM 业务,定价模型时务必先实测单条视频的卡时消耗。

四、结尾建议​

选型三步走:先按模态对号入座(VLM 看显存、语音看延迟、视频看算力),再按并发规模定卡的数量而非档次,最后用真实流量压测两周再固化采购。特别提醒:多模态业务的显存需求会随上下文长度和分辨率持续上涨,新购卡优先选 32GB 以上显存或支持多卡扩展的机型,给六个月后的模型升级留出空间——2026 年的模型迭代速度下,显存不足是所有多模态服务扩容时最先撞上的墙。

NVIDIA H200 深度解析:141GB HBM3e 的长青主力与它在中国市场的曲折命运

· 阅读需 5 分钟
Industry Research Team

在 Blackwell 与 Rubin 接连发布的 2026 年,一颗 2024 年发布的 Hopper 芯片依然是全球推理集群里最常见的面孔。H200 的故事说明了一件事:在 LLM 时代,显存容量与带宽往往比峰值算力更能决定服务器的价值。

H200 到底改了什么:加显存,而不是加算力​

H200 是 H100 的"内存增强版",这是理解它的全部起点。两者的 Hopper 架构核心、算力规格几乎一致:BF16 Tensor Core 均为 1,979 TFLOPS(稀疏口径),FP8 Tensor Core 均为 3,958 TFLOPS(稀疏口径)。NVIDIA 没有动计算部分,而是把显存从 80GB HBM3 换成了 141GB HBM3e,带宽从 3.35TB/s 提升到 4.8TB/s——容量约为 1.8 倍,带宽约为 1.4 倍。

这个改动的逻辑直接来自 LLM 推理的物理特性:生成每一个 token 都要把模型权重和 KV Cache 从显存里读一遍,单流解码速度受限于显存带宽而非 TFLOPS;而能装下多大的模型、多大的上下文,则受限于显存容量。H200 在两个维度上同时抬高了上限,于是出现了官方 MLPerf 测试中 Llama 2 70B 推理吞吐接近 2 倍、GPT-3 175B 推理提升约 1.6 倍的成绩。

规格H100 SXMH200 SXMH200 NVL
显存80GB HBM3141GB HBM3e141GB HBM3e
显存带宽3.35TB/s4.8TB/s4.8TB/s
BF16 Tensor(稀疏)1,979 TFLOPS1,979 TFLOPS1,671 TFLOPS
FP8 Tensor(稀疏)3,958 TFLOPS3,958 TFLOPS3,341 TFLOPS
最大 TDP700W700W600W
NVLink900GB/s900GB/s900GB/s(2 路或 4 路桥接)
MIG 切分7 实例7 实例(每实例 18GB)7 实例(每实例 16.5GB)

值得注意的是 H200 NVL 版本:为了适配企业风冷机柜,其功耗上限降到 600W,算力也相应下调,但保留了 141GB 显存与四卡 NVLink 桥接能力,是"风冷机柜跑 70B 模型"的常见方案。

中国市场:从 H20 的遗憾到 H200 的回归​

H200 在 2026 年的最大新闻不来自参数表,而来自出口管制。此前中国市场的合规替代品 H20 为了满足出口阈值,保留了大量显存带宽(96GB HBM3、4TB/s 级别)却把算力削到约 148 TFLOPS BF16,"能推理不能训练",被广泛认为是糟糕的替代品。

2025 年 12 月,路透社报道 NVIDIA 计划在春节假期前向中国交付 H200;2026 年 3 月的 GTC 大会上,黄仁勋确认在获得美方出口许可与中方审批后恢复面向中国市场的生产;2026 年 5 月,美国商务部批准了包括阿里巴巴、腾讯、字节跳动、京东等约 10 家中国企业购买 H200,每家获批客户最多可采购 7.5 万颗,联想、富士康等分销及服务器企业也拿到了相关授权。

中国市场 SKU算力(BF16 稠密口径约值)显存定位
H20约 148 TFLOPS96GB HBM3推理合规替代,算力被大幅削减
H200约 990 TFLOPS141GB HBM3e训练推理兼顾,2026 年恢复供应
B30A(据公开报道)未确认传 Blackwell 系裁剪版观察中的下一代中国 SKU

需要强调的是:H200 返华是"有限放行"而非限制解除,监管框架仍在,政策方向此前已经反转过多次,采购预算不宜单边押注。## 2026 年视角:H200 还值不值得买

在 B300、Rubin 已经铺开的 2026 年,H200 的定位可以概括为"性价比推理底座"。它的优势场景非常明确:其一,单卡装下 70B 级稠密模型或量化后的百亿级模型,免去张量并行的通信开销;其二,对需要 FP64 或成熟 FP8 生态的 HPC 混合负载,Hopper 栈依然最稳;其三,风冷兼容性好,H200 NVL 可直接进入存量企业机柜。

它的劣势同样清楚:相比 B200/B300,FP4 时代的算力代差已经拉开;随着合规渠道打开,二手 H100 价格与亚洲区域租赁价格都在承压回落,采购者应以季度为单位重新询价。按每百万 token 的综合成本测算,H200 通常在"单卡顶替两卡 H100"的场景下胜出;而模型能装进 80GB 且 prefill 占比高的场景,H100 甚至更便宜。

小结​

H200 的价值公式是:H100 的算力,加上 1.8 倍显存与 1.4 倍带宽,再乘上一个高度成熟的 CUDA 生态。对以推理为主、追求 TCO 的团队,它在 2026 年仍是稳妥的默认答案;对训练前沿模型或押注 FP4 的 AI 工厂,Blackwell 与 Rubin 才是主线。在中国市场,它则承载了出口管制博弈中最微妙的一章——值得每季度复核一次供应与价格信号。

端云协同新格局:手机 NPU 与云端推理的分工边界

· 阅读需 4 分钟
Industry Research Team

手机 NPU 的峰值算力九年间从 0.6 TOPS 涨到 80 TOPS,但一个 3B 模型在端侧的流畅运行,靠的早已不是 TOPS 数字。当云端推理进入万亿参数时代,端与云的分工边界在哪里,正在被重新谈判。

移动 NPU 的进化与瓶颈​

从 2017 年麒麟 970 与苹果 A11 首次引入移动 NPU,到 2026 年的旗舰平台,端侧 AI 算力完成了百倍跨越:

平台NPU 算力主要特点
骁龙 8 Elite Gen 5约 75 至 80 TOPS融合 AI 加速器架构,支持 INT2 与 FP8 混合精度
天玑 950050 TOPS 以上强调能效,宣称性能翻倍、功耗降约四成
苹果 A19 Pro约 38 TOPS凭借统一内存与 Core ML 优化实现实际竞争力
苹果 A11(2017 年)0.6 TOPS移动 NPU 的起点

但 TOPS 从未是真实体验的保证。第三方评测显示,骁龙 8 Elite Gen 5 在运行 8B 量化模型时会因 LPDDR5X 总线带宽(约 85GB/s)饱和而跌到每秒 12 个 tokens 附近——内存带宽而非算力,才是端侧推理的第一瓶颈。峰值 80 TOPS 跑不快一个 8B 模型,这就是移动 AI 的现实:算力年年翻倍,带宽却受制于手机内存的功耗与体积约束,增速远远掉队。

端云分工:三层负载的清晰分层​

2026 年旗舰机型的实践已形成相对稳定的分工范式:

  • 端侧必留:唤醒词、拍照语义处理、实时转写、通话翻译等常驻功能——低延迟、离线可用、隐私敏感,且可在微瓦级功耗下待机运行;
  • 端侧可选:3B 到 8B 级量化小模型承担的摘要、改写、本地图像生成,牺牲部分质量换取零网络依赖;
  • 云端包办:前沿推理模型、视频生成、复杂智能体编排——端侧算力与显存天花板决定了这些负载短期内无可下沉。

三星宣称到 2026 年底将 Galaxy AI 覆盖 8 亿台设备,其策略正是典型的混合路由:个人数据本地处理,复杂推理按需上云。谷歌 Tensor G5 的思路则提供了另一个注脚——它不在原始算力上争第一,而是专为 Gemini Nano 做软硬协同优化,用更低的 TOPS 跑出更好的实际效果。

边界正在向哪里移动​

三个变量将决定端云边界的走向。其一是内存技术:移动内存带宽的持续爬升与更大容量封装的普及,可能把端侧可流畅运行的模型推到 10B 以上;其二是模型效率:蒸馏与量化每前进一代,端侧可承载的能力就上移一档;其三是隐私监管:数据出境与个人信息保护要求趋严,会持续把更多推理"推"回设备内部。综合业界普遍预期,端侧将稳态承接约七成的推理调用次数,但按算力消耗总量计,云端仍将占据绝对大头——调用次数的多,不等于算力的大。

结语:端云不是对手,而是流水线的两站​

把端云关系理解为竞争,是对这场变革最大的误读。手机 NPU 的角色是"常驻的感官与反射",云端大模型是"按需调用的大脑",两者通过意图路由与模型分级协同工作。对芯片产业而言,这意味着两端将长期并行增长:云端拼每瓦 tokens,端侧拼每毫安时 tokens——两个优化方向,同样残酷,也同样机会巨大。真正的赢家,是那些把"什么时候在端、什么时候上云"做成无感体验的厂商。

从 ONNX 到 TensorRT:视觉 AI 的部署流水线拆解

· 阅读需 3 分钟
Industry Research Team

在 LLM 推理框架火热之前,视觉 AI 早就打磨出一条成熟度极高的部署流水线:PyTorch 训练、ONNX 交换、TensorRT 编译、推理服务托管。这条链路今天依然是目标检测、分割、OCR 类业务的标准答案。

全景流水线与各环节要点​

环节工具关键动作常见坑
模型导出torch.onnx.export固定或动态维度、opset 选择自定义算子导出失败、动态轴漏标
算子兼容检查Polygraphy / onnx 工具链逐层对比数值未融合算子回退拖慢速度
引擎构建trtexec精度策略、workspace、形状 profile动态形状未配 profile 导致构建失败
量化校准TensorRT 校准器准备数百张代表性校准图校准集分布偏移导致精度掉点
精度回归自建评测脚本mAP 等指标与 FP32 基线对比只测时延不测精度
服务托管Triton模型仓库、动态批处理instance 数与显存不匹配

trtexec 是流水线的瑞士军刀​

引擎构建不必写代码,trtexec 一条命令完成:用 --onnx 指定输入,--fp16 或 --int8 指定精度策略,--saveEngine 输出序列化引擎。做 INT8 时需提供校准数据(通常 100 到 1000 张代表性图像),TensorRT 默认使用熵校准器统计激活值分布,首次构建生成校准缓存可复用。动态输入是视觉业务刚需,必须显式给出 minShapes、optShapes、maxShapes 三档 profile,运行期张量尺寸落在区间内即可免重编译。构建完成后用 --loadEngine 加载压测,配合 --useCudaGraph 能显著降低内核启动开销,嵌入式设备上这一项常带来两位数的吞吐提升。

量化策略与精度守护​

INT8 能把时延再压一档、显存降三成以上,但不是所有层都能安全量化。工程惯例是让 TensorRT 自动混精度:对量化敏感层保留 FP16 或 FP32 回退,这就是 --fp16 与 --int8 同时开启的原因。精度守护流程必须制度化:固定校准集与评测集,量化后跑完整 mAP 对比,掉点超过业务阈值就启用 QAT(量化感知训练)补救。另外要记住 TensorRT 引擎与 GPU 架构、驱动版本强绑定,换卡必重编,构建耗时和 timing cache 策略要纳入 CI 考量。

实操建议​

把整条流水线做成 CI 任务:每次模型提交自动导出 ONNX、跑算子兼容检查、构建 FP16 与 INT8 双引擎、输出精度与时延对比报告,人工只审报告。上线用 Triton 托管多版本引擎灰度切换。最后一句经验:先锁 opset 版本再动其他,90% 的导出诡异问题都源于训练侧随手升了 opset 而部署侧解析器没跟上。

CUDA 城墙下的三条隧道:CANN 开源、ROCm 补课与 PyTorch 中立层

· 阅读需 6 分钟
Industry Research Team

CUDA 的护城河有多深?20 年的代码沉淀、与主流框架的深度绑定、一代工程师的肌肉记忆。但 2026 年,三条隧道正在城墙下方掘进:华为 CANN 全面开源,AMD ROCm 借 MI455X 补课,PyTorch/Triton 中立层持续稀释锁定。本文逐条拆解。

CUDA 护城河的本质​

CUDA 不是一个库,而是一整套生态惯性。站内 NVIDIA 规格卡反复出现的细节印证了这一点:RTX Spark 全栈 CUDA、DGX OS 预装完整 NVIDIA 软件栈、PyTorch with CUDA 原生兼容。护城河由三层构成:

  1. 代码沉淀:cuDNN、cuBLAS、NCCL、TensorRT 等组件经过近 20 年打磨,算子覆盖度与稳定性无可替代;
  2. 框架绑定:PyTorch、TensorFlow 的默认后端是 CUDA,新模型上线第一天就有 CUDA 支持;
  3. 人才习惯:开发者学的是 CUDA 编程模型,迁移到任何新平台都有重学成本。

这种惯性意味着:即使竞品硬件性能追平,软件栈差距仍会让用户停留在原平台。要翻越这堵墙,硬攻不如打隧道。

隧道一:CANN 开源,用开放换生态​

华为选择的路是把家底亮出来。站内昇腾 960 规格卡记录:CANN 全面开源并进入常态化社区运营,外部开发者占比升至 61%(首次超越内部团队),月活跃开发者突破 5200 人。HC2026 补充口径进一步给出:CANN 已支持 40+ 模型原生训练,兼容 PyTorch、Triton、vLLM、veRL 等 90+ 开源项目,并成为 PyTorch 官网首个中国算力平台。

更关键的是头部模型厂商的背书:DeepSeek 与华为联合开源了面向昇腾 950 加速器的编程工具与库(含计算与通信库),明确瞄准降低 NVIDIA 生态锁定。当最强的开源模型团队直接参与昇腾工具链共建,"昇腾只能跑推理"的旧叙事被正式改写——DeepSeek 此前已在昇腾上完成训练侧验证。

CANN 策略的本质是:单芯片性能可以落后一代,但只要开源生态的迁移摩擦足够小,系统级方案(4096 卡超节点、统一内存编址)就能补齐单卡差距。

隧道二:ROCm 补课,用性能换迁移​

AMD 的路线不同:不是换赛道,而是在 CUDA 的主场追赶。站内 MI455X 规格卡显示:CDNA 5 架构、432GB HBM4、MXFP4 算力 40.3 PFLOPS,2026 Q3 末出货、H2 2026–H1 2027 规模爬坡;MI430X 支持 FP64 双精度并将驱动 LUMI-AI 超算。硬件到位之后,ROCm 的补课重心是算子覆盖与框架兼容——从 PyTorch 官方支持到 vLLM/sglang 的推理后端适配,开源社区的力量正在把 ROCm 从"能用"推向"好用"。

维度CANN(华为)ROCm(AMD)CUDA(NVIDIA)
策略全面开源换生态性能追平 + 兼容层补课闭源完整栈
开发者规模外部占比 61%、月活 5200+开源社区驱动全球最大基数
框架支持PyTorch/Triton/vLLM 等 90+ 项目PyTorch 官方后端默认后端
2026 里程碑PyTorch 官网首个中国算力平台MI455X 量产、LUMI-AI 背书Rubin 平台七芯片堆栈
短板单卡性能落后一代生态成熟度仍逊于 CUDA闭源、锁定深

国产第二梯队的路径也值得注意:站内天数智芯天垓150 规格卡记录,其软件栈 IXUCA 高度兼容 CUDA 生态,官方口径迁移时间下降 50% 以上,适配主流深度学习框架与 200+ 模型(厂商口径)。兼容 CUDA 的"寄生式"策略,是在城墙阴影下最务实的生存方式。

隧道三:PyTorch/Triton 中立层稀释锁定​

前两条隧道是厂商挖的,第三条是社区挖的。PyTorch 2.x 的 compiler 栈(torch.compile)与 OpenAI Triton 让开发者写的模型代码可以不直接接触 CUDA——同一份 PyTorch 代码在 CUDA、ROCm、CANN 后端之间切换的成本逐年下降。当模型定义层与硬件执行层解耦,CUDA 的"默认后端"地位就从护城河变成了可选组件。CANN 能进 PyTorch 官网、ROCm 能成为官方后端,都是这个中立层稀释效应的体现。

绕过式创新:SINQ 与 Strata​

除了正面挖隧道,还有两条"绕过"城墙的小路:

  • 华为苏黎世实验室开源的 SINQ 量化技术:官方测试称可将大模型显存占用削减约 60%-70%——显存需求骤降后,原本装不下的模型可以装进更小的卡,硬件门槛被算法直接拉低;
  • OpenAI Strata 开源推理引擎:基于 C++20 与 CUDA,在 12-24GB 的游戏显卡上运行 125B Qwen MoE 模型,吞吐 60-95 tok/s,核心创新是专家缓存机制(CPU/GPU 并行)。它证明了软件创新可以让"消费级显卡跑大模型"成为现实。

这两项技术的共同点是:用算法层创新绕过硬件层差距——量化绕过显存墙,MoE 专家缓存绕过算力墙。软件栈竞争的维度因此变得更加多维。

开发者迁移决策树​

面对多平台选择,一个务实的决策路径:

  1. 训练前沿模型? 优先 CUDA 栈——算子覆盖与稳定性仍是训练侧硬需求,除非有明确的国产化合规要求;
  2. 国产化合规优先? 评估 CANN:40+ 模型原生训练、PyTorch/Triton/vLLM 支持已覆盖主流工作流,用小规模试点验证自己的模型清单;
  3. 推理为主、成本敏感? ROCm 平台(MI455X 432GB 显存)与 Strata 类引擎值得 POC,量化技术(SINQ 等)可显著降低硬件档位;
  4. 多平台部署? 把代码收敛到 PyTorch/Triton 中立层,避免深度依赖平台专有 API——这是面向未来的对冲。

小结​

CUDA 的城墙依然坚固,但 2026 年的掘进速度前所未有:CANN 用开源把外部开发者占比推到 61%,ROCm 借 MI455X 量产获得性能与出货的双重背书,PyTorch/Triton 中立层则从根上稀释锁定价值。叠加 SINQ、Strata 这类绕过式创新,"非 CUDA 平台不好用"的断言正在失效。对开发者而言,最优策略不是站队,而是站到中立层上——让每一条隧道都成为自己的备选出口。

量化实战:GPTQ、AWQ 与大模型压缩的落地取舍

· 阅读需 4 分钟
Industry Research Team

数值格式(FP8、FP4)解决的是"硬件支持什么精度",而量化算法解决的是"训练好的模型怎么安全地住进低精度"。后者才是工程落地的日常:手里一个 70B 模型、一张 80GB 的卡,怎么让它跑起来还尽量不掉点。

GPTQ:用二阶信息做误差补偿​

GPTQ 的思路源于经典的二阶最优剪枝方法。它逐层处理权重:用少量校准数据(几百条即可)估计该层输入的二阶统计量,然后按列量化权重,每量化一列,就利用 Hessian 信息调整其余未量化列,把引入的误差"摊"到还没量化的地方去补偿。整个过程不需要反向传播,在单张卡上几个小时内就能压完一个百亿级参数模型。

代价是它本质上在做"整体最优的近似":逐层的贪心决策叠加起来,对校准数据分布有一定敏感性,校准集与真实业务分布偏差大时,掉点风险随之上升。

AWQ:抓住关键的 1% 通道​

AWQ 从另一个观察出发:权重中真正对精度敏感的通道,是那些对应激活值特别大的少数通道——通常只占 1% 上下。与其逐列做全局误差补偿,不如识别出这些显著通道,用一个按通道缩放的变换保护它们,让它们落在量化网格的"好位置"上。

这个方法同样不需要反向传播,校准成本与 GPTQ 相当,但对校准数据规模和分布的依赖更弱,跨领域、跨任务的鲁棒性通常更好,这也是它在开源社区部署中被广泛采用的原因。它只解决权重侧的压缩(常见的 W4A16 形态:权重 4bit、激活保持 16bit),计算时需要把权重反量化回高精度再做矩阵乘。

W8A8 与激活离群值​

想同时压缩激活(W8A8)会撞上大模型的经典难题:激活分布中存在系统性的离群通道,个别通道的数值比其余大几个数量级,直接按统一 scale 量化会把这些通道全压废。SmoothQuant 的解法很巧:用一个等效数学变换,把激活里的离群难度迁移到权重侧,让两边都变得"平缓",从而实现全整数推理。W8A8 的算子效率高、适合大 batch 高并发服务,但精度风险高于 W4A16,需要更仔细的评估。

方法对照与取舍​

方法典型形态是否需要反传主要优势适用场景
GPTQW4A16否压缩比高,工具链成熟单卡/双卡装下大模型
AWQW4A16否鲁棒性好,跨域稳定通用生产部署
SmoothQuantW8A8否激活也压缩,算子高效高并发吞吐服务
QAT(量化感知训练)任意是精度上限最高有训练资源且对精度极敏感

实操建议​

单卡或双卡要装下大模型、追求低延迟,选 W4A16 的 AWQ 或 GPTQ,两者精度差异通常不大,优先看框架支持度;高并发吞吐场景考虑 W8A8。评估时不要只看困惑度,困惑度的小幅变化可能对应下游任务的大幅波动,务必跑自己的业务评测集。另外,KV Cache 量化是独立的压缩维度,长上下文场景可与权重量化叠加使用。最后,任何量化方案上线前都先在影子流量上对照全精度基线跑一段时间,这是最便宜也最可靠的保险。