Charles's Castle

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

MoE 和多模型服务看起来属于不同层级，但共同主题是：如何决定“哪一个模型 / 哪一部分参数该为当前请求工作”。MoE 在 token 级选择 expert，多模型服务在请求级选择模型、版本、精度路径或工具链。 路由的本质 路由本质是资源分配： $$ r x rightarrow text resource subse

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

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

推理系统上线后，所有优化最后都会落到两个问题：这次请求到底花多少钱，用户体验底线有没有守住。成本模型回答“值不值”，SLO 回答“能不能接受”。没有这两者，tokens/s、显存节省和 benchmark 分数都很容易误导决策。 图源：vLLM 官方博客：Easy, Fast, and Cheap LLM Servin

长上下文系统的难点，不是把窗口从 4k 扩到 128k 后就结束了。窗口越长，prefill 越贵，KV cache 越大，历史噪声越多，模型越可能把旧信息、无关信息和关键约束混在一起。真正可靠的长上下文系统，本质上是一套记忆管理系统。 长上下文为什么贵 长上下文会同时放大两类成本： 成本 发生在哪里 为什么随上下文变

这篇回答的问题。 如何理解“KV、缓存与投机解码”背后的核心机制、适用边界和下一步阅读路径。 缓存、路由和投机解码看起来是三类技术：缓存复用历史计算，路由选择请求路径，投机解码让便宜 draft 先猜、昂贵 target 再验证。但它们在服务系统里回答的是同一个问题：有限的 GPU 时间、KV 显存和强模型调用次数，应

Transformer 最容易被讲成一张架构图：左边 encoder，右边 decoder，中间有很多箭头。但真正决定模型如何工作的是一条更朴素的链路： 这条链路适用于 LLM，也适用于 VLM、DiT、VLA 和世界模型。文本会被切成 subword token，图片会被切成 patch token，视频会变成时空

这篇文章只回答一个问题：为什么模型里的很多 bug、OOM、速度异常和多模态错位，最后都能追到 shape。 张量不是“多维数组”这么简单。对深度学习系统来说，一个 tensor 至少同时携带五件事：底层 storage、shape、axis semantics、stride/layout、dtype/device。S

这篇文章只回答一个问题：怎样把“让模型回答”改造成一条可控、可复核、能接外部证据和工具的信息流。 Prompt engineering 不是找一句神奇提示词。它是在设计模型这次推理能看见什么、必须遵守什么、哪些文本只是数据、哪些结果要被外部验证。CoT 给复杂任务一个中间工作区；RAG 把外部证据接进上下文；ReAct