FreeToken 刚发布：它真的比 Ollama 和 llama.cpp 更好吗？

编者按：本文根据 Abhinandan Malhotra 的实测文章 《FreeToken Just Shipped. Is It Better Than Ollama and llama.cpp?》整理并改写，并用 FreeToken 官方仓库、技术论文、llama.cpp 与 Ollama 官方资料交叉核对。它是一篇中文技术解读，并非逐字翻译；测试数据与原图归原作者所有。

FreeToken 刚发布就靠一个惊人的说法获得关注：让 753B 参数的 MoE 模型在单张工作站 GPU 上运行。这个数字很容易让人联想到“它是不是已经取代 Ollama 和 llama.cpp”。但三者解决的问题并不完全相同，性能也必须放回模型规模、系统内存、GPU 和工作负载里理解。

原作者在一台 RTX 3050 6GB 显存的 Windows 11 笔记本上，用同一个 gpt-oss-20b MXFP4 模型、同一组提示词和同一份计时代码，对 FreeToken、Ollama 与 llama.cpp 做了直接比较。结果很明确：在这台机器和这个模型上，Ollama 三项都最快，FreeToken 三项都最慢。但这并不能直接否定 FreeToken，因为它的设计目标恰恰是“小模型固定分层”无法覆盖的大规模 MoE 场景。

三个引擎，实际上是两种架构

MoE（Mixture of Experts，专家混合）模型虽然总参数量很大，但每个 Token 只激活少数专家。其余专家在那个时刻都处于空闲状态。问题是：这些暂时不用的权重应该放在哪里？

Ollama 与 llama.cpp：加载时固定切分

llama.cpp 通常在加载模型时决定哪些层放 GPU、哪些层留在系统内存并由 CPU 执行。用户可以用 --n-gpu-layers 等参数控制卸载层数。Ollama 在许多硬件上使用 llama.cpp/GGUF 路径，并把模型管理、下载、服务接口和硬件配置包装成更简单的体验，通常会自动选择一个可运行的 CPU/GPU 分配。

原测试中，ollama ps 显示模型由系统自动分成约 71% CPU、29% GPU。llama.cpp 需要手动调节，配置不当会明显拉低速度，但调好以后可以接近甚至超过自动方案。

FreeToken：把空闲显存变成动态专家缓存

FreeToken 不想在加载时永远固定分层。它把完整专家权重保存在 CPU RAM，将 GPU 剩余显存作为共享 LRU 专家缓存：最近使用的专家留在显存；缓存未命中时，运行时根据机器实测的 CPU 内存带宽与 PCIe 带宽，动态决定是把专家权重传到 GPU，还是直接在 CPU 上计算。

官方 CLI 文档也反映了这套机制：ft bench bw 会用真实 MoE 内核测量主机内存和 PCIe 带宽，并写入与 GPU 和数据格式绑定的性能档案；自动后端再据此选择 offload 或 hybrid 策略。FreeToken 还会共同分配 MoE 专家缓存与 KV Cache，并支持在运行中调整缓存池。

这比固定分层复杂得多。每一步生成都可能涉及缓存查询、淘汰、带宽判断和传输/计算选择。复杂度能否换来收益，取决于模型是否大到真的需要它。

测试环境与方法

• GPU：RTX 3050 Laptop GPU，6GB VRAM；
• CPU：Intel i5-13450HX（6 个性能核、4 个能效核）；
• 内存：24GB；
• 系统：Windows 11，三个引擎均原生运行；
• 模型：gpt-oss-20b MXFP4，磁盘约 13GB。

作者没有把 FreeToken 放在 Linux/WSL、另外两者放在 Windows，因为那会把平台差异混进引擎差异。FreeToken CLI 在 WSL 下加载中途停滞，原生桌面应用可以工作，因此最终三者统一在 Windows 上测试。

提示词覆盖三类生成：三句话解释 MoE 与稠密模型、经典“17 只羊只剩 9 只没死”逻辑题，以及 200 词解释 MoE 路由。每个提示运行四次，正式序列前先用一次“hi”排除冷启动，最终报告中位数。三个引擎都通过 localhost 的 OpenAI 兼容 API 由同一 Python 脚本驱动。

结果：Ollama 在这台 6GB 笔记本上获胜

Ollama 比 FreeToken 快约 60% 到 64%；llama.cpp 也快约 32% 到 40%。对于 gpt-oss-20b 这种规模，固定分层已经足够，FreeToken 持续管理专家缓存的开销没有换回足够收益。

首 Token 延迟：FreeToken 等待时间约为 Ollama 的 3 倍

三个任务的 TTFT（Time to First Token）非常稳定：

• Ollama：约 0.37–0.39 秒；
• llama.cpp：约 0.51–0.53 秒；
• FreeToken：约 1.16–1.18 秒。

这同样符合机制：FreeToken 在生成前要检查缓存状态并选择专家执行策略。对于只有 20B 的模型，这些准备工作比它能节省的专家传输更多。

为什么这次失败，仍不能回答 FreeToken 是否“更强”

FreeToken 的论文目标不是让一个能轻松运行的 20B 模型更快，而是让远超显存容量的大型 MoE 模型变得可用。论文报告支持 20 多个 MoE 模型，硬件范围从 8GB 笔记本 GPU 到单张工作站 GPU，并展示 35B 笔记本、284B 游戏桌面以及 753B GLM-5.2 工作站级场景。

原测试无法验证这些数字。24GB 系统内存不足以在 FreeToken 桌面应用中加载作者想测试的 27B 和 35B 模型，更不用说 753B。MoE 专家主要驻留在主机内存，因此单 GPU不等于只需要 GPU：要运行数百 B 参数模型，依然需要非常大的系统内存、足够的内存带宽和 PCIe 带宽。

正确结论应当是：

在 RTX 3050 6GB、24GB RAM、gpt-oss-20b MXFP4 和三组静态提示下，FreeToken 的动态机制没有收回自身开销；它是否在超大 MoE 与长时间 Agent 工作负载上胜出，仍需要另一台内存充足的机器重新测试。

三者各自适合谁

选择 Ollama：希望几分钟内开始使用

Ollama 的优势是产品化体验：下载模型、管理模型、启动本地 API 和自动硬件配置都比较简单。在这次 6GB 笔记本测试中，它速度最快、TTFT 最低，作者约四分钟完成设置。适合大多数希望“先跑起来”的用户。

选择 llama.cpp：需要最大控制权和硬件覆盖

llama.cpp 提供更细的量化、GPU 卸载、上下文、批处理和后端控制，支持 CUDA、Metal、Vulkan、HIP、SYCL 等广泛硬件。代价是配置与排错更多。手动参数正确时，它可以接近或超过更高层封装；参数错误时，也可能把性能留在桌面上。

选择 FreeToken：模型大到固定切分已经不够

FreeToken 更适合大型 MoE、有限显存但有充足系统内存的机器，以及专家访问模式会随 Agent 会话不断变化的工作负载。它的真正对手不是“20B 模型上的四分钟安装体验”，而是“这个模型在传统固定卸载下根本无法实用运行”。

复现时要注意的两个问题

第一，FreeToken 仍处于快速迭代阶段。版本、模型支持、缓存预算和自动策略都可能变化。复现时应记录 FreeToken commit/版本、模型文件、memory_ratio、MoE 缓存、KV 容量、输出长度和机器带宽档案。只比较一个 tok/s 数字不够。

第二，不要把关闭 Windows Memory Integrity 当成普通安装步骤。原作者遇到未签名 DLL 被系统拦截，并通过关闭该安全功能解决。这会降低系统防护。更稳妥的做法是优先使用可信、签名或可自行验证/构建的二进制，在隔离的测试机上评估，或等待项目提供兼容版本；不要为了跑一次基准就永久降低日常电脑的安全设置。

最终判断

FreeToken 没有在这次测试中击败 Ollama 或 llama.cpp，但它也没有在自己最擅长的战场上接受测试。Ollama 赢的是小机器上现成模型的速度与易用性；llama.cpp 赢的是透明、可调和跨硬件的底层控制；FreeToken 试图赢的是超大 MoE 在有限显存上的可运行性。

所以，问题不该是“FreeToken 是否全面更好”，而应该是“你的模型是否大到需要动态专家缓存”。如果答案是否定的，Ollama 或 llama.cpp 更成熟、更直接；如果答案是肯定的，FreeToken 值得在内存更充足的硬件上做一次真正对口的测试。

来源与延伸阅读：Towards AI 原文、原作者基准脚本与原始数据、FreeToken 官方仓库、FreeToken 论文、llama.cpp、Ollama。