Efficient LLM Inference 与 Serving:KV Cache、Speculative Decoding、PagedAttention 和量化

科研时间管理工具包:4篇论文深度精读法 在AI领域日均新增百余篇论文的信息过载时代,如何高效筛选、深度消化并转化前沿成果成为研究者核心能力。基于工作记忆容量与认知负荷理论,'4篇精读法'通过硬性数量约束倒逼高质量信息处理,融合文献筛选、三维评估、五维解剖与三色笔记等工程化方法,将泛读幻觉转化为可执行技术动作。该方法不仅适用于研究生建立判断锚点,也支撑工程师快速评估大模型推理优化、LoRA微调、FlashAttention变体等热点方向的落地可行性,已在真实工业场景中验证其对A10显存受限环境下的LLM部署加速价值。 阅读详情

Efficient LLM Inference 与 Serving:KV Cache、Speculative Decoding、PagedAttention 和量化

在这里插入图片描述

系列:AI 论文盘点 / 技术趋势
日期:2026-07-04
适合读者:研究生、LLM 系统研究者、推理平台与 AI 应用工程师

摘要

2025-2026 年,LLM 系统的主战场正在从“如何训练更大的模型”转向“如何把模型又快又便宜地服务给真实用户”。原因很直接:推理不是一次性成本,而是每个请求、每个 token、每次 agent 工具调用都会持续发生的成本。尤其在长上下文、推理型模型、多轮对话和代码 agent 场景里,瓶颈往往不再是单次矩阵乘法,而是 KV cache 内存、prefill/decode 阶段干扰、请求调度、低 batch 延迟、量化误差、GPU 内核与网络传输共同组成的系统问题。

这篇文章按系统栈梳理 Efficient LLM Inference 与 Serving 的技术路线:PagedAttention 和 vLLM 如何把 KV cache 当作操作系统式分页资源管理;SGLang 的 RadixAttention、vLLM Automatic Prefix Caching 和 Mooncake 的 KVCache-centric 架构如何把“重复上下文”变成可复用资产;speculative decoding、Medusa、EAGLE-3 与 TensorRT-LLM 的工程支持如何把串行 decode 改写成 draft-and-verify;KIVI、QServe、TurboQuant 与 TensorRT-LLM 量化路线如何把低比特从权重扩展到 KV cache;FlashAttention-3 与 FlashInfer 则说明,内核层优化仍然是服务系统的底座。

目录

  1. 研究背景:推理为什么成为 AI 基础设施瓶颈
  2. 近一年路线图:从单机加速到分层 serving 架构
  3. 代表论文分组解读
  4. 方法对比表
  5. 关键技术趋势
  6. 工程落地启发
  7. 局限与争议
  8. 接下来值得关注的问题
  9. 总结
  10. 参考资料

研究背景:推理为什么成为 AI 基础设施瓶颈

Transformer 训练时代的核心指标是吞吐、并行效率和训练稳定性;推理时代的核心指标变成了 TTFT(time to first token)、TPOT / ITL(每个输出 token 的延迟)、吞吐、SLO 达标率、显存占用和单位 token 成本。更麻烦的是,这些指标经常互相牵制:增大 batch 能提升吞吐,却可能拉高首 token 延迟;激进量化能降低显存,却可能引入额外反量化开销;长上下文提升能力,却会让 KV cache 线性膨胀。

生成式 LLM 推理有两个阶段。prefill 阶段处理 prompt,通常计算密集、可并行;decode 阶段逐 token 生成,常常受内存带宽、KV cache 读取和串行依赖限制。短问答服务可能主要卡在 decode;RAG、长文档问答和代码仓库 agent 则常常卡在长 prompt prefill 与重复上下文复用。服务系统的难点就在于:不同请求长度、输出长度、采样策略、LoRA adapter、多模态输入、结构化输出和 agent 调用链会混在同一个集群里。

经典的 FlashAttention 把注意力优化带到 IO-aware 层面:不要只看 FLOPs,要看 HBM 与 SRAM 之间读写多少。PagedAttention 进一步把 serving 的核心问题落到 KV cache 管理:KV cache 会随请求动态增长,如果按最大长度预留连续显存,碎片和浪费会直接压低 batch size。到了 2025-2026 年,系统开始更明确地把推理平台视为一个“内存、调度、内核、网络和缓存”共同优化的问题。

在这里插入图片描述

近一年路线图

第一条线:KV cache 从副产品变成一等资源。
PagedAttention 让 KV cache 可以按块分页、共享和按需分配;vLLM 的 Automatic Prefix Caching 把共享前缀的 KV cache 复用工程化;SGLang 的 RadixAttention 针对结构化 prompt、多轮对话和程序化 generation 复用前缀;Mooncake 则把 KV cache 放到架构中心,用 CPU DRAM、SSD 和独立 cache 层来服务超长上下文与过载场景。

第二条线:prefill/decode 逐步解耦。
DistServe、Splitwise、Mooncake 和 TensorRT-LLM/vLLM 的 disaggregated serving 示例都指向同一个判断:prefill 与 decode 的资源画像不同,强行 colocate 会导致干扰。2025 年以后的工作进一步探索单 GPU 内部的 prefill/decode 分区、跨节点 KV 传输和 stage-aware scheduling。

第三条线:decode 串行瓶颈用投机和多 token 预测缓解。
Speculative decoding 的核心是“便宜模型先猜,目标模型批量验证”。Medusa 不维护独立 draft model,而是在目标模型上加多头;EAGLE 系列从 feature-level draft 走向 EAGLE-3 的 token prediction 与多层特征融合。TensorRT-LLM 文档到 2026 年已经列出 DraftTarget、Eagle3、NGram、MTP、PARD、DFlash、SA 等多种 speculative decoding 选项,说明它已经从论文技巧变成 serving 框架标配。

第四条线:量化从权重走向端到端 serving。
GPTQ、AWQ、SmoothQuant 等早期路线主要聚焦权重和激活;KIVI 把 2-bit 非对称量化用于 KV cache;QServe 用 W4A8KV4 做算法-系统协同;TensorRT-LLM 支持 FP8、FP4、AWQ/GPTQ 和 FP8/NVFP4 KV cache;2025-2026 的 TurboQuant、KVTC、GPU-accelerated INT8 KV cache 等工作继续把长上下文推理的瓶颈指向 KV cache 压缩。

第五条线:内核库成为 serving 框架竞争力。
FlashAttention-3 面向 Hopper GPU 的异步、TMA、FP8 注意力优化;FlashInfer 则把可组合 attention template、JIT、block-sparse KV 格式和负载均衡调度做成 LLM serving kernel engine,并已被 vLLM、SGLang、MLC-Engine 等集成。推理服务的上层 API 越像云服务,底层就越依赖内核细节。

代表论文分组解读

1. PagedAttention 与 KV cache 内存管理

vLLM / PagedAttention 的贡献不只是“快”,而是重新定义了 serving 内存管理接口。传统实现往往给每个请求预留连续 KV cache 区域,长短请求混合时会产生大量内部和外部碎片。PagedAttention 借鉴虚拟内存,把每个序列的 KV cache 拆成固定大小块,用 block table 做逻辑块到物理块的映射。这样一来,请求不必占用连续物理显存,生成过程中可以按需追加块;共享 prompt、parallel sampling 和 beam search 也可以通过块共享和 copy-on-write 减少重复。

这条线的工程启发是:长上下文 serving 首先是内存系统问题。一个模型是否“能跑满 GPU”,不只取决于 GEMM 吞吐,还取决于调度器能否把更多活跃请求装进显存。vLLM 文档中的 Automatic Prefix Caching 进一步把复用从论文实验带到常见场景:同一长文档被多次查询、多轮聊天复用历史前缀时,新的请求可以跳过共享 prefix 的 prefill 计算。但 APC 也有边界:它主要减少 prefill,不会缩短长回答的 decode。

2. 结构化生成与 prefix 复用

SGLang 的角度更偏“LLM 程序”。当应用不再是一次 prompt 一次 completion,而是包含检索、分支、并行调用、JSON 约束、多轮自洽和 agent 控制流时,系统需要知道哪些上下文可以复用、哪些生成步骤可以并行。SGLang 论文提出前端语言和后端 runtime,后端的 RadixAttention 用 radix tree 管理可共享前缀,减少重复 KV cache 与重复计算。它尤其适合 few-shot、RAG、多轮对话和结构化输出这类共享 prefix 明显的 workload。

这也解释了为什么 2025-2026 年的 serving 框架不再只是“模型加载器”。它们越来越像数据库执行引擎:要理解请求结构、缓存中间状态、调度不同阶段,并在一致性、延迟和吞吐之间做优化。

3. Prefill / Decode 解耦与 disaggregated serving

DistServe 明确提出把 prefill 和 decode 放到不同 GPU 池中,以减少两阶段干扰,并分别优化 TTFT 与 TPOT。Mooncake 进一步把 KV cache 放在架构中心:在 GPU 集群之外利用 CPU DRAM、SSD 和 cache scheduler,目标是支撑 Kimi 这类长上下文聊天服务。TensorRT-LLM 和 vLLM 最新文档也都把 disaggregated serving、KV cache connector、KV offloading 等能力列为重要工程接口。

这里的关键不是“所有场景都应该拆分”,而是拆分让资源规划更精细。短 prompt、长输出的聊天流量可能需要强 decode 池;长文档问答则需要强 prefill 与 cache 复用;agent 工作流还会产生 bursty、可中断、共享上下文的请求。未来的 serving 平台很可能按 workload 动态选择 colocated、chunked prefill、disaggregated prefill/decode、KV offload 或 cache transfer。

4. Speculative decoding:把串行 decode 改成草稿与验证

Leviathan 等人的 speculative decoding 和 DeepMind 的 speculative sampling 都利用一个事实:目标模型一次验证多个候选 token 的代价,常常接近验证一个 token;如果便宜 draft model 能猜中多个 token,就能减少目标模型串行 forward 次数。理论上,带拒绝采样的版本可以保持目标模型采样分布不变。

后续方法开始解决“draft 从哪里来”。Medusa 在模型上加多个解码头,避免维护单独小模型;EAGLE 系列用目标模型内部特征或多层特征构建高接受率 draft;EAGLE-3 在 2025 年报告了对聊天和 reasoning 模型更强的加速效果。TensorRT-LLM 到 2026 年的文档已经把 EAGLE 3、NGram、MTP、Suffix Automaton 等作为可配置选项。这说明 speculative decoding 的工程问题已经从“能否加速”转为“什么 workload、什么 batch size、什么 acceptance rate 下值得启用”。

5. 量化:从模型文件压缩到 serving 协同

低比特量化最容易被误解成“把模型变小”。在 serving 中,更重要的是它改变了内存带宽、cache 容量、反量化开销和 kernel 形态。QServe 的 W4A8KV4 很典型:它不仅提出 4-bit weight、8-bit activation、4-bit KV cache 的 QoQ 算法,还配套实现 QServe runtime,强调低比特如果让 CUDA core 上的反量化变慢,理论压缩不一定转化成吞吐提升。

KV cache 量化尤其重要。KIVI 观察 key cache 与 value cache 的分布不同,分别采用 per-channel 与 per-token 策略,提出 tuning-free 2-bit KV cache 量化。2025-2026 年的 TurboQuant、KVTC、eOptShrinkQ、Fast-TurboQuant 和 GPU-accelerated INT8 KV cache 工作继续沿着“长上下文内存瓶颈”推进。需要注意的是,2026 年的新论文与厂商博客中有些指标仍需按具体硬件、模型、上下文长度和 workload 人工复测,不能直接当成通用 SOTA。

6. 内核与编译:FlashAttention-3、FlashInfer 与硬件协同

FlashAttention 的核心思想是 IO-aware exact attention:通过 tiling 降低 HBM 读写,而不是只优化算子 FLOPs。FlashAttention-3 面向 Hopper GPU,利用 Tensor Core 与 TMA 的异步能力、warp specialization、FP8 等硬件特性,说明 attention kernel 会随着硬件代际持续重写。FlashInfer 则把注意力内核做成 serving-oriented engine,支持多种 KV cache 格式、JIT template 和负载均衡调度。

对工程团队来说,这意味着“换一个 serving 框架”不只是 API 迁移,还可能改变 kernel 后端、CUDAGraph 策略、batch invariance、量化 recipe 和可观测指标。推理性能调优必须用真实请求分布压测,不能只看单条样例或固定长度 benchmark。

方法对比表

方向代表工作 / 系统主要解决的问题适合场景主要风险
Paged KV cachePagedAttention / vLLMKV cache 碎片、动态增长、共享前缀多租户 serving、长上下文、beam/parallel samplingkernel 与内存管理复杂度上升
Prefix reusevLLM APC、SGLang RadixAttention重复 prompt / 历史上下文重复计算RAG、多轮对话、few-shot、agent 程序对共享前缀敏感,长输出收益有限
Prefill/decode 解耦DistServe、Mooncake、TensorRT-LLM/vLLM disaggregated servingprefill 与 decode 干扰、SLO 拆分长上下文、混合流量、大规模集群KV 传输、调度和容量规划复杂
Speculative decodingLeviathan、Speculative Sampling、Medusa、EAGLE-3decode 串行步数多、低 batch 延迟高低 batch、短到中等输出、draft 接受率高draft 维护成本、接受率波动、batch 大时收益下降
KV / weight 量化KIVI、QServe、TensorRT-LLM FP8/NVFP4、TurboQuant显存和带宽瓶颈长上下文、高并发、边缘或成本敏感部署精度、反量化开销、硬件支持差异
Attention kernelFlashAttention-3、FlashInferHBM 读写、kernel 调度、硬件利用率Hopper/Blackwell 等新 GPU、长上下文依赖硬件与框架集成,复现实验门槛高

关键技术趋势

趋势一:KV cache 会成为推理系统的“数据层”。
未来 serving 不只是加载权重和跑 forward,而是管理可复用 KV、可压缩 KV、可迁移 KV、可过期 KV。长上下文 agent、代码仓库问答和多轮工作流越普及,KV cache 的生命周期管理越像数据库缓存和存储系统。

趋势二:调度器从 batch scheduler 变成 SLO scheduler。
连续 batching 只是起点。系统需要同时看 TTFT、TPOT、输出长度预测、prefix 命中率、GPU 显存水位、KV 传输成本、租户优先级和拒绝策略。Mooncake 的 early rejection、DistServe 的 goodput 优化、Nexus 的 intra-GPU 分区都说明,serving 研究正在从平均吞吐转向尾延迟和 SLO。

趋势三:投机解码会和模型训练共同设计。
早期 speculative decoding 可以外挂小模型;现在 EAGLE-3、MTP、Medusa 等方法暗示,模型可能在训练或 post-training 阶段就为多 token 预测、draft head 或验证路径预留结构。推理系统和模型结构会更强耦合。

趋势四:低比特不是单点算法,而是系统协同。
权重量化、激活量化、KV cache 量化、FP8/FP4 kernel、反量化 fusion、scheduler batch size 都会影响最终收益。只报告 perplexity 或压缩率不够,必须报告端到端 TTFT、TPOT、吞吐和成本。

趋势五:开源 serving 框架会继续向生产栈靠拢。
vLLM、SGLang、TensorRT-LLM、llama.cpp、TGI、MLC 等生态不再只拼单机速度,还会拼 OpenAI-compatible API、Kubernetes 部署、metrics、KV connector、LoRA serving、structured output、reasoning parser 和多硬件后端。

工程落地启发

第一,先做 workload 画像,再选优化。至少要统计输入长度、输出长度、并发、共享前缀比例、流式比例、工具调用链长度和 SLO。没有这些数据,讨论 PagedAttention、spec decoding 或量化都是盲调。

第二,把 TTFT 和 TPOT 分开看。长文档问答的用户可能最敏感 TTFT;代码生成和长回答更敏感 TPOT;agent 内部调用可能更在意总完成时间和并发成本。不同指标会导向不同系统方案。

第三,KV cache 预算要独立规划。不要只问“模型权重占多少显存”。在长上下文和高并发下,KV cache 可能超过权重成为主要显存占用;prefix caching、KV offload、KV quantization 和 cache eviction 需要一起设计。

第四,speculative decoding 需要在线开关和回退。它不是普遍加速器:低 batch、draft 接受率高、目标模型验证效率高时收益明显;大 batch、长复杂推理、draft 与目标分布不匹配时可能退化。生产系统应按模型、请求类型和 batch 状态动态启用。

第五,量化必须端到端压测。权重 4-bit 不等于吞吐翻倍,KV 4-bit 也不等于无损。要同时测任务质量、长上下文召回、结构化输出稳定性、工具调用 JSON 合法率、反量化开销和硬件兼容性。

第六,保留可观测性。至少记录 prefill tokens/s、decode tokens/s、KV cache hit rate、prefix cache 命中、GPU 显存碎片、queueing delay、spec acceptance rate、rejected tokens、per-tenant SLO 和 OOM/eviction 事件。

局限与争议

第一,很多论文指标依赖特定模型、硬件和 workload。比如 EAGLE-3 的加速、QServe 的吞吐提升、TurboQuant 的压缩收益,都不能无条件迁移到私有模型、不同 GPU 或 agent 流量。

第二,系统复杂度正在快速上升。Paged KV、disaggregated serving、KV offload、speculation、量化和多后端部署叠加后,debug 难度会显著增加。一次性能回退可能来自调度、网络、cache 命中、kernel fallback 或 tokenizer 不一致。

第三,质量评估仍不充分。低比特和投机方法常用 perplexity、MMLU、LongBench 或局部任务验证,但生产应用还关心格式稳定、拒答边界、工具参数正确性和多轮一致性。这些指标很少在系统论文中完整覆盖。

第四,生态版本变化快。vLLM、SGLang、TensorRT-LLM 的 feature matrix、支持模型、量化 recipe 和 speculative decoding 实现都在快速演进。本文中涉及 2026 年文档和新闻的部分,建议在部署前以项目最新 release notes 与本地 benchmark 复核。

接下来值得关注的问题

  1. KV cache 会不会形成标准化接口?如果 vLLM、TensorRT-LLM、SGLang、LMCache、Mooncake connector 能互通,推理平台会更像可组合存储系统。
  2. 推理型模型会不会原生训练 speculative head 或 verifier?这可能让 test-time compute 与 efficient serving 进一步合流。
  3. 多模态与 agent workload 会怎样改变调度器?图像、视频、工具调用和代码执行会带来更异构的阶段。
  4. 低比特 KV cache 的质量边界在哪里?长上下文检索、数学推理、代码补全和安全拒答可能有不同敏感性。
  5. AI-generated kernel 能否进入生产闭环?FlashInfer-Bench 这类工作把 agent 写 kernel、benchmark、替换生产实现连起来,值得持续观察。

总结

Efficient LLM Inference 与 Serving 已经不是单一加速技巧,而是一整套系统工程:KV cache 管理决定能装下多少上下文和并发;调度决定吞吐是否能转化成用户可感知延迟;投机解码挑战 autoregressive 串行瓶颈;量化改变内存、带宽和 kernel 形态;FlashAttention、FlashInfer 这类内核工作则决定框架能否真正吃到硬件红利。

对研究者来说,这个方向的机会在于把算法、模型结构和系统约束一起建模。对工程团队来说,最重要的不是追逐某一个“最快框架”,而是建立可测量、可回退、可分层演进的推理平台:真实流量画像、端到端指标、缓存策略、动态调度、量化验证和版本化 benchmark,才是 2026 年 LLM 应用成本控制的底盘。

参考资料

检索日期:2026-07-04。以下优先列出论文、官方文档、项目主页等一手资料;涉及 2026 年新资料的性能数字建议部署前人工复核。

  1. Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” arXiv, 2023. https://arxiv.org/abs/2309.06180
  2. vLLM Documentation, “Automatic Prefix Caching,” latest developer preview, accessed 2026-07-04. https://docs.vllm.ai/en/latest/features/automatic_prefix_caching/
  3. Zheng et al., “SGLang: Efficient Execution of Structured Language Model Programs,” arXiv, 2023 / NeurIPS 2024. https://arxiv.org/abs/2312.07104
  4. Zhong et al., “DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving,” arXiv, 2024. https://arxiv.org/abs/2401.09670
  5. Qin et al., “Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving,” arXiv, 2024. https://arxiv.org/abs/2407.00079
  6. Leviathan et al., “Fast Inference from Transformers via Speculative Decoding,” arXiv, 2022 / ICML 2023. https://arxiv.org/abs/2211.17192
  7. Chen et al., “Accelerating Large Language Model Decoding with Speculative Sampling,” arXiv, 2023. https://arxiv.org/abs/2302.01318
  8. Cai et al., “Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads,” arXiv, 2024. https://arxiv.org/abs/2401.10774
  9. Li et al., “EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test,” arXiv, 2025. https://arxiv.org/abs/2503.01840
  10. NVIDIA TensorRT-LLM Documentation, “Speculative Decoding,” accessed 2026-07-04. https://nvidia.github.io/TensorRT-LLM/features/speculative-decoding.html
  11. Liu et al., “KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache,” arXiv, 2024. https://arxiv.org/abs/2402.02750
  12. Lin et al., “QServe: W4A8KV4 Quantization and System Co-design for Efficient LLM Serving,” arXiv, 2024. https://arxiv.org/abs/2405.04532
  13. NVIDIA TensorRT-LLM Documentation, “Quantization,” accessed 2026-07-04. https://nvidia.github.io/TensorRT-LLM/features/quantization.html
  14. Zandieh et al., “TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate,” arXiv, 2025. https://arxiv.org/abs/2504.19874
  15. Staniszewski and Łańcucki, “KV Cache Transform Coding for Compact Storage in LLM Inference,” arXiv, 2025. https://arxiv.org/abs/2511.01815
  16. Dao et al., “FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness,” arXiv, 2022. https://arxiv.org/abs/2205.14135
  17. Shah et al., “FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision,” arXiv, 2024. https://arxiv.org/abs/2407.08608
  18. Ye et al., “FlashInfer: Efficient and Customizable Attention Engine for LLM Inference Serving,” arXiv, 2025. https://arxiv.org/abs/2501.01005
  19. Xing et al., “FlashInfer-Bench: Building the Virtuous Cycle for AI-driven LLM Systems,” arXiv, 2026. https://arxiv.org/abs/2601.00227
  20. Li et al., “LLM Inference Serving: Survey of Recent Advances and Opportunities,” arXiv, 2024. https://arxiv.org/abs/2407.12391
  21. Miao et al., “Towards Efficient Generative Large Language Model Serving: A Survey from Algorithms to Systems,” arXiv, 2023. https://arxiv.org/abs/2312.15234
  22. Shi et al., “Nexus: Proactive Intra-GPU Disaggregation of Prefill and Decode in LLM Serving,” arXiv, 2025. https://arxiv.org/abs/2507.06608
  23. Tiwari et al., “QuantSpec: Self-Speculative Decoding with Hierarchical Quantized KV Cache,” arXiv, 2025. https://arxiv.org/abs/2502.10424
  24. Su, “eOptShrinkQ: Near-Lossless KV Cache Compression Through Optimal Spectral Denoising and Quantization,” arXiv, 2026. https://arxiv.org/abs/2605.02905
  25. Pereira et al., “Fast-TurboQuant: A Multiplier-Free Online Vector Quantization Approach,” arXiv, 2026. https://arxiv.org/abs/2606.21448
下一词预测(Next-token Prediction)深度解析:从 N-gram 到 GPT 的唯一目标函数 下一词预测(NTP)是自回归语言模型的核心训练目标,其本质为最小化交叉熵,等价于最大似然估计。通过链式法则将序列概率分解为条件分布,模型在无监督下学习语料中真实下一个 token 的高概率输出。从n-gram到Transformer,技术演进始终围绕提升上下文建模能力与并行效率。训练时利用因果掩码实现并行前向,推理则逐token采样生成。损失函数的下降揭示了规模定律下的通用智能涌现,但模型仍受限于生成能力,无法学习逻辑或常识。该目标统一了训练、评估与推理,构成大模型发展的基石。 阅读详情

相关推荐

【 ‌infrastructure】【数据中心】【AI infra】第三篇 MLSYS / AI infra 的 Scaling 知识体系02

从 S546​ 继续,聚焦隐性知识中的推理(decode)阶段数学、profile、KV cache优化、speculative decoding等。每条包含详细数学推导、数值示例、工业实践参数。编号类型领域模块子模块详细数学建模与数值设计(含推导、边界、示例)关联知识、论文、工业实践S546推理工程推理ScalingKV cache的显存profile与预算分配KV cache sizing、head dimension、layer count、sequence length1)KV cache每层大小:

weixin_49199313的博客 147

如何快速上手 LLM 推理服务:vLLM 新手完整指南

当你需要把一个大语言模型部署成在线 API,却发现内存越占越多、并发一上来请求就开始排队时——vLLM 就是为这个场景准备的:它是一个高吞吐、显存友好的 LLM 推理与服务引擎,一条命令就能把 Hugging Face 上的模型变成 OpenAI 兼容的 API 服务。 ## 能力全景:vLLM 能帮你做什么 ### 高吞吐服务:continuous batching 与 prefix cac

gitblog_00803的博客 740

【信息科学与工程学】【通信工程】第七十六篇 网络解决方案设计03

继续围绕智算中心相关的组网设计、光路设计、波分设计、OTN设备、交换机设备、组网拓扑、网络操作系统、业务区/管理区/存储区、光设计、租户设计、电磁设计、队列设计、QoS设计、调度设计、组合设计等领域。: 若Tpxe​=2min,Tos_install​=5min,Tagent​=0.5min,Tconfig​=0.5min,则Tready​=8min。: 若N=2000,Ms​=2,Nstorage​=128,Mss​=2,则Nip​=2000×2+128×2=4256,需要/20子网。

weixin_49199313的博客 198

Efficient Inference 论文精读路线:KV Cache、Speculative Decoding、Quantization 和 Serving

Efficient Inference 研究的核心不是“让模型跑得快一点”,而是理解自回归生成的成本结构:prefill 阶段通常更像大矩阵计算,decode 阶段则被 KV cache 读写、显存带宽、调度和 batch 形态限制。KV cache、PagedAttention、continuous batching、speculative decoding、量化、prefix cache、prefill/decode disaggregation 和 serving runtime,都是围绕这条成本链条

weixin_44369324的博客 435

存储&AI行业每日要闻(2026-10-25

影响:这是市场对"烧钱就能赢"叙事的一次集体重估——Meta 主动设 C 类股稀释投票权也要融资,SpaceX 单季资本开支逼近营收 1.35 倍,叠加前一日博通 600 亿/SpaceX 400 亿芯片抵押融资,AI 基建已进入"股权+债务双管抽血"阶段;若指引保守,则昨日费半暴跌的余波将继续发酵。影响:DSX POD 的本质是把 AI 基建从"定制工程"变成"集装箱产品"——这与前一日"芯片抵押融资 5000 亿框架"形成闭环:英伟达不仅卖 GPU,还帮客户解决融资、集成、电力等全链条问题;

惠惠软件 39

第33章 YOLO+OpenCV:视频流网络传输

本案例演示用视觉处理库连接网络视频流并逐帧显示画面。程序先打开流地址,再循环取帧、显示、等待按键退出,并用重试计数应对连接失败与读取中断。验证时关注窗口能否稳定出画、是否长时间卡顿黑屏、退出后终端有无报错。🌈

小哥谈 470

LLM推理优化实战(六):系列总结——RTX 3090+7B最优部署配置与避坑指南

本文是RTX3090+Qwen2.5-7B推理优化系列收官篇,汇总五篇实验结论:AWQ量化(TPOT-65%,吞吐+117%)和Prefix Caching(TTFT最高-93%)是唯二值得做的"免费午餐";投机采样、FP8/INT8 KV Cache在该硬件下均不适用。给出最优部署配置、各优化适用条件速查表,以及"先用公式预判、再决定是否实验"的方法论。

m0_56222998的博客 1131

MoveIt控制睿尔曼RM65机械臂:从仿真到实机的3种控制模式对比

本文详细解析了使用MoveIt框架控制睿尔曼RM65机械臂的三种核心模式:拖动规划、目标姿态规划和Python API控制,从Gazebo仿真到实机部署的完整实现路径。通过ROS环境配置、控制参数优化及实机过渡技术,为工业自动化和机器人研究提供实用指南。

725

高效推理全景:KV Cache、投机解码、MoE 与长上下文推理成本演进

2026年高效推理四大核心杠杆:KV Cache(GQA/MLA)降显存,投机解码提速延迟,MoE稀疏激活省算力,长上下文优化规避成本陷阱。结合百递云桥一图三库实践,实现推理成本与延迟的系统性压缩,真正将“算得快、花得少”落地为可运行的工程方案。

xyghehehehe的专栏 186

WinCC ActiveX控件“许可证缺失”故障排查:从注册表修复到系统兼容性全解析

本文深入解析WinCC ActiveX控件报错“未找到许可证信息”的根本原因与解决方案。核心在于系统注册表中控件的设计时许可证密钥丢失或损坏。文章提供了从手动修复注册表、排查64位系统兼容性,到预防性环境部署的全流程专业指南,帮助工程师彻底解决这一常见故障。

oil88的博客 639

SPSS与SPSS Modeler,不一样的世界

1. SPSS软件的前世今生 1.1 IBM SPSS的由来 与数据打过交道的小伙伴们,应该对SPSS软件都不陌生。SPSS是世界上最早的统计分析软件,由斯坦福大学的三个研究生大牛于1968年研发,同时还成立了SPSS公司。SPSS最初的全称是Solutions Statistical Package for the Social Sciences(社会科学统计软件包),随着SPSS产品服务领...

qq_24339451的博客 3608

FAANG-Coding-Interview-Questions 仓库的 LLM 论文研读清单全解:从 Transformer 到 Agent 的 96 篇核心论文路线图

本文是对仓库中 [LLM_PAPERS_CHEATSHEET.md](https://link.gitcode.com/i/978a14dfc24a895583a8a8fc680a4c0b) 的完整深度解读。该清单按子领域组织了 96 篇理解大语言模型(LLM)所必需的研究论文,并用四档重要性信号标注优先级,覆盖从奠基性 Transformer 到最前沿的 Agent、评测与推理优化。读完本文,你

gitblog_00663的博客 421

穿透鼠标实现后台点击,适用于任何窗口!【后台鼠标】【风雪】

也许你就是被这标题吸引来的,呵呵!好久没发帖了,勾引一下大家的胃口,当然有的人已经猜出原理了!既然来了,都要把原理学回家,不然就没意思了!很多游戏现在都不支持后台消息鼠标,要实现真的不是简单的,什么注入dll啊,什么hook俺也学不懂,那就简简单单另辟蹊径了下面来讲讲原理吧(下面的玩玩可以,用于实际不现实,俺也不藏了,看到这么多人回复,良心过意不去,呵呵)首先,将要点击的窗口上面覆盖的所有窗...

weixin_34129145的博客 1万+

论文声明测试矩阵:在 Colibri 上以受控 A/B 复现 MoE 推理加速机制

本文是 Colibri 项目在 2026-07-28 记录的实验台账(原始文档见 [docs/experiments/inference-paper-test-matrix-2026-07-28.md](https://link.gitcode.com/i/d393b842bb955e57e2cc987c88c76efe))。它以 6x RTX 5090 + 双路 Xeon 主机上的 GLM-5.

gitblog_00038的博客 1025

NFS共享速度慢?麒麟系统性能调优5个关键参数实测对比

本文针对银河麒麟服务器系统上NFS共享速度慢的问题,通过实测对比分析了五个关键调优参数。重点探讨了rsize/wsize传输块大小、TCP/UDP协议选择、sync/async模式权衡等,并结合麒麟系统特性提供了具体的优化建议与配置示例,旨在帮助用户有效提升国产化环境下的文件共享性能。

weixin_29254029的博客 326

ITIL 4 Foundation 自学通关笔记1

ITIL 4 Foundation 自学通关笔记

m0_58817196的博客 934

Gemini 3.8 Flash本质是服务优化,不是新模型

大语言模型推理服务中的‘低延迟’与‘高吞吐’并非源于模型架构革新,而是依赖动态批处理、token级推测解码和自适应内存调度等底层工程优化。这些技术属于LLM serving infrastructure的核心能力,直接影响首token延迟、显存利用率与服务稳定性。在实际应用中,其价值体现在金融报告生成、客服系统响应、多模态流水线编排等对确定性SLA要求严苛的场景。开发者需关注Vertex AI Serving Layer的演进而非营销命名——真正的性能提升来自可验证的服务层升级,而非‘Flash’这类模糊术

weixin_33778544的博客 276

基于STM32L4XX 、HAL库的ATD5984步进电机驱动器驱动程序应用设计

一、简介: ATD5984是一款内部集成了译码器的微特步进电机 驱动器,能使双极步进电机以全、半、1/4、/1/8、1/16 和1/32步进模式工作。步进模式由逻辑输入管脚MSx选 择。其输出驱动能力达到28V±1.6A。 译码器是ATD5984易于使用的关键,通过STEP管脚 输入一个脉冲就可以使电机完成一次步进,省去了相序 表,高频控制线及复杂的编程接口,使其更适于没有复 杂的微处理器或微处理器负担过重的场合。 在步进操作期间,ATD5984的内部电路可以自动

PP_Cottage的博客 394

Spark介绍

底层数据仍可放在HDFS、Hive、HBase等存储系统中,Spark把数据读出来,在集群上分布式计算,再把结果写回去或交给下游。内存计算是优势,不是万能。减少不必要的shuffle:MapReduce很多操作要反复落盘,Spark的DAG调度可以在不涉及跨节点数据交换时,把中间结果放在内存中连续计算,减少磁盘IO。:Spark Core的核心抽象,表示分布在多个节点上的、不可变的、可分区的数据集,支持并行计算和容错。Spark Core:基础功能,任务调度、内存管理、错误恢复、存储交互、RDD API。

yyk33324的博客 353

华为od统一考试B卷【单词搜索】C++ 实现

找到它是一个小游戏,你需要在一个矩阵中找到给定的单词。假设给定单词 HELLOWORD,在矩阵中只要能找到 H->E->L->L->O->W->O->R->L->D连成的单词,就算通过。意区分英文字母大小写,并且您只能上下左右行走,不能走回头路。

MISAYAONE的博客 698

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

「大车小标」自动稽核怎么落地:识别车型与计费车型如何自动比对、争议如何排除

在高速公路货车逃费里,"大车小标"是最高频、也最难缠的一类:实际是更大车型、更多轴数的货车,却按更小车型交费,跑同样的路交更少的钱。单次差额可能不大,但放到长距离、高频次、规模化运营的路网里,累积的通行费流失相当可观。自动稽核"大车小标",核心不是"识别出这是什么车"这么简单,而是要把多个来源的车型判断和最终计费车型自动比对,并在大量正常交易里把真正可疑的少数挑出来,同时把设备误差、遮挡污染造成的误判排除掉。本文拆解这条链路的工程落地思路,全文定性,不涉及具体识别率与金额。

weixin_53898122的博客 347

廖雪峰Python教程[完整版]

廖雪峰的python教程整理的,已经排好版了,而且还是完整的,适合小白

深度拆解|Naoma AI Demo Agent V2 核心技术架构、Conva引擎与工程落地实践

NaomaAIDemoAgentV2重构B2BSaaS产品演示交互范式,自研Conva全链路语音引擎,实现端到端自主可控。突破传统系统延迟高、记忆碎片化、数据闭环缺失等痛点,通过双层记忆架构、实时中断抢占、智能资质评估与CRM无缝同步,支撑5万+场高并发演示。技术核心涵盖低延迟流式推理、多模态交互链路、分层持久化存储、自助部署适配及工程级容错设计,全面实现拟人化、智能化、数据驱动的无人值守演示闭环,为大模型工程优化与企业级AIAgent落地提供可复用的技术范式。

ting9452000的专栏 296

计算机控制技术及应用

《计算机控制技术及应用》通过总结作者的科研成果和吸收国内外的先进理论、方法和技术,以计算机控制系统的网络化、开放化、智能化和集成化发展趋势为主线索,主要介绍计算机控制系统的基本概念和计算机控制系统的典型形式,计算机控制系统的数学描述与基本分析方法,以及数字PID控制器、最少拍控制系统、达林算法、状态变量设计法等设计方法及其各种改进算法。重点突出计算机控制系统输入输出通道接口的设计方法和典型控制系统的设计案例与实现方法等。

Data-Structures-and-Algorithm-Analysis-in-Java.pdf

作者: Weiss, Mark A. 出版社: Addison Wesley Data Structures and Algorithm Analysis in Java is an “advanced algorithms” book that fits between traditional CS2 and Algorithms Analysis courses. In the old ACM Curriculum Guidelines, this course was known as CS7. This text is for readers who want to learn good programming and algorithm analysis skills simultaneously so that they can develop such programs with the maximum amo...

AI+制造还是制造+AI?从2026工博会看工业AI落地的典型问题与解法

2026年工博会展现工业AI深度融合趋势,“AI+制造”与“制造+AI”双轨并行。前者聚焦跨系统智能决策,后者深耕设备层嵌入式智能。实际应用需构建“感知—分析—决策—执行—反馈”闭环,采用分层架构实现高效协同。数字孪生助力虚拟验证,工业智能体推动“能办事”转型,机器人仿真训练须经真实场景检验。项目落地应遵循四步法:选高价值场景、建量化基线、先辅助后执行、按业务指标验收。关键不在于技术堆砌,而在于解决工艺痛点、连接现有系统并持续创造真实价值。

qq_40453532的博客 542

【技术拆解】配音工具选型评估方法论:用 6 个维度给 AI 配音软件打打分

✅ 测试方案:准备一段包含括号注释、数字、中英文混排的文案导入试听,校验读音、停顿是否合理。案例参考:逗哥配音配套了文案提取、自动对轴、人声分离、声音转换等附加工具,支持 wav /mp3 /mp4 格式导出,可附带字幕与 SRT 文件,在字幕对齐、文件导出这条链路具备对应的能力,适合批量生产场景的创作者在这个维度进行自测打分。同一款配音引擎,有人评价 “自然接近真人”,也有人反馈 “AI 感很重”,核心差异往往来自使用场景:30 字以内的短口播,和 3000 字小说章节朗读,对引擎能力要求完全不一样。

zhizhizhuzhuxia的博客 137

外贸独立站 AI 爬虫日志分析:UA 清单、状态码分布与「爬取不等于引用」

日志可反映爬虫访问路径、状态码与UA,但无法证明内容是否被AI引用。需按UA、状态码、路径三层分析,识别可达性问题,避免误判“抓取=引用”。应结合实测验证引用效果,警惕日志误导。关键结论:抓取≠收录≠引用,技术优化仅解决可抓取性,不保证被引用。

mqhgeo的博客 335

把GeoReady九维当工程项做:储能管理官网的AI就绪度改造笔记

GeoReady把1900多个网站的审计数据摊开,做成实时基准(State of GEO):AI搜索就绪度平均56.7/100,中位数59,一半以上卡在地基档。这篇用工程视角拆解这份基准:九维权重分别对应哪些工程项(robots.txt放行AI爬虫、llms.txt部署、Schema JSON-LD注入、Meta标签规范化、品牌实体清晰),哪些是「白给的分」,以及怎么把就绪度检查纳入CI流水线。先说结论——56.7分测的是机器可读性,是卫生指标不是排名;工程上先补最便宜的两块(llms.txt+JSON-L

RoseMarketing的博客 244
上一篇: Test-Time Scaling 与推理时计算:搜索、验证器、反思和自一致性
下一篇: Synthetic Data、Distillation 与 Post-Training 数据飞轮:从“造数据”到“治理数据资产”
Zzj_tju
博客等级 码龄8年 35粉丝 220原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Zzj_tju

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值