1. 项目概述与需求拆解
提起 openrig，得先聊聊我自己是怎么被它吸引的。前两年折腾本地大模型和私有化部署，最头疼的就是各家方案的硬件组合千差万别，光看文档和社区帖子只能拼个大概，真正上手配置时才发现卡在细节上——什么显存带宽和量化等级怎么匹配、供电冗余预留多少、多卡互联该走 PCIe 还是 NVLink，每一个环节不踩几次坑根本摸不透。openrig 这个名字乍一听像是个开源硬件套件，但深入看进去，它更像是一套把“本地 AI 工作站组装、调试、落地”全流程标准化的开放方案。
从产品形态上讲，openrig 的核心价值在于把散落各处的经验集成成一条可复制的施工路径。它不单是一块电路板或者一组机箱图纸，而是涵盖整机架构规划、核心部件选型、系统镜像配置、推理/微调环境预置，以及运行期监控的一整套打包方案。你拿到它，相当于拿到了一位老手整理好的设备装配手册和避坑指南，从零开始就能把一台能跑 7B 到 70B 参数模型的本地工作站给立起来。
这事的适用人群其实很宽。如果你是想在本地跑大模型、又不想完全被云厂商绑定的技术人，openrig 给了你一个刚性起点；如果你是团队里的基础设施负责人，需要快速给出多套可复制的部署方案，它同样具备参考价值；甚至对那些刚入门、骨架还不太清楚的新手，跟着整套链路走一遍，也能把相关的硬件知识、系统调优思路给补齐。我也见过不少人把它用作教学案例——让学生在一台真实机器上完成驱动安装、推理服务拉起、性能观测这一套完整动作。
潜在需求往深了看，其实是这几年 AI 部署逐步从云端向边缘、向个人工作站扩散的缩影。越来越多需求方想同时兼顾数据私密性、时延可控和长期持有成本，本地化执行逐渐成了绕不开的选项。而 openrig 这样的开放方案，恰好压在了“硬件选型不明、配置基准缺失、上手成本太高”这几个痛点上。与其自己从芯片型号开始啃，不如直接站在一套成熟骨架之上做加减法，这才是省力的做法。
所以我写这篇文章，不会只停留在参数罗列，而是把我实际搭建过程中如何选型、怎么组装、怎么把系统与推理环境一次调通的完整思考路径摊开来讲，同时也把踩过的坑和排查方法一并交付，给你一份可以直接照着做的参考。后面的内容，基本就是我一个人从零开始、把一台 openrig 标准架构的工作站跑通的全过程。
2. 整体设计与思路拆解
2.1 为什么需要一套开放硬件标准
先聊个背景。前些年装一台深度学习工作站，本质上就是逛论坛、翻测评、自己攒配置。有人偏重游戏卡性价比，有人坚持专业卡稳定输出，有人追求多卡并行扩展，各说各话，没有一个中间基准。个人玩玩还好，一旦你要在团队内部推广标准化，或者给多个分支节点统一配置，就会发现每台机器都有“个性”，每次故障排查都是独立案件，维护成本直线上升。
openrig 尝试给出一个解：把整机架构拆成可复用的模块。计算、内存、存储、供电、散热、扩展这几大块分别定义好接口和选型范围，然后整体打包成设计参考。你不需要每次都从零开始纠结“这块主板能不能配那张卡”，因为基准方案已经帮你验证过一轮了。你缺算力就升级计算模块，缺存储带宽就换存储模块，其他部分保持不变，整体设计的稳定性仍然可控。
这套思路很像乐高。同样是搭一座房子，你从一堆散砖开始，和从标准化模块开始，前者的不确定性远大于后者。openrig 的价值正是通过预先定义“哪些组合是经过验证的”，把不确定性降下来。我在实际使用中最直接的感受就是，出了问题排查范围被大大缩小——不再是“哪里都可能错”，而是集中在少数几个变动点上。
所以，openrig 的“开放”二字有两层含义。一层是硬件层面的开放，用户可以根据自身需求在建议框架内替换部件；另一层是软件层面，它不绑定任何私有固件或专有运行时，完全遵循通用的 Linux 驱动和开源推理栈。这种设计取向，让它的寿命周期拉得很长，不像某些品牌整机那样，一旦厂商停止更新，机器就成了信息孤岛。
2.2 架构选型背后的权衡
说回架构本身。一套本地大模型工作站的骨架，通常包含这几个关键决策点：CPU 平台、内存容量与通道、GPU 方案、系统盘和数据盘分离、电源冗余策略。openrig 在这些决策点上的选择逻辑很清楚，就是“按模型需求反推硬件配置”。
以常见的量化模型为例，7B 模型量化到 4bit 大约需要 6GB 到 8GB 显存，14B 大概在 10GB 到 12GB，32B 直接跳到 20GB 以上，70B 级别就得 40GB 起步。这里的“起步”只是把模型权重塞进去，还没算上推理时的 KV Cache 和中间激活。所以选 GPU 不能只看显存能不能装下模型，还得考虑推理时会话长度、并发请求数量带来的额外显存占用。openrig 的推荐配置里，基本都留出了 30% 到 50% 的余量，这个习惯很值得借鉴。
CPU 平台的选择权重比很多人想象中更大。你跑大模型推理，核心计算确实在 GPU 上，但数据从硬盘到内存、从内存到显存的通路是否顺畅，直接影响实际体验。尤其是当 GPU 显存不足以完全容纳模型时，CPU 内存带宽就成了决定性能的关键瓶颈。DDR5 平台相比 DDR4 在带宽上有代际优势，四通道配置能有效支撑部分层卸载到内存的场景。这也是为什么 openrig 的基准方案更倾向于新平台，而不是守着老平台省钱。
存储层的思路是“分层”而非“单一”。系统盘用 NVMe 固态，装系统和驱动；模型盘用大容量固态，专门存放权重文件；数据集和日志放机械硬盘或 NAS 网络存储。这种拆分看似增加成本，实则把故障隔离做得更干净。我就遇到过系统盘和模型盘混用的情况，一次权重文件写入把系统分区挤爆，直接导致推理服务崩溃。分开之后，这种问题彻底从根上消失了。
2.3 为什么本地执行仍是必要选择
很多人会问，既然云端 GPU 随用随开，为什么还要搭本地工作站？我自己的体会是，它并不是跟云端完全对立，而是在“数据敏感性、交互时延、长期成本”这三个维度上取得一个平衡点。
数据敏感性这块最直观。企业内部数据、私有代码库、未公开文档，这些内容如果在本地处理，不需要经过第三方平台的审查和留存，合规压力小很多。对于有保密要求的项目团队来说，本地推理几乎是刚需，不是成本问题，而是原则问题。
交互时延的差距在上手之后很容易感知。本地部署的模型接口延迟通常稳定在几十毫秒级别，相比之下，云端方案受到网络路径、共享负载、区域节点等多重因素影响，延迟波动明显更大。如果你的应用偏重交互式体验，比如实时对话、代码补全、教学演示，这个差距会直接影响产品口碑。
长期成本这点需要算总账。云端的按小时计费看似灵活，但高频使用下，月成本很快就会超过一台中高端工作站的均摊成本。而且本地机器是一次性投入，持续使用一段时间后边际成本趋近于零，还多了硬件残值。当然，这不是说所有场景都适合上本地，如果你只是偶尔调一调 API，云端自然更划算。但如果推理任务已经是日常工作流的一部分，本地执行的经济账就非常值得一算了。
3. 核心细节解析与实操要点
3.1 GPU 与显存选择的黄金规则
先说最关键的部件——GPU，毕竟大模型推理的性能上限九成由它决定。我在选择 GPU 时的第一原则是：显存容量优先于计算峰值。这一点可能和许多人的直觉相反，很多人以为跑模型最看重算力，但实际使用中，当模型无法完整放进显存，就得把部分层卸载到内存或硬盘，性能下降是断崖式的，远不是“慢一点”那么简单。
怎么测算显存需求呢？我一般用一个简易公式：模型参数量（B）× 量化位数 / 8 × 1.3，得到的就是基本显存需求。以 7B 模型、4bit 量化为例，7 × 4 / 8 × 1.3 约等于 4.55GB，这只是纯权重占用，实际推理时还要叠加上 KV Cache、CUDA 上下文、中间激活等开销。因此，如果想跑 7B 模型，至少要 8GB 显存起步；想跑 14B 模型，16GB 显存是底线；32B 模型没有 24GB 往上基本不要考虑。
再往细里说，不同品牌和架构的 GPU 还有各自的脾气。消费级显卡性价比高，但驱动生态和专业卡的稳定性存在差距；专业卡在显存 ECC、多卡通信、长期负载稳定性上有明显优势，但价格直接起飞。我的建议很务实：个人学习和轻量部署选消费级旗舰即可，团队生产环境尽量配备专业卡。这里的判断依据不是“贵就是好”，而是当业务连续性和故障率变成硬指标时，专业卡多出来的成本通常能在维护成本上省回来。
多卡互联也是一个需要提前规划的维度。小规模双卡跑 32B 模型，可以用 PCIe 直连凑合，但通信带宽受限，性能会有折损；如果要跑 70B 以上或者追求高效微调，NVLink 级别的互联能力几乎不可或缺。openrig 的扩展设计在主板选型和机箱空间上给多卡预留了余量，这也是它适合长期演进的重要原因。
3.2 主板、CPU 与内存的匹配规则
选完 GPU，主板和 CPU 的匹配往往容易被忽视，但这里其实藏着不少坑。一个常见的错误是：看主板有 PCIe 插槽就默认能跑满所有 GPU。实际上，消费级平台的 PCIe 通道数有限，你插两张卡，很可能就只能各自跑在 x8 或 x4 模式，性能折损肉眼可见。所以，开跑之前先把主板的 PCIe 通道分配规则查清楚，别只顾着数插槽数量。
我用过的配置里，CPU 选择更多是围绕“内存通道数”和“PCIe 通道数”这两个指标展开的。中高端主流平台的桌面旗舰 CPU 一般支持四通道内存和二十多条 PCIe 通道，配合一块拆分能力好的主板，支撑 1 到 2 张 GPU 比较从容；如果要上 4 卡甚至更多，就不得不考虑工作站级平台，甚至双路服务器平台了。这里的核心不是“核心数越多越好”，而是“通道资源够不够拆”。模型推理和训练场景里，内存带宽对性能的影响往往比 CPU 核心数更直接。
内存容量和 DPC（内存通道占用）同样需要细细考量。大模型场景下，内存不仅是系统运行的基础，还承担着“显存溢出时的二级缓存”这一角色。当模型权重部分驻留在内存中时，内存带宽和延迟会直接体现为 token 生成速度的变化。所以我倾向于在预算允许范围内把内存容量拉高，频宽选主流甜点频率即可，不必追求极致的超频条，稳定性长期看更值钱。
3.3 供电、散热与机箱空间的三重约束
供电这块是很多人装机时最容易犯嘀咕的环节。GPU 瞬时功耗可能比官方标称峰值高出不少，尤其多卡并行时，峰值叠加非常可怕。我的经验是：电源额定功率取整机理论功耗的 1.5 到 2 倍比较稳妥。比如一张 450W 的 GPU，加上 CPU 和其余部件，整机峰值可能到 900W 左右，此时搭配 1200W 到 1600W 的电源才够从容，别卡着理论值买，瞬时功耗超载会让电源触发保护，直接断电重启，那个酸爽谁碰谁知道。
散热方案需要结合机箱空间一起看。不少人只顾着显卡尺寸能不能塞进去，忘了高负载下的散热风道设计。多卡并排安装时，卡与卡之间的间距如果不够，风切和积热会迅速拉高温度，触发降频或者直接让系统不稳定。我的建议是，至少保证每个卡位之间有一个槽位的空间，机箱采用前进后出、底部进风上部出风的风道设计，必要时可以上水冷或专用辅助风扇。
机箱不只是“装得下”的问题，还牵涉到扩展性和维护便利性。如果你计划未来加卡、加硬盘、加扩展卡，机箱尺寸就得提前预留。openrig 实际上在机箱选型上做了一些推荐，思路很直接：塔式机箱优先于紧凑型，不是为了占地方，而是为了给后续演进留出余量。现在省下的空间，以后就是安装时的血泪。
4. 实操过程与核心环节实现
4.1 硬件组装与系统初始化
这一节开始说实在的施工环节。我自己组装 openrig 架构的第一步，是先把所有硬件清单列清楚，逐一确认接口和兼容性。这里有一个装机的通用原则：先装电源，再装主板，然后装 CPU、内存、固态，最后才轮到 GPU 和扩展卡。按照这个顺序操作，能避免过程中反复拆装线缆、碰到其他部件的麻烦。
通电开机后第一件事就是进 BIOS，开启对应平台的虚拟化支持、调整内存频率配置，同时把启动顺序设为 U 盘优先。这一步里最容易忽略的是平台对内存频率的默认兼容性，有时你买了 5600MHz 的内存，默认运行在 4800MHz 甚至更低，需要手动开启内存超频档位。不过我不建议新手上来就拉高频率，先把系统装好跑一遍稳定性测试，再回来调优频率更安全。
系统安装我用的是 Ubuntu 桌面版，版本选择上建议 LTS 版本，稳定性优先。需要注意的一点是，在安装系统时就规划好分区方案：系统分区至少 200GB，模型权重分区单独挂载，预留足够空间给权重文件和未来扩展。我吃过一次亏，当时图省事没分独立分区，结果后期下载模型把系统盘塞爆，整个环境直接崩掉，重新配置掉了一晚上时间。分区这件事，前置做五分钟，后面省五小时。
装完系统后，紧接着是更新固件和驱动。这里有一个很多人会忽略的细节：主板厂商会用新固件修复 CPU 微码和内存兼容性问题，在装完系统后第一时间查一次主板官网，把 BIOS 更新到稳定版本，能预防很多莫名其妙的问题。更新 BIOS 的过程不同主板各有差异，但核心原则是一致的：在更新过程中绝对不能断电，否则可能直接变砖。
4.2 GPU 驱动与 CUDA 环境配置
驱动安装是个经典难点，这里分享一套我已经用得很顺的流程。NVIDIA 驱动安装最省事的方式是使用官方提供的仓库自动匹配，但前提是先把系统自带的默认驱动卸载干净，否则新旧驱动冲突会带来一堆隐患。我的做法是直接进入 tty 模式，停掉显示管理器，然后执行驱动安装命令，全程保持干净的环境。
驱动装完之后就要验证是否生效。用nvidia-smi命令查看 GPU 列表和驱动版本是最直接的检查手段，能正确输出显卡信息基本就说明驱动层没问题。接下来是 CUDA 工具集的安装，这里有一点要特别强调：不要盲目装最新版 CUDA，而是要根据深度学习框架和推理库的兼容性要求来选择版本。很多时候模型运行报错，不是代码问题，而是 CUDA 版本和 PyTorch 或推理引擎的版本要求不一致导致的。
装完 CUDA 后，我习惯用一个小脚本把环境变量固化到 shell 配置里，这样每次开终端就不用手动设置 PATH 和 LD_LIBRARY_PATH。顺便说一句，用nvcc --version确认 CUDA 编译器版本时，注意别只看这个命令的输出，最好同时检查/usr/local/cuda的软链接指向是否和实际安装版本一致。软链接指错导致的“版本不对”问题，排查起来非常隐晦，却经常发生。
另外，Docker 环境下的 GPU 透传也值得提前配置好。现在很多推理服务和模型运行时都倾向于容器化部署，如果 Docker 容器里访问不了 GPU，就等于白装了。装上 NVIDIA Container Toolkit，然后跑一个简单的容器测试一下nvidia-smi是否能在容器内正常输出，把这个环节提前验证完，能避免后期部署服务时再来回折腾。
4.3 推理服务部署：从模型下载到 API 调用
硬件和驱动就绪之后，就可以进入推理服务部署的核心环节了。我通常用 Ollama 和 vLLM 这两套方案作为主力，它们的取舍值得拿出来讲一讲。Ollama 的定位是“开箱即用”，把模型下载、运行时管理、API 暴露几件事用极简的方式封装起来，非常适合快速验证和轻量调用；vLLM 则是面向性能和吞吐优化的引擎，支持高并发和高效的显存管理，更适合把同一模型以服务形式提供给多个消费者使用。
从模型来源讲，我一般从两个地方获取权重：一是 Hugging Face 上直接拉取原始权重，二是直接用 Ollama 或 ModelScope 的模型仓库拉取量化版。这里要提醒的是，Hugging Face 在中国的访问稳定性问题，有时候下载到一半就断了，所以优先考虑国内可直连的镜像源会省心很多。下载模型权重时，千万不要中断重试太多次，最好一次性选好源，耐心拉完。
部署成功后的验证环节同样重要。我习惯先用一段简单的 Python 代码发起一次本地请求，检查返回内容和响应时间是否符合预期。这一阶段别急着上复杂应用，先把“模型能不能正常吐出文字”这个基础问题搞清楚，再逐步加并发、加流式输出、加多轮对话。如果基础调用就不稳，后面的压力测试做得再花哨也没有意义。
4.4 监控体系与性能观测
推理服务跑起来后，监控就成了保证体验的关键。很多人觉得监控是运维阶段的事情，但实际跑起来才发现，没有监控数据，连“慢是因为什么”都说不清楚。我的做法分成三层：硬件层用nvidia-smi定期记录 GPU 利用率、显存占用、温度功耗；进程层记录服务的 token 生成速度和请求排队时长；业务层记录 API 调用的成功率和延迟分布。
硬件层的指标里，最值得关注的是“GPU 利用率和显存占用率是否匹配”。一个典型的低效场景是：显存占用很高，但 GPU 利用率只有百分之二三十，这说明模型权重加载占用了大量显存，但计算量没有撑满，大概率是请求并发不够或者存在串行等待。另一些情况下，GPU 利用率很高、显存也没爆，但 token 生成速度上不去，那就需要看是否触发了显存碎片、PCIe 带宽瓶颈或者 KV Cache 回收策略的问题。
除了传统监控工具，还可以在推理服务内部插入一些轻量日志，把每次请求的prefill 耗时和decode 耗时分开记录。这两项数据是判断优化方向的关键：prefill 慢说明处理长提示词的能力有瓶颈，decode 慢说明单 token 生成效率不够。只有把数据分得足够细，调优时才能对症下药，而不是拍脑袋。
5. 常见问题与排查技巧实录
5.1 显存溢出和模型加载失败
我在实际部署中遇到最多的问题就是显存溢出（OOM），特别是在调试比较激进的量化参数或者把模型加载进一个显存刚好够用的卡上时。这种情况下，报错信息往往会直接提示无法分配显存，但解决方案并不是简单换一张更大的卡，而是要从多个方向同时排查。
第一步看模型本身。现在很多模型都有不同的量化版本，4bit、8bit、16bit 的显存占用差距很大，如果加载失败，先用官方量化版本跑通流程，再尝试更激进的量化方案。第二步看推理参数。上下文长度（context length）直接决定 KV Cache 大小，有时候从 2048 调到 8192，显存占用立刻飙升好几个 GB，遇到这种情况先降回短上下文再逐步往上调。第三步看服务框架是否开启了显存复用机制，比如 vLLM 的 continuous batching 和 PagedAttention 都能显著提升显存利用率，该开的功能别省着。
如果这三种手段都用上还是偶尔出现 OOM，我最后的手段是开启“CPU 卸载”策略，让部分层运行在内存中。这会牺牲一些速度，但至少让服务不会动不动就崩。实际项目中，稳定运行比峰值跑分更重要。
5.2 CUDA 版本不匹配导致的推理报错
说实话，这个坑是我自己踩得最深的一类。明明nvidia-smi显示驱动正常，代码也照着文档写了，但一跑就报各种CUDA error: no kernel image is available for execution on the device或者undefined symbol之类的错误。这类问题九成出在 CUDA 运行时版本和驱动支持的 CUDA 版本不匹配上。
排查思路很清晰：先用nvidia-smi看驱动版本对应的最高 CUDA 版本，再用nvcc --version看当前安装的 CUDA 版本，确保二者兼容。另外一个极其隐蔽的坑是 PyTorch 自带的 CUDA 运行时版本和系统全局版本不一致。当你使用虚拟环境（conda 或 venv）时，PyTorch 会优先加载自己的 CUDA 依赖，这就可能和系统环境混着用，导致一些奇怪的报错。我最终的解决方案是直接用官方预编译的 PyTorch 版本，不做多版本交叉尝试，省下一晚上的排查时间。
5.3 系统重启后服务无法自启
这个问题常在部署完成后第二周暴露出来。当时一切配置好了，你以为万事大吉，结果机房一次断电重启，推理服务再也起不来了。排查一看，原来是某个依赖服务没有设置开机自启，或者环境变量在非交互式 shell 里没有被加载。
解决这个问题的思路是建立一个可重复的服务启动脚本。我的做法是把环境变量、GPU 状态检查、服务拉起动作固化到一个 systemd 服务单元里，设置成开机自启动，并在启动前自动检查 GPU 状态是否就绪。这样即使机器重启，服务也会自动恢复，不再需要人工介入。另外，每次更新驱动或者修改 CUDA 版本后，记得重新检查一遍这个启动脚本是否还能正常工作。
5.4 模型下载中断与校验
模型权重文件动辄几个 GB，甚至几十个 GB，下载过程中的网络波动是一个很现实的问题。分享一段经历：有一次我下载一个 13B 模型，连到一半断了，重新下载又得从头开始，白白浪费将近两个小时。后来我学乖了，先用支持断点续传的下载工具进行拉取，下载完成后立刻用 SHA256 或官方提供的校验值验证文件完整性，避免拿到一个损坏的权重文件，让后续排查陷入“看起来全对但跑起来就错”的泥潭。
遇到下载速度不理想的情况，优先考虑从国内可直连的 CDN 镜像或者学术资源加速站点入手，选择最靠谱的单一通道，一条路拉到底。不要开太多并行下载任务，反而容易互相抢占带宽，最后每个文件都下不完。
6. 实战扩展:从单机到小型集群
openrig 这套思路不仅能用于单机部署，顺着同样的架构逻辑，也能平滑演进出一个小规模推理集群。我在后期就把这套方案应用到了多机场景中，配合容器编排工具，让多台机器协同对外提供推理服务。这里简单分享一些扩展路径。
单机阶段，openrig 解决的是“可用性”问题；多机阶段，核心诉求变成了“扩展性”和“高可用”。此时，需要引入中间层来统一管理多台机器的 GPU 资源和推理任务调度。我尝试过两种思路：一是把每台机器作为独立的推理节点，前方负载均衡按权重分发请求；二是用集群调度框架把多机 GPU 抽象成一个资源池，按需分配给不同模型服务。两种方案各有适用场景，前者简单可靠，后者资源利用率更高，但对基础设施的要求也更高。
存储规划在多机场景下会更讲究。模型权重文件如果各自存放在每台机器上，会造成大量重复存储和同步负担。我在实践中的做法是集中在一个节点管理权重文件，通过高速局域网共享给各个推理节点。同时，日志和监控数据集中收集，统一到一个可视化面板上查看。这套架构虽然比单机复杂，但跑起来的稳定性和可运维性明显上了一个台阶。
不过多机扩展的前提是单机的模型方案已经稳定跑通。很多人一上来就想搭大集群，结果连单机的显存和驱动都没调明白，最后问题堆在一起，反而无从下手。从单点突破再向外延伸，是更稳健的路线。
7. 实操心得与后续优化建议
最后这部分，说一些不常写进文档、但我实际用下来觉得很有价值的心得。
第一点是关于配置记录的。我强烈建议你从第一次装机开始就维护一份配置清单，记录硬件型号、驱动版本、CUDA 版本、推理框架版本、关键参数设置。这听起来有点像“文档强迫症”，但当你一个月后回来调试旧项目，或者需要复现一套环境时，这份清单能让你少走大量弯路。我自己就吃过没记录配置的亏，换了一块硬盘重装系统后，花了将近两天时间才想起当时的 CUDA 版本组合，那滋味真的不好受。
第二点是关于稳定优先的哲学。openrig 整体思路是开放灵活的，但在实际执行时，我总倾向于把“稳定”放在“激进”前面。比如驱动版本选择，如果新驱动没有给你带来明确的新特性需求，老老实实留在验证过的版本上；内存频率不追求满载超频，留一点余地给长期运行的稳定性。这个思路和产品哲学同频：能长期稳定跑完的任务，比偶尔冲高跑分更有价值。
再补充一个优化方向：模型层可以做轻量化。如果你发现某类任务的响应速度始终跟不上，不妨先检查是不是模型本身太大。换一个更小的蒸馏模型或者更激进的量化等级，如果业务指标下降幅度在可接受范围内，那整体体验会有一个明显提升。别上来就觉得模型越大越聪明，实际场景里，响应速度和可控性往往比绝对智能更值钱。
openrig 这套东西，本质上是一套“自己动手、丰衣足食”的本地 AI 落地范式。它不神秘，也没有捷径，核心逻辑就是先把硬件骨架搭对、把软件环境调稳、把监控路径跑通，之后的一切优化都是在这个基础上顺水推舟。如果你也想搭自己的本地推理平台，不妨就从一份开源方案开始，一步步把每一层细节验透。
)
