企业官网建设流程全解析

当一家 AI 公司开始冲刺上市，市场最先追问的往往不是模型排行榜上又前进了几名，而是它的能力到底能转成多少现金流、覆盖多少真实场景。面壁智能这轮被资本市场关注，技术叙事上有一个非常明确的落点：端侧 AI。换句话说，这家公司正在试图回答一个所有端侧模型厂商都绕不开的问题——大模型能力的价值，能不能脱离云端的昂贵算力，在用户手边的设备上被重新兑现。

端侧这个词本身并不新鲜，手机厂商早就把 NPU、端侧语音助手当作卖点。新鲜的是，如今大模型公司开始把“跑到用户终端上”当作产品的前提，把端侧 AI 硬件部署当作工程体系来建设，而不是实验室里的一个 demo。这种变化背后，是推理成本、隐私合规、离线可用性和交互体验的多重压力：如果每一个智能功能都要把用户语音、图片、文档片段传到云端，AI 企业的边际成本就无法被商业模式消化。而如果一部分推理能够在手机、PC、汽车和工业终端上完成，单位成本更低，数据不出设备也能成为可承诺的安全卖点。

本文不打算重复“端侧 AI 是未来趋势”这类正确废话，而是从面壁智能的上市叙事切入，拆解一个更实际的问题：端侧 AI 的价值到底由什么决定？在硬件约束和工程优化的前提下，我们应该如何判断一个端侧模型是不是真的“有用”？开发者在接入端侧 AI 推理时，会遇到哪些坑，又应该如何评估和避坑？

1. 上市叙事背后：端侧 AI 必须回答的三个商业问题

一家科研背景浓厚的 AI 公司冲刺上市，市场听故事的方式和刷论文完全不同。故事里可以有“更强的小参数模型”，但如果没有回答清楚三个商业问题，端侧 AI 这条叙事就立不住。

第一个问题是：用户为什么需要端侧智能？如果用户永远处于网络稳定、可以接受几秒延迟的环境中，云端大模型的服务质量已经足够好。但现实是大量场景出现在网络不稳定、流量敏感、隐私要求高的环境中。会议记录、邮件摘要、车载语音、医疗影像辅助判断、工业质检，这些任务一旦需要把原始数据传到云上，要么延迟不可控，要么合规上不去。端侧 AI 真正的用户价值，不是“不用联网”这个功能点，而是“数据不出设备”带来的安全感和“响应不依赖网络”带来的确定性。

第二个问题是：为什么现在能落地？过去做端侧 AI，模型动辄几十亿参数，手机 CPU 根本吃不消，量化后精度又损伤明显。现在这个问题之所以被重新讨论，并不是因为模型突然变小了，而是整个链路成熟了：模型压缩方法更稳定，NPU 等异构算力成为终端标配，ONNX Runtime、NCNN、MNN 等推理框架逐步补齐了底层支持，端侧大模型才从“能跑 demo”走向“能被产品集成”。

第三个问题是：AI 公司的护城河到底在哪里？端侧 AI 的竞争早已不只是模型参数量的竞争。谁更懂某款芯片的算子库，谁有更成熟的量化工具链，谁在真实机型上踩过更多坑，谁的系统在高温、低电、弱网下还能保持稳定，这些工程细节才是护城河。也可以说，面壁智能需要向资本市场证明的不是它能训练出一个小模型，而是它能把一个“平均水准偏上的模型”稳定部署到大量异构设备上，并让用户持续为之付费。

从公开资料和模型发布动作看，面壁智能在端侧 AI 上的故事主线，是“用中小参数模型搭配端侧部署工具链，在用户手边完成推理”。这并不仅仅是压缩模型，而是从模型选型、推理引擎到硬件适配的全链路工程。上市只是把这个问题摆到台面上，真正的答卷要在实际项目里交出来。

2. 端侧 AI 价值的本质：在约束条件下完成有效任务

很多开发者会把端侧 AI 理解为“把大模型缩到手机能跑”，这个判断只对了一半。缩小模型只是手段，端侧 AI 的价值本质是在资源约束条件下完成真实业务任务，并且让这套系统在单位成本上可被接受。

有人习惯用参数量、Top-1 准确率、MMLU 分数来给端侧模型排座次，这其实是把实验室评估直接搬到了生产环境。端侧模型真正被用户感知的指标，往往更朴素：冷启动要多久，首 Token 延迟高不高，连续使用半小时后会不会降频，断网时能不能正常给出结果，内存会不会被挤爆。模型在服务器上跑得再快，只要目标设备上内存峰值过高，就无法成为产品的一部分。

为了更清楚地说明端侧 AI 的价值，可以把它与云端 AI 放在同一张表里做对比。

从表格中能看到一个结论：端侧 AI 并不是云端的替代品，而是云端的补充。两者之间不是非此即彼的关系，而是按场景、按成本、按隐私要求做分布式部署。真正有商业价值的架构，通常是端云混合架构：简单、高频、隐私敏感的任务由端侧完成，复杂推理和模型持续更新仍由云端兜底。

把“端侧 AI 的价值”翻译成工程语言，其实是三个数字：一是在目标设备上单位时间能完成多少次有效推理，二是每次推理占用的内存与功耗是否在可接受范围内，三是这套本地推理方案能为云端节省多少成本。脱离了这三点去谈“模型能跑在端侧”，意义很有限。

3. 端侧 AI 硬件部署：真正的难点其实不在参数

端侧 AI 硬件部署，术语听起来很直白，就是让模型在目标设备上跑起来。但一旦进入真实产品，它会立刻拆成无数细节。

第一层约束来自硬件本身。手机、PC、车载座舱、摄像头、工业网关的性能差异极大。同一个模型在旗舰手机上可能很流畅，换到中低端设备上就可能内存爆掉。NPU、GPU、DSP、CPU 的算子支持范围也不同，PyTorch 训练出来的模型不能直接在 NPU 上运行，需要经过一系列图优化和算子映射。很多项目在电脑上验证没问题，一搬到 ARM 设备上就出现算子不支持或速度反而更慢的情况，原因就在这一层。

第二层约束来自内存与功耗。当前的生成式模型，哪怕只有 1B 到 3B 参数，权重加载也不是一个小数目。端侧设备的运行内存通常有限，而且需要给操作系统、上层应用预留空间。大模型推理不是只算一次前向传播，而是在用户交互过程中反复运行，内存占用会持续存在。功耗方面，手机散热能力有限，长时间推理容易导致 CPU 降频，进而带来推理速度波动。这也是端侧 AI 硬件部署与云端部署的本质差异：云端可以堆算力、堆内存、堆冷却，端侧必须把每一瓦功耗和每一兆内存都用在刀刃上。

第三层约束来自推理引擎和算子优化。同一套模型，使用不同的推理框架、不同的后端算子，性能可能相差数倍。要做好端侧 AI 硬件部署，需要理解模型计算图中哪些算子会成为瓶颈。对于 Transformer 这类模型，权重读取量非常大，推理过程常常是访存密集型，而不只是计算密集型。换句话说，瓶颈往往不在于芯片算力不够，而在于数据在内存和计算单元之间的搬运速度。量化、算子融合、内存复用、KV Cache 优化，都是为了减少搬运开销。

因此，一个更稳妥的判断是：端侧 AI 硬件部署的成功标志，不是把模型塞进 App，而是让模型在散热受限、内存受限、并发任务交织的真实环境中，长时间稳定地提供可用服务。模型参数只是起点，后面是一整套性能工程。

4. 模型压缩：从“能跑”到“跑得好”的必经之路

如果只做一次前向推理，很多小模型都可以用蛮力跑起来。但产品化需要的不是“跑一次”，而是“持续跑得好”。这就绕不开模型压缩。端侧模型压缩大致可以分成三类：结构剪枝、知识蒸馏、量化。

结构剪枝是删掉模型中贡献较小的连接、通道或层，从而减少计算量。这种方式比较直接，但容易造成精度损失，通常需要在剪枝后做微调恢复。知识蒸馏则是让一个小模型去学习一个大模型的输出分布，用小模型逼近大模型的能力。这种方式在端侧模型训练阶段更常见，但它依赖一个大而强的教师模型，训练成本并不低。量化是三者在部署阶段最常用、也最容易被低估的一种手段。

量化可以理解为用更少的数据位去表示模型的权重和激活值。原来用 FP32 存储一个权重，现在换成 INT8，理论上模型体积缩小到原来的四分之一，推理时内存读取量也大幅下降。具体实现路径又分为动态量化、静态量化和量化感知训练。动态量化实施最简单，运行时把权重从 INT8 转回 FP32 再参与计算，能压缩体积，但对延迟的优化不一定明显。静态量化需要准备校准数据集，提前统计激活值的范围，把更多算子真正落到 INT8 计算，加速效果更明显，但实现复杂度更高。量化感知训练则在训练阶段模拟量化误差，让模型权重去主动适应低比特表示，是精度损失最小但成本最高的方案。

很多团队在量化掉精度后，第一反应是“量化有损，不能再用了”。但更常见的真相是：精度下降并非全部来自量化误差，还可能来自输入预处理不一致、模型图优化破坏了数值范围、校准数据集与真实数据分布差异过大。实际工程中应该看每一层对精度损失的贡献，选择性地把敏感层保留为更高比特，而不是一刀切地量化整个模型。

5. 端侧 AI 价值评估：不要只用跑分，要用评估漏斗

不少技术团队在评估一个端侧模型能不能上线时，习惯先看跑分和参数量。但端侧 AI 的价值并不由单一指标决定。一次完整的评估应该像漏斗一样，从模型精度到硬件性能，再到业务效果，逐层筛选。

第一层是模型语义精度。开发者需要确认这个模型在目标任务上的准确性是否达标。对于文本模型，可以看它在特定评测集上的精确率、召回率或人工评审通过率。对于视觉模型，可以看 mAP 或 Top-1 准确率。这个阶段的评估不需要引入真实设备，目的是快速筛掉能力不足的候选模型。

第二层是端侧硬件性能。到了这一层，必须把模型放到真实的目标设备上运行，测量引擎加载时间、首 Token 延迟、单次推理平均耗时、内存峰值、CPU/GPU 占用率、功耗与温升。项目一开始就应该定义一个“可上线阈值”，比如“在 3 秒内完成首次回复”“内存峰值不超过 500 MB”“连续运行 10 分钟不触发降频”等。

第三层是真实业务效果。端侧 AI 最终要落到一个具体动作上。如果是会议助手，用户真正关心的是“会议结束 1 分钟内能不能生成一份能用的摘要”；如果是端侧质检，用户关心的是“漏检率是否低于某个阈值”。这一层需要把模型放到完整业务链路里测试，而不是单独测模型。

第四层是商业成本评估。端侧 AI 的收益来自云计算成本下降、用户隐私信心提升、离线功能带来的付费意愿增强。但也会付出端侧研发、真机测试、版本升级和运维的成本。评估公式可以不那么学术，但逻辑必须完整：单次端侧推理带来的单位成本节省，乘以调用次数，再减去端侧开发和设备适配成本，才是端侧 AI 在财务报表上的真实增量。

这里特别想提醒一点：如果只看模型跑分，面壁智能这类端侧厂商很难与云端超大模型正面比较。但换到“端侧设备上单位成本完成任务”这个尺度上，中小参数模型就有了自己的优势区。选择评价尺度，本身就是端侧 AI 价值论证的一部分。

6. 一条可复用的端侧部署路径：从模型到真机

端侧 AI 硬件部署没有一个万能模板，但方向相对固定。下面的步骤可以作为一个通用起点。

第一步，明确目标设备与场景边界。先确定要在哪几款设备上运行，CPU 主频、内存大小、是否支持 NPU、系统版本是什么。同时明确场景允许的最大延迟、内存占用和功耗。不要试图用一个模型覆盖所有设备，硬件差异过大时要分档选型。

第二步，选择合适的基础模型。在满足任务能力的前提下，优先选推理框架原生支持较好的模型结构。参数量不是唯一标准，还要看模型对内存带宽的依赖、能否方便地转成 ONNX 或 TFLite、关键算子是否与目标硬件匹配。

第三步，导出为标准中间表示。PyTorch 模型一般先导出为 ONNX，再做图优化和算子验证。如果是专门为移动端设计，也可以直接导出 TFLite。导出的核心目标是打破训练框架与端侧推理框架之间的隔阂。

第四步，跑通最小推理链路。在电脑上用标准 CPU 加载导出的模型，先用随机输入验证前向计算没有问题。这个过程能过滤掉大量算子兼容问题。

第五步，模型压缩与量化。根据目标硬件能力，依次做算子融合、动态量化或静态量化。每次压缩后都要对比压缩前后精度和性能，建立一张量化验证表。

第六步，搬到真机做端到端验证。这一步必须使用接近用户条件的真机，而不是模拟器。重点观察冷启动耗时、内存峰值、发热降频、前后台切换后的状态恢复。如果真机速度不达标，再回到模型压缩阶段调整策略。

第七步，设计端云回退策略。端侧 AI 并不能在所有情况下保证结果正确。更可靠的架构是：先尝试端侧推理，如果端侧输出的置信度较低或任务复杂度超出模型能力，再回退到云端大模型。这样既保证了基础体验，也为复杂任务留了出口。

第八步，建立线上指标监控。上线后要实时观察端侧模型的调用成功率、平均延迟、资源占用和用户会话长度。不要等到用户投诉才去排查，端侧模型的崩溃通常表现得更隐蔽，需要尽早建立监控。

7. 代码实操：以 PyTorch 模型导出、推理与量化为例

接下来用一个最小示例演示端侧部署链路中的关键步骤。这里的示例只是一个轻量 CNN 模型，没有直接跑大语言模型，但“导出为 ONNX、推理引擎加载、动态量化”这三个动作，是端侧部署通用路径的一部分。换成小型 Transformer 或 LLM，整体思路一致，只是要处理更复杂的动态序列和 KV Cache。

在开始之前，建议先准备一个 Python 环境。需要安装以下依赖：

pip install torch torchvision onnx onnxruntime

本文示例以 CPU 环境为准，不涉及具体手机 NPU 适配，版本请以实际项目为准。

7.1 第一步：把 PyTorch 模型导出为 ONNX

# export_onnx.py import torch import torchvision.models as models # 这里只为了演示导出链路，weight 随机初始化也没问题。 # 如果是自己的任务，可以把 model 换成你自己训练好的 PyTorch 模型。 model = models.squeezenet1_1(weights=None) model.eval() dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, "squeezenet1_1.onnx", opset_version=11, input_names=["input"], output_names=["output"], dynamic_axes={ "input": {0: "batch"}, "output": {0: "batch"} } ) print("ONNX 导出成功")

这段代码执行后会生成一个squeezenet1_1.onnx文件。opset_version表示 ONNX 算子集的版本，太低的版本可能缺少部分新算子，太高的版本又可能超出端侧推理框架的支持范围。建议从 11 或更高版本开始试，碰到算子不支持时再针对性地降低或手动替换算子。

7.2 第二步：用 ONNX Runtime 加载模型并验证推理

ONNX Runtime 是连接 ONNX 模型和端侧设备的重要桥梁，它提供同一套接口覆盖云端 CPU、移动端 CPU、GPU 和 NPU 场景。以下代码用随机输入验证模型能否正常推理。

# inference_onnx.py import numpy as np import onnxruntime as ort sess = ort.InferenceSession( "squeezenet1_1.onnx", providers=["CPUExecutionProvider"] ) input_name = sess.get_inputs()[0].name output_name = sess.get_outputs()[0].name # 用随机输入验证链路，真实项目中请替换为经过预处理的数据 x = np.random.randn(1, 3, 224, 224).astype(np.float32) result = sess.run([output_name], {input_name: x}) print("输出 shape:", result[0].shape) print("输出 dtype:", result[0].dtype)

如果要进一步提升 CPU 上的推理性能，可以开启 ONNX Runtime 的图优化级别：

sess_options = ort.SessionOptions() sess_options.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL sess = ort.InferenceSession( "squeezenet1_1.onnx", sess_options=sess_options, providers=["CPUExecutionProvider"] )

ONNX Runtime 会尽可能对计算图做算子融合和内存复用。这个步骤在模型结构比较复杂时，往往比直接换推理框架更值得优先尝试。

7.3 第三步：动态量化压缩模型体积

ONNX Runtime 的量化 API 可以直接把 FP32 模型转成动态量化模型，代码量很小，适合作为快速验证方案。

# quantize_onnx.py from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic( model_input="squeezenet1_1.onnx", model_output="squeezenet1_1_quant.onnx", weight_type=QuantType.QUInt8, ) print("动态量化完成")

量化完成后，可以用同样的推理代码加载squeezenet1_1_quant.onnx，然后观察结果。如果在真实任务中精度波动较大，尽量先用一个小型验证集做量化前后对比，不要凭一两次结果下结论。

ls -lh squeezenet1_1.onnx squeezenet1_1_quant.onnx

在 Linux 或 macOS 上执行上述命令，可以看到量化后模型文件明显更小。Windows 环境可以用dir查看文件大小。这说明端侧模型部署时，模型体积并不是唯一的优化目标，但量化通常是一个简单有效的起点。

7.4 第四步：理解在真实端侧设备上的差异

上文的代码都在电脑上运行。真正进入 Android 或 iOS 时，还需要接入各自的移动端推理库，把 ONNX Runtime 通过 JNI 或 Swift 封装起来。到了这一层，很多问题不再是 Python API 能覆盖的，需要关注动态输入 shape 是否设得过大、NPU 是否支持某些算子、推理线程是否阻塞了 UI 主线程。

这里要强调一个容易被忽略的点：端侧模型不能只在开发机上测试，必须尽早放到真实硬件上。同样是 CPU，手机上的 ARM CPU 和电脑上的 x86 CPU 对缓存、带宽、指令集的支持不同；同样是 NPU，不同芯片厂商的算子支持差异也很大。代码在服务器上跑得流畅，只是第一步，不能证明端侧部署成功。

8. 端侧 AI 硬件部署的常见问题与排查思路

在端侧 AI 项目中，很多问题并不是同一个原因导致的。下面把常见的现象、可能原因、排查方式和解决思路整理成表，方便遇到问题时快速定位。

这些问题看起来零散，但大多指向同一个工程原则：端侧 AI 是一个软硬件结合系统，环境和状态变化都会影响最终表现。排查时不要只盯代码，要从硬件状态、输入数据、推理配置、系统调度多个维度同时看。

9. 从“能跑”到“能交付”：端侧 AI 给开发者的真正启示

回到面壁智能冲刺上市这个话题，其实可以从中看到一种共性：端侧 AI 公司的价值不在于讲一个“更小的模型”的故事，而在于证明自己能够交付一套稳定、可量化、可持续维护的端侧解决方案。模型能力排行榜留给实验室，真机性能表和单位任务成本表才属于商业世界。

对普通开发者来说，这意味着在学习和选型时，也要把注意力从“哪个端侧模型跑分更高”转移到“哪个模型在自己的目标硬件上能满足延迟和内存要求”。与其同时追逐多个新模型，不如把一个中小规模的模型从导出、量化、真机部署到效果评估完整跑一遍。这个过程能建立起来的工程手感，比记住几十个榜单数据更有价值。

如果接下来要继续深入，建议从三个方向展开：

第一，吃透一个主流端侧推理框架的配置项，比如 ONNX Runtime 或 TFLite，理解线程数、内存分配、图优化开关分别影响什么。

第二，找一台真实旧手机或一块低成本开发板，把一个 1B 到 3B 级别的小模型部署上去。重点记录冷启动时长、内存峰值、推理耗时和发热曲线。哪怕第一次只是跑通流程，也会让你更理解端侧部署的约束。

第三，参考面壁智能 MiniCPM 这类主打端侧的小模型的开源方式，关注它的量化版本、推理示例和跨设备适配方案。同类模型之间的真正差异，往往藏在模型结构之外的部署工程里。

端侧 AI 的价值不需要靠“替代云端”来证明，而应该在每一天的真实调用里被验证。谁能把模型、压缩、硬件适配和业务指标串成一条完整的流水线，谁就离“端侧 AI 能创造持续收入”这个答案更近一步。