企业官网建设流程全解析

开头先看一段生成结果：愚人众执行官『公鸡』出场，主持皇都评议会，公子与富人激烈争论，最后以「我们的争论，只为延续极光与冻土，只为铸造荣耀与团结」收束。

看到这种多角色场景文本，很多人会问：这是人工写的，还是 AI 生成的？如果再往下追问一层，技术上的问题就变成：如果用本地 LLM 来批量生成类似剧情，需要多大的显卡、什么样的提示词结构、长文本会不会角色串味、有没有现成 API 可以接进自己的工具链？

这篇文章要拆解的，不是游戏剧情本身，而是背后的部署链路。我们会以“愚人众评议会”这种多角色叙事场景为演示素材，完整走一遍：角色扮演叙事生成服务的本地部署、多角色提示词设计、长上下文一致性验证、功能测试、接口 API 调用和批量任务设计。适合以下读者：想用 AI 做同人剧情创作、游戏文案原型搭建、多角色对话模拟，或者单纯想搞清楚本地 LLM 角色扮演服务怎么跑通的人。

核心判断先放在前面：这套能力不需要企业级服务器，一张 8G 显存的消费级显卡就能跑出可用效果；纯 CPU 也能跑，只是速度会明显慢下来；真正的难点不在显存，而在“多角色一致性”和“长文本稳定生成”这两件事上。

1. 核心能力速览

显存这块我没有给固定数字，因为同一个 7B 模型，FP16、INT8、INT4 三种量化方式可以差出一倍显存，上下文长度从 4K 拉到 32K，KV Cache 也会吃掉更多显存。更稳妥的做法是拿到模型后，先按小参数试跑，再逐步放大。

2. 适用场景与使用边界

2.1 适合谁用

• 同人作者：用 AI 生成不同角色之间的对手戏，用来找剧情灵感和对话节奏。
• 游戏策划和文案：快速生成角色语音草稿、剧情大纲、多分支结局。
• 技术开发：想验证本地 LLM 的服务化能力，包括 OpenAI 兼容接口、批量推理和工作流集成。

2.2 能解决什么问题

最直接的场景是“角色太多，作者写不过来”。人工维护三个角色的立场、语气和称呼很容易崩，LLM 配合结构化的角色卡可以在一定程度上缓解这个问题。另一个场景是“需要批量产出剧情变体”，同一段开场，换一个角色立场或换一条结局分支，批量提交后自动生成多版本文本，用于文案筛选。

2.3 不适合什么场景

• 不适合未经授权直接用官方世界观做商用发行。
• 不适合生成包含真实人物肖像、真实地名、真实机构影射的内容。
• 不适合把 AI 输出当成最终成品直接上线，长篇文本需要人工校验。
• 如果追求稳定出版级文笔，当前开源模型在长故事结构上仍会崩，不要只靠单次生成。

2.4 合规边界提醒

这里要特别强调：原神、愚人众等相关角色和世界观属于游戏版权方所有，本文所有演示内容仅用于本地功能测试和同人创作学习，不用于商业用途。生成结果不表达任何现实政治立场，“皇都评议会”等名词仅作为虚构叙事测试素材。涉及人脸、声音、肖像和任何版权素材时，必须确认授权后再使用。AI 生成内容发布前应当做原创性核查和事实核对。

3. 环境准备与前置条件

3.1 硬件建议

最低可用配置和推荐配置差距主要在“能不能跑”和“跑得多快”：

如果是纯 CPU 推理，建议选择 INT4 量化的 7B 级模型。速度不会快，但用来验证接口和批量流程没有太大问题。

3.2 软件依赖

不同框架依赖不同，下面是一份通用检查清单：

# 检查 Python 版本，建议 3.10 及以上 python --version # 检查 CUDA 驱动是否正常 nvidia-smi # 检查 pip 是否可用 pip --version # 检查端口占用，准备给推理服务预留端口 netstat -ano | findstr :8000

如果决定用 vLLM 启动服务，需要安装对应 PyTorch 和 CUDA 版本的依赖；如果决定用 Ollama，则只要安装客户端后拉取模型即可，依赖管理会更省事。

3.3 推理框架选型

第一次建议选 Ollama，少踩依赖坑。后面要做批量任务和高并发服务，再切 vLLM 不迟。

4. 本地部署与启动方式

4.1 方式 A：Ollama 一键启动

Ollama 是目前最快跑通本地模型的方案。安装完成后，直接拉取一个 7B 量级的指令模型，例如 Qwen2.5-7B-Instruct：

# 拉取模型，模型名按实际可用版本替换 ollama pull qwen2.5:7b # 默认 11434 端口启动服务 ollama serve

服务启动后，用下面命令确认模型列表：

curl http://127.0.0.1:11434/v1/models

返回结果里有模型 ID 和名称，就说明服务已经正常拉起。

4.2 方式 B：vLLM 启动 OpenAI 兼容服务

批量任务和接口集成更推荐 vLLM，因为它吞吐更高。安装依赖：

pip install vllm

启动服务时把模型路径或模型名换成实际情况：

python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --host 127.0.0.1 \ --port 8000 \ --max-model-len 16384 \ --gpu-memory-utilization 0.9

关键参数说明：

• --max-model-len：最大上下文长度，设得越大显存占用越高。
• --gpu-memory-utilization：限制显存使用比例，预留系统显存，避免爆显存。
• --host和--port：服务监听地址和端口。只在本机使用就绑定127.0.0.1，需要局域网调用再绑定0.0.0.0。

4.3 方式 C：CPU 用 llama.cpp

没有 N 卡环境时，可以走 llama.cpp：

# 克隆并编译，或者直接下载 release 版本 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build && cd build cmake .. -DCMAKE_BUILD_TYPE=Release cmake --build . --config Release

然后用量化模型启动简易服务：

./llama-server \ -m /path/to/model.gguf \ --host 127.0.0.1 \ --port 8080 \ -c 8192

CPU 推理的常见问题是慢。如果文档很长，建议先把上下文调到 8K 以下，或者分段生成，避免单次推理时间过长。

4.4 启动后自检

不管用哪个框架，启动后都建议做一次最小调用测试：

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5-7b-instruct", "messages": [ {"role": "user", "content": "你好，请用一句话确认服务正常。"} ], "max_tokens": 50 }'

能正常返回 JSON 且包含choices字段，就说明服务链路没问题。如果访问失败，优先检查端口号、模型名和日志输出。

5. 功能测试与效果验证

下面以“愚人众评议会”同一主题做一组功能测试。所有测试输入均为虚构同人创作测试数据。

5.1 测试一：单角色人设测试

测试目的：确认模型能按角色卡稳定输出，不出现角色称呼漂移。

提示词示例：

【角色卡】 角色名：公鸡 所属：愚人众执行官 性格：说话稳重，重视秩序和团结 语言风格：正式、克制、有点长辈语气 【任务】 请以公鸡的身份，发表一段会议开场白，点名本次评议会主题。

预期结果：输出内容称呼保持“公鸡”人设，语气偏正式，段落中有“秩序”“评议会”“讨论”等关键词。如果输出出现刻意卖萌、现代网络梗或角色名错乱，说明提示词约束不足，需要强化角色卡。

5.2 测试二：多角色辩论场景测试

测试目的：验证模型能否在一个上下文里同时守住两个立场冲突的角色。

提示词示例：

【世界观】 虚构至冬国愚人众评议场景，仅作同人创作测试。 【角色】 公鸡：参会主持人，重视秩序，最后做总结。 公子：好战派，认为力量才是解决问题的核心。 富人：务实派，认为利益和成本才是决策依据。 【场景】 公鸡走进评议会大厅，宣布开始讨论北境冲突问题。公子和富人立刻立场对立。 请生成一段三人对话，要求： 1. 公子语气冲动，富人语气冷静。 2. 公鸡不直接站队，负责控制会议节奏。 3. 对话最后以公鸡的总结收尾。

预期结果：对话应当出现“力量”“成本”“秩序”三类关键词，且立场不能混。常见失败情况是：公子说着说着变成了股东嘴脸，富人说出了“我要战斗”，这就是角色串味，需要在提示词里增加“说话方式说明”和“立场禁止项”。

5.3 测试三：长上下文一致性测试

测试目的：检查在长文本里角色是否还能保持一致性。

操作步骤：

1. 先让模型生成一段 2000 字左右的评议会开场。
2. 把这段内容接在后续对话的 history 中。
3. 请求写一段 500 字的第二幕，看模型能否沿用前面埋下的角色关系和争论焦点。

提交格式参考：

messages = [ {"role": "user", "content": "请先写一段评议会开场，约2000字，公鸡主持，公子与富人争论。"}, {"role": "assistant", "content": first_story}, # first_story 是上一次模型输出 {"role": "user", "content": "接着写第二幕，公子和富人的争论升级，公鸡出面制止。"} ]

判断标准：

• 第二幕里角色名保持一致。
• 公子和富人仍然延续上一幕的立场，没有突然反过来。
• 没有反复使用同一套句式。

如果长文本出现“立场反转”或“重复开头”，优先考虑降低上下文长度，或者在提示词中要求“每一轮对话都带上角色名再发言”。

5.4 测试四：剧情续写与多分支结局

测试目的：验证“同一开场，多结局”的批量结构是否可控。

示例输入：

按照以下结构生成结局 A： 公鸡最终做出裁决：停止争论，优先保证后勤补给，要求富人公开预算，公子保留一线作战权。 要求：500字以内，保留三个角色的核心人设。

再换结局 B：

按照以下结构生成结局 B： 公鸡最终做出裁决：授权公子组建先遣队，但富人主导后勤和监督。 要求：500字以内，保留三个角色的核心人设。

对比两组输出，重点看模型是否根据“结局设定”自动调整角色反应。如果两种结局输出差不多，说明提示词里的“最终裁决”条件没有被模型真正利用，需要把裁决内容拆得更细，例如明确“谁获得预算权”“谁获得指挥权”“谁被剥夺发言权”。

5.5 批量生成测试

先把多个提示词放进 JSONL，每行一次请求：

{"prompt": "公鸡开场白，200字，稳重语气", "scene": "opening", "index": 1} {"prompt": "公子与富人第一轮争论，300字，立场对立", "scene": "debate", "index": 2} {"prompt": "公鸡收尾总结，200字，强调团结", "scene": "closing", "index": 3}

再用 Python 脚本循环调用接口。判断成功的标准是：任务全部返回成功，没有超时，输出文件条数与输入一致，并且按index排序后能拼成一个完整场景。

5.6 效果判断标准汇总

6. 接口 API 与批量任务

6.1 OpenAI 兼容接口

Ollama、vLLM 和 Xinference 都提供 OpenAI 兼容格式，统一走/v1/chat/completions：

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5-7b-instruct", "messages": [ {"role": "system", "content": "你是一个多角色叙事引擎，严格按输入的角色设定生成内容。"}, {"role": "user", "content": "公鸡主持评议会，公子与富人争论，最后公鸡收尾。"} ], "temperature": 0.8, "max_tokens": 2048 }'

注意：model字段必须和推理服务实际加载的模型名一致。不同框架对model名称的要求不同，如果返回模型不存在，先查服务的模型列表接口。

6.2 Python 调用示例

下面是一个能直接改用的函数：

import requests API_URL = "http://127.0.0.1:8000/v1/chat/completions" MODEL_NAME = "qwen2.5-7b-instruct" def generate_story(user_prompt, system_prompt=None, max_tokens=2048, temperature=0.8): messages = [] if system_prompt: messages.append({"role": "system", "content": system_prompt}) messages.append({"role": "user", "content": user_prompt}) payload = { "model": MODEL_NAME, "messages": messages, "max_tokens": max_tokens, "temperature": temperature } resp = requests.post(API_URL, json=payload, timeout=180) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"] if __name__ == "__main__": scene = ( "公鸡主持皇都评议会，公子说必须开战，富人说必须控制成本。" "请生成三人对话，最后以公鸡强调团结收尾。" ) result = generate_story(scene) print(result)

这个函数适合单次调用，如果任务量大，请加上重试机制和日志。

6.3 批量任务队列设计

比较简单的批量方案是“JSONL 输入 + 循环调用 + 结果落盘”：

batch/ inputs.jsonl outputs/ result_0001.md result_0002.md logs/ run.log

Python 侧逻辑：

import json import time def run_batch(input_file, output_dir): with open(input_file, "r", encoding="utf-8") as f: lines = [json.loads(line) for line in f if line.strip()] for i, item in enumerate(lines, start=1): try: text = generate_story(item["prompt"]) out_path = f"{output_dir}/result_{i:04d}.md" with open(out_path, "w", encoding="utf-8") as out: out.write(text) print(f"[OK] {i}/{len(lines)}") except Exception as exc: print(f"[FAIL] {i}: {exc}") # 失败不中断，整体跑完后再统一重试 time.sleep(0.5)

目的就是不让单条失败影响整个批次。

6.4 失败重试建议

• 超时：把timeout从 180 秒放大到 300 秒，同时检查服务日志是否有推理错误。
• 返回空内容：大概率是max_tokens太小，或者模型触发了停止符。
• 返回 400：优先检查messages格式，特别是role字段是否合法。
• 服务卡死：确认显存是否被打满，观察nvidia-smi的显存占用。
• 批量中断：保存已成功的序号，断点续跑，不重复请求已完成的任务。

7. 资源占用与性能观察

7.1 怎么观察显存

GPU 推理时，用nvidia-smi查看实时显存：

nvidia-smi -l 2

如果是 Ollama，还可以用ollama ps看当前加载模型占用的显存：

ollama ps

这里不写死具体数字，因为同一个模型在不同量化级别、不同上下文长度下的显存差异很大。你只需要关心三件事：加载模型后显存占用多少、生成过程峰值多少、上下文加长后增长多少。

7.2 显存的主要消耗来源

所以“7B 模型要多少显存”没有标准答案。更合理的做法是：先设短上下文跑通，再把上下文逐步翻倍，观察显存变化，找到本机安全上限。

7.3 降低显存的常用手段

• 使用 INT4/INT8 量化模型。
• 减小max-model-len，比如从 32K 降到 16K 或 8K。
• 调低gpu-memory-utilization，给系统留余量。
• 批量任务时用batch_size=1跑通流程，再逐步加大。
• 不使用 GPU 时，加载 CPU 量化版本。

7.4 CPU 与 GPU 的差异

CPU 推理的优势是兼容性和低门槛，劣势是速度。同一个模型，GPU 几秒能出的句子，CPU 可能要几十秒。做批量任务时，CPU 会把单批时间拉到不可接受的级别，所以批量优先用 GPU；只做接口调试和格式验证时，CPU 足够。

8. 常见问题与排查方法

9. 最佳实践与使用建议

第一，角色卡要结构化。不要只写“公鸡很稳重”，要写成“公鸡语气沉稳，习惯先说结论，再点名让其他人发言，经常强调秩序和团结”，这样模型更容易形成稳定输出。

第二，上下文控制优先于模型升级。先在一个固定上下文长度下做好提示词模板，不要一上来就开 32K。角色扮演叙事最怕的不是长度不够，而是长度拉满后立场混乱。

第三，批量任务要做成可重入的。输入文件保留序号，输出文件按序号命名，失败后只重跑失败项。这个习惯能省下大量重复操作时间。

第四，接口服务要控制访问范围。只在本机调试就绑定127.0.0.1，需要局域网访问再开0.0.0.0，并且加上基本鉴权或防火墙规则，避免推理服务被外部随意调用。

第五，素材和输出分目录管理。模型文件、输入提示词、输出文本、日志分开存放，既有利益复现，也方便排查问题。下面是一套轻量目录结构：

project/ models/ prompts/ inputs/ outputs/ logs/

第六，涉及版权和隐私时必须前置确认。像本文使用的“愚人众”相关世界观属于版权方所有，仅用于个人学习和功能测试。任何商业化场景、真实人物声音和人脸相关生成，都必须有明确授权，并且在发布前做内容复核。

第七，AI 生成的剧情不要直接发布到正式渠道。同人共创没有问题，但如果面向公众发布，需要标明 AI 生成，人工审校角色和剧情逻辑，避免出现版权风险和内容误导。

10. 总结与下一步

最值得先验证的是“三个角色在同一段对话里立场不崩”。先用单角色人设测试，再逐步扩展成多角色辩论，最后才是长文本续写。最容易踩的坑有两个：一是上下文拉太长导致显存暴涨，二是提示词太简单导致角色串味。

如果手里只有一张 8G 显存显卡，优先用 7B 量化模型，上下文从 8K 开始试；如果要做批量生成，先用 JSONL 把提示词固化下来，再跑脚本循环调用；如果只是想快速体验，Ollama 加一条curl命令就能完成验证。

跑通最小链路之后，可以继续往三个方向扩展：一个是在多角色提示词里加入“场景规则”和“禁止事项”，提高输出稳定性；另一个是把批量脚本升级成带队列和重试的任务系统，接入自己的文案生产流程；第三个是尝试不同量级模型，对比同一个角色卡在不同模型上的表现，找到最适合你创作场景的组合。

这套方案的核心价值不是“生成一段文案”，而是把角色扮演这种偏主观的创作过程，变成了可重复调用的本地服务。能稳定跑出评议会开头，就能稳定跑出你需要的其他多角色场景。建议收藏备用，真正搭服务时直接拿这份清单对照。