上个月替朋友调一套 70B 模型的推理服务单卡塞不下双卡张量并行又各种踩坑折腾到后半夜我忽然意识到一个问题就算算法再卷硬件选型和任务拆分的思路不换性能上限就卡在那儿。推理侧的未来其实不是某一个芯片通吃而是 GPU、ASIC 和存算一体这三条路线各管一摊再靠一套像样的调度逻辑把它们捏合成整体——也就是标题里说的多芯协同。这篇东西算是我最近做推理侧选型、部署和压测的一手笔记。我不写硬件白皮书就把“GPU 为什么会被卡脖子”“ASIC 为什么能在推理侧捡漏”“存算一体到底是不是吹牛”“多芯协同该怎么想、怎么落地”全部摊开来讲。适合正在搞大模型服务部署、推理性能优化或者单纯想判断 AI 硬件走向的工程师也适合那些刚入门、想知道 GPU 显存该怎么看、Ollama 为什么没跑在 GPU 上的新手。1. 推理侧的真实瓶颈为什么大家都在跟显存和带宽较劲1.1 显存容量先看清训练与推理对显存的需求差在哪“GPU 显存容量是测算推理还是训练用的”这个搜索词隔一阵就有人翻出来。很多人把训练和推理的显存占用混为一谈实际上两者差异非常大。训练时显存里至少装着五样东西模型权重、梯度、优化器状态、激活值、通信缓冲。以 Adam 优化器为例它需要保存一阶动量、二阶动量两份状态显存开销经常比模型权重本身还大所以训练场景对显存的渴求是“拼命式”的——显存越大越好装不下就上张量并行、流水线并行把各路状态分到多张卡上。推理侧明显更轻。推理没有梯度没有优化器状态主要就两个大头模型权重和 KV Cache。以 Llama 3 70B 为例FP16 权重大约 140GB单张 A100 80GB 根本塞不下。但做完 INT4 量化后权重可以压到 35GB 左右单卡基本盘就稳住了。问题随之转移到 KV Cache 身上——并发请求越多、上下文越长KV Cache 膨胀得越快。粗略估算每个 token 大约需要2 × 层数 × 注意力头维度 × 2字节的存储70B 模型开 8K 上下文再叠加不小的并发KV Cache 直接吃掉几十 GB 一点不意外。所以我常说“显存够不够”在推理侧从来不是一个静态数字而是一个和 batch size、序列长度绑定的动态函数。我实际部署时算显存从来不走“凭感觉”路线而是用一套固定估算框架模型权重量化后 KV Cache 激活值 推理引擎的中间缓冲激活值在推理时不像训练那么夸张但如果用 FlashAttention、PagedAttention 这类方案峰值变化还是很明显PagedAttention 的思路其实就是“操作系统里的虚拟内存换页”按需分配 KV Cache 块而不是一次性按 max length 预留整段空间这也是为什么现在的推理引擎都在讨论 PagedAttention、vLLM 这些方案。它们本质上是把显存当内存来管理大大缓解了高并发下的显存浪费问题。1.2 访存瓶颈推理卡的不只是算力更是“搬数据”的效率很多人下意识以为推理瓶颈是算力不够TOPS 不够高但实际上大模型解码是 token by token 的每个 step 的矩阵乘规模相对固定计算量并不大。真正的压力在于每一步都要把模型权重从显存搬到计算单元。用大白话说就是“货不多但每次都要把整个仓库翻一遍”。这时候决定延迟的不是算力峰值而是显存带宽。我们可以做一个很粗糙的估算假设模型权重 170GB显存带宽 3.35TB/sH100 级别那么每解码一个 token光搬权重就要170GB / 3.35TB/s ≈ 50ms这还不算计算时间。如果量化到 INT8权重降到 85GB搬运时间也能压到 25ms 左右看到没有纯靠堆算力不解决根本问题反而压缩权重大小、提高带宽利用率收益立竿见影。这也解释了为什么推理侧对量化如此痴迷——不仅省显存关键是省“搬运时间”。同样道理FlashAttention 为什么有效因为它减少了中间矩阵的读写次数把带宽花在真正需要计算的地方。这些优化手段的共同目标都是在和“内存墙”对抗。这里也就能看清 GPU 面对推理的一个本质劣势GPU 是一台为“高并行 高吞吐”设计的万能引擎在训练环节它能充分运转但在单 token 解码的推理场景有大量带宽和算力被浪费。于是 ASIC 和存算一体本质都是想从这个“通用引擎”手里抢走一部分推理生意。2. ASIC推理侧的低功耗先锋但不是万能药2.1 ASIC 凭什么能在推理侧如鱼得水用工厂做类比最直观GPU 像是一台万能机床什么零件都能加工但切换工序要时间能耗也高。ASIC 就是一台专门为某种零件定制的高速冲压机一旦产品定型、批量巨大成本和能效就全面碾压通用设备。推理侧对 ASIC 非常友好原因有几个神经网络结构基本固定算子集合足够小MatMul、LayerNorm、Softmax、GELU 也就那么几个推理时大量计算是稠密线性代数非常适合硬管线实现推理不需要反向传播不需要存储中间梯度内存访问模式比训练规矩太多所以 ASIC 可以把芯片面积全部押在乘加阵列、数据流调度、片上缓存上把每瓦性能拉到极致。宣传口号里经常出现的“XX TOPS”在推理场景下确实有一定参考意义但不能只看峰值。我评价一款推理 ASIC 芯片通常聚焦三个点数据格式支持FP16、INT8、INT4 是否能全覆盖互联能力走 PCIe 还是自研高速互联软件编译栈成熟度把 PyTorch/TensorFlow 模型迁上去要花多少工作量一个很朴素的验证方法是拿一个落地模型跑典型 batch计算“每瓦每秒处理多少 token”这比厂商宣传的 TOPS 数字可靠得多。2.2 昇腾这类“类 GPU”与 GPU 的本质区别“昇腾系列有哪些 GPU”这个问题我见过很多次。严格说昇腾不是 GPU它是面向 AI 计算场景的专用加速芯片有自己的架构体系并搭配 CANN 工具链使用。因为不兼容 CUDA很多在 GPU 上跑通的模型迁移过来需要做算子适配和模型转换。昇腾里也有矩阵计算单元因为它和 HBM 结合紧密能提供不错的带宽和能效但它和英伟达 CUDA 生态并不是一回事。这类芯片的好处是确定性极好——算子固定、访存规律固定比通用 GPU 更容易做推理优化。问题是生态不是一朝一夕能补起来的开源软件默认支持的是 CUDA一个“PyTorch 安装 GPU 版”的背后牵连的是编译配置、算子替换、推理引擎适配这一整套工程量都不小。我的建议是团队要上这类芯片不要只看单卡算力先跑一个“最小可行迁移”把真实模型完整跑通一次推理记录从 PyTorch 权重到芯片可执行模型的全过程耗时。如果迁移成本过高ASIC 的性价比优势会被运维成本吃掉一大截。从实操角度把模型切一部分做算子适配另一部分继续留在 GPU 上是现阶段比较务实的协同方案。2.3 ASIC 的软肋生态壁垒和模型演进速度之间的拉锯ASIC 最怕的就是模型结构多变。现代大模型基本是 Transformer 一统天下短期内这个架构方向不会被推翻但注意力变体、MoE、混合专家等分支的出现都会改变算子的 shape 分布和访存比例。ASIC 一旦在芯片里把数据流调度固定成某一种形态遇到新结构时往往需要流片才能适配而流片周期通常是 12 到 24 个月起步。软件团队加班能解决一部分问题但不能从根本上解决。所以 ASIC 在推理侧的现实位置其实是“分工协同”在模型稳定、算子成熟、流量规模化之后把最热的几个算子拆给 ASIC 做剩下快速迭代的部分还是留在 GPU 或 CPU 上。说白了ASIC 适合做“量上规模之后的定点突变”不适合做“百花齐放时的全能选手”。3. 存算一体把计算搬进记忆体向“内存墙”动刀3.1 内存墙到底有多贵传统冯·诺依曼架构里计算单元和存储单元是分开的数据要不停搬来搬去。随着模型变大访存开销的占比越来越高。业界经常说“内存墙”本质就是算力增长的速度远快于带宽增长的速度。想象一下办公室在一楼仓库在十楼员工作一小时的活有五十分钟都耗在上下楼搬材料上了。大模型推理就是这个状态。前面算过解码一步的搬运时间可能占到大头而且随模型容量增长搬运压力是线性上涨的。解决内存墙有两条技术路线近存计算把计算逻辑放进 DRAM 或者 HBM 封装里缩短物理距离存算一体在存储阵列里直接完成乘加运算3.2 存算一体为什么天然适配推理场景推理时有一个天然优势模型权重是静态的。这意味着权重可以“烧”进存储单元阵列比如 ReRAM、PCM 这类器件。基本原理是基尔霍夫电流定律电流流过每条字线的电导刚好对应权重输入电压对应激活值输出电流自然就是加权和。这一步直接在存储体里完成连数据搬运都省了。理论上矩阵乘的能耗能比数字电路低一个数量级甚至更多。这个思路在学术上非常优雅工程上也在逐步落地。不少项目先做“近存”版本把 KV Cache 放进存储中让注意力部分的矩阵运算靠近数据先把访存带宽压力降下来。有些厂商已经在芯片里把存算一体单元和经典计算核心混布能先跑一部分可控的算子。对大模型推理来说存算一体尤其适合做“访存密集但算子简单”的部分例如 Attention 里的 QK^T、PV 乘法或者某些量化矩阵计算。这些部分放在存算单元上把带宽压力直接抹掉效果是立竿见影的。3.3 工程化挑战模拟计算的精度和集成度存算一体的难点也在这里模拟计算天然有噪声、温漂、器件波动。神经网络虽然有一定容错性但大模型后面接着 attention、softmax 这些非线性部分模拟域做线性乘加还行做非线性就非常麻烦。所以现实方案是“混合精度 协同计算”矩阵乘这类大的线性热点交给存算单元非线性、控制流、数据预处理交给数字核心或 CPU。这其实就是多芯协同在存算一体维度的落地方式。目前更成熟的商业路径还是近存计算和 HBM 集成。纯存算一体要达到规模商用还要再过几个工艺节点。但如果哪天 KV Cache 这一块真的被存算一体吃掉推理成本会发生一次质变。4. 多芯协同不是“拼硬件”而是“搭班子”4.1 多芯协同的系统架构多芯协同不是简单地把 GPU、ASIC、存算板卡插到同一块主板上就完事关键在任务切分与数据流编排。我把它分成三个层面来看节点内协同CPU、GPU、ASIC、存算模块共享统一的内存视图用一个任务调度器决定算子去哪个设备执行。CPU 适合处理动态 shape、稀疏控制流GPU 适合通用稠密矩阵ASIC 适合固定热点算子的批量执行存算模块负责访存密集但算子简单的部分节点间协同多台服务器之间用高速互联如 RoCE 或 InfiniBand连接把单机放不下的模型拆到不同节点同时做到负载均衡任务级协同推理服务本身有 prefill 和 decode 两个阶段两个阶段资源需求完全不同。prefill 是计算密集型decode 是访存密集型。已经有系统在做“prefill 用 GPUdecode 用专用芯片或存算资源”的分阶段调度效果非常明显做多芯协同的时候行业里经常踩的坑是把问题想成“硬件的排列组合”。协同之后显存容量、带宽、算子延迟、功耗是一套联动约束要用整体的眼光做问题建模而不是一块卡一块卡地去凑。4.2 单机多卡的调度实操PyTorch、Ollama 与设备指定实操层面先看 PyTorch。多卡推理有三条常用路径张量并行把一个大矩阵切成几块放到不同卡上A 卡算一部分列B 卡算另一部分列最后汇总。张量并行对互联带宽要求极高最好用 NVLink 或 InfiniBand 把卡连起来否则通信开销会盖过计算收益。我实测过一个 70B 模型的张量并行用 PCIe 互联的双卡比单卡还慢换成 NVLink 之后才有明显收益数据并行多张卡各自持有完整模型每张卡处理不同的请求适合并发量大的服务流水线并行模型拆成几个层段每张卡负责一段像流水线一样推进。单机多卡时均衡性不错但会有 bubble 开销Ollama 这类工具在 Windows 和 Linux 下指定 GPU 的逻辑是一样的设置 CUDA_VISIBLE_DEVICES 环境变量或者用 OLLAMA_DEVICES 来限卡。很多人在 Windows 上装了 Ollama 但发现它“未使用 GPU”大概率是显卡被别的进程占着或者 Ollama 内部的 CUDA 路径没配好也可能是驱动版本太旧。实操上我会先跑一句 nvidia-smi 确认驱动和 CUDA 可用性再在启动时指定设备最后用 ollama ps 查看模型加载情况。如果显示 GPU 列为 0 或者空白基本就是还在用 CPU。GPU 虚拟内存方面CUDA MPS、vGPU 这类技术本质是把一块物理显卡的资源切成多份给多个任务用。推理部署里常用 CUDA MPS 让多个进程共享计算和显存能有效提高利用率。但多进程共享也会引入调度延迟小 batch 场景下可能得不偿失必须实际测。4.3 GPU 运维视角下的多芯管理GPU 服务器运维不是一个“跑一下 nvidia-smi 看看占用”的活。真正的排查顺序是看温度、看功耗、看 PCIe 链路带宽、看显存 ECC 错误、看驱动版本与 CUDA 版本匹配关系。我遇到过几个典型的运维坑驱动装好后设备找不到最常见是与内核版本不匹配需要重新编译 DKMS显存明明够用但任务卡死很可能是显存碎片化可以考虑 CUDA MPS 或换 PagedAttention多卡利用率不均多半是数据加载线程成了瓶颈CPU 预处理跟不上在多芯环境里还要额外管理 ASIC 与存算设备的驱动、固件、算子库版本操作面大很多。运维侧建议把监控指标统一拉到同一个系统里别按厂商分开看。一个好的监控面板至少要覆盖每设备的利用率、温度、功耗、显存/片上内存使用任务排队时间互联吞吐量多芯协同的前提是“可观测”一个指标都看不到协同就是盲人摸象。5. 实操记录推理环境搭建与压测的避坑笔记5.1 驱动与基础环境CentOS 7.9 安装 GPU 驱动的要点CentOS 7.9 安装 GPU 驱动是一个老话题坑点依旧很多。我每次装都会按这个顺序走装驱动前先卸载旧 NVIDIA 驱动清掉 nvidia*、libcuda* 相关残留确认内核开发包和当前内核版本完全一致否则编译必然报错禁用 nouveau 驱动写入 /etc/modprobe.d/blacklist-nouveau.conf然后更新 initramfs 并重启用 runfile 方式安装配合 --no-opengl-files 参数避免和桌面环境冲突安装完成再装 CUDA Toolkit注意版本匹配我见过太多人在第 3 步翻车——nouveau 没禁干净重启后核心模块加载失败NVIDIA 驱动根本起不来。还有一种经典错误是 CUDA Toolkit 版本比驱动支持的新导致程序找不到可用设备。PyTorch 安装 GPU 版时最容易栽在 CUDA 版本上。torch 的 CUDA 版本必须和实际驱动兼容常用做法是先查 nvidia-smi 里显示的驱动版本再去 PyTorch 官网选匹配的安装命令别直接 pip 装默认版本完事。5.2 Ollama 的 GPU 配置与验证Ollama 在 Linux 下默认会枚举 GPU但有时候它选中了错误的卡。我一般这样处理启动前设置 CUDA_VISIBLE_DEVICES0指定第一张 GPU跑一个模型后执行 ollama ps 看 GPU 列配合 nvidia-smi 看进程占用确认显存上升和 GPU 利用率跳动如果 Ollama 提示未使用 GPU按这个顺序排查检查驱动版本老显卡老驱动可能不在支持列表里检查显卡是否被其他进程占用检查 CUDA_VISIBLE_DEVICES 是否被设置成了空值Windows 下可以考虑重置 WSL有时从 WSL 里跑反而适配更稳这类问题一旦跑通后续微调大模型时 GPU 调用逻辑是一样的——设置可见设备、调整 batch size、观察显存峰值。GPU 微调大模型的本质就是把数据并行和张量并行组合起来用同时控制好数据加载速度别让 GPU 停下来等数据。5.3 压力测试与多卡状态观测服务器装完驱动后跑一轮压力测试能暴露大部分部署问题。以 CentOS 7.9 为例我会用 stress 工具压 CPU同时用一个 GPU 压测脚本持续跑大矩阵乘再用 watch -n 1 nvidia-smi 观察各卡状态。压力测试重点看四类指标稳态温度是否打到保护阈值GPU 一般到 90℃ 附近会触发降频显存用量是否接近上限接近后容易 OOM功耗是否达到设计 TDP如果远低于 TDP说明负载没打满多卡之间互联链路是否出现带宽掉线有一次我压一台双卡机器发现第二张卡利用率始终在 0 和 100 之间跳最后定位到是 PCIe 链路降到了 x8 而不是 x16换了一个插槽解决。这种问题如果只盯平均利用率很容易被忽略。跑大型训练或推理集群之前把这些基础指标摸透能省下很多半夜救火的场景。6. 常见问题与排查技巧实录6.1 高频问题速查我在部署和调优过程中整理了下面这些高频问题基本覆盖日常运维的大多数情况。问题现象常见原因排查与解法Ollama 显示未使用 GPU速度很慢驱动版本不匹配、CUDA_VISIBLE_DEVICES 未设置、设备被占用先跑 nvidia-smi 确认驱动设置 CUDA_VISIBLE_DEVICES用 ollama ps 验证PyTorch 报 CUDA error: no kernel image availableCUDA 版本与显卡计算能力不匹配换匹配的 torch 版本或加入编译选项重新安装双卡之间互联带宽很低张量并行反而更慢PCIe 插槽位置不对、未启用 NVLink用 nvidia-smi topo -m 查看拓扑调整物理布局显存还有空间但程序一直 OOM显存碎片化、KV Cache 预留过大启用 PagedAttention调小 batch size必要时用 CUDA MPSASIC/存算设备无法被框架识别软件栈不兼容、算子未映射转换模型格式检查算子映射必要时嵌入自定义 kernel6.2 两个“特别想说”的排查实录第一个是双卡互联带宽问题。某次线上推理服务升级到 70B 模型双卡张量并行跑起来比单卡还慢。我用 nvidia-smi topo -m 一看两张卡虽然在同一个 NUMA 节点但互联走的是 PCIeNVLink 根本没启用。后来把卡插到支持 NVLink 的槽位delay 立刻降了一半。这件事给我一个教训多卡方案不是“插上去就行”物理拓扑对性能影响极大尤其张量并行这类通信密集型并行。第二个是显存碎片化问题。有人跑了一批推理任务nvidia-smi 显示显存只剩 2GB但每次启动新任务都报 OOM。后来发现是多个进程各自预留了 KV Cache碎片化严重。我建议他用 PagedAttention 的方案把 KV Cache 按页分配而不是为每个请求预留满额空间。调完之后同样的 80GB 显存能多扛 30% 的并发量。在推理侧做性能调优经验和日志分析比理论推演更靠得住。遇到问题先看现象再看指标最后动配置宁可多花五分钟看监控也不要盲目重启重装。写到这里我想再补几句实话。最近这一轮折腾下来我最深的体会是推理侧的未来不会是哪一种芯片的独奏而是 GPU、ASIC、存算一体各挑各的擅长领域再由多芯协同的调度把它们串成一台真正的机器。算法团队也别总觉得硬件是自己控制不了的黑盒——至少在模型结构稳定之后拆算子、量化精度、KV Cache 策略、显存规划这些事完全可以拿到选型桌上提前谈好。如果这篇笔记能帮你少熬夜调一次显存、少踩一个驱动坑那我就很满足了。