33 篇博文 含有标签「Inference」

做 RAG 的后端工程师大多有过这样的经历：一套 PDF 解析（PyMuPDF + pdfplumber）、分块、embedding、rerank 的管线在技术文档上效果不错，一换到财报、合同、产品手册就开始掉分。检索出来的段落看着相关，但答案在表格的某个交叉格里、在某张流程图的标注里、或者依赖两栏排版的位置关系——这些信息在"解析成纯文本"的那一步就已经丢了。

VisRAG 这篇工作把这个损失量化过：不做文本解析、直接把文档页当图片用 VLM 嵌入，端到端比传统文本 RAG 管线高 20%~40%。这个数字不必照搬（它建立在自建的检索/生成数据上），但方向是明确的：多模态文档的检索单元应该是"页"，而不是"段落"。

本文不讨论 VLM 生成侧，只讲检索层怎么落地：三条技术路线的取舍、多向量的存储与算力账本、把成本压下来的四种手段，以及我自己在 ColQwen 上趟过的坑。前置阅读可以看 RAG 进阶检索 和 向量索引 HNSW/IVF-PQ 两篇。

这是「每日一题」专栏的第二十一篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇是 分库分表之后的在线扩容，今天按轮换回到 AI/LLM 方向，兑现上一篇的预告：长上下文与 RoPE 长度外推。这道题的分水岭很清楚——背过的人能说出「位置插值」四个字，真做过的人能讲清楚「为什么高频维度和低频维度的失败方式完全相反，所以一刀切必错」。

这是「每日一题」专栏的第十九篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇是 短链接系统进阶，间隔了一个月没更新，今天按轮换回到 AI/LLM 方向，聊近两年面试出现频率陡增的一题：混合专家（MoE）——为什么 671B 的模型只需要 37B 的激活参数就能跑起来，这条路到底省了什么、又难在哪。

开源模型现在是一周一个的节奏：Kimi-K3 那篇 2.8T 的 MoE 还没消化完，DeepSeek V4 Flash 就以 284B 参数打出了「智能指数 50」的性价比，隔一周又是 GLM-5.3 把编程 Agent 安全做成卖点（见 GLM-5.3 编程 Agent 安全拆解）。对后端工程师来说，选型已经不是一个「调研一次、用半年」的静态决策，而是一个持续跟踪、反复评估、随时切换的工程问题。本文不讲具体某个模型的评测报告，讲怎么建立自己的评估框架：看什么动态、躲什么 License 坑、怎么用自家任务集跑分。

公司那台 K8s worker 是台「三无」机器：无 GPU、4 核 8 线程（AMD EPYC 9754）、30GB 内存，CentOS 7 + nerdctl，还要兼顾集群负载。我在上面用 llama-server 跑了一个给 IDE 用的代码补全/问答服务，模型从 16B 的 DeepSeek-Coder-V2-Lite 到 135M 的 SmolLM2 随意切换。这篇把选型账本和踩坑记录写下来：量化怎么选、KV Cache 每个 token 到底吃掉多少内存、CPU 上 prefill 为什么比 decode 还慢、KV cache 满载时日志长什么样。上一篇讲了 CentOS 7 + nerdctl 编译 llama.cpp 的完整流程，这篇是运行期的优化。GPU 侧的理论对比（Continuous Batching、PagedAttention）见 vLLM 推理面试题，投机解码 是另一条优化路线，这里只谈 CPU 上最现实的三个杠杆：量化、KV Cache、并发槽位。

这是「每日一题」专栏的第十六篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇讲了 实时协作文档系统，今天按轮换回到 AI/LLM 方向，聊上一篇预告的题：为什么 vLLM 最快？Continuous Batching 和 PagedAttention 各自解决了什么？

自回归解码是 memory-bound 的：小 batch 下每生成一个 token 都要把全部权重从 HBM 读一遍，GPU 算力大部分时间在空转。投机解码（Speculative Decoding）的思路反直觉但极其优雅——让一个便宜的小模型先猜 γ 个 token，大模型一次前向并行验证，猜对的直接收下，猜错的用拒绝采样修正。论文级收益 2-2.5 倍，工程实现（Medusa/EAGLE/DeepSeek MTP）能到 3-4 倍，而且输出分布与原生解码严格一致，不是近似。

推理引擎选型是 LLM 服务化里最容易被低估的架构决策。同样的模型、同样的 GPU，换一个引擎吞吐可能差 2-3 倍；但反过来，厂商 benchmark 里好看的引擎，落到你的真实负载上可能反而更慢。这篇文章把 vLLM、SGLang、TensorRT-LLM、TGI 四个主流引擎放在一起对比，从调度机制、前缀缓存、结构化输出、量化、MoE 支持五个维度拆，最后给选型决策表和生产踩坑记录。

这是「每日一题」专栏的第十篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇讲了 秒杀系统，今天按轮换回到 AI/LLM 方向，聊上一篇预告的题：模型量化。

PD 分离（Prefill/Decode Disaggregation）是这两年推理集群改造里回报最高的一步。DeepSeek-V3 技术报告在部署章节明确写了 "separates the prefilling and decoding stages"；Kimi 的 Mooncake 平台靠它多扛了 75% 的真实流量；vLLM、SGLang、NVIDIA Dynamo 都把它做成了一等公民。

但这项技术有个反直觉的点：它几乎不提升峰值吞吐，买的是延迟的可控性。vLLM 官方文档第一句就是 "Disaggregated prefill DOES NOT improve throughput"。本文拆解它为什么成立、KV cache 传输这笔账怎么算、两级调度怎么设计，最后给一个可运行的模拟器和一份踩坑清单。