本地大模型档位对照表

新增 B 参数速览；横向滚动查看，表头、“模型档位”和“B 参数”列已冻结。

模型档位 B 参数 64GB 能否舒服运行 128GB 能否舒服运行 舒服运行的最低推荐配置 64GB 舒服上下文 128GB 舒服上下文 最大上下文 上下文体感 64GB 本地吞吐参考 128GB 本地吞吐参考 线上 API 吞吐参考 代表模型 总参数 / 激活参数 4bit 文件体积 8bit 文件体积 与 Codex 长上下文差距 适合任务 不适合任务 跟线上满血模型差距 实用结论
小模型 8.2B 舒服 舒服 16GB 起可跑；24GB 起更从容；64GB 是“几乎不用想内存”档 7 32K-64K 64K-128K 131K（Qwen3 8B with YaRN） 4 短文、十几页文档、较长多轮聊天 DeepSeek R1 8B / Ministal 8B / Qwen3 8B 在 64GB Mac 上约 97-98 tok/s；M4 Pro 24GB 上 Qwen3 8B 约 82 tok/s 8 Qwen3 8B 在 M5 Max 128GB 上约 98 tok/s 9 高频在线模型常见约 80-220 tok/s，取决于模型与服务商 10 Qwen3 8B、DeepSeek-R1-0528-Qwen3-8B、Llama 5 8B 4 8.2B dense（Qwen3 8B） 4 Qwen3-8B Q4_K_M 5.03GB；DeepSeek-R1-0528-Qwen3-8B Q4 约 5GB 级 5 Qwen3-8B Q8_0 8.71GB 6 在线 Codex / GPT-5.4 / GPT-5.5 的标准长上下文已到 272K-400K，部分场景可到 1M；本地 8B 的“舒服上下文”仍明显更短 11 OCR 后清洗、翻译、字幕整理、会议纪要初筛、轻量脚本辅助、小型 RAG、本地客服/离线助手 超长代码库理解、复杂多步推理、高质量 Agent 规划、大型知识库一次塞入 参数量、稳健性、工具调用与长上下文整合，仍明显落后在线前沿模型 12 64GB 完全够用；128GB 不应为这档模型买单
中模型 14.8B 舒服 舒服 24GB 起实用；64GB 明显宽裕 17 32K-64K 64K-128K Qwen3 14B 为 131K；部分新 14B 可更长，但“舒服值”仍远小于标称值 13 一篇长稿、较长访谈、一个中等代码模块 Qwen3 14B 在 M5 Max 64GB 上约 58 tok/s；Phi-4 14B 在 M5 Max 64GB 上约 62 tok/s 3 Phi-5 Medium 14B 在 M5 Max 128GB 上约 65 tok/s 18 同上：在线常见 80-220 tok/s 10 Qwen3 14B、Ministral 14B、Phi-4/5 Medium 14B 13 14.8B dense（Qwen3 14B） 14 Qwen3-14B Q4_K_M 9.00GB 15 8bit 通常约 15-16GB；同类 14B 在 Apple Silicon 实测 58-65 tok/s 区间 16 在线长上下文仍更大；本地这档更像“速度和体感甜品”而非“长上下文机器” 11 代码片段解释、文档改写、文章润色、会议与播客转写后的再整理、本地翻译 大仓库全局重构、超长报告综合、复杂研究助手常驻 上下文、稳定性、复杂推理上仍弱于云端前沿；但性价比与低延迟非常好 12 64GB 的黄金甜点位之一
甜点位 dense 32.8B 可用到能忍之间：短上下文能干活，长上下文和重度多任务会明显卡感 可高频用 真正常用建议 64GB 起；如果想把它当主力编码/知识整理模型，128GB 更稳 22 8K-16K 16K-32K 128K-131K（模型官方），但 dense 32B 长上下文代价高 19 长文章、长 PR、单仓库一个较大的子模块 Qwen3 32B 在 M4 Max 64GB 约 22 tok/s；DeepSeek R1 32B 在 M5 Max 64GB 约 27 tok/s 22 Qwen3 32B 在 M5 Max 128GB 约 28 tok/s 23 在线前沿 / 高速开源 API 约 80-220 tok/s 10 Qwen3 32B、DeepSeek-R1-Distill-Qwen-32B、Qwen2.5-Coder-32B 19 32.8B dense（Qwen3 32B） / 32B dense（R1 Distill 32B） 19 Qwen3-32B Q4_K_M 19.76GB；R1 Distill 32B Q4_K_M 19.85GB 20 Qwen3-32B Q8_0 34.82GB；R1 Distill 32B Q8_0 34.82GB 21 长上下文与稳定性仍明显不如在线；Codex/GPT-5.5 400K、GPT-5.4 272K 标准窗口已超本地 dense 32B 标称或至少更易用 11 本地代码问答、私有代码库局部改写、长文摘要、较重推理、离线知识助手 多小时逐字稿一次性吞下、超长 agentic coding、多人并发、多代理后台常驻 能力像“云端大模型的局部投影”，不是等价替代；dense 32B 已经接近 64GB 上限的高频边缘 24 64GB 能上，但 128GB 才开始“真舒服”
甜点位 MoE / 混合注意力 30.5B / 3.3B active 舒服，这是 64GB 上最有价值的一档 非常舒服 24GB-48GB 已可实用；64GB 已很强；128GB 主要换来更大上下文与多任务余量，而不是“能不能跑” 28 32K-64K 64K-128K 262K（Qwen3.5/3.6/30B-A3B 同档） 29 长报告、多小时访谈的分段处理，比 dense 32B 更从容 Qwen3 30B-A3B 在 M5 Max 64GB 约 62 tok/s；Qwen3.5 35B 在 M5 Max 64GB 约 52 tok/s 16 Qwen3.6 35B-A3B 在 M5 Max 128GB 约 55 tok/s；M4 Max 48GB 约 42 tok/s 2 在线仍普遍更快，尤其在大输入与多用户并发下 12 Qwen3 30B-A3B、Qwen3.6 35B-A3B、Qwen3-Coder-30B-A3B 25 30.5B / 3.3B active；35B / 3B active 25 Qwen3.6-35B-A3B Q4_K_M 22.29GB；Qwen3.5-35B-A3B Q4_K_M 22.29GB；Qwen3-30B-A3B 量级约 20GB 出头 26 Qwen3.5-35B-A3B Q8_0 37.81GB；同档多在 35-38GB 级 27 在线长上下文仍更大；但这档已经是“本地高频工作流甜点位”最接近云端体验的一类 28 私有码仓编码助手、长访谈摘要、批量标签、Agent 工具链后端、长上下文 RAG、个人知识库 期待它替代 DeepSeek 满血 / GPT-5.5 / Claude 级云端综合能力 优势是私有化、低延迟、批处理和成本可控；不是全面替代云端大脑 30 这是 64GB 与 128GB 都值得围绕它做决策的一档
大模型 dense 70B 能忍 / 不实用：能加载不等于适合日常高频 可用 128GB 才是“日常不痛苦”的起点；64GB 更像实验机 31 4K-8K 8K-16K，必要时 32K 但不舒服 128K（Llama 3.3 70B） 32 中长书稿、较大代码子系统，但等待感明显 Llama 3.3 70B 在 M3 Max 64GB 社区实测生成约 5 tok/s；M5 Max 128GB 官方聚合页约 12 tok/s，MLX 可到约 15 tok/s 35 同左：约 12-15 tok/s；Llama 5 70B 在 M5 Max 128GB 约 18 tok/s 31 在线通常仍快一个量级以上，且 TTFT 更短得多 10 Llama 3.3 70B、Llama 5 70B、DeepSeek-R1 70B distill 类 31 70B dense 32 Llama-3.3-70B Q4_K_M 42.52GB 33 Llama-3.3-70B Q8_0 74.98GB 34 与 Codex / GPT-5.x / DeepSeek 满血相比，长上下文、速度、工具稳定性均有明显差距 11 创作型长文、耐心型离线问答、希望“比 32B 更稳一点”的重任务 高频短问短答、IDE 内来回追问、多 Agent 并发、长上下文敏捷工作流 70B 在 MacBook 上最大的敌人不是“能不能跑”，而是“你愿不愿每天等” 24 128GB 的加分项，但单靠这行不太够构成购买理由
特殊加分项 MoE 109B / 17B active 模型依赖极强：部分能跑，不能泛化 可用，但仍要挑模型与后端 M5 Max 128GB、MLX / 特殊后端优先；不建议把“个别漂亮 benchmark”当普适结论 36 8K-16K 16K-64K，视架构而定 从 256K 到 10M 不等，但“标称长上下文”不等于舒服上下文 36 取决于模型，体验差异极大 Llama 4 Scout 在 M5 Max 64GB 社区汇总约 32 tok/s；Grok 4 Open 在 M5 Max 128GB 约 32 tok/s 36 Llama 4 Scout 在 M5 Max 128GB 官方聚合页约 22 tok/s；更大 MoE 在 128GB 上仍强依赖后端优化 38 在线依旧更稳、更容易开长上下文和工具链 12 Llama 4 Scout 109B/17B、gpt-oss-120b、Grok 4 Open 100B-A20B 36 109B / 17B active；117B / MoE；100B / 20B active 36 Llama 4 Scout Q4 约 50GB 级；gpt-oss-120b 不是标准 GGUF 4bit，而是官方 MXFP4 / 社区实验 GGUF 36 gpt-oss-120b 官方口径为单 80GB GPU 可跑；并非传统 “8bit 笔记本友好” 档 37 线上长上下文和稳定性仍优势明显；本地只是“架构红利型特例”，不是普适替代 11 特定私有流程、指定 MoE 模型、研究型尝鲜、超长上下文实验 把它当所有 100B+ 都适合 Mac 的证据 这类模型最容易制造“128GB 好像无敌”的错觉，但泛化风险最高 36 只有当你明确知道自己要哪一个模型时，才是 128GB 的理由
云端满血模型 671B / 37B active 不适用 不适用 云端多 GPU / 专用推理集群 不适用 不适用 164K-400K 常见，1M 已出现于部分产品或实验能力 41 真正的“大部头”上下文与高并发在线工作 不适用 不适用 DeepSeek V3.2 顶级服务商约 220.5 tok/s；GPT-5.4 xhigh 提供商实测约 83.8 t/s 起，服务商间差异明显 41 DeepSeek-R1 671B、DeepSeek-V4 Preview / Pro、Codex / GPT-5.x 39 671B / 37B active（R1）；V4 为更大前沿稀疏架构；Codex/GPT-5.x 参数未公开 40 不公开 / 不适用 不公开 / 不适用 这就是长上下文的真实参照物；任务书里的“Codex 256K”今天应视作保守旧参照，而不是最新上限 11 大仓库、复杂代理、跨模态、多工具、多用户并发 对隐私严格、离线、低边际成本批处理不友好 本地的价值不是替代它们，而是守住隐私、离线、批量自动化与低延迟局部任务 42 不要把 128GB 当“云端满血替代品”来买