这是「每日一题」专栏的第一篇。每天一道面试题，后端 + AI 混合，从原理到代码，从八股到实战。

云服务器搭 AI 绘图/视频生成环境，网络和依赖是最大拦路虎。本文记录在 AutoDL Tesla T4（16 GB 显存）实例上，从裸 Ubuntu 20.04 到跑通 ComfyUI + CogVideoX-5B 的完整过程。

你有一台国内云服务器，需要从 GitHub / HuggingFace / PyTorch 官方源下载东西，直连慢到怀疑人生。但你本地电脑已经跑着 Clash，出国速度飞快。能不能让服务器借用本地的 Clash？能，一行 SSH 反向隧道搞定。

Hermes Agent 用久了，积累的东西其实不少：几十个 skill、累积的 memory、多个 cron 定时任务、多个 profile 的 SOUL 定义。这些东西全放在 ~/.hermes/ 下面，重装系统或者换机器时，如果没备份，就得从头再来。

用 Git 做备份，比手动 cp -r 靠谱得多：有版本历史、能增量同步、还能推送到 GitHub 私有仓库做异地容灾。

「一个 70B 模型、每天 10 万请求、p95 TTFT 小于 1 秒，需要多少张 H100？」如果你问云厂商销售，答案取决于他的季度指标；如果你问架构师，答案应该取决于一张纸上的数学。LLM 推理的性能不是靠 benchmark 榜单「测」出来的，而是可以被两条硬件参数——峰值算力和内存带宽——从第一性原理「算」出来的。

本文沿用 Roofline 模型的分析框架（参考 Sid Babu 2026 年 5 月的同名长文），把 prefill 与 decode 两个阶段的吞吐、延迟写成可计算的代数式，再用 70B 模型在 H100/B200 上的具体数字验证，最后给出一个完整的容量规划实例。看完你会理解三件事：为什么 decode 阶段「大 batch 包治百病」是错的、为什么长上下文是推理成本的真正杀手、以及为什么 FLOPs 越高不代表推理越快。

传统可观测性三板斧——指标、日志、链路——搬进 LLM 应用后很快就失灵了。原因有三个：成本不再是「一台机器多少钱」而是「一个请求烧了多少 token」；故障不再只有 500 错误，还有「返回了 JSON 但字段是错的」「在工具调用里循环了 15 轮」「幻觉编了个不存在的订单号」；确定性不复存在——同一 prompt 两次调用结果不同，你没法靠「重放请求」复现 bug。

这不是换一套 dashboard 的事，而是需要一套面向 LLM 的语义模型：知道哪一次调用花了多少钱、哪个 span 对应哪次工具执行、哪条 Agent 轨迹陷入了循环。本文从 OpenTelemetry GenAI 语义约定出发，拆解指标、追踪、成本归因三个层面，最后给出一条可落地的开源工具链路径。

自回归解码的本质是「一步一个 token」：生成第 t 个 token 必须等前 t-1 个 token 全部算完，而且每个 token 都要跑一遍完整的前向传播。在 decode 阶段，Transformer 的算力利用率通常只有个位数百分比——因为激活很小、瓶颈在显存带宽（memory-bound），GPU 上几 TB/s 的 HBM 带宽被浪费在搬运权重上。这就是投机解码（Speculative Decoding）要解决的核心矛盾：能不能用便宜的计算提前猜出未来几个 token，让大模型一次前向同时验证 K 个猜测？

答案是能，而且无损失。本文拆解投机解码的数学原理、三条主流实现路线（独立草稿模型 / Medusa 多解码头 / EAGLE 特征级草稿）、以及 vLLM 中的生产配置与收益边界。

KubeKey 搭的 k8s 集群，节点上装的是 containerd + nerdctl，没有 docker daemon。平时操作没问题，但一旦要跑别人的脚本、CI 或者凭肌肉记忆敲 docker 命令时就傻眼了——docker: command not found。

这篇记录我写的一个 60 行 bash shim：把 docker 伪装成 nerdctl 的转发器，以及部署过程中踩到的一个 CentOS 7 专属的隐蔽坑。

2026 年的生产应用里，纯文本模型越来越少见——文档解析、截图问答、票据识别、视频审核，几乎每个场景都绕不开「看图」。但把图片塞进 LLM 不是免费的：一张 336×336 的图在 LLaVA 范式下要 576 个 token，比一段 500 字的中文还贵；一次文档问答可能吃掉数千 token 的 prefill。本文从架构、token 成本、数据管线、推理部署、评测五个角度，拆解 VLM 工程落地的关键问题，重点是可复现的数据与可执行的配置。

长上下文是 2026 年推理成本的主战场。模型权重是「一次性」成本——加载一次、人人共享；KV Cache 却是「每次请求」成本——随并发数与上下文长度线性增长。以 Llama-3-70B 为例：fp16 权重约 140GB，而单路 128K 上下文的 KV Cache 在 GQA-8 配置下就要 40GiB，若是 MHA-64 架构则高达 320GiB。权重只装一次，KV 却要为每个并发请求各存一份。这就是为什么「上下文 128K 免费」的口号背后，钱都花在 KV 上。

本文按「架构 → 工程 → 量化 → 驱逐」四层拆解 KV Cache 优化：先算清账，再讲 GQA/MLA 如何从模型侧减量，PagedAttention 与前缀缓存如何复用，FP8/KIVI 如何压缩，最后是 StreamingLLM/H2O/SnapKV 这类「不保留全部」的驱逐方案。数字来自公开论文与可复现的计算，工程建议以 vLLM 为例给出可直接落地的配置。