这是「每日一题」专栏的第二十三篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇是 MySQL 索引与深分页，文末预告的分布式 ID 生成器在 8 月 16 日已经出过一版 基础篇，再写一遍是重复劳动，所以今天换成同属系统设计方向、但更贴近日常后端的一道硬题：IM 即时通讯系统。
这题的杀伤力在于它「看起来谁都能画个框图」：客户端、网关、业务层、存储，几笔就画完了。但只要面试官往下一问——「单机百万连接，内存要多少 GB？端口够用吗？」「网关到底是不是无状态？」「你说消息不丢，丢在哪几个时刻？」「顺序用什么保证，时间戳行不行？」「一万人群发一条消息，写放大是多少倍？」——画框图的人立刻熄火。今天把这五个追问的账全部算一遍。
做 RAG 的后端工程师大多有过这样的经历：一套 PDF 解析（PyMuPDF + pdfplumber）、分块、embedding、rerank 的管线在技术文档上效果不错，一换到财报、合同、产品手册就开始掉分。检索出来的段落看着相关，但答案在表格的某个交叉格里、在某张流程图的标注里、或者依赖两栏排版的位置关系——这些信息在"解析成纯文本"的那一步就已经丢了。
VisRAG 这篇工作把这个损失量化过：不做文本解析、直接把文档页当图片用 VLM 嵌入，端到端比传统文本 RAG 管线高 20%~40%。这个数字不必照搬（它建立在自建的检索/生成数据上），但方向是明确的：多模态文档的检索单元应该是"页"，而不是"段落"。
本文不讨论 VLM 生成侧，只讲检索层怎么落地：三条技术路线的取舍、多向量的存储与算力账本、把成本压下来的四种手段，以及我自己在 ColQwen 上趟过的坑。前置阅读可以看 RAG 进阶检索 和 向量索引 HNSW/IVF-PQ 两篇。
这是「每日一题」专栏的第二十二篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇是 长上下文与 RoPE 长度外推，今天按轮换回到后端/分布式方向，兑现上一篇的预告：MySQL 索引与深分页。这题的面试杀伤力在于它「人人都会、人人答不满」——绝大多数人能说出「B+ 树矮、叶子有链表」，但一追问「三层的容量账怎么算」「最左前缀为什么断在范围列就没了」「延迟关联为什么还是 O(offset)」，就露馅了。
这是「每日一题」专栏的第二十一篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇是 分库分表之后的在线扩容，今天按轮换回到 AI/LLM 方向，兑现上一篇的预告：长上下文与 RoPE 长度外推。这道题的分水岭很清楚——背过的人能说出「位置插值」四个字，真做过的人能讲清楚「为什么高频维度和低频维度的失败方式完全相反，所以一刀切必错」。
这是「每日一题」专栏的第二十篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇是 MoE 混合专家，今天按轮换回到后端/分布式方向，兑现昨天的预告：分库分表之后的在线扩容。这题的面试杀伤力很高——很多人张口就是「双写」两个字，但一追问「迁移期间读走哪边」「校验对不上怎么办」「出错怎么退回去」，就答不完整了。
后端工程师看 LLM 应用，最容易忽略的一层是分词器。它夹在你的文本和模型之间：你发出去的每一个请求，先被转换成一串整数编号；你按量付费的每一个 token，就是这串编号里的一位。这一层没有超时、没有重试、没有连接池，看起来不像"系统"，但它是唯一决定 token 数量的环节——而 token 数量同时决定了账单、KV Cache 显存、有效上下文窗口和 decode 阶段的吞吐。
更要命的是，分词器不是中立的。它的行为由训练语料的语言配比决定：一个主要用英文语料训练出来的词表，会把绝大多数额度花在英文词素上，中文、代码和数字只能退化成更短、数量更多的符号。本文不讲"分词器很重要"这种废话，直接从零写一个 BPE，然后用它跑四组实验，把每一项都变成可以写在容量规划表里的数字。所有代码只用 Python 标准库，你可以直接复制运行。
这是「每日一题」专栏的第十九篇。每天一道面试题，后端 + 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、并发槽位。