NanoJev 0.6B：并行决策模型如何直接输出概率分布替代Token生成

1. 从 Token 生成到概率分布：NanoJev 到底在做什么

第一次看到 NanoJev 这个项目标题的时候，我的反应是：终于有人把这件事拿出来认真做了。大语言模型从 GPT 系列一路卷到现在，几乎所有主流方案都在做同一件事——自回归地一个 Token 一个 Token 往外蹦。你问它“明天天气怎么样”，它先输出“明”，再输出“天”，再输出“天”，再输出“气”……每一步都在做一次 softmax，然后采样或者取 argmax。这个范式统治了整个 LLM 时代，但它有一个根本性的问题：模型内部明明已经算出了一个完整的概率分布，我们却只取了一个 Token 出来，把剩下的信息全扔了。

NanoJev 做的事情，用一句话说就是：让模型直接输出概率分布，而不是生成 Token。它只有 0.6B 参数，走的是并行决策的路子，不是自回归解码。你给它一个输入，它一次性给出一个分布，这个分布可以直接用来做决策、做分类、做排序、做打分，而不需要经过“生成文本再解析”这个中间环节。这个思路其实在学术界不新鲜，但在工程落地层面，能把参数量压到 0.6B 还能保持可用性的开源项目，确实不多见。

我为什么对这个方向感兴趣？因为在实际业务里，大量场景根本不需要模型“说话”。比如内容审核，你只需要模型输出“违规概率 0.87”；比如推荐排序，你只需要模型给出每个候选的分数分布；比如意图识别，你只需要模型告诉你“用户想退款”这个类别的概率最高。这些场景下，让模型自回归生成一段文本来解析，既慢又浪费算力，还容易因为生成的不确定性引入额外错误。NanoJev 这类并行决策模型，瞄准的就是这块需求。

适合谁来参考这篇内容？如果你是在做 LLM 应用落地的工程师，尤其是遇到“分类、打分、排序、决策”这类任务时觉得自回归生成太别扭的，这篇值得细看。如果你是对模型架构感兴趣的研究者，0.6B 这个尺寸也足够你在单卡上跑起来做实验。如果你只是刚入门 LLM，想了解除了“聊天”之外模型还能怎么用，那 NanoJev 是一个很好的切入点，因为它足够小，小到你可以在本地把它跑通，亲眼看到概率分布长什么样。

2. 核心设计思路拆解：为什么是并行决策而不是自回归

2.1 自回归范式的信息损耗问题

要理解 NanoJev 的价值，得先看清楚自回归解码到底损失了什么。假设一个模型在某个位置上输出的 logits 经过 softmax 之后是这样一个分布：类别 A 概率 0.45，类别 B 概率 0.35，类别 C 概率 0.15，其他 0.05。如果你用 argmax，你只拿到了 A，B 和 C 的信息全丢了。如果你用采样，你这次拿到 A，下次可能拿到 B，输出不稳定。如果你用 beam search，你保留了几条路径，但最终还是要选一条出来。

问题在于，很多决策场景下，B 和 C 的概率信息本身就是有价值的。比如在风控场景里，一个用户被判定为“高风险”的概率是 0.45，“中风险”是 0.35，这两个数字放在一起，和“高风险 0.95，中风险 0.02”是完全不同的业务含义。自回归生成把这种分布信息压缩成了一个 Token 序列，下游还得再解析回来，中间既有信息损耗，又有解析成本。

NanoJev 的做法是跳过 Token 生成这一步，直接让模型输出一个固定维度的概率分布向量。这个向量可以直接接下游的决策逻辑，不需要任何文本解析。你可以把它理解成一个“会说话的分类器”，但它说的不是自然语言，而是概率。

2.2 0.6B 参数量的取舍逻辑

为什么是 0.6B？这个数字不是随便定的。我自己的经验是，参数量在 0.5B 到 1B 之间是一个很微妙的区间。低于 0.5B，模型对复杂语义的捕捉能力会明显下降，尤其是需要理解长上下文或者细微语义差别的任务，效果会打折扣。高于 1B，推理成本上去了，部署门槛也上去了，很多边缘场景或者高并发场景就吃不消。

0.6B 刚好卡在一个平衡点上：单张消费级显卡就能跑，量化之后甚至可以在 CPU 上做推理，同时又能承载足够多的语义信息。NanoJev 选择这个尺寸，我猜测背后的考量是：并行决策任务通常不需要模型“知道”太多世界知识，它需要的是对输入做精准的语义压缩和分类。这类任务对参数量的需求，远低于开放式生成任务。你不需要模型会写诗，你只需要它判断这段文本属于哪个类别。

2.3 并行决策的架构选择

从架构层面看，NanoJev 走的是 encoder-only 或者 encoder-decoder 的路子，而不是 decoder-only。这意味着它不需要 causal mask，所有位置可以同时看到全部输入，注意力是双向的。这种架构在分类和决策任务上天然有优势，因为决策往往需要全局信息，而不是从左到右的逐步推理。

具体到实现上，我推测它大概率是基于 Qwen3 0.6B 这个底座做的微调或者结构改造。Qwen3 系列本身就有 0.6B 的版本，社区里做微调的案例也很多，底座成熟、tokenizer 稳定、生态工具齐全，选它作为起点是很合理的工程决策。改造的核心在于把原来的语言模型头换成一个决策头，输出维度从词表大小变成任务需要的类别数或者打分维度。

注意：这里说的“换头”不是简单的替换，而是需要重新设计训练目标和损失函数。如果只是把语言模型头换成分类头而不做针对性训练，效果会非常差，因为底座模型学到的表示和决策任务需要的表示不在一个空间里。

3. 核心细节解析与实操要点

3.1 概率分布输出的具体形式

NanoJev 输出的概率分布，具体长什么样？根据我对这类模型的理解，通常有两种形式。第一种是固定类别数的 softmax 输出，比如 10 个类别就是 10 维向量，每个维度是一个概率值，加起来等于 1。第二种是打分输出，每个候选得到一个实数分数，然后通过 sigmoid 或者 softmax 归一化。前者适合互斥分类任务，后者适合多标签或者排序任务。

在实际使用中，你需要根据任务类型选择对应的输出形式。如果是意图识别这种互斥任务，用 softmax 输出；如果是内容多标签审核，用 sigmoid 输出每个标签的独立概率；如果是推荐排序，用打分输出然后做 pairwise 比较。NanoJev 作为通用决策模型，大概率支持多种输出配置，通过配置文件或者 API 参数来切换。

3.2 输入处理与上下文长度

0.6B 的模型，上下文长度通常不会太长。我实测过类似尺寸的模型，在 2048 到 4096 这个区间比较稳，再长的话注意力计算的开销和效果都会有问题。NanoJev 如果定位是决策模型，输入大概率是短文本或者中等长度文本，比如一条评论、一段对话、一个商品标题。这种场景下，2048 的上下文完全够用。

输入处理上，需要注意 tokenizer 的选择。如果底座是 Qwen3，那 tokenizer 就是 Qwen 系列的那套，对中文的支持很好，这一点对国内开发者很友好。你不需要额外做分词适配，直接拿过来用就行。但要注意，决策任务和生成任务对输入格式的要求不一样。生成任务通常需要 prompt 模板，决策任务可能只需要原始文本，或者加一个简单的任务前缀。

3.3 训练数据的构造要点

这是最容易被忽视但最关键的一环。NanoJev 这类模型的效果，八成取决于训练数据质量，两成取决于模型结构。构造训练数据时，有几个坑我踩过，这里直接说结论。

第一，标签噪声比数据量更重要。0.6B 的模型容量有限，如果标签本身有 10% 的噪声，模型学到的就是噪声。宁可要 1 万条干净数据，不要 10 万条脏数据。第二，类别不平衡要处理。如果某个类别占比超过 80%，模型会倾向于全预测这个类别，概率分布会退化成 one-hot。需要用重采样或者损失加权来平衡。第三，难样本要保留。那些模型容易分错的样本，恰恰是提升决策边界的关键，不要因为“看起来奇怪”就删掉。

3.4 推理部署的资源配置

0.6B 模型部署起来很轻。FP16 精度下，模型权重占大约 1.2GB 显存，加上 KV cache 和中间激活，2GB 显存足够跑起来。如果做 INT8 量化，权重降到 600MB 左右，1GB 显存就能跑。INT4 量化的话，权重只有 300MB，甚至可以在一些边缘设备上跑。

推理速度方面，并行决策模型比自回归生成快得多。自回归生成 N 个 Token 需要 N 次前向传播，而并行决策只需要 1 次。这意味着在同等硬件下，NanoJev 的吞吐量可以是同尺寸生成模型的几十倍。对于高并发场景，这个优势非常明显。

4. 实操过程与核心环节实现

4.1 环境准备与依赖安装

先把环境搭起来。我建议用 Python 3.10 或者 3.11，太新的版本有些库还没适配，太旧的版本性能不好。CUDA 版本根据你的显卡来，12.1 以上比较稳。依赖方面，核心是 PyTorch、Transformers、以及项目自己的代码库。

conda create -n nanojev python=3.11 conda activate nanojev pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers accelerate safetensors

如果项目提供了自己的包，直接 pip 安装或者从源码装。从源码装的好处是你可以直接改代码做实验，坏处是依赖冲突要自己处理。我一般先用 pip 装稳定版跑通，再考虑从源码装。

4.2 模型加载与初始化

加载模型的时候，有几个参数需要特别注意。torch_dtype建议设成float16或者bfloat16，省显存。device_map设成auto让 accelerate 自动分配。如果显存紧张，可以加load_in_8bit=True做量化加载。

from transformers import AutoModelForSequenceClassification, AutoTokenizer model_name = "nanojev-base" # 替换成实际模型路径 tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True) model = AutoModelForSequenceClassification.from_pretrained( model_name, torch_dtype="auto", device_map="auto", trust_remote_code=True ) model.eval()

这里用AutoModelForSequenceClassification是因为决策任务本质上就是序列分类的泛化。如果项目有自己的模型类，替换成对应的类就行。trust_remote_code=True在加载自定义架构的模型时是必须的，但要注意只加载可信来源的模型。

4.3 输入构造与推理调用

推理调用的核心是把输入文本转成模型需要的格式，然后拿到概率分布。下面是一个完整的调用示例。

import torch text = "这个产品的质量太差了，用了两天就坏了" inputs = tokenizer(text, return_tensors="pt", truncation=True, max_length=512) inputs = {k: v.to(model.device) for k, v in inputs.items()} with torch.no_grad(): outputs = model(**inputs) probs = torch.softmax(outputs.logits, dim=-1) print(probs) # tensor([[0.02, 0.05, 0.88, 0.05]]) 假设四个类别

拿到概率分布之后，你可以直接取 argmax 做分类，也可以把整个分布传给下游做更细粒度的决策。比如在客服场景里，如果“投诉”类别的概率超过 0.7，直接转人工；如果在 0.4 到 0.7 之间，先走自动回复再观察。

4.4 批量推理与性能优化

实际业务里不可能一条一条推理，必须做批量。批量推理的关键是 padding 和 attention mask 的处理。用 tokenizer 的padding=True自动补齐，同时确保 attention mask 正确传递，否则 padding 位置会影响注意力计算。

texts = ["文本1", "文本2", "文本3"] inputs = tokenizer(texts, return_tensors="pt", padding=True, truncation=True, max_length=512) inputs = {k: v.to(model.device) for k, v in inputs.items()} with torch.no_grad(): outputs = model(**inputs) probs = torch.softmax(outputs.logits, dim=-1)

批量大小根据显存来调。0.6B 模型在 2GB 显存下，batch size 开到 32 问题不大。如果开了 INT8 量化，batch size 可以翻倍。实测下来，batch size 32 的时候，单卡吞吐能到每秒几百条，具体数字取决于文本长度。

提示：批量推理时，如果文本长度差异很大，建议按长度分桶，减少 padding 浪费。这个技巧在文本分类任务里很常用，能提升 20% 到 30% 的吞吐。

5. 常见问题与排查技巧实录

5.1 概率分布过于集中或分散

这是最常见的问题。模型输出的概率分布要么接近 one-hot，要么接近均匀分布，说明模型没有学到有效的决策边界。原因通常有三个：训练数据标签噪声太大、学习率设置不当、或者训练轮数不够。

排查思路：先看训练集上的分布，如果训练集上也是 one-hot，说明模型过拟合了，需要加正则化或者减参。如果训练集上分布正常但验证集上 one-hot，说明泛化能力差，需要更多数据或者数据增强。如果训练集和验证集都是均匀分布，说明模型根本没学到东西，检查标签是否正确、损失函数是否合理。

5.2 推理速度不达预期

理论上并行决策应该很快，但实际跑起来可能发现没那么快。常见原因包括：没有用批量推理、没有开 FP16、attention 实现没有优化、或者 CPU 和 GPU 之间的数据传输成了瓶颈。

排查步骤：先用torch.cuda.synchronize()确保计时准确，然后逐步排查。如果单条推理慢，看是不是每次都在做 tokenization，把 tokenization 也批量化。如果批量推理慢，看 GPU 利用率，利用率低说明是 IO 瓶颈，利用率高说明是计算瓶颈，考虑量化或者换更高效的 attention 实现。

5.3 类别不平衡导致的预测偏置

如果训练数据里某个类别占绝大多数，模型会倾向于预测这个类别。表现是：少数类别的概率永远很低，即使输入明显属于少数类别。

解决方法：在损失函数里加类别权重，权重和类别频率成反比。或者用 focal loss，让模型更关注难样本。还可以做数据重采样，对少数类别过采样，对多数类别欠采样。我一般先用类别权重，效果不够再上 focal loss。

5.4 模型输出与业务预期不一致

有时候模型输出的概率分布看起来合理，但和业务预期对不上。比如业务上认为某条文本应该判为高风险，但模型给的风险概率只有 0.3。这种情况通常不是模型的问题，而是训练数据和业务定义之间的 gap。

我的经验是：决策模型的效果上限由数据标注标准决定。如果标注标准本身模糊，模型学到的边界也会模糊。解决方法是把业务规则显式地写进标注指南，让标注一致性达到 90% 以上，再训练模型。另外，可以在推理阶段加一个后处理层，用业务规则对模型输出做校准。

5.5 模型更新与版本管理

决策模型上线之后，随着业务变化，模型需要迭代。这时候版本管理就很重要。我建议每次训练都保存完整的配置：底座版本、训练数据版本、超参数、评估指标。推理服务加载模型时，把版本号也带上，方便回滚和对比。

另外，新模型上线前一定要做 A/B 测试，不要直接全量替换。决策模型的输出直接影响业务逻辑，一旦出问题影响面很大。A/B 测试期间，对比新旧模型的决策一致率和业务指标，确认新模型确实更好再切流量。

6. 这类模型还能怎么用：几个延展场景

NanoJev 这种并行决策模型的适用面其实比想象中宽。除了前面说的分类和打分，还有几个场景我觉得很有潜力。

第一个是检索重排。传统做法是用交叉编码器给 query 和 doc 打分，NanoJev 可以直接输出相关性概率分布，而且推理速度快，适合做大规模候选的重排。第二个是对话状态追踪。多轮对话里，每一轮用户意图的概率分布可以直接作为状态转移的输入，比生成文本再解析稳定得多。第三个是内容质量打分。给一篇文章输出多个维度的质量分，比如信息密度、可读性、原创性，每个维度一个概率值，下游根据这些分数做推荐或者审核。

还有一个我觉得很有意思的方向是模型集成。多个 NanoJev 实例输出各自的概率分布，然后做加权平均或者投票，效果通常比单个大模型好，而且推理成本可控。0.6B 的尺寸让集成变得可行，你可以在单卡上跑好几个实例。

注意：延展场景虽好，但每个场景都需要重新构造训练数据和评估标准。不要指望一个通用模型直接套到所有场景上就能用，领域适配这一步省不了。

7. 我踩过的几个坑和实操心得

说几个实际做这类项目时踩过的坑。第一个坑是低估了 tokenizer 的影响。同样的模型，换一个 tokenizer，效果可能差好几个点。尤其是中文场景，有些 tokenizer 对中文的分词粒度不合理，导致模型看到的输入和预期不一致。我的做法是先用小样本对比几个 tokenizer 的效果，选最好的那个再开始训练。

第二个坑是学习率设得太大。0.6B 的模型虽然不大，但微调时学习率还是不能太高。我试过 5e-5，loss 直接炸了。后来降到 1e-5 到 2e-5 之间才稳定。如果是全量微调，学习率还要更低；如果是 LoRA，可以适当高一点。

第三个坑是忽略了推理时的数值稳定性。FP16 推理时，softmax 之前如果 logits 数值范围很大，可能会出现 inf 或者 nan。解决办法是在 softmax 之前做数值截断，或者用 FP32 做 softmax 再转回 FP16。这个细节在训练时不容易发现，上线后才暴露出来。

最后一个心得：决策模型的评估指标要和业务对齐。不要只看 accuracy 或者 F1，要看业务真正关心的指标。比如风控场景，你关心的是在固定误杀率下的召回率；推荐场景，你关心的是排序的 NDCG。评估指标选错了，模型调优的方向就会偏。

这个方向后续还可以这样扩展：把 NanoJev 和 RAG 结合起来，用检索到的文档作为额外输入，让决策模型在更丰富的上下文下做判断。或者把多个决策头拼在一起，一个模型同时输出多个任务的概率分布，共享底层表示，进一步提升效率。0.6B 的尺寸给了很多实验空间，单卡就能跑，试错成本很低，值得多折腾折腾。