llama.cpp 0.6.0：新增混合批处理 API，但保存的会话会失效

llama.cpp 发布 0.6.0，本地推理方向有几个实打实的更新，同时带来一个必须提前知道的兼容性问题。

llama_batch_ext 支持混合输入 新 API 允许在同一个 batch 里同时放 embedding 向量和文本 token。这对 paligemma 这类非因果 prompt 的模型是刚需。

不能处理混合 batch 的模型会在内部用 llm_arch_supports_mixed_batch 拦住并返回错误，不会默默算错。这个设计是对的——静默产生错误结果比直接报错难查十倍。目前 mtmd 的处理还没跟上。

服务端多模态 server 现在接受带类型的视觉、音频、视频输入用于 embedding，并报告模型的输入和输出模态。注意这是能力上报，应用层还是要自己做媒体类型、大小、模型能力的校验，不能假设所有模型接受同样的输入。

性能相关

• CUDA 内核对 lightning indexer 做了分块，优化低 head 数场景。
• Metal 侧新增 2 到 16 行 src1 的矩阵乘内核与批量拷贝，专门服务投机解码。在 M1 到 M4 上没有 tensor API，原来 2 到 16 行的场景走的是 mat-vec 内核，代价随行数增长——在 M3 Ultra 上甚至出现过投机解码比串行还慢的情况。
• 日志系统重写，颜色自包含，router 的颜色设置会传给子进程。

升级前必须知道的坑 0.6.0 改了会话格式，升级后之前保存的 session 文件加载不了。如果你有依赖会话持久化（长对话断点续跑、预热缓存）的服务，升级前先确认有没有恢复路径，或者直接规划成一次性失效重建。

另外近期还有 Vulkan Flash Attention 的越界写入修复。这些都说明一件事：模型能加载成功 ≠ 部署是安全的。引擎升级要和应用发布走同一套变更管理流程。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

混合 batch 对非因果 prompt 是刚需，不支持的模型内部拦住也比静默算错强。会话格式变更这条要提前预警，依赖 session 持久化的服务得准备重建方案。

混合 batch 这个 API 看着小众，实际是给非因果 prompt 的模型补短板，以前 embedding 和 token 得拆两次调用，延迟翻倍。用 llm_arch_supports_mixed_batch 显式报错而不是静默算错，这个取舍我认同。可惜老会话失效只能重建缓存。

不支持就返回错误而不是默默算错，这个处理很负责任。混合批处理对多模态输入确实是刚需，之前要拆成两个 batch 再拼结果，延迟白白翻倍。会话格式失效这条得提前通知团队，我们吃过亏，升级后历史会话全读不出来，建议过渡期先把旧会话导出备份一份。