Charles's Castle

现代推理系统已经很少只是“给模型一个 prompt 然后生成答案”。很多真实系统更接近下面这种结构： 这页先回答“RAG、Agent 与长上下文系统”在「推理」里的位置：它解决什么局部问题，依赖哪些前置，最后会影响哪类工程或研究判断。 前置 ：先知道 transformer 解码、GPU kernel、显存和吞吐/延迟

推理系统上线后，团队很快会遇到两个问题：现在还能撑多久，下一步该先优化哪里。这两个问题表面像“算资源”，本质是在做系统建模。大模型推理容量不是固定常数，而是请求分布、输入输出长度、模型结构、batch 策略、缓存命中、工具调用和 SLO 共同作用的结果。 这页先回答“容量规划与推理优化”在「推理」里的位置：它解决什么局

模型上线后，真正难的不是“服务有没有活着”，而是能不能持续回答四个问题：线上发生了什么、质量有没有变好、成本和稳定性是否可控、异常能不能回放并进入下一轮修复。可观测性回答“系统现在如何运行”，在线评测回答“这次变化是否值得保留”。两者应被设计成同一套闭环，而不是两个互不相干的 dashboard。 这页先回答“可观测性

MoE 和多模型服务看起来属于不同层级，但共同主题是：如何决定“哪一个模型 / 哪一部分参数该为当前请求工作”。MoE 在 token 级选择 expert，多模型服务在请求级选择模型、版本、精度路径或工具链。 这页先回答“MoE 路由与多模型服务”在「推理」里的位置：它解决什么局部问题，依赖哪些前置，最后会影响哪类工

这一页把 推理服务系统 里的 queue、prefill、decode 和 KV cache 落到 GPU 执行层。你不需要先会写 CUDA，但要能判断：慢是因为 GPU 算不过来，还是因为 batch 太碎、KV 访存太重、量化 kernel 没命中，或者调度让用户等太久。 这页先回答“GPU Kernel、Batc

随着上下文越来越长、请求越来越异质、模型越来越多，把所有工作都塞进一套统一推理实例，不再总是合理。长文档问答、RAG、Agent 和多模型路由场景中，prefill 与 decode 的资源特征明显不同，KV cache 也越来越像独立资源层。解耦式 prefill、KV 服务化和更细粒度容量运维，正是在这个背景下出现

推理系统上线后，所有优化最后都会落到两个问题：这次请求到底花多少钱，用户体验底线有没有守住。成本模型回答“值不值”，SLO 回答“能不能接受”。没有这两者，tokens/s、显存节省和 benchmark 分数都很容易误导决策。 这页先回答“成本建模与 SLO 设计”在「推理」里的位置：它解决什么局部问题，依赖哪些前置

长上下文系统的难点，不是把窗口从 4k 扩到 128k 后就结束了。窗口越长，prefill 越贵，KV cache 越大，历史噪声越多，模型越可能把旧信息、无关信息和关键约束混在一起。真正可靠的长上下文系统，本质上是一套记忆管理系统。 这页先回答“上下文压缩与 KV 内存管理”在「推理」里的位置：它解决什么局部问题，

缓存、路由和投机解码看起来是三类技术，其实都在回答同一个问题：有限 GPU 时间和显存应该花在哪里。缓存减少重复计算，路由让不同请求走不同路径，投机解码用便宜草稿先猜、昂贵目标模型再验证。 这页先回答“缓存、路由与投机解码”在「推理」里的位置：它解决什么局部问题，依赖哪些前置，最后会影响哪类工程或研究判断。 前置 ：先

Transformer 是现代 LLM、VLM、DiT、世界模型和很多推理系统的核心结构。它的关键思想是：把输入变成 token，再用 attention 让 token 之间按相关性互相读取信息。 这页先回答“Transformer 输入与注意力”在「基础知识」里的位置：它解决什么局部问题，依赖哪些前置，最后会影响哪