关于 AI 基础设施的讨论，往往集中在算力上。
GPU。
电力。
冷却。
数据中心。
内存。
存储。
互连。
这些都很重要。
但还有一层基础设施得到的关注少得多：
互联网号码资源。
一家 AI 公司可以拥有 GPU、签订稳定的电力合同、部署大容量光纤，并建设复杂的模型服务基础设施。
但如果客户无法稳定访问这些基础设施，再多算力也没有意义。
面向公众的 AI 系统仍然依赖互联网基础设施。
模型 API 需要端点。
GPU 云需要客户连接。
数据中心需要可路由的网络。
企业 AI 平台需要稳定的集成。
安全系统可能依赖已知的网络身份。
多区域服务可能需要独立路由。
这些系统背后是 IPv4 和 IPv6 地址、自治系统号、路由策略、注册记录以及安全声明。
因此，AI 公司不应把 IP 地址当作事后才考虑的问题。
它们是基础设施栈的一部分。
而一旦号码资源深度嵌入实际运营， IP 地址治理就会成为业务连续性问题。
AI 基础设施也是互联网基础设施
AI 公司可能主要把自己视为软件公司或算力公司。
然而从运营角度看，许多 AI 企业正越来越像基础设施公司。
例如，一家 AI 平台可能运营：
- 公共模型 API
- GPU 云服务
- 企业推理基础设施
- 训练集群
- 面向客户的控制面板
- 私有网络
- 多区域数据中心
- 云网关
- 合作伙伴集成
这些系统最终都会与网络标识符发生联系。
从最基本的层面看，公共 IP 地址告诉互联网服务可以从哪里访问。
更深一层看，这些地址可能与以下内容关联：
- DNS
- 客户白名单
- 防火墙
- VPN
- API 安全
- 路由
- 地理定位
- 滥用管理系统
- 监控
- 信誉数据库
IP 地址最初可能只是容量。
随着时间推移，它可能成为身份。
对于快速扩展基础设施的 AI 公司而言，这一区别至关重要。
AI 公司首先应理解：IP 地址是经协调的资源
公共互联网号码资源并不是由各家公司自行挑选、彼此独立存在的数字。
它们处于一个全球协调框架之中。
由 互联网号码分配机构（IANA） 维护 IPv4、IPv6 和自治系统号的全球注册表，而号码资源则通过区域互联网注册管理机构体系进行管理。
这一架构的存在有一个重要的技术原因：
互联网标识符必须在全球保持唯一。
RFC 7020 描述了用于维护全球唯一 IP 地址空间和 AS 号的互联网号码注册系统。
对于 AI 公司而言，唯一性本身并无争议。
两个互不相关的生产网络不能同时对同一个全球路由前缀提出互不相容的排他性权利主张。
在唯一性确立之后，更重要的治理问题才真正开始：
协调层应在多大程度上干预一个已运行号码资源的商业与运营生命周期？
问题正是在这里变得更加复杂。
注册记录不等于正在运行的网络
AI 基础设施团队必须理解的一个重要区别，是以下两者之间的分离：
注册信息
以及
互联网的实际运行状态。
注册管理机构可以维护某个 IPv4 地址块的信息。
但数据库条目本身并不能传送数据包。
BGP 在网络之间传递路由信息。
路由器执行策略。
上游提供商传播路由通告。
RPKI 可以提供安全信息，说明哪个 ASN 获准宣告某个前缀。
应用和客户随后依赖由此形成的连接。
这正是我一直主张以下观点的原因：
注册记录描述现实，而不是创造现实。
注册管理机构应帮助确保记录账本准确。
它应维护唯一性。
它应记录合法变更。
它应支持安全与运营协调。
但数据库的存在，不应被混同为对围绕其中所记录资源建立起来的经济和运营现实拥有所有权。
这一点在 《唯一性协调权利法案》中有更深入的阐述。我在其中主张，共同的号码资源层应专注于唯一性、记录准确性、控制权证明、安全声明、可审计性和运营连续性。
对于围绕 IP 资源建设昂贵基础设施的 AI 公司而言，这一区别并非哲学问题。
而是风险管理问题。
IPv4 稀缺性改变了治理问题
IPv4 不同于普通的软件资源。
公司可以再建一个数据库。
它可以配置更多虚拟机。
如果供应允许，也可以制造或购买更多硬件。
但它无法再创造一个全球唯一的 IPv4 互联网。
IPv4 是有限的。
一旦稀缺性具有实际经济意义，号码资源就不再只是管理凭证。
它们会成为运营资产。
这与 AI 基础设施尤其相关。
假设一家 AI 云公司需要数千个公共 IPv4 地址，用于：
- 客户工作负载
- 公共网关
- API
- 管理基础设施
- 专用端点
- 安全设备
- 区域服务
其 IPv4 策略可能包括：
- 现有分配
- 购买的资源
- 转让
- 租赁
- 提供商分配的地址
- 自带 IP 安排
这些结构会带来不同的依赖关系。
因此，问题不只是：
“我们需要多少个 IP 地址？”
更好的问题是：
“在怎样的治理结构下，这些地址才能持续可用？”
AI 公司应区分容量与身份
这可能是最重要的基础设施区分。
并非每个 IP 地址对企业都具有相同价值。
有些地址可以随时替换。
临时开发工作负载从一个地址迁移到另一个地址，影响可能很小。
另一些地址则会随着时间推移被深度嵌入。
设想一家 AI API 提供商。
其企业客户把特定源地址加入白名单。
银行和受监管客户围绕这些地址配置安全控制。
合作伙伴会在文档中记录它们。
监控系统围绕它们积累多年的历史记录。
防火墙依赖它们。
内部合规系统引用它们。
此时，地址已不再只是容量。
它已经成为公司 网络身份的一部分。
我在 《谈 LARUS One——网络身份、客户连续性与提供商收入的经济学》中阐述了这一区别。核心观点很简单：重要地址的真正成本通常不是号码的价格，而是更换它的成本。
AI 公司应尽早识别哪些地址只是容量，哪些正在成为身份。
不应以同样的方式治理这两类地址。
问对问题：重新编号的成本是多少？
基础设施团队经常会问：
IPv4 要多少钱？
这是一个采购问题。
对于关键基础设施，另一个问题可能更重要：
替换这些地址需要多少成本？
设想一个拥有全球客户的成熟 AI 平台。
更换核心公共前缀可能需要更新：
- DNS 记录
- 防火墙策略
- 客户白名单
- 合作伙伴白名单
- API 安全设置
- VPN 配置
- BGP
- RPKI
- 监控
- 反向 DNS
- 地理定位记录
- 合规文档
有些变更可以自动完成。
另一些则需要客户或合作伙伴采取行动。
这就形成了外部依赖。
识别某个地址的外部系统越多，重新编号的成本就越高。
对于快速发展的 AI 公司，应在基础设施深度嵌入之前对此建模。
ASN 同样重要
IP 地址只是网络身份的一部分。
大型 AI 基础设施运营商还可能使用自治系统号。
当公司实施独立路由策略或连接多个提供商时，ASN 尤其重要。
一种简化架构可以是：
AI 基础设施 → 自有 IPv4 前缀 → 自有 ASN → 多个上游网络
与完全依赖提供商分配的地址相比，这可以带来更强的路由独立性。
但独立性也意味着责任。
运营商必须理解：
- BGP 策略
- 路由通告
- 前缀过滤
- RPKI
- IRR 信息
- 上游关系
- 事件响应
AI 公司不会仅仅因为运营 ASN 就必须成为互联网治理专家。
但组织内部必须有人理解这种依赖。
ASN 不应成为电子表格里被遗忘的号码，直到路由故障发生的那一天。
AI 公司需要理解 RPKI
RPKI 是与互联网号码资源相关的最重要路由安全机制之一。
路由起源授权（ROA）允许资源持有者声明哪个 ASN 获准宣告某个前缀。
RIPE NCC 将 ROA 描述为一个签名的 RPKI 对象，它授权某个起源 ASN 宣告一个或多个前缀，并可包含最大前缀长度。
对于 AI 基础设施运营商，每次路由架构发生变化，这一点都很重要。
假设您的 AI 公司：
- 购入一个 IPv4 地址块。
- 从 ASN 64500 部署该地址块。
- 创建相应的 ROA。
- 后来改用 ASN 64501。
- 更新了 BGP，却忘记更新 ROA。
该路由在运营上可能完全合法。
但安全声明已经过时。
执行路由起源验证的网络可能会把新路由视为无效。
教训很简单：
RPKI 必须跟随运行网络的现实。
因此，网络变更与注册或安全变更应纳入同一套运营流程。
安全基础设施不应成为治理施压工具
RPKI 的价值恰恰在于它回答了一个范围明确的技术问题：
这个 ASN 是否获准宣告该前缀？
范围狭窄正是它的优势。
如果把安全基础设施变成处理无关争议的通用执行机制，它就会变得危险。
关于以下事项的分歧：
- 商业结构
- 租赁
- 客户所在地
- 商业模式
- 机构政治
并不会自动成为路由安全问题。
RPKI 应反映合法的技术授权。
它不应成为惩罚无关机构分歧的工具层。
这一原则源于我在 《运行代码优先》中描述的更大框架：应按照运行网络实际需要的最小技术功能来解释协调系统。
IETF 自身的使命宣言也提供了有用背景。RFC 3935 描述了 粗略共识与运行代码的传统，把技术正当性建立在工程判断和现实实现之上。
对 AI 公司而言，其实际含义是：
安全机制应保护网络。治理不应把安全基础设施变成无关的卡点。
购买 IPv4 不会自动消除治理风险
AI 公司面对 IPv4 依赖时，可能会决定：
我们直接购买自己的地址就行了。
类似所有权的控制可以带来重要好处。
但购买并不会让注册层消失。
在购入 IPv4 后，公司仍可能依赖：
- 注册记录
- 转让流程
- RPKI 服务
- 反向 DNS
- 账户访问权限
- 管理联系人
- 注册管理机构合同
- 机构连续性
这意味着公司只是改变了风险所在的位置。
并不一定消除了风险。
这并不是说购买 IPv4 是错误的。
而是说，采购应区分：
商业收购
与
连续性架构。
签署交易可以确立商业地位。
但它不会自动回答未来路由、注册连续性、安全服务或机构依赖方面的所有问题。
租赁 IPv4 同样带来治理问题
租赁也是如此。
AI 公司选择租赁 IPv4，可能是因为需要：
- 更低的前期成本
- 快速部署
- 弹性容量
- 多区域扩展
- 临时地址需求
这完全可能是理性的选择。
但公司应清楚：
- 究竟是谁控制着地址资源？
- 提供商是直接供给方还是通过中间商提供？
- 哪个 ASN 可以宣告该前缀？
- 由谁创建 ROA？
- 谁控制反向 DNS？
- 如果信誉恶化，会发生什么？
- 谁负责处理滥用？
- 续约时会发生什么？
- 如果上游资源关系失效，会发生什么？
在这些地址已经成为关键网络身份之后，才发现这些依赖，时机最糟糕。
中间商问题实际上是风险问题
这正是普通采购术语可能造成误导的原因。
市场会问：
谁能为我们取得 IPv4？
AI 基础设施运营商则应问：
谁承担 IPv4 背后的风险？
交易市场可以展示库存。
中间商可以介绍交易对手。
合同可以说明条款。
但建设生产基础设施的 AI 公司必须理解交易完成后会发生什么。
如果地址嵌入客户系统，其价值就会越来越依赖连续性。
因此，我在 《i.LEASE 为何存在——以及中间商问题为何实质上是注册风险问题》 中主张，应根据表面交易背后的风险结构评估 IPv4 的执行。
同样的原则也适用于 AI 公司。
评估 IPv4 来源时，不要只看：
每个地址的价格。
还要评估：
每个地址的连续性。
AI 基础设施团队应重视可移植性
互联网号码资源治理最大的结构性弱点之一，是缺少通用的资源级可移植机制。
我所说的资源可移植性，不同于普通的公司迁移或成员资格迁移。
问题不是：
公司能否更换办公地点？
也不是：
公司能否加入另一个组织？
真正的问题是：
如果现有管理结构失效，特定号码资源能否保留其注册管理、控制权证明、安全声明和运营连续性？
这一区别对 AI 基础设施很重要。
设想一家 AI 公司围绕一个稳定的 IPv4 地址块建设了重要的客户平台。
如果围绕该资源的注册机构遭遇：
- 治理崩溃
- 资不抵债
- 法律瘫痪
- 技术故障
- 严重冲突
公司是否应仅仅因为管理服务方不再稳定，就被迫重新编排基础设施地址？
我的答案是否定的。
运行中的网络需要一条连续性路径。
正因如此， 《唯一性协调权利法案》 把可移植性纳入基本设计原则。
保护注册功能，而不是追求机构永存
这一区别对 AI 公司尤其重要，因为 AI 基础设施正变得更加昂贵，在运营中也更加关键。
一家公司可能投入数十亿美元建设算力。
如果网络身份层的设计依赖某个机构永久健康运作，显然并不合理。
注册功能很重要。
它包括：
- 号码唯一性
- 准确记录
- RDAP/WHOIS
- 反向 DNS
- RPKI
- 转让历史
- 安全元数据
但这些功能的连续性，在逻辑上并不要求某个机构永久存在。
我在 《注册连续性谬误——保护账本，而不是守门人》中进一步阐述了这一观点。
原则很直观：
保护账本。
保护安全链。
保护运行中的网络。
保护客户。
管理这些功能的机构应当始终可以替换。
对 AI 公司来说，这属于基础设施工程的基本要求。
我们要求算力具备故障转移能力。
我们要求电力具备故障转移能力。
我们要求存储具备故障转移能力。
我们要求连接具备故障转移能力。
号码资源层又为何可以例外？
AI 公司应像对待其他基础设施风险一样对待注册风险
成熟的 AI 基础设施风险清单可能已经包括：
- GPU 供应
- 电力可用性
- 数据中心集中度
- 传输故障
- 云集中度
- 网络安全
- 硬件故障
- 供应商风险
还应加入：
互联网号码资源风险。
这种风险包括多个类别。
管理风险
谁控制管理这些资源所需的账户和凭据？
注册风险
这些资源周围存在哪些机构依赖？
路由风险
哪些 ASN 宣告这些前缀？
RPKI 风险
安全声明是否与路由现实相符？
提供商风险
网络是否依赖提供商分配的地址？
续约风险
租赁地址是否会在合同到期时消失？
身份风险
有多少客户和合作伙伴依赖特定地址？
可移植性风险
如果必须更换管理服务，会发生什么？
与 AI 公司的算力预算相比，这些问题看似很小。
但后果未必如此。
AI 基础设施团队需要自己的号码资源清单
每一家严肃的 AI 基础设施公司都应能回答：
我们依赖哪些互联网号码资源？
清单应包括：
- IPv4 前缀
- IPv6 前缀
- ASN
- 资源持有者
- 注册管理机构
- 起源 ASN
- RPKI 状态
- 反向 DNS 权限
- 租赁或所有权结构
- 续约日期
- 上游提供商
- 关键客户
- 外部白名单
- 管理账户负责人
不要让这些信息只存在于某一位网络工程师的脑海里。
应把它视为基础设施元数据。
公司应能承受人员变动，而不会失去对号码资源的控制。
AI 公司应按关键程度对 IP 分类
并非每个地址都需要最高级别的连续性保护。
可以建立以下类别。
可替换容量
示例：
- 开发环境
- 临时测试
- 短期实验
重新编号的成本很低。
生产容量
示例：
- 客户工作负载
- 通用应用基础设施
- 区域云服务
连续性很重要，但替换可能仍在可控范围内。
业务关键身份
示例：
- 主要 API 端点
- 面向合作伙伴的网关
- 受监管基础设施
- 安全白名单地址
- 支付相关系统
- 核心客户网络
重新编号可能需要大量外部协调。
无法重新编号或重新编号成本极高的身份
这一类别应当很少见。
但如果某个地址已经嵌入客户、安全系统、合作伙伴、合规环境和多个提供商，更改地址的成本可能超过维持专用连续性架构的成本。
基础设施投入应遵循这种分类。
IPv6 并不是完整答案
AI 公司应在技术和商业上合理时部署 IPv6。
但 IPv6 不会让 IPv4 治理问题在一夜之间消失。
AI 平台仍可能需要与以下对象交互：
- 仅支持 IPv4 的客户
- 传统企业网络
- 安全产品
- 合作伙伴系统
- 外部服务
- 客户白名单
真正需要规划的问题不是：
“IPv4 还是 IPv6？”
而是：
“哪些工作负载仍然需要 IPv4，哪些可以通过 IPv6 运行，每一种身份又需要怎样的连续性？”
这是基础设施决策。
它不应被简化为一种协议取代另一种协议的意识形态之争。
地理位置不应成为所有权
AI 基础设施天然具有全球性。
模型可能在一个国家训练。
其 API 可能在另一个国家运行。
客户可能遍布世界各地。
流量可能穿越多个大洲的网络。
IP 地址管理在历史上可能与某个区域互联网注册管理机构相关联。
但服务区域的地理位置，不应被混同为对资源经济命运的所有权。
这对全球 AI 公司尤为重要。
互联网在全球范围内路由。
前缀不会因为某个数据库在历史上管理过它，就获得政治国籍。
协调层需要准确的记录。
它不需要判断 AI 公司的客户是否足够本地化，从而有资格使用稀缺资源。
这一区别也是我在多篇文章中反复阐述的更大观点的一部分：
轻协调能够发挥作用。重治理会制造不必要的风险。
轻量 IP 地址治理应当是什么样？
有效的号码资源协调层应只回答一组范围有限的问题。
资源是否唯一？
不应存在互不相容的重复注册。
谁能证明控制权？
系统应维护可信的证明。
记录是否准确？
联系人和资源信息应反映现实。
安全声明是否有效？
RPKI 及相关机制应反映合法的路由授权。
变更是否可审计？
转让和更新应具备可靠的历史记录。
争议能否隔离？
分歧不应无谓地摧毁一个正在运行的网络。
是否存在替代路径？
注册功能应能在机构失效时继续存在。
这些已经足以支撑全球互操作的互联网。
其他所有要求在成为强制规则之前，都应接受更严格的检验。
始终应该追问：
运行中的代码真的需要这条规则吗？
AI 基础设施中的运行代码优先
AI 公司尤其有条件理解这一原则。
软件工程师早已区分：
规范如何描述
与
系统实际如何运行。
互联网基础设施也应以同样的严谨态度对待。
运行中的网络是真实的。
客户是真实的。
路由是真实的。
安全依赖也是真实的。
政策文件如果有助于协调这种现实，就是有用的。
如果它开始假装凌驾于现实之上，就会变得危险。
正因如此， 运行代码优先 的重要性并不限于传统电信公司。
AI 公司正在成为互联网基础设施运营商。
它们应继承让互联网得以运作的技术纪律：
协调必须协调之事；不需要中央决策的事项全部去中心化。
AI 公司 IP 治理实用检查清单
在扩展 AI 基础设施之前，请回答以下问题：
- 哪些 IPv4 和 IPv6 资源支撑生产环境？
- 我们的网络包含哪些 ASN？
- 谁被登记为资源持有者？
- 哪个注册管理机构管理每项资源？
- 谁控制管理访问权限？
- 每个生产前缀由哪个 ASN 宣告？
- 我们的 ROA 是否正确？
- 谁可以修改 RPKI？
- 谁控制反向 DNS？
- WHOIS/RDAP 联系人是否准确？
- 哪些资源是租赁的？
- 哪些资源由公司直接持有？
- 哪些资源来自提供商？
- 续约日期分别是什么？
- 如果出租方失效，会发生什么？
- 如果注册管理机构无法提供服务，会发生什么？
- 哪些客户已将我们的地址加入白名单？
- 重新编排每个关键前缀需要多少成本？
- 这项资源只是容量，还是已经成为身份？
- 是否存在可信的连续性或替代路径？
如果公司无法回答这些问题，其号码资源基础设施还没有得到完整治理。
董事会应当了解什么
当公司达到一定规模后，IP 地址治理不应继续完全局限在网络工程团队内部。
董事会和高级管理人员不需要理解 BGP 配置。
但他们应理解风险模型。
需要关注的问题包括：
关键网络身份是否稳定？
更换提供商后，客户能否继续访问服务？
注册管理问题是否会造成业务中断？
重新编号需要多少成本？
机构依赖的单点位于哪里？
这些都是治理问题，因为它们会影响连续性、资本、客户关系和战略灵活性。
投资者应当询问什么
投资者在对 AI 公司开展基础设施尽职调查时，也应审查号码资源。
一个有效的尽调问题不只是：
“你们有足够的 IP 地址吗？”
更应该问：
- 这些地址从何而来？
- 有多少是租赁的？
- 有多少由公司直接持有？
- 谁承担注册风险？
- 哪些地址对业务至关重要？
- 路由是否由内部控制？
- RPKI 和注册流程是否有完整文档？
- 如果关键地址关系终止，会发生什么？
AI 公司即使拥有出色的算力，只要网络身份脆弱，仍然存在基础设施集中风险。
只是这种风险不那么显眼。
更广泛的治理问题
AI 可能成为全球基础设施资本最大的新增需求方之一。
这使其成为互联网治理未来的重要利益相关者。
但 AI 公司不应带着加强中央控制的诉求加入这场讨论。
它们应要求更好的工程设计。
号码资源层应做到：
- 准确
- 可审计
- 安全
- 可移植
- 可替换
- 抵御控制攫取
- 以连续性为中心
互联网确实需要协调。
但它不需要对标识符拥有不必要的主权。
随着建立在号码资源之上的经济价值持续增长，这一区别会变得更加重要。
结语
AI 公司正在学习从战略角度思考芯片、电力、冷却、土地、光纤和数据中心。
它们还应把互联网号码资源加入这份清单。
IPv4 地址、IPv6 地址、ASN、BGP、RPKI、反向 DNS 和注册记录，看起来可能只是基础设施栈深处的细节。
事实并非如此。
它们有助于决定客户能否访问公司斥巨资建设的基础设施。
随着 AI 公司扩张，一些 IP 地址仍会是可替换的容量。
另一些则会成为深度嵌入的网络身份。
治理模型应承认这种区别。
正确的问题不只是：
我们有多少 IP 地址？
它们要花多少钱？
还要问：
谁控制它们？
谁可以路由它们？
谁可以修改安全声明？
它们周围存在哪些机构依赖？
它们能否经受提供商变更？
它们能否经受注册管理机构失效？
当运行现实与管理现实发生分歧时，会发生什么？
这就是 IP 地址治理更深层的含义。
注册管理机构应保护唯一性。
它应保护准确性。
它应保护合法的安全声明。
它应让转让和控制权变更清晰可查。
但它不应成为围绕所记录号码建立起来的运营命运的所有者。
AI 基础设施将越来越依赖稳定的网络身份。
这类基础设施值得采用与其他关键层相同的设计纪律：
不保留任何不必要的单点故障。
只要技术上可以故障转移，就不设置无法替代的管理者。
不混淆协调与主权。
保护账本。
保护运行中的网络。
保护客户。
这就是 AI 公司应了解的 IP 地址治理。
Heng.lu 站内延伸阅读
- 《唯一性协调权利法案》
- 《运行代码优先：维护互联网原始设计所需的补丁》
- 《注册连续性谬误——保护账本，而不是守门人》
- 《谈 LARUS One——网络身份、客户连续性与提供商收入的经济学》
- 《i.LEASE 为何存在——以及中间商问题为何实质上是注册风险问题》
权威外部资料
常见问题（FAQ）
1. AI 公司为何应关注 IP 地址治理？运营 API、GPU 云、数据中心、企业平台及其他面向互联网基础设施的 AI 公司，可能会依赖公共 IP 地址和 ASN。治理会影响这些资源如何注册、路由、保护、转让以及保持运行。
2. AI 公司应跟踪哪些互联网号码资源？公司至少应维护生产 IPv4 前缀、IPv6 前缀、自治系统号、注册关系、路由起源、RPKI 配置、反向 DNS 以及资源合同的清单。
3. IP 地址与网络身份有何区别？IP 地址最初是一个技术标识符。当客户、合作伙伴、防火墙、API、安全系统和合规流程依赖某个特定地址保持稳定时，它就可能成为网络身份。
4. AI 公司应购买 IPv4 地址吗？对于可预测的长期需求，购买可能是合理选择，但商业收购并不能消除注册、路由、RPKI 和管理依赖。因此，这项决策应包含连续性分析。
5. AI 公司应租赁 IPv4 吗？租赁可以提供灵活容量并降低前期成本。在生产环境依赖某个地址块之前，公司应评估资源来源、提供商结构、路由权限、RPKI、反向 DNS、信誉、续约以及连续性。
分类: 博客
