企业官网建设流程全解析

拿到这台32G内存的Mac mini M6之后，我做的第一件事不是跑分，不是剪视频，而是直接往里面塞大模型。这是我玩本地大模型这几年一直想干的实验：一台不到巴掌大的桌面小主机，靠统一内存能吞下多大参数量的模型？跑起来到底是"能跑"还是"能用"？网上那些漂亮的TPS数据，实际复现能信几成？又该怎么判断哪些任务该留在本机、哪些该丢给云端API？

这篇不打算搞什么玄学，就用一个比较直接的视角，把32G Mac mini M6本地跑大模型的几个关键问题拆开：内存账怎么算、算力瓶颈到底在哪、实测TPS的参考区间、以及端侧和云端的任务怎么分。适合正在纠结要不要拿Mac mini当本地AI工作站的开发者，也适合买了机器但不知道拿它跑什么模型的普通用户。

1. 先算清楚内存账：32G统一内存能装下什么样的大模型

很多人拿到32G的Mac mini，第一反应是"内存这么大，岂不是什么模型都能跑"。这个想法对了一半。统一内存架构确实是Mac跑大模型的最大优势——CPU和GPU共享这32G，不用像PC那样把显存和内存分开买，但模型的体积、量化等级、KV缓存、运行时的临时开销，全都要从这32G里出。账算不明白，很快就会发现系统卡成幻灯片。

1.1 模型占用的基础换算逻辑

大模型的内存占用有一个很粗略但好用的公式：模型文件体积 ≈ 参数量 × 每个参数占用的字节数。以70亿参数的7B模型为例：

• FP16（半精度，大家常说的"满血"）：7B × 2字节 = 14GB
• INT8量化：7B × 1字节 = 7GB
• INT4量化（Q4系列）：7B × 0.5字节左右 = 3.5~4.4GB

也就是说，在不带任何上下文的情况下，一个原始的7B FP16模型刚好能塞进32G，但几乎没有任何余量给对话历史和KV缓存，跑起来离OOM只有一步之遥。所以绝大多数Mac用户实际选择的是量化后的模型。

1.2 量化等级怎么选：不要盲目追求"满血"

总有人觉得量化是"降级"，FP16才叫完美。但用32G统一内存跑大模型，量化的意义不是"凑合"，而是"让模型能真正被用起来"。我自己的经验是：

我实际用下来，7B和8B这档模型在32G机器上是"最舒服"的——即使上Q8量化，模型加上下文还有大量余量，系统不会因为内存不足把模型往Swap区赶。13B到14B这档，Q4量化之后大概8GB，再预留4-6GB给KV缓存和系统，完全够用，是日常对话和代码补全的主力档位。32B模型属于"能跑但紧巴巴"的状态，Q4量化后约19GB，跑短对话没问题，但一旦把上下文拉长到8K以上，内存压力立刻上来了。

1.3 KV Cache才是真正的"内存刺客"

内存账里最容易被忽略的是KV Cache。简单说，模型在生成每个新token时，都要把之前所有对话内容的关键向量保存在内存里，用于"回忆"之前的上下文。它的占用随上下文长度线性增长，模型层数越多、注意力头越多，KV Cache越大。

以32B Q4模型为例，模型本身19GB，当上下文长度拉到4K时，KV Cache可能额外占用2-3GB；拉到16K，可能就要6-8GB。我在实测中遇到过一个非常典型的场景：模型加载一切正常，前几轮对话速度也不错，聊到十几轮之后系统开始明显变卡，紧接着OOM弹出来——原因就是KV Cache和对话历史把32G吃满了。

提示：用Ollama或llama.cpp跑大模型时，num_ctx（上下文窗口）参数千万不要无脑拉满。32G内存优先保证模型本体，再按剩余内存的50%左右配置KV Cache空间，比什么都"默认拉满"要稳定得多。

所以32G能装多大的模型，答案不是"32G除以模型体积"，而是"32G减去KV Cache、减去系统占用、减去其他应用之后，还剩多少"。在这个前提下，7B-14B的量化模型是黄金档位，32B是中高强度训练，70B基本别想。

2. 算力真相：LLM推理的天花板是内存带宽，不是TOPS

接下来是很多人对"算力"的误解。Mac上的GPU和NPU账面数字并不差——又是多少TFLOPs，又是多少TOPS——但大模型推理这种任务，真正卡脖子的往往是内存带宽，而不是峰值算力。搞清楚这一点，你就能理解为什么8核GPU的M系列芯片跑7B模型也能有不错的每秒token数，也能解释为什么网上那些"Mac跑大模型速度惊人"的说法有一定道理但又有误导性。

2.1 GPU、NPU、CPU在LLM推理里各干什么

一次标准的大模型推理分两个阶段。第一个阶段叫Prefill（预填充），模型要一次性把用户输入的整个prompt吃进去，并行计算出所有token的中间状态，这个阶段非常吃GPU的矩阵计算能力。第二个阶段叫Decode（解码），模型逐token地生成回答，每生成一个token，都要把模型的所有参数从内存里读取一遍，再配合当前上下文做一次计算。

这就导致一个有意思的现象：Prefill阶段看的是芯片算力，GPU核心越强、并行度越高，首token延迟越低；而Decode阶段看的是内存带宽——每次生成token都要完整读取一次十几GB的模型权重，内存带宽就是道路的限速，GPU算力再高也得在路上等数据。Mac mini M6的GPU在Prefill上可能比不过NVIDIA的中高端独显，但在Decode阶段，凭借统一内存的高带宽表现，反而能跑出让人意外的成绩。

2.2 一个公式看懂：Decode速度≈内存带宽÷模型体积

把模型加载过程简化成"每次生成token都要把模型参数全读一遍"，那么理论上的Decode上限就约等于：

Decode速度(每秒token数) ≈ 内存带宽 / 单次需要读取的模型体积

举个例子。一台32G的Mac mini，如果有效内存带宽在200GB/s左右（M系列标准水平），跑一个4.5GB的7B Q4模型，理论上限大约44 token/s，实际到不了这个理想值，但30-40 token/s是可以预期的。当换成19GB的32B Q4模型时，理论值直接掉到10 token/s出头，即使它体积不算离谱，生成速度也会明显感觉得到"慢"。

这就是为什么"跑得动"和"跑得快"完全不是一回事——32G能塞下32B模型，但生成速度是否满足日常使用，取决于内存带宽和模型体积的比值。同样的内存容量，Mac mini这种统一内存机器跑大模型的体验，反而比很多配大内存但内存频率低的PC更顺畅，就是带宽的功劳。

2.3 软件栈选型：Metal、MLX、llama.cpp、Ollama的差异

Mac上跑大模型，软件栈的选择对最终体验影响极大，甚至比硬件差异还明显。目前主流的有四条路：

• llama.cpp：纯C++实现，针对Apple Silicon有专门的Metal后端优化，成熟度最高，支持模型格式最全。优点是可调参数细，缺点是很多人用不惯命令行。
• Ollama：基于llama.cpp封装的一键部署工具，把模型下载、运行、API服务全包了，是Mac上最简单的人门方式。缺点是黑盒属性强，想精细调整推理参数得翻文档。
• MLX：苹果官方推出的机器学习框架，MLX-LM专门针对Apple Silicon的统一内存做了深度优化。实测部分模型在MLX上的Decode速度会略快于llama.cpp，但不支持所有模型架构。
• vLLM：服务端高并发神器，在Mac上支持有限，通常配合容器使用，做生产服务时才会考虑。

我给新手的建议是：先用Ollama把流程跑通，感受"能跑大模型了"这件事；等你想优化速度、压榨性能了，再切换到llama.cpp或MLX。我自己日常用的是llama.cpp的Metal版，因为它能让我精确控制KV Cache大小、线程数、量化策略，在32G机器上做压力测试时很有用。

3. TPS虚高从哪来：一套能复现的实测口径

在聊"实测TPS"之前，必须先谈一个很多评测博主不愿意细说的事：你看到的TPS数字，很可能是"虚高"的。我见过有人在Mac mini上跑出"7B模型170 token/s"的成绩，实际一问，测的是空输入、短输出、忽略首token延迟的结果；换成日常对话场景，能把系统拖到卡顿。这里不针对任何人，只讲TPS数据是怎么被"美化"的。

3.1 Prefill和Decode要分开看

绝大多数推理框架在输出评测数据时，默认给出的是从开始生成到结束的平均token速度。这个平均值是Prefill和Decode混在一起的。问题在于，Prefill阶段一次性处理几百个token的输入，速度可以非常快（单体计算密集）；而Decode阶段逐token生成，速度慢得多。两者的平均结果，完全取决于测试时输入和输出的长度比。

举个例子：如果你输入一个2个token的prompt，生成100个token的回复，那么整体TPS几乎等于Decode速度；但如果你输入800个token的prompt，生成50个token的回复，TPS会被Prefill的高速度显著拉高，看起来"又快又强"。实际聊天时，用户的输入往往不短，模型的回答也不短，混合场景下的真实体感往往低于评测数字。

3.2 虚假TPS的五个常见来源

我把常见的"虚高"原因整理成了一份清单，你在看任何大模型评测时都可以拿这个对照：

1. 空上下文测试：不加任何system prompt和历史对话，直接从零开始生成，内存压力最小，速度自然最快。真实使用时，几轮对话下来KV Cache填充完毕，速度会明显下降。
2. 忽略TTFT（首token延迟）：只统计第一个token之后的平均速度，把用户等待"开始输出"的时间排除在外。TTFT在长输入场景下可能长达几秒，这部分的体验损失被完全抹掉了。
3. 低温采样：temperature=0甚至直接greedy解码，避免了采样阶段的额外开销。虽然影响通常只有几个百分点，但够把数字"修"好看一点。
4. 短输出测试：只生成几十个token就把计时停掉，还没等KV Cache膨胀和中后段的减速出现，测试就结束了，测出来的当然是"峰值速度"。
5. SOTA格式模型+激进量化：用专门为原始性能调优的GGUF格式，配合Q2/K2这类极低质量量化来减小模型体积，速度是快了，但输出质量明显崩坏，这种速度在真实任务里没有价值。

3.3 一套可复现的TPS测试方法

那怎么测才能得到"可信"的TPS？我自己有一套固定的测试口径，你可以直接照搬：

• 固定输入长度：用一个400-600 token的固定prompt作为测试输入，记录TTFT（从发起请求到生成第一个token的时间）。
• 固定输出长度：生成200个token后截断，统计从第一个token到第200个token之间的速度，即"Decode速度"。
• 分两个场景测：空上下文场景（模拟新对话）和不带历史但有长输入的场景（模拟论文、长文档处理）。
• 跑三次取中位数：每次都要重启模型进程，避免缓存热度和KV Cache状态影响结果。
• 记录内存峰值：观察模型加载后、长输出后的内存占用，判断32G是否真的"够用"。

我通常用llama.cpp自带的benchmark工具直接跑，命令行指定固定prompt和生成长度，或者手动写一个Python脚本调用本地API，控制输入输出的token数，采集TTFT和Decode速度。下面这个命令可以作为一个模板：

./llama-cli -m model.gguf \ -p "这是一个用于TPS测试的固定提示词，请基于以下背景，详细回答一个关于本地大模型部署的问题……" \ -n 200 -t 8 -ngl 99 --temp 0 \ --metrics

--metrics会输出详细的计时信息，包括prompt processing time和generation time，一换算就能得到真正分离的Prefill和Decode速度。这样测出来的数字，才配叫"真实TPS"。

4. 32G Mac mini M6实测：哪些模型跑得动、跑到什么速度

下面进入正题：32G Mac mini M6在主流模型上到底能跑出什么速度。我先声明一点，实际速度受芯片型号、系统版本、推理框架版本和室温散热的影响很大，下面的数字是我个人在中低负载下的实测参考值，你可以作为选型依据，但不用当成绝对标准。

4.1 主流模型档位的TPS参考区间

先给出我实测中最有代表性的几组数据（均使用Q4或Q8量化，Metal后端，模型从Ollama库拉取）：

这个表里的区间跨度比较大，是因为温度、并发、上下文状态都会影响速度。7B到14B这个区间，Decode速度在30 token/s以上时，人已经基本感知不到"一卡一卡"的逐字输出，体验接近网页端的GPT-3.5级别；而32B模型的10-16 token/s，读起来像"打字机速度"，能接受，但谈不上爽。

4.2 CPU、GPU、MLX三种回退模式的表现对比

Mac上的推理框架普遍支持三种运行后端：纯CPU、GPU（Metal）、以及MLX的高性能模式。我特意在同一台机器上做了对比测试：

• 纯CPU：7B Q4模型大约12-18 token/s，完全可以用，但明显比GPU慢。优点是占用内存更少，系统更稳定，适合在后台挂一个模型给其他应用偶尔调用。
• GPU/Metal：7B Q4大约55-75 token/s，整体速度约为CPU的3-4倍。这是日常推荐的模式，缺点是显存（统一内存）占用高，一旦超过32G就会出现"模型跑到Swap磁盘"的灾难情况。
• MLX优化：在部分模型上比Metal再快5%-10%，特别是在长上下文场景下，MLX的内存管理更聪明。它的问题是模型格式要专门转换，GGUF生态里的模型不能直接用，需要在这两者之间做个权衡。

我现在的策略是：日常用Ollama（走Metal），研究性能或做长文本处理时切MLX-LM，CPU模式只在需要"安静运行"或内存紧张时使用。

4.3 长期跑起来的实际体感：多轮对话、并发请求和发热

静态测速只能说明"峰值"，真实使用还要看三件事：多轮对话后的稳定性、并发请求的能力、以及长时间跑模型会不会过热降频。

多轮对话方面，我拿14B模型连续聊了30轮，上下文长度从几百token涨到4000多token。前10轮速度几乎没有变化，20轮之后能感觉到生成速度有所下降，但还在可用范围。这是因为KV Cache增长后，每一步需要处理的数据变多了，macOS的内存压缩机制也开始介入。32G内存跑14B Q4模型，极限大概在8K-16K上下文之间，超过这个范围就该考虑清理会话。

并发请求是Mac mini相对薄弱的一环。单用户对话没有压力，但如果你把它当成局域网共享AI服务，同时接两三个客户端的请求，TPS会快速下滑。实测同时有3个会话请求8B模型，每个会话的Decode速度大概掉了20%-30%，而且内存占用会叠加。它适合"个人AI工作站"的定位，不适合直接对标云端的高并发负载。

发热降频在32G Mac mini上表现还不错。M系列芯片的整体功耗控制做得好，连续跑半小时7B模型，机器只是温热，没有明显的性能衰减。不过别把它塞在不通风的电视柜里，全封闭小空间还是会影响散热。

5. 端云决策：本地跑得动不代表应该本地跑

最后一个也是我特别想聊清楚的问题：既然本地跑得动，甚至跑得还不慢，是不是所有任务都应该塞到这台Mac mini上？答案是否定的。本地和云端各有不可替代的位置，机械地"能本地就绝不云端"和"全都用云端API"两种极端，在32G Mac mini这个档位上都会浪费资源。

5.1 这几个场景请毫不犹豫地留在端侧

• 隐私敏感数据：病历、企业内部文档、未公开代码、个人简历，这些内容只要传到云端API，就等于默认把数据给别人了。哪怕API平台承诺不用于训练，很多人依然不敢冒这个险。本地部署就没有这个问题，模型文件完全在你自己手里，请求不出局域网。
• 离线或弱网环境：飞机上、客户内网、断网状态下的数据查询，云端根本指望不上，本地模型是唯一可用的AI能力来源。
• 毫秒级响应的交互场景：你做一个桌面辅助工具，希望键盘一敲就出结果，走云端API即便再快也有网络延迟，本地推理的稳定低延迟更有优势。
• 高频、低难度调用：一些固定格式的信息抽取、分类、拼写修正、日常文本润色，单次调用价值低但频率极高，全走云端API会累积出一笔不小的账单，本地模型几乎零边际成本。

我测试过一个具体案例：把Mac mini M6作为局域网共享的文本改写服务，用8B Q4模型，响应速度在300-600ms之间，比调用任何云端API都快，而且完全不需要担心请求量。这类任务就是端侧的甜点区。

5.2 这些场景别勉强端侧，交给云端更合适

本地模型的能力上限是明摆着的——32G内存能装的模型最大也就32B量化档，它和云端最强模型之间的思维深度、知识面、多模态能力差距，靠量化或工程优化是无法填平的。

• 复杂推理和长链条任务：写多轮技术方案、调试复杂代码、分析一篇长论文的逻辑链条，32B本地模型的错误率和"一本正经胡说八道"的情况远高于云端大模型。这种任务省那几块钱API费，往往得不偿失。
• 超长输入处理：几万字的小说、一百页的PDF、超长代码仓库，本地模型的上下文窗口放不下，硬塞只会OOM。云端模型的百万级上下文可以轻松搞定。
• 高并发、高可用服务：对外提供API服务，或者多个同事同时使用，本地单机扛不住负载，一旦断电、卡死，整个服务就瘫了。云端有完整的运维保障。
• 最新模型和更新频率：云端API几个月就更新一次能力更强的模型，本地模型你得自己下载、转换、调优，这个维护成本很多人低估了。

5.3 混合架构：让Mac mini做"前端调度员"

真正合理的使用方式，是端云混合：让本地小模型当大脑的"助理"，云端大模型当"专家顾问"。这个模式我实践了很久，非常推荐。

具体来说，可以分为三层：

第一层，本地模型做意图识别和路由。用户的所有请求先打到Mac mini的本地模型，由它判断：这是一个简单请求，还是需要调用云端的复杂请求？简单请求直接本地处理掉，复杂请求再转发到云端API。这样90%的日常请求都留在了本地，只有少数高价值请求才会产生API成本。

第二层，本地模型做预处理和结构化。把用户输入拆成结构化数据——提取关键实体、修正拼写、整理格式，然后再发给云端。这样云端收到的是规整的请求，输出质量会明显提升，同时因为输入精简了，token消耗也变少。

第三层，云端结果回流到本地做后处理。云端返回的答案经过本地模型做一遍格式整理、内容过滤、引用检查，再呈现给用户。这样用户看到的永远是干净、符合预期的输出，云端模型的"话痨"和"答非所问"会被过滤掉一部分。

我之前用这个架构做过一个项目：Mac mini本地跑8B模型做全流程调度，云端只在用户明确要求"写一份完整方案"或者"分析这个数据表格"时才被调用。结果一个月的云端API费用控制在几美元以内，而日常随时可用的AI助手体验，比纯云端方案稳定得多。这种"端侧掌握入口、云端按需出场"的模式，才是32G Mac mini M6比较理想的位置——它不需要和云端硬拼算力，它把住的是"最后一公里"的智能调度。

最后再分享一个实操技巧：这套混合架构里，本地模型的system prompt非常关键。你可以把路由判断规则写得很明确，比如"如果用户请求涉及数据分析、长文撰写、复杂代码调试，回复EXACTLY: CLOUD_REQUIRED；否则直接回答"。用这种硬性标记让本地模型做判断，比复杂的自然语言路由更可靠，我用了很久没出过岔子。32G的Mac mini M6跑大模型，真正的价值不在于和云端比谁快，而在于把AI能力从"按次付费"变成"随时可用"——这个感受，只有真的把它跑起来才体会得到。