从资源、公平到算力：小团队该怎样看待 AI 基础设施成本
本文由本站基于公开热点摘要整理和原创分析生成，原文来源：科技爱好者周刊（第 405 期）：资源，社会公平与算力。
这不是一个只属于大厂的话题
阮一峰这期周刊的题目是“资源，社会公平与算力”。基于公开摘要可见，原文仍是每周科技内容的整理，但这个标题本身已经够有讨论价值了。算力以前听起来像云厂商、芯片公司和大模型团队的事，离普通业务系统有点远。现在不一样了。哪怕只是给内部客服加一个问答助手，或者给后台加一段文档检索，最后都会落到机器、队列、缓存、调用次数和账单上。
我更关心的是，很多团队谈 AI 时先谈效果，真正上线时才发现成本和稳定性才是第一道门槛。模型回答慢一点，前端还能转圈；接口偶尔超时，客服系统就会有人抱怨；账单突然翻倍，老板不会关心你用了什么向量库，只会问为什么这个月云费用这么难看。
算力会变成新的容量规划
以前做容量规划，常见问题是数据库 QPS、Redis 内存、消息堆积、容器副本数。AI 功能进来之后，又多了推理延迟、上下文长度、向量检索耗时、批处理窗口这些东西。它们不神秘，但很容易被产品演示掩盖。Demo 里一次问答跑通了，不代表高峰期也稳；本地脚本能跑，不代表放进生产链路就能接住重试和降级。
这事放到实际项目里，我会先看两件事。第一，能不能把 AI 调用从主链路里拆出去。用户点保存、支付、提交工单这些动作，最好不要被一个不稳定的外部模型拖死。第二，监控怎么补。只看 HTTP 200 不够，还要看平均耗时、超时率、空回答比例、缓存命中率，以及失败后有没有落到人工处理或传统规则。没有这些东西，上线就是碰运气。
公平问题最后也会落到工程决策
“资源”和“公平”听起来有点社会议题，但在小团队里会变成很具体的选择：哪些用户可以用更贵的模型，哪些场景只能走便宜方案，哪些功能必须排队，哪些功能干脆不上。算力不便宜时，产品权限设计就会和成本绑在一起。免费用户每次都跑长上下文，付费用户反而排队，这种设计迟早会把系统和商业模型一起拖乱。
还有一个容易被忽略的点：团队能力也是资源。买到 GPU 或者接上模型 API，并不等于能长期维护。线上出了问题，谁判断是提示词问题、检索问题、模型服务问题，还是数据库慢查询把整条链路拖住了？对小团队来说，最怕的不是新技术不会用，而是出了问题没人接得住。
普通开发者可以先做减法
如果团队正在评估 AI 功能，我不建议一上来就追最强模型、最长上下文、最复杂工作流。先把问题拆小：哪些地方真的需要生成，哪些地方只是搜索；哪些请求可以缓存，哪些结果必须实时；哪些失败可以让用户重试，哪些失败必须有人兜底。能用规则解决的地方，别急着塞模型。能异步处理的地方，别硬塞进同步接口。
我的判断比较保守：算力会越来越重要，但它不会替代基本功。日志要打清楚，队列要能消化峰值，缓存要知道什么时候失效，回滚按钮要真能用。AI 功能可以慢慢加，基础设施欠的债却会在流量和账单面前一起到期。先把可观测性和成本边界搭好，再谈更聪明的功能，项目会安全很多。
