AI 硬件跑步进入多模态时代之后一个非常现实的问题浮出水面用户已经为硬件付过钱但每一次“智能”都意味着持续的云端推理成本。2024 年底到 2025 年初Meta 在 Ray-Ban 智能眼镜上的 AI 收费试探正好把这个问题摆到了台面上。消息曝光后Meta 很快退回了原来的立场公开表示暂时没有收费计划。这篇文章会从这条产业新闻出发重点拆解三件事AI 眼镜的 AI 功能到底是怎么运行的、为什么厂商想收费、以及作为 AI 应用开发者我们可以从这场“收费风波”中学到哪些成本控制和商业化设计的方法。1. 事件回顾Meta 为什么想给 AI 功能收费1.1 AI 眼镜是把 AI 搬到了“脸上”Meta 与 EssilorLuxottica 合作推出的 Ray-Ban Meta 智能眼镜是近几年 AI 硬件里关注度很高的产品。它的外观和普通眼镜差别不大但内部集成了摄像头、麦克风、扬声器、骁龙芯片和一套完整的 AI 交互体系。用户说一句“Hey Meta”就可以唤醒 AI 助手让它识别眼前的建筑、翻译路牌和菜单、回答关于视野里物体的问题也可以让它朗读收到的消息。这种“所见即所问”的交互方式是靠多模态 AI 模型支撑起来的。它不再像手机助手那样只需要处理语音而是要把图像、音频、地理位置等信息一起送进模型。可以说Ray-Ban Meta 是消费市场里最早把多模态大模型装进眼镜形态的产品之一也是观察 AI 硬件成本模型的一个典型样本。1.2 收费传闻与紧急澄清产品卖得好之后一个现实问题出现了AI 功能每被调用一次Meta 就要向云计算资源支付一次成本。据多家海外科技媒体报道Meta 内部曾讨论过对 Ray-Ban Meta 眼镜上的 AI 功能加收费用甚至计划在后续版本中引入类似“额外费用”的机制。这个消息传到用户和媒体耳朵里之后引发了比较强烈的反弹。不少人的第一反应是一副几百美元的眼镜凭什么里面的基础 AI 功能还要单独收费很快Meta 对外澄清目前没有计划在 Ray-Ban Meta 上针对 AI 功能收费。英文标题里的 “Backs Off” 说的就是这个动作意思是“退回去、收手了”。整个“试探—反弹—澄清”的过程在国内外的科技社区都引发了大量讨论因为它触及了 AI 硬件普遍面临的一个核心矛盾AI 能力到底算硬件的一部分还是一个需要单独付费的服务。1.3 “sloppy gambit”到底草率在哪英文标题里还有一个词值得琢磨sloppy gambit。gambit 指“为了获得优势而采取的策略”sloppy 则指“草率的、漏洞百出的”。媒体用这个词意思是 Meta 这次尝试收费的动作本身不算一个成熟的商业策略。草率之处至少有三点第一用户在购买硬件时已经把 AI 功能当成了产品的一部分此时突然说“AI 要额外花钱”等于让用户感觉自己被二次收费。第二Meta AI 助手是 Ray-Ban Meta 的核心卖点卖点还没完全建立心智就急着收费会直接影响后续销量和口碑。第三AI 功能的成本结构本来可以用“订阅制”“硬件溢价”等方式消化直接按小功能零散收费是最容易引发负面舆论的一种方式。从产品策略的角度看Meta 这次的动作确实像一次没有想清楚用户预期的仓促尝试。但这件事也提醒所有团队AI 功能不是没有成本只是“羊毛出在羊身上”的方式需要设计得更聪明。2. AI 眼镜里的 AI 功能是怎么运转的要理解 Meta 为什么要打退堂鼓首先得知道眼镜上的 AI 功能是怎么跑起来的。2.1 一次多模态问答的完整链路以“看到一个建筑问 AI 这是什么”为例完整的请求链路大致如下用户在镜腿上按下唤醒键或者说出唤醒词。眼镜上的麦克风开始采集音频摄像头拍摄当前画面。音频和图像在眼镜端做初步编码通过蓝牙传输到手机上的配套 App。App 对数据做打包和预处理把请求转发到 Meta 的云端 API。云端多模态模型处理图像和文本生成回答。回答文本通过语音合成TTS转化为音频。音频通过蓝牙回传到眼镜由扬声器播放给用户。这条链路的最大特点是“眼镜本身不是算力中心”。由于功耗、体积和散热的限制眼镜端通常只能做唤醒词检测、画面采集和音频播放真正的理解和推理全部在云端完成。手机在其中扮演的是“中继网关”的角色负责蓝牙通信和互联网通信之间的转换。这种“眼镜 手机 云端”的三段式结构决定了 AI 眼镜的产品体验非常依赖网络质量。网络差的时候AI 回答延迟会明显上升而无网环境下很多功能直接不可用。这是当前 AI 眼镜普遍存在的技术边界。2.2 端侧与云端的职责划分把任务拆到端侧和云端是 AI 眼镜设计的核心问题。端侧推理的优势是延迟低、隐私好、不依赖网络、边际成本为零但受限于芯片算力只能运行很小的模型。云端模型的优势是能力强、可以持续升级但每一次调用都产生费用而且对网络环境有要求。Ray-Ban Meta 这类产品采用的是混合架构端侧负责“值守”例如检测有没有人说话、识别是不是唤醒词、判断当前画面是否需要拍照云端负责“干活”例如开放域问答、图像理解、翻译等。这种架构决定了 AI 眼镜的成本结构只要用户频繁使用 AI 功能云端请求量就会快速上升推理账单也会跟着涨。2.3 用一段伪代码理解请求链路为了帮助大家理解我用 Python 伪代码把这个链路画出来。实际工程中会拆成多个微服务但流程是一致的。def handle_ai_request(wake_audio, camera_frame, phone_client, cloud_api): # 1. 端侧唤醒词检测 if not detect_wakeword(wake_audio): return # 2. 判断是否需要视觉输入 image camera_frame if camera_enabled() else None # 3. 组装多模态请求 payload { audio: encode_audio(wake_audio), image: encode_image(image) if image else None, context: get_sensor_context(), } # 4. 通过手机转发到云端 response cloud_api.multimodal_chat(payload) # 5. 云端结果做语音合成后回传 audio_out text_to_speech(response.text) play_to_speaker(audio_out)这个例子想说明一个容易被忽略的点用户感受到的“一秒钟回答”背后涉及音频编解码、图像压缩、网络传输、模型推理、语音合成等多个环节。任何一个环节出问题都会表现为用户体验下降而每一个环节其实都在消耗资源。3. 一次 AI 回答到底凭什么“花钱”3.1 推理成本不是简单的一张电费单很多开发者以为大模型推理成本就是 GPU 的电费真实情况复杂得多。一次多模态 AI 对话的成本至少包含成本项说明文本 Token 费用输入文本和输出文本按 Token 计费视觉编码费用图片需要切成 Patch经过 Vision Encoder 变成视觉 Token语音识别ASR把用户语音转成文本语音合成TTS把模型回答转成语音服务器与带宽推理集群的维护、网络传输、内容分发模型开发摊销训练数据、模型调优、评测等前期投入对 AI 眼镜来说语音项和视觉项往往比纯文本聊天贵得多因为每一次对话可能同时包含“听”和“看”两个模态。3.2 用脚本估算一个月的推理开销我写了一个很简单的成本估算脚本假设产品有 1 万日活、每人每天调用 AI 功能 20 次、每次平均 500 个输入 Token 和 200 个输出 Token可以快速算出月度成本。# ai_glasses_cost.py def estimate_monthly_cost(dau, requests_per_user_per_day, avg_input_tokens, avg_output_tokens, input_price_per_million, output_price_per_million): monthly_requests dau * requests_per_user_per_day * 30 input_tokens monthly_requests * avg_input_tokens output_tokens monthly_requests * avg_output_tokens input_cost input_tokens / 1_000_000 * input_price_per_million output_cost output_tokens / 1_000_000 * output_price_per_million return { monthly_requests: monthly_requests, input_cost_usd: round(input_cost, 2), output_cost_usd: round(output_cost, 2), total_cost_usd: round(input_cost output_cost, 2), } if __name__ __main__: r estimate_monthly_cost( dau10000, requests_per_user_per_day20, avg_input_tokens500, avg_output_tokens200, input_price_per_million3, output_price_per_million15, ) print(r)运行结果大致如下价格只是示意实际以模型厂商报价为准{monthly_requests: 6000000, input_cost_usd: 9000.0, output_cost_usd: 18000.0, total_cost_usd: 27000.0}也就是说在很保守的假设下1 万日活的纯文本问答功能一个月的模型费用就已经接近 2.7 万美元。如果加上语音识别、语音合成、图像编码以及带宽成本实际数字还会更高。如果用户量到 10 万、100 万这个数字会线性增长。这也就解释了为什么 Meta 会对“免费 AI”感到压力AI 功能卖得越好补贴就越多。3.3 视觉输入的成本放大效应视觉输入是另一个烧钱点。一张图片进入大模型之前会被缩放成固定尺寸再切成多个 Patch由视觉编码器转换成视觉 Token。一张普通图片产生的视觉 Token 数量通常是几百到上千相当于一次输入了几百到上千个文本 Token。这意味着“看一眼”的请求比“说一句”的请求要贵得多。如果用户经常让眼镜识别路标、植物、商品、菜单成本会迅速上升。某个功能如果特别受欢迎比如“帮我翻译这个菜单”就可能成为成本黑洞。做 AI 硬件的团队在上线前一定要对这类“高频高价”场景做专门评估。4. 为什么“零敲碎打”式收费不被接受既然成本确实存在那 Meta 想收费这件事为什么还是会被批评为“零敲碎打nickel-and-dime”4.1 用户已经付过钱了一副 Ray-Ban Meta 眼镜的售价并不便宜。用户购买时心理上已经为“智能”付过一部分价格。此时如果 AI 功能还要按次收费用户的感知是“双重付费”而不是“为额外价值付费”。nickel-and-dime 这个短语的意思是“一点一点地收小钱”往往带有贬义形容商家通过零散收费让客户多掏钱。媒体用这个词评价 Meta 的动作是在说如果你把 AI 功能拆成一个个小额收费项用户会觉得自己的眼镜永远没买完总在补钱。4.2 主流收费模式对比我们把几种常见收费方式放在一起对比收费模式典型做法优点风险硬件溢价功能免费售价覆盖成本用户感知清晰售价过高影响销量订阅制月费/年费解锁高级 AI 功能收入稳定用户可预期需要持续提供价值按量计费免费额度用完后按调用付费成本匹配最好体验割裂容易引发负面舆论广告补贴AI 免费用广告/推荐变现用户不直接花钱隐私和体验压力大Meta 被批评的是“按量计费”方向尤其是没有正式设计免费额度和替代方案的情况下容易出现“为了十几个功能分别付小钱”的糟糕局面。对用户来说这种收费方式的不确定性太强很难形成稳定的心理预期。4.3 功能降级与信任风险对一个硬件产品来说AI 能力往往是支撑早期口碑的核心。如果用户刚因为“AI 很好用”买了眼镜转头就看到收费计划信任感会立刻下降。更麻烦的是收费计划一旦进入讨论阶段哪怕最终没有执行用户也会开始担心基础功能会不会被阉割、响应速度会不会被降级、免费额度会不会缩水。这种“未收费先掉口碑”的风险是任何 AI 硬件团队在做商业化设计时都该警惕的。商业策略可以调整但用户信任一旦失去重建的代价非常高。5. 更务实的商业化路径有哪些Meta 这次的尝试虽然收手了但“AI 功能怎么收钱”这个问题不会消失。下面我们讨论几条更务实的技术和商业路径。5.1 先把成本算清楚再谈收费很多团队一上来就讨论“定价”其实应该先讨论“成本”。我建议上线前完成三件事统计每个用户的日均请求量、平均 Token 数、平均图片数。按功能维度和模型维度拆分成本找出“高频高价”场景。做带动成本的敏感性分析假设用户量翻 10 倍会怎样。只有把成本拆开才能知道某个功能单用户每月成本是 1 毛钱还是 10 块钱。成本在 1 毛钱级别不如不做收费直接靠硬件溢价覆盖成本在 10 块钱级别才值得专门设计订阅制。下面是一个单用户成本的快速计算# 计算单用户月成本 monthly_cost 27000 # 每月总模型费用美元 mau 8000 # 月活跃用户数 cost_per_user monthly_cost / mau print(f每用户每月成本约 {cost_per_user:.2f} 美元)输出每用户每月成本约 3.38 美元如果单用户成本在 3 美元左右那么一副眼镜在生命周期内把售价提高 10 到 15 美元就足以覆盖两年的 AI 成本完全没有必要做复杂的按次收费。先算账再定价是成本驱动型产品的基本原则。5.2 免费额度 订阅增强更平滑的方案是“免费额度 订阅增强”基础功能免费例如每天 50 次问答、每天 10 次视觉识别。高频用户订阅例如无限次调用、优先队列、更强的模型。企业级功能单独计费例如批量识别、API 接入。这种模式的优点是用户有清晰的心理预期重度用户才需要付费且运营方可以通过配额系统控制成本。订阅收入也可以反哺模型迭代和服务器扩容形成正向循环。5.3 用端侧模型过滤简单请求成本控制还有一个很重要的手段不要把所有请求都发给云端大模型。很多场景用端侧小模型就能解决例如唤醒词检测简单物体识别固定模板问题“现在几点”“今天天气如何”把简单请求过滤掉云端只处理真正需要大模型理解的请求可以显著降低成本。下面是使用 ONNX Runtime 部署端侧分类模型的示意代码# 端侧意图分类判断是否需要上云 import onnxruntime as ort session ort.InferenceSession(glasses_intent.onnx, providers[CPUExecutionProvider]) def need_cloud(image_tensor): outputs session.run(None, {input: image_tensor}) intent_id outputs[0].argmax(axis1)[0] # intent_id 0 表示本地可回答1 表示需要云端开放域模型 return int(intent_id) 1这段代码的思路是先在眼镜端用小模型判断问题类型能本地回答的直接返回只有真正复杂的请求才上云。类似的设计在真实产品里已经被广泛采用也是控制 AI 硬件推理成本最有效的手段之一。6. 开发者能从这件事里学到什么Meta 的收费风波不只是商业新闻它对所有 AI 应用开发者也提了一个醒免费 AI 功能背后有真实成本开发时就要把成本控制设计进系统里。6.1 没有配额系统不要上线免费 AI很多团队上线 AI 功能时只实现了“调用大模型”这一条路径没有配额、没有限流、没有熔断。一旦出现短视频带火某个功能、或者某个机器人刷调用量月底账单可能直接爆掉。正确做法是在第一个版本就引入配额体系把“用户每天可以调多少次”作为产品参数而不是事后补救。6.2 用 Redis 实现滑动窗口限流下面是一个很常见的实现方案使用 Redis 的计数器做按天限流。用户 ID 加上功能类型作为 key按天递增计数。import redis import time r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) def check_quota(user_id: str, action: str, daily_limit: int) - bool: day_key int(time.time()) // 86400 key fquota:{user_id}:{action}:{day_key} count r.incr(key) if count 1: r.expire(key, 86400) return count daily_limit把这个函数放在 AI 请求入口处就能在最简单的情况下避免单个用户无限调用。配合异步队列削峰和熔断降级效果会更好。6.3 日志与成本可观测性每个 AI 请求的日志都应该带上user_id功能名称model_nameinput_tokensoutput_tokensvision_patch_countlatency_ms是否命中缓存是否被限流有了这些字段后续才能按用户、按功能、按渠道聚合成本才能回答“哪个功能最烧钱”“哪个用户透支风险最高”这类问题。没有可观测性成本失控时你甚至不知道钱花在哪里这是 AI 应用工程化最容易踩的坑。7. 还有哪些风险值得关注7.1 “免费 AI”能补贴多久Meta 目前的做法是继续免费提供 AI 功能但这种免费不是来自“AI 没有成本”而是来自补贴。补贴能持续多久取决于单用户成本、资本投入和广告等其他收入。对消费者来说应该明确一个点AI 眼镜的 AI 功能不会永久免费厂商只是选择了更合适的收费时机和收费方式。后续如果 Meta 推出订阅制或者在新版本硬件中把成本计入售价都是更成熟的可能性。7.2 第三方开发者不要押注平台永远免费如果你打算基于某家平台的 AI 眼镜做应用或服务不要假设平台的 AI 能力永远免费。接口费用、调用限制、功能权限都可能在未来调整。架构上建议做到三点通过 SDK 或网关调用平台能力方便切换供应商。自己保留一份核心数据的完整副本避免被平台锁定。对平台能力和自建能力做抽象关键是接口可替换。7.3 隐私与数据合规同样影响成本AI 眼镜天生会采集用户在现实世界中看到的画面和声音这涉及非常严格的隐私合规要求。每一次图像上云都意味着用户的环境信息被传输到服务端。为了满足数据保护要求产品往往需要增加本地脱敏、数据加密、权限弹窗、自动删除等机制这些机制本身也会消耗算力和研发资源是成本模型中常常被忽略的一部分。8. 总结Meta 在 AI 眼镜收费问题上的“试探—反弹—收手”给整个 AI 硬件行业上了一课AI 功能不是没有成本但收费方式必须和用户预期、产品定位以及成本结构相匹配。对开发者来说这件事最大的价值是提醒我们正视三个工程问题一是推理成本到底怎么算二是免费功能怎么通过配额和限流控制风险三是端侧模型怎么帮云端“减负”。这些问题的答案比一次商业新闻的走向更值得记录。如果你最近也在做 AI 硬件或者 AI 应用正在被推理成本和商业化设计折磨欢迎在评论区聊聊你的成本拆分思路。把账单算明白了做产品才能睡得着觉。