三木的技术博客

本文转载自公众号「AI Infra 源码分析」，原文《Go TaaS：把算力变成 Token 工厂的开源底座》。 作为云计算从业者，过去十年，我们习惯用资源描述基础设施：多少核、多少 GB 内存、多少张卡。客户也习惯这样买。但在推理成为主要负载之后，资源不再是交付物，Token 才是。资源只是生产 Token 的原材料。 Go TaaS 是我们基于这样的判断做的一个 AI Native 的开源项目：Apache-2.0 License，跑在 Kubernetes 上，把模型部署、异构加速卡调度、Token 计量、计费结算和路由治理做成可私有化部署的底座。它不是又一个 MaaS 平台，而是一座能自己运营的 Token 工厂。 之所以称之为 AI Native 的项目，是因为这个项目我只做了架构设计和 CI/CD 流水线的搭建，剩下的功能探索、设计、文档、编码都是 AI 小团队完成的。AI Coding 发展到今天，模型编码的能力已经达到甚至超过很多人类工程师的水平，我们 Review 的速度已经远远赶不上代码生成的速度。所以我们把这个项目开源出来，希望更多的伙伴参与进来，给 A...

私有化交付的 Token 工厂，权限问题很少从“角色怎么分”开始暴露，通常是从两个很具体的问题开始： 客户的安全团队问：这把 Key 能不能只允许调用某几个模型，每分钟最多多少次？Key 被带出去之后，影响范围有多大？ 客户的平台团队问：运维能不能看到我们调了什么？能不能替我们建 Key、改配额？ 这两个问题，机器学习平台的权限模型答不好。与其说它不够细，不如说它细在了另一个地方。 Go TaaS 是一个跑在 Kubernetes 上的开源大模型推理与计量计费平台：平台方部署模型、镜像和推理服务，租户用 OpenAI 兼容 API 按 token 消费。下面以它的权限设计为例，把这两条链拆开看。设计文档与代码都在 go-taas.com 和 GitHub 上公开，文末附了本文引用到的章节链接。 私有化交付的 Token 工厂，权限问题很少从“角色怎么分”开始暴露，通常是从两个很具体的问题开始： 客户的安全团队问：这把 Key 能不能只允许调用某几个模型，每分钟最多多少次？Key 被带出去之后，影响范围有多大？ 客户的平台团队问：运维能不能看到我们调了什么？能不能替我们建 Ke...

AIBrix v0.8.0 在 2026 年 10 月 12 日发布。从 v0.7.0 算起，这个版本合入 443 个 commit，来自 104 位贡献者。 光看功能清单，容易把它当成一次“又加了一堆东西”的例行升级。但把这些改动串起来看，v0.8.0 其实在回答同一个问题：当推理集群里跑的不再是“一个模型配一组 Pod”，基础设施该怎么变？ v0.7.0 解决的是“可组合”——Console、Batch API、多引擎支持、P/D 分离、高可用网关，这些能力拼成了一个能自助使用的平台。v0.8.0 往前走了一步：模型的生命周期不再绑定 Pod 的生命周期；路由从“看请求量”变成“看推理工作量”；Agent 多轮对话和视频生成这类不典型的负载，也各自有了对应的处理路径。 下面按“问题 → 方案 → 代价”的顺序拆开讲。 这一版改了什么先看全景，再往下拆细节。 flowchart TD P["问题：模型 = Pod<br/>要么独占 GPU，要么冷启动"] --> MC["ModelClaim<...

Aibrix 是一个开源项目，目标是提供构建可扩展 GenAI 推理基础设施所需的”积木”。它解决的是 LLM 推理上云后的运维问题：模型怎么部署、流量怎么调度、GPU 显存怎么省、资源怎么扩缩容。 1. 为什么不能直接用 Nginx先把问题定义清楚。LLM 推理服务看起来和其他 HTTP 服务一样：前面挂个网关，后面一排后端 Pod。但把一个请求从网关打到后端，远不止”负载均衡”这么简单。 Aibrix 的官方文档把这类问题归为两个阶段： Prefill（预填充）：一次性处理整个输入 prompt，计算密集，速度快。 Decode（解码）：逐个生成输出 token，受内存带宽限制，速度慢。 一个关键事实是：这两个阶段的运行特征完全不同，而且 KV Cache 把请求变成了”有状态”的。如果网关把一个请求随机打到某个 Pod，而这个 Pod 里没有该请求 prompt 前缀的缓存，那么整个前缀都要重新走一遍 Prefill。这不仅浪费 GPU 算力，还直接拉高了首字延迟（TTFT）。 更麻烦的是，KV Cache 占用的显存远超想象。长上下文模型里，KV Cache 会挤...

Ray 是一个面向 Python 的分布式计算框架，最初作为 UC Berkeley RISELab 的研究项目发展而来，如今已演进为覆盖数据加载、分布式训练、超参调优、在线推理等环节的完整 AI 计算生态。本文从核心抽象、总体架构、底层机制与上层生态四个层面梳理 Ray 的设计与实现。 一、 引言：Ray 解决的问题在 Ray 出现之前，机器学习流水线通常需要拼接多套系统：用 Spark 处理数据，用 Horovod 进行分布式训练，用 Celery 执行异步任务，用 Kubernetes 部署在线推理服务。这种组合带来几个问题： 多套系统的学习与运维成本叠加。 系统之间的数据交换依赖磁盘或网络序列化，存在额外开销。 Python 本身缺少细粒度的分布式原语。 Ray 提供了一套统一的编程模型：开发者只需在普通 Python 函数或类上添加 @ray.remote 装饰器，即可将单机代码扩展到多节点集群。它同时支持无状态的任务（Task）和有状态的服务（Actor），用同一套底座承载不同类型的 AI 计算负载。 二、 Ray 的核心概念与编程模型Ray 的三个核心抽象...

在 LLM 应用开发中，系统提示词（System Prompt）的管理往往是一个容易被忽视的工程痛点。随着应用复杂度的提升，传统的单体字符串拼接方式会导致代码难以维护，并且在面对长上下文时，容易产生不必要的高额 Token 消耗和延迟。 本文基于 Claude Code 泄露出来的源代码（主要覆盖 src/QueryEngine.ts 及 src/utils/ 等核心模块），从工程视角拆解其提示词管理的系统架构。其核心设计理念包括：极致的模块化解耦、对 Prompt Caching（提示词缓存）的深度优化、多级路由调度机制以及并发的上下文组装。 1. 提示词的模块化注册机制对于复杂应用，单体字符串形式的 Prompt 极易引发代码冲突与逻辑混乱。Claude Code 在这方面采用了类似中间件的模块化注册机制。这种设计使得新增能力（如引入特定的 MCP Server 指令）时，只需在组装层增加相应的 Section，无需在数千行的主字符串中修改，符合软件设计的开闭原则（OCP）。 在 src/constants/systemPromptSections.ts 中，各类规则和指令被...

随着大模型和人工智能技术的爆发，底层的算力基础设施迎来了前所未有的挑战。传统的 Kubernetes 调度器最初为微服务（长运行的无状态或有状态服务）设计，在面对机器学习训练、大数据分析等 高性能计算（HPC） 和 批处理（Batch Processing） 任务时，显得捉襟见肘。 为了解决云原生环境下机器学习平台对高级调度的需求，CNCF 首个批量计算项目 Volcano 应运而生。本文将深度解析 Volcano 的核心概念、架构设计、关键技术细节，以及它在机器学习平台中扮演的底层基石角色。 摘要在云原生 AI 基础设施中，调度系统的能力直接决定了算力集群的利用率和分布式训练的效率。本文从 Kubernetes 原生调度器的痛点出发，系统性地阐述 Volcano 的核心对象及其相互关系，深度拆解其架构模块，并详细剖析了 Gang Scheduling（组调度）、Fair-share（公平调度）、资源队列与多租户机制、拓扑感知等关键技术细节，最后探讨其在真实机器学习平台生态（如 Kubeflow、Ray 结合）中的最佳实践。 一、 引言：为什么机器学习平台需要 Volca...

Claude Code是一款强大的基于终端运行的 AI 编程助手工具，其背后的工程实现远非简单的“脚本调用大模型 API”，而是一套高度抽象、解耦且具备极佳扩展性的现代软件架构。通过深度拆解其意外流出的源码结构，我们可以清晰地看到以大语言模型 (LLM) 为计算核心的 CLI 应用是如何处理复杂交互、状态机流转、本地运行时安全保障及外部生态扩展的。 本文将从技术栈选型、终端前端渲染、核心逻辑引擎、工具链协议、状态管理体系以及扩展通信桥接等多个维度，对该项目的架构设计进行详细的源码级分析。 代码仓库： https://github.com/sanmuny/claude-code-source-code 核心架构示意图在深入探讨代码之前，我们可以先通过系统的模块交互全景视图建立直观的认知： 1. 核心架构与技术栈概览通读 package.json 及核心代码目录，该项目使用了极度现代化的底层技术栈。这些技术的选取体现了作者在启动性能与开发效率之间极佳的平衡考量： 核心语言与运行时基座：系统主体通过 TypeScript 严格类型约束编写，并在部分执行环节强依赖于 Bun 的运...

深夜 11 点，微信群弹出一条消息。 产品经理：“小王，那个 AI 客服的语气能不能再温柔一点？顺便把双十一的最新活动规则加进去，明早要上服。” 你默默看着代码库里那段长达 100 多行的 System Prompt，叹了口气。改完这句话，你又要经历：本地构建 -> 提交代码 -> 等待 CI/CD 流水线 -> 灰度发布…… 仅仅因为改了几个字，整个系统就要被重新折腾一遍。 在全面拥抱 AI、快速构建大语言模型（LLM）应用与智能体（Agent）的今天，你是否也在忍受这些“反人类”的痛点： 💥 极高的调试成本：Prompt 深度耦合在业务代码里，每一次 Prompt 的字眼微调，都伴随着沉重的重新编译与发版过程。 🧱 跨部门协作的“隔离墙”：懂业务的运营人员和懂提示词工程的 Prompt 专家无法直接修改指令，必须沦为“提需求的人”，苦苦排期等待研发实现。 🌀 失控的多智能体灾难：在 Multi-Agent 架构下，成百上千个不同角色的性格设定、工具约束像牛皮癣一样散落在代码的各个角落，版本回溯更是天方夜谭。 如果这些场景让你感到窒息，那么你正面...

大家好，今天分享一篇 2026 年初非常值得精读的综述论文：《Agentic Reasoning for Large Language Models》，由伊利诺伊大学厄巴纳-香槟分校、Meta、亚马逊、Google DeepMind、UCSD和耶鲁大学等多机构联合发布。不同于普通的技术论文，这篇综述系统梳理了大语言模型（LLM）从“文本生成工具”向“自主智能体（Autonomous Agents）”跃迁的核心范式、推理机制，以及当前行业的技术现状与未来方向，是入门和深耕 Agent 领域的必备参考。 论文链接：https://arxiv.org/abs/2601.12538 一、为什么需要 Agentic Reasoning？（核心背景与价值）要理解 Agentic Reasoning（智能体推理）的必要性，首先要明确传统大模型的局限性，以及真实世界任务的核心需求，这也是论文开篇重点阐述的内容。 1. 传统大模型的“能力边界”传统 LLM（如 GPT-4、Llama 3 等）在静态、封闭上下文（Closed-world Settings）中已经展现出极强的生成与推理能力——比...