软提示时间序列语言模型能在手机上私密运行吗？

这是部署结果，不是临床验证

论文要回答的是：能否把时间序列语言模型从服务器搬到手机上，同时不丢失传感器信号的时间结构。它给出的答案是一个可运行的移植版本：编码器、投影器和语言模型都通过 MLX-Swift 运行时在 Apple 芯片上本地执行，作者称推理过程中没有健康数据离开设备。

这一结论被有意限定得很窄。报告的结果只覆盖实现一致性和设备端上下文开销；作者明确说明，他们没有测试临床性能，也没有测试面向患者的部署。基准测试使用的是 Sleep-EDF 和 ECG-QA 中固定、公开、去标识的研究样本，而不是来自患者的前瞻性 HealthKit 记录。因此，论文证明的是这条流水线能在手机上私密运行，而不是它的回答在新场景中具有临床可靠性。

嵌入为何优于序列化样本

时间序列语言模型把时间序列编码器与语言模型耦合起来，使模型能从原始生理信号生成自然语言描述。在软提示变体中，原始序列被切成固定长度的片段，CNN 片段编码器和 Transformer 把每个片段变成一个嵌入，再由一个学习得到的投影器把这些嵌入映射到冻结的 Llama-3.2-1B 主干模型的输入空间。投影后的向量作为软提示 token 与文本提示的嵌入交错排列——这些连续向量被直接注入模型的嵌入序列，而不是作为词表 token。

另一条路是文本序列化：把原始样本转换成语言模型已经理解的 token。这保留了标准生成路径，但把上下文消耗在信号本身上。论文的基准格式对每四个样本的片段计一个软提示 token（不足一个片段向上取整），而文本序列化对每个原始样本计 3 个 BPE token。这就是约 12 倍 token 差距的来源，也是软提示路径能为实际推理任务留下更多手机有限上下文和内存的原因。

移植版复现了参考实现的输出

迁移模型分两步：先从 PyTorch 到 Python MLX，再从 Python MLX 到 Swift MLX。这样分阶段可以把框架层面的差异与 Swift 移植引入的错误区分开。作者还必须重建部分生成路径，因为 MLX-Swift 的高层生成接口接受的是 token 标识符，而不是预先计算好的输入嵌入。

一致性通过数值方式检验。编码器、投影器、编码器与投影器的融合流水线以及旋转嵌入，在 CPU 后端上与 Python MLX 参考实现的最大逐元素误差在 10⁻⁴ 以内、平均误差在 10⁻⁵ 以内，旋转嵌入为 10⁻³。端到端来看，Python MLX 与 Swift 实现产生了完全相同的贪心解码 token 序列。与 PyTorch 参考实现相比，解码出的答案一致，但在 bf16 算术下中间推理过程的措辞可能不同。这一点很重要，因为整个隐私论证依赖于手机运行的是同一个模型，而不是它的近似版本。

二十段睡眠片段答案完全一致

token 一致并不等于任务准确率，因此作者还把 Sleep-EDF 思维链测试集的前 20 个样本分别跑过 PyTorch 参考实现、Python MLX 参考实现和 iPhone 上的 Swift 移植版。三者都得到 17/20，且对每个预测都一致，包括同样三个错误和同样错误的标签。错误上的一致是更强的信号：只近似参考实现的移植版，理应在模型最不确定的地方最先出现分歧。

测得的 85% 与 Langer 等人在完整测试集上报告的 81.08% 相符，但 20 个样本给出的 95% 区间约为 ±16 个百分点。因此作者把它当作对部署的佐证，而不是准确率估计。他们还指出，软提示似乎没有以质量换取上下文经济性：在这项任务上，参考实现报告 69.88 F1，而同一主干模型在同一信号的文本序列化上微调后为 9.05。

12 导联心电决定可行性

当导联数增加时，token 差距变得具有决定性。两种编码都按导联计费，因此一段 N 个样本的 12 导联心电窗口需要 36N 个文本 token，而软提示只需 12⌈N/4⌉ 个。在每导联 L=100 个样本时，文本序列化已经需要 4,133 个提示 token 和 4.3 GiB 内存；所有更长的窗口（L≥250，至少 9,533 个 token）都被跳过，以避免无法捕获的操作系统内存终止。

软提示跑完了完整的 1,000 样本评估片段，首 token 时间不超过 11.6 秒，峰值内存不超过 4.2 GiB。仅 bf16 主干权重就占其中约 2.3 GiB，其余部分随提示长度增长。实测扫描中的实际截止点是更低的 4,300 token 设备端提示预算，用于在生成期间保留运行时内存余量。

单通道脑电以更温和的方式呈现同一机制。文本序列化在 L=1000 时仍能运行，但其预填充 token 约为软提示分支的 7 倍，因此首 token 时间约大 6 倍（L=1000 时为 14.8 ± 0.8 秒对 2.4 ± 0.1 秒），并且在完整的原始 1,500 样本窗口上仍超出预算。软提示的首 token 时间在所有长度下都不超过 3.0 秒，峰值内存不超过 3.9 GiB。

延迟数字没有回答的问题

延迟和内存数字是五次重复扫描的平均值，因此描述的是重复运行的表现，而不是孤立的冷启动或经过验证的稳态。对脑电而言，L≥1000 时离散度低于均值的 6%，但 L≤500 时达到约 30%，此时较短的预填充主要由固定开销而非计算决定。对心电而言，每个长度上的离散度都是 19–27%，由更快的第一轮运行驱动。

测试期间热状态也发生了变化：脑电在第一轮扫描内从 nominal 升到 serious 并保持在那里；心电在每次运行开始时读数为 nominal，尽管第一轮比最后一轮快 1.6 倍。热降频是心电变慢的一种可能解释，但作者表示并未直接证实。他们没有报告能耗。在截断长度下，软提示分支生成的文本会退化，因为短于 1,000 样本训练片段的窗口属于分布外；报告中的 token、延迟和内存开销不受影响，因为它们取决于输入编码而非解码内容。

部署结论的边界

压缩比是固定的，而不是调优得到的。片段长度和步长沿用 OpenTSLM 参考实现，编码器、投影器和 LoRA 适配器都从其检查点加载；改变压缩比需要重新训练这三者，作者将其描述为对模型的改变，而不是对部署的改变。两个 LoRA 适配器各约占模型参数的 1%，使冻结的主干模型适配心电和脑电任务，所选适配器决定推理时使用的模态特定映射。

作者把 PocketTSLM 定位为实现与部署贡献，而不是新场景下临床性能的证据。他们指出的主要后续步骤，是在真实可穿戴时间序列数据上开展前瞻性评估，并预先定义审查、安全、监测和治理流程。该研究使用公开、去标识的研究数据集，不涉及前瞻性招募、参与者互动、干预或收集可识别的私人信息。

关键在于上下文余量

对于任何权衡设备端生理推理的人来说，论文中最具决策相关性的比较不是准确率，而是什么能装得下。外推到主干模型的 8,192 token 上下文窗口，文本序列化支持约 2,659 个单通道脑电样本（约 53 秒的 50 Hz 数据），但每个心电导联只支持约 212 个样本；而在同样预算下，软提示分别支持约 31,912 和 2,553 个。

这就是值得带走的判断阈值：软提示路径才使多导联、更长窗口的生理输入在手机上可行，而 12 导联心电是文本路径最先失败的场景。20 个样本的睡眠分期一致性把移植版锚定到原始 PyTorch 实现，但这是对一致性的检验，不是临床准确率声明。论文留下的下一个问题是：这种部署能否在真实审查和安全流程下，经受住前瞻性可穿戴数据的检验。

本文引用的文献