DeepSeek V4.1集成llama.cpp：审查点名空白PR与崩溃风险

一份 DeepSeek V4.1 集成 PR 提交到了 llama.cpp。代码审查列了一长串问题，从提交流程到运行时安全都有。

最先让人皱眉的是 PR 描述：空白。没有概述，没有关联 issue 或讨论，模板里的 AI 使用披露栏也没填。

代码层面有两个崩溃相关风险。mtmd-image.cpp 的 plan_grid 末尾有一个 GGML_ASSERT，它拿调用方提供的图像尺寸做校验。精心构造的尺寸可以让进程在服务器上中止。状态恢复路径也有问题。类型检查用了 GGML_ASSERT，同一条路径上其他失败抛的都是 std::runtime_error。项目约定在这处没被遵守。

模型保存器漏写了新的 LLM_KV_HYPER_CONNECTION_SINGLE_PASS 键。V4.1 的 DSpark 草稿模型经过保存再加载，可能被静默分发到 graph_dsv4 分支。但保存后的文件里没有这个分支需要的 hc_head 张量，加载时有出错风险。

两个参数把边界定得很紧。LLAMA_MAX_PLE_NGRAM 锁定为 8，LLAMA_MAX_PLE_HEADS 锁定为 64。两个上限约束所有 Engram 模块总数。DeepSeek-V4.1-Flash-1017 的配置是否放得下，还没有确认。DEEPSEEK41 也没进“始终为 lightning indexers 创建 Hadamard 旋转”的名单。如果相关尺寸相等，量化 KV 会失去 V4 已有的那层不相关旋转。在 -ctk q8_0 下，质量可能下降。审查没有说明这是有意为之，还是遗漏。

两处改动会波及所有模型。set_embeddings 现在每次切换嵌入都会把 sched_need_reserve 设成 true，非池化上下文也一样。频繁切换时，这个 reserve 动作会反复发生。softplus 改成 log1pf(expf(x)) 后，现有 ggml op 的数值对所有模型都有微小变化。它更精确，各后端也一致。

也有站得住的改动。Engram 的 GGUF 元数据在使用前被完整限制，token_map 构造得再恶意，主机端哈希也产生不了越界行 ID。im2col 内核视图步幅的修复正确，CUDA 路径因此解锁。V4 的状态 IO 格式原样保留，旧状态文件依然兼容。dsv41_shared_history_ok 会拒绝共享 token 但 n-gram 历史不一致的批次，并给出明确错误。它不会静默生成错误哈希。

剩下的是小问题堆叠。V4.1 的检测字符串“｜DSML｜ calls>”重复出现在三处，应该提成共享常量。common_chat_msg 的相等性比较漏了新的 extra_json 字段。靠消息相等性的测试，抓不到这类回归。reasoning_effort 的注释写着“medium -> default”，代码实际写的是 JSON null。转换器里 set_gguf_parameters 用裸 assert，同一文件其他地方抛 ValueError。大端主机在字节交换中途抛 NotImplementedError，会留下半截损坏文件。

最需要留意的是测试覆盖。两条完整注意力路径由 LLAMA_DSV41_SPARSE 选择。默认 ON 走优化后的 gather 路径；密集参考路径只能靠环境变量打开。CI 只跑默认那条。V4.1 的 lightning-indexer 缓存和压缩器状态，仍按零层创建并记录。每个批次还在构建 lid 计划和输入，但 V4.1 图从不使用。切到密集路径的部署，等于拿一条合入前从未被测过的路径在跑。