99POS

为什么突然有人想在店里跑大模型

智能导购屏、语音问询、店务助手这类需求，门店提得很具体：断网也要能用，顾客的问话不要传到外面去，响应别等太久。

云端方案能解决能力问题，解决不了这三条里的前两条。于是「在店里放一台能跑大模型的设备」就成了一个自然的选择。

问题是，这里说的「大模型」和大家熟悉的端侧小模型，账目结构不一样。算不清这三笔账，买回来的设备很可能只够演示。

第一笔账：存储按总参数算，不按激活参数算

现在开放权重的大模型里，有一类叫专家混合（MoE）：模型里有很多个「专家」子网络，每个字只走其中几个。

好处是算得少。比如 35B 总参数、3B 激活这一档，每个字实际参与的只有 30 亿参数，算力需求和一个小模型差不多。

坏处是存得多。没被选中的专家也得放在设备上等着，所以权重要按总参数算：

• 35B 这一档，按 4 位量化，权重约 17GB；
• 再往上，235B 这一档，16 位权重约 470GB，压到 4 位仍在 120GB 上下。

门店常见的收银一体机、边缘盒子，内存普遍在 4GB 到 16GB 之间，还要分给收银软件、界面和摄像头。17GB 的权重加运行时开销，一台盒子放不下；120GB 更不是单店设备该考虑的量级。

这一步算完，很多方案其实已经出局了。剩下的选择是：换更小的模型，或者不放店里。

第二笔账：速度按内存带宽算，不按算力算

MoE 在端侧的速度，很少是「算不动」，多数是「等数据」。

专家平时待在内存或硬盘里，用到时才搬进显存。搬运速度和命中率决定了一切：

• 命中率高就快。 顾客问的都是同类问题（营业时间、退换货、会员积分），用到的专家集中，缓存命中高，速度接近小模型。
• 问法一散就慢。 一会儿问商品、一会儿问活动、一会儿问发票，专家不停换入换出，每一句都要等搬运。
• 第一句最慢。 冷启动时缓存是空的，首字延迟明显长于后面几句。

所以「这个模型每秒能出多少字」这种单句测试，参考价值有限。要看的是连续问十几轮之后的速度，以及问法变化时的抖动。

第三笔账：并发按最忙的半小时算

单店一天可能只有几十次问询，但集中在几个时段：早高峰、午市、促销日。

三五个店员同时问，和一个人慢慢问，是两种负载：

• 每路对话都要占一份上下文缓存，路数越多，内存越紧；
• 同时进来的请求能提高专家复用率，但也把带宽压力叠上去；
• 一旦内存不够，系统要么排队，要么直接拒绝，现场表现就是「按了没反应」。

验收时按最忙的时段、按实际同时在用的人数测，而不是一个人测完乘个系数。

三种放法，各有各的适用条件

多数连锁最后落在中间那一档：门店只做采集和播报，模型跑在区域机房。单店设备跑大模型，通常只在小模型够用、或者网络确实不行的场景里成立。

验收时该怎么试

如果对方说「这台设备能在本地跑大模型」，按下面几步试，问题会暴露得很快：

1. 用店里真实的问法连续问 20 轮，中间穿插不同类型的提问，记录首字延迟和后续速度。
2. 三路同时问，看是否有明显排队，以及内存峰值。
3. 拔掉网线再问一遍，确认「本地」是真的本地。
4. 冷启动一次，看开机到第一句能答要多久。
5. 问清楚模型怎么更新：换模型要不要重新加载几十 GB 权重、要不要人到店。
6. 问清楚内存占用：权重、专家缓存、上下文缓存各占多少，加起来还剩多少给收银软件。

这六条里任何一条答不上来，这套「本地大模型」就还停在演示阶段。

小结

门店能不能本地跑大模型，不是一个是非题。存储按总参数算、速度按带宽算、并发按高峰算，三笔账算下来，答案往往不是「能」或「不能」，而是「多大的模型、放在哪一级、什么条件下跑得住」。

对绝大多数门店，先想清楚哪些问题真的需要大模型、哪些用规则和小模型就能解决，比先买设备更省钱。