Back to blog
    运行时感知的数据准备:为什么你的管道应该知道模型将在哪里运行
    on-device-aidata-preparationfine-tuningedge-aienterprise-aisegment:enterprise

    运行时感知的数据准备:为什么你的管道应该知道模型将在哪里运行

    当前 AI 管道假设先训练后部署。对于端侧 AI,工作流是教师模型 → 蒸馏 → 量化 → 运行时约束。理解目标运行时的数据准备能产生从根本上更好的模型。

    EErtas Team·

    大多数 AI 数据准备管道对模型最终将在哪里运行一无所知。它们生成一个 JSONL 文件。该文件被交给训练脚本。训练好的模型被部署到某处。数据团队和部署团队独立运作,仅通过文件格式连接。

    当训练和部署在类似硬件上进行时,这种方式可行。当部署目标是具有 8GB 共享内存、512 token 上下文窗口和 50ms 延迟预算的 Qualcomm Snapdragon NPU 时,这种方式就行不通了。

    对于端侧 AI,部署目标应该塑造数据集——而不是反过来。

    导致端侧模型失效的脱节

    以下是典型的企业 AI 管道:

    1. 数据团队准备训练数据(优化完整性和覆盖范围)
    2. ML 团队微调模型(优化基准准确率)
    3. 部署团队量化并导出(优化硬件适配)
    4. 端侧性能比云端基准低 15-25 个百分点

    第 4 步不应该是一个意外。但它始终如此,因为第 1-3 步在运行时没有了解第 4 步的部署约束。

    数据团队包含 4,000 token 的示例,因为它们很全面。ML 团队用所有数据训练,因为更多数据通常有帮助。部署团队量化为 Q4 并将上下文截断为 512 token。模型已经在它在生产中永远无法使用的模式上进行了训练。

    这不是部署问题。这是一个在部署时浮现的数据准备问题。

    运行时感知数据准备的含义

    运行时感知的数据准备意味着从一开始就将部署约束编码到数据管道中。在策划第一个训练示例之前,你需要定义:

    目标硬件配置:

    • Qualcomm Hexagon NPU(移动端):0.5B-1B 模型,4-8GB 内存,15-50ms 延迟
    • Qualcomm XElite Snapdragon(笔记本):3B-8B 模型,16-32GB 内存,50-200ms 延迟
    • Apple Neural Engine:0.5B-3B 模型,统一内存架构
    • Intel NPU:1B-3B 模型,集成在 Core Ultra 处理器中
    • NVIDIA Jetson(边缘):3B-14B 模型,专用 GPU 内存

    上下文窗口预算: 不是模型的最大值——而是在内存和延迟约束下的实际限制。0.5B 模型在技术上可能支持 2048 token,但在 512 token 时运行速度快 4 倍,使用内存少 60%。你的生产上下文窗口决定了训练数据长度分布。

    量化级别: Q4(4-bit)将模型大小减少 75% 但增加了对边缘情况的敏感性。Q8(8-bit)保留更多精度但需要更多内存。量化级别影响哪些训练模式能在压缩中保留。

    输出格式: JSON 分类?自由文本响应?结构化提取?输出格式约束了词汇表、响应长度和有用示例的类型。

    约束如何流入数据决策

    一旦定义了运行时配置,每个数据准备决策都映射到一个约束。

    长度过滤。 如果你的生产上下文窗口是 512 token,你的训练示例输入应低于 400 token(留空间给输出)。移除或截断任何更长的内容。这不是数据丢失——这是与生产现实的对齐。

    复杂度校准。 在 Q4 量化下运行 0.5B 模型的 Hexagon NPU 可以可靠地处理单步分类、基于模板的提取和短文本生成。它无法可靠地处理多步推理、条件逻辑链或开放式摘要。你的训练数据应该匹配运行时能交付的内容。

    词汇表范围。 计算训练数据中的唯一 token 数量。对于 0.5B 模型,如果训练词汇表超过 15,000 个唯一 token,你的嵌入容量分散得太薄了。通过标准化术语、移除罕见变体和合并同义词来减少词汇量。

    延迟感知的示例设计。 如果你的延迟预算是 50ms,模型需要在该窗口内生成输出。在低于 1B 模型的典型端侧吞吐量为 20-40 token/秒下,这是 1-2 个 token。你的训练数据应该产生在该范围内可测量的输出,或者你的批处理策略需要考虑更长的生成时间。

    实践中的变化

    采用运行时感知数据准备的团队报告了一致的改进:

    减少迭代周期。 没有运行时感知,团队通常需要 4-6 个数据-模型-部署周期才能达到可接受的端侧性能。将运行时约束从一开始编码,这降至 2-3 个周期。每个周期涉及数据准备、训练、量化和端侧测试——节省了数周的工程时间。

    更少的部署意外。 最昂贵的结果是模型通过所有云端基准但在端侧失败。运行时感知的数据准备消除了由训练-部署不匹配导致的故障类别。

    更好地利用模型容量。 在运行时感知数据上训练的 0.5B 模型将其有限的参数用于生产中重要的模式。没有容量浪费在模型永远不会在端侧执行的模式上。

    本地部署约束

    对于企业团队,还有一个额外要求:数据准备必须在本地进行。如果你的源数据包含临床记录、法律文件或金融交易,你不能将其发送到云标注工具——即使最终模型在端侧运行。

    这创建了一个三环境工作流:

    • 本地:数据准备(敏感数据不离开大楼)
    • 云端:在 GPU 集群上进行模型训练(仅模型权重和准备好的数据集,不含原始源数据)
    • 端侧:模型部署(推理数据留在设备上)

    数据准备环境必须是运行时感知的,同时也是隔离的。这种组合——运行时感知加上本地操作——是大多数企业团队所缺少的。

    Ertas Data Suite 如何处理这个问题

    Ertas Data Suite 是一个完全在本地运行的原生桌面应用程序。配置数据准备项目时,你指定目标部署:

    • 设备类别(移动 NPU、笔记本、边缘设备、数据中心)
    • 目标模型大小(0.5B、1B、3B、8B、14B+)
    • 上下文窗口预算
    • 量化级别

    Clean 模块自动调整质量评分阈值以匹配这些约束。Augment 模块生成针对目标模型容量校准的合成数据。Export 模块验证最终数据集与指定部署目标的兼容性。

    没有数据离开大楼。管道知道模型将在哪里运行。企业端侧 AI 团队最需要的两个要求——隐私和运行时感知——在一个工具中得到处理。

    预约探索通话 讨论针对你的端侧 AI 部署的运行时感知数据准备。

    Turn unstructured data into AI-ready datasets — without it leaving the building.

    On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.

    Keep reading