企业官网建设流程全解析

一家电视与家电巨头把AI芯片代工订单从台积电切换到三星，这条新闻在消费电子圈很容易被读成一句普通的供应链消息。但如果把视角切到做嵌入式AI和智能家居的开发者身上，它背后牵出的问题要具体得多：AI家电芯片到底是一颗什么样的芯片？为什么它非要找代工厂？换一家代工，对底层BSP、NPU工具链、模型部署和产品送测这些环节会带来哪些连锁变化？

先把判断放在前面：LG选择三星代工，短期看是产能与成本的账，长期看是终端厂商在AI芯片供应链上从“单点依赖”走向“双供应商备份”。对开发者来说，这意味着接下来你会面对更多不同代工厂出身、不同NPU指令集、不同工具链的AI SoC。过去只认某一家芯片原厂的日子会结束，适配与验证能力会变得更重要。

这篇文章不打算做新闻复述，而是从三个层面展开：第一，AI家电芯片的技术构成和它为什么离不开代工；第二，LG把订单从台积电换到三星，对芯片设计、流片验证和量产会产生哪些真实变化；第三，站在嵌入式AI开发者的角度，如何应对SoC启动、NPU工具链、模型部署、芯片测试这些环节中的实际问题。最后会给出一个最小可行的端侧AI实践，以及一套面向多供应商芯片的工程建议。

1. 这篇文章真正要解决的三个问题

这则新闻看起来是“公司A找公司B代工”，对普通开发者来说，最直接的反应可能是“跟我有什么关系”。但如果你的工作涉及AI家电、智能家居或端侧AI应用开发，关系非常直接，因为芯片加工方式的变化，会通过产品形态传导到你的代码、编译参数、驱动接口和测试流程上。

第一个问题是选型问题。以前推一款智能家电，方案基本上是某颗固定SoC或者MCU，换供应商往往意味着从原理图到驱动全部重来。现在头部家电厂商开始主动管理芯片供应链，同一个产品可能同时评估多家代工厂、多个芯片原厂方案。开发者要接受一个现实：上游会越来越多地把“同一功能在不同芯片上跑”，而不是“永远只维护一款芯片”。

第二个问题是适配问题。AI芯片要真正落地，不是芯片本身做出来就行，还必须有一整套软件开发链条：Boot ROM引导、Linux内核适配、NPU驱动、模型转换工具、推理运行时、OTA升级。换代工厂不等于换外壳，它会影响晶圆制程、IP组合、寄存器布局以及芯片原厂SDK的底层实现。这些变化最终都会出现在开发者的编译日志和调试串口里。

第三个问题，也是更实际的问题：终端厂商和越来越多模组公司，都在把AI能力往设备端下沉。设备端芯片越来越像一台“边缘AI服务器”，需要同时处理语音、视觉、传感和控制。如果你不理解SoC启动、NPU算子支持和模型量化之间的关系，会在产品从送样到量产的过程中持续踩坑。

这篇文章正好把这些问题串起来。它不是某一颗芯片的手册，而是一张从供应链到开发板的“问题地图”，帮你判断下一代AI家电平台选型时该看哪些指标，该在什么阶段验证什么。

2. AI家电芯片为什么是一类特殊芯片

2.1 从云端AI到端侧AI：家电为什么要装NPU

过去很多智能家电的“智能”只是把摄像头或麦克风数据传到云端，由云端AI大模型处理，再把结果返回。这种方法部署简单，但有几个根深蒂固的问题：网络一抖，语音助手就变笨；视频流一直上传，隐私压力很大；每次交互往返几百毫秒，控制空调、门锁这类实时设备体验不好；云端推理按次计费，长期运营成本居高不下。

端侧AI家电芯片解决的就是这个问题。芯片内部集成CPU、NPU（神经网络处理单元）、DSP、ISP、音视频编解码和各类外设接口，音频唤醒、人脸识别、宠物识别、跌倒检测、食材识别这些任务直接在本地完成。以一台智能冰箱为例，摄像头识别冰箱里的食材，NPU完成图像分类，CPU根据分类结果管理食材库存和保鲜策略。即使断网，也能继续工作。

2.2 AI家电芯片的技术组成

AI家电芯片不是一颗简单的MCU，而是一颗面向特定场景的SoC，关键模块包括：

• CPU：负责运行应用程序、操作系统和业务逻辑，常见的是Cortex-A系列或多核RISC-V。
• NPU：做卷积、矩阵乘、激活函数等AI算子，是芯片算力的主要来源。
• ISP：处理摄像头输入，自动曝光、白平衡、降噪，直接影响图像识别准确率。
• DSP：处理音频信号，负责语音唤醒、回声消除和麦克风阵列。
• 视频编解码单元：用于视频监控、门锁可视对讲、电视画质处理。
• 安全单元：负责密钥存储、安全启动和固件防篡改。

这类芯片目前的演进趋势是往“大模型端侧化”走。比如语音助手从单纯的命令词识别转向自然语言理解，图像识别从分类模型升级到目标检测和语义分割模型，甚至跑轻量化大模型。这要求NPU不仅支持常见CNN算子，还要支持Transformer结构中的Attention、LayerNorm等算子。“AI大模型”“AI Agent”并不是只在云端，未来家电端也会出现承担部分Agent功能的芯片。

2.3 一颗芯片为什么要做出来这么复杂

因为家电产品不是开发板。它需要低成本、低功耗、高可靠性，还要在每年数百万台的出货量下保证一致性。CPU可以买ARM IP，GPU/NPU可以买加速器IP，但把这些东西集成在一起，完成前后端设计、验证、流片、封装测试，再写出稳定BSP，是一个系统工程。这也是为什么终端厂商通常不会自己建晶圆厂，而是找台积电、三星这类代工厂合作。芯片设计公司负责架构和代码，代工厂负责把设计变成物理芯片。你手上那颗能跑TensorFlow的AI模组，背后其实是一条包含数百道工序的制造链条。

3. 代工模式与LG换供应商的技术逻辑

3.1 IDM、Fabless与Foundry是什么

在聊LG和三星之前，先理清半导体行业的三种模式：

• IDM（集设计、制造、封测于一体）：比如三星电子自己设计芯片也自己生产，Intel过去也长期如此。
• Fabless（无晶圆厂）：只做芯片设计和销售，不建晶圆厂，典型代表是苹果、高通、联发科、海思。
• Foundry（代工厂）：只负责制造，不设计终端芯片，典型代表是台积电、三星代工、中芯国际。

LG电子作为终端品牌，具备电视SoC和家电控制芯片的自主设计能力，但它不是大规模IDM，也不会为所有家电芯片自建先进制程产线。所以它设计完一颗AI家电芯片后，必须把版图交给代工伙伴生产。“LG委托三星代工”这个动作，本质上是用三星的晶圆厂资源，换掉原先在台积电的产能。对LG来说，无论最终订单比例如何，都增加了供应链的灵活度，这是更稳妥的判断。

3.2 台积电和三星代工的差异点

这里先明确，代工厂与代工厂之间的差异，不只是“谁工艺更先进”，还涉及IP生态、设计规则、PDK（工艺设计套件）、标准单元库和流片服务。

从产业逻辑看，LG选择三星，除了降低对单一供应商依赖，还有一个容易被忽略的协同点：三星在屏幕、存储、传感器和生产自动化上同样有布局，LG和三星虽然在消费市场是竞争对手，但在供应链层面可以形成更紧密的配合。芯片的迭代、测试和定制开发，离代工厂近一点，沟通成本会更低。这是一种典型的“竞合”关系。

3.3 换代工厂，对芯片本身意味着什么

从芯片设计流程来看，一家企业决定切换代工厂，会牵扯到很多环节：数字前后端设计要按新的PDK重做时序收敛，标准单元库要更换，SRAM、模拟IP、GPIO等IP要重新评估，芯片测试向量要调整，封装和可靠性验证也要重新走一遍。即使逻辑功能不变，一颗芯片在物理层面已经发生了改变。

对于家电AI芯片来说，这种改变最终会体现在寄存器地址、时钟频率、中断号、电源域和启动方式上。你在开发板上看到的现象可能就是：同样的启动流程，在某芯片上能从SD卡启动，在另一个芯片上却只能从eMMC启动；同样的摄像头型号，在某个平台上驱动可用，在另一个平台上却需要改上电时序。这些不是玄学，而是代工切换和IP变化带来的连锁反应。

既然提到SoC启动，下一节就直接进入这个环节，这也是很多从MCU转做AI芯片的开发者最不熟悉的部分。

4. 从SoC启动到量产：AI芯片开发链条上的关键环节

4.1 一颗AI SoC的启动流程

家电AI芯片通常跑嵌入式Linux，它的启动流程可以简单拆成下面几个阶段：

• Boot ROM：芯片内部固化的第一段代码，负责从外部存储读取引导程序，一般无法修改。
• BL1/BL2（或预引导加载）：完成DDR初始化、时钟配置、安全启动校验，然后加载下一级引导。
• ATF（Arm Trusted Firmware）或类似安全固件：建立可信执行环境，处理安全启动链。
• U-Boot：初始化外设、加载设备树和内核镜像。
• Linux内核：启动驱动、挂载文件系统，最终运行用户态AI推理程序。

在开发板阶段，最常见的调试方式就是连接串口和JTAG/SWD调试器。如果你的芯片进入不了内核，第一件事永远是看串口打印停在哪个阶段。停留位置不同，排查方向完全不同。

4.2 回片后Bring-Up的常见操作

芯片回片之后，硬件工程师和嵌入式工程师要一起做Bring-Up，也就是让这颗裸芯片从“能上电”走到“能跑代码”。比较常见的做法是：先按住芯片复位键，在调试软件里点连接，连接成功后松开复位键，然后再擦除或下载固件。这个操作的本质是让调试器在芯片刚上电、CPU还没跑乱的时候介入，保证调试器能拿到CPU控制权。如果你遇到过“连不上SWD”“下载器报错”之类的问题，很可能就是复位时序没有配合好。

# 示意：GDB 远程调试时先连上，再触发复位 # 具体端口和命令以调试器厂商工具为准 target remote :3333 monitor reset halt load u-boot.elf resume

这一步看起来简单，但在AI芯片上尤其重要，因为NPU和多媒体子系统经常会抢占总线或进入异常状态。连不上调试器时，可以先用示波器确认复位引脚和电源时序，再检查调试器速率是否过高，最后再把复位保持时间拉长一些。

4.3 从启动到量产需要做哪些测试

一颗AI家电芯片能不能量产，不只是启动一次就够。还要做：

• 芯片测试：包括晶圆测试和成品测试，确保每颗芯片的频率、功耗、IO都符合规格。
• 压力测试：长时间跑NPU负载和多媒体负载，观察温度、电流和性能是否漂移。
• 老化测试：模拟多年使用环境，验证可靠性。
• 安全测试：检查安全启动、密钥保护和加密通信。

这些工作大多数看起来是硬件工程师的事，但软件工程师也要参与。因为测试过程中需要大量的驱动和脚本支持，而且量产之后出现功能异常，第一步要看的就是芯片日志和内核日志。一个良好设计的日志系统，能节省大量问题定位时间。

5. 端侧AI开发者的最小实践：从模型到NPU推理

前面的内容偏供应链和芯片架构，接下来进入真正能动手的部分。假设你现在要在一颗AI家电芯片上实现一个“食材识别”功能，但手头还没有最终模组，你可以先用通用开发板或电脑跑通模型转换和ONNX推理流程，之后再替换成目标NPU runtime。这里用到的是完全公开的工具链，不绑定某一家芯片原厂。

5.1 第一步：把PyTorch模型导出成ONNX

在训练阶段，模型通常用PyTorch保存为.pt，但NPU工具链一般不能直接吃PyTorch格式，需要先导出成ONNX。以下是一个最小导出脚本。

# 文件路径：export_onnx.py import torch import torch.onnx # 假设已经有了一个训练好的分类模型，这里是示意加载方式 model = torch.load("food_classifier.pt", map_location="cpu") model.eval() dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, "food.onnx", input_names=["input"], output_names=["output"], opset_version=11, dynamic_axes={"input": {0: "batch"}, "output": {0: "batch"}}, ) print("ONNX model exported at food.onnx")

这里需要解释几个关键点。opset_version=11是一个兼容性选择，太高版本可能在部分NPU工具链上不被支持，太低又可能缺少新算子；dynamic_axes允许batch维可变，但如果你确定推理时batch永远是1，也可以去掉这个参数。导出之后，建议先用onnxruntime检查一遍ONNX模型是否能正常运行，排除算子兼容问题。

5.2 第二步：用ONNX Runtime在开发板上验证

很多NPU工具链都提供了“PC模拟器”和“板端runtime”。在没有NPU环境时，先用CPU执行ONNX模型，可以验证预处理和后处理逻辑是否完整。下面是一个简单的推理脚本。

# 文件路径：infer_onnx.py import cv2 import numpy as np import onnxruntime as ort # 读取一张本地图片，模拟摄像头输入 image = cv2.imread("apple.jpg") image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB) image = cv2.resize(image, (224, 224)).astype(np.float32) / 255.0 # 按模型的预处理要求调整通道顺序 image = np.transpose(image, (2, 0, 1)) input_tensor = np.expand_dims(image, axis=0) # 创建 ONNX Runtime 会话 sess = ort.InferenceSession( "food.onnx", providers=["CPUExecutionProvider"], ) outputs = sess.run(None, {"input": input_tensor}) pred = np.argmax(outputs[0], axis=1)[0] print("predicted class id:", pred)

在这个阶段，运行结果不依赖任何NPU硬件，核心目的是验证模型图结构和数据流。如果输出结果和PyTorch不一致，优先检查预处理归一化、通道顺序和resize插值方式。到了这一步，你已经完成了端侧AI应用开发里最不依赖硬件的一部分。

5.3 第三步：接入NPU设备树

当产品真正选用某颗SoC后，NPU和摄像头通常需要在内核设备树里配置。下面是一个示意片段，实际地址和中断号必须以芯片原厂手册为准。

// 文件路径：arch/arm64/boot/dts/board/ai-home.dts / { npu: npu@12300000 { compatible = "vendor,ai-npu"; reg = <0x0 0x12300000 0x0 0x100000>; interrupts = <0 42 4>; clocks = <&cru NPU_CLK>; power-domains = <&power NPU_PD>; status = "okay"; }; camera0: camera@34500000 { compatible = "vendor,camera-sensor"; reg = <0x0 0x34500000 0x0 0x1000>; reset-gpios = <&gpio3 10 GPIO_ACTIVE_LOW>; pinctrl-names = "default"; pinctrl-0 = <&camera0_pins>; status = "okay"; }; };

设备树是Linux内核和硬件之间的一座桥。摄像头挂在哪条I2C总线、GPIO编号是多少、NPU的时钟和电源域怎么接，都要在上面体现。如果设备树里的寄存器地址写错，驱动能加载但访问会出错，严重时会导致整个内核崩溃。所以拿到新平台的第一个任务，通常是对照原理图和原厂Linux内核，把设备树里的节点逐一核对清楚。

5.4 第四步：在目标NPU上编译和运行

ONNX模型不能在NPU上直接运行，需要经过原厂工具链转换成NPU专属指令集模型文件。不同厂家的转换命令差异很大，但逻辑都是类似的三步：导入模型、配置量化参数、生成可执行模型。

# 示意命令：不同NPU工具链的命令不同，请以芯片原厂工具链为准 npu_convert --framework onnx \ --model food.onnx \ --output food.npu \ --quantization asymmetric \ --calibration_data calibration/ \ --target_platform ai_home_npu_v1

转换完之后，在你的C/C++程序里调用NPU runtime加载模型。大多数厂商SDK提供的操作方式类似：

// 示意：NPU推理伪代码，实际API以原厂SDK为准 #include <npu_runtime.h> npu_context ctx; npu_model model; npu_init(&ctx); npu_load_model(&ctx, "food.npu", &model); npu_input input = {0}; npu_output output = {0}; prepare_input(&input, camera_frame); // 把摄像头帧转成模型输入 npu_run(&model, &input, &output); printf("class = %d, confidence = %.3f\n", output.top_class, output.top_score); npu_release_model(&model); npu_deinit(&ctx);

这里最重要的是理解“模型转换不是透明过程”。ONNX里的算子数量、算子类型、张量排布，都会影响转换成功率。更常见的情况是，一个模型在PyTorch里跑得很好，转成ONNX也没问题，但进入NPU工具链时报“Unsupported Op”。这种问题通常只能通过改写模型算子、拆分子图或升级工具链解决。

6. 运行结果与效果验证

模型部署不是烧进去就结束，还要在真实环境和模拟条件下验证效果。这里列出典型的运行命令和判断标准。

# 板端运行ONNX/Runtime推理程序 ./infer_onnx --model food.onnx --image test.jpg # 预期输出示例 [INFO] model loaded: food.onnx [INFO] inference time: 45.6 ms on CPU predicted class id: 3, confidence: 0.92

如果是NPU环境，重点看三个指标：推理时延、吞吐量和端到端精度。对于家电场景，语音唤醒要求时延一般在几十毫秒级别，图像识别可以放宽到几百毫秒，但连续识别时不能有明显的卡顿。精度指标则要与云端模型做对比，不能只看准确率掉没掉，还要看误报率有没有升高。

# 查看NPU利用率、温度和频率 cat /sys/class/devfreq/*/cur_freq cat /sys/class/thermal/thermal_zone*/temp # 查看内核日志中与NPU、摄像头相关的错误 dmesg | grep -E "npu|camera|iommu|error"

如果运行失败，第一步看的是日志，不是改代码。很多NPU错误会通过内核日志丢弃或打印在stderr里，比如“Allocate memory failed”“IOMMU fault”等。先用这些信息确认问题是驱动层、运行时层还是数据层，再决定排查方向。

7. 常见问题与排查思路

结合前面提到的SoC启动、NPU工具链和代工切换相关风险，整理一张排查表。

这张表解决的是“现象 -> 原因”的定位思路。实际项目里，很多问题是交叉出现的，比如NPU时延高可能是设备树里没有配置热管理策略导致的降频，也可能是因为DMA buffer没有复用。建议每次只改一个变量，记录日志，再继续下一轮测试。

8. 最佳实践与工程建议

8.1 供应链层面的建议

如果你所在的公司现在开始评估AI家电芯片，我建议不要等到产品定稿才找芯片供应商。至少提前两个季度锁定候选方案，同时送样验证两块不同来源的模组，分别跑相同的功能和压力测试。多供应商策略不是把成本最低的方案选出来，而是要对“第二家方案”的真实成熟度做到心中有数。很多团队只验证了主方案，备胎方案一旦启用，发现BSP还缺模块，这是最糟糕的情况。

对终端厂商来说，“摆脱对台积电依赖”并不是完全不用某一家代工厂，而是引入冗余。真正的