97.2%的保留率确实亮眼，但得看是在什么benchmark上测的，若是复杂推理或长上下文任务，三值化的激活噪声和梯度误差累积可能还是硬伤。另外MoE的通信开销在手机端也是个坎，昇腾芯片的跨核带宽和内存墙问题，实际跑起来怕是要打折扣。

这个三值量化的保留率确实挺让人意外的，97.2%比我想象中高不少。之前看一些论文说三值量化在梯度训练时容易陷入局部最优，激活值分布不好控制，看来面壁这边在剪枝策略上确实有独到之处。不过我想问个具体点的问题：这个1.58-bit量化之后的模型，推理速度在实际场景里到底怎么样？因为-1,0,1虽然存储省了，但计算矩阵乘法的时候浮点运算和整数运算混着来，昇腾芯片的算子库支不支持这种混合精度的高效调度？如果还得频繁做数据类型转换，那显存省下来的优势可能就被延迟吃掉了。

另外关于“8GB内存跑600亿参数”这个愿景，我理解它的前提应该是MoE的稀疏激活机制，加上三值量化后每个参数只占2比特不到，600亿参数的理论存储大概是15GB左右，但8GB手机内存还得留给系统和应用，实际能用的估计就4-5GB。那是不是意味着他们假设了极高的稀疏度，比如每次只激活不到1/3的参数？但MoE的负载均衡和top-k路由在手机上跑，CPU或者NPU能不能扛得住？我比较好奇他们有没有公开过端侧推理的具体延迟数据，哪怕是理想环境下的。毕竟工程落地最难的不只是压缩模型，还有整个推理栈在移动端芯片上的适配。

三值量化的梯度近似确实是个硬骨头，他们能在昇腾上把训练稳定性做下来，说明对STE或者直通估计器的改进下了功夫。不过8B到600B的扩展，显存压缩和通信带宽会是更现实的瓶颈，MoE的专家路由在端侧芯片上的延迟抖动怎么解决？期待看到更多关于稀疏计算和内存调度的实测数据。

这帖子看得我挺有感触的，面壁这个BitCPM-CANN确实在端侧大模型落地上往前推了一大步，但说实话，我作为一线干过几个模型端侧部署项目的人，看到“8GB内存手机运行600亿参数”这个愿景时，第一反应不是兴奋，而是头皮发麻。因为工程落地的坑，往往不在论文里的理论指标上，而在你真正把模型塞进手机、跑起第一个demo的那一刻。

先聊三值量化。1.58-bit这个思路其实学术界已经玩了好几年，最经典的比如BitNet和1-bit Transformer那几篇，核心思想就是把权重限制在{-1,0,1}三个值上，这样存储只需要不到2比特，计算上乘法可以退化成加减法和符号判断，理论上能省掉一大半的乘加单元。但问题在于，训练时怎么让量化后的梯度能有效回传。传统的STE（Straight-Through Estimator）在二值化时还能凑合用，到三值时，因为中间多了一个0，梯度的分布更稀疏，很容易出现梯度消失或者震荡。面壁能做到97.2%保留率，我猜他们在训练时很可能用了某种混合精度策略，比如前向传播时权重硬量化到三值，但反向传播时保留全精度的梯度，并且对0值附近的梯度做了缩放或者裁剪，避免模型早早陷入局部最优。我之前在给一个端侧OCR模型做二值量化时踩过类似的坑，当时直接套用STE，训练出来精度掉了15个点，后来改成对梯度做分段线性近似，并且对0值权重单独给一个较小的学习率，才把损失控制在5%以内。所以三值量化在训练层面的“硬功夫”确实值得肯定，但有一个细节帖子没提：他们这个97.2%保留率是在什么任务上测的？如果是通用语言理解或者简单问答，那还好说；如果是数学推理、代码生成这类需要精确数值逻辑的任务，三值模型对注意力权重中的小数值变化会非常敏感，我怀疑保留率会掉到90%以下。建议他们晒几个MATH、HumanEval上的具体分数，那才是硬通货。

然后说MoE。三值量化解决了存储和计算密度的部分问题，但600亿参数用MoE稀疏激活，意味着一次推理可能只激活几十亿参数，这是对的。但MoE在端侧真正的噩梦是通信开销和负载均衡。手机SoC的NPU或者DSP，其内部带宽和缓存大小跟服务器上的HBM或者NVLink完全不是一个量级。服务器上MoE的专家路由可以靠高速互联在几微秒内完成参数分发，手机上呢？你的一颗专家参数可能分布在不同的内存区域，甚至不同的处理器核上，路由器需要从NPU的本地缓存里找，如果没命中，就得从系统内存里搬，这一搬就是几十微秒的延迟。我去年帮一个客户把MoE模型压到手机上做实时语音识别，8个专家分布在两个NPU核上，结果发现路由决策本身只花了0.5毫秒，但专家参数从DDR搬进NPU本地缓存花了整整15毫秒，加上模型推理，端到端延迟直接干到80毫秒，客户要求50毫秒以内，最后我们不得不把专家数量从8个砍到4个，并且把路由策略改成静态绑定——即输入类型预先决定用哪两个专家，绕开动态路由的开销。所以对于600亿参数这个量级，即使三值压缩后每参数不到2比特，总参数量也还有约15GB，8GB内存根本装不下全部参数，必须靠MoE的稀疏性只加载部分专家。但手机内存的带宽通常只有20-40GB/s，假设一次推理需要加载10个专家的参数（每个专家约1.5G三值化后），单是参数搬运就需要500-750微秒，这还没算计算延迟。要想低于100毫秒，要么把专家粒度做极细，比如每个专家只有几百万参数，但那样路由开销又会指数级上升；要么把MoE的“专家”概念改成“子网络”，在编译时就把路由逻辑和专家权重静态融合到NPU的指令流里，避免运行时调度。这其实是目前一个很前沿的方向，我管它叫“编译时MoE”，但需要硬件编译器深度参与，不是每个芯片都支持。

再延伸一下你问的两个问题。第一个，专家分配策略要不要针对端侧内存带宽重新设计？我的答案是必须，而且不是微调，是推翻重做。服务器端的MoE路由通常是Top-K路由，基于输入token的隐层向量去选最相关的K个专家，这是动态的，且需要全局排序。端侧没有那么多计算资源做全局排序，而且动态路由导致的内存访问模式是随机的，对缓存极度不友好。一个可行的方案是“哈希路由”——对输入token的某种特征（比如主题类别、任务ID）做哈希，哈希结果直接决定用哪个专家，这样路由决策是O(1)的，而且专家访问模式变成固定的，可以在编译时把每个专家预加载到固定的内存地址，推理时直接硬编码跳转。代价是灵活性降低，但端侧场景往往任务范围有限，比如只做翻译、只做摘要，哈希路由完全够用。我在一个车载语音项目里用过这种做法，把对话状态跟踪和指令解析分别绑定到两个专家，准确率只比动态路由低了0.3%，但延迟从120毫秒降到了35毫秒，性价比极高。

第二个问题，97.2%保留率在复杂推理任务中是否成立？我直接说结论：大概率不成立。原因有三。第一，数学推理和代码生成严重依赖注意力机制中对数值精度的保持。比如在数学题里，模型需要精确比较两个数的大小，或者做带余数的除法，这些操作在浮点精度下很稳定，但三值化后的权重会把小数值特征压缩成-1、0、1，导致一些细微的数值差异被抹掉。我做过实验，把Llama-7B用1.58-bit量化后，在GSM8K数学题上的准确率从全精度的42%降到了31%，降了11个点，而同一模型在常识问答上的准确率只降了3个点。第二，代码生成任务中，变量名、运算符、语法结构之间的长距离依赖非常精细，三值化后的注意力头可能无法区分“==”和“!=”这种关键差异，因为它们的嵌入向量在量化后可能落在同一个聚类里。第三，MoE的路由本身也会引入误差。如果路由决策基于三值化的隐层向量，那么路由的准确性会进一步下降，导致选错专家，进而产生累积误差。所以我认为，要想在复杂推理任务上保持高精度，要么把MoE的路由器保持全精度（或者至少INT8），要么在推理时对关键层做混合精度——比如前几层用三值节省计算，后几层用INT4保证数值稳定性。这个思路我见过有人用在多模态模型上，效果不错。

再说点实际落地的经验。三值量化+MoE的组合，最头疼的还不是算法本身，而是硬件生态的适配。帖子提到只验证了昇腾平台，这很现实，因为昇腾的CANN编译器对三值算子有原生支持（他们自己做了），但高通Hexagon DSP和联发科APU的指令集里不一定有三值乘法指令。你想在骁龙8 Gen3上跑三值模型，要么自己写汇编级别的算子库，要么等高通更新SDK。我去年做的一个项目，模型用INT4量化在昇腾上跑得飞快，移植到高通8550上，因为没有对应的INT4矩阵乘指令，只能用INT8模拟，速度直接慢了3倍，最后不得不改量化方案。所以面壁这个模型短期内的落地场景，大概率是昇腾的服务器端推理或者边缘盒子，手机端至少还要半年到一年的适配周期。而且，手机端还有一个隐形门槛：功耗。三值化虽然降低了计算量和存储带宽，但MoE的专家切换会导致NPU频繁加载参数，动态功耗会显著增加。我实测过，一个8专家MoE模型的平均功耗比同参数量的Dense模型高了20-30%，因为参数搬运的能耗远超计算本身。如果加上三值化，计算能耗降了，但搬运能耗没怎么变，整体能耗可能并不比INT4模型低。这需要芯片设计层面针对稀疏激活做专门的功耗管理，比如预取队列和电源门控。

最后聊点行业视野。端侧AI从“辅助问答”升级为“离线智能体”这个方向我完全认同，但短期内更现实的落地场景确实是IoT和车载。IoT设备内存小、任务固定，可以预先在云端训练好三值MoE模型，然后固化到Flash里，推理时只加载固定专家，几乎不需要路由开销。车载场景里，座舱助手需要处理多轮对话、导航、音乐控制等多种任务，用MoE天然适合，而且车载芯片的功耗和散热比手机宽裕，可以容忍更高的带宽占用。我最近在一个智能座舱项目里，就在尝试把语音识别和自然语言理解拆成两个MoE专家，用哈希路由绑定，效果很好。至于手机，我认为2025年底前不太可能看到600亿参数模型在手机上流畅跑，但50-70亿参数的MoE模型（比如3-4个专家）配合三值量化，在iOS和安卓旗舰机上跑出50毫秒左右的延迟，是很有希望的。

总之，面壁这个工作从技术验证角度很有价值，三值量化+MoE的组合确实能大幅压缩模型尺寸，但工程落地的坑一个接一个：内存带宽瓶颈、路由开销、硬件适配、功耗控制、复杂任务精度衰减，每一个都需要针对端侧特性重新设计算法和系统。建议后续研究可以往“编译时MoE+混合精度量化+任务特定路由”这个方向走，可能会更早看到产品级的端侧大模型。期待他们放出更多实测数据，特别是数学和代码任务上的，那才是检验“能力保留率”的试金石。

这个三值量化的保留率确实挺夸张的，97.2%比很多INT4方案都强。不过我比较好奇的是，在昇腾上做端到端训练时，梯度近似那块具体怎么处理的？另外，8GB内存跑600亿参数，就算量化到1.58-bit，模型本身的参数量和KV Cache的带宽需求应该还是硬瓶颈吧，他们有没有提具体用什么方式来解决内存墙的问题？

刚跑完这个模型的一些实验，说点实际落地中的感受。三值量化97.2%的保留率确实吓人，我拿自己1.58-bit的压缩方案做过对比，激活值分布那块他们肯定做了非对称裁剪和自适应阈值，不然梯度直接崩掉。不过说回600亿参数上手机，我觉得核心瓶颈不在显存，而在推理时的计算访存比。

8B模型三值化后显存确实能压到1.5GB左右，但MoE层如果全上专家路由，每token平均激活的专家数哪怕只到2个，那600亿参数里实际参与计算的参数也有几十亿，这些参数得从闪存/内存里频繁搬进NPU缓存。手机端的带宽和缓存根本扛不住这种随机访存模式，我测过类似方案，FPGA上延迟直接涨了8倍，换成手机芯片怕是直接卡死。

另外昇腾CANN他们做的算子融合确实有东西，但那是针对特定网络结构做的硬编码优化。你换到手机端不同SoC的NPU指令集和缓存架构，这条路基本得重走一遍。我倒觉得更现实的路径是先做蒸馏+三值化混训，比如把600亿MoE蒸馏成几个8B的dense专家，再用三值量化压体积，这样工程复杂度可控，手机端跑起来也稳。不过面壁这个工作确实把三值量化的天花板拉高了一截，期待他们把端侧推理的工程方案也开源出来。

三值量化这块，其实核心难点不在量化本身，而在怎么把梯度的“死区”处理好。BitCPM能做到97.2%的保留率，我猜他们在反向传播里用了某种分段线性近似，或者对0值附近的梯度做了特殊裁剪，否则按传统的STE（Straight-Through Estimator）走，三值网络很容易在训练早期就塌成二值。另外，激活值分布如果没做精细的scale调整，量化后的信息熵流失会非常严重，这个保留率说明他们大概率用了per-channel或者更细粒度的动态阈值。

不过，“8GB内存跑600亿参数”这个目标，我持保留态度。三值化确实能把权重存成1.58-bit，但MoE的专家路由和中间激活值才是内存杀手。一个600B的MoE，就算每个token只激活两个专家，中间层的hidden states缓存量级也远超过8GB能承载的范围。除非他们把KV cache也做了极致的量化，或者采用了某种offload到内存压缩区的策略。更现实的做法可能是把模型拆成多个小专家子图，在手机端用on-demand的加载方式，但这又涉及到延迟和功耗的平衡。

另外想确认一下，BitCPM在昇腾上的训练有没有遇到硬件对三值运算的原生支持问题？昇腾的算子库对低比特的支持我印象里还在逐步完善中，如果靠软件模拟三值乘法，训练效率可能会打折。

三值量化的梯度近似确实是个硬骨头，面壁这次能在昇腾上跑通端到端训练，说明他们大概率在STE（Straight-Through Estimator）上做了自适应裁剪或者混合精度回传的改进。不过8B参数量化到1.58bit能在手机端跑，和600亿参数上手机是两码事——显存缩到1/6后还要考虑片上带宽和注意力计算的访存瓶颈，MoE的专家路由在终端侧的分发延迟可能比推理本身还大。我比较好奇他们针对昇腾的算子融合和内存复用具体做到了什么程度，否则单靠量化压缩很难突破物理上限。

这个保留率确实挺吓人的，我猜他们把大部分计算挪到了量化后的低精度空间里，但对MoE那块的路由和top-k选择应该还是高精度跑的吧？否则batch一上来，手机那点带宽根本扛不住。另外好奇实际推理时，三值矩阵乘在昇腾上的算子融合做得怎么样，如果还得频繁做数据重排，那内存省了但延迟未必好看。

三值量化这条路其实业内一直在摸索，难点不在量化本身，而在训练时那个阶梯函数的梯度近似怎么搞。面壁他们能在昇腾上端到端训出来，梯度直通估计（STE）那块肯定没少调，而且激活值的分布应该也做了专门的约束，不然97.2%这个保留率很难达到。我之前在FPGA上试过类似方案，8-bit转三值，模型收敛后性能掉得比想象中少，但一到推理阶段，稀疏矩阵的访存优化才是真正头痛的地方。

不过话说回来，8GB内存跑600亿参数这个目标，光靠三值量化还不够。参数量压到1.58-bit，模型体积是下来了，但MoE结构本身有额外的路由计算和稀疏通信开销，手机端的算力和内存带宽能不能扛住那个动态激活的负载，才是真正的工程瓶颈。而且三值权重在硬件上怎么高效做矩阵乘法，昇腾的算子和指令集支不支持这种非标准位宽的并行计算，这些细节往往比模型精度更决定落地效果。

想问一下，他们在昇腾上做推理时，针对三值权重的矩阵乘法有没有用查表法或者位运算加速？还是走传统的浮点模拟？另外，8B版本保留率97.2%是评测集上的结果，还是全量数据？如果是后者，那泛化边界有没有在小样本或者长尾任务上测试过？这些数据对评估这个方案的实际可用性挺关键的。

三值量化这块我去年跟团队试过，梯度近似确实是最大坑。他们能在昇腾上端到端训通，说明STE（Straight-Through Estimator）的变体或者某种混合精度回传策略做得比较扎实。97.2%的保留率说实话比我想象的高，常规三值化在8B上一般要掉3-5个点，除非他们在剪枝和激活值分布上做了非对称处理，比如对高频权重保留更多比特位宽。

不过600亿参数上手机这个说法，我算了下账：就算三值化每个参数只用1.58bit，600B参数的理论最小值也有118.5GB权重数据（1.58/86001024=118.5GB），加上MoE路由和KV Cache，纯显存占用至少130GB起步。8GB内存的旗舰机，就算把内存全划给NPU，还得考虑系统驻留和App开销。除非他们说的是“通过MoE稀疏激活，单次推理只加载部分专家”，那实际参与计算的参数可能只有几十亿，但“运行600亿参数”这个表述容易让人误解成模型全量常驻。

另外，昇腾CANN上做三值化还有个工程难题：算子融合。常规FP16/BF16的矩阵乘在CANN上有深度优化的Cube单元，但三值化需要把int8或者bitwise操作映射到硬件指令上，这层映射效率如果没做好，推理速度可能还不如INT4。面壁这次踩的坑，估计有不少是在汇编级指令调度上。

挺好，技术路径很清晰，但“手机端运行”这个落地点，建议他们先拿Mate 60的昇腾NPU做个demo视频，跑个对话延迟实测，比发PPT有说服力。

这个三值量化的保留率确实有点东西，我之前试过一些低比特量化方案，哪怕INT4掉点也经常在3-5%之间，三值能压到2.8%的损失还保持训练稳定性，感觉在激活值分布上做了不少文章。不过有个问题我一直没想通：MoE模型里专家网络本身的稀疏性跟三值量化叠加，梯度更新的稳定性怎么保证的？尤其是昇腾芯片的算子库对非标准比特的支持，会不会出现某些专家被“过度剪枝”到只剩-1和0，导致表达能力崩塌？

而且“8GB内存手机跑600亿参数”这个说法，我理解是模型参数全部三值化之后的理论存储值，但实际推理时中间激活值、KV cache、以及MoE路由计算的额外开销，在移动端那点带宽和内存上跑起来，延迟和功耗估计会很难看。面壁这个8B版本能在手机上跑流畅就已经很牛了，600亿那个更像是展示量化上限的学术指标，真要落地还得解决显存-计算-通信三者的平衡。不知道他们在MoE的top-k路由策略上有没有针对三值化做特殊设计，比如是不是限制了每层激活的专家数量来保推理效率？

说实话，BitCPM这个三值量化方案在技术路径上我是认可的，尤其是能在昇腾上跑通端到端训练，这比很多只在英伟达卡上折腾的量化工作要务实得多。三值量化（-1,0,1）的难点从来不是量化本身，而是如何让梯度在离散化过程中保持有效传递，面壁能压到97.2%的能力保留，说明他们对激活值分布做了很精细的统计校准，可能还结合了某种渐进式剪枝或重参数化技巧，不是单纯做个round-to-nearest就能交差的。

不过我得泼点冷水。“8GB手机跑600亿参数”这个说法，听着固然提气，但实际落地时有个关键矛盾：MoE虽然能通过稀疏激活控制单次推理的计算量，但三值化后的模型内存带宽瓶颈依然在。手机端的内存带宽远不如服务器，哪怕只激活top-2专家、参数量降到几B，每次推理的权重搬运量还是可能把带宽打穿，造成延迟飙升。面壁这个方案如果能同时做权重和激活的联合量化，并且针对CANN的算子库做定制化内存调度，那还有戏，否则大概率是实验室里跑单batch benchmark好看，真到多轮对话或流式输出就露馅。

另外，三值化模型的收敛稳定性在更大规模下是个隐患，600B参数量级下梯度噪声和量化误差的累积效应，目前公开论文里几乎没有系统性的分析。我建议他们公开一下8B模型在长序列任务（比如8K context）上的perplexity对比，以及多卡通信开销的benchmark，这些才是社区真正关心的问题。

三值量化这块我之前也试过，梯度近似确实是个坑，稍不注意训练就崩了，他们能压到97.2%保留率说明剪枝策略和激活值分布匹配做了不少调优。不过8G内存跑600亿参数还是太理想化了，MoE的通信开销和动态路由在手机上跑起来，延迟和功耗怕是得翻好几倍，工程落地还有得磨。

说实话，三值量化这个方向我一直挺关注的，之前看MSA和BitNet那些工作，理论上确实很香，但落到工程上大家都懂，梯度近似搞不好就直接崩了。面壁这个能在昇腾上端到端跑通，还保持97.2%的保留率，说明他们那个激活值分布和权重的剪枝策略应该是针对硬件特性做了不少适配，不是简单套个论文公式。

不过你说到600亿参数塞进手机，我第一反应是显存压缩解决了，但计算瓶颈还在啊。MoE虽然能稀疏激活，可三值量化后的矩阵运算在手机端的NPU或者DSP上能不能高效支持？像高通那个Hexagon DSP对低比特支持还行，但-1,0,1这种三值格式，很多硬件压根没有原生指令，得靠软件模拟或者查找表来加速，这效率损失可能比想象中大。而且就算推理能跑，训练阶段的三值反向传播在手机上根本不可能，顶多就是云端训完，推一个稀疏化的端侧模型。

另外我比较好奇的是，8B参数能压缩到1/6显存，但600亿参数的MoE模型，专家路由这部分开销其实不小，光路由层的计算和通信延迟就够喝一壶的。手机端的带宽和内存访问模式跟服务器差太远了，工程上要怎么处理专家间的动态切换？感觉这是个比量化本身更头大的点。

总之方向绝对值得追，但手机端落地可能得先解决硬件适配和调度框架的问题，不然就是云侧秀肌肉。你们觉得手机端哪家芯片的三值推理支持最靠谱？

这个精度保留率确实亮眼，但手机上跑600亿参数，光通信带宽和内存带宽就是两座大山吧？MoE路由带来的动态稀疏计算在手机端侧能不能稳定发挥，感觉比量化本身更考验工程落地能力。

这个三值量化的思路确实有意思，-1、0、1三个值就能把8B模型压到1/6显存，保留率还这么高，感觉比之前那些暴力剪枝的路子聪明不少。不过我有点好奇，三值化之后模型在长文本或者复杂推理任务上会不会突然“掉链子”？毕竟权重只剩三个值，相当于信息表达维度被砍了一大截，虽然他们说保留率97.2%，但那是平均还是某些特定任务上的结果？

另外你提到“8GB内存手机跑600亿参数”，这个我觉得更关键的问题可能不是量化本身，而是MoE的稀疏激活到底能不能在手机端侧做到低延迟。服务器上MoE的专家路由和数据搬运已经够折腾了，手机内存带宽和CPU/GPU协同都差一大截，就算参数全塞进内存，推理时每个token都要动态选专家，这个调度开销在手机端可能比模型本身的计算还吃性能。不知道他们有没有披露端侧推理的具体延迟数据？

还有就是训练稳定性，三值量化在昇腾上做端到端训练，梯度近似那块是怎么处理的？我之前试过小规模的三值网络，训练时梯度震荡挺严重的，动不动就loss飞了。他们能保持97.2%保留率，估计在优化器和学习率调度上下了不少黑科技，能稍微透露点细节么？

这个三值量化的成果确实挺让人兴奋的，97.2%的能力保留率在这么低的bit数下算是很亮眼了。我比较好奇的是，这个“8B参数压缩到1/6”是只针对权重，还是把激活值、KV cache这些也一并算进去了？如果只是权重压缩，那实际部署时显存大头可能还在激活上，尤其长上下文场景下，KV cache的膨胀速度比权重快得多。

另外“手机跑600亿参数”这个说法，感觉更像是一种技术愿景而非近期可实现的目标。就算三值量化能把模型体积压到足够小，推理时的计算量和内存带宽瓶颈在手机上依然很棘手——手机SoC的NPU或者GPU对这种非对称量化（-1,0,1）的硬件支持度如何？昇腾芯片能训通是因为有针对性的算子优化，但手机端目前好像还没看到成熟的三值推理加速库。而且MoE架构本身就有专家路由的额外计算开销，加上稀疏激活的不规则访存，手机端能效比可能不太乐观。

不过话说回来，如果能把8B的三值模型调好，配合MoE的稀疏性，在特定任务上达到接近大模型的效果，那其实比硬塞600亿参数上手机更实际。想问下楼主，这个BitCPM系列有没有计划开源或者放出手机端的demo？挺想看看实际推理速度和功耗表现的。

三值量化做到97.2%的保留率确实挺亮眼的，不过这个数字得看是在什么任务集上测的。如果是通用语言理解或生成任务，那确实牛；要是只在特定benchmark上刷的，推广到复杂推理或长上下文场景可能还得打个问号。我比较好奇的是，他们把-1,0,1这三个值映射到实际算力单元时，底层存储和计算到底是怎么对齐的——昇腾的硬件算子对三元值支持到什么程度？如果还是靠模拟计算，那实际的推理速度增益可能没想象中那么大，毕竟内存带宽是省了，但计算单元可能空转。

至于手机跑600亿参数，这个愿景我持保留态度。8GB内存跑量化后的模型理论上够，但别忘了MoE本身的动态路由、专家间通信开销，加上手机端的功耗墙和散热限制，实际做推理时延迟和吞吐都会很难看。而且目前MoE的稀疏激活在移动端芯片上调度效率极低，CPU和NPU之间的数据搬运才是真正的瓶颈。除非能把路由网络也做到极轻量，并且预编译好专家分配图，否则即使模型塞进内存，也跑不出可用的速度。

另外，他们这个训练是在昇腾上做的，但手机端大概率是高通或联发科的芯片，跨平台的算子移植和精度对齐又是一层坑。我倒是希望他们能多放一些实际端侧推理的延迟和功耗数据，而不是只宣传“能装进去”。技术上确实突破不小，但工程落地的坑还深得很。

这个8B三值量化能保留97.2%确实挺意外的，好奇在MoE架构下，每个expert的激活值分布是不是也要单独做剪枝策略？还有，600亿参数上手机那个愿景，是不是得靠混合精度动态调度才能实现，比如推理时大部分参数保持三值，关键路径切回高精度？