现在做 AI 改造的团队越来越多，但仔细看会发现一个有意思的现象：
做智能驾驶的人说：模型不是问题，延迟才是。训练的时候用 720 亿参数，上车的时候蒸馏成几十亿参数，推理延迟压到 50 毫秒以内。然后还得加一层规则引擎兜底，因为神经网络偶尔一抽风，在高速上就是命。
做 AI 编程助手的人说：模型越聪明越好，等 20 秒没关系，关键是生成的代码能不能直接用。
都叫"AI 改造"，诉求完全是两个方向。
这不是技术细节的差异——是范式的分裂。一个拼延迟，一个拼智力。搞混了，代价不小。
一、实时服务型：延迟是生死线
自动驾驶是 AI 实时服务的极端案例，但也因此最能说明问题。
特斯拉 FSD V12 去年搞了一件大事：删掉了 30 多万行 C++ 规则代码，换成端到端神经网络。听起来很激进，但有一个东西他们没删——AEB 自动紧急制动。这套系统到今天还是基于规则的，因为紧急制动不能等神经网络"想一想"，更不能接受它偶尔"想错了"。
小鹏的路线更典型。他们的基座模型有 720 亿参数，但上车的是蒸馏后的小模型，参数量压缩到原来的几十分之一。原因很简单：车载芯片的算力有限，推理延迟必须压在毫秒级。720 亿参数的模型认路能力确实强，但在车上跑一次推理要好几秒——红绿灯都变了。
这就是实时服务型 AI 的三个硬约束：
延迟——毫秒级。不是"越快越好"，是"慢了就出事"。自动驾驶要 50ms 以内，推荐系统要 100ms 以内，语音对话要 200ms 以内。这些数字不是 KPI，是物理约束。
确定性——不能偶尔抽风。大模型有一个著名的问题叫"幻觉"，在内容生成场景里最多是尴尬，在实时控制场景里就是事故。所以实时服务型 AI 必须追求确定性输出，宁可笨一点，也不能飘忽不定。
兜底——必须有安全网。Waymo 的架构里，神经网络负责规划路径，但最终执行前还有一层"安全验证器"做碰撞检测。特斯拉删了 30 万行规则代码，但 AEB 还是规则兜底。不管模型多先进，实时服务场景一定有一层"不信任 AI"的传统代码在最后把关。
总结成一句话：实时服务型 AI，不是拼模型多聪明，而是拼模型多可靠。
二、离线任务型：智力是天花板
换到 AI 编程助手这边看。
Cursor、Copilot、CodeBuddy——这些工具在使用体验上有一个共同点：你输入需求，然后等。等 5 秒、10 秒、甚至 30 秒。你不会觉得不耐烦，因为你知道它正在"思考"一个复杂问题，而你在等待期间可以喝口水。
内容生成、代码审查、数据分析、报告撰写——这些场景都属于离线任务型 AI。它们也有三个显著特征，但跟实时服务完全相反：
延迟容忍度高。用户等 10 秒甚至几分钟都可以接受。没有人会因为 AI 编程助手多花了 5 秒生成代码就出车祸。核心指标不是延迟，是输出质量。
可以用最大最强的模型。既然延迟不敏感，那就直接上最强模型。Claude Opus、GPT-4o、Gemini Ultra——能用多大用多大，因为模型越大，输出质量越高，而这正是用户最在意的。不需要蒸馏，不需要压缩，不需要量化。
错了能重来。AI 编程助手生成的代码有 bug？删掉重新生成。AI 写的报告数据有误？修改后再跑一遍。离线任务有一个实时服务没有的奢侈品——人类 review 环节。结果不会直接作用于物理世界，永远有一个人在中间把关。
离线任务型 AI 的核心竞争力就一个字：准。模型跑得慢没关系，给的东西得能直接用。
一个常见的误区：看到自动驾驶在做蒸馏，就觉得所有 AI 服务都该蒸馏。但代码审查等 30 秒有人投诉吗？大概率没有。蒸馏完模型变笨了，少查出一个关键 bug，有人投诉吗？那肯定有。
问题不在技术选型，在于你搞清楚了你的约束是什么没有。
三、同一个 AI，两套研发范式
把两种范式放在一起看，差异一目了然：
看完这张表你会发现，两种范式的差异不是程度上的，而是方向上的。
实时服务型团队的日常是：模型压缩、推理加速、量化部署、安全验证、规则引擎维护。他们最怕听到的一句话是"模型又飘了"。
离线任务型团队的日常是：prompt 调优、模型评测、输出质量打分、人类对齐、工作流编排。他们最怕听到的一句话是"生成的结果不能用"。
这两群人的技能树几乎没有交集。让一个做模型蒸馏和嵌入式部署的工程师去调 prompt，跟让一个 prompt engineer 去写 CUDA 内核，难度差不多。
成本结构更是天差地别。实时服务需要 GPU 常备在线、7×24 待命，推理成本是大头。而离线任务可以用 batch API（成本降低 50-70%），可以用 spot 实例，可以攒一堆请求一起处理。同样是调用大模型，一个花 10 块钱能干的事，另一个可能花 3 块就够了。
四、最危险的错误：用错范式
行业里有两种典型的翻车：
第一种：把实时服务当离线任务做。
有团队做智能客服，直接把 GPT-4 级别的大模型塞进在线链路。结果用户每句话要等 3-5 秒才有回复，高峰期延迟飙到 10 秒以上。GPU 成本更是爆炸——7×24 小时保持足够的推理实例在线，月账单六位数。
智能客服是实时对话场景，用户期望的响应时间是 1-2 秒。正确的做法是：用蒸馏后的小模型做首轮响应，复杂问题异步转给大模型，同时加规则引擎处理高频标准问题。这不是偷工减料，这是实时服务的基本架构。
反过来也成立。有团队做 AI 代码审查，花三个月蒸馏模型把审查时间从 30 秒压到 5 秒——然而开发者提交完代码就去倒咖啡了，根本不在乎这 25 秒。蒸馏后的模型倒是漏了两类关键风险，引发了线上事故。
用错范式比用错模型更致命。因为用错模型只影响效果，用错范式是整个系统架构方向就错了——延迟预算、成本结构、团队能力、容错策略，全都跟着错。
写在最后
很多团队在做 AI 改造的时候，第一个问题是"用什么模型"。
错了。第一个问题应该是：你的场景是实时的，还是离线的？
实时服务——用户在等、系统在跑、结果直接作用于物理世界或实时交互。这种场景，小模型 + 规则兜底 + 极致延迟优化，是基本功。
离线任务——用户可以等、结果有人审、错了能重来。这种场景，大模型 + 质量优先 + 人类 review，才是正确姿势。
回答了这个问题，模型选型、架构设计、团队配置、成本预算——后面的决策都会清晰很多。
说到底，AI 改造不难。难的是在动手之前，先想清楚你要改的到底是什么。下次有人跟你聊"我们也要上 AI"，先问一句：你这个是要快，还是要准？
