企业官网建设流程全解析

摘要：准备本地部署大模型时：到底加一张显卡，还是直接上 Jetson Orin？这两条路都能“在本地跑模型”，但解决的问题不同。本文把本机私有化助手与端侧现场闭环拆开，给出可执行的判断表、检查清单和验证脚本。适合已经看过本机本地部署，也在考虑边缘板卡的人。显卡型号、Orin 规格与 JetPack 版本以 NVIDIA / 各发行版官方文档为准。

承接前文：

• 本地部署大模型的详细考虑（含脚本/代码）
• 本地部署大模型前，要不要加显卡
• Orin 上跑本地大模型，适合什么场景
• Orin端侧检测+小模型解释闭环

建议单独建一个选型实验目录，避免和现有local-llm-lab/orin-edge-app搅在一起：

mkdir-p~/hw-choice-lab/{notes,scripts,logs}cd~/hw-choice-lab

1. 问题

常见纠结是这样的：

1. 想本地跑模型，不想把数据送公有云
2. 看到别人显卡跑得很快，又看到 Orin 能做边缘 AI
3. 预算只够买一边，于是开始比 TOPS、显存、功耗

问题在于：这不是同一条购物清单上的两个 SKU。

图1. 先分清是桌面私有化，还是现场端侧，再谈具体型号。

把它们硬比成“谁更划算”，通常会得到错误答案：Orin 不会因为功耗低就成为更好的编码机；消费级显卡也不会因为吞吐高就成为更好的产线旁盒子。

2. 先说结论

再压成四条：

1. 显卡放大的是本机本地部署；Orin 服务的是现场端侧约束。
2. 没有弱网/不出域/传感器同机这些约束时，别为了“本地大模型”买 Orin。
3. 没有稳定使用记录和明确瓶颈时，别为了“更快”先买旗舰卡。
4. 同一验收任务先在 PC 上跑通，再决定迁移到 Orin，还是加卡扩本机。

图2. 现场约束、任务形态、主链路归属，比参数表更先决定方向。

3. 能力对比

图3. 能力重叠在“能跑模型”，差异在约束、形态和维护成本。

3.1 加显卡

更适合：

• 长上下文、较大模型、多轮编码助手
• 本机知识库、离线文档处理、个人/小团队私有化
• 你已经确认慢在显存或吞吐，而不是磁盘/内存/提示词

不太适合：

• 7×24 挂在产线旁、要过工业现场认证与功耗墙
• 必须和多路相机、GPIO、现场总线紧耦合，却还想当普通台式机用

相关判断见：本地部署大模型前，要不要加显卡。

3.2 Orin

更适合：

• 弱网/离线、数据不出域
• 检测/感知主链路已经在板上，语言层做短解释、摘要、模板填充
• 体积、功耗、常驻比峰值吞吐更重要

不太适合：

• 替代旗舰显卡本机当主力开发机
• 还没跑稳相机/检测，就先追端侧大模型演示

相关判断见：Orin 上跑本地大模型，适合什么场景。

3.3 对照表

价格、具体显存、Orin 档位（Nano / NX / AGX）会随市场与版本变化，本文不锁死数字；选型时以官方规格页和你实测的内存余量为准。

4. 路线清单

保存为notes/route_checklist.md：

# 显卡 vs Orin 路线检查 ## A. 现场约束 - [ ] 弱网或必须离线可用 - [ ] 原始数据不能出厂/出域 - [ ] 必须和相机、传感器、报警同机或同柜 - [ ] 需要设备旁常驻，而不是偶尔在办公室跑 ## B. 本机私有化 - [ ] 编码/文档/知识库要高频本机完成 - [ ] 现有机器已跑通小模型，且真实任务有记录 - [ ] 已排除磁盘满、内存不够、驱动未就绪 - [ ] 能说清加卡后改善的是速度、上下文还是更大模型 ## C. 主链路 - [ ] 主价值在视觉/检测闭环 → Orin 优先，LLM 辅助 - [ ] 主价值在语言能力本身 → PC/云端优先 - [ ] 两边都要 → 开发 PC + 现场 Orin，分两套验收 ## D. 未定 - [ ] 验收任务还写不出来 → 先别下单 - [ ] 只是看到别人跑得爽 → 先复制他的任务，而不是他的硬件

读法很直接：

• A 多项成立、B 很少 → 偏 Orin
• B 多项成立、A 很少 → 偏加显卡或继续用现有 PC/云端
• A、B 都成立 → 两套硬件/两套验收，不要压成一个选择
• A、B 都不成立 → 硬件不是当前瓶颈

图4. 任务与约束写不清时，买任何一边都容易闲置。

5. 路线脚本

下面脚本不代替你思考，只是把清单变成可重复的输出。保存为scripts/choose_route.sh：

#!/usr/bin/env bashset-euopipefailask(){localprompt="$1"localanswhiletrue;doread-r-p"$prompt[y/n]: "anscase"$ans"iny|Y|yes|YES)return0;;n|N|no|NO)return1;;*)echo"请输入 y 或 n";;esacdone}edge=0pc=0echo"== 现场约束 =="ask"是否存在弱网/离线硬需求？"&&edge=$((edge+2))ask"原始数据是否不能出域？"&&edge=$((edge+2))ask"是否必须和相机/传感器同机处理？"&&edge=$((edge+2))ask"是否需要设备旁 7x24 常驻？"&&edge=$((edge+1))echo"== 本机私有化 =="ask"是否高频做本机编码/文档/知识库？"&&pc=$((pc+2))ask"现有机器是否已跑通小模型且有真实任务记录？"&&pc=$((pc+2))ask"是否已排除磁盘/内存/驱动这类基础问题？"&&pc=$((pc+1))ask"是否能说清加卡后具体改善哪一项？"&&pc=$((pc+1))echo"== 主链路 =="vision_main=0ask"主价值是否在检测/感知闭环，LLM 只是辅助？"&&vision_main=1echoecho"edge_score=$edgepc_score=$pcvision_main=$vision_main"if((edge==0&&pc==0));thenecho"建议: HOLD —— 先写验收任务，暂不买硬件"elif((vision_main==1&&edge>=3));thenecho"建议: ORIN_FIRST —— 先保证视觉主链路，再挂小模型解释层"elif((edge>=pc+2));thenecho"建议: ORIN —— 现场约束更硬，优先评估 Orin + 小模型"elif((pc>=edge+2));thenecho"建议: PC_GPU —— 本机私有化更硬，优先评估加显卡或优化现有 PC"elseecho"建议: SPLIT —— 开发用 PC，现场用 Orin；不要指望一块板兼顾"fi

用法：

chmod+x scripts/choose_route.sh ./scripts/choose_route.sh|teelogs/route_$(date+%F).txt

把输出标签写回notes/task_acceptance.md，后面测 PC 或 Orin 时都对着同一标签看，避免测着测着目标漂移。

6. 验收任务

硬件选型最怕两边测的不是同一件事。先把验收任务写成固定模板，保存为notes/task_acceptance.md：

# 验收任务（同一份，两边复用） ## 任务简述 - 例如：把一条缺陷检测 JSON 解释成三步处置建议 ## 输入 - 固定样例文件路径： - 是否允许模型自由发挥：否 / 有限 ## 输出验收 - [ ] 格式稳定（条数、字段、长度上限） - [ ] 内容可执行（值班人员看得懂） - [ ] 延迟可接受（写出你的上限，例如 3 秒 / 10 秒） ## PC 结果 - 模型： - 延迟： - 是否通过： ## Orin 结果 - 板型/功耗档： - 模型： - 延迟： - 是否与检测服务同机： - 是否通过：

6.1 PC 侧

最小路径：

1. 现有机器用 Ollama 或你已有方案跑通同任务
2. 连续几天真实使用，记录卡点
3. 用上一篇的瓶颈思路确认是不是显存/吞吐问题
4. 再决定加卡档位

PC 粗探（保存为scripts/pc_probe.sh）：

#!/usr/bin/env bashset-euopipefailecho"=== memory ==="free-hecho"=== disk ==="df-h/echo"=== gpu (if nvidia-smi exists) ==="ifcommand-vnvidia-smi>/dev/null2>&1;thennvidia-smi --query-gpu=name,memory.total,memory.used,utilization.gpu--format=csvelseecho"nvidia-smi not found"fi

6.2 Orin 侧

最小路径：

1. PC 上先把提示词和输出格式验过
2. Orin 上换同任务小模型，先求短答案可用
3. 若有检测服务，同机压测内存与功耗，而不是只测聊天窗口
4. 再谈常驻与并发

Orin 粗探（保存为scripts/orin_probe.sh）：

#!/usr/bin/env bashset-euopipefailecho"=== jetpack / l4t (best-effort) ==="if[[-f/etc/nv_tegra_release]];thencat/etc/nv_tegra_releasefiecho"=== memory ==="free-hecho"=== disk ==="df-h/echo"=== nvpmodel (if available) ==="ifcommand-vnvpmodel>/dev/null2>&1;thennvpmodel-q||truefiecho"=== tegrastats sample (5s) ==="ifcommand-vtegrastats>/dev/null2>&1;thentimeout5tegrastats||trueelseecho"tegrastats not found"fi

端侧应用怎么把检测接到解释层，可继续看：

• Orin端侧检测+小模型解释闭环
• 端侧 YOLO 检测结合大模型告警

7. 常见情况

图5. 多数人不是二选一，而是“现在先买哪边”或“要不要分两套”。

7.1 编码助手

选 PC。现有机器够用就先别买；不够再用显卡放大。Orin 在这里通常是成本更高、体验更差的开发机替代品。

7.2 告警解释

选 Orin。重点不是模型排名，而是：断网可用、和事件 JSON 对接、输出短且可执行。PC 只负责你开发提示词和回放样例。

7.3 开发 + 现场

分两套：

• 开发与评测：PC（可加卡）
• 现场推理：Orin

不要试图用一块 Orin 同时满足“舒服写代码”和“产线常驻”。

7.4 预算只够一边

按失败代价选：

经验做法：约束写在合同/项目里的，优先保现场（Orin）；个人效率投资，优先保本机（显卡）。项目属性不明时，先花时间写验收，不先花预算。

8. 决策表

9. 常见误区

9.1 把低功耗当成更适合本地部署

功耗优势服务的是现场部署，不自动等于更好的本机助手体验。

9.2 用跑分替代边缘选型

吞吐高解决不了安装方式、功耗墙、接口和常驻形态。

9.3 先比型号、后写验收

型号比较会把你锁进参数细节；先锁任务，再锁硬件族，最后才到具体 SKU。

9.4 Orin 上硬追大模型

端侧先求闭环，再求规模。相关坑见：本地大模型跑通了，为什么还是不好用。

9.5 把能跑通当成选型完成

两边都能跑通 hello world。选型完成的标志是：目标任务在目标环境里稳定通过验收。

10. 术语速查

11. 小结

想本地部署大模型时，加显卡和上 Jetson Orin 不是同级替代：

1. 先分清是本机私有化，还是现场端侧
2. 用约束清单和choose_route.sh打出路线标签
3. 同一验收任务先在便宜环境跑通
4. 再决定加卡、上 Orin，或拆成开发/现场两套

先让验收任务成立，硬件采购才接得上。否则参数表再漂亮，也只是把不确定从软件挪到了快递箱里。

12. 相关阅读

• 本地部署大模型的详细考虑（含脚本/代码）
• 本地部署大模型前，要不要加显卡
• 本地大模型跑通了，为什么还是不好用
• Orin 上跑本地大模型，适合什么场景
• Orin端侧检测+小模型解释闭环
• 端侧 YOLO 检测结合大模型告警
• Jetson 做边缘 AI，有价值的方向是什么
• NVIDIA Jetson Orin NX 简介
• Jetson Orin 和 Thor 怎么选

相关链接：

• Jetson Orin
• Ollama
• NVIDIA Jetson Linux

如果本篇对你有帮助，欢迎点赞、收藏，也欢迎关注后续更新。