咖啡小屋

最近在写一个小工具：InferLens。 它现在还很早期，目标也不大：我本地起了一个 vLLM，或者手里有一个 OpenAI-compatible API，我想用一个命令确认它到底能不能正常流式返回、首 token 大概有多慢、vLLM 的 metrics 有没有变化。 说白了，它不是平台，也不是监控系统。现在更像一个推理服务的 ping。 为什么写它调 LLM 推理服务的时候，我经常遇到一些不算大、但很烦的问题： 服务能连上，但是 stream 里没有真正的 token 首 token 很慢，但不知道慢在 headers、首 chunk，还是后面的生成 vLLM 的 /metrics 接上了，但每次都要自己对照 第三方 API 说兼容 OpenAI，但 stream 字段可能长得不完全一样 offline 推理能跑，不过模型加载时间和生成时间混在一起 这些问题都可以手写 curl 或临时 Python 脚本解决，但每次都临时写一遍就很累，而且结果也不太好复现。 所以我想先把最常用的检查动作收进一个 CLI 里。 现在有什么当前版本是 v0.0.2，inferlens pin...

Linux 的权限系统看起来很朴素：用户、用户组、rwx 三组权限位。可是只要真的排查过“为什么这个进程能写这个文件”“为什么 root 装出来的文件被某个用户拿不到”“为什么目录有读权限却进不去”，就会发现它并不只是 chmod 755 这么简单。 这篇文章不从某个项目出发，而是从 Linux 自身的模型出发，梳理用户、用户组、进程身份、文件权限、目录权限、ACL、setuid/setgid/sticky bit，以及一次访问检查大致是如何发生的。 一、用户不是名字，而是 UID我们平时说的 root、nginx、mysql、test，本质上只是名字。内核真正识别的是数字 ID： 12UID: user idGID: group id /etc/passwd 里保存的是用户基本信息： 1test:x:982:982::/opt/test-agent:/sbin/nologin 字段拆开是： 1用户名:密码占位:UID:GID:描述:home:shell 这里真正决定身份的是： 12uid = 982gid = 982 用户名只是用户态工具展示和解析时...

在做大语言模型推理优化时，很多人一开始会把注意力集中在算力上，比如 FlashAttention、量化、算子融合等。但在真实的在线服务里，一个同样关键、甚至更容易先把系统拖慢的问题其实是 KV cache 的管理。 vLLM 的 PagedAttention 之所以重要，不是因为它重新发明了 attention 的数学公式，而是因为它重新设计了 KV cache 在显存里的组织方式。这件事直接影响吞吐、延迟，以及服务能同时容纳多少并发请求。 这篇文章会重点解释： 为什么传统 KV cache 管理方式容易浪费显存 PagedAttention 到底“paged”在什么地方 它为什么对 beam search 这种共享前缀、后续分叉的场景特别友好 先看问题：推理阶段真正膨胀的是KV Cache在自回归生成中，每生成一个新 token，模型都会把这一时刻每一层的 K 和 V 保存下来，后续 token 做 attention 时直接复用这些历史结果，而不是每一步都从头再算一遍。 这就是 KV cache。 KV cache 的几个特点决定了它很难管： 它会随着输出 token ...

背景线上某控制器负责管理 WorkItem 资源。删除流程里偶发出现： 日志显示已经把状态写成 Deleting 紧接着同一轮 reconcile 又读到旧状态 Failed 状态机落入 default 分支，提前 return nil 在特定 predicate 组合下，不会被 status 变更再次触发，最终表现为“删除卡死” 现象与日志下面是一次典型时间线（省略无关字段）： 12310:14:07.447 entering delete flow, setting phase to Deleting10:14:07.460 delete admission check passed10:14:07.460 unexpected phase during deletion: Failed 注意第三行和第一行间隔只有十几毫秒。 关键代码路径删除状态机（简化后）大致是： 1234567891011121314151617181920func (r *Controller) reconcileDelete(ctx context.Context, item *v1.WorkI...

很多人把 PromQL 当成“画图 SQL”：会写 sum(rate(...)) 就能应付 80% 的面板，但一旦遇到多指标关联、实例集合变化、窗口语义、告警抖动，查询就开始失控。本文不绑定任何具体业务指标，而是从 Prometheus 的数据模型与 PromQL 的算子体系出发，系统梳理常用指令，并给出 Grafana 中可复用的查询范式。 1. 先建立数据模型：你在操作的不是“一个数”Prometheus 存储的是时间序列（Time Series）。一条序列由两部分唯一确定： 指标名（metric name）：如 http_requests_total、node_cpu_seconds_total 标签集（labels）：如 {job="api", instance="10.0.0.1:8080", method="GET", code="200"} 每个时间点上的采样是 (timestamp, value)。因此 PromQL 的输入/输出从来不是“单个 fl...

Git 命令很多，但高频场景其实比较稳定。本文不追求“命令大全”，而是按研发流程整理一套可扩展的 Git 使用体系，方便后续持续补充。 一、先建立心智模型：三个区域 Working Tree：本地改动区 Index (Staging Area)：暂存区 Repository：提交历史 多数命令都可以归类为： 在三个区域之间搬运内容 在分支之间组织历史 与远端仓库同步 二、日常开发主流程（推荐）1) 拉取最新代码12git checkout mastergit pull origin master 目的：把本地主干更新到最新状态。 2) 切分支开发123git checkout -b feature/login-audit# 新版写法git switch -c feature/login-audit 目的：把功能改动和主干隔离。 3) 提交本地改动123git statusgit add .git commit -m "feat: add login audit logs" 建议：提交信息遵循团队规范（如 feat/fix/ref...

在写 Kubernetes controller、HTTP API 或者后台 worker 时，context.Context 几乎无处不在。它本身 API 很小，但用错的地方很常见：超时没传下去、goroutine 泄漏、或者把 context 当成「万能参数包」乱塞值。这篇笔记整理几个我在项目里反复用到的约定，不追求完整，只求日常够用。 1. 谁创建，谁负责取消规则：在请求入口（HTTP handler、gRPC interceptor、reconcile 顶层）用 context.WithTimeout / WithCancel 创建带截止时间的 context，并保证函数返回前调用 cancel()。 1234567func (s *Server) handle(w http.ResponseWriter, r *http.Request) { ctx, cancel := context.WithTimeout(r.Context(), 30*time.Second) defer cancel() if err := s.svc.D...

本片博客将介绍一些不成系统的零碎知识点，后续根据体量选择部分写成新的博客 GO flags GOPROXY：Go 拉取依赖的代理服务地址，默认值是：https://proxy.golang.org,direct，一般来说不挂梯子访问不了，所以会进行修改。配置GOPROXY能直接从代理拉取包而不走git直连从而能绕开 Git 认证 GOPRIVATE：表明哪些模块是「私有的」，不要走公共代理和校验服务，既绕过GOPROXY和GOSUMDB，直接进行git 直连但会触发git验证。譬如go env -w GOPRIVATE=git.dev.xxx.com/*。 GOINSECURE：允许对某些模块使用不安全的连接（HTTP 或自签证书）而跳过tls认证 GOSUMDB：Go 的模块校验数据库，用来验证下载的依赖是否被篡改，默认是 sum.golang.org（国外的）。国内常换成镜像：sum.golang.google.cn git rebase在和别人合作过程中总会遇到自己在分支上写了很多代码而别人在相关部分也写了代码并比你提前和入了master，如果你当前分支上有很多提交，直接...

本片博客将介绍kubebuilder的使用以及相关原理 ，原始教程kubebuilder项目地址。但由于原教程kubebuilder版本为v4而教程部分为v3，故而本篇会做出修正并进行相关解释。相关组件版本如下 k8s版本：v1.33.1 kubebuilder版本：v4 go版本：v1.22.0 controller-runtime：v0.18.2 kubebuilder的简要说明： 是什么：是针对controller-runtime的封装脚手架工具 为什么：开发者使用controller-runtime开发operator过程繁琐 怎么样：使用marker机制自动化生成相关资源代码，用户只需要再顶层填充代码逻辑即可 K8s Operator工作原理CRD，CR 和 controller CRD(Custom Resource Definition)为K8s 自定义资源定义，比起K8s内置的资源(如deployment，configmap)，这种资源由开发者自己定义 CR(Custom Resource)为K8s 自定义资源，由CRD实例化而来，CR和CRD的关系类似于...

本片博客将介绍kuberhealthy的使用以及相关原理 ，kuberhealthy项目地址 kuberhealthy简介 kuberhealthy是一个k8s operator kuberhealthy 用于k8s 组件功能检测和验证，保证功能可用 kuberhealthy 通过下执行kuberhealthy checker pod进行测试逻辑执行和测试结果收集从而完成组件功能验证 核心概念 CRD: KuberhealthyChecker该CRD指定了一次check（可以理解为一次测试）的相关控制信息，比如 运行check的间隔 回收check的时间 checker pod的具体内容，包括拉取哪些镜像以及相关参数 下面是一个典型的KuberhealthyCheck 123456789101112131415apiVersion: comcast.github.io/v1kind: KuberhealthyCheckmetadata:name: kh-test-check spec:runInterval: 30s # The interval that Kuberhe...