单设备十五万上下文预填充压到毫秒

本地部署的性能边界又被推进了一格：单台 DGX Spark 跑稠密版 Qwen3.8-27B（不是蒸馏的 Flash 版），借优化过的缓存算法与 StairCut 方法，约 15 万 token 的上下文预填充压到毫秒级，解码速度按任务不同在 50 到 90 token 每秒之间。

发布者还贴了连续运行五小时的记录——让模型反复设计一座宝塔园林并持续迭代实现新想法，中途不停机。

三个数字里最值钱的是预填充。长上下文曾卡在"读进去"这一步：文档堆到十几万 token，光等它读完就要几十秒，模型还没开口人的耐心先没了；预填充毫秒化后，把整个代码库或整套文档一次性摊进上下文成了默认操作。解码速度决定迭代节奏，五小时不停机则回答了另一个问题——过夜自主任务能不能托付给它。

这组数据给出一条实用判断线：单设备本地部署已能承接"长上下文加长时程"的负载，不必事事外包云端 API。对数据不能出厂的团队，可用性与合规本是同一道题，如今性能这半边也补齐了，剩下的多是运维成本的账。

评估本地化方案盯三个数：多大文档的预填充要等多久、稳定解码速度多少、连续运行多久需要干预。三项对得上这类实测，本地与云端就从"敢不敢"变成"划不划算"。