企业官网建设流程全解析

最近 Hacker News 上有个帖子热度很高：“Ask HN: How is everyone using Local LLMs?”标题很直白，问的是“大家现在到底怎么用本地大模型”。如果你关注过本地 LLM，应该能感受到讨论内容的变化——前两年大家还在问“我的显卡能跑吗”，现在社区里聊的已经变成“我拿它做了个什么工具”“怎么接进现有系统”“批量任务怎么编排”。

这类帖子最有价值的地方，不是某一个答案，而是它把分散的用法聚在了一起。编程辅助、私有文档问答、Agent 工具调用、网页内容抓取、知识库整理、批量文本处理、RAG、MCP——几乎每个方向都有人在实践。这篇文章就把这些用法整理成一套可以直接照着做的本地 LLM 落地指南，覆盖硬件选型、推理引擎部署、RAG 文档问答、Agent 与 MCP 接入、API 调用、批量任务、资源占用和问题排查。

不管你是刚准备接触本地 LLM，还是已经在用但想扩展应用场景，这篇文章都可以直接收藏。

1. 本地 LLM 核心能力速览

先给一张速览表，方便快速判断本地 LLM 适不适合你的场景。

本地 LLM 的核心价值不是“跑一个聊天机器人”，而是把模型嵌入到自己的业务流程里。文章后面的内容会按这个思路展开。

2. 本地 LLM 典型使用方式与场景边界

结合社区讨论，目前本地 LLM 的主要用法可以归纳为七类。

2.1 编程辅助与代码解释

本地代码补全模型可以在不联网的情况下提供代码建议、变量命名、注释生成、代码解释等功能。对于代码不能出内网环境、或者希望控制补全模型反馈内容的团队，这是一个比较常见的切入点。

2.2 私有文档问答

这是目前落地最广的方向之一。把内部技术文档、合同、论文、产品手册导进来，用 RAG 方式做问答。它的好处是数据保存在本地，不需要上传到外部服务，并且回答可以附上引用来源，方便人工复核。

2.3 自动化文本处理

用本地 LLM 做文本分类、情感分析、摘要、翻译、关键词抽取、格式清洗。这类任务对模型指令跟随能力要求不高，小参数模型就能胜任，非常适合批量化处理。比如每天进来的工单先自动分拣，或把一批 PDF 里的表格内容抽取成结构化字段。

2.4 LLM Agent 任务编排

Agent 模式的思路是让 LLM 不只是“回答”，而是“做事”。它先理解用户目标，把任务拆成步骤，然后调用工具——比如搜索、读文件、执行代码、调外部 API——再根据返回结果决定下一步。本地 LLM 在私有化环境里跑 Agent，工具都部署在企业内网，数据链路全程可控。

2.5 个人知识库与笔记管理

社区里有一个提法叫 “LLM wiki”，意思是用本地模型配合笔记工具、知识库软件，做双向链接、卡片整理、语义检索。你不需要背文件放在哪，只要描述你要找的内容，本地模型会通过向量检索把相关笔记捞出来。这个用法和 RAG 原理一致，但更轻量。

2.6 网页内容抓取与再加工

抓取网页内容后，用本地 LLM 做去重、摘要、结构化提取，是很多工程师在做的自动化链路。本质上就是“爬虫 + LLM 后处理”，生成的干净文本再入库或转成 Markdown。要注意目标网站的 robots 协议和版权约定。

2.7 离线环境下的开发与调试

没有外网权限的研发环境里，本地 LLM 可以作为代码助手和数据处理的唯一可选方案。这也是很多企业内部部署本地模型的直接动因。

2.8 使用边界与合规提醒

本地 LLM 不是万能的。它不适合做需要最新实时知识的问答（除非接检索），也不适合对事实准确性要求极高、且没有人工复核环节的生产场景。涉及人脸、声音、个人隐私、版权素材的数据处理，必须确认授权范围；用本地模型处理业务数据时，也要遵守企业内部的数据安全规范。模型许可证和权重来源需要在部署前确认清楚，避免合规风险。

3. 本地 LLM 硬件门槛与模型选型

社区讨论里出现频率很高的问题就是“什么配置能跑”。这里给出一个保守的估算思路，具体数字以你自己机器实测为准。

3.1 显存大小与模型规模

LLM 推理时，模型权重需要加载到内存或显存里。以 7B 参数模型为例，FP16 精度下权重文件大约占 14GB 空间，4bit 量化后大约占 4-5GB。所以：

• 8GB 显存：适合跑 7B 量化模型，上下文长度不能开太大
• 12GB-16GB 显存：可以比较舒服地跑 7B-14B 量化模型，甚至非量化的小模型
• 24GB 显存：可以跑 33B 左右量化模型，或 14B 非量化模型
• 纯 CPU 推理：内存 32GB 以上可以跑 7B 量化模型，速度慢但能用

需要提醒的是，显存占用不仅是模型权重，还有 KV Cache。上下文越长，KV Cache 占用越大。很多人“模型加载成功了，但一跑长文本就爆显存”，就是这个原因。

3.2 量化精度选择

本地 LLM 常说的 GGUF 格式支持多种量化等级，比如 Q4_K_M、Q5_K_M、Q8_0。社区讨论里比较多的结论是：4bit 量化在日常任务里损失不明显，5bit 到 8bit 会更好一些，但占用也更高。FP16/FP32/BF16 同样影响显存和精度——FP32 是 FP16 的两倍大小，BF16 和 FP16 在显存占用上基本一样。本地部署优先考虑 GGUF 量化模型，这是目前工具链支持最成熟的格式。

3.3 具体选型思路

第一台机器做测试，不要一上来追求大模型。先跑通一个 7B 量化的通用模型，验证 API、RAG、Agent 链路，再逐步换更大的模型。这样排错成本最低。

4. 主流推理引擎部署：Ollama、llama.cpp、LM Studio

推理引擎是本地 LLM 的地基。目前社区里最常用的三个工具各有侧重。

4.1 Ollama：最省事的一键部署方案

Ollama 适合大多数用户。它把模型下载、启动、API 服务都封装好了，命令行操作，还提供了 OpenAI 兼容接口。Windows 和 macOS 直接下载安装包，Linux 用官方安装脚本。

# Linux 安装示例，具体命令以 Ollama 官方文档为准 curl -fsSL https://ollama.com/install.sh | sh # 拉取模型 ollama pull qwen2.5:7b # 启动服务 ollama serve # 在另一个终端里直接对话 ollama run qwen2.5:7b

启动后，服务默认监听127.0.0.1:11434。Ollama 的优势是模型管理非常方便：ollama list查看已下载模型，ollama pull更新模型，卸载也很干净。

4.2 llama.cpp：适合需要精细控制的人

llama.cpp 是 GGUF 格式的源头实现，支持 CPU 推理和 GPU 加速，也支持 Apple Silicon 的 Metal 加速。它更适合愿意自己编译、自己调参数的用户。

# 克隆并编译，路径以实际为准 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build cmake --build build --config Release # 使用编译好的命令行工具进行推理，模型路径需要替换 ./build/bin/llama-cli -m models/your-model.gguf -p "你好，请介绍你自己" -n 256

llama.cpp 的启动参数非常细，比如线程数、上下文长度、GPU 层数都可以手动指定。如果 Ollama 不能满足性能调优需求，可以换到 llama.cpp。

4.3 LM Studio：图形界面，对 Mac 友好

LM Studio 在“最佳 Mac LLM 推理引擎”这类话题里经常被推荐。它提供完整的图形化界面，可以浏览模型仓库、下载模型、启动本地 OpenAI 兼容服务，还能直接看到加载模型后的资源占用。想快速验证一个模型的回答质量，LM Studio 是最快的方式之一。

4.4 部署时需要注意的问题

三个工具都可能遇到端口冲突。Ollama 默认 11434，LM Studio 的本地服务默认 1234。如果端口被占，手动指定一个高位端口更稳妥。另外，模型文件很大，拉取前确认磁盘剩余空间。

5. 文档问答与 RAG 实践

RAG（Retrieval-Augmented Generation）是目前本地 LLM 落地价值最明确的方向。它解决的是模型“不知道私有知识”的问题：先把文档切片、向量化、存到向量库，提问时先检索相关片段，再让模型基于检索结果生成回答。

5.1 RAG 完整流程

典型流程是：解析文档 -> 文本切块 -> 生成向量 -> 存入向量库 -> 用户提问 -> 检索相关块 -> 拼接提示词 -> LLM 生成回答。

这个链路里，本地 LLM 负责两步：生成向量（Embedding）和最终回答。两个任务可以共用一个模型服务，也可以分开。

5.2 Ollama 的 Embedding 接口

Ollama 自带 embedding 模型接口，不需要额外部署向量模型服务。

# 拉取一个嵌入模型，模型名需要按实际拉取情况替换 ollama pull nomic-embed-text # 通过 API 获取向量，模型名需要按实际替换 curl http://127.0.0.1:11434/api/embeddings -d '{ "model": "nomic-embed-text", "prompt": "大语言模型本地部署" }'

返回结果是一个浮点数数组，维度取决于嵌入模型。

5.3 一个简单的本地 RAG 示例

下面给一个最小可用的 RAG 示例。这个示例使用requests调用 Ollama 接口，用简单的余弦相似度做检索，不依赖重型框架。代码里需要替换模型名和文件路径。

import requests import numpy as np import os OLLAMA_URL = "http://127.0.0.1:11434" EMBED_MODEL = "nomic-embed-text" # 按实际拉取模型名替换 CHAT_MODEL = "qwen2.5:7b" # 按实际拉取模型名替换 def get_embedding(text): resp = requests.post( f"{OLLAMA_URL}/api/embeddings", json={"model": EMBED_MODEL, "prompt": text}, timeout=60 ) resp.raise_for_status() return resp.json()["embedding"] def cosine_similarity(a, b): a = np.array(a) b = np.array(b) return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))) def load_chunks(doc_dir): chunks = [] for fname in os.listdir(doc_dir): if fname.endswith(".txt"): with open(os.path.join(doc_dir, fname), "r", encoding="utf-8") as f: text = f.read() # 简单切块：按 500 字切，实际项目里要处理段落边界 for i in range(0, len(text), 500): chunks.append(text[i:i+500]) return chunks # 初始化：构建向量索引 doc_dir = "./docs" chunks = load_chunks(doc_dir) chunk_vectors = [get_embedding(c) for c in chunks] print(f"共加载 {len(chunks)} 个文本块") # 检索 query = "这个项目需要什么硬件？" query_vec = get_embedding(query) scores = [cosine_similarity(query_vec, v) for v in chunk_vectors] top_idx = sorted(range(len(scores)), key=lambda i: scores[i], reverse=True)[:3] context = "\n".join([chunks[i] for i in top_idx]) # 生成回答 prompt = f"""请根据下面提供的资料回答问题。 资料： {context} 问题：{query} 回答：""" resp = requests.post( f"{OLLAMA_URL}/api/generate", json={"model": CHAT_MODEL, "prompt": prompt, "stream": False}, timeout=300 ) resp.raise_for_status() print(resp.json()["response"])

这个示例验证完，再换 LlamaIndex、LangChain 或 Spring AI 这类编排框架，思路完全一致：切块 -> 向量化 -> 检索 -> 生成。

5.4 RAG 效果不好时先查哪几项

最常见的问题有三个：切块太碎导致上下文不完整、检索召回的相关文档不够、提示词没有约束模型“只能基于资料回答”。逐个排查，效果通常会有明显改善。

6. LLM Agent 与 MCP 应用

“LLM 应用为什么需要编排框架”是社区里一个很实际的问题。原因是：单次模型调用只能完成一步任务，而业务场景往往需要多步操作。Agent 的典型工作方式是：

1. 接收用户目标
2. 规划需要执行的步骤
3. 调用工具完成当前步骤
4. 观察工具返回结果
5. 决定下一步继续执行还是结束

这个循环里，本地 LLM 扮演“大脑”，外部工具通过标准接口暴露给模型调用。MCP（Model Context Protocol）就是这类接口的标准化协议，它把“工具”变成 client-server 结构，模型侧只需要理解一套协议，就能连接不同的外部能力。

一个典型的 MCP 配置示例：

{ "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "./data"] }, "fetch": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-fetch"] } } }

这种配置的含义是：给 Agent 暴露了两个工具，一个可以读本地文件目录，另一个可以抓取网页内容。模型在对话中判断需要读取文件时，会通过 MCP 调用对应工具。

在 Java 技术栈里，Spring AI 也提供了 MCP、RAG、Agent 的组合支持。社区里“Spring AI + MCP + RAG + Agent”是一条很典型的工程链路：Spring AI 做模型接入抽象，MCP 负责工具标准化，RAG 提供私有知识，Agent 完成多步编排。如果团队已经基于 Spring Boot，这个方向很有落地价值。

要注意的是，Agent 模式会显著增加模型调用次数。每个子任务都可能触发一次甚至多次推理，响应时间和资源开销会成倍增长，批量使用前一定要做成本评估。

7. 本地 LLM 接口 API 与批量任务

本地 LLM 真正进入工程化，靠的是 API 接口。部署好推理引擎后，业务系统通过 HTTP 调用模型能力，不需要关心模型跑在哪台机器上。

7.1 OpenAI 兼容接口

Ollama 启动后，会暴露一个 OpenAI 兼容的接口地址：http://127.0.0.1:11434/v1。这意味着原本调用 OpenAI 接口的代码，把 base_url 改成本地地址、把 key 改成任意占位值，就能切到本地模型。

curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "写一段 Python 快排"}], "stream": false }'

这种方式的好处是迁移成本极低，现有工具链不需要大改。

7.2 原生接口调用

如果不需要兼容 OpenAI，直接调用 Ollama 的原生接口更简洁。

import requests resp = requests.post( "http://127.0.0.1:11434/api/generate", json={ "model": "qwen2.5:7b", "prompt": "用一句话解释什么是 RAG", "stream": False }, timeout=120 ) resp.raise_for_status() print(resp.json()["response"])

需要确认接口路径和参数以当前部署的引擎版本为准，不同引擎有差异。

7.3 批量任务设计

批量处理是本地 LLM 的常见使用场景，比如批量摘要、批量分类、批量信息抽取。批量任务设计的核心不是“循环调用”，而是任务队列和失败重试。

一个推荐的批量处理结构：

import requests import time import json MODEL = "qwen2.5:7b" API_URL = "http://127.0.0.1:11434/api/generate" def process_text(text, max_retries=3): for attempt in range(max_retries): try: resp = requests.post( API_URL, json={ "model": MODEL, "prompt": f"请对以下内容做摘要，控制在 100 字以内：\n{text}", "stream": False, "options": {"temperature": 0.2} }, timeout=120 ) resp.raise_for_status() return resp.json()["response"] except Exception as e: print(f"第 {attempt+1} 次尝试失败: {e}") time.sleep(2 ** attempt) # 退避重试 return None # 待处理文本列表 texts = [ "第一篇文本内容……", "第二篇文本内容……", # 实际项目从文件或数据库中读取 ] results = [] for i, text in enumerate(texts): result = process_text(text) results.append(result) print(f"第 {i+1} 条处理完成") # 避免请求过快，给服务留出余量 time.sleep(0.5) # 保存结果 with open("results.json", "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2)

批量任务要注意三点：一是单条请求设置超时，避免服务卡死拖垮整个队列；二是错误重试要加退避；三是记录每一条的处理状态，即使中断也能断点续跑。并发请求能提升吞吐量，但要看显存是否放得下多个并发任务。

8. 资源占用与性能观察方法

本地 LLM 的性能观察是部署过程中的核心环节。重点看四个指标：显存占用、内存占用、单次请求耗时和吞吐量。

8.1 显存占用观察

Linux 下最直接的方式是nvidia-smi：

watch -n 1 nvidia-smi

Windows 可以用任务管理器的 GPU 性能面板，或者安装 GPU-Z。macOS 的 Apple Silicon 用活动监视器查看内存压力。

观测的时机很重要：模型刚加载完看一次，跑长文本时看一次，批量并发时再看一次。单纯的显存占用不代表全部，还要看是否触发了显存溢出或 swap。

8.2 推理精度与资源占用对比

FP32、FP16、BF16、INT8、INT4 这些精度等级直接影响模型文件大小和推理开销。FP16 相对 FP32 显存减半，BF16 与 FP16 在同尺寸下占用接近，4bit 量化通常能做到 FP16 的 1/4 以下。量化等级越高，占用越低，但生成质量可能下降。对大多数任务来说，4bit 或 5bit 量化的损失可以接受，但具体还要以你自己的测试样本为准。

8.3 CPU 与 GPU 推理差异

GPU 推理速度远快于 CPU，但 CPU 推理的优点是内存便宜，可以跑更大的模型。llama.cpp 在 CPU 上支持多线程加速，能跑但速度不理想。如果只是做离线批量任务，对实时性要求不高，CPU 跑小模型是可行的；如果要接交互式应用，尽量上 GPU。

8.4 降低显存占用方法

优先换低量化模型。其次减小上下文长度——KV Cache 会随上下文线性增长。第三是控制并发数量，不要同时开多个请求。最后考虑 GPU 层数和 CPU 层数混合部署，把部分层放到 CPU 上，缓解显存压力。

9. 本地 LLM 常见问题与排查方法

汇总社区讨论和实际部署里最常遇到的问题。

9.1 ComfyUI 和 LLM 必须在同一台电脑吗

不需要。ComfyUI 负责图像生成，本地 LLM 负责文本理解和任务规划，两者可以部署在不同机器上，通过 HTTP API 或队列服务通信。分开部署反而能避免单机显存不足的问题。联调时只需要确认网络互通和接口地址配置正确。

9.2 依赖安装失败怎么处理

Python 环境优先使用虚拟环境（conda 或 venv），避免系统依赖冲突。安装 PyTorch 时注意选择与 CUDA 版本匹配的安装命令。如果安装速度慢，换国内镜像源。Node 项目同理，用npm镜像加速。

10. 本地 LLM 最佳实践与使用建议

10.1 第一次使用从最小配置开始

刚接触本地 LLM，不要直接挑战最大模型。先用 7B 量化的通用模型跑通完整链路：部署引擎 -> 调用 API -> 做一次 RAG -> 接一个批量任务。链路通了之后再优化模型和参数。

10.2 目录结构从开始就规范化

建议这样组织：

models/ # 模型权重文件 inputs/ # 输入素材，按任务分目录 outputs/ # 输出结果，按日期分目录 logs/ # 运行日志 scripts/ # 启动和任务脚本

10.3 批量任务必须加日志和重试

这是本地 LLM 批量处理最容易踩的坑。单次请求可能因为网络抖动、显存不足、服务过载等原因失败。没有日志和重试机制，批量任务可能会静默丢失数据。写结果时建议先写临时文件，全部处理完再统一重命名。

10.4 接口服务要限制访问范围

本地 LLM 服务默认监听 127.0.0.1，如果需要在局域网内被其他机器访问，要把监听地址改成 0.0.0.0，同时必须做好访问控制，避免接口被未授权调用。

10.5 合规与授权不能省略

本地化部署不等于可以随意使用数据。涉及人脸、声音、版权素材的生成和处理，必须确认授权；用模型处理业务数据，要确认数据脱敏要求；部署的模型权重要检查许可证是否允许商用。发布或商用前，对模型输出做人工复核，尤其是面向用户的场景。

11. 总结与下一步

从社区讨论来看，本地 LLM 已经从“能不能跑”进入“怎么用好”的阶段。最值得尝试的路线是：先用 Ollama 跑通一个 7B 模型，验证 API 调用，再做一个 RAG 文档问答，最后尝试接一个 Agent 或批量任务场景。

最先要验证的功能是接口连通性，这是所有后续应用的基础；最容易踩的坑是显存溢出和端口冲突，排查清单里都有对应方案。后续扩展方向包括：接入 Spring AI 等编排框架、通过 MCP 连接更多外部工具、把 ComfyUI 图像生成和 LLM 文本规划联动起来、在 Mac 上用 LM Studio 做轻量级本地推理。

建议收藏备用，拿到机器后从第 3 章开始对照操作。