一个值得注意的信号是腾讯云与智慧产业事业群CEO汤道生近期在一份内部发文中直接回应了外界关于“腾讯AI慢了”的讨论。他的核心判断可以概括为一句话AI竞争不是短跑熬得久比起得早更重要。这句话在行业里听起来像战略定调但对做技术的开发者来说它其实值得拆开细读。因为“早起”和“熬得久”背后是两套完全不同的竞争逻辑。第一轮AI竞赛拼的是模型分数、榜单排位、发布速度谁先放出一个大参数模型谁就占据舆论高地。但真正决定技术能不能落地的不是第一波发布而是后续能不能把模型变成稳定、可维护、可评估、成本可控的系统能力。本文不打算讨论腾讯内部管理或公关话术而是想把这个判断翻译成技术语言AI竞争进入后半程工程化才是真正的分水岭。我们会从模型选型、评测、部署、Agent工作流、成本监控、数据闭环这几个角度分析为什么“熬得久”会赢以及作为开发者你现在应该开始积累哪些能力。1. 这件事真正值得关注的不是“腾讯慢了”而是AI竞争的逻辑变了“腾讯AI是不是慢了”这个问题的前提是默认AI竞争像百米短跑谁先冲出去谁就有优势。但如果你把视线拉长到过去几年大模型落地的情况会发现一个事实第一波发布领先的模型并不一定在真实业务场景中成为使用率最高的模型。原因很简单发布快只解决“有没有”不解决“好不好用、能不能用、用得起用不起”。换个角度看传统软件工程。一个项目上线晚两个月但架构清晰、测试完善、文档齐全、运维自动化程度高后续迭代反而会更快。AI项目也一样。模型只是系统里的一个组件真正进入生产环境之后要面对的是数据质量、推理延迟、并发压力、成本预算、安全合规、效果退化等一系列问题。这些问题没有一个能靠“发布早”解决。汤道生的判断真正点醒人的地方在于AI竞争正在从“拼模型能力”转向“拼综合工程能力”。前者的比拼单位是论文、榜单、发布会后者的比拼单位是线上的稳定运行时长、单次推理成本、业务指标提升幅度、开发者接入效率。这两种竞争节奏完全不同。对开发者来说这个变化不是坏事。因为模型能力更多掌握在少数大厂和实验室手里普通团队很难参与第一轮拼参数规模的游戏。但工程能力是可以通过一套规范的方法论、工具链和项目实践逐步积累的。也就是说当竞争转向“熬得久”中小团队、业务研发、AI应用开发者反而有了更大的发挥空间。这篇文章接下来的内容就是围绕“如何在这场长跑中建立自己的工程优势”展开的。适合的读者包括正在做AI应用开发的工程师、准备做模型部署和推理优化的运维/平台同学、负责AI技术选型的技术管理者以及想入行AI工程化的学生或转行者。2. 为什么“熬得久”会赢“抢首发”和“拼落地”是两种游戏要理解“熬得久比起得早更重要”可以先看清楚AI竞争的两个阶段分别拼什么。第一阶段可以称为“模型竞赛”。这个阶段的核心目标是证明模型能力常见指标是各种公开榜单上的分数、参数量大小、多模态能力、上下文长度、代码能力等。谁先发布谁就能获得最多的关注和流量。这个阶段有一个明显特点竞争集中在少数玩家手里因为训练一个大模型需要巨额算力、数据和技术积累普通团队很难参与。第二阶段才是大多数团队真正参与的“落地竞赛”。这个阶段的核心目标不再是把模型做大而是把模型用好。问题变成了如何选择一个适合业务场景的模型而不是参数最大的模型如何把模型部署成高可用、低延迟的推理服务如何评估模型在真实业务数据上的效果而不是只看公开榜单如何控制推理成本让业务能算得过账如何让模型和现有系统、工具链、数据体系高效协作如何建立数据回流和持续优化机制让系统越用越好把这些维度列出来就会发现“早起”的优势会随着时间推移被稀释。哪怕一个团队晚半年进入市场但只要它把上述问题逐个解决依然可以在业务场景中建立真正的壁垒。更关键的是这些工程能力有很强的复利效应。每解决一个问题都是在为后面的迭代铺路而“抢首发”带来的热度则是一次性的。用一个表格来对比维度抢首发阶段拼落地阶段核心评价指标榜单分数、发布时间、参数规模线上效果、推理成本、稳定性、迭代速度主要参与者大模型厂商、研究机构业务研发团队、AI平台团队、应用开发者关键能力算力、数据、训练技术工程化、评测体系、部署运维、产品化竞争节奏短期爆发靠抢长期持续靠积累普通团队机会较小很大所以“熬得久”不是一句自我安慰而是对AI技术落地规律的准确判断技术的长期价值往往不在发布那一刻而在后续持续运营和迭代的过程中。3. 后半程的核心命题AI工程化到底在解决什么问题如果说“拼落地”是后半程的主线那么AI工程化就是这条主线的施工方法。这里先给一个通俗解释AI工程化指的是把大模型从“一个能聊天的接口”变成“一个能稳定支撑业务的系统能力”的全部工作。很多团队第一次接入大模型时觉得很简单。调用一个API写几句prompt就能做出一个Demo。但Demo和线上系统之间隔着一条很宽的河。举几个真实的场景第一个场景模型上线后线上用户的提问千奇百怪有些问题明显不在模型能力范围内模型会一本正经地给出错误答案。这时候你需要的不是换更大的模型而是建立一套“模型能力边界”的认知体系——哪些问题应该拦截哪些问题应该转人工哪些问题需要检索增强。这个边界不是靠猜而是靠评测和线上日志分析。第二个场景模型响应速度不稳定。同样的提示词有时1秒返回有时5秒。如果下游业务对延迟敏感就必须做超时控制、排队策略、缓存、模型量化或者降级方案。这些工作听起来不像AI但恰恰是决定AI能不能真正跑起来的“水电煤”。第三个场景成本失控。一个大模型API按Token计费如果应用没有做上下文管理每次请求都把整段历史记录一股脑发给模型月度账单会高得吓人。控制Token消耗、设计合理的上下文裁剪策略、选择合适的模型档位都是AI工程化的一部分。所以AI工程化解决的问题可以归纳为四类效果问题、性能问题、成本问题、稳定问题。这四个问题一个比一个接近生产环境也一个比一个考验工程能力。对于想在AI领域长期发展的开发者来说与其追逐每天新发布的模型不如先把这四类问题的解决思路和实践工具掌握扎实。4. 从模型到系统AI应用开发的技术栈分层做AI应用不能只盯着模型本身。从工程视角看一个完整的AI应用系统至少可以分为五层每一层都有对应的技术关注点。第一层是模型层。这里关心的是选什么模型、模型参数规模、推理框架、量化方案、部署方式。如果走API路线模型层就是选厂商和服务如果走私有化部署路线模型层还包含GPU资源、推理引擎和模型管理。第二层是数据层。包括知识库构建、文档解析、向量化、检索、数据回流。RAG检索增强生成是目前最常见的AI应用形态之一它的效果上限很大程度上取决于数据层的质量而不是模型本身的聪明程度。第三层是编排层。对应的是AI Agent、工作流、多步任务拆解、工具调用、上下文管理等。这一层解决的是“模型怎么和外部世界交互”的问题。模型本身没有记忆和行动能力需要编排层赋予它目标和流程。第四层是应用层。包括业务逻辑、用户界面、权限控制、对外API、消息队列、任务调度等。这一层和传统后端开发相似但多了很多与模型交互的细节比如流式返回、超时处理、幻觉兜底。第五层是可观测与运营层。包括日志、监控、评测、告警、成本分析、A/B实验。这一层决定了AI系统能不能持续迭代、能不能在出问题时快速定位。这五层之间的关系是模型层解决“能力”问题数据层解决“知识”问题编排层解决“行动”问题应用层解决“接入”问题可观测层解决“信任”问题。大多数团队在初期会把精力集中在模型层到处比较哪个模型更强。但真正决定系统长期表现的往往是中间三层——数据、编排和可观测。这是一个非常重要的认知转变AI应用开发不再只是写Prompt而是一项需要系统性设计的软件工程。这也解释了为什么“熬得久”重要——系统能力的建设需要时间沉淀无法靠一次模型升级一蹴而就。5. 先解决“用什么模型”模型选型与评测实操5.1 评测维度很多团队在选模型时习惯直接看公开榜单。但公开榜单的任务分布和你的业务场景很可能不一致。一个在通用问答上表现优异的模型未必擅长处理特定领域的专业术语。因此我建议每个准备长期做AI应用的团队都建立一套自己的评测集。评测集不一定要非常大。初始阶段300到500条真实业务问题就够了。关键是覆盖典型场景和边界情况。常见评测维度包括回答准确性模型输出是否与业务事实一致。格式规范性是否能按照要求的JSON、Markdown或表格格式输出。指令遵循度是否理解并执行了限制条件例如“不要编造数据”。响应延迟P50和P95的响应时间是否满足业务要求。成本单次平均消耗的Token数量、调用费用。稳定性相同输入多次调用输出质量是否波动。只有把评测维度量化为分数和表格模型选型才有依据。否则就只能凭感觉、凭名气上线后再靠用户骂声发现问题。5.2 最小评测脚本下面提供一个最小但可用的评测脚本。它以OpenAI兼容的API为统一接口方便你随时切换不同的本地推理服务或云端模型服务。# evaluate_model.py import json import time from openai import OpenAI # 这里改成你实际使用的模型服务地址和模型名称 client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY ) MODEL_NAME your-model-name test_cases [ { prompt: 用一句话解释什么是数据库索引, max_tokens: 200, }, { prompt: 请输出一个包含name和age字段的JSON表示一个叫张三的人年龄30岁, max_tokens: 300, }, { prompt: 写一个Python函数判断一个字符串是否为回文只返回代码, max_tokens: 400, }, ] def run_eval(): results [] for case in test_cases: start time.time() try: resp client.chat.completions.create( modelMODEL_NAME, messages[ {role: system, content: 你是一个可靠的AI助手回答要简洁准确。}, {role: user, content: case[prompt]}, ], temperature0.2, max_tokenscase[max_tokens], ) latency time.time() - start answer resp.choices[0].message.content usage resp.usage results.append({ prompt: case[prompt], answer: answer, latency: round(latency, 2), prompt_tokens: usage.prompt_tokens, completion_tokens: usage.completion_tokens, total_tokens: usage.total_tokens, }) except Exception as e: results.append({ prompt: case[prompt], error: str(e), }) with open(eval_result.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(评测完成结果已写入 eval_result.json) if __name__ __main__: run_eval()这个脚本的价值不只是跑一遍而是帮你建立“可重复评测”的意识。每次更换模型、调整Prompt、升级推理框架之后都在同一套评测集上重新跑对比结果才能知道改动到底是变好还是变差。5.3 如何判断评测结果评测脚本跑完后不要只看延迟和Token数。建议对回答做人工抽检尤其是第一版评测集要逐条看回答是否符合业务预期。这里有一个容易踩的坑模型格式遵循度差不等于业务不能做。你可以在Prompt里给出一个Few-shot示例或者在后端代码里做结构化解析和重试。评测的意义是暴露问题而不是一票否决某个模型。在实际项目中更推荐的做法是让评测集持续生长。把线上真实用户的问题日志定期清洗、去重、补充进评测集。这样评测集就成了团队最宝贵的资产之一。它比任何公开榜单都更贴近你的业务也更能指导你在“熬得久”的过程中持续做对决策。6. 模型部署与本地推理把模型变成稳定服务6.1 本地推理快速启动模型选型确定之后下一步是部署。本地部署的核心目标是把模型变成稳定、低延迟、可水平扩展的服务。这里以当前常见的本地推理工具为例演示一个最小部署流程# 以 Ollama 为例拉取模型并启动服务 # 具体模型标签以 ollama 官方仓库为准 ollama pull qwen2.5:7b ollama serve模型下载完成后Ollama会在本地启动一个兼容OpenAI格式的服务默认端口是11434。可以通过curl快速验证服务是否可用curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 你好}], stream: false }如果你需要更高的吞吐量通常会使用专门的高性能推理框架。以vLLM为例命令形式类似# 以实际安装版本的帮助信息为准 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name my-model \ --port 8000这里不写死版本号因为推理框架的演进速度很快命令参数可能变化。关键是理解部署时真正要关注的点模型路径、显存占用、并发数、量化精度、服务端口。6.2 服务化调用的注意事项本地推理服务启动之后有几个生产环境必须考虑的问题。第一显存与并发的关系。模型能同时处理多少请求取决于GPU显存和推理框架的调度策略。并发过高会导致显存溢出并发过低则浪费资源。建议在真实业务流量下做压测找到吞吐和延迟的平衡点。第二量化与效果权衡。把模型从FP16量化到INT8甚至INT4能大幅降低显存占用和推理成本但会带来一定的效果损失。不要盲目追求量化需要用上一节的评测脚本对比量化前后的效果。第三超时与重试。AI推理接口和普通HTTP接口不一样一个长文本生成请求可能耗时几十秒。调用方必须设置合理的超时时间不能一直等待。同时要区分“请求失败”和“生成质量差”前者可以做自动重试后者需要走评测和优化链路重试没有意义。第四安全边界。本地部署模型不等于没有安全问题。模型输出仍然可能包含不当内容服务接口必须加鉴权、限流和内容过滤。内部使用和公开API的访问控制策略应该分开。把模型部署成服务这只是一个开始。接下来更重要的是如何让模型与业务系统协作完成更复杂的任务。7. 从单模型到AI Agent长跑中真正拉开差距的工程形态7.1 一个简化Agent示例如果AI应用只停留在“问答”层面模型部署好就能工作。但你会发现真实业务通常不是一个问题回答就结束的。用户需要系统帮他查数据、算结果、填工单、发邮件这就需要把模型放进一个可以行动的工作流里也就是AI Agent。“AI Agent”这个词很容易被理解成玄乎的智能体。从工程角度看它的本质是让模型在循环中决策调用外部工具并把结果反馈回上下文直到任务完成。下面用一个简化示例展示核心思路# simple_agent.py import json def call_llm(messages, toolsNone): 调用本地或云端兼容OpenAI接口的模型返回结构化结果。 # 这里对接你的推理服务 pass def search_knowledge(query: str) - str: 模拟知识检索根据问题召回相关文档片段。 # 实际项目可以替换为向量数据库检索 return 知识库中与 query 相关的段落 def calculator(expression: str) - str: 模拟工具调用执行简单的数学计算。 # 实际项目需要注意表达式注入风险建议用安全解析库 return str(eval(expression)) def run_agent(user_input: str) - str: # 第一步组装系统提示告诉模型有哪些工具可用 messages [ {role: system, content: 你可以使用工具解决问题。工具名search_knowledge、calculator}, {role: user, content: user_input}, ] # 第二步循环让模型决策直到它认为任务完成 for _ in range(3): response call_llm(messages) if response.get(tool_call): tool_name response[tool_call][name] args json.loads(response[tool_call][arguments]) if tool_name search_knowledge: tool_result search_knowledge(args[query]) elif tool_name calculator: tool_result calculator(args[expression]) else: tool_result 未知工具 # 第三步把工具结果放回上下文继续交给模型 messages.append({role: tool, name: tool_name, content: tool_result}) else: # 模型认为不需要调用工具返回最终回答 return response[content] return 已达到最大循环次数任务未完成请人工介入。 if __name__ __main__: print(run_agent(帮我算一下168乘以23等于多少并检索相关的知识))这个示例省略了与推理服务的具体对接细节但把Agent的核心循环讲清楚了。真正生产级的Agent还要处理工具调用失败、多轮对话中的上下文裁剪、角色权限、操作审计、人工审批节点等问题。你可以从最简循环开始逐步增加能力。7.2 Agent容易踩的坑Agent看似简单但“让模型自己决策”会带来新的失控风险。常见问题有三个。第一个是无限循环。模型可能在工具调用和总结之间反复横跳把Token耗尽。必须设置最大循环次数并在超过阈值后强制退出或转人工。第二个是幻觉被工具放大。模型在一次错误判断中调用了错误的工具生成了看似合理的错误结果。这种错误比单纯问答中的幻觉更难发现因为它经过了“工具验证”的假象。因此Agent系统必须保留完整的执行轨迹方便事后审计。第三个是权限范围失控。如果Agent具备调用外部API的能力必须严格限制它的操作范围。不要给Agent一个可以删库的数据库连接串也不要让它调用内部管理接口。最小权限原则在Agent场景下比传统后端更关键因为模型的行为有随机性。8. 持久战的底层支撑数据闭环、可观测性与成本控制8.1 成本控制AI应用和传统应用最大的不同之一是每一次请求都有真实的计算成本。随着用户量增长成本会线性甚至超线性上升。所以从第一天起就必须建立成本意识。成本控制的核心是算清三个数字单次平均Token消耗、单次平均调用成本、月度预算线。一个简单的计算公式是单次请求成本 (输入Token数 * 输入单价 输出Token数 * 输出单价) / 1000举例来说如果输入单价是每千Token 0.001元输出单价是每千Token 0.002元一次请求消耗2000个输入Token和500个输出Token那么成本大约是(2000 * 0.001 500 * 0.002) / 1000 0.003元。当每日调用量为100万次时单日成本就是3000元。这个数字对很多业务来说都不低。常见的成本优化手段包括合理裁剪上下文不要把整个聊天历史无脑发给模型。简单问题走小模型复杂问题才调度大模型。对可缓存的结果做缓存尤其是相同或相似的查询。在低谷时段用批量任务处理非实时请求可能获得更低的单价。建立Token用量监控异常突增时能及时告警。8.2 可观测性“熬得久”的另一个前提是“看得清”。AI系统的故障模式比传统软件复杂传统系统是请求报错、超时、内存溢出AI系统还多了一个“接口正常返回但答案完全错误”的隐形故障。因此除了传统的日志、监控、链路追踪AI应用还需要记录模型层面的关键信息模型版本、Prompt版本、输入输出Token数、响应延迟、是否触发安全过滤、是否发生重试、最终用户是否点了“有用”按钮。推荐把每次模型调用记录成一条结构化日志方便后续做效果分析和问题回溯{ timestamp: 2025-01-01T10:00:00Z, api: /v1/chat/completions, model: qwen2.5-7b, prompt_version: v3, input_tokens: 1200, output_tokens: 340, latency_ms: 850, cache_hit: false, response_id: chatcmpl-xxx, app_id: knowledge-assistant }这些数据日积月累就构成了团队的“AI运营资产”。没有这些数据任何模型升级和Prompt优化都是盲目的。有了这些数据你才有了持续迭代的依据。9. 给开发者和AI团队的行动建议回到汤道生那句“熬得久比起得早更重要”对开发者来说它不是一句可以心安理得的安慰反而是一种更严格的要求早起可以靠运气和资源熬得久必须靠方法和纪律。结合前面提到的工程化实践我给正处在AI应用开发路上的团队几个具体建议。第一从一个小而真实的业务场景开始不要一上来就做通用大平台。场景越小越容易建立评测集、越容易定义成功指标也越容易在三个月内跑出可感知的价值。第二建立自己的评测基线把评测脚本纳入CI/CD流程。每次换模型、改Prompt、调参数都触发一次自动评测。这是确保“越改越好”而不是“越改越乱”的基础设施。第三不要被新模型发布打乱节奏。模型始终会迭代今天的最优解三个月后可能过时。你的核心资产不是某个具体模型而是围绕模型构建的评测体系、数据管道、Agent工作流和运维能力。第四重视成本和安全从第一天就纳入设计而不是等问题爆发再补救。尤其是Agent类应用权限边界、操作审计、人工确认机制一定要在早期想清楚。第五保持学习节奏但要让学习服务于项目。AI领域信息量很大每天都有新工具、新论文、新框架。如果只是追逐热点很容易陷入“学了很多却什么都没有落地”的状态。更稳妥的方式是带着真实问题去学每学一个技术就尝试把它接入到当前项目里。AI竞争到底是不是一场短跑时间会给出答案。但对身处其中的开发者来说唯一能确定的是把模型能力转化为工程能力的过程需要一步步走也需要跑起来。越早建立评测、部署、Agent、成本、可观测这套基础设施越能在“熬得久”的竞争中占据有利位置。如果你所在团队正好在讨论“现在入场AI是不是晚了”可以把这篇文章的核心判断作为参考晚了的是单纯追热度不晚的是用工程化把模型能力沉淀为系统能力。工具和模型会变但这个方向值得长期投入。
