前阵子做产品，需要在浏览器端侧跑个轻量模型。一开始我天真地以为——参数越小越省心，随便挑一个 1B 左右的模型塞进去不就完事了？

坑就坑在我这"以为"上。

试了一圈才发现，同样是"小模型"，在浏览器里的表现能差出一个银河系。有的加载快得离谱但输出让人想摔键盘，有的中文好得一批但内存吃得跟 7B 模型有一拼。今天这篇就把我试过的四个模型——Qwen2.5-1.5B、Phi-3-mini、Gemma-2-2B、Llama-3.2-1B——在浏览器里的实测感受全抖出来。

你不是正愁选哪个吗？这篇你来对了。

---

先说说这几个选手

坦白讲，我一开始的筛选标准就一条——能用 Transformers.js 或 WebLLM 在浏览器里直接跑。那些还得搭 Python 环境的就不聊了，咱说的是纯前端方案。

Qwen2.5-1.5B（通义千问的小老弟）：阿里出的，1.5B 参数，主打中文。我一开始最看好它，毕竟国产嘛。

Phi-3-mini（微软家的小钢炮）：号称"小模型里的大模型"，将近 4B 参数。等等，你可能会说——4B 还敢叫小模型？但在浏览器里，你还真别嫌它大。

Gemma-2-2B（Google 的轻量级）：2B 参数，Gemma 家族的老二。Google 出品，英文底子没得说，中文就……

Llama-3.2-1B（Meta 的最小吃）：1B 参数，四个里最小的。我一开始的想法是——这玩意能干啥？后来发现，它还真能干点事。

四个模型全部做 INT4 量化，用 Transformers.js 的 device: wasm 模式跑。机器是台普通的 MacBook Pro M2，不是啥服务器级别的东西——这不更符合咱普通开发者的真实场景吗？

---

实测一：启动速度——谁先张嘴？

这个维度说实话我没太当回事，结果现实狠狠抽了我一耳光。

你想想，用户打开页面，等个模型加载，超过 3 秒就已经开始骂娘了。启动速度直接影响体验，这可不是小事。

Llama-3.2-1B 第一个亮眼——模型文件量化完也就几百兆，下载加加载到跑通第一段推理，差不多十来秒。在端侧模型里算快的了。当然，前提是你的用户网络不能太拉胯。

Qwen2.5-1.5B 紧随其后，加载时间比 Llama 多了那么一小截，但也在可接受范围内。毕竟它模型本身大了一圈。

Gemma-2-2B 的加载时间……怎么说呢，比我预期慢了一点。可能跟它的 tokenizer 也有关系，反正第一次加载时我盯着进度条看了好一会儿。

Phi-3-mini 是最让我意外的。量化完了文件仍然快 2GB，首次加载时间用了我将近 半分钟。说真的，我当时差点就放弃它了——用户能等你半分钟？做梦呢。

不过后来我发现了个骚操作：把模型文件做成离线包提前下发，这样冷启动时间能砍掉大半。但这是另一个话题了，后面有空可以单独聊聊。

---

实测二：推理速度——吐字快不快？

这个维度才是大家最关心的吧。我拿了一个同样的 prompt 去试：

“请用一句话解释什么是量子计算”

为什么用中文？因为我最终产品面向国内用户，中文能力是第一位的。

结果挺有意思——

Llama-3.2-1B 速度最快，几乎感觉不到延迟，用"秒出"来形容不过分。但是……输出质量嘛，后面再说。

Phi-3-mini 推理速度出乎意料地好。虽然将近 4B 参数，但 每 token 的生成速度跟 Qwen2.5-1.5B 差不多，大概一秒十个 token 左右（模糊估算，我懒得记录精确时间）。微软在优化这块确实有两把刷子。

Qwen2.5-1.5B 中规中矩，不快不慢，一个字一个字往外蹦，你能感受到它在"思考"。

Gemma-2-2B 推理速度比 Qwen 稍慢一点点，差距不大，基本属于同一梯队。

不过我劝你别只看推理速度。快有什么用？生成的是垃圾，那跟没生成也没区别。是不是这个理？

---

翻车一：嘴上说快，内存先崩了

就在我测 Phi-3-mini 推理速度正乐呵的时候，拿测试机跑了一轮——8GB 内存的 Windows 笔记本。

模型加载到一半，浏览器直接崩了。连个错误提示都没有。

我还以为是代码写错了，翻来覆去查了半天。后来才发现——端侧模型运行时需要的不仅仅是模型本身占的内存。推理过程中的中间激活值、KV cache、临时缓冲区，加起来比模型文件还大。你以为量化到 INT4 就万事大吉了？太天真了。

那 Phi-3-mini 的内存到底吃了多少？这就顺理成章进入下一个维度了。

---

实测三：内存占用——谁是真正的内存刺客？

这个是最让我崩溃的维度，没有之一。

我之前写过 WebView 内存治理的文章，自认为对内存有点概念。结果端侧模型一上来，直接把我的认知干碎了。

Llama-3.2-1B 是良心选手，推理期间内存增长 不到 500MB。对大部分用户来说，这完全扛得住。

Qwen2.5-1.5B 也不过分，大概多了不到 1GB。普通用户只要不是同时开几十个 tab，问题不大。

Gemma-2-2B 就开始上强度了。推理时内存涨了将近 1.5GB。而且这部分内存不会在推理结束后立刻释放，你得手动处理，不然就一直占着。这个问题我排查了半天，最后发现是 Transformers.js 的 Wasm 缓存机制搞的鬼。绝了。

Phi-3-mini…… 刚才那个翻车已经剧透了。将近 4B 参数的模型，量化完了也要吃 接近 2GB 的内存。我在 M2 16GB 内存的机器上跑的，还算勉强。但 8GB 的测试机直接黑屏，连个提示都不给你。

说起来都是泪啊。

---

实测四：中文能力——谁不胡说八道？

好，到了最关键的地方。速度快有什么用？内存小有什么用？"量子计算"解释成"魔法计算"你受得了吗？

全用同一个 prompt，分别看四个模型的中文表现：

Qwen2.5-1.5B 的中文最稳。毕竟是阿里自家的模型，对中文的理解和表达都挺到位的。“量子计算是利用量子力学原理进行计算的一种方式”——中规中矩，但至少没出错。

Phi-3-mini 的中文……怎么说呢，能看懂，但偶尔有语法别扭的地方。微软毕竟主攻英文，中文语料估计没喂够。不过整体能用，比预想的好。

Llama-3.2-1B 的中文输出就有点离谱了。同样是"量子计算"，它冒出来一句"Quantum computing is like…"然后开始混着英文。我怀疑是它的中文训练数据太少，或者 tokenizer 对中文的支持不够。

Gemma-2-2B 也差不多，中文理解能力堪忧。简单的中文指令还能应付，稍微复杂一点就开始"中英混杂"或者答非所问。你要做个英文产品选它没问题，做中文产品的话……算了吧。

---

翻车二：它把"太烂了"分成了"正面"

这个翻车让我印象特别深。

我让 Gemma-2-2B 做个简单的文本分类——“这句话是正面还是负面评价？”

输入：“这个产品太烂了”

它的输出：正面。

我当时就懵了。反复试了几遍，每次结果都一样。后来查了才知道，Gemma-2 在情感分析这类任务上，如果 prompt 不写得特别详细，表现确实不稳定。可能是预训练数据里没多少中文情感语料，也可能是指令跟随能力在中文上打了折扣。

这告诉我一件事：在端侧用模型，你不能假设它跟云端 API 一样靠谱。你得多一层校验，或者做个简单的置信度判断，不行的就兜底。

---

到底选哪个？我的个人意见

你让我推荐的话，分场景说：

做中文产品，用户设备还行： 无脑选 Qwen2.5-1.5B。中文最好，内存和速度都能接受。作为主力模型没毛病。

做英文产品，对速度要求高： 可以考虑 Llama-3.2-1B，快是真快，但前提是你的任务不能太复杂。简单的文本补全、分类啥的够用了。

设备内存紧张，但需要一定能力： 也是 Qwen2.5-1.5B。它在小内存设备上的表现最均衡。

对模型能力要求高，用户设备好： 可以上 Phi-3-mini，但必须做好离线包预加载和降级策略。千万别啥准备不做直接扔给用户。

Gemma-2-2B…… 呃，除非你特别需要 Google 的那套生态，否则我暂时想不出非选它不可的理由。也许是我没用到它的正确场景吧，这块我也没完全搞明白。

---

说实话，这四个模型我试完一圈，最大的感受就是——端侧选模型没有银弹。你以为参数小的就省心，结果速度可以但中文不能看。你以为能力强的就全能，结果内存吃死你。

所以我的建议是：别只盯着一款模型上。做一个模型管理层，根据用户设备自动切换。跑不动 Phi-3 就降到 Qwen，Qwen 也跑不动就降级到云端。这才是端侧 AI 的正确姿势。

你们最近也在折腾端侧推理吗？遇到什么坑了？评论区聊聊，看看谁的血泪更多（我赌我的肯定最多）。