
运行时感知的数据准备:为什么你的管道应该知道模型将在哪里运行
当前 AI 管道假设先训练后部署。对于端侧 AI,工作流是教师模型 → 蒸馏 → 量化 → 运行时约束。理解目标运行时的数据准备能产生从根本上更好的模型。
大多数 AI 数据准备管道对模型最终将在哪里运行一无所知。它们生成一个 JSONL 文件。该文件被交给训练脚本。训练好的模型被部署到某处。数据团队和部署团队独立运作,仅通过文件格式连接。
当训练和部署在类似硬件上进行时,这种方式可行。当部署目标是具有 8GB 共享内存、512 token 上下文窗口和 50ms 延迟预算的 Qualcomm Snapdragon NPU 时,这种方式就行不通了。
对于端侧 AI,部署目标应该塑造数据集——而不是反过来。
导致端侧模型失效的脱节
以下是典型的企业 AI 管道:
- 数据团队准备训练数据(优化完整性和覆盖范围)
- ML 团队微调模型(优化基准准确率)
- 部署团队量化并导出(优化硬件适配)
- 端侧性能比云端基准低 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 分类?自由文本响应?结构化提取?输出格式约束了词汇表、响应长度和有用示例的类型。