2026-06-05 学习日志

今日主题

RLHF = Reinforcement Learning from Human Feedback：RL（强化学习）+ HF（人类反馈），
名称本身描述了核心机制——用人类偏好作为奖励信号，通过强化学习试错优化模型。DPO 出现后省掉了显式 RL 步骤，但解决的问题域相同，所以常被放在同一语境讨论。
SFT 与 RL 的学习信号本质不同：SFT 给模型标准答案（"应该输出什么"），RL 只给奖励分数（"答得好不好"）。
后训练叫"强化学习"是因为 RLHF 第二阶段确实用 PPO 等 RL 算法，模型通过生成-评分-更新的试错循环，自己摸索高分策略。
"强化"指好行为被奖励信号加强、坏行为被削弱。
DPO 本质不是 RL 但替代了 RL 阶段：DPO 的数学洞察是偏好数据中直接隐含奖励信号，无需训练奖励模型、无需试错循环，一步到位。
省掉了 RLHF 的奖励模型训练和 RL 优化两步，更简单稳定、计算成本更低，已基本替代传统 RLHF 成为后训练主流。
但推理模型仍需额外的 RL 阶段训练思考链。

SSH 靠 TOFU 而非 CA 证书：SSH 首次连接时记录主机公钥到 known_hosts，之后每次比对——变了就报警。
这跟 HTTPS 的 CA 证书链不同，CA 体系依赖第三方签名担保，SSH 则完全信任首次连接时收到的公钥。TTFU 的弱点是首次连接有被中间人攻击的风险，
但优点是简单、无需依赖任何第三方。SSH 协议本身也支持 CA 签发 host cert，但工程实践中很少使用。
HTTPS 交叉验证 SSH 公钥的方法：判断 known_hosts 里的公钥是否被中间人替换，
可以用 HTTPS（CA 证书体系保证真实性）获取官方的 SSH 指纹，再跟本地比对。具体：1) 从 docs.github.com（HTTPS）获取官方指纹；
2) 从 api.github.com/meta（HTTPS）再拿一份交叉印证；3) 用 ssh-keygen -lf 算本地指纹；三者一致则无中间人。
信任传递链是 HTTPS CA → GitHub 官方指纹 → SSH known_hosts。

Ed25519 公钥只有 68 字符：RSA 4096 的公钥可达 700+ 字符，而 Ed25519 仅约 68 字符。短是因为算法本身编码紧凑，
并非安全性打折——Ed25519 的安全强度等效 RSA ~3000 位。工程上短密钥意味着更小的握手开销和更快的连接建立。
GitHub 的 known_hosts 存了三套算法（Ed25519/RSA/ECDSA）是为了兼容不同 SSH 客户端。

VMCS 通过 VMPTRLD 预加载而非指令传参：VMLAUNCH/VMRESUME 不带参数，
它们隐式使用当前 CPU 上已通过 VMPTRLD 加载的 VMCS。这样设计是为了让 CPU 可以 cache VMCS 并做内部优化，
避免每次 VM Entry 都要做地址翻译。VMCS 的 current 状态是 per-CPU 的，切核心时需要重新 VMPTRLD。
VM Exit 是虚拟化性能瓶颈：一次 VM Exit 成本在几百到上千 cycles，涉及上下文切换、pipeline 刷新和 cache 影响。
因此虚拟化优化的核心策略是减少 VM Exit 次数——通过精细控制 bitmap 只拦截危险指令，其他全速跑。
virtio 的价值也在于用共享内存替代频繁 VM Exit。
CPU 每个核心有独立寄存器组：通用寄存器、RIP、RFLAGS、控制寄存器在物理上是 per-core 的，不是共享后被 OS 分时复用。
每个 core 本质是一台独立执行状态机，寄存器是其私有工作空间。多核之间共享的是 L3 Cache、内存、PCIe 设备等。

Linux scheduler 完全不感知虚拟化：scheduler 只看到 vCPU 线程（task_struct），
不知道 VM、VMCS、Guest OS 的存在。VM 之间的切换本质是 scheduler 在 vCPU 线程之间切换，
KVM 在线程运行时加载对应 VMCS。三层分工：scheduler 选线程 → KVM 管 VMCS → CPU 执行 VM。
KVM 只在 VM Exit 后才有机会切换 VM：VM 在跑时 KVM 完全看不见它，只有 VM Exit 发生后 CPU 才把控制权交回 KVM。
kvm_vcpu_ioctl_run() 是核心循环入口，
内部是 VM Entry → Guest 运行 → VM Exit → KVM 处理 → 继续或让出的循环。
VM Exit 之后 KVM 才决定继续当前 VM、阻塞 vCPU、或让 scheduler 切走。

virtio 是半虚拟化 I/O 而非全虚拟化：virtio 只改了设备层的通信方式（用 virtqueue 共享内存替代模拟硬件寄存器），
不改 CPU 和内存虚拟化。它常出现在 KVM 这种全虚拟化环境中作为 I/O 加速手段，
因此 KVM 实际是 VT-x 全虚拟化 + virtio 半虚拟化 I/O 的混合架构。
云厂商使用分层混合虚拟化而非单一方案：
AWS（Nitro）、Azure（Hyper-V）、阿里云（KVM+神龙）底层都是 VT-x/AMD-V 提供 CPU 虚拟化基础 + Hypervisor 做控制层 + virtio/SR-IOV/硬件 offload 做 I/O 加速的混合体系。
趋势是 Hypervisor 变轻、I/O 硬件化。

退出码不是充分判据：Docker 区分手动 stop 和崩溃不靠退出码，
因为容器内程序正常 exit(0) 或外部脚本 kill 发 SIGTERM 也会产生相同的 0/143 退出码，但 Docker 会重启它们。
退出码只是容器退出后的尸检报告，真正决定重启与否的是 Docker 内部状态机标记的 DesiredState。
DesiredState 标记先于信号发送：docker stop 的执行顺序是 1) 先将 DesiredState 改为 Stopped，
2) 再发 SIGTERM，3) 容器退出。这个顺序是关键——重启判断读的是第 1 步的标记，而非第 3 步的退出码。
只要 DesiredState == Stopped，无论退出码是什么都不重启。
状态机透传才是区分依据：Docker 底层通过 containerd 维护容器生命周期状态机。
手动 stop 走 Running → Stopping → Stopped 路径，重启监听器在 Stopping 阶段被显式注销；
异常崩溃直接从 Running 掉到 Stopped，监听器发现未经过 Stopping 阶段，于是触发重启策略。OrbStack 完全兼容这套机制。