1. 大模型的下半场，已经从“模型竞赛”转向“系统竞赛”
过去一年，做技术规划和产品立项的人应该都有一个共同感受：公开渠道能拿到的大模型，能力和价格都在快速内卷，但真正能稳定跑出业务价值的项目，反而没有想象中多。各大厂商每隔几个月就发布一版新模型，参数规模越卷越大，长文本、推理能力、多模态理解一个接一个被点亮，可落到企业内部，大家问得最多的已经不是“这个模型聪明不聪明”，而是“推理贵不贵、并发扛不扛得住、数据能不能私有化、能不能接进我们现有的系统”。这种信号其实非常明确：大模型的竞争重心，正在从“谁能训练出更强的模型”，切换到“谁能用可接受的成本把模型送进真实业务流程”。
预训练这条赛道的边际收益正在降低，这是行业里越来越多人愿意承认的事实。智能水平再往上提一档，需要的算力、数据和能耗是指数级增长，而能承接这种增量消耗的商业场景还没有同步增长。说得直白点，模型从80分涨到85分，用户未必感知得到，但为了这5分付出的推理成本翻倍，企业客户一算账就犹豫了。真正决定商业回报的，往往是模型之外的系统工程能力：部署是否方便、响应是否够快、私有化方案是否安全、运维是否简单。
从近期大家搜索的热词也能侧面验证这个判断。现在搜“大模型”的人，已经不满足于概念科普，更多是“大模型本地部署配置”“vllm部署大模型”“大模型微调”“大模型RAG怎么读”“多模态大模型”这类特别实操的问题。这和学习曲线是完全吻合的：第一波人问“什么是大模型”，第二波人问“怎么用API”，第三波人问“怎么在自己环境里跑起来并调好”。我们正处于第三波，也就是从“能聊天”过渡到“能用起来”的阶段。推演未来一到两年，谁能把单位Token成本打下来、把使用门槛降到普通工程师也能驾驭，谁就能在落地市场上占据主动权。
2. 推理成本与本地部署：物理账算清楚，方向才不会跑偏
2.1 显存墙与KV Cache：先理解钱花在哪了
部署大模型，第一个绕不开的就是显存。很多人以为模型加载就是把参数放进显存这么简单，实际上推理时的开销远不止参数本身。以7B模型为例，FP16精度下光参数就占了约14GB显存，再加上推理过程中要保存的KV Cache、临时激活值、CUDA上下文，一张24GB的消费级显卡跑7B模型，通常也就能给到几千Token的上下文窗口。如果你把上下文推到32K甚至128K，KV Cache会吃掉大块显存，这还不算并发请求同时到来时的显存竞争。
理解了这个物理账，就能解释为什么“本地部署”会成为搜索热词。很多企业并不是不想用大模型，而是数据不能出内网，或者每次调用云端API的成本太高、延迟不可控，于是自建推理成了刚需。但自建不是说买张显卡把模型拉下来就完事，还需要考虑吞吐量、并发请求、量化格式兼容性、推理框架选型等一系列问题。这一块没有统一答案，只有基于场景的权衡。
2.2 本地部署的三条主流突围路线
目前想在大模型本地部署上少踩坑，基本有三条路线可选。
第一条是面向桌面和边缘设备的轻量路线，代表方案是llama.cpp配合GGUF格式的量化模型。这种方案的优势在于对硬件极其宽容，CPU也能跑，Mac上也能用，4-bit量化之后，7B模型可以缩到4GB左右，普通16GB内存的笔记本都能流畅运行。它适合个人学习、离线知识库问答、以及不需要高并发的内部工具。缺点是吞吐量有限，GPU利用率不如专门的服务化框架，不适合大规模并发业务。
第二条是面向服务化部署的高性能路线，代表方案是vLLM。vLLM的核心优势是PagedAttention和Continuous Batching，前者把KV Cache按页管理，大幅降低显存碎片和浪费，后者让多个请求在同一个批次里动态进出，显著提升GPU利用率和吞吐量。对于面向内部几十上百人使用的知识库问答、客服辅助这类场景，vLLM是目前最主流的选择。需要注意，vLLM对显存规划比较敏感，max-model-len设得太大，或者gpu-memory-utilization设得太满，很容易OOM，实际配置时要多做压测。
第三条是单卡极限路线，比如用AirLLM这类方案把模型分层调度到显存和内存之间，让一张显卡也能加载70B级别的大模型。这种做法本质上是用带宽换显存，速度会比较慢，但在本地实验、模型效果验证、低频率推理场景下非常实用。很多人一上来就追求“跑最大模型”，其实如果场景允许，我更建议先用小模型验证完效果，再决定要不要上大参数方案。因为推理框架的工具链成熟度，往往比模型本身的参数量更影响落地效率。
2.3 服务端推理的选型参考
根据我自己的部署经验，可以做这样一个粗粒度的选型参考：
- 7B以内、CPU或边缘设备：llama.cpp + GGUF量化，兼顾易用性和资源占用
- 7B到14B、需要并发服务：vLLM + AWQ或GPTQ量化，用连续批处理提高吞吐
- 30B到70B、单机多卡：vLLM配合张量并行，注意调整KV Cache预留比例
- 70B以上、追求高并发高可靠：多节点推理集群或者直接走云端API
这个选型逻辑的核心不是“哪个框架最好”，而是“你的业务对延迟、吞吐、成本、数据安全四个指标分别有多敏感”。典型的例子是，有些企业数据敏感度极高，宁可牺牲一半性能也要全私有化，那服务端推理的选型就要优先考虑vLLM这类可定制性强、社区活跃的方案；如果是给C端用户做交互型产品，那延迟就是生命线，可能还要在模型量化和动态批处理上做更细的调优。
3. 多模态与Agent化：大模型正在从“聊天脑”变成“调度脑”
3.1 Agent化不等于多一个API，而是交互范式的改变
如果说2023年的主旋律是“对话式AI”，那未来两年的主线一定是“智能体化”。AI Agent这个概念的热度持续走高不是偶然，因为单轮对话能解决的问题太有限了。一个真正有用的AI，不仅要知道“怎么回答”，还要知道“什么时候该调工具、什么时候该查数据、什么时候该主动问用户”。这背后是模型能力的重构：从“文本生成器”变成“任务调度器”。
打个比方，以前的AI像一个知识渊博但坐在家里不动的顾问，你问一句它答一句；Agent化的AI更像一个项目经理，接到一个目标之后，自己拆解步骤、调用外部工具、验证中间结果，最后交付一个完整结果。这个转变对底层模型的要求非常高，因为工具调用、代码生成、结构化输出、错误恢复这些能力，都不只是“多几个训练字段”那么简单，而是模型对“世界如何运转”的理解又深了一层。
3.2 多模态不再是锦上添花，而是行业场景的刚需
多模态大模型的搜索热度同样说明了问题。现在很多真实场景，数据天然就是混合形态的：工厂里有设备运行日志，还有监控视频和PLC控制逻辑；医疗场景里有病历文字，也有医学影像；内容创作行业更是文本、图片、音频、视频一起上。比如有热词提到的“Audacity OpenVINO AI Effects”，就是音频处理工具接入本地AI能力的典型例子。这说明，多模态的价值不只是让模型“看得懂图、听得懂音”，而是让AI能进入那些原来根本没法数字化的场景，直接处理人类工作流里的原始信息。
未来推演下去，我认为多模态会沿着两个方向走：一是输入端融合，让模型同时解析文字、图像、音频、表格，形成统一理解；二是输出端生成，从文生图进化到可控的视频生成、语音克隆、3D内容生成。以“AI漫剧”这类内容形态为例，本质上就是脚本生成、分镜、配音、动画渲染这一整条流水线被AI重新串了一遍。这时模型的定位就变了：它不再是一个问答框，而是一座内容工厂的操作系统。
3.3 AI编程和工业代码生成，是Agent落地最快的试验场
编程领域是Agent落地最典型、也最容易被感知的场景。AI辅助编程工具已经在改变日常开发方式，但从“帮你补全代码”到“帮你完成整个任务模块”，中间还有很长的路。搜索热词里能看到“AI编程提示词”“AI PLC代码生成”“Next Drawio使用自定义大模型”这类具体需求，说明大家已经不满足于让AI写一段玩具代码，而是希望它直接嵌进生产工具链，生成可用的业务代码、自动绘制架构图、甚至配置工业控制逻辑。
我把这种趋势理解为“Agent优先的软件交付”：未来大量的重复性开发工作会由AI完成，人类工程师的角色从“写代码的人”变成“提需求和审代码的人”。这并不意味着程序员会消失，而是对工程师的抽象能力、系统设计能力、代码审查能力要求更高了。PLC这类工业场景也是如此，代码生成只是第一步，更难的是理解设备语义、安全规范和调试约束。谁能把领域知识结构化给到模型，谁就能训练出真正可用的工业代码生成助手。
4. RAG、微调与知识抽取：企业私有化落地的三驾马车
4.1 长上下文时代，RAG还有没有存在的必要？
“上下文窗口越来越长，RAG是不是要被淘汰了？”这是最近被问得最多的技术问题之一。我的观点很明确：长上下文和RAG不是替代关系，而是互补关系。长上下文的价值在于让模型一次性“读”更多材料，但它并不解决“如何精准找到关键信息”的问题。当知识库里有几万份文档，模型不可能每轮对话都把全部内容塞进去，这样做既不经济，也容易让注意力被无关信息稀释。
RAG的正确读法是三个字母分开念，它的核心思路是先检索再生成：先把文档切块、向量化、存进向量数据库，用户提问时先做相似度检索，把最相关的片段拿出来，再交给大模型组织答案。这套方案最大的好处是知识可更新、来源可追溯、领域可扩展，企业换一批文档，不需要重新训练模型，只要重新灌库就行。长上下文适合“一次性读长文档”的场景，RAG适合“从海量文档里找答案”的场景，两者同时部署在现代应用里是常态。
4.2 微调工具平民化，让行业模型门槛一降再降
RAG解决的是“让模型知道知识”，微调解决的是“让模型学会行为”。有些需求靠提示词和RAG是搞不定的，比如让模型严格按企业规定的格式输出、模仿特定文风、对某类专业术语有统一的偏好，这就是微调的用武之地。前几年微调是算法工程师的专属技能，现在以LLaMA Factory为代表的一站式微调平台把门槛大幅拉低，普通工程师也能在Web界面上完成数据集准备、LoRA微调、模型导出和评测。
我用过这类平台之后最大的感受是：微调本身越来越简单，难的是数据。模型最终学成什么样，几乎完全由训练数据的质量决定。给模型喂1000条风格统一、标注规范的高质量样本，效果可能好过喂10万条随便整理的脏数据。所以在微调这条路上，真正的工程重心应该放在“怎么构建一份均衡、无污染、覆盖边界情况的训练集”，而不是纠结用哪个微调框架跑得更快。工具只是把配方变成成品，配方好不好才是关键。
4.3 知识抽取框架：把公司文档变成结构化资产
知识抽取这个方向，过去在NLP领域属于“传统手艺”，但大模型时代它又焕发了第二春。“大模型知识抽取框架”之所以成为热门话题，是因为企业和机构内部有大量非结构化数据，比如合同、工单、维修记录、产品手册、科研论文，这些文档如果只做向量化检索，模型仍然难以进行复杂的逻辑推理。先把文档解析成实体、关系、属性组成的结构化知识图谱，再喂给大模型做问答和推理，准确率和可解释性都会提升一个档次。
做企业级知识库，我自己比较推荐“RAG+知识抽取”分层建设的思路：底层用知识抽取框架把核心实体和关系抽出来，构建领域知识图谱；上层把原始文档切片做成向量索引，负责兜底检索。这样既有精确查询的能力，又有模糊语义检索的覆盖。未来知识抽取工具会越来越自动化，但短期内，高质量的知识体系仍然离不开领域专家的参与。模型能抽出“有关系”的实体，但哪些关系对企业决策有意义，还是需要人来定义。
5. 安全对齐、红队与评测：可信大模型的“水电煤”
5.1 为什么“无限制生成”是一条走不通的歧路
互联网上“无限制AI聊天”“无禁词AI”这类关键词热度一直不低，这背后反映的其实是用户对“过于保守的模型回复”的不满。一些模型为了安全，经常出现过度拒答、套话连篇、答非所问的问题，用户问一个正常问题也被拦下来，体验很糟糕。这种情绪是真实的，我想每个做过模型产品的人都会遇到。但我们必须把“开放”“不敷衍”和“无限制”“无审核”两个概念分开：前者是产品体验问题，靠更好的对齐方法解决；后者是底线问题，真正无视安全边界的模型，使用起来会带来巨大的合规风险和社会危害。
我始终认为，大模型走向可信生产力，靠的不是放低安全标准，而是让安全机制更聪明。一个成熟的安全护栏应该做到“该放行的放行、该拦截的拦截、该引导的引导”，而不是一刀切。现在很多团队已经在研究更细粒度的意图识别和价值观对齐，让模型理解用户真正想解决的问题，而不是看到某些关键词就触发防御。这个方向的进步，才是“无限制感”和“安全性”同时满足的正路。
5.2 投毒测试、越狱测试与评测基准：未来会像等保一样普及
安全评测正在成为一个独立的工程领域，而不是模型训练完之后的附加环节。“大模型投毒测试”本身就是最近的大热词。所谓投毒测试，主要是验证两件事：一是模型在训练阶段有没有被恶意数据污染，二是模型在使用阶段会不会因为特定触发器而输出异常内容。对于开源模型，数据链路更长，投毒风险更高，很多安全团队已经开始对训练数据做血缘分析和异常检测，这个趋势只会越来越严格。
还有一类工作是红队测试和越狱测试。“CTF本地大模型”这个组合很有意思，说明安全圈的人已经开始把本地部署的模型当成一个攻防目标来研究。推演未来，企业上大模型之前做安全评估，会像做等保测评一样成为标准动作。评测维度也会越来越丰富：不能只看准确率，还要看幻觉率、拒答率、越狱成功率、数据泄露风险、对投毒样本的鲁棒性。可测性决定可信度，评测基础设施会成为整个AI产业的地基。
6. 普通人面对大模型：学习路线、职业冲击与个人选择
6.1 少儿编程会不会被大模型挤压？
我经常看到有人问“大模型会不会把少儿编程给挤压掉”，这个问题其实问偏了。被挤压的不是编程教育本身，而是过去那种以语法记忆和简单逻辑训练为主的编程教育。当AI能自动生成大量基础代码时，孩子再花大量时间背诵API、死磕语法细节，确实意义不大。但编程教育背后的计算思维、问题拆解能力、调试耐心，恰恰是大模型时代更稀缺的能力。
所以我觉得未来少儿编程会往两个方向分化：一是“AI启蒙”，教孩子怎么和大模型合作，学会提需求、拆问题、验证结果，这更像是思维训练；二是“机器人和硬件编程”，强调真实世界的动手能力，AI负责提供创意辅助，孩子负责把想法变成实物。这两个方向都不愁没价值，真正该淘汰的是让孩子照着PPT敲代码、然后跑出几个图形就结课的教学方式。
6.2 给想入行的人一份现实版学习路线
大模型相关学习资料的搜索热度一直很高，有人问“自学够不够”，有人问“要不要先读博士”。根据我自己带团队的经验，如果目标是进入这个行业做应用落地，最现实的学习路线可以分成四段：第一阶段是打基础，理解Transformer、注意力机制、Token化、预训练和RLHF的基本原理，不需要推导全部公式，但要知道每个模块解决什么问题；第二阶段是上手推理部署，把开源模型在自己电脑或云服务器上跑起来，试一遍llama.cpp、vLLM、量化配置，建立“模型到底多能吃资源”的体感；第三阶段是做微调和RAG，用公开数据集完成一次LoRA微调，再自己搭建一个带向量的知识库问答系统；第四阶段才是深入Agent和多模态项目，把工具调用、记忆管理、评估体系串起来。
这条路线看起来平缓，实际上每一段都会卡住一批人。第一段卡在“数学恐惧”，第二段卡在“环境配置”，第三段卡在“数据清洗”，第四段卡在“系统工程思维”。我见过不少人学了两周还在折腾环境变量，最后放弃了，其实如果只是先把开源模型跑起来，直接用一键部署脚本就好，不要一开始就和底层较劲。学习大模型和做工程一样，先把闭环跑通，再回来抠细节，效率会高很多。
如果让我给一个最朴素的学习建议，那就是：不要只当一个“Prompt工程师”，也不要把自己局限在“只会调库”。真正值钱的，是能理解模型能力边界、能设计评测方案、能把AI嵌进业务流程的人。这部分能力，没有哪个课程能直接教会你，只能在真实项目里一遍遍踩坑、复盘、再优化中长出来。说实话，现在这个时点入行大模型，门槛比两年前高了不少，但机会反而更实在，因为行业缺的不再是“能聊AI的人”，而是“能把AI用明白的人”。
回到整篇推演，我可以把自己的判断浓缩成一句话：大模型的未来，不是模型参数自己的独角戏，而是模型、工程、数据、安全、组织能力一起构成的系统战。能把单位成本降下来，把知识接进来，把安全做到位，把人才梯队在业务里长出来，谁就有机会走到下一轮。
