On November 9, 2026, Preferred Networks (PFN) released the weights of PLaMo 3.0 Fin, a small language model specialized for the financial domain. The model has 8 billion parameters (8B), and PFN says it can run from a single GPU, even in closed-network cloud or on-premises environments. Users can deploy the weights in their own environments, or try the model through beta versions of an API and a chat service.
When considering adoption for financial work, it is important to distinguish between two kinds of evaluation: financial knowledge, and the ability to use external tools. Financial knowledge tests measure whether a model can choose the correct answer from a set of options. Tool-use evaluations, by contrast, ask whether the model can select the necessary external functions and use the information it retrieves to answer appropriately. In tool calling, the model generates a function name and arguments, but the application actually executes the processing. Practical usefulness in real work therefore depends not only on the model's performance but also on how it is connected to external functions.
An 8B model with released weights and three stages of finance-focused training
What has been released is "pfnet/plamo-3-8b-fin-instruct," distributed on Hugging Face. PFN envisions it as the core of AI agents that automate parts of financial work. In addition to outputting its reasoning process in Japanese, the model supports tool calling for functions such as web search, calculation, and database lookup. With the weights public, users can deploy the model in an environment they manage themselves. However, the statement that it can run from a single GPU does not guarantee operating costs, response speed, or concurrent-processing performance. In addition, using search or database lookup requires separately preparing the connected systems and a mechanism for executing the tools.
The foundation is "PLaMo 3 NICT 8B Base." PFN first carried out continued pretraining on financial documents, mainly in Japanese, to reinforce specialized knowledge. In the subsequent supervised fine-tuning (SFT), the model was trained on instruction-following responses, Japanese reasoning processes, and tool calling. Finally, PFN applied DPO (Direct Preference Optimization), which tunes the model by comparing good and bad answers. Specifically, answers generated by the post-SFT model were evaluated by Gemma 4 31B, and pairs of good and bad answers were created, aiming to curb problems such as unnecessary tool calls, incorrect arguments, fabricated facts, and repeated processing. For training, PFN used its in-house AI processor MN-Core 2 for SFT, and NVIDIA H100 for continued pretraining and DPO.
Financial knowledge improved, but tool-use evaluation shows a different pattern
In its development blog, PFN compares performance at each training stage using five financial-knowledge tasks. The sentiment analysis task on securities reports, "chabsa," uses F1 score, the other four tasks use accuracy, and the average was calculated. This evaluation does not generate text; it selects answers based on the likelihood of each option, and it does not use reasoning-process generation either.
| Training stage in PFN's financial knowledge evaluation | 5-task average |
|---|---|
| Base model | 48.0 |
| After continued pretraining | 50.1 |
| After SFT | 56.0 |
| After DPO | 55.8 |
In the results PFN published on November 9, 2026, the score rose 2.1 points from 48.0 for the base model to 50.1 after continued pretraining, then rose a further 5.9 points to 56.0 after SFT. After DPO, the score was 55.8, a drop of 0.2 points from after SFT. The published values are given to one decimal place, and the differences are 50.1 − 48.0 = 2.1, 56.0 − 50.1 = 5.9, and 55.8 − 56.0 = −0.2.
However, this result is a comparison using a default prompt common to all models in PFN's own evaluation environment, so the conditions differ from official leaderboards that pick the prompt giving each model a higher score. It also shows changes as each training step was applied in sequence; it does not prove that each individual training method always yields the same improvement. Nor can the 5.9-point rise after SFT be interpreted as the improvement in tool-execution accuracy. Because DPO is also intended to reduce inappropriate responses and failed tool calls, the 0.2-point decline in the financial knowledge evaluation alone does not mean it had no effect.
In the same financial knowledge evaluation, Qwen3.5-9B scored 60.1 and Ministral 3 14B scored 62.8, so PLaMo 3.0 Fin's 55.8 did not exceed all of the compared models. Moreover, this test uses a format of choosing answers from options; it does not directly evaluate the accuracy of explanations in natural language, or the ability to handle the laws and regulations required in real financial work. It is a useful reference for gauging how well financial knowledge has been acquired, but judging answer quality across entire business workflows requires separate validation.
The tool-use evaluation, on the other hand, showed a different pattern. According to PFN, answers were generated five times each for 108 scenarios across nine categories, and a total of 540 samples were evaluated. For each sample, Gemma 4 31B scored the answer from 0 to 100 three times, and the median was used. In this evaluation, PLaMo 3.0 Fin averaged 71.3 points, below Gemma 4 E4B's 76.2 points. But in the share of cases that reached a tool returning the information needed for the answer, PLaMo scored 78.9% versus Gemma's 67.1%, reversing the ranking.
In other words, being able to retrieve the necessary information and being able to generate an appropriate final answer using that information need to be evaluated as separate capabilities. However, PFN has not released the foundation or data for this tool-use evaluation. The published figures reveal differences in the characteristics of the two models, but at present third parties cannot rerun the evaluation under the same conditions and verify the results independently.
How to handle roughly 90 tools
The demo PFN released also shows how it handles a large number of external tools. Although about 90 tools are prepared, they are not all presented to the model from the start; the model is given only "search_tools," a tool for searching tools. The model searches for the tools it needs and adds available tools according to the results. This design addresses the problems that arise when there are too many candidates: the model may fail to choose the right tool, or reasoning may drag on.
In fact, according to PFN, in the 540-sample evaluation described above, 5 to 10 samples hit the context-length limit and could not complete an answer. In its development blog, the company explains, "Currently, we recommend use in an environment where only a small number of tools are given to the model." The existence of a demo supporting about 90 tools does not mean the model can use them stably when all are provided at once. In business adoption, it is important to limit the candidate tools according to the processing being targeted.
Regarding the tool-calling mechanism, note too that the model does not directly execute actual operations. The model outputs the name of the function to call and its arguments, and the application carries out the processing according to that content. After the execution result is added to the conversation, the model continues reasoning using that information and generates the final answer. For example, when passing a number to a calculation tool, the meaning of the result changes depending on whether the same value is treated as a percentage or a decimal, so interpretation and validation of arguments must be properly controlled on the application side.
The model card on Hugging Face asks that, before executing any tool, all call contents be validated against a predefined schema. It also asks that operations affecting real transactions, such as orders or remittances, be confirmed by a human before execution. It further states that applications using this model should not be used to make investment decisions on behalf of users. Even if the weights are placed in a closed environment, the flow of data when connecting to web search or external databases depends on the system configuration, so running the model in your own environment is not the same as having all data processing complete within the closed network.
PFN has also released a demo of inquiry classification as an example of processing that does not use tools. In this demo, five inquiries are classified into three urgency levels and specified categories, and the results are output in JSON format. One possible approach is to begin with limited-scope processing such as this kind of classification or information extraction from documents, and combine external information retrieval and human confirmation as needed. However, the demo's behavior does not guarantee a track record in real operating environments or any particular level of accuracy.
License terms to check before deploying in a closed environment
The released model weights cannot be used commercially by anyone without conditions. Under the official Japanese license, use within an organization also counts as commercial purpose. Commercial use requires prior registration, and a condition is that the revenue or sales of the user or its affiliates in the most recent fiscal year not exceed 1 billion yen. Those exceeding this threshold must obtain a separate commercial license. Even if the ability to operate in your own environment is appealing, the terms of use must be checked before adoption.
PFN also offers beta versions of an API and chat under the name "plamo-3.0-fin-beta." A free plan with usage limits is available, but the content may change or service may end without notice, and there is no service-level agreement (SLA) covering matters such as uptime. Obtaining the weights from Hugging Face and running them in your own environment differs from using the API or chat provided by PFN not only in terms of use but also in how data is managed and where operational responsibility lies, so the choice should be considered according to the use case.
To judge the value of adopting PLaMo 3.0 Fin, it is important to assess not only the operational feature of running on a single GPU but also how stably it can be used in actual work. A sensible approach is to first limit the target tasks and verify the accuracy of final answers and how cases where the model cannot answer are handled. If operations requiring human confirmation and the data paths used when connecting to external systems are then made clear, the processes that can be entrusted to the model can be specifically separated from those that should be controlled on the application side. For practical use in finance, the next focus will be the results of validation on such limited tasks and confirmation of operating conditions in real environments.