Posts

近日举办的2025 RISC-V中国峰会上，NVIDIA硬件工程副总裁Frans Sijstermans宣布，CUDA软件平台将支持RISC-V指令集架构处理器，为开源架构RISC-V开启进入数据中心与AI市场的大门。 遗憾的是，Go 的 C 语言 FFI 实在太差了。cgo 的糟糕程度怎么说都不为过。 使用Gemini cli 尝试做一个自动抓取公司技术博客的应用。 Qwen-codeer 发布了，效果还可以，比Qwen好一些，但是有点贵 调试百万分之一的故障：将 Pinterest 的搜索基础设施迁移到 Kubernetes， 指标 container_referenced_bytes 在 cAdvisor 中默认启用，用于跟踪进程在每个测量周期中引用的总内存字节数。该指标通过 PTE 访问位机制实现了 Brendan Gregg 的工作集大小（WSS）估计，该机制使用页表中的访问位来计算进程读取或写入的总内存量。每次 cAdvisor 运行时，它会扫描整个页表来计算此统计数据，通过统计所有条目中的所有访问位，然后清除每个已访问的位。PinCompute 每 30 秒运行一次 cAdvisor，这意味着这种侵入性的访问位检查和清除每分钟发生两次，每分钟一次。 Manas 搜索索引每个叶节点可能高达数百 GB，而二级排序索引可能超过 1TB。当 Manas 叶节点启动时，它们会将整个索引映射到内存中。这意味着内存使用可能非常显著（例如，对于内存使用量为 100GB 的主机，页表可以容纳 2500 万个条目）。每 30 秒遍历并清除 2500 万个页表条目可能会确实导致与内存密集型叶处理产生竞争。

Kimi K2 是一款具备更强代码能力、更擅长通用 Agent 任务的 MoE 架构基础模型，总参数 1T，激活参数 32B。 在 SWE Bench Verified、Tau2、AceBench 等基准性能测试中，Kimi K2 均取得开源模型中的 SOTA 成绩，展现出在代码、Agent、数学推理任务上的领先能力。 知乎提问 在openrouter看到了groq，瞄了一下他们居然有自己的GPU。 不过最近，GPU 的地位也在经受挑战：一家名为 Groq 的初创公司开发出了一种新的 AI 处理器 ——LPU（Language Processing Unit），其推理速度相较于英伟达 GPU 提高了 10 倍，成本却降低到十分之一。贾扬清在推特上算了一笔账，因为Groq小的可怜的内存容量（230MB），在运行Llama-2 70b模型时，需要305张Groq卡才足够，而用H100则只需要8张卡。从目前的价格来看，这意味着在同等吞吐量下，Groq的硬件成本是H100的40倍，能耗成本是10倍。 Apple CPU的推理框架要支持CUDA了 EKS 100k node，之前k8s官方说最大5k节点，openai说他们有10k节点，这篇文的写的不错，都是之前遇到的问题。 和上文对应，介绍如何保障APIserver的稳定 opencode 好像火起来了，golang加ts写的。 NFD 还可以探测操作系统的相关配置。 谷歌DeepMind最近从OpenAI的潜在收购目标中挖走了Windsurf公司的核心团队，进一步增强了谷歌的AI技术实力，背后离不开戴密斯·哈萨比斯的操盘。

那么HBM内存究竟是什么，与现在主流的LPDDR5有何不同呢？事实上，HBM（High Bandwidth Memory，高带宽内存）是一种基于3D堆栈技术，通过TSV（硅通孔）和微凸块（ubump）工艺实现的多层DRAM芯片垂直堆叠。而DDR（Double Data Rate）则采用的是并行总线架构，常见于DIMM（双列直插式内存模块）形式。 HBM的带宽究竟有多高呢？以最新的HBM3E为例，其传输速率达到了9.6GB/s，可提供1.2TB/s带宽。作为对比，LPDDR5X的带宽为8533Mbps（1066.6MB/s），也就是说HBM3E的带宽是LPDDR5X的1180倍。 这里 目前只有kubelet支持动态修改log level。 用于LLM的沙盒环境，没想到背后是依赖libkrun，containers组件下面的，后来看下了RedHat也有相关介绍。 和集团那边沟通他们声称设计的推理集群最多只能支持32物理机节点，啊这有点不科学，天天都在听说什么万卡集群，这差的有点多吧。 液冷服务器 生产环境中的 LLM 推理， 这系列文章写的不错。 试用了下perplexity，感觉一般，没有很惊讶。 GORK 4 发布了。 生活 已经提了离职，周五晚上到下周一去了趟青岛。 电力如何调度的？这几天新闻说用电量一直达到历史新高。

体验过chatgpt，豆包，Qwen，和Gemini的深度研究之后，个人感觉Gemini是最好的。 首先会生成研究方向，搜索关键字，然后可能是通过tool call的方式抓取相关内容，生成的结果可以用来创建到Web Page（可交互），Infographic，Quiz和音频。 当 kube-apiserver 处理 LIST 请求时，它会一次性将数据序列化为 JSON 或 Protobuf 格式，然后交由底层的 Go/http 处理。根据标准的 encoding/json 库实现，kube-apiserver 需要分配一大块内存来存放完整的序列化结果。更严重的是，这块内存要等到数据的最后一个字节被传输完毕后才会释放，容易导致高峰时的内存占用激增。 解决这个问题的关键在于引入 流式处理 来序列化数据。KEP-5116 根据 LIST 响应的结构特点，可以依次序列化 TypeMeta、ListMeta，然后逐项序列化 Items，避免一次性分配和持有大块内存，从而降低内存占用。 Streaming JSON/Protobuf in Kubernetes k8s 中 prometheus的 token 是如何访问经过认证的kube-controller-manager的/metrics的？ 答案是：证书验证（TLS）和Token授权（RBAC）是两个独立但连续的步骤。kube-controller-manager自己处理TLS握手，但会将授权决策委托给kube-apiserver。 认证 (Authentication) - 使用 TokenReview： kube-controller-manager接收到Token后，它会创建一个TokenReview对象。这个对象包含了它从Prometheus收到的原始Token。 它向kube-apiserver的/apis/authentication.k8s.io/v1/tokenreviews端点发起一个请求，内容就是这个TokenReview对象。 kube-apiserver收到请求后，会验证这个Token的签名和有效性。如果Token有效，kube-apiserver会在TokenReview对象的状态（status）字段中填充该Token对应的用户信息（用户名、UID、所属组等），并返回给kube-controller-manager。 现在，kube-controller-manager知道了这个请求的发起者是谁（例如，system:serviceaccount:monitoring:prometheus-k8s）。 授权 (Authorization) - 使用 SubjectAccessReview： 在知道了请求者的身份后，kube-controller-manager需要确认这个身份是否有权限执行请求的操作（即对/metrics路径进行GET操作）。 它会创建一个SubjectAccessReview对象。这个对象里包含了上一步获取到的用户信息以及本次请求试图执行的操作（verb: "get", nonResourceURL: "/metrics"）。 它向kube-apiserver的/apis/authorization.k8s.io/v1/subjectaccessreviews端点发起请求。 kube-apiserver收到请求后，会查询集群中所有的RBAC规则（Role, ClusterRole, RoleBinding, ClusterRoleBinding），判断这个用户是否有权限执行该操作。 kube-apiserver将检查结果（允许或拒绝）填充到SubjectAccessReview对象的状态字段中，并返回给kube-controller-manager。 最终决策： kube-controller-manager收到SubjectAccessReview的响应后，如果结果是“允许”，它就会向Prometheus返回/metrics的数据。 如果结果是“拒绝”，它会向Prometheus返回403 Forbidden错误。 这保证了整个集群的认证授权策略是统一和集中的，避免了每个组件各自为政带来的安全风险和管理复杂性。 k8s 为什么要设计service/proxy的子资源? AI生成了4个理由，我觉得唯一有点说服力的也就第三条。 ...

简单用了下claude artifact，效果如下： 我是普通账号，上下文长度有点短，生成之后就不能做修改了，步骤分解第一次是自己生成，截图这次是手动补充的。 后端接口接口不能直接发布，只能作为纯文本预览。 同样的提示词在aistduio上面用Gemini 2.5 pro效果就差了一些： https://github.com/vllm-project/production-stack vllm官方的最佳实践 letsencrypt 准备颁发IP证书了 Gemini Cli 发布，可以免费用2.5 pro，超过以后会降到2.5 flash，还是比较良心的 TensorFlow 现在是不是比不上pytorch了？ 曾几何时，TensorFlow是深度学习框架领域无可争议的王者。然而，近年来，战局已悄然改变。来自学术界和产业界的多方证据表明，由Meta AI（原Facebook AI Research）主导开发的PyTorch，在用户青睐度、社区活跃度和学术研究应用等多个关键指标上，已经超越了Google支持的TensorFlow。虽然TensorFlow在特定的工业生产环境中仍占有一席之地，但“PyTorch后来居上”已成为业界的普遍共识。 学术界的压倒性优势与开发者的普遍偏爱 目前，PyTorch在学术研究领域的主导地位尤为突出。根据PyTorch官方在2024年底发布的回顾报告，超过70%的AI研究论文实现采用了PyTorch。这一数据得到了各大顶级AI会议论文代码实现的印证，PyTorch的出现频率远高于TensorFlow。这种趋势的背后，是PyTorch以其简洁、灵活和“Pythonic”的编程风格赢得了广大学者和开发者的心。 工业界的版图变迁：从TensorFlow独大到两强并立 传统上，TensorFlow凭借其强大的生态系统，如用于模型部署的TensorFlow Serving、用于移动和嵌入式设备的TensorFlow Lite（TFLite）以及端到端机器学习平台TFX，在工业界，特别是大规模生产部署方面，占据了绝对优势。许多大型科技公司，包括Google自身，其内部大量的AI应用和系统都深度绑定了TensorFlow。 然而，随着PyTorch的日渐成熟和其生态的不断完善，这一格局正在被打破。PyTorch在2.0版本后，通过引入torch.compile等功能，显著提升了训练性能，缩小了与TensorFlow在速度上的差距。同时，TorchServe等部署工具的推出，也补齐了其在生产环境中的短板。 更重要的是，随着大量在校期间习惯使用PyTorch的学生和研究人员进入工业界，企业的新项目越来越倾向于采用PyTorch。许多公司，特别是那些追求快速迭代和创新的AI初创企业，已将PyTorch作为首选框架。虽然让拥有庞大TensorFlow技术栈的公司进行“伤筋动骨”的迁移尚不现实，但在新项目的选择上，天平已明显倾斜。 Hugging Face生态的“风向标”意义 作为全球最大的AI模型和数据集社区，Hugging Face上模型的框架分布是衡量框架流行度的重要“风向标”。尽管没有精确的官方统计数据持续发布，但社区的普遍观察和模型上传趋势显示，绝大多数最新的、SOTA（State-of-the-Art）的自然语言处理（NLP）模型，尤其是大语言模型（LLMs），都优先提供PyTorch版本。这得益于Hugging Face的Transformers库与PyTorch的无缝集成。开发者可以轻松地使用PyTorch对Hugging Face上的模型进行微调和再训练，这极大地促进了PyTorch在NLP领域的统治地位。 那什么又是 Pythonic 呢？ cline 可以从Gemini cli中调用2.5 pro的接口的，后续又去掉了，哈哈。 https://github.com/musistudio/claude-code-router 想用claude code但是没有合适的购买途径，就可以用这个项目。 生活 bilibili首页刷到了某豪车租赁的账号。 为啥AMD突然就把英特尔干趴了？Intel的股价快到历史新低了。