过去一年做 AI 应用开发的同学应该都有一个直观感受模型能力迭代得飞快但真正把模型用好、用稳、用出成本优势难度反而比两年前大了不少。我最近在整理团队 AI 基础设施的时候正好看到台积电 2026 年第二季度奖金放出了约 360 亿新台币、同比增长 50.6% 的消息。乍一看这是财经新闻但站在技术人的角度它释放的信号非常明确AI 算力需求正在把半导体产业链的利润和人才一起推高而终端应用开发者如果不把底层推理、部署、GPU 资源管理这些硬技能补起来后续很容易在项目落地时被算力成本和技术断层卡住。这篇文章不打算做泛泛的行业分析而是从“AI 人才争夺”这个现象切入把开发者需要关注的核心技术链路拆开从芯片与算力基础设施到本地 GPU 推理部署再到 AI Agent 开发和企业级框架集成。全文会给出可复制的命令和代码重点演示 Ollama 本地部署、Python 最小 Agent 实现、Spring AI 集成三个场景最后补上常见问题排查和工程化建议。无论你是刚接触大模型的初级开发者还是已经在做 AI 应用落地的后端工程师都能从中找到可操作的部分。1. 从台积电奖金增长看 AI 算力需求的传导路径1.1 奖金数字背后的产业逻辑台积电 2026 年第二季度奖金约 360 亿新台币、同比增长 50.6%这个幅度在半导体行业里属于非常显著的增长。奖金池变大的直接原因是先进制程产能利用率提升、相关 AI 芯片订单增加带来的利润改善。更深一层看它反映的是 AI 产业链从上到下的需求传导大模型训练需要大量 GPU而 GPU 依赖先进制程与先进封装。推理需求爆发后推理芯片的出货量持续增长对产能提出更高要求。芯片良率提升、封装测试、固件开发都需要持续投入人力。这条链条最终会落到一句话AI 不是纯软件工程它高度依赖算力基础设施。开发者如果只会在云端调 API不了解底层推理是怎么跑的、显存是怎么占用的、成本是怎么产生的在真正的生产项目里会遇到大量瓶颈。1.2 对应用开发者的实际影响很多同学会觉得“芯片公司赚钱和我写业务代码有什么关系”。其实关系非常直接。第一算力成本会直接影响你选择模型和部署方式。AI 芯片供不应求时云端 GPU 实例的价格波动会传导到 API 调用成本和自建推理成本上。第二企业对 AI 岗位的期待已经从“会用 API”变成“能降本增效”。同样是做一个智能问答系统一个只会调接口的工程师和一个能通过量化、批处理、本地化部署把单次调用成本降低一半的工程师价值差距非常大。第三大模型应用正在从“原型验证”走向“生产落地”企业对推理性能、稳定性、可观测性的要求越来越高这部分恰好需要扎实的工程能力。所以与其把台积电的奖金新闻当谈资不如把它当作一个提醒AI 人才争夺的本质是对“能驾驭算力基础设施的工程型人才”的争夺。2. AI 算力产业链中的关键技术环节要理解 AI 工程化需要哪些技能先要把 AI 算力产业链拆成几个层次。每个层次对应不同的技术栈和岗位角色。2.1 芯片设计与制造层这一层是台积电所处的环节包括 IC 设计、晶圆制造、先进封装如 CoWoS、测试验证。对应的技术岗位偏向硬件方向固件开发、芯片验证、EDA 工具使用、数字电路设计。对普通应用开发者来说这一层不需要深入但理解“GPU 为什么稀缺”“先进封装为什么影响算力供给”对后续做资源规划有帮助。2.2 硬件与算力平台层这一层是应用开发者最容易接触到的部分包括 GPU/NPU 驱动、CUDA、ROCm、TensorRT-LLM、vLLM 等推理引擎。无论是自己部署模型还是使用云平台你都会遇到以下概念CUDA 版本与显卡驱动的兼容关系。显存VRAM容量对模型参数量级和并发数的限制。推理引擎的批处理、KV Cache 优化等机制。这一层的能力直接决定模型能不能在有限硬件上跑起来以及跑起来的效率如何。2.3 云与基础设施层当应用规模变大单机推理无法满足需求时就需要进入基础设施层Kubernetes 集群、GPU 节点调度、弹性扩缩容、推理服务的高可用。这一层关注的不是“模型怎么回答”而是“服务怎么稳定”。很多大厂招 AI 平台工程师时看的正是这部分的经验。2.4 模型与推理层模型层包含模型选择、微调、量化、蒸馏、RAG 知识库组织等。大部分业务团队不会从零训练模型而是基于开源模型或商业 API 做二次开发这就要求开发者理解不同尺寸模型的推理成本差异。模型量化如 INT8、INT4对显存占用和输出质量的影响。RAG 中向量检索、重排序、上下文拼接的工程细节。2.5 应用与产品层应用层是绝大多数 AI 开发者日常工作的位置用 Agent 框架编排工具调用用 Spring AI、LangChain4j 等框架集成大模型开发带状态的多轮对话系统处理流式输出等。这一层的技术迭代非常快需要持续跟进。3. AI 工程开发者需要掌握的核心技能栈结合上面的产业链拆解我从工程落地的角度梳理了一套 AI 开发者技能栈。这套技能栈不要求你成为芯片专家但每一项都能直接提升项目交付质量。3.1 模型推理与本地部署能力在项目早期最快的验证方式是直接调用商业大模型 API但到了需要控制成本、满足数据合规、降低延迟的阶段就必须具备本地部署能力。推荐从 Ollama 入手它是一个非常轻量的本地推理工具支持多种开源模型安装简单适合个人开发者和团队原型验证。3.2 GPU 资源管理与性能观测部署完成后开发者需要能判断“模型到底有没有用上 GPU”。这就涉及nvidia-smi、rocm-smi等命令的使用以及 CUDA/ROCm 版本兼容性的排查。我见过不少项目模型明明部署了但推理速度非常慢最后发现是因为驱动版本不对模型一直在用 CPU 跑。这种问题如果不会排查会浪费大量时间。3.3 模型接口协议与框架集成现在主流推理服务和云厂商基本都提供了 OpenAI 兼容的 HTTP 接口也就是说你只要学会一套chat/completions协议的调用方式就可以在中切换不同的模型后端。这种标准化让 Spring AI 等框架的集成变得简单也让 Python、Java 两种技术栈的团队可以共用同一套推理基础设施。3.4 AI Agent 开发能力AI Agent 是大模型应用从“对话机器人”走向“自动化执行”的关键。它的核心不只是调用模型还包括工具定义、结果解析、上下文管理和任务拆分。没有 Agent 能力的 AI 应用很难处理复杂业务场景。4. 实战一本地 GPU 推理环境搭建接下来进入实操环节。第一个实战演示如何用 Ollama 在本地搭建 GPU 推理环境并验证模型是否真正使用了显卡。这个步骤是大模型应用开发的“地基”后续的 Python 调用、Spring AI 集成都会建立在它之上。4.1 环境准备本文示例环境如下实际项目可按你的机器配置调整操作系统Ubuntu 22.04Windows/macOS 也有对应安装方式。GPUNVIDIA 显卡优先需要安装显卡驱动AMD 显卡依赖 ROCm 运行时。推理工具Ollama。模型以 qwen2.5:7b 示例显存不足时可换成 qwen2.5:3b。需要注意Ollama 对 AMD 显卡的支持依赖 ROCm且不同版本对显卡型号和驱动版本有要求。如果你的 AMD 显卡不在支持列表里建议先切换回 NVIDIA 环境或者用 CPU 模式跑小模型验证流程。4.2 安装 OllamaLinux 下可以直接使用官方安装脚本curl -fsSL https://ollama.com/install.sh | sh安装完成后确认服务状态systemctl status ollama如果服务正常会看到active (running)的状态信息。启动后Ollama 默认监听本机的11434端口后续所有本地请求都走这个端口。4.3 拉取并运行模型拉取和运行模型都很直接# 拉取 7B 参数模型 ollama pull qwen2.5:7b # 交互式运行 ollama run qwen2.5:7b第一次拉取因为模型文件较大可能需要等待一段时间。交互式运行后你可以直接在终端输入问题验证模型能否正常回复。4.4 验证 GPU 是否启用这一步最关键。打开另一个终端运行 NVIDIA 显卡的状态命令nvidia-smi -l 1如果模型正确跑在 GPU 上你会在进程列表里看到ollama对应的进程并且显存占用会明显上升7B 模型量化后通常占 4~8GB 左右。如果你发现显存占用为 0模型基本就是在用 CPU 推理需要检查驱动和 Ollama 的 GPU 支持。AMD 显卡环境可以使用rocm-smi --showuse4.5 通过 HTTP 接口调用本地模型Ollama 提供了 OpenAI 兼容接口这让后续用 Python、Java 调用变得非常统一。验证命令如下curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 用一句话解释什么是 RAG}], stream: false }正常情况下你会收到一个 JSON 响应其中choices[0].message.content字段就是模型生成的回答。这里有一个细节需要注意Ollama 的 OpenAI 兼容接口路径是/v1/chat/completions不是/api/chat后者的请求和响应格式更底层。为了让代码可以平滑切换到云厂商服务统一使用前者更好。5. 实战二用 Python 实现一个最小 AI Agent模型部署完成之后就可以开始做更有价值的应用了。这一节我们实现一个最小的 AI Agent核心是利用模型的工具调用能力让模型在需要时调用外部函数。这里我以“查询天气”为示例场景完整代码可复制运行。5.1 项目结构与依赖先创建项目目录mkdir agent_demo cd agent_demo本示例只需要requests库pip install requests5.2 核心代码实现下面的代码实现了 Agent 的主循环把用户问题发送给模型如果模型决定调用工具就执行对应函数并把工具结果返回给模型让模型基于工具结果生成最终回答。# 文件路径agent_demo/main.py import json import requests # 本地 Ollama 的 OpenAI 兼容接口 API_URL http://localhost:11434/v1/chat/completions # 本地服务没有严格鉴权key 可以任意填写 API_KEY ollama MODEL_NAME qwen2.5:7b def call_model(messages, toolsNone): 调用大模型接口支持携带工具定义 payload { model: MODEL_NAME, messages: messages, tools: tools or [], stream: False, } headers {Authorization: fBearer {API_KEY}} resp requests.post(API_URL, jsonpayload, headersheaders, timeout120) resp.raise_for_status() return resp.json() def get_weather(city: str) - str: 模拟天气查询工具实际项目中可替换为真实天气 API # 生产环境请调用真实数据源并增加超时和异常兜底 return f{city} 当前气温 26 摄氏度微风空气质量良好。 def run_agent(user_input: str) - str: Agent 主循环 messages [{role: user, content: user_input}] tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气情况, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city], }, }, } ] for step in range(5): result call_model(messages, tools) message result[choices][0][message] messages.append(message) tool_calls message.get(tool_calls) if not tool_calls: return message.get(content, ) for tool_call in tool_calls: fn_name tool_call[function][name] args json.loads(tool_call[function][arguments]) print(f[Agent 第 {step 1} 步] 调用工具 {fn_name}参数 {args}) if fn_name get_weather: observation get_weather(args[city]) else: observation f未知工具: {fn_name} messages.append( { role: tool, tool_call_id: tool_call[id], content: json.dumps(observation, ensure_asciiFalse), } ) return 达到最大执行轮次未能完成请求。 if __name__ __main__: answer run_agent(我想知道杭州今天的天气适合穿短袖吗) print(最终回答, answer)5.3 代码逻辑拆解这段代码的核心逻辑值得逐段说明。call_model函数是 Agent 与模型通信的唯一入口。它接受消息列表和工具定义列表统一封装了 HTTP 请求。这里的重点是tools参数它告诉模型“你可以调用哪些能力”模型本身并不执行工具它只负责根据对话内容决定是否需要调用工具以及调用时应该传入什么参数。run_agent函数则是一个标准的 Agent 循环包含四步发送消息、检查模型是否请求调用工具、执行工具、把工具结果回传给模型。循环设置 5 次的上限防止模型陷入反复调用的死循环。还有一个容易忽略的细节工具执行结果必须以role: tool的消息回传给模型并且要携带tool_call_id这样模型才能把工具结果和之前的工具调用请求关联起来。如果漏掉tool_call_id很多模型会报错或者无法理解上下文。5.4 运行与预期结果python main.py如果一切正常你会看到类似输出[Agent 第 1 步] 调用工具 get_weather参数 {city: 杭州} 最终回答 杭州今天气温约 26 摄氏度比较舒适可以穿短袖。实际输出文本会因为模型版本不同而有差异但关键流程是一样的模型自动判断需要查天气生成工具调用拿到结果后组织最终回答。这就是 AI Agent 最基本的形态再往上做就是在循环里加入更复杂的任务规划、多工具组合和记忆管理。6. 实战三Spring AI 集成大模型服务Java 后端团队在实践中更常用 Spring AI 这类框架来集成大模型。Spring AI 的定位有点类似 Spring 生态中的“AI 版 JdbcTemplate”屏蔽了底层 HTTP 调用的细节让你可以用熟悉的依赖注入和配置方式接入模型。6.1 添加 Maven 依赖Spring AI 的版本迭代很快建议使用与 Spring Boot 版本匹配的 BOM 统一管理。这里以 1.0.0 系列为例实际使用时请以官方发布的最新稳定版为准。!-- 文件路径pom.xml -- dependencyManagement dependencies dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-bom/artifactId version1.0.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId /dependency /dependencies使用 OpenAI Starter 的原因是它支持配置base-url指向任意兼容 OpenAI 协议的服务。也就是说我们既可以接 OpenAI也可以接本地 Ollama还能接国内各类兼容网关这一层是可替换的。6.2 配置文件在application.properties中把 Spring AI 指向本地 Ollama# 文件路径src/main/resources/application.properties spring.ai.openai.base-urlhttp://localhost:11434/v1 spring.ai.openai.api-keylocal spring.ai.openai.chat.options.modelqwen2.5:7b spring.ai.openai.chat.options.temperature0.7这段配置把 Spring AI 的 OpenAI 通道指向了本地 11434 端口。api-key填什么都行因为本地服务不校验。temperature0.7控制生成内容的随机性需要稳定输出时可以调低到 0.2 左右。6.3 编写调用接口下面是一个完整的 Controller演示如何通过ChatClient构建一个简单的问答接口。// 文件路径src/main/java/com/example/aichat/AiChatApplication.java package com.example.aichat; import org.springframework.ai.chat.client.ChatClient; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.context.annotation.Bean; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; SpringBootApplication public class AiChatApplication { public static void main(String[] args) { SpringApplication.run(AiChatApplication.class, args); } Bean ChatClient chatClient(ChatClient.Builder builder) { return builder.build(); } RestController public static class ChatController { private final ChatClient chatClient; public ChatController(ChatClient chatClient) { this.chatClient chatClient; } GetMapping(/ask) public String ask(RequestParam String question) { return chatClient.prompt() .user(question) .call() .content(); } } }这里有两个地方需要解释。第一ChatClient是 Spring AI 提供的流式接口客户端通过构造器注入方便后续统一配置系统提示词和默认参数。第二prompt().user(question).call().content()是它的标准链式调用逻辑很直观构造提示词、发起调用、取出文本结果。6.4 运行验证mvn spring-boot:run启动成功后浏览器或命令行访问curl http://localhost:8080/ask?question%E4%BB%8B%E7%BB%8D%E4%B8%80%E4%B8%8B%E4%BD%A0%E8%87%AA%E5%B7%B1参数question是 URL 编码后的“介绍一下你自己”。如果返回了模型生成的内容说明 Spring AI 到本地 Ollama 的链路已经打通。实际项目中不建议直接在 Controller 里写完整的对话逻辑。更合理的做法是抽象一个AiService层把系统提示词、历史消息管理、工具调用封装在里面Controller 只负责参数转换和响应包装。这也是 Spring AI 官方推荐的分层方式。7. 常见问题与排查思路在实际部署和集成过程中下面几个问题是出现频率最高的。这里以表格形式整理方便你遇到问题时快速定位。问题现象常见原因解决思路模型运行很慢GPU 显存占用为 0显卡驱动或 ROCm 未正确安装模型回退到 CPU 推理用nvidia-smi或rocm-smi检查驱动确认 Ollama 日志中是否识别到 GPU拉取模型时一直卡住或超时模型文件体积大网络不稳定检查网络连通性可先拉取 3B 小模型验证企业环境可配置镜像源Spring Boot 启动报 LLM 相关 Bean 创建失败spring.ai.*配置前缀写错或依赖版本与 Boot 版本不兼容核对官方文档的配置项查看启动日志中的自动装配报告调用本地接口返回 401OpenAI 兼容接口要求携带 Authorization 头本地 Ollama 的 key 可以随便填但请求头不能省略工具调用准确率低或反复调用失败tool schema 描述模糊或模型本身不支持 function calling精简参数描述换用支持工具调用的模型限制最大轮次避免死循环爆显存导致 OOM模型参数量超过显存容量或并发请求过多换小模型或量化版本开启 KV Cache 优化控制并发数必要时加 GPU 内存调度模型输出不稳定同一个问题答案波动大temperature 设置偏高需要稳定答案时把 temperature 调到 0.1~0.3并增加输出格式约束排查这一类问题的通用思路建议按“驱动层 → 服务层 → 应用层”的顺序来。先确认 GPU 状态和驱动版本再看模型的部署服务日志有没有报错最后才去检查应用代码。很多开发者在服务层还没确认正常的情况下就开始排查代码效率很低。8. 最佳实践与工程建议到这里三个实战场景都已经跑通了。但要真正把这些能力用在生产项目中还需要注意几个工程化层面的问题。8.1 模型选型与成本控制同一个业务场景7B 模型和 70B 模型的推理成本可能相差一个数量级。建议按照任务的复杂度分级选模型简单分类、抽取任务用 7B 甚至 3B 模型复杂推理、代码生成再上大模型。同时要考虑量化策略INT8 或 INT4 量化能显著降低显存占用但对输出质量有轻微影响需要做效果回归测试。8.2 本地部署与云端 API 的取舍当项目遇到数据隐私、延迟或成本问题时优先考虑本地部署但本地部署意味着你要自己承担 GPU 运维、模型更新和可用性保障的成本。更务实的做法是“本地 云端 API”混合模式日常低风险请求走本地模型复杂任务或者本地负载过高时回退到云端 API这样既能控制成本又不会牺牲峰值场景的可用性。8.3 Prompt 与工具 Schema 的版本管理这是很多人容易忽略的点。Prompt 的微调会直接影响模型输出质量而工具 Schema 的改动会影响 Agent 的调用准确率。建议把 Prompt 模板和工具定义都纳入版本控制必要时为 Prompt 建立独立的配置中心方便灰度调整和快速回滚。8.4 设置评估回路模型输出是概率性的每次升级模型版本或调整 Prompt 后都要用一套固定的评测集做回归。评测集不需要很大但必须覆盖你的核心业务场景。可以准备 20~50 条代表性输入用“通过/不通过”的方式快速比对避免“感觉变好了”的主观判断。8.5 安全与权限边界AI Agent 接入了工具调用之后安全问题会成倍放大。给 Agent 授权的工具必须遵循最小权限原则例如天气查询、计算器这类只读工具可以放开但涉及写数据库、发消息、删除文件的工具必须增加人工确认环节。同时要注意提示词注入风险——用户输入可能诱导模型执行非预期操作必要时对用户输入做清洗和鉴权。8.6 可观测性与日志记录生产环境里你需要知道每次请求消耗了多少 token、耗时多少、调用了哪些工具、最终是否成功。建议在 Agent 调用层统一埋点输出结构化日志并统计请求量、成功率、平均延迟、Token 成本和工具调用分布。有了这些数据后续做成本优化和模型选型才有依据。9. 总结与学习路线回到开头的问题台积电奖金大幅增长对普通开发者意味着什么我的理解是它意味着 AI 行业的竞争正在从“拼想法”转向“拼工程落地”。芯片产能和算力资源越来越宝贵谁能高效地把模型部署好、把成本降下来、把 Agent 做得稳定谁就能在下一阶段拿到更高的技术溢价。如果你想沿着这个方向系统提升可以按下面的路线推进先跑通一条完整的本地推理链路掌握 GPU 状态查看和模型部署这是基础。再用 Python 或 Spring AI 实现一个带工具调用的 Agent理解模型、工具、上下文之间的关系。接着给 Agent 加上评测集和日志埋点把“能不能跑”变成“跑得好不好”。最后再考虑多 Agent 协作、分布式推理、微调和量化等进阶主题这些都需要前三步的工程基础。坦白说AI 工程化这条路没有捷径新技术出现的速度也远超普通人的学习速度。最有效的方式不是追每一个新框架而是把模型调用协议、推理资源管理、评估与安全这些“不变的东西”吃透。之后再看到新的 Agent 框架、新的模型版本你只需要花半天时间就能迁移过去。如果这篇文章里的某个实战步骤帮你解决了问题或者你对哪一部分还有疑问可以收藏备用也欢迎在评论区留言交流。下一步我更建议你亲手把 Ollama 跑起来用一台带 GPU 的机器体验一次从部署到调用 API 的完整过程这比看十篇文章都管用。 AI算力需求下的工程化实战：从本地GPU推理到Agent开发
过去一年做 AI 应用开发的同学应该都有一个直观感受模型能力迭代得飞快但真正把模型用好、用稳、用出成本优势难度反而比两年前大了不少。我最近在整理团队 AI 基础设施的时候正好看到台积电 2026 年第二季度奖金放出了约 360 亿新台币、同比增长 50.6% 的消息。乍一看这是财经新闻但站在技术人的角度它释放的信号非常明确AI 算力需求正在把半导体产业链的利润和人才一起推高而终端应用开发者如果不把底层推理、部署、GPU 资源管理这些硬技能补起来后续很容易在项目落地时被算力成本和技术断层卡住。这篇文章不打算做泛泛的行业分析而是从“AI 人才争夺”这个现象切入把开发者需要关注的核心技术链路拆开从芯片与算力基础设施到本地 GPU 推理部署再到 AI Agent 开发和企业级框架集成。全文会给出可复制的命令和代码重点演示 Ollama 本地部署、Python 最小 Agent 实现、Spring AI 集成三个场景最后补上常见问题排查和工程化建议。无论你是刚接触大模型的初级开发者还是已经在做 AI 应用落地的后端工程师都能从中找到可操作的部分。1. 从台积电奖金增长看 AI 算力需求的传导路径1.1 奖金数字背后的产业逻辑台积电 2026 年第二季度奖金约 360 亿新台币、同比增长 50.6%这个幅度在半导体行业里属于非常显著的增长。奖金池变大的直接原因是先进制程产能利用率提升、相关 AI 芯片订单增加带来的利润改善。更深一层看它反映的是 AI 产业链从上到下的需求传导大模型训练需要大量 GPU而 GPU 依赖先进制程与先进封装。推理需求爆发后推理芯片的出货量持续增长对产能提出更高要求。芯片良率提升、封装测试、固件开发都需要持续投入人力。这条链条最终会落到一句话AI 不是纯软件工程它高度依赖算力基础设施。开发者如果只会在云端调 API不了解底层推理是怎么跑的、显存是怎么占用的、成本是怎么产生的在真正的生产项目里会遇到大量瓶颈。1.2 对应用开发者的实际影响很多同学会觉得“芯片公司赚钱和我写业务代码有什么关系”。其实关系非常直接。第一算力成本会直接影响你选择模型和部署方式。AI 芯片供不应求时云端 GPU 实例的价格波动会传导到 API 调用成本和自建推理成本上。第二企业对 AI 岗位的期待已经从“会用 API”变成“能降本增效”。同样是做一个智能问答系统一个只会调接口的工程师和一个能通过量化、批处理、本地化部署把单次调用成本降低一半的工程师价值差距非常大。第三大模型应用正在从“原型验证”走向“生产落地”企业对推理性能、稳定性、可观测性的要求越来越高这部分恰好需要扎实的工程能力。所以与其把台积电的奖金新闻当谈资不如把它当作一个提醒AI 人才争夺的本质是对“能驾驭算力基础设施的工程型人才”的争夺。2. AI 算力产业链中的关键技术环节要理解 AI 工程化需要哪些技能先要把 AI 算力产业链拆成几个层次。每个层次对应不同的技术栈和岗位角色。2.1 芯片设计与制造层这一层是台积电所处的环节包括 IC 设计、晶圆制造、先进封装如 CoWoS、测试验证。对应的技术岗位偏向硬件方向固件开发、芯片验证、EDA 工具使用、数字电路设计。对普通应用开发者来说这一层不需要深入但理解“GPU 为什么稀缺”“先进封装为什么影响算力供给”对后续做资源规划有帮助。2.2 硬件与算力平台层这一层是应用开发者最容易接触到的部分包括 GPU/NPU 驱动、CUDA、ROCm、TensorRT-LLM、vLLM 等推理引擎。无论是自己部署模型还是使用云平台你都会遇到以下概念CUDA 版本与显卡驱动的兼容关系。显存VRAM容量对模型参数量级和并发数的限制。推理引擎的批处理、KV Cache 优化等机制。这一层的能力直接决定模型能不能在有限硬件上跑起来以及跑起来的效率如何。2.3 云与基础设施层当应用规模变大单机推理无法满足需求时就需要进入基础设施层Kubernetes 集群、GPU 节点调度、弹性扩缩容、推理服务的高可用。这一层关注的不是“模型怎么回答”而是“服务怎么稳定”。很多大厂招 AI 平台工程师时看的正是这部分的经验。2.4 模型与推理层模型层包含模型选择、微调、量化、蒸馏、RAG 知识库组织等。大部分业务团队不会从零训练模型而是基于开源模型或商业 API 做二次开发这就要求开发者理解不同尺寸模型的推理成本差异。模型量化如 INT8、INT4对显存占用和输出质量的影响。RAG 中向量检索、重排序、上下文拼接的工程细节。2.5 应用与产品层应用层是绝大多数 AI 开发者日常工作的位置用 Agent 框架编排工具调用用 Spring AI、LangChain4j 等框架集成大模型开发带状态的多轮对话系统处理流式输出等。这一层的技术迭代非常快需要持续跟进。3. AI 工程开发者需要掌握的核心技能栈结合上面的产业链拆解我从工程落地的角度梳理了一套 AI 开发者技能栈。这套技能栈不要求你成为芯片专家但每一项都能直接提升项目交付质量。3.1 模型推理与本地部署能力在项目早期最快的验证方式是直接调用商业大模型 API但到了需要控制成本、满足数据合规、降低延迟的阶段就必须具备本地部署能力。推荐从 Ollama 入手它是一个非常轻量的本地推理工具支持多种开源模型安装简单适合个人开发者和团队原型验证。3.2 GPU 资源管理与性能观测部署完成后开发者需要能判断“模型到底有没有用上 GPU”。这就涉及nvidia-smi、rocm-smi等命令的使用以及 CUDA/ROCm 版本兼容性的排查。我见过不少项目模型明明部署了但推理速度非常慢最后发现是因为驱动版本不对模型一直在用 CPU 跑。这种问题如果不会排查会浪费大量时间。3.3 模型接口协议与框架集成现在主流推理服务和云厂商基本都提供了 OpenAI 兼容的 HTTP 接口也就是说你只要学会一套chat/completions协议的调用方式就可以在中切换不同的模型后端。这种标准化让 Spring AI 等框架的集成变得简单也让 Python、Java 两种技术栈的团队可以共用同一套推理基础设施。3.4 AI Agent 开发能力AI Agent 是大模型应用从“对话机器人”走向“自动化执行”的关键。它的核心不只是调用模型还包括工具定义、结果解析、上下文管理和任务拆分。没有 Agent 能力的 AI 应用很难处理复杂业务场景。4. 实战一本地 GPU 推理环境搭建接下来进入实操环节。第一个实战演示如何用 Ollama 在本地搭建 GPU 推理环境并验证模型是否真正使用了显卡。这个步骤是大模型应用开发的“地基”后续的 Python 调用、Spring AI 集成都会建立在它之上。4.1 环境准备本文示例环境如下实际项目可按你的机器配置调整操作系统Ubuntu 22.04Windows/macOS 也有对应安装方式。GPUNVIDIA 显卡优先需要安装显卡驱动AMD 显卡依赖 ROCm 运行时。推理工具Ollama。模型以 qwen2.5:7b 示例显存不足时可换成 qwen2.5:3b。需要注意Ollama 对 AMD 显卡的支持依赖 ROCm且不同版本对显卡型号和驱动版本有要求。如果你的 AMD 显卡不在支持列表里建议先切换回 NVIDIA 环境或者用 CPU 模式跑小模型验证流程。4.2 安装 OllamaLinux 下可以直接使用官方安装脚本curl -fsSL https://ollama.com/install.sh | sh安装完成后确认服务状态systemctl status ollama如果服务正常会看到active (running)的状态信息。启动后Ollama 默认监听本机的11434端口后续所有本地请求都走这个端口。4.3 拉取并运行模型拉取和运行模型都很直接# 拉取 7B 参数模型 ollama pull qwen2.5:7b # 交互式运行 ollama run qwen2.5:7b第一次拉取因为模型文件较大可能需要等待一段时间。交互式运行后你可以直接在终端输入问题验证模型能否正常回复。4.4 验证 GPU 是否启用这一步最关键。打开另一个终端运行 NVIDIA 显卡的状态命令nvidia-smi -l 1如果模型正确跑在 GPU 上你会在进程列表里看到ollama对应的进程并且显存占用会明显上升7B 模型量化后通常占 4~8GB 左右。如果你发现显存占用为 0模型基本就是在用 CPU 推理需要检查驱动和 Ollama 的 GPU 支持。AMD 显卡环境可以使用rocm-smi --showuse4.5 通过 HTTP 接口调用本地模型Ollama 提供了 OpenAI 兼容接口这让后续用 Python、Java 调用变得非常统一。验证命令如下curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 用一句话解释什么是 RAG}], stream: false }正常情况下你会收到一个 JSON 响应其中choices[0].message.content字段就是模型生成的回答。这里有一个细节需要注意Ollama 的 OpenAI 兼容接口路径是/v1/chat/completions不是/api/chat后者的请求和响应格式更底层。为了让代码可以平滑切换到云厂商服务统一使用前者更好。5. 实战二用 Python 实现一个最小 AI Agent模型部署完成之后就可以开始做更有价值的应用了。这一节我们实现一个最小的 AI Agent核心是利用模型的工具调用能力让模型在需要时调用外部函数。这里我以“查询天气”为示例场景完整代码可复制运行。5.1 项目结构与依赖先创建项目目录mkdir agent_demo cd agent_demo本示例只需要requests库pip install requests5.2 核心代码实现下面的代码实现了 Agent 的主循环把用户问题发送给模型如果模型决定调用工具就执行对应函数并把工具结果返回给模型让模型基于工具结果生成最终回答。# 文件路径agent_demo/main.py import json import requests # 本地 Ollama 的 OpenAI 兼容接口 API_URL http://localhost:11434/v1/chat/completions # 本地服务没有严格鉴权key 可以任意填写 API_KEY ollama MODEL_NAME qwen2.5:7b def call_model(messages, toolsNone): 调用大模型接口支持携带工具定义 payload { model: MODEL_NAME, messages: messages, tools: tools or [], stream: False, } headers {Authorization: fBearer {API_KEY}} resp requests.post(API_URL, jsonpayload, headersheaders, timeout120) resp.raise_for_status() return resp.json() def get_weather(city: str) - str: 模拟天气查询工具实际项目中可替换为真实天气 API # 生产环境请调用真实数据源并增加超时和异常兜底 return f{city} 当前气温 26 摄氏度微风空气质量良好。 def run_agent(user_input: str) - str: Agent 主循环 messages [{role: user, content: user_input}] tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气情况, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city], }, }, } ] for step in range(5): result call_model(messages, tools) message result[choices][0][message] messages.append(message) tool_calls message.get(tool_calls) if not tool_calls: return message.get(content, ) for tool_call in tool_calls: fn_name tool_call[function][name] args json.loads(tool_call[function][arguments]) print(f[Agent 第 {step 1} 步] 调用工具 {fn_name}参数 {args}) if fn_name get_weather: observation get_weather(args[city]) else: observation f未知工具: {fn_name} messages.append( { role: tool, tool_call_id: tool_call[id], content: json.dumps(observation, ensure_asciiFalse), } ) return 达到最大执行轮次未能完成请求。 if __name__ __main__: answer run_agent(我想知道杭州今天的天气适合穿短袖吗) print(最终回答, answer)5.3 代码逻辑拆解这段代码的核心逻辑值得逐段说明。call_model函数是 Agent 与模型通信的唯一入口。它接受消息列表和工具定义列表统一封装了 HTTP 请求。这里的重点是tools参数它告诉模型“你可以调用哪些能力”模型本身并不执行工具它只负责根据对话内容决定是否需要调用工具以及调用时应该传入什么参数。run_agent函数则是一个标准的 Agent 循环包含四步发送消息、检查模型是否请求调用工具、执行工具、把工具结果回传给模型。循环设置 5 次的上限防止模型陷入反复调用的死循环。还有一个容易忽略的细节工具执行结果必须以role: tool的消息回传给模型并且要携带tool_call_id这样模型才能把工具结果和之前的工具调用请求关联起来。如果漏掉tool_call_id很多模型会报错或者无法理解上下文。5.4 运行与预期结果python main.py如果一切正常你会看到类似输出[Agent 第 1 步] 调用工具 get_weather参数 {city: 杭州} 最终回答 杭州今天气温约 26 摄氏度比较舒适可以穿短袖。实际输出文本会因为模型版本不同而有差异但关键流程是一样的模型自动判断需要查天气生成工具调用拿到结果后组织最终回答。这就是 AI Agent 最基本的形态再往上做就是在循环里加入更复杂的任务规划、多工具组合和记忆管理。6. 实战三Spring AI 集成大模型服务Java 后端团队在实践中更常用 Spring AI 这类框架来集成大模型。Spring AI 的定位有点类似 Spring 生态中的“AI 版 JdbcTemplate”屏蔽了底层 HTTP 调用的细节让你可以用熟悉的依赖注入和配置方式接入模型。6.1 添加 Maven 依赖Spring AI 的版本迭代很快建议使用与 Spring Boot 版本匹配的 BOM 统一管理。这里以 1.0.0 系列为例实际使用时请以官方发布的最新稳定版为准。!-- 文件路径pom.xml -- dependencyManagement dependencies dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-bom/artifactId version1.0.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId /dependency /dependencies使用 OpenAI Starter 的原因是它支持配置base-url指向任意兼容 OpenAI 协议的服务。也就是说我们既可以接 OpenAI也可以接本地 Ollama还能接国内各类兼容网关这一层是可替换的。6.2 配置文件在application.properties中把 Spring AI 指向本地 Ollama# 文件路径src/main/resources/application.properties spring.ai.openai.base-urlhttp://localhost:11434/v1 spring.ai.openai.api-keylocal spring.ai.openai.chat.options.modelqwen2.5:7b spring.ai.openai.chat.options.temperature0.7这段配置把 Spring AI 的 OpenAI 通道指向了本地 11434 端口。api-key填什么都行因为本地服务不校验。temperature0.7控制生成内容的随机性需要稳定输出时可以调低到 0.2 左右。6.3 编写调用接口下面是一个完整的 Controller演示如何通过ChatClient构建一个简单的问答接口。// 文件路径src/main/java/com/example/aichat/AiChatApplication.java package com.example.aichat; import org.springframework.ai.chat.client.ChatClient; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.context.annotation.Bean; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; SpringBootApplication public class AiChatApplication { public static void main(String[] args) { SpringApplication.run(AiChatApplication.class, args); } Bean ChatClient chatClient(ChatClient.Builder builder) { return builder.build(); } RestController public static class ChatController { private final ChatClient chatClient; public ChatController(ChatClient chatClient) { this.chatClient chatClient; } GetMapping(/ask) public String ask(RequestParam String question) { return chatClient.prompt() .user(question) .call() .content(); } } }这里有两个地方需要解释。第一ChatClient是 Spring AI 提供的流式接口客户端通过构造器注入方便后续统一配置系统提示词和默认参数。第二prompt().user(question).call().content()是它的标准链式调用逻辑很直观构造提示词、发起调用、取出文本结果。6.4 运行验证mvn spring-boot:run启动成功后浏览器或命令行访问curl http://localhost:8080/ask?question%E4%BB%8B%E7%BB%8D%E4%B8%80%E4%B8%8B%E4%BD%A0%E8%87%AA%E5%B7%B1参数question是 URL 编码后的“介绍一下你自己”。如果返回了模型生成的内容说明 Spring AI 到本地 Ollama 的链路已经打通。实际项目中不建议直接在 Controller 里写完整的对话逻辑。更合理的做法是抽象一个AiService层把系统提示词、历史消息管理、工具调用封装在里面Controller 只负责参数转换和响应包装。这也是 Spring AI 官方推荐的分层方式。7. 常见问题与排查思路在实际部署和集成过程中下面几个问题是出现频率最高的。这里以表格形式整理方便你遇到问题时快速定位。问题现象常见原因解决思路模型运行很慢GPU 显存占用为 0显卡驱动或 ROCm 未正确安装模型回退到 CPU 推理用nvidia-smi或rocm-smi检查驱动确认 Ollama 日志中是否识别到 GPU拉取模型时一直卡住或超时模型文件体积大网络不稳定检查网络连通性可先拉取 3B 小模型验证企业环境可配置镜像源Spring Boot 启动报 LLM 相关 Bean 创建失败spring.ai.*配置前缀写错或依赖版本与 Boot 版本不兼容核对官方文档的配置项查看启动日志中的自动装配报告调用本地接口返回 401OpenAI 兼容接口要求携带 Authorization 头本地 Ollama 的 key 可以随便填但请求头不能省略工具调用准确率低或反复调用失败tool schema 描述模糊或模型本身不支持 function calling精简参数描述换用支持工具调用的模型限制最大轮次避免死循环爆显存导致 OOM模型参数量超过显存容量或并发请求过多换小模型或量化版本开启 KV Cache 优化控制并发数必要时加 GPU 内存调度模型输出不稳定同一个问题答案波动大temperature 设置偏高需要稳定答案时把 temperature 调到 0.1~0.3并增加输出格式约束排查这一类问题的通用思路建议按“驱动层 → 服务层 → 应用层”的顺序来。先确认 GPU 状态和驱动版本再看模型的部署服务日志有没有报错最后才去检查应用代码。很多开发者在服务层还没确认正常的情况下就开始排查代码效率很低。8. 最佳实践与工程建议到这里三个实战场景都已经跑通了。但要真正把这些能力用在生产项目中还需要注意几个工程化层面的问题。8.1 模型选型与成本控制同一个业务场景7B 模型和 70B 模型的推理成本可能相差一个数量级。建议按照任务的复杂度分级选模型简单分类、抽取任务用 7B 甚至 3B 模型复杂推理、代码生成再上大模型。同时要考虑量化策略INT8 或 INT4 量化能显著降低显存占用但对输出质量有轻微影响需要做效果回归测试。8.2 本地部署与云端 API 的取舍当项目遇到数据隐私、延迟或成本问题时优先考虑本地部署但本地部署意味着你要自己承担 GPU 运维、模型更新和可用性保障的成本。更务实的做法是“本地 云端 API”混合模式日常低风险请求走本地模型复杂任务或者本地负载过高时回退到云端 API这样既能控制成本又不会牺牲峰值场景的可用性。8.3 Prompt 与工具 Schema 的版本管理这是很多人容易忽略的点。Prompt 的微调会直接影响模型输出质量而工具 Schema 的改动会影响 Agent 的调用准确率。建议把 Prompt 模板和工具定义都纳入版本控制必要时为 Prompt 建立独立的配置中心方便灰度调整和快速回滚。8.4 设置评估回路模型输出是概率性的每次升级模型版本或调整 Prompt 后都要用一套固定的评测集做回归。评测集不需要很大但必须覆盖你的核心业务场景。可以准备 20~50 条代表性输入用“通过/不通过”的方式快速比对避免“感觉变好了”的主观判断。8.5 安全与权限边界AI Agent 接入了工具调用之后安全问题会成倍放大。给 Agent 授权的工具必须遵循最小权限原则例如天气查询、计算器这类只读工具可以放开但涉及写数据库、发消息、删除文件的工具必须增加人工确认环节。同时要注意提示词注入风险——用户输入可能诱导模型执行非预期操作必要时对用户输入做清洗和鉴权。8.6 可观测性与日志记录生产环境里你需要知道每次请求消耗了多少 token、耗时多少、调用了哪些工具、最终是否成功。建议在 Agent 调用层统一埋点输出结构化日志并统计请求量、成功率、平均延迟、Token 成本和工具调用分布。有了这些数据后续做成本优化和模型选型才有依据。9. 总结与学习路线回到开头的问题台积电奖金大幅增长对普通开发者意味着什么我的理解是它意味着 AI 行业的竞争正在从“拼想法”转向“拼工程落地”。芯片产能和算力资源越来越宝贵谁能高效地把模型部署好、把成本降下来、把 Agent 做得稳定谁就能在下一阶段拿到更高的技术溢价。如果你想沿着这个方向系统提升可以按下面的路线推进先跑通一条完整的本地推理链路掌握 GPU 状态查看和模型部署这是基础。再用 Python 或 Spring AI 实现一个带工具调用的 Agent理解模型、工具、上下文之间的关系。接着给 Agent 加上评测集和日志埋点把“能不能跑”变成“跑得好不好”。最后再考虑多 Agent 协作、分布式推理、微调和量化等进阶主题这些都需要前三步的工程基础。坦白说AI 工程化这条路没有捷径新技术出现的速度也远超普通人的学习速度。最有效的方式不是追每一个新框架而是把模型调用协议、推理资源管理、评估与安全这些“不变的东西”吃透。之后再看到新的 Agent 框架、新的模型版本你只需要花半天时间就能迁移过去。如果这篇文章里的某个实战步骤帮你解决了问题或者你对哪一部分还有疑问可以收藏备用也欢迎在评论区留言交流。下一步我更建议你亲手把 Ollama 跑起来用一台带 GPU 的机器体验一次从部署到调用 API 的完整过程这比看十篇文章都管用。