Strata v0.1.39 发布：长提示与解码提速，并接入 OpenAI Responses API 供 Codex CLI 使用

面向消费级硬件的本地推理引擎 Strata 于 2026 年 10 月 4 日发布 v0.1.39。官方变更清单的主线是解码与长提示提速、可选的多请求并发、老显卡与老 CPU 的实验性支持，以及新增 OpenAI Responses API 接口，让 Codex CLI 可以直接接在本地引擎上使用。

这次发布的是什么

Strata 是一个把大模型搬到本地消费级硬件上跑的开源推理引擎项目，仓库自带的说明写的是「让 Qwen3.8-Flash-Next 跑在任意消费级硬件上：Windows / Linux 一键安装，Strata 推理引擎，本机提供 OpenAI/Anthropic API，可选图像输入」。项目 2026 年 9 月底才公开，10 月 4 日发布了 v0.1.39。

这一版的主线有四条。一是解码更快：verify pass 用更少的 kernel launch 与主机往返完成。二是长提示更快：流式专家环形缓冲改为按字节计量，并且默认开启。三是多了两个可选项：引擎内多请求并发，以及一批由社区贡献、项目方自己没有对应硬件的老显卡与老 CPU 支持路径。四是新加了 OpenAI Responses API 接口（POST 到 /v1/responses），官方写明这个接口的目的是让 Codex CLI 能直接接在 Strata 上。

需要说清楚的定位：这是一个推理引擎而不是一个打包好的桌面应用，它解决的是「显存放不下、但想在本机跑起来」这类问题，收益与代价都高度依赖你手上的硬件。所以下面的每一条，都请对照自己的显卡与内存看。

可用性与限制

• 系统：官方提供 Windows 与 Linux 的一键安装脚本；macOS 不在本次说明覆盖的范围内，以官方说明为准。
• 硬件覆盖：老显卡（NVIDIA Pascal / Volta 一代）、老 AMD 卡、Intel Arc、以及没有 AVX2 的老 CPU 都属于实验性 opt-in 路径。官方明确写了这些硬件他们手上没有，只做了编译检查与单元测试，实测数据来自社区贡献者。
• Intel Arc：走 SYCL 后端，需要在 Linux 上用 Intel oneAPI 从源码构建，官方没有提供预编译的 Intel 引擎，Windows 上也没有构建路径。
• Responses API 的边界：官方写明支持 function tools、tool results、reasoning effort、JSON Schema 与流式事件；不支持 previous_response_id（接口是无状态的，不保存任何内容）、hosted tools 与 reasoning summaries。
• 并发解码是 opt-in，不是默认行为：开启后每个 slot 都会从专家缓存里分走显存，在显存放不下专家的卡上会变慢，所以官方的安装脚本只在「专家基本能放进显存」时才给出建议。
• 服务暴露面：默认监听 127.0.0.1，可以配置 API key；上一版起加入了 Host 与 Origin 检查以及 CORS 处理，MCP 工具与请求监视器都是 opt-in。完整口径见仓库里的 SECURITY.md。
• 网络环境：模型文件下载走 Hugging Face，官方说明中提到会尊重 HF_ENDPOINT 环境变量，也就是说可以指向镜像；国内的实际下载速度以各自网络环境为准。

主要功能

• 解码路径提速：verify pass 减少 launch 与主机往返（sub-warp expert packing、staged inputs、PLE 与 MTP 步骤批处理）
• 长提示提速（默认开启）：流式专家环按字节计量，--prefill auto 自动挑取能填满的最大分块
• 超长上下文：注意力 top-k 超出 register kernel 覆盖范围时改走 per-warp 直方图
• 多卡：安装脚本为两张及以上显卡的配置加入 --remote-expert-opt；三卡以上的 layer split 让各阶段重叠得更好
• 多请求并发（opt-in）：配置文件里的 parallel 或安装脚本的 --parallel N
• 老硬件实验性支持：Pascal / Volta 保留一份 CUDA 12.9 构建的引擎、RTX 20 的 BF16 张量核心开关、老 AMD 的手动构建、Intel Arc 的 SYCL 后端、无 AVX2 CPU 的降 ISA 重编
• 新增 OpenAI Responses API：POST 到 /v1/responses，让 Codex CLI 可以直接使用本地引擎
• 修复与加固：RAM 预算下 prompts 变慢、单个 token 重复的回复会被终止、显存紧张时的加载顺序、容器内存上限检查、机械盘的 I/O 提示、layer_split 校验、Linux CUDA 工具链选择、/load 与 /unload 先读取请求体、tools 值不合法返回 400、消息里字面出现的 think 标签按纯文本处理

技术原理

按官方变更条目整理，这一版的提速集中在「少启动、少往返、少复制」三件事上。

解码阶段，原来一次 verify pass 需要多次 kernel launch 与主机往返，0.1.39 把专家按 sub-warp 粒度打包、输入改为 staged、PLE 与 MTP 两个步骤也做了批处理。官方特别说明：这个 zero-doorbell 的 verify 图只在某一层的全部专家都在显存里时才会启用，所以 12 GB 显存的卡走不到这条路径，大卡上的收益他们没有在本机测到。

长提示这一侧，流式的专家环形缓冲原来是按 slot 数量计量的，现在改成按 pack 的字节数计量，--prefill auto 会挑能把它填满的最大分块。这样做的代价是长提示经过的专家分组变了，输出位不再与 0.1.38 一致；官方给了 teacher-forced 的对比结果来说明质量落在同一区间，并留了 STRATA_RING_BYTES=0 退回旧行为的开关。短提示以及本来就能装进旧分块的提示，仍然走旧的 ring，位结果不变。

多卡方面，--remote-expert-opt 的意义是：对「用到的专家全部在副卡上」的 token，跳过主机侧的那份工作。三张以上显卡的 layer split 则让各阶段重叠得更充分。这两条官方都注明是多卡作者自己的实测，项目方只有一张卡。

老硬件是这一版最容易被误读的部分。Pascal 与 Volta 一代的卡，CUDA 13 已经无法为它们编译，所以安装脚本会额外保留一份用 CUDA 12.9 构建的引擎，只有在你明确选到这类卡、或者显式指定 --cuda 12 时才启用；这也是驱动版本较老时的运行方式。RTX 20 可以用 STRATA_BF16_TC=1 试 BF16 乘积走张量核心的路径，但官方提醒它的求和结果与 cuBLAS 不是按位一致的。老 AMD 卡要按 gfx 代号手动构建；Intel Arc 走 SYCL；没有 AVX2 的 CPU 则由安装脚本降低指令集基线重新编译一次，官方给的时间量级是一次十几到二十分钟。

RAM 预算那条修复也值得一提：0.1.38 判断「要不要读文件缓存之外的专家」时判得太早，而且拿所有模型文件的大小做比较，官方举的例子是一台 96 GB 内存、预算 72 GiB 的机器会判错，导致每次补充都去读盘；0.1.39 改成只统计 RAM 副本之外的专家字节，并在副本建好之后重新判断一次。

实际体验

这一段不写主观实测，给一套你自己就能复现的验证步骤。

第一步，先记录基线。升级前把当前版本号、显卡型号、显存、系统内存、以及你常用的那几个提示长度下的表现记下来。没有基线，后面的提速百分比对你没有意义。

第二步，只在隔离的目录或虚拟环境里升级，不要直接覆盖你正在用的那份。升级走仓库提供的一键脚本，升级完先确认版本号确实是 0.1.39。

第三步，分场景对比，而不是只跑一个短对话。至少分四组：短提示、长提示（几万 token 量级）、多轮对话、以及一次并发多个请求。长提示的收益与空闲显存相关，短提示基本不受影响，只测一项很容易得出相反结论。

第四步，验证「输出是否变了」。长提示这一版的输出位不再与 0.1.38 完全一致，这是官方明确写明的。如果你的下游有依赖可复现性的检查，先用 STRATA_RING_BYTES=0 退回旧行为再评估要不要切过来。

第五步，如果打算接 Codex CLI，按仓库 docs 目录里的 DETAILS.md 给出的配置写 config.toml，然后跑一次带工具调用的会话，确认 function tools、tool results 与流式事件都正常；同时记住这个接口不支持 previous_response_id，任何依赖服务端保存上下文的用法都要自己处理。

项目地址与获取方式

官方仓库在 github.com/Niko1221/Strata，本次版本的发布页是该仓库 releases 下的 tag v0.1.39，许可证为 MIT。安装走仓库里的一键安装脚本（Windows 与 Linux 各一份），模型文件按官方说明准备；涉及到的文档分散在 docs 目录下：BATCHING.md（并发的数字与选项）、OLDER_GPUS.md（社区反馈的老卡数据）、INTEL_ARC.md（Arc 的构建方式）、INSTALL.md 里的老 CPU 小节、以及 DETAILS.md（Codex 的配置示例）。

请只从官方仓库与其发布页获取安装脚本与引擎文件，安装前核对发布页上的版本号与校验值；如果是通过镜像或内网转发安装，同样建议先比对校验值再运行。

适合谁用

• 想在自己机器上跑 Qwen3.8-Flash-Next、但显存放不下常规精度的人：这类项目的价值就在这里，值得花一个下午试。
• 手上有老显卡或老 CPU、又不想为了跑模型换机器的人：0.1.39 把这类路径做成了 opt-in，但要接受「实验性」三个字的含义。
• 想把命令行编码智能体接到本地模型上的人：新增的 Responses API 就是为 Codex CLI 这类用法准备的。
• 需要一次服务多个并发请求的小团队：parallel 是这一版才有的 opt-in 能力，但要先确认显存够不够分摊。
• 不适合：只想开箱即用、不想关心显存与编译选项的人。这个项目的每一步都要求你知道自己的硬件情况。

常见问题

这次提速我在自己的卡上能拿到吗？

看路径和硬件。官方说明里的实测是在单张 RTX 5070 上、与 0.1.38 对比得出的，且明确写了 zero-doorbell 的 verify 图只在整层专家都在显存时才启用，12 GB 显存的卡走不到。你的实际收益取决于空闲显存、提示长度和量化档位，所以按「实际体验」那五步自己测一遍，比照搬数字可靠。

老显卡值得试吗？

可以试，但要按实验性来对待。官方明确写了这些硬件他们手上没有，只做了编译检查与单元测试，实测数据来自社区贡献者；intel Arc 目前只有 Linux 上的源码构建路径，没有预编译引擎。如果你的机器是主力机，建议先在一台不重要的机器上验证，再决定要不要长期用。

升级后输出和以前不一样了，是坏了吗？

不一定。官方写明长提示这一版经过的专家分组变了，输出位不再与 0.1.38 一致，并给了 teacher-forced 的对比结果说明质量落在同一区间。如果你只是聊天，通常感知不到；如果你有依赖可复现输出的流程，用 STRATA_RING_BYTES=0 可以退回 0.1.38 的环形缓冲行为。

能直接当成公网上的 API 服务用吗？

不建议。这个项目的默认形态是本机的推理引擎：默认监听 127.0.0.1，可以配 API key，上一版起有 Host 与 Origin 检查和 CORS 处理，MCP 工具与请求监视器都是 opt-in。对外暴露之前请先读完仓库里的 SECURITY.md，并自行评估鉴权与网络边界，具体配置项以官方说明为准。

并发该开多少？

从小往大试。官方说明里给的例子是 12 GB 显存的卡上，四个请求同时解码时最后一个的等待时间明显缩短，但合起来的吞吐会下降，因为每个 slot 都要从专家缓存里分走显存；所以安装脚本只在专家基本能放进显存时才推荐开启。先用 2 个 slot 测，再看要不要加。

相关工具与内容

如果你的目标是「在本机把模型跑起来」，本站可以顺着两条线看：硬件侧有DGX Spark 64GB 版本这篇，讲的是另一条本地算力的路线；软件侧可以看Ollama 的决策模型，对比一下成熟方案和自己编译引擎这两种选择各自的成本。

想把本地引擎接到日常编码流程里的，可以先看AI 编程分类下的Claude Code与Cursor，再对照Claude Code 的 mods 自定义机制；习惯中文工具链的，CodeBuddy是另一条更省事的路线。图像生成方向的本地部署思路可以参看ComfyUI，背景阅读则推荐AI 聊天助手分类与OLMo-core 3 发布这篇。