没有独立显卡，7.9B 模型在这台 Mac 上跑到了 47 token/s

Ling-3.0-tiny模型跑起来以后，我先问了一个毫无难度的问题， “计算 17×23，只输出最终整数。” 屏幕返回了 391。

这三个数字没什么可炫耀的，它说明 Ling-3.0-tiny 的官方 INT4 权重已经完整落在本地，Apple GPU 在参与推理，服务也确实能从本机接口调用。到这一步，部署才算完成。

这次的机器是一台 MacBook Pro，Apple M5 芯片，10 核 CPU、10 核 GPU，32GB 统一内存。

没有 NVIDIA 显卡，也没有 DGX Spark。

普通 Mac 用户看到新模型，先要知道机器装不装得下，速度和内存表现怎样，最后还得问一句能拿它干什么。三个问题，我都跑了一遍。

7.9B 参数，为什么还能叫 tiny

官方模型页显示，Ling-3.0-tiny 总参数量 7.9B，但每处理一个 token，只激活大约 1.3B。它是稀疏 MoE 架构，里面有 128 个路由专家，每个 token 调用其中 8 个，再加一个共享专家。

可以把它当成一个人数不少的小团队。活来了，不用把所有人都叫进会议室，只挑这次最合适的几个人上手。模型保留了 7.9B 的总参数规模，每个 token 只激活其中约 1.3B，实际计算量就压了下来。

注意力结构是 3 比 1 的 KDA 与 MLA 混合，细节够单独拆一篇。对本地用户来说，这套设计瞄准的是一件很具体的事，它想把长文本处理和推理成本压进个人电脑能承受的范围。

官方给了 BF16、FP8、INT4 三个版本：

BF16 权重大约 14.7GiB，FP8 约 7.8GiB，INT4 的 32 个权重文件合计约 5.4GiB。

这台机器装的是 INT4。

32GB 统一内存不算少，可 macOS、日常软件、模型权重、上下文缓存都要从这里拿空间。INT4 留下的余量最多，适合长期挂后台，也适合一边调模型一边干正事。

BF16 和 FP8 这次没做同机完整对比，所以不排想象出来的速度名次。INT4 是已经在这台 M5 上跑通、测完、留作常驻服务的版本。

在 Mac 上跑通，中间还有一点折腾

Ling-3.0-tiny 还没进 Ollama 稳定版的常规支持列表，Mac 端要走尚未合并的实验分支，再通过 MLX 和 Metal 调 Apple GPU。

这次固定了实验分支的具体源码提交，补齐 CMake 和 Metal Toolchain，编译 MLX Metal v4 运行时，再下载官方 INT4 权重。32 个 safetensors 文件合计 5,805,705,224 字节，导入后本地模型名叫 ling-3-tiny:int4。

服务交给 macOS 的 launchd 管。登录自动启动，异常退出自动拉起，API 只监听 127.0.0.1，同一局域网里其他设备默认访问不到。

模型闲置 30 分钟后从内存卸载，API 服务继续留着，下次请求进来，再重新载入。

Ollama 原生接口和 OpenAI 兼容接口都跑通了。支持自定义 OpenAI 接口地址的聊天工具和脚本，通常都能接入，个别客户端还要调整鉴权或接口配置。

这台 M5 实际跑多快

普通中文、JSON 和代码任务的持续生成速度，大致落在每秒 47 到 49 个 token。

一次 741-token 的连续中文生成，速度 47.63 token/s。放在聊天窗口里体感已经很顺，文字持续往外冒，阅读速度通常跟不上它。

模型完全卸载后再发请求，冷加载 1.7 到 2.9 秒。模型留在内存时，流式请求 145 毫秒看到第一个字，这 145 毫秒是暖机成绩，和冷启动不是一回事。

短提示任务的运行时峰值内存约 6.04GiB。

再塞进去一段 4,677-token 的长材料，让它找出藏在里面的编号 LING-0160。一次找对，输入处理速度约 444 token/s，运行时峰值内存升到 9.11GiB。

32GB 的机器还有明显余量。不过上下文继续变长，KV 缓存也会继续长，不能拿 8K 的占用去推算 128K 或 256K。

官方介绍里还有更高的性能数字，包括特定平台每秒 160 token 以上，DGX Spark 上 100 到 105 token/s。那些数字有各自的硬件和测试条件。本次 M5、32GB、INT4 的成绩就是上面这一组。把不同机器的成绩混在一起，文章会更热闹，读者装完以后更容易失望。

能干活，也会犯一些很具体的错

跑分只说明一部分问题。我又给它安排了几类更接近日常工作的任务。

结构化信息提取完成得很干净。输入一段订单描述，让它只返回 JSON，姓名、城市、金额、退款状态全部正确，字段类型也对。

代码测试里，它写了一个合并区间的 Python 函数。语法检查通过，五组功能用例全部通过。

提示词明明写着“不要 Markdown“，它还是很热心地套了一层代码围栏。代码能用，格式指令没完全听进去。

工具调用也成功了。给它一个天气查询函数，它准确选了 lookup_weather，参数填的是杭州。也就是说，模型能继续接搜索、日历、资料库或本地脚本，能做的事不必停在聊天框里。

中文摘要出了另一个小问题。内容概括正确，要求三个项目符号，它只写了两个。意思懂了，数量没守住。

Thinking 模式的问题更明显。我问了它一道经典的三盒标签题，允许它输出 2,048 个思考 token。模型一直在推导里绕，撞到长度上限也没交出最后答案。关掉 Thinking 后，它能推到正确的“一次“，可过程又太长，还是撞上了长度限制。

这些毛病值得写出来。一个本地模型能跑，不等于每种任务都适合直接交给它。

JSON、文本处理、代码草稿、工具路由，已经有不错的可用度。严格格式、复杂推理、必须一次答对的流程，仍然要加校验。

它更适合谁

Ling-3.0-tiny INT4 放在 32GB Mac 上，更像一个随时能叫起来的本地助手。

个人用户可以拿它处理私密文档、总结长材料、写代码草稿，也能接进 Obsidian、编辑器或自己的自动化脚本。模型权重和推理都在本机，日常处理的文本不用发到云端。

开发者还能走 OpenAI 兼容接口，把原来调云模型的部分工作流切到本地测试。

它现在的并发配置是 1。两个请求同时进来，会排队执行。单人使用和现场演示没问题，多人服务就要重新做并发、内存和长时间稳定性测试。

Mac 支持目前来自实验分支。截至 2026 年 8 月 16 日，稳定版 Ollama 还没有合并这部分代码。当前部署固定在验证过的提交上，后面升级运行时，导入、推理、工具调用、内存都要重新跑一遍。

追新版本可以，最好别在商单演示前五分钟追。

跑完以后，重新认识了 tiny

“小模型“过去常常让人联想到能跑就行，回答质量先别要求太高。

这次跑下来，Ling-3.0-tiny 已经适合放进日常工作流。将近 8B 的总容量，每次只动用其中一部分，32GB Mac 能稳稳装下，速度也到了愿意每天打开的程度。

它也有明显的边界。Thinking 会绕，格式偶尔不听话，当前并发只适合一个人。把这些问题留在文章里，反而更能看清它的价值。

目前模型就挂在这台 M5 Mac 的 http://127.0.0.1:11434 上，名字叫 ling-3-tiny:int4。

打开编辑器或脚本，发一条请求，它就开始出字。

对一台没有独立显卡的个人电脑来说，这样已经很有用了，你觉得如何？

相关资料

• Ling-3.0-tiny 官方模型页

• Ling-3.0-tiny INT4 官方模型页

• Ling-3.0-tiny 官方介绍

• Ollama 的 Ling 与 MLX 支持进展