没跑过几百次本地模型部署你可能觉得硬件这事儿就看显卡显存大小。我一开始也这么想直到把 MoE 架构的模型、CPU 推理、NPU 板卡、32GB Mac mini 挨个试了一圈才发现参数表上的数字和真实体验完全是两回事。这篇文章就把我说人话、摆数据、不吹不黑地拆开讲讲本地大模型硬件到底怎么选、怎么调尤其适合那些准备花预算但还没拿定主意的朋友参考。1. 被“参数总量”骗了太久MoE 才是算力的分水岭很多朋友一上来就问“我 32GB 内存能不能跑 70B 模型”这个问题本身就暴露了对架构的不了解。同样是 70B稠密模型和 MoE 模型的硬件需求天差地别。想搞清楚本地部署该买什么第一步不是看显卡价格而是看模型到底是怎么算的。1.1 稠密模型和 MoE 的本质差别传统的大模型比如 Llama 3.1 70B、Qwen2.5 72B属于稠密模型。每次推理时无论输入什么内容模型里的所有参数都会参与计算。你可以把稠密模型想象成一家没有分工的公司任何任务进来全公司几千号员工都要放下手头的事情一起上人力利用率看似高但大部分人都只是在旁边帮倒忙白白消耗资源。MoEMixture of Experts专家混合则是另一套玩法。它把模型拆成很多个专家子模块每次推理只需根据输入内容挑选其中几个专家干活。还是那家公司但现在分成很多小组来了任务先由一个路由器判断该派哪几个小组其他小组继续歇着。这就是稀疏激活机制。媒体总爱强调 MoE 模型的总参数量动辄上百亿但真正决定性能开销的是“活跃参数”——每次实际被调用的那部分。这个差异直接决定了硬件选型。稠密模型要求你把全部参数塞进显存或内存占用的空间和总参数量成正比MoE 模型虽然整体文件很大但单次计算量只集中在少量专家上所以运行时的内存压力和计算压力都比同体量稠密模型低一个量级。这也是很多人在 32GB 内存设备上跑 14B 级别 MoE 模型体验反而比跑同体积稠密模型更流畅的根本原因。1.2 MoE 对推理硬件的影响内存与计算分离搞懂了稀疏激活接着看它对硬件的三个关键影响。第一负载压力从“单次全量计算”变成了“大内存加载 小步快跑”。MoE 模型的所有专家权重都存在内存里但每次计算只动其中的几个。这就像你仓库里堆了两百箱货但每天只开其中五箱。仓库面积决定你能不能装下搬运工的数量决定你干活快不快。所以内存容量是门槛计算吞吐是速度两者各管各的。第二内存带宽成为真正瓶颈。哪怕只激活部分专家读取权重时依然要把那些专家参数从内存搬到计算单元。如果内存带宽不够比如普通电脑 DDR5 那几十 GB/s 的吞吐光搬运参数就耗时巨大计算单元再好也只能干等着。GPU 之所以碾压 CPU核心优势之一就是上千 GB/s 甚至更高的显存带宽。Mac mini 的 M4 和 M4 Pro 统一内存带宽能达到 100-270GB/s 级别也正因为这个才在本地推理里有了一席之地。第三KV Cache 的占用不一样。长上下文对话会缓存历史计算的 Key 和 Value 值MoE 模型虽然专家多但 KV Cache 只和注意力层的规模和上下文长度有关和专家数量不直接挂钩。这意味着 32GB 内存如果跑 MoE 模型上下文长度反而有更多喘息空间不容易像稠密模型那样几分钟就被缓存塞满。1.3 能落地的 MoE 模型盘点目前普通人能直接拉下来跑的 MoE 模型已经不少我实测过几个有代表性的Qwen2.5-14B-Instruct-A14B全称有点绕参数总量约 14B但激活参数只有约 2.7B。千问系列在中文任务上一直稳这个模型在 32GB 内存上很舒服。Mixtral 8x7B欧洲版 MoE 代表作总参数 46.7B每次激活两个专家约 12.9B。它在 34B 左右的存储占用下推理速度接近 14B 稠密模型英语能力强。Qwen3-30B-A3B总参 30B、激活 3BQ4 量化后大约 18GB 文件32GB 内存设备跑得动是当下 Mac mini 这类设备的甜点模型。DeepSeek-V2/V3 系列MoE 做得最激进的一档激活参数比极低。但模型体积太大本地部署基本要小几百 GB 硬盘和至少 128GB 内存起步普通用户可以直接略过。选择思路很简单如果机器内存 16GB优先看 7B 稠密模型的 4bit 量化版如果内存 32GB-64GB直接冲 MoE 架构的 30B 总参级别量化版性价比最高。总参数量大不等于带不动活跃参数才是硬指标这个观念真得转过来。2. CPU、GPU、NPU不是在选芯片是在选带宽和生态明确了模型架构的底层逻辑再看硬件就清晰多了。CPU、GPU、NPU 三条路线我全都实测过也踩过不少坑这里把各自的定位和适合人群讲明白。2.1 CPU 路线内存为王速度垫底CPU 推理属于“没显卡也能玩”的底线方案。核心原理是让 CPU 直接通过内存读取模型权重在寄存器里做矩阵乘法。关键在于内存带宽不在 CPU 核心数。家用电脑双通道 DDR4/DDR5 的带宽通常只有 45-70GB/s跑 7B 模型的 4bit 量化版每秒只能蹦出 5-10 个 token读一段 500 字的回答得等一分多钟体验比较考验耐心。但 CPU 路线有两个不可替代的优势。一是成本极低老电脑加根内存条就能跑不花钱买显卡二是容量扩展宽松普通主板插满 128GB 内存也不难能跑得动大模型的量化版而单张显卡显存撑死也就 48/80GB。所以如果你只是偶尔在本地跑跑小模型做测试或者预算有限CPU 路线完全能用。另一个技巧是优先选带 AVX-512 指令集的 CPU比如目前几代至强和锐龙数学计算的向量化程度高推理速度能比普通 CPU 快 30%-50%。压缩模型时选适合 CPU 的 k-quants 量化比如 Q4_K_M、Q5_K_M能明显减少解码时的计算损耗。2.2 GPU 路线显存容量决定你能跑什么GPU 是本地大模型的性能标杆。核心指标不是你常听说的“多少 TFLOPS 算力”而是显存容量和显存带宽。你跑 7B 模型 Q4 量化需要约 5GB 显存14B 需要约 9-10GB32B 需要约 20GB70B 则需要约 40GB 以上。显存不够模型根本加载不进去算力再高也一样白搭。这背后是权重的存储逻辑半精度模型参数多大显存就得有多少剩量。比如 7B 参数的 FP16 模型权重有 14GB4bit 量化压缩到约 4.5GB再加 KV Cache 和推理中间层想舒舒服服跑起来最好有 8GB 以上显存。所以消费级显卡里 RTX 4090、4080 的 16GB/24GB 显存是针对 32B 以下模型的主流选择要跑 70B 级别基本得考虑双卡拼接或专业卡比如 A100、A6000 这类大显存产品成本也随之上了一个台阶。GPU 路线的调优重点排序是先解决显存容量再追求带宽最后才看算力。拿 A100 80G 和 RTX 4090 比A100 显存带宽约 2TB/sRTX 4090 约 1TB/s虽然 4090 的 FP16 算力高但推理受显存带宽约束更明显真跑同规模大模型时A100 反而可能更稳。这一条经验在我实际部署中反复验证过。建议你决定买什么卡之前先明确要跑的模型和解码速度预期再把显存带宽放在选型表第一位。2.3 NPU 路线能效比诱人但要接受兼容性NPU 是这次观察中最有意思的一条线。英特尔 Meteor Lake 之后的酷睿 Ultra 系列、高通的骁龙 X Elite 等平台都集成了专用于 AI 推理的 NPU 单元算力从十几 TOPS 一路卷到几十 TOPS。它的核心定位是低功耗、持续推理比如在笔记本上长跑语音识别、图像分类这类轻量模型能效比远超 GPU。但我实测下来NPU 跑大语言模型目前还有很多坎。首先是生态各家 NPU 的编程模型和运行时都不一样必须有对应的推理引擎支持才能用不像 CUDA 那样一套代码到处跑。其次是显存/内存访问路径特殊NPU 通常共享系统内存但访问机制和 CPU 不一样跑大模型时性能发挥不稳定。再次是模型支持范围社区常见的 Ollama、llama.cpp 目前对 NPU 的适配还在路演阶段。所以我的结论是NPU 适合作为轻薄设备的 AI 加速器跑通一些中小模型但如果你想本地部署 7B 以上模型跟 GPU 比还不现实。顺手一提某些厂商宣传“NPU 跑大模型无压力”时多数指的是量化到极致的小模型或特定优化场景不要被营销话术带偏。2.4 一张表看懂三条路线怎么选维度CPUGPUNPU单次成本低高中集成在CPU/SoC中内存容量上限高128GB可行低消费级24GB封顶受系统内存限制内存带宽45-70GB/s家用500-2000GB/s共享系统内存但路径特殊大模型推理速度慢几token/s快数十至数百token/s中小模型可用大模型不稳定生态成熟度高llama.cpp、Ollama均支持最高CUDA/AI生态完善低各家API割裂适合场景白嫖测试、大容量低速度正经本地部署、生产级体验笔记本离线轻量AI、能效优先看完表格你会发现所谓“选择硬件”本质是选择容量、带宽和生态之间的三角取舍。GPU 是全面手CPU 是低成本兜底NPU 是未来增量。谈到 Mac mini它其实是用统一内存架构把这个三角往上抬了一截下面详细讲。3. 32GB Mac mini 实战从选模型到调参数的完整过程很多人一听 Mac mini 就觉得“这也算 AI 服务器”我原本也持保留态度直到用 32GB 内存的 M4 版 Mac mini 跑了一个月的本地大模型服务才发现这套方案的甜点区间比想象中宽得多。下面是完整过程和调优记录。3.1 为什么统一内存架构成了本地部署的“隐藏选项”Mac mini 的核心竞争力在统一内存架构。CPU 和 GPU 共享同一块物理内存GPU 能直接访问全部 32GB不需要像独显那样把权重拷贝到自己的显存里。这意味着可被模型利用的“显存”就是整机内存容量。你不需要担心“显卡只有 8GB 显存跑不了 14B 模型”这种尴尬只要整机内存够模型就能塞进去。这个架构在跑 MoE 模型时特别占便宜。MoE 模型总参数大、但活跃参数小每次只是把部分专家读到 GPU 计算单元。统一内存带宽虽不如高端显卡的独立显存但 M4 大约 120GB/s、M4 Pro 大约 273GB/s 的吞吐在中小模型场景下完全够用。再加上 M 系列 GPU 对 FP16/FP8 这类精度的支持很完善实际解码速度远比参数表上看着吓人。当然它也有短板内存带宽上限就摆在那跑 70B 级别的稠密大模型时依然会卡得明显另外生态里某些量化内核在原生的 Metal 后端上支持度不如 CUDA 精细个别优化技巧要改参数才能生效。但对于个人开发者、企业的轻量内网服务32GB Mac mini 是个性价比很高的节点二手教育优惠的价格也比同性能的 GPU 整机低不少。3.2 模型选择与量化7B、14B、32B 的分界线在这台 32GB Mac mini 上我按使用场景把模型分成三档第一档是 7B-8B 稠密模型对应 Qwen2.5-7B、Llama 3.1-8B。Q4_K_M 量化后文件大小约 4.7-5.5GB32GB 内存跑起来非常宽松上下文窗口拉到 8K-16K 都不会有太大压力。适合日常问答、文案生成、API 测试链路速度可以做到 30-50 token/s几乎感觉不到延迟。第二档是 14B 稠密模型和总参 30B 左右的 MoE 模型对应 Qwen2.5-14B、Qwen3-30B-A3B。前者 Q4 量化后约 9-10GB后者约 18GB。32GB 内存跑 14B 稠密模型很稳跑 MoE 30B 则要留意上下文和并发。实测 Qwen2.5-14B 的 Q4_K_M 在 32GB Mac mini 上可达 12-18 token/sQwen3-30B-A3B 可达 10-15 token/s都属于能用但不够流畅的范围。第三档是 32B 稠密模型如 Qwen2.5-32B 的 Q4 量化版文件约 20-23GB。勉强能加载到 32GB 内存但系统可用内存会被压到极低速度掉到 5-8 token/s而且动不动会触发 macOS 的内存压缩交互体验不太行。如果你只有 32GB这一档不适合日常使用至少得 48GB 或 64GB 才从容。我的核心建议是32GB 机型的最佳性价比区在 7B-14B 稠密模型或总参 30B 级别的 MoE 量化模型。量化等级默认选 Q4_K_M 或 Q4_0再往上提精度的收益有限内存开销却明显增加。3.3 Ollama 部署与关键参数调优本地部署我选 Ollama理由很简单跨平台、命令行友好、自带模型仓库而且支持 OpenAI 兼容 API后续接开发框架非常方便。安装一条命令搞定但真正跑得顺需要调几个关键参数这里着重讲。# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取模型以 Qwen3-30B-A3B 的 Q4 量化为例 ollama pull qwen3:30b-a3b-instruct-q4_K_M # 启动服务前台模式方便看日志 ollama serve关键的调优藏在环境变量里。我在~/.zshrc或~/.bash_profile中配置了以下内容# 并发请求条数Mac mini 上推荐 1-2太大会导致内存吃紧 export OLLAMA_NUM_PARALLEL1 # 模型驻留时间设为 20m 避免频繁加载模型 export OLLAMA_KEEP_ALIVE20m # 开启 Flash Attention大幅降低长上下文的显存压力 export OLLAMA_FLASH_DECODE1 # KV Cache 上限32GB 内存建议设为 8GB-12GB export OLLAMA_KV_CACHE12G这里面的逻辑我展开说下。OLLAMA_NUM_PARALLEL不是越高越好它代表多少个请求可以同时进入解码阶段。在 Mac mini 这类统一内存设备上每个并发请求都会占一块额外的 KV Cache并发条数过高会直接挤掉模型权重的内存空间导致系统开始用 Swap速度断崖式下降。实测 1 条并发、20 分钟驻留是最稳的组合。OLLAMA_FLASH_DECODE的作用是把注意力计算改成分块处理减少中间激活对内存的瞬时占用。这个开关在长上下文场景下收益明显默认不开强烈建议打开。OLLAMA_KV_CACHE是直接控制 KV Cache 上限的参数设置太小会导致上下文被截断设置太大会挤占模型室温。32GB 内存跑 14B 模型一般设 8-12GB跑 7B 模型可以放宽松到 16GB。如果你觉得上下文不够用优先考虑调这个而不是盲目拉长 num_ctx。3.4 实际测试数据与性能表现参数调完之后我用几个真实任务做了对照测试。测试统一用 8K 上下文并发 1输出 300 字左右分别记录首 token 延迟和平均生成速度。模型内存占用平均生成速度首 token 延迟主观体验qwen2.5:7b-instruct-q4_K_M7GB42 token/s0.4s流畅无卡顿qwen2.5:14b-instruct-q4_K_M12GB15 token/s1.2s可接受略微等待qwen3:30b-a3b-instruct-q4_K_M19GB12 token/s1.8s基本可用内存紧张llama3.1:8b-instruct-q4_K_M6.8GB38 token/s0.5s流畅英语较好数据说明两个问题一是 7B 模型体验好到可以直接对外提供服务14B 以上才需要考虑速度优化二是 MoE 模型虽然总文件大但解码速度反而接近体积小一半的稠密模型这就是稀疏激活的威力。在实际写代码、写摘要这些任务里7B 模型偶尔会逻辑短路14B 以上稳定很多如果对质量有要求建议把 14B 稠密或 30B MoE 作为保底配置。还有一个很容易被忽略的细节Mac mini 的电源管理和散热对推理速度影响很大。默认是“自动”省电模式跑长任务时可能降频速度掉一半。我在“系统设置 - 电池 - 电源适配器”里把所有选项改成“高性能”和“不关闭硬盘”推理速度才回到稳定峰值。加上 Mac mini 的被动散热结构环境温度超过 30 度时建议加个笔记本散热垫亲测能降 3-5 度速度也稳一点。3.5 接 Dify 和 API 服务的完整链路本地模型跑起来后要接业务系统基本绕不开 Dify 这类 LLMOps 平台。Dify 的模型供应商里可以直接填 Ollama 的 API 地址整体流程很简单但有几个坑要提前避开。进入 Dify 控制台的“设置 - 模型供应商 - Ollama”填写API 地址http://127.0.0.1:11434Dify 和 Ollama 同一台机器时模型名称必须和ollama list里的名字完全一致比如qwen2.5:14b-instruct-q4_K_M模型类型选“对话”如果你要做嵌入向量再单独加一个 Embedding 模型一个经常踩的坑是 Dify 走容器部署。如果你用 Docker 跑 Dify容器内的127.0.0.1指向的是容器自己不是 Mac mini 宿主机。解决办法有两个一是用host.docker.internal这个特殊域名代替127.0.0.1二是在 Docker Compose 里配置extra_hosts: - host.docker.internal:host-gateway。我第一次就是卡在这里怎么填都连不通换掉地址立马正常。另一个要注意的是模型超时。Dify 默认的请求超时比较短长文本生成很容易超时报错。在 Dify 的模型供应商设置里把“超时时间”调到 120 秒以上或者按你测试的最慢生成速度留两倍余量。我自己是按 14B 模型每秒 15 token、单次出 1000 字来算超时直接设 180 秒至今没再被超时打断过。如果你不打算用 Dify直接写 Python 调 OpenAI 兼容 API 也很方便from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama, # Ollama 不校验 key但 OpenAI SDK 会校验格式 ) resp client.chat.completions.create( modelqwen2.5:14b-instruct-q4_K_M, messages[ {role: user, content: 写一封请假邮件200字以内} ], temperature0.7, ) print(resp.choices[0].message.content)这套链路实测直接从 Dify 界面发指令到模型返回结果再到前端展示整个过程 3-5 秒内企业内部做知识库问答、审批辅助、自动化摘要已经完全够用。4. 常见问题与排查实录本地部署的九个坑本地部署大模型最大的难点其实不在“部署”而在“遇到问题能不能快速定位”。我把这一个月里踩过的坑整理出来按排查频率排序你看完至少能少走两天弯路。4.1 内存不够 / 速度太慢的排查顺序内存不够的第一反应不要是加内存而是先看你在跑什么。我用ollama ps查过一项常驻模型发现 Qwen3-30B-A3B 默认占掉 21GB 内存而系统本来就需要 5-6GB 空闲。这时候即使还有空间macOS 也会开始压缩内存速度直接被杀到 5 token/s 以下。正确的操作顺序是先ollama ps确认当前加载模型和内存占用适当调大OLLAMA_KV_CACHE会缓解上下文不足但如果已到物理上限就要换小模型或减小上下文长度用memory_pressure命令查看系统内存状态数值红色就说明 Swap 活跃必须降低并发或换更小的量化检查磁盘剩余空间llama.cpp/Ollama 在内存紧张时会把部分 KV Cache 落到磁盘磁盘速度就是新的瓶颈。速度慢的排查也有优先级先看模型是否在内存里再次强调ollama ps如果显示“加载中”就说明反复换入换出再看内存带宽是否跑满用powermetrics或top观察 CPU/GPU 占用率最后才考虑换量化等级。我见过有人一觉得慢就换 SOTA 模型结果问题出在之前的进程没关掉内存被占了 25GB怎么调都白搭。4.2 Dify 接入失败与 API 超时问题接入 Dify 时最常见的一个报错是“模型调用失败connection refused”绝大多数是容器网络的坑前面已经讲过了。另一个常见报错是“model not found”此时要仔细核对模型名称注意 Dify 不会自动提示可选模型名称完全靠手打大小写、冒号、后缀都不能错。最简单的方法是去 Ollama 里先跑一遍ollama list把名字原样复制过来。还有一类坑是“请求成功但响应为空”。这通常是因为模型设置了较长的上下文而 Dify 把整个聊天历史都发给模型导致单次 token 数超限。可以用OLLAMA_CONTEXT_LENGTH或模型参数限制上下文上限也可以告诉 Dify 的“对话历史轮数”为 6-10 轮别无限累积。另一个隐藏因素是温度参数某些模型在 temperature 很高时输出会退化成空白建议固定在 0.7 以内。超时问题的通用解决办法我在 3.5 已经说过。这里补充一个细节如果你在 Dify 里同时给多个应用接同一个 Ollama 模型要注意并发累加后模型驻留的 KV Cache 会激增超时率会飙升。所以生产环境里Dify 应用层的并发最好限制在 2-4或者给 Ollama 配OLLAMA_NUM_PARALLEL2但别同时调太高否则两边都会挤压系统资源。4.3 企业部署的运维工作量真相很多人问我“公司内网搭一个本地大模型服务到底要不要养个运维”我的回答是看规模。如果只是三五个人做内部工具Mac mini 或者一台 4090 主机就够了日常运维基本为零偶尔更新模型即可。如果是几十上百人生产使用那工作量就会显现出来核心在这几块模型版本管理多个模型混用、回滚版本、封印某个不良输出都要做规范。建议配置统一的模型目录用 Ollama 的 Modelfile 记录版本和参数别裸跑。资源监控要盯内存饱和度、请求延迟、失败率。我见过很多团队在模型卡死和内存溢出之后才想起来看监控每次都手忙脚乱。建议至少部署一个简单的 Prometheus Grafana内置 Ollama 指标就能覆盖大部分需求。配置备份和自动重启Ollama 自身恢复能力一般异常退出后不会自动把模型拉回来。配上 Systemd 或 launchd 的 keepalive 会省心很多。这算是最基础的一次性成本半小时搞定。许可证合规本地部署也要注意模型开源协议商用要确认条款。不同模型授权差异很大企业内部做合规审查时最容易在这里踩雷。反过来说二三十万采购 GPU 服务器后运维工作量确实会陡增要处理驱动版本、CUDA 环境、多卡通信、失败任务重试、模型分发、监控告警。如果只是内部轻量使用真没必要一上来就上这么重的方案。我建议先在 32GB 内存的 Mac mini 或 16GB 显存的消费级显卡上验证流程等并发确实不够了再考虑扩容到专业卡集群。4.4 量化等级选不对速度直接腰斩量化不是选越低越好。Q2 级别模型虽然文件最小但质量损失明显生成内容经常逻辑断裂Q8 或 FP16 又会让内存占用大幅涨高在 32GB 设备上把速度拖成个位数。我的经验是在“跑不跑得动”和“质量够不够用”之间Q4_K_M 是性价比最高的一档大部分开源模型的 Q4_K_M 和 FP16 输出差异已经很小肉眼很难分辨。尤其要注意团结 MoE 模型的量化选择。因为 MoE 的专家参数反复被激活低量化造成的误差会在专家切换间不断累计结果就是偶尔中间句崩坏。我在试 Mixtral 8x7B 时Q2_K 版本出了不少语义混乱换成 Q4_K_M 后恢复稳定。所以如果内存吃紧优先缩减上下文长度而不是压量化等级质量底线会更稳。4.5 mac 特有坑休眠、升级、散热Mac mini 本地部署还有几个特有的坑值得展开。第一个是休眠问题默认设置下机器合盖或闲 20 分钟后会自动睡眠模型服务随之中断。解决办法是安装caffeinate -dimsu常驻命令或者调整系统的能源设置让显示器关闭但主机不休眠。第二个是 macOS 系统更新会打断正在运行的模型甚至导致 Ollama 内核扩展或 Metal 组件失效。经验是不要把大模型部署放在刚升级完系统的机器上先跑几天确认系统稳定再上生产。第三个是散热前面提过 M4 Mac mini 是被动散热长时间满载后温度能到 80 度以上性能大幅下降。加散热垫是最直接的改善手段。我有一次在室内 28 度环境下连续跑 30 分钟长文本速度从 15 token/s 掉到 7 token/s加散热垫后基本稳在 13-14 token/s。结尾我踩完一遍坑后的个人判断这套组合拳试下来我最深的体会是本地大模型硬件没有绝对的最优解只有匹配你的模型、并发、预算和接受度的相对最优解。MoE 模型让小内存设备有了更高上限统一内存架构的 Mac mini 让非 GPU 玩家也能体面地跑起来而 CPU/NPU 路线在特定场景也远没到被淘汰的时候。你要做的不是追着参数表跑而是先算清楚自己最多能接受多慢的速度、能容忍多大的模型体积、有多少预算投入再倒推硬件选型。如果让我给一个最直接的行动建议那就是先拿一台 32GB 内存的 Mac mini 或者 16GB 显存的消费级显卡配 Ollama 跑通 Qwen 或 Llama 的 7B/14B 量化模型把 Dify 这类平台也接上完整跑一遍你自己最常用的三个任务。这个过程中的瓶颈和惊喜都会告诉你下一步该往哪边升级。最后再提醒一句模型更新频繁硬件决策尽量留一点余量内存和显存永远比算力更早成为瓶颈。