企业官网建设流程全解析

跑了几年大模型部署，我最大的感受是：不管训练阶段用的是哪家卡，最终把模型落到生产环境、跑推理服务的时候，选项正在悄悄变多。国产 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、语音唤醒、人脸识别等中小模型完全够用，是“边端”领域里最接地气的存在。

为了直观对比，我做了一张简表：

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, prompt=prompt, max_tokens=256) 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( source="rtsp://your_stream", # 本地图片/视频/摄像头都行 save=True, # 保存带标注的可视化结果 save_txt=True, # 保存 txt 格式的检测标签 save_conf=True, # 可视化结果上显示置信度 project="runs/detect", name="exp1", exist_ok=True ) 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_txt=True和save=True的配合：save=True生成的图片带可视化框，方便人工巡检；save_txt=True生成的 txt 文件可以直接喂给下游业务系统，比如自动存档、告警联动。如果你手里已经有摄像头配置，把source换成流媒体地址就能跑实时检测。

实际项目里，我还会把boxes.data转成 numpy 后写入数据库或消息队列，用于关联业务。这里有个细节容易被忽略：results是大数组，视频流跑久了内存会涨，建议每帧拿到数据后就释放引用，不要长期持有整个results列表，否则推理速度会越来越慢，最后直接卡死。

3.4 推理速度实测：tok/s 到底怎么测才不算“自嗨”

热词里“k100ai单卡推理qwen3.8:27b推理速度”这类问题，几乎每个做部署的人都会纠结。这里先说结论：别人报的任何 tok/s，包括我写的，都不能直接用来预估你的业务。推理速度受模型量化方式、输入输出长度、并发数、batch size、框架版本的影响太大，脱离负载谈速度都是自嗨。

正确测速至少要满足四个条件。第一，预热：先跑 5 到 10 轮请求再计时，否则算子初始化会严重拉低首轮数据。第二，分离 Prefill 和 Decode：Prefill 负责处理输入 token，Decode 负责逐字生成，两者速度差异巨大，混在一起看的“平均 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 延迟，比读一百篇发布会稿都有用。文里这些方法和坑，都是我从实际部署里摸出来的，希望你能在选型和落地时少走点弯路。