跑了几年大模型部署我最大的感受是不管训练阶段用的是哪家卡最终把模型落到生产环境、跑推理服务的时候选项正在悄悄变多。国产 AI 算力芯片这两年不再只是“备胎”和测试台上跑 demo 的角色已经出现了一批能稳定承接推理任务、覆盖边缘端场景的产品序列。这篇就把目前主流的品牌盘一遍聊聊为什么行业里都在说“推理与边端是突破口”再把我知道的部署细节、实测方法和踩坑记录一起写出来给做私有化推理部署、智能硬件和端侧 AI 的朋友一份能直接参考的清单。1. 国产 AI 算力芯片品牌全景盘点先给个整体判断现在没有任何一家国产算力芯片品牌能通吃“云—边—端”三个市场。训练场上有几个能打的推理场则有一拨更接地气的选手端侧还有一堆低成本 NPU 在默默出货。所以盘点品牌不能只看名气得先想清楚你打算跑什么任务。1.1 训练市场的主力玩家昇腾、海光、寒武纪华为昇腾是目前绕不开的一家。昇腾 910 系列训练卡、Atlas 训练服务器加上 310P 推理卡配合 CANN 软件栈构成了从训练到推理的相对完整闭环。昇腾的优势在于生态深度除了自有 MindSpore 框架主流开源大模型基本都有适配镜像或参考脚本做私有化部署时点名要填昇腾的客户非常多。尤其是金融、运营商、政企这类对数据本地化要求高的场景昇腾几乎是默认的候选。海光 DCU 走的是另一条路。深算系列在架构上对标通用 GPU对 CUDA 代码的迁移相对友好社区里不少基于 CUDA 写的算子能较快移植到 DCU 上。这个特点在推理项目里很加分因为很多开源模型的原生实现本身就是 CUDA 写的迁移成本低意味着你手上的技术栈不用推翻重来。海光的问题在于推理工具链没有昇腾那么“重”适合有一定研发能力、愿意自己配环境的团队。寒武纪思元系列像个多面手。思元 590 面向训练370 系列则是训练、推理都能做。寒武纪比较早就开始铺自家编译栈和框架适配OpenMMLab 等主流模型库有不少现成移植从算法到芯片的“最后一公里”有人在管。不过寒武纪在互联网大厂核心业务里的覆盖案例有限更适合算法团队自研模型的场景。这三家有一个共同点单卡算力标称值都不难看真正的瓶颈反而在集群互联和集合通信上。训练任务需要多卡并行、梯度同步、任务调度这些不是一块卡能解决的而是个系统工程。如果你主要做推理不一定非要上这些训练卡后面这些可能更划算。1.2 推理与边端的主力选择燧原、昆仑芯、沐曦、天数智芯、摩尔线程燧原科技的产品线分得很清楚云燧做训练邃思做推理后者在互联网推荐、广告场景里落地量相当大。燧原推理卡的特点是能效和性价比模型适配主要走 PyTorch 到算子库的路径适合那种“一个模型服务百万级请求”的业务对推荐系统和广告 CTR 预估这类场景尤其熟。昆仑芯是百度体系出来的P800 在搜索、信息流等场景里跑了好几年稳定性和工具链都是被真实流量磨出来的。如果要做国产化替代昆仑芯是替换存量推理服务时比较平滑的选项社区资料和踩坑记录也相对好找团队上手速度会快一些。沐曦这两年在大模型推理圈子里热度很高。曦云 C500 走训练方向曦思 N100 则是专门为大模型推理设计的单卡在大模型吞吐上做了不少工程优化。很多做 MaaS 的厂商在对比测试时对它评价不错主要原因是解码阶段优化做得比较到位KV Cache 管理和连续批处理的支持比同类芯片更顺手。天数智芯和摩尔线程属于通用 GPU 路线产品覆盖训练和推理兼容 CUDA 生态的力度都很大。摩尔线程的 MTT S 系列在不少实验室里被当“国产 PCIe 练习卡”用用来做适配验证、跑通流程很合适但生产环节的稳定性需要自己实测天数智芯的智铠系列则在科学计算和部分推理场景有落地。壁仞科技的 BR100 系列也曾是数据中心的热门选手受制于生态和出货节奏目前存量部署主要集中在特定项目里。它的架构设计在通用计算上有特点但工具链成熟度比起头部几家还有差距。做选型的话建议把壁仞放在“备选评估”而非首批验证里。再往边缘走还有一批你未必听过但出货量极大的品牌地平线的征程系列主打智能驾驶和机器人黑芝麻智能做智能驾驶芯片瑞芯微、晶晨、全志等公司的轻量级 NPU 则大量出现在 IPC、智能摄像头、门禁机、边缘盒子里。这些芯片不一定能跑十亿级大模型但跑 YOLO、语音唤醒、人脸识别等中小模型完全够用是“边端”领域里最接地气的存在。为了直观对比我做了一张简表品牌代表产品主攻方向典型场景华为昇腾昇腾910 / 310P训练推理全栈数据中心、私有化、大模型训练推理海光深算 DCU通用计算、训练推理科学计算、CUDA迁移项目寒武纪思元590 / 370训练推理自研算法团队、云服务燧原云燧 / 邃思训练推理互联网推荐、广告昆仑芯P系列推理为主搜索、信息流、国产替换沐曦曦云C500 / 曦思N100训练大模型推理MaaS、大模型服务天数智芯智铠通用计算、推理科学计算、边缘推理摩尔线程MTT S系列通用GPU适配验证、通用计算壁仞BR100数据中心通用计算国产化项目地平线 / 黑芝麻征程 / 华玉智能驾驶芯片车、机器人瑞芯微 / 晶晨 / 全志系列SoC轻量端侧NPU摄像头、边缘盒子2. 为什么推理与边端是国产芯片真正的突破口这几年行业里几乎没有争议的一个判断是国产 AI 算力芯片想在训练市场直接硬碰硬难度极大但在推理和边端市场机会正敞开着。这个判断不是情绪化的背后有很现实的技术和商业逻辑。2.1 训练市场的壁垒不只是算力而是“协同网”先拆解训练为什么难。训练任务的特征是数据量大、迭代次数多、需要大规模多卡并行而且并行效率极度依赖卡间互联带宽、集合通信库、集群调度器和网络拓扑。你可以把训练芯片想成一支打团战的军队单个士兵再强如果通信指令跟不上打起来就是各自为战。CUDA 生态沉淀了多年的分布式训练工具链很多都是开箱即用国产芯片要一一重写或适配工作量是几何级别的。这个门槛靠一两年堆硬件是抹不平的。国产芯片在单卡算力上头部产品已经追得相当接近但一上多卡集群实际利用率可能掉到 50% 甚至更低。训练场景里集群效率才是真正的分水岭这恰恰是后发者最难快速补课的部分。做训练的同行应该都体会过单卡 benchmark 跑得很漂亮一上分布式训练就原形毕露。同步开销、通讯拓扑、容错恢复任何一个环节出问题整个任务都得重来。所以训练市场的客户不敢轻易替换存量方案因为切换成本实在太高这是国产芯片短期内很难突破的“惯性壁垒”。2.2 推理是容错空间更大的“量变市场”推理任务和训练的画风完全不同。推理时模型已经固定不需要反复迭代更新参数更多是请求进来、计算出去。它不要求动辄几十 TB 的参数同步也不依赖复杂的多机互联单卡、双卡甚至单机就能扛过绝大多数业务。这意味着国产芯片可以避开最难啃的集群部分只需要把单卡吞吐和延迟做好就能在市场上立足。更关键的是推理对精度的容忍度更高。训练通常要求 FP32/FP16 高精度推理阶段可以降到 FP16、INT8、甚至 INT4 量化。损失一点精确度来换取吞吐翻倍绝大多数业务都愿意接受。这种容错性给了国产芯片在算子精度优化上足够大的腾挪空间——哪怕某些算子实现不如国外芯片精细只要量化后模型精度达标用户不会计较中间过程的浮点差异。推理市场还是典型的“量变市场”。同一个模型每天成千上万次调用单次成本降一点点全年总成本差异就非常可观。国产卡只要在性价比上站住脚替换动力就很足。这几年不少大厂在推理侧落地国产卡与其说是被形势推着走不如说是算过账后发现只跑推理确实划算。要说影响范围这波“从训练到推理的注意力转移”几乎重新定义了国产 AI 芯片的整个赛道优先级。2.3 边端碎片化反而让国产品牌获得“主场”优势边缘端和终端场景跟云端完全不同。云端是少数几套标准硬件服务海量请求边缘端则是一个个孤岛工厂里要跑质检模型门店要跑客流统计无人小车上要跑目标检测变电站里要跑指针读数识别。每个场景对算力、功耗、成本、模型尺寸的要求差异巨大这种碎片化让国外大厂很头疼因为它们的商业模式通常以通用芯片为主不太愿意为一个几万片的细分场景单独定制。国产芯片公司恰恰擅长“贴身服务”能改算子、能出定制板卡、能陪跑落地。很多行业对数据本地化和国产硬件又有硬性要求等于给国产品牌发了一张优先入场券。反过来看机会不等于躺赢边缘碎片化同样意味着适配成本高场景不标准化、模型迭代快、交付周期短。谁能帮客户多做一步“软硬协同”谁才能真正吃到红利。3. 推理落地实操框架选型、量化思路与结果保存市场逻辑说完了落到具体干活。这一部分全是这几年我实际跑过的流程从推理引擎、量化部署、检测模型的结果保存到速度测试每一步都有能直接抄的配置和思路。3.1 推理引擎选型从 vLLM 到 nano-vllm跑大模型推理时几乎不会裸写模型的 forward 过程而是用推理引擎。vLLM 是目前社区最常用的一种它能在同样一张推理卡上服务比原生 Transformers 管线多几倍的请求。vLLM 的核心价值可以概括为四点连续批处理解决 GPU 空转问题PagedAttention 把 KV Cache 分页化来提升显存利用率投机采样用小模型先草拟再大模型验证来加速解码量化支持则直接覆盖 GPTQ、AWQ、FP8、INT8 这类常见格式。部署一个服务很简单参考命令如下vllm serve Qwen/Qwen3-27B \ --tensor-parallel-size 1 \ --max-model-len 32768 \ --quantization awq \ --served-model-name qwen27b如果你是刚接触这块我非常建议先读一遍 nano-vllm 这类精简实现。它把大模型推理的核心功能拆成了请求调度、KV Cache 管理、token 生成循环几个模块代码量少、注释清楚。我花了两个晚上把逻辑顺下来之后再回来看 vLLM 源码很多名词都不再是黑话。理解原理对后面排查性能问题非常有帮助。其实不止语言模型像 ST-GCN 这类行为识别模型推理落地的套路也一样先选推理框架再规划内存和批处理策略不要一上来就裸写算子、与框架底层较劲。3.2 端侧量化推理以 Qwen3 27B 的 4-bit 玩法为例最近讨论度很高的一个方向是端侧跑大模型热词里也有“mlx 4-bit 推理”“Qwen3 27B 跑在个人设备上”这类话题。端侧量化确实是大模型普及的一个拐点。以 MLX 为例它是苹果生态里的机器学习框架对 Apple Silicon 做了针对性优化支持直接加载 4-bit 量化模型。代码量很少from mlx_lm import load, generate model, tokenizer load(mlx-community/Qwen3-27B-4bit) prompt 给我讲讲国产GPU芯片的发展现状 response generate(model, tokenizer, promptprompt, max_tokens256) print(response)这个例子的意义不在于用了哪个平台而在于它证明了一个 27B 的模型量化到 4-bit 之后权重大约只有 15GB 左右塞进一台高性能个人设备的显存绰绰有余。对大模型推理来说内存占用下降会带来两个直接收益一是显存装得下了二是内存带宽瓶颈被缓解解码速度明显提升。如果你要在国产 NPU 或推理卡上部署类似模型思路是相通的先用 AutoGPTQ 或 llm-compressor 把模型量化成 4-bit再导出成目标芯片要求的格式。需要提醒的是4-bit 模型能跑但精度会下降有些算子在端侧 NPU 上根本不存在会自动回退到 CPU 实现一旦回退速度可能掉一个数量级。所以量化方案定下来后一定要做“量化模型 真实业务 prompt 精度对比”的验收而不是只看标称速度。3.3 YOLOv11 保存推理结果容易被漏掉的最后一公里YOLOv11 是当前 CV 落地里用得最多的检测模型之一。“yolov11保存推理结果”这个热词恰好戳中了很多人的真实困惑——推理完不保存结果只留在内存里程序一重启全部丢失。这里给一段可以直接抄的完整流程from ultralytics import YOLO model YOLO(yolo11n.pt) results model.predict( sourcertsp://your_stream, # 本地图片/视频/摄像头都行 saveTrue, # 保存带标注的可视化结果 save_txtTrue, # 保存 txt 格式的检测标签 save_confTrue, # 可视化结果上显示置信度 projectruns/detect, nameexp1, exist_okTrue ) for i, r in enumerate(results): boxes r.boxes.data.cpu().numpy() # 每一行: [x1, y1, x2, y2, conf, cls] cls_names [model.names[int(c)] for c in boxes[:, 5]] print(f第{i}帧检测到: {cls_names})代码里最关键的是save_txtTrue和saveTrue的配合saveTrue生成的图片带可视化框方便人工巡检save_txtTrue生成的 txt 文件可以直接喂给下游业务系统比如自动存档、告警联动。如果你手里已经有摄像头配置把source换成流媒体地址就能跑实时检测。实际项目里我还会把boxes.data转成 numpy 后写入数据库或消息队列用于关联业务。这里有个细节容易被忽略results是大数组视频流跑久了内存会涨建议每帧拿到数据后就释放引用不要长期持有整个results列表否则推理速度会越来越慢最后直接卡死。3.4 推理速度实测tok/s 到底怎么测才不算“自嗨”热词里“k100ai单卡推理qwen3.8:27b推理速度”这类问题几乎每个做部署的人都会纠结。这里先说结论别人报的任何 tok/s包括我写的都不能直接用来预估你的业务。推理速度受模型量化方式、输入输出长度、并发数、batch size、框架版本的影响太大脱离负载谈速度都是自嗨。正确测速至少要满足四个条件。第一预热先跑 5 到 10 轮请求再计时否则算子初始化会严重拉低首轮数据。第二分离 Prefill 和 DecodePrefill 负责处理输入 tokenDecode 负责逐字生成两者速度差异巨大混在一起看的“平均 tok/s”没有意义。第三固定测试条件比如输入 512 token、输出 128 token连续测 50 次取中位数同时记录显存占用。第四记录 TTFT首 token 延迟交互式服务对 TTFT 非常敏感光看吞吐高但首 token 半天不出来用户体验照样崩。用 vLLM 自带的 benchmark 脚本可以跑一轮标准化的测试python -m vllm.benchmarks.benchmark_throughput \ --model Qwen/Qwen3-27B \ --quantization awq \ --tensor-parallel-size 1 \ --input-len 512 \ --output-len 128 \ --num-prompts 200 \ --max-num-seqs 8跑完之后你会得到一组包含吞吐、延迟、TTFT 的报告。拿这组数据去对比不同芯片才能真正看出哪个适合你的业务。我之前遇到过客户拿一份网上截图的 tok/s 来质疑测试结果后来统一了测试条件之后数据差异就完全在合理范围内了。这也说明测速规范比硬件本身更能决定你的判断。4. 常见问题与排坑实录再写点真正花时间踩过的坑。这些内容通常不在官方文档里是我在项目交付和客户现场反复遇到的问题希望能帮大家省下几周排查时间。4.1 推理速度上不去先查这四件事如果你发现模型在国产卡上跑得比预期慢很多别急着怪芯片先按顺序查这四个点。第一显存带宽是否用满。大模型推理本质上是带宽密集型任务解码阶段要反复读写 KV Cache显存带宽不够算力再高也是空转。运行时工具里可以看显存带宽利用率如果持续低于 60%说明瓶颈不在芯片算力而在数据搬运。第二连续批处理是否开启。有些推理引擎默认没开动态 batching每批请求都要等当前 batch 全部跑完才进入下一批吞吐差距可以达到数倍。去引擎配置里确认 continuous batching 或 dynamic batching 是开启状态。第三量化位宽和权重格式是否合理。W4A16、W8A8、FP16 各有适用场景4-bit 权重能大幅降低显存需求但某些国产芯片对 INT4 支持不完善一旦走回退路径反而比 FP16 更慢。用性能分析工具看算子回退日志能直接定位问题。第四输入输出张量是否连续。在边端 NPU 上跑模型时如果输入 tensor 不是连续内存驱动会频繁做格式化拷贝开销极大。尽量保持数据批量、通道、尺寸一致减少动态 shape这个优化在边缘盒子上效果尤其明显。4.2 国产芯片适配时的典型坑算子覆盖不全是国产芯片适配时最常见的坑。模型里某个特殊激活函数或 attention 变体芯片的算子库没有实现跑起来要么报错要么静默回退到 CPU。解决思路是先打开算子回退日志定位到具体算子再用等价实现替换。我曾经排查一个行为识别模型慢得离谱最后发现是模型里一个 GroupNorm 的 epsilon 处理方式跟芯片算子实现不一致触发了逐层回退性能直接跌到不可用。精度不一致是第二个坑。同一个模型在 GPU 上和国产卡上结果差一点点大概率是算子内部的浮点中间精度不同比如有的实现用 FP32 累加有的用 FP16 累加。部署时建议开启确定性计算模式虽然会牺牲一点性能但换来的是结果可复现对需要审计的业务来说非常关键。驱动、框架、芯片 SDK 的版本绑定是第三个坑。国产卡的软件栈更新节奏和开源社区不完全同步经常出现“升级了驱动模型推理性能反而下降”的情况。我的做法是固定一版经过验证的组合写在部署文档里明确标识“未经测试不要升级”这是我在现场吃过亏之后养成的习惯。4.3 “工具链兼容性设置”这类问题的通用解法热词里“opencode 设置兼容推理”这类问题本质上都是同一件事上层开发工具默认配置不适合推理任务。很多开发环境会默认开启自动混合精度、自动并行、线程池大小调整等特性这些在训练或通用计算时是加分项但在推理场景可能适得其反。通用排查步骤很简单我建议按顺序走先把开发工具和推理框架都升级到稳定版排除版本兼容问题然后只修改与推理直接相关的开关比如采样温度、max token、上下文长度不要一上来就乱动全局配置再用独立容器或虚拟环境跑推理避免和其他任务的环境变量互相污染最后写一个最小复现脚本把模型、输入、参数全固定下来再挨个开关测试用二分法定位问题。这个方法在边缘设备上尤其好用因为边端盒子经常同时跑多个任务环境变量、内存池、线程数互相干扰的情况太常见了。先隔离再最小化几乎能解决一半的疑难杂症。我见过太多同事花一整天查性能问题最后发现只是 root 用户的 PATH 里混进了一套旧驱动这种低级问题用隔离环境一测就现原形。我个人的经验是选国产 AI 算力芯片时别只盯着纸面 TOPS也别只迷信大品牌。推理和边端之所以成为突破口是因为这个赛道拼的是“适配速度、工程服务、单卡性价比”而不是“集群规模”。你拿一张推理卡跑一遍量化后的业务模型测一测吞吐和首 token 延迟比读一百篇发布会稿都有用。文里这些方法和坑都是我从实际部署里摸出来的希望你能在选型和落地时少走点弯路。