昨天 · 5月16日 周六

1 条

论文速递·1 天前

δ-mem 提出在线记忆机制，让 LLM 长上下文推理效率提升 3 倍

大模型在处理超长上下文时，KV cache 随序列长度线性增长，导致推理延迟和显存开销急剧上升。δ-mem 提出一种在线记忆机制，将历史上下文压缩为可更新的记忆状态，仅在需要时从记忆中检索相关信息，从而避免全量 KV cache 的存储与计算。实验表明，在 128K 上下文长度下，δ-mem 将推理延迟降低约 3 倍，显存占用减少 60% 以上，同时保持与全注意力基线相当的任务准确率。

›1 条相关源

5月15日 周五

2 条

推理引擎·1 天前

Orthrus 冻结主干网实现 7.8× 加速，输出分布与 Qwen3 完全一致

Orthrus 提出一种扩散注意力模块，注入冻结的 Qwen3-8B 自回归 Transformer 每层，实现最高 7.8× tokens/forward 加速。核心思路：扩散头并行投影 K=32 个 token，AR 头二次验证并接受最长匹配前缀，两路共享同一 KV cache。仅训练 16% 参数、<1B token、8×H200 上 24 小时。与 EAGLE-3、DFlash 等推测解码方案相比，无需外部草稿模型、无需独立 KV cache、零 TTFT 惩罚；KV 开销仅约 4.5 MiB。MATH-500 上接受长度 11.7 vs DFlash 7.9 vs EAGLE-3 3.5。单步去噪优于多步，KL 蒸馏优于 CE。局限：受限于冻结基座模型能力，仅 Qwen3 评估，仅支持贪心+拒绝采样。

›1 条相关源

推理引擎·2 天前

本地实测 Qwen 3.6 MTP：35B MoE 模型 300K 上下文仅用 28GB VRAM

Reddit 用户使用 unsloth 发布的 Qwen3.6-35B-A3B-UD-Q5_K_S（MTP 版）在本地进行多轮长上下文测试，构建 Pygame 迷宫游戏。在 32GB RDNA 4 显卡上，35B MoE 模型在 Q4_0 量化下达到 300K 上下文，VRAM 占用 28.3GB，仍有空间扩展到 400K。用户实测 MTP 版本在 27B 稠密模型上带来约 1.5 倍 tokens/s 加速，但 35B MoE 版本仅提升不到 10%。测试中 MoE 模型在 200K 附近出现稳定性问题，切换至 Q8_0 量化的 27B 模型后解决。MTP 推理需使用 llama.cpp 的 MTP 原型 Docker 镜像（haven oammo/llama:vulkan-server），后端为 Vulkan。

›1 条相关源

5月14日 周四

1 条

推理引擎·2 天前

vLLM 发布 TurboQuant 全面评测：FP8 仍是 KV Cache 量化最佳默认方案

vLLM 官方博客对 TurboQuant 系列 KV Cache 量化方法进行了首次全面评测。核心结论：FP8（--kv-cache-dtype fp8）依然是生产环境的最佳默认选择，提供 2 倍 KV Cache 容量且精度损失可忽略，在内存受限场景下性能显著优于 BF16。TurboQuant k8v4 相比 FP8 无明显优势，仅将容量提升至 2.4 倍但带来吞吐和延迟的持续下降。4bit-nc 变体在边缘部署等内存极度受限场景下有一定实用价值，但需付出精度、延迟和吞吐的折中。k3v4-nc 和 3bit-nc 在推理和超长上下文任务上精度下降明显，同时严重劣化延迟和吞吐，不适合生产部署。

›1 条相关源

5月10日 周日

3 条

推理引擎·6 天前

8GB显存跑190K上下文：Qwen3.6-35B-A3B + llama.cpp TurboQuant 实测

用户在一台搭载 RTX 4060 8GB 显存、32GB DDR5 内存的笔记本上，通过 llama.cpp TurboQuant 分支成功运行 Qwen3.6-35B-A3B（MoE 架构，35B 参数，每 token 激活 3B）的 Q5 量化版，实现约 37–51 tok/s 的推理速度，上下文窗口达到约 190K。关键技术配置包括：--n-gpu-layers 430 将大部分层卸载到 GPU，--n-cpu-moe 35 将 MoE 专家放在 CPU 上以节省显存，--cache-type-k/v "turbo4" 启用 TurboQuant 的 4-bit KV cache 量化，以及 --flash-attn on 降低显存占用。该方案通过 Tailscale 将笔记本作为局域网推理服务器使用。

›1 条相关源

推理引擎·7 天前

vLLM v0.20.2 发布：修复 DeepSeek V4 稀疏注意力与 KV 缓存分配

vLLM 发布 v0.20.2 小版本补丁，包含 6 个提交，主要修复三个问题：DeepSeek V4 稀疏注意力在 Hopper 架构上的持久 topk 路径，修复 MTP=1 场景下的挂起问题；V1 引擎 KV 缓存管理器中的 KV 块分配失败错误；Qwen3-VL 在高负载下的 deepstack 边界检查失效。此外还修复了 gpt-oss MXFP4 在 torch.compile 下的 hidden_dim_unpadded 传递问题。无破坏性变更。

›1 条相关源

推理引擎·7 天前

NVIDIA 发布 Star Elastic：一个检查点内含 30B/23B/12B 三模型，零样本切片推理

NVIDIA 发布 Star Elastic，一种后训练方法应用于 Nemotron Nano v3，将 30B 参数的主检查点嵌套为 23B 和 12B 子模型，三者共存于同一检查点（支持 BF16/FP8/NVFP4）。核心技术是 Gumbel-Softmax 可学习路由器，将任意目标参数预算映射到最优嵌套配置，覆盖注意力头、Mamba SSM 头、MoE 专家、FFN 通道和嵌入维度等弹性轴。组件重要性排序在训练前计算完成。推理策略上，可将 23B 子模型分配给思考阶段、30B 完整模型用于最终回答，实现"小模型思考、大模型作答"的流水线。KV cache 在三模型间共享，支持推理速度的滑动调节。

›1 条相关源

5月9日 周六

1 条

推理引擎·7 天前

llama.cpp MTP 让 12GB 显存跑 35B MoE 达 80 tok/s

Reddit 用户分享在 12GB 显存的 RTX 4070 Super 上，通过 llama.cpp 的 MTP（Multi-Token Prediction）分支配合 Qwen3.6-35B-A3B-MTP GGUF 模型，实现了 80+ tok/s 的生成速度与 80%+ 的草稿接受率，上下文窗口达 128K。关键参数 -fitt 1536 用于平衡 GPU/CPU 负载，为 MTP 草稿模型和 KV cache 预留显存。该 MTP 功能尚未合入 llama.cpp 主线，需从源码编译并应用 draft PR。

›1 条相关源

5月6日 周三

1 条

推理引擎·10 天前

vLLM V0到V1重构：RL训练前先保证推理正确性

ServiceNow AI 团队在 Hugging Face 博客发文，详细介绍了 vLLM 从 V0 到 V1 的重构历程。核心思路是：在引入强化学习（RL）等复杂功能之前，先确保推理引擎的正确性。团队重写了调度器、KV cache 管理和 PagedAttention 实现，修复了 V0 中因历史原因积累的多处正确性 bug。V1 版本将调度与执行解耦，统一了 block 管理策略，并引入了更严格的正确性测试套件。文章强调，对生产级推理引擎而言，"正确性优先于功能迭代"是基本原则。

›1 条相关源

5月5日 周二

1 条

工具发布·11 天前

Transformers v5.8.0 发布：原生支持 DeepSeek-V4 与 Gemma 4 投机解码

HuggingFace Transformers 发布 v5.8.0，主要新增 DeepSeek-V4 和 Gemma 4 Assistant 两个模型架构。DeepSeek-V4 是 DeepSeek 的新一代 MoE 模型，架构上弃用 MLA 改用混合局部+长程注意力，将残差连接替换为流形约束超连接（mHC），并在前几层 MoE 使用静态 token-id→expert-id 哈希表做引导。Gemma 4 Assistant 是一个纯文本小模型，专为 Gemma 4 做投机解码（MTP 方法），全模型共享 KV cache，跳过预填充阶段，并引入交叉注意力以利用目标模型的上下文。该版本无已知破坏性变更。

›1 条相关源

5月4日 周一

1 条

大模型·12 天前

Google 四月 AI 更新：Gemma 3.1 与 Gemini 2.5 多项升级

Google 在 2026 年 4 月发布多项 AI 产品更新。Gemma 3.1 开源模型新增 4B 和 12B 两种尺寸，支持 128K 上下文窗口，采用后训练优化提升指令遵循能力。Gemini 2.5 Flash 模型在推理成本降低的同时提升了代码生成与多模态理解能力。此外，Google 推出 AI 安全框架 Secure AI Framework (SAIF) 的更新版本，并开源了部分安全评估工具。

›1 条相关源

4月27日 周一

1 条

推理引擎·19 天前

vLLM v0.20.0 发布：DeepSeek V4 支持、CUDA 13 默认、PyTorch 2.11 升级

vLLM 发布 v0.20.0 版本，包含 752 次提交、320 位贡献者。核心变更：首次支持 DeepSeek V4 推理，修复 DSV4/3.2 的 DSML token 泄露问题；默认 CUDA 版本升级至 13.0（跟随 PyTorch 2.11.0），PyTorch 底座同步升级至 2.11，属于环境依赖的 breaking change；新增 Python 3.14 支持；兼容 HuggingFace transformers>=v5。推理引擎方面：FlashAttention 4 重新成为 MLA prefill 默认后端（支持 head-dim 512 及 SM90+ 上的 paged-KV）；TurboQuant 2-bit KV cache 新 attention 后端上线，实现 4 倍容量压缩；新增端到端在线量化前端。新模型支持包括 Hunyuan v3 预览版、Granite 4.1 Vision 多模态模型。

›1 条相关源

4月16日 周四

1 条

推理引擎·2026/4/16

Ollama v0.21.0 发布：Hermes 学习型 Agent 与 Gemma 4 MLX 支持

Ollama 发布 v0.21.0，核心亮点是 Hermes Agent——一个能根据用户工作流自动学习并创建技能的本地 Agent，通过 ollama launch hermes 即可启动。技术层面，新增 Gemma 4 在 Apple Silicon 上的 MLX 运行时支持，包含混合精度量化、Conv2d/Pad/RoPE 等算子封装；ollama launch 集成 Hermes 和 GitHub Copilot CLI，OpenCode 改为内联配置，且当模型列表未变化时不再重写配置文件。修复了 Gemma 4 Metal 编译错误、macOS 交叉编译触发 generate 的问题，以及 openclaw --yes 跳过频道配置的 bug。

›2 条相关源