PortArgs、IPC 名称与 shared memory 引导#

这章解决什么问题#

前面的运行时架构章节已经讲了：

Engine 怎样装配进程
typed IPC 怎样组织 manager 间消息
多 worker 入口怎样把请求汇入 shared runtime

但还有一层非常关键的“连接信息编译与传递”没有被单独讲透：这些进程与 worker 到底怎样拿到同一套端口、IPC 名称和 bootstrap 参数？特别是：

PortArgs
tokenizer_ipc_name
scheduler_input_ipc_name
detokenizer_ipc_name
multi-tokenizer 模式下的 shared memory 参数传递

如果不把这一层讲清楚，前面的装配图和多 worker 图仍然会显得像“组件会自动找到彼此”，而不是一套被明确编译和传递的连接信息。

为什么这层值得单独成章#

因为在运行时系统里，“谁和谁通过什么名字连起来”从来不是小事。它既决定：

启动是否稳定
端口是否冲突
多 worker 是否能各自获得正确的返回通道

也决定你排障时该去看：

主服务逻辑
还是连接信息根本没编对

因此 PortArgs 和 shared-memory bootstrap 不是实现细枝末节，而是运行时拓扑如何被真正落成的关键一步。

一张图：运行时连接信息并不是天然存在，而是先被编译、再被传播#

这张图解决的理解障碍是：很多读者会默认各进程天生知道彼此地址，实际上系统是先编译一套连接信息，再把它传给不同进程和 worker。

flowchart LR
    Args["ServerArgs"] --> Ports["PortArgs.init_new(...)"]
    Ports --> Engine["Engine / scheduler / detokenizer"]
    Ports --> SHM["shared memory bootstrap"]
    SHM --> Worker["TokenizerWorker / Granian worker"]
    Worker --> IPC["worker-local tokenizer_ipc_name"]

图比纯文字多解释的一点是：运行时连接信息也是一条正式的“编译 -> 分发 -> 本地化”链，而不是隐式环境状态。

`PortArgs` 为什么是运行时连接的最小事实源#

server_args.py 里的 PortArgs 很值得先读，因为它直接定义了运行时真正需要共享的几类连接信息：

tokenizer_ipc_name
scheduler_input_ipc_name
detokenizer_ipc_name
rpc_ipc_name
metrics_ipc_name
tokenizer_worker_ipc_name
nccl_port

这说明运行时连接信息并不只是“一个总端口”，而是：

请求主链
detokenizer 回程
rpc
metrics
worker 内部通道

这些都各有自己的连接名字或端口。

从架构角度看，这是一件好事，因为它让不同通信职责不会被混进同一个“万能端口”里。

`PortArgs.init_new(...)` 真正在做什么#

更稳的理解是：它不是在“挑几个空闲端口”，而是在根据当前 server 人格编译一套连接拓扑。

单机、非 DP attention 场景#

这里更偏：

用 ipc://... 命名临时文件型通道

这说明单机本地模式更偏向低开销、短路径的本机 IPC。

启用 DP attention 场景#

这时会切到：

TCP 地址
基于 dist_init_addr 和多个 port delta 推导连接点

也就是说，一旦系统进入更分布式的运行人格，连接信息也会从“本地 IPC 名”升级成“可跨节点的 TCP 拓扑”。

这再次说明 PortArgs 不是静态结构，而是 runtime topology compiler 的一部分。

为什么 `tokenizer_worker_ipc_name` 是一个特别值得注意的字段#

只有在：

tokenizer_worker_num > 1

时，它才会被真正生成。这说明多 worker 路径并不是把主链路平移复制几份，而是给入口 worker 额外编出一条内部协作通道。

换句话说：

单 worker：入口和 manager 更像同体
多 worker：入口和 shared runtime 之间多出了一层 worker 侧专用连接

这和前面 request lifecycle 里“多入口共享同一 runtime”那条主线正好咬合。

shared memory 为什么会出现在这里#

multi_tokenizer_mixin.py 里的：

write_to_shared_memory(...)
read_from_shared_memory(...)
write_data_for_multi_tokenizer(...)

说明系统在 multi-tokenizer 模式下，并不会让主进程直接把对象传给 worker，而是选择：

把 (port_args, server_args, scheduler_info) 打包进 shared memory

这是一种非常务实的引导方式，因为它避免了：

在 worker 启动时重复推断整套连接拓扑

而是把已编好的连接信息一次性传给 worker。

为什么 worker 还要再改写自己的 `tokenizer_ipc_name`#

http_server.py::init_multi_tokenizer() 里有一段很关键的逻辑：

先从 shared memory 读出一份公共 port_args
再为当前 worker 生成新的 tokenizer_ipc_name

这说明 shared memory 给的是：

共同的拓扑基础

而 worker 还要在本地再做一步：

“把我自己的返回通道名字个性化”

这非常合理，因为多 worker 模式下，每个 worker 都需要一个独立的回包落点。否则 detokenizer 和 router 根本无法精确把结果送回原始 worker。

`SenderWrapper` 为什么特别值得提#

它看起来只是个小 wrapper，但语义很重要：

当发送的是 BaseReq
就自动把 http_worker_ipc = port_args.tokenizer_ipc_name 附上

这说明连接信息不只存在于外部 bootstrap 结构里，它最终还要被显式写进请求对象，才能在后续回包链路里继续生效。

从系统书角度看，这很值得强调，因为它说明：

连接拓扑不会停留在装配阶段
它最终还会进入 request-level 语义

为什么这章和 3.5 / 3.8 / 2.6 不重复#

这三章分别讲的是：

3.5：进程怎样被装配起来
3.8：manager 之间怎样交换 typed message
2.6：多 worker 入口怎样放大

而这一章补的是它们之间的连接层：

这些进程和 worker 共享的端口 / IPC 名字怎样被编译与传播

也就是说，它在解释：

组件为什么能连起来

这一层最容易出现的误判#

1. 以为 `PortArgs` 只是一个小配置对象#

它实际上定义了运行时的连接拓扑。

2. 以为 worker 会自己推断完整连接信息#

multi-tokenizer 模式下，它们依赖 shared memory bootstrap。

3. 以为请求回包路由只在 router / detokenizer 层决定#

真正的 worker 身份信息更早就被 SenderWrapper 写进请求对象了。

如果你要顺着源码读这条连接信息链，推荐顺序是什么#

建议按下面顺序：

PortArgs 定义与 init_new(...)
write_data_for_multi_tokenizer(...)
init_multi_tokenizer() / _init_granian_worker()
SenderWrapper.send_pyobj(...)
再回到多 worker 和 typed IPC 章节里的 router / detokenizer 分流逻辑

这样读，你会先看到“连接信息从哪里来”，再看到“这些信息如何进入请求和 worker”，最不容易把连通性问题误判成业务逻辑问题。

小结#

这一章真正要补齐的，是运行时架构里此前还比较隐性的连接层：

PortArgs 负责把运行时连接拓扑编译出来
shared memory 负责把这套拓扑引导给 worker
worker-local tokenizer_ipc_name 和 SenderWrapper 则把它继续带进请求语义

到这里，运行时架构就不只讲组件和消息，也开始讲“这些组件和消息为什么真的能在同一套连接世界里找到彼此”。