2026 Frigate 视频结构化服务器租用选型干货：检测帧率与录像码流怎么算存储 + Coral 与核显避坑全解

2026 Frigate 视频结构化服务器租用选型干货：检测帧率与录像码流怎么算存储 + Coral 与核显避坑全解

这一篇是写给正在为一台 Frigate 机器填配置单的人看的。我们最近接触到的这类需求基本集中在三类：连锁门店要把每个门店 8 到 16 路摄像机集中留存，用于内部稽核和外部检查；工厂要把车间通道、仓库月台、危化品暂存区的画面结构化，出了货损能快速反查；园区周界要在夜间、雨雪天气下把翻越、滞留、车辆徘徊这几类事件筛出来。三类的共同点是摄像机数量一多，原本在小主机上"能装就是能用"的选型逻辑立刻失效——机器不是写不动录像，而是录像还在写、检测已经开始丢帧，等你发现的时候，留存窗口里缺的恰好是最该留下来的那一段。

失败的方式往往非常一致。采购人按"录像服务"的思路下单：看重盘位数量、看重总容量，CPU 挑个中等型号，内存给 8GB，心想视频嘛，不就是往硬盘里写文件。交付上线第一天一切正常，第三天夜里开始告警——检测延迟从几十毫秒涨到几百毫秒，事件队列堆积，取流进程反复重连摄像机，主码流的写入还在继续，磁盘因此更忙，整个系统进入"越慢越忙、越忙越慢"的循环。问题不在盘不够大，而在把两条互相独立的资源线当成了一条：AI 检测消耗的是 CPU/TPU 的推理能力，录像消耗的是顺序写带宽与容量。这两条线必须分开算，然后取交集，才是这台机器的真实配置。

所以本文的方法不谈玄学，全部落在可验算的数字上：容量用"总码率 × 10.8 × 保留天数"这个公式反推盘子大小；算力用 Coral 的单次推理耗时、设计吞吐与社区实测口径来划边界；网络与 IO 按多路并发持续写的特征来预留。最后给出 4 路、8 路、16 路三档可以直接照抄的配置清单，以及一份上线前必须跑完的验收动作表。如果你的场景正好落在这三档里，往下读照着配基本不会出错；如果你的场景更复杂，这套算法本身也是通用的。

检测跑子码流、录像走主码流：这是两条互不干涉的资源账

先交代清楚 Frigate 是什么，避免后面的讨论跑偏。它是一个开源 NVR（网络视频录像机），主打在本地做实时 AI 对象检测，可以识别人、车、动物、包裹这些类别；与 Home Assistant 原生集成，支持把摄像机的 RTSP 流 restreaming 出去供其他客户端复用，也支持用区域、遮挡区和对象过滤来限定"哪里动了才算数"。核心功能是免费的，Frigate+ 只是可选的付费模型改进服务——也就是说，你可以完全不依赖任何外部云服务，把整套能力跑在自己租用的机器上，这正是它被大量自建场景选中的原因。

它最关键的设计只有一个，但决定了后面所有选型：检测默认跑在低分辨率子码流上，常见的是 320×320 或 480×480 的裁剪窗口，录像则走主码流。这意味着"看得清"和"算得动"完全是两回事——录像留证必须要清晰的主码流，但参与 AI 推理的画面只需要够用即可。由此推出第一条结论：真正消耗 CPU/TPU 的从来不是录像画质，而是"路数 × detect FPS × 帧尺寸"这个乘积，三者任意一个加倍，推理开销就近似线性加倍。现实中最常见的错误是反复纠结主码流给 4Mbps 还是 8Mbps，却把 detect FPS 随手设到 15，方向从一开始就错了。

由此还能推出第二条更实用的结论：增加摄像机数量，不等于等比增加算力需求，关键看它是否参与实时检测。一个 16 路的系统里如果有 10 路只录像不检测，它的推理压力和一台 6 路全量检测的机器差不多，但存储压力和 16 路完全一样重。因此在配机器之前，要先把"每一路是否开检测、detect FPS 设多少、是否被区域或遮挡过滤掉"这三件事定下来，算力线和容量线才能各自算准。这里还要把常驻容器的开销一起计入：同时跑 go2rtc、Home Assistant 这些组件时，内存按 4 路 8GB、8 路 16GB、16 路 32GB 来留余量是比较稳的做法。内存通常不是第一个瓶颈，但不该把持续多路录像跑在只有 2–4GB 的机器上——光是流缓冲与容器本身就会让它提前成为瓶颈。

用「总码率 × 10.8 × 保留天数」反推机器：4 路、8 路、16 路逐档演算

公式先摆出来：GB = 总码率(Mbps) × 10.8 × 保留天数。换算关系很直白，1Mbps 的码率持续写一天大约是 10.8GB。这个公式的价值在于可逆——通常不是先有机型再去算能存多久，而是先被"留存 14 天"或"留存 30 天"这个要求卡住，再往回推需要多大可用容量、需要几块盘、机器该用什么盘位形态。把这一步做在前面，比先定机型再去凑容量要省心得多。

为了让三档演算可比，统一声明前提假设：每路摄像机主码流 1080p、码率 4Mbps，子码流 0.5Mbps 只用于检测、不计入录像体积。真实环境里码率受帧率、画面复杂度、编码器、夜间黑白画面等因素影响浮动很大，实际请按现场摄像机的实测码率代入，不要直接照抄这个假设值。另外提醒一句，公式里的"总码率"只统计真正落盘的流；如果另外开了高码流的抓拍或取证流，也要一并计入。

先看 4 路的小门店与仓库：总码率 4 × 4 = 16Mbps，一天就是 16 × 10.8 = 172.8GB，14 天约为 172.8 × 14 ≈ 2419GB，也就是约 2.4TB；如果内部稽核习惯保留 30 天，则是 172.8 × 30 ≈ 5184GB，约 5.2TB。这里算出的是录像数据的理论字节数，落到实盘还要叠加文件系统元数据与冗余开销，RAID1 直接翻倍，RAID5、RAID6 按冗余级别摊销，具体余量视 RAID 级别与文件系统而定。采购时通常要在这两个数之上再留一层，别按刚好够用的容量下单——视频这种东西从来只增不减。

再看 8 路，这是连锁门店单店最常见的规模：总码率 8 × 4 = 32Mbps，一天 32 × 10.8 = 345.6GB，14 天就是 345.6 × 14 ≈ 4838GB。这也是核验材料里那道标准算式：8 路 × 4Mbps × 10.8 × 14 天 ≈ 4838GB。换句话说，一个门店想留 14 天连续录像，光录像数据就要接近 5TB，加上系统、数据库缓存和冗余开销，实际要准备 8TB 级的可用空间才算踏实。同一档还要同步核对网络：8 路 1080p 主码流 4Mbps 加 8 路子码流 0.5Mbps，约 36Mbps 入向，建议预留 50Mbps；子码流虽然不占容量，但会吃掉一部分入向带宽。

最后是 16 路的多栋园区加周界：总码率 16 × 4 = 64Mbps，一天 64 × 10.8 = 691.2GB，14 天约 9677GB，接近 10TB；若留存期按 30 天算，则是 691.2 × 30 ≈ 20736GB，超过 20TB。到了这个量级，选型已经不是"买块更大硬盘"能解决的事，它反过来决定了机器形态：要有足够盘位、录像最好放独立卷、要不要留热备盘、以及录像盘能不能单独扩容。也正是在这一步，大多数人第一次意识到容量是完全可以提前算准的——算完再挑机型，比挑完机型再来祈祷容量够用，是两种完全不同的交付质量。

Coral、核显、独显三条推理路线的取舍边界：4–8 路别急着买 GPU

算力这条线的选型，本质上是在 Google Coral、Intel QuickSync（核显）和 NVIDIA 独显三条路线里做取舍。先给硬数据：Coral TPU 的单次推理约 8–12 毫秒，功耗约 2W，设计约 100 次推理/秒（与兼容模型相关）；在 detect FPS 设为 5 时理论上限约 20 路摄像机，但实务上的安全范围是 8–16 路，还要看帧尺寸、模型、USB 延迟与瞬时峰值。这两句话必须一起读——理论 20 路不代表你真能压着 20 路跑，多路同时出现对象时的瞬时叠帧会把推理队列顶满，表现出来就是延迟飙升、事件落库滞后，而这段滞后恰好是最难排查的问题。

接口形态的选择被严重低估。4–8 路用 USB 版 Coral 确实方便，即插即用、换机容易；但到了 8–16 路，建议换成 M.2/PCIe 版，理由不是它算得更快，而是它更稳：接口不会误脱、不与存储抢总线、也不受机箱前置 USB 线材和供电质量的影响。我们在实际交付里见过太多次"半夜掉加速器"的故障，最后都能追到 USB 供电不足或接触不良上；而对录像这种全天候场景来说，掉一次加速器就意味着这一整段的检测结果是空的，事后完全补不回来。

没有 TPU、纯靠 CPU 会是什么样？社区实测有一组可参考的口径，测试机是树莓派 4 8GB：无 TPU 时跑 1–2 路 320×320、5fps，CPU 占用约 60–75%，检测延迟 150–250 毫秒，加到第 3 路就开始撞温控降频；同一台机器插上 Coral 之后，4 路 320×320、10fps 约 55% CPU，延迟降到 10–20 毫秒。两组数字放在一起看结论很清楚：CPU 当然能跑，但那是"能跑起来"而不是"能跑多路"。把 CPU 当成长期主力推理单元，代价是延迟和电费同步上涨，还会挤掉录像写入与 RTSP 转推本来就不多的余量。

Intel QuickSync（VAAPI / OpenVINO）扮演的是另一个角色。它能把视频解码从 CPU 上卸下来，比纯 CPU 快 2–5 倍，但仍然慢于 Coral。所以正确的用法是分工而不是二选一：解码交给核显，推理交给 Coral，CPU 只做调度、录像封装与转推。一台带核显的机器即使暂时不插加速器，也会比纯拼核数的机器舒服很多，这也是我们建议"宁可选带核显的 CPU，也不要只用堆核数来补"的原因——多路视频的第一笔开销是把码流解开，而不是把对象认出来。

那什么时候才轮到 NVIDIA GPU + TensorRT？边界其实很清楚：超过 16 路、detect FPS 高于 5–10、模型较重，或者同一台机器上还跑着别的 AI 负载，比如人脸特征重排序、车牌 OCR 二次校验、客流统计。这几种情况下，一张支持 TensorRT 的卡能把负载一次性收拢，综合下来反而划算。反过来，仅为 4–8 路单独买一张独立 GPU 通常不划算：卡本身、供电、散热、驱动维护和长期电费叠加起来，收益远不如一块 Coral 加核显解码的组合。至于"拿闲置游戏卡顺便跑 NVR"的想法也要慎重，桌面卡的驱动生命周期与 7×24 持续写入场景对稳定性的要求，根本不是一回事。

4 路 / 8 路 / 16 路三档配置清单：路数、推理、内存、存储与网络一次对齐

下面这张表是把前面三章的结论收拢成可以直接执行的一页纸。它的读法是从左往右：先确定你的路数与画质档，然后推理方案、CPU 核数、内存、存储分层、网络口径这五项就有了确定的取法，不需要再回到前文的推导里翻。需要说明两点：一是 CPU 核数是按"同机还会跑 go2rtc、Home Assistant 等常驻容器"给出的起步建议，实际请以压力测试校准；二是所有码率都沿用前面 1080p / 4Mbps 主码流、0.5Mbps 子码流的假设，现场码率不同请按同一方法重算。

这张表里最容易被跳过的一列是最后两列的组合关系：很多项目的网络不是带宽不够，而是上行抖动。你可以在验收时把 8 路或 16 路同时拉出来做实时预览，同时后台跑一次历史片段导出，再叠加一次 RTSP 转推到第三方平台，看检测延迟会不会出现明显的台阶；如果会，说明这台机器这里的瓶颈在网络与解码，而不是盘。至于最后一行的"纯录像"配置，它是给另外一类人准备的：只想把证据留下来、后续靠人工看成片的场景，这种机器压力几乎全在 IO 和容量上，完全可以省掉加速器的钱。

随机写 vs 顺序写：录像盘的 IO 模型为什么和数据库完全不是一回事

很多人给 NVR 配存储时，脑子里默认的参照物是数据库：既然数据库要高性能固态，那录像也放固态肯定更快。方向听起来没毛病，钱大概率白花了。数据库的写是大量小块随机写加频繁的同步落盘，追求的是随机写能力与写延迟的一致性；而 NVR 的写是多路并发、长时间、几乎纯追加的顺序写，落盘粒度是一段一段的视频分片。两者对介质的要求是两套完全不同的指标：一个盯"随机会不会抖"，一个盯"顺序能不能一直不断流"。只要把"录像是长期持续写"这一个特征想清楚，选型就不会跑偏。

顺序写带来的第一个推论是：消费级固态做长期录像卷并不划算。它在接近写满时主控要做垃圾回收，写延迟会出现明显抖动，而抖动对多路录像来说是最坏的消息——某一个瞬间写不下去，环形缓冲区就开始堆积，堆到一定程度只能丢帧，丢帧在回看画面里就是一段花屏或者干脆缺失。固态在这台机器上的正确位置是系统与数据库缓存，量级在 60–100GB 就够用。真正该放录像的是独立的机械硬盘：西部数据 Purple、希捷 SkyHawk 这类 surveillance 级 CMF 盘，它们的固件针对长时间持续流写入做过优化，遇到坏扇区不会陷入长时间的深度重试，从而避免整块盘被 RAID 控制器判掉。

第二个推论关于阵列与文件系统。别把手上有的盘随便组起来就用，也别比"哪种阵列更快"——这里没有快的诉求，只有"写入不能抖、重建要扛得住"的诉求。带校验位的阵列级别在写入时要额外做读改写，写惩罚实实在在存在；更麻烦的是重建：一块盘失效后，阵列要连续读满剩余盘去计算数据，而此时多路录像还在持续写入，重建窗口会被拉长，窗口越长第二块盘出问题的概率越高。镜像方案牺牲容量换来重建过程简单、对写入影响小，反而更适合"写一整年不删"的录像场景；如果容量确实吃紧必须上带校验的方案，请务必核算重建时间与二次失效的风险，必要时向容量服软。

文件系统这一层的选择原则也差不多：优先选在大量文件频繁创建与删除的场景下元数据处理稳定、空间回收时不容易把写入卡住的类型，并结合阵列策略、块大小与挂载参数一起压测，具体选哪一种、某些挂载选项能不能开，一律以实测为准。这里还有一条比选型更重要的纪律：录像必须单独成卷，不要和系统盘或数据库共用一个文件系统。理由很现实，视频写满时会把分区占满，一旦和数据库共享分区，数据库会因为无法写入跟着一起崩，故障从"录像暂停"升级成"NVR 整体不可用"，排查时间成倍增加。

最后补一句容易被忽略的：录像盘的考核指标是"不掉速、不掉盘"，不是随机读写跑分。验收时别只看分数，要看压力状态下的行为——把全部路数同时拉起实时预览、后台导出一段历史片段、再叠加 RTSP 转推给第三方平台，观察写入曲线是否平稳、有没有出现台阶。一个跑分很高却在半夜抖动十分钟的方案，在 NVR 这种场景里一文不值；反之，顺序写稳定、掉盘后重建可控的方案，才会让你在一个月后忘记它的存在。

事件模式到底能省多少：雨、雪、树影、车灯、繁忙街道会让它失效

事件模式指的是只在检测到对象时才录像，理论上能把容量需求降到连续录像的 1/3 到 1/10。这个省法很吸引人，尤其在路数多、留存天数长的场景里，看起来可以少买一半的盘。但它有一个必须说清楚的前提：这个比例成立的条件是"画面大部分时间静止"。现实中的画面往往不满足这个条件，所以它只能当作上限参考，不能当作采购依据。

把它打回连续录像水平的因素主要来自四类场景。第一类是天气：下雨和下雪会让画面的像素持续变化，运动与对象检测被反复触发，一场雨可能意味着一整天都在"录事件"，雨夜叠加灯光反光时尤其严重。第二类是植被：园区绿化带的树影、灌木在风里晃动，白天日光角度变化时更明显，这是周界摄像机最常见的无效触发源。第三类是光：夜间车灯扫过墙面、对面商铺的霓虹招牌、走廊感应灯的亮灭，都会制造大面积突变。第四类是人流车流本身：临街门店的人行道、地下车库出入口、工厂交接班时的通道，这些位置"有对象"本来就是常态，事件模式与连续录像的差别微乎其微。

所以正确的做法是两句话：先按连续录像配盘，把事件模式省下来的部分当作缓冲，而不是当作可以砍掉一半硬盘的理由。如果一定要在经济账上做文章，建议按这个顺序操作：上线先跑连续录像，稳定两周后从系统里取出真实的事件占比数据，再判断能不能把容量缩一档、或者反过来把留存天数提一档。全程以实测为准，不要凭想象拍板——很多业主估算自家门店"一天也没几个人经过"，回看数据是另一回事。

还有一条正面建议：与其指望事件模式省容量，不如先把触发质量做扎实。用好区域、遮挡区和对象过滤，把明显不该触发的地方排除掉——不必要的区域直接屏蔽、把晃动的树冠画进遮挡区、把不关心的类别从对象列表里剔除。这一步不会减少多少算力开销，但能显著降低无效片段和误报，既减少了回看时的噪声，也让事件列表真的能用。事件模式的价值应该体现在"找得更快"，而不是"存得更少"。

摄像机到机房这一段怎么走：上行、抖动与不要把 RTSP 直接放出去

如果把 NVR 放在租用的服务器上而不是站点本地，摄像机到机房这一段链路就成了系统的一部分，它的质量直接决定检测延迟的上限。带宽先算清楚：沿用前面的口径，8 路 1080p 主码流 4Mbps 加 8 路 0.5Mbps 子码流，入向约 36Mbps，建议预留 50Mbps。注意这是链路的可用余量，要把实时预览、导出、转推同时进行的情况一并算进去；百兆端口理论上能扛 16 路中等码流，但一旦叠加回看与导出就很勉强，所以只要路数上去，直接选千兆更稳。

比带宽更要命的是时延抖动。RTSP 是长连接流媒体协议，对丢包和抖动的容忍度远低于网页浏览这类突发流量；一次明显的抖动表现出来就是客户端花屏、摄像机断流后重连、时间戳错乱导致检测丢帧。更隐蔽的是这类抖动往往出现在晚高峰，也就是画面最关键的时间段。因此这一段的验收不能只测带宽，一定要测稳定性：在业务高峰时段连续观察丢包与抖动情况，具体的合格阈值按业务对回看与实时性的要求自行确定，但"测了"和"没测"是两回事。

流量怎么走，这里给出明确取舍：不要为了省事把 RTSP 端口直接开到公网。正确做法是摄像机侧与管理侧分开：摄像机到 NVR 走加密隧道或组网隧道（站点到机房的 VPN 隧道、SD-WAN 组网等实现方式都可以），管理入口只从 VPN 进入，公网侧不开放任何直连的视频端口。多站点集中留存时还要单独确认每一条上行链路的性质：是否经过 NAT、是否为共享出口、上下行是否对称、是否提供固定地址——这些都属于需要向链路提供方核实的信息，不要靠假设。

架构上有两种选择：其一是边缘落地加异地复制，每个站点放一台小型机器做本地录像与检测，只把事件片段和告警摘要回传中心，好处是对上行依赖小、单站点断网也不影响本地留存，代价是要管多套设备；其二是集中式，所有摄像机直接把流推到中心机房的 NVR，好处是审计与留存口径统一、运维集中，代价是上行质量成为全局命门。门店数量多、留存要求统一的连锁场景，我们更推荐前者；单园区、单厂房且内部链路可控的场景，后者更省力。这个决定越早做，后面的机型和带宽选型就越准。

摄像机侧的隔离、VLAN 与管理通道：最小暴露面怎么划

视频系统一旦暴露，最危险的往往不是录像被看，而是摄像机本身被接管。这里的原则既简单也硬：RTSP（554/8554）与 NVR 网页界面不要直接暴露在公网。摄像机要放进独立的 VLAN，明确禁止摄像机访问互联网，每一台都改成强密码并关掉用不上的管理端口与云联功能，机房侧用防火墙把可访问来源收敛到白名单，管理员远程维护一律走 VPN。这几条看起来是常识，但绝大多数出过事的部署都是倒在其中某一条上。

网络分区建议至少划三块：摄像机区（只允许向 NVR 的取流端口建立连接，禁止主动外联、禁止互访）、NVR 服务区（允许读取摄像机、允许被内部客户端回看，但不向公网开放任何端口）、管理区（仅通过 VPN 接入，负责配置、升级与导出）。三块之间的访问控制要写进交付文档，而不是只留在一个人的脑子里——半年后接手的人看不到当时是怎么想的。导出这块还要额外留痕：谁、在什么时间、导出了哪一路哪一段，都应该有日志记录，这是后面合规部分能站得住脚的前提。

合规与留存：留存期限、访问审计、导出留痕按什么原则设计

视频留存的合规要求在不同行业、不同地区差别很大，我们不会也不应该在这里给出一个"通用天数"。正确的做法是三件事：第一，向企业的法务或合规负责人确认本企业适用的留存期限要求，把结论写成书面依据；第二，确认这些要求以当地现行法规为准，因为这类要求会变化；第三，把"谁能查、查什么、查完要不要记录"在系统层面落实，而不是靠口头约定。任何具体条款编号请从当地现行规定中自行核对，本文不做引用。

系统层面至少要落实四件事。一是留存期限可验证：机器要能证明"过去 N 天的画面确实完整"，这就回到前面那张配置表——容量按连续录像算足，是最省事的证明方式。二是访问权限分级：店长看本店、区域经理看多店、法务只读不能删，导出能力集中到少数账号。三是操作审计：登录、回看、导出、配置变更都要落日志，且日志本身不要放在录像卷上，避免被写满牵连。四是导出留痕：导出的片段带时间与设备信息，导出记录含操作人与时间范围，并且 NVR 与摄像机的时间源保持一致、统一校时。

还有一个现实问题值得单独提：不要指望靠事后补录来救火。最常见的合规事故不是天数不够，而是留存窗口里存在空洞——机器半夜掉过一次加速器、重启过一次、盘写满过一段时间，留下的片段断断续续。所以验收动作里一定要包含"连续留存验证"：随机抽取过去若干天里任意一天的任意一路，检查能不能连续回放到每一分钟，重点盯夜间、雨雪天和交接班高峰这三个时段。能不能满足合规，看的是这件事，而不是配置单上写了多少 TB。

一万网络在多路视频这个场景上的两个推荐摆位

如果只给两个最直接的推荐，我们的立场是这样。第一个：在 4–8 路的门店与小型场景，把钱花在"带核显的 CPU + 一块 M.2/PCIe 版 Coral + 一块真正靠谱的 surveillance 级录像盘"上，而不是去堆更多 CPU 核心，或者急着买一张独立显卡。核显负责把多路码流解开，Coral 负责把对象认出来，录像盘负责一天到晚不停写，三件事各司其职；这套组合的稳定性已经被大量自建场景验证过，比"先上大机器再说"省钱也省心。

第二个：在 16 路及以上、或者单站点之外还要做多站点集中的场景，先别急着换更大的单机，把网络和部署架构想清楚——是继续集中到一个机房，还是改成边缘落地加异地复制。这个决定对最终体验的影响，往往比多加两根内存条大得多。做这类交付时，我们的判断一直是"先算账、再选机型"：把路数、detect FPS、保留天数、上行链路这四项问清楚，容量用公式推、算力用边界卡，剩下的才是报价问题。这也是我们一贯的做法：一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

Frigate 视频结构化上线前的服务器验收清单

第一项，容量验证：按"总码率 × 10.8 × 保留天数"复算一遍，核对实盘可用容量是否包含文件系统与冗余开销，并确认录像卷与系统卷是分开的。第二项，推理边界验证：把 detect FPS 与帧尺寸设成生产值，让所有开了检测的路同时出画面（可以用同一段素材循环播放模拟），观察检测延迟是否还在可接受区间、有没有因瞬时叠帧把队列顶满。第三项，网络验证：8 路场景按入向约 36Mbps、预留 50Mbps 的标准核对；要不要上千兆，看的是实时预览、导出、转推同时进行时的表现。

第四项，IO 稳定性验证：连续跑 24 到 72 小时，观察写入是否平稳、有没有周期性台阶，随机抽取历史片段做回播放通率测试。第五项，留存完整性验证：随机抽取过去若干天的任意一路，逐分钟检查有无空洞，重点盯夜间、雨雪与交接班高峰。第六项，事件质量验证：检查区域、遮挡与对象过滤是否配置到位，有没有被树影、车灯、人流长期误触发的区域。第七项，内存与容器：确认在跑 go2rtc、Home Assistant 等常驻组件的前提下，4 路 8GB、8 路 16GB、16 路 32GB 的余量是否被满足，交换空间是否被常态化使用。

第八项，暴露面确认：RTSP（554/8554）与网页界面不得直连公网，摄像机位于独立 VLAN 且不能主动访问互联网，密码强度符合要求，管理入口只能从 VPN 进入，并留好访问控制说明文档。第九项，故障演练：拔掉一块录像盘看阵列与应用是否按预期降级而不崩溃；重启一次加速器确认能否被正确识别并自动恢复；断一次摄像机网络看恢复后能否自动重连。第十项，文档化：把路数、码率、detect FPS、保留天数、留存策略、账号权限与导出留痕写进交付文档，方便半年后接手的人照着复核。

一万网络能给多路视频这种持续写入场景接什么：下单前要确认的清单

下单之前，建议把下面这些一次性问清楚，能省掉后面绝大部分反复沟通。机型与介质层面：CPU 是否带核显（决定能否用 VAAPI / OpenVINO 卸掉解码），可用的 PCIe 或 M.2 插槽与 USB 口数量（决定 Coral 用什么形态、会不会与存储抢总线），盘位数与是否支持独立录像卷，能否做 RAID1 或 RAID10 并留热备盘，系统盘是否为 60–100GB 量级的独立固态。加速器层面：是自带 Coral 还是自行加装，M.2/PCIe 版还是 USB 版，超过 16 路或帧率较高时是否需要评估 NVIDIA GPU 加 TensorRT，模型兼容性需自行核对。

网络与合规层面：入向带宽按多少预留（8 路约 36Mbps、建议 50Mbps，16 路以上建议直接千兆），摄像机到机房这一段走什么隧道方式，是否提供固定地址，上下行是否对称，有没有可用的组网方案；机房侧能否配合做 VLAN 划分与白名单策略，重装系统与维护窗口怎么安排，这些都要与业务方逐条核实。运营层面：是否允许自主重装系统与安排维护窗口，是否提供 IPMI 或类似的带外管理，故障时的响应与处理流程是什么，以及这种持续写入负载在所选机型上是否存在限制或建议年限。

最后回一句：一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。多路视频这件事，难点从来不在"买一台更大的机器"，而在于把算力账和容量账分开算、把摄像机到机房这一段链路管好；这两件做对了，剩下的选型就是一张可以照抄的表格。