企业官网建设流程全解析

DeepSeek-V3 推理调用：从跑通到调参

【免费下载链接】DeepSeek-V3项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-V3

任务是让 DeepSeek-V3 只输出 200 个 token 以内的事实性回答，答完立刻停，两次运行的结果要能对上。官方仓库没有封装 HTTP 服务，所有调用都走inference/目录里的推理脚本。我们把整条链路走一遍：命令行怎么跑、一个请求从 prompt 到 token 经历了什么、控制长度和随机性的两个参数在不同任务下怎么配。

🏃 先跑通：交互式模式

依赖见 依赖清单：torch 2.4.1、triton 3.0.0、transformers 4.46.3、safetensors 0.4.5，装好后进inference/目录执行：

python generate.py \ --ckpt-path /path/to/DeepSeek-V3 \ --config configs/config_16B.json \ --interactive \ --max-new-tokens 200 \ --temperature 0.2

启动后会打印一行>>>提示符，直接输入问题即可。/clear清空多轮历史，/exit退出。CLI 对--max-new-tokens和--temperature的默认值就是 200 和 0.2，正好覆盖上面这个长度控制需求。多卡部署用torchrun启动，README.md 里有完整命令。

一个请求的组成：从 prompt 到 token

翻看 推理脚本，并不存在什么请求体 JSON，真正流转的是四步：

1. tokenizer.apply_chat_template(messages, add_generation_prompt=True)——把对话历史（user/assistant 交替的消息列表）按聊天模板编码成 token
2. generate(model, [prompt_tokens], max_new_tokens, eos_id, temperature)——核心生成函数
3. 生成中一旦采到eos_id立即截断，函数只返回 prompt 之后的部分
4. tokenizer.decode(..., skip_special_tokens=True)还原成文字

两个容易踩的点：prompt_tokens是"列表的列表"，批量模式就是文件里每行一个 prompt，逐行编码后整批传入；函数开头有断言，任何一条 prompt 超过max_seq_len（默认 16384）会直接报错。

如果要嵌进自己的代码而不是走 CLI，最小可运行版本是这样：

# 在 inference/ 目录下执行 import json, torch from safetensors.torch import load_model from transformers import AutoTokenizer from model import Transformer, ModelArgs from generate import generate with open("configs/config_16B.json") as f: args = ModelArgs(**json.load(f)) with torch.device("cuda"): model = Transformer(args) load_model(model, "/path/to/ckpt/model0-mp1.safetensors") tokenizer = AutoTokenizer.from_pretrained("/path/to/ckpt") prompt = tokenizer.apply_chat_template( [{"role": "user", "content": "fp8 和 bf16 的区别？一句话说完"}], add_generation_prompt=True) out = generate(model, [prompt], 200, tokenizer.eos_token_id, 0.2) print(tokenizer.decode(out[0], skip_special_tokens=True))

generate的参数顺序是 model、prompt_tokens、max_new_tokens、eos_id、temperature。注意 eos_id 传tokenizer.eos_token_id而不是 -1——传 -1 意味着生成过程永远不会遇到停止信号，只能跑满max_new_tokens才停。

不同任务的参数搭配

真正需要调的旋钮只有两个：max_new_tokens和temperature。仓库的采样实现是 Gumbel 采样（概率除指数随机量取 argmax），随机性完全由 temperature 控制，没有 top_p 这个入口。

• 事实性问答、流水线任务：temperature 用 0.2（CLI 默认）。再往下，temperature 设 0 时代码直接走 argmax 贪心解码，输出完全确定——这不是报错，是设计好的分支，适合需要复现结果的场景。
• 开放式、创作类：temperature 提到 0.7~1.0，同时把max_new_tokens放宽，否则输出还没展开就被长度截断。
• 多轮对话：把上一轮的 user/assistant 消息一直追加进 messages 列表再走 chat template，脚本里的交互式模式就是这么实现的，自己封装时照抄这个结构即可。

配置文件与长上下文

inference/configs/ 下有四份配置：16B、236B、671B 和 v3.1，选哪份取决于你手里的权重版本。以 config_v3.1.json 为例，"dtype": "fp8"表示权重和计算都走 FP8，显存占用约为 bf16 的一半；MoE 部分共 256 个路由专家，每个 token 只激活 8 个（n_activated_experts）。16B 配置里没有 dtype 字段，按 模型结构 里的默认值走 bf16。fp8 权重想按 bf16 加载，可以先用 fp8_cast_bf16.py 转一遍。

16K 上限与 128K 能力

max_seq_len在 模型结构 的 ModelArgs 里默认 16384，这是上面那个断言的依据。而论文层面的压测（下面这张图）表明 128K 上下文内全文检索能力不衰减——所以"输入太长报错"基本是默认配置的问题，不是模型能力的天花板。

128K 上下文 × 全深度位置的检索测试，整块全绿说明各深度都能被准确定位。

模型定位参考

六项基准测试中 DeepSeek-V3 的分数对比，可用来判断选型时它的定位。

⚠️ 踩坑速查

下一步三件事

1. 把上面的交互式命令用 16B 权重跑一遍，确认/exit、/clear行为符合预期
2. 把 Python 片段包成一个函数，max_new_tokens和temperature走参数，接到自己的流水线里
3. 批量任务写一个每行一句 prompt 的 txt，用--input-file跑，注意每批不超过 8 行

【免费下载链接】DeepSeek-V3项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-V3