LiteLLM 的 spend log 按 key 记了 token 和来源 IP，放在 Cloudflare Tunnel 后面时 IP 全是集群内地址。改用 pre-call hook 读 CF-Connecting-IP，对外的 key 另加别名和限流。

xiaogpt 不改音箱固件，靠每秒轮询小米云的对话记录截下带关键词的问题，再交给大模型回答。在新加坡密码登录会被小米风控拒绝，只能用 passToken；它会轮换，登录失败还会删掉 token 文件，所以在 K3s 里放 PVC、单文件挂载。

写信人没有 CS 背景，靠 LLM 攒出一套 TypeScript 系统，往生产环境推的时候发现它超出了自己的理解。Mark Seemann 的答复自称算不上严谨，落点在两处：往下懂一层、往上懂一层这条老规矩，以及只拿可证伪的问题去问 LLM。

基于一次 M5 本地测试，记录 MoE 模型带宽瓶颈，以及通过内存热缓存把长上下文推理提速到约 6.4 倍的过程。

Qwen3.6 随 KV cache 修复一起引入的 preserve_thinking 开关是 chat template 的 kwarg，不是 vLLM CLI 标志；借助集群两台 DGX Spark 做 A/B 对照，量化出 prompt/completion token 的差异。

实测两台 DGX Spark 上 Qwen3.6-35B-A3B-FP8 的 vLLM 吞吐：单机单流 ~50 tok/s，双机经 FastAPI Gateway 并发 N=16 聚合可达 ~485 tok/s。

将两台 DGX Spark 从不稳定的 vLLM TP=2 跨节点部署迁移到单节点独立运行 + Bifrost 负载均衡网关的完整实践和 benchmark 结果。

在两台 DGX Spark 上对比 vLLM EP2 和 TP2 跑 NVIDIA Nemotron 3 Super 120B A12B NVFP4 的结果，并分析 EP2 失稳的可能原因。

两台 DGX Spark 以 vLLM TP=2 跨节点跑 Qwen3.5-35B-A3B，部署过程、benchmark 数据和与单机的对照都在这一篇。

Tools、Resources、Prompts 这三个 MCP 核心概念，用一个能跑起来的 SQLite MCP 服务器串起来，连调试一起走完一条开发流程。