任务依赖的最优基数：多值离散计算在物理AI中的实践

1. 多值离散计算并不玄：从三值网络到低比特量化，本质是同一件事

很多人听到"多值离散计算"这个术语，第一反应是某个冷门学术分支，跟自己的实际工程没什么关系。我最初也是这么想的，直到在一个边缘设备项目里被功耗和延迟逼到墙角，才回过头来认真琢磨这东西——然后发现，大家天天挂在嘴边的神经网络量化、三值权重网络、低比特推理，其实全都是多值离散计算在不同尺度上的具体表现。

先把这个概念揉碎了说清楚。现代计算机底层是二值逻辑，0和1，一切数据最终都被编码成这两档。但"多值离散计算"的意思是：让计算过程中的数值表示不再局限于0和1，而是允许一个有限集合里的多个离散取值。比如三值逻辑，常见的取值是-1、0、1；四值是-1、-1/3、1/3、1；再往上就是各种低位宽定点数，比如4比特量化相当于16档离散值，8比特量化相当于256档。

为什么说量化就是多值离散计算？因为量化干的事情本质上就是把连续的浮点数值映射到一个有限的离散取值集合上。你训练好的神经网络权重原本是32位浮点数，每个权重都有超过40亿种可能取值，但推理的时候你用不着这么高的精度——把权重限制到三值（-1、0、1）或者4比特（16档），计算照样能跑，功耗和延迟却可能降低一个数量级。

这背后的原因很直观。计算机做32位浮点乘法需要完整的乘法器电路，做一次乘法要多个时钟周期；但如果是三值权重，乘法直接退化成符号判断——权重是-1就取反，是0就跳过，是1就原样输出，根本不需要乘法器。同样做一次卷积，三值化和浮点版本的计算能耗差出几十倍，这在边缘设备上是决定生死的差距。

物理AI天然适合吃这碗饭。它不像云端大模型那样追求"什么都能答"，而是要在机器狗、机械臂、自动驾驶车里做感知、规划、控制——这些任务的共同特点是：环境信息通过传感器进来，数值本身就有噪声，你算得太精没有意义；执行器（电机、舵机）的物理精度也就那样，你再努力算到小数点后六位，电机该抖动还是抖动。

所以我在做物理AI相关项目时，深刻体会到一件事：算得"够好"往往比算得"够精"更重要，而"够好"怎么定义，直接牵扯到一个问题——到底该用多少档离散值？这就是标题里"最优基数"的来历。基数在这里指的是离散取值的数量，比如二值逻辑基数是2，三值逻辑基数是3，4比特量化基数是16。

2. 物理AI的边缘困境：云端延迟与控制回路的生死线

物理AI和传统AI最大的区别在于，它的一部分决策必须在一个物理闭环里实时完成。你部署一套模型，如果只是做离线图像分类，延迟高一点无所谓，等两秒出结果也能接受。但如果这台机器人在公路上跑，前方突然出现障碍物，从摄像头采集图像到模型输出刹车信号，整个链路延迟超过100毫秒，以60公里时速换算过来，车已经往前冲了将近2米——大概率已经撞上了。

这就是网络热词里提到的那条现状：传统做法把AI模型放在云端，所有计算都在云端完成，但网络传输和云端排队带来的延迟太高了。4G网络下单向延迟通常有30到80毫秒，5G好一些也有10到20毫秒，再加上云端处理时间，一个完整来回经常超过100毫秒。对视频聊天、网页检索这类场景完全没问题，但对物理AI的实时控制回路来说，这就是灾难。

物理AI的控制回路简单说就是"感知→决策→执行→再感知"的循环，每一圈的时间直接决定了系统的响应速度。我用一个具体数字来说明：四足机器人的动态步态控制，控制频率通常要求400Hz以上，也就是每2.5毫秒就要完成一次从状态估计到关节指令的计算。这种节奏下，云端计算根本没有参与讨论的资格，所有推理必须在机身内完成。

所以边缘智能的意义不在于"把AI放到边缘"这个空间上的移动，而在于把延迟从100毫秒级别压到微秒到几毫秒级别。但边缘设备的算力是有限的，一块面向机器人场景的典型边缘计算芯片（比如Jetson Orin Nano这类），浮点算力不过几十到几百TOPS，功耗预算往往只有5到15瓦。你不可能把云端那套大模型整套塞进去，能做的是让模型在"边缘算力够得着"的前提下尽量保证效果。

这里就是多值离散计算登场的地方。同样的模型结构，浮点版本在边缘芯片上跑100毫秒，4比特版本可能只需要20毫秒，三值版本可以压到10毫秒以内。代价是精度损失——但正如前面说的，物理世界的感知数据本身就带噪声，很多时候10毫秒的延迟优势远比那几分贝的精度优势值钱。

我做过一个对比实验，同一个目标检测模型，浮点推理在边缘设备上的端到端延迟是88毫秒，其中模型推理本身占了70多毫秒；改成4比特量化之后，推理部分压到18毫秒，总延迟降到36毫秒左右；再极致一点做三值化，推理只要9毫秒，但检测精度从AP 0.82掉到0.71。在大多数抓取场景里，0.71的AP已经够用，而36毫秒到9毫秒的差距意味着机器人可以更从容地避开突然出现的人手或障碍物。

3. 最优基数是一个设计空间问题：延迟、精度、功耗的三角博弈

既然离散档位从2到256都有，那"最优基数"到底怎么定？这是整个项目里最核心的问题。我的做法是把它当作一个设计空间搜索问题，而不是拍脑袋定一个数。先明确三个互相关联的指标：延迟、精度、功耗，然后看基数每变化一档，这三个指标各自怎么动。

先说延迟。神经网络里最重的运算是卷积和矩阵乘法，本质上都是乘法累加。浮点版本的乘法累加要完整走乘法器；4比特定点版本的乘法可以用查表或者移位近似；三值版本的乘法变成加减法和零跳过。不同基数下的单次运算延迟差异，乘以模型里的运算次数，就是整体延迟差距。我实测的数据是：同样结构的MobileNetV2在边缘芯片上，浮点推理延迟约75毫秒，8比特约25毫秒，4比特约15毫秒，三值约8毫秒——基数从256降到16，延迟降到五分之一；再降到3，延迟再砍一半。

再说精度。基数降低带来的精度损失不是线性的。拿图像分类举例，从32位浮点降到8比特，精度损失通常很小，可能只有0.1%到0.5%；降到4比特，损失可能到1%到3%；降到三值甚至二值，损失可能飙到5%到15%。关键拐点一般出现在4比特到三值之间——很多任务到4比特还能维持可观精度，再往下就崩了。但物理AI任务的容错空间和图像分类不一样，需要具体测量。

功耗是第三角。边缘设备的功耗大头在存储访问和计算单元，低基数既减少了每个数值占用的位宽（存储访问带宽需求下降），又简化了计算逻辑（动态功耗下降）。实测中，从8比特降到4比特，芯片整体功耗可能降低30%到40%；从4比特降到三值，再降20%左右。对一个电池供电的机器狗或者无人机，这意味着续航从40分钟延长到55分钟，价值非常大。

把这三个维度放在一起看，最优基数根本不是一个固定答案，而是具体任务、具体硬件、具体延迟需求和具体功耗预算下的折中结果。我习惯画一张"基数值−综合收益"曲线：横轴是基数（2、3、4、8、16、256），纵轴是"精度保留率×延迟缩减率×功耗缩减率"这类加权评分。曲线通常不是单调的，会在某个基数处出现一个明显的拐点——这个拐点附近，再增加基数带来的精度提升很小，但延迟和功耗代价增长很快；再减少基数，延迟和功耗省不了多少，但精度开始崩。那个拐点区域，就是最优基数的候选区间。

光说方法论有点空，我举个具体的例子。假设有个移动抓取机器人的视觉感知模块，任务是从RGB-D图像里识别物块位置。我先用浮点模型跑一遍，拿到精度基线AP 0.85、延迟75毫秒、功耗11瓦。然后依次做8比特、4比特、三值化，测出三组数据：

但这个项目里控制回路要求视觉模块延迟必须低于20毫秒，功耗预算不超过5瓦。对照表格，浮点直接出局，8比特延迟超标，4比特延迟15毫秒、功耗4.5瓦都满足，三值虽然更快更省电但精度掉了太多，抓取成功率实测从92%降到81%，不可接受。所以这个任务的最优基数就是16（4比特）。如果换一个任务，比如只要识别障碍物有没有来，根本不抓取，那基数3的0.71精度完全够用，它就会成为最优选择。

这就是"任务依赖"的实质——最优基数不是模型自己的属性，而是"模型+任务约束+硬件约束"三者的共同解。

4. 任务依赖不是口号：检测、位姿、控制各需要几档精度

我接触过的物理AI项目里，任务五花八门，但归纳起来无非三大类：感知检测类、位姿估计类、运动控制类。这三类对精度的敏感程度完全不同，最优基数自然也不一样。

感知检测类任务的目标是"有没有""在哪"——目标检测、障碍物识别、语义分割都属于这一类。这类任务的输出本身是离散的标签类别和粗略的边界框，不需要非常细的数值精度。二值分割网络和三值检测网络在学术界已经有大量研究，工程上也确实跑得通。实测下来，4比特量化通常能保留95%以上的检测精度，三值化大概保留80%到90%，二值化就看运气了，有的任务还行，有的任务直接崩。所以对检测类任务，我的默认建议是先试4比特，如果延迟还有余量再试三值，精度确实不能接受就退回4比特或者混合方案。

位姿估计类任务的情况就麻烦一些。不管是对机械臂抓取点的六自由度位姿估计，还是对机器人自身状态的关节角估计，输出都是连续数值，需要一定的数值分辨率。我做过一个物块抓取位姿估计实验：浮点模型的位姿误差约2毫米、2度；4比特量化后误差涨到4毫米、3.5度，还在可接受范围；三值化之后误差直接跳到12毫米、9度，抓取时经常对不准目标。这种情况下的最优基数一般在8比特或4比特，三值基本不用考虑。

运动控制类任务又不一样。控制信号讲究平滑性和稳定性，虽然控制频率高、对延迟极其敏感，但每次输出的数值范围非常窄，往往只需要在上一时刻值附近做一个很小幅度的调整。这种情况下，低基数带来的量化噪声反而可能被控制律的积分环节吸收掉一部分。我见过一个四足机器人关节控制项目，用三值权重网络做状态估计和控制量计算，跑出来的步态稳定性竟然和4比特版本差不多——因为控制律本身的滤波和反馈机制把量化噪声抑制了。这类任务的最优基数往往可以压得很低，但前提是控制算法本身要稳定。

把三类任务放到一张表里，横向对比就很清晰了：

需要说明的是，这只是一个经验性的起点，不是铁律。真正的最优基数必须在你的具体硬件和具体任务上实测之后才能确定。但有了这个分类框架，你可以不用从256开始逐个试——先落到对应的推荐区间，再在这个区间内做精细搜索，效率会高很多。

还有一个点容易被忽略：同一个系统里不同模块可以用不同的基数。机器人通常同时跑感知、规划、控制好几个模型，没必要统一基数值。感知模块用4比特，控制模块用三值，状态估计模块用8比特，这种"混合基数"方案在工程上完全可以实现，而且往往比全系统统一基数更优——这正是"任务依赖"的另一个含义：最优基数不但在任务之间不同，在同一个系统的不同模块之间也可能不同。

5. 实机验证：一个机械臂抓取项目的基数选择全过程

理论说了这么多，我拿一个实际项目完整走一遍"找最优基数"的过程。这个项目是一台六自由度机械臂的视觉抓取系统，任务是从传送带上识别工件并抓取到指定位置。处理器是一块典型的边缘计算模组，机械臂的运动控制由一个独立的实时控制器负责，视觉感知结果通过以太网传给控制器。整套系统的延迟预算是：从图像采集到控制指令发出，不能超过50毫秒。

第一步是建立基线。我先用全浮点模型跑通整个链路，测出视觉部分的推理延迟为82毫秒，远超50毫秒预算。这时候唯一的选择就是做降低基数，让推理速度提上来。

第二步是在推荐区间里做展开。根据任务分类，抓取位姿估计属于"位姿估计类"，我优先试4比特和8比特，三值只做一个参考对比。我用同一个训练好的模型，分别做8比特、4比特、三值量化，然后逐个在实机上跑端到端测试。这里有个细节：量化不是改个配置就完事，我用了量化感知训练，用少量带标签数据对量化后的模型做微调，把量化误差带来的精度损失往回拉一截——这一步非常关键，直接做训练后量化，4比特的精度会比量化感知训练版本差好几个点。

第三步是测量和评估。每个配置下我都测了四组数据：推理延迟、端到端延迟（包括图像采集、预处理、推理、通信）、抓取成功率、模型显存占用。这里我写了一个简单的延迟基准测试脚本，用Python实现：

import time import numpy as np from PIL import Image def benchmark_inference(model, input_tensor, runs=100): # 先跑几次预热，避免显存分配和缓存影响测量结果 for _ in range(5): model(input_tensor) latencies = [] for _ in range(runs): start_time = time.perf_counter() output = model(input_tensor) end_time = time.perf_counter() latencies.append((end_time - start_time) * 1000) latencies.sort() # 取中位数而不是平均值，更能反映真实表现，避免偶发卡顿污染结果 median_latency = latencies[len(latencies) // 2] p99_latency = latencies[int(len(latencies) * 0.99)] return median_latency, p99_latency

测试结果汇总如下：

端到端延迟包含了图像采集约15毫秒、预处理约5毫秒和通信约2毫秒，所以两头都扣除掉，8比特的推理28毫秒加上这些开销勉强压在51毫秒，离50毫秒预算差1毫秒——严格来讲不达标，实际运行中还会因为系统调度出现抖动。4比特的37毫秒很稳，留出了将近13毫秒余量。三值的28毫秒虽然更快，但抓取成功率掉到78%，比4比特低了13个百分点，对生产线场景是不可接受的。

所以这个项目的最优基数最终定在了16档（4比特）。后续我又做了一个细调：把网络里对精度最敏感的几层（通常是靠近输出的层）保持8比特，其余层用4比特，混合配置下抓取成功率从91%回升到93%，端到端延迟只增加了2毫秒，依然在预算内。这个结果就比单纯的全4比特更优——说明即使确定了基数值，还可以在模型内部做局部异构，把"任务依赖的最优基数"进一步细化到"层依赖的基数"。

6. 落地时最容易踩的坑：硬件限制、训练策略和量化感知

在实际项目中把基数落到实机，我踩过的坑比理论推导多得多。挑几个影响最大的说，都是之前各种文章里很少提的。

第一个坑是内存带宽比算力先成为瓶颈。很多人在选择低基数时只盯着算力，觉得延迟降低全靠计算变快，但实际上边缘芯片上数据搬运的能耗和延迟往往比计算本身更可观。模型参数从8比特降到4比特，内存占用减半，内存带宽压力也随之减半——这才是低基数在显存受限场景下真正救命的地方。反过来，如果模型本身已经很小，降低基数对延迟的改善可能很有限，因为瓶颈在内存吞吐而不是计算能力。所以选基数之前，先看清楚你的硬件瓶颈到底在算力还是带宽，可以用芯片厂商提供的profiler工具跑一遍。

第二个坑是训练时就必须考虑推理时的基数值。很多团队的做法是先训练一个高精度浮点模型，最后直接做训练后量化，发现精度崩了，然后回头骂低基数没用。实际上正确的做法是量化感知训练——在训练阶段就模拟推理时的量化误差，让网络自己去适应离散取值。我在位姿估计项目里做过对比：训练后量化的4比特版本精度比浮点低7%，而量化感知训练的4比特版本只低2%。差距非常明显。所以决定基数值的时机应该是在训练准备阶段，不是训练完成之后。

第三个坑是不是所有层都适合同一个基数。网络的第一层和最后一层通常对数值精度最敏感——第一层直接处理原始输入，最后一层直接决定输出精度，中间层因为有BatchNorm和激活函数缓冲，量化误差容易被吸收。之前提到的混合基数方案就是基于这个观察。经验法则是：把最敏感的那一到两层保持高基数，其余层压低基数，可以在精度和效率之间拿到很好的平衡点，而且实现成本并不高，大多数推理框架支持逐层指定量化位宽。

第四个坑是硬件对非标准基数的支持参差不齐。8比特和4比特在很多边缘芯片上都有硬件加速指令，做得比较好；三值、二值这类极端低基数，或者3比特、5比特这类非标准基数，很多芯片的指令集根本没有对应支持，最终会先转成8比特再计算，省下的延迟就大打折扣。所以选基数不能只看理论计算量，要查你目标芯片的指令集和白皮书，看看它原生支持哪些位宽。如果一个芯片只支持8比特和4比特的SIMD指令，那三值量化带来的收益可能只是减少内存带宽，计算延迟却降不了多少，这时候三值未必比4比特划算——我做四足机器人项目时就在这个问题上浪费了整整两个星期。

第五个坑是电学层面的噪声和动态功耗。低基数计算单元的逻辑更简单，数字电路翻转次数更少，这确实降低功耗，但如果你的系统是电池供电，还要考虑芯片在低负载下的静态功耗占比——很多芯片静态功耗才是大头，计算功耗降了，总功耗却降不了太多。选择基数时应该把功耗测量放到整机上做，而不是只看芯片算力规格。

把这些坑避开之后，还要注意评估指标的选取。我见过不少团队在选基数时只看平均精度，忽略延迟分布。物理AI是实时系统，98分位延迟比平均延迟重要得多。一个模型平均延迟15毫秒，但98分位跑到60毫秒，在控制回路里一样会出事故。我上面代码里特意算了p99延迟，就是为了暴露这类尾延迟问题——边缘设备上由于系统调度、中断处理、散热降频，尾延迟比云端更不可控。

7. 现在的做法与下一步的扩展方向

回到标题里的"任务依赖最优基数"——这个说法不是一句口号，而是我在多个物理AI项目里反复验证过的方法论。概括起来就是四步走：第一步，明确任务的延迟、精度、功耗硬约束；第二步，建立浮点基线，确定量化感知训练的起点；第三步，在任务类型对应的推荐基数区间里做系统扫描，测量中位数延迟和尾延迟；第四步，在选定基数值的基础上做逐层混合优化，逼近真正的局部最优。

依我个人的实际体会，这个方法最大的价值不是找到一个数字，而是逼着你把"精度越高越好"这个惯性思维改过来。物理AI系统最终要活在真实的物理世界里，传感器有噪声、执行器有误差、功耗有上限，在这堆约束的交集里找可行解，比在云端无限叠加算力要复杂得多，也更有意思。多值离散计算给了你更多的档位可以选择，最优基数方法给了你选档的决策框架，两者结合才能把边缘设备的每一分算力都花在刀刃上。

下一步我自己打算继续探索两个方向。一是把基数的决策自动化，通过类似贝叶斯优化的方式在延迟、精度、功耗的约束下自动搜出最优基数，省掉手工扫描的笨办法。二是尝试在运行时根据任务状态动态切换基数值——比如机器人空闲巡检时用高基数保证环境感知的准确性，紧急避障时自动切到低基数换取更快的反应速度，这个"任务依赖"就从静态配置变成了动态策略，对物理AI的实时性会是又一次进化。不过这些都是后话，先把当前这套最优基数方法用好，已经能让大多数边缘设备上的物理AI项目迈过实用门槛了。