企业官网建设流程全解析

本文以 Phocinae-Largha-150M-v1（斑海豹 Largha）官方 FAQ 的 15 个核心问题为骨架，逐条结合仓库内的模型配置、训练配方、校准实现与基准数据展开：从"一次前向推理即产出结构化决策"的模型机制，到 phocinae-server 的本地部署与硬件分档、延迟特征、选项翻转稳健性、温度与幂变换两级校准、JevBench 披露、中文表现、τ=0.6 置信度升级门带来的 LLM 调用节省，直至许可证与引用复现方式。读完本文，你可以独立完成该模型的权重校验、服务启动与冒烟测试，并理解其每一组公开数字背后的测量协议与适用前提。

FAQ 中引用的所有数字均以 BENCHMARKS.md 为准 —— 该文件是发布数字的唯一事实来源（source of truth）。中文读者可参阅 docs/faq.zh.md，完整模型信息见 MODEL_CARD.md。

1. 这个模型到底是什么？

Largha 是一个基于编码器的决策模型（decision model），而不是聊天模型。一次前向推理即可把一段state（状态描述）加上若干带类型的提问转换为带置信度的校准答案，三种题型为：

• noul：是/否判定（布尔输出）；
• choice：多选一（输出 0 基选项索引）；
• score：2–10 分打分（整数输出）。

它没有文本生成、没有采样，在固定 batch shape 下推理结果是确定性的。这意味着它可以作为 Agent 的本地决策层（审批门、工具路由、升级分流、工单分诊），而不是通用语言模型。

从仓库源码结构看，这一"编码器 + 决策头"的设计在配置文件中有完整落点：

• config.json：model_type为modernbert（即 mmBERT-small 底座），hidden_size384、num_hidden_layers22、num_attention_heads6、vocab_size256000、max_position_embeddings8192；layer_types数组显示 22 层中每 3 层出现一次full_attention，其余为sliding_attention（local_attention窗口 128），即滑动窗口与全局注意力混合；RoPEtheta为 160000；classifier_pooling为mean（均值池化）。
• rl_agent_config.json：决策头为 2 层 transformer head（head_layers: 2），决策序列默认长度max_len: 512、head 注意力窗口head_max_len: 192，推理精度amp_dtype: fp16，model_name必须为Phocinae-Largha-150M-v1。
• checkpoint_meta.json：1 个 epoch 训练，平均损失 1.3689859。

训练配方（见 MODEL_CARD.md 的 Training 一节）：底座jhu-clsp/mmBERT-small上游预训练不变，在LocalLLaMA/typed-decisions训练集加翻转增广（选项重排）上微调；损失ce+brier、优化器adafactor、lr_encoder2e-5 /lr_head1e-4、micro batch 8、梯度累积 4、共 300 步更新，约 0.044 GPU 小时。评测行从未进入训练（typed-decisions 的 test split 与 JevBench 均被留出）。

2. 如何在本地运行？

官方运行时是 phocinae-server（pure-torch 前向推理，无需额外运行时依赖），它是一个只监听 127.0.0.1 的本地 FastAPI 服务：

pip install phocinae-server PHOC_MODEL_DIR=/path/to/Phocinae-Largha-150M-v1 python -m phocinae.main # http://127.0.0.1:8155

从源码构建（替代方式）：克隆 Phocinae 组织下的 phocinae-server 仓库后cd phocinae-server && pip install .。

启动后的目录布局必须满足PHOC_MODEL_DIR的期望，即仓库根目录本身的结构：model.safetensors、encoder/、tokenizer/、rl_agent_config.json。服务默认地址为http://127.0.0.1:8155，交互文档在/docs。

按 docs/deployment.md 的说法，常用环境变量如下（FAQ 之外补充，便于实操）：

冒烟测试（取自 docs/deployment.md）：

curl -s http://127.0.0.1:8155/health curl -s http://127.0.0.1:8155/v1/systemone -H 'Content-Type: application/json' \ -d '{"model":"Phocinae-Largha-150M-v1","state":"git status","questions":[{"id":"ok","type":"noul","threshold":0.65}]}'

硬件分档、guard 与 MCP 集成详见 docs/deployment.md；请求契约详见 docs/protocol.md。

3. 服务端兼容 OpenAI 接口吗？

不兼容——这是有意设计。因为该模型不是聊天模型，所以 API 不假装是聊天 API：它只暴露一个决策端点族，且默认仅绑定 127.0.0.1。按 docs/protocol.md，端点清单为：

请求侧关键约束（违反即422）：model必须精确为"Phocinae-Largha-150M-v1"；questions为 1–64 项；id非空且请求内唯一；type只能是noul/choice/score；choice必须有options（非空、≤255）且score禁止携带options；noul的threshold必须在 [0,1]。响应中answers的取值形态为noul→bool、choice→0 基索引、score→2–10 整数，另有温度校准后的answer_confidence、action、option_scores、routing扩展字段。错误码体系为 422（参数类）/ 413（请求体超过 2 MiB）/ 401（配置了PHOC_BEARER_TOKEN但鉴权缺失或错误）。确定性约定：同一请求、同一设备、同一 batch shape 下答案逐位一致；fp16 与 fp32 或不同 batch shape 之间可能有末位差异。

4. 需要什么硬件？

FAQ 给出的三档配置（数字与 docs/deployment.md 一致）：

补充说明（同样来自 docs/deployment.md）：权重为 288.6 MB（fp16 safetensors），推理峰值约 1.6 GB 显存 / 1.8 GB 内存；baseline 档模型加载约 4 秒。21.0 ms 是高端 GPU 的 fp16 p50 数字，CPU 永远达不到它——纯 CPU 用户应按单线程约 1.64 s/case 做预算，或使用 8 线程批处理（8–20 decisions/s）。

5. 速度有多快——CPU 为什么约 1.5 秒？

• GPU fp16 单决策：21.0 ms（RTX 5090）p50，发布值，端到端包含 tokenize + forward + 答案组装；
• CPU 单线程：1.64 s/case p50（1 case = 1 个 state + 5 个决策，单次前向）——端到端（tokenize + forward + 答案组装）在单条 fp32 线程上的测量。这是"诚实的 CPU 数字"，而不是拿 GPU 数字冒充；
• CPU 8 线程批处理：8–20 decisions/s（b=1 → 19.7，b=32 → 8.4）。

从 BENCHMARKS.md 的延迟表看，另有一项独立环境下的参考测量：CPU 预热、20 线程、无 GPU 时约 51 ms/call（约 17 ms/decision），文档明确标注这是"量级参考值，不是榜单值"。批处理越大吞吐越低（b=32 时降至 8.4），2000 行 mega-batch 为 6.8–8.5 decisions/s 且需要较大内存——这说明该模型的 CPU 侧最优用法是小批量、多线程预筛，而非单条硬扛。

6. "flip" 数字是什么意思？

协议：打乱某个决策的选项顺序，如果答案改变则记为一次 "flip"（越低越好）。CPU fp32、空闲机器、双重复测的主表（协议细节见 docs/reproduce.md）：

直白解读：大约每 46 次选项重排才有一次答案改变（1/0.0217 ≈ 46）。横向对比：比 Laya 域内的 3.7% 好 1.5 个百分点（注意这是百分点差距而非数量级差距），明显优于 Jev 的约 9% 与 Laya 域外的 19.4%。GPU fp16 的 0.0200/0.0217 与 1k 行 4-perm 的 0.0181/0.0150/0.0331 是不同协议下的"仅备注"值，不与主表混用。工程含义：选项顺序稳健性很好但不完美，重要决策可用POST /v1/systemone/permute（或PHOC_PERM_AVG=1）在 4 种顺序上取平均来进一步压制翻转，代价是 4× 前向开销。

7. 模型是如何校准的？

校准分两层，都在推理期生效、不改变权重：

第一层：温度校准（出厂默认）。出厂列的ECE 为 0.2519（en）/ 0.1941（zh）。三个校准温度0.8660205 / 0.8081192 / 0.6624661存储于模型仓库配置 rl_agent_config.json 的temperature字段，由 phocinae-server 在推理时直接应用——这也是 BENCHMARKS.md 中所有*.json指标所用的"shipped column"。

第二层：可选的幂变换校准列（calib/，opt-in，默认不启用）。仓库随发布附带了 calib/ 目录，机制是逐决策的幂变换：

q ∝ p ** gamma （先逐元素取幂，再按决策归一化）

推荐参数（2026-10-08 拟合，v1.1 权重上复测）：

从源码看，calib/calibrate.py 的apply_gamma(probs, gamma)实现非常简洁：对概率向量逐元素取gamma次幂后归一化；gamma=1时原样返回。由于幂变换是单调的，argmax 结果与 noul 的 0.5 阈值判定都不变，因此所有准确率严格不变——它只重塑置信度分布（γ>1 使概率更尖锐）。代价是 Brier 上升（更自信的列在错误时错得更重），ECE 与 Brier 之间的取舍是显式的。拟合过程使用 25% 留出 case（seed 20261008）+ 向全网格 ECE argmin 的收缩规则，并满足 NLL 护栏（校准后 NLL ≤ raw + 0.01）。

用法示例（calib/README.md）：

from calibrate import apply_gamma q_cal = apply_gamma({"a": 0.61, "b": 0.39}, gamma=4.33)

8. 为什么没有通过 JevBench 验收门？

没有通过——并且公开这一事实：0.5455（126/231），低于 58.4% 的验收门。数字按实测发布，从未在评测行上训练过，也不据此做任何榜单声明。分档细节（BENCHMARKS.md §4）：tier easy 0.9167（44/48）、tier original 0.5000（36/72）、tier hard 0.4144（46/111）——困难题是主要失分点；工具选择子集tool_selection（k≤10）为12/12。这一披露的意义在于给出能力边界：对困难、开放式的判断任务，该模型不是合格答案，而应配合升级机制使用（见第 10、11 节）。

9. 中文真的可用吗？

英文测试集上测得0.906；机器翻译的 typed-decisions 中文 case 上测得0.848。同一 typed 协议下的参照点：Laya 0.766（自测、原生接口）· JEV 0.727 · meraGPT 0.768（en 测试）。

必须诚实说明的 caveat：zh 评测行是英文测试用例的机器翻译，而训练混合中本身就包含机器翻译中文（约 2,400 行）加原生中文（约 1,400 行）。因此 zh 数字应视为域内（in-mix，已拟合）评测，而不是零样本跨语言迁移——中文能力是"训练里见过"的结果，不能外推为任意中文任务的零样本表现。

10. 能把它当安全/安全门用吗？

不能作为唯一的门。Largha 是"第一道决策辅助"：应配合升级机制使用（E1 τ=0.6 门会把它不确定的 45.0% 分流到外部 LLM 或人），再叠加一层确定性的 L0 规则层（如 phocinae-guard）——永远不要让它独自承担破坏性或安全关键动作的控制。

从 docs/deployment.md 的 guard 设计看，这套"门"是分层的：

• L0 层：确定性白/黑名单表（l0_table.json，纯离线）——只读命令放行，危险模式（破坏性 rm、sudo dd/mkfs、curl|sh、git push --force、chmod 777、fork 炸弹等）直接拒绝。即使模型服务宕机也照常工作；
• L1 层：通过/v1/systemone做模型决策（noul "approve?" + score "risk 2–10"；阈值 noul 0.65、ask ≥4、deny ≥7）。默认关闭（PHOCINAE_GUARD_L1_ENABLED=0），因为出厂权重并未针对命令审批任务重新拟合，需在你的域上校准后再启用；
• fail-closed 语义：服务不可达时，一切不在白名单上的请求一律 deny（可配置为 ask，PHOCINAE_GUARD_FAIL_CLOSED=ask）。

退出码约定：0allow ·1deny ·2ask（阻塞、需人在 hook 层确认）；不变式是--confirm只能把ask升级为allow，永远不能推翻deny；审计轨迹为 JSONL 日志（PHOCINAE_GUARD_AUDIT=off可关）。MCP 侧桥接（phocinae-mcp）把 gate/classify/route/score 暴露为工具，同样是服务宕机即 fail-closed。

11. 它到底能省多少钱？

τ=0.6 的升级门（E1 gate）能在本地答完约一半决策：保留子集准确率从0.906 → 0.9936（+0.0876），同时把不确定的 45.0% 升级出去，LLM 调用减少 55.0%（τ=0.5 时可减少 79.6%）。

完整 τ 扫描（出厂权重 + 部署温度列，官方集 2,000 决策；来自 docs/cost-savings.md）：

一个按出厂测试行重算的成本示例（docs/cost-savings.md Worked example）：每月 10,000 个路由决策、τ=0.6 时 45.0% 需升级 = 每月 4,500 次 LLM 调用；升级提示平均 204 tokens（state+question+options，用出厂 tokenizer 实测）加约 50 输出 tokens；按 Claude Sonnet 5 公开标价（$2/M 输入、$10/M 输出）估算约$4.1/月（≈$50/年），对照全部走 LLM 的基线约 $9.1/月（≈$109/年），即移除约 55% 的 LLM 开销，与调用量降幅一致。注意这些是基于公开标价的估算，取决于你的工作负载构成、实际 LLM 定价与"真正例行"决策的占比；token 计数存在 ±30% 左右的 tokenizer 依赖误差；换新域之前应重新扫描 τ，不要默认 55.0% 与 +0.0876 仍然成立。

12. 主要局限是什么？

• 不用于聊天/生成、长文档推理、世界知识问答（MMLU 式探测低于正常水平）；
• zh 是机器翻译 case 上的评测（域内拟合，见第 9 节）；长输入退化明显（16k/32k 探测：0.453 / 0.387）——底座支持 8192 位置，但决策头以 512 token 为默认训练/推理长度（rl_agent_config.json 的max_len）；
• JevBench 验收门未通过（见第 8 节）；顺序稳健性好但不完美（见第 6 节）；
• 未做人口统计/公平性评测；训练数据是英文业务运营文本（typed-decisions），其域与语言偏差会原样带出；
• 另有模型卡披露的已知弱点：一小撮否定式表述（如 "do NOT cancel subscription"）可能被误读为肯定意图（内部探测 1/6 偏弱），安全关键审批应配合 L0 规则层/fail-closed 语义；
• 确定性限定：同设备、同 batch shape 下逐位一致，fp16/fp32 或不同 batching 可能有微小差异。

完整列表见 MODEL_CARD.md。

13. 从哪里下载（镜像与中文社区资源）？

• Hugging Face：Phocinae/Phocinae-Largha-150M-v1官方模型仓库（本仓库即其镜像布局）；
• GitHub：Phocinae/Phocinae-Largha-150M-v1代码仓库；
• ModelScope（魔搭）：PerryLink/Phocinae-Largha-150M-v1；
• 运行时组件位于 GitHub 组织Phocinae下：phocinae-server · phocinae-guard · phocinae-mcp。

中文资源：FAQ 中文版 docs/faq.zh.md · 场景演示画廊中文版 docs/gallery/README_cn.md。

14. 适用什么许可证？

• 权重：Apache-2.0（见 LICENSE）；
• 底座编码器jhu-clsp/mmBERT-small：MIT（见 NOTICE，NOTICE 同时列明训练数据LocalLLaMA/typed-decisions为 Apache-2.0）；
• server/guard 代码：Apache-2.0。

15. 如何引用与复现？

@misc{phocinae-largha-150m-v1, title = {Phocinae-Largha-150M-v1: a 150M-class decision model}, author = {Phocinae}, year = {2026}, note = {https://huggingface.co/Phocinae/Phocinae-Largha-150M-v1} }

复现步骤：先校验权重完整性——sha256sum model.safetensors应得到b6472511eea30729985374f43968cf7f4b16bbe0827de6c6ca07cf92afbb778a（该哈希同样收录在仓库根的 SHA256SUMS 中，可整体核对）；然后按 docs/reproduce.md 中声明的协议、发布数值与证据路径逐项验证（typed-decisions 400 case × 5 决策 = 2000 决策、flip 双重复测、JevBench public-231、E1 τ 扫描、校准列）。评测 harness 已随主仓库发布。

要点回顾：Largha 的价值主张可以浓缩为三点——① 144.3M 参数、288.6 MB 权重的编码器决策模型，一次前向、零输出 token、确定性可审计；② GPU 21.0 ms（RTX 5090）/ CPU 单线程 1.64 s per case 的本地延迟特征，使"本地预筛 + 升级"在成本上成立（τ=0.6 门：保留集 0.9936、LLM 调用 −55.0%）；③ 诚实的边界披露：JevBench 未过门、zh 为域内评测、选项翻转约 1/46、长输入退化、且它只是第一道门而非安全预言机。所有数字以 BENCHMARKS.md 为准，协议与证据路径以 docs/reproduce.md 为准。