码农早餐 · 2026-09-15
今日头菜：35KB 提示词迁到自托管 Ollama：能跑，但 3 分钟就开始没油。另有 4 条快讯：PyO3 实战：JSON 转换可以比解析本身还慢；RX 9060 XT 跑通 CUDA：ZLUDA + HIP SDK 6.4 的一份可复现清单；等。
35KB 的 preprompt 从 Opus 搬到自托管 Ollama 上，27B 本地模型 3 分钟就开始在工具调用里打转、反复读取。能跑不等于能扛活，这种迁移最该先算的是上下文这笔账。
35KB 提示词迁到自托管 Ollama：能跑，但 3 分钟就开始没油
把一份 35KB 的 preprompt 从 Opus 搬到自托管的 Ollama 上，会发生什么？原文给的答案挺朴素：在 frontier API 上跑得好好的提示词，到了本地模型上直接散架。这不是「本地模型不行」的结论，而是一份踩坑清单的开头。
先说硬件前提，因为这决定了后面所有现象。作者的机器是 AMD Ryzen AI MAX+ 395，128GB 内存，其中 32GB 留给宿主系统，剩下的全分给推理。他瞄准的是 abliterated（去拒答）的开源权重 27B 模型，目的是绕开前沿厂商在网络安全话题上的安全拒答——按他的说法，这些过滤器让防守方没法去发现漏洞，因为「发现漏洞」本身就被归进了 hacking 相关。他想验证的是：本地 27B 能不能扛住他那些上下文最贵的 agent。
答案是不能直接扛。原文记录得很具体：当他把在 frontier provider 上工作良好的大 preprompt 搬过来，Ollama 在 3 分钟内就开始「没油」，agent 在反复的工具调用里打转、重复读取。注意这个 3 分钟——它不是模型答得慢，是上下文被大提示词吃掉之后，留给对话和工具结果的空间不够了，于是 agent 陷入循环。你在云端习以为常的那种「提示词随便堆、反正上下文窗口大」的用法，换到本地就是另一笔账。
这里有个容易被忽略的分界：作者关心的其实不只是「我的数据会不会被拿去训练」，而是会话元数据——你怎么一步步把 AI 逼到解出问题的那套直觉，本身就是稀缺品。他的原话是，agent session 就是你处理最难问题的完整记录，如果别人手里有副本，代价是什么？这个视角比「别上传隐私」更狠一层：值钱的不是数据，是你调试 agent 的方法论。同一篇文章里他提到，前沿厂商在被问到数据留存时给出的最强防御性说法是「无法排除」，而留存和训练 pipeline 都不可审计——不可审计这件事，本身就是自托管的理由，跟模型强不强没关系。
横向比一下就更清楚了：同样的 35KB 提示词，在 Opus 上一路畅通，在本地 27B 上 3 分钟熄火。差距不在「谁更聪明」，而在你能给模型留多少上下文预算。云端是你花钱买窗口，本地是你用显存换窗口，128GB 里还要先切 32GB 给系统，剩下的每一 GB 都在跟模型权重抢地方。所以「自托管省钱」这个直觉要反过来想：省下的是 API 账单，付出的是你得亲手做上下文工程，还得接受拒答之外的另一种失败——不是拒绝回答，是答着答着开始原地转圈。
对写代码的人，这件事的直接含义有几层。一是如果你在考虑把 agent 迁到本地，别拿小提示词试水，要拿你最长的那个去压测，3 分钟这个量级就是你的验收线。二是 abliterated 权重解决的是拒答问题，解决不了上下文预算问题，这两件事经常被混为一谈。三是工具调用密集的 agent 对本地部署最不友好，因为每一轮工具结果都在吃窗口，循环一旦起来就是指数级的浪费。
原文没说后来怎么样——没有交代他是否调小了提示词、换了量化、还是加了显存配置后跑通。这一点得诚实标出来：目前能确认的只有「第一次尝试失败了，失败方式是 3 分钟内耗尽」。
💡 主厨说：他真正想迁走的不是提示词，是那套「怎么把 AI 逼出答案」的会话记录——按他的说法，这玩意儿比代码本身更值钱。所以本地部署的第一道坎不是模型强弱，是你愿不愿意自己养上下文预算。
来源：
PyO3 实战：JSON 转换可以比解析本身还慢
用 Rust 写个 JSON parser 再包成 Python 库，听起来是标准操作。但真正决定这个移植值不值的，是出口那一段：10 万个值，就要在边界上创建大约 10 万个 Python 对象，这一步的开销可以超过解析本身。写 Rust 快是容易的那一半，Rust 值转成 Python 对象的那一半才决定成败。
流程本身四步：写普通 Rust 模块，用 #[pyfunction] 和 #[pymodule] 两个宏标注，交给 maturin 编译成 shared library（.so / .dylib / .dll）丢进 virtualenv，然后照常 import。#[pyfunction] 这类属性宏接近 Python 的装饰器，它会重写函数，加上让 Python 能调用的胶水，并在边界处理类型转换和引用计数。Pydantic v2 的核心 pydantic-core 就是这么建的，你每次做数据校验，跑的就是这套东西。
坑在返回值上。parser 产出的是一棵 Rust enum 树，Python 根本看不见；.into_pyobject(py) 才把整棵树走一遍，重建成本地 Python 对象——每个 object 一个 dict、每个 array 一个 list、每个叶子一个 float 或 str，靠实现 IntoPyObject trait 递归完成。这一切都发生在解析彻底结束之后。错误也要翻译：给 JsonError 实现 From 转成 PyErr，? 就能把带 position 的解析失败变成带 offset 的 ValueError；std::io::Error 自带转换，路径不存在直接抛 FileNotFoundError。
所以，如果你要移植的 Rust 函数返回的是标量，直接上，边界小到可以忽略；返回大结构，转换就是真正的成本，也是 parser 快起来之后下一个该优化的地方。预分配 PyDict 只能抠点边际收益，更大的赢法是架构上的：调用方不会碰整棵树，就别急着物化整棵树，改回一个 lazy 的、Rust 支撑的 view，按需生成 Python 对象。上手渠道原文也给了：#[pyfunction] 签名里 py: Python<'py> 是访问解释器的 token，Bound<'py, PyAny> 相当于 Rust 侧的 PyObject，PyResult<T> 就是 Result<T, PyErr>。移植前先 profile 边界，别只 profile 算法。
来源：
RX 9060 XT 跑通 CUDA：ZLUDA + HIP SDK 6.4 的一份可复现清单
有人在 GitHub 上放出了一套 Windows 上的 CUDA 兼容方案：用 ZLUDA 把 CUDA 调用翻译到 AMD 的 HIP/ROCm 上，配 AMD HIP SDK 6.4、ZLUDA v6-preview.69、LibTorch 2.3.0 + cu118。它明确标注的验证硬件只有一块：Radeon RX 9060 XT（gfx1200，RDNA4）。其他 AMD 卡在脚本里只会被标成 unverified candidate——能识别，不等于能跑，这个区分做得挺老实。
能跑通的东西列得比较具体：nvcuda、cuBLAS、cuBLASLt、cuSPARSE、cuFFT 都过了 cuda_check；一个 2,216,347 参数的 PPO 网络完成了前向推理、PPO 学习和优化器步骤；一次干净的验证迭代跑了 65,536 timesteps。性能上做了一次 A/B，每种 runtime 跑 10 次迭代、丢掉第一次当预热，上游公开路径中位数 13,278 SPS，对比某个私有 overlay 的 12,876——那个 overlay 反而慢约 3.03%，所以默认走上游。注意这里说的是「这套配置下」，不是「CUDA 在 AMD 上普遍可用」。
真正该看的限制是 cuDNN 那一栏：稳定版 Windows HIP SDK 不带 MIOpen 那套 AI 库，所以依赖卷积、依赖 cuDNN 的程序跑不起来，得换 nightly 或者自己补。作者也直说了，密集 GEMM 类的 LibTorch 训练不一定要 cuDNN，验证用的 PPO 就是没它跑完的。上手路径是 git clone 之后跑 install.ps1——它会检测 GPU 的 gfx 目标、校验驱动和 HIP SDK、下载固定版本的 ZLUDA 和约 2.66 GB 的 LibTorch、核对 SHA-256，最后生成 runtime 配置并跑一遍 cuda_check；不需要 LibTorch 就加 -SkipLibTorch。之后 run-zluda.ps1 -Program xxx.exe 会把兼容 DLL 铺到目标程序旁边再启动。
对写代码的人来说，这事的意义不在于「AMD 能跑 CUDA 了」这种一句话结论，而在于它把「哪些层被替换了」摊开了：CUDA 驱动层走 ZLUDA，数学库分别落到 rocBLAS、hipBLASLt、rocSPARSE。你如果手上是 NVIDIA 卡，基本不用动；如果你在考虑用 AMD 卡省显存钱、又恰好卡在 CUDA 依赖上，先对着这张覆盖表看自己用的是哪几个库——只要碰到 cuDNN，当前这条路径就得先放一放。
来源：
一个免权限 App，就能 root 三星小米等机型
原文只有标题和一句说明：一个不需要任何特殊权限的 Android App，可以在三星、小米等厂商的设备上拿到 root。没有披露具体机型、系统版本和利用链条，所以现在能确认的只有「有这件事」，值不值得细看还得等细节。对写代码的人来说，这事的直接意义不在刷机，而在它戳中的那类问题：厂商定制的系统服务里，只要有一个环节把外部输入当成了可信数据，提权就只是时间问题。看这类研究，我习惯先看它到底改了什么、卡在哪个版本，再看热闹。
来源：
AI agent 攻击 RubyGems：这次只有一句指控
前几天我们聊过这条，当时原文只有一句指控，我提醒过先别当实锤。今天再看，还是同一句话：恶意 AI agent 攻击了 RubyGems.org。没有攻击手法，没有 agent 的行为模式，也没有任何数字。所以判断不变，证据依旧薄——但这事值得盯着，因为包仓库一旦被投毒，中招的是所有拉依赖的人。原文只有标题，先记下这个方向。
来源：
你手头那些长提示词的活，敢不敢也搬去本地 27B 跑一遍，还是继续烧 API？明早 8 点见。
本期从过去 24h 的 X / Hacker News / GitHub Trending 共 74 条信息中挑出 5 条（全天逐小时采写、经事实校对后于晨间选编）。内容由 LLM 辅助生成，每条均附原始来源链接，重要决策请交叉验证。
微信扫码关注「码农早餐」
每天早 8 点推送到微信，不用记网址。关注后回复「价格」，拿大模型价格与退役时间速查表。
喜欢这篇？订阅每日推送
每天 8:00 帮你挑好 AI 圈最重要的 5-10 条，说人话、看得懂、不浪费时间。
本页内容由 LLM 自动聚合 + 解读生成，每条均有原始来源链接，建议交叉验证。