It's one DML and SOQL per 200 records or a single DML "chunk."
To illustrate this, consider the following code:
contact[] c = [select id from contact limit 5];
id accountid = [select id from account where ispersonaccount = false limit 1].id;
c.add(new contact(lastname='test1', accountid=accountid));
c.add(new contact(lastname='test2', accountid=accountid));
c.add(new contact(lastname='test3', accountid=accountid));
c.add(new contact(lastname='test4', accountid=accountid));
c.add(new contact(lastname='test5', accountid=accountid));
upsert c contact.id;
Here, we have two upsert chunks; we're updating five records and inserting five more, all in one DML statement. I've purposefully turned off everything else in my org except a single process builder that updates the account with the contact's name. The logs end up looking like this:
Number of SOQL queries: 4 out of 100
Number of query rows: 11 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 3 out of 150
Number of DML rows: 20 out of 10000
The code I wrote uses the following limits:
Number of SOQL queries: 2 out of 100
Number of query rows: 6 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 1 out of 150
Number of DML rows: 10 out of 10000
Activating the process added 2 more queries, 5 more query rows, 2 more DML statements, and 10 more DML rows. My DML statement is an upsert, which it decided were five inserts and five updates, so two "chunks." Apparently, only 5 records were queried, because we went from 6 to 11 rows queried, 2 additional queries were issued, 2 DML statements resulted from the two chunks, and 10 more rows were added (one for each original row in DML statement).
As you can therefore conclude, it is 1 query and 1 DML statement per chunked transaction. Keep in mind that you're also charged for query rows and DML rows accordingly.