llm-infra · E1 预消化简报(2026-11-02)

  • 作者：spark
  • 批次：cron 3c698927-9044-4540-873b-f961d6380d7d · E1 日间预消化轮 · llm-infra
  • 覆盖范围：宿主机增量清单 /shared/research-kb/organized/indexes/work-guard/3c698927-9044-4540-873b-f961d6380d7d.json（1 项任务 / 8 件材料：7 repo_card + 1 paper_card；created_at=2026-11-02 18:40:02、expires_at=2026-11-02 19:40:02 CST，未过期；items 非空）
  • 方法边界：逐份全读清单 item.materials 的 8 份 source（相对 /shared/research-kb/，未只取 item.source 首项——首项 4818-synchopate-nemotron-30b-cpu-256k.md 只是其中一件）+ 活文档基线 organized/knowledge/llm-infra.md（v3.70，2026-10-29 05:00）全文 grep + 工作队列 organized/queue/work-queue.md（2026-11-02 18:00）+ 近 2 天他人 inbox 笔记（jay / tom / flyp / stephen）+ 近 3 天 paper_cards 抽查 + 库内已有攻略交叉（organized/guides/，1719 份）；未联网补料（web_search = 0）、未全库扫描、未为凑字数多轮重写、未改活文档
  • 字数：约 3,100 字（由 8 件材料的可论证密度决定，未凑到旧稿上限）

§0 本轮判定

8 件材料 → 5 件 NET-new 实质增量 + 2 件已入册但正文空缺 + 1 件纯元数据刷新。

活文档全文 grep 逐件核验（含 §6.99.2 的 494 条 arXiv 表、§6.99.5 的 736 条 URL 表、§0/§3/§4/§5 正文）：

材料 标识 活文档命中 判定
synchopate/nemotron-30b-cpu-256k synchopate / nemotron-30b-cpu-256k 0 NET-new（卡面级）
xuiltul/animaworks animaworks / xuiltul 0 NET-new（卡面级）
ozynautetu-create/FlowForge-Optima FlowForge / ozynautetu 0 NET-new（卡面级）
modelscope/ms-cookbook ms-cookbook / modelscope/ms-cookbook 0 NET-new（库内已有攻略，见增量 ④）
GeminiLight/EvoDesign EvoDesign 6 跨轴/沿用（v3.69/v3.70 已两轮承接，本轮仅元数据漂移）
arXiv:2604.17227 2604.17227 1（仅 §6.99.2 arXiv 表 line 92） 已入册但正文空缺（§0.99.5 URL 表命中 0）
maximhq/bifrost bifrost / maximhq 0（仅 archive/multimodal-changelog.md 命中，全库他轴） NET-new（库内已有攻略，见增量 ①）
ttoss/soat soat / ttoss 0 NET-new（卡面级）

关键结构性判断：本批 8 件中 4 件是 首次采集 当日的新仓库（synchopate / xuiltul / ozynautetu / modelscope-ms-cookbook 的首次采集均为 2026-11-02），另 2 件是 8 月/6 月起的旧仓库再入 manifest（soat 首次采集 2026-08-16；bifrost 首次采集 2026-06-30）。这意味着本批的"信息密度分布"极度不均——真正的可论证增量集中在 2 件已有攻略的仓库上，而 4 件新仓库只有卡面一句话简介。本简报严格按"证据强度"而非"数量"排序，不把卡面元数据当技术主张。

§1 今日最重要的增量（5 条，按可论证密度排序）

增量 ① maximhq/bifrost ⭐⭐⭐⭐（本批唯一有 production 级 + 库内攻略 + 双源互证的材料）

  • 来源：organized/repo_cards/153-maximhq-bifrost.md；https://github.com/maximhq/bifrost；库内已有攻略 organized/guides/maximhq-bifrost.md（作者 Jay，2026-07-08 更新，已核实 README + 官方文档 Quickstart/Provider Configuration/Semantic Caching/Benchmarking + Discord）
  • 要点（卡面 + 攻略交叉）：
  • 卡面：Go · Apache-2.0 · 9,268★ · 周增 +173 · 最近提交 2026-11-01 · 主分类 risk · 形态 app · 分类 skill · 成熟度 production · 首次采集 2026-06-30。简介：Open-source, high-performance AI gateway，同时是 LLM gateway / MCP gateway / agent gateway；一个 OpenAI 兼容 API 接 10,000+ 模型，带 failover、load balancing、semantic caching、virtual keys、budgets 与 MCP Code Mode；5k RPS 下额外开销 <200 µs。
  • ⚠️ 卡面与攻略存在两处口径冲突（必须逐条写出，不得抹平，见 §2 D-新1/D-新2）：① 延迟数字三套并存——卡面 <200 µs、卡面中文版 <100 µs、攻略实测引文为 5,000 RPS 持续压测下额外延迟 ~11 µs（t3.xlarge）/ 59 µs（t3.medium），且攻略明写"比 LiteLLM 快 50 倍"是官方宣称，需验证。② Provider 数量两套并存——卡面简介"10,000+ models"，攻略正文为"23+ 家 AI 提供商"，二者不是同一量纲（模型数 vs 供应商数）。
  • 攻略的可核查工程细节：① 三种部署形态——NPX/Docker 独立 HTTP 网关（任意语言可用）、Go SDK 深度集成（go get，最小延迟）、Kubernetes + Helm Chart（ArtifactHub）；② 模型名格式 provider/model-name（anthropic/claude-3-5-sonnet / bedrock/us-west-2/anthropic.claude-3-5-sonnet-v1@BEDROSTER 等 provider-specific 差异是已知坑）；③ semantic cache 默认 threshold 0.95——攻略明确"过高几乎不命中，过低会返回语义相似但不正确的答案"；④ governance 插件支持 virtual key + 月度 USD 预算 + allowed_models 白名单；⑤ MCP Gateway 让模型经 MCP 调外部工具（文件系统/搜索/数据库）；⑥ 可观测性为 Prometheus metrics + 分布式追踪 + 请求日志；⑦ PostgreSQL 必须以 template0 + UTF-8 建库，否则迁移失败；⑧ OIDC/SSO、集群模式、Guardrails 属 Enterprise 许可。
  • 攻略的对比表口径（可直接引用但须带"官方/攻略转述"标注）：LiteLLM Python 实现、100+ provider、~ms 级、无语义缓存；Bifrost Go、23+ provider、有、<15 µs。
  • 与活文档脉络的关系：v3.70 的 §3 C392（工具 schema 体积已是协议层一等预算） 与 §0.5.9 脉络 O（上下文供给面 = 攻防面） 已经把"网关"这件事推到了协议层预算与攻防两面的位置，但活文档至今没有任何一件"企业级 AI 网关"样本——本件是这条线的第一个可核查落地载体，而且它同时把活文档此前分散在各处的能力收敛到一个进程里：语义缓存（成本）、virtual key + 预算（治理）、MCP Gateway（工具）、Guardrails（安全）、Prometheus（观测）。 更关键的是它给出了 C392 的对偶：C392 说的是"你传给 agent 的 schema 体积要设预算"，本件说的是"你在中间替 agent 管住所有 provider 的路由与预算"——即中间层既可以是攻击面（v3.70 脉络 O 的 BLA 面向 agent 反向抽取）也可以是治理面（bifrost 面向 agent 正向的路由/配额/护栏）。另外 §5 趋势线里的"语义缓存"在本库此前只作为零散工程点出现，从未被当作网关层的一等公民；本件的 threshold 口径是一个可核查的成本-正确性权衡点，比"命中率"这类单一指标更有论证价值。 本件是本批唯一"成熟度 = production"的材料——活文档此前绝大多数样本是 experimental/research。
  • 建议归入：§0.5.1（新增行，⭐⭐⭐⭐，标注"首个 production 级网关样本 + 库内已有攻略 + 双源互证但口径三套"）+ §0.5.9 新增 脉络 P（"网关从协议层预算走向治理层中间件"）+ §3 候选 C（"语义缓存的正确性/命中率权衡必须显式调参，不能只看命中率"）但需至少 1 件独立样本佐证，暂不升级为 C + §2 矛盾 D-新1/D-新2。

增量 ② modelscope/ms-cookbook ⭐⭐⭐（本批唯一"中文教科书式全链路"样本；库内已有 spark 本人攻略）

  • 来源：organized/repo_cards/4814-modelscope-ms-cookbook.md；https://github.com/modelscope/ms-cookbook；库内已有攻略 organized/guides/modelscope-ms-cookbook.md（作者 spark 本人，2026-11-02 更新，已核实 39 章目录结构 + 第 07 章代码实读 + 构建脚本）
  • 要点（卡面 + 攻略交叉）：
  • 卡面：HTML · Apache-2.0 · 512★ · 周增 +0 · 最近提交 2026-11-02 · 主分类 agent · 形态 app · 分类 trending · 成熟度 research · 首次采集 2026-11-02。简介：魔搭紫皮书，覆盖模型选型、推理、微调、评测、RAG、Agent 与 AIGC。
  • 攻略的结构性事实（比卡面信息量大一个量级）：8 篇 39 章，状态标注 ✅可读(31) / 🚧待更新(1，第 27 章 AI 视频) / 🤝共建入口(2，第 22 / 39 章)；学习路线 = 模型选型 → 推理部署 → 数据准备 → 微调评测 → 应用开发；配套工具链 EvalScope（评测）/ ms-swift（微调）/ DiffSynth（图像 LoRA）/ Ollama（本地推理）。
  • 方法论内核（可作独立技术主张引用）：第 05 章"把业务问题转换成模型任务问题（定义输入输出 + 评估标准）" + 第 06 章"用 EvalScope 形成第一份报告" = "先评再选"，明确反对"拿排行榜选模型"。
  • 硬约束级细节：① 显存是隐性门槛——第 07 章示例 device_map="cuda:0" + torch.bfloat16 + max_inference_batch_size（注释明说"调小可避免 OOM"），攻略明写"本地没 N 卡就别硬抄，第 09 章 Ollama 路线更适合纯 CPU 起步"；② 构建系统双份陷阱——改 content/source-html/，不能直接改 content/chapters/（后者是构建产物会被覆盖），须同时提交源文件与生成文件；③ 校验脚本要求 Node.js 22+，而构建本身只要 Python 3；④ 第 11 章完整走通"LoRA 微调 → GGUF 量化 → Android 部署"（MiniCPM 上手机），第 21 章是端侧图像推理 + 人工确认 + 离线同步；⑤ 依赖版本浮动未在 README 汇总表给出，各章版本需以章节正文为准（攻略自标 ⚠️ 待补）。
  • 与活文档脉络的关系：v3.70 的 §0.5.9 脉络 L（等待时间从推理栈指标下沉为人机界面预算） 与 脉络 M（给 agent 看结构） 都是单点技术机制；本件提供的是"从选型到上线"的完整教学编排，这在本库从未出现过——活文档目前是"机制清单"，不是"路径清单"。它的真正论证价值有三处：① "先评再选"是评测轴与推理轴的接口——v3.70 的 C390-C396 全部是技术机制层的共识，缺少"评测先于部署"这一流程层的方法论约束；② 显存/OOM 是"模型选型"的第一性约束——本库已有 C390 等强调"等待时间"，但"选型阶段就要按显存/参数量算可行性"这个更早、更便宜的决策点，本件第 07/09 章给出了明确路径（第 07 章 GPU 路线 vs 第 09 章 Ollama 纯 CPU 路线）；③ 端侧部署第一次有"LoRA → GGUF → Android"的完整可复现链条——与 2026-11-01 简报里 Mika（wangzan101）的"端侧 Phone Agent + arm64 沙箱"是同一轴的第二个独立样本，且本件是教学式、Mika 是产品式。⚠️ 注意本件的成熟度标为 research 且第 27 章待更新、22/39 章为共建入口，不能当成完整教程引用。
  • 建议归入：§0.5.1（新增行，⭐⭐⭐，标注"首个全链路教学编排样本 + '先评再选'方法论 + 端侧 LoRA→GGUF→Android 链条"）+ §0.5.9 脉络 L 补"选型期显存可行性先于部署期性能优化"这一决策时序注记 + §3 候选 C（"模型选型必须以评测基线而非排行榜为入口"）单样本，不升级 + §4 新增 O（各章依赖版本浮动未汇总）。

增量 ③ arXiv:2604.17227 "Cloud-native and Distributed Systems for LLM" ⭐⭐（已入 arXiv 表但正文/URL 双空缺；survey）

  • 来源：organized/paper_cards/140-2604-17227.md；https://arxiv.org/abs/2604.17227；DOI 10.48550/arxiv.2604.17227；OpenAlex ID W7155070632；开放获取 green；被引 4（S2）/ OpenAlex 0 / 影响力被引 0；OpenAlex 更新 2026-07-19；主题标注 7 标签（agent/database/engineering/evaluation/llm-infra/multimodal/rag），主分类 llm-infra，形态 survey；上游来源文件 /inbox/jay/2026-06-10-database-cloudnative-backend.md（2026-06-10，已 5 个月）
  • 要点（严格限于 card 字段）：
  • TLDR（英）：分析分布式 LLM 训练、推理 serving、云原生编排、资源管理、异构计算与边云智能的研究进展与实践发展，指出要规模化支撑 LLM，必须从"通用云基础设施"转向"LLM-aware、跨层、自适应系统"。
  • TLDR（中）：探讨 cloud platform 与 distributed system 在支撑 LLM 可扩展性/效率/优化方面的作用，涵盖数据管理、资源优化，以及对 microservices、autoscaling 与 hybrid cloud-edge 方案的需求。
  • 场景标注：分布式系统、云原生LLM。卡内自列待补齐 4 项：BibTeX/正式引用格式、方法与实验设置细节、与现有工作的差异点、是否有代码和数据集。
  • ⚠️ 卡内「可复用信息」段存在疑似串卡：该段内容为 "KubeVirt爆发（虚拟机直接在K8s内运行）/ 自动化FinOps成主流，过度配置集群已成历史 / 覆盖迁移策略、最佳实践、生态工具链 / 标签 Kubernetes 迁移 FinOps KubeVirt GatewayAPI 2026 / 建议动作：关注；工程实践参考，非学术" —— 这段的措辞（"建议动作：关注"、"工程实践参考，非学术"）与本卡自称的"学术综述"（survey / ⭐⭐⭐ / 被引 4）自相矛盾，且它显然来自 jay/2026-06-10-database-cloudnative-backend.md 这条云原生数据库笔记而非本 arXiv 论文。在核实原文前，这段不得作为 2604.17227 的技术主张引用（见 §2 D-新3）。
  • 与活文档脉络的关系：本件是本库唯一一件以"LLM 的云原生/分布式系统"为对象的综述级论文，命中活文档中一个至今完全空缺的段落。v3.70 的 §0.5.9 三条脉络（客户端时延预算 / 给 agent 看结构 / 可判定性分叉）全部是单点机制，而本件的 TLDR 恰好提出了一个统一框架性论断——"LLM-aware、跨层、自适应"，这恰好是三条脉络的公共上位概念。更有意思的是，本件与 v3.70 的 §0 "推理栈的最前线从服务端移到客户端" 构成对偶：本件主张的是云端要变成 LLM-aware，而 v3.70 记录的是算力预算要往客户端沉——两者指向同一根轴的两端（"算力应该住在哪一层"）。 另一处实用价值在 §6.99.5 URL 表：该表命中 arxiv.org/abs/2604.17227 为 0（仅 arXiv 表 line 92 有编号），说明"入册"与"有可引链接"是两套账——本件今晚应作为URL 表 +2 候选（https://arxiv.org/abs/2604.17227 与 https://arxiv.org/html/2604.17227v1，后者写在卡内）。 ⚠️ 但本件的证据强度是本批最弱的 paper_card：被引仅 4、OpenAlex 被引 0、影响力被引 0、卡内明列 4 项待补齐、且上游来源已 5 个月未更新。本简报未取原文正文，因此本件只作"框架级登记"，不作"结论级引用"。
  • 建议归入：§0.5.1（新增行，⭐⭐，标注"已入册 5 个月、本轮首次正文承接；survey 级框架论断；正文/URL 双空缺已补"）+ §0.5.9 新增 脉络 Q（"算力应该住在哪一层：云端 LLM-aware ↔ 客户端预算下沉"——作为假设性框架，不作断言）+ §6.99.5 URL 表 +2 + §4 新增 O（必须取原文正文核"跨层自适应"的具体主张；卡内「可复用信息」段疑似串卡）；§3 不建议立 C（被引 4 + 无正文）。

增量 ④ synchopate/nemotron-30b-cpu-256k ⭐⭐（卡面级；CPU 推理 + 长上下文的一次罕见组合）

  • 来源：organized/repo_cards/4818-synchopate-nemotron-30b-cpu-256k.md；https://github.com/synchopate/nemotron-30b-cpu-256k
  • 要点（严格限于卡面，卡内无任何 README 核实、无任何数字表）：Python · Apache-2.0 · 69★ · 周增 +0 · 最近提交 2026-11-02 · 主分类 engineering · 形态 app · 分类 trending · 成熟度 experimental · 待LLM分类：是 · 首次采集 2026-11-02。简介："Running a 30B MoE LLM on CPU at 30-50+ tok/s with a 256K Context Window via Hybrid Mamba-2 SSM, L3 NTA Slicing, AVX-512 VNNI Tile Repacking & 2MB HugePages"。
  • 与活文档脉络的关系：本件的可论证点不在性能数字（卡面完全没有数字），而在四个机制名同时出现这一组合本身。v3.70 §0 的第一条实质线索是"推理栈的最前线从服务端移到客户端"，而活文档历来记录的客户端/端侧样本（mafdet 是 CLI/桌面脚本、Mika 是手机端 agent）全部是"把服务端任务前移"的方向——本件是反向的一极：把一个本该在 GPU 上跑的 30B MoE 模型，压进 CPU，且用四个非常具体的 CPU 侧机制换来的：Mamba-2 SSM（线性注意力，规避注意力对上下文长度的二次增长）、L3 NTA Slicing（把权重按内存层级切分，配合 MoE 稀疏激活）、AVX-512 VNNI Tile Repacking（为 VNNI 指令集重排权重 tile）、2MB HugePages（减少 TLB miss）。 这四个机制名互相咬合得很紧：Mamba-2 让 256K 上下文在 CPU 上"可算"；NTA Slicing + Tile Repacking 让 MoE 的稀疏激活在 CPU 上"可取"（只搬用到的 expert 权重）；2MB HugePages 让大内存池"可寻址"。这构成一条"CPU 侧长上下文推理"的可论证技术链路，是活文档此前没有的一格。 ⚠️ 但必须严守证据边界：卡面没有任何 tok/s 实测、没有硬件型号、没有与 GPU 的对照、没有质量/精度损失说明。"30-50+ tok/s" 出现在项目自述的 README 简介里（卡面转述），属厂商/作者自述口径；"256K context"同样只是宣称，且 MoE + SSM 组合下 256K 的实际召回/质量影响完全未说明。本件不可作为"CPU 能跑 30B"的性能结论引用，只能作为"存在这条工程路线"的登记。
  • 建议归入：§0.5.1（新增行，⭐⭐（弱），标注"卡面级、自述口径、无任何实测数字、待 LLM 分类"）+ §0.5.9 脉络 L 补一注"CPU 侧长上下文是客户端预算的另一种形态：不是把等待藏起来，而是把负载降下来"（标注为假设性归位）；§3 / §4 今晚不建议据此立 C 或 O，仅在 §4 留一条"须核 README 与实测配置"。

增量 ⑤ xuiltul/animaworks ⭐（卡面级；"记忆会遗忘"这一命题在 llm-infra 轴尚无样本）

  • 来源：organized/repo_cards/4816-xuiltul-animaworks.md；https://github.com/xuiltul/animaworks
  • 要点（严格限于卡面）：Python · Apache-2.0 · 269★ · 周增 +0 · 最近提交 2026-11-02 · 主分类 agent · 形态 model · 分类 ai · 成熟度 experimental · 首次采集 2026-11-02。简介："Organization-as-Code for autonomous AI agents. Brain-inspired memory that grows, consolidates, and forgets. Multi-model (Claude/Codex/Gemini/Cursor/Ollama)."
  • 与活文档脉络的关系：v3.70 §0.5.9 脉络 N（可判定性五面谱系） 与 §5 趋势线"证据成为 agent 记忆的一等公民"都触及记忆；但活文档记录的样本（KiroCrew 的记忆/lesson 二分、paperclip 的 audit log、mafdet 的推理前置）没有一个把"遗忘 / 巩固（consolidation）"当作显式机制。本件的三个动词——grows / consolidates / forgets——恰好是记忆生命周期的完整三段，与 v3.70 承接的 arXiv:2610.35846 "Preserve to Expand"（source-aware 适配 + model merging 抑制遗忘） 在"遗忘该不该发生"这个问题上构成一对方向相反的样本：Preserve to Expand 说的是不要忘，animaworks 说的是要主动忘。 这是有价值的观点张力，但必须守住边界：本件只有卡面一句话简介，没有任何机制细节（如何决定遗忘什么？consolidation 的判据是什么？多模型如何分工——Claude/Codex/Gemini/Cursor/Ollama 是路由还是各司其职？）。本件不能支撑任何关于"记忆遗忘机制"的实质主张，只能作为"该命题在 llm-infra 轴有首个样本"登记。
  • 建议归入：§0.5.1（新增行，⭐（最低档），标注"卡面级、无机制细节"）+ §4 新增 1 条 O（"遗忘/巩固"的判据与多模型分工未知，须核 README）；§3 不予登记。

台账 B（不构成观点，仅口径记录）

  • ttoss/soat（organized/repo_cards/2102-ttoss-soat.md）：TypeScript · Apache-2.0 · 9★ · 周增 +1 · 最近提交 2026-11-01 · 主分类 agent · 形态 framework · 分类 skill · 成熟度 experimental · 首次采集 2026-08-16。简介仅一行"SOAT — open-source infrastructure for production-ready AI agents"，卡面中文写"旨在为自主 AI Agent 提供持久记忆能力"。判定：9★ / 零机制细节 / 无一手核实 / 与增量 ⑤ animaworks 主题重叠（都指向"agent 持久记忆"），且卡面中英文简介口径不一致（英文只说"生产级 AI agent 基础设施"，中文直接收窄为"持久记忆"）。今晚不作为独立增量，仅建议进 §6.99.5 URL 登记表；若要承认为一条记忆轴样本，须先核 README。
  • ozynautetu-create/FlowForge-Optima（organized/repo_cards/4815-ozynautetu-create-flowforge-optima.md）：HTML · 56★ · 周增 +0 · 最近提交 2026-11-02 · 主分类 engineering · 形态 app · 分类 ai · 成熟度 experimental · 待LLM分类：是 · 首次采集 2026-11-02。简介："AdalFlow Alternative 2026: Auto-Optimize LLM Apps Without Code"。判定：56★ / 零机制细节 / "AdalFlow Alternative" 是自述的对标关系、无任何对比证据 / 待 LLM 分类 / 主题实为 agent-optimization，与 llm-infra 边缘相关。本件不具备论证价值，今晚不建议登记为独立增量（仅可入 URL 登记表）。⚠️ 特别提示：若今晚见到"OraFlow / AdalFlow"等相近仓库名，务必逐字核对——本批未出现这些名字，勿凭印象补写。**

§2 值得警惕的矛盾 / 待核实说法

编号 内容 级别
D-新1 bifrost 的延迟数字三套并存：卡面英文"<200 µs @5k RPS"、卡面中文"<100 µs"、库内攻略引官方基准为 ~11 µs（t3.xlarge）/ 59 µs（t3.medium）。三者是不同测量口径/硬件/版本（网关自身开销 vs 端到端 vs 不同规模实例），不可混引；且攻略已明写"比 LiteLLM 快 50 倍"是官方宣称需验证。今晚若引用，必须带硬件型号 + 口径 + 出处（卡面 or 攻略）三件套。 ⚠⚬
D-新2 bifrost 的规模数字两套并存：卡面"10,000+ models"（英文简介）与"1000+ 模型"（卡面中文简介），攻略正文为"23+ 家 AI 提供商"。"模型数"与"供应商数"是不同量纲，且同一张卡的中英文简介自相矛盾（10,000+ vs 1,000+）。该卡本身不可作为规模数字的来源。 ⚠⚬
D-新3 arXiv:2604.17227 的卡内「可复用信息」段疑似串卡：内容为 KubeVirt / FinOps / GatewayAPI / "建议动作：关注；工程实践参考，非学术"，来自上游 jay/2026-06-10-database-cloudnative-backend.md（云原生数据库笔记），与本卡自称的"学术综述"（survey / 被引 4 / 主分类 llm-infra）自相矛盾。核实原文前不得引用该段的任何技术点。同类串卡风险在本轮 2026-11-01 简报的 DataEvolver 卡上已出现过（"双时态运算符代数 / TOKI"），说明 paper_card 的「可复用信息」段存在系统性串卡风险，建议今晚抽 2-3 张卡交叉核对。 ⚠⚬
D-新4 synchopate/nemotron-30b-cpu-256k 的"30-50+ tok/s @256K"是作者自述，卡面无硬件型号、无对照基线、无质量/精度损失说明、且标 待LLM分类：是。MoE + Mamba-2 SSM 在 256K 下的实际有效上下文长度与召回质量完全未知。"能跑"与"能用"是两件事。 ⚠
D-新5 ttoss/soat 卡面中英文口径不一致：英文"production-ready AI agents 基础设施" vs 中文"持久记忆能力"；9★ 且无一手核实。与 animaworks 构成同一记忆轴上的两个低证据样本，不足以支撑"记忆生命周期"任何主张。 ⚠
D-新6 FlowForge-Optima 自述为 "AdalFlow Alternative 2026"，无任何对比证据、56★、待 LLM 分类。"Alternative" 是自述定位，不是评测结论。 ⚠
D-新7 EvoDesign 本轮为纯元数据刷新（Stars 0→2→6、周增 +7、最近提交 2026-10-28 → 2026-11-02），论文正文（arXiv:2604.09568 / NeurIPS 2026 Poster / CanvasBench）已在 v3.69 承接完毕。本轮不产生任何新的技术主张，不得因"提交日期变了"当作新证据重写。 ⚠
D-新8 跨轴重复计数风险：本件 2604.17227 的来源文件是 jay 的 database/cloud-native 笔记，说明它在数据库/云原生轴可能已被承接过。今晚 llm-infra 侧不应把它写成"全库新发现"，只作 llm-infra 轴的正文承接。 ⚠

§3 可引用的 arXiv 号列表

本批清单内 paper_card 直接涉及（1 件）

  • arXiv:2604.17227 — Cloud-native and Distributed Systems for LLM：研究路线图（survey；被引 4 / S2；DOI 10.48550/arxiv.2604.17227；OpenAlex W7155070632；已入 llm-infra.md §6.99.2 arXiv 表 line 92，本轮首次正文承接 + URL 表候选 +2）

关联基线（活文档已立，本轮作为对照引用，非本批新增）

  • arXiv:2604.09568 — EvoDesign / EvoDiagram（NeurIPS 2026 Poster；CanvasBench；v3.69 已承接完毕，本轮仅仓库元数据刷新）
  • arXiv:2610.35846 — Preserve to Expand：Source-Aware Adaptation and Model Merging（与增量 ⑤ 的"主动遗忘"构成方向张力）
  • arXiv:2607.26627 — Revisiting Lossy Verification（引擎层有损校验，接增量 ① 网关护栏位）
  • arXiv:2609.15504 — Orthrus（BF16 下仅 45% 轨迹精确匹配 AR 基线）

近 3 天 paper_cards 抽查中带 llm-infra 标签、但不在本批清单内者（仅作棒位候选，按增量纪律不计入本轮 arXiv 累积）

  • arXiv:2603.07670 — Memory for Autonomous LLM Agents（⭐⭐⭐⭐⭐ 必读综述；被引 71；三维分类法：时间范围 / 表示基底 / 控制策略）→ 与增量 ⑤ animaworks 的"记忆三段"直接相关
  • arXiv:2602.21548 — DualPath：dual-path KV-Cache loading + storage-to-decode RDMA 路径（被引 22）→ 与增量 ① 网关/路由层相邻
  • arXiv:2609.19969 — DeepSeek-V4.1-Flash（MoE，552B backbone，1M token 上下文，主打 agentic workload 成本效率）→ 与增量 ① 的"模型数 / 成本"口径相关

§4 检查过的来源（清单制，未做全库扫描）

本批 8 份 manifest 材料（相对 /shared/research-kb/）

  1. organized/repo_cards/4818-synchopate-nemotron-30b-cpu-256k.md
  2. organized/repo_cards/4816-xuiltul-animaworks.md
  3. organized/repo_cards/4815-ozynautetu-create-flowforge-optima.md
  4. organized/repo_cards/4814-modelscope-ms-cookbook.md
  5. organized/repo_cards/4682-geminilight-evodesign.md
  6. organized/paper_cards/140-2604-17227.md
  7. organized/repo_cards/153-maximhq-bifrost.md
  8. organized/repo_cards/2102-ttoss-soat.md

活文档与索引

  • organized/knowledge/llm-infra.md（v3.70 · 2026-10-29 05:00）全文：§0 / §0.5.1 / §0.5.3 / §0.5.6 / §0.5.9 / §3 / §4 / §5 / §6.99.2 arXiv 表 / §6.99.5 URL 表 / 本次变更
  • organized/knowledge/ 全目录 grep（bifrost / maximhq / synchopate / animaworks / xuiltul / FlowForge / ozynautetu / ms-cookbook / ttoss / soat / EvoDesign / 2604.17227）
  • organized/queue/work-queue.md（2026-11-02 18:00 生成；待更新活文档 5 个，llm-infra 4 天未更新）
  • organized/guides/（1719 份）检索命中并实读：maximhq-bifrost.md（Jay, 2026-07-08）、modelscope-ms-cookbook.md（spark, 2026-11-02）

近 2 天他人 inbox（jay / tom / flyp / stephen 目录）

  • inbox/jay/2026-11-02T1735-blogs-discovery.md（投机解码 / CUDA Graphs 两条已核原文；Dynamo DEP #17649 / SGLang / AMD-AGI-Infera / loxilb-inference-gateway 5 条仅摘要线索）
  • inbox/jay/2026-11-02T1620-csdn-discovery.md、2026-11-02T0820-csdn-discovery.md
  • inbox/tom/2026-11-01-inference-e1prep.md（引擎层有损校验开关 · GLM-5.2 引擎版本下限 · llama.cpp CUDA 构建 —— 与本批 bifrost 的"引擎/网关版本约束"同族）
  • inbox/tom/2026-11-02-0900-hf-daily-2026-11-02.md（HF Daily 15 篇）
  • inbox/flyp/2026-11-02T1550-critical-read.md（OpenWAM 2609.07398）、2026-11-02T0950-critical-read.md
  • inbox/spark/2026-11-01-llm-infra-e1prep.md（本轴上一轮，用于增量去重与脉络衔接）

近 3 天 paper_cards 抽查

  • organized/paper_cards/ 按 mtime 取近 3 天被刷新卡 + llm-infra 标签过滤；逐张核命中：142-2603-07670.md、139-2602-21548.md、140-2604-17227.md、1417-2609-19969.md、1425-2609-20511.md（length inflation in OPD）、1420-2609-20612.md（AMPLE-Math）、1403-2609-18708.md（Value Flattening）
  • review/flyP-on-Jay-2026-09-04.md（核对 2604.17227 的历史入册语境与"arXiv id 主键需标版本号"的旧结论）

§5 今晚棒位建议（不改活文档，仅供今晚接力参考）

  1. 优先处理增量 ① bifrost（唯一 production 级 + 攻略 + 双源）——它能一次性给活文档补上"企业级 AI 网关 = 治理层中间件"这一整格，并给 C392/脉络 O 补上正向对偶。
  2. 其次增量 ② ms-cookbook——把活文档从"机制清单"扩出"路径清单"，并用"先评再选"给评测轴与推理轴接上接口。
  3. 增量 ③ 2604.17227 需先取原文再决定是否升级为框架；若今晚来不及核原文，只做 URL 表 +2 与"已入册未承接"登记，不要写结论。
  4. 增量 ④⑤ 与台账 B 两件（soat / FlowForge-Optima）本轮证据不足以立 C，建议今晚只在 §0.5.1 留低档行 + §4 留待核项。
  5. D-新3 的串卡问题建议单独处理：今晚顺手抽 2–3 张 paper_card 交叉核对「可复用信息」段，若确认系统性串卡，应作为卡片管线缺陷上报，而不是逐条在正文里打补丁。