1. 为什么要把大模型“请”回家：聊聊私有化部署的那些事儿

上次咱们聊了怎么用LangChain4j去调OpenAI的在线API，玩起来是挺爽的，但很多朋友心里可能犯嘀咕：这数据嗖嗖地往别人服务器上跑，总感觉不太踏实。尤其是公司里做项目，涉及到客户隐私、内部文档或者核心业务逻辑，把数据送出去处理，法务和老板那关可能都过不了。我自己在给一些金融和医疗客户做方案时，就深有体会，数据安全是头等大事，一点都马虎不得。

所以，今天咱们就来聊聊另一个更“硬核”的玩法：把大模型“请”到自家服务器上，关起门来自己用。这也就是所谓的私有化部署。你可能听过Ollama这个工具，它就像是一个专门管理开源大模型的“管家”，能让你在本地电脑或者公司服务器上，轻松跑起来像Llama 2、DeepSeek、Qwen这些明星模型。而LangChain4j呢，就是那个“万能遥控器”，不管模型是在云端还是在你桌底下，它都能用同一套Java API去调用，切换起来几乎不用改代码。

私有化部署的好处，我掰着手指头给你数数，远不止数据安全这一条。第一，成本算得清。在线API是按次或者按Token收费的，用户量一上来，账单看着就肉疼。本地部署相当于一次性投资，买好显卡服务器，电费和维护成本相对固定，长远看更划算，尤其适合需要频繁调用的内部应用。第二，速度快得飞起。没有了网络往返的延迟，模型推理就在本地完成，响应速度从几百毫秒降到几十毫秒甚至更低。我做过一个内部知识问答系统，换成本地模型后，用户体验的提升是立竿见影的。第三，完全自己说了算。你可以自由选择模型版本，甚至用自己的数据去微调它，让它更懂你的业务行话。在线API的模型更新、功能增减，你只能被动接受，而本地模型，你就是它的“主人”。

当然，天下没有免费的午餐。私有化部署意味着你要自己搞定硬件、运维和优化。但这正是我们开发者展现价值的舞台，不是吗？接下来，我就手把手带你，从零开始，在Windows电脑上把Ollama和DeepSeek模型跑起来，再用Spring Boot和LangChain4j把它集成到你的Java应用里。整个过程，我会把踩过的坑和总结的技巧都告诉你。

2. 第一步：给你的电脑装上模型“管家”——Ollama

2.1 下载与安装：比装个游戏还简单

Ollama的安装过程，简单到超乎你想象。它把复杂的模型下载、环境配置、服务启动全都打包好了，对新手极其友好。

首先，打开你的浏览器，访问Ollama的官网。找到下载页面，选择Windows版本。这里有个小提示，官方建议Windows 10及以上系统，我个人是在Windows 11上测试的，非常稳定。下载下来的是一个.exe安装文件，直接双击运行。

安装过程就是一路“下一步”，它会自动完成所有设置，包括在系统后台注册一个服务。安装完成后，你甚至不需要手动去启动什么。可以打开命令行（CMD或者PowerShell），输入一个简单的命令来验证：

ollama --version

如果显示了版本号，恭喜你，Ollama这个“管家”已经悄无声息地在你的系统里安家了。它默认会在本地的11434端口启动一个服务，等着你发号施令。

2.2 拉取你的第一个模型：像下载软件一样简单

“管家”有了，接下来得请“房客”——也就是大模型入住。Ollama支持很多热门的开源模型，比如Meta的Llama 2/3、清华的ChatGLM、阿里的Qwen，还有我们今天要用的深度求索的DeepSeek。

选择模型有点像给电脑配显卡，得量力而行。主要看你的显卡显存。我的开发机是一张NVIDIA RTX 4060，8GB显存。对于8B（80亿）参数左右的模型，8G显存是刚好够用的门槛。如果你用的是CPU或者显存更小，可以考虑更小的3B、1B参数模型，或者使用量化版本（模型名字里带-q4_0这类后缀的，表示4位量化，能大幅减少内存占用）。

我选择deepseek-r1:8b这个模型，它在代码和推理能力上表现不错，而且8B大小对我的显卡很友好。拉取模型只需要一行命令：

ollama run deepseek-r1:8b

第一次运行这个命令，Ollama会自动从镜像仓库下载这个模型。下载速度取决于你的网络，模型大概几个GB大小。喝杯咖啡的功夫，回来应该就差不多了。下载完成后，它会直接进入一个交互式聊天界面，你可以试试跟它打个招呼，比如输入“你好，介绍一下你自己”。看到它流畅地回答，就说明模型部署成功了！

这里有个实战小技巧：如果你不想每次都用交互模式，或者需要它在后台长期运行，可以分开操作。先用 ollama pull deepseek-r1:8b 只下载模型。然后用 ollama serve 启动后台服务，这样模型服务就会一直运行，供你的Java程序调用。

3. 搭建桥梁：在Spring Boot中引入LangChain4j

3.1 项目依赖配置：用Starter省心省力

模型在本地跑起来了，现在我们要让Java程序能跟它对话。这里就是LangChain4j大显身手的时候了。它提供了一个专门的Spring Boot Starter，让我们能用最Spring Boot的方式集成Ollama。

打开你的pom.xml文件，添加以下依赖。我强烈推荐用spring-boot-starter版本，它能省去大量手动配置Bean的麻烦。

<dependency>
    <groupId>dev.langchain4j</groupId>
    <artifactId>langchain4j-ollama-spring-boot-starter</artifactId>
    <version>0.31.0</version> <!-- 请使用当前最新稳定版本 -->
</dependency>

如果你之前已经引入了LangChain4j的核心依赖，这个starter会自动帮你配置好一切。版本号记得去Maven中央仓库查一下最新的，保持更新能获得更好的功能和稳定性。

3.2 配置文件详解：关键参数别配错

依赖加好了，接下来在application.yml（或application.properties）里配置连接信息。这里是与在线API配置并列的，你可以轻松切换。

langchain4j:
  ollama:
    chat-model:
      base-url: http://localhost:11434 # Ollama服务地址，如果在其他机器，改成对应IP
      model-name: deepseek-r1:8b       # 你刚才拉取的模型名称，必须完全一致
      timeout: 120s                    # 超时时间，处理长文本时建议调大
      temperature: 0.7                 # 创造性，0-1之间，值越高回答越随机
      max-tokens: 2048                 # 单次回复最大token数，控制回答长度
      log-requests: true               # 强烈建议开启，调试神器
      log-responses: true              # 同上，能看到完整的请求和响应

重点解析几个关键配置：

• base-url：这是最容易出错的地方。如果你的Spring Boot应用和Ollama运行在同一台电脑，用localhost或127.0.0.1没问题。但如果你的应用是跑在Docker容器里，或者Ollama装在另一台服务器上，这里就需要填写那台服务器的真实IP地址。
• model-name：必须和你用ollama run或ollama pull命令使用的名字一字不差。你可以通过ollama list命令查看本地已安装的模型列表来确认。
• timeout：模型推理是需要时间的，特别是你的问题很复杂或者模型正在思考长文本时。默认可能有点短，我建议设成60秒以上，避免不必要的超时错误。
• log-requests：开发阶段一定要打开！它会在控制台打印出你发送给模型的完整提示（Prompt）和模型返回的原始结果。很多问题，比如回答不对、格式错误，通过看日志一下子就找到原因了。

配置完成后，启动你的Spring Boot应用。如果控制台没有报连接错误，通常就意味着配置成功了。LangChain4j会自动帮你创建一个OllamaChatModel的Bean，接下来直接注入使用就行。

4. 编写业务代码：像调用普通Service一样调用AI

4.1 注入与调用：简洁到不可思议

配置妥当后，在代码里使用就变得异常简单。LangChain4j的API设计得非常统一，不管你背后是Ollama、OpenAI还是Azure，调用方式几乎一样。

首先，在你需要用的Service或Controller里，直接注入ChatLanguageModel。我更喜欢用构造器注入，更清晰。

import dev.langchain4j.model.chat.ChatLanguageModel;
import org.springframework.stereotype.Service;

@Service
public class AIChatService {

    private final ChatLanguageModel chatModel; // 统一接口

    public AIChatService(ChatLanguageModel chatModel) {
        this.chatModel = chatModel;
    }

    public String chatWithModel(String userMessage) {
        // 核心调用就这一行！
        String response = chatModel.chat(userMessage);
        return response;
    }
}

看到了吗？核心代码就一行：chatModel.chat(userMessage)。这就是LangChain4j的魅力，它把不同模型的复杂差异都屏蔽了。你现在用的就是本地的DeepSeek模型，但代码和上次调用OpenAI时一模一样。如果你想切换回云端模型，只需要在配置文件里注释掉Ollama的配置，打开OpenAI的配置，代码一行都不用改。

4.2 构建一个RESTful接口：快速提供AI能力

通常我们会把AI能力封装成HTTP接口。下面是一个完整的Spring MVC Controller示例，我加了一些企业级应用常用的东西，比如Swagger文档、统一响应体和简单的异常处理。

import dev.langchain4j.model.chat.ChatLanguageModel;
import io.swagger.v3.oas.annotations.Operation;
import io.swagger.v3.oas.annotations.tags.Tag;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api/ai")
@Tag(name = "AI对话接口", description = "基于本地Ollama模型的对话能力")
@RequiredArgsConstructor
public class AIChatController {

    private final ChatLanguageModel chatModel;

    @Operation(summary = "与AI模型对话", description = "发送一段文本，获取模型的回复")
    @PostMapping("/chat")
    public ApiResponse<String> chat(@RequestBody ChatRequest request) {
        // 简单的参数校验
        if (request.getMessage() == null || request.getMessage().trim().isEmpty()) {
            return ApiResponse.error("消息内容不能为空");
        }

        try {
            // 调用模型，可以在这里添加业务逻辑，比如记录日志、处理敏感词等
            String aiResponse = chatModel.chat(request.getMessage());
            return ApiResponse.success(aiResponse);
        } catch (Exception e) {
            // 记录异常日志，这里可以更精细地处理超时、模型不可用等不同异常
            // log.error("调用AI模型失败", e);
            return ApiResponse.error("AI服务暂时不可用: " + e.getMessage());
        }
    }

    // 简单的请求体
    @Data
    public static class ChatRequest {
        @NotBlank
        private String message;
    }
}

这个接口提供了一个/api/ai/chat的POST端点。前端或者别的服务只需要发一段JSON过来，比如{"message": "用Java写一个快速排序算法"}，就能立刻得到本地大模型生成的代码。我实测下来非常稳定，响应速度基本在1-3秒内，完全能满足内部工具、知识库问答等场景的需求。

4.3 进阶玩法：使用Message封装对话历史

上面的简单调用适用于单轮问答。但真正的对话是有来有回的，模型需要记住上下文。LangChain4j提供了ChatMemory和UserMessage、AiMessage等对象来管理多轮对话。

import dev.langchain4j.memory.ChatMemory;
import dev.langchain4j.memory.chat.MessageWindowChatMemory;
import dev.langchain4j.model.chat.ChatLanguageModel;
import dev.langchain4j.service.AiServices;
import dev.langchain4j.service.UserMessage;

// 1. 定义一个AI服务接口
interface Assistant {
    String chat(String message);
}

// 2. 在Service中创建带记忆的AI代理
@Service
public class AdvancedChatService {

    private final Assistant assistant;

    public AdvancedChatService(ChatLanguageModel chatModel) {
        // 创建一个能记住最近10轮对话的聊天内存
        ChatMemory memory = MessageWindowChatMemory.withMaxMessages(10);
        // 通过AiServices绑定模型和内存，创建代理
        this.assistant = AiServices.builder(Assistant.class)
                .chatLanguageModel(chatModel)
                .chatMemory(memory)
                .build();
    }

    public String multiTurnChat(String sessionId, String userMessage) {
        // 在实际应用中，sessionId用于区分不同用户的对话记忆
        // 这里简化处理，直接调用
        return assistant.chat(userMessage);
    }
}

这样，你的AI就拥有了短期记忆。你可以问它：“我上一句话说了什么？”，它有可能回答上来（取决于模型能力）。这对于构建聊天机器人、持续性的分析任务至关重要。MessageWindowChatMemory的参数可以调整，比如设为20，就是记住最近10组问答（一问一答算2条消息）。

5. 性能调优与实战踩坑指南

5.1 硬件资源监控与优化

本地部署后，性能瓶颈就从网络转移到了你自己的硬件上。你需要关注几个关键指标：

• GPU显存占用：这是最重要的。使用nvidia-smi（N卡）命令可以实时查看。当你的问题很长或者并发请求时，显存可能爆掉，导致Ollama服务崩溃。解决方案：1）使用量化模型（如-q4_0版本）；2）在Ollama启动或模型加载时，通过环境变量限制GPU层数（如OLLAMA_GPU_LAYERS=20）；3）升级硬件。
• 响应时间（TTFB）：第一个Token返回的时间。如果发现首次响应特别慢，可能是模型正在加载到显存。预热是一个好办法，可以在应用启动后，先发送一个简单的提示（如“你好”）让模型加载好。
• Token生成速度：每秒生成的Token数。这取决于你的GPU算力。如果追求速度，可以考虑更小的模型，或者在Ollama配置中调整并行参数。

我自己的经验是，在8GB显存的4060上跑8B模型，处理一段500字的文本进行总结，响应时间大概在2-5秒，完全可接受。但如果要处理数十个PDF文档的RAG检索，就需要更强大的显卡或者考虑CPU+大内存的方案了。

5.2 常见错误与解决方案

坑1：连接拒绝 (Connection refused)

ERROR: Failed to connect to Ollama at http://localhost:11434

• 检查Ollama服务：确保Ollama正在运行。在终端执行 ollama serve 或重启Ollama应用。
• 检查端口和IP：确认Spring Boot配置中的base-url是否正确。如果是Docker环境，注意容器网络，可能需要用host.docker.internal代替localhost。
• 防火墙：检查11434端口是否被防火墙阻止。

坑2：模型未找到 (Model not found)

ERROR: model 'deepseek-r1:8b' not found

• 确认模型名：用 ollama list 查看本地已安装模型的精确名称，大小写和冒号后的版本号都要一致。
• 拉取模型：如果列表里没有，用 ollama pull deepseek-r1:8b 拉取。

坑3：显存不足 (CUDA out of memory)

Ollama logs show: "CUDA out of memory"

• 降低负载：减小请求的文本长度（max-tokens）。
• 使用量化模型：换用 deepseek-r1:8b-q4_0 这类4位量化模型。
• 调整GPU层数：启动Ollama前设置环境变量 OLLAMA_GPU_LAYERS=10（数值调小），让部分计算落在CPU上。

坑4：响应内容奇怪或不符合预期

• 开启日志：确保配置了 log-requests: true 和 log-responses: true，查看发送给模型的完整提示词。很多时候问题出在提示词（Prompt）上，模型只是“照章办事”。
• 调整温度（temperature）：如果回答天马行空，把temperature调低（如0.3）；如果希望更有创意，调高它（如0.9）。
• 尝试System Prompt：在更复杂的集成中，你可以通过LangChain4j设置系统指令，比如“你是一个专业的Java代码助手，只回答技术相关问题”，来更好地约束模型行为。

把这些坑提前告诉你，希望能帮你节省不少排查的时间。本地部署的路上，遇到问题多看看Ollama的服务日志和LangChain4j的请求日志，大部分答案都在里面。

6. 从Demo到生产：架构思考与扩展方向

当你跑通了这个简单的集成Demo，可能会想，这怎么用到真实项目里？这里分享几点我的架构思考。

首先，关于服务化。在微服务架构下，更好的做法不是在每个需要AI能力的服务里都引入LangChain4j和Ollama。而是将Ollama模型服务化，并封装一个统一的AI能力中台服务。具体来说：1）在一台或多台性能足够的服务器上部署Ollama，作为模型推理集群；2）单独构建一个AI-Service，专门负责通过LangChain4j调用模型，并在此服务中实现提示词工程、对话记忆管理、流量控制、熔断降级等企业级功能；3）其他业务服务通过RPC或HTTP调用这个AI-Service。这样解耦了业务逻辑和AI技术细节，也便于模型资源的统一管理和升级。

其次，结合RAG（检索增强生成）。这是本地大模型落地最具价值的场景之一。单纯的大模型并不了解你公司的内部知识。利用LangChain4j强大的RAG模块，你可以先将公司手册、产品文档、代码库等私有数据向量化存储（比如用Chroma、Milvus这类向量数据库）。当用户提问时，先从向量库中检索出最相关的文档片段，再将这些片段作为上下文连同问题一起发给模型。这样生成的回答不仅准确，而且有据可查。我做过一个内部技术支持机器人，接入公司历史工单和知识库后，解决常见问题的准确率提升了70%以上。

最后，多模型路由与降级。生产环境不能把鸡蛋放在一个篮子里。你可以利用LangChain4j的ModelProvider等特性，配置一个模型列表。当主要模型（如本地DeepSeek）响应超时或出错时，自动降级到备用模型（如另一个更小的本地模型，甚至一个限流调用的云端API）。这能极大提高系统的可用性。

本地部署大模型，初期可能会觉得麻烦，但一旦跑顺，那种对数据、成本和性能的完全掌控感，是在线API无法给予的。它尤其适合那些对数据敏感、调用频繁、需要深度定化的内部应用场景。从今天这个简单的Spring Boot集成开始，你已经拿到了打开这扇大门的钥匙。接下来，是把它变成一个简单的工具，还是演化为一个支撑核心业务的智能中台，就看你如何发挥和迭代了。