企业官网建设流程全解析

把一台32G内存的Mac mini M6放到桌上，装个Ollama，拉一个7B模型下来，输入问题，回车……很多人问的第一句话通常都是“快吗”，紧接着就是“它到底能跑多大的模型”。这两个问题看似简单，背后其实牵扯到算力、TPS和端云决策三个完全不同的层面。我这段时间用这台机器做了不少本地大模型实验，先说结论：它能跑，而且日常使用完全能当一台LLM服务；但有三个真相必须提前说清楚——容量决定你能不能跑，带宽决定你跑多快，而“TPS虚高”这个现象，几乎能骗过所有只盯着评测数字看的人。这篇东西适合AI应用开发者、正在纠结要不要入手Mac mini做本地推理的人，以及想把大模型服务塞进个人工作流的技术爱好者。

1. 算力真相：跑大模型，先看带宽与容量，再看TOPS

1.1 为什么“AI算力TOPS”在大模型推理里参考意义不大

每次发布新款Apple Silicon，宣传页上都会出现一个好看的“每秒万亿次运算”数值，M系列芯片的神经网络引擎数字逐年翻倍，看起来很唬人。但真把大模型部署上去，你会发现那个数字和体验之间的相关性远没有想象中那么强。

核心原因在于：大模型生成token是一个内存带宽密集任务，不是算力密集任务。模型推理时，每一层都要把权重从内存搬到计算单元，和输入向量做矩阵乘，再写回结果。生成一个token，本质上等于把模型全部权重完整读一遍。读权重的速度取决于内存带宽；而矩阵乘本身在现代芯片上相对快得多，权重搬运才是真正的瓶颈。

可以把这个过程类比成厨房出菜：CPU/GPU是厨师，内存是仓库，内存带宽是传送带。厨师手艺再好，传送带每小时只能运500斤食材，出菜速度上限就是这500斤对应的菜量。TOPS代表厨师有多能切墩，带宽代表食材进厨房的速度。在大模型推理场景里，大多数人不是被厨师速度卡住的，而是被传送带卡住的。

另外还有一个生态层面的原因：神经网络引擎虽然也算力很强，但它只对Core ML优化过的算子友好，llama.cpp、MLX、Ollama这些主流推理框架在Apple芯片上主要走GPU和CPU路线，ANE几乎帮不上忙。所以你在评测里看到的M系列TOPS参数，和实际跑LLM的体验之间，隔着整整一个软件生态的距离。PC上N卡还有个类似的问题，就是驱动模式是TCC还是WDDM会影响显存分配方式和计算性能；Mac这边没有这层困扰，统一内存天然归系统统一调度，但“32G不是32G全部给模型”这件事，反而是更隐蔽的坑。

1.2 32G统一内存：模型到底能吃到多少

Apple Silicon的统一内存架构确实很先进，CPU和GPU共享同一片物理内存，避免了传统PC里“显卡显存不够、还要把数据拷回内存”的来回折腾。但这不意味着你在系统里看到的32GB全都能用来跑模型。

macOS系统本身、后台进程、桌面窗口、浏览器标签页，日常开机就要吃掉6到10GB。剩余的内存里，GPU还要遵守一个“wired limit”限制，大致上是系统给图形和计算任务划定的预留上限，默认情况下，32G机器可被GPU自由支配的部分通常在20到24GB左右。如果这台Mac mini是纯当推理服务器用，不带显示器、不常开图形密集型应用，可以通过调高iogpu.wired_limit_mb把更多内存划给计算任务用；但如果是日常兼用办公，这个参数最好不要乱动，否则图形界面调度会非常难受。

所以在32G机器上规划模型时，我的经验是按下限估：系统留10G，模型和运行时的可用空间大概只有20到22G。这意味着什么？看下面的速查表就清楚了。

表格里只是权重占用的估算，还有一个经常被忽略的大头是KV Cache。以Llama-3-8B这一类结构为例，FP16精度下，每生成一个token，KV Cache大约要占128KB；算下来8K上下文就是1GB，32K上下文直接吃掉4GB。如果量化到8bit，这个数字能砍一半左右。也就是说，32G能跑多大的模型，不只是“权重放不放得下”的问题，还包括“你要给它留多长的对话上下文”。想跑大模型加超长上下文，在32G上基本只能二选一。

1.3 精度与算力需求：FP32、FP16、INT8、INT4到底差多少

聊精度之前，先给一个最基础的换算关系，后面所有估算都靠它。模型权重的内存占用等于参数量乘以每参数字节数：FP32是4字节，FP16/BF16是2字节，INT8是1字节，INT4是0.5字节。比如一个8B模型，FP16下就是16GB权重，INT8下是8GB，INT4下是4GB。

精度的选择直接影响两个东西：速度和质量。速度方面，因为推理是“读权重算一遍”，权重越小，每分钟能读的轮数就越多，吞吐自然上来。同样带宽下，INT4比FP16快四倍，INT8比FP16快一倍。质量方面，FP16几乎没有信息损失，INT8在多数场景下损失不大，INT4则要分模型看，新版量化算法做出来的4bit模型，很多任务上已经能和FP16打得有来有回，但复杂推理、代码生成这类任务偶尔还是会出现细节上的退化。

回到M6的带宽推算。Apple芯片的内存带宽规律一直是：基础款大约100到200GB/s，Pro款翻倍到300GB/s左右，Max款再翻倍。按这个演进规律，M6基础款的带宽估个150GB/s上下、Pro款估个300GB/s上下，应该不会偏太远，具体以真机为准。基于这个带宽，就能用公式直接估算理论TPS上限：

单流生成速度 ≈ 内存带宽 / (参数量 × 每参数字节数)

以150GB/s为例，8B INT4模型的理论上限是150 / (8 × 0.5) ≈ 37 token/s；32B INT4是150 / (32 × 0.5) ≈ 9 token/s；8B INT8则是150 / (8 × 1) ≈ 18 token/s。实际跑起来因为预填充、内存分配、系统调度这些开销，能到理论值的八成左右就算很健康了。这就是为什么同款芯片、同尺寸模型，有人晒出的TPS是另一个人的快一倍，很可能只是精度、上下文长度和批处理参数不同而已。

2. 真实TPS：数字好看和好用是两回事

2.1 “TPS虚高”是怎么来的

大模型圈子里“TPS虚高”几乎是个默认现象了。你在论坛上看到有人晒出某模型在Mac上跑到每秒四五十个token，自己也买了一台一模一样的，结果实际用起来感觉完全不是那么回事。问题就出在测试方法和真实使用场景的严重脱节。

最常见的虚高来源有几种。第一种是只报生成速度不报预填充速度。大模型的完整响应分为两个阶段：读入你那一大段prompt做理解，这叫预填充；然后一个字一个字往外蹦，这叫生成。预填充对长文档、长对话来说非常耗时，但很多人测速时只测生成段，甚至用极短的prompt跳过了大头。第二种是用低量化、小模型来测，8B INT4和32B INT4本来就是两个世界，跑出来的数字根本没有可比性。第三种是短回复测试，模型只生成了几十个token，首token延迟占总耗时的比重被摊得很薄，端到端速度自然好看。

还有一个更隐蔽的因素是热缓存和小批量。同样的prompt跑第二遍，系统的页缓存、KV Cache、推理框架的算子缓存全都生效了，速度比冷启动快很多；而测试时只测单并发、单请求，实际生产环境里一旦多路请求同时打进来，单流TPS会明显下降，网格抖动也会让体感变得更差。所以“TPS虚高”的本质是：拿实验室里最理想的单点数字，去对标真实工作负载里的综合体验，中间差的这30%到50%，就是这届评测最容易骗人的地方。

2.2 一套靠谱的测速方法

既然要聊真实TPS，就得有一套能复现的测法。我的原则是区分三个指标：预填充速度、生成速度、端到端TPS。三个分开测，别混在一起算。

llama.cpp编译出来的二进制里自带一个llama-bench工具，可以快速得到标准的prefill和token generation数据。比如跑一个8B模型，可以这么测：

./llama-bench -m qwen2.5-8b-Q4_K_M.gguf -p 512 -n 256 -t 8

输出里的pp512就是处理512个token prompt的预填充速度，tg256就是生成256个token的生成速度。这两个数字能直观反映芯片带宽和框架优化水平。

但工具数字只能说明硬件表现，真实的端到端体验还需要模拟实际使用场景测。我更建议直接跑一个真实任务：准备一段500到1000字的实际业务文本，让模型先读文本再输出一段200字以上的回复，然后用时间戳把整个过程包起来，看全流程的token数除以总耗时。这个数字才是你每天写代码、做摘要、跑Agent时真正体会到的速度。

把服务跑起来之后，用Ollama的API计时也是个实用办法：

time curl -s http://127.0.0.1:11434/api/generate \ -H "Content-Type: application/json" \ -d '{"model":"qwen2.5:8b","prompt":"请总结下面这段文字...","max_tokens":300}'

从返回体里把eval_count字段拿出来，结合time命令输出的总耗时，就能算出一个端到端的生成TPS。这种做法测出来的数字，会比跑分工具更贴近“我实际用起来到底什么感觉”。同时还要把任务叠加测几次，比如连续发3个并发请求看单流下降幅度，这才是真实工作负荷。

2.3 32G M6上各档模型的TPS参考区间与体验建议

基于内存带宽公式和前代M系列实测规律，32G Mac mini M6上跑各档模型，大致的参考区间如下。注意这些是估算区间，不是硬指标，拿到真机后建议按上面的方法自己测一遍再作决定。

这里有个很实际的经验：不要只看峰值TPS，还要看上下文长度对TPS的拉低作用。32G机器上跑32B INT4，权重占了16GB，系统剩下十几GB，上下文一拉长，KV Cache内存吃紧，框架就会开始和系统抢内存，TPS会比表里的参考值掉得更厉害。相比之下，8B INT4在32G上是真正的舒适区，权重小、缓存宽裕，就算开到32K上下文也能稳住速度。

3. 实操：在32G Mac mini M6上把模型跑顺手

3.1 选型与安装：MLX还是Ollama还是llama.cpp

在Mac上跑大模型，主流方案就三套：Ollama、MLX生态和llama.cpp。它们不是互斥关系，我自己的机器上三套都装了，按场景切换。

Ollama胜在零门槛，安装完一条命令拉模型，自带OpenAI兼容API，非常适合快速搭建个人助手服务。它的底层调用的就是llama.cpp的推理引擎，所以很多参数在服务端也能调。MLX是Apple官方维护的机器学习框架，对Apple Silicon的算子优化是全家桶里最彻底的，跑模型的速度通常比llama.cpp在同等条件下再快个百分之十到二十，尤其是批处理场景更明显。缺点是需要懂一点Python，生态相对集中在开源模型转换这一块。llama.cpp则是最灵活、最底层的选择，能精确控制KV Cache量化、批大小、线程数这些参数，适合排查问题。

我的建议是：第一次上手直接装Ollama，体验本地大模型。有进阶需求后再用MLX跑跑你手头最常用的模型，比较一下两者速度差距。最后如果你想深入调优，再拿llama.cpp做对照组。

安装基本是这些命令：

# Ollama curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:8b # MLX pip install mlx mlx-lm python -m mlx_lm.generate --model mlx-community/Qwen2.5-8B-4bit --prompt "你好" # llama.cpp brew install llama.cpp

3.2 让模型用得更快的内存设置

很多人装上Ollama后没做什么设置，跑大模型就总感觉内存吃紧、速度不稳。实际上有些关键参数值得手动调一调。

第一个是上下文长度。Ollama默认的上下文窗口通常只有2048或4096，对长文档任务根本不够。可以在启动服务前设置OLLAMA_CONTEXT_LENGTH=16384这样的环境变量，或者运行时用num_ctx参数指定。上下文越长，内存占用越大，速度也会略微下降，所以别无脑开大，按你实际需求来。

第二个是KV Cache量化。如果用的是llama.cpp直接推理，可以在启动参数里加-ctk q8_0 -ctv q8_0，把KV Cache压到8bit，对长上下文场景内存能省一半，质量损失几乎感知不到。Ollama新版部分模型也支持KV量化，但兼容性不如llama.cpp直接。

第三个是GPU内存上限。刚才说过，32G机器实际给模型的就是二十几G，如果把它当无头推理服务器用，可以通过sysctl调高GPU wired limit，让系统为计算任务预留更多内存。但注意，这个操作会让图形响应变钝，日常办公的机器别试。

还有一个容易被忽视的点：后台占用。很多人的Mac mini是主力开发机，Xcode、Docker、浏览器、IM全开着，再跑一个8B模型，内存早就见红了。跑大模型前先用htop和vm_stat看看剩余可用内存，内存压力如果长期处于黄色或红色，别怪机器慢，先把后台清一清，效果立竿见影。

3.3 一个完整示例：把8B模型跑成个人知识库接口

把以上设置落到一个真实场景里，整个流程会清晰很多。假设我想让这台32G机器承接一个“内部知识库问答”服务，每天处理几十次长文档摘要请求。

第一步，拉一个8B级别模型。我用qwen2.5:8b，4bit量化版，权重占4到5G，给系统和上下文留出很大余量。第二步，设置上下文长度为16K，重启Ollama服务，这样单次能吞下万字左右的文档，超出部分做切分。第三步，写一个简单的Python脚本，把文档按段落切块后做向量检索，将命中片段拼进prompt，再调用本地的OpenAI兼容接口完成问答。第四步，用上一节的方法做端到端计时，观察不同文档长度下的真实TPS和内存占用。

这套流程跑下来，我的经验是：8B INT4在32G机器上，面对16K上下文、几百行代码或万字文档的摘要需求，单次响应普遍在十秒内完成，TPS基本稳定在20到35之间。完全够个人和五六个同事一起使用。如果你想进一步压榨这台机器的价值，还可以尝试用MLX做LoRA微调。32G内存对7B/8B模型做LoRA是可行的，4bit基础模型叠加低秩适配器，峰值内存能控制在十几GB以内，微调完的适配器只有几百MB，可以针对自己业务场景做轻量定制。但全参数微调就别想了，那是64G甚至128G机器才该考虑的方案。

3.4 跑不到想要的速度时的排查顺序

如果发现速度明显低于预期，按这个顺序排查，能省下大量瞎折腾的时间。

首token慢这个点要单独说说。很多人只关心生成速度，忽略了预填充。当你丢给模型一篇八千字的文档，让它写总结时，模型要先把这个文档全部“读”一遍，这个阶段走的是矩阵运算，对带宽和算力需求都很高。不同框架的预填充优化差异非常大，llama.cpp在这一块的调度做得相对好。如果经常处理长文档，建议对比一下Ollama和MLX的预填充速度，选择更适合的那套方案。

4. 端云决策：本地有本地的好，云端有云端的强

4.1 成本账：一次性投入还是按token付费

跑本地大模型的人，多少都算过一笔账：买这台机器花了一万多，到底值不值回票价？这个问题不能只看硬件价格，要看你的使用强度和使用周期。

本地端的成本分两部分。一是设备折旧，一台32G Mac mini按三四年使用周期摊下来，每天十几到二十几块。二是电费，Mac mini满载大概五十瓦上下，真按24小时挂机算，一年电费也就两百多块，比想象中低很多。所以本地端一年的隐性开销，大约在几百到一千里徘徊，大头还是设备折旧。

云端端的成本就比较灵活了。不同大模型API的价格差异极大，便宜的国产模型每百万token只要几块钱，旗舰海外模型可能要到几十甚至上百美元。我们不讨论具体价格，直接给判断逻辑：你的单日token消耗量乘以API单价，再乘以365天，如果这个数明显高于设备的年折旧成本，那本地端就是划算的。反过来，如果你一天只调几百次API，每次回复才几百个token，一个月算下来几十块钱，那还真没必要额外添置一台专用设备。

以我的实际用量看，纯开发时偶尔调用API和纯生产环境跑批处理是两种完全不同的账单，前者一年可能就几百块，后端一跑起来，一个月几千块的token费用都是正常的。所以“买32G到底值不值”这个问题，本质上取决于你是否把本地机器用成了“跑批处理的常驻工人”，而不是偶尔玩一玩。

4.2 延迟、隐私与可控性

成本之外，端云选择的另外三个维度是延迟、隐私和可控性。

延迟层面，本地模型最大的优势是首token延迟稳定，因为所有计算都在本机完成，没有网络RTT，没有排队。API服务的首token延迟波动很大，高峰期几百毫秒甚至几秒都正常，但云端集群的并发吞吐是本地完全没法比的：你本机跑8B模型，两三个并发就差不多到极限了；云端卡池同时处理几十个请求毫无压力。所以“延迟低”和“吞吐高”这两件事，在端云两侧是分开的：单请求体验本地好，多请求总吞吐云端强。

隐私层面就不需要多解释了。代码、病历、财务数据、未公开的论文，这些东西送进第三方API，即使服务方承诺不用于训练，心理上也很难踏实。本地模型哪怕能力弱一点，数据不出主机这个特性就足够让它成为很多场景的必选。可控性则是另一个容易被忽略的点：本地模型可以随意改system prompt、切量化档位、做LoRA微调，甚至改采样参数到离谱的程度都没人管你；云端API的审核、限流和使用条款，随时可能影响你的工作流。

4.3 决策清单：什么任务留在本地，什么任务必须上云

在32G Mac mini M6这个配置上，端云决策可以整理成一份很实用的清单。

本地优先的任务：高频低延迟交互，比如Copilot类的代码补全、聊天机器人；隐私敏感数据处理，比如内部文档摘要、脱敏日志分析；离线环境下的固定模板生成；以及你需要反复修改prompt、微调模型、实验各种采样参数的研究任务。这些任务用云端API，要么延迟不可控，要么隐私不放心，要么成本按量算下来太贵。

云端优先的任务：超大参数模型才能搞定的复杂推理和长链Agent任务；需要最新知识更新的问答；高并发批量处理，比如几千条客服对话的自动分类、大量文章的批量改写；以及云端生态更成熟的多模态和工具调用场景。这类任务本地跑既慢又不稳，硬扛只会两头受气。

更理想的做法是混合架构。我现在的模式是本地8B模型作为第一层，接收高频和敏感请求；遇到本地模型置信度偏低、任务超出它的能力边界、或者并发量超过两台本地机器处理极限时，再自动转发到云端大模型。这个降级逻辑在代码里只需要几行判断，比如看请求类型、看上下文长度、看本地服务超时时间。很多Agent框架原生支持多模型路由，配起来也不麻烦。这样既能享受本地隐私和低延迟，又保留云端灵活兜底的能力。

5. 常见问题与避坑记录

5.1 为什么我的TPS只有别人晒的一半

这个问题在社区里出现频率极高，根源几乎都在配置差异上。先核对模型文件是不是同一个：同一家族模型，INT4、INT8、FP16三个版本的速度可以差出四倍。再核对上下文长度：别人开4K你开32K，KV Cache对内存的占用会导致框架启动内存压缩，速度会明显下降。然后是运行环境：别人的“裸机测试”可能是刚开机、后台干净，你的机器挂着开发环境，后台一直在占用CPU和内存带宽。最后才是芯片本身的差异——M6基础款和M6 Pro款的带宽差了一倍，同款模型在Pro上跑出两倍TPS，一点都不奇怪。

5.2 跑着跑着内存满了、系统卡死怎么办

这是在做本地模型初期最容易踩的坑。系统内存压力一旦变红，macOS就会疯狂压缩内存或启用swap，整个机器流畅度迅速崩盘。解决办法有三个方向：第一，把模型档位降一档，从14B降到8B，体验改善是立竿见影的；第二，缩短上下文窗口，不要贪心长对话；第三，设置Ollama或llama.cpp的模型卸载策略，用完立刻释放内存，别让多个模型同时常驻。

如果确认是系统内存分配问题，可以观察vm_stat里的cow_faults和swap使用情况，频繁的swap说明内存真的不够用了，这时候再有优化技巧也救不回来，只能减模型或加内存。

5.3 Mac mini的散热对长时推理的影响

Mac mini并不是无风扇设备，它内部有主动散热风扇，但小机箱压大算力时温度会比较高。跑那些动辄十几分钟到几十分钟的长文本批处理任务时，芯片温度爬高后会有降频保护，TPS会从峰值往下掉一截。这不是bug，是硬件的自我保护机制。

要延缓解这个问题，物理放桌上的话，给Mac mini留出足够的通风空间，不要塞在密闭柜子里；软件层面可以把线程数调低一点，或者拉长请求间隔，让芯片有余力喘气。如果是7×24小时挂机做批处理，建议观察一下核心温度和功耗，找到长期稳定运行的工作点，而不是盯着开跑前两分钟的峰值性能。

5.4 如何判断哪些模型真的能长期留在32G里

32G机器的模型管理其实是个取舍题。根据我的经验，最多常驻两个模型就差不多了：一个8B INT4做日常主力，一个14B INT4或32B INT4做精度要求更高的离线任务。如果还想放一个视觉模型，那主力就得让位给7B。判断标准很简单：先估算权重占用，再按最常使用的上下文长度估算KV Cache，两项之和加系统余量不超过25G，就算健康；一旦超过27G，长期运行一定会出问题。

另外值得记住的是，Ollama和MLX都支持按需加载模型，不用的时候权重不占显存，但“按需”在首次调用时会有一次冷启动延迟，几秒到十几秒不等。如果你追求随时响应，就得让模型常驻内存；如果你更看重多模型切换，那就接受冷启动延迟，两者不可兼得。

最后再分享一个我个人的体会：这台32G的Mac mini跑大模型，最正确的打开方式不是把它当日常办公电脑，而是当成一台安静扔在角落、7×24小时开机的本地推理服务器。给它接上知识库、Agent框架和自动化脚本，平时根本不用走过去碰它，需要时随时通过局域网API调用。有了这种“常驻服务”的使用心态之后，你才会真正理解为什么说本地模型最重要的是可用内存和带宽，而不是GPU的广告纸面数字。