2026-10-27（周二）赛博日记

生成时间：2026-10-27 23:50 (Asia/Shanghai)

核心工作

💻 Claude Code 工作记录

  • 时间：11:00 ~ 19:09
  • 项目：ysbapitest（内部 API 测试项目，以代称记）
  • 会话数：Cursor 7 个 / Claude 0 个，共 340 条消息
  • 主要内容：
    • 上午：梳理某次会话的完整调用链路，定位到一个比已修复问题更底层的缺陷，重理问题边界
    • 中午：连上内网测试库（192.168.x.x，已泛化）核对数据，确认没有残留占锁的僵尸行，零数据改动，纯排查收口
    • 下午：完成代码修改并按仓库规范提交推送；随后对可疑问题做了一轮完整排查，结论明确
    • 傍晚：核对 Java 8 兼容性（streams / Optional.orElseThrow 均为 Java 8 可用），打磨测试代码
    • 晚间：设计 API 用例落库前的校验逻辑——用例落库前核对券、订单、收货地址是否属于该用例的默认用户和门店；不匹配只丢弃该条、其余照常写入，全部不匹配才整批拦截
  • 状态：✅ 正常（多为自动兜底摘要，未调用 LLM 提炼）

🏠 Hermes 本机事项（vLLM 工作台调优）

  • 主题：PP2 模式 KV 池参数化 + MTP 投机解码性能排查
  • 核心成果：
    • 启动脚本参数化：start-nvfp4-prod.sh 改为从 tool-params/flashnext.json 读取 KV 池等 overrides，值带正则白名单校验（实测注入串会被置空走默认），沿用「落盘后下次启动生效」约定
    • MTP 根因定位（读 vLLM 源码确认，非猜测）：投机解码要求前缀命中时丢掉最后 1 块重算，但 _annotate_eagle_groups 只认 Kimi-K3 DSpark / deepseek_v4 的标记，不认识 qwen4_exp 的 MTP 层 → 保守地把包括 4 个 Mamba 组在内的所有组都当 draft 组处理，导致性能劣化。修复路径：eagle_drop=off + batched_tokens=8192，前缀缓存命中率有望从 <1% 恢复；另有打补丁识别 MTP 组的彻底路线，但维护成本高暂不推荐
    • GPU「空转」之谜实测排除：2 秒间隔采样显示是请求脉冲（util 87-94%、功耗 100-150W）而非轮询底噪；空闲时 10 秒内回落到 ~48+41W 驻留本底。真正的外部消费者是自己工作机上的 Codex/Claude Code
    • 安全发现：:8000 曾暴露于公司网段可达，10-22 后无外部访问，建议收紧（绑定 xxx.xxx.xxx.xxx 走 ssh 隧道，或防火墙仅放行 tailnet + LAN），待授权后执行
  • 残留：GLM key 三消费者（Hermes 对话 + 知识库摄取 + 记忆栈）的 429 风险已写入 yaml 注释；TEP2 vs PP2 的取舍（decode 100 vs TTFT 2 倍慢 + OOM 风险史）待定

思考与备忘

  • vLLM 投机解码的「保守回退」策略值得警惕：不认识的模型结构会被全组按 draft 处理，性能劣化且难察觉——遇到"感觉变慢"优先查版本间默认开关变化（本次即 TEP 相关开关）
  • 落库校验的粒度设计：单条丢弃优于整批失败，用数据韧性换可用性
  • 内网服务端口暴露面需要定期审计，哪怕目前没被滥用

今日摘要

两条主线：白天在 ysbapitest 上完成了链路排查、测试库核验、代码提交与用例落库校验设计（7 个 Cursor 会话 340 条消息）；晚上围绕本地 vLLM 做了 KV 池参数化改造和 MTP 性能根因分析（vLLM 源码级），顺带排除了 GPU 功耗疑云并发现了一个内网暴露面隐患。

📊 自动化统计

  • 捕获 Memory 数：0（memory/2026-10-27.md 不存在）
  • 笔记更新数：1（本机笔记仓库自动提交 03:00）
  • Todoist 完成任务数：0（当日完成/到期均为空）
  • Claude Code 会话数：7（Cursor 7 / Claude 0）