Posts

你有没有这种感觉：每天早上醒来，前一天学的东西大部分都忘了？ LLM 就是这样工作的。 每个对话 session，模型都是从零开始。它不记得你是谁，不记得你上次做了什么决定，更不记得那个方案三个月前就试过并且失败了。你花 20 分钟解释背景，下一个 session 又得重来一遍。 这不是 AI 的 bug——这是架构限制。大多数 Agent 的"记忆"，就是把整段对话历史塞进 prompt，靠上下文窗口撑着。贵、慢，而且换一个新 session 照样失忆。 Stash 想要解决这个问题。它的 slogan 很直接：Your AI has amnesia. We fixed it. 这个项目是做什么的 Stash 是一个开源的持久化记忆层，专门给 AI Agent 用。它不是一个聊天机器人，而是一个基础设施——在 Agent 和外部世界之间加了一层认知处理管道。 核心思路：Episodes become facts. Facts become patterns. Patterns become wisdom. AI 的每一次对话、每一个决定、每一次成功和失败，都被记录下来，经过一个 8 阶段的管道，转化成结构化的知识。事实与事实之间建立关联，关联形成模式，模式沉淀为真正的理解。 原始对话 ↓ Episode 记录（原始事件） ↓ Fact 提取（去掉了时间戳和情绪的事实） ↓ Relationship 建立（事实之间的连接） ↓ Pattern 检测（反复出现的模式） ↓ Goal Tracking（目标状态） ↓ Failure Pattern（失败教训） ↓ Hypothesis & Confidence（假设与置信度衰减） ↓ Wisdom（长期知识） 这个管道是增量的——每次运行只处理新数据，不会重复劳动。 ...

如果你在生产环境跑过 AI Agent，大概率遇到过一个头疼的问题：Agent 怎么安全地访问那些需要 API Key 的服务？ 传统方案很简单：把密钥配置在环境变量里，Agent 启动时读取。但这套逻辑是给"确定性程序"设计的——程序行为可预测，不会被外部指令诱导去做你没想过的事。 AI Agent 不一样。它们是非确定性的，能被 prompt injection 诱导，能被恶意网页操纵，能在 RAG 流程里接收有害指令。密钥一旦进了 Agent 的上下文，就等于随时可能被抽走。 这是一个真实存在的威胁，不是理论推演。Infisical 最近的博客详细描述了攻击路径：攻击者通过文档注入、恶意网页或工具调用让 Agent “主动"把环境里的密钥发到攻击者控制的端点。哪怕你上了多层 guardrails，也没有办法保证 Agent 绝对不泄露。 传统解法为什么不够用 业界的应对思路大概分三类： ① 短命凭证（Short-lived Tokens） OAuth2 的 access/refresh token 模式，API 返回临时凭证，过期自动失效。配合自动化密钥轮换，攻击者拿到的那串字符很快变成废纸。 听起来合理，但本质上只是降低窗口期，没有解决根本问题——凭证依然会泄露，攻击者只要在失效前用完就赚了。 ② 防火墙和网络隔离 只允许 Agent 访问特定 IP 段，不允许出站直连。攻击者通过 Agent 发起请求，同样会经过那些被允许的端点，该泄露还是泄露。 ③ 自行实现凭证代理 Anthropic 的 Managed Agents 架构、Vercel 的 credential brokering、Cloudflare 的 outbound workers，都走了同一条路：Agent 的请求经过一个代理层，由代理负责在请求发出前把凭证注入，Agent 自己从不直接接触密钥。 这条路是对的，但每家公司都得自己造轮子。 Agent Vault 的思路 Infisical 新开源的 Agent Vault 把这条路做成了通用产品。它的核心设计原则只有一条：Agent 永远拿不到金库里的密钥，只能通过代理间接使用。 ...

如果你在生产环境里接入了两个以上的 LLM 提供商（OpenAI、Anthropic、Gemini、Groq……），大概率已经踩过这些坑：供应商的 API 格式不统一、重试逻辑要写 N 份、想把 Claude 和 GPT 的调用日志合并看也做不到、换个供应商代码要改一大坨。 这就是 AI Gateway 存在的意义——在你和所有模型供应商之间加一层抽象，对外暴露统一的 OpenAI 兼容 API，你改供应商只需要改配置，不用动业务代码。 这个赛道最知名的是 LiteLLM（Python），今天要聊的是一个用 Go 写的竞争方案——GoModel，4 个月时间，511 Stars，GitHub 最后一次提交就在昨天。 背景：多供应商困境 先说个真实的场景。 你做 AI 产品，接入了 GPT-4o 做主力、Claude Sonnet 做复杂推理、Gemini 2.5 Flash 做快速摘要。三个供应商，三套 SDK，三套错误处理，三套重试策略，三套计费逻辑。然后产品经理说：「能不能把这个月各模型 token 消耗做个报表？」 你翻了三天日志，发现各家日志格式完全不一样，计量单位都不统一。这就是为什么需要一个 AI Gateway——它把所有调用收敛到一个统一的接口，同时帮你把日志、计费、缓存这些事情做好。 LiteLLM 是这个方向最成熟的开源方案，但它是 Python 写的，GIL 限制了并发能力，而且配置相对复杂。 GoModel 是什么 GoModel 是来自波兰华沙的独立开发者 Jakub（GitHub @santiago-pl）的作品，2024 年 12 月开始开发，定位是高性能 AI Gateway，用 Go 编写，对外暴露完整的 OpenAI 兼容 API。 核心特性： 11 家供应商支持：OpenAI、Anthropic、Google Gemini、xAI Grok、OpenRouter、Z.ai、Azure OpenAI、Oracle Cloud AI、Ollama、vLLM OpenAI 兼容端点全覆盖：/v1/chat/completions、/v1/embeddings、/v1/files、/v1/batches 双层响应缓存：精确匹配缓存 + 语义缓存（基于向量相似度），官方案例中语义缓存将命中率从 18% 提升到 60-70% Guardrails：可配置的请求/响应过滤管道 Provider Passthrough：原生端点透传（/p/{provider}/...），绕过网关直接访问供应商特性 Admin API：用量统计、Token 消耗追踪、审计日志 说白了就是：LiteLLM 能做的 GoModel 基本都能做，但用 Go 写的，高并发下性能更好，内存占用地更低。 ...

你选了一个Kimi K2的第三方API提供商，省了30%的成本。结果线上agent跑着跑着开始乱调用工具——你以为模型有问题，实际是API供应商的工程实现挖的坑。 这不是段子，是真实发生的。MoonshotAI最近开源的 K2 Vendor Verifier（551 Stars）干了一件事：他们对市面上的Kimi K2第三方API做了套标准化精度测试，结果发现同样一个模型，经不同厂商分发后，toolcall精度可以从100%掉到76%。 背景：K2的核心能力就是toolcall Kimi K2是MoonshotAI发布的专注于Agent场景的LLM。什么叫"专注Agent"？说白了就是它的核心能力不是聊天，而是toolcall——让模型学会调用外部工具完成复杂任务。 这类能力对精确度要求极高。一次toolcall失败，可能导致整个agentic loop崩溃： 工具ID格式错误 → 解析异常 JSON Schema不匹配 → 调用参数丢失 触发时机错误 → 该调工具时模型"停了" 所以K2的toolcall精度不是"体验问题"，是"能不能用"的问题。 测试方法：和官方API同题作答 K2VV的测试思路很直接：用同一套4000条测试请求，分别走官方MoonshotAI API和各第三方厂商API，对比toolcall结果。 核心指标就两个： ① tool_call_f1（触发精度） 模型该不该调用工具、该调用哪个工具。用F1分数衡量，和官方API对比。 ② schema_accuracy（Schema符合度） 模型决定调用工具了，但它生成的JSON参数对不对。用通过schema验证的比例衡量。 结果？差异触目惊心。 数据说话：同卷不同分 K2-thinking版本（temperature=1.0，max_tokens=64000）的成绩单： 厂商 schema_accuracy MoonshotAI（官方） 100% Fireworks 100% InfiniAI 99.89% SiliconFlow 98.96% GMICloud 95.95% vLLM（自托管） 87.22% DeepInfra 86.91% GoogleVertex 85.76% Together 84.63% vLLM自托管版本，schema精度只有87%——意味着每100次toolcall，13次生成的参数过不了schema校验。这在生产环境里是什么概念？你的agent每天跑1000次toolcall，有130次会在运行时崩溃。 K2-0905-preview版本（temperature=0.6）的数据更明显： 厂商 schema_accuracy MoonshotAI（官方） 100% SGLang（自托管） 73.13% vLLM（自托管） 76.00% Volc 72.86% SGLang和vLLM这两个最流行的开源推理框架，精度都没过80%。 根因分析：三个工程坑 K2VV的维护者直接点名了三个最常见的问题： ...

一个 27B 参数的大模型，在一张 2021 年买的游戏显卡上能跑多快？ Lucebox 团队给出了一个让很多人没想到的数字：207.6 token/s。用的还是 Qwen3.5-27B 官方模型，不是蒸馏，不是 INT8 量化残血版——就是 Q4_K_M 量化版本，目标加草稿模型全部加载在一张 24 GB VRAM 的 RTX 3090 上。 这个成绩靠的不是等英伟达下一代消费级显卡，而是对解码算法本身动刀子。 为什么自回归解码是瓶颈 大多数人聊 LLM 推理优化，会先想到量化、KV cache 压缩、batch 并行。但对单卡消费级 GPU 来说，这些都已经做到头了——Q4_K_M 量化能压缩到约 16 GB，再压下去效果肉眼可见地降。 问题出在自回归解码本身。每生成一个 token，GPU 要完整跑一遍 27B 参数的前向传播。27B 参数在 Q4_K_M 下大约 16 GB，VRAM 带宽是 936 GB/s——每次解码都要把这 16 GB 从显存读一遍，理论带宽利用率撑死不到 20%。这是机械式的物理限制，不是软件优化能绕过去的。 speculative decoding（投机解码）解决的就是这个问题：用一个小草稿模型一次生成多个候选 token，再用大模型一次验证整串。如果草稿猜得准，大模型只跑一次就能吐出五六个 token，GPU 计算资源用得更充分。 DFlash：块扩散草稿，比 Chain EAGLE 更容易命中 主流投机解码方案是 EAGLE（及其 chain 版），草稿模型做自回归预测，每步大约能接受 3 个 token。DFlash（2026） 换了个思路：用块扩散（block diffusion） 做草稿——一个 5 层非因果的去噪网络，同时预测多个位置，而不是逐个生成。 ...

如果你只有一台 Mac 电脑，想从单张图片生成 3D 模型——直到今天，这基本上是个伪需求。市面上最好的开源图片转 3D 技术，几乎全部围绕 NVIDIA CUDA 构建，买不到合适的硬件就等于玩不了。 这个局面正在被打破。 TRELLIS.2 是微软 2025 年发表在 CVPR 的论文提出的图片转 3D 方法，在 GitHub 上有 1.2 万星，官方仓库清一色 CUDA 代码。近日有个开发者把它完整移植到了 Apple Silicon，M4 Pro 上 3.5 分钟就能生成一个 40 万顶点的网格模型，全程跑在苹果自研芯片上，不需要半块 NVIDIA 显卡。 移植的核心思路：替换掉 CUDA 依赖 TRELLIS.2 依赖好几个 CUDA 专用的库，官方版本开箱即用但根本不支持 Metal。这不是简单的编译选项问题，而是代码里大量硬编码了 .cuda() 调用和 CUDA 核函数。 移植的思路很直接：找到每一个 CUDA 依赖，用 PyTorch 原生功能或纯 Python 实现替换。 主要替换关系如下： 原始（CUDA） 移植版本 用途 flex_gemm backends/conv_none.py 子流形稀疏 3D 卷积，通过 gather-scatter 实现 o_voxel._C hashmap backends/mesh_extract.py 从双体素网格提取网格面 flash_attn PyTorch SDPA 稀疏变换器的注意力机制 cumesh Stub（跳过） 网格孔填充与简化 nvdiffrast Stub（跳过） 可微分光栅化（仅影响纹理导出） 稀疏 3D 卷积的替换是个技术亮点。原始 flex_gemm 做的是子流形稀疏卷积——3D 生成任务中只有物体表面有数据，不需要对整个空间做卷积。移植版本用 Python 构建空间哈希表，对每个活跃体素收集邻域特征，通过矩阵乘法应用权重，再把结果 scatter 回去。neighbor maps 做了缓存避免重复计算。 ...

真实案例引入：一次生产事故揭开的盖子 2025 年中，某团队的 AI 编码助手在凌晨两点突然崩溃——他们在 Ollama 上跑的好好的 GPT-OSS 20B 模型突然报 GGML tensor type 不支持的错误。同一模型，在 llama.cpp 上运行完全正常。 这不是孤例。2025 年 GitHub 上关于 Ollama 的 issue 爆发式增长：#3185（许可证问题，400 天无回应）、结构化输出失效、视觉模型崩溃、多版本 GGML assertion crash。社区反复报告同一个事实：Ollama 自 2025 年中从 llama.cpp 后端切换到自研 ggml 分支后，引入了 llama.cpp 早已解决的 bug。 这场崩溃的根源，要从 Ollama 的诞生说起。 背景：Ollama 的起源与商业模式 Ollama 由 Jeffrey Morgan 和 Michael Chiang（曾主导 Docker GUI 工具 Kitematic）于 2021 年创办，入选 Y Combinator Winter 2021，2023 年正式公开。核心卖点是"Docker for LLMs"——一条命令下载运行模型。 然而，Ollama 的全部推理能力来自 llama.cpp：Georgi Gerganov 于 2023 年 3 月用一晚上 hack 出来的 C++ 推理引擎，让 LLaMA 模型首次能在消费级笔记本上运行。llama.cpp 如今 GitHub 104,280 stars，450+ 贡献者，是几乎所有 GGUF 工具的底层依赖。 ...

引言：一个「只修皮毛」的工具为什么获得 16 万星 2023 年，Ollama 以「Docker for LLMs」的定位进入开发者视野——一行命令下载模型，本地跑起来。这种低门槛让它迅速积累了 16.9 万 GitHub Stars，成为本地运行大模型的事实标准。 然而，它的底层问题正在被更多开发者意识到：许可证归属争议长达一年未处理、自研后端性能反而低于 llama.cpp 30-50%、模型格式产生供应商锁定……这些问题在 Hacker News 上引发了大量讨论，HN 热帖当天获得 603 分。 本文不是「二选一」的观点稿，而是一次基于事实的深度拆解——为什么 Ollama 的工程实践存在系统性缺陷，以及真正值得投入生产的替代方案是什么。 背景：llama.cpp 才是本地 LLM 的真正引擎 要理解 Ollama 的问题，先要了解它依赖的底层技术。 llama.cpp 由 Georgi Gerganov 于 2023 年 3 月用一个晚间编写，最初只是一个将 LLaMA 模型跑在消费级硬件上的 C++ 推理引擎。它的核心创新是 GGUF 量化格式——让数十亿参数的大模型能够在普通电脑的 CPU 和 GPU 上高效运行。 今天，llama.cpp 拥有： 104,116 Stars，450+ 贡献者 MIT 许可证，完全开源 2026 年 2 月，ggml.ai 项目并入 Hugging Face，确保长期可持续发展 可以说，没有 llama.cpp，就没有本地 LLM 生态的今天。 问题是：Ollama 几乎从未承认这一点。 问题一：长达 400 天的许可证争议 Ollama 于 2023 年 6 月公开，基于 MIT 许可证开源。然而，其二进制发布包中包含 llama.cpp 代码，却从未附带 llama.cpp 要求的版权声明——这是 MIT 许可证的唯一主要义务。 ...

真实案例引入：深夜 11 点的 PR 终于有人 review 了 王海（化名）是一家中型 SaaS 公司的后端工程师。团队采用 monorepo 结构，每到周五晚上，积压的 PR 少则七八个，多则十几个。手动 review 耗时耗力，完全丢给 AI review 工具又担心质量。 他尝试的解法：用 Claude Code Routines 配置了一个每周五 20:00 自动运行的代码审查 routine。Claude 会主动拉取本周所有未合并的 PR，按模块分类，生成结构化 review 报告推送到 Slack。第二天早上，他只需要花 20 分钟过一遍 AI 的报告，重点关注高风险变更。 这不是科幻场景——这是 Claude Code Routines 已经支持的真实能力。 背景：Claude Code 不只是交互式工具 Claude Code 最早以"终端里的 AI 搭档"定位——你提需求，它在本地仓库里翻代码、写文件、跑测试。但这套模式的本质还是被动响应：你在，它才动。 2026 年 4 月 14 日，Anthropic 正式发布 Routines 功能（官方文档，HN 热度 700+），将 Claude Code 的能力边界从"交互式"扩展到"自动化"。你可以定义一组任务，让它按时间表、按 GitHub 事件、或按 API 调用触发，在 Anthropic 托管的云端基础设施上自动执行——不需要保持终端打开。 框架核心拆解 触发模型：三种自动化路径 Routines 支持三种触发机制，覆盖了开发者日常中最常见的自动化场景： ...

真实案例引入 2025 年后，扩散语言模型（Diffusion Language Model，DLM）成为了 LLM 架构探索的热门方向。与自回归（Autoregressive，AR）模型逐步生成 token 不同，DLM 通过逐步去噪的方式并行生成整个序列，理论上能带来更高的硬件利用率和推理吞吐量。然而在实践中，开发者们很快发现了一个根本性问题：扩散模型的生成质量总是落后于同规模的自回归模型。 这一问题在真实部署场景中尤为突出。以 SGLang 团队在 2024 年的基准测试为例，SDAR-8B 在 LiveCodeBench 上的通过率仅为 16.6%，而 Qwen3-8B（AR 模型）则达到了 50.3%——差距超过 3 倍。即便在数学推理（MATH-500）上，SDAR 的 78.6% 也明显低于 AR 的 95.8%。质量差距使得企业在生产环境中选择扩散模型时顾虑重重。 I-DLM（Introspective Diffusion Language Models）的研究者将这个质量 gap 归因于一个被忽视的问题：自省一致性（Introspective Consistency）。AR 模型天生具备这一特性——模型会认可自己的生成结果（自省接受率约 0.98），而标准扩散模型的这个指标仅为 0.57-0.70。这种"自我怀疑"导致扩散模型难以在复杂推理任务上稳定发挥。 框架核心拆解 自省一致性：问题的根源 I-DLM 论文将自省接受率定义为：模型在位置 i 生成的 token，在后续去噪步骤中仍然被模型认可的概率。AR 模型由于其因果注意力机制和逐 token 生成的特性，天生具备高自省一致性——模型"相信"自己逐步生成的内容。 扩散模型的问题在于双向注意力和多 token 并行生成：模型在某个位置生成了一个 token，但后续步骤中可能因为看到更多上下文而"反悔"，导致生成结果不一致。这种不一致性在长推理链（如数学证明、代码生成）中被放大，最终表现为质量落后。 Introspective Strided Decoding（ISD） I-DLM 提出了 ISD 算法，在单次前向传播中同时完成生成和验证两个操作： # ISD 核心逻辑伪代码 # 每次前向传播: # 1. 从 MASK 位置生成 N 个新 token（proposal 分布 q） # 2. 验证之前生成的位置（anchor 分布 p） # 3. 通过 min(1, p(x)/q(x)) 决定接受/拒绝 # p/q 接受准则数学保证输出符合基础 AR 分布 关键在于 p/q 接受准则：通过比较 proposal 分布和 anchor 分布的概率比值，ISD 能够数学上保证最终输出与目标 AR 分布一致。这解决了扩散模型"自我不一致"的核心问题。 ...